good morning, jonathan % cognominal_ has left cognominal_!~cognomina@AToulouse-152-1-14-122.w82-125.abo.wanadoo.fr Just about to leave for the venue. % davidfetter has left davidfetter!~chatzilla@start.fetter.org % kdc has joined #parrot % tiglionabbit has left tiglionabbit!~root@67-207-136-95.slicehost.net % teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net * jonathan arrives pmichaud: If you are using setprop etc to set the type on the mutable, why are you then having them forwarded? I'm not having them forwarded. they were being forwarded before my change in r27954 r27945 looked that way...let me look again. Oh man, are you relying on my hacky Perl script's stupidity to not know about comments?! so far, yes. :-) :-O That's sick. :-) I do some sick things from time to time. I'm still getting a variety of segfaults Even with -G? so what I thought I would do is to complete the merge, but with a simple switch so that we can use either the existing non-Perl6Scalar version or the Mutable then we can keep playing with Mutable in trunk, without that being the default OK Hmm How many are you getting, and where? just a sec, I'll try spec_regr again "make test" still passes. Weren't we down to just one failing test earlier? I think I'm still at one failing test (the same one) but things fail when we start doing my Int $a; (which spectest_regression isn't doing much of.) Grrr. Grrr? woof! I had got that to work nicely in my original branch. To the point that with roles and constraints it was more correct than trunk. Hmm I haven't changed *that* much of the code. Your hack is too evil. perl6scalar.obj : error LNK2001: unresolved external symbol _Parrot_Mutable_setp rop Breaks the build on Win32 Unless you have uncommitted fixes? not for that. ...how could we end up with an unresolved extern? unless it shows up in the .h file but not the .c make clean, perhaps? yeah, sorry, didn't do make clean works now OK, you switched to storing the type with setprop ? Rather than giving a parameter to new that provided the init into? s/into/info/ yes, for a variety of reason s OK, where to properties get put now? getprop and setprop :-) Which sticks them....? in a hash every PMC has a properties hash (or _can_ have one, if setprop is used) OK, so ATTR PMC *properties; is now redundant and we should be doing lookups through a vtable call now? the problem you're running into Is that init_pmc sets up various things But you're providing the type info too late now. oh, I have a change for that. (uncommited) ok here, I'lll commit. ok, thanks, I'll have a look r27956 | pmichaud++ | mutamerge: : [mutamerge]: : * More conversions for 'type' property and Mutable initialization. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27956 (I get quite a few failures in the mutablerakudo branch, fwiw) Sure, there were 4-5 spectest_regression that failed I wasn't sure how much of that was being behind on changes to trunk, though. about 8 now. Right. the PMC parameter to 'new' is now the initial value for the Mutable as opposed to a properties hash Ah, OK That un-does the "is it a proto-object" logic, but I can put that back later. well, I know when it's called that we have a proto-object, at least at this point. I haven't figured out when we end up with a Junction of types. (i.e., what Perl 6 code produces it) $( $[0] ) - might be a role or subset too In which case we need to store an undef Oh, you took out the junction stufff? it's easy to put back Sure. (it's still there at the bottom) OK It's for my Mouse Explosive $danger_mouse; Like, it has to be an instance of Mouse and do the Explosive role. :-) and in that case it's initialized to undef also? It's * in the grammar to let you have many Yes If the thingy isa proto-object, it's initialized to that. okay. I think we should do that logic in actions.pm instead of Mutable Yeah, eventually it needs to interact with a class registry too. So for that it needs to be in actions.pm. I just stuck it in the pmc_new for the time being, since it was easy. :-) I think Mutable should simply initialize to a value, or be undef. If you have my Foo $x, and Foo is a proto-object, it initializes to that. Otherwise, it's undef. I'm also wondering if perhaps Mutable shouldn't initialize value at all, but simply keep track of the initial type somewhere to use if it's accessed before assigned I'm pretty sure that was the upshot when I asked for clarifications on p6l about this. Could be an optimization, yes. well, I'm not sure it's an optimization since basically every vtable method has to check to see "am I initialized?" Hmm, true. Yeah, you're right. Maybe we shouldn't do that. :-) BTW, the changes to VTABLE assign method are a tiny bit suboptimal. what would be really cool would be to have an object that replaces itself upon initialization :-) Because if you have an untyped variable, it goes to the properties hash every time. But let's get the semantics right first, anyways. yes, I hadn't quite worked out how I wanted to get around that. Well, it makes typed variables more efficient than untyped. ;-) well, not really :-) because a typed variable calls DOTYPECHECK True. :-) and I guarantee that's likely to take longer than the property lookup :-) Also true. :-) we could possibly make a NULL vs. PMCNULL distinction Mwahaha. mwahaha is probably at http://jerkcity.com/jerkcity1983.gif i.e., initialize it to NULL, then on first assign change it to PMCNULL Evil. :-) But I like it. It's fine by me, provided we put a comment in explaining. it's nice to have so many sentinels to choose from :-) OK, so how far do you feel we are off mergning? I know it will break stuff in trunk (parameter type checking etc) that I want to demonstrate in my talk this morning. is the stuff in trunk currently working? % bgeron_ has left bgeron_!bgeron@toad.stack.nl i.e., after the changes I did the past couple of days? And I'm going to be inviting people to check out trunk and make their own Rakudo. Yeah. With -G. :-S weird. well, that's gotta be all parrot bugs then, because trunk isn't using any custom PMCs beyond perl6str Oh, hmm It was yesterday. it's not working now? yeah, but I didn't remember doing svn up (merge, long story): PHP is a minor evil perpetrated and created by incompetent amateurs, whereas Perl is a great and insidious evil, perpetrated by skilled but perverted professionals. I'm not sure how long it will take us to chase down the various segfaults. It could be simple, but it could also be a while OK I'm not sure, where they are happening so that's why I was aiming towards the "easily switch between Mutable and non-Mutable implementation" approach Oh, I see the breakage - Perl6Str does odd things with ACCEPTS sub foo(Int $x) { say "ok" } foo(42) ok foo(4.2) Parameter type check failed It's some issue specific to string type. I'm not seeing where strings enter in to this. foo("hi") # incorrectly works Ah, my original example was with foo("hi") * bacek just read gc_gms_*... I think let's see why the segfaults Try and find them quickly, if possible. % cognominal has joined #parrot okay. I was going to go ahead and finish up my Mutable switch. I'm scared, of breaking trunk then telling people to check it out. ;-) well, I'm not in rush to merge right now OK Which tests are segfaulting? it can wait a day or so Or simple test case? Ok, great. I can work on the segfault between talks. no tests are segfaulting (more) > my Int $a; say $a.WHAT; Int > my Int $a; $a = 3; say $a.WHAT; [oops; continuation 0x83375a8 of type 22 is trying to jump from runloop 571 to runloop 50] Unknown PMC type to thaw 0 > (segfaulting being a generic term for "totally unexpected behavior") Oh, not realy segfault. well, I see those from time to time also. Ugh. It's still there with -g? er, -G I'm running with -G now, and yes, still there with -G ok, at least it's not just GC bug then hmmmm > my Int $a; _dumper($a); "VAR1" => PMC 'Int' { ... } with-properties: Hash { "type" => PMC 'Int' { ... } } okay, that's what I expect. but > my Int $b; $b = 3; _dumper($b); "VAR1" => PMC 'Int' { ... } > is not what I expect. The properties disappeared. Odd % iblechbot has joined #parrot oh, it's not doing the :multi(Perl6Scalar, _) like it was earlier Ah, OK I just went through the properties code in default to check that it doesn't call any vtable functions we are forwarding. it doesn't, does it? (I looked it over, but didn't think about those having vtable calls of their own) No, it doesn't from what I can see. It would have been a logical source of the problem (e.g. it was setting the props on the value), but it seems to not be that. actually, I think dumper is lying to me that it's still a Scalar and still has properties Ah How so? just a sec (preparing nopaste) ok oh I got a segfault actually, a failed assertion. "pmichaud" at 76.183.97.54 pasted "failed assertion" (48 lines) at http://nopaste.snit.ch/13124 it's somewhere in _dumper. % AndyA has left AndyA!~andy@82.152.157.85 $P2 = new 'String' $P2 = 'xyz' setprop $P0, 'type', $P2 That looks bogus. how so? type is not expected to be the name of the type It's meant to be a proto-object, role or subset type ohhhhh duh $( $ ) gives those :-) you're right I was testing something different (which won't work) All the same, it shouldn't fail that nastily. and it shouldn't fail prior to the assign. (which it does.) because all I'm doing is setting a property. yeah we don't actually *do* a typecheck until the assign. Right. So it shouldn't matter until then. I think it's a bug in dumper, actually "pmichaud" at 76.183.97.54 pasted "failed assertion trace" (23 lines) at http://nopaste.snit.ch/13125 "clone S1, S0"?!? oh, I see where it's coming from. something's null. get_params PC13 (3), P2, S0, P1 PC13=FixedIntegerArray=PMC(0x837f180) P2=PMCNULL S0="(null)" P1=PMCNULL That's wrong wrong wrong. Yes. oh Should be PMCNULL that's the same problem I was seeing earlier and that we have with the one failing spectest callmethodcc loses the arguments. No set_args PC25 (3), P0, S1, P1 PC25=FixedIntegerArray=PMC(0x837eec4) P0=Object(Data::Dumper::Default)=PMC(0xb747e12c) S1="(null)" P1=Undef=PMC(0x83370c0) S1 was null going into the call oh. Unless it lost them some way back Look a bit further back in the trace % bacek has left bacek!~bacek@123-243-38-218.tpgi.com.au looking Oh, it's S1, not P1, so wouldn't be PMCNULL % bacek has joined #parrot OK, giving 2 hour Perl 6 tutorial starting in a few mins. So will be away for a bit. okay. I should probably get some sleep. yeah! it's late where you are 03h35 % AndyA has joined #parrot % barney has joined #parrot % kdc has left kdc!~calbert@ip68-100-47-41.dc.dc.cox.net r27957 | pmichaud++ | mutamerge: : [mutamerge]: : Fix .ACCEPTS method in P6object so it doesn't over-eagerly : match strings. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27957 I'm not the only evil code writer :-) % AndyA has left AndyA!~andy@82.152.157.85 % AndyA has joined #parrot bernhard.schmalhofer@gmx.de | Plumhead: link: http://www.perlfoundation.org/parrot/index.cgi?plumhead r27958 | pmichaud++ | mutamerge: : [mutamerge]: : * Finish the 'switch between Mutable and non-Mutable'. : * This commit is not using Mutable, although the code : remains close to the same. Modify the $?PERL6SCALAR : variable in src/parser/actions.pm to switch between : them. : * All spectest_regression tests pass with this version. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27958 r27959 | pmichaud++ | mutamerge: : [mutamerge]: : * ....and this version works when using Mutables for Scalars. : * All spectest_regression tests pass. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27959 jonathan: r27959 in the mutamerge branch passes all spectest_regression tests. ...off to bed... r27960 | bernhard++ | trunk: : [Plumhead] : Add test for case sensitivity of variable names. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27960 % Whiteknight has joined #parrot applauses for jonathan++ % cognominal has left cognominal!~cognomina@auteuil.enstimac.fr % allison has joined #parrot r27961 | bernhard++ | trunk: : [Plumhead] : Add a TODO-test for string interpolation. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27961 % masak has joined #parrot % iblechbot has left iblechbot!~iblechbot@238.17-dial.augustakom.net % ejs has left ejs!~ejs@98-237-124-91.pool.ukrtel.net r27962 | allison++ | pdd25cx: : [pdd25cx] Allow pragma subs to resume after a handled exception by returning to : an outer runloop. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27962 % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot % bgeron has joined #parrot % cognominal has joined #parrot From which PCT-based language can I steal string interpolation? Perl6 looks too involved. Cardinal seems to have no variable interpolation. pmichaud++ # mutamerge :-) % NotFound has joined #parrot Hello. bonjour hey, jonathan. japhb: ping r27963 | bernhard++ | trunk: : [ecmascript] : Arguments to subrules need to be quoted. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27963 % Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net r27964 | bernhard++ | trunk: : [Plumhead] : Allow digits in variable names. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27964 % iblechbot has joined #parrot % IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk r27965 | bernhard++ | trunk: : [Plumhead] : Simplify the IDENT rule diff: http://www.parrotvm.org/svn/parrot/revision?rev=27965 % kid51 has joined #parrot % AndyA has left AndyA!~andy@82.152.157.85 % AndyA has joined #parrot % kid51 has left kid51!~jkeen@68.237.2.121 % ambs has joined #parrot % kid51 has joined #parrot % cognominal has left cognominal!~cognomina@auteuil.enstimac.fr % jimk has joined #parrot % kid51 has left kid51!~jkeen@70.107.4.239 % davidfetter has joined #parrot % cognominal has joined #parrot r27966 | bernhard++ | trunk: : [Plumhead] : Add todo test for references. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27966 % barney has left barney!~bernhard@dslb-084-058-129-010.pools.arcor-ip.net % Ademan_ has joined #parrot % Ademan has left Ademan!~dan@h-69-3-232-86.snfccasy.dynamic.covad.net % IllvilJa has joined #parrot % Ademan_ has left Ademan_!~dan@h-69-3-232-86.snfccasy.dynamic.covad.net % allison has left allison!~chatzilla@dsl-241-62-167.telkomadsl.co.za r27967 | jkeenan++ | codetests: : Eliminate all instances of from this file only. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27967 That was $(PARROT_ARGS) that was eliminated from that file. % jimk has left jimk!~jkeen@pool-71-247-52-140.nycmny.east.verizon.net % kid51 has joined #parrot % Ademan_ has joined #parrot % kid51 has left kid51!~jkeen@pool-71-247-52-140.nycmny.east.verizon.net good morning and a lovely morning to you too, pmichaud morning * jonathan has survived all of his talks bar a lightning talk running commentary was that the talks were excellent They were fun to give. "jaws are dropping" :-) I haven't had chance to look at the segfaulting fun yet. it might not be there any more :-) Just built the latest of the mutamerge branch Oh So did you do the merge yet? no -- wanted to give you a chance to play with it first and see what errors you could find (I"m like you -- I don't like breaking too much in trunk because then people who check it out may be disappointed) Let me run the tests on Win32 to make sure they pass consistently for both of us. but most of the tests I ran were doing fine % ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt I need to write more tests for some of the features we don't yet test in spectest_regression. But that work. (Like subset.) > my Int $a; $a = 'hi'; Type mismatch in assignment. (And type checking. And .*, .+...) Ah, good. :-) That was broken in trunk, I think. yes, the default .ACCEPTS method in P6object was a little overeager :-) hehe "It's a string! Okay!" You did check your changes, didn't break matching grammars. ? Something else, I fear we have no test for, but should work. Let me run my Perl 6 RPN calculator in the mutamerge branch...that'll soon tell us. I didn't check that. But I was thinking that matching grammars might in fact be an overload of infix:<~~> and not something that .ACCEPTS does That'd be a cunning stunt. I was thinking that we could create an t/03-misc/ directory where we can throw tests that aren't yet ready for t/spec/ Cool I throw them there, and @aother spec-test-ifies them. :-) Delegation! it has been said that delegation is the handler chain And second pair of eyes, more importantly. well, we could perhaps get Auzon++ to look at them as a source of tests for his work, too. Aye. OK, all testsw pass here. yay! * pmichaud celebrates. But geck. My RPN evaluator is br0ked. :-( I suspect, on grammar matching. nopaste? rumour has it 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 or App::Nopaste or tools/dev/nopaste.pl "jonathan" at 194.167.199.29 pasted "un-rpn" (46 lines) at http://nopaste.snit.ch/13126 Just try 3 5 + But minimal test case is this: grammar Test { rule TOP { \d+ } } if "42" ~~ Test { say "ok" } Doesn't print ok okay, I'll fix that. Awesome (BooK is giving too amusing talk to concentrate on code!) % tetragon has left tetragon!~seneca@216.126.67.44 % tetragon has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Whiteknight has joined #parrot % Zaba has joined #parrot % allison has joined #parrot pmichaud: Back now, from coffee + lightning talk slide hacking. % davidfetter has left davidfetter!~chatzilla@start.fetter.org okay. I'm reworking .ACCEPTS a bit. (also taking a short break for breakfast :-) A fast break ;) % iblechbot has left iblechbot!~iblechbot@111.4-dial.augustakom.net % Limbic_Region has joined #parrot % masak has left masak!~user@130.238.45.242 % particle has left particle!~particle@c-98-232-7-104.hsd1.wa.comcast.net % particle has joined #parrot pmichaud: I found that using roles as type names doesn't work, but I don't think this is a result of the Mutable branch, but rather earlier work in trunk. I will fix this after the merge. okay I suspect you're correct. I suspect it's the P6object stuff that broke it. It's maoning about a missing .item in fact. oh, then it's the changes to support list/hash/scalar context Aye man. Well, I will be having a good look a role composition in a week or two. getting attributes right and so forth. I'm planning to do an 'add_attribute' method to P6object that takes care of the create-a-new-class-object (and adjusts protoobjects and so forth) don't know if that will impact role composition, but I figure we'll need it at some point. Just a wrapper around addattribute op? essentially, yes. Adding them to roles will be a similar process. metaclass.'add_attribute'('$.foo') no, $!foo right But yes, that's fine with me. (some other language could use $.foo !) :-) BTW, I found Grammar in the smart match table :-) Oh/ I thought it was only mentioned in S05. $Larry is evil. "pmichaud" at 76.183.97.54 pasted "Grammar in S03" (15 lines) at http://nopaste.snit.ch/13127 Argh! =-) which tells me this has to be done using .ACCEPTS, which is just as well because :multi on infix:~~ wasn't working out anyway. Yeah, I figured it needed to be on ACCEPTS It's just how. :-) got it covered :-) Nice. Give grammars an auto-generated ACCEPTS method> ? make it possible for classes to tell P6object which class methods override the protoobject ones I was already doing that for 'new' -- I've just generalized it into a list. Ah, cunning. :-) $ cat x grammar Test { rule TOP { \d+ } }; if "42" ~~ Test { say "ok"; } $ ./parrot perl6.pbc x ok Nice. OK, I can't find any mutable-specific breakage now. Go ahead and commit erm, merge $ ./parrot perl6.pbc rpn 3 5 + 8 If you're happy with it. :-) cool I think so. I need to get a fresh drink and then do the merge. % silug has joined #parrot should be pretty straightforward now, since most of the issues have been taken care of and I don't think trunk changed in any of the relevant files. ./mutable.c:1974: error: invalid conversion from 'void (*)(parrot_interp_t*, PMC*)' to 'void (*)(parrot_interp_t*, PMC*, PMC*)' I did one or two tiny fixes since the branch, I don't think they touched the same files either. Building with c++ NotFound: what's on that line? NotFound: and are you in the branch or in trunk ? Parrot_default_visit, inside temp_base_vtable pmichaud: in trunk okay, we're about to redo that. (i.e., it'll be replaced on merge) Try again after we merge. Ok. r27968 | pmichaud++ | mutamerge: : [mutamerge] : * Add ability for P6object to specify which class methods override : P6protoobject ones. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27968 I bought 25 euros with 30 euros at the perl auction ... r27969 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] updating to trunk r27967 diff: http://www.parrotvm.org/svn/parrot/revision?rev=27969 I wondered what on earth you were buying. just goes to show that 30 euros aren't worth what they used to be. ...says the guy with the US dollars... ;-) ("but these are 'Special FPW Edition' euros!") I used to have a Swiss bank account. :-) that was cool. the last tshirt auction with many of them okay, svn ups, realcleans, rebuilds, tests, then merge r27970 | pmichaud++ | mutamerge: : [mutamerge]: : * Get Grammar (and subclasses) to use Grammar.ACCEPTS instead of : the P6protoobject one. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27970 Try with monopoly money. pmichaud: Doing here too. % Theory has joined #parrot * pmichaud prepares to give his Dual-core Intel a serious workout. compiling two parrots and running a variety of 'make test' targets in parallel. (evil laugh) FRY, MOTHERBOARD, FRY! * pmichaud hears the fan spinning up on his workstation. pmichaud: Are you trying a new implementation of hcf? lol hey, don't we need a 'lol' opcode? NotFound: you rang? pmichaud: no need -- we have a whole language for that japhb: g++ 4.2.3-2ubuntu7 VIZIBLE "LOL" will auction lol, but they want to stay aftre 1.0 I will vote for a PLASE opcode. NotFound: Which Ubuntu release is that? ? PLEASE PLASE? Oh I pondered proposing object oriented extensions to lolcode. To help Intercal implementations. japhb: 8.04 Objects would be called "KITTEHZ" and Classes would be "BREEDZ"? The ubuntu7 thing is a packet id, I think. NotFound: do you usually install the latest release? IIRC, KTHXBYE is already taken in lolcode syntax jonathan: yeah, end of program japhb: usually not, this time yes. NotFound: What CPU/arch? model name : Intel(R) Pentium(R) M processor 1.73GHz NotFound: thank you. Mind if I feed the bot? Do. parrot platforms? it has been said that parrot platforms is Win32/MSVC: particle, Ron; Win32/Cygwin: Limbic_Region, donaldh (Vista); Win32/MinGW: Limbic_Region; Mac OS X: kid51 (PPC/10.4), tetragon (Intel/10.4/32-bit, PPC/10.5/32-bit), DietCoke (Intel/10.4); Debian Linux/i386: japhb; AIX: paco grrrr. It refused to take your C++ use, because "karma must be done in public!" no, parrot platforms is Win32/MSVC: particle, Ron; Win32/Cygwin: Limbic_Region, donaldh (Vista); Win32/MinGW: Limbic_Region; Mac OS X: kid51 (PPC/10.4), tetragon (Intel/10.4/32-bit, PPC/10.5/32-bit), DietCoke (Intel/10.4); Debian Linux/i386: japhb; Ubuntu Linux/i386/g++: NotFound; AIX: paco parrot platforms? i heard parrot platforms was Win32/MSVC: particle, Ron; Win32/Cygwin: Limbic_Region, donaldh (Vista); Win32/MinGW: Limbic_Region; Mac OS X: kid51 (PPC/10.4), tetragon (Intel/10.4/32-bit, PPC/10.5/32-bit), DietCoke (Intel/10.4); Debian Linux/i386: japhb; AIX: paco karma g g has karma of 427 grrrr :D lol karma c c has karma of 6947 ... parrot platforms? it has been said that parrot platforms is Win32/MSVC: particle, Ron; Win32/Cygwin: Limbic_Region, donaldh (Vista); Win32/MinGW: Limbic_Region; Mac OS X: kid51 (PPC/10.4), tetragon (Intel/10.4/32-bit, PPC/10.5/32-bit), DietCoke (Intel/10.4); Debian Linux/i386: japhb; Ubuntu Linux/i386/g_plus_plus: NotFound; AIX: paco finally karma chameleon It comes and goes. okay, mutamerge branch fails coding tests but I'll fix those in trunk. so..... MERGE! YAAAY! Getting passes on Win32 as well. no conflicts in the merge. now rebuild and test. :-) * jonathan is happy to see this go in pmichaud++ for doing the hard part I'm really happy we have this in too , and that things like my @a = 1; dtrt and that hash() works, and list() works, and... btw, while working on list context I figured out that lazy lists are going to be pretty easy to put together. I was half-tempted to go ahead and try it. and now you can work on protoregexes ;-) (actually, more than half-tempted) I was pondering working on that soon. But if you've figured it out... Some good soul can try #55050 ? Or alternatively, the explain what you were thinking and I turn it into code approach, so you can hack on the protoregexes. ;-) it's pretty straightforward, actually I already started getting a Range class in place. That is a lazy iterator. essentially, a List simply keeps all of its elements lazily but we override keyed access, shift, etc to flatten as needed And an Array has the lazy part, and an evaluated part? erm, list OK right. but the evaluated parts are just elements of the underlying ResizablePMCArray Sounds good. How do we keep track of what's evaluated and unevaluated? for optimization we just need to keep track of how much is already flat Just add an extra counter? Right. well, I was thinking of adding a variable.... but now that I've committed to getprop and setprop I might do that :-) s/variable/attribute variable => attribute? ok since the "already flat" part is supposed to be somewhat hidden anyway for an iterator, a list just returns a clone of itself That's what I did already for Range. well, not a clone % AndyA has left AndyA!~andy@82.152.157.85 Hah. I just won something in an auction by bidding 42 EUR. 43! dollars! % AndyA has joined #parrot * jonathan now has a some plush smileys. :-) Will help make my new appartment more geeky. % cognominal has left cognominal!~cognomina@auteuil.enstimac.fr r27971 | pmichaud++ | trunk: : [p6object]: Merge changes from mutamerge branch : * Add PROTOOVERRIDES to say which class methods : override protoobject methods. : * Clean up .ACCEPTS to do class/role-based smart : matching (i.e., isa + does). diff: http://www.parrotvm.org/svn/parrot/revision?rev=27971 Done. r27972. tests welcomed. r27972 | pmichaud++ | trunk: : [rakudo]: : * Merge mutamerge + mutablerakudo branches into trunk. : * All spectest_regression tests pass. : * jonathan++ jonathan++ for Mutable implementation and merge help. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27972 jhorwitz++ # mod_perl6 Registry Scripts http://www.smashing.org/jeff/node/35 ./perl6scalar.c:517: error: 'Parrot_Mutable_delprop' was not declared in this scope % iblechbot has joined #parrot Same for getprop, getprops and setprop did you make clean or make realclean? Mmmmm... please, wait. those were defined in the previous version of mutable, but are no longer there. so I think a library / header is out of date. (and possibly a makefile dependency.) ./perl6 -e"say 'Hello, world.'" Hello, world. rm -fr / :) pmichaud++ % tetragon has left tetragon!~seneca@216.126.67.44 ./perl6str.pmc: In function 'FLOATVAL Parrot_Perl6Str_get_number(parrot_interp_t*, PMC*)': ./perl6str.pmc:91: warning: switch missing default case Just this warning. % dcat_ has joined #parrot % tetragon has joined #parrot % teknomunk has joined #parrot NotFound++ r27973 | pmichaud++ | trunk: : [rakudo]: : * Fix "switch missing default case" warning reported by NotFound++ . diff: http://www.parrotvm.org/svn/parrot/revision?rev=27973 okay, time for a break. then maybe lunch. then journal posts. then dinner, soccer, and hopefully more hacking. % cognominal has joined #parrot Yay, we has merge! it's been a good couple of weeks. :-) afk for a while Ugh. I get a failure in instantiate.t in trunk. oh, not rakudo bug. svn issue % kid51 has joined #parrot works, my bad. % DietCoke has joined #parrot * DietCoke ~~ % DietCoke is now known as Coke ~~ % Coke is now known as DietCoke jpahb? japhb? japhb is probably Geoffrey Broadwell, mailto:geoff@broadwell.org DietCoke: here, for just a second I think he just wanted your name and address for an introductory letter to parrot-porters. pmichaud: Ah, cool, thanks Thanks again, DietCoke. * pmichaud suggests "/msg purl japhb?" :-) If everyone else did that, I'd be happy to follow their lead. :| * japhb has taken to just keeping a purl tab open in his IRC client how do you know we aren't doing that? ;-) clearly -everyone- isn't. =-) DietCoke: sometimes you *want* your purl conversation to be in public I use /msg purl selectively. :-) % lichtkind has joined #parrot pmichaud: ditto that you shouldn't have to autogenerate an ACCEPTS method if it just gets inherited from Grammar correct, however, we run into a bit of a tricky issue wrt protoobjects i.e., $x ~~ Foo means something slightly different if Foo is a Grammar protoobject as opposed to another type ("Grammar protoobject" => protoobject of something inheriting from Grammar) why does it mean something different? $x ~~ Dog # is $x a Dog? ah $x ~~ MyGrammar # match against MyGrammar's TOP rule then lets not use ~~ at all for grammar matching that's okay with me... but what instead? $x.match(MyGrammar) ? MyGrammar.TOP($x) ? the way it works out in STD5 is Dog.new("string").TOP() where Dog is a Grammar? yes, sorry, not awake yet histamine/antihistimine inspired jetlag... I can do that as well, but I like one of the .match or MyGrammar.TOP forms better. I don't have a strong opinion. At any rate, as it turns out we end up not autogenerating methods, but instead have something to control when a protoobject retains its protoobject sense over its class sense (and that gets used pretty rarely.) well it needs to know when to generate an initial match state against which grammar and which string, but other than that I'm not picky about syntax that sounds hacky oh, it's not too bad, actually. well, it's too bad if every other implementation settles on a differnt hack... :( it's not really visible to the P6 programmer -- it's kinda internal to Parrot/Rakudo these things have a way of leaking... but yes, the $x ~~ Type vs. $x ~~ Grammar conflict is probably worth resolving (leaking) -- yes, I know. If we fix $x ~~ Grammar then it's one less thing to leak. :-) anyway, it works for now until the synopsis changes. Also, I always thought it was kinda strange that TOP was described in S03 and not S05. possibly we need a defined grammar object that is a match factory actually, .ACCEPTS is distinguishing undefined vs defined all over the place, Regexp, Junction, etc yes, I thought about that as well but couldn't quite make it work with Grammar (conceptually, that is) essentially the way we do it now is that protoobjects have a slightly different .ACCEPTS method from their normal instances i.e., they do type-matching instead so that argues that a Grammar match should be against a Grammar.new I'm warming up to that very quickly, yes. so!!! $x ~~ Grammar # is $x a Grammar? $x ~~ Grammar.new # match against Grammar ? % Andy has joined #parrot that might help straighten out current parser bookkeeping too in the compiler yes that's what I was liking about .new because then we know we have an actual instance of a Grammar instead of a potentially shared one and maybe a grammar could then be somewhat mutable without always resorting to inheritance to modify it yes which might make it easier to track subs and such yes lemme think about that s'more wrt STD... sure thing what I have now works and will be easy to modify and I'm at least a day or two away from any significant PGE refactoring that would depend on this (and even if it takes longer than that, it shouldn't be hard to adapt) when I see all the different responses to a perl6: query on #perl6, it worries me when I see such different responses. I wonder when (if ever) we'll even agree on what error messages to emit... ... you can always agree for us. =-) let the test suite decide. % Zaba_ has joined #parrot no, I can't, because I just don't have time to agree on everything so I have to have faith in the larger community to work it out I think it will work out and I think [particle] is correct that the test suite is the locus of that negotiation agreed. totally. GAG ME WITH A SPOON!!1! agreed. I would, however, give you the 20 dollar bill I have left in my wallet if you'd take a full time "agree-er" position. =-) * pmichaud grabs a spoon and proceeds to... Eat gelato? DietCoke: well, I did that for about four years once, and it set me back about $250k... the fact that the perl6: queries evoke different responses is at least partially due to evolutions in the spec, I think as well as our evolving understanding of Perl 6 ... ok, 25$. purl, 250000 / 25 10000 yahhh. now if we only had 10,0.... coke beat me to it. % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % gmansi has joined #parrot pmichaud: yeah, I actually think the perl6: query is a healthy thing to keep the democratic process alive I _really_ like that query. 9999 coders with $25 in their pockets, 9999 coders with money, ask one for money for larry, pass it to him, 9998 coders with $25 in their pockets it shows what other developers are thinking, it also shows the questions and problems that non-developers are encountering a lot of times I look at the scrollback to find things to fix or implement :-) i wish we had an off-channel (like run.pugscode.org) version (or decide to fix/implement it because of something I saw in scrollback) but part of the value is its in-your-face-ness yes, I like it on-channel there's room for both there are some times when I want to issue queries without flooding the channel -- otoh it's nice to see everyone else's queries eek, a heterogenous opinion!!! shoot it!!! timtowtqi? % gryphon has joined #parrot maybe there's a way to log the query and a summary of how much agreement was achieved on one line with a link to the actual results well, "log the query" can be the irclogs :-) the summary could usefully give the shortest non-null response, and which engines returned that answer and a list of the dissenting engines % radhios has joined #parrot "writing the dissenting opinion is pugs, which has in past debate often been held as a persuasive authority" --npr coverage % slightlyoff has joined #parrot particle: you can message the evalbot directly and it will reply just to you yay, finished some `official parrot business' I had to do. Now I can actually hack on something. ... this is going to suck, I'm going to have to bring a windows laptop to yapc! * particle shakes his house & % AndyA has left AndyA!~andy@82.152.157.85 DietCoke: you're right, that sucks. I'll give you the 20 dollar bill left in my wallet and a Kubuntu disk so you can fix it. :-) * pmichaud prepares to make his first-ever parrotblog post % AndyA has joined #parrot when merging, what does "skipped" mean? (I know I've already looked this up once...) I don't know -- never encountered that. % kid51 has left kid51!~jkeen@216.220.101.5 to verify, 'svn merge -rRev1:Rev2 .' from inside a pristine, updated working copy of the branch? svn really doesn't track any of that for you? Huh. % braceta has joined #parrot has perl 6 __END__ tokem? token % slightlyoff has left #parrot lichtkind: no TimToady: so all token are gone good use =begin END instead, is the current recommendation, though we'd have to special case it not to complain about a missing =end END but how can i say to parser stop parsing to ignore large POD sections? S02 lists where various __FOO__ tokens have gone i see thanks TimToady: but so i have to put POD in seperat pod file if i want to prevent reading by parser? in general, yes, but =begin END might be a special case % allison has left allison!~chatzilla@dsl-241-62-167.telkomadsl.co.za afk & thanks TimToady++ % bigal has left bigal!~BigAL@ip72-211-175-126.tc.ph.cox.net % slightlyoff has joined #parrot % Ademan_ has left Ademan_!~dan@h-69-3-232-86.snfccasy.dynamic.covad.net % ambs has joined #parrot % AndyA has left AndyA!~andy@82.152.157.85 % Zaba has joined #parrot % slightlyoff has left #parrot % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru % AndyA has joined #parrot article posted to http://www.parrotblog.org/ . That was far more painful than writing ever should be. (because of the way blogger handles formatting) but at least now I have a tool for (re)formatting my text into something acceptable for Blogger.