Camelia, the Perl 6 bug

IRC log for #parrot, 2008-07-09

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:08 rafl joined #parrot
00:09 AndyA joined #parrot
00:15 japhb joined #parrot
00:31 Ademan joined #parrot
00:50 TiMBuS joined #parrot
01:03 kid51 joined #parrot
01:28 Ademan joined #parrot
01:31 s1n moritz: i've tried that trick to run a single test, it seems to need Test.pm. what's the easiest way to including t/spec/packages/Test.pm in @INC for this?
01:31 Auzon s1n: That's not _the_ Test.pm that's used for the tests
01:32 s1n Auzon: what is?
01:32 Auzon parrot/languages/perl6/Test.pm
01:32 s1n okay, how do i get that in @INC so I can run a single test?
01:32 Auzon Easiest way is to be in parrot/languages/perl6, and type ../../parrot perl6.pbc ~/pugs/t/whatever
01:32 s1n hmm ok...
01:33 s1n that worked, thanks
01:33 s1n by the way, is it just me or does it take a while to start the test?
01:34 magnachef joined #parrot
01:35 Auzon Took me 5.5 seconds for spec/S02-builtin_data_types/nested_arrays.t with an unoptimized build and all
01:35 Auzon -e1 takes ~.3s though.
01:36 s1n weird, i'm on a gentoo build, nothing special in the configure, took me 11.5 seconds
01:36 s1n my proc isn't that slow either, wonder why that is
01:37 Auzon How long does -e1 take?
01:37 s1n heh, if i strace it, it'll segfault, does a ton of brk() calls that seem slow too
01:37 s1n what's -e1?
01:37 Auzon just ../../parrot perl6.pbc -e1
01:38 s1n 1s
01:38 s1n what is that though?
01:38 Auzon Basically, a no-op to see how long Rakudo takes to start up
01:38 s1n optimizations?
01:38 s1n oh
01:39 bacek_ s1n: perl Configure.pl --optimize --inline will speedup parrot a bit
01:39 s1n hmm, i was running the perl6 bin to get 11.5s, running parrot with the perl6.pbc took 7.7s
01:39 s1n half as long for -e1
01:41 s1n bacek_: i'll give it a whirl
01:42 s1n why would the perl6 bin be twice as slow as using parrot and the pbc?
01:42 Tene s1n: --target parse, past, pir
01:42 Auzon The perl6 binary has been known to have problems sometimes too.
01:42 Tene check times
01:42 s1n Tene: what is that, a configure switch?
01:43 s1n err looks like make target?
01:43 Tene no, parrot perl6.pbc --target=parse foo.pl
01:43 s1n oh, okay, will in a second, rebuilding parrot
01:47 Ademan joined #parrot
01:49 s1n that's no good, segfault building perl6.pbc with those configure options
01:50 s1n hmm, i didn't disable debugging and parrot doesn't have any debuggable symbols
01:52 s1n file shows its not stripped though
01:52 bacek_ s1n: make realclean is ultimate answer
01:52 Whiteknight can somebody tell me what freeze/thaw is?
01:52 s1n what does that do compared to just clean?
01:53 Infinoid Whiteknight: serialize/deserialize
01:53 Infinoid its the Storable interface
01:53 Whiteknight Infinoid, what do you mean by that?
01:53 Whiteknight I'm not familiar with that interface at all
01:53 Infinoid Whiteknight: take a complex data structure, "freeze" it into a string, so you can send it across a network or stick it in a file
01:53 Infinoid then, get it on the other side and "thaw" it back into your complex data structure.
01:54 s1n http://search.cpan.org/~ams​/Storable-2.18/Storable.pm
01:54 Whiteknight okay, I think I see what you're talking about
01:54 Whiteknight That's how PMCs are stored in PBC?
01:54 Infinoid very likely, yes
01:56 japhb s1n: realclean gets rid of extra stuff (including Makefiles and other Configure-generated files) that clean does not.  Often when 'make clean; make' fails, 'make realclean; perl Configure.pl; make' works
01:58 s1n japhb: yeah i eventually noticed my makefiles were gone
02:03 s1n no go, with --optimize and --inline i still get a segfault
02:04 s1n i don't seem to have any symbols, but this is the top of the stack: Parrot_ResizablePMCArray_set_pmc_keyed_int
02:05 s1n is there a pastebot in here?
02:06 Auzon nopaste?
02:06 clunker3 http://pasta.test-smoke.org/ or http://paste.husk.org/ or http://nopaste.snit.ch:8001/ or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/
02:09 Infinoid s1n: http://nopaste.snit.ch/ is the normal one
02:10 nopaste "s1n" at 75.16.180.101 pasted "optimize and inline crash with nqp.pbc" (20 lines) at http://nopaste.snit.ch/13532
02:10 s1n i don't have full symbols for some reason though
02:12 s1n that was executed by doing:  ./parrot /home/s1n/Projects/parrot/compilers/nqp/nqp.pbc --output=src/gen_actions.pir --encoding=fixed_8 --target=pir languages/perl6/src/parser/actions.pm
02:12 s1n which was part of the make procedures
02:13 s1n anyone have an idea as to how to get debugging symbols, so i can post an RT bug (if necessary)?
02:17 Infinoid not sure... normally debugging is on (Configure.pl has a --debugging=n flag, but it defaults to 1)
02:19 bacek_ s1n: which command causes this segfault?
02:20 Infinoid bacek_: ./parrot /home/s1n/Projects/parrot/compilers/nqp/nqp.pbc --output=src/gen_actions.pir --encoding=fixed_8 --target=pir languages/perl6/src/parser/actions.pm
02:21 bacek_ ah. ok
02:21 bacek_ missed the line
02:21 bacek_ s1n: can you try run it manually with -G optiion? ./parrot -G /home...
02:22 s1n Infinoid: i didn't disable that, just provided a prefix, optimize, and inline
02:22 Infinoid s1n: do you know if both of those were necessary to reproduce the crash?
02:22 s1n optimize seems to be the trigger, i took off inline and it still did it
02:22 s1n i'll try with just inline
02:27 Infinoid I get a different segfault with --optimize
02:28 s1n no segfault with just inline
02:29 s1n okay, does anyone have any ideas what i'm doing wrong to not get debuggable symbols? i'll submit an RT ticket
02:29 nopaste "Infinoid" at 75.5.244.195 pasted "building perl6 segfaults on x86_64 with Configure.pl --optimize" (95 lines) at http://nopaste.snit.ch/13533
02:29 Infinoid s1n: what platform?
02:30 s1n amd64
02:30 s1n gentoo, all source compiled
02:30 Infinoid I am also running gentoo amd64, and debugging symbols are working here
02:30 s1n hmmm
02:30 s1n what the hell
02:31 Infinoid my system isn't exactly standard (I've upgraded to perl 5.10.0 for instance), but last I checked, stock gentoo worked fine
02:32 Infinoid (if there's any such thing as "stock gentoo" :))
02:32 Infinoid maybe its worth comparing Configure.pl's output
02:33 nopaste "Infinoid" at 75.5.244.195 pasted "Here's mine." (89 lines) at http://nopaste.snit.ch/13534
02:37 s1n hmm i've got a different parrot version: r29179
02:40 nopaste "s1n" at 75.16.180.101 pasted "configure output" (90 lines) at http://nopaste.snit.ch/13535
02:41 s1n there's not much different, i have ctags and a different parrot revision
02:45 Infinoid yeah, that looks pretty innocent
02:46 Infinoid japhb might be interested in getting a look at your glxew.h (my system doesn't have that), but that shouldn't affect debugging symbols I don't think
02:47 Infinoid guess the next step is to trade cflags
02:47 Infinoid the first couple lines output by "make" show how it invokes the compiler
02:48 japhb Infinoid, s1n: Yep, I'm always interested in getting new tarballs of GL headers ...
02:48 Infinoid there's a -g in there in mine... it's long but it ends with:  -march=nocona -O2 -pipe -g -DHAS_GETTEXT -DHAVE_COMPUTED_GOTO -fPIC -I. -o xx.o -c xx.c
02:50 cognominal joined #parrot
02:54 s1n not mine
02:54 s1n for some reason, it's not adding it for me
02:54 s1n even when i specify debugging=1
02:57 s1n if i figure out what's going on there, i'll submit a patch, i gotta get some symbols first
02:57 s1n i do have this in my CFLAGS though: -DDISABLE_GC_DEBUG=1 -DNDEBUG
02:59 dalek r29181 | jkeenan++ | trunk:
02:59 dalek : [configure] Merge autojit branch into trunk per
03:00 dalek : http://rt.perl.org/rt3/Tic​ket/Display.html?id=43318.  Code from runstep()
03:00 dalek : refactored into internal subroutines, then tested.  Description which
03:00 dalek : Configure.pl prints for this step has been made more precise.
03:00 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29181
03:35 s1n Infinoid: okay, i built parrot with symbols and i got a totally different backtrace
03:36 Infinoid s1n: what did you have to change?
03:37 nopaste "s1n" at 75.16.180.101 pasted "optimize segfault" (36 lines) at http://nopaste.snit.ch/13536
03:37 s1n i think i'm going to create an RT ticket since i'm not the only one getting this
03:39 Infinoid please do
03:39 s1n should i still use the parrot bug or just email the ml?
03:39 s1n err parrotbug
03:39 Infinoid parrotbug@parrotcode.org, the mailing list will be copied automatically
03:40 s1n will that create an RT ticket?
03:40 Infinoid yes.
03:40 s1n okay
03:40 s1n want me to include your backtrace too?
03:41 Infinoid hmm, good question.  I'm not sure they're caused by the same thing
03:42 * Infinoid will try with -G
03:42 Infinoid in theory they should be caused by the same thing, because our platforms are more or less the same.  but the crash definitely occurs in a different spot
03:44 Infinoid adding -G to the parrot command line allows it to succeed.  guess that means it's memory-management related
03:44 Infinoid the perl6 pseudo-executable built properly for me now that I got past that one spot in compilers/json/
03:45 s1n lemme try that before I submit the repor
03:45 s1n t
03:46 Infinoid great, thanks.  (if -G does affect it, it's worth mentioning that, but it doesn't mean the bug shouldn't be submitted)
03:46 s1n -G as a gcc option?
03:46 Infinoid no, it's a parrot option
03:46 s1n oh
03:46 Infinoid it means "turn off garbage collection"
03:47 s1n alright, i'll rebuild and try again. i'll submit the report when i'm done, thanks for the help Infinoid
03:49 Infinoid no problem.
03:49 Infinoid s1n++ for the testing
03:50 s1n heh i wanted to try working through some of the skipped rakudo tests, but finding this problem will be sufficient for tonight's effort :)
03:52 s1n yup, works with the -G option
04:00 s1n alright, im out for tonight
04:44 Andy joined #parrot
04:56 Theory joined #parrot
05:20 slightlyoff left #parrot
05:24 Psyche^ joined #parrot
05:32 particle1 joined #parrot
05:52 chromatic joined #parrot
05:53 cotto_home if I want to add tests to an existing .t file where the tests are current pasm, is it fine to use pir?
05:53 chromatic Yes, please do.
05:53 cotto_home thanks
06:06 cotto_home should a normal Array PMC evaluate to true when it has unassigned elements (i.e. only size has been set)?
06:08 cotto_home it does currently, but it seems counterintuitive
06:09 Andy joined #parrot
06:15 cotto_home I guess it is the least surprising thing to do, though.
06:20 dalek r29182 | cotto++ | trunk:
06:20 dalek : [gdbm pmc] return empty string instead of PMCNULL for null key or gdmb handle
06:20 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29182
06:28 uniejo joined #parrot
06:36 cotto_home it looks like freeze and/or thaw for src/pmc/array.pmc are broken and list_visit has no test coverage
06:37 cotto_home is this worth fixing?
06:37 cotto_home other list functions have very good test coverage
06:38 purl joined #parrot
06:41 chromatic More tests is usually good.
07:01 Ademan joined #parrot
07:07 dalek r29183 | cotto++ | trunk:
07:07 dalek : [pmc] added test for get_bool, freeze/thaw and is_equal
07:07 dalek : All except freeze/thaw pass.  RT #56718 has more details.
07:07 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29183
07:07 chromatic Did you TODO the failing ones?
07:07 purl joined #parrot
07:12 dalek r29184 | fperrad++ | trunk:
07:12 dalek : [Lua]
07:12 dalek : - fix #56694 (segfault in closure.pmc)
07:12 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29184
07:13 cotto_home I did now.
07:13 dalek r29185 | cotto++ | trunk:
07:13 dalek : [pmc] TODO'd failing test
07:13 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29185
07:14 chromatic Perfect.
07:14 purl La perfection est atteinte non quand il ne reste rien � ajouter, mais quand il ne reste rien � enlever
07:15 GeJ purl: bien dit.
07:15 purl GeJ: excuse me?
07:16 cotto_home whoever added that banner to the public RT pages is awesome
07:23 Ademan joined #parrot
07:53 barney joined #parrot
08:08 iblechbot joined #parrot
09:03 dalek r29186 | bernhard++ | trunk:
09:03 dalek : [codingstd] remove trailing whitespace
09:03 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29186
09:07 clunker3 joined #parrot
09:12 desertmax joined #parrot
09:32 kj joined #parrot
10:04 dalek r29187 | bernhard++ | trunk:
10:04 dalek : [Pipp PCT] Simplify rule 'concat_expression'.
10:04 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29187
10:22 clunker3 joined #parrot
10:32 dalek r29188 | bernhard++ | trunk:
10:32 dalek : [Pipp PCT] Add test script t/php/concat.t.
10:32 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29188
10:44 kj joined #parrot
10:49 dalek r29189 | bernhard++ | trunk:
10:49 dalek : [Pipp PCT] Add concatenation to optok parsing
10:49 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29189
11:05 dalek r29190 | bernhard++ | trunk:
11:05 dalek : [Pipp PCT] Try to simplify the grammar.
11:05 dalek : Move some productions from 'expression' to 'term'.
11:05 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29190
11:08 dalek bernhard.schmalhofer@gmx.de | Pipp:
11:08 dalek link: http://www.perlfoundation.​org/parrot/index.cgi?pipp
11:08 jan joined #parrot
11:30 dalek r29191 | fperrad++ | trunk:
11:30 dalek : [build] on MinGW32
11:30 dalek : fix the following linking error :
11:30 dalek : undefined reference to `CONST_STR'
11:30 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29191
11:32 kid51 joined #parrot
11:37 dalek r29192 | bernhard++ | trunk:
11:37 dalek : [Pipp PCT] <statement_delimiters> are not needed in PAST generation.
11:37 dalek : Also put the delimiters at end of the respective statements.
11:37 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29192
11:48 dalek r29193 | bernhard++ | trunk:
11:48 dalek : [Pipp PCT] Fiddle with operator precedence table.
11:48 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29193
12:01 dalek r29194 | bernhard++ | trunk:
12:01 dalek : [Pipp PCT] Add relational ops to optok parsing.
12:01 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29194
12:24 cotto_home joined #parrot
12:29 dalek r29195 | bernhard++ | trunk:
12:29 dalek : [Pipp PCT] Neater layout of the grammar declaration.
12:29 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29195
12:34 Whiteknight joined #parrot
12:41 dalek r29196 | Whiteknight++ | gsoc_pdd09:
12:41 dalek : [gsoc_pdd09] updating to trunk r29195
12:41 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29196
12:44 contingencyplan joined #parrot
12:57 dalek r29197 | bernhard++ | trunk:
12:57 dalek : [Pipp PCT] more fiddling with grammar layout.
12:57 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29197
13:14 particle joined #parrot
13:27 gryphon joined #parrot
13:27 dalek r29198 | bernhard++ | trunk:
13:27 dalek : [Pipp PCT] Replace rule 'array_key' with rule 'expression'.
13:27 dalek : More layout-only changes.
13:27 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29198
13:39 iblechbot joined #parrot
13:42 sjansen joined #parrot
13:43 integral joined #parrot
13:44 jhorwitz joined #parrot
14:03 apeiron joined #parrot
14:06 rdice joined #parrot
14:13 dalek r29199 | bernhard++ | trunk:
14:13 dalek : [Pipp PCT] Add initial support for $this.
14:13 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29199
14:22 dalek bernhard.schmalhofer@gmx.de | Parrot:
14:22 dalek link: http://www.perlfoundation.o​rg/parrot/index.cgi?parrot
14:29 sjansen joined #parrot
14:41 dalek r29200 | bernhard++ | trunk:
14:41 dalek : [Pipp] Try to make 'make test-php' work again.
14:41 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29200
14:48 jcm joined #parrot
14:49 dalek bernhard.schmalhofer@gmx.de | PHP OO for Perl 6 programmers:
14:49 dalek link: http://www.perlfoundation.org/parrot/i​ndex.cgi?php_oo_for_perl_6_programmers
14:49 dalek bernhard.schmalhofer@gmx.de | PHP OO for Perl 6 programmers:
14:49 dalek link: http://www.perlfoundation.org/parrot/i​ndex.cgi?php_oo_for_perl_6_programmers
14:50 dalek bernhard.schmalhofer@gmx.de | PHP OO for Perl 6 programmers:
14:50 dalek link: http://www.perlfoundation.org/parrot/i​ndex.cgi?php_oo_for_perl_6_programmers
14:50 gryphon joined #parrot
14:50 dalek bernhard.schmalhofer@gmx.de | PHP OO for Perl 6 programmers:
14:50 dalek link: http://www.perlfoundation.org/parrot/i​ndex.cgi?php_oo_for_perl_6_programmers
14:53 cotto_home barney++ #"the PHP desert"
14:54 cotto_home Although dessert is the food.  Desert is the place.
14:54 dalek Christoph Otto | PHP OO for Perl 6 programmers:
14:54 dalek link: http://www.perlfoundation.org/parrot/i​ndex.cgi?php_oo_for_perl_6_programmers
14:58 cotto_home A silly way to remember is that dessert is fancy because it has two S's.
14:58 moritz just as many S's as "fancy" - oh, wait ;-)
14:59 particle you want more dessert than you want desert
14:59 moritz well, that's true ;-)
15:01 cotto_home I'd rather be stuck on a dessert island than a desert island.
15:02 moritz as long as it's not solvable in water ;)
15:02 particle *soluble
15:03 jonathan Desserts is stressed backwards.
15:30 dalek r29201 | julianalbo++ | trunk:
15:30 dalek : Allow null arguments in split opcode, RT#54384
15:30 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29201
15:38 kj joined #parrot
15:42 desertmax_ joined #parrot
15:48 dalek r29202 | bernhard++ | trunk:
15:48 dalek : [Pipp PCT] Use rule 'block' instead of '<statements>'.
15:48 dalek : Some more simplifications.
15:48 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29202
15:53 pmichaud jonathan: ping
15:57 dalek r29203 | bernhard++ | trunk:
15:57 dalek : [Pipp PCT] use the rule 'param_list', with the parentheses.
15:57 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29203
15:57 jonathan pmichaud: pong
15:57 pmichaud I'm wondering if signature binding is just a form of sub call for us.
15:58 pmichaud except that the "lexicals" refer to the outer scope.
15:58 particle ...time to add that min parameter to the lexical search sub...
16:00 jonathan Binding a signature will, as far as I had it laid out in my head, just do stuff to the lexicals in the caller's scope, yes.
16:00 pmichaud except I'm thinking it's actually a Parrot sub call
16:00 pmichaud i.e., we invoke the signature itself, and it does the bindings in the outer scope
16:01 jonathan And generate every sub to just get a slurpy list and hash?
16:01 jonathan And pass them flat?
16:01 pmichaud no
16:01 jonathan And the signature worries about the binding?
16:01 jonathan OK. I hadn't wanted to go that far, even if it's tempting in some ways.
16:01 pmichaud we _can_ do it that way, yes, and may have to, but that's not what I'm thinking
16:01 purl Oooh he is soooo fine!!!
16:02 jonathan My thought was compromise.
16:03 jonathan We generate .param declarations that do about the right thing.
16:03 pmichaud I'm thinking that    :($x) := foo()       actually generates the :($x) part as a subroutine call
16:03 jonathan But then pass it onto the signature object, to do the binding, and do any unpacking that is too complex for Parrot's calling conventions.
16:04 pmichaud sorry, actualy generates the :($x) part as a Sub definition
16:04 jonathan I was going to construct a signature, and then := would become an invocation of a method on the signature objects.
16:04 pmichaud yes, but I'm not sure that's exactly what we want
16:04 jonathan We need :(...) generally to make a signature object.
16:04 jonathan my $x = :(...);
16:04 pmichaud sure, but can that signature object be a Sub ?
16:05 pmichaud I'm trying to avoid duplicating the binding code between Signature and normal routines
16:05 jonathan I guess we could subclass sub...you just mean can it be invokable, right?
16:05 pmichaud i.e., the :named, :optional, :slurpy, etc. logic
16:06 pmichaud yes, I mean it can be invokable, we pass it whatever it's being bound to, and then it bind lexicals in the outer scope
16:06 pmichaud there's more.
16:07 pmichaud in the general multi-sub case, the dispatcher invokes a (multi) sub, but if there's an error in binding it throws an exception that tells the dispatcher to try the next candidate sub
16:07 TimToady I suspect that signatures don't have a clue whether their variables exist in an outer scope
16:08 TimToady it's the declarator that embeds them that worries about that, generally
16:08 pmichaud TimToady: yes, this would accommodate that, I think.
16:09 particle so, :(my $x) would be illegal
16:09 pmichaud particle:  yes, but   my ($x)  is legal.
16:09 TimToady now I'm wondering about my $sig := my ($a,$b,$c);  \(1,2,3) ~~ $sig and whether it binds the $a that my declares
16:10 TimToady as opposed to $sig := :($a,$b,$c), which wouldn't
16:11 particle does ~~ ever bind or assign?
16:11 particle i always thought of it as compare/match
16:11 particle never changing the lvalue or rvalue
16:12 particle but i should look again at the table to be sure
16:12 TimToady .ACCEPTS can have side effects
16:12 pmichaud matching a Signature returns true if it can bind
16:12 dalek r29204 | Whiteknight++ | gsoc_pdd09:
16:12 dalek : [gsoc_pdd09] diagnostically remove List_chunks from memory management.
16:12 jonathan But doesn't actually bind it.
16:12 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29204
16:12 jonathan use when * -> ... { } for that, IIRC.
16:13 TimToady I think it binds the variables blindly, and it doesn't know or care whether the variables exist outside the sig
16:13 TimToady it depends on what kind of declaration the sig is part of
16:13 jonathan Though trying to bind to something that doesn't exist, will be an error?
16:13 pmichaud I'm thinking of the case    :($x) = foo()
16:13 TimToady the variables exist in the sig, but aren't aliased into any outer lexical scope
16:14 pmichaud what $x are we referring to there?
16:14 TimToady itself
16:14 pmichaud sorry, :=
16:14 pmichaud :($x) := foo();
16:14 TimToady the name is a singleton
16:14 TimToady :($) := foo() has the same effect with a null name
16:14 dalek r29205 | bernhard++ | trunk:
16:14 dalek : [Pipp PCT] Add rule 'literal' for use in rule 'member_definition'.
16:14 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29205
16:15 TimToady so the 'x' part is really a form of commentary, unless the sig is embedded in a larger declarator
16:15 pmichaud how about
16:15 purl is is is <reply> a space alien
16:15 jonathan So when we do the bind, we look up $x at binding time, rather than at signature declaration time?
16:15 pmichaud :(:who($name), :why($reason)) := (why => $because, who => "me");
16:16 TimToady I don't think that can work, the way I'm thinking of signatures currently
16:16 TimToady I also don't think it's any great loss
16:16 pmichaud oh.  I took that directly from S06.  :-(
16:16 jonathan Right.
16:17 particle hee
16:17 TimToady note that my (:who($name), :why($reason)) := (why => $because, who => "me"); still works
16:17 TimToady because of the "my"
16:18 particle and my declares $name and $reason?
16:18 TimToady and, in fact, can reuse the same "my $name" declared earlier by the current rules
16:18 jonathan Right. Because what is parsed between the (...) in a my is a signature.
16:18 jonathan OH? It doesn't declare a new $name always?
16:18 pmichaud so then, if I'm understanding this correctly....
16:18 jonathan my $a; my ($a, $b); # not a redeclaration of $a?
16:18 TimToady jonathan: nope, there can only be one $name in a lexical scope
16:19 particle correct
16:19 pmichaud :($x) := foo();    simply tests that the binding occurs, but doesn't actually modify any $x
16:19 jonathan That feels so wrong.
16:19 pmichaud or is otherwise not legal
16:19 TimToady if you're looking up the dynamic stack for lexical scopes (say, to find a context var), you don't have to track the line number to know which $name
16:20 pmichaud I understand how my (:who($name)) := ...   can work, no problem.
16:20 jonathan TimToady: My comment about it being "so wrong" was in response to what pmichaud said about it not modifying $x
16:20 TimToady it can warn you unless you declare $a as proto
16:20 TimToady okay
16:21 jonathan I mean, :($x) := foo(); just looks like something that should have some effect on $x.
16:21 pmichaud thus I think we have TimToady's comment "I don't think that can work..."   ?
16:21 particle t/syntax/signature.t needs to be converted and extended to spec tests
16:22 particle these examples should be put there
16:22 jonathan OK, but I don't get why it shouldn't be allowed to work.
16:22 TimToady well, I suppose we could go the other way, and require $x to refer to something existing, but then you can't write a signature with vars as commentary
16:22 jonathan And why "my (:($x)) := foo();" should work.
16:22 TimToady and are forced to write :($,$,$,*@) and such
16:22 particle ick.
16:23 jonathan Hmmm. I see what you're getting at now, and I dislike that even more.
16:23 TimToady in any case, we need to be consistent
16:23 pmichaud I think  "my (:($x)) := foo();"   isn't exactly right -- it's just    my ($x) := foo();
16:23 jonathan Ah, OK.
16:23 jonathan Yes, mis-read.
16:24 TimToady well, it's a degenerate case of (:foo($x))
16:24 TimToady s/foo/othername/
16:24 pmichaud well, wouldn't    (:othername($x))   be a named-only param?
16:24 TimToady except it's also sig syntax
16:24 jonathan I'm just a little uncofortable that the only way to do unpack things with a signature requires a my, when the varialbes in it have already been declared.
16:25 TimToady but if sigs are allowed to look outside for existing variables, we'll get people wanting things like
16:25 TimToady sub foo ($*x) {...}
16:26 pmichaud i.e.,   my ($x) :=  foo();     and my (:othername($x)) := foo()     are really different in terms of what foo() returns
16:26 TimToady currently submethod BUILD ($!x) is kind of an exception, not a general policy
16:26 jonathan Hmmm...true. Well, they can already have method foo($.x)
16:26 jonathan Aha, OK.
16:27 jonathan I figure "has ($.x, $.y)" is another case where you'd want to parse a signature with that in.
16:27 TimToady and ($x) is really just the null twigil :)
16:28 TimToady it's probably not really a syntactic decision, but something that either succeeds or fails in semantic analysis
16:29 TimToady so you can parse sub foo ($*x) and get a syntax tree, but something downstream carps about it
16:29 jonathan Sure, we already have various "can't use that twigil here" stuff in the actions.
16:30 jonathan OK, so we're basically saying, the names in signatures only have the meaning that is provided by the declarator?
16:30 TimToady but none of the twigil meanings in signatures currently imply lexical scope scanning, other than what the declaration context supplies
16:30 TimToady one problem with this interpretion
16:31 TimToady my ($a,$b,$c) is kinda defined as my :($a,$b,$c) with an optional :
16:31 pmichaud right.
16:31 jonathan Right.
16:31 pmichaud that's what prompted this.  :-)
16:31 TimToady maybe we need a singleton sigil :)
16:31 TimToady s/sigil/twigil
16:31 jonathan But it's the "my" there that means, "the names in this signature are varialbes that we should declare"
16:32 jonathan (if they aren't already declared in this scope)
16:32 TimToady ah true
16:32 TimToady now I'm confusing me own self
16:32 TimToady so that's okay still
16:33 jonathan and in the case of sub foo($a, $b) { ... } it's the fact that they appear in the sub declaration that gives them the "these are parameters to bind" meaning
16:33 pmichaud ('sub' is just another declarator)
16:33 TimToady yes, it's implicitly a "my" context inside
16:33 TimToady likewise for ->
16:34 jonathan We could just have another declarator, which makes the meaning be "look up the names in the current scope and bind to them".
16:34 TimToady sort of a rewrite to my ($a,$b) := @_, as it were
16:34 pmichaud 'sig'
16:34 TimToady jonathan: that's called "my" :)
16:34 pmichaud what if the variables aren't 'my' variables, though?
16:34 pmichaud our $a;  my $b;
16:34 pmichaud my ($a, $b) := ...
16:35 jonathan There's that, and I'm also thinking of a way to do this without making it look like a redeclaration.
16:35 pmichaud or, if we want to bind to things with twigils
16:36 pmichaud so, perhaps 'sig' is the commentary varnames, leaving :(...) to do binding?  or vice-versa?
16:36 TimToady outside of the "our", $a looks like it was a my
16:36 japhb jonathan++.  Seeing a visually rendundant 'my', just to get the variable binding semantic, will be confusing to me -- or at least cause a mental stutter.
16:36 particle sig (my $a, our $b) ??
16:36 TimToady in any case, you can get a warning on the redeclaration unless you say proto our $a; proto my $b; above
16:36 pmichaud my $s = sig ($a, $b)     --->   same as   sig ($, $)
16:36 TimToady so we have a way currently, but it's up at the top
16:37 pmichaud okay
16:37 TimToady you mark the reusable name, not the re-use spot
16:37 japhb TimToady: but being forced to say 'my' at the reuse spot is jarring.
16:37 particle { our $a; { my $b; my $s = sig ($a, $b); } }
16:38 TimToady what, you never say "my dog Fido" twice in the same conversation?
16:38 pmichaud heh
16:38 pmichaud *in fact*
16:38 particle { our $a; { my $b; my ($a, $b) := ...; } }
16:38 pmichaud one can test signature bindings using a null routine
16:38 pmichaud sub foo($x, $y) { ... }     # foo is effectively   :($,$)
16:38 Theory joined #parrot
16:39 pmichaud sorry, eliminate my ... there
16:39 pmichaud sub foo($x, $y) { }
16:39 nopaste "barney" at 84.154.13.62 pasted "Should that work with Rakudo?" (40 lines) at http://nopaste.snit.ch/13538
16:39 TimToady yes, in terms of constraint checking, it's :($,$).ACCEPTS($capture)
16:40 jonathan particle: In that case, since $a is in an outer scope, I guess even the "not declared with proto" thing wouldn't get you a warning you weren't declaring a new lexical.
16:40 particle right
16:40 TimToady yes, $a would be different, and $b would be the same
16:41 japhb TimToady: I get that, sure, but there aren't any computer languages I use where 'my dog Fido' or the moral equivalent can mean declaration the first time, and something very different (like, say, signature binding) in the second.
16:41 japhb (that == 'my dog Fido' joke)
16:41 particle that's not what i'd want to happen
16:41 pmichaud barney: I don't know if initializers work on has declarators yet
16:41 TimToady YOU GET A DIRE WARNING unless you say "proto"
16:42 jonathan TimToady: Even in particle's example, where the variable name being "re-used" is declared in an outer scope?
16:42 TimToady no, you get the warning on $b, not on $a
16:43 particle { our $a; { proto my $b; my ($a, $b) := ...; } }
16:43 jonathan Aha, OK, makes sense. But it still doesn't give us a way, to bind to the outer $a.
16:43 particle { our $a; { proto my $b; my ($a, $b) := ...; #{$a is defined} } #{$a is undef} }
16:44 particle does { proto our $a; { multi my $a; } } allow you to bind the outer $a?
16:45 japhb OK, perhaps this will help my confusion -- what is the recommended syntax to do this concept: 'sub foo($baz) { my ($a, $b); if $baz { :($a, $b) := bar() } else { :($a, $b) := quux() } say "a: $a, b: $b"; }'
16:45 dalek r29206 | cotto++ | trunk:
16:45 dalek : [pmc] added a test to exercise FixedPMCArray's is_equals.  The test exposes a
16:45 dalek : bug, so it's TODO'd until a fix is found.
16:45 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29206
16:45 pmichaud fwiw, I think that the syntax japhb just get ought to be the recommended syntax (more)
16:46 pmichaud and that signature w/commentary variables is simply     "sub ($a, $b) { ... }"
16:46 pmichaud or w/o the ...
16:46 pmichaud or with a special declarator  'sig'  that doesn't require a body:     "sig ($a, $b);"
16:47 jonathan pmichaud: This makes sense to me.
16:47 pmichaud (or a semi, in that mis-typed example)
16:47 pmichaud perhaps that huffman-codes the wrong way -- I haven't thought about it much.
16:47 pmichaud I'm just going off-the-top-of-my-head
16:47 TimToady well, there's always OUTER:: and MY::
16:48 japhb TimToady: so how would you write my example?
16:48 TimToady :(OUTER::<$a>)= 1 might work
16:48 TimToady := rather
16:48 particle hrmm
16:49 TimToady and the limit on sub foo ($*x) is not imposed by the sig, but by the sub
16:49 particle of course, then you need to know how many OUTER:: scopes above $a was declared
16:49 TimToady so :(GLOBAL::<$x>) := 1 probably even works
16:50 TimToady but that tends to point toward :($x) also doing the normal thing
16:50 TimToady and looking in MY::
16:50 pmichaud I don't quite understand "the limit on sub foo ($*x)" comment.  (I don't necessarily need to understand it, but...)
16:51 TimToady well, it's not really an impossible thing for a sub to bind to a global parameter, but it's just kind of one of those policies that you probably want to enforce for sanity
16:52 TimToady or not...
16:52 jonathan TimToady: It feels strange to use a pseudo-package there, when to someone writing { my $a; ...stuff...; :([$a, @]) := foo() } style things wouldn't really thing of $a is being in anything other than the current scope visually (as in, where the curlies are).
16:52 jonathan s/thing/think/
16:52 pmichaud s:2nd/thing/think/   :-)
16:52 TimToady yes, and we do have the bare $ syntax to mean the other thing
16:53 pmichaud I wasn't recommending that   'sub foo ($*x)'  be allowed to bind to a global param.  (I.e., I still don't understand.)
16:53 TimToady so the sane thing is probably to treat :($a,$b) := consistently with ($a,$b) =
16:54 TimToady if :($a,$b) := 1,2; works on existing vars, then so does :($*a,$*b) := 1,2;
16:54 pmichaud ahhhhh
16:54 TimToady and if that works, then so does sub foo ($*a,$*b)
16:54 pmichaud okay, I get it now.  thanks.
16:54 TimToady and if there's a policy, it's enforced by the decl
16:54 jonathan But the sub declarator could choose to forbid it.
16:55 TimToady or just issue a DIRE WARNING :)
16:55 pmichaud I agree w/jonathan -- the sub declaration can forbid it, just as we expect to forbid things in has, our, my, etc.
16:55 japhb Apparently all of our dire warnings should be capitalized.  :-)
16:56 TimToady I didn't hear the words between "our" and "should"...
16:56 japhb heh
16:56 pmichaud I think our warnings ought to begin with   "Larry says"   :-)
16:57 pmichaud "Larry says you shouldn't use a global variable here."
16:57 japhb OK, so have we now returned to the state that my example is actually correct syntax?
16:57 japhb pmichaud: nice!
16:57 TimToady Larry says take three giant steps forward
16:57 pmichaud or, even better, "TimToady says you shouldn't use a global variable here.  There are many other (better) ways to do it."
16:57 pmichaud minor disaster here-- bbiab
16:57 particle Larry says lose a turn, install python.
16:57 japhb "I didn't say 'Larry says'! Segmentation fault (core dumped)"
16:58 jonathan TimToady: OK, so ":($a, $b) := foo()" is the same as "($a, $b) := foo()". But you can use the Full Power of signatures on the LHS.
16:58 jonathan What about now: my $sig = :($a, $b); ...later, in a galaxy far, far away... $sig := foo()
16:58 TimToady yes, you have the declarative syntax rather than the rvalue list syntax, fwiw
16:59 TimToady er, you mean foo() ~~ $sig ?
17:00 TimToady $sig := foo() would do something else
17:00 particle btw, rakudo's make -j fulltest has some funky display issues, but runs without error
17:00 jonathan Ah, of course.
17:00 jonathan OK, so in :(...) := ..., we syntactically know what := is going to do.
17:01 TimToady that's where I'm saying that sig matching doesn't know or care whether or where the $a and $b are actually aliased to
17:01 TimToady or however you say that...
17:01 TimToady it has a variable, and it binds it, and that might have effects elsewhere
17:01 TimToady or it might now
17:01 TimToady *not
17:02 jonathan OK, so :($a, $undeclared_thingy) := foo() will not be an error?
17:02 TimToady yes, it's an lvalue signature
17:02 TimToady I think we have to make it an error
17:02 jonathan OK, that's what I was hoping.
17:02 TimToady :($a, my $b) := ...
17:04 particle that last statement will work, and throw away $b?
17:04 TimToady no, declares it in the current scope
17:04 TimToady no {...} around it
17:04 particle ah, ok
17:04 TimToady so it propagates outward
17:05 jonathan I don't look forward to implementing that, but I think it's the Right Thing. :-)
17:05 TimToady seems to follow least surprise
17:05 jonathan Right. Which is what I'm aiming for here.
17:05 particle i don't know what to be surprised about anymore
17:05 pmichaud does <signature> handle declarators inside the parens?
17:06 TimToady not currently
17:06 * jonathan throws a badger at particle.
17:06 pmichaud I think I'd rather not have   :($a, my $b) then
17:06 * particle always tries to anticipate chaos
17:06 pmichaud my $b;  :($a, $b) :=   seems easiers
17:06 dalek bernhard.schmalhofer@gmx.de | PHP OO for Perl 6 programmers:
17:06 dalek link: http://www.perlfoundation.org/parrot/i​ndex.cgi?php_oo_for_perl_6_programmers
17:07 TimToady pmichaud: nodnod
17:07 pmichaud (minor disaster continues, expands... bbiab)
17:07 particle ah, kids.
17:08 particle on a different but related topic, in perl 5 (undef, $x) = foo() allows you to throw away a result...
17:08 TimToady or ($a, my $b) = works too
17:08 particle can you throw away all named results in perl 6?
17:08 jonathan *%
17:08 cognominal joined #parrot
17:08 jonathan At a guess.
17:08 TimToady what he said
17:08 particle wasn't sure if that'd work, but that'd be my guess
17:08 particle fab.
17:09 dalek bernhard.schmalhofer@gmx.de | PHP OO for Perl 6 programmers:
17:09 dalek link: http://www.perlfoundation.org/parrot/i​ndex.cgi?php_oo_for_perl_6_programmers
17:09 moritz .oO( we just have to implement it ;-)
17:09 jonathan moritz: Ssshhh... :-P
17:10 jonathan OK, seems we have signatures straightened out somewhat.
17:10 jonathan TimToady++ # thanks
17:12 jonathan TimToady: While you're about, one other thing occurred to be: at the moment for parametric roles, we parse it as something like <name> '[' <EXPR> ']'
17:12 jonathan s/be/me/ # wish I could type today
17:12 jonathan For the role declaration, parsing a signature there would make more sense to me - am I missing something?
17:12 particle moritz: think you could look at t/syntax/signature.t conversion to spec tests?
17:13 TimToady jonathan: agree
17:13 pmichaud so, back to my original comment, I'm thinking that Parrot's implementation of signature binding is perhaps just a sub that bounds to lexicals in its outer scope?
17:13 jonathan OK, thanks.
17:13 moritz particle: yes
17:13 particle moritz++
17:13 moritz I'd only need to understand them :/
17:13 jonathan pmichaud: That now makes some sense, yes.
17:14 dalek r29207 | cotto++ | trunk:
17:14 dalek : [pmc] fixed fixedpmcarray bug, unTODO'd related test
17:14 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29207
17:14 TimToady I wish I knew whether the php_oo example was trying to be idiomatic Perl 6 or trying to be idio(ma)tic PHP
17:14 jonathan pmichaud: I'm curious though what my $x = (:($a, $b) := foo()); leaves in $x - if it's a signature object, we have to build one of those still.
17:14 pmichaud jonathan: it can still be a subclass of the Sub PMC
17:15 jonathan Signature?
17:15 purl Signature is invalid
17:15 TimToady it's certainly not how I'd write the Perl 6...
17:15 jonathan TimToady: Expand?
17:15 purl i think Expand is at language.perl.com/ppt/src/expand/
17:16 TimToady using ~ instead of interpolation, adding extra () on all the calls...
17:16 particle TimToady: it's a wiki :)
17:16 jonathan pmichaud: Signatures are generally not invokable, so it doesn't feel completely right to me...
17:16 barney TimToady: I'm translating PHP examples to Perl6,   is there idiomatic PHP ?
17:17 jonathan TimToady: Ah, I didn't realize what that was a comment to... :-)
17:17 TimToady I'd make it a method for now, and if it ends up there's only one such method, and it works with .(), then you could easil refactor later
17:17 particle i'd also write "my Foo $foo .= new;"
17:17 pmichaud jonathan: I think the only alternatives are to have two separate mechanisms for signature binding, or to have all subs use :slurpy arguments and then bind with a separate signature specification
17:17 TimToady or we'll probably end up with "new Foo" working too.
17:17 TimToady if we defined sub new in Any to do it
17:18 particle indirect object notation?
17:18 purl indirect object notation is taking a beating on p5p
17:18 pmichaud and I'm not a big fan of the "two separate mechanisms" approach.
17:18 TimToady no, just a listop with one arg
17:19 TimToady on the principle of "The customer is always right"
17:19 pmichaud yes, I caught myself writing   new PAST::Op   this past week
17:19 particle well, then, there you go.
17:19 jonathan pmichaud: Me either. But I think that since we need to do things like sub foo($a, [$b, @]) { ... } and other unpacking stuff that we ain't going to be able to get Parrot to do for us, we will always need to get the signature object to do some work for us.
17:19 pmichaud unfortunately, I was writing it as  new PAST::Op(...args...)   which doesn't really do what I want.
17:19 TimToady and if it's actually indirected to PAST::Op.new, then people will naturally micro-optimize to the latter
17:20 TimToady yeah, don't see a decent way to support that syntax
17:20 TimToady well, not without making protoobjects respond to .()
17:20 pmichaud jonathan: well, except we don't have to have a separate Signature Object
17:20 TimToady which already means a coercion
17:20 particle would .new :Past::Op (...) work?
17:20 jonathan pmichaud: Huh?
17:21 pmichaud inside of a sub
17:21 particle i think i misplaced a colon
17:21 TimToady .new: Foo
17:21 TimToady no
17:21 jonathan pmichaud: Every sub has an associated signature object.
17:21 TimToady that would mean $_.new: Foo
17:21 pmichaud jonathan: every sub has a way to get at its signature.
17:21 TimToady .new given Foo
17:22 pmichaud how that's represented isn't entirely spec'd yet.
17:22 moritz TimToady: and that's idomatic perl 6? ;-)
17:22 TimToady s/ma//
17:22 particle i don't like 'new Foo' if you can't do 'new Foo(...)'
17:22 jonathan pmichaud: At a Perl 6 level, &?ROUTINE.signature
17:22 pmichaud jonathan: sure, I'm speaking of PIR level
17:22 pmichaud and I don't like having two separate representations of signatures at the PIR level
17:23 jonathan pmichaud: At a PIR level, $P0 = interpinfo .INTERPINFO_CURRENT_SUB\n$P0 = $P0.'signature'
17:23 jonathan ()
17:23 pmichaud nonono
17:23 pmichaud sub foo(Int $a) { ... }
17:23 pmichaud how does that Int constraint get attached to $a ?
17:24 TimToady same way my Int $a does it, presumably
17:24 pmichaud right now the code is doing it in two parts -- one that places it in the .signature, another that attached a constraint to $a, and there are different paths for doing it.
17:24 pmichaud TimToady: yes, that's what I'm thinking.
17:24 NotFound Is a good idea to define a function to create an empty string and replace with it a lot of CONST_STRING(interp, "") ?
17:25 TimToady come again?
17:25 purl Damn, TimToady!  I just gave you sweet lovin' 10 minutes ago!
17:25 TimToady I have staying power...
17:25 jonathan pmichaud: Right, at the moment that's what happens; if we switch over to letting the signature object do all of the work/checks/binding etc, we'd clear up the duplication.
17:26 pmichaud jonathan: so, you're saying pass all params as slurpy then?
17:26 jonathan Half of we wants to say, let's just do it. Part of me is thinking, is this really a good idea. :-S
17:26 jonathan Can you think of good reasons not to do this?
17:27 TimToady are you merely converging on the notion of Capture?
17:27 pmichaud TimToady: ultimately, yes.
17:27 jonathan TimToady: Yeah, it seems so...
17:27 pmichaud TimToady: Parrot doesn't haven't an internal notion of Capture yet
17:27 TimToady then converging sooner would seem better than converging later  :)
17:27 pmichaud we can certainly impose one on it, but there's this "language interop" issue we also want to deal with
17:28 particle NotFound: why would you replace a compile-time constant  with a runtime lookup?
17:28 NotFound particle: mainly because is not a compile-time constant.
17:28 jonathan pmichaud: I'm not sure that it'll be a big issue for interop, if we just accept slurpies.
17:29 TimToady pmichaud: are you claiming that other languages aren't interested in named args or invocants? :)
17:29 pmichaud TimToady: I'm only claiming that the Parrot way of doing it doesn't match Perl 6 :-)
17:29 NotFound CONST_CAST is a call to a function that makes a lookup, build a string header, and fills it.
17:29 NotFound Err... CONST_STRING
17:30 TimToady first-class Captures can be optimized away, but I'm not sure they can be pessimized toward.  :)
17:30 NotFound For an empty string, build the header is almos all.
17:30 particle pmichaud: if parrot way matches perl 6 way, then all other languages pay the penalty
17:30 pmichaud particle:  no, Parrot could provide a :capture flag
17:30 TimToady heh
17:30 pmichaud *and*
17:31 pmichaud I actually suspect that using captures would be more efficient than the way Parrot does it now
17:31 pmichaud I have no proof of this, but it seems like a far easier resolution mechanism than what we currently have
17:31 pmichaud *and*
17:31 TimToady you build the capture once for all the multies you want to match against, including any that want the capture whole
17:31 jonathan It will bring world peace?
17:31 pmichaud following what TimToady said, a lot of it could be optimized away, although the reverse isn't true
17:32 particle NotFound: if there's a faster way, like putting a singleton string struct with null value in a shared header, sounds good to me
17:32 particle i've thought about giving parrot a caputure pmc, and using that for mmd
17:32 NotFound particle: I looked at it, but I think that always bulding the header is fast, and is safer, because we have no way to guarantee const usage.
17:33 jonathan pmichaud: I suggest we look at the route of taking slurpies, and letting the signature do the binding for us.
17:33 jonathan From other languages, they can still pass us args. The caller doesn't care if the callee is slurping.
17:33 pmichaud I was hoping to avoid the extra ResizablePMCArray creation on every subcall
17:33 moritz "Null PMC access in type()" just plain sucks while fudging tests - anything anyone can do about it?
17:34 pmichaud especially for subs that don't need it or do any funky things with signatures.
17:34 NotFound And even if we can, that creates a lot of COW and unCOW on every modification of the returned string.
17:34 jonathan OK, but if we're saying we're going to aim to get Parrot to provide something better in the future, this lets us get the right semantics for now and gives us soemthing we can easily refactor into a capture-supproing-Parrot like shape later.
17:35 pmichaud *actually*
17:35 jonathan *supporting
17:35 pmichaud I think we can have both.
17:35 pmichaud certainly we can do it if Signature is in fact a PIR sub
17:35 pmichaud it's no problem to make it un-invocable.
17:36 pmichaud if that's what is bothering you.
17:36 jonathan It just haven't seen the benefits that much yet.
17:36 pmichaud PIR is easier to represent in PIR than a data structure.
17:36 pmichaud especially since the act of binding is more procedural than anything else.
17:36 NotFound moritz: don't use Null PMCs ;)
17:37 pmichaud even now, our constrants tend to be blocks.
17:37 moritz NotFound: I don't. I only use Perl 6 ;-)
17:37 pmichaud moritz: I don't think we know the source of the "Null PMC access in type()" yet.
17:37 apple-gunkies joined #parrot
17:37 jonathan pmichaud: Constraints are always generated as blocks at the moment.
17:37 moritz pmichaud: would a minimal Perl 6 example help?
17:37 pmichaud right.  I don't think that will change.
17:38 pmichaud I think by definition our constraints are somewhat procedural.
17:38 pmichaud which, in Parrot, means "block"
17:38 particle moritz: yes, it would
17:38 pmichaud since a signature is really a form of constraint, it also makes sense for it to be a .sub
17:38 particle moritz: it's been hard to cosistently replicate
17:39 pmichaud (actually, a signature is just a set of constraints over a set of variables)
17:39 jonathan pmichaud: Yes, but also signatures need to be introspectable.
17:39 pmichaud how introspectable?
17:40 jonathan .arity and .count for starters, but also see perl6-language
17:40 jonathan I posted about this yesterday and TimToady answered.
17:40 pmichaud I did see perl6-language, which led me to where I am now :-)
17:40 pmichaud .arity and .count are also introspectable on blocks
17:41 pmichaud and probably should be introspectable on Parrot subs in general
17:41 jonathan OK
17:41 jonathan But you can also get a bunch of parameter descriptors.
17:41 pmichaud which would look like...?
17:42 jonathan for @(&foo.signature.parameters) { say .name }
17:42 pmichaud I can still do that.
17:42 jonathan Oh, sure, it's possible.
17:43 jonathan I guess we'd just produce code that could generate that data structure.
17:43 pmichaud I can do it even easier if the way that we represent constraints is the same for variables as it is for signatures
17:43 jonathan On demand, if needed.
17:43 jonathan It is.
17:43 jonathan Or can be.
17:43 jonathan At the moment, constraints on varaibles = and junction of the constraints.
17:43 pmichaud yes, I know
17:44 pmichaud that works well for me
17:44 jonathan I was pondering the same way for parameters.
17:44 pmichaud that's what my refactor intends to do
17:44 jonathan Right. It was on my "want to do" list too, just didn't get to it. So I'm all for that.
17:45 pmichaud but I wasn't planning to try to do it as a separate signature object
17:46 pmichaud instead, my 'signatures' are simply subs that set constraints on the variables and bind them appropriately
17:46 pmichaud and for anything else we introspect on the variables
17:46 jonathan introspect on the variables?
17:46 TimToady hmm, junctions as self-optimizing jits based on history...
17:46 jonathan TimToady: Also, parallely evaluatable.
17:47 TimToady that too
17:47 pmichaud jonathan: sure, introspect on the variables.  what sorts of introspection would we want to do besides .name ?
17:47 jonathan pmichaud: .constraints :-)
17:47 pmichaud which are junctions
17:47 pmichaud which I think ought to be attached to the variables
17:47 jonathan But maybe .slurpy, .named etc
17:47 TimToady manycores Я  us
17:48 pmichaud i.e., I can see wanting to do   VAR($a).constraints
17:48 jonathan Depends just how introspectable signatures need to be.
17:48 jonathan Right, but introspecting the bound to variable isn't the same as introspecting the signature.
17:48 pmichaud how does it differ?
17:49 jonathan Imagine &foo.signature.parameters when we'd never invoked or bound foo
17:49 pmichaud hrm.
17:49 jonathan s/or bound/
17:49 jonathan /
17:49 TimToady or currying, even
17:49 jonathan I think a signature object itself needs to actually describe the signature.
17:50 TimToady or subsetting a multi using args
17:50 jonathan And with :(Int $) style things, there's no variable name, but still a scalar that has an Int constraint.
17:50 pmichaud so, name is just empty in that case
17:50 jonathan Right.
17:50 pmichaud we can have nameless Scalars  :-)
17:50 pmichaud that already exists now .
17:51 jonathan pmichaud: Also, VAR($a) does constraints($some_new_ones) # oh no, please say isn't allowed. :-)
17:51 pmichaud oh, I was wondering about that also
17:51 pmichaud my Foo $a;
17:51 pmichaud my Bar $b := $a;
17:52 pmichaud (not allowed?  how are they constrained?)
17:52 NotFound What's the current recommended usage, INTERP or interp?
17:52 pmichaud NotFound: when in doubt, I'd also go for the CAPS version.
17:52 pmichaud s/also/always/
17:53 particle notfound: ack is your friend
17:53 jonathan pmichaud: I'm not so clear on that, as := replaces the container.
17:53 pmichaud ...replaces the container?
17:54 jonathan It's a binding.
17:54 jonathan So $b is now bound to whatever $a is.
17:54 NotFound particle: not very usefull when there is a lot of both usages.
17:54 pmichaud I thought it just meant that $b and $a refer to the same container.
17:54 jonathan Right.
17:54 jonathan Sorry, I mis-spoke.
17:54 jonathan That's what I was trying to say.
17:54 pmichaud so, what constraints does that container get?
17:55 moritz ok, Null PMC example in #56748
17:55 jonathan So I'm not sure what my Bar $b := $a; means, because you're declaring a type constraint for the container $b, but then making it reference the container $a.
17:56 jonathan The current container $b doesn't really get a say in it.
17:56 pmichaud okay, then:    my Foo $a;  sub xyz(Bar $b) { ... };   xyz($a);
17:56 pmichaud actually, add a 'is rw' to that.
17:57 slightlyoff joined #parrot
17:57 PerlJam woo, it looks like you guys are having a weighty discussion today
17:58 PerlJam pm: not knowing the relationship between Foo and Bar, wouldn't that be a type-constraint error?
17:58 jonathan pmichaud: Another fun case. Here, the call could fail if the value in $a is not an instance of Bar.
17:58 jonathan erm
17:58 jonathan Instance of something that isa/does bar.
17:58 jonathan Bar
17:58 slightlyoff left #parrot
17:58 jonathan Or Bar could be a subset type, of course.
17:58 PerlJam what jonathan said
17:58 pmichaud sure, if it doesn't bind, no problem.  But what about
17:59 pmichaud my Foo $a;  sub xyz(Bar $b) { $b = something_valid_for-Bar };   xyz($a)
18:00 jonathan Supposing that $a isa Bar, for example?
18:00 pmichaud $a could be something that "does Bar", but something_valid_for_Bar might not be "does Foo"
18:00 jonathan Yeah.
18:00 pmichaud (and I forgot my 'is rw' again)
18:01 pmichaud so we can't really say "$b doesn't get a say".
18:01 jonathan At the moment, in Rakudo, if you try and assign something to $b that does not do Foo, it'll fail.
18:01 jonathan However, is copy gets you a fresh container that has the type constraint Bar.
18:01 jonathan And with is ro, the default, you can't assign to it, of course.
18:01 pmichaud right
18:02 jonathan Whether that is the Right Semantics, is a question for @Larry.
18:02 pmichaud Bar $b is rw   is essentially the same as    my Bar $b := $a;
18:02 pmichaud (when the binding occurs)
18:02 jonathan Yeah, but the := doesn't result in a check that the value of $a is type compatible with Bar.
18:03 pmichaud it probably should.
18:03 jonathan I'd guess so.
18:03 pmichaud think of it as
18:03 pmichaud my (Bar $b) := $a;    # :-)
18:03 jonathan Right, which would fail. :-)
18:03 pmichaud there's not really a lot of difference between that and    my Bar $b := $a;
18:03 jonathan So yes, for consistency we should be doing a check.
18:04 jonathan Right. Agree, and agree there shuld be a check.
18:04 pmichaud which is why I'm thinking that signatures are actually routine-ish  :-)
18:05 jonathan Only because, we emit the code to do the check in routines at the moment. ;-)
18:05 jonathan I'm not saying they shouldn't be procedural here.
18:05 pmichaud I'm thinking they're procedural in general, with exceptions for failure
18:05 jonathan I'm just saying, given we need to have a data representation too, that might not be everything there is to it.
18:06 pmichaud 'introspectable' doesn't always mean represented in a data structure
18:06 jonathan For example, for MMD, I don't care about binding. I do care about (quickly) knowing what the types in the signature are.
18:06 jonathan Right, but we shouldn't make introspection slow either.
18:06 jonathan I was mostly implementing signautres now to be able to introspect them. :-)
18:06 pmichaud well, for Perl 6 MMD you really care about binding, also, at some point
18:06 jonathan Oh, at some point, but the dispatcher cares first about the types.
18:06 pmichaud for a first-pass I agree that types is sufficient
18:06 jonathan So it can look at type narrowness.
18:06 pmichaud but I don't have to have a Signature structure for that
18:07 jonathan No, put having to invoke something that gives bits of the type information every time will be bad.
18:08 pmichaud worse than method calls on a Signature structure?
18:08 Theory joined #parrot
18:08 jonathan I just want to be able to say "OK, here's a candidate, get it's signature, get the types of the parameters we care about and their types" etc.
18:08 jonathan Well, in the MMD guts I'd pondered cheating and just knowing the data structure. ;-)
18:08 pmichaud ah.  *that* sounds very Perl 6 specific, unless you're creating a Parrot Signature PMC
18:09 jonathan We'll have a Parrot-specific MultiSub PMC.
18:10 pmichaud so, where does ":multi(...)"  fail to act as "get the types of the parameters we care about"?
18:10 jonathan And yes, this will be tricky if we want to have a multi-sub with different subs in the multi being from different languages.
18:10 Andy joined #parrot
18:10 jonathan Because :multi doesn't let you specify enough.
18:10 pmichaud example?
18:11 jonathan :multi(...) just takes some type names in there, which it expects to resolve to PMC type IDs later, as I understand it.
18:11 pmichaud and, of course, :multi doesn't have to do all of the constraint checking -- just enough to cull out the list of subs we have to check using constraints
18:11 jonathan Right.
18:12 jonathan But it's tricky, since we don't know until runtime whether constraints are actually classes or subsets or roles.
18:12 pmichaud well, subsets require a runtime check, regardless
18:12 jonathan Sure.
18:12 pmichaud so that's not going to be captured in type information anyway
18:13 jonathan I'm thinking that multi sub foo(Thing $a) { ... }
18:13 jonathan Is Thing a class? A role? A subset type?
18:13 jonathan We maybe don't know at compile time.
18:13 pmichaud we know at the point where we compile foo
18:13 pmichaud Thing has to be predeclared.
18:14 jonathan OK but
18:14 jonathan Hmm]
18:14 jonathan True.
18:14 jonathan We don't have the registry in place in the compiler to track that for now.
18:14 pmichaud (we don't currently do that, right)
18:14 jonathan Also, I'm not completely sure that we can put roles in :multi as well as classes.
18:16 pmichaud at any rate,  :multi() or anything type-based looks like more of an optimization to me
18:16 jonathan My plan was just to have all the information in the signature, and side-step :multi aside from emitting the right number of _ for the arity.
18:16 jonathan And then the Perl6Multi PMC would do the Right Thing, based upon the signatures.
18:17 pmichaud but it has to have intimate knowledge of the signature structure
18:17 pmichaud (which is okay)
18:17 jonathan Which isn't a problem for langauge inter-op, because people will call through the Perl6Multi, which knows where tofind the type info.
18:17 jonathan Right, because this is all internal to Perl 6.
18:17 pmichaud so then we need an efficient mechanism to build the signature structure
18:18 jonathan Right. So my code now builds it inside a :immediate sub.
18:18 jonathan e.g. at compile time
18:18 pmichaud I don't like :immediate.
18:18 jonathan And attaches it as a property to the sub.
18:18 jonathan So we build it at compile time.
18:18 pmichaud and the constraints need to be something attachable to the variables
18:19 pmichaud (in general, anytime we are doing things in w/inline PIR I think we're doing something wrong.)
18:19 jonathan They are - they're just the blocks.
18:19 jonathan It's should just be making a signature data structure which is an array of hashes at the moment.
18:20 jonathan I can find a way to do the exact same without inline PIR, it was just easier this way.
18:20 pmichaud array is indexed based on parameter?
18:20 jonathan Yeah
18:20 pmichaud hashes contain the properties?
18:20 jonathan Right.
18:20 jonathan name, constraints, etc.
18:21 jonathan I had constraints as a list, but as you point out, it should be a junction.
18:21 pmichaud well, it could be a list, too, if we remembered to use  all(...) on it
18:21 jonathan Sure.
18:21 jonathan There's more than one way to do it.
18:22 pmichaud I'm really uncomfortable with the $?SIG_BLOCK_NOT_NEEDED global
18:23 pmichaud and it feels to me as though the constraints should be attached to the PAST::Var nodes
18:23 jonathan It'll have a load less use, if we're planning to get signatures to do the binding.
18:24 pmichaud I didn't parse that last one.
18:24 jonathan PAST::Var - well, not really, because we'll just take a slurpy array and hashes and invoke the signature to do the binding for us.
18:25 pmichaud right.  but if we're invoking the signature anyway, it doesn't have to be a slurpy array and hashes
18:25 pmichaud i.e., the signature is PIR.
18:25 jonathan OK, but I mean in the sub itself that is called, and then invokes the signature.
18:25 pmichaud invokes or bind?
18:25 pmichaud if the signature is PIR, then it's just part of the prologue of the sub itself.
18:26 jonathan Oh!!
18:26 jonathan Damm. Now I get what you're trying to do.
18:26 pmichaud i.e.,   a signature is really effectively    'sub (...params...) { }'
18:26 pmichaud a block with a signature is   'sub foo(...params...) { ... }'    -- i.e., it has a name and a body
18:27 jonathan You want to have the PIR we generate that does the binding in the Parrot sub itself.
18:27 pmichaud effectivley that's what happens now, yes.
18:27 pmichaud it's just that the code currently binds a lexical first and then typechecks, whereas I think we should create a type-checking container and then bind it to a lexical symbol
18:28 jonathan .signature somehow then needs to be able to return something useful, though. And I fear we're back to building two things.
18:28 pmichaud depends on how much introspection we can put into our blocks
18:28 jonathan Because I don't see how we can get this PIR prologue in the sub to also provide the needed data.
18:28 pmichaud and since we're having to create  Perl6Block  _anyway_
18:29 jonathan We aren't any more though. You didn't like the way I did that, so we ended up just stashing its proto as a propery in the sub...
18:29 pmichaud heh
18:29 pmichaud I didn't like having to have a separate PMC for every type
18:29 jonathan So we don't ever instantiate Perl6Block.
18:29 pmichaud I didn't like the fact that we had to have separate Perl6Sub, Perl6Method, Perl6Block, Perl6Routine, etc.
18:30 pmichaud I don't mind if we have one base class.
18:30 jonathan Yeah, but the Sub vs Closure issues kinda got in the way of that.
18:30 pmichaud oh, I think that'll be fixed anyway -- see my latest posting to parrot-porters
18:30 jonathan So it didn't work on that account either. :-|
18:30 jonathan Ah, OK.
18:31 jonathan Anyway, basically we need to know where we're going with this.
18:31 jonathan I want to dig into MMD, and for that I need the type info available/accessible.
18:31 NotFound I've made a patch with the function to create empty strings and using it in lot of places, RT#56750
18:31 pmichaud yes, which is why I've been thinking about it a lot in the past couple of days.
18:31 jonathan Right. I want that we do it *right*, I'm not trying to throw in some sucky hacked-up solution here.
18:31 pmichaud I agree, I never suspected otherwise.  We both just aren't sure what *right* is.
18:32 jonathan Right.
18:32 Infinoid pun intended? :)
18:32 pmichaud right!
18:32 jonathan In some senses, if instead of digging into the internals of signature, I just define an interface, and use that with the MMD...
18:32 jonathan Then it means we have the ability to refactor signatures anyway until they are right.
18:33 pmichaud "signature" ==>  "signature as parrot sub", you mean?
18:33 jonathan At some point though, when someone calls .signature, we need to return a Signature object.
18:33 pmichaud yes, I agree totally about that.
18:34 pmichaud I'm just curious about how we'll choose to represent it, and how to map signatures to individual variables outside of subroutine calls
18:34 jonathan Well, if i make it so I can call .parameters and get something to iterate over to get the types and parameters, it lets us play with different underlying implementations until we get something that's right, without getting in the way of MMD progress.
18:34 pmichaud because it seems to me that as TimToady said, whatever we do for signatures in invokable blocks we ought to be doing for individual variable constraints as well
18:34 pmichaud and not have separate paths in actions.pm for that
18:35 jonathan Yes.
18:35 pmichaud here's what I propose for now, since I have to get some lunch
18:35 jonathan To me, having <signature> in actions.pm build a signature object, which in turns knows how to bind, seemed like the way to achieve that.
18:35 Ivatar joined #parrot
18:36 pmichaud I'm going to continue to look and think about it (and I'm sure you'll do the same) with the incredible amount of useful information this conversation has brought
18:36 jonathan OK, I need to eat too...getting late her!
18:36 jonathan *here
18:36 pmichaud if I do any playing with refactors at this point, I'll do it in a branch
18:36 pmichaud we can probably discuss it more tomorrow as part of your Rakudo day (assuming I haven't usurped too much of today for it :-)
18:37 jonathan Heh, you've probably made it a late night to get other stuff done that I need to do today. ;-)
18:37 jonathan But it was a useful conversation.
18:37 jonathan And maybe having it today unblocks things a bit more tomorrow.
18:37 pmichaud I totally agree that the separate Signature object has elegance to it, but I'm not comfortable with the way we're currently generating those
18:37 jonathan So it's fine.
18:37 pmichaud I'm thinking you can count half of today as a rakudo day  :-)
18:37 pmichaud certainly asking these questions and thinking about design is as important as writing code
18:37 jonathan Oh, for sure.
18:37 purl like totally!
18:38 jonathan No point writing a bunch of wrong code.
18:38 pmichaud anyway, thanks a bunch for being patient with me on this :-)
18:38 jonathan What specifically about the way it's being generated is worrying you, by the way?
18:39 pmichaud it just feels wrong.  I'm still feeling like it should attach to PAST::Var nodes somehow.
18:39 jonathan Purely the presence of :inline, the use of :immediate...
18:39 jonathan Ah, OK.
18:39 pmichaud :inline and :immediate bug me too, but I'm not sure we can avoid :immediate
18:39 jonathan The signature itself, or the type constraints?
18:39 pmichaud the type constraints.  Perhaps the signature as well.
18:39 jonathan I think not the signature, that's a sub level thing.
18:40 jonathan Or block level, anyway.
18:40 pmichaud well, a signature feels like an array of PAST::Var nodes to me with constraints.  But perhaps I just haven't thought it through.
18:40 jonathan There's a bit more than constraints.
18:40 pmichaud I mean, the PAST::Var nodes already have things like :slurpy, :named, :optional, etc.
18:40 pmichaud :name
18:40 jonathan Like, is one of them the invocant (before :), is it after ;; and so forth so it doesn't participate in MMD...
18:41 pmichaud sure, there are some things above the signature level
18:41 jonathan Plus a signature also has a .of, which is the return type.
18:41 pmichaud sorry, above the parameter level
18:42 jonathan Yeah.
18:42 pmichaud but right now all of it is being processed in method signature, where I think the parameter-specific things belong in method parameter
18:42 pmichaud and whatever <signature> returns ought to be usable for all of the various contexts where it is used
18:42 pmichaud (hopefully without setting a bunch of flags to indicate the context)
18:43 jonathan And if a sub is just going to take a slurpy array and a slurpy hash and invoke a method on a signature object, maybe it can be?
18:44 jonathan Because sub and method just do $( $<signature> ) and emit code to generate that and attach the resulting data structure, in a :immediate sub, to themselves?
18:44 pmichaud well, even if we're doing that I think we can avoid slurpy array/slurpy hash, now that I think about it.
18:45 jonathan OK. But I think the way to go to get the elegance we want, is that <signature> results in something that produces a signautre object.
18:45 jonathan And different declarators (sub, method, my, etc) know what to do with that.
18:46 pmichaud well, <signature> should result in a PAST structure that produces a signature object
18:46 jonathan Yes, sorry, that's what I was thinking/meant.
18:47 pmichaud but for any block declarator, we have to be able to generate the PAST::Var lexical nodes in the block itself
18:47 pmichaud i.e., they can't be in the signature
18:47 pmichaud i.e., they can't be strictly in this :immediate-generated thing that we attach to the .sub
18:48 jonathan OK, but if the way that signature PAST is produced is well defined and in one place (it will be), then we can write something that says "here's some signature PAST, give me a list of variables it references" and then can loop over that and emit the code to generate them.
18:49 jonathan As in, make the PAST::Var nodes.
18:49 pmichaud "give me a list of variables it references"  is probably pretty nasty in PAST
18:49 pmichaud that has an icky smell to me
18:49 jonathan It'd be nicely re-usable for all the things that need it.
18:49 pmichaud sure, but it's also starting to sound like the PAST structure is really the prologue to the sub :-)
18:50 jonathan And it lets us encapsulate knowledge of signatures in the signature actions and this one sub.
18:50 jonathan Yes, but the point is that this won't built a signature object that is useful in every case.
18:50 pmichaud okay.
18:51 pmichaud I'm going to play with a few things here then.
18:51 jonathan Anyway, we're probably going to go round in circles on this now if we don't go eat something first. :-)
18:51 * jonathan is at the point of starting to feel dizzy now!
18:51 pmichaud First, I'm going to see about eliminating :immediate, by giving a way to attach initialization stuff directly to a PAST::Block node
18:51 jonathan OK.
18:51 pmichaud I may or may not end up with a PAST::Signature structure (which may be Perl 6 specific)
18:52 pmichaud that might simplify things a great deal
18:52 jonathan May well do.
18:52 pmichaud since it could contain the lexical definitions, but also generate and attach the Signature stuff
18:53 pmichaud I'll go ahead and see if I can find a clean (to my sense of "clean") way to generate the Signature structures, but we'll leave them as data structure-ish for now.
18:53 jonathan It would probably be neater than what I've tried to do, which is cobble current PAST stuff we do have into the right kinda shape.
18:53 pmichaud It's likely they'll be a form of Capture.
18:53 pmichaud (i.e., a subclass of Capture)
18:53 jonathan That may well work nicely.
18:54 pmichaud well, it has a lot of the same attributes, and especially since Signatures are supposed to bind with Captures :-)
18:54 jonathan Array slots for the parameter descriptors, and a hash slot for "of" and so forth.
18:54 jonathan Or is that not what you were thinking?
18:54 pmichaud possibly.
18:54 jonathan OK
18:54 pmichaud I'll have to think about how I want to get parameter passing in subs working first, the rest should fall out of that.
18:55 pmichaud anyway, I'll let you go eat, and do the same here.  thanks again.
18:55 jonathan Thanks to you too, for putting up with me. :-)
18:55 jonathan dobru chut # nice meal :-)
19:11 AndyA joined #parrot
19:33 rdice joined #parrot
19:34 ruoso joined #parrot
19:49 Theory joined #parrot
19:56 cjfields joined #parrot
20:15 dalek r29208 | julianalbo++ | trunk:
20:15 dalek : [lua] Fixed luatable problem with Hash and clean warnings in other pmc
20:15 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29208
20:33 gryphon joined #parrot
20:38 rdice_ joined #parrot
20:45 dalek r29209 | pmichaud++ | trunk:
20:45 dalek : [rakudo]: spectest-progress update: 94 files, 1677 passing tests
20:46 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29209
20:48 Whiteknight is use.perl.org down?
20:48 particle ping use.perl.org
20:48 purl /sbin/ping returned an error.
20:49 particle ping is down :(
20:49 purl I can't find is in the DNS.
20:49 Whiteknight good, then I'm not crazy
20:49 PerlJam Whiteknight: it's been slow and hit-or-miss for me for the last week or more
20:49 PerlJam maybe we should nudge pudge gently
20:49 Whiteknight darn, I wanted to post a blog update
20:50 Whiteknight to tell the world that, while still broken and unusable, my branch is getting marginally better
20:50 cjfields_ joined #parrot
20:51 particle (marginally less broken and unusable)++
20:51 cjfields_ use.perl.org seems back up (at least for me)
20:53 Whiteknight yeah, i just got int
20:58 dalek r29210 | julianalbo++ | trunk:
20:58 dalek : [lua] Fix the previous fix for c++ compatibility
20:58 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29210
21:14 Theory joined #parrot
21:18 Whiteknight joined #parrot
21:19 dalek r29211 | Whiteknight++ | gsoc_pdd09:
21:19 dalek : [gsoc_pdd09] A few changes and a fudged makefile, and suddenly the build process completes.
21:19 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29211
21:24 moritz Whiteknight++
21:24 Whiteknight no ++ just yet, it's still in terrible shape
21:24 moritz Whiteknight: in your gsoc_pdd09 branch my build continues up to ../../parrot --output=JSON/pge2pir.pbc JSON/pge2pir.pir
21:26 Whiteknight yeah, for some reason, JSON/pge2pir.pir is an empty file at that point
21:26 Whiteknight ...so I edited the makefile to ignore it :)
21:26 sjansen joined #parrot
21:28 moritz I can't even find it in Makefile
21:28 moritz anyway, doesn't matter
21:29 moritz it's just good to know that the segfault that had plagued you for so long isn't the big blocker anymore
21:37 Whiteknight no, i figured out where that was happening with chromatics help
21:37 Whiteknight and I commented out the code until I could find a fix for it :)
21:47 Limbic_Region joined #parrot
21:57 shamu joined #parrot
22:00 Whiteknight Yay! I isolated another segfault
22:01 Whiteknight me++
22:01 cotto_work karma me
22:01 purl cotto_work has neutral karma
22:01 Whiteknight cotto_work++
22:01 cotto_work happy!
22:02 Whiteknight (getting you up to positive numbers)
22:24 pmichaud perl6:  say "cotto_work" ~ "++";
22:24 polyglotbot OUTPUT[cotto_work++␤]
22:24 pmichaud perl6:  say "Whiteknight" ~ "++";
22:24 polyglotbot OUTPUT[Whiteknight++␤]
22:27 dalek r29212 | chromatic++ | gsoc_pdd09:
22:27 dalek : [src] Fixed coding standards.  The only real functional change is that
22:27 dalek : C++-style line comments are now C-style comments, which may help some very
22:27 dalek : picky compilers.
22:27 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29212
22:30 cotto_work perl6: say "ploy"~"glot"~"bot"~"++";
22:30 polyglotbot OUTPUT[ployglotbot++␤]
22:30 cotto_work that's kinda pretty with all those tildes
22:31 gryphon joined #parrot
22:39 rafl joined #parrot
22:39 dalek r29213 | julianalbo++ | trunk:
22:39 dalek : Fix tab in lua.pmc
22:39 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29213
22:42 cotto_work chromatic++ #codingstd fixes
22:42 dalek r29214 | moritz++ | trunk:
22:42 dalek : [pipp] codingstd: trailing whitespace
22:42 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29214
22:44 Theory joined #parrot
22:55 kid51 joined #parrot
23:07 TiMBuS joined #parrot
23:16 ruoso joined #parrot
23:17 jonathan pmichaud: Going to get some sleep soonish. If you want more time to do your refactorings, I can hack on something that ain't signatures etc earlier on in the day...
23:23 Coleoid joined #parrot
23:23 cotto_work where's the proper use of svn properties documented?
23:35 Infinoid cotto_work: grep docs/project/committer_guide.pod for "svn properties setting"
23:35 Infinoid there is also a "Subversion properties" heading in pdd07.
23:37 cotto_work thanks
23:37 bacek_ joined #parrot
23:37 bacek_ joined #parrot
23:39 dalek r29215 | Whiteknight++ | gsoc_pdd09:
23:39 dalek : [gsoc_pdd09] a few small changes denoting my debugging progress:
23:39 dalek : * Adding a "readme" status file to keep track of my progress
23:39 dalek : * Fixed some variable localization in Parrot_dod_trace_root
23:39 dalek : * Removed an assertion that was always wrong (and therefore unhelpful) in pobject_lives
23:39 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29215

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

Parrot | source cross referenced