Camelia, the Perl 6 bug

IRC log for #parrot, 2008-07-29

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:10 Tene DietCoke: looks like no parrot work today.  I've been distracted by a personal project for a while.
00:30 bacek joined #parrot
00:43 ruoso joined #parrot
00:43 Theory joined #parrot
01:16 ruoso joined #parrot
01:16 duckyd joined #parrot
01:18 DietCoke kid51: pong. didn't have a chance to run that test yet. You still need it?
01:19 DietCoke (ugh. getting late)
01:31 DietCoke if I want something in C that respects the PCC, creating it as a PMC method is the easiest (only?) way to do so, neh?
01:32 DietCoke well, not only, since I could just take whatever the pmc2c generated and used that, but that's guly.
01:32 DietCoke "ugly"
01:34 kid51 DietCoke:  Yes, though it's not a must for today.  However, please see my remarks in http://rt.perl.org/rt3/Tic​ket/Display.html?id=57358, which has thrown a spanner in the works.
01:35 DietCoke kid51: there's no spanner.
01:35 DietCoke that's an orthagonal issue.
01:35 DietCoke (I had a followup comment.)
01:35 DietCoke s/had/made/
01:36 DietCoke The combination you're doing should still be done; his parallel stuff is another potential speedup we can (should) do, but you can resolve the parallel branch independantly of making things ||-safe.
01:36 kid51 k
01:37 DietCoke that's more of a nice to have. Just nice to have the option to run it that way now, perhaps it will encourage someone else to supply a patch. =-)
01:37 DietCoke but anyone running 'make test' out of the box won't see it.
01:40 kid51 svn.perl.org/parrot/ is slooooow.
01:41 kid51 I had to kill (from my end) a long running 'svn diff'.  I hope that didn't cause problems on the server end.
01:41 DietCoke I can't imagine it would.
01:42 DietCoke summon robrt!
01:42 kid51 purl seen robrt?
01:42 purl robrt was last seen on #perl 22 hours, 58 minutes and 20 seconds ago, saying: bed is for the weak
01:43 davidfetter joined #parrot
01:57 Schwern joined #parrot
01:58 Whiteknight seen purl?
01:58 purl purl was last seen on #poot 31 days, 10 hours, 54 minutes and 19 seconds ago, saying: _Fud was last seen on #poot 2 days and 22 minutes ago, saying: heyo  [Jun 25 07:42:25 2008]  [Jun 27 15:03:59 2008]
01:58 Whiteknight viva la recursion!
02:03 Auzon seen purl?
02:03 purl purl was last seen on #poot 31 days, 10 hours, 59 minutes and 8 seconds ago, saying: _Fud was last seen on #poot 2 days and 22 minutes ago, saying: heyo  [Jun 25 07:42:25 2008]  [Jun 27 15:03:59 2008]
02:04 Tene seen purl_?
02:04 purl purl_ was last seen on #poe 1 years, 192 days, 3 hours, 37 minutes and 33 seconds ago, saying: hides behind purl  [Jan 18 22:27:16 2007]
02:11 * kid51 must  sleep
02:11 purl $kid51->sleep(8 * 3600);
02:53 Andy joined #parrot
03:02 cotto joined #parrot
03:27 rhr joined #parrot
03:37 dalek r29835 | coke++ | trunk:
03:37 dalek : [tcl] make 'get_list' METHOD more universal on the Tcl PMCs.
03:37 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29835
03:38 dalek r29836 | coke++ | trunk:
03:38 dalek : [tcl] TODO more spec tests
03:38 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29836
03:40 verve joined #parrot
04:06 dalek r29837 | coke++ | trunk:
04:06 dalek : [tcl] Have our special constant class inherit from our string PMC.
04:06 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29837
04:41 rurban_ joined #parrot
05:32 Tene joined #parrot
05:32 Psyche^ joined #parrot
06:23 TiMBuS joined #parrot
06:28 uniejo joined #parrot
06:54 dalek r29838 | cotto++ | trunk:
06:54 dalek : [pdd] typo fix
06:54 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29838
06:55 iblechbot joined #parrot
06:59 tuxdna joined #parrot
07:40 barney joined #parrot
07:43 masak joined #parrot
08:01 leo joined #parrot
08:26 dalek r29839 | bernhard++ | trunk:
08:26 dalek : [codingstd] Fix POD.
08:26 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29839
09:12 donaldh joined #parrot
09:16 jonathan morning all
09:16 purl afternoon, jonathan
09:16 jonathan Rakudo day! :-)
09:17 moritz YaY
09:18 jonathan Just gotta re-bandage my leg, then I'll get down to work. :-)
09:18 moritz rakudo approaches the 2000 passing test mark
09:18 Casan morning jonathan, keep fighting there.
09:19 moritz and with working IO we might hit the 2000 today if Auzon++ manages to get the regex tests running ;)
09:19 donaldh oooh, working IO
09:20 masak jonathan++ # rakudo day!
09:27 jonathan (hitting 2000)++
09:49 Ademan joined #parrot
10:02 kj joined #parrot
10:07 jonathan Hmm. Fixing IO iterator is trickier than it first appears. :-|
10:07 moritz jonathan: it would already help to have $handle.eof working
10:08 jonathan moritz: That can be done. It's not that I can't make for =$fh { ... } work, it's that I can't do it without breaking one other spec-test.
10:23 jonathan moritz: my $fh = open "README"; while !$fh.eof { say =$fh }; $fh.close(); # now works
10:24 jonathan If the changes for that haven't broken any tests (shouldn't have), I'll ci.
10:24 moritz jonathan++
10:25 jonathan moritz: I'm thinking if you have two file handles $fh1 and $fh2, you should be able to write things like for =$fh1, =$fh2 -> $x { say $x }
10:25 jonathan To iterate through both of them.
10:25 jonathan Does that fit with your understanding?
10:26 moritz yes
10:26 moritz =$fh2 returns a lazy list in list context
10:27 moritz so you're just iterating over lists
10:27 jonathan Yeah
10:27 jonathan We don't really have lazy lists at the moment, though.
10:27 moritz the iterator cludge is just a premature optimization in the absence of lazy lists
10:28 jonathan The other thing is that, at the moment, for =$fh { } doesn't actually put the iterator prefix:= returns into list context, but instead calls 'list'(...) to make the list.
10:28 jonathan However, we can't change that to actually call .list to do list context
10:28 jonathan Because then for [1,2,3] { } does the wrong thing.
10:31 jonathan Essentially, we need our own iterator, I think, that iterates any iterators contained immediately in the list we're iterating over.
10:31 jonathan But in some senses, I guess that'd make for a big chunk of lazy lists. :-)
10:35 moritz why not just let =$fh return a list of all items, and do the optimizations once we have lazy lists?
10:35 jonathan The problem is that =$fh is context sensitive
10:35 moritz and we have no contexts yet
10:35 jonathan If I make it return a list of all items, then I break =$fh
10:35 jonathan We do.
10:36 dalek r29840 | jonathan++ | trunk:
10:36 dalek : [rakudo] Implement .eof on file handles, and make IOIterator do something closer to the write thing in item/string contexts.
10:36 moritz do we? can a sub determine its context? how?
10:36 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29840
10:37 jonathan OK, we don't have *this* piece, but we do have .item, .list and .hash.
10:38 jonathan And $(...), @(...)...
10:38 moritz but as long as a sub can't determine its context it feels a bit like fake ;-)
10:41 Whiteknight joined #parrot
10:56 lurker joined #parrot
11:01 nopaste "moritz" at 89.13.199.231 pasted "IO.eof - wtf?" (19 lines) at http://nopaste.snit.ch/13684
11:02 moritz jonathan: is that "works as designed"?
11:03 jonathan moritz: Works as Parrot is designed, perhaps... ;-)
11:04 jonathan I'd have expected it to not have the final line either.
11:08 dalek r29841 | jonathan++ | trunk:
11:08 dalek : [rakudo] Make self work in nested lexical scopes in a method.
11:08 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29841
11:20 ruoso joined #parrot
11:41 timbunce joined #parrot
11:50 jonathan OK, time for me to have some lunch, and then I have Slovak class, then I'm back for the rest of the day/evening hacking on Rakudo.
12:06 pancake joined #parrot
12:06 pancake io
12:10 pancake i have generated a callgrind graph of parrot running a perl6 hello world
12:11 pancake this can maybe help to find the bottlenecks
12:13 pancake http://news.nopcode.org/callgrind.out.7299.gz
12:13 pancake gunzip + kcachegrind <file>
12:15 moritz pancake: ERROR 403: Forbidden.
12:15 pancake ^R
12:17 moritz works now
12:24 donaldh_ joined #parrot
12:41 rurban_ joined #parrot
12:46 dalek r29842 | coke++ | trunk:
12:46 dalek : [tcl] revert patch, use 'String' as our object's base class once more to avoid problems. Leave a note.
12:46 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29842
12:47 dalek r29843 | coke++ | trunk:
12:47 dalek : [tcl] use our list PMC preferentially, even internally.
12:47 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29843
13:09 gryphon__ joined #parrot
13:14 dalek r29844 | coke++ | trunk:
13:14 dalek : [tcl] Convert internal usage of String, Integer to tcl PMC variants.
13:14 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29844
13:33 paco joined #parrot
13:58 * jonathan returns
13:59 jonathan pmichaud: Awake/around yet?
14:10 iblechbot joined #parrot
14:13 masak are heredocs in STD.pm?
14:15 moritz masak: yes, think so
14:15 masak ok
14:15 moritz token ws { ... | <.vws> <.heredoc> }
14:16 masak the need for them in rakudo isn't pressing (since multiline strings work fine) but would be a nice addition
14:16 masak so heredocs are parsed as whitespace?
14:16 moritz I think it's best to wait for the Big Grammar Refactor
14:20 Andy joined #parrot
14:32 gmansi joined #parrot
14:39 masak moritz: so, tell me more about this Big Grammar Refactor? :)
14:39 masak does it hurt?
14:40 moritz yes ;-)
14:40 moritz masak: the following is 80% speculation...
14:41 moritz masak: TimToady refactored STD.pm to handle DSLs by copying the grammar, and modifying the copy
14:41 moritz masak: and since rakudo's grammar follows STD, it might do the same thing
14:41 masak aha
14:41 moritz masak: also, STD.pm is based on proto regexes, rakudo on simple alternation
14:42 moritz pmichaud already announce that he *will* change that
14:42 masak I've heard the term "proto regexes" before, but I don't know what they are
14:42 gmansi joined #parrot
14:42 moritz it's a bunch of regexes with the same name, but parameterized by a symbol
14:42 moritz and they match as an alternation
14:43 moritz so multi foo:sym<a> { <sym> }; multi foo:sym<b> { <sym> }; makes '<foo>' match a|b
14:44 moritz with the small difference that you can add alternatives simply by subclassing, and adding more methods /tokens / whatever
14:44 dalek r29845 | jonathan++ | trunk:
14:44 dalek : [rakudo] Implement get_bool vtable method in Object, such that it tests definedness. This means things like 'ok Foo.new' used in some spectests can work.
14:44 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29845
14:44 moritz s/multi/multi token/ actually
14:45 moritz and it means that you can modify a symbol without altering the parse tree, for example you can say multi:sym<a> { 'c' } # it looks the same in the parse tree, because foo:sym<a> matched, but it actually matched c and not a
14:53 pmichaud pong
14:54 jonathan pmichaud: hi! :-)
14:55 jonathan pmichaud: I'm ready to discuss/work on refactoring variable declaration or type registry, if you're free to discuss that first.
14:56 particle 76/142
14:56 purl 0.535211267605634
14:56 jonathan pmichaud: Also, got a couple of smaller questions/issues.
14:56 particle wow. parallel branch runs configure tests in half the time
14:56 jonathan particle: On Win32?
14:56 particle ayep
14:57 jonathan Nice!
14:57 donaldh schweet.
14:57 particle i'm formulating a mail for the list
14:57 pmichaud smaller questions/issues might be better first
14:57 jonathan OK
14:58 jonathan First, just trying to get some of the delegation tests (for handles) to pass. Already handles is implemented, so we can cover some of the cases, but running into a couple of other things the test exercises.
14:58 jonathan The first one is that if you do "ok !try{ something that dies }", if what's in try dies then you get a null PMC exception.
14:59 jonathan Because the block never returns a value.
14:59 jonathan I'm not seeing an especially neat way to deal with this.
15:00 cjfields joined #parrot
15:03 pmichaud try needs refactoring anyway
15:04 pmichaud I'm kinda waiting for the new exceptions stuff before going too far with that.  But we might be able to fix it earlier.
15:04 pmichaud but actually { something that dies }  should probably return a Failure object
15:04 jonathan Well, it never gets chance, is the real issue.
15:04 pmichaud -or-
15:04 jhorwitz joined #parrot
15:04 pmichaud try should detect that it didn't get something back from the block, and generate a failure object
15:05 nopaste "donaldh" at 144.254.89.228 pasted "patch for t/doc/pod.t on Cygwin" (23 lines) at http://nopaste.snit.ch/13689
15:06 donaldh Does anyone want to give ^ a try on another platform?
15:07 jonathan pmichaud: I'm trying the second of those...and failing to find the correct incantation. :-Z
15:07 donaldh The test was complaining on Cygwin because -e pbc_to_exe returns true when pbc_to_exe.exe exists
15:08 pmichaud jonathan: where does the null PMC arise, exactly?  The argument to prefix:! ?
15:08 jonathan Yes
15:08 jonathan Ah
15:08 Infinoid donaldh: trying on linux/amd64
15:08 pmichaud well, if an exception occurs, then we know we get into the catch portion of the 'try' PAST node
15:08 donaldh Infinoid++
15:09 * moritz tries on linux/i368 (32 bit)
15:09 pmichaud try should then wrap the exception into a Failure object and return it.
15:09 moritz but the byte lenght shouldn'T make a difference
15:09 jonathan Yes, but assigning something back to the register that the result of the block woulda been assigned to, is the tricky bit.
15:10 pmichaud ....?
15:10 purl dot dot dot *yawn* dot
15:10 pmichaud you lost me there
15:10 donaldh Infinoid: I have simplified the test to use -T instead of -e & -B & an additional check for $file . $PConfig{exe}
15:10 jonathan $P23 = "_block16"()
15:10 jonathan We have no way, that I can see, to refer to $P23 inside the catch PIR.
15:11 Infinoid donaldh: doesn't seem to break the test here
15:11 pmichaud oh, I think you're just saying that PAST's 'try' block needs better return value handling
15:11 Infinoid passes without the patch, passes with the patch.
15:11 pmichaud which is entirely possible.
15:11 jonathan That would probably be the easiest solution.
15:11 donaldh Infinoid: I'd expect that ;-)
15:11 moritz donaldh: second test fails with 568 files without DESCRIPTION - is that intended?
15:11 donaldh Always did I think.
15:11 pmichaud I wasn't dealing with try blocks as rvalues when I wrote the original 'try' code, I don't think.
15:11 jonathan Aha, OK.
15:12 donaldh I'm not really up for posting a patch to 568 files ;-)
15:12 pmichaud but the entire fail/try/exception system needs a bit of a rework
15:12 moritz uhm, why not? ;-)
15:12 donaldh s/posting/pasting/
15:12 jonathan Would you rather we just leave this until the re-work post-pdd25cx?
15:12 Infinoid if you can't paste, post :)
15:12 pmichaud I might be able to get that later today
15:12 jonathan OK.
15:12 pmichaud it's not a hard fix
15:12 moritz donaldh: ah, it's marked as TODO, I haven't seen that
15:13 donaldh phew.
15:13 jonathan OK, sounds good.
15:13 jonathan I also tried to get file I/O in better shape. When various refactors were done, for =$fh { ... } got broken.
15:13 jonathan Notably, because for now calls list(...)
15:14 jonathan Which is probably right, but doesn't play out too well, since we get a list with one element, which is an iterator.
15:14 cjfields how far off are lazy lists?
15:14 jonathan I tried switching it to call .list, so we get a value there in list context. Then the IO iterator could just return itself in .list.
15:15 pmichaud no, .list would be wrong.
15:15 jonathan But then for [1,2,3] { } fails.
15:15 jonathan Yes.
15:15 jonathan I found that out. :-)
15:15 pmichaud short-term fix would be to update flatten to recognize IOIterator, the way it currently does Ranges (which are also lazy)
15:15 jonathan Would that not mean we flatten the entire iterator?
15:15 jonathan (Works for reading from files, not so well from $*IN)
15:16 jonathan (flatten the entire iterator = read from it...)
15:16 jonathan (read everything from it)
15:16 pmichaud checking.
15:16 pmichaud no.
15:16 pmichaud Currently the flatten code calls .list on Range objects
15:17 pmichaud I don't think it actually flattens the Range object.  (The .list method on Range might do that, but the flatten code doesn't do it)
15:17 pmichaud so, if flatten encountered an IOIterator, then it would call .list on it
15:17 jonathan The .list method on Range does.
15:17 moritz we just need freakin' lazy lists for it, and we need the pdd25cx branch for that
15:17 jonathan (does flatten it)
15:18 jonathan So we'd boil down to the same thing - it'd work for files (though we'd end up reading the lot before we started looping), but would hang for $*IN.
15:18 jonathan OTOH, it doesn't work at all at the moment...
15:18 particle PLEASE TEST THE PDD25CX BRANCH. submit results to the ticket allison posted.
15:18 pmichaud ..."hang for $*IN"
15:18 pmichaud ?
15:18 jonathan pmichaud: for =$*IN { .say }
15:18 particle also test hlls with that branch. it'll help it get merged faster.
15:19 pmichaud oh, I see.  okay.
15:19 dalek r29846 | infinoid++ | trunk:
15:19 dalek : [t] Apply patch from donaldh++ to fix a test on cygwin.
15:19 dalek : (-e pbc_to_exe is true for pbc_to_exe.exe on cygwin, which confuses the test)
15:19 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29846
15:19 jonathan If you are calling .list, this will try and get all values from the iterator...but it never gets to eof.
15:20 jonathan The other thing that occured to me, is we could just implement our own iterator, which I guess we'll need to do anyway as part of the lazy lists work, that can iterate over an iterators it immediately finds occuring in the list.
15:20 moritz donaldh++
15:20 jonathan s/an/any/
15:20 pmichaud jonathan: I think that's just a lazy list.  :-)
15:20 donaldh What's on the pdd25cx branch?
15:21 jonathan pmichaud: Yeah, we'd have done a good part of lazy lists by then, I guess. ;-)
15:21 pmichaud does lazy lists require pdd25cx ?
15:21 jonathan Though of course, not for indexing into them.
15:21 jonathan I didn't know of any lazy list dependency on pdd25cx.
15:21 pmichaud me either.
15:21 jonathan gather/take may require pdd25cx
15:21 moritz donaldh: reworked dependency branch
15:21 pmichaud yes, gather/take requires pdd25cx
15:21 jonathan But lazy lists more generally don't.
15:22 jonathan Hmm. I'm tempted to JFII.
15:22 pmichaud so lazy implementations of some functions will require gather/take
15:22 moritz then I was wrong - if I had to implement lazy lists, I'd do most if it with gather /take
15:22 jonathan OK, but to get file handles and ranges lazy on iteration, is a smaller and easier step.
15:23 jonathan Well, ranges needn't change for now - file handles are what really needs this.
15:24 dalek r29847 | moritz++ | trunk:
15:24 dalek : [rakudo] add more IO tests to spectest_regression
15:24 dalek : most of them are TODO right now
15:24 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29847
15:24 jonathan Ooh, moritz++
15:25 jonathan moritz:  S16-io/basic-open.
15:25 jonathan Missing a t?
15:25 moritz jonathan: yes, will fix
15:27 dalek r29848 | moritz++ | trunk:
15:27 dalek : [rakudo] fixed typo in spectest_regression.data, moritz--, jonathan++
15:27 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29848
15:30 pmichaud I'm thinking about how lazy lists will end up working with ResizablePMCArray
15:30 jonathan In the sense of, is it an "isa" or a "has a"?
15:31 pmichaud in the sense of -- how do we make sure everything works correctly when Parrot hands us an RPA instead of a List
15:31 pmichaud (e.g., :slurpy)
15:32 jonathan Could we have a case where that happens and we have an iterator in the list that we should be iterating?
15:32 particle pmichaud: how is that lazy?
15:32 particle RPAs aren't lazy, i mean
15:32 jonathan If not, get_iter on ResizablePMCArray can just return its iterator, we iterate it, and it works out, I think.
15:32 pmichaud particle:  RPAs aren't lazy, correct.  That's why it's a problem.
15:33 pmichaud if we get an RPA with lazy elements, we can't just return those elements
15:33 jonathan True - will that conceivably happen?
15:33 particle oh, yeah, you'll probably have to override get_iter
15:33 pmichaud jonathan: sure, anytime we use :slurpy
15:34 particle mixin a role for that
15:35 jonathan Ah, like we get something like sub foo (*@foo) { ... }; foo(1..10, 20..Inf)
15:35 pmichaud I've been wanting to get .HLL type mapping working, so that Parrot would at least give us a List instead of an PRA
15:35 pmichaud *RPA
15:36 jonathan Yes, but that's blocking on various things, IIRC.
15:36 pmichaud other possibility might be to generate code to recast all slurpy params into Lists explicitly.  But I'm not sure that will be very robust -- quite a few might slip through the cracks.
15:36 pmichaud oh, it might work out if we just implement a separate .list and/or .iterator method for RPA
15:36 pmichaud that returns what we want.
15:37 jonathan .sub 'iterator' :vtable('get_iter')
15:37 jonathan That'd probably work.
15:37 pmichaud we have to be *very* careful about trying to override get_iter in RPA
15:37 sjansen joined #parrot
15:37 pmichaud because we'd be doing that for all of Parrot, not just Rakudo.
15:38 jonathan Ah, yes. :-|
15:39 jonathan http://rt.perl.org/rt3/Tic​ket/Display.html?id=49812 only has http://rt.perl.org/rt3/Tic​ket/Display.html?id=56650 as a dependency.
15:39 pmichaud it's the same problem we have with overriding get_string in Object
15:39 jonathan Does that mean that the second of those is the only blocker to being able to use .HLL?
15:39 pmichaud no
15:39 pmichaud p6object still needs its refactor.
15:39 jonathan OK, but I meant Parrot guts issue.
15:40 pmichaud I'm not sure if HLL type mapping is working yet for :slurpy
15:40 pmichaud Coke had a ticket about that recently.
15:40 jonathan HLL map of :slurpy's ResizablePMCArrayresolved
15:40 jonathan It's marked resolved as of 13 days ago.
15:40 pmichaud ticket number?
15:41 jonathan 56958
15:41 pmichaud looks like there might
15:41 pmichaud be other issues with non-PMC classes, but that's a different test and a
15:41 pmichaud different RT.
15:41 pmichaud (quote from ticket)
15:42 jonathan Ugh.
15:42 jonathan If we can't use non-PMC classes in the HLL_map, it's a tad useless to us.
15:43 pmichaud so, we could at least use a test for that for now.  :-)
15:43 pmichaud just a sec, I'm distracted going over itinerary details for tomorrow's travels
15:44 jonathan ok
15:49 particle jonathan: we don't need to do much to get a semantic analysis phase in rakudo (re: 57336)
15:50 particle heck, we're doing some semantic analysis inside the parse->past code now
15:50 rdice joined #parrot
15:50 pmichaud parse->past is the semantic analysis, isn't it?  ;-)
15:50 particle hi ho richard!
15:51 particle how's life with baby?
15:52 jonathan I suspect it'd be useful, to have a second "CHECK" phase, rather than tyring to clump it all into one. :-)
15:52 particle yeah
15:53 particle very easy to do
15:53 moritz TGE for PAST-nodes?
15:53 particle we can use nqp
15:53 jonathan OK, great.
15:54 particle see perl6.pir:44
15:56 pmichaud wait, I'm confused.
15:56 pmichaud okay, I de-confused myself.
15:58 pmichaud I'm not convinced I like the second "CHECK" phase, though.
15:58 pmichaud but I haven't thought about it that much yet.
15:58 pmichaud but "second CHECK phase" sounds wrong to me.
15:58 particle i want a phase for tree-ssa, but that might be after past
15:58 pmichaud ...tree-ssa?
15:59 particle tree based static single assignment
15:59 particle gcc does it
15:59 pmichaud ...what is that?
15:59 particle their tree language is called 'gimple' i think
15:59 particle ssa tracks assignments of variables
16:00 particle it's an optimization strategy
16:00 particle lemme get you a link
16:00 pmichaud does it work in a dynamic language?
16:01 jonathan pmichaud: SSA is a form where you re-arrange code into a format where a variable/register is only ever assigned to once, which makes certain types of analysis (that can in turn lead to optimization) easier.
16:01 particle http://gcc.releasenotes.org/summit/2003/Tree%20SSA​%20-%20A%20New%20optimization%20infrastructure.pdf
16:01 particle yes, it's good for dynamic languages
16:01 jonathan That is, you don't actually emit the code like that, but you get a tree representing it in such a form so you can do such analysis.
16:01 pmichaud why does this sound premature to me?  ;-)
16:01 particle i want to add it as an optimization step to pct
16:02 pmichaud particle:  this week, this month, this year, ...?
16:02 particle before 1.0
16:02 particle it's not blocking on anything
16:02 particle it can happen anytime
16:02 pmichaud no, but spending tuits on it causes other things to block
16:02 particle so anybody with tuits can help, if they're not working on anything else
16:03 pmichaud if we have spare tuits around, then yes, great.  and yes, it belongs in pct.  And that can go in as a separate phase for pct, no problem.
16:03 pmichaud I thought you were referring to rakudo specifically.
16:03 particle no
16:03 * particle has his parrot hat on
16:04 jonathan pmichaud: Got a fix for 56650
16:04 jonathan Smoking it now to make sure, there's no collateral damage.
16:05 pmichaud okay, great.  We were going to fix it by fixing class creation.
16:05 jonathan (that is, don't get exicted yet)
16:05 jonathan I fixed it in init_pmc insdie the class PMC.
16:05 pmichaud the way that classes get stored in the name registry was messed up.
16:05 pmichaud it would include the HLL name as part of the class name
16:05 jonathan Yeah
16:06 jonathan I fixed that.
16:08 particle should it always include the hll name, including 'parrot' ?
16:09 pmichaud for now it should never include the hll name
16:09 pmichaud otherwise we have a lot of stuff to deprecate and repair
16:10 particle so how do you tell rakudo's Integer from parrot's Integer?
16:10 pmichaud there's not currently a way to do that.  That's a different bug
16:10 pmichaud (looking up ticket number)
16:11 particle maybe we should have a special marker to signify that namespace keys should be relative to current hll rather than root
16:11 pmichaud #43419
16:12 pmichaud I think that what is more likely to happen is
16:12 pmichaud (1) always use namespaces to refer to classes (no ambiguity)
16:12 pmichaud (2) use protoobject-based items, and make all HLL classes anonymous
16:13 pmichaud although #2 is problematic because it's hard to stick methods into an anonymous class
16:13 pmichaud so what we really end up doing is using mangled names for the HLL-specific classes
16:13 pmichaud such as Perl6Object, Perl6String, etc.
16:14 jonathan pmichaud: It passed all tests.
16:14 pmichaud but at least as PCT/rakudo are currently designed, the HLL never really sees a Parrot class name.
16:14 particle (sorry, phone)
16:14 pmichaud jonathan++
16:15 * jonathan finally does something successful today.
16:15 pmichaud yay!
16:16 jonathan So far I've failed to fix try and failed to fix for =$fh { ... }
16:16 jonathan Did implement .eof on file handles, though.
16:16 pmichaud well, let's at least make tickets for those that explain the blockers.
16:16 dalek r29849 | jonathan++ | trunk:
16:16 dalek : [core] Fix RT #56650 (class created from namespace fails MMD).
16:16 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29849
16:16 pmichaud or add the blocker information to the tickets.
16:16 pmichaud or make tickets for the blockers, and then link the tickets.
16:16 iblechbot joined #parrot
16:17 jonathan Do you want me to try and get some custom iterator set up for lists, to try and handle file handles better?
16:17 pmichaud I think I'd rather just implement lazy lists.
16:17 masak will 'multi' in a grammar mean 'multi regex' or something, eventually?
16:17 jonathan OK, I kinda saw doing that as a step towards lazy lists.
16:18 pmichaud I don't think lazy lists need custom iterators
16:18 jonathan They need some kind of iterator.
16:18 pmichaud a list can just clone itself.
16:18 jonathan OK, in that case the list just is the iterator.
16:19 pmichaud correct.
16:19 * jonathan senses this will be a big refactor.
16:19 pmichaud we might be able to do a specialized iterator as an optimization, but I see that coming later.
16:19 pmichaud I think it's not so bad, except for the RPA stuff
16:20 jonathan Now the MMD bug is fixed, how far do you think .HLL is?
16:20 pmichaud not far.  I'll have to re-try my p6object conversion
16:20 jonathan OK.
16:21 jonathan So best to wait on lazy lists until .HLL is done, and we're not getting RPAs?
16:22 pmichaud I think we'll still get RPAs, so .HLL probably shouldn't be a dependency.  Instead we need to figure out how to handle RPAs when we get them.
16:23 jonathan Hmm.
16:25 jonathan When we can't reply on an RPA being fully evaluated, that's really tricky.
16:25 jonathan *rely
16:27 pmichaud I think the answer is to convert RPAs to Lists when we find them, or at least keep track of when they occur
16:28 jonathan *nod*
16:28 jonathan I guess we can only see how well that will work out by giving it a go.
16:28 jonathan At least once .HLL is in place, we eliminate the primary source of RPAs (from :slurpy)
16:29 pmichaud the other source of RPAs will be arrays from matches
16:29 pmichaud although those probably won't be lazy for a while yet
16:30 pmichaud we need to update the roadmap, and make it a little more detailed
16:30 pmichaud and identify some of these dependencies
16:30 jonathan Yes, and probably break down some of the big items too.
16:31 jonathan * class, role, objects
16:31 jonathan * regex, token, rule, grammar
16:31 jonathan Those two are pretty wide-ranging. We have progress on all of them.
16:31 pmichaud a good thing to do would be to place most of the skip/todo items from spectest regression into the roadmap
16:32 pmichaud or, at least the major ones
16:33 jonathan As in, work out why they skip and list the features we need to get them to pass?
16:33 pmichaud well, most of the skips already have reasonable messages
16:33 pmichaud (and I've been changing them to reasonable messages when they're incorrect or imprecise)
16:33 pmichaud but yes, list the features we need to get them to pass.  Perhaps create tickets for them or for the features.
16:34 jonathan Hmm. Did we get rid of #pure?
16:34 pmichaud Schwern submitted a patch that eliminated #pure, yes.
16:34 pmichaud We couldn't find the reason for it.
16:35 moritz that slows down autounfudge a bit :/
16:35 jonathan There goes my easy way of looking through, in one file, which spectests have skips. ;-)
16:35 pmichaud schwern was arguing for rgrep
16:35 pmichaud instead of manually maintaining #pure
16:35 pmichaud even 'ack' ought to be able to do it.
16:36 pmichaud it's okay to create a tool and/or make target for that
16:37 pmichaud but a good first approximation is   ack '/\#\?rakudo/' t/spec
16:37 pmichaud or for just a list of files,   ack -l ...
16:38 pmichaud and, of course, the way I find skipped tests is to run  tools/test_summary.pl
16:39 jonathan That's rather useful. :-)
16:40 moritz but it takes quite some time
16:40 pmichaud jonathan: your fix to #56650 isn't the approach I was planning to take.
16:40 Andy joined #parrot
16:41 jonathan pmichaud: In a, "re-do it another way" kidna way?
16:41 pmichaud I'm just looking to see if I see any difficulties
16:41 jonathan OK
16:41 jonathan What were you planning?
16:42 pmichaud to fix lines 191-212
16:42 pmichaud which is where the bug _really_ is.
16:43 jonathan Hmm
16:43 jonathan That would work to, I think.
16:43 pmichaud the problem is when init_class_from_hash gets called with a namespace argumnent
16:43 jonathan Yes, I see...
16:48 jonathan OK, done, smoking
16:52 pmichaud #parrotsketch in 98?
16:54 jonathan 'twas a vintage year.
16:55 jonathan pmichaud: Working on making list of features used in spectests to go in the roadmap.
16:55 pmichaud excellent.
16:55 pmichaud I'm going to have to run errands in a bit.
16:55 jonathan OK
16:55 jonathan I noticed STD.pm has some type registry stuff in it.
16:55 pmichaud and there is so much background noise in the house at the moment that I'm having trouble concentrating :-(
16:55 pmichaud (housekeepers, two kids, wife, and dog)
16:56 jonathan I figure doing something very similar is a good approach.
16:56 jonathan Plenty of noise-emitters!
16:56 pmichaud STD.pm has type lookups, does it have anything else?
16:56 jonathan Two weeks until pre-YAPC hacking. We can find somewhere quiet for that.
16:56 jonathan It has a sub for putting stuff into the type registry
16:56 * particle is back
16:56 jonathan Which is called from a few places.
16:56 pmichaud I hadn't noticed that.  what sub?
16:57 jonathan add_type
16:57 particle i'm disappointed to see #pure go away without discussion that involved me
16:57 particle (or moritz)
16:57 jonathan Oh, actually it's a method.
16:57 jonathan Though it never touches the invocant, or any attributes, so it may as well have been a sub.
16:58 pmichaud particle:  it's an easy revert.
16:58 pmichaud I didn't feel like arguing the point much with schwern.
16:58 pmichaud especially since I wasn't sure why they were needed either
16:59 particle well, for example, to run a test as pure even though it has #?rakudo markers in it
17:00 pmichaud as part of spectest_regression?
17:00 particle sure, or localtest
17:01 pmichaud I can't imagine ever wanting to do that in spectest_regression
17:01 pmichaud afaik we didn't take out the capability to have #pure in localtest
17:01 particle ok, i haven't reviewed the patch, so i don't know the extent of the changes
17:01 particle or whether they're right or wrong
17:02 pmichaud the main point of the patch was to enable   "make t/spec/S29-num/foo.t"
17:02 pmichaud which runs a single test
17:02 pmichaud (fudging as needed)
17:02 particle what does that have to do with #pure?
17:03 pmichaud why do we need #pure in the first place?
17:03 particle the idea:
17:03 dalek r29850 | jonathan++ | trunk:
17:03 dalek : [rakudo] A different fix for the class created from namespace and MMD bug.
17:03 particle tests may optionally be marked as #fudge or #pure...
17:03 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29850
17:03 particle the default (for now) is #fudge...
17:04 pmichaud jonathan: all of the calls to add_sub are doing so on the cursor object, which would seem to be a different method from the add_sub that is in STD.pm
17:04 pmichaud jonathan: we might need to ask TimToady about that
17:04 particle but the user can override the behavior of fudge by specifying #fudge or #pure in the .data file.
17:04 pmichaud particle: how many times have we needed to override the behavior?
17:04 pmichaud (in spectest_regression.data)
17:05 pmichaud in localtest.data, I can understand it and fully support it, yes.
17:05 particle if it's in one data file, why not all?
17:05 jonathan pmichaud: You mean add_type?
17:05 particle i'd like to be very specific in spectest_regression. once they're all pure, we don't need fudge
17:05 pmichaud because in spectest_regression it means we're having to maintain a flag that can be automatically determined
17:06 pmichaud particle:  but isn't that "make spectest"?
17:06 particle we don't *need* no specify the flag in spectest_regression
17:06 pmichaud jonathan: yes, add_type
17:06 particle oh, wait. did the patch simply remove the flags from the data file?
17:06 pmichaud particle:  I don't know -- I didn't check that far.
17:07 pmichaud I know it at least removed the flags from the data file.  I don't know that it removed the flag handling code.
17:07 pmichaud I don't mind if the flag handling code returns, if that's the case -- as long as we don't break the other testing changes.
17:08 pmichaud easier still might be to not use flags at all
17:08 particle fudge is a preprocessor. i don't trust it.
17:08 particle i want the ability to override
17:09 pmichaud I don't think we need the ability to override in spectest_regression
17:09 particle fine with me
17:09 pmichaud especially if "fudge" is the default
17:09 pmichaud in localtest.data, I think overriding makes sense
17:09 particle well, that can be easily changed
17:09 particle (fudge as default)
17:10 pmichaud I don't think we'll ever switch spectest_regression from having fudge as its default
17:10 pmichaud if the list of files were known and static, perhaps we might do that, but since we're constantly adding (fudged) test files to _regression, we'll likely keep fudge as the default
17:11 pmichaud eventually we'll get to the point that either (1) we're no longer adding files to spectest_regression, in which case it's just 'spectest', or (2) we're running things unfudged, in which case it's just 'spectest'.
17:12 particle depends on the percentage of files that run pure in spectest_regression, i think
17:13 particle if more run pure, that should be default
17:14 cjfields_ joined #parrot
17:15 pmichaud but fudge already leaves files as 'pure' if there isn't any fudging taking place
17:16 moritz I liked the pure marking, but I can live without them
17:16 particle if there aren't any '#?rakudo' markers, it leaves it as pure, yes
17:16 particle no matter.
17:17 particle spectest_regression can live without the markers.
17:17 DietCoke joined #parrot
17:17 moritz then we might just as well delete tools/fudge_purity_inspector.pl
17:18 particle unless we use it for other localtest
17:18 cjfields joined #parrot
17:18 particle s/other//
17:18 pmichaud we could certainly modify test_summary.pl to report the fudged/pure tests
17:18 particle svn diff -c 29782
17:19 particle it does remove #fudge/pure mark detection entirely
17:20 pmichaud feel free to add it back in... but I do like schwern's overall option handling better
17:21 pmichaud the decision to have global fudge/pure should come from the --fudge option
17:21 pmichaud if --fudge, then default all tests to being fudged
17:21 pmichaud if no --fudge, then default all tests to being pure
17:22 particle there's no way to run a single test without fudge, as schwern has it
17:23 moritz ../../parrot perl6.pbc path/to/test.t # ;-/
17:23 pmichaud as I said, feel free to add #pure option back in.  I just don't think we need to maintain the markers in spectest_regression
17:23 pmichaud and I'd like to avoid adding more options to t/harness
17:26 pmichaud my suggestion would be to refactor the lines
17:26 pmichaud if ($do_fudge) { @tfiles = fudge(@tfiles);
17:26 pmichaud }
17:31 chromatic joined #parrot
17:31 jonathan pmichaud: I'm thinking this test is not right:
17:31 jonathan my $h;
17:31 jonathan sub some_sub_2 ($arg) { $h = $h ~ $arg; };
17:31 jonathan for (0 .. 5) { .some_sub_2 };
17:31 jonathan (we never fall back to a sub any more?)
17:32 pmichaud correct, method fallback to sub is gone
17:32 pmichaud (per TimToady at OSCON)
17:32 particle yep
17:32 pmichaud actually, it was pre-OSCON, because I even committed a Synopsis patch to eliminate it.
17:32 jonathan OK
17:32 jonathan Will eliminate the test.
17:32 pmichaud there are a lot of those.
17:34 pmichaud okay, lunchtime for me.
17:34 pmichaud bb in 56 for #ps
17:34 jonathan kk
17:36 Tene ocrap #ps.
17:37 Tene QUICK I NEED SOME COMMITS
17:37 Tene svn rm languages/tcl
17:37 moritz lol
17:37 cotto you can misspell something and then fix it
17:37 cotto that'd give you two
17:37 moritz it would "solve" some of the pdd25cx problems (svn rm languages/tcl)
17:40 * DietCoke_afk wonder why everyone always hates on tcl.
17:40 chromatic It was a slow Lisp with weirder syntax for a long time.
17:41 DietCoke ... fine, "partcl"
17:42 Tene DietCoke: I wasn't picking on tcl, I was picking on you.
17:42 DietCoke as penance, where's my patch?
17:43 Tene Um... hey, look, cardinal has a failing test!
17:43 Tene I should go fix that!
17:43 * particle thinks tene owes dietcoke a dinner
17:44 Tene Well, I will be in NYC in a couple of weeks.
17:46 * Infinoid gives DietCoke a free patch
17:47 dalek r29851 | infinoid++ | trunk:
17:47 dalek : [tcl] Fix trailing whitespace.
17:47 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29851
17:50 DietCoke NYC is a bit of a haul for dinner. =-)
17:50 dalek r29852 | tene++ | trunk:
17:50 dalek : [cardinal]
17:50 dalek : * Track a change in P6Object for calling methods on the metaclass.
17:50 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29852
17:51 Tene DietCoke: but it would be *free* dinner!
17:54 DietCoke You probably don't have anything I can eat. :|
17:54 DietCoke Infinoid++
17:57 DietCoke purl, 236.5-205
17:57 purl 31.5
17:57 DietCoke purl, 31.5/77
17:57 purl 0.409090909090909
17:58 moritz pmichaud, jonathan, particle: anybody motivated to review RT #56700 ?
18:01 Tene We really need to persuade one of the bots to provide links for ticket numbers.
18:02 Infinoid I could write a dalek script for that
18:02 DietCoke someone did that and it was booted as being too spammy, as I recall.
18:02 jonathan moritz: I think that one has been discussed some, and some PCT changes for namespaces are forthcoming to make this possible.
18:02 DietCoke (perhaps because it failed spammily)
18:02 Infinoid was that Whiteknight's bot?
18:02 moritz jonathan: ok, thanks
18:02 cotto I thought it was booted for being too spammy for other output
18:03 moritz another one I'm looking at: RT #57068
18:03 moritz it seems to duplicate effort, and use '!EXPORT' instead
18:04 nopaste "Infinoid" at 96.238.213.50 pasted "[PATCH] silence some "switch missing default case" warnings" (88 lines) at http://nopaste.snit.ch/13690
18:04 Infinoid DietCoke: any objection to that nopaste?  I doubt it adds any value, but it silences some warnings.
18:04 particle the ticket links exist on the irc log moritz runs, right moritz?
18:05 moritz particle: yes
18:05 jonathan moritz: I'm not sure export quite cuts it here, because we want a version that doesn't take a file handle.
18:05 jonathan But it should probably just look up $*IN and invoke the printf method on that.
18:06 Infinoid DietCoke: hmm, and causes some test failures.  Guess you're relying on silent passthrough for those switch statements
18:10 DietCoke Infinoid: where are the failures, t/cmd_binary ?
18:10 Infinoid lots of places.  far more failures than there were without the patch
18:10 moritz jonathan: should I just commit the method form, and ask for a re-worked form of the function?
18:10 * Infinoid is making a gentler version of the patch :)
18:10 dalek r29853 | jonathan++ | trunk:
18:10 dalek : [rakudo] Updates to the ROADMAP, including a list of many smaller tasks that are needed to allow us to skip less tests in spectest_regression.
18:11 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29853
18:11 DietCoke ah, many places. (gentler) hokay.
18:11 jonathan moritz: Yes, or just write it to do get_hll_global '$OUT' and call .printf on the return value.
18:11 jonathan moritz: Should be less characters to type to change that, than to type them asking for a new patch. ;-)
18:11 DietCoke anyone looking to play with PCT, a tcl conversion would not be unwelcome. =-)
18:12 DietCoke (well, a patch. I don't want to lose .HLL yet.)
18:12 DietCoke bah. nevermind. if you're bored, check the the TODO file. ^_-
18:13 Infinoid there are a few failing tests here in partcl, even without my patches.  are those known failures?
18:13 Infinoid or is everything expected to work?
18:14 DietCoke everything is expected to work.
18:14 DietCoke What's failing for you?
18:15 dalek r29854 | coke++ | trunk:
18:15 dalek : [tcl] use more truth.
18:15 Infinoid I'll paste that in a moment
18:15 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29854
18:15 nopaste "Infinoid" at 96.238.213.50 pasted "[PATCH] silence some "switch missing default case" warnings (gentle version)" (82 lines) at http://nopaste.snit.ch/13691
18:16 moritz jonathan: has method fallback been oficially removed yet?
18:16 nopaste "Infinoid" at 96.238.213.50 pasted "partcl test results (3 failed scripts)" (103 lines) at http://nopaste.snit.ch/13692
18:18 DietCoke ok. note that the lsort failure is a non-failure.
18:18 DietCoke the other two, looks like runtime/builtins/join is not compiling for some reason.
18:18 Infinoid I am doing a fresh build after svn update
18:19 jonathan moritz: Yes.
18:19 jonathan 19:32 <@pmichaud> correct, method fallback to sub is gone
18:19 jonathan 19:32 <@pmichaud> (per TimToady at OSCON)
18:19 DietCoke Ah. I think I see the problem, and it would depend on a hash ordering, so I can see why it hasn't hit me. moment.
18:19 moritz so not in the specs yet :/
18:20 jonathan 19:32 <@pmichaud> actually, it was pre-OSCON, because I even committed a Synopsis patch to eliminate it.
18:20 jonathan So if there is any remaining references in the synopses, they should be reported.
18:21 moritz jonathan: I get a test failure in S02-builtin_data_types/range :(
18:22 DietCoke Infinoid: try now.
18:23 dalek r29855 | coke++ | trunk:
18:23 dalek : [tcl] add in missing namespace/HLL directives ; depending on how runtime/builtins.pir gets generated, these could have broken the runtime. (infinoid++)
18:23 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29855
18:23 dalek r29856 | coke++ | trunk:
18:23 dalek : [tcl] don't bother saving the return value if we're never going to look at it.
18:23 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29856
18:24 moritz I commited it wihtout change because the duplicate code isn'T really much
18:25 dalek r29857 | moritz++ | trunk:
18:25 dalek : [rakudo] implement sprintf. Patch courtesy of Carl M�sak <cmasak at gmail.com>
18:25 dalek : masak++
18:25 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29857
18:26 jonathan moritz: Oh? That's odd...
18:27 jonathan C:\Consulting\parrot\trunk\languages\perl6>perl t\harness t\spec\S02-builtin_dat
18:27 jonathan a_types\range.rakudo
18:27 jonathan t\spec\S02-builtin_data_types\range....ok
18:27 chromatic #ps in 3
18:27 moritz t/spec/S02-builtin_data_types/range..​....................Missing '}' at line 168, near ""
18:27 moritz current instr.: 'parrot;PGE::Util;die' pc 120 (runtime/parrot/library/PGE/Util.pir:82)
18:27 jonathan Hmm
18:28 moritz let me try again
18:28 particle moritz: perhaps remove t/spec and regen?
18:28 Infinoid DietCoke: looks like cmd_join.t worked, waiting for the rest of it...
18:28 jonathan moritz: Even doing a clean run of spectest_regression, t\spec\S02-builtin_data_types\range...............ok
18:29 moritz now cleaning and trying again
18:29 jonathan And no local patches.
18:29 moritz perhaps it was a local fuckup
18:29 jonathan OMFG SWEARING
18:29 jonathan ;-)
18:29 pmichaud back
18:30 jonathan pmichaud: Checked in a bunch of stuff to ROADMAP.
18:30 Tene OY?G
18:30 Infinoid DietCoke: all passed, except for the cmd_lsort continuation weirdness.
18:30 DietCoke ok. that is expected.
18:30 chromatic #ps time
18:30 DietCoke (and sadly, not fixed by pdd25cx)
18:30 pmichaud #56700:  the patch doesn't really follow STD.pm
18:30 Infinoid assuming they don't break anything, any objection to the (gentler) default cases patch?
18:31 DietCoke Infinoid: no, removing warnings good.
18:31 Infinoid great, retesting now.
18:31 pmichaud I thought we already had sprintf in Rakudo?
18:32 pmichaud (r29857)
18:33 paco seems that make spectest_regression stopped to work (at least for me)
18:33 paco En la revisión 21616.
18:33 paco /usr/bin/perl t/harness --fudge --keep-exit-code --tests-from-file=t/spectest_regression.data <--- sleeps here ..
18:35 dalek r29858 | infinoid++ | trunk:
18:35 dalek : [tcl] Fix some "switch missing default case" warnings.
18:35 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29858
18:36 chromatic "enlightening conversation" means "why version numbers are stupid"
18:36 moritz lol
18:37 cjfields_ joined #parrot
18:38 * DietCoke sees that particle has already taken over.
18:38 * DietCoke wanders away, then.
18:40 paco NotFound: #ps
18:42 purl joined #parrot
18:44 cotto paco: #parrotsketch
18:48 Ivatar joined #parrot
18:49 confound joined #parrot
18:52 purl joined #parrot
18:53 cotto patch monster?
18:59 Infinoid reviewer and committer of other people's patches
19:04 pmichaud I think that #44471 can be rejected.
19:07 DietCoke I think the only reason to use :anon with a :vtable was so you could also use :method, neh?
19:07 DietCoke (and now that you don't need to do that, I don't see a point to :vtable :anon)
19:07 chromatic Right.
19:07 pmichaud I think the original post was expecting to use the sub name
19:08 pmichaud with the changes discussed on saturday, though, it'll be a non issue
19:08 pmichaud (because :vtable implies :anon)
19:08 DietCoke ... there were changes discussed ?
19:08 pmichaud yes.
19:08 particle they'll be in allison's coming commit of pdd19
19:08 pmichaud I thought it was already committed
19:08 pmichaud I know I reviewed something.
19:09 pmichaud maybe it was just a m/l message
19:09 * DietCoke makes a snarky comment about discussion on list. =-)
19:09 DietCoke more likely a private mail message. last things I have from allison are yapc:eu 2008 yesterday, and then hackathaon space on 7/26
19:13 pmichaud RT #53302
19:14 * jonathan afk for 15 mins or so - dinner
19:16 pmichaud anyway, I suspect the current way to create an anonymous vtable entry is     .sub "" :anon :vtable('get_integer')
19:16 pmichaud shall I just stick these comments as replies to the tickets?
19:16 pmichaud I guess I'll do that.
19:17 pmichaud to avoid snarky comments about discussion on list.  =-)
19:22 moritz usr/bin/perl t/harness --fudge --keep-exit-code --tests-from-file=t/spectest_regression.data # this line hangs for me from time to time
19:22 moritz it seems to expect input from STDIN
19:22 pmichaud as in "stops running?"
19:22 pmichaud it doesn't process any tests?
19:23 moritz as in "last output that I see untild I press Ctrl+D"
19:23 pmichaud this is from the 'make spectest_regression' target?
19:23 moritz yes
19:23 pmichaud but it happens only sometimes?
19:23 pmichaud odd.
19:24 moritz it happens the first time after a clean checkout or other serious changes
19:24 moritz when I hit Ctrl+D once, it runs fine on the next invocation
19:25 pmichaud sounds like it's missing a file or directory or something
19:26 moritz yes, but they all exist
19:27 moritz try 'rm t/spec/S02-builtin_data_types/range.rakudo; make spectest_regression' - does that work for you?
19:28 pmichaud I'm not at a point where I can easily test :-(
19:28 moritz :/
19:28 pmichaud I can get there in about 15 mins though
19:29 moritz I'll test a few more things here locally
19:30 jonathan moritz: Trying deleting that file, and giving it another run
19:31 jonathan Will let you know what I see
19:31 moritz when I delete the line with S02-builtin_data_types/range.t
19:31 moritz from spectest_regression.data all works fine
19:31 moritz when I don't, and rm -rf t/spec && make spectest_regression it hangs
19:32 moritz maybe fudge tries to read from <> somewhere?
19:34 jonathan t\spec\S02-builtin_data_types\range...............ok 22/79 skipped: various reasons
19:34 jonathan Hmm
19:34 jonathan I need to grab something quickly from the supermarket before it closes - back soon...
19:36 dalek r29859 | allison++ | trunk:
19:36 dalek : [pdd] Architectural review of PIR PDD.
19:36 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29859
19:41 DietCoke someone please open a ticket for this new deprecation note:
19:41 DietCoke {{DEPRECATION NOTE: PIR will no longer support the old PASM-style syntax
19:41 DietCoke for registers without dollar signs: C<In>, C<Sn>, C<Nn>, C<Pn>.}}
19:41 DietCoke (and add the ticket # back into the PDD)
19:42 dalek r29860 | allison++ | trunk:
19:42 dalek : [pdd] Resolving a few more TODOs in the PIR PDD.
19:42 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29860
19:43 DietCoke and this:
19:43 DietCoke =item .HLL <hll_name>, <hll_lib> [deprecated]
19:43 DietCoke An old form of the .HLL directive that also loaded a shared lib for the
19:43 DietCoke HLL. Use C<.loadlib> instead.
19:43 DietCoke (also, the PDD uses that second deprecated syntax shortly after the warning.)
19:47 dalek r29861 | allison++ | trunk:
19:47 dalek : [pdd] Launching the PIR PDD out of draft.
19:47 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29861
19:48 * DietCoke does wonder how it can be out of draft when there are so many {{NOTES}} in it.
19:48 DietCoke and outstanding questions.
19:48 particle take a look at the io pdd
19:49 DietCoke ... doesn't mean we should -keep- doing that. =-)
19:57 chromatic Some questions we can't answer until we have some implementation.
19:57 pmichaud moritz: I get the hang on spectest_regression also (on fresh checkout)
19:59 jonathan back
19:59 jonathan Do you know where it's hanging?
20:00 pmichaud at the do_fudge step in the harness (still probing)
20:01 jonathan OK
20:01 jonathan I'd help, but I can't reproduce it here.
20:02 pmichaud it's hanging in fudgeall
20:04 pmichaud oh wait
20:05 pmichaud it might not even be getting there
20:06 pmichaud okay, it's getting there, and hanging when fudging range.t
20:06 particle if only we could skip it with #pure or something ;)
20:06 particle see what make t/.../range.t does
20:07 moritz just calling ./fudge rakudo S02-builtin_data_types/range.t doesn't hang, though
20:08 pmichaud it's actually calling   fudge --keep-exit-code rakudo t/spec/.../range.t
20:09 jonathan Hmm.
20:09 jonathan I did change that file, intending to un-todo a few tests that Rakudo could pass.
20:09 jonathan #?rakudo 5 skip 'range reverse not in spec'
20:09 jonathan Valid directive?
20:10 moritz jonathan: but whatever you did to that poor file, why on earth should fudge start to hang?
20:10 paco joined #parrot
20:10 moritz valid directive, but not true
20:10 pmichaud fudge _does_ do while (<>)
20:10 moritz it *is* in the spec, and defined to be the empty range
20:10 jonathan moritz: the line below: ### pmichaud, 2008-07-04:  XXX  no spec for .reverse
20:11 jonathan If it is spec'd now, we should change this/check the tests.
20:11 moritz jonathan: oh, I thought you meant 4..1
20:11 jonathan No, it means .reverse method
20:11 jonathan My comment maybe shoulda had a "." in there to make things clearer.
20:12 pmichaud I've been trying to use  "Range.reverse"
20:13 moritz I see that TimToady used quite some <> magic :/
20:14 jonathan moritz: Where?
20:14 jonathan Oh, in fudge?
20:14 moritz jonathan: in fudge
20:14 moritz @ARGV = ($IN);
20:15 moritz so all should be well if $IN is what we think it is
20:15 pmichaud for some reason the while (<>)  isn't seeing @ARGV
20:15 pmichaud if I print @ARGV just before the while (<>) ... it's correct.
20:16 moritz I don't even get to the first debugging print statement I made :(
20:16 pmichaud moritz: are you printing to STDERR ?
20:17 moritz no, that's the problem
20:17 pmichaud right... fudgeall and fudge are called from backticks, so their STDOUT is captured
20:18 pmichaud it does start processing range.t, up to the first test after the #?rakudo skip line that jonathan added
20:19 moritz uhm, should reading from <> empty @ARGV?
20:19 pmichaud @ARGV isn't empty, when I run it.
20:19 pmichaud i.e., I'm actually getting lines from range.t
20:19 moritz I added a few 'warn Dumper \@ARGV' lines, and it's empty sometimes
20:20 jonathan This isn't because you #? has to be in the leftmost column?
20:20 jonathan *the
20:20 pmichaud it shouldn't matter
20:20 jonathan I thought not.
20:21 pmichaud but there's something about the #?rakudo skip lines that fudge doesn't like
20:21 pmichaud commenting out the first causes me to hang on the second
20:23 moritz is $ARGS tied to @ARGV somehow?
20:23 moritz no, that was $ARG
20:23 pmichaud it's something to do with the skip lines jonathan added.
20:23 pmichaud if I take them out, processing works fine.
20:24 jonathan I removed one and added one, I believe.
20:24 pmichaud #    #?rakudo 2 skip '.reverse on ranges'
20:24 AndyA joined #parrot
20:24 pmichaud ...how about that one?
20:24 jonathan (The one I removed covered both some tests that passed in Rakudo and some that failed)
20:24 pmichaud #    #?rakudo skip 'XXX test error -- result should be undef?'
20:24 pmichaud those are the ones that are causing issues for fudge
20:25 Auzon Those aren't recognized by fudge, I think
20:25 jonathan It was around the .reverse that I did the changes.
20:25 pmichaud Auzon: ...?
20:25 purl Yada yada yada hasn't been implemented yet! (unless you run bleadperl)
20:25 jonathan The entire block "# simple .to, .from" before was marked as skip
20:26 jonathan I moved the #?rakudo directive inside the block and tweaked the number.
20:26 Auzon pmichaud: Fudge requires the ? right after the # mark or it's just a comment
20:26 jonathan (since .from and .to work)
20:26 pmichaud Auzon: oh.  the extra #'s in my pastes were where I commented out the skip lines
20:26 pmichaud if I remove those, then fudge hangs on what's left
20:32 pmichaud oops, I have to run.  I'll follow up on it later.  It's something about the range.t test that is causing the problem, though.
20:32 pmichaud bbiaw
20:32 jonathan OK
20:34 jonathan I have another update to that file anyway (removing one of the fudge directives, since I've made more tests pass)
20:49 dalek r29862 | jonathan++ | trunk:
20:49 dalek : [rakudo] Make range smart-matching accept the same or equivalent range as well as a single value within the range.
20:49 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29862
20:52 moritz in ROADMAP, Make junctions in boolean context return a junction of True/False
20:52 moritz is that actually correct?
20:53 moritz if you do this, 'if "a" eq any(<a b>)' and 'if !"a" eq any(<a b>)' will both be true
20:55 jonathan Doens't !"a" do prefix:! on "a"?
20:55 moritz I'd expect it to have a low precedence
20:56 moritz anyway, I meant !("a" eq any(<a  b>)
20:56 jonathan OK
20:56 jonathan Comment was based on comment from pm in RT#56630, but I may have mis-understood
21:00 jonathan I see your point. Hmm.
21:00 jonathan Think is that we should be able to rely on auto-threading to carry us through.
21:01 jonathan if !("a" eq any(<a b>)) -> if !(any("a" eq "a", "a" eq "b")) -> if !any(True, False) -> if any(False,True)
21:02 jonathan -> True
21:02 jonathan Hmm. :-S
21:03 donaldh joined #parrot
21:04 moritz "Collapsing to a single
21:04 moritz true/false value should happen when a Junction is used in a boolean context."
21:04 jonathan Yeah
21:04 jonathan Oh
21:04 jonathan ! enforces boolean context
21:05 moritz prefix:<!> actually does provide boolean context
21:05 jonathan !any(True, False) -> !True -> False
21:06 teknomunk joined #parrot
21:13 paco left #parrot
21:17 paco_ joined #parrot
21:18 * jonathan gets at least another 36 spec tests to pass with an implementation of infix:===
21:18 moritz YaY
21:22 jonathan t\spec\S03-operators\value_equivalence............dubious Test returned status 1 (wstat 256, 0x100) after all the subtests completed successfully
21:22 jonathan moritz: Seen this before? Any ideas?
21:22 moritz jonathan: yes, in other tests
21:23 jonathan It gave all tests successful with perl t\harness
21:23 moritz jonathan: usually some GC f*ckup
21:23 jonathan sh*t.
21:24 dalek r29863 | allison++ | pdd25cx:
21:24 dalek : [pdd25cx] Bringing the pdd25cx branch up-to-date with trunk r29862.
21:24 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29863
21:24 jonathan Oh, no, it does the same with t\harness too; I'd run it with perl6.pbc before
21:25 particle is it fudged?
21:25 jonathan particle: Yup
21:25 particle all fudged tests return 1
21:25 particle even if all tests pass
21:26 jonathan particle: OK, but normally in spectest_regression you don't then get a warning about it.
21:26 particle yes, because of --keep-exit-code
21:26 particle or whatever it's called
21:26 jonathan Right. But I'm getting the "dubious" in running spectest_regression
21:26 particle ah.
21:26 particle :(
21:28 jonathan And it doesn't segfault or anything when run under the debugger.
21:28 jonathan Just says it exited with code 1
21:28 chromatic Something sets the exit code then.
21:29 chromatic T*::Harness expects that an exit code of 0 means everything's okay.
21:29 chromatic Anything else indicates some form of oopsie.
21:29 moritz jonathan: did you try to run the .rakudo manually?
21:29 jonathan chromatic: It's meant to be exiting with a code of 1; fudged tests do.
21:29 jonathan moritz: Yes; it all looks fine doing that.
21:29 jonathan It's only when I run it under the harness.
21:30 jonathan Hmm, the harness says "Test returned status 1" too. Oddness.
21:31 chromatic The harness doesn't know that 1 means everything's okay.
21:32 jonathan chromatic: The harness used in make spectest_regression is modified to know that 1 means that.
21:32 dalek r29864 | Whiteknight++ | gsoc_pdd09:
21:32 dalek : [gsoc_pdd09] update to trunk r29862
21:32 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29864
21:32 chromatic Alright then.
21:32 jonathan chromatic: Normally, this works out fine; we have other tests doing this. For some reason, one that I've just added to the spectest_regression list ends up giving the warning. :-(
21:34 pmichaud what's the spec that gives rise to r29862?
21:34 particle what happens if schwern's patch is reverted?
21:34 Debolaz joined #parrot
21:34 pmichaud (equivalence of ranges)
21:35 pmichaud (dubious): I  get that a lot in the test harness
21:36 dalek r29865 | jonathan++ | trunk:
21:36 dalek : [rakudo] Basic implementation of the === and !=== operators, plus WHICH defined one some immutable types. Does enough to pass all non-fudged tests in S03-operators/value_equivalence.t.
21:36 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29865
21:37 iblechbot joined #parrot
21:38 jonathan pmichaud: It was in the spec test, and looked familiar; now I go look at the spec, I don't see it.
21:38 pmichaud right, that's one of the reasons I hadn't implemented it yet.  But I also hadn't had a chance to ask about it on p6l.
21:38 jonathan I was probably thiking of "Array     Array     arrays are comparable"
21:38 pmichaud but Range != Array
21:38 jonathan Oh, sure.
21:38 pmichaud I think we have to be a little bit pessimistic about assuming the spectests are correct
21:39 jonathan I wasn't saying that makes it correct, just what I was probably thinking of.
21:39 pmichaud can we get a p6l clarification or attach a ticket to get one?
21:39 jonathan I'm writing to p6l now.
21:43 jonathan pmichaud: Written; will update the spectest/implementation if I get a response back saying the spec is right and the test is wrong.
21:44 jonathan pmichaud: On the dubious test - since it's the only one doing that here for me, I'm a bit wary about adding it to spectest_regression.data, even though it is passing all un-fudged. Thoughts?
21:44 jonathan (all un-fudged tests, that is)
21:44 pmichaud I've seen "dubious" on other spectest_regression tests -- push.t gives that for me a lot
21:45 pmichaud I also get exceptions on the exit code
21:45 jonathan OK
21:46 pmichaud (RT#56630):  My primary point about boolean context was simply that the comparison operators currently in Junction.pir are wrong.
21:47 jonathan In that they should return a junction?
21:47 pmichaud yes
21:47 jonathan Makes sense.
21:47 pmichaud but yes, the underlying thought is also that most of the operators and items defined in Junction.pir should be handled via the normal dispatch and not as special-purpose functions
21:48 jonathan That involves writing out own dispatcher. :-)
21:48 pmichaud we're going to have to do that, yes.
21:48 pmichaud I left a question with TimToady on saturday asking about how we autothread method calls over junctional invocants
21:49 jonathan Junctional invocants = $junc.foo?
21:49 pmichaud yes.
21:49 jonathan I think you that's always a call on Junction.
21:49 moritz that's what i'd expect too
21:49 jonathan Otherwise, $junc.values maybe doesn't work.
21:49 pmichaud right
21:49 pmichaud but that's not what TimToady answered
21:49 jonathan Oh, damm.
21:49 jonathan :-S
21:50 pmichaud because it means we can't do    (1|2).exp
21:50 jonathan Hmm
21:51 pmichaud so we were speculating about something like  $junc.JUNCTION.values, similar to VAR on scalars
21:51 jonathan I guess if you're expecting to be able to use a junction anywhre you'd use a normal value, that kinda hurts...
21:51 jonathan That's ugly, though consistent-ish.
21:52 Whiteknight I would rather it be consistently not ugly :)
21:52 jonathan (and easy to implement...)
21:52 pmichaud autothreading method calls over junctions sounds... interesting, though.
21:53 jonathan With a custom dispatcher, I'm not thinking it'll be too horrible.
21:53 pmichaud right... but it means we can't do method calls on junctions through parrot's normal dispatch
21:53 pmichaud unless we override find_method somehow or something like that.
21:53 jonathan Yes...
21:54 pmichaud anyway, it also means that most of the existing spectests that do   $junction.values or $junction.pick are wrong.
21:54 jonathan Actually, it may not be so bad. Because $j.foo will call foo on Junction.
21:54 jonathan And then it can hit the fallback
21:54 pmichaud there is no fallback.
21:54 jonathan (because There Is No Foo)
21:54 pmichaud method fallbacks are gone now.
21:54 jonathan As in, the Perl 6 equivalent to AUTOLOAD
21:54 pmichaud yes, I was thinking it'd have to be autoload-ish.
21:54 jonathan Which sees the name, and gets the parameters.
21:55 jonathan And threads the call through the values in the junction.
21:55 jonathan We don't have a nice way to do AUTOLOAD style thing in Parrot right now.
21:55 pmichaud how does one do autoload-ish stuffin Parrot?
21:55 pmichaud oh.
21:55 pmichaud you answered my question as I was typing it :-)
21:55 jonathan We could either teach Parrot how to do it (by doing Stuff in find_method)
21:55 pmichaud surely it's been considered already, though?
21:55 jonathan Or stick it in our custom dispatcher.
21:56 jonathan find_method can return the AUTOLOAD on failing to find anything.
21:56 pmichaud right.
21:56 pmichaud or dynamically generate a method :-)
21:56 jonathan But they you have the slightly tricky issue of, how does it actually get the name of the thing we originally planned to call...
21:57 pmichaud if we dynamically generate the method we can put it in there :-)
21:57 jonathan Mwaha. :-)
21:57 jonathan Dynamically generated bytecode. :-)
21:58 pmichaud I wonder if there's a way for a method to determine how it was invoked?  (i.e., what name was used?)
21:58 pmichaud that would make it easier.
21:58 jonathan No, which goes back to the usual issue of find_method / invoke are split.
21:59 jonathan (The null PMC access in invoke that we used to get, was because we didn't know the name any more of what we find_method or find_name'd)
22:00 jonathan It's also the same reason that find_method currently can't do MMD, and we thus invoke on the multi..
22:00 jonathan (The args ain't promised to be available, at find_method time)
22:00 pmichaud ...but methods are invoked with callmethodcc, not invoke
22:00 pmichaud it's not the same
22:01 pmichaud subroutine calls are invoked using find_name_not_null + invoke, yes.
22:01 pmichaud method calls are invoked using callmethodcc, which has the name as part of the invocation
22:01 jonathan OK, but the callmethodcc op does a find_method, and then an invoke inside.
22:01 pmichaud okay.  but we could potentially squirrel away the invoke name somewhere.
22:02 jonathan You're right though, we do in callmethodcc emit a good error message rather than the Null PMC in invoke. That was for subroutine calls.
22:02 pmichaud btw, allison also said on saturday that we would see about changing things so that   foo.$P0(...)  would dtrt if $P0 is a String
22:02 pmichaud (or does 'string')
22:03 jonathan Does that not do the right thing now?
22:03 pmichaud currently it expects $P0 to be an invocable PMC
22:03 jonathan Ah.
22:03 jonathan That could make some code neater.
22:03 pmichaud yes, that's why I asked for it.
22:03 pmichaud and she said "oh, I was about to ask you about that as well."  :-)
22:04 jonathan :-)
22:04 jonathan Will Allison be at YAPC::EU, do you know?
22:04 pmichaud same for sub invocation -- i.e.,   $P0(...)  when $P0 is a String
22:04 pmichaud yes, she's at YAPC::EU
22:04 jonathan Cool.
22:04 pmichaud she's even planning to attend the hackathon, remember?  ;-)
22:05 jonathan I'm starting to think I already knew this... ;-)
22:05 pmichaud (from email, about dates when we would be there for pre/post-yapc hacking)
22:05 jonathan Oh, yes!
22:05 pmichaud :-D
22:06 pmichaud that may be a _really_ good time to get all of our dispatch and parameter issues worked out
22:06 pmichaud including mmd
22:06 jonathan Yes, agree.
22:06 jonathan I think I'm going to see if I can spend some of my MMD time towards the end of the week, going over the spec closely, writing tests, and coming up with any questions I need answered.
22:07 pmichaud that would be excellent.
22:07 jonathan So at least the algorithm is nice and clear.
22:07 pmichaud I think that would be extremely wise.
22:07 pmichaud I also think it will yield big dividends when we get to implementation
22:08 jonathan Yes, agree.
22:08 jonathan Also, Parrot needs to be able to HLL_map MultiSub.
22:08 pmichaud that sounds really.... scary
22:09 pmichaud but I don't disagree.
22:09 jonathan Not really - I think in fact the MMD PDD requires it.
22:09 pmichaud oh, in that case I'm less scared.
22:09 jonathan "An alternate multiple dispatch matching algorithm may be plugged in by subclassing MultiSub and overriding invoke."
22:10 jonathan So that's exactly what I plan to do.
22:10 pmichaud oh yes, of course.
22:10 pmichaud that works for me then.
22:10 jonathan But it follows on, that you need to have a way to have your multis of the right PMC type.
22:10 jonathan So if you can get HLL working, it makes my life a little easier.
22:10 pmichaud I can do that, yes.
22:10 jonathan If you can't, I can work around this.
22:11 jonathan We also need to think a bit on signatures at some point too. :-S
22:11 pmichaud correct
22:11 jonathan Last time we tried that, we got kinda bogged down.
22:12 pmichaud I'm beginning to think that PIR will never have sufficient pragma flags for us to do everything we want to do, so that we'll have to make it all part of :init/:load
22:12 jonathan I think, because I was primarily interested in them being introspectable data, because that's what I need for MMD.
22:12 pmichaud do you need them more introspectable than simply arity and types of args?
22:12 jonathan No.
22:13 jonathan Well
22:13 jonathan Yes and no. :-)
22:13 pmichaud so :multi is sufficient as a first cut?
22:13 jonathan I'm struggling to think of a good way to get enough information into multi.
22:13 pmichaud well, that's why I said "first cut"
22:13 jonathan There can be many constraints.
22:13 pmichaud however
22:13 jonathan Which may be class or role names, etc.
22:14 ruoso joined #parrot
22:14 pmichaud I'm starting to think that for Rakudo we should just have a Junction of constraints, and have the dispatcher smart-match against that
22:14 jonathan The MMD algorithm requires a bit more of us than "is it a match"
22:15 pmichaud agreed
22:15 pmichaud where's the Perl 6 mmd sort speced?
22:15 jonathan First, we need to consider classes and roles, and we use constraints (subset types) later.
22:15 jonathan S12
22:15 pmichaud okay, I'll need to re-review that
22:15 jonathan Starts at heading "Multisubs and Multimethods"
22:16 pmichaud anyway, I agree that signatures will end up as introspectable types.  For a variety of reasons I think I'd like to avoid :immediate if we can.
22:16 pmichaud (it may be that we cannot, but that's what I'd like to shoot for to begin with)
22:17 jonathan The fact that it is in the way of PBC generation (I *think* that's what you said?) makes me kinda keen to do away with them too.
22:17 pmichaud yes
22:17 pmichaud going back to the roadmap a bit, I think that PBC generation is my highest priority at the moment
22:18 pmichaud I think that depends on .HLL a bit, as well as getting :load/:init fixed
22:18 jonathan The reason I used them was because they provide a sure-fire way to make sure you attach things to the Right Sub.
22:18 jonathan (Because you make it the :outer)
22:18 pmichaud yes, "the Right Sub" is also a bit of an issue for me.  I think we might need a way to uniquely identify subs outside of just names.
22:18 pmichaud :lexid is close, but this goes beyond just lexicals.
22:19 jonathan We already created one of those and called it lexid, but it seems it could be more widely applicable.
22:19 pmichaud basically :lexid is almost equivalent to "longname"
22:19 jonathan Also, lexid is not generated until POST-time.
22:20 pmichaud I did that as a short-term measure
22:20 pmichaud there's nothing to prevent :lexid from being part of the PAST
22:20 jonathan If we're going to attach something to a sub based upon that, we need either POST to be able to help us link the two up or move it up.
22:20 pmichaud it's the same approach that gets used now for anonymous subs
22:20 jonathan Yes, to PAST, as you mentioned.
22:20 pmichaud PAST doesn't contain a name, but the POST generates one.
22:21 jonathan OK.
22:21 jonathan But Rakudo could feasibly generate the names.
22:21 pmichaud correct
22:21 pmichaud and :lexids
22:21 jonathan Right, which is what we're interested in here.
22:21 pmichaud which is why I think that :lexid might be more correctly thought of as a longname equivalent
22:21 jonathan Then the missing bit of the puzzle, is a lookup by lexid.
22:22 pmichaud ....and a way to do that efficiently. :-)
22:22 jonathan Yeah. :-|
22:22 jonathan Thing is, we kinda want a hash of lexid => sub
22:22 jonathan But we only care about having it at startup.
22:23 pmichaud I wonder if the Eval PMC could help here
22:23 pmichaud since the Eval PMC has an array of Sub PMCs
22:23 jonathan You can likely make it easy (if this ain't already possible) to iterate all of it's subs. We can also trivially expose the lexid.
22:24 pmichaud yup
22:24 jonathan Then we can even just build our hash in one iteration in PIR.
22:24 jonathan In the :init :load
22:24 jonathan Do our lookups in it
22:24 jonathan Then let the GC have its way with it after :init :load.
22:25 pmichaud yes, that has some possibilities
22:25 jonathan Oh
22:25 jonathan But the Eval PMC ain't available in the :init :load?
22:25 pmichaud currently, no, but we might be able to fix that as well.
22:25 jonathan Even in the PBC version?
22:26 pmichaud I really have to get the whole :init/:load process mapped out
22:26 pmichaud there's been so much "workaround" stuff done to get things to work that I have to go back and decide which parts are "real" and which parts are "workaround"
22:26 jonathan Really we want to walk the constants table attached to the current bytecode segment.
22:27 jonathan This will contain, if we eval'd, the Sub PMCs that we evaluated.
22:27 jonathan And if we're loading a PBC, will contain the Sub PMCs we compiled and had in the PMC.
22:27 pmichaud true.  For example, I didn't realize until a week or two ago that :immediate subs get replaced in the bytecode by whatever they return
22:27 jonathan Yes. I wasn't using them so much for this purpose, though.
22:27 pmichaud but it's very handy for building the signature object we need
22:28 pmichaud instead of building it at load time
22:28 pmichaud (assuming we can get a reasonable representation.)
22:28 jonathan Yes, that's another reason :immediate is good - we do compile time at, well, compile time.
22:28 jonathan I think in reality, we can do stuff in :init :load now, and move some of it to :immediate as a kind of "optimization" later.
22:29 pmichaud yes, we can certainly do that.
22:29 jonathan Once we get issues with :immediate in Parrot straightened out.
22:29 jonathan (Which evidently exist, since they're geting in our way...)
22:29 pmichaud Anyway, I hate to rush off but I have to get some other stuff done today.
22:29 jonathan Well, in your way. :-)
22:29 pmichaud I _should_ have some Parrot hacking time tomorrow.  After that it's spotty until August 9th
22:29 jonathan OK, it's half midnight here so I should maybe call it a night.
22:30 jonathan OK, I'll likely be on IRC a bit tomorrow too.
22:30 pmichaud my time tomorrow will be early (before noon localtime) -- after that it's off to the airport
22:30 jonathan Vacation?
22:30 purl Vacation is good for the soul, and allows one to learn JDK 1.2 or or GET REAL it's a VACATION or an alien concept to formerly underpaid beleaguered perl hackers whose time is long overdue
22:30 * jonathan suggests NOT learning JDK 1.2 on vacation.
22:33 pmichaud yes, vacation
22:33 purl it has been said that vacation is good for the soul, and allows one to learn JDK 1.2 or or GET REAL it's a VACATION or an alien concept to formerly underpaid beleaguered perl hackers whose time is long overdue
22:33 jonathan Nice. Enjoy. :-)
22:37 * jonathan rests - report tomorrow
22:39 Tene 'night
23:34 cesar joined #parrot
23:36 cesar Hi
23:37 cesar It seems the code for Software Transactional Memory remained almost the same since 2006
23:37 cesar I'm a MSc student with interest in parallel computing
23:38 cesar and I would like to contribute ...
23:38 cesar is there anyone here who had worked on that?
23:39 cesar joined #parrot
23:41 cotto cesar, if nobody here can help you right now, you can subscribe to parrot-porters and ask there.
23:42 cesar cott: ok, I'll try it, thanks
23:43 cotto the amount of activity on #parrot varies greatly
23:45 Whiteknight cesar, what suggestions do you have about the STM system?
23:46 Whiteknight I'm peripherally familiar with it
23:50 cesar I would like to begin testing another approaches described in literacy
23:51 Whiteknight I don't know how pluggable the system is. That is, I don't know if you can easily write an alternative without mangling the existing code
23:51 Whiteknight Although if you wrote up an alternative, you could separate it with an #ifdef
23:55 cesar I started by reviewing the code, and the paper the implementation is based on, just beginning with it
23:56 Whiteknight I'm not as familiar with stm as I would like. I'll have to read that paper myself
23:57 Whiteknight Actually, if you understand that file pretty well, it needs a lot of function-level documentation
23:57 Whiteknight all the "RT#48260: Not yet documented!!" notes need to be replaced by documentation
23:58 Whiteknight I may work on that myself, if you don't want to do it
23:59 cesar I plan to use the VM as bed of the research and I'll like that part of the resulting work be useful for the project

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

Parrot | source cross referenced