Camelia, the Perl 6 bug

IRC log for #parrot, 2009-06-15

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 ruoso joined #parrot
00:02 ruoso joined #parrot
00:05 dalek partcl: r491 | coke++ | trunk/lib/Parrot/Test/Tcl.pm:
00:05 dalek partcl: Fix a comment.
00:05 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=491
00:06 Infinoid Okay.  Any other temp files? :)
00:12 GeJ anyone (other than me that is) experiencing lots of imcc syntax errors with 'perl t/harness t/examples/pod.t'  ?
00:18 Coke GeJ: I believe that has been reported. if those errors are in the book, I presume allison and chromatic are working on them.
00:18 Coke you can search trac tickets to see if there's an open one.l
00:19 GeJ will do.
00:21 GeJ mikehh reported it already.
00:23 GeJ So, please feel free to just ignore me and resume what it is that you usually do. thanks.
00:26 Infinoid Once I figure that out, I will do so :)
00:30 Whiteknight GeJ: I'm seeing the same thing
00:30 Whiteknight serious karma to the person who resolves that
00:31 bacek joined #parrot
00:32 Infinoid Whiteknight: Are you working on NEWS yet?
00:32 Coke Whiteknight: really? it's a trivial fix, at least to mark the tests as TODO.
00:32 Coke I'll take care of it.
00:34 dalek partcl: r492 | coke++ | trunk/ (24 files):
00:34 dalek partcl: Eliminate the helper .sub toList - instead, use the .getListValue() METHOD
00:34 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=492
00:41 Coke Whiteknight: done.
00:42 Coke well, "test passing", anyway. =-)
00:42 Coke you still get the annoying output. =-)
00:42 Coke but the test passes.
00:42 dalek parrot: r39566 | coke++ | trunk/docs (2 files):
00:42 dalek parrot: pass the t/examples/pod.t by TODO'ing or fixing some sample PIR code.
00:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39566/
00:42 Coke to get rid of the output will require slightly more work.
00:43 Infinoid fsvo "slightly"
00:43 Infinoid (there's a lot of it, and there are a lot of other pir examples already todoed)
00:43 Infinoid coke++
00:44 mikehh_ joined #parrot
00:45 Coke since we have pir_error_like, I imagine we could use an existing test function to grab that output and make sure it was empty.
00:45 Coke (but not report it if the test was TODO'd)
00:46 Coke ah. I cheated when I wrote that test, and didn't use any of the builtin test functions.
00:46 Coke I am just doing system(parrot -o /dev/null foo.pir)
00:50 Whiteknight Coke++ # Awesome!
00:50 Whiteknight Infinoid: I was hoping some other developers would chronicle their own exploits in NEWS
00:50 Whiteknight but, it seems I had hoped wrong
01:02 Infinoid Whiteknight: Yeah.  I'd get a head start on it if you can - I spent 4 hours on it for 1.2.0 and it felt ... rushed
01:02 Infinoid (clicking "Next Revision" over and over in trac)
01:03 Whiteknight I was going to use TortoiseSVN on my work computer, it has a really nice log interface
01:03 Whiteknight but yeah, I'll get started on it tomorrow
01:03 Whiteknight (people not updating NEWS)--
01:04 Infinoid cool.
01:04 mikehh_ joined #parrot
01:04 Infinoid I had trouble deciding exactly where the line in the sand should be drawn, with regards to what importance level should be deemed newsworthy
01:05 Infinoid so I sorta just followed the previous releases' lead
01:09 * bacek wonders what he can put in NEWS
01:11 Infinoid The branch merges tend to be the most noteworthy
01:11 mikehh_ joined #parrot
01:12 Andy joined #parrot
01:13 Coke nice. some of those PIR examples are causing segfs.
01:15 Whiteknight bacek: Anything you want. Just put something in NEWS
01:15 Whiteknight I don't care what
01:15 Whiteknight Coke and Infinoid: You guys too. Do it now!
01:15 Whiteknight update NEWS!
01:17 Infinoid erm.  Did I do anything this month?
01:18 Coke Whiteknight: ... I have pretty much been working on partcl.
01:18 Coke Whiteknight, Infinoid: fixed t/example/pod.t to be much less verbose. now YOU get to fix the very visible segfaults. =-)
01:19 dalek parrot: r39567 | coke++ | trunk/t/examples/pod.t:
01:19 dalek parrot: Instead of spewing stderr to the screen, save it, and verify that it's 0.
01:19 dalek parrot: This has the benefit of hiding the output for all TODO'd tests, but
01:19 dalek parrot: showing the error for those expected to pass.
01:19 dalek parrot: BTW - when I run this, 3 of the sample PIR files are segfaulting; they
01:19 dalek parrot: should be hunted down and fixed.
01:19 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39567/
01:21 Infinoid Whiteknight: I cleaned some cages, nothing newsworthy.  The performance improvements are already mentioned
01:21 Infinoid I spent a lot of time on planes this month... not much parrot time
01:23 Infinoid Hmm.  TT #726 got warnocked, which is too bad, it's a significant performance improvement
01:24 Infinoid That and r39414 speed up Hash allocations
01:25 Whiteknight which was #762?
01:25 Infinoid #726 chops the number of malloc()s for a hash creation in half
01:25 Infinoid I dunno #762
01:26 Whiteknight oh wow
01:27 Infinoid I posted it as a ticket because I didn't have time to review it thoroughally... and that hasn't changed since
01:28 * Infinoid putting together an expense report for moving to delaware right now... such fun
01:28 Whiteknight Infinoid: #726 has a +1 from me
01:28 Whiteknight and it doesn't cause any test failures?
01:28 Infinoid No failures.  I haven't checked it for leaks yet tho
01:28 dalek partcl: r493 | coke++ | trunk/ (4 files):
01:28 dalek partcl: Move the String overrides into their own class file.
01:28 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=493
01:29 Whiteknight if it were a few days earlier I would say to just dump it into trunk. But so close to the release, don't do it unless you're sure it's good
01:29 Whiteknight Dump it to trunk on tuesday afternoon :)
01:31 Infinoid Yeah, will do.  I've still got it in my local patch stack anyway, hoping for some time to run valgrind on it tomorrow
01:33 dalek partcl: r494 | coke++ | trunk/ (4 files):
01:33 dalek partcl: move TclList.getListValue() into PIR.
01:33 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=494
01:34 * bacek found only one thing worth putting in NEWS - TT#452
01:34 Whiteknight bacek: There are no small commits.
01:34 Whiteknight (only small committers) :)
01:35 Infinoid (like me)
01:35 bacek (..)
01:35 bacek O
01:35 bacek o
01:35 bacek .
01:35 * bacek disappears
01:35 Infinoid ohnoes
01:36 Whiteknight ENOBACEK
01:36 bacek :)
01:36 bacek Ah. Packfile PMCs are useful now. "Someone" can put it in NEWS.
01:37 Whiteknight if (someone == bacek) { bacek,can_do_it(); }
01:38 Whiteknight are the packfile PMCs actually being used, or are they just a novelty?
01:38 Infinoid The next step is to make the rest of the system use them
01:38 dalek partcl: r495 | coke++ | trunk/ (3 files):
01:38 dalek partcl: move TclList.'reverse'() into PIR.
01:38 dalek partcl: - add a test for [lreverse]
01:38 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=495
01:38 bacek Whiteknight: no way. Or you'll get something like - "Old crappy PMCs for Packfiles was greatly improved. They are shiny now and can be used for generatinc PBCs"
01:39 Infinoid And after that, we can start getting rid of that old and nasty src/packfile.c code
01:39 Whiteknight is there a schedule for that work?
01:39 Whiteknight that would be great to have pre-1.4
01:39 Infinoid Not likely.  Big task, short on tuits
01:39 Whiteknight who'se the teamleader on that project?
01:40 Infinoid I guess I am, as bacek has assigned the ticket to me again
01:40 Infinoid But I normally just defer to jonathan or allison when someone asks me questions
01:40 bacek btw, http://tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk shows t/pmc/packfile.t failure on freebsd. Probably regenerating native PBCs will fix it.
01:40 Infinoid (again?  I've already done that, what, 3 times now?)
01:40 Whiteknight Infinoid++
01:41 bacek PBC format is too fragile...
01:41 Infinoid Yes.  PBC is insufficiently P
01:41 Whiteknight What would need to get done to make it more robust, I wonder?
01:41 Whiteknight a more informative header?
01:42 bacek different strategy for store them.
01:42 Whiteknight okay
01:42 Whiteknight Well, any major PBC format changes that don't get done before 1.4 will have to wait until 2.0 I think
01:43 Infinoid Yeah, it's a mess and it won't go away any time soon
01:43 Infinoid Although... tossing a simple lookup table of op/pmc names and values would go a long way to improve forward compatibility of these things
01:43 Whiteknight so many systems are a mess still
01:43 Whiteknight Infinoid: I was thinking the same thing
01:43 Infinoid ^into the file
01:44 Whiteknight although you end up with problems when ops are deprecated and disappear from core
01:44 Infinoid Well, now you have a means of detecting it and can toss an exception only in that case
01:44 Infinoid ...rather than just invalidating *everything*
01:44 Whiteknight yeah
01:44 Infinoid Now, changing APIs of existing stuff... that's a bigger problem.
01:44 bacek simple solution: don't renumber ops.
01:45 Whiteknight we could probably "borrow" some of the predereferencing code to renumber PMCs and Ops from the packfile on the fly
01:45 bacek Assign enum_class_Foo values explicitely
01:45 Infinoid bacek: The last couple of PBC_COMPAT bumps didn't renumbered ops, they just added a couple of new PMCs
01:45 Infinoid s/renumbered/renumber/
01:45 Whiteknight bacek: That's quite an interesting idea, but we still run into problems where a type disappears
01:45 bacek which cause enum_class_Foo renumbering
01:46 Infinoid So, what then, you propose assigning them by hand?
01:46 bacek Whiteknight: if type disappear we can throw exception on load.
01:46 bacek Infinoid: exactly
01:46 Infinoid Then you end up with numbers you can never reclaim
01:47 Whiteknight okay, I am heading to bed nowish. Goodnight
01:47 Infinoid I think I prefer the lookup table embedded in pbc file idea
01:47 Infinoid night Whiteknight
01:47 Tene Looks like chromatic was the last person to touch the internals I'm trying to deal with right now.
01:47 bacek Oh... 2^32 has enough numbers
01:47 Infinoid (why does that sound like a tongue twister?)
01:47 Whiteknight goodnight
01:47 Infinoid bacek: And we're volunteering you to maintain that list, on demand, forever and ever. :)
01:47 Tene and creiss
01:47 Infinoid (rather than letting the computer do the things it's good at :))
01:48 bacek we already maintaining it.
01:48 Tene most of it hasn't been changed since 2006 or 2007
01:48 Infinoid bacek: Putting in the lookup table will reduce the amount of maintenance overhead
01:48 bacek (not for PMC)
01:48 bacek Infinoid: really?
01:49 bacek Lookup from what to what?
01:49 Infinoid pbc op numbers to parrot op names, pbc pmc numbers to parrot pmc names
01:50 bacek what about passing freezed PMC to another instance of Parrot over network?
01:51 bacek from my pov is better to store PMC name in freezed format
01:52 bacek And we have "pmc_type" to deal with it
01:53 Infinoid What about it?
01:53 Infinoid When you load an ELF object, you do the link and everything works
01:53 Infinoid This is the same sort of thing
01:54 bacek exactly.
01:54 bacek So just store PMC name instead of type.
01:54 bacek call "pmc_type(interp, name)" on thaw.
01:54 bacek ...
01:54 bacek Profit!
01:54 Infinoid You'd need a type placeholder in the opcode array, to replace at runtime
01:54 Infinoid That's the numeric component of the lookup table
01:55 bacek I don't get it...
01:55 Infinoid I'm proposing having an ELF-style relocation list, but the implementation details aren't important
01:55 Infinoid Decoupling ops/pmcs from their numbers will solve a lot of problems, no matter how we do it.
02:07 davidfetter hello
02:07 purl que tal, davidfetter.
02:07 Util good evening
02:07 davidfetter can rakudo build against a pre-installed parrot, and if so, what version(s)?
02:10 bacek davidfetter: You'll need a time machine to achieve this :)
02:10 davidfetter ugh
02:10 davidfetter with a time machine, there's all kinds of things i'd do, very few having to do with computers ;)
02:11 bacek :)
02:12 davidfetter is putting this capability back on anybody's roadmap?
02:12 Util current recommended practice is not just to use a non-installed parrot, but to use a particular version (which changes frequently) of parrot that rakudo builds itself (by using Configure.pl --gen-parrot).
02:12 Util It is high on the roadmap
02:13 Util (well, that is from memory; I do not actually see it on the roadmap report)
02:13 bacek Don't smoke roadmap!!!
02:13 davidfetter well, it's safer than shooting roadmap
02:23 Util davidfetter: clarifying - I *think* that, in the past (3 months), making languages (Rakudo and partcl) work from an installed Parrot has been a priority, including roadmap. Several tickets addressed parts of the issue, and are closed now. However, after this was working (for some definition of "work"), the functionality has drifted.
02:23 Util In the last #ps meeting ( http://irclog.perlgeek.de/parrotsketch/2009-06-09 ), pmichaud reported this among his items of work from the last week: "Fixing Rakudo to work from installed Parrot".
02:24 Util END_BRAIN_DUMP
02:24 davidfetter thanks for the info :)
02:26 Util glad to help
02:26 * Util ==> bed; 'night, all
02:29 davidfetter g'night, Util
02:29 Infinoid As long as he doesn't break running from a non-installed parrot, I'll be happy
02:29 Infinoid (and I'll be happier if tcl runs from a non-installed parrot, too, because then I can test it)
02:30 Infinoid goodnight all
02:49 davidfetter g'night, Infinoid
02:55 Coke hurm. my 'reverse' method is not working in PIR.
02:56 Coke ah, because I'm an idiot.
03:01 dalek partcl: r496 | coke++ | trunk/t/cmd_lreverse.t:
03:01 dalek partcl: Check even and odd length lists
03:01 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=496
03:04 mikehh__ joined #parrot
03:10 dalek partcl: r497 | coke++ | trunk/src/class/tcllist.pir:
03:10 dalek partcl: actually make 'reverse'() work.
03:10 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=497
03:13 Coke how to override a PMC vtable from PIR?
03:13 Coke (just declaring it in the namespace isn't sufficient.)
03:17 amuck joined #parrot
03:20 donaldh joined #parrot
03:42 xenoterracide joined #parrot
03:43 xenoterracide what installs nqp? I seem to have parrot otherwise installed... but that doesn't seem to be installed
03:52 Coke I am not sure it gets installed. one moment.
03:53 Coke you could try 'make install-dev'
03:53 Coke (I seem to have it installed on my dev box, and that's what I use.)
03:53 Coke (ends up in lib/parrot/1.2.0-devel/languages/nqp/)
03:55 Coke I'm getting a class not found on "root_new ['parrot'; 'TclList']", having just switched it to a PIR class from a dynpmc. any clues?
03:57 xenoterracide interestingly I have build errors (odd that I didn't have them the last time I built 1.2)
03:57 xenoterracide http://privatepaste.com/fd1uQnM790
04:00 xenoterracide Coke: hmm... from the prebuilt binary I have installed that directory and files exist... but I don't have an executable in my path
04:01 Coke xenoterracide: those look like references to ICU.
04:02 * xenoterracide has an icu package installed and the headers should be there... hmm...
04:04 xenoterracide Coke: is the executable for nqp lib/parrot/1.2.0-devel/languages/nqp/nqp ?
04:08 Coke there is no executable, I think, just a .pbc file
04:09 xenoterracide hmm
04:09 Coke so then /path/to/parrot nqp.pbc
04:11 xenoterracide hmm
04:11 xenoterracide introductory docs may be a bit off
04:19 xenoterracide are there any books about parrot that reference 1.0? (or greater)?
04:21 Coke in progress.
04:21 Coke the docs/book/ directory is as close as we have atm.
04:22 Coke two folks on the board are working on writing/editing it, hopefully in time for a dead-tree version at YAPC::NA.
04:23 xenoterracide hmm
04:23 xenoterracide cool
04:25 xenoterracide seems that the getting started doc suggests running nqp test.pir and that does work. so I've got nqp installed... would I just run it with parrot then?
04:25 Coke TT #218 is now blocking several hours of work I just put into partcl. :|
04:25 xenoterracide s/does/doesn't
04:25 Coke if it's suggesting ./nqp, try /path/to/parrot /path/to/nqp.pbc
04:26 xenoterracide ah
04:26 xenoterracide that whole page seems to have quite a few bugs
04:26 xenoterracide mostly I think formatting code that's being displayed
04:26 xenoterracide ah well
04:26 xenoterracide I think I'm gonna go get food now
04:27 Coke xenoterracide: are you using perldoc to read the doc?
04:28 Coke easiest way to read the book at the moment is:
04:28 Coke http://docs.parrot.org/parrot/latest/ht​ml/docs/book/ch01_introduction.pod.html
04:28 Coke (though that's from the 1.2 release, not svn)
04:29 bacek Coke: (vtable in PIR) did you try mark them as :vtable ?
04:29 Coke bacek: ... yes
04:29 Coke bacek: I got around it by converting the whole (&*#$ PMC to pir.
04:30 xenoterracide well I'd suggest that it's chapter 2 that's bugged ;)
04:35 bacek PIR ftw!
04:38 Coke bacek: except for TT #218.
04:38 bacek Coke: sorting of RPA?...
04:39 Coke <nod>
04:39 Coke I was switching my array-like PMC over. =-)
04:39 Coke so now all my sorts explode.
04:49 bacek oh shi...
05:02 Coke bacek: evil workaround: $P0 = new 'RPA', assign $P0, my_list; $P0.'sort'() ; assign my_list, $P0
05:08 bacek yeah... But this can be removed right after 1.4 afaiu
05:12 dalek partcl: r498 | coke++ | branches/convert_tcllist:
05:12 dalek partcl: Try to eliminate the tcllist PMC and replace it with a PIR class.
05:12 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=498
05:12 dalek partcl: r499 | coke++ | branches/convert_tcllist/ (5 files):
05:12 dalek partcl: First pass at eliminating the the TclList PMC and using a class instead.
05:12 dalek partcl: A few failures remaining.
05:12 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=499
05:41 chromatic joined #parrot
05:52 Coke chromatic: evening.
05:52 purl it has been said that evening is when IRC is dead, TV is laden down with ads, and you're having my own dinner.
05:54 chromatic yes
05:56 dalek partcl: r500 | coke++ | branches/convert_tcllist/run​time/builtin/namespace.pir:
05:56 dalek partcl: Avoid TT #218 again.
05:56 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=500
05:57 * Coke gets the dreaded "Object must be created by a class." error.
06:07 Coke chromatic: I think I just got 'make test' passing again with a pure-pir tcllist.
06:08 Coke will give a spec test run to see if there's a speed improvement.
06:08 eternaleye joined #parrot
06:11 chromatic Very nice.
06:11 dalek partcl: r501 | coke++ | branches/convert_tcllist/src/ (2 files):
06:11 dalek partcl: These uses of TclList generate a "Object must be created by a class" error now.
06:11 dalek partcl: Work around this by creating a pre-stringified list for now.
06:11 dalek partcl: With this, 'make test' now passes in branch.
06:11 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=501
06:13 uniejo joined #parrot
06:20 xenoterracide left #parrot
06:57 kyle_l5l joined #parrot
06:57 c0tt0 joined #parrot
07:02 cotto hi
07:03 bacek seen Andy
07:03 purl Andy was last seen on #parrot 5 days, 8 minutes and 8 seconds ago, saying: ok beditme for me.  [Jun 10 06:51:34 2009]
07:18 barney joined #parrot
07:21 donaldh joined #parrot
07:22 Coke chromatic: slight improvement in speed, but I regressed on some test files:
07:22 Coke "2009-06-13 06:08",483,"r39529",67,5145,2972,1352,821,4374
07:22 Coke +"2009-06-15 08:12",498,"r39537",62,4792,2763,1222,807,4129
07:23 chromatic The regression is odd.
07:23 Coke looks like a reduction in tests/second, but it's hard to tell how far each of those 5 failing tests got before dying.
07:24 Coke chromatic: given that classes are not drop in replacements for PMCs, not really.
07:24 chromatic They ought to be.
07:24 Coke and that's assuming I didn't screw up the C to PIR translations.
07:24 Coke chromatic: they're not. =-)
07:24 Coke TT #218, for example.
07:25 Coke once I had a mostly function PIR version, I still had to make other changes elsewhere in the code to deal with it.
07:25 Coke also: http://code.google.com/p/p​artcl/source/detail?r=501
07:26 chromatic C versus PIR strikes again.
07:27 Coke so, I'll have to fix those regressions before I can get a real speed compare. so far looks "slightly better."
07:27 Coke another way: overriding :multi vtable entries.
07:28 afk_coke (oi)
07:31 viklund_ joined #parrot
07:37 clinton joined #parrot
08:11 cognominal joined #parrot
08:43 gaz joined #parrot
08:48 viklund_ joined #parrot
09:15 DanielC joined #parrot
09:30 mikehh_ joined #parrot
09:36 nopaste "mikehh" at 90.209.69.154 pasted "patch to fix docs/pdds/pdd19_pir.pod" (60 lines) at http://nopaste.snit.ch/16916
09:39 mikehh docs/pdds/pdd19_pir.pod failed t/codingstd/pod_syntax.t - fixed that but then failed examples_tests agin - now also fixed by patch
09:39 mikehh passes codetest and examples_tests with patch http://nopaste.snit.ch/16916
09:40 mikehh also fixed html
09:42 mikehh looking at TODO passes in t/op/debuginfo.t
09:42 * barney applied patch in r39568
09:44 dalek parrot: r39568 | barney++ | trunk/docs/pdds/pdd19_pir.pod:
09:44 dalek parrot: Better annotation of PIR examples
09:44 dalek parrot: Courtesy of mikehh++
09:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39568/
09:45 mikehh barney: thanks muchly
09:46 barney he, eays karma for me
09:52 barney s/eays/easy/
09:56 gaz joined #parrot
10:27 whoppix joined #parrot
11:07 burmas joined #parrot
11:10 mikehh how do you run a specific test in a given runcore - I think I have fixed t.op.debuginfo,t but need to test and don't want to run fulltest yet
11:10 moritz mikehh: perldoc t/harness
11:11 mikehh I did a prove t.op.debuginfo,t and that works but need to test the other runcores
11:11 mikehh ok I'll look
11:13 iblechbot joined #parrot
11:15 burmas joined #parrot
11:21 donaldh joined #parrot
11:34 szbalint joined #parrot
11:40 skids joined #parrot
11:51 bacek_ joined #parrot
11:52 mikehh got t/op/debuginfo.t TODOs fixed in everything but the -g core Test 8 ok
12:04 mikehh ok I think that works now
12:07 mikehh going to run codetest etc will post patch for t/op/debuginfo.t in a bit
12:07 mikehh got to go to the store - will run tests
12:11 ruoso joined #parrot
12:15 Whiteknight joined #parrot
12:26 AndyA joined #parrot
12:28 DanielC joined #parrot
12:41 elmex joined #parrot
12:56 Whiteknight bacek: ping
13:00 Whiteknight purl msg bacek Can you write about some of your annotations-related work in NEWS?
13:00 purl Message for bacek stored.
13:00 burmas joined #parrot
13:03 gryphon joined #parrot
13:04 dalek parrot: r39569 | whiteknight++ | trunk/NEWS:
13:04 dalek parrot: [NEWS] Add a preliminary selection of news items from the past month, based on my understanding of short, oblique SVN log messages
13:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39569/
13:06 bacek Whiteknight: "+ Initial version of Packfile PMCs with read/write capabilities"
13:06 bacek "+ Support for 'self' in NQP"
13:08 Whiteknight that was your annotations work?
13:08 afk_coke I want "lexical trace mode", so I can say "make this .sub have verbose tracing, but disable it whenever I leave the sub."
13:09 Coke (whenever you use PGE, it's mandatory. :|)
13:09 bacek Whiteknight: I did nothing with annotations. It probably was Tene and jonathan.
13:10 Whiteknight bacek: r38965 "Merge branch tt504_annations"
13:11 dalek parrot: r39570 | whiteknight++ | trunk/NEWS:
13:11 dalek parrot: [NEWS] Added two items for bacek++
13:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39570/
13:11 bacek yeah. It was PackfileAnnotations :)
13:11 Whiteknight ah, okay
13:15 nopaste "mikehh" at 90.209.69.154 pasted "PATCH to correct TODO PASSes in t/op/debuginfo.t" (45 lines) at http://nopaste.snit.ch/16917
13:16 mikehh the patch passes all tests - no extra TODO passes
13:16 Whiteknight wow, nice work
13:16 Whiteknight mikehh++
13:16 mikehh codetest etc passes
13:17 mikehh if fact with that patch make fulltest passes
13:17 Whiteknight are you a committer?
13:17 mikehh no
13:20 mikehh I just hope there are no probs on other paltforms
13:21 mikehh I am running Ubuntu (.04 i386
13:21 mikehh 9.04
13:21 Whiteknight I'm on 9.04 x86_64, so can't help much with diversified testing
13:25 dalek parrot: r39571 | barney++ | trunk/t/library/p6object.t:
13:25 dalek parrot: Add test for registering a parrotclass.
13:25 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39571/
13:34 buildbot joined #parrot
14:03 PacoLinux joined #parrot
14:12 * Coke remembers to run fulltest with TEST_JOBS this time.
14:12 Coke no love on pbc_to_exe, huh?
14:14 Coke wow. I am getting a TON of fulltest failures.
14:15 nopaste "coke" at 72.228.52.192 pasted "failures on os x/x86" (38 lines) at http://nopaste.snit.ch/16920
14:15 burmas left #parrot
14:21 Util Coke: which aspect of pbc_to_exe are you referring to?
14:25 mikehh coke: my patch should at least fix the first one - http://nopaste.snit.ch/16917
14:25 mikehh sorry
14:26 mikehh Coke: my patch should at least fix the first one - http://nopaste.snit.ch/16917
14:26 Whiteknight Coke: Don't say that! fulltest was running perfectly for me a few minutes ago
14:28 davidfetter joined #parrot
14:37 Coke Util: there's a ticket..
14:38 Coke http://code.google.com/p/partcl/wiki/ParrotIssues -> https://trac.parrot.org/parrot/ticket/691
14:38 Coke Whiteknight: it's failing for me drastically on os x/x86
14:39 Util coke, thanks
14:39 Whiteknight shit, I'm getting failures now in t/op/trans.t
14:39 Coke /drastically//
14:41 Whiteknight bacek: ping
14:42 Whiteknight purl msg bacek I'm getting some failures in t/op/trans.t, could r39565 or r39538 cause that?
14:42 purl Message for bacek stored.
14:42 Whiteknight Coke, what is failing specifically?
14:44 Coke Whiteknight: http://feather.perl6.nl/~coke/fulltest.txt
14:44 Coke (that's darwin)
14:44 Coke no new failures on partcl...
14:45 Coke Whiteknight: linux looks fine...
14:46 Whiteknight urg
14:47 Coke Whiteknight: I don't run fulltest often; no clue when those were introduced.
14:47 Coke I can probably give someone remote access to the box in question.
14:47 mikehh whiteknight: don't fail for me at r39567/8
14:48 Whiteknight I don't have any time now to do any remoting myself
14:50 pmichaud Good morning, #parrot
14:50 mikehh hi
14:50 davidfetter OH HAI
14:50 purl bonjour, mikehh.
14:52 Coke pmichaud: thanks for your input this weekend. couldn't override :vtable in PIR on a PMC, so I ended up just converting the whole PMC to PIR.
14:53 bacek Whiteknight: pong
14:53 Coke (which caused a few wierd spec test regressions I'm hunting down, but is otherwise going ok)
14:53 pmichaud Coke: glad to help.
14:53 Whiteknight bacek: I sent you a few messages
14:53 Whiteknight hello pmichaud
14:54 bacek Whiteknight: can you nopaste failures?
14:54 Whiteknight nopaste?
14:54 purl nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/ or http://paste.scsys.co.uk (for #catalyst, #dbix-class, #moose  and others) or http://gist.github.com/
14:54 clunker3 http://pasta.test-smoke.org/ or http://paste.husk.org/ or http://nopaste.snit.ch:8001/ or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/
14:54 moritz make fulltest pass on linux/amd64 with --optimize
14:55 nopaste "whiteknight" at 66.252.102.37 pasted "test failures for bacek++" (32 lines) at http://nopaste.snit.ch/16921
14:56 Coke does PIR support SUPER?
14:56 Whiteknight yeah, I had a successful fulltest last night on that platform, although I didn't optimize
14:56 Whiteknight Coke: no
14:56 Whiteknight there is a way to do it, but it involves the PMCProxy and it's a mess
14:56 PerlJam joined #parrot
14:57 Coke oh, right. I'm already using that trick. Thank you.
14:57 Whiteknight no prob
14:58 bacek Whiteknight: oh. platform and Configure.pl flags?
14:58 Whiteknight Win32, no configure flags
14:59 Whiteknight Strawberry Perl
14:59 purl hmmm... Strawberry Perl is found at http://strawberryperl.com/
14:59 bacek msg mj41 Can you add just Win23 into TapTinder?
14:59 purl Message for mj41 stored.
15:04 Theory joined #parrot
15:05 bacek Whiteknight: can you tweak test to output N2? Line 245, right before "print not"
15:10 Whiteknight it didn't fail when I did that. Let me rerun the tests
15:11 bacek Btw, I've got failure in t/pmc/pmc.t. Didn't see it yesterday.
15:11 bacek Is Win32 jit capable?
15:11 Whiteknight yes
15:13 Whiteknight I can't duplicate the failure outside of make testj, which is weird
15:14 bacek May be this is a problem. Some of those tests marked with @jittodo. Some of them - not. But technically - all this functions are very similar.
15:16 Whiteknight bacek: The value is NaN in make testj
15:17 bacek hrm...
15:19 bacek but... It's not parsing floating point. Second part is for "tanh N2, I1"...
15:19 bacek So it's just "N2 = tahn 1". And I bet that "1" parsed correctly!
15:20 donaldh joined #parrot
15:21 bacek We need jit expert to fix it.
15:21 bacek o wait...
15:23 Coke pmichaud: wierd. $P0 = 5 (when a PMC), then $P0[0] was returning ""; now it's returning NULL.
15:23 Coke (so am cheating by overriding the get_string_keyed_int vtable to convert it for me.
15:23 bacek Whiteknight: https://trac.parrot.org/pa​rrot/ticket/530#comment:2
15:24 pmichaud Coke: that sequence doesn't make sense to me.
15:27 donaldh left #parrot
15:29 Coke if I pre-extend a list to size FOO; and then ask to stringify the list, I walk through the elements, asking for the string value of each one (and potentially modifying it for display). When my list was a PMC, an element existed due to the extension (but had never been set), returned an empty string.
15:29 Coke now that it's PIR, I have to override the "give the string representation of the Nth element" to return the empty string where it would otherwise be the NULL string.
15:33 Coke One wonders why I'm pre-extending a subclass of RPA, though. =-)
15:34 pmichaud oh, so you're using $P0 = 5 to pre-extend the list.
15:34 pmichaud okay, I'm used to doing that with 'assign' instead of 'set'.
15:34 pmichaud normally RPA returns "" for any unset elements of an array.
15:34 pmichaud (if asking for a string)
15:34 Coke right.
15:34 Coke my subclass was returning null.
15:35 Coke (class vs. dynpmc)
15:35 Andy joined #parrot
15:35 pmichaud it's not inheriting what RPA does?
15:36 pmichaud oh, src/pmc/fixedpmcarray.pmc:303 looks bogus.
15:36 pmichaud compare to line 286.
15:41 NotFound pmichaud: Have you looked at my last patch in TT #752?
15:42 pmichaud I looked at the discussion, not the patch.  Looking.
15:44 viklund_ joined #parrot
15:44 pmichaud looks like we're starting to see the rash of -G failures again.
15:46 nopaste "pmichaud" at 72.181.176.220 pasted "-G failures rear their ugly head again" (34 lines) at http://nopaste.snit.ch/16922
15:47 pmichaud (note test #6 in the nopaste)
15:49 pmichaud NotFound: TT #752 doesn't really solve my problem.
15:49 pmichaud (the patch)
15:49 NotFound pmichaud: it pass the test case for me
15:49 pmichaud sure, but you have ICU.
15:49 NotFound I don't
15:50 NotFound I'm buliding with debian amd64 without icu right now
15:50 pmichaud oh.
15:50 amuck joined #parrot
15:50 pmichaud okay, I'll look again.  Did you see my note to the list about this issue?
15:50 pmichaud http://lists.parrot.org/pipermail​/parrot-dev/2009-June/002357.html
15:51 pmichaud I think there's a bug in utf8->to_encoding
15:51 NotFound If fails if I make it to convert to utf16 by default, but I make it to use utf8 for ascii, utf8 and latin1 cases.
15:52 pmichaud okay.  My patch in the mailing list does the same thing (convert to utf8), but gives me a segfault.  Any ideas why?
15:52 NotFound pmichaud: note that this patch always uses to_charset and to_encoding, to be on the safe side.
15:54 NotFound pmichaud: probably because some code somewhere assumes that utf8 encoding implies unicode charset, and that assumption fails because of other assumptions on other parts.
15:54 NotFound %-)
15:54 pmichaud well, in the specific test case I give, it's all unicode charset.
15:54 pmichaud (since unicode is a superset of iso-8859-1 and ascii)
15:54 pmichaud so I don't think that quite explains it.
15:55 NotFound pmichaud: it is in the real world, but not in parrot code.
15:55 pmichaud Okay.  I'm saying that we need to find that bug and fix it.
15:55 NotFound iso-8859-1 is charset iso-8859-1 and encoding fixed 8
15:56 pmichaud We shouldn't just work around it for this one case.
15:56 NotFound Different charset, different encoding, If you just change the encoding the result is not what other parts of parrots expect.
15:57 pmichaud Okay.  I'm saying that we need to find that bug and fix it.
15:57 pmichaud We shouldn't just work around it for this one case.
15:57 pmichaud "working around a special test case" is what led to this point in the first place.
15:59 NotFound Then tell people to stop complaining about not being able to do things without icu.
15:59 pmichaud I did do that.
16:00 pmichaud I've been told that requiring ICU isn't an option until July.
16:00 Coke for perl or parrot?
16:00 NotFound For rakudo, or for parrot?
16:00 pmichaud for parrot.
16:00 Coke heh.
16:00 pmichaud but the bug we're experiencing is a parrot one, and it's unrelated to ICU.
16:01 NotFound pmichaud: then what we do for this month release? Workaround, or nothing?
16:01 pmichaud When will the workaround get taken out?
16:02 pmichaud wait, we're off on a tangent.
16:02 pmichaud Let me back up.
16:02 pmichaud In the email I sent to the list, I point to a place where there's a known segfault.
16:02 pmichaud There's a segfault that shouldn't be there.
16:02 NotFound That depends on what you consider a workaround. Dropping the special case for utf8 can be easily done. Stablishing a permanent and well documented behaviour, I don't know.
16:02 pmichaud I have a repeatable test case that demonstrates the segfault.
16:03 pmichaud You're proposing to change my test case so that we don't see the segfault.  I claim that's wrong.
16:03 pmichaud Given that Rakudo is now experiencing segfault-and-gc issues again, I'd like us to be addressing the segfaults.
16:03 pmichaud The segfault I'm seeing is completely unrelated to ICU.
16:04 pmichaud so, to get to your question of "what do we do for this month release"....   if the option is "workaround so that a test case passes but leaves the segfault undiagnosed", I'm opposed.
16:04 NotFound pmichaud: Did you mean the segfault when applying the patch you put in that thread?
16:05 pmichaud Yes.
16:05 NotFound I'll take a look at it.
16:05 pmichaud Changing a string's encoding to utf8 should not result in a segfault.
16:05 NotFound pmichaud: but note that the workaround is not for that segfault, but for the concatenation problem that originates all that discussion.
16:13 NotFound pmichaud: it doesn't segfault for me. It says 'equal'
16:15 Whiteknight the whole mechanics of string encodings still mystifies and frightens me
16:19 pmichaud NotFound: on my system, I get a segfault after the equal.  See the mail.
16:19 pmichaud Yes, I note that the workaround is for the concatenation problem that originated the discussion.  However, your workaround ultimately uses the same routine that my post in the email does, which leads to a segfault.
16:20 NotFound I'll try in a 32 bit system in a few minutes
16:20 jhorwitz joined #parrot
16:21 Psyche^ joined #parrot
16:21 pmichaud I do think your patch is more of a correct solution, however, by changing the charsets to match as well.  So I think I'll do that in my version and see what happens.
16:26 pmichaud oh, wait.
16:26 pmichaud Apparently it's the "debug 1" that is causing the segfault.
16:26 pmichaud eliminating it, or changing it to "debug 0" no longer segfaults.
16:26 pmichaud Okay.
16:27 NotFound What debug?
16:27 purl well, debug is 1 to see what => being sent and received 'down the wire'
16:27 pmichaud in my test PIR script
16:27 pmichaud I had a "debug 1" in there to make it easier to trace with GCC.
16:27 pmichaud er, GDB.
16:29 NotFound Yes, adding that it segfaults for me.
16:29 pmichaud okay.
16:29 pmichaud I'm revising my patch and I propose we use it.
16:30 pmichaud (I'm revising to change charset instead of encoding)
16:30 pmichaud (or to change both)
16:31 nopaste "pmichaud" at 72.181.176.220 pasted "my proposed fix to TT #752" (52 lines) at http://nopaste.snit.ch/16923
16:32 pmichaud I'm running "make test" now.
16:33 eternaleye joined #parrot
16:33 pmichaud actually, I have an even better patch.  One moment.
16:35 eternaleye_ joined #parrot
16:35 nopaste "pmichaud" at 72.181.176.220 pasted "better fix to TT #752" (55 lines) at http://nopaste.snit.ch/16924
16:40 NotFound pmichaud: looks good
16:41 eternaleye joined #parrot
16:42 cghene joined #parrot
16:44 pmichaud I get a couple of failures where it's expecting utf16 results.... just a sec
16:45 NotFound It pass for me, I think because all that tests are skiped when no icu.
16:45 pmichaud correct.
16:45 pmichaud I'm going to update the encoding just a bit more.
16:47 NotFound Still segfaults with debug 1
16:48 pmichaud yes, that appears to be a separate issue.  I'll add a note to my mailing list post.
16:50 Sark joined #parrot
16:53 pmichaud string_cs.t seems to assume that concatenating utf16 should always result in utf16.  I'm not sure I agree, but...
16:56 NotFound I think we need more unicode encodings
16:56 pmichaud I'm happy with utf8 and utf16 :-)
16:57 NotFound They are variable length.
16:57 pmichaud utf16 is fixed width.
16:57 NotFound Is not
16:57 pmichaud depends on what you mean by "width"
16:58 pmichaud utf16 has the surrogates that handle things in the upper page blocks
16:58 pmichaud at any rate, we have at least one more encoding coming, according to the new strings pdd :-)
16:58 NotFound The same can be said with utf8 and the 8th bit
17:00 Theory joined #parrot
17:00 TimToady I do not consider utf16 to be fixed width
17:00 pmichaud fair enough, I agree.
17:01 pmichaud (upon reconsideration)
17:01 TimToady surrogates are evil
17:01 pmichaud I completely agree.
17:01 pmichaud I read something in my unicode book that said utf16 was fixed width, but upon reflection I disagree with that.
17:02 NotFound pmichaud: It was, a lot of years ago. But it wasn't called utf16 at that time, I think.
17:02 pmichaud the book is the Unicode 4.0 guide.  It understood the difference between utf16 and ucs2
17:02 moritz UCS-2 is usually said to be fixed-width
17:02 NotFound moritz: It is, but it has limited range.
17:03 TimToady so does UCS-1 :)
17:03 NotFound The same as iso-8859-1 is a unicode encoding of fixed width with limited range.
17:03 NotFound And ascii.
17:04 ruoso_ joined #parrot
17:05 ruoso_ joined #parrot
17:07 * Coke wonders if/when he should retest partcl after the unicode changes. =-)
17:17 pmichaud finally, all tests pass.
17:17 nopaste "pmichaud" at 72.181.176.220 pasted "patch to fix string concat (TT #752)" (61 lines) at http://nopaste.snit.ch/16926
17:24 NotFound pmichaud: pass for me in amd64, now with icu
17:24 dalek parrot: r39572 | pmichaud++ | trunk (2 files):
17:24 dalek parrot: [core]:  Fix to TT #752 to get concatenation of mixed string types to work.
17:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39572/
17:37 Coke pmichaud: no core partcl failures with r39572
17:37 Coke (running the spec tests for string/utf handling)
17:39 dalek TT #752 closed by pmichaud++: Parrot concatenates iso-8859-1 and utf8 incorrectly
17:39 pmichaud Coke++ # thanks
17:40 pmichaud I'm pretty comfortable with the patch doing the right thing for now.
17:40 pmichaud It will undoubtedly be revisited/re-implemented when work begins on the new strings implementation.
17:41 NotFound pmichaud: agree
17:42 skids when and who is doing the new STRING?
17:45 Coke SFAIK, there is no concrete time line at this time.
17:45 Coke simon cozens had started to spec out the new interface.
17:46 skids is he posting/blogging that somewhere?
17:46 NotFound I think that there is a branch with seudocode for some operations.
17:46 Coke pmichaud: stringComp.test is ABENDing.
17:47 Coke I'll try to figure out if/when it broke.
17:47 skids was that the branch I saw someone say was rather old a few days back?
17:47 Coke er, s/if//
17:47 NotFound skids: probably yes
17:49 Coke last updated in january. never kept up to date with trunk.
17:49 Coke https://trac.parrot.org/par​rot/wiki/BranchDescriptions  //Strings
17:49 skids thanks.
18:03 sekimura joined #parrot
18:09 viklund_ joined #parrot
18:13 Theory joined #parrot
18:15 he_ Hi, folks.
18:16 he_ I'm doing "Testing for 1.3.0", as directed by the title, and ... have a new failure.  I'll send a nopaste.
18:16 nopaste "he" at 158.38.152.63 pasted "t/pmc/eval.t test failure stack backtrace++" (106 lines) at http://nopaste.snit.ch/16927
18:17 chromatic joined #parrot
18:52 dalek rakudo: 0d5221a | pmichaud++ | build/PARROT_REVISION:
18:52 dalek rakudo: Bump PARROT_REVISION to get latest parrot changes.
18:52 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​d5221a380fd2ac5e065cc778bdf1e38f82c1215
18:55 mikehh_ joined #parrot
18:58 NotFound he_: What were you executing to get that failure?
19:20 donaldh joined #parrot
19:22 particle joined #parrot
19:28 dalek rakudo: d3185be | pmichaud++ | docs/spectest-progress.csv:
19:28 dalek rakudo: spectest-progress.csv update: 404 files, 11535 passing, 0 failing
19:29 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​3185be45f4b770890164d96cd9509d2a9ef988f
19:29 dalek rakudo: ba09b27 | pmichaud++ | :
19:29 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
19:29 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​a09b2773ac6c67fed4ac4ee74e54f41f6cdd1a2
19:29 NotFound pmichaud: the segfault in your test is no strings related at all, is a pitfall in the debugger ops.
19:29 pmichaud correct.
19:29 pmichaud did I say it incorrectly in my message?
19:29 NotFound I have a simple fix for it.
19:29 pmichaud (checking)
19:30 NotFound pmichaud: no, is just the conclusion of some test I'm doing
19:30 pmichaud oh, okay.
19:32 donaldh left #parrot
19:37 dalek parrot: r39573 | NotFound++ | trunk/src/debug.c:
19:37 dalek parrot: [cage] fix for a problem with the debug op found while working on TT #752
19:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39573/
20:03 mikehh joined #parrot
20:07 mikehh_ joined #parrot
20:18 Theory joined #parrot
20:24 pmichaud NotFound: You might want to look at TT #760.
20:27 NotFound pmichaud: I'm doing right now
20:30 NotFound The diagnostic is wrong, FileHadle.readline_interactive returns NULL
20:32 NotFound BTW I've never used a system that has a default of control-G for eof
20:35 pmichaud me either... I think it's really CTRL-D
20:35 pmichaud anyway, I can verify that it fails under current trunk.
20:36 NotFound Ctrl-D is the default value in unix systems, and windows uses ctrl-z since the times of ms-dos and cp/m AFAIK
20:38 pmichaud (rebuilding trunk, then will nopaste)
20:38 NotFound I agree that setting the EOF flag in the filehandle is reasonable, anyway.
20:38 pmichaud that also requires a deprecation cycle, I think.
20:40 nopaste "pmichaud" at 72.181.176.220 pasted "trunk readline_interactive is incorrect" (29 lines) at http://nopaste.snit.ch/16928
20:41 NotFound pmichaud: that test is wrong
20:41 pmichaud how so?
20:42 NotFound The string is null, the pmc that contains a null string is not.
20:42 pmichaud NotFound: no.
20:42 pmichaud readline_interactive has been defined from the beginning to return NULL when reaching EOF
20:42 pmichaud in particular, it's been defined to return a PMCNULL
20:42 NotFound pmichaud: It returns a NULL string.
20:43 pmichaud NotFound: I'm telling you the way it was defined in 1.0.0
20:43 pmichaud you cannot change that definition without a deprecation cycle
20:43 pmichaud the definition of returning a NULL PMC has been in place for a very long time
20:43 NotFound So it returned a PMC, not a string?
20:43 pmichaud YES.
20:43 pmichaud not an empty string.
20:43 NotFound That's a different kind of problem.
20:44 pmichaud readline_interactive returns an empty string if the person simply hits "enter"  ( any newline is automatically chopped off )
20:44 pmichaud so the way to determine EOF has always been to check for a Null PMC
20:48 NotFound I don't get it. It must return a PMC only for the eof case, or it must always return a PMC?
20:49 pmichaud it doesn't really matter, normally.
20:49 pmichaud because the calling conventions normally take care of casting to alternate forms.
20:50 pmichaud i.e., it would work even if I did     $I0 = $P0.'readline_interactive'('prompt')
20:50 NotFound pmichaud: here lies the problem: the calling conventions does not convert a NULL string to a NULL PMC.
20:50 pmichaud a NULL string isn't EOF.
20:50 pmichaud I don't need it to convert a null string to a null PMC
20:51 pmichaud a null string should be returned as a null string.
20:51 pmichaud the way it was set up in the 1.2.0 was correct.
20:51 NotFound There is no way no read a null string. An empty line is an empty string.
20:52 pmichaud sure, no problem.
20:52 pmichaud but an empty line is returned as a null string.
20:52 NotFound pmichaud: the current code does not do that.
20:52 pmichaud NotFound: the current code is WRONG.
20:52 pmichaud the interactive readline code chops off the trailing newlines of any input data.
20:53 pmichaud you may disagree with the design of 'readline_interactive'.  That's fine if you disagree there.  But it cannot be changed without a deprecation cycle.
20:53 NotFound pmichaud: the readline lib already does that
20:53 pmichaud That's my point.
20:54 pmichaud (the readline lib already does that) -- that's my point.
20:54 NotFound Already does the chop, but does not return null
20:54 pmichaud please, let's get some terms straight
20:54 pmichaud what do you mean by "null string"?
20:55 NotFound At c level (char *) 0. At parrot level (STRING *)0
20:55 pmichaud okay.
20:55 pmichaud so, "null string" is a 0 pointer.
20:55 pmichaud "empty string" is a string of zero length.
20:55 pmichaud okay so far?
20:55 NotFound Yeah, bot in C and in parrot strings
20:56 Andy joined #parrot
20:56 pmichaud now then, the readline library returns an empty string if there's an empty line of input, yes?
20:56 NotFound Ok
20:56 pmichaud the readline library returns a null string if EOF is reached
20:56 pmichaud the readline_interactive method must return a PMCNULL if EOF is reached
20:57 pmichaud because otherwise the caller doesn't have an easy way to determine that EOF has been reached.
20:57 pmichaud if EOF is not reached, then readline_interactive simply returns whatever string it got back from the readline library.
20:57 NotFound Minor point: if EOF is found without reaching EOL, it does not return NULL.
20:58 pmichaud fair enough, but not a major issue to the way things are set up.
20:58 pmichaud again, readline_interactive was explicitly created to mimic the behavior of the readline method in earlier versions of Parrot (but also providing better prompting support)
20:59 pmichaud so you can't claim that my test is wrong, because my test is testing the API that was set up for Parrot 1.0.0
21:00 NotFound pmichaud: is wrong as a way of checking if it returns NULL. It already returns NULL, just a different kind of NULL than expected.
21:01 pmichaud how do you think it should be testing for NULL?
21:01 pmichaud and that question is bogus anyway.
21:01 pmichaud In 1.0.0, the way to check for EOF from readline_interactive was to check for PMCNULL.
21:01 NotFound pmichaud: for the current state of the code, using a string for the result, not a pmc
21:01 pmichaud how does one check for a null string in PIR?
21:02 NotFound Same as a pmc, just using a string register
21:03 NotFound Anyway, we can just change the method to always return a PMC, both for eof and not eof cases.
21:03 pmichaud that's fine with me.  I just don't want to see an API change without proper deprecation.
21:03 NotFound A null pmc for eof, a string pmc otherwise.
21:03 pmichaud why was this changed in the first place, out of curiosity?
21:03 pmichaud it was working correctly in 1_2_0
21:04 pmichaud oh.
21:04 pmichaud There is no "isnull" opcode for string registers.
21:04 NotFound pmichaud: I remember a talk about inconsistently returning string or pmc, don't remember if it was about this method or another thing.
21:04 pmichaud So, it's not "same as a pmc"
21:06 NotFound pmichaud: I've been testing with 'unless null ...' and works fine :?
21:06 pmichaud it looks like there's an "unless_null" for string registers, yes.
21:06 pmichaud but not an "isnull"
21:06 NotFound Ah, the isnull opcode... I didn't think about that.
21:07 NotFound There is some reason for not having it?
21:07 pmichaud Not that I'm aware of.  We could potentially add it.  Still, the readline_interactive needs to be able to work with PMCs
21:08 NotFound pmichaud: I think the clean solution is to always return a PMC.
21:08 pmichaud I should be able to do   $P0 = $P1.'readline_interactive'()  and have it do the right thing.
21:08 pmichaud why always return a PMC?
21:08 pmichaud that seems inefficient.
21:08 NotFound Consistency.
21:08 purl it has been said that consistency is a problem. or highly overrated or the hobgoblin of small minds or (see FOOLISH consistency)
21:08 pmichaud why does it need to be consistent?  (more)
21:09 NotFound Good question
21:09 purl Yeah, it is. I'm stumped.
21:09 pmichaud or are you claiming that all of the PIR methods we right should also consistently always return the same thing?
21:09 pmichaud right now in PIR we can do
21:09 pmichaud .return ($P0)
21:09 pmichaud and
21:09 pmichaud .return ($S0)
21:09 pmichaud in the same method.  Why would this need to be any different?
21:10 pmichaud s/right/write/ # above
21:10 NotFound I'm most used to statically typed systems
21:10 pmichaud In general, I think type conversions should be left up to the calling conventions as much as possible, since we have them.
21:10 pmichaud if we always return a PMC, then
21:11 pmichaud $S0 = $P1.'readline_interactive'()
21:11 pmichaud will end up always creating a PMC that is immediately thrown away.
21:11 bacek good morning #parrot...
21:13 NotFound pmichaud: not a big speed problem for interactive usage, but I see the point.
21:13 pmichaud yes, I agree it's not a big speed problem.
21:14 pmichaud given that we even have a way to check string registers for null, I don't have an issue for that.  At the time when all of this was being put together, I didn't realize there was a way to check string registers for null because there wasn't an appropriate isnull opcode
21:15 Whiteknight joined #parrot
21:15 NotFound Well, I think a good plan might be: restore the old behaviour now, propose to deprecate it in favour of returning a null string, and propose to add a isnull opcode for string
21:16 pmichaud I think I'd be okay with that.
21:16 Whiteknight +1 from me
21:16 Whiteknight just so long as we get a fix in for the release tomorrow
21:16 NotFound Whiteknight: I'll do that
21:16 pmichaud well, from a parrot perspective it has to be fixed by 1.4.
21:16 pmichaud Having it fixed by tomorrow would be a bonus, yes.  :-)
21:22 Whiteknight NotFound++
21:25 Whiteknight t/codingstd/paren.t failure: /home/andrew/Projects/parrot/src/string/api.c
21:27 mikehh ditto - all other tests pass on make -k fulltest on Kubuntu 9.04 Amd64 at r39573
21:27 Whiteknight i just put in a fix
21:27 NotFound There is a minor problem: returning PMCNULL causes a Null PMC access exception when using a string for the result, but I suppose that code that expected the previous behaviour never does that,
21:27 mikehh I did apply the patch http://nopaste.snit.ch/16917
21:28 pmichaud NotFound: correct.
21:28 dalek parrot: r39574 | whiteknight++ | trunk/src/string/api.c:
21:28 dalek parrot: [t] fix coding std failure
21:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39574/
21:28 kid51 joined #parrot
21:30 mikehh I now pass fulltest on Ubuntu 9.04 i386 and Kubuntu 9.04 Amd64 (apart from the codetest failure)
21:30 mikehh The patch http://nopaste.snit.ch/16917 works on both
21:31 Whiteknight mikehh, is that patch associated with a ticket?
21:31 dalek parrot: r39575 | NotFound++ | trunk/src/pmc/filehandle.pmc:
21:31 dalek parrot: [io] restore behaviour of readline_interactive, TT #760
21:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39575/
21:32 mikehh whiteknight:  I didn't create one - I can
21:32 Whiteknight don't worry about it, I'm testing it now
21:33 Whiteknight committed
21:34 Whiteknight mikehh++
21:35 dalek parrot: r39576 | whiteknight++ | trunk/t/op/debuginfo.t:
21:35 dalek parrot: [t] add patch from mikehh++ to fix TODO test passing in some places in t/op/debuginfo.t
21:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39576/
21:35 mikehh :-} - that's two patches I got in today
21:37 NotFound Fix a TODO passing is don't do it? ;-)
21:39 Whiteknight fix it so it's not TODO and is always passing
21:40 NotFound Ah, good :)
21:42 NotFound BTW, I'm not having amd64 test errors for more than a week :)
21:43 NotFound Is a shame, I've installed a linux 64 in order to be able to work on that problems X-)
21:43 chromatic I rooted your box and made it a 32 bit installation.  You're welcome.
21:45 NotFound I always thinked that there must be some obscure reason for the nopaste showing of the IP ;)
21:53 he_ NotFound: sorry; a trip to the cinema got between us...  This is the result of running "perl t/harness t/pmc/eval.t", and it fails test 17 with "src/call/pcc.c:563: failed assertion 'PObj_is_PMC_TEST(sig_pmc)'".
21:56 chromatic Did you 'make realclean' and rebuild, he_?
21:57 he_ chromatic: yes, "make distclean; perl ./Configure.pl && make && make smoke".  I can repeat just to be absolutely certain.
21:59 chromatic Is distclean different from realclean?
21:59 chromatic I don't know the differences.
22:00 chromatic Ah, they're the same.  Okay.  Hm.
22:00 Tene chromatic: I found a FAIL in some C code that was last touched by you afaict... TT 757
22:01 he_ Not really; top-level Makefile has "distclean : realclean"
22:01 chromatic Tene, the fail is probably an old, old fail, but I can take a look.
22:02 Tene chromatic: Thanks.  I'd really like to get threading working to some degree in rakudo.
22:03 chromatic Me too.
22:03 chromatic Autothreading would be spectacular.
22:06 Whiteknight what is the state of the Parrot threading system?
22:06 Whiteknight I know it "works" to some degree, but don't know if it's good or needs work or what
22:06 chromatic Cloning interpreters doesn't fully work.
22:06 chromatic I think there's a problem cloning classes and other interpreter global information.
22:07 Whiteknight that doesn't sound so bad
22:08 Whiteknight the code I saw seemed a little old and messy but otherwise sane
22:10 chromatic It's not horrible.  It's merely incomplete.
22:11 Tene Whiteknight: The pir file attached to TT757 exposes a bug with class cloning, iiuc.  it runs fine without perl6.pbc loaded, but when you uncomment the load_bytecode perl6.pbc, it fails an ASSERT.
22:11 Whiteknight Somebody else had done some work on that system (chromatic?) after I wrote it, poorly
22:12 Whiteknight I'll take a look at the ticket, how urgent is it?
22:13 Tene Whiteknight: if someone can get it working, I can add 'async' to rakudo, afaict.
22:13 Tene To get basic threading.
22:13 Tene And after that, maybe some autothreading.
22:13 Whiteknight oh wow, okay, so that is important
22:13 Whiteknight can it wait till after the release though?
22:13 Tene Well, I don't know if anybody is actually blocking on async.
22:13 jan joined #parrot
22:13 Whiteknight okay
22:14 Tene Um, ask pmichaud?
22:14 Whiteknight next month will be a big one for asynchronous stuff, I think
22:14 Tene Oh!  I'm kinda blocking on it... as far as "this would be fun to play with" counts as a blocker. ;)
22:15 Tene Which is "not much".
22:15 chromatic I think we have more important blockers to concentrate on first.
22:15 Tene Rather. :)
22:16 chromatic I'd like to talk about that at YAPC next week.
22:17 Whiteknight talk about what, our short-term priorities?
22:18 Whiteknight I've got AIO in my sights now, and I'm tackling that system soon, come hell or high water
22:19 Infinoid What assert does it fail?
22:19 Whiteknight Maybe one more round of IO cleanups as soon as the release lands, and then it's on to AIO
22:19 * Tene sad to be missing YAPC
22:20 Tene Infinoid: ./src/pmc/parrotinterpreter.pmc:94
22:21 * Infinoid sees about reproducing that in gdb
22:22 Tene I always have trouble remembering how to get information from parrot structures in gdb, and have to re-discover every time.
22:22 chromatic Not our short term priorities but how we handle priorities and milestones and tasks.  I think we could be more effective.
22:22 Tene Infinoid: it fails on the first iteration, and class_name is "Perl6;Grammar;Actions"
22:23 Tene if that helps
22:24 Infinoid thanks, I'm gonna start by seeing which class it's calling the exists_keyed_str vtable on
22:26 Tene Infinoid: parrotinterpreter
22:27 Tene look at line 80
22:28 Tene also at the signature of the function
22:28 Infinoid I don't get an assert failure
22:28 Infinoid I get: get_pmc_keyed_str() not implemented in class 'Key'
22:28 Tene I remember seeing that after I removed the assert
22:28 viklund_ joined #parrot
22:29 Whiteknight chromatic: I agree, we haven't been too good at estimating what tasks will get done when
22:30 chromatic More than that, we still flail around at the edges of the important tasks and sometimes poke at them.
22:31 chromatic We do pretty well when we work together on things, but we don't work together on things as often as I'd like.  We could be more effective.
22:31 Whiteknight I agree with that, but those are intrinsic mechanics of volunteer-driven groups
22:31 Whiteknight people work on what interests them first, which isn't necessarily what's best for the organization
22:31 Tene Whiteknight: that doesn't mean that we can't try to do something different (on a volunteer basis)
22:32 Whiteknight Tene: Oh, I definitely agree, we need to encourage people to work on important things, but not get discouraged when they don't
22:32 Whiteknight it's like herding cats
22:32 Tene Whiteknight: I'm often primarily interested in "Doing something for parrot", but the current priorities aren't very clear.
22:32 Infinoid cats who like shiny things, and often disagree on which things are shiny
22:33 Tene Not so much in the past few months, but before that I often came in here, asking "Is there anything anyone wants me to work on?"
22:34 rg1 joined #parrot
22:34 Tene I don't do that so much anymore due to lask of response and decreasing available time.
22:34 Whiteknight chromatic: What in your mind is highest priority right now?
22:36 Infinoid It often seems like the highest priority stuff (like, for instance, making PCC faster and making the GC suck less) are the least approachable tasks to those people who are just looking to throw a spare hour at parrot here and there
22:37 Whiteknight I'll be happy to focus on whatever is the task du jure, allowing for some focus on areas of personal interest
22:38 Tene My life is settling down a lot lately... I'm looking to have a regular scheduled Parrot Hour every evening.
22:38 Whiteknight Tene: luck you! my life is becoming increasingly unsettled
22:39 Infinoid The last couple of weeks were a statistical outlier, it's all downhill from there for me too
22:40 he_ chromatic: new test results are same as before (as expected), http://smolder.plusthree.com/app/pu​blic_projects/report_details/23783
22:41 Tene Whiteknight: seems like I'm paying for the next year's complexity and stress over about two weeks, centered around last weekend.
22:42 Tene so, it's a tradeoff. :)
22:48 * Infinoid noms PBJ and tests the TT #726 patch for leaks
22:53 Infinoid Yay, no leaks.
22:53 * Infinoid will commit it after 1.3.0
22:53 chromatic I'm not sure what the current priorities are.
22:53 Infinoid Actually, putting a priority in the channel topic has helped me a lot
22:53 chromatic Obviously PCC rewiring (but that one depends highly on Allison either to explain or finish).
22:54 chromatic Installable Parrot and HLLs running from installable Parrot.
22:54 NotFound Tene: <Tene> I always have trouble remembering how to get information from parrot structures in gdb, and have to re-discover every time.
22:54 chromatic Multidispatch semantics, I think.
22:54 NotFound Tene: a page in the wiki about that will be helpful
22:54 chromatic It'd be nice to have a regular plan for refactoring a part of Parrot.
22:55 Infinoid NotFound, Tene: There are some helpers in tools/dev/.gdbinit
22:55 chromatic Mostly I'd like to pick one or two targets for each monthly release, have someone take charge of breaking it up into bite-sized tasks, and help herd all of us to getting it done.
22:56 Whiteknight chromatic: I was looking at the pcc_rewiring branch the other day, and just merging it up to trunk HEAD is a bit of a nightmare
22:56 chromatic Yeah, it needs smaller merges.
22:56 Tene I remember several times seeing someone working on a branch, and not having enough information about the branch to help.
22:56 chromatic Or git.
22:57 Tene The majority of our branches have been one or two person affairs, and if that person loses momentum, the work is lost.
22:57 Tene iirc
22:57 Whiteknight chromatic: I'm almost convinced that the best way forward on pcc_rewiring is to delete the branch and start a shorter-lived one in it's place
22:57 Whiteknight although there's a point beyond which a large chunk of work needs to get done between merges, to migrate things from one system to another
22:57 chromatic That's one of our problems.  We have plenty of expertise and people to solve a problem, but too often the solution to that problem is in one person's head where it's difficult to collaborate.
22:57 * Infinoid eats some git spinach and takes a crack at merging
22:58 Tene I'll try a pcc merge with git.
22:58 NotFound The same might apply to the strings branch
22:58 Whiteknight Infinoid: I got the merge to work today, but it was ugly
22:58 Whiteknight and I lost track of some metadata along the way, so I have to redo it later
22:58 chromatic It should just be a git rebase, if I understand git correctly (and I'm not sure I do).
22:58 Whiteknight on the bright side, it does clean up the error backtraces significantly
22:58 Whiteknight because of all the io_rewiring work, cleaning up PCCINVOKEs in the IO system
22:59 Infinoid chromatic: Yep, that's what it is
22:59 Infinoid How's pmc_pct going?
23:00 chromatic That's cotto and bacek, I think.
23:00 chromatic I've watched how they work and I watch how Allison and I can work and I watch how Patrick and Jonathan work, and I believe more strongly that we go faster and write better code when two people tackle a problem.
23:01 Infinoid I just think we have a lot of rock stars. :)
23:01 Tene Yeah, it doesn't merge cleanly, and I don't know enough about the changes to sanely resolve the merge conflicts.
23:02 Whiteknight chromatic: I'm sure of it, Infinoid and I did really well together this month, and I'd be happy to pair up on other projects in the future
23:03 chromatic Pairing would be good.  Maybe that's sufficient.
23:04 chromatic I hate to introduce that dreaded P-word into the discussion, but a little more formality on how we approach things might help a lot.
23:04 Whiteknight I'm very open to the idea of pairing
23:04 Infinoid Whiteknight++ # You did most of the work, I just swung through like a pirate and stabbed a couple of things sticking out
23:04 Whiteknight and like I said, I'll work on anything people have a clear need to do, and without a major focus I work on areas of personal interest
23:05 Whiteknight I'm looking forward to some real heads-together hacking at YAPC, if we can find time to do that
23:05 chromatic That's the sticking point Allison thought might come up; people work on what they want to work on.
23:05 Infinoid I need to figure out a way to get there
23:07 Infinoid Problem is I can't actually stay for YAPC, so I'd just be going for the hackathon
23:07 Infinoid Then again, I'm an hour away from Whiteknight, maybe I can just drop by some other weekend with pizza.
23:07 NotFound pizza++
23:09 chromatic Thursday wouldn't be bad.
23:10 Whiteknight I'm leaving tuesday evening, unfortunately
23:10 Whiteknight Infinoid: I would love to get together for hackathons
23:10 Coke yay, ^D now closes interactive tcl.
23:11 Coke ... of course, [exit] doesn't. wierd. figured those were the same problem.
23:11 Whiteknight chromatic: First step is identifying our priorities, second step is motivating people to tackle them
23:12 Coke the roadmap was supposed to help identify priorites.
23:12 Whiteknight getting together for focused planning meetings for those tasks would be nice, like #ps but focused on a single task
23:12 NotFound The addition of an isnull (out INT, in STR) opcode needs a RFC, or it just doesn't exist because nobody noticed his absence?
23:12 Coke but they really need more requirements than just "bullet item".
23:12 Whiteknight NotFound: I say add it, but maybe ask tomorrow at #ps to be sure
23:12 Coke perhaps have a patch ready in case no one minds. =-)
23:12 NotFound Whiteknight: ok
23:13 Tene Several times, I've found a severe lack of information on the roadmap.
23:13 chromatic That's just it.
23:14 chromatic The idea was in someone's head at some point, but it's not available in a form that lets Tene say "Oh, I can do THIS in an hour" or Infinoid say "I have Saturday morning free" or Whiteknight "I'll take my laptop while my wife is watching Pride and Prejudice again."
23:15 Whiteknight I think a part of it is uncertainty about who can and should be updating design docs
23:15 Whiteknight and what the process is for putting plans together, and where such plans should be
23:15 chromatic Yep.
23:16 chromatic We do that ad hoc anyway though.
23:16 Whiteknight I do a lot of informal planning on my blog, but that's only helpful to me and the one dude who reads it
23:16 NotFound Coke: I located the exit problem some months ago while putting a hand on ecmascript. Exceptions are unconditionally catched by the code generated by the tools, and the interactive loop reentered.
23:17 Infinoid Whiteknight: Can has blog URL?
23:17 Infinoid purl, whiteknight?
23:17 purl whiteknight is mailto:wknight8111@gmail.com or the grand master funk
23:17 Andy joined #parrot
23:18 Whiteknight the parrot-related posts are in the planet.parrot.org aggregator
23:18 Whiteknight planet.parrotcode.org
23:18 purl i guess planet.parrotcode.org is the aggregator
23:18 skids joined #parrot
23:19 Coke NotFound: I just figured that out. (Easier to see now that the ^D issue is fixed.)
23:19 Coke of course, since I have my own REPL, have to figure it myself.
23:19 Coke s/have/had/
23:20 Coke NotFound: looks like that never would have worked. =-)
23:20 Tene I wonder how helpful it would be to have explicit "email <tene@allalone.org> for more information on what's required here" notes.
23:20 NotFound In ecmascript I worked around that by throwing a fatal excpetion, but I don't think that is a good general solution.
23:20 chromatic email has too much latency.
23:20 Tene presuming the content of those emails would be "Please add detail on A, B, and C to the page"
23:21 Tene Phone? ;)
23:21 dalek partcl: r502 | coke++ | trunk/src/tclsh.pir:
23:21 dalek partcl: Allow [exit] to leave the REPL
23:21 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=502
23:22 Infinoid purl, whiteknight is also http://wknight8111.blogspot.com/
23:22 purl okay, Infinoid.
23:27 patspam joined #parrot
23:28 GeJ Good morning everyone
23:30 everyone good morning, GeJ
23:32 nopaste "GeJ" at 202.22.227.128 pasted "NEWS: be consistent with previous releases and add '.' after each item. Also fix a couple of typos I found" (51 lines) at http://nopaste.snit.ch/16929
23:32 dalek TT #10 closed by coke++: -r33351 causes tcl segfault
23:33 GeJ I may have missed some. Never trust the English of a French.
23:33 GeJ Hello davidfetter
23:36 dalek parrot: r39577 | bacek++ | branches/tt761_keys_revamp (4 files):
23:36 dalek parrot: [pmc] Initial version of HashIterator/HashIteratorKey.
23:36 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39577/
23:36 bacek OH HAI.
23:37 GeJ G'Day bacek
23:38 eternaleye joined #parrot
23:40 kid51 Whiteknight:  With Infinoid now in DE, possibility of East Coast hackathon becomes non-zero.
23:41 Coke I could be up for an east coast thing.
23:41 Coke though I'll probably just show up and whine about how everyone keeps breaking partcl.
23:41 Coke (which, oddly, hasn't happened recently.)
23:41 kid51 Sometime between Sept and Nov would fit nicely into the yearly conference cycle.
23:41 chromatic I seem to recall *fixing* partcl.
23:42 Tene Coke: Now that you can use partcl libraries from rakudo, you just need to get some tests that use partcl into rakudo's test suite. ;)
23:42 Coke chromatic: =-)
23:42 Coke chromatic: I'm actually trying to close out a few bugs you fixed.
23:42 dalek TT #193 closed by coke++: segfault using -t1
23:44 Infinoid What's the difference between "Integer" and "INTVAL" from an MMD perspective?  BigNum declares MULTI PMC *add(BigNum value, PMC *dest), MULTI PMC *add(Integer value, PMC *dest), MULTI PMC *add(DEFAULT value, PMC *dest) and VTABLE PMC *add_int(INTVAL value, PMC *dest), which confuses me.
23:45 Infinoid one is for the .add method, and one is for the add op, I guess?
23:46 Coke I would expect INTVAL is 'int'
23:46 Coke but I wonder why we wouldn't just write "int" instead of exposing the C type.
23:46 dalek parrot: r39578 | tene++ | trunk/NEWS:
23:46 dalek parrot: minor NEWS update
23:46 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39578/
23:46 dalek partcl: r503 | coke++ | wiki/ParrotIssues.wiki:
23:46 dalek partcl: Several parrot tickets have been resolved.
23:46 dalek partcl: Also, reformat slightly.
23:46 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=503
23:47 Infinoid oh, I get it.  Integer is a PMC type
23:47 chromatic Integer is the PMC type, isn't it?
23:47 Infinoid BigNum has a distinct lack of *_float vtables
23:51 Coke Is there any documentation on interacting with parrot's call chain? I wish to stop managing my own.
23:51 chromatic What do you have in mind?
23:52 kid51 I know certain people will hate to hear this but ...
23:52 Coke I need to be able to execute code in the context of higher levels.
23:52 Coke or return control up N levels.
23:52 kid51 I'm getting a codingstd failure t/codingstd/c_indent.t fails on src/pmc/filehandle.pmc
23:52 chromatic [upvar]
23:52 Coke chromatic: yes. upvar, uplevel, return -level 4 continue
23:53 Coke right now I manage my own and can pull off... most of that.
23:53 Coke but it's extra work I shouldn't be doing.
23:53 chromatic I'm not sure how to do upvar, but return -level 4 should be following the return continuation chain.
23:54 kid51 This "bad indent" is the line after an #ifdef
23:54 kid51 Test wants 4 spaces; line is indented 8.
23:54 Coke kid51: that conflicts with another test. have fun. =-)
23:54 Coke either that, or with good sense.
23:54 amuck joined #parrot
23:54 kid51 But line is indented 8 to be consistent with overall indent style:  file is one big block
23:55 kid51 #ifdef  has to be flush left, correct?
23:55 Coke /have/ to be? no.
23:55 chromatic Unless it's within an #ifdef.
23:55 kid51 lemme se
23:55 kid51 see
23:55 Coke This is one of those cases where it's not worth spending the time making the test pass.
23:56 Coke chromatic: so, pointers to docs on return continuation chain? Esp. the part where I only care about HLL scopes?
23:57 chromatic Beyond the Continuation POD, I'm not aware of any.
23:57 chromatic There *might* be some general discussion of how things work in a PDD (calling conventions?) or docs/dev/ somewhere, but certainly not from an HLL implementor POV.
23:57 chromatic HLLIPOV
23:58 Coke bah.
23:58 Coke ok. shelving that, then.
23:59 chromatic Consider it a cri-pportunity to provide some!

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

Parrot | source cross referenced