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

Powered by Cro and the Raku® Programming Language.

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

Thank you!