Camelia, the Perl 6 bug

IRC log for #parrot, 2009-06-01

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:08 Coke sure.
00:09 Coke stuff exists, most of it's not shipped with Tcl or partcl.
00:09 Coke nothing cpan-y.
00:21 bacek_ joined #parrot
00:27 patspam joined #parrot
00:34 Zak joined #parrot
00:40 * Tene asks google for partcl repo
00:42 Tene Coke: can I have commit bit on partcl?
01:01 Coke Thought I already did that. moment.
01:01 Coke http://code.google.com/u/@WRRfRF1YARJBXQd6/ ?
01:02 Coke (same rules as parrot itself)
01:04 Tene Coke: You're right.   I forgot again that my googlecode svn password isn't the same as my googlecode password.
01:05 Tene Coke: rules?
01:05 purl <req> No Web/CGI/HTML!  This includes CGI.pm, damnit!  No colors/bold/autonoise/FAQs/away/mIRCage/paste!  No k3wlt0k/u/ne1/plz/im/ill   This means you.  CGI questions go to #cgi or #cgi-bin. or see http://pound.perl.org/RTFM/pound.perl.guide.html for even more attitude. :) or !! or foad. diaf.
01:05 Coke license/copyright/etc.
01:05 Tene Ah.
01:06 Coke whatchaworkingon?
01:06 Tene Coke: wanted to add support to load libraries wirtten in tcl from other languages.
01:07 Tene All I really need is a way to define things in an appropriate namespace... but if there's a standard tcl way to write a library, that would be obviously better.
01:08 Coke there may very well be. =-)
01:09 Tene And if you could tell me what loading a library from a foreign language should look like in tcl, I could implement that too.
01:12 Coke that is beyond my current level of tcl-fu. I suspect it would involve either package or load.
01:12 Tene I see something about "package provide myLib 1.0
01:12 Tene "
01:13 Tene oh, "namespace eval"
01:34 Tene http://www.wjduquette.com/tcl/namespaces.html
01:34 Coke there ya go. =-)
01:34 Coke Not all of that code may work in partcl. :(
01:35 Tene I know there's at least "eval namespace"
01:35 Coke yup!
01:35 Coke package is kind of a hack.
01:35 Coke ... which should be removed entirely in favor of the library version.
01:35 Tene I'd love to show scheme and tcl interoperating in my next blog post.
01:35 Coke I think I just stubbed it out to stop getting "invalid command" errors.
01:36 Coke ok. If you find anything that doesn't work, open a partcl ticket and I can fixit.
01:36 Coke (or you can, that's also fine. =)
01:36 Tene A patch is fine too.
01:39 Tene Coke: am I not running the full test suite with 'make test'?  I remember complaints about test speed, but that finished in 3m.
01:39 Coke ugh. found another thing that I can't fix until stack traces exist.
01:39 Tene oh, 'make spectest'
01:39 Coke right.
01:39 Tene um, what stack traces do you need?  just reporting?
01:42 Coke invoked from within
01:42 Coke "parray"
01:42 Coke ("uplevel" body line 1)
01:42 Coke invoked from within
01:42 Coke "uplevel 1 $args"
01:42 Tene Coke: to work well with other languages, either the "lowercase some HLL stuff" issue in Parrot needs to be fixed, or I'll have to change .HLL 'Tcl' to .HLL 'tcl' and compreg 'TCL' to compreg 'tcl'.
01:42 Coke You can go ahead and make those changes.
01:42 Tene :)
01:43 Coke so, that stacktrace is what you'd get if you ran [uplevel 1 parray]; [unknown] grabs out the error and rethrows it as if you had run it instead of having unknown run it.
01:44 Coke but if it can't find that, it just barfs.
01:45 dalek partcl: r401 | coke++ | trunk/runtime/variables.pir:
01:45 dalek partcl: use more box
01:45 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=401
02:10 dalek partcl: r402 | coke++ | trunk/ (4 files):
02:10 dalek partcl: Add basic support for -errorinfo and -errorcode to catch/return.
02:10 dalek partcl: This was in an effort to get unknown to properly handle errors generated
02:10 dalek partcl: if the first run of an unknown results in an error, which needs stacktrace
02:10 dalek partcl: support to work. Ironically, this has slightly broken the functional
02:10 dalek partcl: parray test cases by somehome generating extra whitespace after the output.
02:10 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=402
02:12 Coke hurm. scripts expect Tcl version 7.5b1 or later but the loaded version is
02:12 Coke only 8.5.6
02:16 Coke ah. library/package.tcl != [package]
02:24 dalek partcl: r403 | coke++ | trunk/runtime/tcllib.pir:
02:24 dalek partcl: Claim to be the version we're targeting.
02:24 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=403
02:25 darbelo joined #parrot
02:26 ruoso joined #parrot
02:27 Coke in parrot, how can I tell if a file is executable?
02:35 janus joined #parrot
03:00 Coke msg bacek - I tested the wrong variant. I'm getting an error on :flat
03:00 purl Message for bacek stored.
03:00 Coke msg bacek (double checking on trunk)
03:00 purl Message for bacek stored.
03:18 cotto seen tewk
03:18 purl tewk was last seen on #parrot 5 days, 29 minutes and 14 seconds ago, saying: goes to search irc logs  [May 27 02:46:07 2009]
03:24 Coke msg bacek getting the error on trunk, too; I suspect I've been testing the wrong thing for a few days, so it's not your fault.
03:24 purl Message for bacek stored.
03:27 Theory joined #parrot
03:35 bacek_ OH HAI
03:35 bacek_ Coke: apparently not every single bug in the World is my fault :)
03:38 Andy joined #parrot
03:41 Coke lucky you, or I'd make you fixit.
03:41 Coke I started generating invalid PIR, I think, but I'm not sure why my 'make test' didn't cover this. :|
03:46 bacek_ oh shi...
03:48 Coke prove t/tcl_misc.t, if anyone's bored.
03:49 david joined #parrot
03:55 bacek_ Coke: why don't switch to PCT?
04:01 Coke bacek: feel free to steal http://code.google.com/p/p​artcl/issues/detail?id=59
04:01 Coke I was avoiding it for some time because it didn't support .HLL
04:02 Coke now that it does, I have no objection. tcl may not be the best fit for it, but it should still work.
04:04 pmichaud Ugh.  hll_map is really slow.
04:07 Coke initial setup or using it later?
04:07 pmichaud using it later
04:07 Coke if you can speed that up, tcl will be happy. =-)
04:07 pmichaud for now I'll just complain about it. =-)
04:08 pmichaud Time to create 100000 parrot Integers:  0.058s
04:08 pmichaud Time to create 100000 MyInts through hll_map:  0.315s
04:09 Coke where MyInt is a PMC or a class?
04:09 pmichaud class
04:09 Coke that might be your slowdown. try mapping Int to Float or something to see if a PMC is faster?
04:09 pmichaud it might be my slowdown, but using PMCs isn't really an option for me at present
04:09 pmichaud not without basically rewriting the entire Object system.
04:10 Coke no, but it would be nice to know where the slowdown is.
04:10 Coke a better case might be to compare creating 100K non-mapped MyInts, then.
04:10 pmichaud about to do that also
04:10 Coke and see if the mapping is adding any significant ... ok. =-)
04:11 Coke I suspect it's mostly the class.
04:11 pmichaud mapping Integer to Float:  0.086s
04:11 pmichaud creating 100K non-mapped MyInts:  0.400s
04:12 Coke see, hll_map is fast! =-)
04:12 Coke it shaved 0.1s off! =-)
04:12 Coke <duck>
04:13 pmichaud oh, my comparison wasn't really fair there
04:13 pmichaud just a sec
04:13 pmichaud creating 100K non-mapped MyInts:  0.304s
04:21 bacek_ pmichaud: how you create them? Just 'new "MyInt"'?
04:21 pmichaud new $P0    where $P0 is the class object
04:21 pmichaud the first one I did was   new ['MyInt']   which added the cost of the class lookup (which is why it wasn't a fair comparison)
04:22 pmichaud so, using   new ['MyInt']   --> 0.400s
04:22 pmichaud using    new myintclass    --> 0.304s
04:22 pmichaud using   box $I0    --> 0.315s
04:22 Coke so hll_map is pretty cheap, relatively.
04:22 Coke (to class creation itself)
04:22 bacek_ oo_get_class doesn't cache created proxies.
04:23 pmichaud there's no proxy here.
04:23 pmichaud well, hll_map is cheap compared to creating the objects of the derived class, but expensive compared to what rakudo is doing now.
04:24 Coke were you just using plain integers before?
04:24 pmichaud yes
04:24 Coke ah.
04:24 Coke I figured you were manually using the classes.
04:24 pmichaud No.
04:25 Coke well, anything you can do to speed that up, I would appreciate. =-)
04:25 pmichaud sure, but it looks as though hll_map to PMCs isn't so bad
04:25 pmichaud only a 60% slowdown instead of a 500% slowdown =-)
04:25 Coke t/compilers/pge/pge_examples            (Wstat: 0 Tests: 2 Failed: 0) TODO passed:   2
04:25 Coke Files=395, Tests=11929, 255 wallclock secs ( 3.74 usr  3.12 sys + 98.60 cusr 93.01 csys = 198.47 CPU)
04:25 Coke Result: PASS
04:26 Coke (that on my automated midnight run.
04:31 Zak joined #parrot
05:04 Coke I don't know how this test was ever passing. wtf.
05:04 particle joined #parrot
05:17 Coke particle: hio
05:17 particle ahoy, coke
05:18 particle just back from sfo
05:23 Theory joined #parrot
05:36 pmichaud there are times when Parrot really frightens ms
05:36 pmichaud *me
05:37 Coke ?
05:37 pmichaud nopaste coming
05:38 Coke AHA.
05:38 Coke my partcl test failures? introduce by parrot. working on a bisect now.
05:38 Coke "uced"
05:39 dalek TT #727 created by coke++: remove config steps 'auto:macports' and 'auto:fink'
05:41 * Tene eagerly awaits nopaste
05:41 pmichaud just doing some final timings
05:41 pmichaud anyway, here's the gist
05:42 bacek_ pmichaud: "$P0 = subclass 'Integer', 'MyInt'" creates Proxy for Integer... And then in 'new "MyInt"' it spent all time working out attributes...
05:43 nopaste "pmichaud" at 72.181.176.220 pasted "DON'T use keyed lookups for isa PMC types in HLLs" (26 lines) at http://nopaste.snit.ch/16758
05:43 nopaste "pmichaud" at 72.181.176.220 pasted "DO use lookups by namespace" (29 lines) at http://nopaste.snit.ch/16759
05:43 pmichaud note that I'm even pessimizing the second example by repeatedly looking up the class inside the loop
05:44 Tene pmichaud: should the "load_bytecode" calls in rakudo-generated PIR be replaced with 'load_language'?
05:44 pmichaud Tene: not yet.
05:45 Tene Why's that?
05:45 pmichaud because I want to understand exactly what load_language does first
05:45 Tene load_bytecode with a different search path.
05:45 pmichaud and the search path is... ?
05:46 Tene It looks for lang/lang.pbc with parrot_locate_runtime_file_str
05:46 * Coke wonders if infinoid is awake.
05:47 pmichaud does it check the current directory also?
05:47 pmichaud or just lang/lang.pbc ?
05:47 Tene Let me check...
05:47 pmichaud does it work with a devel copy of parrot, as opposed to an installed parrot?
05:47 pmichaud Let's just say that I find it to be very underdocumented, and my (weak) protest is to not use it yet.
05:47 Tene It works with either.
05:48 Tene No, doesn't look in .
05:48 pmichaud That's a problem.
05:49 Coke bah. anyone know why svn-bisect complains that --max 39300 is bigger than 39291 for parrot?
05:49 Tene I'm not sure that the solution is really to change load_language instead of improving the process of working against an uninstalled parrot.
05:50 pmichaud I'm not necessarily claiming we should change load_language.
05:50 Tene With 'load_bytecode', precompiled .pm can fail.
05:50 Tene is the issue I was running into.
05:50 pmichaud ...and load_language fixes that?
05:50 Tene Yes.
05:50 pmichaud why is it a problem for load_bytecode and not load_language, then?
05:51 Tene should 'perl6.pbc' really be in the normal search path for 'load_bytecode'?
05:51 Tene instead of 'languages/perl6/perl6.pbc'?
05:51 pmichaud should I have to copy perl6.pbc into my Parrot directory before I can use it with load_language?
05:51 pmichaud what if I don't have write permission to that directory?
05:52 Tene I added a symlink to my rakudo checkout to lib/1.2.0-devel/languages/perl6 in my installed copy
05:52 pmichaud what if I don't have write permission to that directory...?
05:52 Coke (ah. svn-bisect is too smart for my own good)
05:52 pmichaud (as might be the case with an installed parrot)
05:52 Tene There's an environment variable for runtime search path.
05:52 Coke pmichaud: I imagine you'd put it into a local runtime/ dir.
05:52 Coke (as opposed to the installed one.)
05:52 Tene Oh, load_language also adds to the include and dynext path.
05:52 Theory joined #parrot
05:53 pmichaud I'd _really_ like to see these paths documented somewhere.
05:54 Tene Where would you expect to see them documented?
05:55 pmichaud I don't know.  I haven't seen any mailing list discussion or documentation about the changes in paths.
05:55 pmichaud It just seems to "happen".
05:56 pmichaud mind, I'm glad that it happens.  I just learned a couple of days ago that I can create my own dynext/ directory for the dynops and dynpmcs (from looking at the tcl makefile)
05:56 pmichaud but it would be really nice to see that actually written somewhere.
05:56 pmichaud anyway, rakudo's startup sequence is already a little fragile, and it affects 'use' semantics and a bunch of other stuff.
05:57 pmichaud I'm also about to implement BEGIN { ... }
05:57 pmichaud (like, so that it really works in compiled code)
05:57 pmichaud so I'd rather not muck with the startup sequence right this moment
05:57 Tene Okay.
05:57 pmichaud also, it still doesn't make sense to me that load_language works but load_bytecode doesn't
05:57 pmichaud that's just... weird
05:58 Tene load_bytecode would work if I put perl6.pbc directly into the runtime directory
05:58 pmichaud and load_bytecode *should* work.  Libraries can have dynops and dynpmcs too -- those aren't restricted to compilers and languages.
05:58 pmichaud currently load_bytecode fails for me with precompiled .pm
05:58 Tene load_bytecode will also work if my cwd has perl6.pbc in it
05:59 pmichaud Tene:  on my system, with perl6.pbc in the cwd, precompiled .pm files fail.
05:59 pmichaud it looks like the same issue as TT #150 when I try it.
06:00 Tene pmichaud: run parrot under strace -estat
06:00 pmichaud Can this wait, please?
06:00 Tene does it not look for ./perl6.* ?
06:00 Tene Sure. :)
06:00 pmichaud I've been working on postfix:<++> all day, and I'd like to finish it before going to bed tonight.
06:00 Tene not currently an issue or blocker for me whatsoever.
06:01 pmichaud and I'm getting frustrated by these little parrot oddities here and there (such as the nopastes I just gave)
06:01 Tene I'll write up what I can, and see where to add it to the docs.
06:01 pmichaud It might make sense to put it in pdd*_install
06:01 pmichaud and we also need a pdd for compiler objects, so perhaps there
06:02 pmichaud but overall I'd just like to see a summary (mailing list okay) of what the current state of building and installing is (and what it's expected to be)
06:03 Tene hmm.  Maybe I can barter some partcl patches with Coke for that. :)
06:03 pmichaud i.e., where language bytecode files go, how one officially creates a "foo" executable that isn't the fakecutable, where libraries go, etc.
06:13 dalek TT #728 created by coke++: r39273 breaks 'make test' for tcl
06:13 Coke msg bacek hey, turns out you DO break all the code. =-)
06:13 purl Message for bacek stored.
06:15 Tene ... ouch.  partcl registers a function as its compiler with compreg... not an object.
06:16 Tene So I can't add methods to it without changing that.
06:17 Tene Coke: permission to change that?
06:17 bacek_ Coke: hey, it's impossible
06:17 Coke Tene: that code is from when 'compile' was still an opcode. =-)
06:18 pmichaud other possibility is to register a different object
06:18 Coke You can change it, sure. I think there's a test in t/ for it.
06:18 pmichaud i.e., keep the existing compiler the same, but create a new one under a different compreg name
06:18 Coke (it's acting like PIR's compiler, not rakudo's)
06:18 Coke no need to keep 2 compilers.
06:18 pmichaud fair enough, was just providing a stop-gap.  :-)
06:18 Coke bacek_: I was being facetious, but in this case, I think r39273 is yours.
06:18 Tene Hmm... the existing compiler is registered under 'TCL', which won't work anyway...
06:18 pmichaud right.
06:19 pmichaud so just register the new one under the name that will work :-)
06:19 Coke Tene: you can change it to 'tcl', too, that's fine.
06:19 pmichaud anyway.
06:19 Coke Tene: just be sure to test against r39272 of parrot.
06:20 * Tene discovers yet again his inability to work with svn.
06:20 dalek partcl: r404 | coke++ | wiki/Par (2 files):
06:20 dalek partcl: Document our maximum-required version of parrot, track another parrot bug.
06:20 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=404
06:22 Coke Tene: hey, use a different password.
06:22 Coke Tene: commit something so it'll cache your password. =-)
06:22 Tene Coke: it was trying to deal with reverting my local changes this time.
06:23 Tene i decided to just rm it all and re-check-out with git-svn
06:24 Coke tene; don't forget to update your credits entry when you commit. Danke.
06:28 pmichaud well, I'm personally shocked at how hard it's turning out to be to get a reasonably-efficient postfix:<++> to work.  :-|
06:28 Coke shocked?
06:28 purl I'm shocked... SHOCKED...
06:28 Coke I tend towards "recurringly disappointed" =-)
06:28 pmichaud I'm disappointed, too.
06:28 Zak joined #parrot
06:29 pmichaud but I didn't expect it to take 12 hours (with small breaks here and there)
06:29 pmichaud and I'm still not done yet.
06:30 pmichaud Tene: you might have missed the earlier discussion, but it turns out that we lose a ton of speed if we 'hll_map'  Integer/Float to Int/Num
06:30 Tene Huh.
06:30 Tene I did miss that.
06:31 pmichaud boxing $I0 into 'Int' takes about 5 times as long as it does to box it into an 'Integer'  (which is what it currently does)
06:31 Tene That's... unfortunate.
06:32 pmichaud In fact, that likely means that the takeaway from that is that we should avoid $I and $N registers as much as possible.
06:33 pmichaud I wonder if cloning is cheaper than boxing.
06:34 Tene Coke: Okay, I'll just do whatever and let you clean up the pieces.
06:35 Coke pmichaud: does rakudo handle nan?
06:35 pmichaud somewhat.
06:35 pmichaud it passes some nan tests and knows how to parse it
06:36 Coke oh, duh, I can just special case it. (most floats are created with something like "box 3.2")
06:37 viklund joined #parrot
06:37 nopaste "tene" at 24.10.199.37 pasted "weird partcl build failure for Coke++" (18 lines) at http://nopaste.snit.ch/16760
06:38 Coke Tene: how many *.sos do you have there?
06:38 Tene Four.
06:38 Coke what do you get if you run that perl command by hand?
06:39 Coke (from the subdir)
06:39 Tene the same output
06:39 Coke what OS?
06:39 Coke (works for me on feather and OS X...)
06:39 Tene Fedora Linux x86_64
06:39 Tene It worked fine when I built from svn...
06:40 Coke did you reboot^Wrealclean?
06:40 Tene yes
06:40 Tene lemme confirm if it works from svn again....
06:41 Tene Yes, it works from an svn checkout.  wtf?
06:42 Tene Oh...
06:42 Tene [sweeks@kweh ops]$ file ../../dynext
06:42 Tene ../../dynext: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
06:42 Tene where dynext is a directory in my svn checkout?
06:43 Coke yes.
06:43 Coke should be an empty dir.
06:43 Tene ah, git can't handle empty directories
06:43 pmichaud WHAT?!?  SOMETHING THAT GIT CAN'T HANDLE?!?  :-)
06:43 Tene OK, everything works now. :)
06:43 Coke I would not be averse to having the directory removed and having it created as part of the build process.
06:44 Tene but... but what about workarounds? :(
06:44 Coke if that'll help you use it on git and therefore send more patches.
06:44 Coke whee. [expr nan] -> NaN.0
06:44 pmichaud anyway, I'm done for the day, I think.  I'll pick back up on this tomorrow, along with /lots/ of wonderful things to discuss/explore with jonathan++ :-)
06:44 * Coke wonders how to generate a nan
06:44 Tene 'night pm
06:45 pmichaud I think Rakudo does it with
06:45 pmichaud $N0 = 'nan'
06:45 Coke I mean from tcl.
06:45 pmichaud oh.
06:45 pmichaud anyway, I'm gone.
06:45 Coke I want to see how realtcl formats nan.
06:45 Coke later.
06:45 bacek_ g'night pm
06:54 UltraDM joined #parrot
06:57 Coke rant: there's no painless way to check for isNan. :|
06:59 Coke $N0 = $P0, $S0 = $N0, if $S0 == 'NaN' is the cleanest I've found.
07:00 UltraDM joined #parrot
07:06 Coke (though that's pretty easy to turn into a macro)
07:07 Tene Oops, forgot to make it actually work right.
07:08 Coke ... that might be a problem.
07:09 dalek partcl: r405 | tene++ | trunk/ (3 files):
07:09 dalek partcl: Add a 'tcl' compiler object that has a 'load_library' method
07:09 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=405
07:10 Tene Coke: can I dump a tcl file to PIR?
07:11 Coke not really.
07:11 Coke You can do parrot -D60 tcl.pbc foo.tcl, though.
07:11 Tene Oh, the proc is named with a leading & in the namespace
07:11 Coke (maintaining the --pir option was too much work.)
07:12 Coke Tene: yes. since I need to support &foo and $foo
07:12 Coke in tclspeak, [foo] and [set foo]
07:12 Coke er, and [namespace foo] =)
07:13 Tene oh, procs aren't subs, they're TclProcs.
07:14 Coke which isa Sub.
07:14 Tene Ah.
07:16 Tene Oh, that's all...
07:16 Tene I can't call a sub with a name that starts with an & from rakudo.
07:16 Coke aha. I blame rakudo! =-)
07:17 Coke (Ironically, I made my subs start with that to try to adhere to perl standards, initially)
07:17 Coke now I'm stuck with it, since of namespaces, vars, and subs, having namespaces be the real name seems the most important.
07:19 nopaste "tene" at 24.10.199.37 pasted "Having said that, Coke, this now works, as long as you invoke it from the right directory..." (3 lines) at http://nopaste.snit.ch/16761
07:19 dalek partcl: r406 | tene++ | trunk/runtime/tcllib.pir:
07:19 dalek partcl: Make load_library actually return something (mostly) useful.
07:19 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=406
07:19 Tene so Tcl is kinda like a lisp-2
07:20 nopaste "tene" at 24.10.199.37 pasted "Oops, here's the .tcl" (4 lines) at http://nopaste.snit.ch/16762
07:21 Tene Yeah, I have no clue how to deal with that... hopefully pmichaud will have some API ideas on how to get useful names... :(
07:23 Tene Coke: how bad do you think it would be to return symbols without a leading sigil?
07:28 Tene This also means that if tcl imports anything from another language, it will need to add & to incoming functions.
07:28 Tene (and $ to incoming variables?)
07:32 Coke yes.
07:32 Coke Unless you can make namespaces not suck.
07:33 Tene Well, if it's adding to incoming vars, I'll strip on outgoing vars for now.
07:33 Coke hokay
07:33 Tene kinda evil, but... m'eh
07:40 eiro joined #parrot
07:42 eiro joined #parrot
07:46 Tene Coke: check this out: http://gist.github.com/121293
07:47 Coke is the second block supposed to be tcldemo.pl ?
07:47 Tene Uh, yeah.
07:47 Coke then woot. =-)
07:48 dalek partcl: r407 | tene++ | trunk/runtime/tcllib.pir:
07:48 dalek partcl: Remove sigils from outgoing subs in load_library
07:48 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=407
07:48 Tene I tend to use very short filenames, and then rename them in my pastes.  Sometimes I miss parts when lieing.
07:48 Tene Most commands that I run more than a few times in one shell, I usually set one-letter aliases for.
07:49 Tene Now if I can just find out what foreign library *import* should look like for scheme and tcl...
07:49 Coke you broke a test.
07:49 Tene :(
07:49 Coke prove t/cmd_namespace.t
07:50 Coke (you just need to move compiler out of the root_hll namespace.
07:50 Tene oh, into _tcl
07:50 Coke <nod>
07:51 Coke or parrot, just not tcl.
07:53 dalek partcl: r408 | coke++ | trunk/ (6 files):
07:53 dalek partcl: First pass at NaN support in tcl.
07:53 dalek partcl: - NaN now parses as a float, generates a TclFloat eq 'nan'.
07:53 dalek partcl: - all operators we tested nan for now properly squawk when used with NaN
07:53 dalek partcl: - todo the remaining NaN tests (instead of skip)
07:53 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=408
07:53 Tene Coke: fixing...
07:53 purl it has been said that fixing is good, definitely.
07:53 Coke tene;danke.
07:53 Coke support nan is expensive at runtime. =-)
07:53 Coke support /of/
07:54 Coke all the infix:: ops now have to check explicitly for nan usage in order to generate the appropriate tcl error.
07:55 Coke tene++
07:56 iblechbot joined #parrot
08:01 Tene getting some really weird errors...
08:01 Tene :(
08:04 Tene Null PMC access in get_string()
08:04 Tene current instr.: 'compileTcl' pc 23866 (runtime/conversions.pir:367)
08:04 Tene That line is:
08:04 Tene .sub compileTcl
08:06 Tene I don't get it.
08:06 Coke ok. I have to sleep soon; if you can't figure it out, open a partcl ticket with whatever you have, I'll look at it later.
08:07 Tene Okay.
08:07 Tene 'night
08:07 dalek partcl: r409 | coke++ | trunk/ (2 files):
08:07 dalek partcl: make [expr nan] fail properly
08:07 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=409
08:14 Coke bacek++
08:14 Tene Coke: I'll look at it again tomorrow.
08:16 mikehh joined #parrot
08:21 Coke hokay
08:26 dalek partcl: r410 | coke++ | trunk/ (3 files):
08:26 dalek partcl: make function(nan) squawk with a domain error.
08:26 dalek partcl: - make a .macro to simplify this. use it back in [expr nan]
08:26 dalek partcl: All nan-related test in t/cmd_expr.t now pass.
08:26 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=410
08:34 ZuLuuuuuu joined #parrot
08:39 barney joined #parrot
09:01 masak joined #parrot
09:18 mikehh_ joined #parrot
09:23 bacek joined #parrot
09:45 bacek oh hai
09:56 mikehh joined #parrot
10:01 donaldh joined #parrot
10:19 rdice joined #parrot
10:56 bacek msg Coke problem of TT#728 in Scalar.concatenate_str. If I replace Parrot_pmc_try_reuse with pmc_new test passed. But I don't understand roots of this problem...
10:56 purl Message for coke stored.
10:57 rdice left #parrot
11:20 donaldh joined #parrot
11:49 forthat joined #parrot
11:54 muixirt joined #parrot
12:00 Infinoid bacek: (re: #728) I don't fully understand this code, but... your latter version changes semantics quite a bit, Parrot_pmc_try_reuse() updates the "dest" PMC for *all* code which keeps a pointer to it, and after the patch, only the caller gets the update
12:03 Infinoid In other words, if I had a string "bar" and had 3 pointers to it (lexpad, stack and register), and another string "foo", and did a "$foo .= $bar", Parrot_pmc_try_reuse() would unset $bar in all places, which most definitely is *not* what we want
12:03 bacek Infinoid: but all calls to "try_reuse" calculate result before...
12:04 bacek oh...
12:04 Infinoid I'm not sure my example is completely accurate, but I think that's the semantic difference
12:06 bacek It can be not very accurate, but there is some deep hiding bug in Parrot spotter in this ticket
12:06 bacek Because second version of patch fix problem as well..
12:08 Infinoid the fact that the second version of the patch fixes the problem, to me, implies that having using Parrot_pmc_try_reuse() there breaks assumptions about the PMC not being shared/used anywhere else
12:08 bacek Hmm...
12:08 Infinoid Previously it just returned an empty string, now (with r39273) you're overwriting an existing PMC (which could be used elsewhere) with an empty string
12:09 Infinoid Or do I misunderstand the idea behind Parrot_pmc_try_reuse()?
12:09 bacek No, you don't...
12:10 Infinoid ok.  Sorry, but I think it sounds dangerous to overwrite PMCs without knowing who else uses them
12:10 ruoso joined #parrot
12:11 bacek There is major misundesrtand between me, pmc_reuse and parrot
12:12 bacek And VTABLE
12:12 bacek Consider code: $P0 = hash['key']; $P0 = 1;
12:13 bacek Should we update stored value in this case?
12:14 Infinoid in that case I think it will call set_integer on $P0, so probably yes
12:15 bacek (If "yes" than usage of Scalar it incorrect, if "no" than we have to bury pmc_reuse)
12:15 bacek Ah, "yes"...
12:17 bacek ok. So we need some kind of resolution. If $Pn treated as pointer, than we hit hit bug in PGE. If not - than I'll apply my patch for try_reuse.
12:18 Infinoid All it does is call set_integer_native, it's up to the PMC to do something intelligent with that
12:18 Infinoid for instance, for RPAs, I think that will set the number of entries in the array to 1
12:19 Infinoid I don't think it will morph the PMC to an Integer, if that's what you were expecting
12:19 bacek In this case it call "set_string_native", but it doesn't matter...
12:19 Infinoid ok
12:20 Infinoid r39273 changed quite a few things, I'm worried about what else it may have broken
12:21 Infinoid The reason I'm having trouble understanding this stuff is, I'm not sure it's ever possible to detect whether your caller is the only code using this pmc or not
12:23 Infinoid in some cases, like "$foo = 'bar'", I would expect all copies to be updated, in others, returning a newly created PMC sidesteps that problem (with some extra GC overhead)
12:24 Infinoid Was the intention of this patch to reduce GC overhead?
12:24 bacek yes
12:24 Infinoid that's a great goal :)
12:24 bacek indeed... But...
12:25 Infinoid I don't have enough time to review the design for this stuff, but I guess it really comes down to whether the caller wants you to update all instances of the pmc, or just generate some local value which the caller might simply discard
12:26 Infinoid (I have to leave soon)
12:26 bacek I just need one word about treating PMC's as pointers.
12:26 bacek I have to go to bed soon :)
12:27 ZuLuuuuuu joined #parrot
12:28 Infinoid what about treating PMC's as pointers?
12:28 HG` joined #parrot
12:32 bacek Than there is bug somewhere else.
12:32 Infinoid where?  why?  I don't understand
12:32 bacek TCL of (unlikely) PGE reuse old PMC after "concat"
12:33 Infinoid are you saying it should copy the string before calling concat?
12:33 bacek $P0 = "foo"; $P1 = $P0; $P0 = concat "bar","baz"; say $P1
12:34 bacek (copy) Yes.
12:34 bacek before r..3 $P1 was preserved.
12:35 bacek after - not.
12:35 Infinoid in this case, it is the caller who decides what to do with the truncated string.  it might assign it back to the original variable or it might discard it, the concat method can't know
12:35 Infinoid that's why it's hard to review the design of this, because the semantics vary depending on which method
12:36 bacek "<bacek> I just need one word about treating PMC's as pointers." :)
12:37 Infinoid inline op concat(out STR, in STR, in STR) :base_mem {
12:37 Infinoid $1 = Parrot_str_concat(interp, $2, $3, 1);
12:37 Infinoid }
12:37 Infinoid I think your change is modifying $3
12:37 Infinoid even though it's only supposed to be an "in", not an "inout"
12:38 Infinoid the caller gets the new string as the return value, $1
12:39 bacek inline op concat(invar PMC, invar PMC, in STR) :base_core {
12:39 bacek $1 = VTABLE_concatenate_str(interp, $2, $3, $1);
12:39 bacek }
12:39 bacek this one.
12:39 purl it has been said that this one is bugged too now
12:39 bacek Someone holds $1.
12:39 bacek And I update it....
12:39 Infinoid are you sure?  $P0 = concat "bar","baz" looks like two STRs
12:40 bacek Second patch for concatenate_str. So I'm 100% sure
12:41 bacek (But my example if 100% incorrect)
12:42 bacek It should be something like this:
12:43 bacek $P0 = "foo"; $P99 = $P1; $P1 = concat $P0,"baz"; say $P99
12:45 bacek (oh. My English is failing.)
12:45 Infinoid ok
12:45 bacek It should by "is 100%" few lines above.
12:46 Infinoid So the issue is, $P99 and $P1 aren't really PMCs, they are register entries (pointers to PMCs)
12:46 Infinoid Before your change, $P1 would end up pointing to a new PMC, afterwards, the pointer wasn't updated and the PMC itself was overwritten
12:47 Infinoid Right?
12:47 bacek indeed
12:47 Infinoid Thanks, that makes sense.  This is quite a serious semantic change, no wonder it broke things
12:49 bacek Main problem is in "$P0 = hash['key']; $P0 = 1;".
12:50 bacek We have to decide, how $Pn treated. For consistency sake.
12:51 Infinoid Let me guess... hash['key'] is updated, because you're changing the PMC instead of the pointer?
12:51 bacek yes
12:52 Infinoid Ok.  Please don't do that? :)
12:52 Infinoid I think any semantic change at the PIR level will require updating all the HLLs, which sounds like a Bad Thing
12:52 bacek Should we update stored value in this case?
12:52 bacek <Infinoid> in that case I think it will call set_integer on $P0, so probably yes
12:53 Infinoid if it didn't update the stored value before, then I would be very reluctant to change that behavior
12:53 bacek (This is next line after my "$P0 = hash['key']; $P0 = 1;" question)
12:54 bacek It did, but not always.
12:54 Infinoid Right, I think it depends on the type of PMC
12:55 Infinoid If there's an underlying design issue here, I think that it should really be up to the *ops* to determine which things get overwritten, not the pmc methods themselves
12:55 * bacek voted for consistency...
12:56 Infinoid but all of this is way above and beyond a simple GC optimization :)
12:56 bacek It's just another "undefined behaviour" in C++ terms...
12:57 bacek And I want to make it "defined".
12:57 gryphon joined #parrot
12:57 Infinoid I don't have a problem with that.  Though I think it would need a deprecation cycle, and a nice flame war on the list beforehand to make sure it's really correct
12:58 bacek :)
12:58 pmichaud hello
12:58 pmichaud the meaning of "$P0 = hash['key']; $P0 = 1'  is very clear
12:58 pmichaud it's the same as
12:58 pmichaud set $P0, hash['key']
12:58 bacek I will happy to remove try_reuse in favour of PMC_IS_NULL
12:58 pmichaud set $P0, 1
12:59 pmichaud the first will bind  $P0 to the entry in hash['key']
12:59 pmichaud the second will depend on the identity of $P0
12:59 pmichaud most of Parrot's built-in PMCs treat the second like an assign
12:59 pmichaud (but not always, and not all)
13:00 Infinoid at the very least, the opinions of allison and chromatic would be valuable before you make that kind of design change
13:00 bacek Hooray!
13:00 bacek $P0 = "foo"; $P99 = $P1; $P1 = concat $P0,"baz"; say $P99
13:00 Infinoid In the meantime, can you back out r39273 until a less obtrusive optimization can be found?
13:01 pmichaud bacek: in that instance, $P99 should be unchanged.
13:01 bacek pmichaud: why?
13:01 pmichaud because it's not the same as $P1
13:01 pmichaud the three argument form of concat constructs a new string, it doesn't modify an existing one.
13:01 pmichaud i.e., it's not an in-place concatenation.
13:02 pmichaud so then $P1 ends up pointing to the new string, and $P99 continues to point to the old one.
13:02 bacek $P1 = 1; $P1 = add $P1, 2;
13:02 bacek $P1 = 1; $P2 = $p1; $P1 = add $P1, 2; say $P2
13:02 pmichaud in this one, $P2 is also unchanged
13:03 bacek ok. So try_reuse is wrong.
13:03 pmichaud now then
13:03 purl now then are found :P
13:03 bacek I'll remove it tomorrow
13:03 pmichaud $P1 = 1;  $P2 = $P1;   add $P1, 2;   say $P2    # $P2 changed
13:03 pmichaud because the 2-argument form of add is an inplace add
13:06 bacek try_reuse is still wrong...
13:08 dalek parrot: r39301 | barney++ | trunk (3 files):
13:08 dalek parrot: Some tidbits in PCRE library.
13:08 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39301/
13:08 bacek we treat $Pn as something between pointers and values. So, we can't reuse them in 3-args ops.
13:08 pmichaud I don't quite understand that
13:09 Infinoid we're not really trying to map them directly onto C pointer/value semantics
13:09 bacek $P0 = hash['key']; $P1 = $P0; $P0 = 'new_value'; say $P1
13:09 pmichaud $P1 unchanged
13:09 pmichaud oh, wait
13:09 pmichaud no
13:09 pmichaud because of the string
13:09 pmichaud (I thought you meant "do something that makes a new value")
13:10 pmichaud the difference is generally that    set <pmc>, <pmc>
13:10 pmichaud means something very different from
13:10 pmichaud set <pmc>, <int>
13:10 pmichaud set <pmc>, <str>
13:10 pmichaud set <pmc>, <num>
13:11 Infinoid afk_coke: ping
13:11 pmichaud Personally, I think that's a design issue
13:11 pmichaud i.e., it was done incorrectly
13:12 bacek Ha! So "foo_native_TYPE" shouldn't reuse dest? Like "concatenate_str"?
13:12 pmichaud we shouldn't have    the set_p_i   set_p_n   set_p_s   opcodes, we should've just stuck with   assign_p_i  assign_p_n   assign_p_s
13:12 pmichaud because the set opcodes really act more like assign
13:12 pmichaud i.e., the change the value of the target PMC instead of changing the PMC register
13:13 Infinoid ...sometimes
13:13 Infinoid set_p_i is useful for (for instance) resizing arrays
13:13 pmichaud Infinoid: sure, but assign_p_i  does the same thing
13:13 Infinoid ah, ok.
13:13 Infinoid even though it's named misleadingly in that case
13:14 Infinoid I guess set_ is just as misleading
13:15 pmichaud anyway, that train left the station a long time ago, I think.
13:15 Infinoid yeah
13:15 burmas joined #parrot
13:16 bacek but... Why can't catch this train and fix it?
13:16 bacek This code isn't cut on stone
13:17 Infinoid it is until we've gone through a deprecation cycle, at the very least
13:18 bacek 1.5 is soon :)
13:18 Infinoid but it seems like a lot of effort (code, documentation and retraining) without much gain
13:18 * Infinoid would much rather have shiny new features
13:19 bacek I've spent ~6 hours investigating this issue...
13:19 pmichaud bacek: changing this would require rewriting basically all of the existing PIR codebase
13:19 bacek Just because semantic isn't clear.
13:19 Infinoid all of the HLLs, examples, tests would need to be reviewed/edited
13:20 pmichaud the semantic is clear if we remember that int, num have value semantics while pmcs and strings have reference semantics
13:21 pmichaud it's very much like C in that respect
13:22 bacek $P99 = $P1; $P1 = concat $P0, "foo"; say $P99
13:23 bacek It's not quite C-like semantic...
13:23 pmichaud sure it is
13:23 pmichaud if one assumes that "concat" means "allocate a new string that is the concatenation of $P0 and "foo""
13:24 skids joined #parrot
13:25 barney joined #parrot
13:25 bacek Ok, I'll commit second version of patch from T#728 tomorrow and add big warning notice about using try_reuse from "value semantic" function.
13:28 Infinoid What about the other things changed in r39273?  I'm worried there may be other fallout, our testsuite probably wasn't written with this kind of semantic change in mind
13:28 Whiteknight joined #parrot
13:29 bacek $P0 = hash['key']; $P1 = $P0; $P0 = 'new_value'; say $P1
13:29 bacek $P99 = 'new_value'; $P0 = hash['key']; $P1 = $P0; $P0 = $P99; say $P1
13:29 bacek Is it different?
13:30 Infinoid yes
13:30 bacek Is it different after implementing PIR optimiser with value propagation?
13:30 Infinoid in the first example, if $P0 is (for instance) a Packfile, it will stay a Packfile, and try to unpack the string
13:31 Infinoid the second example uses simple pointer semantics, I think
13:31 bacek ok, I'll add PARROT_ASSERT(value) in try_reuse.
13:33 Infinoid if you can fix everything and guarantee that no PIR semantics have changed, great.  Otherwise, sorry, but I think you need to back out the patch
13:34 bacek I'm happy to revert any changes if they are wrong.
13:34 Whiteknight what does try_reuse do?
13:34 bacek I scraped whole branch for this reason.
13:35 bacek Whiteknight: try reuse pmc when C<dest> preovided
13:35 bacek provided
13:35 Whiteknight ah, okay
13:36 Infinoid ok, I have to go... good luck with it
13:36 bacek But not all C<dest>s are equal...
13:41 pmichaud in bacek's last paste
13:41 pmichaud 13:29 <bacek> $P99 = 'new_value'; $P0 = hash['key']; $P1 = $P0; $P0 = $P99; say $P1
13:42 pmichaud $P1 will have the value of hash['key']
13:42 pmichaud $P0 will point to $P99
13:42 pmichaud let me look a bit closer
13:43 pmichaud first, note that one cannot say   $P99 = 'new value'   unless $P99 has already been given a PMC
13:43 pmichaud so without knowing that, it can't be answered in general
13:43 ZuLuuuuuu left #parrot
13:45 barney Is http://gist.github.com/121411 sane? When using pcre.pir in Pipp, there is a different HLL-root, so symbols are not found.
13:59 nnunley joined #parrot
14:13 mj41 joined #parrot
14:15 Tene barney: the other option is to export the PCRE namespace to your hll root
14:28 barney I'm a bit confuse. There might be a messup with    .HLL '_pipp'     and   .HLL 'Pipp'
14:50 NotFound barney: the HLL of pcre.pir is parrot, isn't it?
14:51 NotFound Ah, is an example of use.
14:52 Steve_H joined #parrot
15:01 barney NotFound: I think so. I'm not sure whether the current .HLL carries over, when a function is called
15:02 NotFound barney: I'm almos sure that the current HLL is the one of the current context, and that depend of the sub.
15:03 NotFound Of course, when using include instead of  loading, all assumptions are wrong.
15:08 barney Yes, I also think, that's how it should work. The current HLL in runtime/parrot/library/pcre.pir:127 should be 'parrot', as there is no .HLL directive
15:09 particle joined #parrot
15:09 barney When runtime/parrot/library/pcrelib.pbc has been loaded, the symbol should always be fount
15:09 barney s/fount/found/
15:20 donaldh joined #parrot
15:54 Tene barnmake sure that you run load-bytecode from a sub in HLL 'parrot'.
15:54 Tene oh, no barney
16:03 NotFound examples/library/pcre.pir
16:03 NotFound 25:.include 'library/pcre.pir'
16:03 NotFound This is wrong
16:07 NotFound I think that adding a new convention for extensions of files intended to be .included may be helpful to calrify things.
16:08 dalek parrot: r39302 | NotFound++ | trunk/examples/library/pcre.pir:
16:08 dalek parrot: [examples] don't .include libraries
16:08 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39302/
16:12 dalek rakudo: b9bfabc | pmichaud++ | src/ (8 files):
16:12 dalek rakudo: Fix postfix:<++> to be faster in general, and faster still for Ints.
16:12 dalek rakudo: auto-incrementing 20,000 Ints previously took 13.36s, it now takes 2.76s.
16:12 dalek rakudo: In order to get this to work, we also:
16:12 dalek rakudo: * Fixed ++/-- to auto-promote to Num/BigInt as needed
16:12 dalek rakudo: * Changed !DEREF to check isa using a class object instead of a Key
16:12 dalek rakudo: * Refactored all of the autoincrement/decrement operators
16:12 dalek rakudo: * Fixed infix:<does> to now work on Integer/Float/String PMCs
16:12 dalek rakudo: * Cleaned up .succ and .pred in Bool
16:12 dalek rakudo: * Rewrote the .succ and .pred rules for Str in PIR (was C),
16:12 dalek rakudo:   made it extensible to unicode ranges, and removed no-longer-the-right-place
16:12 dalek rakudo:   increment/decrement vtable in Perl6Str
16:12 dalek rakudo: * Removed the not-quite-working Range.clone method -- we can inherit
16:12 dalek rakudo:   from Object anyway.
16:12 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​9bfabc46dfd27f3b9fdf10547556c871d00a9bc
16:13 PacoLinux joined #parrot
16:15 jhorwitz joined #parrot
16:26 iblechbot joined #parrot
16:28 Steve_H left #parrot
16:45 jonathan lol segfault
16:45 jonathan in 6 lines of PIR
16:52 NotFound jonathan: no record ;)
16:52 szbalint is that the new golf? :)
16:52 pmichaud lol
16:52 pmichaud Parrot segfault golf
16:53 NotFound We crashed it for you.
16:55 dalek TT #729 created by jonathan++: Segfault on printing a String PMC assigned a null string
16:56 NotFound Uh. Don't we fixed that some time ago?
16:56 jonathan NotFound: I've fixed similar-ish bugs before.
16:57 jonathan NotFound: Having NULL pointers around for strings gets us into all kinds of trouble.
16:58 jonathan I've make test'ing a Parrot patch that re-orders some code that actually was not the source of my segfault (that ticket was) but that looked like it had potential to get us screwed too.
16:59 jonathan Actually I ended up doing something like the code that made the segfault because I had a stupid bug somewhere else.
16:59 jonathan So I'm not blocking on it, but of course fixing segfaults is good. :-)
17:00 NotFound I'll take a look at it.
17:03 jonathan NotFound++
17:03 NotFound Ah, good, at least ASSERT_ARGS is doing his job
17:04 Whiteknight joined #parrot
17:04 dalek parrot: r39303 | jonathan++ | trunk/src/oo.c:
17:04 dalek parrot: [core] cloned_guts is a struct, and was referencing a PMC that it appears nowhere else was. This means the PMC was unanchored from the stack (since we walk the stack looking for stuff in the PMC pool). I re-ordered the code to attach the struct to the PMC earlier, so that this shouldn't happen. (I haven't seen it happen, but it could...ran across this while trcking down an unrelated segfault).
17:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39303/
17:05 darbelo joined #parrot
17:11 Whiteknight hello darbelo
17:13 Whiteknight joined #parrot
17:16 NotFound "Sets the value of the string to a copy of the specified C<string>" Setting the value to NULL makes no sense, isn't it?
17:19 NotFound Anyway, that's not what the function is really doing.
17:19 jonathan NotFound: I'm not sure, I just know it shouldn't segfault. ;-)
17:20 NotFound jonathan: yeah, but not having that things cristal clear is the long term cause of segfaults.
17:20 darbelo hi Whiteknight
17:21 NotFound Well, I'll make it set NULL, but leave the ticket open asking for clarification.
17:21 Whiteknight how's the project going?
17:22 jonathan NotFound: Note that the segfault is on printing it rather than setting. But completely agree on asking for clarification.
17:23 darbelo It's moving. Writing a blog entry now the power's back to normal.
17:23 NotFound jonathan: here the segfault is a confess from ASSERT_ARGS fail
17:24 NotFound Which is correct.
17:25 NotFound #4  0xb7bea1de in Parrot_str_set (interp=0x804f040, dest=0x80f7830, src=0x0)
17:25 NotFound at src/string/api.c:211
17:27 NotFound src/string/api.c:211: failed assertion 'src'
17:30 jonathan NotFound: OK, I fear the assertion wsn't enforced here or something like that.
17:31 NotFound Let's fix one problem each time
17:32 jonathan I'm not convinced an assertion failure is much better than a segfault though.
17:32 NotFound jonathan: I am
17:33 NotFound Unless the assertion in a particular case is a bug itself, of course ;)
17:34 jonathan The point is that _either_ is an abnormal termination of the VM.
17:35 NotFound The main problem IMO is that compilers and tools are not helping us catch violations of nonnullness attributes.
17:35 jonathan Plus an ASSERT_ARGS fail means "something passed me something my declaration says I must not be passed".
17:35 jonathan (namely, a NULL.)
17:36 NotFound jonathan: yes, and we need that, or better we drop the nonnullness thing because it does more bad than good
17:37 NotFound If the compiler does not catch it, but the optimizer uses it, we're doomed.
17:37 jonathan *nod*
17:37 NotFound ASSERT_ARGS is the less evil solution to that problem.
17:37 jonathan So far as I can tell, it's mostly being used by compilers as an optimization hint, not a safety mechanism.
17:38 NotFound jonathan: yes, and the optimization hint happiliy drop all attempts of catching nullness at runtime.
17:38 jonathan yup. :-(
17:39 NotFound Because he trust us, and we tell him that is never null.
17:39 pmichaud it's not a check, it's a declaration.
17:40 pmichaud (at least, that's what it sounds like to me)
17:40 NotFound "We declare that this arg will never be null. Then you can optimize to nothing all compariasons with NULL"
17:40 NotFound That's it.
17:41 NotFound And that caused a lot of hard-to-catch bugs in the past.
17:41 jonathan To me it feels well intentioned, but as much harm as help.
17:41 dalek rakudo: 711bd6d | jnthn++ |  (14 files):
17:41 dalek rakudo: Large refactor of method dispatch, providing deferal, eliminating some levels of indirection in method dispatch and improving performance. Also starts a refactor of roles since various past tricks will no longer fly and we should fiddle less with Parrot's Role PMC, though much remains to be cleared up there so roles are a little messy for now.
17:41 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​11bd6d629533672e68bcefa4a72b79213cff7d1
17:41 dalek rakudo: ff312ab | jnthn++ | :
17:41 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
17:41 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​f312abb7feb6950c1d894f0fbb1da503d288eee
17:41 dalek rakudo: 03e90ad | jnthn++ | src/ (4 files):
17:41 dalek rakudo: Track down a couple of issues relating to enums and role punning, which were causing test fails, plus track down a bug with .perl on roles.
17:41 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​3e90ad93a181716e5a3c4f7bddb05d1d7b1ba7c
17:41 dalek rakudo: 2044332 | jnthn++ | :
17:41 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
17:41 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​044332a2a66db5087982645027ec5cf9ece1454
17:41 NotFound ASSERT_ARGS was introduced as a helper against this problems.
17:42 pmichaud oooh, I can't wait to try out the new refactor.
17:42 * pmichaud fires up his benchmarking machine.
17:42 NotFound But it does not help in non-debug builds.
17:43 NotFound What we need is a compiler/lint/whatever that tell us: "attempting to pass a maybe NULL as a non-null argument"
18:06 leovle joined #parrot
18:21 rakudohudson joined #parrot
18:27 mctremel joined #parrot
18:31 dalek parrot: r39304 | NotFound++ | trunk/lib/Parrot/Pmc2c/Attribute.pm:
18:31 dalek parrot: [cage] drop ; at end of "do .... while (0)"
18:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39304/
18:37 leovle left #parrot
19:11 dalek parrot: r39305 | NotFound++ | trunk/src/pmc/string.pmc:
19:11 dalek parrot: [pmc] fix String.assign_string_native with NULL value, TT #729
19:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39305/
19:21 dalek parrot: r39306 | pmichaud++ | branches/isafast:
19:21 dalek parrot: New branch to refactor/optimize VTABLE_isa_pmc.
19:21 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39306/
19:22 donaldh joined #parrot
19:25 Steve_H joined #parrot
19:31 cotto NotFound, did you look at any other PMCs for similar bugs to the one you fixed in 39505?
19:31 Tene I wrote a little http app in ruby, using the HTTP::Daemon ad Tags libraries from Perl 6. :)
19:32 dalek website: darbelo++ | decnum-dynpmcs: week #01
19:32 dalek website: http://www.parrot.org/cont​ent/decnum-dynpmcs-week-01
19:43 NotFound cotto: looks specific for String
19:44 NotFound Tene: Have you tried recently examples/nci/xlibtest.rb ?
20:06 dalek rakudo: a0d09b3 | masak++ | src/classes/List.pir:
20:06 dalek rakudo: [src/classes/List.pir] C<> clarification
20:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​0d09b31e74155abd0066a9f4a25d608221f4595
20:22 particle joined #parrot
20:49 szabgab joined #parrot
21:00 Theory joined #parrot
21:11 dalek parrot: r39307 | pmichaud++ | branches/isafast/src/oo.c:
21:11 dalek parrot: [core]:  Refactor pmcproxy creation.  Improves speed of <isa $P0, Proxy?>
21:11 dalek parrot: testing in foreign HLLs by 87% (benchmark goes from 9.029 sec to 1.118 sec).
21:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39307/
21:20 muixirt doesn't the parrot -O option work anymore?
21:32 dalek rakudo: 6ed6997 | jnthn++ |  (3 files):
21:32 dalek rakudo: Rename Role.pir to P6role.pir now it's adding methods to Rakudo's subclass of Parrot's Role PMC.
21:32 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​ed69978207cf37e50c3ad99ea626a58cff22127
21:34 darbelo cotto: ping
21:35 snarkyboojum joined #parrot
21:36 Whiteknight joined #parrot
21:36 cotto darbelo, pong
21:36 cotto what happen
21:36 purl /kick cotto enough with the aybabtu already
21:37 darbelo I was looing at the pmc-related changes in the last few day and r39268 caugh my eye.
21:38 darbelo it look similar to what I'm doing in http://code.google.com/p/decnum-dynpmcs/​source/browse/trunk/src/pmc/decnum.pmc#5 but it looks like I missed the readonly PMC case.
21:38 cotto Once it stabilizes, you can just use the code bacek++ wrote.
21:39 cotto istr that it's marked PARROT_EXPORT
21:40 cotto and since the only way to get it stable is to use it...
21:41 darbelo I don't think it's exported.
21:41 cotto it is
21:41 cotto see r39269
21:43 darbelo Ah. I hadn't seen that one yet. Thanks.
21:45 cotto It's good to avoid duplicating that kind of code, since all the fiddly special cases are easy to miss.
21:47 darbelo Yup. I'll kill new_if_not_a_decnum and use that. It generalizes what I was doing, so there's no point in keeping my version arround.
21:48 darbelo AND I get to dump blame on other people if it breaks :)
21:48 cotto yay!
21:49 cotto how often are you updating Parrot?
21:49 darbelo daily-ish, but I don't always read the changes before updating.
21:50 darbelo And I spent the whole weekend with electricity issues, so I have some catching up to do.
21:51 dalek parrot: r39308 | pmichaud++ | trunk/src/oo.c:
21:51 dalek parrot: [core]:  Merge isafast branch back into trunk.
21:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39308/
21:52 darbelo Apparently someone decided 220 volts was way too much, and that we should just make do with 160 volts or so.
21:53 mugwump Electricity?  Pfft, a luxury
21:53 cotto still enough to kill you, but not enough to be useful
21:53 cotto sounds like a plan
21:53 mugwump http://www.nzherald.co.nz/nz/news/art​icle.cfm?c_id=1&amp;objectid=10575858  # customers were told they [...] would have to make do without power
21:54 bacek joined #parrot
21:56 darbelo mugwump: At least thy got *told* something.
21:56 cotto "buy more blankets and sweaters"
21:56 mugwump probably when they complained :)
21:58 darbelo Oh I complained, to an answering machine. A very polite answering machine at that, too. But not a very helpful one.
22:11 darbelo Hmm. Parrot_pmc_try_reuse only handles three-argument operations.
22:12 muixirt problems with the parrot -O option: http://sial.org/pbot/36964
22:13 dalek rakudo: f43c644 | jnthn++ | src/parrot/P6role.pir:
22:13 dalek rakudo: Sometimes, git doesn't do what you want. Add p6role.pir, which it lost in the rename but didn't show as not under version control when I did git status. How awesome.
22:13 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​43c644bee5741a135243bd8834d45a082570962
22:13 muixirt anyone with some insights on that?
22:13 darbelo Nevermind, value is ARGIN_NULLOK.
22:21 Coke so can we back out the commit that caused TT#728?
22:22 contingencyplan joined #parrot
22:32 rg1 joined #parrot
22:33 dalek decnum-dynpmcs: r72 | darbelo++ | trunk/src/pmc/decnum.pmc:
22:33 dalek decnum-dynpmcs: Replace new_if_not_a_decnum with the new Parrot_pmc_try_reuse.
22:33 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=72
22:36 pmichaud (back out commit)++
22:36 dalek rakudo: def4e6d | jnthn++ | src/ (7 files):
22:36 dalek rakudo: Do a little optimization to the deref_objectref dynop, and then eliminate the !DEREF PIR sub in favor of it. Wins a modest but worthwhile performance improvement.
22:36 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​ef4e6dd8ccba2ab25d0fe312806405873b2272e
22:40 mugwump is rakudo/src/parrot supposed to contain files?
22:40 jonathan yes
22:40 mugwump ah, rakudo/parrot is where parrot checkout lives
22:41 Coke pmichaud: working on reverting 39273 now.
22:42 pmichaud rakudo/src/parrot is where we store the "we're mucking about in the parrot namespace" stuff.
22:42 pmichaud I'd be open to changing the dirname, though.  It makes it harder for me to tab-complete src/parser/
22:42 pmichaud although I've been thinking about moving src/parser to src/pct, since more than just a parser lives there.
22:45 nopaste "chromatic" at 72.90.115.31 pasted "Rakudo P6 MultiSub Building Patch for pmichaud" (58 lines) at http://nopaste.snit.ch/16765
22:48 dalek parrot: r39309 | coke++ | trunk/src/pmc/scalar.pmc:
22:48 dalek parrot: TT #728 - revert r39273 until someone determines the proper implementation.
22:48 dalek parrot: (This version broke partcl)
22:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39309/
22:49 kid51 joined #parrot
22:53 dalek rakudo: 9421bca | pmichaud++ | src/pmc/perl6multisub.pmc:
22:53 dalek rakudo: Add semicolons after GETATTR/SETATTR (chromatic++).
22:53 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​421bcaf77f411c472762cd123722d8fa8618d86
22:54 dalek partcl: r411 | coke++ | trunk/runtime/tcllib.pir:
22:54 dalek partcl: Move the shiny new HLL compiler out of the user-visible namespace for now.
22:54 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=411
22:54 bacek good morning
22:54 purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
22:54 NotFound Ha
22:55 mugwump purl: parrot viewvc?
22:55 purl i haven't a clue, mugwump
22:55 bacek Coke: I've reverted r39273 locally already. Waiting for make test to finish before commit
22:55 particle joined #parrot
22:55 NotFound Now I underestand why no one complained about the unneeded semicolon in the GET/SET ATTR macros X-)
22:55 pmichaud bacek: it's already reverted in r39309
22:56 bacek ah... ok
22:56 skids joined #parrot
22:56 * bacek launching git rebase -i
22:57 payload joined #parrot
22:58 Coke bacek: sorry, already did it, as pmichaud noted
22:58 bacek Now we have to remove all pmc_reuse. What about Scalar.subtract(Complex, PMC*dest)?
22:59 mugwump purl: parrot viewsvn?
22:59 purl mugwump: no idea
23:01 bacek actually many math VTABLEs try to reuse dest...
23:03 bacek especially in BigInt and BigNum.
23:03 cotto mugwump, looking for https://trac.parrot.org/parrot/browser ?
23:04 mugwump yes, actually :)
23:04 cotto Well, there it is.
23:04 mugwump thanks
23:04 dalek parrot: r39310 | NotFound++ | trunk/t/pmc/string.t:
23:04 dalek parrot: [test] test for fix on TT #729
23:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39310/
23:05 tetragon joined #parrot
23:10 dalek TT #480 closed by jkeenan++: [PATCH] Display assembly filenames when compiling, like C filenames are
23:11 dalek parrot: r39311 | bacek++ | trunk/src/pmc.c:
23:11 dalek parrot: [core][cage] Call pmc_reuse from Parrot_pmc_try_reuse even if types are same.
23:11 dalek parrot: Parrot_pmc_try_reuse is about "try" not "how".
23:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39311/
23:12 ruoso joined #parrot
23:14 dalek parrot: r39312 | bacek++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
23:14 dalek parrot: [pmc2c] Don't use return with expression in void functions. ISO C forbids it. doughera++
23:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39312/
23:15 Coke I am not a fan of closing tickets just because they've been open for 2 months.
23:16 Coke msg kid51 I am not a fan of closing tickets just because they've been open for 2 months.
23:16 purl Message for kid51 stored.
23:17 dalek TT #730 created by pmichaud++: [bug]  IMCC chokes on unicode strings as method call names
23:19 Coke to verify, we don't currently have a way to see if a file in the OS is executable, correct?
23:20 donaldh joined #parrot
23:20 pmichaud try running it, if it failz, it's not executable :-)
23:20 NotFound Coke: A portable way? I don't even think that such a thing exists.
23:21 NotFound pmichaud: incorrect. It can be executable, but maybe you don't have permissions to execute it ;-)
23:22 Coke NotFound: parrot MAKES it portable, even if we have to do it 30 different ways on 30 different OSes.
23:22 Coke perl5 can do it, I think we can too. =)
23:23 NotFound Coke: or we can just use our own definition of 'executable'
23:23 Coke NotFound: sure, as long it's right.
23:23 NotFound We can redefine 'right' as well
23:24 Coke NotFound: I'm sorry, I'm afraid I don't understand.
23:25 Coke In any case, I opened a ticket, pointing back to the tcl spec for why I need it.
23:25 nopaste "bacek" at 114.73.180.229 pasted "pmc. reuse or not reuse? there is question." (18 lines) at http://nopaste.snit.ch/16766
23:25 bacek what is expected output for nopasted code?
23:25 NotFound Sorry, I mean: we can also redefine 'right'
23:26 bacek #define RIGHT LEFT /* Happy debugging! */
23:26 Coke NotFound: ... not really, no.
23:27 bacek pmichaud: can you check http://nopaste.snit.ch/16766 please?
23:27 dalek TT #731 created by coke++: can't tell if an OS file is executable from parrot
23:29 pmichaud bacek: I think output should be
23:29 pmichaud 42
23:29 pmichaud 42
23:29 pmichaud 402
23:29 pmichaud 42
23:29 bacek why "add" differ from "concat"?
23:30 pmichaud it doesn't.
23:30 * bacek feel inconsistency...
23:30 pmichaud although the output I thought I'd get isn't what I'm getting in current Parrot.  I don't know if that means Parrot changed recently, checking.
23:31 bacek If I replace "$P2 = $P0 + $P1" with "$P2 = add $P0, $P1" it produces same results.
23:32 bacek I don't understand why "add" and "concat" doesn't differ in treating destination pmc...
23:32 pmichaud the difference is where you're setting $P99
23:33 Tene NotFound: haven't looked at xlibtest in ages.
23:33 Tene NotFound: cardinal is in pretty bad shape.
23:33 pmichaud bacek:  first two lines, $P0 references an Integer with value 40
23:33 NotFound afk_coke: "Returns 1 if file name is executable by the current user, 0 otherwise" --> I suppose this means a check of file permissions, not executable format or something
23:33 pmichaud next two lines, $P1 references an Integer with value 2
23:34 pmichaud next line, $P2 references an Integer with value 0
23:34 dalek rakudo: b91e089 | pmichaud++ | build/PARROT_REVISION:
23:34 dalek rakudo: Bump PARROT_REVISION to get latest isa fixes and other stuff.
23:34 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​91e089021cd808fa2a098ccd43b1588322616d1
23:34 pmichaud next line, $P99 references the same Integer as $P2
23:34 mikehh joined #parrot
23:34 pmichaud okay so far?  At this point we have three Integers
23:34 pmichaud $P2 = $P0 + $P1  is the same thing as    add $P2, $P0, $P1
23:34 bacek no. parrot -t1 calls "set P3, P2" for both "$P99 = $P2"
23:35 pmichaud that creates a new Integer, stores the result of $P0 + $P1 (42) into it, and sets $P2 to point to the new Integer
23:35 pmichaud at this point there are *four* Integers   40 ($P0), 2 ($P1), 0 ($P99), and 42 ($P2)
23:36 pmichaud oh, I see, I miswrote earlier
23:36 pmichaud I transposed the $P2=$P99 in my head
23:37 pmichaud output should be
23:37 pmichaud 42
23:37 pmichaud 0
23:37 pmichaud 402
23:37 pmichaud 42
23:38 bacek Ok. So "dest" in all VTABLEs is redundant and should not be there.
23:38 pmichaud I don't know about "all" VTABLES
23:39 pmichaud depends on what happens with    add $P2, $P1
23:39 NotFound Don't know if all, but I have thinked that about several of them lots of times.
23:40 bacek There is no "dest" in "add $P2, $P1"
23:41 Zak joined #parrot
23:43 pmichaud well, the result goes into $P2 in that case.
23:43 NotFound Or maybe the return value is the redundant one.
23:44 pmichaud Anyway, it wouldn't surprise me if dest is no longer used.
23:44 pmichaud it used to be that   add $P2, $P0, $P1  meant "add $P0 to $P1 and store the result in the PMC given by $P2"
23:44 pmichaud which was often a pain if $P2 was something other than an Integer
23:44 NotFound add(invar PMC, invar PMC, invar PMC) :base_core { $1 = VTABLE_add(interp, $2, $3, $1);
23:45 pmichaud what about   add(inout PMC, invar PMC) ?
23:45 bacek Now it means "and ignore $P2, create new PMC and return it. op will do the rest"
23:46 bacek anyway, $dayjob time.
23:46 NotFound pmichaud: I don't see such op
23:46 pmichaud sorry, it's
23:46 pmichaud inline op add(invar PMC, invar PMC) :base_core { VTABLE_i_add(interp, $1, $2);
23:46 pmichaud }
23:46 NotFound add(invar PMC, invar PMC) :base_core {
23:46 bacek afk &
23:48 NotFound Dropping the return value looks like a clean way to me.
23:48 bacek And reuse "dest'?
23:48 pmichaud huh?
23:48 purl huh are you 2 on the same box or something?
23:49 pmichaud "drop the return value"?
23:49 NotFound Mmmm.... no, that way a null pmc can't be used
23:49 pmichaud which vtable are we referring to at the moment?
23:49 NotFound Drop from the code, not the result.
23:50 pmichaud or give me a more precise picture of whatyou're thinking of changing
23:50 NotFound Forget it, was a bad idea.
23:50 purl NotFound, I didn't have anything matching it, was a bad idea
23:50 pmichaud okay.
23:50 patspam joined #parrot
23:50 pmichaud As an example
23:50 pmichaud in
23:50 pmichaud inline op add(invar PMC, invar PMC, invar PMC) :base_core { $1 = VTABLE_add(interp, $2, $3, $1);
23:50 pmichaud }
23:51 pmichaud the $1 parameter to VTABLE_add is completely unused (by the core PMCs)
23:51 pmichaud i.e., it doesn't provide anything to the calculation, nor are its contents changed.
23:52 NotFound The intended semantic is to assign to $1 or to set $1 ?
23:52 pmichaud to set $1
23:52 pmichaud i.e., the return value.
23:52 NotFound Then we can drop dest
23:52 pmichaud assigning to $1 is the old semantic, which was dropped last year sometime
23:52 pmichaud (with some difficulty, so please let's not change it back :-)
23:53 NotFound Then we must get rit of the dest parameter in the vtable function.
23:53 pmichaud that may want a deprecation cycle, if there are any custom PMCs using the old interface.
23:53 NotFound Agreed
23:54 darbelo that would mean that every that now has a dest will have to pmc_new() a destination and return it. Right?
23:54 pmichaud darbelo: I think that's what is happening now, yes.
23:54 pmichaud for the non-inplace operations.
23:55 darbelo pmichaud: most of the arithmetic VTABLEs reuse the destination.
23:55 pmichaud they re-use the dest pointer, but not the PMC that it was referring to.
23:55 pmichaud at least, not in Integer
23:55 pmichaud dest = pmc_new(INTERP, VTABLE_type(interp, SELF));
23:55 pmichaud that doesn't mean "change the PMC that dest was pointing to"
23:55 pmichaud it actually causes dest to refer to a new PMC
23:55 pmichaud but that has no effect on the $1 that was in the caller.
23:55 darbelo BigInt uses pmc_reuse()
23:56 NotFound We can stop doing that as the first step towards the deprecation.
23:56 pmichaud we can't stop doing that, no.
23:56 pmichaud (depending on what "that" is in this case)
23:56 pmichaud I admit I haven't looked to see what BigInt does.  However, it's very likely that the existing BigInt was never updated to the new semantic, since it wasn't being used or tested anywhere.
23:57 NotFound Reusing the dest pointer, use a local variable instead.
23:57 pmichaud I would just change the parameter to be   *unused   and use *dest as the local variable :-)
23:57 NotFound Just to clarify the intention in the code.
23:57 zak_ joined #parrot
23:57 NotFound Yes, less work
23:57 pmichaud or *result
23:57 pmichaud but *dest works.
23:57 pmichaud or the parameter could be *deprecated :-)
23:58 NotFound Letting the code in a state where the end of deprecation cycle is deleting the parameter in the declaration.
23:58 pmichaud Correct.
23:58 pmichaud That sounds nice.
23:59 NotFound A better english grammar will be even nicer ;)

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced