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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!