r27336 | fperrad++ | trunk: : [Lua] : - luad.pir : fix tests on win32 diff: http://www.parrotvm.org/svn/parrot/revision?rev=27336 % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot % Ademan has joined #parrot Morning, all good morning ;) allison@perl.org | Concurrency Tasks: link: http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks dalek's url is at http://xrl.us/bjqpy % IllvilJa has joined #parrot Urk. * Jonathan gets a segfault in the GC my Int $x = undef; say $x.WHAT Int my $x = undef; say $x.WHAT; Failure my Int $x = 42; say $x.WHAT; $x = undef; say $x.WHAT; Int Int moritz: Look correct to you? r27337 | jonathan++ | trunk: : [rakudo] Make it so we can assign undef to typed variables. In the case where it's a typed variable we're assigning it to, stick the proto-object in there instead. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27337 Jonathan: yes OK, that's one ticket down. Read up a bit on the Failure stuff, understand it a tad better now. it's amazing how much thought is in the synopsis. I couldn't fully appreciate that on first reading because I understood only 20% now I'm at 40% I guess ;) Some things when I first looked at them, I thought "how on EARTH will they implement that? glad I don't have to do it!" lol Apart from I've implemented some of those things now. r27338 | jonathan++ | trunk: : [rakudo] Make grammars more class-like. We now create protoobjects for them. Added a Grammar class, implementing the ACCEPTS method which calls TOP. Had to tweak the protoclass' ACCEPTS to also try the one in the class to make this work; should review if this is really the Right Way for this to work. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27338 r27339 | jonathan++ | trunk: : [rakudo] Smart-matching against a grammar should set $/. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27339 % wknight8111 has joined #parrot % rdice has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot r27340 | jonathan++ | trunk: : [rakudo] Make grammar inheritance work. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27340 * Jonathan takes lunch % rdice has left rdice!~richard_d@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com % IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk % iblechbot has left iblechbot!~iblechbot@ppp-62-216-201-19.dynamic.mnet-online.de % tetragon has left tetragon!~seneca@216.126.67.44 * Jonathan returns % gryphon has joined #parrot r27341 | jonathan++ | trunk: : [rakudo] Should be able to smartmatch against grammar protoobject as well as an instantiation of it. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27341 % mire has joined #parrot % rdice has joined #parrot r27342 | jonathan++ | trunk: : [rakudo] Implement .perl method on junctions. Mostly based upon a patch courtesy of Zach Morgan . diff: http://www.parrotvm.org/svn/parrot/revision?rev=27342 r27343 | jonathan++ | trunk: : Give Zach Morgan a CREDITS entry. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27343 r27344 | jonathan++ | trunk: : [rakudo] .perl methods for Num, Int and Str. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27344 % mire has left mire!~Frodo@252-172-222-85.adsl.verat.net % Andy has joined #parrot % uniejo has left uniejo!~uniejo@langebro.adapt.dk % irclogbot has left irclogbot!moritz@faui2k3.org % iblechbot has joined #parrot jonathan: ping % moritz has left moritz!moritz@ssh.faui2k3.org particle: pong nice work today. noticed your recent patch to provide .perl shouldn't that be on Any, though, and let Str, Num, and Int inherit it? Well, override rather than inherit, I guess.. Num and Int both called get_string v-table, Str has to escape... ah, yeah, i'm just looking at Num and Int now So they do different things, if you were thinking of sharing an implementation. But Any wouldn't be the right place anyway. You can .perl a Junction and a Junction isn't an Any. what's .perl of Any return? probably an exception :-) So it'd be in Object if anywhere. And yes, we should have a default implementation for objects, I think, that returns Name.new(:x(42), :y("foo")) I'm not sure we can have an instance of Any directly. :P what should it return? my Any $x = undef; $x.WHAT pmichaud: I think Any is actually meant to be a role too... particle: note that .WHAT != .perl :-) yes, i know % parrot-poke has joined #parrot Jonathan: iwbni we knew which of these things are classes and which are roles :-) all i'm trying to say is that there's shared code between the Int and Num implementations of .perl pmichaud: Well, I did it as a class for now, but at the time I hadn't read it was a role... if that code could be stuck in a role and shared, that'd be great. pmichaud: Also, MMD doesn't know about roles yet. the generic code for .perl is probably simply to call the get_string vtable method at least for Int and Num That's a very small number of cases. ;-) correct. no, it's not! I struggle to think of many other types that stringify and .perl'ify the same. I agree shared is shared. i already had it that way, particle. I'm not entirely sure what needs to be "shared" there pmichaud: I do have a question on something else to get your thoughts on, if you have a moment now. I do -- I'm working on getting rid of the "Null PMC in invoke" messages OK, cool. I got grammars being all class-like this morning. Protoobjects, inheritance, etc. % ask has left ask!~ask@pat-tdc.opera.com Unfortunately, if you write grammer Foo { rule Blah { \d+ } } Then Foo::Blah (or trying to match against it) now doesn't work. % ask has joined #parrot We'll have a parallel issue with referring to methods in classes. well, that's because Foo::Blah is of type sub The reason being that we put the protoobject into the namespace slot Foo I haven't found that having protoobjects in namespace slots have caused me any problem % IllvilJa has joined #parrot So the lookup ends up giving an error because Foo isn't a namespace. It's the protoobject. I thought I had tested that before. just a sec Well, you don't see it with Object, say, because while the protoobject gets put in Object, the namespace there is Perl6Object. no, I had tested it with a few PGE things and PCT/NQP things OK writing test case now -- just a sec "pmichaud" at 76.183.97.54 pasted "protoobject doesn't conflict with namespace" (16 lines) at http://nopaste.snit.ch/12901 "pmichaud" at 76.183.97.54 pasted "protoobject doesn't conflict with namespace (extended)" (21 lines) at http://nopaste.snit.ch/12902 Hmm. That's both releiving and confusing. Now I gotta work out, why what I have doesn't work. that said, I've been thinking that protoobjects will need to implement hash lookups to be able to do things like Foo:: or Foo::{$xyz} Oh, hmm. That's not what protoobject hash lookup does with the :: mind. ??? Then they return a clone of the protoobject with a WHENCE auto-vivification caluse. *clause See right at end of S12. okay, well, I haven't looked at the module spec recently enough to understand any of that :-) OK, well, I already implemented a fair bit of that section anyway. :-) anyway, Parrot doesn't seem to have an issue with storing symbols with the same name as a namespace It's the thing that lets you initailize superclass attributes in .new I'll review it after I get a few other tasks off my plate No, I think you're right. Something else must be wrong with what I'm attempting. unless we have something that understands smart matching against a Sub, then that may also be the issue as Foo::Blah will be some sort of method or sub this does beg the question as to whether individual rules are automatically flagged as "is export" We do. That's how regex work today. regex Test { \d+ } if "42" ~~ Test { say "yes" } yes hmmmm fwiw, the 'grammar' option to Perl6Regex *ought* to create a protoobject as well (but currently doesn't). I consider that a PGE bug. But for the case where it's in a grammar, we get code generated as... .namespace ["Foo"] .sub "Test" :method However, i guess However, is there a reason you aren't using getpwnam() ? grammar Foo { regex Test { \d+ } } if "42" ~~ Foo::Test { say "yes" } Null PMC access in find_method() Null PMC access in find_method() is the bane of Infinoid's existence. purl, forget However, pmichaud: I forgot however, ....why is that calling find_method in the first place? It's inside infix:~~ Which calls ACCEPTS get_hll_global $P18, ["Foo"], "Test" $P16 = "infix:~~"($P17, $P18) ah, no ACCEPTS on a Sub, yes? how does "infix:~~" work when calling it on a non-grammar method? ACCEPTS is implemented on Sub, yes. ....okay, I'm confused. :-) so Foo::Test is returning a Null PMC ? Yes. But it's compiled down to get_hll_global $P18, ["Foo"], "Test" - which is what we'd expect to work. grammar Foo { regex Test { \d+ } } Foo::Test("42") Null PMC access in invoke() can I see --target=pir on the above? module Bar { sub Test { say "hi" } } Bar::Test() hi hi, Jonathan. get_hll_global $P36, ["Foo"], "Test" new $P37, "Int" assign $P37, 42 $P38 = $P36($P37) Oh, for the grammar too? I'll nopaste that. I was more interested in the regex code generated right. nopaste? nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://paste.husk.org/ or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or don't bother me while I'm eating actually, the whole thing. :-) "Jonathan" at 80.39.174.204 pasted "for pmichaud" (140 lines) at http://nopaste.snit.ch/12903 That's just from interactive mode. yay birthday. my (weak) suspicion at this point is something in !keyword_grammar or make_grammar_proto since everything else is pretty much the same between the two I don't think we need to mess with namespaces in !keyword_grammar Whatever the issue is, classes have it the same. class Foo { method Test { say "yes" } } Foo::Test() Null PMC access in invoke() % jhorwitz has joined #parrot keyword_grammar should simply cause the new class to be created as a subclass of Grammar, honoring any 'is Foo' traits same for keyword_class (keyword_class should cause the new class to be created as a subclass of Any, honoring any ...) keyword_class does that % cjfields has joined #parrot well, not exactly keyword_grammar has cruft in that I forgot to remove when I made it have a real protoobject what keyword_class does is create a new class and then let something else attach parents OK, keyword_class doesn't do the Any bit. But it should happen later. in make_proto I think that we ought to attach parents as part of keyword_class and keyword_grammar directly Well, problem is that we need to then "unattach" them later when we apply a trait that is a class. It's maybe easier to fix them up later. that's why I said "honoring any traits" class Foo { ... } # creates class as a subclass of Any OK, put we have to have a class object, to dispatch on. *but class Bar is Foo { ... } # creates Bar as a subclass of Foo Right, agree that's what should happen. But I don't know that keyword_class is the place to do it. keyword_class creates a class object We then need to use that to add parents, because trait application is multi-dispatch. ...multi-dispatch? Only after we've done all of that, do we then know whether it got any parents from the traits, and then we can attach any. Yes. ok. See src/builtins/traits.pir, also (more, sec) actions.pm:976 # but mine has local changes, maybe a bit off but could we hold off on the class object creation until we've resolved the traits ? And trait_auxiliary:is No, because the class object itself is one of the parameters to the multi-dispatch. In S12, see trait_auxiliary:is search for, I mean. looking. It's just under the Traits heading. found it % grim_fandango has joined #parrot OK, and inheritance is spec'd just as being a trait that is another class, so the MMD does the Right Thing. okay, I somewhat see where this goes so, getting back to 'grammar' -- will fixing keyword_grammar to not do any namespace mangling resolve it ? No, because keyword_class shows the same issue okay hrm. And it doesn't do any namespace mangling. I'll tidy up keyword_grammar in a moment, just doing some grammar changes to take us a tad closer to STD.pm. what happens with class Foo { sub Test { say "hi"; } } ? class Foo { sub Test { say "hi"; } } Foo::Test() Null PMC access in invoke() Or you meant, what PIR? no, you had it right. but yes I'm curious about the PIR also. "Jonathan" at 80.39.174.204 pasted "for pmichaud" (62 lines) at http://nopaste.snit.ch/12904 and we're certain that it's Foo::Test that is null and not some other call inside of it? (e.g., 'say') One second, I just br0ked my Rakudo with grammar changes okay also, what's the purpose of the Iterator over methods inside of !keyword_class ? is that to prepare things for mixing in roles later or something? Yes. We need to tell Parrot what methods the class has, that override methods from roles. Parrot's support for composing roles is a superset of what Perl 6 wants. and we do that at the point where the class is created? interesting. okay, I get it. r27345 | pmichaud++ | trunk: : [rakudo]: : * Add a .print method to Object to (hopefully) help out : evalbot on #perl6. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27345 % ambs has joined #parrot wow. parrot has a superset of something perl 6 needs. is that the first time that can be said? lol parrot has a lot of things that perl 6 doesn't. I wish I could get rid of some of it. :-P er, *doesn't need * particle revokes pmichaud's commit bit before he takes action ;) Nooo! He has to do return and list assignment first! :-P sorry Jonathan, that's your job now! think about all the crazy needs that perl 7 will have though * pmichaud tosses a booby-trapped pumpkin to jonathan++ we can't add features fast enough if we want to support the magic of perl 7 perl 7 is really just Perl 6.999999999999... yeah, we're gonna run perl 6 on a pentium iv and call it perl 7 69? quite a mouthful, I think you will agree or Beef with Broccoli Perl 6.99 with enhanced DWIM and DWIT (do what I think) purl, perl 7? somebody said perl 7 was real? (just checking :-) r27346 | infinoid++ | trunk: : [codingstd] remove trailing whitespace diff: http://www.parrotvm.org/svn/parrot/revision?rev=27346 Jonathan: your .perl methods are too nice... podchecker is complaining about =item without an =over, because none of the surrounding subs were documented :) D'oh. I do the Right Thing, and podchecker spanks me for it. Jonathan++ # adding code so shiny, the rest of the code breaks out of jealousy r27347 | infinoid++ | trunk: : [rakudo] Int.pir: add enough POD stubs to avoid a t/doc/pod.t test failure diff: http://www.parrotvm.org/svn/parrot/revision?rev=27347 Hmmm...wonder if we've ever been able to parse my @result = @list.grep():{ ($_ % 2) }; or if my grammar changes have just broken that... it's not anything I tried to make happen yet that looks like list context (I suspect we've never parsed it.) OK, good. Then I probably haven't broken anything. (else.) :-) I thought a few more spectests might have been failing, but there's so many that it's impossible to know... I cleared up a few more today. yes, we really need to tag more of the spectests ...without caching results of previous runs. It feels like an endless task. r27348 | infinoid++ | trunk: : [rakudo] Grammar.pir and Num.pir: stub in enough POD to prevent t/doc/pod.t failures. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27348 Yeah, I ddin't think to do that. ;-) Jonathan: you were doing way too much work when tagging the tests you don't need #?DOES everywhere Oh? fudge figures it out on its own most of the time But if you want it to knock out 5 lines that do 3 tests? Oh, OK. fudge looks for actual instances of test calls not number of lines Ah, OK. in the source for fudge, there's is|ok|is_deeply|... OK. Well, all basic tests pass with the changes, so I can't have done anything *too* bad... agreed. ok, i'll make it my task to get fewer spectests complaining r27349 | jonathan++ | trunk: : [rakudo] Refactor parsing of method calls to bring us somewhat closer to STD.pm, as well as parsing various other call operators and private calls so we can implement those. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27349 Ouch. I asked a question on p6l. Now I need a month to understand the answers. that seems to happen. My solution is to skim the answers and wait for TimToady to answer. Yeah. That's what I'm hoping will happen. the other approach is to write a (spec) test and ask "is this correct?" TSa's answer suggests that Undef exists as a parametric type... % moritz has joined #parrot % iblechbot has left iblechbot!~iblechbot@ppp-62-216-205-112.dynamic.mnet-online.de % moritz has left moritz!moritz@ssh.faui2k3.org % cjfields has left cjfields!~cjfields@cjfields.igb.uiuc.edu Hmmm. STD.pm has two ways to parse .= oops, milk pickup :-( bbl % moritz has joined #parrot % sjansen has joined #parrot % ilbot2 has joined #parrot r27350 | jonathan++ | trunk: : [rakudo] Panic on the unimplemented method call operators for now, so folks know they don't work rather than think they're broken. :-) diff: http://www.parrotvm.org/svn/parrot/revision?rev=27350 % davidfetter has joined #parrot % pmichaud has left pmichaud!pmichaud@feather.perl6.nl % dalek has left dalek!dalek@feather.perl6.nl % leo has left leo!lt@feather.perl6.nl % Jonathan has left Jonathan!jonathan@feather.perl6.nl % wolverian has left wolverian!wolverian@feather.perl6.nl % Juerd has left Juerd!juerd@feather.perl6.nl % PerlJam has left PerlJam!duff@feather.perl6.nl % cjfields has joined #parrot % davidfetter has left davidfetter!~chatzilla@start.fetter.org % pmichaud has joined #parrot % wolverian has joined #parrot % Jonathan has joined #parrot % Juerd has joined #parrot % dalek has joined #parrot % PerlJam has joined #parrot % leo has joined #parrot svn st cotto_work, svn is dead. * ambs grins Parrot trunk seems broken to me sounds like time for me to go do dinner... Will do private methods later on. pmichaud, updating, configuring and compiling ambs: does this mean that the broken trunk is a known/expected failure? I get to the part that is building config.php (I think), and I get an endless loop of "Cannot put to non-PIO PMC" sorry, config.fpmc pmichaud, no, no. I am just updating to check if it is your ault. Jonathan++ # excellent work as always make run ok pmichaud: I get the same messages % cjfields has left cjfields!~cjfields@cjfields.igb.uiuc.edu I think it's in "make languages" hmmm I just did a fresh checkout and it builds fine % jq has left jq!~jquelin@merlin.mongueurs.net % cjfields has joined #parrot weird. % jq has joined #parrot local changes, need a realclean... ? no local changes, did a realclean % davidfetter has joined #parrot removing the directory and checking it out again fixed it, though. so I'm guessing a missing dependency or realclean isn't real clean enough. :D you removed the directory so no chance of figuring out what it was? right. Cannot put to non-PIO PMC ? that was the error message. I just did 'svn up && make -j realclean && perl Configure.pl && make -j' and am stuck in that loop. I'll see if I can track it down. jonathan++ that's a very recent change by chromatic. r27351 | pmichaud++ | trunk: : [pct]: : * Fix 'call' generation of PAST nodes so that "Null PMC in invoke" : messages now read "Cannot invoke non-existent sub 'foo'". diff: http://www.parrotvm.org/svn/parrot/revision?rev=27351 what's it do for anon subs? * particle reads the patch same error here : Cannot put to non-PIO PMC % lidden has left lidden!~stefan@puce.campus.luth.se % wknight has joined #parrot % ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt I won't be around for #PS... I pasted my report early. % chromatic has joined #parrot well, if it isn't the man who broke parrot. hi chromatic % Searle has joined #parrot % Searle has left Searle!~Searle@p54BC97F0.dip0.t-ipconnect.de % AndyA has left AndyA!~andy@82.152.157.85 Ooh, I'm actually going to be here for (the first 25 mins of) ParrotSketch for once... ParrotSketch? somebody said ParrotSketch was 18:30 UTC, Tuesdays or a weekly status meeting for parrot design team 18:30.. +03:00. purl, ParrotSketch is also held in #parrotsketch okay, cotto_work. % Ivatar has joined #parrot % AndyA has joined #parrot do my maths fail or it started already? no, parrotsketch is a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch okay, particle. your maths fail. it starts in 6m there is no daylight savings time in UTC, you need to adjust ahh yeah, right.. particle: your englishes fail. ;-) I still can't remember that I'm in +04, not +03 +03 is in winter.. but I will still miss it % allison has joined #parrot % jhorwitz has left jhorwitz!~chatzilla@96.245.16.45 it's time * particle pokes coke % chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net % chromatic has joined #parrot % NotFound has joined #parrot 66+661-86-700 -59 -59? 66+661 727 % davidfetter has left davidfetter!~chatzilla@start.fetter.org allison, I won't have time to hack until late tonight. 66+661+86-700 113 there. 113 tickets left to close. Huh. RT said we have 738 or something. you're missing stalled. :| chromatic: I'm about to sleep here, so won't wrap up until after you go to sleep, probably I don't miss those. there are probably 50 tickets that are just crap and can be closed. I'm going by new + open. so only 27, then. * particle doesn't mind 30 failing tests, if we are told how to fix them Pretty sure I fixed RT #53492. chromatic: #53352 is still open? particle: I've been triaging the tests and fixing them as I go. there's one thing I know I have to do, though not sure I can explain it well enough to hand off. otherwise, it's "look at the test, figure out why it's failing, and fix it" Closing now, NotFound. Thanks. allison: the usual, then :) figured there might be "change all rethrow to throw" or similar to do 26! 4.03291461126606e+26 Perl exists : http://maps.google.es/maps?f=q&hl=es&geocode=&q=perl+alemania&sll=40.396764,-3.713379&sspn=11.641133,20.566406&ie=UTF8&ll=49.472419,6.390524&spn=0.019409,0.054245&t=h&z=15 paco's url is at http://xrl.us/bj8a8 tene: trailing commas allowed both in rakudo and nqp now? tene++ % iblechbot has joined #parrot % rhr has left rhr!~ryan@bas3-montreal02-1096681222.dsl.bell.ca r27352 | allison++ | trunk: : [exceptions] Noting a series of deprecated features from the concurrency : implementation branch. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27352 pmichaud: Perl 6 concurrency - yes, but I think it might be a case of, whoever does a good implementation first mostly makes the spec.. Three more tickets closed. pmichaud: One thing for ROADMAP - explicitly mention IO on there? where should it go? I'm not entirely sure...it's not low priority really, as I think people need it to Do Stuff. (stuff to close) this guy has 4 pending patches: http://rt.perl.org/rt3/Ticket/Display.html?id=53552 But there's other big things that need doing too, and it's not like we have no I/O at all at the moment. I'm going to treat IO around the 'modules' area OK, works for me. it's also not like I/O is officially spec'd yet, either :-D r27353 | allison++ | pdd25cx: : [exceptions] Merging 'throw' and 'throwcc', the one-argument versions were : identical anyway. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27353 True, but the bits floating around aren't officialy hated either, so far as I'm aware. :-) In Parrot or in Perl 6? allison: you had +1'd changing "compilation unit" to sub, neh? er, "subroutine" I/O not officially spec'd in Perl 6 -- there's a draft in the pugs repo chromatic: I'm talking about Perl 6. I suspect I/O will be a little ahead of lazy lists, although they have a lot in common is the fh read operator still (planned to be) prefix:=? Eevee: last I checked it still was, yes. chromatic: you were going to poke at 43719, neh? (comes with patch and everything!) hm. I don't know if '$line = =$fh' will ever look not weird Eevee: It's even somewhoat implemented. oh really But only using it on for loops... I don't even know how files are opened (concurrency) I'm guessing the April 30 design meeting notes aren't published yet? r27354 | pmichaud++ | trunk: : [rakudo]: : * Add I/O to ROADMAP, for clarity. Jonathan++ diff: http://www.parrotvm.org/svn/parrot/revision?rev=27354 my $fh = open("filename.txt", :r); coke: in what context? for =$fh -> $line { say $line } $fh.close(); coke: 'compilation unit' is really mainly an abstract concept r27355 | chromatic++ | trunk: : [PIR] Improved the error message for invoking a non-existent dynamic sub (fixes : RT #49972). diff: http://www.parrotvm.org/svn/parrot/revision?rev=27355 chromatic++ now I can rip out my PCT patch :-) awesome allison: if you could comment on http://rt.perl.org/rt3/Ticket/Display.html?id=49001, that'd help. =-) Coke, sounds familiar. What did you want me to do? well, except that global open() is a bit of a wart Eevee: lots of the builtins are "global" chromatic: ISTR that you and I were both confused how that opcode could have not failed tests. print() say() etc. True. I find it preferable to Something::Very::Long::To::Just::open($thisfile, :r); ;-) maybe change it to throw an exception on use and then see if anything breaks, if not, deprecate it and apply my patch. I know, and I don't really have any better suggestion that doesn't look ridiculous (my $fh = new file('file_that_already_exists')? ugh) allison: RT#49001 comes about because the pdd19 draft often says "compilation unit" when most of us would think "sub". To me a "compilation unit" is a complete file or text (which could have multiple subs), and so reading pdd19 is a bit awkward coke: ah, in that context it's really an accident of history: at one point subs were labels and compilation units were something else then subs graduated to being compilation units and all the other kinds of compilation units died off Eevee: You can if you want do (I think, though this maybe isn't yet implemented) my $fh = IO.new(); $fh.open(...); so, really sub == compilation unit now we had discussed this in a #ps long ago and the general concensus (iirc) was that "compilation unit" should refer to a file or complete item sent to the compiler pmichaud: that's the thing, a subroutine now is a complete item sent to the compiler it's the largest unit the compiler handles at a time that's not entirely accurate yeah there's also various directives when PGE or PCT generates a string of PIR that contains multiple subs, the compiler handles them all and returns an Eval object my IO $x .= open( 'foo.txt', :r ); oh ho, I like that pmichaud: in the larger sense, a "compilation unit" is giving the largest body across which a label can be used label or symbol? either then I think a compilation unit for IMCC is larger than just a sub. at least, in the sense of a PIR .local symbol (anything stuffed in a symbol table doesn't count) right, I'm referring to symbols in the compiler's table, not runtime labels can't be used outside of a subroutine neither can .locals but .sub can outside of a .sub, that is .sub defines the compilation unit no, for :anon subs the only way to refer to it is from within the same file. and, produces something that's inserted into the symbol table for example, .const .Sub corou = "ws_corou" we're talking in circles. All I meant to say is that at one time the name "compilation unit" made sense in that context okay. but that time really has passed I'm not disagreeing with that. I'm asking what it should be. :-) (and advocating that it should refer to a file as opposed to individual subs) I don't know that it matters much what the top-level non-terminal rule is called, 'subroutine' is fine (also, it doesn't matter to me what it's called in the imcc yacc grammar -- I was referring primarily to pdd19) just a sec, I'll take a look and check if it's parsing anything other than .sub s/was/am/ yeah, that rule parses .sub, namespace definitions, and constant declarations, so "subroutine" really doesn't make sense oh, and macros and pragmas, and... but 'compilation_unit' is also entirely inappropriate for pdd 19, yeah, it doesn't really need to mention compilation units at all "routine" is shorter shy sub why sub i mean % Ivatar has left Ivatar!~graham@tu055.demon.co.uk r27356 | jonathan++ | trunk: : [rakudo] Bug fix to protoobject ACCEPTS change from earlier. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27356 the use of "compilation unit" in pdd19 is _really_ confusing. % wknight has left wknight!~chatzilla@c-71-230-33-251.hsd1.pa.comcast.net We just lost power here (I'm on cell now) so I'm going to run some other errands for a while back in an hour or so notebook+gprs+bluetooth == priceless % Ivatar has joined #parrot (actually, I guess it has a price. $20/month.) back later. Theoretically, every non-system include in a parrot .c file should be reflected as a dependency in the top level Makefile, neh? (but is less crucial than catching generated fiels) is there a makedeps prog that can be used to figure those out? or scandeps well, scandeps is really much more aggressive. scandeps is perl. neh? i don't recall. however, eight years ago i had a c utility to follow the #include chains % ambs has joined #parrot can't remember what it was called chromatic: did you add an opcode but not renumber the ops? (is that kosher?) % mj41 has joined #parrot r27357 | allison++ | pdd25cx: I added to experimental.ops, which I believe is okay. : [pdd25cx] Move exceptions over to the concurency scheduler, mainly keeping the : same interface while ripping out the guts. : * Changed 'push_exception' to 'Parrot_cx_add_handler'. : * Moved 'run_cleanup_action', 'Parrot_push_action', 'Parrot_push_mark', : 'Parrot_pop_mark' out of src/exceptions.c into src/stacks.c. : * Changed 'count_exception_handlers' to 'Parrot_cx_count_handlers_typed'. : * Deleted 'get_exception_handler' function and 'get_eh' opcode. : * Deleted 'get_all_exception_handlers' function and 'get_all_eh'. : * Replaced 'pop_exception' with 'Parrot_cx_delete_handler_typed' (new : function) in all found uses. chromatic: k. : * Several header changes from rerunning 'make headerizer'. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27357 Oh dear, make headerizer. Some of those changes likely break things. chromatic: I had to revert one file I've seen it eat #ifdefs TapTinder blame chromatic ... http://tt.perl6.cz/ .. two newly failing tests in 27355 :-) ooh, nifty. does that really build every version? yes allison@perl.org | Concurrency Tasks: link: http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks dalek's url is at http://xrl.us/bjqpy will@coleda.com | Concurrency Tasks: link: http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks dalek's url is at http://xrl.us/bjqpy r27358 | chromatic++ | trunk: : [t] Fixed test breakage caused by r27355 (reported by Michal Jurosz). diff: http://www.parrotvm.org/svn/parrot/revision?rev=27358 % rillian has left rillian!~giles@mist.thaumas.net mj41: ooc, does it do them sequentially, or does it do the latest one and then backfill? is it smart enough to skip commits that happen on branches? \msg Coke it is too stupid now % particle[ventus] has joined #parrot http://mj41.cz/wiki/TapTinder added taptinder to the resources page on the website. taptinder wiki is http://mj41.cz/wiki/TapTinder allison@perl.org | Concurrency Tasks: link: http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks dalek's url is at http://xrl.us/bjqpy % ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt % davidfetter has joined #parrot % rhr has joined #parrot % jq has left jq!~jquelin@merlin.mongueurs.net % jq has joined #parrot % particle[ventus] has left particle[ventus]!~particle@c-24-19-3-148.hsd1.wa.comcast.net % davidfetter has left davidfetter!~chatzilla@start.fetter.org % teknomunk has joined #parrot % gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net % gryphon_ has joined #parrot % cotto_work has left cotto_work!~cotto@tide534.microsoft.com % cotto_work has joined #parrot * Jonathan is back from having something try to inject the Slovak language into his head. :-) % particle[ventus] has joined #parrot % rdice has left #parrot % cjfields has left cjfields!~cjfields@cjfields.igb.uiuc.edu % Sartak has left Sartak!~sartak@69.25.196.249 % barney has joined #parrot % cjfields has joined #parrot % Sartak_ has joined #parrot % Sartak_ is now known as Sartak r27359 | jonathan++ | trunk: : [rakudo] Parse scoped routine declarations, and stub into actions.pm with panics all of the things that we need to fill out to implement these. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27359 % barney has left barney!~bernhard@dslb-084-058-164-032.pools.arcor-ip.net % cjfields has left cjfields!~cjfields@cjfields.igb.uiuc.edu % mire has joined #parrot I'm again getting the "Cannot put to non-PIO PMC" error message. Should I try to track it down? or just remove and start over? in the odd "FWIW" category, "svn status" shows a spurious src/io/io.str file. That .str file probably needs to be in the ignore thingielist. barney usually fixes those for me. AHA! pmichaud: a friend tell me that deleting all and reloading from cvs solved the issue for him. is io.str in the clean list? Should be. NotFound: yes, that's what I did earlier as well. But I was wondering if I needed to go further. Probably isn't. I suspect it isn't and that there's a new constant string in io that wasn't there before. yah, c just added io.str, IIRC and since we don't have .str deps marked, .... isn't io.str auto-generated? We do, if you reconfigure. I did a make realclean. same here followed by perl Configure.pl and make % Andy has left Andy!~AndyL@host3130.follett.com and then got the repeating error message lwall++ # sane answer to my types question aha, my strategy worked. :-) aha, make realclean *fails* it do? it don't here. I blame society. Think I have one follow-up question from it, but I'll look at it again when it's not after midnight and I haven't had a one and a half hour Slovak lesson. :-) "pmichaud" at 76.183.97.54 pasted "'make realclean' fails in trunk" (10 lines) at http://nopaste.snit.ch/12907 I think that's about all from me today...pretty tird now. s/tird/tired/ % lidden has joined #parrot That warning seems to think you didn't finish config'ing the first time. hurm. Agreed. I haven't done anything odd beyond a svn up Is your computer on drugs? let me try again Should it be? Today's report: http://use.perl.org/~JonathanWorthington/journal/36343 % iblechbot has left iblechbot!~iblechbot@ppp-62-216-207-123.dynamic.mnet-online.de jonathan++ ahh now I'm getting that error. I blame chromatic. I'm part of society. Them too. :-) r27360 | coke++ | trunk: : [repo] : ignore newly generated .str file in src/io diff: http://www.parrotvm.org/svn/parrot/revision?rev=27360 (that's just the ignore, not the clean) ... our .str remove is globs instead of specifics. Grumble. ... we already *have* the list... Ok. realclean now removes src/io/io.str. % particle[ventus] has left particle[ventus]!~particle@71-212-101-214.tukw.qwest.net would anyone else like to see how the props changed in our commit emails? r27361 | coke++ | trunk: : [build] : When removing generated STR files, just remove the ones we know about, : so we don't have to maintain the list of deps -and- the list of things : to remove. (same list!) - this catches the newly added src/io/io.str diff: http://www.parrotvm.org/svn/parrot/revision?rev=27361 I am hoping it was the remove of src/io/io.str that did it; seems to work now. mine was working for a while too and then re-appeared. but we'll see if it happens again. Yeah. Mine too. Mine too. are you approaching 1800 now? I left 1800 about 208 ago. HEAD still doesn't work moritz: you may need to rm trunk and re-checkout don't say HEAD. say R27361. at some point an svn up should work. =-) pmichaud: already did that once moritz: are you doing a realclean? uh oh, guess what. Just got it again. Coke: yes r27361. svn up; make realclean; perl Makefile.PL && make smoke ok. try regen'ing the makefile from 27361 and then doing it again. that is, re config, then realclean, then config and build. (since the makefile you ahve before the svn is now out of date.) Hi, make realclean, configure, and make <--> error reappears .. ok, I'll try taht paco:see what I just said. =-) * pmichaud shudders at the thought that this might be ccache-related again. I've never had a ccache problem. I recall several months ago where I had a problem that was reproducible when using ccache and I disbelieved pmichaud when he said he did, but it was reproducible for him. yup. seems ok for me now, and I was seeing it before. aye built worked, smoke is running chromatic: I need some variant of 53430 and 53406 pretty soon -- and they have a conflict. So, can you apply 53406, and then let me know if my response to your 53430 objection was acceptable, so I can regenerate that patch and get *it* committed? I'll look at it. % davidfetter has joined #parrot chromatic: thank you! Hm, the problem is that the .str file for src/io/io.c points to the wrong entry in the constant table. all the time, or only when it's leftover? When I do a realclean and then a parallel build. Probably then it's not getting cleaned up appropriately. ... but it's in STR_FILES. % davidfetter has left davidfetter!~chatzilla@start.fetter.org If I change the .str file to have the correct line number and touch src/io/io.c and rebuild, things are fine. ahh. I think I found it. That should do it. dalek, ping r27362 | chromatic++ | trunk: : [config] Added a dependency to src/io/io.c on src/io/io.str; missed in r27340. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27362 chromatic: works here. It was two parts. First, Coke's patch cleaned up the old src/io/io.str file. % tetragon has joined #parrot Second, my patch made rebuilds happen based on changes to that file. % Ivatar has left Ivatar!~graham@tu055.demon.co.uk The funny thing is that don't failed for me until the previous. chromatic: This morning's patch brings my usual test crash count down to five (and I think the hcf sigbus is intentional) I agree about hcf. I'll try to get you down to four this week. % gryphon_ has left gryphon_!~gryphon@dsl-209-221-185-54.zipcon.net % davidfetter has joined #parrot % NotFound has left NotFound!~julian@50.Red-213-96-228.staticIP.rima-tde.net % Sartak has left Sartak!~sartak@69.25.196.249 % teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net % Sartak has joined #parrot chromatic: ah. normally that would be handled by the rule of .str -> .c, but since there was already an explicit dep there... I do find it odd that gmake at least isn't smart enough to infer the generic when you have the specific too. One probably overrides the other. Shirley. Just annoying. ...and don't call me shirley! % Sartak has left Sartak!~sartak@69.25.196.249 r27363 | pmichaud++ | trunk: : [pct]: : * Revert the earlier change for throwing an exception on non-existent : subs, as Parrot now handles it for us. (chromatic++) diff: http://www.parrotvm.org/svn/parrot/revision?rev=27363 r27364 | pmichaud++ | trunk: : [rakudo]: : * Fix trailing whitespace coding error. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27364 r27365 | chromatic++ | trunk: : [src] Tidied the code slightly and documented some undocumented functions. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27365 where is the best place to learn about coroutines? PDD19? google for coroutine sandwich? is that really a term? er, no. That's a "continuation sandwich". sorry. =-) * tetragon puts away the bread and jam "sandwich"? Really? I mean, that's not exactly a technical term Yeah, but it explains how continuations work. it was the first time I thought I knew what a continuation was. =-) sandwich? rumour has it sandwich is a sandwich. The styles are very different a sandwich is also a continuation sandwich. Yum! okay, Coke. I was trying to figure out how parameters were handled if you passed them into the coroutine on successive calls experimentally, it looks like parameters are only passed the first time, and successive parameters passed are ignored Sounds right. okay, i was just making sure i was understanding things right. In the interests of reducing the number of patches I manually apply every day, has anyone looked at the second patch in #53402 (I know it fails codingstd). It lets my parrot builds display function names in backtraces instead of '(unknown)' I'd rather see that in a header with a macro, but it looks reasonable otherwise. chromatic: http://rt.perl.org/rt3/Ticket/Display.html?id=37323 is closable, neh? Parrot_print_backtrace? tetragon, I just don't like #ifdef in .c files. % Sartak_ has joined #parrot Coke, go ahead. chromatic: Those ifdefs were there when I got there. in src/exceptions.c? Yes Huh. The patch confuses me then. Although I do consider moving the #include to the header I'd define a macro FIND_BACKTRACE_SYMBOL(i) and #ifdef it. % shorten has left shorten!~xrl@203.141.139.231.static.zoot.jp Parrot_print_backtrace doesn't to single symbols, it does a full backtrace the strchr/strings part gets a single symbol though. strchr? Oh, the code my patch replaces Yep. The old code gets a human-readable backtrace out of backtrace_symbols and parses out the symbol names My patch rips that out and replaces it with dladdr calls Ah. I'm looking at the first patch in the ticket then. I haven't seen any others. There is a second patch there I use it Alright, I'll read that one instead and stop confusing us both. Looks decent to me. The second patch doesn't add any ifdefs Although I think the #include would probably be better in a header Just thinking the same thing. If you resubmit a patch with the include in a header, I'll test and apply. There's also a pre-existing ifdef at the top of exceptions.c with an include in it It could go there then. * tetragon ponders to what extend the code is still "stolen from http://www.delorie.com/gnu/docs/glibc/libc_665.html" % shorten has joined #parrot I've added a new version The defines are PARROT_HAS_BACKTRACE and BACKTRACE_VERBOSE; are they isomorphic? From what I see, BACKTRACE_VERBOSE only affects things when PARROT_HAS_BACKTRACE is set Thought that might be the case. And the only time I've seen BACKTRACE_VERBOSE set is the time I uncommented the define for a test I think the only way to set it is to edit the source/Makefile Testing now. % kid51 has joined #parrot r27366 | chromatic++ | trunk: : [src] Removed a fragile glibc-ism from Parrot_print_backtrace() (Seneca : Cunningham, RT #53402). diff: http://www.parrotvm.org/svn/parrot/revision?rev=27366 chromatic: 9 tickets to go. I just closed another. Down to two patches to apply every day (but those two aren't nearly as nice as that one) 8. I would not be heartbroken to see pirtidy.pl and the associated ticket vanish, if the goal is to eventually do this with something else. % sjansen has left sjansen!~sjansen@hq-nat2.gurulabs.com Coke: "tickets to go"? We're trying to get below 700 new+open for the next release. should probably send out an email, though you're nearly there. kid51 just closed one. lucky number slevin. * Coke wanders off to eat his last medifast ''meal'' of the day and have some lovely parting insulin. chromatic: you can get another knocked off by applying 53406. ;-)\ % davidfetter has left davidfetter!~chatzilla@start.fetter.org I'm weighing the BigInt options there. chromatic: fair enough How much work is there to use BigInts for this at the moment? Also how much is this blocking you? chromatic: I dunno re: BigInt. I was not the one that created that patch; I merely requested *some* way to handle 'long long', and that patch looked decent to me. % particle[ventus] has joined #parrot chromatic: as for blocking me, I need the 'long long' functionality soon but not immediately. However, I *do* want to get my patch (53430) unblocked, because I have more urgent stuff waiting on *that*. Alright, I'll ask Mark to look into the BigInt stuff. I know you had an objection on 53430, and I responded, but I didn't see a response from you, which would tell me whether I should A) resubmit with just my suggestion handled, B) resubmit with my suggestion plus 53406 conflict handled, or C) something else entirely. japhb: Like fixing up the linking of the GLUT callbacks so that make doesn't fail when I hit them in a no missing symbols allowed build? tetragon: huhwhat? % Theory has joined #parrot It's been mentioned a couple of times (I've been stuck in RL for a few days) japhb, I can live with core.in, opengl.in, and misc.in. chromatic: OK, cool. So I'll regen with just that change, and expect 53406 to be handled later when the BigInt change is made? If I tweak my build flags so that '-undefined dynamic_lookup' is not set (in other words, throw an error on an undefined symbol), my build trips over the callbacks japhb, sounds reasonable to me. chromatic: OK, cool, thank you. For what it's worth, the three-file approach you suggested sounds like the best fit overall. I just hadn't thought through all of the implications until now. :-) It solves another problem we'll run into eventually, so I'm sold. chromatic: Good! But what's the other problem? Knowing which thunks we need for a core even if we disable NCI in general. chromatic: ah yes, I had suspected from comments in a couple places that might be the case. Sounds like my hunch was right. japhb: And with "make -j2" it even tries to find symbols that haven't even been built yet tetragon: Your issue is the do_panic stuff, as I recall? IOW, stuff that comes from libparrot.so Which is neither built yet nor included in the linker flags tetragon: OK, I'm working on an API improvement to the callbacks anyway, I'll try to address the symbol problems as part of the same patch. The default OS X builds get past this point as they put off handling undefined symbols until runtime % chromatic is now known as chromatic_mowing_la tetragon: ... but I gather that's suboptimal, and you'd like to get away from that And _do_panic is the hidden symbol you depend upon Doing away with the undefined symbol situation would have the side effect of stopping editline from tricking the readline test and causing "scary" messages from appearing to the builder tetragon: did anyone ever answer my question about A) making panic part of the parrot API, or B) a better way for a lib to panic in a parrot-friendly way? I didn't see anything * japhb may just print to STDERR and exit(), just to unblock you. (blocked developers)-- Simply resolving do_panic still doesn't help with the other libparrot symbols you depend on while omitting the link flags can you paste a list? (you probably did so before, sorry I've lost it) The other symbols are exported by libparrot _PMCNULL and _Parrot_runops_fromc_args_event Although, libparrot doesn't exist yet. afk for a sec, brb % mire has left mire!~Frodo@252-172-222-85.adsl.verat.net bak r27367 | chromatic++ | trunk: : [src] Made data member of Stack_Chunk_t a Stack_Entry_t, not a void pointer : (Andy Dougherty, RT #53264). diff: http://www.parrotvm.org/svn/parrot/revision?rev=27367 % Sartak_ has left Sartak_!~sartak@69.25.196.249 % Sartak_ has joined #parrot % Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net chromatic: 27367 missing a file commit? Parrot HEAD is not building for me, dying in src/stack_common.c , claiming a mismatch with include/parrot/stacks.h . paste? i think paste is (see: nopaste) or like glue but a little safer to sniff. or http://nopaste.snit.ch:8001/ or http://scsys.co.uk:8001/ anywhere shadowpaste is or mmm, sticky paste or You there! Eating the paste. or 2 girls, 1 paste "japhb" at 76.191.190.8 pasted "Build failure with r27367" (11 lines) at http://nopaste.snit.ch/12908 wknight8111: iiuc, the arguments sent to a .yield(...) call become the return values for the coroutine's call. (from scrollback) I think I might be able to close a few tickets tonight for one, I think that #49972 is now resolved. chromatic: 53430 patch now regenerated and resubmitted. "tetragon" at 76.10.171.227 pasted "Same build failure, but using "make -j2" on OS X 10.5" (18 lines) at http://nopaste.snit.ch/12909 I'm getting the same error as tetragon % janus has left janus!~janus@e182074079.adsl.alicedsl.de I think it's just that include/parrot/stacks.h didn't get updated "kid51" at 70.107.11.144 pasted "r27367: Similar build error for 'make' on linux" (13 lines) at http://nopaste.snit.ch/12910 I think I have r27367 fixed -- running 'make test' now and then committing % teknomunk has joined #parrot r27368. r27368 | pmichaud++ | trunk: : [core]: : * Get include/parrot/stacks.h to match changes made to src/stacks.c : in r27367. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27368 % janus has joined #parrot 27368 worked for me on linux * kid51 must sleep $kid51->sleep(8 * 3600); % kid51 has left kid51!~jkeen@70.107.11.144 r27369 | pmichaud++ | trunk: : [pge]: : * Fix handling of <.ws> rule in OPTable parsing (resolves RT#52718). diff: http://www.parrotvm.org/svn/parrot/revision?rev=27369 six to go. r27368 builds on OS X 10.5 % japhb has left japhb!~geoff@76-191-190-8.dsl.static.sonic.net % japhb has joined #parrot wheee ... OpenGL app + Flash for Linux + nVidia drivers = kaboom Well, at least Adobe is opening their Flash specs; I can hope for that to suck less some day. Anyway, 27368 working on Linux/i386 % parrot-poke has left parrot-poke!~mollusk@user-112vvlr.biz.mindspring.com % wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net % davidfetter has joined #parrot % tetragon has left tetragon!~seneca@76-10-171-227.dsl.teksavvy.com r27370 | pmichaud++ | trunk: : [core]: : * Fix mul and n_mul opcodes for subclassed objects. : Resolves RT#53108. : (The other math ops apparently already worked.) diff: http://www.parrotvm.org/svn/parrot/revision?rev=27370 five to go. resolved RT#48507. four to go. % tetragon has joined #parrot % Theory has joined #parrot % Psyche^ has joined #parrot % Patterner has left Patterner!~Psyche@e177224094.adsl.alicedsl.de % Psyche^ is now known as Patterner I think we can close RT#39329. If we send PMC_str_val to the underworld where it belongs.... Provided we follow PDD 17, we should be fine. what would you do if it comes back as a zombie or undead? Call Shaun. Head trauma. % Theory has left Theory!~Theory@c-24-21-175-208.hsd1.or.comcast.net OK, I'm ready to submit some OpenGL improvements that depend on 53430. I'm applying and testing now. % chromatic_mowing_la is now known as chromatic I'm in the distro tests and everything's passing. Looks good. O_O Cool beans Ahh, missed the coda in config/gen/call_list.pm chromatic: hmm? The final five lines of config/gen/config_h.pm I know it's six, but I like saying Final Five. # End: is a Cylon Oh, duh. I had been thinking "No coda on a generated file", but mentally crossed that with "No coda on the *generating* file" Sorry about that. Who maintains Rakudo.org? No problem, the test caught it and it was easy to fix. r27371 | chromatic++ | trunk: : [NCI] Split NCI signatures into core, misc, and opengl groups. : Removed src/call_list.txt, which is now a generated file. : (Geoff Broadwell, RT #53430) petdance, I believe. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27371 seen petdance petdance was last seen on #parrot 49 days ago, saying: no, the IRC client at work is Andy [Mar 18 22:19:01 2008] Hmmmm. Jonathon's example in his latest post on rakudo.org doesn't make any sense, because the code is not properly HTML escaped, so has missing stuff when rendered. I might be able to fix it. Nope. seen Andy Andy was last seen on #parrot 1 day and 14 hours ago, saying: Oh, I don't know of this editor you mean. [May 5 08:15:11 2008] r27372 | chromatic++ | trunk: : [config] Made generated src/call_list.txt file read-only, to remove some : temptation to edit it instead of config/gen/call_list/*.in. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27372 r27373 | chromatic++ | trunk: : [src] Added the final part of the missing patch in r27367 and r27368. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27373 % grim_fandango has left grim_fandango!~matt@bas2-kingston08-1177655568.dsl.bell.ca % Sartak_ is now known as Sartak OK, just submitted the patch I was blocked on. chromatic, thank you for unblocking me. :-) You're welcome. % chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net % teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net % particle[ventus] has left particle[ventus]!~particle@c-24-19-3-148.hsd1.mn.comcast.net % uniejo has joined #parrot STD.pm is in the pugs repo, right? Ah, looks like yes. Okay, both rakudo's grammar and STD.pm have this line in token methodop: | ':' t/spec/S29-list/minmax.t has the following, though: is @array.min:{ $^a <=> $^b }, -9, Which doesn't parse, because there's no whitespace after the : Is the test wrong? Should I update it? purl: rakudobug? i think rakudobug is mailto:rakudobug@perl.org purl++ % JordanG has joined #parrot Looks like there are 58 instances of that in t/spec. getting parrot to build w/ cygwin is a bit of a pain, isn't it... huh... that might be because I'm somehow missing files... there should be a libparrot.dll in parrot/blib/lib, right?