http://canonical.org/~kragen/strlen-utf8.html Tene: very interesting http://porg.es/blog/counting-characters-in-utf-8-strings-is-faster Tene's url is at http://xrl.us/bmhdz % iblechbot has joined #parrot Tene: nice reading % Zaba has joined #parrot % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru % Zaba_ has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % ruoso has left ruoso!~ruoso@81.84.157.134 % Zaba has joined #parrot % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot % Zaba_ has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru % allison has joined #parrot % allison has left allison!~chatzilla@dsl-241-62-167.telkomadsl.co.za % tetragon has left tetragon!~seneca@gw-312-705.somanetworks.com % tetragon has joined #parrot % iblechbot has left iblechbot!~iblechbot@ppp-62-216-201-251.dynamic.mnet-online.de allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws % bacek has left bacek!~bacek@mcas-151.usr.optusnet.com.au allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws % silug has left silug!~steve@ppp-70-225-32-179.dsl.covlil.ameritech.net allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws % ruoso has joined #parrot allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws allison@perl.org | A foundation for Parrot: link: http://www.perlfoundation.org/parrot/index.cgi?a_foundation_for_parrot dalek's url is at http://xrl.us/bkxq5 % Ademan has left Ademan!~dan@h-68-167-207-98.snfccasy.dynamic.covad.net allison@perl.org | Membership Committee Charter: link: http://www.perlfoundation.org/parrot/index.cgi?membership_committee_charter dalek's url is at http://xrl.us/bmhjt allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws % silug has joined #parrot % braceta has joined #parrot % ank has left ank!~ank@ppp121-44-210-24.lns1.hba1.internode.on.net % ank has joined #parrot allison@perl.org | Conflict of Interest Policy: link: http://www.perlfoundation.org/parrot/index.cgi?conflict_of_interest_policy dalek's url is at http://xrl.us/bmhj7 % bacek has joined #parrot hi again. oh, you're back! purl, you still there! bacek: sorry... allison@perl.org | Conflict of Interest Policy: link: http://www.perlfoundation.org/parrot/index.cgi?conflict_of_interest_policy dalek's url is at http://xrl.us/bmhj7 allison@perl.org | Conflict of Interest Policy: link: http://www.perlfoundation.org/parrot/index.cgi?conflict_of_interest_policy dalek's url is at http://xrl.us/bmhj7 allison@perl.org | Conflict of Interest Policy: link: http://www.perlfoundation.org/parrot/index.cgi?conflict_of_interest_policy dalek's url is at http://xrl.us/bmhj7 allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws summon pmichaud #perl6? #perl6 is at irc.freenode.net. allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws % bacek has left bacek!~bacek@123-243-38-218.tpgi.com.au % Theory has joined #parrot % bacek has joined #parrot allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws pmichaud, http://nopaste.snit.ch/13152 makes S29-list/grep.t passing % kid51 has joined #parrot % pjcj has joined #parrot Hurray! We're back to all tests passing 'make test' on Darwin and Linux. chromatic and tetragon must have been able to complete the binary search last night. % kid51 has left kid51!~jkeen@pool-71-247-45-164.nycmny.east.verizon.net % tetragon has left tetragon!~seneca@216.126.67.44 % ank has left ank!~ank@ppp121-44-210-24.lns1.hba1.internode.on.net % Themeruta has joined #parrot % NotFound has left NotFound!~julian@50.Red-213-96-228.staticIP.rima-tde.net % gryphon has joined #parrot % jhorwitz has joined #parrot % Whiteknight has joined #parrot sheriff_p, Tene: parrot's lua implementation is "real world" and "complete" ...for reasonable definitions of those words % iblechbot has joined #parrot % kj has joined #parrot bacek: could you send your patches as tickets rather than nopasting always? higher visibility of your work is more likely to lead to a commit bit sooner bacek: you can copy parrot-porters@ so the list gets the mail immediately, even if it takes rt a while to catch up is parrot-porters the same as perl6-internals? % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot r28059 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] updating to trunk r28058 diff: http://www.parrotvm.org/svn/parrot/revision?rev=28059 moritz: yes it's the new name, although it seems impossible to get rid of the old name ..."new" being about two years old pmichaud, ok. hello everybody Hello Dr. Nick! for the interested readers: I converted the pct tutorial to POD; it's in lang/squaak/doc. The solutions will come later, prob. next week or so. kj++ particle: I guess you don't need it anymore, but any feedback is welcome :-) well, since i haven't read it yet, i may have some nice feedback when i do :) yep, that's what I was hoping for ;-) General tips on writing or how to make things clear would help in my future documentation efforts which I envision :-P log? o/` it rolls downstairs, alone or in pairs, rolls over your neighbour's dog, it fits on your back, it's good for a snack, it's log, log log! o/` it's log, it's log, it's big, it's heavy, it's wood it's log, it's log, it's better then bad, it's good! :) it's log, it's log, it's only in four characters different than "beer" i grew up on ren & stimpy ...which explains some of my more glaring personality deficiencies * particle <3 ren&stimpy % ruoso has left ruoso!~ruoso@195.23.92.2 Yesterday kalashnikovs, today logs. I really must pick my times to glance at #parrot... * jonathan will do Rakudo day tomorrow. Whiteknight: you EEEEEEEEEDIOT! :) Don't touch it, you fool! It's the history eraser button! % TiMBuS has left TiMBuS!~Hurf@123-243-167-27.static.tpgi.com.au haha! classic references! % ruoso has joined #parrot bacek: (nopaste 13152) -- we really don't need to make separate calls to 'list'() % gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net jonathan: are there any tests that I could prepare for your rakudo day tomorrow? moritz: I was going to write some tests myself, for: (more) * subset foo of bar where { baz } * grammar { ... }, with rule/regex/token inside pmichaud, I'm little bit paranoid with new tools/languages... * Matching against a grammar / rule / regex / token with ~~ % particle is now known as PowderedToastMan hey kids! If you're interested in working on any of those, then I'll probably dig straight into working on roles with attributes. :-) But I think we have no tests for those things yet. Also, some junctional stuff. % PowderedToastMan is now known as particle jonathan: I'll take a look at those, and probably /msg you when I get some of it done jonathan: note that the ~~ Grammar invocation is likely going to change I'd expect $variable ~~ MyGrammar to do a type check just like with classes yes, that's what TimToady was speculating a couple of days ago ayep with a method call to run it to match against a grammar may become $x ~~ MyGrammar.new() % acmoore has joined #parrot will $x ~~ MyGrammar.TOP still work? I can't say for sure on that one yet. will $x ~~ MyGrammar.TOP check that $x isa regex/rule/token? for that one would use $x ~~ Regex how do i get the type of MyGrammar.TOP? &MyGrammar::TOP.WHAT ? ok are parens (for invoke) implied in perl 6? not for &var foo.bar same as foo.bar() if bar is a method, yes. and TOP is a method on MyGrammar regex/rule/token == method so, that seems to suggest $x ~~ MyGrammar.TOP will execute TOP ...and smartmatch $x against whatever MyGrammar.TOP returns pmichaud: Sure, but best to have *something* tested so we can make sure the functionality still works, even if the details will change. yes so how would you smartmatch against MyGrammar.TOP? $x ~~ &MyGrammar.TOP ? jonathan: sure. But the big point about $x ~~ Grammar changing is that we no longer need the .ACCEPTS special stuff. Yes, that will be much cleaner, for sure. $x ~~ MyGrammar.TOP - will be Regex case in smartmatch Regex is method-like, maybe even a subclass of Method. 'subset' seems to lack quite some testing MyGrammar.TOP _should_ invoke TOP Hmm. True. $x ~~ MyGrammar::TOP would do the Regex match. MyGrammar.TOP - as particle said. no. Oh? MyGrammar.TOP _should_ invoke TOP. Yes, invokes TOP But without any arguments? It's just a method call? $x ~~ MyGrammar.TOP would then do a smartmatch between $x and whatever MyGrammar.TOP returns same as if I did $x ~~ $y.bar $x ~~ $y.bar does not mean $y.bar($x) Right, I thought that's what particle had meant. MyGrammar::TOP would be something different. In fact, it probably doesn't exist. TOP doesn't exist in the MyGrammar namespace? if it does, it's a namespace. The TOP method would be MyGrammar::&TOP Ah. OK, got it. * jonathan trundles back to $DAYJOB TimToady says that TOP invocation in STD5 is currently: MyGrammar.new($x).TOP() we really need eval_lives_ok and eval_dies_ok for? for testing all kinds of stuff, for example subsets (not disagreeing, just curious) subset Even of Int where { $_ % 2 == 0 }; why does that require eval? lives_ok { my Even $x = 3 }, "desc", won't work because a compiler is allowed to such checks at compile time where possible NOT! pmichaud: I found some instances where undeclared variables where used in a try { ... } block, and rakudo bailed at those (rightfully) eval_lives_ok and eval_dies_ok -- I agree. and there are quite many test like eval 'string'; ok !$!, "compiled"; that could also use these are these latter tests actually testing eval? if we're just testing that something parses/compiles, we should use #?impl skip for that or one of the other fudge directives % Themeruta is now known as NotFound eval_dies_ok can be used for testing parsing failures. yes, it can be used for that (more) (nm more) bacek: and for failures that can either happen at runtime or compile time anyway, I agree that we should keep eval_lives_ok and eval_dies_ok moritz, +1 bacek: if you have free tuits, would you like to implement these in Test.pm? % IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk aren't they already there? or is it just lives_ok and dies_ok ? no 'eval' at all in Test.pm okay, add them. :-) pmichaud, no. But they can be easily implemented bacek: do you want me to fix nopaste 13152 and apply it? actually, I'll clean up exports first. "bacek" at 202.7.166.166 pasted "scetch of eval_dies/lives_ok in Test.pm" (29 lines) at http://nopaste.snit.ch/13162 probably need try { ... } around those evals pmichaud, Already done. I just fixing other... hmm... glitches in List.pir do failed evals throw exceptions? don't think so, actually $ ../../parrot perl6.pbc > use Test; > eval_dies_ok('die!'); Segmentation fault (Core dumped) Yeek... eval might not throw an exception -- I suppose if the code doesn't eval then it would return one. in which case we probably need to update rakudo's eval() however inside there could be an exception pmichaud, (about List.pir) do you want it in RT? S04 says "The Perl 6 equivalent to Perl 5's eval {...} is try {...}." which might lead one to believe that eval doesn't trap exceptions anymore. (but it could also be that S04 is simply referring to P5's block form of eval.) eval { ...} *is* the block form of eval S04 says there is no eval { ... } in p6 S04" The Perl 6 equivalent to Perl 5's eval {...} is try {...}. (Perl 6's eval function only evaluates strings, not blocks.) that's what I meant ;) bacek: just a sec, thinking bacek: either nopaste or RT is fine for this. I'll probably go ahead and apply it now, and then do my export refactoring a bit later "bacek" at 202.7.166.166 pasted "List.pir cleanup for pmichaud" (101 lines) at http://nopaste.snit.ch/13163 for sort, shouldn't 'list' be :slurpy ? pmichaud, I also have 'reduce' refactored. same for map pmichaud, why? otherwise we can't do sort 1,2,3,4,5 bacek: (nopaste 13152) -- we really don't need to make separate calls to 'list'() right we do '!flatten' on the slurpy arg instead .param pmc array :slurpy array.'!flatten'() .return array.'whatever'() (unless the 'whatever' method already does flattening, in which case we don't need the extra '!flatten' step. % uniejo has left uniejo!~uniejo@langebro.adapt.dk ok. Just a sec. hmm... What the difference with my original version? 'list' is actually 'alias' for '!flatten'... not really 'list' always constructs a List() sorry, you're right, that's not what it does however, it does create an *extra* list. bbi15m & using '!flatten' directly avoids the extra list creation. * bacek throws Knuth's book to pmichaud - PREMATURE OPTIMIZATION! I'm willing to accept the argument that this would be a prematu..... right :-) okay, I'll apply it. well, I'll apply 13152 :) BTW... Always flattening is bad idea... We really need lazy lists... ...except that sort() does flatten. except sort() and map. and grep. and anything that has *@array as an argument. (grep { $_ % 3 }, 1..Inf)[20] flattening is not actually required. oka, flatten is the wrong name then. I don't mean flatten in the sense of "eager", I mean it in the sense of "remove dimensions" pmichaud, o! '!flatten' is little bit misleading... it's okay, as you say, it'll go away with lazy lists. jonathan: I added two test files for subsets in S02-polymorphic_types/. They seem to pass once we implement eval_lives_ok or at least it'll become less eager moritz, eval trowing exception in rakudo. pmichaud, indeed moritz: Nice. jonathan: they are very basic, but atm I don't really know what else I can test... a job for Auzon when he gets to it ;) "bacek" at 202.7.166.166 pasted "woring version of eval_dies/lives_ok in Test.pm" (31 lines) at http://nopaste.snit.ch/13164 use Test; plan 1; eval_dies_ok('die'); it works :) I'd be interested to know if eval throws exceptions on parsefails, though. moritz: Basic tests beat no tests. :-) pmichaud, it throws bacek: no, I mean in the spec, not in rakudo. i.e, "should eval throw an exception on parsefail?" pmichaud, hmm... pmichaud, my vote for 'shouldnt' * moritz too so, one would have to explicitly check $! after eval? Why shouldn't it? If you've got a parse fail in what you tried to eval, you'd like to know about it? pmichaud: or 'use fatal 'eval'' moritz: that's reasonable. I'd go with it following what use fatal does. anyway, is eval() documented in S29? the whole philosophy is not to die unless fatal is in scope rather 'fail' instead which does the right thing works for me. so we need to fix rakudo's 'eval' pmichaud, yes. moritz, S02-polymorphic passed with this Test.pm :) bacek++ either fix eval or file a ticket for it, please. pmichaud, src/builtins/control.pir. I think we should fix rakudo, not parrot in this case. bacek: I don't understand. * bacek is little bit dumb... pmichaud, sorry. I just misread ...you proposal to fix. Just a sec. I'll fix eval. we probably ought to have a 'fail' function, too :-) pmichaud, it's too many failures without this function... Why we need it? :) bacek: because it's specced? ;-) You can implement it just by calling other function that fails X-) * bacek still try to understand how set value in '$!'... bacek: I fear that is looking down the callstack, since $! is a context variable. % Zaba_ has joined #parrot jonathan, and how it should look like? % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru look like time to summon chromatic bacek: You can get at it through the interpinfo opcode, I believe. % kj has left kj!~IceChat7@193.1.100.109 % ambs has joined #parrot bacek@icebolt:~/src/parrot/languages/perl6$ cat e.pl eval('die'); print defined $!; eval('1==1'); say defined $!; bacek@icebolt:~/src/parrot/languages/perl6$ ../../parrot perl6.pbc e.pl 10 Bingo! "bacek" at 202.7.166.166 pasted "Fixed eval() for pmichaud/jonathan to review" (26 lines) at http://nopaste.snit.ch/13165 "bacek" at 202.7.166.166 pasted "Fixed eval() for pmichaud/jonathan to review (again... full version)" (35 lines) at http://nopaste.snit.ch/13166 % braceta has left braceta!~Braceta@nc.eurotux.com bacek: include documentation about setting $! and i think it's good to apply jonathan, junctions have a .perl method but no .get_string. particle, # We fetch callers lexpad and set '$!' in it. is it enough? i mean pod doc particle, but pod doc is already there... Returns whatever C<$code> returns, or undef on error. Sets caller's C<$!> on error. something like that particle, ok. i can apply and add that, if you think it's accurate enough cognominal: I don't know what get_string on a junction should do. Not the same as .perl, that I'm pretty sure of. Stringifying each element and returning a junction of the strings would seem sane. also, i'm moving the .local away from the .param and closer to where they're used I did not thought that far :) "bacek" at 202.7.166.166 pasted "new version of eval()" (45 lines) at http://nopaste.snit.ch/13167 cognominal: Actually, what I just said won't work. particle, I just copied your text :) Because you have to return a STRING* and not a PMC*. but prefix:~ on a junction should return a junction of strings, I'm pretty sure about that. I think it should be the same as .perl, but call .str on the asssembled objects, not .perl (just intuitive guessing here) .perl of a junction returns a string rather than a junction; stringifying a junction I don't think changes it's junction-ness. Since serializing and stringification are different. but shouldn't ~$foo return a string, regardless of $foo is? bacek: applied, testing now particle, ok, thanks. must sleep $bacek->sleep(8 * 3600); it's 3 AM here. Good night everyone. thanks purl sleep well bacek ;) moritz, I will. Last 4 hours before waking kids... moritz: (~$foo returns string always) No, because ($a + $b) doesn't always return a number, if $a or $b are junctions. I guess as moritz about ~ on junctions applying basic opts to junctions produces junctions of applied ops japhb: you've got a point there. But how do I *really* produce a string then? .perl does it japhb: please take a look at #49966 cognominal: but that doesn't do what I want ;) NotFound: looking OK, give me a minutes to make realclean and compile a fresh parrot, and I will test again here. moritz: $junc.values will get you the values in a junction as a list, which may stringify how you want. moritz: What do you really want, if .perl's string output isn't it? say $junc will, eventually, autho-thread. *auto-thread That is, call say for each value in the junction japhb: .perl calls .perl on all assembled objects in the list. Which is arbitrary, as long as it reproduces these objects. I'd expect prefix:~ to return something that assembles the stringification of all these objcts r28060 | particle++ | trunk: : [rakudo] eval: propagate $! to caller (bacek++) diff: http://www.parrotvm.org/svn/parrot/revision?rev=28060 Anyone know if in PIR, the :opt_flag .param must immediately follow the matching :optional .param? Can there be intervening other .params? In particular, can you group all of the :optional's together, followed by all of the :opt_flags in the same order? japhb: but I think I actually want ~$junc.values, jonathan++ moritz: fair enough japhb: i believe they must be :optional :optflag :optional :optflag order particle: ok, thanks moritz: Or perhaps (~$junc).values, if you wanted an array of strings...depends what you're after. :-) japhb: given all current bugs in passing arguments, trying that can be a nightmare. prefix:~ on a junction should return a junction in this respect it's no different than doing prefix:- on a junction NotFound: yeah, I thought about testing it to get the answer from the horse's mouth, then realized I would be getting the answer from the donkey's mouth instead. -(2|3) " (-2 | -3)" ~(2|3) ==> "2" | "3" however, prefix:~ should never actually "see" a Junction -- the dispatcher should autothread the calls to prefix:~ japhb: I think it can be a Monte Carlo answer, mostly, (and I don't talk about Alonso-Hamilton things) X-) * japhb goes to look up Alonso-Hamilton, can't find anything but Mercedes-Benz racing references That's it. they race in monte carlo non sequiturs manage to always converge in Perl with the appropriate metric for_each a,b -> distance(a,b)=0 ? NotFound: wow, if I'd been more awake ... I still probably wouldn't have figured out that joke. ;-) NotFound: #49966 looks fixed, so I marked it resolved, thanks for pointing that out. japhb: what do you want as include files? I am opengl and glut illiterate r28061 | pmichaud++ | trunk: : [rakudo]: : * Refactor handling of exported methods into !EXPORT sub. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28061 r28062 | kjs++ | trunk: : [tutorial] add solutions to episode 3. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28062 "cognominal" at 82.67.232.89 pasted "glxinfo for japhb" (69 lines) at http://nopaste.snit.ch/13168 pmichaud: will you be layering 'is export' on '!EXPORT'? % cjfields has joined #parrot cognominal: The full contents of any directory containing a header file named 'gl.h', 'glu.h', or 'glut.h' ok pmichaud: also, if you have some pointers as to what Exporter needs or should act, let me know (test cases give you bonus points) japhb, I thought the problem was that I added a opengl port but removing it did not change anything I believe the problem is an extra header file with macros formatted in a weird way I'm not handling. * japhb examines cognominal's glxinfo ... OpenGL 1.2? Seriously, Intel!? Sheesh. this seems to comme with X11 No wonder NVIDIA is constantly giving Intel a hard time about being graphics-incompetent. that may not be what you sarch this is not the native window system on a mac Is there a cglinfo? (Or aglinfo, for that matter?) "cognominal" at 82.67.232.89 pasted "for japhb" (12 lines) at http://nopaste.snit.ch/13169 cognominal: yes, perfect. The full contents of all of those directories, plus the glut.h-containing ones you posted the first time. tar that whole puppy up. :-) ok thank you! you are welcome r28063 | pmichaud++ | trunk: : [rakudo]: particle: (is export) haven't decided yet. : * Add more improvements to List (bacek++) : * Two additional subtests in t/spec/S29-list/grep.t now pass. : * Patch courtesy Vasily Chekalkin diff: http://www.parrotvm.org/svn/parrot/revision?rev=28063 I was simply tired of writing stub code to put methods into the global namespace, so figured an export of some sort would work well. % sjansen has joined #parrot I see !EXPORT as an interim measure until we decide how we want to handle it in general. if we decorate methods with 'is export', can we use '!EXPORT' for trait_auxiliary:is ? not yet. eventually we'll do something like taht. what stops us? can't get the name of the method? only that I'm not sure this is the design I want. r28064 | kjs++ | trunk: : [tutorial] add solutions to ep.4 diff: http://www.parrotvm.org/svn/parrot/revision?rev=28064 hrmm it is the proper perl 6 syntax, though, isn't it? if someone wants to implement 'is export' using !EXPORT that's okay, keeping in mind that I may change my mind I'm only saying that !EXPORT itself might be wrong. ok, sure i just want to be able to specify on the routine that it should be exported, rather than hardcoding it in :onload where 'routine' means "Perl 6 routine"? yes. or are you advocating an :export flag on Parrot subs? no method foo is export (...) { ... } right. but the code to do that is going to end up in an :load :init sub grrr ... what's the correct PIR to do a COW assign of string registers? '$S0 = $S1' doesn't seem to do it, unless I have a bug elsewhere japhb: $S0 = clone $S1 pmichaud: thanks. That's really COW, not a copy? so I'm told. ok % Ivatar has joined #parrot pmichaud: I believe you said a couple days ago what the 'friendliest' way to obtain an iterator from an aggregate was ... was it the 'iter' op? yes. pmichaud: cool, thanks vtable++ there's an iter op? learn something new every day.... It's listed in the docs as experimental, so I wasn't sure. it's in experimental ops, but apparently is likely to stay. it calls the get_iter vtable function makes life easier. that's all i care about. :) * particle hands jhorwitz a beer Well, that didn't work -- "get_iter() not implemented in class 'ResizeableStringArray" * jhorwitz needs a write_slides_for_talk opcode * jhorwitz chugs particle's beer japhb: file a ticket, and use new 'Iterator' :-) pmichaud: I will file a ticket, but I was trying to get rid of "new 'Iterator'" ... ah well, just have to revert a couple "improvements" japhb: right -- apparently we're not quite ready for "iter everywhere" yet. unfortunately I tended to use 'iter' as the symbol for my Iterator PMCs, so that's a lot of code to change (because I was also unaware of the iter opcode) % barney has joined #parrot ticket submitted * jhorwitz does the same thing with iter * japhb was in the habit of naming an iterator for 'foo' as 'foo_iter', so 'foo_iter = iter foo' looked nice * particle uses it_foo it_foo might be okay. That begins to border on hungarian notation, which gives me the heebie-jeebies % AndyA has left AndyA!~andy@82.152.157.85 % Zaba has joined #parrot r28065 | japhb++ | trunk: : [OpenGL] Friendlier function export API : * Make the namespace parameter to _export_all_functions_to optional : * Accordingly, change name to _export_all_functions : * Rename glutcb* to glut* on export, so importing module sees standard names : * Fix POD and example to match diff: http://www.parrotvm.org/svn/parrot/revision?rev=28065 % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru % AndyA has joined #parrot % ccube has joined #parrot I was going to use parrotbug to report a "make test" failure on Parrot_Test and found that parrotbug is non-functional % Ademan has joined #parrot It doesn't even respond to a ./parrotbug -h Looking at the code for it, it tries to do stuff in the "init" sub that shouldn't come until later the "main" part of parrotbug: init(); help(); # bug init() seems not to return I think this is a case where you guys are clearly not eating your own dogfood. I will note that docs/submissons.pod points you to using this non-functional tool Off with his head! ccube: current bug report is http://rt.perl.org/rt3/Ticket/Display.html?id=41601 jonathan, in fpw2008, I think you spoke about a java extension that was cool, was that groovy? Yes, but I only said I'd been told it was cool, I haven't tried it yet. :-) pmichaud: SO update docs/submission.pod why don't you? pmichaud: and FIX or REMOVE parrotbug ccube: I don't know how to fix parrotbug. that's the story of the man that has seen the man that has seen the man that has seen the bear... ccube: it's not my call whether or not to remove it. pmichaud: hmm - then whose is it? I suspect the people responding in RT#41601 you're welcome to add your report to RT#41601. That might get it moving again. What impression does it make on people investigating parrot, if even the bug reporting tool is not functional? you're also welcome to contribute a patch. :-) ccube: not a good one, but we don't get many complaints maybe nobody likes parrot, or bothers to complain when parrotbug doesn't work, or they use email instead of the program But then they have to know where to email to - it seems simple enought to update docs/submissions.pod I, for example, juts notice his existence some days ago, but never tried. % braceta has joined #parrot pmichaud: Could I, say, contirbute a patch that dumps parrotbug and update docs/submissions.pod to direct people to RT or email? ccube: yes. But again, it's not my call. ccube: if you contribute that patch, it will be considered % ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt ccube: it's best to just submit a doc patch IMHO (especially since parrotbug does work for some cross section of people) OK in the meantime - how do I report 6 not oks on my "make test" of 6.2 i mean 0.6.2 ccube: you can submit a bug report about parrotbug using parrotbug ;) I was waiting for that purl, parrotbug i think parrotbug is mailto:parrotbug@parrotcode.org or http://svn.perl.org/parrot/trunk/docs/submissions.pod or see also "rakudobug" ccube: You can email the output to that email address, which will create an RT ticket. % ruoso has left ruoso!~ruoso@195.23.92.2 what should go in the subject line, what minimum information should be in the body (all stuff that I imagine a working parrotbug would take care of) Subject: Test failures in 0.6.2 on ok, thanks ccube: operating system, architecture, compiler + version, parrot version, output of failed tests Body: The details of the test failures, and the contents of the myconfig file (in the directory where you built Parrot) Trailing space in List.pir % braceta has left braceta!~Braceta@bl10-33-137.dsl.telepac.pt pmichaud: As a parting comment, I worry about that "not my call", it reminds me of my time in a big corporation where you could never get things changed, because you could never find anybody that thought they had the authority to make changes ccube: I understand, really. But there are people who can make the call on this one -- I'm just not him or her. Certainly any of DietCoke, particle, or allison could likely make the call. OK, cognominal receives the award for most insane set of OpenGL headers: "77 directories, 223 files" pmichaud: you could do it and then be reviled when you do it wrong :) "We only second guess the decisions that turned out to be wrong." PerlJam: if I had little else to do at the moment, I might consider it. Right now I'm way behind on applying patches as it is. * PerlJam cracks the whip over pmichaud's head ... "Get back to patching!" ;-) pm: have there been that many contributions to rakudo/PGE/PCT? Anybody cares about tools/util/pirtidy.pl ? RT#39132 suggest to kill it. PerlJam: rakudo, yes. japbh: no surprise, I got an award from TPJ for being demented ccube: In any large project, there are always people who have more authority in various pieces of it. Even in the Linux kernel, though Linus may be titular authority on everything, I'm pretty sure there are entire subsystems where he defers entirely to someone else. But even regular patch people don't have authority over the stuff that he *does* monitor on a daily basis. PerlJam: and some of them require some refactoring before I can reasonably apply it. r28066 | chromatic++ | trunk: : [PMC] Cleaned up a compiler warning found in optimized build. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28066 PerlJam: and there are some patches which could be applied or submitted if only I have a few more core items cleaned up. cognominal: link? r28067 | chromatic++ | trunk: : [PMC] Cleaned up a compiler warning found in optimized build. http://www.foo.be/docs/tpj/issues/vol3_3/tpj0303-0015.html diff: http://www.parrotvm.org/svn/parrot/revision?rev=28067 r28068 | chromatic++ | trunk: : [PMC] Cleaned up a compiler warning found in optimized build. whenever I get a chance to look at rakudo again it's going to be a different beast I think. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28068 PerlJam: a lot has changed yes, but underneath a lot of it is still the same. % IllvilJa has joined #parrot % ccube has left ccube!~ccube@cpe-74-70-114-162.nycap.res.rr.com that's because "underneath of it" == "Parrot" r28069 | chromatic++ | trunk: : [IO] Cleaned up a few more compiler warnings from optimized build. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28069 actually, it's more that I re-did the underlying class structures. P6object, for example, and list context. there are two patches from bacek++ pending, one for eval, one for eval_(lives|dies)_ok in Test.pm http://nopaste.snit.ch/13164 and http://nopaste.snit.ch/13167 the Test.pm one looks find, I don't understand the eval() one (lack of PIR knowledge) allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws moritz: got a commit bit yet? pmichaud: no in linux/x86 t/spec/S29-conversions/ord_and_chr seems to hang, I am alone ? :-( paco: no moritz: ok paco: that's why tools/update_passing_test_data.pl unlinks that test file a ticket if one doesn't exist. allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws ok, will do allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws actually bacek's patch for eval_dies_ok doesn't work correctly > use Test; eval_dies_ok('asdfkljsdf') not ok 1 - > asdfsdf Could not find non-existent sub asdfsdf it seems that the outer try { ... } resets the $! from eval r28070 | japhb++ | trunk: : [OpenGL] Tweak POD, remove dead code : * Point to triangle.pir in OpenGL.pir docs : * Remove useless .include in triangle.pir diff: http://www.parrotvm.org/svn/parrot/revision?rev=28070 moritz: is that a problem in try, or in eval? particle: I don't know if it's problem in try { } or in bacek's patch particle: the current behaviour is try { eval 'asdlkfj' }# $! is undef here should $! from eval be propagated to the outer scope? or should it reset $! to undef (as it currently does)? we should get rid of the try { ... } that is around eval. but eval needs some work to do that, I think. does an eval catch execeptions? it probably should so maybe the patch is just overly paranoid yes, works without the outer try as well r28071 | bernhard++ | trunk: : #39132: [DEPRECATED] pirtidy : Remove pirtidy-pl and Parrot::PIR::Formatter diff: http://www.parrotvm.org/svn/parrot/revision?rev=28071 t/tools/smartlinks is spitting out a lot of "Use of uninitialized value ..." errors. The test passes, but it still spits out errors % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot well shoot, it looks like the error is in Text::Balanced, not in the test itself and languages/perl6/src/classes/List.pir is failing t/codingstd/trailing_space too, but I can fix that Whiteknight: I once looked into that, but got confused which one? THAT ONE! thanks purl Text::Balanced Text::Balanced is cool i didn't see any trailing whitespace in List.pir, i'm going to update and run the test again Whiteknight: line 950 r28072 | bernhard++ | trunk: : #39132: [DEPRECATED] pirtidy : Remove the test for Parrot::PIR::Formatter as well diff: http://www.parrotvm.org/svn/parrot/revision?rev=28072 I checked line 950, didn't see any trailing whitespace there its a blank line with 4 spaces that should be removed. % ruoso has joined #parrot oh shoot, i was looking in my branch, not in trunk hate it when that happens :) fixed r28073 | Whiteknight++ | trunk: : [rakudo] Removing trailing whitespace for t/codingstd/trailing_space warnings diff: http://www.parrotvm.org/svn/parrot/revision?rev=28073 urg, now we're failing t/perl/Parrot_PIR_Formatter (probably because of r28072 just now) * Whiteknight updates, AGAIN Whiteknight: should be fixed, by removing the test right, i updated (which removed the test) and I'm testing again thanks % barney has left barney!~bernhard@dslb-084-058-168-069.pools.arcor-ip.net % jhorwitz has left jhorwitz!~chatzilla@96.245.16.45 ok, patch finally sent to rakudobug (eval_(lives|dies)_ok) % Zaba_ has joined #parrot msg jonathan t/spec/S02-polymorphic_types/subset-range.t has one failing (fudged) test that should actually work % purl has left purl!purl@sentient.life no msg/tell bot around? you killed him nasty /me which is funny because something similar killed him yesterday % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru I think irc bots are intrinsically nasty ;) my perl 6 evalbot sometimes segfaults, and I have no idea why everything that's potentially evil is only executed in forked childs and all communication is through temp files it's a recent development with purl dunno how that could lead to segfaults at all At least it can be a reproducible bug. who's purl's handler? purl, owner? oh, duh. Masque I think lol % Zaba has joined #parrot % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru % purl has joined #parrot moritz: i don't see the patch, just the mail particle: dammit, I forgot.. infinoid, owner? * particle sends out more resumes % IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk particle: now sent with patch moritz++ particle: Use of uninitialized value in print at -e line 1. particle: owner is . actually mostly bacek++ ++ for everybody! particle, resumes? you in the job market too? i am, i cried i've been in the job market for years me too, that's a consultant's life :) it's not a bad place to be, if you like being a poor unemployed graduate student hrmm... having tests that actually test Test.pm in t/02-test-pm would be nice % slightlyoff has joined #parrot % donaldh has joined #parrot moritz: t\spec\S02-polymorphic_types\subset-range.t (Wstat: 0 Tests: 6 Failed: 1) Failed test: 4 Files=58, Tests=1107, 412 wallclock secs ( 0.39 usr + 0.31 sys = 0.70 CPU) particle: oops, forgot to commit a fudge :( particle: try again please I'm not really concentrated any more, should go to bed ok, i'l try again it'll take 10m to run or so, then will commit okay, I have a Parrot oddity and it's pretty annoying "pmichaud" at 76.183.97.54 pasted "very odd behavior in Parrot" (18 lines) at http://nopaste.snit.ch/13171 "pmichaud" at 76.183.97.54 pasted "very odd behavior in Parrot, with PIR source" (36 lines) at http://nopaste.snit.ch/13172 for some reason the line $P0 = values.'sort'(by) is jumping directly to infix:cmp morning Test.pm should be without 'try' around eval % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot pmichaud: can you do a tailcall there instead? i'm not sure if pir has sugar for .return values.'sort'(by) tailcall gives me a segfault. i wonder if it will change anything well, it changes something then :) which is what started me on this path in the first place :-( getting rid of the tailcall at least got me here. But let me check something else first. I think I can get a PIR program that exhibits the difficulty doh! found it. "Never mind." oh, wait, that's not it. okay, let me put together a short PIR program "bacek" at 202.7.166.166 pasted "better List.sort for pmichaud" (28 lines) at http://nopaste.snit.ch/13173 r28074 | particle++ | trunk: : add eval_dies_ok and eval_lives_ok (bacek++ moritz++) diff: http://www.parrotvm.org/svn/parrot/revision?rev=28074 r28075 | particle++ | trunk: : [rakudo] more tests passing due to eval_dies_ok and eval_lives_ok (moritz++ bacek++) diff: http://www.parrotvm.org/svn/parrot/revision?rev=28075 particle, eval_lives_ok is incorrect. It always passed due try{} ...this is why t/02-test-pm/ needs more tests... bacek: did you check the version that particle commited right now? bacek: I think I fixed it but maybe I broke it in other ways who woke moritz? moritz, yes, I checked diff oh, maybe it was just eval_dies_ok that I fixed particle, I'll write more tests in 02-test-pm. Later today... stupid me perhaps we should first fix/fuge the existing 02-test-pm tests ".sub 'sort' :multi(_)" might not work if 'sort' has no arguments. pmichaud: If you didn't see earlier - will do Rakudo hacking tomorrow. let me run a spectest_regression, commit what I have, and we can play more jonathan++ Is there anything you specifically want me to do or not do? I've not been watching the chanel much today, and am too tired to read the whole backscroll to know exactly what you're working on right now... not off the top of my head. right now I'm refactoring List a bit more and cleaning up exports japhb: apologies for not yet replying with status of OpenGL on Cygwin testing. I still need to work on parameters a bit but don't know when I'll get to it. OK. What are you planning for parameters? just a refactor, mostly. I think too much of the work is being done too high in the parse tree. I think my patch wasn't too far off correct, aside from forcing Mutable into place... What's remaining todo on Mutable before we can really switch to that? getting find_method to work properly or figuring out how we can say "apply X to the mutable instead of what it contains" So that it lets you call methods on the container as well as forwarding them? i.e., getting infix:= to work, or alternatively, figuring out how we can get vtable assign to dtrt for other types. Why can't we just use assign directly for all types? And customize it a little? I'm not sure how to overload assign for, say, Integer without totally messing things up. e.g. Scalar calls .item on what assign is passed Assign for Integer? @a[0] = 3; @a[0] = 4; Oh. Hmm Yes, that's...not nice. I guess for now we can have each array element being a scalar. no, I think that's fundamentally wrong. But it's a whole lotta PMCs. I'd rather not go that way. Yeah. This boils down to, "I can haz keyed assign", right? not necessarily I'm thinking there might be other situations where this comes up OK. I can't come up with any off the top of my head, but... I guess, when doing an array index assignment we want to get the element, then do a copy op? that's what is happening now, yes. It'd be nice to have something cleaner. agreed. that's "I can haz keyed assign", I think. you can temp() items of an array (like perl 5's local()) So we can stick the type-check in more neatly, for example. can that be done without "a scalar for each item"? I think so, yes. Yeah, I think so too. arrays can attach properties to values as they're placed into the array or is temp() done via temporary assignment anyway? we aren't doing temp() yet, so I hadn't really worried about that. It won't bother me if some of the elements of an array end up being Scalars, but I certainly don't want that for every element Yeah, it's a lot of overhead. the answer may be to have infix:= check for a Scalar target and dtrt assign vs copy? yes. Makes sense. you could try that if you want :-) seems easier for now than trying to fix vtable. but somewhere in all of this we will have to decide how to do VAR($x) see everyone in couple of hours maybe a MutableVAR PMC :-) MutableVAR PMC is almost exactly what I was thinking. I may do that tomorrow. it is also completely acceptable to try to do it through a special method on Mutable. okay, pmichaud. On infix:= dispatching properly, I think we need to not just blindly forward find_method, but first check if the container has any matching methods. perl, it purl, it or completely acceptable to try to do it through a special method on Mutable. purl, forget it jonathan: I forgot it *sigh* I don't think we want Scalar's methods interacting with the values methods, though that's what VAR() is for. OK So tasks are: * MutableVAR, to make VAR work * Get assign to do what infix:= does now for each of the types, so we don't need infix:= (Get assign to do...) I don't think that's likely, at least not for the Parrot existing types. Scalar assignment just calls .item on the value, I thought? or not until we have a way of invoking superclass vtable methods from within a PIR subclass. So Perl6Scalar's assign would call .item on the value, then call SUPER do you mean the assign vtable op? I'm not concerned about Perl6Scalar for that -- it's the other types that concern me. Are you thinking the keyed case here? or anywhere that we end up with a value that could otherwise be assigned to but for short term I think just get infix:= to recognize Scalar vs. other and perform assign or copy $a = ..., @a = ..., %a = ... - all seem relatively easy to handle with assign; that is, assignment directly to the container The other case is to some other value % iblechbot has left iblechbot!~iblechbot@20.17-dial.augustakom.net For that, can we not do .sub 'assign' :method :vtable in Object? And it does a copy? yes, but let's suppose that somehow we end up with a Parrot String, Integer, or Float somewhere (as opposed to a Perl6 Str, Int, or Num) % donaldh has left donaldh!~chatzilla@host213-123-171-12.in-addr.btopenworld.com the assign vtable will not dtrt for those values. Ah. This, will not dispatch to our assign. :-( exactly. Damm. And we need .HLL to get rid of those. and even when we have .HLL, I'm not entirely certain we'll be able to 100% get rid of those for a while. Yeah. I'm not sure if :slurpy and :slurpy :named map to HLL types (yet) OK, but they could be made to. yes, but I'm thinking we're better off leaving that to a longer-term issue short term, infix:= seems to be flexible enough to do what we want. at least until we get some of the other particulars in place. OK, but does that mean we need to get infix:= being called on Scalar rather than on a value itself somehow? I'm thinking we let Object's infix:= figure it out. Ah, because we already fixed isa in Mutable. rather than trying to get Parrot's MMD to do it. right. OK, that sounds sane. not a permanent solution, but clean enough that we can proceed for a while until we start down the road of .HLL mapping OK, sounds good. it's easy enough to switch infix:= to assign later :-) True. :-) and yes, I would like as many things as possible to be using assign OK, so I'll look at that and VAR tomorrow. so perhaps what we do is overload assign for Perl6Object, but continue to use infix:= also and infix:= does 'copy' only for the non Perl6* types but I think taking the simpler step first is easier % slightlyoff has left #parrot personally, I'm becoming more interested in how roles get handled Hang on....infix:= is a method call, so I guess we are sticking those methods into the namespace of other classes? yes. OK. a hack, I know. So will we emit an assign anywhere, or just have support ready for when we can use it? short term I think we continue to stick with emitting infix:= % IllvilJa has joined #parrot OK. long term goal is to use assign, but in meantime we'll build support for it as we can oh! I know something else worth working on :-) lazy lists. :-) Alright. So I'll work on that a bit tomorrow morning, as well as VAR. And then I was also planning roles. Aha. :-) Damm, I need like, a Rakudo *week*. although I'm still messing with the list code. I'll let you finish your messing first, then. yes, that's probably wise. I can always look at lazy lists in next week's Rakudo day. if i had the money, i would fund a week how much would a week be, at vienna.pm rates? $750? ;-) Whiteknight: Due to other commitments, I couldn't actually give a straight week this month anyway. July Rakudo gets me two days a week, thanks to Viena.pm++ and DeepText++. I'm already declaring Jun-Aug 2008 to be "Rakudo Summer" for me :-) % gryphon has joined #parrot anyway, lazy lists for next week's rakudo day would be good. Does that mean we get "Perl6 Fall"? :) pmichaud, are you a teacher or professor? they're the only people I know who get a summer off heh OK, sounds like a plan. I think I'm going into my fifth year of being "off" I took an unpaid sabbatical starting September 2003. Never really went back. :-P (I did teach two online courses this past fall and spring, though.) i was hoping that you were a professor, i would apply to be your graduate student % kid51 has joined #parrot *were* is the operative term, though. I don't have any real plans to return to being a professor. "been there, done that." % clunker9__ has joined #parrot http://www.jnthn.net/articles.shtml # uploaded by talks from Stockholm uni, NPW and FPW s/by/my/ Will do use.perl.org and rakudo.org post about them now too. please do. I'll read them a bit later :-) Hmm...my talks list is starting to get quite long. :-) % Zaba_ has joined #parrot % clunker3 has left clunker3!~IRC@procura.xs4all.nl % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % teknomunk has joined #parrot jonathan: several of the talks have the same title, at different venues. Can we assume that the topmost entry is the newest/most complete? japhb: Yes, pretty much. jonathan: great, thanks I will note that in my use.perl.org post The differences are very subtle. I need to create a page of my talks also. % mire has joined #parrot % tetragon has joined #parrot % IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk should ns.'add_sub'($P0) work when $P0 is a MultiSub ? (and ns is a namespace PMC) I'm going to vote yes. I'm even going to commit my vote. :-) pmichaud: I think so, yes. Commit as in, patch to make it do so? ;-) yes. pmichaud++ forgiveness instead of permission, and all that. :-) I'm sure enough that it should work, that I'm happy to share any guilt. :-) of course, it really needs to be made smarter than what I'm going to write now, so that multiple calls to 'add_sub' merge the multisubs together. but I'm just going to do the simple case for now. or, hmmm maybe I'll do the long one. And make sure you're doing an isa check rather than base_type ;-=) So when I subclass MultiSub in July, it keeps on working. :-) of course! * pmichaud evilly considers doing base_type anyway, just to see if jonathan catches it. :-) :-P jonathan: I just looked through your slides. The ones from the FPW on using parrot/perl6 in teaching are interesting. PerlJam: Yeah, I wasn't really sure what to say in that talk, but I hope I made sense. :-) I'm more used to giving technical talks. % IllvilJa has joined #parrot % sjansen has left sjansen!~sjansen@64.207.31.107 Stuff posted to various journals. % Zaba has joined #parrot % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru longest-token matching is, i take it, hard to implement? Hard to get right in that it depends on what you're matching against okay, i dont know a lot about regex engine implementation, so i dont know It's hard. :-) okay, that explains why it hasn't been done yet r28076 | Whiteknight++ | trunk: : [docs/book] a few fixes to chapter 6 in readability. no major updates needed diff: http://www.parrotvm.org/svn/parrot/revision?rev=28076 jonathan++ #manatees do not explode Whiteknight: imagine that you've got the regex f | food | f.* under LTM semantics you don't know which of those 3 alternatives "wins" until you've seen the string you're matching agains. r28077 | pmichaud++ | trunk: : [core]: : * Allow 'add_sub' for namespace PMCs to work for MultiSub PMCs. : See also RT#55308 for some other improvements to make. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28077 % cjfields has left cjfields!~cjfields@cjfields.igb.uiuc.edu r28078 | pmichaud++ | trunk: : [rakudo]: : * More List class refactoring. This commit temporarily breaks : S29-list/sort.t due to an odd Parrot bug, which I'm looking at : now. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28078 what would people say are the main principals behind Parrot's design? docs/book lists three: "speed, abstraction, and stability" I'm wondering if those are really current/accurate descriptions of the design principals wings, beak, and feet Whiteknight: s/speed/correctness/ and it reads closer to how I think of it. those are nice words, and parrot certainly follows them, if not necessarily in that order I'm sure portability is in there somewhere, too. and DRY and dwimmyness ...which isn't really a word % bacek_ has joined #parrot Is there a more coloquial way to do an early exit from a void PIR sub than '.return ()' ? not that i know of '.return' Whiteknight: doesn't work. Parsefail see? that's what you get for listening to me :-) Just as long as you collect that garbage ... ;-) % kid51 has left kid51!~jkeen@pool-71-247-56-64.nycmny.east.verizon.net % ank has joined #parrot i really hope i do a good job with that! what's funny is that I used to be an actual, day-laboring garbage collector myself! % TiMBuS has joined #parrot heh pmc? pmc is responsible for deciding whether to extend itself or not. or a parrot thing, kind of like "magical holds-one-of-anything variable"? or parrot magic cookie or Parrot Magic Cookie or pARROT mAGIC cOOKIE or Poly Morphic Cracker (for the Parrot) or a big problem for optimizations or a compiled pm .oO( WTF? How does iconifying not trigger a visibility change event? ) * japhb fighting with a new Parrot OpenGL example program % AndyA has left AndyA!~andy@82.152.157.85 % AndyA has joined #parrot % purl has left purl!purl@sentient.life % purl has joined #parrot % davidfetter has joined #parrot literal pmc cotto_work: pmc =is= responsible for deciding whether to extend itself or not. or a parrot thing, kind of like "magical holds-one-of-anything variable"? or parrot magic cookie or Parrot Magic Cookie or pARROT mAGIC cOOKIE or Poly Morphic Cracker (for the Parrot) or a big problem for optimizations or a compiled pm r28079 | pmichaud++ | trunk: : [rakudo]: : * Further "fix" to List class to get spectest_regression passing again. : The real fix will have to wait for improvements to Parrot's MMD. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28079 % Ivatar has left Ivatar!~graham@tu055.demon.co.uk % Andy has left Andy!~AndyL@host3130.follett.com % Limbic_Region has joined #parrot % niteice has left niteice!~ice@69.37.98.194 pmichaud ping % Zaba_ has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % kid51 has joined #parrot % Zaba has joined #parrot % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot % Zaba_ has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % mire has left mire!~Frodo@80-168-222-85.adsl.verat.net % Zaba has joined #parrot Limbic_Region: pong % kid51 has left kid51!~jkeen@pool-71-247-56-64.nycmny.east.verizon.net * bacek_ wanders about pmichaud's localtime... 21:23 ...of yesterday :) (US Central Daylight Time) % Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net no, it's still "today" here. it won't be yesterday until tomorrow. :-) future is here! 12:25. Looks like lunch time. * bacek_ never met americans which use 'military time' before :) I'm not typical in that respect. I actually think in terms of UTC much of the time. I was in charge of a data collection project where we synchronized and did all of our internal processing in UTC. world getting smaller and smaller over time. (and I saw tons of other similar-but-failed projects that would try to do things in localtime and fail.) pmichaud: +1. 1 purl: go drink with Bender! bacek_: huh? is parrot's object system still a "tricky work in progress", or is it basically nailed down? (updating the book, again) I don't think it's likely to undergo a major change prior to Parrot 1.0 The book says "As I write this it's still a work in progress, though it should be done by the time this book is in print" so i'm going to delete that part of it pmichaud: JFYU, replacing 'iter = new Iterator, self' with iter = self.'iterator'() in List.grep will made grep works. did I miss one? I thought I got all of those. oh, I sure did! fixing. pmichaud: this is the last one S29-list/grep.t passed (fudged) also afk, Lunch r28080 | Whiteknight++ | trunk: : [docs/book] updates, fixes, and readability improvements to chapter 7. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28080 % gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net r28081 | Whiteknight++ | trunk: : [docs/book] errata list in appendix is all out of date and is removed. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28081 r28082 | pmichaud++ | trunk: : [rakudo]: : * In List.pir. change C to : C : * bacek++ diff: http://www.parrotvm.org/svn/parrot/revision?rev=28082 r28083 | Whiteknight++ | trunk: : [docs/book] update section numbers in chapter 8 diff: http://www.parrotvm.org/svn/parrot/revision?rev=28083 karma bacek bacek has karma of 36 karma moritz moritz has karma of 46 he still overpace me :) karma Whiteknight whiteknight has karma of 35 you both beat me :( the race is on! * Whiteknight demands a recount! karma Whiteknight whiteknight has karma of 35 damnit! karma wknight8111 wknight8111 has karma of 11 karma pmichaud pmichaud has karma of 1335 oh right, alternate nicknames! no one can beat pmichaud :) karma leo leo has karma of 1883 karma chromatic chromatic has karma of 1220 beaten! karma particle particle has karma of 1338 twice! karma c c has karma of 6959 oh shit... King of the hill C has an unfair advantage due to the C-- variant of it. :) And how may of those were references to a certain language? I should create a language implementation called C-- like C, but without subroutines karma java java has karma of -170 java-- karma tests tests has karma of 114 tests ++ karma karma karma has karma of 61 karma coke coke has karma of 1904 karma korma korma has karma of 1 go coke go. karma dietcoke dietcoke has karma of 2 karma DietCoke dietcoke has karma of 2 karma case_sensitivity case_sensitivity has neutral karma karma (things working) (things working) has neutral karma karma things working things working has karma of 1 karma things working things working has karma of 1 heh (things working)++ (things working)++ :) karma (things working) (things working) has neutral karma :( karma chocolate chocolate has karma of 39 karma things working things working has karma of 3 chocolate+=10 karma chocolate chocolate has karma of 39 :( no shortcuts! chocolate++ chocolate++ karma chocolage chocolage has neutral karma chocolate++ indeed. karma chocolate chocolate has karma of 41 except that one i guess except that one is valid Perl syntax, and the other is crack from inside my head. purl++ forget except that one cotto_home: I forgot except that one purl, instant karma is also gonna get you okay, Auzon. instant karma? instant karma Whiteknight-- or gonna get you cotto_home++ no! I win? yeah, that's bad for me literal instant karma cotto_home: instant karma =is= $who++|$who-- or gonna get you I thought instant karma was always positive it's karma roulette wishful thinking, apparently I think I like it better now :) i dont like it when it hits me with a negative! I'm too poor to be losing karma randomly! Whiteknight++ # karma balancing * Whiteknight has karma kids to feed I though purl didn't evaluate its own statements karma spinclad spinclad has karma of 8 * Auzon shrugs instant karma? spinclad-- or gonna get you karma spinclad spinclad has karma of 8 karma for test test has karma of 13 purl, karma test is test++ test is test++ has neutral karma karma for test test has karma of 13 karma test test has karma of 13 d'oh purl, karma_test is test++ karma_test foo bar bar no baz? :-/ purl, bar is baz ...but bar is Great plan. To the pub!... literal foo cotto_home: foo =is= bar! It's possible that there's something more useful I could be doing with my time. * tetragon thinks of all the functions at work called 'blerg' cotto_home: doubtful I guess I'll leave the useful stuff to that cotto_work fellow purl, karmatest is test++ purl? cotto_home? What is karmatest? I'm trying to figure out if it evaluates its own output for karma. karma cotto_home cotto_home has karma of 3 instant karma cotto_home++ karma cotto_home cotto_home has karma of 3 nope cute trick, though purl needs karma aliasing Infinoid: what? cotto and wknight both have karma split across multiple names and so do coke and barney that falls firmly in the "would be nice" category (would be nice) > (wouldn't be nice) r28084 | Whiteknight++ | gsoc_pdd09: : [gsoc_pdd09] updated branch copy of pdd09 to reflect some changes I made in the Arenas struct. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28084 Does parrot still have the following: "Global stash", "System stack", "PMC register stack"? actually, the system stack is probably the C stack, so we definitely have that. Do we have the other two still? I dont know if "PMC register stack" is the same as the register backing stack, which I know we don't have anymore % Zaba_ has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % davidfetter has left davidfetter!~davidfett@start.fetter.org % teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot % tetragon has left tetragon!~seneca@69-196-141-26.dsl.teksavvy.com % tetragon has joined #parrot cognominal: Patch for #55228 is waiting for you % Whiteknight has left Whiteknight!~nobody@c-71-230-33-251.hsd1.pa.comcast.net % Zaba_ has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot % uniejo has joined #parrot % Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net