Camelia, the Perl 6 bug

IRC log for #parrot, 2008-11-11

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:10 AndyA joined #parrot
00:12 tewk japhb: is is possible to draw anything in opengl without callbacks?  I traced the static-triangle.pir with -t5 and saw the draw function getting called to refresh the window, so I think that callbacks are working.
00:13 japhb tewk: Unfortunately no.  This was the source of MUCH angst for me at the beginning of this year.  That's why I had to write the callback libraries in the first place, just to be able to do *anything*.
00:13 japhb The best you can do without it (depending on your GLUT version) is get a blank window.  Sometimes just a window *frame*, with no contents.
00:14 japhb I wish I could give you an even simpler test program, but honestly I'm running out of places to cut.  :-(
00:15 tewk I guess I need to find some debug libraries for opengl so I can set break points on the other side of the function call and make sure params are gettign passed correctly.
00:16 chromatic What about src/nci_test.c?
00:16 tewk those all pass.
00:16 japhb You know ... even though the code is utterly unrelated, long ago I had a problem with the Perl 5 SDL_perl OpenGL bindings that was causing stuff to show up black, and it turned out to be a float -> int -> float conversion problem.
00:16 japhb Just something to think about.
00:17 japhb As for debug libraries, yes, those would help.  The good ones can show you exactly what got to the GL and GLX libraries in a pretty easy-to-follow form.
00:18 japhb nci_test.c, last I saw, tested only a small subset of the available NCI functionality.
00:19 tewk japhb: maybe its a conversion problem with colors, ie its drawing black on black.  Could you try setting the color with a different function say 3i or 3f instead of 3c?
00:19 tewk japhb: change everything to doubles and see if you can get it to work
00:19 purl tewk: that doesn't look right
00:19 tewk I'll try to load some debug libraries tonight.
00:20 tewk I'm on ubuntu, with binary nvidia drivers.
00:20 tewk I'm on ubuntu 8.10 , with binary nvidia drivers.
00:20 japhb I'm on debian testing, with binary nvidia drivers as well.  Same difference.  :-)
00:21 japhb And yes, black on black drawing was what I was thinking of.  Will try doubles in a sec.
00:23 tewk also try not using integer constants in pir when calling float and double varients.  Use 1.1, instead of 1
00:25 dalek r32503 | Whiteknight++ | trunk:
00:25 dalek : [Book] Revision and editing pass for chapter 1. Decrease line lengths where dangerously long, fix wording, tone, and flow. Fixed some grammar issues.
00:25 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32503
00:26 chromatic tewk, I meant you can build src/nci_test.c with debug code.
00:36 japhb tewk: using float constants instead of integer constants did nothing (by itself, at least).  But then following that with changes from float to double entry points made it work perfectly.
00:36 japhb Now working back to use old constants, and see if that works.
00:38 japhb Yup.
00:38 jan joined #parrot
00:38 japhb So just changing from float to double calls is enough to fix it.
00:48 dmknopp joined #parrot
00:51 Lorn joined #parrot
01:16 particle1 joined #parrot
01:44 cotto perl6: say %*VM<config><revision>
01:44 polyglotbot OUTPUT[get_pmc_keyed() not implemented in class 'Undef'␤current instr.: '_block11' pc 40 (EVAL_12:23)␤called from Sub 'parrot;PCT;HLLCompiler;eval' pc 866 (src/PCT/HLLCompiler.pir:501)␤called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1141 (src/PCT/HLLCompiler.pir:631)␤called from Sub
01:44 polyglotbot ..'parrot;PCT;HLLCompiler;command_line' pc 1320 (src/PCT/HL...
01:55 japhb joined #parrot
02:01 jimmy joined #parrot
02:10 Andy OK, are we done with the command-line stuff yet?
02:14 jimmy i found that some place use _config() function to get OS name, I think using sysinfo is more better.
02:14 jimmy such as runtime\parrot\library\pcre.pir
02:14 chromatic We may not have had sysinfo when that came about.
02:17 jimmy yesterday we replaced one place. http://svn.perl.org/viewvc/parrot/trunk/runtime/p​arrot/library/File/Spec.pir?r1=32388&amp;r2=32488
02:17 jimmy but there is a little confused
02:21 jimmy mostly we use sysinfo to get os name like pipp, basic
02:22 jimmy because _config() need to open a file, and it is not needed to only get a os name.
02:27 bacek_ joined #parrot
02:31 davidfetter joined #parrot
02:32 dmknopp left #parrot
02:32 dmknopp joined #parrot
02:45 dmknopp left #parrot
02:59 jimmy why we have no sysinfo?
03:00 s1n joined #parrot
03:05 Tene joined #parrot
03:07 dalek r32504 | chromatic++ | trunk:
03:07 dalek : [IMCC] Moved yet another static variable into the IMCC_INFO structure.  Sadly,
03:07 dalek : still more re-entrancy problems remain (see RT #60170).
03:07 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32504
03:12 kj joined #parrot
03:17 * kj arrived in san francisco, and loves it :-)
03:17 * Coke finds his name mentioned in concert with languages/lolcode in a youtube video starring pmichaud.
03:17 kj coke: link?
03:18 Theory joined #parrot
03:27 Andy joined #parrot
03:28 Coke it'll be in the upcoming partcl blog post.
03:28 Coke notfound?
03:28 Coke purl, notfound?
03:28 purl coke: bugger all, i dunno
03:33 Coke posted: http://partcl.blogspot.com/
03:34 autarch joined #parrot
03:35 * Tene doesn't see lolcode mentioned there.
03:36 chromatic http://www.youtube.com/watch?v=DzpSREpLJY8
03:36 autarch I'm working on the parrot grant update for Sep & Oct
03:37 autarch did the IO implementation get done? http://www.perlfoundation.o​rg/parrot_grant_from_nlnet for details
03:37 autarch Specifically, it says "Complete and deliver a functional implementation of Parrot's synchronous and asynchronous I/O subsystem."
03:37 autarch I assume that the MMD stuff did get done, because I see mention of merging an MMD branch in the design minutes
03:38 chromatic The IO implementation is still in a branch and still in progress.
03:38 chromatic MMD has merged.
03:38 autarch I'm also interested in characters sets and garbage collection
03:38 autarch chromatic: MMD was you and allison?
03:39 autarch also, I don't suppose there's any chance pmichaud and kjs finished the PCT docs?
03:39 autarch I'd love to see the grant fully paid out, we're really close ;)
03:39 kj autarch: I haven't worked on it recently.
03:40 autarch plus then I won't have to write any more reports ;)
03:40 autarch kj: there's money in it for you if you do!
03:40 kj I'm not entirely clear what exactly should be written, except that things should be "finished"
03:40 kj but I'm not really clear what info and in what format.
03:41 kj so I guess that'd be something that could be discussed next weekend.
03:41 autarch kj: basically, what I'm looking for is a "blessed" PDD moved out of drafts
03:42 autarch but I'm not qualified to say what the contents should be
03:42 kj ok. Yeah, I guess I have trouble distinguishing design and implementation
03:42 kj conceptually I understand the difference
03:43 kj (I should anyway, that's what you're supposed to be able to do with a CS degree :-)
03:43 autarch design is what you write _about_, implementation is code
03:43 kj hehe yeah I get *that*
03:43 autarch it doesn't need to set in stone for all time
03:43 autarch in fact, since the _implementation_ was already paid for, simply documenting what's there nwo should suffice
03:46 chromatic joined #parrot
03:46 jimmy is there anybody chinese?
03:46 jimmy kj?
03:46 purl well, kj is Klaas-Jan Stol or mailto:parrotcode@gmail.com
03:46 kj what makes you thinkI'm chinese? :-)
03:46 jimmy hehe
03:47 kj although I do like the country :-)
03:47 jimmy this word 'hehe' ;)
03:48 kj I know what you mean ;-) It seems to be common in Chenglish.
03:49 autarch so anyone know about character set of garbage collection initial implementations?
03:49 autarch I know garbage collection was worked on for SoC, but I'm not sure where that stands
03:50 chromatic GC hasn't merged yet.
03:50 chromatic Character set hasn't started yet.
03:50 autarch ok
03:51 chromatic Did you get my list of everyone who worked on MMD?  My net connection burped.
03:54 autarch I did not
03:55 chromatic Nuno (smash), Andrew (Wknight), and Julian (NotFound) also worked on it.
03:56 bacek_ chromatic: (about #60170) there is 'static opcode_t *pc' in e_pbc_emit which used in verify_signature call.
03:56 bacek_ With proper comment 'move to IMCC_INFO' :)
03:56 chromatic bacek_, that may be what I'm looking for.
03:57 kj chromatic: w.r.t. your patch to make the :immediate + load_bytecode .. (more)
03:58 autarch left #parrot
03:58 kj i realized later that this is exactly why the pir compiler must be completely reentrant; so moving the stuff to imcc-info, as you did, was not enough ( I could have known that before)
03:58 kj *all* global fields must be removed.
03:59 Psyche^ joined #parrot
03:59 chromatic We're getting there.
04:02 Coke chrome++
04:02 Coke chromatic: I think RT #48024 is closable once we remove the few remaining deprecated opcodes.
04:03 Coke there's a vtable or two left, but those are separate tickets.
04:13 dalek r32505 | chromatic++ | trunk:
04:13 dalek : [IMCC] Replaced still more static variables with entries in IMCC_INFO.
04:13 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32505
04:30 jimmy Is there a history link about talking here?
04:31 Coke backlog?
04:31 purl backlog is, like, not in the form of a set of bug reports
04:32 Coke parrot log?
04:32 Coke irc log?
04:32 purl irc log is http://irclog.perlgeek.de/parrot/
04:32 Coke there you go.
04:32 jimmy kj: so welcome to china.
04:32 Coke backlog is probably irc log
04:32 Coke parrot log is probably irc log
04:33 Coke btw, hi, jimmy. =-)
04:33 jimmy got it
04:33 jimmy thanks
04:33 kj jimmy: you're in china?
04:33 jimmy yes
04:33 kj where about?
04:34 jimmy shenzhen
04:34 kj ah yes. Know the name, can't point it on the map though
04:34 kj I was in beijing for a couple of months
04:35 jimmy round Hong Kong
04:37 jimmy trave in beijing?
04:37 jimmy travel in beijing?
04:38 kj I lived in BJ and did an internship there
04:39 dalek r32506 | chromatic++ | trunk:
04:39 dalek : [IMCC] Removed two unused global variables.
04:39 jimmy really, so i think you can speak chinese too. oops!!
04:39 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32506
04:39 kj bu hui ;-)
04:40 jimmy 'bu hui' is chinese words.
04:40 jimmy and hehe means laughing in chinse too.
04:44 dalek r32507 | coke++ | trunk:
04:44 dalek : RT #48024 - remove last user facing integer opcodes that refernece type ids. (2 of which only throw exceptions anyway).
04:44 dalek : Fix some docs on a few opcodes while we're at it.
04:44 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32507
04:56 tewk ?.const .Sub glutInit = 'glutInit'
04:56 tewk doesn't parse anymore.
04:59 kj was that already removed from the parser/imcc?
05:00 kj Removed the .const .TYPEID syntax from IMCC and updated all libraries
05:00 kj > and tests where I found it in r32419.
05:00 chromatic Should be gone.
05:00 kj (from an email)
05:00 chromatic use .const 'Sub' foo = 'bar' now
05:07 tewk examples/opengl/*.pir were not changed.
05:13 * Coke notes that .tailcall is about to become required.
05:14 Coke (patches to everything in 'make' coming shortly...)
05:16 dalek r32508 | chromatic++ | trunk:
05:16 dalek : [IMCC] Replaced several more global variables in IMCC with flags in IMCC_INFO.
05:16 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32508
05:20 dalek r32509 | coke++ | trunk:
05:20 dalek : RT #58974 - .return is deprecated when .tailcall could be used.
05:20 dalek : This covers all the cases invoked during 'make'
05:20 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32509
05:30 Coke it would be nice if src/gen_builtins.pir said what built it.
05:31 tewk japhb: glVertex3f works but glColor3f doesn't seem to work.
05:31 Coke OOK. it's just a big concat? (why not just .include them?)
05:31 Coke makes fixing bugs in the original source -painful-
05:40 notbenh joined #parrot
05:43 * Coke has a patch for rakudo's .tailcall usage...
05:44 Coke compiles!
05:44 purl SHIP IT
05:44 Coke (also passes test, but purl++)
05:46 dalek r32510 | coke++ | trunk:
05:46 dalek : [rakudo] RT #58974 - use of .return as a synonym for .tailcall is [DEPRECATED]
05:46 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32510
05:51 dalek r32511 | coke++ | trunk:
05:51 dalek : [APL] RT #58974 - use of .return as a synonym for .tailcall is [DEPRECATED]
05:51 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32511
05:55 dalek r32512 | tewk++ | trunk:
05:55 dalek : [opengl examples] change .Sub to 'Sub'
05:55 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32512
05:55 Coke cardinal?
05:55 purl hmmm... cardinal is http://mail.freesoftware.fsf​.org/pipermail/cardinal-dev/ or the Ruby-on-Parrot project. or http://xrl.us/uyz3
05:55 Coke Tene?
05:55 purl Tene is probably Stephen Weeks
05:56 Coke is cardinal supposed to be passing 100% in trunk?
05:56 Coke s/supposed/expected/
05:57 TimToady joined #parrot
05:57 diakopter joined #parrot
06:01 dalek r32513 | coke++ | trunk:
06:01 dalek : [cardinal] RT #58974 - use of .return as a synonym for .tailcall is [DEPRECATED]
06:01 dalek : (getting some test failures which appear to be unrelated to this patch.)
06:01 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32513
06:06 dalek r32514 | coke++ | trunk:
06:06 dalek : [pheme] RT #58974 - use of .return as a synonym for .tailcall is [DEPRECATED]
06:06 dalek : one unrelated test failure in t/null.t with an <<<assign $PXX, '''>>>
06:06 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32514
06:13 dalek r32515 | coke++ | trunk:
06:13 dalek : [pipp] RT #58974 - use of .return as a synonym for .tailcall is [DEPRECATED]
06:13 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32515
06:15 dalek r32516 | coke++ | trunk:
06:15 dalek : [punie] RT #58974 - use of .return as a synonym for .tailcall is [DEPRECATED]
06:15 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32516
06:17 dalek r32517 | coke++ | trunk:
06:17 dalek : [pynie] RT #58974 - use of .return as a synonym for .tailcall is [DEPRECATED]
06:17 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32517
06:21 japhb tewk: Dang it, I'd committed a .Sub -> 'Sub' fix locally, but forgot to push it upstream.  Was planning to do it when I got back to my desk, and then you beat me to it.  :-)
06:24 * Coke thinks that's enough languages. :|
06:24 Coke someone want to volunteer to go through the docs and update any bare .return <sub> to .tailcall <sub> ?
06:31 particle joined #parrot
06:33 jimmy hello particle
06:33 dalek r32518 | coke++ | trunk:
06:33 dalek : RT #58974 - use of .return as a synonym for .tailcall is [DEPRECATED]
06:33 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32518
06:37 * tewk for the second time in his life has wasted 15 minutes surfing the web to find out chromatics real name:)
06:38 japhb Why bother?
06:38 japhb tewk: Did you figure out why doubles were working, but not floats?
06:41 Coke chromatic?
06:41 Coke purl, chromatic?
06:41 purl well, chromatic is <req>a lot of fun.  For years I'd try to play stuff like `peter and the wolf', and then I'd be frustrated because it would use some note I didn't have. or the author of jellybean or mailto:chromatic@wgz.org or http://wgz.org/chromatic/ or the winner of the not-a-contest perl-bugathon. or best reached via email. or the guy who hit me in the eye.
06:42 * Coke tries to post a reply to via RTweb and has it hang.
06:42 tewk Coke: have no fear, I found it, but it isn't item #1 on google search. :)
06:43 tewk japhb: no not yet, the funny thing is that glVertex3f with the same NCI signature 'vfff' seems to work fine, yet glColor4f doesn't.
06:43 tewk japhb: no not yet, the funny thing is that glVertex3f with the same NCI signature 'vfff' seems to work fine, yet glColor3f doesn't.
06:44 japhb odd
06:45 tewk I couldn'
06:46 tewk t get glColor3b or glColor3ub to work either.
06:46 tewk I'm sure there is an explaination, I just haven't found it yet.
06:51 japhb nodnod
06:52 * Coke posts his followup via gmail instead.
06:56 Coke ->
06:57 davidfetter joined #parrot
06:59 bacek joined #parrot
07:01 * jimmy slaps particle around a bit with a large trout
07:01 Tene Coke: cardinal doesn't pass all of its tests.
07:14 chromatic Ahh, you invalidated bytecode!
07:22 notbenh joined #parrot
07:23 uniejo joined #parrot
07:37 dalek r32519 | chromatic++ | trunk:
07:37 dalek : [examples] Removed deprecated PMC type integers.
07:37 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32519
07:38 jimmy is particle online?
07:41 dalek r32520 | fperrad++ | trunk:
07:41 dalek : [Lua] tailcall
07:41 dalek : - remove useless generated code (LuaNil instantiation)
07:41 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32520
07:42 dalek r32521 | japhb++ | trunk:
07:42 dalek : [OpenGL] WIP: Conversion of shapes.pir to Perl 6
07:42 dalek : * So far, only about 1/3 done with conversion
07:42 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32521
07:44 dalek r32522 | japhb++ | trunk:
07:44 dalek : [OpenGL] Set SVN props on shapes.p6
07:44 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32522
07:54 Zaba joined #parrot
07:57 dalek r32523 | fperrad++ | trunk:
07:57 dalek : [Lua] tailcall
07:57 dalek : - revisit r32520
07:57 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32523
08:01 Zaba joined #parrot
08:04 dalek r32524 | fperrad++ | trunk:
08:04 dalek : [Pipp] POD
08:04 dalek : - basename is implemented
08:04 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32524
08:09 jimmy i post a email to parrotbug@parrotcode.org
08:09 jimmy but no any replay for hours
08:12 jimmy is it time?
08:14 chromatic Sometimes it's slow.
08:15 jimmy got it.
08:19 Zaba joined #parrot
08:25 Zaba_ joined #parrot
08:26 contingencyplan joined #parrot
08:33 jimmy left #parrot
08:35 jimmy joined #parrot
08:36 Zaba joined #parrot
08:37 jimmy left #parrot
08:37 jimmy joined #parrot
08:37 jimmy left #parrot
08:38 jimmy joined #parrot
08:59 Zaba joined #parrot
09:05 AndyA joined #parrot
09:13 iblechbot joined #parrot
09:29 Ademan joined #parrot
09:36 Zaba joined #parrot
09:37 elmex joined #parrot
09:43 bacek good evening
09:43 bacek purl: hi
09:43 purl salut, bacek.
09:50 apeiron joined #parrot
09:51 jonathan morning all
09:51 purl morning, jonathan
09:51 jimmy moring jonathan
10:03 davidfetter_ joined #parrot
10:06 bacek joined #parrot
10:08 Zaba joined #parrot
10:23 cosimo joined #parrot
10:29 jimmy joined #parrot
10:29 tomyan joined #parrot
10:37 slavorg joined #parrot
10:39 ruoso_ joined #parrot
10:41 ruoso_ joined #parrot
10:45 Zaba joined #parrot
10:46 dalek r32525 | jonathan++ | trunk:
10:46 dalek : [rakudo] Add tests for is also to spectest_regression.
10:46 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32525
10:48 moritz jonathan: it's called just `spectest' nowadays, spectest_regression is just an alias for backwards compatibility ;)
10:48 jonathan moritz: Yes, I 'know' that. Just habbit!
10:51 jonathan moritz: Do you remember where there are any tests for being able to assign an Int to a Num?
10:51 jonathan I just fixed the type check here.
10:52 moritz jonathan: I had one just yesterday...
10:52 moritz jonathan: in autovivification.t
10:53 moritz (t/spec/S03-operators)
10:53 moritz but I can run autounfudge if you want
10:54 moritz uh, it's not even in spectest.dat yet...
10:55 moritz it should be
10:55 jonathan oh, hmm
10:55 jonathan I'm not 100% sure if that's exactly what I just fixed, but it may well work now.
10:56 moritz did you already commit it?
10:56 jonathan No
10:56 jonathan It's caused some bug.
10:56 dalek r32526 | moritz++ | trunk:
10:56 dalek : [rakudo] add autovivification tests to spectest.data
10:56 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32526
10:57 moritz then there's no point for me running autounfudge yet ;)
10:57 moritz did you fix it just for assignment, or also for multi dispatch?
10:57 jonathan Well, that's actually the problem.
10:58 jonathan The real thing these all boil down to is 42 ~~ Num
10:58 jonathan my Num $x = 42; # does 42 ~~ Num
10:58 jonathan But the multi sub test checks this too
10:59 jonathan And then we get a conflict, because
10:59 jonathan multi foo (Int $bar)   { "Int "  ~ $bar  }
10:59 jonathan and
10:59 jonathan multi foo (Num $bar)   { "Num "  ~ $bar  }
10:59 jonathan Both accept a dispatch with an Int.
10:59 moritz yes, but the Int one is closer
10:59 jonathan Yeah, but how and why?
11:00 jonathan I agree, but how am I supposed to implement that?
11:00 moritz dunno
11:00 jonathan Like, Int is not a subclass of Num in Perl 6, AFAIK.
11:00 jonathan If it was, we'd have been able to make it that way before now and fix this...
11:00 jonathan I've had to add a special case to get this to work, and I suspect I'm going to need to special case it in the multi-dispatcher too.
11:01 moritz tie-brakeing by checking for dierect types vs. roles?
11:01 jonathan There's no roles involved here, though.
11:01 jonathan Int and Num are both real, concrete types.
11:01 moritz my idea would be that Num is both a a class and a role
11:01 moritz and Int does Num
11:01 moritz and Complex does Num
11:01 moritz but I have no idea if it works out in the end.
11:02 jonathan Even then, I'm not sure.
11:02 jonathan Hmm.
11:02 moritz we had a discussion the other day on p6l about the numeric types
11:03 moritz and what TimToady said was that they don't fit into our current type system
11:03 cognominal_ jonathan, when native types like int will be supported in rakudo?
11:03 jonathan moritz: Did that imply our current type system needed fixing somehow?
11:03 jonathan Or that they were intended to be special cases?
11:03 jonathan cognominal_: Not for a while.
11:04 cognominal_ ok, just curious
11:05 moritz jonathan: I think the conclusion was that the implementors have to figure it out ;(
11:05 moritz http://www.nntp.perl.org/group/perl.​perl6.language/2008/06/msg29310.html buried somewhere in that thread
11:05 moritz look for replies by timtoady
11:06 moritz http://www.nntp.perl.org/group/perl.​perl6.language/2008/06/msg29323.html Larry proposes boxing
11:06 Lorn joined #parrot
11:07 cognominal_ jonathan,  42 ~~ Int > 42 ~~ Num   #  can a ~~ return a Int in numéric context?   :)
11:07 cognominal_ so that preferences can be expressed
11:08 cognominal_ I don't know how it scales with MMD though
11:08 jonathan Hmm
11:09 jonathan I think that, for now, just making Int be considered specially narrower when doing narrowness analysis might do us for now.
11:10 jonathan Oh
11:10 jonathan Hmm
11:10 jonathan Actually
11:10 jonathan I think that I don't need to
11:11 jonathan But something is wrong inside MMD more generally with narrowness analysis and we just start to tickle that now.
11:11 jonathan It's a bug already on my fix list.
11:11 moritz jonathan: I submitted a bug report about subset types and MMD (back in the days) that might tickle the same issue
11:11 cognominal_ tcpw was good?
11:11 jonathan Maybe.
11:12 jonathan I've got a bunch of work left to do on MMD
11:12 jonathan cognominal_: Yes, it was! :-)
11:12 cognominal_ I wish I could have been there
11:12 jonathan Was great to have a conference in my current home city. :-)
11:12 jonathan Well, I think we may well repeat it, was quite successful.
11:12 cognominal_ at least you avoided evil green stuff related epic failures
11:13 cognominal_ how many people?
11:18 jonathan Over 40, I think 45ish
11:23 cognominal_ jonathan, you were speaking working an iphone app? is that true? or did I misunderstood you?
11:23 jonathan cognominal_: I was going to be, but the company I was going to be doing it for never got the venture capital they were aiming for to do it.
11:23 jonathan So I never got to do it.
11:23 cognominal_ too bad
11:24 jonathan Yeah, woulda been fun to play with.
11:24 jonathan oh, argh
11:24 jonathan I've found the multi sub bug
11:24 cognominal_ I got a iphone and I learn the API to write a pentomino app
11:24 jonathan Well, I've found multiple actually.
11:24 jonathan Damm, what was I on when I wrote this...
11:32 * jonathan thinks he has a fix
11:33 jonathan At least, it fixes the Num/Int case.
11:33 jonathan With no extra code.
11:33 jonathan Phew.
11:44 dalek r32527 | jonathan++ | trunk:
11:44 dalek : [rakudo] Fix a couple of bugs in candidate sorting for MMD. One was an off-by-one error. The other was more subtle; we mustn't remove edges from the graph per iteration of the topological sort, otherwise we end up not identifying one candidate as narrower than another, depending on the order they appear in the code.
11:44 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32527
11:44 dalek r32528 | jonathan++ | trunk:
11:44 dalek : [rakudo] Make the Num type also accept Int values.
11:44 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32528
11:45 clunker3 joined #parrot
11:46 jonathan I think that MMD fix will help out a lot of things.
11:47 jonathan moritz: You can autofudge now :-)
11:51 jonathan moritz: Also, the subset ticket you have now runs.
11:56 Zaba joined #parrot
11:58 jonathan moritz: I fear this test script is not so good though.
11:58 jonathan subset Even of Int where { $_ % 2 == 0 };
11:58 jonathan subset Odd  of Int where { $_ % 2 == 0 };
11:58 jonathan ;-)
12:03 jonathan Oddness. The test works in the REPL, but not in the test script. :-|
12:07 moritz jonathan: autounfudge running, will be back in a few hours
12:08 Zaba joined #parrot
12:12 Ontolog joined #parrot
12:16 dalek r32529 | bernhard++ | trunk:
12:16 dalek : [codingstd] Satisfy c_operator.t
12:16 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32529
12:27 dalek r32530 | jonathan++ | trunk:
12:27 dalek : [rakudo] Must create subset types earlier (in the end at compile time, but for now moving them to $?INIT, the same time as we do classes, makes things work much better).
12:27 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32530
12:27 dalek r32531 | tewk++ | trunk:
12:27 dalek : [Jitted NCI] added a vfff test, it passes which doesn't shed any light on the OpenGL failures
12:27 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32531
12:33 Zaba joined #parrot
12:48 dalek r32532 | jonathan++ | trunk:
12:48 dalek : [rakudo] Add multi dispatch based on subset types test.
12:48 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32532
12:51 jimmy joined #parrot
13:13 jimmy can i create a ticket manully at http://rt.perl.org/ ?
13:15 Coke no. followup can be via the web, but initial ticket creation is email only, I think.
13:16 Coke you're not pioto, are you?
13:16 jimmy I post  a email to parrotbug@ parrotcode.org for hours, there is no ticket created.
13:17 Coke I can take hours, yes; perl.org machine are occasionally spammed out.
13:17 Coke s/I/It/
13:18 jimmy is pioto a name?
13:18 jimmy not me
13:18 Coke email. from #60474; most recent ticket I see.
13:18 Coke You could nopaste it in the meantime.
13:18 Coke nopaste?
13:18 clunker3 http://pasta.test-smoke.org/ or http://paste.husk.org/ or http://nopaste.snit.ch:8001/ or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/
13:18 purl nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/
13:18 Coke ... clunker3 !?
13:19 * Coke hates irc.
13:19 jimmy poito is not me
13:19 jimmy i am jimmy
13:21 Coke so, anyway, if the email/ticketing system has temporarily eaten your message, you can nopaste it here or resend to the list.
13:24 Coke I just got the email for 60474, which my client says came at 1AM. (that's about a six hour lag, if everyone did their TZ math properly)
13:24 Coke ooh, which I didn't. it's about a 7.5 hour lag.
13:24 Coke so if yours was sent in that window...
13:25 jimmy i post my email more than 8 hour.
13:25 jimmy -)
13:29 jimmy nopaste?
13:29 clunker3 http://pasta.test-smoke.org/ or http://paste.husk.org/ or http://nopaste.snit.ch:8001/ or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/
13:29 purl somebody said nopaste was at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/
13:30 Coke Yup; sorry about the delay; the perl.org servers are not under our control.
13:31 jimmy http://rafb.net/p/jq3pph91.html
13:33 iblechbot joined #parrot
13:37 jimmy this is the nopaste link.
13:37 Coke yup, already checking it out, thanks.
13:38 jimmy and http://svn.perl.org/viewvc/parrot/trunk/runtime/p​arrot/library/File/Spec.pir?r1=32388&amp;r2=32488
13:39 mkelly32 jimmy: i'm pioro
13:39 mkelly32 err, pioto
13:39 jimmy can this be applied to to other place?
13:39 jimmy Coke: pioto is here.
13:40 jimmy hello, pioto.
13:41 mkelly32 hi
13:41 barney joined #parrot
13:41 jimmy hello barney, i have written test case for basename.
13:42 barney cool. Can you nopaste or mail to Bernhard.Schmalhofer@gmx.de ?
13:43 jimmy here: http://rt.perl.org/rt3/Tic​ket/Display.html?id=60432
13:44 dalek r32533 | bernhard++ | trunk:
13:44 dalek : [codingstd] Get rid of a probably unnecessary 'import'.
13:44 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32533
13:45 Coke jimmy: thanks, applied.
13:45 jimmy and can you change my credit Jimmy to Jimmy Zhuo?
13:46 jimmy thanks coke too.
13:46 mkelly32 jimmy, Coke: actually, i need to head off to work now. i just tested again w/ latest HEAD and still am experiencing the bug. if you need me to provide more info, etc, can you drop me an email?
13:46 Coke mkelly32: I hadn't touched your ticket; was just wondering if jimmy was you. sorry about the confusion.
13:46 mkelly32 oh, ok
13:46 mkelly32 well, no hurry then
13:46 dalek r32534 | coke++ | trunk:
13:46 dalek : [CAGE] magic constants are bad. Courtesy jimmy++
13:46 dalek : ... I have no idea if this impacts BASIC, but it certainly looks reasonable.
13:46 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32534
13:48 Coke jimmy++ : done
13:49 dalek r32535 | coke++ | trunk:
13:49 dalek : Add jimmy++ surname.
13:49 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32535
13:49 jimmy thanks again.
13:50 Coke np. Thank you for your patience & patches.
13:56 barney jimmy++: Patch applied. And incremented test plan by 1
13:56 dalek r32536 | bernhard++ | trunk:
13:56 dalek : RT#60432: [PATCH]basename function implementation for pipp
13:56 dalek : add test for basename(). Courtesy of Jimmy Zhuo.
13:56 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32536
13:58 Coke lemon soaked paper napkins?
13:58 Coke curse you, purl.
13:58 purl Coke: i'm not following you...
13:59 dalek r32537 | bernhard++ | trunk:
13:59 dalek : [t] Codeformating, whitespace for t/op/sysinfo.t
13:59 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32537
13:59 * barney wonders why  t/codingstd/trailing_space.t didn't complain about t/op/sysinfo.t
14:17 masak joined #parrot
14:18 Coke barney: did you actually run the codetests?
14:18 Coke (they are no longer run by default)
14:18 * Coke wishes someone would fix those annoying parrot_test smolder failures.
14:19 Coke when the only thing that's failing is your test that tests your tester (and none of your tests...)
14:28 barney coke: I ran the codetest
14:29 barney Yes, coding standards for code tests might be overkill
14:32 gryphon joined #parrot
14:34 dalek r32538 | bernhard++ | trunk:
14:34 dalek : [t] Refactor sysinfo.t
14:34 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32538
14:41 Coke in the trailing space test, it checks for m{.?[ \t]+$} ... isn't m{\h$} more to the point?
14:43 dalek r32539 | bernhard++ | trunk:
14:43 dalek : [t] Add PIR tests for sysinfo
14:43 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32539
14:45 particle coke: that seems fine to me
14:45 Coke which, my version?
14:46 particle yes
14:46 Coke barney: why test the same stuff in pasm -and- pir?
14:46 Coke (that is basically a door for someone to walk through with our testing strategy. =-)
14:47 barney Because we can
14:47 Coke Unrecognized escape \h passed through at t/codingstd/trailing_space.t line 49.
14:50 barney Is \h new in 5.10 ?
14:50 particle i guess it's new in 6.0 :)
14:51 particle 5.10 doesn't have \h, so that's why it doesn't work
14:51 Coke yup, just figured that out (perldoc.perl.org++ for having at least one old version of the docs)
14:52 Coke still, m{[ \t]$}m is still more concise.
14:53 barney 5.10 has it, 5.8 probably not
14:53 particle er, yeah
14:54 * barney is goining out to do some chore
14:54 Coke (good thing I happened to be testing against a 5.8 version.)
14:55 dalek r32540 | coke++ | trunk:
14:55 dalek : [cage] simplify the check for trailing whitespace slightly.
14:55 dalek : (sadly, \h doesn't work in our mininum required perl version.)
14:55 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32540
14:58 jhorwitz joined #parrot
14:58 hercynium_ joined #parrot
15:10 UltraDM joined #parrot
15:16 dalek r32541 | pmichaud++ | trunk:
15:16 dalek : [rakudo]: spectest-progress.csv update: 212 files, 4199 passing, 473 failing
15:16 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32541
15:17 moritz 473 failing?
15:21 pmichaud yes.
15:21 pmichaud rx.t is aborting earlier.
15:21 pmichaud *early
15:21 moritz ah
15:22 pmichaud -G doesn't seem to help.
15:24 pmichaud jonathan++  # mmd and type fixes
15:24 pmichaud but I think there's a bug in the overall .ACCEPTS code
15:25 moritz indeed
15:25 pmichaud I need to look at that a bit closer.
15:26 jonathan hi, back
15:26 jonathan (had Slovak class)
15:27 moritz jonathan: I just did the unfudging, it found quite some pieces that were fixing in the last few days
15:28 pmichaud yes, if it weren't for the rx.t failure, we'd be well over 4600 passing.
15:30 nopaste "pmichaud" at 76.183.97.54 pasted "...what was I thinking when I wrote this?" (11 lines) at http://nopaste.snit.ch/14534
15:31 dalek r32542 | jonathan++ | trunk:
15:31 dalek : [rakudo] A while back, some changes were done that set $?CLASS when a grammar was created. But since we checked $?PACKAGE =:= $?GRAMMAR second after checking $?PACKAGE =:= $?CLASS, we stopped creating grammars properly, meaning they started inheriting from Any instead of some grammar rules. This switches around the ordering. Also re-fixes the bug originally fixed before this change where $?NS wasn't cleared.
15:31 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32542
15:33 Ademan_ joined #parrot
15:33 jonathan pmichaud: I looked at that earlier today and thought...wtf...then thought, "OK, Pm wrote it, he probably had his reasons"...
15:33 pmichaud I'll have to re-think it.
15:34 jonathan OK. I copied a chunk of it into the Num special case... ;-)
15:34 jonathan So we'll want to fix that too.
15:34 pmichaud right, that's what made me notice it.
15:34 moritz rx.t fails through harness, and works through test_summary.pl
15:34 pmichaud I'm going to clean up the Num special case slightly.
15:34 pmichaud rx.t fails for me even in test_summary.pl
15:34 pmichaud at least as of 00:00 CST it did.  It might be working now -- I'll try head.
15:35 pmichaud (test_summary.pl is what I use to produce the updates.)
15:36 jonathan my $a = G::TOP(":123"); # pmichaud - after the container changes, do the problem we had before with this doing .item and extracting the string value only go away?
15:36 masak ./perl6multisub.pmc:520: warning: control reaches end of non-void function # during the make perl6. is this something to be concerned about?
15:37 pmichaud jonathan: they will when we implement Match
15:37 pmichaud because it'll be an ObjectRef
15:37 pmichaud and we no longer call .item for assignment (at least not directly) -- it's now .Scalar
15:37 pmichaud so .Scalar can always dtrt
15:38 jonathan masak: maybe, let me look what's on that line
15:38 masak jonathan++
15:39 jonathan oh
15:39 jonathan OK, it's the typical thing.
15:39 jonathan We actually can never fall out of the function
15:39 jonathan Because we throw an exception.
15:39 jonathan Or return a value.
15:40 jonathan I'll stick some returns in to shut the compiler up.
15:40 pmichaud okay, I understand what .ACCEPTS was doing now
15:41 masak jonathan: if we can never fall out, why do we need to test for `if (!many)`?
15:41 masak seems to me we can either fall out, or the `if (!many)` is superfluous.
15:42 jonathan Oh!
15:42 masak :)
15:42 jonathan ah
15:42 jonathan yes
15:42 jonathan This function also provides a way to do some other stuff.
15:42 jonathan Like call all of a bunch of multis that match.
15:43 jonathan But I've not got to the point of using it for that yet.
15:44 jonathan masak: I don't want to work on that right now, but will put something in the code to quieten the warnings for the time being.
15:45 masak jonathan: oki. just wanted to bring it to attention.
15:45 jonathan Thanks for pointing out - it may even be fatal on some picky compilers.
15:45 * jonathan being a C disaster is a common cause of Rakudo build fail
15:45 masak ;)
15:46 jonathan pmichaud: I'm not seeing a huge bunch of failures.
15:46 jonathan pmichaud: Suspect GC?
15:47 jonathan Oh, but -G didn't help. Hmm.
15:47 jonathan Do you see rx.t bailing out on HEAD?
15:48 pmichaud jonathan: I'm trying it now.
15:49 pmichaud it passed in head.
15:49 moritz btw when I tried with HEAD today my rakudo was up-to-date, but I don't know if my parrot was.
15:49 pmichaud so it apparently just fails in the 00:00 checkout
15:49 jonathan Oh, hmm
15:49 pmichaud (r32512)
15:49 jonathan Is .namespace [] not valid syntax?
15:50 pmichaud it's valid.
15:51 jonathan oh, cunning
15:51 jonathan I'm getting things like this emitted: get_hll_global $P77, ], "_block76"
15:51 pmichaud that looks pretty wrongish.
15:51 jonathan Yes.
15:52 pmichaud get_hll_global $P77, [], "_block76"  wouldn't be valid, though.
15:52 jonathan Seems that if you :namespace() a PAST::Block and what you provide is an empty array this happens.
15:53 pmichaud that's a bug
15:53 purl No, it's a feature.
15:53 jonathan Replaced putting a string there with putting an array.
15:53 pmichaud an empty array is supposed to be allowed.
15:53 jonathan Yeah.
15:53 jonathan It does the right thing when generating the .namespace [] above the .sub
15:53 jonathan But seems to have an issue in generating the code to lookup the sub perhaps.
15:54 jonathan I'll go dig.
15:59 dalek r32543 | pmichaud++ | trunk:
15:59 dalek : [rakudo]:  Revise r32528 so that Num::ACCEPTS (re)uses existing .ACCEPTS
15:59 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32543
16:01 Coke I don't know anything about this, but should you be checking Any's accept before your own?
16:01 Coke (I would expect Any to be more permissive)
16:02 pmichaud I'm not actually checking Any's accept
16:02 pmichaud I'm using Any's .ACCEPT method on Num
16:02 pmichaud it's a superclass call
16:02 Coke meh. if it works, it works. I don't pretend to understand your object system. =-)
16:02 Coke just read oddly, 'sall.
16:02 pmichaud at present this is the only way to call superclass methods
16:03 pmichaud and it's Parrot's object system that has that issue :-)
16:03 pmichaud to check Any's ACCEPT I would be doing   $P0.'ACCEPTS'(topic)
16:04 pmichaud instead of   self.$P1(topic)
16:04 Coke So what does it mean to invoke any's accept method on a subclass?
16:04 pmichaud it's basically the same as saying    super.ACCEPTS(topic)
16:04 pmichaud (if such a syntax were supported)
16:05 pmichaud semantically,   the ACCEPT method in Any checks if the topic has the same type as self
16:05 pmichaud sorry
16:05 Coke regardless, i would expect that if you asked Any if it could .... thank you.
16:05 pmichaud if the topic 'isa' self
16:06 pmichaud so, I'm not changing self here -- 'self' is still the Num instance
16:06 Coke without looking at how any's ACCEPTS is implemented, I'd expect Any to accept anything, which would make me expect that call to -always- return true, hence my confusion. The syntax was just a red herring.
16:06 Coke thanks for the clearup.
16:09 PerlJam everytime I look here, you guys are always talking about crazy stuff.
16:09 PerlJam I'm going to continue to believe that that's a Good Thing.  :-)
16:12 PerlJam pm:In the line $P0 = get_hll_global 'Any', is it always 'Any', or must that be the name of the superclass?
16:12 pmichaud it has to be the name of the superclass
16:12 PerlJam That's what I thought.
16:13 pmichaud at present there's not an easy way in parrot to say "get xyz method from my superclass"
16:13 PerlJam Yeah, that seems awkward
16:13 pmichaud well, there's also the issue that there may be multiple superclasses
16:13 pmichaud I might add something to P6object to support that.
16:16 particle so, Super PMC still isn't working?
16:18 jonathan Why would I want to instantiate another PMC just to do a call to a superclass?
16:18 particle you do it to iterate
16:18 jonathan pmichaud: You can look the method up in the namespace of the superclass and then use the obj.$P0(...) syntax
16:18 jonathan particle: Iterate the super classes?
16:18 pmichaud jonathan: that will eventually break.
16:19 jonathan pmichaud: ah
16:19 particle jonathan: no, iterate a pmc
16:19 pmichaud because sometime soon methods won't automatically be in the namespace of the superclass.
16:19 jonathan Use find_method on the superclass
16:19 particle iter op creates a new pmc
16:19 jonathan Sure
16:19 jonathan But what's that got to do with anything?
16:20 * jonathan thinks he's missing a point somewhere
16:20 pmichaud anyway, find_method on the protoobject is the best approach for now.
16:21 pmichaud there's not a way to use find_method on a superclass (Class PMC) directly, afaik
16:21 jonathan pmichaud: My fix for the namespace code-gen bug appears to work - all spectests pass now (aside from the declaration order one, which I may just pull out of the spectest.data...)
16:21 jonathan pmichaud: No, you'd have to use inspect to look up the parent class, and then use it on that.
16:21 jonathan Oh, there's not an op that calls find_method?
16:21 jonathan Hmm.
16:21 pmichaud find_method is an op.
16:21 jonathan OK
16:21 jonathan So can use that.
16:22 jonathan Oh, wait
16:22 pmichaud but if you use it on a Class PMC, you're looking up the methods of the Class PMC and not an instance
16:22 jonathan It needs an instance...
16:22 jonathan Yes.
16:22 jonathan d'oh
16:22 pmichaud thus, use it on the protoobject
16:22 jonathan *nod*
16:22 pmichaud (which is exactly what I'm doing in r32543)
16:23 pmichaud the other problem with looking up in a namespace is that one would have to know exactly which namespace to look up in
16:23 pmichaud for example, in this case, there really *isn't* an 'ACCEPTS' method in Any -- it's inherited from some superclass of Any
16:23 jonathan Yes, and it won't work for anonymous classes.
16:23 jonathan Where there is no namespace.
16:23 jonathan Nor lexical ones
16:23 jonathan So yes, bad idea.
16:23 PerlJam jonathan: I think the point is that dealing with superclasses in parrot is currently awkward :)
16:24 jonathan pmichaud: In my patch I did:
16:24 jonathan ##  determine name and namespace
16:24 jonathan name = self.'escape'(name)
16:24 jonathan -    $I0 = defined ns
16:24 jonathan -    unless $I0 goto have_ns_key
16:24 jonathan +    unless ns goto have_ns_key
16:24 jonathan Which worked, but now I realize maybe isn't right.
16:24 jonathan YOu were probably using defined because you wanted to generate different code when an empty string was supplied rather than just no value at all?
16:24 pmichaud yes
16:25 jonathan That would generate a get_hll_global result, '', name though..
16:25 bacek joined #parrot
16:25 jonathan oh
16:25 jonathan ns = $P0.'key'(ns)
16:25 jonathan Maybe the bug is inside the key method
16:25 pmichaud I was preserving the possibility that there might be a [''] namespace.
16:25 jonathan OK
16:25 pmichaud which is different from the [] namespace
16:26 jonathan OK.
16:26 jonathan So I guess I can't just fix it like that...
16:26 pmichaud well, I might decide that [''] namespace is bogus.
16:26 pmichaud at least for PCT
16:26 jonathan Like now? ;-)
16:26 pmichaud and that if someone wants [''], they have to explicitly provide an array with an empty string.
16:26 jonathan Oh, that'd work.
16:27 jonathan It doesn't break anything in Rakudo to do the patch I did.
16:27 jonathan Nor the PCT tests.
16:27 pmichaud if all the tests pass in your patch I think we can go with it for now.  we might need to review other parts of PCT to make sure they're consistent as well.
16:27 pmichaud PCT tests aren't really useful.  NQP is the best test for PCT.
16:28 jonathan Well, NQP is working I guess if we successfully get a Rakudo that passes all the spectests. ;-)
16:28 Theory joined #parrot
16:28 dalek r32544 | jonathan++ | trunk:
16:28 dalek : [PCT] Fix to code generation when we have a namespace supplied as an empty array.
16:28 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32544
16:30 dalek r32545 | jonathan++ | trunk:
16:30 dalek : [rakudo] Make C compiler shut up with its warnings. Spotted by masak++.
16:30 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32545
16:31 pmichaud I would've phrased that as "Give the C compiler less to complain about."   :-)
16:31 moritz but some people are blunt ;)
16:33 pmichaud I've found that it's nearly impossible to make a C compiler do anything.  :-)
16:33 jonathan It's all about the way your phrase things to it. ;-)
16:46 dalek r32546 | jonathan++ | trunk:
16:46 dalek : [rakudo] Make grammars in namespaces work correctly. Patch courtesy of Chris Dolan.
16:46 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32546
16:46 dalek r32547 | jonathan++ | trunk:
16:46 dalek : [rakudo] Add a namespace/grammar related spectest file.
16:46 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32547
16:48 Coke jonathan: 32545 seems wrong.
16:48 jonathan Coke: Why?
16:48 Coke shouldn't your compiler be smart enough to know that throw* doesn't return control?
16:48 jonathan I don't think any compilers are?
16:48 Coke (isn't that why we're marking all these subs with attributes?)
16:48 jonathan Oh, hmm.
16:49 jonathan Maybe they are not needed then and the warning just related to the missing else block.
16:49 dalek r32548 | pmichaud++ | trunk:
16:49 dalek : [rakudo]:  fix trailing space
16:49 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32548
16:51 pmichaud parrotsketch in 99
16:52 moritz I'll probably miss #ps, but I've got nothing interesting to report - just the usual testing + patch-monkeying
16:53 moritz I've observed some general brokenness of the harness, but perhaps I should take that to the list instead
16:56 Andy joined #parrot
16:58 Coke time?
16:58 purl hmmm... time is 16:58:13 2008 and (did you mean "clock"?) or flowing like a river
16:58 Coke clock?
16:58 purl Coke: LAX: Tue 8:58am PST / CHI: Tue 10:58am CST / NYC: Tue 11:58am EST / LON: Tue 4:58pm GMT / BER: Tue 5:58pm CET / IND: Tue 10:28pm IST / TOK: Wed 1:58am JST / SYD: Wed 3:58am EST /
17:04 * jonathan sets about doing the MAIN sub
17:04 pmichaud keep in mind that the full implementation of MAIN is part of particle's grant
17:05 jonathan pmichaud: I ain't going to parse @*ARGS, just pass -em
17:05 pmichaud sure thing.
17:05 jonathan pmichaud: japhb asked for it yesterday, and I think that'll be enough for him.
17:06 japhb jonathan: yep, precisely
17:06 * jonathan doesn't want to write the args parser ;-)
17:06 pmichaud so, do we just check for a sub called 'MAIN' and call it?
17:06 * japhb doesn't either.
17:06 jonathan That would be an easy way...
17:06 jonathan In fact, I think the best way.
17:06 jonathan We just need to make sure we only do this if we're run directly.
17:06 pmichaud do we do that after the main invocation, or as part of it, or...?
17:07 pmichaud "run directly" isn't really an issue
17:07 jonathan We run anything that's in the main body.
17:07 jonathan As in, not in a subroutine
17:07 pmichaud but the MAIN body gets run after the "main"
17:07 jonathan Yes.
17:07 japhb particle: This reminds me ... when you're working on the arg-parsing grant, remember that some of us have to work with libraries that expect to get a pass at the command line.  X toolkits, for instance, want to pull geometry and display arguments out of the command line.
17:07 jonathan This call is performed if and only if:
17:07 jonathan a)
17:07 jonathan the compilation unit was directly invoked rather than by being required by another compilation unit, and
17:07 barney joined #parrot
17:07 jonathan b)
17:07 jonathan the compilation unit declares a Routine named "MAIN", and
17:07 jonathan c)
17:07 jonathan the mainline code is not terminated prematurely, such as with an explicit call to exit, or an uncaught exception.
17:09 pmichaud so, I'm thinking override 'evalpmc' from HLLCompiler
17:09 pmichaud although I guess that doesn't quite work with precompiled modules
17:09 jonathan Hmm
17:10 jonathan How do we know if we're being required by another compilation unit?
17:10 pmichaud do we have to know that?
17:10 pmichaud I'm thinking we only call MAIN explicitly
17:10 pmichaud i.e., it should never be part of :load or :init
17:11 jonathan Ah, OK.
17:11 jonathan You mean do it inside perl6.pir?
17:11 pmichaud yes, but that won't work for precompiled modules
17:11 pmichaud (inside perl6.pir really means "override evalpmc" afaict)
17:12 pmichaud we could, for the time being, simply say that MAIN doesn't work for precompiled modules
17:12 pmichaud then it could be done from perl6.pir (or equivalent) fairly simply.
17:14 pmichaud or, to get it to work for precompiled modules, we just tag any MAIN sub with :main
17:14 pmichaud (checking precompiled output)
17:15 jonathan pmichaud: That doesn't quite work because we need to call it explicitly with @ARGS
17:15 jonathan pmichaud: We could however emit a :main that does that.
17:15 pmichaud yes, that would work.
17:15 jonathan As in, a separate Parrot sub.
17:16 jonathan Question is, will that then get run when we compile?
17:16 jonathan Might need to do both.
17:16 pmichaud no.
17:16 pmichaud yes, we need both
17:16 jonathan OK
17:16 pmichaud a :main sub for precompiled form, and a way of calling MAIN from perl6.pir
17:16 pmichaud that takes care of the two cases, and we don't have to worry about if something is loaded because its MAIN doesn't fall in either of those two cases
17:17 pmichaud for the :main sub, simply generate it if a subroutine is declared called MAIN
17:17 jonathan Yes, I was planning on tracking that.
17:17 jonathan our $?HAVE_MAIN
17:17 pmichaud oh, please not that
17:17 jonathan hah
17:17 pmichaud I'm trying to avoid special-purpose global flags
17:17 jonathan Sur
17:18 jonathan *sure
17:18 pmichaud for one, it causes difficulty for re-entrant
17:18 jonathan Right. But we don't want to generate many of them if there are multiple MAINs.
17:18 pmichaud we could just attach a :main to every compilation unit, that checks for a MAIN and call it
17:18 pmichaud thus one per unit
17:19 jonathan That's what I was going to do, before you mentioned to only generate it if we have a MAIN. ;-)
17:19 pmichaud do it that way then.
17:19 pmichaud we can optimize later.
17:19 jonathan I think at some point we'll need to ponder @?BLOCKS and that bunch with regard to re-entrancy too.
17:20 pmichaud I've been keeping track of it and so far we're relatively okay
17:20 jonathan Can they not somehow be attributes on some instance of the Actions?
17:20 jonathan s/@?BLOCK/@!BLOCK/
17:21 pmichaud either that or instances on the compiler object
17:21 pmichaud or parser object
17:21 purl hmmm... parser object is $p ?
17:21 pmichaud s/instances/attributes
17:21 jonathan Yes
17:22 pmichaud i.e., they'd still remain @?BLOCK, but the '?' would redirect to a compiler instance instead of a package variable
17:22 Coke purl, forget parser object
17:22 purl Coke: I forgot parser object
17:28 japhb Who is running #ps today?
17:29 apeiron joined #parrot
17:32 * Coke is, apparently.
17:32 pmichaud parrotsketch in 60
17:32 pmichaud (58, actually)
17:32 pmichaud afk, errands
17:35 * PerlJam hands Coke a gavel for later.
17:50 chromatic joined #parrot
17:52 johbar joined #parrot
18:13 notbenh joined #parrot
18:17 allison joined #parrot
18:19 masak joined #parrot
18:24 Theory joined #parrot
18:26 dalek r32549 | jonathan++ | trunk:
18:26 dalek : [PCT] Add isnull to list of op sigs.
18:26 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32549
18:27 cognominal_ http://blogs.sun.com/bmc/en​try/concurrency_s_shysters  # a critic of STM
18:28 pmichaud #ps in 2
18:32 bacek joined #parrot
18:33 ambs joined #parrot
18:33 ambs left #parrot
18:34 Coke chromatic++
18:34 chromatic For being a leader?
18:34 Coke ayup
18:34 Coke Andy: you in?
18:35 cout joined #parrot
18:44 jonathan pmichaud: I've discovered that in pre-compiled scripts, we don't run the main body at all.
18:45 pmichaud jonathan: of course we do.
18:46 jonathan pmichaud: For modules yes
18:46 jonathan If you "use" them
18:46 jonathan Unless I br0ked it... :-
18:46 jonathan S
18:47 pmichaud $ cat foo.pl
18:47 pmichaud say 'hello';
18:47 pmichaud $ ./parrot perl6.pbc --target=pir foo.pl >foo.pir
18:47 pmichaud $ ./parrot foo.pir
18:47 pmichaud hello
18:47 purl bonjour, pmichaud.
18:47 pmichaud $
18:47 jonathan Hmm.
18:47 japhb pmichaud: question for you in #ps
18:47 * jonathan wonders how he's busted it.
18:47 pmichaud it *does* require that the "main" code be the first sub in the output.
18:50 jonathan pmichaud: Oh! But that doesn't actually get run any more, if we are generating a :main.
18:50 pmichaud aha.
18:50 pmichaud that would be an issue, yes.  :-)
18:50 pmichaud so, if we generate a :main, it needs to run the first sub and then call MAIN if it exists.
18:51 pmichaud that could probably be an outer block.
18:51 jonathan Yes.
18:51 rurban joined #parrot
18:52 bacek joined #parrot
18:52 pmichaud japhb: can you nopaste the code that's generating an error for you
18:52 japhb sure.  Snippets of a larger pie.
18:52 japhb nopaste?
18:52 clunker3 http://pasta.test-smoke.org/ or http://paste.husk.org/ or http://nopaste.snit.ch:8001/ or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/
18:52 purl i guess nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/
18:54 nopaste "japhb" at 76.191.190.8 pasted "+= crashing in Rakudo" (20 lines) at http://nopaste.snit.ch/14535
18:55 japhb That paste is directly from examples/opengl/shapes.p6, btw.
18:56 moritz rakudo: my $x = 0.0; $x += 2; say $x
18:56 polyglotbot OUTPUT[Multiple Dispatch: No suitable candidate found for 'i_add', with signature 'PP'␤current instr.: 'infix:+=' pc 12507 (src/gen_builtins.pir:7739)␤called from Sub '_block11' pc 51 (EVAL_12:22)␤called from Sub 'parrot;PCT;HLLCompiler;eval' pc 866 (src/PCT/HLLCompiler.pir:501)␤called from Sub
18:56 polyglotbot ..'parrot;PCT;HLLCompiler;evalfiles' pc 1141 (src/PCT...
18:56 pmichaud okay, I see the issue.
18:56 moritz ah, that's probably because Num != Int
18:56 pmichaud Fixing.
18:56 moritz writing test...
18:56 pmichaud oh, I don't see the issue.
18:57 pmichaud that looks like a mmd bug.
18:57 japhb That's why I brought it up in #ps.  ;-)
19:05 cotto I need to remember that that's at 10:30 for me now.
19:06 cotto irclog
19:06 cotto irclog?
19:06 purl irclog is http://irclog.perlgeek.de/parrot/today
19:07 dalek r32550 | coke++ | trunk:
19:07 dalek : Delete a resolved issue and a rejected issue.
19:07 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32550
19:08 jhorwitz pmichaud: it appears that "for %hash<nestedarray>" loops over a list containing the nested array, not the actual flattened nested array.  known issue?  couldn't find anything in RT.
19:09 * Coke cries in his coffee about missing the conference. :P
19:09 * Coke should have asked his MIL to sit the kids.
19:09 jhorwitz mmmm...sad flavored coffee.
19:09 rurban coke: which conference
19:09 TimToady where is the conference?
19:09 purl well, the conference is at http://conference.perl.com
19:09 pmichaud jhorwitz:    for %hash<nestedarray>.list
19:09 Coke parrot dev
19:09 jhorwitz pmichaud: prepare for karma
19:10 rurban because I was with jonathan at yapc twincity
19:10 pmichaud oops
19:10 pmichaud for %hash<nestedarray>.values
19:10 pmichaud (although .list might also work)
19:10 chromatic TimToady, http://code.google.com/events/visitors
19:10 chromatic But you can't attend unless you answer my interview questions.
19:11 jhorwitz pmichaud++ # .values works
19:11 jhorwitz fyi, .list does not
19:11 pmichaud okay, might need to look at that one.
19:12 TimToady chromatic: but I already did, I thought...
19:12 * jonathan looks at a bunch of failed spectests and wonders if his MAIN changes really did this...
19:13 chromatic TimToady, I sent the final batch on Friday.
19:13 TimToady ah, I've been in email bankrupcy lately... :/
19:13 TimToady I see 'em
19:14 chromatic jonathan, do you have a Rakudo MMD example which triggers the 'Ambiguous dispatch' exception?
19:14 jonathan chromatic: As in, something using Perl 6 multisub?
19:14 chromatic Yes.
19:15 jonathan Just declare two subset types that do the same thing and write a multi that does each one.
19:15 pmichaud jhorwitz: also, for clarity, I'm pretty sure that    for %hash<nestedarray> { ... }    should loop over a list containing the nested array, and that .values, .list, or @(...)   are needed to loop over the values
19:15 jonathan And then call it.
19:15 jonathan I found a buggy test that did exactly that earlier today. ;-)
19:15 jonathan subset Even of Int where { $^n % 2 == 0 }
19:15 jonathan subset Even of Int where { $^n % 2 == 0 }
19:16 jonathan erm
19:16 jhorwitz pmichaud: ok.  never saw it in any of the 80 tutorials i looked at, so wasn't sure.  :)
19:16 jonathan in full
19:16 jonathan subset Even of Int where { $^n % 2 == 0 }
19:16 jonathan subset Odd of Int where { $^n % 2 == 0 }
19:16 jonathan multi test(Even $x) { 1 }
19:16 jonathan multi test(Odd $x) { 2 }
19:16 jonathan test(4)
19:16 jonathan Of course, Odd is wrong, but that's why you get an ambiguous dispatch.
19:17 Coke ... that's an ambiguous duo of subsets.
19:17 pmichaud jhorwitz: it's somewhat analogous to     for [1,2,3] { ... }       only gets iterated once
19:17 chromatic Seems to work.
19:17 chromatic $ parrot perl6.pbc multi_exception.p6
19:18 chromatic Ambiguous dispatch for multi test.
19:18 jhorwitz pmichaud: yeah, it makes sense.  didn't know how to make it DWIM though.  :)
19:18 chromatic I'll throw quotes around the sub name and call that good.
19:18 jonathan chromatic: You put the name in? Nice! :-)
19:18 jonathan chromatic++ # one thing of my hit list
19:18 chromatic I'm getting good at PMCs.
19:18 jonathan chromatic: I was pondering a method on multis where you could get at the computed dispatch order too, for debugging purposes
19:19 Coke chromatic: hey, do you know what we're replacing 'get_mro' with?
19:19 Coke (if nothing, let's just rip it out.)
19:20 chromatic Coke, offhand I don't.
19:23 dalek r32551 | chromatic++ | trunk:
19:23 dalek : [Rakudo] Tidied some code in Perl6MultiSub PMC.  No functional changes.
19:23 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32551
19:23 jonathan chromatic: Thanks! :-)
19:26 chromatic You're welcome.
19:27 dalek r32552 | chromatic++ | trunk:
19:27 dalek : [Rakudo] Added sub name to multidispatch failure message in Perl6MultiSub PMC.
19:27 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32552
19:28 dalek r32553 | chromatic++ | trunk:
19:28 dalek : [PMC] Revised a comment an an exception message to use new .const 'Sub' syntax.
19:28 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32553
19:30 jonathan chromatic: I was thinking of implemeting .perl on the Signature object, and then when we have an ambiguous dispatch including the signatures that collided too.
19:30 jonathan Would make for quite a lot of output, potentially, but I think it'd be useful.
19:31 jonathan This is huge improvement in the meantime though.
19:31 chromatic Yeah, it's hard to find the right balance between too much and just enough output, but this was an easy change.
19:32 TimToady I've suggested before putting the extra stuff into a .html file and put a link to it in the message
19:33 jonathan TimToady: While you're about - if you have a bunch of multis, say with short name foo, how do you get a list of all the candidates to iterate over them?
19:33 jonathan &foo.candidates?
19:33 * jonathan didn't see it spec'd but may have missed something
19:34 jonathan On a similar note, what would &foo.signature do on a multi?
19:35 jonathan pmichaud: about?
19:35 pmichaud here
19:35 TimToady certainly the intent is that &foo represent the set of candidates, .candidates seems fine for now
19:36 TimToady and .signature should be the signature of the actual or inferred proto
19:36 jonathan pmichaud: Did all spectests pass after you did the change to Num::ACCEPTS?
19:36 pmichaud yes.
19:36 jonathan TimToady: OK, thanks.
19:36 pmichaud well, I say that...
19:36 pmichaud just a sec.
19:36 jonathan Hmm. I get a fail in t\spec\S06-multi\type-based.t
19:36 TimToady (I believe pugs already infers a proto where none is declared)
19:36 pmichaud jonathan: they were all passing as expected through test_summary.pl .  I don't know that I tried "make spectest"
19:37 pmichaud I'll try again quickly here
19:37 jonathan pmichaud: It fials for me just run at command line.
19:38 jonathan It's my remaining failure before putting in the MAIN changes. But I can't really think how they'd have made this particular test fail...
19:38 jonathan And it comes back with "Circularity detected in multi sub types."
19:38 pmichaud yes, that's what I get also.
19:38 jonathan Ouch.
19:39 pmichaud ...checking.
19:39 pmichaud and yes, removing the Num check causes that set of failures to disappear.
19:39 jonathan Hmm.
19:39 jonathan I *think* it worked before your change.
19:41 * jonathan glances over the patch
19:41 pmichaud it has trouble with the Int check
19:41 pmichaud if I comment out the Int check (but leave .ACCEPTS there), then it passes.
19:42 pmichaud I wonder if it's a .tailcall issue
19:42 jonathan oh
19:42 jonathan .tailcall $P0.'ACCEPTS'(topic)
19:42 jonathan Yeah, don't do that. :-)
19:42 jonathan I think tailcalls + invocation from C = bad
19:42 pmichaud I didn't realize it was being invoked from C
19:42 jonathan Yes.
19:42 jonathan From Perl6MultiSub PMC.
19:42 pmichaud yes, that fixes it.
19:42 pmichaud I'll commit
19:42 jonathan Awesome, thanks.
19:43 jonathan And that means MAIN patch can go in too.
19:43 pmichaud I may refactor parameter handling a bit later today.  I want to get   <->  lambda to work
19:43 pmichaud and that's going to require a refactor.
19:44 PerlJam random thought--If tailcalls + invocation from C == bad, then there should be other such (reproducable) failures wrt MMD shouldn't there?
19:44 jonathan Sounds good.
19:46 jonathan What are the main things you're thinking of changing?
19:46 dalek r32554 | jonathan++ | trunk:
19:46 dalek : [rakudo] Some very basic support for MAIN entry point sub. Just passes all command line arguments as positionals.
19:46 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32554
19:46 dalek r32555 | pmichaud++ | trunk:
19:46 dalek : [rakudo]:  Don't do tailcalls for methods called from C. (jonathan++)
19:46 pmichaud well, in some ways the whole structure changes
19:46 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32555
19:46 pmichaud I still feel like we build signatures and apply traits in the wrong place
19:46 jonathan You want to push more stuff down into param_var or parameter?
19:47 pmichaud yes, or store the relevant information somewhere other than the parse tree
19:47 jonathan Applying traits - I'm thinking a lot on that, after discussion with TimToady yesterday.
19:47 pmichaud it's likely going to be held in the symbol table
19:47 pmichaud (in the block's symbol table)
19:47 jonathan Aha.
19:47 jonathan I'd not thought of doing it that way, but it makes sense.
19:48 pmichaud then we can generate everything at the end of the block
19:48 jonathan *nod*
19:48 pmichaud it might even allow us to get rid of the open/close semantics in statement_block
19:48 pmichaud or, at least, some of them.
19:48 particle that'd be nice
19:48 jonathan Could be interesting.
19:49 pmichaud but I'll also be looking at getting array, hash, and slurpy params to work properly
19:49 jonathan That would certainly be a good thing.
19:50 pmichaud afk for a short while
19:51 stockwellb joined #parrot
19:52 Wknight8111 joined #parrot
19:52 stockwellb With an eye toward the PIR noob, what things should one be doing with PIR?
19:53 Coke as opposed to PASM? everything.
19:53 stockwellb You wouldn't build a business application in PIR would you?
19:54 Coke ah. that high level of a question? implement a high level language in.
19:54 particle chromatic might
19:55 Coke ->
19:55 jonathan particle: When do you start on the grant? :-)
19:55 Coke left #parrot
19:55 particle jonathan: i've already started S19
19:55 jonathan Ah, cool! :-)
19:56 stockwellb I'm not trying to be too obtuse, just trying to learn PIR. To learn it, I need to write it. What should I, a noob, be writing.
19:56 jonathan As you've probably noticed, you've got a first cut of MAIN.
19:56 jonathan I'll leave the rest to you. But I'll make sure there's enough introspection on multis done too, so you can implement the auto-generated USAGE and so forth.
19:56 apeiron joined #parrot
19:56 particle stockwellb: what do you want to do with parrot? you may not need to learn pir in order to do it
19:57 jonathan Did the MAIN since someone was after it.
19:57 jonathan japhb: You can haz MAIN. ;-)
19:57 particle thanks, jonathan, i'm looking at that commit now
19:57 jonathan karma jonathan
19:57 purl jonathan has karma of 896
19:57 tewk stockwellb: go look at examples
19:57 jonathan ...haven't I had that for a long time?
19:58 stockwellb Particle, that's the crux! I like PIR I want to learn more. I'm just wonder what are some sensable things to do with PIR. Things a newcommer could get into.
19:58 PerlJam stockwellb: anything!  :)
19:58 stockwellb Note: I ran through the squawk tutorial and it melted my brain.
19:59 stockwellb PerlJam, so PIR is the golden hammer?
19:59 particle stockwellb: ok. that's good context. you can write a high-performing module in pir designed to be shared between parrot hlls
19:59 chromatic It'd be nice to have a PIR version of File::Temp
20:00 particle stockwellb: you can wrap a shared library (like pcre)
20:00 masak stockwellb: you can find something missing in Rakudo and implement it in PIR.
20:00 stockwellb Noob noob noob! I'm a very new at this. You guys are so freakin advanced in your skill!
20:01 PerlJam stockwellb: well, what do *you* hope to use parrot for?
20:02 stockwellb PerlJam, I'd like to have in my head a sensable path of goals that could take me from twiddler to apprentice.
20:02 PerlJam stockwellb: sounds like a good project then  :)
20:03 PerlJam stockwellb: i.e., you should develop such a thing because I don't think anyone is thinking of parrot in terms of teaching
20:04 particle stockwellb: work your way through examples/tutorial/
20:04 stockwellb I realize that, your all so very versed that it is natural for you.
20:04 jonathan stockwellb: We were all Parrot beginners once too. :-)
20:05 tewk stockwellb: write hello world, then write hello world with a for loop, then write hello world with a sub.
20:05 jhorwitz then embed it in apache
20:05 stockwellb I've worked through the examples and have been playing with composition and roles. Quit cool. I'm at the stage where I'm looking to try something small and non trivial.
20:05 tewk Wow didn't know about  examples/tutorial/, it looks very good.
20:05 * jonathan -> dinner, bbiab
20:06 PerlJam tewk: It's under-documented.
20:06 particle an implementation of perl5's File::Temp module is non-trivial and smallish
20:09 stockwellb Particle, as a newcomer I have no clue how to measure my understanding of PIR. Maybe that's what I find frustrating. I might be kinda good at it or maybe I should start over because I've missed the boat. To make things worse I have no Perl experience. I don't even know what File::Temp is. I will look it up of course, but I'm certainly at a disadvantage.
20:10 PerlJam stockwellb: well, what do you have experience with?
20:10 masak stockwellb: you know how to find File::Temp? otherwise, here: http://search.cpan.org/~tjen​ness/File-Temp-0.20/Temp.pm
20:10 stockwellb I'm looking at File::Temp right now. I should have guessed at what it was for :)
20:10 particle stockwellb: in testing parrot via pir (many t/ files are written in pir) we have occasion to generate temporary files. it would be nice to have a library written in pir to ease the generation of temp files and temp directories.
20:11 PerlJam stockwellb: I'm sure parrot could use more tests if you just want to write PIR
20:11 particle parrot definitely needs more tests
20:11 particle our opcodes are way undertested
20:11 stockwellb @PerlJam, I kinda thought tests would be a good place for me to earn my stripes.
20:11 stockwellb I just don't know where to start?
20:14 particle stockwellb: take a look at the files in t/op/. pick a file, and look at what it's testing. check the spec for the opcodes it's testing, and see if there's good coverage--you need to use judgement here, we don't have coverage testing software available.
20:15 particle for example, is the documentation for 'isnull' clear and unambiguous wrt edge cases and wording? do the tests cover possible outcomes and edge case?
20:16 particle how about the io ops? sprintf? etc.
20:16 particle pick some ops you're familiar with first
20:16 stockwellb particle, I've always worked alone. I use svn a little, git a little more. Most things I do are C# with a little python and ruby. I've no experience collaborating. One I write/edit something I'll really have to query you folks again for what to do next.
20:17 particle that's fine, stockwellb, we're around :)
20:18 stockwellb Alright I'm going to dig around in t/op/. Thanks again for the patience.
20:28 bacek_ joined #parrot
20:31 DietCoke joined #parrot
20:31 Coke I was about to apologize for r32555, but I realized it was still doing a tailcall before I touched it. =-)
20:33 chromatic You should still apologize.
20:37 stockwellb I'm feeling like a boat anchor today. I looked it t/op/. I looked at 01-parse-ops_1.t it's perl. I see 326 pasm files that have chunks of pasm. I'm not understanding the testing. Is there some reading I should be doing?
20:38 chromatic Ignore that one for now.
20:38 chromatic Just keep in mind that the .t files that are Perl 5 code write PIR/PASM to the file system, run it from Parrot, and compare the results.
20:39 Coke (that's a particularly evil test file.)
20:39 Coke "some of the .t files are perl5 code". others are PIR themselves.
20:40 stockwellb I'm trying...to wrap my brain around this. It's hard without the big picture.
20:40 bacek_ good morning
20:41 masak stockwellb: the big picture tends to come in small pieces, unfortunately.
20:41 stockwellb I'm definitely seeing the small that, masak.
20:42 masak good.
20:42 masak keep at it.
20:43 stockwellb I just feel a little pesky. Almost like I'm bothering folks when I should be able to get it myself.
20:44 masak stockwellb: not at all. I'm sure people here are glad to help.
20:44 chromatic If it's difficult for a novice to understand what's happening, we need to make things easier or document them better somehow.
20:45 chromatic One thing you could do is write some notes on how the test suite works -- or at least the questions you ask and the answers you get.
20:46 stockwellb Maybe I could start with the questions :)
20:47 masak stockwellb: I'm especially eager to help you, actually, because I've only recently learned the basics of PIR, and I could use the more solid ground that comes from explaining things. :)
20:51 stockwellb masak, do you contribute code?
20:51 masak stockwellb: sometimes.
20:51 purl sometimes I think you're off your rocker.
20:51 Coke I think it's very hard for those of us that have been here for a while to look at it fresh. could definitely use help lower the barrier to entry.
20:53 particle wiki page seems like a good place for collaboration
20:53 particle wiki?
20:53 purl rumour has it wiki is http://dev.catalyst.perl.org/new-wiki/ or http://rakudo.org/parrot
20:53 particle bah.
20:53 particle parrot wiki?
20:53 purl hmmm... parrot wiki is at http://rakudo.org/parrot
20:53 stockwellb mask, that's what I want to do is to contribute. I use all this open source stuff and I've never given back my time.
20:53 * jonathan is back
20:54 particle no, parrot wiki is http://www.perlfoundation.org/parrot
20:54 purl okay, particle.
20:54 masak stockwellb: do you know about Rakudo?
20:55 stockwellb I know it's an implimentation of Perl6.
20:55 masak stockwellb: it's a fascinating project, and a fun thing to write PIR for.
20:55 stockwellb @particle are you suggestiong that I start a noob page there?
20:56 particle ayep
20:56 masak stockwellb: please avoid the derogatory term 'noob', especially about yourself. :)
20:56 stockwellb Will do just that.
20:56 particle stockwellb++
20:57 stockwellb Considering I started at level 0, I'll celebrate being bumped up one!!
20:57 masak :)
20:57 masak that makes you a n11b.
20:57 particle i think i lost an electron
20:57 masak particle: you're sure?
20:58 particle i'm positive!
20:58 stockwellb :) n11b, I like that.
20:58 masak particle: :D
20:59 stockwellb Alright folks, time to go out and have V-day dinner. Thanks again to all.
20:59 masak stockwellb++ # good luck!
20:59 jonathan masak: Any particular Rakudo ticket you want me to glance over tonight?
20:59 masak jonathan: hm. let me check.
21:00 masak I suppose #58392 is out. :) as is that last one with .split and .trans, yes?
21:00 masak both those are pretty serious.
21:00 Coke ... no, the parrot wiki is at http://www.parrot.org/wiki/parrot
21:01 Coke the perlfoundation one is, I thought, being de-commissioned as we move content to the parrot.org one.
21:01 jonathan masak: 58392 depends on the lexicals work
21:01 masak jonathan: aye.
21:02 jonathan Which pm has much of in a branch, I believe.
21:02 masak jonathan: what about #59484, is that doable?
21:02 masak jonathan: he does. lex.
21:02 jonathan And the most recent one depends on HLL stuff.
21:03 dalek will@coleda.com | Parrot:
21:03 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?parrot
21:03 masak jonathan: =<> would be cool too, though not nexessarily from a November standpoint. I don't know what ticket # it has.
21:03 particle stdfish++
21:03 dalek will@coleda.com | Parrot:
21:03 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?parrot
21:03 japhb jonathan: thanks for MAIN!  I'll rebase and test.
21:03 jonathan 59484 is maybe do-able.
21:04 masak jonathan: ah, #58524.
21:04 particle probably wait on =<> until after io branch merge
21:04 masak ack.
21:05 pmichaud although it seems like $*IN ought to be doable.
21:05 dalek will@coleda.com | Parrot:
21:05 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?parrot
21:06 pmichaud oh, er, wait, um.
21:06 masak jonathan: oh, oh, #57400!
21:06 pmichaud I'm thinking of $*ARGS
21:06 jonathan pmichaud: Doesn't =<> read from @*ARGS?
21:06 masak it does.
21:06 purl if you say so...
21:06 pmichaud no.
21:06 pmichaud well, yes, but not directly.
21:07 pmichaud =<> is short for =$*ARGS
21:07 masak jonathan: and #57330, it's odd that this one is still alive.
21:07 Coke particle: can we delete http://www.perlfoundation.org/parr​ot/index.cgi?release_manager_guide now?
21:07 pmichaud and $*ARGS does successive reads of files in @*ARGS (or $*IN if @*ARGS is empty)
21:07 Coke (since it's in version control?)
21:07 jonathan 57400 I said was got to review after the container changes...which have happened...so...
21:07 particle coke: aye
21:08 pmichaud I wonder if the Env PMC needs to be mapped to Hash
21:09 pmichaud that would at least get some of the methods.
21:09 jonathan pmichaud: Maybe.
21:09 pmichaud there's still going to be the issue that the strings returned from Env aren't Str
21:09 jonathan Yeah.
21:09 jonathan Plus I'm not sure about assigning to it and stuff.
21:09 pmichaud yes, that's an issue as well.
21:09 chromatic It should be assignable.
21:10 chromatic I don't know that it is.
21:10 pmichaud it's not
21:10 masak what's wrong with assigning to %*ENV?
21:10 jonathan chromatic: I think at a Parrot level it maybe is.
21:10 pmichaud no, it's not assignable even at a Parrot level
21:10 pmichaud it's _bindable_ but not assignable
21:10 pmichaud i.e., one can do   set_string_keyed
21:10 jonathan Hmm.
21:11 jonathan > for %*ENV -> $k, $v { say "$k = $v" }
21:11 jonathan StopIteration
21:11 masak ah, yes, that was a fun one.
21:11 pmichaud for %*ENV.kv   perhaps?
21:11 jonathan Oh, yes
21:11 jonathan > for %*ENV.kv -> $k, $v { say "$k = $v" }
21:11 jonathan No applicable methods.
21:11 pmichaud I think .kv isn't mapped.
21:11 jonathan yes
21:11 pmichaud and the Env PMC isn't really a Hash.
21:12 jonathan Indeed, it's not.
21:12 jonathan pmclass Env singleton provides hash {
21:13 chromatic I don't know if we provide setenv in the platform-dependent code for Parrot to use within Env.
21:13 pmichaud if (keyname && env_val)
21:13 pmichaud Parrot_setenv(keyname, env_val);
21:14 pmichaud (looks like yes.)
21:14 japhb grrr, I hate it when I 'make realclean; perl Configure.pl; make; make perl6', get all the way to the end, and realize I forgot step 2: 'git svn rebase'.  (wasting time)--
21:15 chromatic I couldn't remember if I had read that or was only seeing the code I had to write in my head.
21:15 jonathan :-)
21:15 pmichaud the real issue with %*ENV (and the Env PMC) is described in RT #58632
21:15 particle japhb: that's what shell scripts are for!
21:16 japhb particle: There you go, using your brain again.
21:16 pmichaud I'll add my comments about 57400
21:16 jonathan pmichaud: 58632?
21:16 jonathan That looks like a Perl 5 ticket...
21:17 pmichaud sorry, 58362
21:17 chromatic That should be easily fixable.
21:18 pmichaud is it?
21:18 purl it's it!
21:18 pmichaud here's the hard one:
21:18 pmichaud env = new 'Env'
21:18 pmichaud $P1 = env['foo']
21:18 pmichaud assign $P1, 'bar'
21:18 pmichaud (this last statement should cause env['foo'] to change)
21:19 ruoso joined #parrot
21:19 pmichaud currently   get_pmc_keyed always creates a new String PMC for the lookup, but that String PMC is not in any way tied back to the Env hash
21:19 pmichaud so modifying that PMC doesn't modify the environment
21:20 chromatic I'm not sure that should.
21:21 pmichaud the issue is that nearly all of Rakudo (and PCT) assumes that assignment is performed on a PMC
21:21 Coke make your copied a tied copy that twiddles the original parrot version on set.
21:21 ab5tract joined #parrot
21:21 pmichaud "on assign"
21:21 Coke (and when you figure out how that works, let me know so i can write [trace] for tcl.)
21:22 dalek r32556 | particle++ | trunk:
21:22 dalek : [t] skip test for platform-dependent inf behavior
21:22 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32556
21:22 dalek r32557 | particle++ | trunk:
21:22 dalek : [docs] trailing space cleanup
21:22 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32557
21:22 chromatic You can argue that it should, but that's kind of like that modifying a string returned from a SQL query should modify the row in place.
21:22 Coke huh?
21:23 pmichaud since there's no    assign $P0[key], value     opcode, we're pretty much stuck
21:23 Coke I would expect modifying the hll's env to impact the env of any spawned processes.
21:23 Coke or are we talking about two different things here?
21:23 pmichaud (and even if we did have one, we'd be stuck in other ways)
21:24 jonathan I think we're going to have to somehow tie it.
21:24 chromatic Coke, I think pm's talking about modifying the PMC from a get_pmc_keyed on the Env.
21:24 pmichaud chromatic:  let's take the case of a normal Hash
21:24 pmichaud if I do
21:24 pmichaud $P1 = hash[key]
21:24 pmichaud assign $P1, value
21:24 pmichaud then I expect that to impact the value in the hash
21:25 pmichaud is that correct, or no?
21:25 chromatic I don't think you can make that assumption in general.
21:25 pmichaud okay, I'll take another tack
21:25 pmichaud new $P0, 'Integer'
21:25 pmichaud set $P1, $P0
21:25 pmichaud assign $P0, 3
21:25 pmichaud say $P1
21:26 pmichaud ...outputs 3, yes?
21:26 chromatic Yes.
21:26 pmichaud new $P0, 'Hash'
21:26 pmichaud new $P1, 'Integer'
21:26 bacek_ #57330 can be closed. At least it WFM.
21:26 pmichaud set $P0['key'], $P1
21:26 pmichaud assign $P1, 3
21:26 pmichaud set $P2, $P0['key']
21:26 pmichaud say $P2
21:27 bacek_ and #57396 too
21:27 pmichaud ...?
21:27 purl Yada yada yada hasn't been implemented yet! (unless you run bleadperl)
21:27 chromatic 3
21:28 bacek_ and #57398...
21:28 chromatic new $P0, 'Hash'
21:28 bacek_ masak: around?
21:28 chromatic set $P0['key'], 'value'
21:28 masak bacek_: aye.
21:28 chromatic $S0 = $P0['key']
21:28 chromatic inc $S0
21:28 bacek_ this is all your tickets :)
21:28 masak bacek_: just tested #57330. DNWFM.
21:28 chromatic $S1 = $P0['key']
21:28 chromatic say $S1
21:28 pmichaud ...outputs #value, but a String is not a PMC
21:29 chromatic Nor is a C string from getenv a PMC.
21:29 pmichaud here's what I'm saying
21:29 bacek_ masak: strange...
21:29 purl strange is but true
21:29 pmichaud from a code generation perspective, the only way I have to assign values to an aggregate is via a PMC
21:30 masak bacek_: I often get segfaults where others don't. I'm on Mac OS X.
21:30 pmichaud it has to be this way because of the Perl 6 possibility of
21:30 Coke masak; what processor/version?
21:30 masak Coke: checking.
21:30 pmichaud my $x := $*ENV<foo>
21:30 pmichaud (oops)
21:30 pmichaud my $x := %*ENV<foo>;
21:30 pmichaud %*ENV<foo> = 'bar';
21:31 rdice joined #parrot
21:31 pmichaud in other words, %*ENV<foo> has to return me something (a PMC) that can have its value changed by something else
21:31 Coke cheeze it, it's the prez.
21:31 chromatic Hide the beer.  The Canuck's here.
21:31 masak Coke: Intel 2 Core Duo/10.5.4 (9E17)
21:32 Coke masak; i'm on intel at 10.4 and don't see many segfaults.
21:32 Coke 10.4.mumble
21:32 japhb .oO( Where did the phrase "Cheeze it!" come from, and why? )
21:32 Coke 11.
21:32 chromatic pmichaud, to make that work in Parrot, I don't see any other possibility than writing a custom PMC that does its own setenv/getenv on every assign and fetch.
21:32 bacek_ bacek@haste:~/src/parrot/languages/perl6$ ../../parrot perl6.pbc -e 'sub a { b() }; sub b { exit }; a()'
21:32 bacek_ bacek@haste:~/src/parrot/languages/perl6$ ./perl6 -e 'sub a { b() }; sub b { exit }; a()' 2>&1
21:32 bacek_ *** glibc detected *** ./perl6: double free or corruption (!prev): 0x09073e40 ***
21:32 masak Coke: I still get them a lot in connection with some kinds of runtime error.
21:32 masak Coke: double frees.
21:32 pmichaud chromatic: I agree with you.
21:32 bacek_ looks like a bug in pbc2exe (or how it's called)
21:33 * Coke hurls http://www.worldwidewords.org/qa/qa-che4.htm for japhb
21:33 chromatic I've explained that double free before.
21:33 chromatic It's not a bug.
21:33 chromatic At least, it's not a bug in pbc2exe.
21:33 pmichaud so, instead of having an Env PMC that tries to act like a Hash, we should have bunch of EnvPair PMCs that are tied to the environment
21:33 chromatic Use the --leak-test flag to parrot and you'll see the same thing.
21:34 chromatic Yes, that would work.
21:34 pmichaud and perhaps the Env PMC is an easy way to get EnvPair s
21:34 masak chromatic: I know you've talked about it before, and I'm listening, but don't always grok.
21:34 chromatic pbc2exe sets the "Free all allocated memory!" flag in the Parrot interpreter, while that flag is off by default in the parrot executable.
21:34 masak right.
21:34 japhb Thanks, Coke.
21:34 chromatic I enabled that flag by default to expose those errors.
21:34 masak but something's wrong somewhere.
21:35 Coke how would you expect tying to work in general, c? If I have a particular FooHash i wish to do that to, how do I override vtable entries for that particular instance?
21:35 Coke I can do it for -the pmc-, but then that affects all instances.
21:35 jonathan pmichaud: We need a way to implement Proxy style things in Perl 6 anyway that trap assignments/accesses - so we can possibly use that mechanism rather than having to write a PMC.
21:35 chromatic Coke, tying (in the Perl 5 sense) works on vtable calls.
21:35 Coke jonathan: other HLL's need that; if you can make it parrot-generic, that would be most helpful.
21:36 pmichaud ...except that the only vtable calls we have do 'bind', not assign.
21:36 Coke chromatic: ... do you have an example?
21:36 chromatic purl msg masak the problem is in the reference count of context structures somewhere related to continuations and exception handlers.
21:36 purl Message for masak stored.
21:36 pmichaud we could have a generic ProxyKey PMC
21:36 chromatic Coke, beyond perldoc perltie?
21:36 Coke ... in parrot
21:37 Coke I can do tying in perl.
21:37 chromatic $P0 = subclass 'Hash', 'MyAwesomeHash'
21:37 chromatic .sub set_pmc_keyed :vtable
21:37 chromatic ....
21:37 chromatic Is that what you're asking?
21:38 Coke so for every variable I wish to tie, I should create a (presumably anonymous) subclass ?
21:38 Coke and then just wholesale replace that class's vtable?
21:38 chromatic I don't think I understand the question.
21:39 chromatic You only have to override the vtable entries for which you want different behavior.
21:39 Coke if I have (in perl5), %a, I wish to tie -%a-, not -every hash-
21:39 chromatic You only have to create a new subclass for each collection of different behavior you want.
21:39 chromatic In Perl 5, when you tie %a, you name the class into which you want to tie it.
21:40 Coke so, yes, I'll need a new class every time I wish to do this.
21:40 rdice joined #parrot
21:40 chromatic Only insofar as you do in Perl 5, yes.
21:40 Coke I suspect this means I'll just create a shadow, tie-able class for each tcl PMC.
21:41 pmichaud jonathan: I think that trapping assignment may just be an infix:= mmd
21:41 pmichaud I already know that we'll have to have our own   postcircumfix:<[ ]>  and postcircumfix:<{ }>
21:41 Coke ok. I am now at least vaguely hopeful that it is doable.
21:41 jonathan pmichaud: Yes, we will.
21:41 purl o/` We will, we will ROCK YOU! o/`
21:42 jonathan rock++
21:42 Coke yes we can?
21:42 chromatic I still don't think we understand each other, but I need food more than anything else.  Or maybe a giant fighting robot.
21:42 Coke yes we can is change.gov
21:42 jonathan Coke: Yes. It'll be a change we can believe it.
21:42 dalek r32558 | allison++ | pdd22io:
21:42 dalek : [pdd22io] Clarifying buffer flushing behavior.
21:42 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32558
21:42 pmichaud yes we can is also a change we can believe in
21:42 Coke chromatic: I think I understand you.
21:43 Coke I think our problem is, as always, that tcl ain't perl.
21:44 chromatic Yeah, my knowledge of Tcl is superficial.  I don't know its tying semantics at all.
21:44 Coke we have something in common; my knowledge of tcl is ALSO superficial.
21:44 Coke I think we'll get along just fine.
21:44 chromatic I know more about its C API than its behavior.
21:44 chromatic But again, NOM NOM.
21:45 Coke ~~
21:45 Coke -> to NOM himself
21:45 Coke ... pervs.
21:45 Coke left #parrot
21:46 dalek r32559 | allison++ | pdd22io:
21:46 dalek : [pdd22io] Add accessors for FileHandle buffer attributes.
21:46 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32559
21:51 dalek r32560 | allison++ | pdd22io:
21:51 dalek : [pdd22io] Fix double free error, 'buffer_start', 'buffer_next', and
21:51 dalek : 'buffer_end' are all pointers to the same chunk of allocated memory. (Note, the
21:51 dalek : buffer will probably have to change to an actual STRING to support the Strings
21:51 dalek : PDD. But, for now, we just want a smooth transition from the old I/O
21:51 dalek : architecture to the new I/O architecture.)
21:51 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32560
21:53 dalek r32561 | allison++ | pdd22io:
21:53 dalek : [pdd22io] Remove unused 'mode' variable.
21:53 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32561
21:59 dalek r32562 | allison++ | pdd22io:
21:59 dalek : [pdd22io] Fix compilation warnings in ported I/O buffering code and clean out
21:59 dalek : old architecture cruft.
21:59 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32562
22:03 dalek r32563 | allison++ | pdd22io:
22:03 dalek : [pdd22io] Turn on compilation of I/O buffering code.
22:03 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32563
22:04 Ademan_ joined #parrot
22:05 dalek r32564 | allison++ | pdd22io:
22:05 dalek : [pdd22io] Use buffering in core I/O API.
22:05 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32564
22:05 dalek r32565 | particle++ | trunk:
22:05 dalek : [t] fix broken skip marker
22:06 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32565
22:09 Limbic_Region joined #parrot
22:16 ruoso joined #parrot
22:18 jonathan masak: > module Foo { sub bar { say $?PACKAGE } }
22:18 jonathan > Foo::bar();
22:18 jonathan Foo
22:20 rob joined #parrot
22:20 dalek r32566 | allison++ | pdd22io:
22:20 dalek : [pdd22io] Fully switch to buffered I/O.
22:20 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32566
22:31 dalek r32567 | jonathan++ | trunk:
22:31 dalek : [rakudo] Set scope to $?FOO type variables to be lexical, and set up $?PACKAGE. Gives wrong stringification for root namespace for now (should be Main), but should be correct otherwise.
22:31 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=32567
22:34 pmichaud .... I don't understand r32567
22:35 jonathan pmichaud: How so?
22:35 pmichaud why set up $?PACKAGE in every block?
22:35 pmichaud why not just have a sub that we can call to get the current namespace?
22:35 pmichaud and invoke that sub when $?PACKAGE occurs?
22:35 jonathan I pondered that, but wasn't convinced by it...
22:36 pmichaud I definitely don't like generating code for variables that are rarely used.
22:36 jonathan The spec refers to them as, "Magical lexically scoped values"
22:36 pmichaud magical means we can do whatever magic we want :-)
22:37 jonathan I don't know that the "magically" was referring to the "lexically scoped" bit...
22:37 pmichaud it's a compile time variable, at any rate.
22:38 * jonathan ponders whether $?PACKAGE could ever end up being different if we implemented it the other way
22:39 pmichaud at any rate, I'm not comfortable with this approach.  I'm worried it'll get cargoculted all over the place for the other compiler vars.
22:39 jonathan The spec seems to suggest they're available at runtime...
22:40 pmichaud sure, they're available at runtime.
22:40 pmichaud but they're still rare, so I'd rather add them only when needed.
22:40 pmichaud we can leave it in for now, but I'm trying to keep the AST smaller
22:40 jonathan I'm not sure how we're going to make $?CLASS and $?ROLE work...
22:41 pmichaud I'm not even sure what $?CLASS and $?ROLE are supposed to return.
22:41 pmichaud my guess is the protoobject.
22:41 jonathan $?CLASS would I believe give the proto-object for the class.
22:41 jonathan $?ROLE the same thingy that a role installs in the namespace when declared.
22:42 jonathan Right now, that's an instance of Parrot Role, but that'll need to change, I expect.
22:42 moritz since all these variables are compile-time thingies, you can know at compile time if they are needed... maybe you can just create them when they are needed?
22:42 jonathan moritz: Falls apart in a world where we have eval. :-(
22:42 moritz oh, right
22:43 pmichaud no, it doesn't.
22:43 pmichaud eval can know what things are.
22:43 jonathan OK, choosing whether to emit the $?PACKAGE setting code with the approach I've taken probably wouldn't work out.
22:44 jonathan Because you wouldn't spot it inside the eval'd code until later.
22:44 jonathan I guess in the eval we'll have to emit code inside the current namespace.
22:44 jonathan And then we can make $?PACKAGE work with mapping it to a sub, I guess.
22:45 jonathan $?CLASS I ain't so sure how to do that way.
22:45 pmichaud same thing -- we can get the proto via a runtime lookup
22:45 jonathan What do we have to fetch it by, though?
22:45 pmichaud it's even pretty easy, since we already know $?NS
22:45 TiMBuS joined #parrot
22:45 jonathan That won't work for anonymous classes, though?
22:46 pmichaud hmmm
22:46 jonathan Or maybe lexical ones.
22:46 jonathan Nor inside roles.
22:46 jonathan $?CLASS when mentioned in a role is generic, I believe.
22:46 pmichaud we can always give unique names to the anonymous classes.
22:46 moritz unique per pre-compiled module, at least
22:47 jonathan True.
22:47 pmichaud I need to think about it more.
22:48 pmichaud something about the approach just committed feels wrong to me.
22:48 jonathan Oh, ::?CLASS is mentioned in S12, not $?CLASS
22:48 jonathan But it does say it's generic.
22:48 jonathan Fine, we'll do it differently.
22:49 pmichaud let's just think on it a day or two more
22:49 jonathan Sure
22:49 jonathan I certainly need to think on ::?CLASS more.
22:49 jonathan I don't see how it can be both generic and lexical.
22:49 jonathan And I'm doubting that $?CLASS and ::?CLASS both exist and mean different things.
22:54 * jonathan calls it a day
23:03 jonathan http://use.perl.org/~Jonath​anWorthington/journal/37859 # report
23:04 jonathan (and on rakudo.org too)
23:09 moritz jonathan++ # good hacking, nice report!
23:11 jonathan Thanks, I tried to write one that had some decent Perl 6 content in it today rather thanh just a list of bug fixes.
23:13 pmichaud I guess I should write a report as well.
23:13 pmichaud unfortunately it's looking like a distracting night here :-(
23:16 jonathan :-(
23:16 jonathan Maybe on the plane? ;-)
23:16 pmichaud oh, I'm hoping to do a report then, too.
23:16 pmichaud my plane isn't until friday
23:17 pmichaud (now + 66 hrs)
23:17 jonathan Yeah, and I'll bet yours is only a few hours flight too...
23:17 pmichaud indeed -- straight shot from DFW to SJC :-)
23:17 jonathan I'm connecting in Germany, then straight to SFO.
23:17 jonathan Happy that I don't have to do a connecting flight in the US.
23:18 jonathan That tends to be a pain on the way in.
23:18 pmichaud instead of doing interpinfo and .'get_namespace' .... couldn't we just do $P0 = get_namespace   ?
23:20 jonathan Erm, I suspect, yes.
23:20 * jonathan forgot that op even existed
23:20 jonathan But if we move it out to a sub, we'll need to get the caller and do .get_namespace() on it. ;-)
23:20 pmichaud yes, I was expecting that. :-)
23:21 pmichaud but we only need it when called, then, instead of every package.
23:21 jonathan Sure
23:22 Whiteknight joined #parrot
23:22 jonathan I just get a little uncomfortable when the spec says something is one thing and we do it as another. :-)
23:22 pmichaud I'm warming up to the idea of leaving it as lexical.
23:23 jonathan I saw "lexically scoped" and thought "OK, so let's make it lexical"
23:23 jonathan Yeah, but I'm still unconvinced the model will work for ::?CLASS.
23:23 pmichaud are all of the $? vars lexically scoped, or just a few?
23:23 jonathan The spec suggests they are all magical lexicals.
23:23 pmichaud okay.
23:23 pmichaud that actually makes me happier.
23:23 pmichaud on a different topic
23:24 jonathan The S02 quote I'm going on is, "Magical lexically scoped values live in variables with a ? secondary sigil."
23:24 pmichaud could we get the methods to use their actual name, instead of doing add_method ?
23:24 pmichaud ah, that quote actually says something different.
23:24 jonathan Oh?
23:24 purl hmmm... Oh is there a standard rule that defines a number of estimated man-hours per ticket?
23:25 pmichaud it says that magical lexical scoped values have a ? sigil, but doesn't necessarily mean that everything with a ? sigil is a magic lexical scoped value.
23:25 jonathan Ah, OK.
23:25 jonathan But it then goes on to list $?PACKAGE, etc.
23:25 pmichaud sure,
23:25 pmichaud it may actually be that all of them are that way, and we may still want to do it
23:25 jonathan Sure.
23:25 pmichaud I'm pretty sure we don't want $?LINE to always be a magical lexical, though.
23:26 pmichaud s/magical//
23:26 jonathan No, that's very true...
23:26 jonathan We can't support that yet.
23:26 pmichaud i.e., it can be lexical, but we want it to be "magic" so that we aren't setting a $?LINE variable on every statement.
23:26 jonathan Yes.
23:26 jonathan Makes sense.
23:26 bacek joined #parrot
23:26 jonathan On your question
23:27 jonathan Are we in the context of the is also support?
23:27 pmichaud yes, partially.
23:27 pmichaud but also in general.
23:27 jonathan OK.
23:27 pmichaud I guess the question is, why do we have to do 'add_method' and not just rely on the :method flag?
23:27 jonathan In fact, the fact that we don't name them correctly is a side-effect of me wanting to add_method them.
23:28 jonathan Well, we do (should?) in normal class definitions
23:28 jonathan That is, non-anonymous and when you don't use is also.
23:28 pmichaud ah, anonymous.
23:28 jonathan For 'is also' however, I think we should add_method them.
23:28 pmichaud ...because?
23:29 jonathan That's because we might do the 'is also' in a different compilation unit, and thus the .sub's wouldn't be visible at the time we do newclass
23:29 jonathan Which is, IIRC, the time when we look in the namespace for the subs.
23:29 nopaste "japhb" at 76.191.190.8 pasted "Easy rebase/rebuild tool for Parrot/Rakudo" (101 lines) at http://nopaste.snit.ch/14539
23:29 jonathan And find hwat is marked :method and insert them into the methods hash.
23:29 japhb particle: stick that in your pipe and smoke it.  :-)
23:30 jonathan So I don't think not add_method'ing them would work in the general case.
23:30 pmichaud if we do is also in a different compilation unit, the class must already exist.
23:30 pmichaud otherwise it's not 'is also'
23:31 jonathan I think you're right that we should emit the Parrot-level subs with their names when we do 'is also', though.
23:31 pmichaud okay
23:31 jonathan So they do end up going into the correct namespace.
23:31 jonathan But I don't think we can get away with add_method'ing them.
23:31 pmichaud ...without add_method'ing?
23:32 jonathan Oh. Trouble is, if we don't give them anonymous names, we gotta be real careful.
23:32 jonathan I don't think we can get away with having to call add_method.
23:33 pmichaud I'm having trouble parsing the negatives there.
23:33 jonathan Not unless we go change Parrot and add a way to say to it, "go look in the namespace again for any new methods"
23:33 pmichaud oh, that's not an issue.
23:33 jonathan We need to do add_method. # no negatives ;-)
23:33 pmichaud I already know that works.
23:33 pmichaud there's never a case where we have to say "check the namespace again"
23:33 jonathan I think there is.
23:34 pmichaud if the class doesn't exist, then all methods get queued up until after the class is created
23:34 pmichaud if the class already exists, then methods are automatically added at the time they're loaded
23:34 jonathan Oh?
23:34 purl Oh is probably there a standard rule that defines a number of estimated man-hours per ticket?
23:34 jonathan Really?
23:34 purl Really is it bad?
23:34 pmichaud yes.
23:34 jonathan purl, STFU.
23:34 purl well, stfu is DCC SEND "FURBLELOGGER" 0 0 0 or eval: join"",map uc,map$_ eq"i"?"u":$_,("fist"=~/./sg)[2,3,0,1] or "Show Them Fury Unleashed"
23:35 japhb Which subdir of tools/ does the rebuild tool I nopasted belong in?
23:35 pmichaud which of those two statements do you think is incorrect?
23:35 pmichaud (or "may be incorrect")
23:35 jonathan I'm not saying it's incorrect, it just isn't what I thought happened.
23:35 jonathan The second one.
23:35 pmichaud I'm certain it does.  The "look for methods" occurs at the point where the class is created.
23:35 jonathan Oh, both.
23:36 jonathan :-)
23:36 jonathan OK, so use case
23:36 pmichaud by definition, that happens at runtime.
23:36 jonathan Imagine that we have a file Foo.pm
23:36 jonathan Inside it we have
23:36 jonathan class Foo { method test1 { say 1 } }
23:36 jonathan In a script we then do
23:36 jonathan use Foo; class Foo is also { method test2 { say 2 } }
23:37 jonathan We'll have already created the proto, and thus instantiated Foo, by the time we've done "use Foo".
23:38 jonathan Now, if what I think you're saying is correct, then just putting test2 tagged with :method into the namespace Foo later on, when we do the is also, would make it appear in the methods hash.
23:38 jonathan Inside the class.
23:38 jonathan I don't think that happens.
23:38 jonathan Though I'm happy to be proven wrong.
23:38 pmichaud I can prove it happens.  :-)
23:39 pmichaud just a sec, I'll find the code :-)
23:40 pmichaud src/classes/List:141
23:41 pmichaud that adds a method to ResizablePMCArray
23:41 pmichaud clearly ResizablePMCArray already exists at the time that code is loaded
23:41 jonathan Ah!
23:41 pmichaud so the method gets added to the class.
23:42 jonathan OK. But I think that find_method by default finds things in the namespace of the same name as the PMC.
23:42 pmichaud no.
23:42 jonathan I am pretty sure that find_method in Object.pmc, which overrides it, doesn't do that.
23:42 pmichaud oh, I see what you're saying.
23:42 pmichaud okay, I'll test another way -- one moment.
23:44 nopaste "pmichaud" at 76.183.97.54 pasted "automatic add_method (for jonathan)" (16 lines) at http://nopaste.snit.ch/14540
23:45 nopaste "pmichaud" at 76.183.97.54 pasted "automatic add_method via .pbc (for jonathan)" (17 lines) at http://nopaste.snit.ch/14541
23:46 jonathan Actually the order wanted to be
23:46 jonathan $P1 = new 'Foo'
23:46 jonathan load_bytecode 'y.pir'
23:46 jonathan To mirror our situation.
23:46 jonathan Alas, it works... :-S
23:46 pmichaud oh, okay.
23:46 pmichaud I wasn't worried about the case of existing instances.
23:46 pmichaud but yes, you're correct that it's an issue because we already have an existing instance
23:46 pmichaud (the protoobject)
23:46 pmichaud still, it works.  :-)
23:47 pmichaud (using 'add_method' probably wouldn't have helpd in that situation anyway :-)
23:47 pmichaud i.e., if it works for one, it's likely to have worked for the other.
23:48 jonathan Yeah. But I'm looking at find_method in class.pmc/object.pmc and can't see *why* it works...
23:48 pmichaud doesn't find_method just look through the available methods for the class?
23:49 jonathan I can only see it looking in the hash, yeah.
23:49 pmichaud doesn't add_method modify that hash?
23:49 jonathan So it must be when the bytecode is loaded.
23:49 jonathan Yes.
23:49 pmichaud I'm thinking the bytecode calls add_method
23:49 jonathan So the only question I have now is
23:49 jonathan What happens if we don't load_bytecode y.pir
23:49 jonathan But instead we have the code in a string and eval it?
23:49 pmichaud it works too.  :-)
23:49 jonathan If *that* works, I'm convinced.
23:49 jonathan OK.
23:50 pmichaud I think I've already got a ticket for that case :-)
23:50 jonathan Right.
23:50 jonathan Then I've learend something about Parrot, and we can use the real names and just let Parrot do the Right Thing.
23:50 pmichaud I'll work on cleaning that up.
23:51 jonathan OK, sure.
23:51 pmichaud I'd like to clean up the 'def' instances also.
23:51 jonathan Should be simple.
23:51 pmichaud thanks for the answers
23:51 jonathan Ah, register scope instead?
23:51 pmichaud yes, but we may also be able to reduce the number of times we need that
23:51 jonathan On the class stuff - there's some things I want to discuss with you on that.
23:51 pmichaud I'm thinking that metaclass objects should have add_method and add_attribute and the like.
23:51 jonathan I'm kinda concerned about some of it.
23:52 jonathan Like
23:52 jonathan class Foo { } BEGIN { Foo.new }
23:52 jonathan We need to actually build the classes "on the fly".
23:52 pmichaud yes, I know.
23:52 jonathan But equally, we need to be able to do pre-compiled modules.
23:52 pmichaud yes.
23:53 jonathan Doing the two neatly could be...interesting.
23:53 pmichaud my guess is that we'll have a way to check if something's already been done.
23:53 jonathan Yes.
23:53 pmichaud that's been worrying me for some time as well
23:53 jonathan But even more than that, we might find that if we're not actually meant to be genearting a pre-compiled module, we might want to ask if we need to emit a bunch of stuff at all.
23:54 pmichaud *good* point
23:54 jonathan We need to install something in the namespace about as soon after we write "class Foo" as we can though.
23:54 pmichaud I was going to do it in the block open
23:54 jonathan Yeah.
23:55 jonathan The question is what to install.
23:55 pmichaud I would go ahead and create the class.
23:55 jonathan I mean, the ProtoObject is the Obvious Thing.
23:55 jonathan Yeah. That's easy enough for methods and stuff.
23:55 jonathan Attributes are trickier.
23:55 pmichaud yes.
23:55 jonathan Oh.
23:55 pmichaud we might end up with a prot-proto
23:55 pmichaud proto-proto
23:55 jonathan But we're adding them to the parent class
23:55 jonathan Not to the proto itself, which we instantiated.
23:55 jonathan So we may be OK.
23:55 pmichaud true!
23:56 jonathan I think we'll get away with that.
23:56 pmichaud at any rate, we can potentially come up with a proto that replaces itself on the first "real instantiation"
23:57 jonathan I don't know that this will be a big problem, I just want to find a way to neatly both do the stuff "on the fly" and also generate the code that will do it on load if needed.
23:57 pmichaud or, a proto that knows how to act like an instance of the class without actually being one.
23:57 jonathan True.
23:57 pmichaud at any rate, I was thinking that namespaces, classes, packages, etc.  get built as soon as we detect them in compilation
23:58 jonathan Yes, me too.
23:58 pmichaud that way symbol tables and the like can look in the actual namespace instead of keeping double-records in a symbol table.
23:58 jonathan Right.
23:58 pmichaud and thus eval "..."  dtrt
23:58 sjansen joined #parrot
23:58 jonathan Switching to that kinda model is something I was pondering sticking in my grant prop.
23:58 pmichaud I actually think it'll fall out kinda naturally.
23:59 pmichaud some tricky pieces here and there, but I'm not expecting a major refactor.
23:59 jonathan I think we can do it step by step.
23:59 pmichaud right.
23:59 jonathan Traits are the other thing that are givng me a headache.
23:59 pmichaud essentially I think we can selectively eval parts of the AST during compilation
23:59 jonathan sub foo { my @x is dim(1,2,3); };
23:59 jonathan for 1..100 { foo() }
23:59 pmichaud ...and that's why I'd like the compilation process to not modify the AST

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

Parrot | source cross referenced