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

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!