»ö« | perl6-projects.org/ | nopaste: paste.lisp.org/new/perl6 | evalbot: perl6: say 3;' | irclog: irc.pugscode.org/ | UTF-8 is our friend! Set by moritz_ on 27 June 2009. |
|||
00:01
hercynium joined
00:05
justatheory left
00:16
netfish joined
00:32
avar left,
avar joined
|
|||
dalek | kudo: ee1fd13 | pmichaud++ | src/classes/Multi.pir: Allow .WHAT and other p6object methods on Parrot MultiSub objects (RT #66928). |
00:35 | |
00:38
mizioumt1 left
|
|||
dalek | kudo: 7fdd7c8 | pmichaud++ | build/PARROT_REVISION: Bump PARROT_REVISION so we get some Parrot fixes (RT #66060). |
00:41 | |
00:42
frew_ left,
frew_ joined
00:43
lambdabot left
00:46
lambdabot joined
00:50
Whiteknight left
00:54
cdarroch left
00:55
cls_bsd left,
cls_bsd joined
00:56
orafu joined
01:17
nihiliad joined,
orafu left
01:18
orafu joined
01:28
molaf_x left
01:38
orafu left
01:42
KyleHa joined
01:44
orafu joined
01:45
molaf_x joined
|
|||
pugs_svn | r27345 | kyle++ | [t/spec] Test for RT #66928 | 01:45 | |
01:59
orafu left
02:00
japhb left
02:01
charsbar_ left,
charsbar joined
02:05
orafu joined
02:10
snarkyboojum left
02:14
jhorwitz left
02:16
dukeleto joined
02:19
alester joined
02:21
orafu left,
orafu joined
02:22
szabgab left
02:32
japhb joined
02:33
amoc joined
02:36
last left
02:37
szabgab joined
02:40
athomason left
02:42
orafu left
02:44
szabgab left
02:45
szabgab joined
|
|||
dalek | kudo: 6c6299f | pmichaud++ | src/builtins/globals.pir: Fix %*VM<config> (RT #66818). |
02:45 | |
kudo: 5351a33 | pmichaud++ | build/PARROT_REVISION: Bump PARROT_REVISION to get fix for RT #66840 (ternary error shouldn't exit) |
|||
02:46
Limbic_Region left
02:48
orafu joined
|
|||
pugs_svn | r27346 | kyle++ | [t/spec] unfudge the RT #66840 test since it passes in Rakudo 5351a33 | 02:55 | |
02:56
KyleHa left,
leon joined
03:01
skids left,
leon left
03:02
dukeleto_ joined
|
|||
pugs_svn | r27347 | pmichaud++ | [t/spec]: Unfudge test for unicode method names (now fixed in Parrot). | 03:02 | |
03:03
leon_mu joined,
orafu left
03:04
orafu joined,
orafu left
03:09
orafu joined,
synth left
03:23
orafu left,
orafu joined
03:24
dukeleto left
03:25
orafu left
03:28
orafu joined
03:32
orafu left,
molaf_x left
03:37
dukeleto_ left,
orafu joined
03:46
orafu left
03:52
orafu joined
04:07
orafu left
04:08
orafu joined
04:23
FurnaceBoy left
04:28
orafu left
04:29
orafu joined
04:32
justatheory joined
04:50
orafu left
04:55
orafu joined
05:01
japhb left
05:11
orafu left,
orafu joined
05:13
ihrd joined
05:17
frew_ left
05:18
agentzh left
05:22
finanalyst joined
05:23
dukeleto joined
05:32
orafu left
05:33
orafu joined
05:36
agentzh joined
05:37
netfish left
05:45
alester left
05:49
nihiliad left
05:53
orafu left
05:54
orafu joined
06:05
zamolxes left
06:06
azawawi joined
|
|||
azawawi | good morning | 06:06 | |
06:06
M_o_C joined
|
|||
pugs_svn | r27348 | kyle++ | [t/spec] fix the plan I broke in what.t | 06:08 | |
Matt-W | morning azawawi | ||
eternaleye | Hi azawawi, Matt-W | 06:09 | |
moritz_ | good morning | ||
Matt-W wants to know how to move an operator into the setting | |||
eternaleye | oh hai, moritz_ | ||
Matt-W: Just define it in the setting, remove it from the PIR, and spectest! | 06:10 | ||
Matt-W | eternaleye: it causes a null pmc access :( | ||
moritz_ | ... in find_method? | ||
eternaleye | Well, that's _never_ right | ||
moritz_ | which operator? | ||
Matt-W | moritz_: yes. I was trying to do infix:<leg> | ||
eternaleye | I was just thinking, we're going to need to be careful defining operators in terms of other operators, because we might get an infinite recursion going. | 06:11 | |
moritz_ | Matt-W: you also have to remove it from build/gen_junction_pir.pl | ||
Matt-W | ah | ||
Matt-W tries that | 06:14 | ||
06:14
synth joined
|
|||
Matt-W | ah that's better :) | 06:14 | |
06:15
mvuets joined,
orafu left
|
|||
Matt-W | just have to wait for spectest now | 06:15 | |
eternaleye | rakudo: my @seed = 2, 3; .say for @seed ... -> *@prev { state $c = 0; return () if $c > 100; my $cur = @prev[*-1]; while ++$cur { return $cur unless $cur % any( @prev ) == 0 }; }; | ||
p6eval | rakudo 5351a3: OUTPUT«5» | ||
eternaleye | rakudo: my @seed = 2, 3; .say for @seed ... -> *@prev { state $c = 0; return () if $c > 100; my $cur = @prev[*-1]; while ++$cur { last unless $cur % any( @prev ) == 0 }; $cur }; | 06:16 | |
p6eval | rakudo 5351a3: ( no output ) | ||
eternaleye | rakudo: my @seed = 2, 3; .say for @seed ... -> *@prev { state $c = 0; return () if $c > 100; my $cur = @prev[*-1]; while ++$cur { take $cur unless $cur % any( @prev ) == 0 }; }; | ||
p6eval | rakudo 5351a3: OUTPUT«Diedin sub infix:... (/tmp/mAFnftJ9B8:2)called from Main (/tmp/mAFnftJ9B8:2)» | ||
eternaleye | In any case, the first one appears wrong - it looks like it's returning from infix:<...> | 06:17 | |
Do we need to do a wrapping sub around $generator, so that it DWIMs | |||
? | |||
When I define the generator as a sub, and then use &nextprime in infix:<...>, it works | 06:18 | ||
rakudo: sub nextprime( *@prev ) { state $c = 0; return () if $c > 100; my $cur = @prev[*-1]; while ++$cur { return $cur unless $cur % any( @prev ) == 0 }; }; my @seed = 2, 3; .say for @seed ... &nexprime; | 06:19 | ||
06:19
leon_mu left
|
|||
moritz_ | return() is specced to exit a routine, not a block | 06:19 | |
p6eval | rakudo 5351a3: OUTPUT«No applicable candidates found to dispatch to for 'infix:...'in Main (/tmp/lsLy8NUC4i:2)» | ||
eternaleye | Hmm | ||
moritz_ | you'd need leave() to leave the block, but I don't think it's implemented yet | ||
rakudo: say { leave 3 } | 06:20 | ||
p6eval | rakudo 5351a3: OUTPUT«_block49» | ||
moritz_ | rakudo: say { leave 3 }.() | ||
p6eval | rakudo 5351a3: OUTPUT«Could not find non-existent sub leave» | ||
eternaleye | Ah | ||
06:20
rfordinal left,
orafu joined
06:21
rfordinal joined
|
|||
eternaleye | rakudo: my @seed = 2, 3; .say for @seed ... -> *@prev { state $c = 0; my $cur = @prev[*-1]; while ++$cur { break unless $cur % any( @prev ) == 0 }; $c > 100 ?? () !! $cur }; | 06:21 | |
p6eval | rakudo 5351a3: OUTPUT«Diedin sub infix:... (/tmp/LEbFssDoqU:2)called from Main (/tmp/LEbFssDoqU:2)» | ||
eternaleye | rakudo: my @seed = 2, 3; .say for @seed ... -> *@prev { state $c = 0; my $cur = @prev[*-1]; while ++$cur { last unless $cur % any( @prev ) == 0 }; $c > 100 ?? () !! $cur }; | ||
p6eval | rakudo 5351a3: ( no output ) | 06:22 | |
eternaleye | Hm | ||
Loop control is apparently NYI | |||
moritz_ | what do you mean by loop control? | 06:23 | |
last should work | 06:24 | ||
eternaleye | rakudo: sub nextprime( *@prev ) {{ state $c = 0; return () if $c > 100; my $cur = @prev[*-1]; while ++$cur { return $cur unless $cur % any( @prev ) == 0 }; }; my @seed = 2, 3; .say for @seed ... &nextprime; | ||
p6eval | rakudo 5351a3: OUTPUT«Unable to parse block; couldn't find final '}' at line 2, near ""in Main (src/gen_setting.pm:3279)» | ||
eternaleye | rakudo: sub nextprime( *@prev ) { state $c = 0; return () if $c > 100; my $cur = @prev[*-1]; while ++$cur { return $cur unless $cur % any( @prev ) == 0 }; }; my @seed = 2, 3; .say for @seed ... &nextprime; | ||
p6eval | rakudo 5351a3: ( no output ) | ||
eternaleye | moritz_: last doesn't seem to work, since it loops forever on that one. If I put a say in there, it just repeats | ||
It should give a 5, a 7, etc | |||
rakudo: my @seed = 2, 3; .say for @seed ... -> *@prev { state $c = 0; my $cur = @prev[*-1]; while ++$cur { last unless $cur % any( @prev ) == 0; say "hi" }; $c > 100 ?? () !! $cur }; | 06:25 | ||
p6eval | rakudo 5351a3: | ||
..OUTPUT«hihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihixE2 | |||
moritz_ still too tired to actually *look* at the code | |||
eternaleye | or maybe... | ||
rakudo: my @seed = 2, 3; .say for @seed ... -> *@prev { state $c = 0; my $cur = @prev[*-1]; while ++$cur { last unless $cur % any( @prev ) == 0; say "hi" }; $c > 5 ?? () !! $cur }; | |||
p6eval | rakudo 5351a3: | ||
..OUTPUT«hihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihihixE2 | |||
eternaleye | Nope, that is what's happening | 06:26 | |
Also, does that look like a NL symbol to everyone else? Since it looks like lower-a, circumflex acce,t, space, Euro sign here | |||
moritz_ | it looks broken here too | 06:27 | |
rakudo: say 'ö' | |||
p6eval | rakudo 5351a3: OUTPUT«ö» | ||
eternaleye | _weird_ | ||
moritz_ | hm, that looks fine | ||
eternaleye | Bug? | 06:28 | |
Running in local rakudo | |||
moritz_ | it loooks OK on the IRC logs, though | ||
Matt-W | woohoo | ||
my operator passed its part of the spectest | |||
what's the preferred way to submit a patch? | |||
moritz_ | eternaleye: ah, I know why... the last NL character got trunkated, so our IRC client's autodetection thought "that's not valid UTF-8" and went beserk. | 06:29 | |
Matt-W: [email@hidden.address] | |||
Matt-W | moritz_: yes but how to make the patch | ||
eternaleye | Ah | ||
Matt-W | moritz_: unfamiliar with git for this | ||
eternaleye | Matt-W: git format-patch --stdout 'HEAD^' | 06:30 | |
and nopaste/rakudobug/email/etc it | |||
Or remove the --stdout and it'll make a file | |||
I like the --stdout, so I can pipe it to wgetpaste | 06:31 | ||
moritz_ | Matt-W: first commit it (git commit -a) | ||
Matt-W: then git-format-patch HEAD^ | |||
Matt-W: and attach the generated file | |||
Matt-W sends | 06:34 | ||
and just in time to go to work too | |||
I'll be back later | |||
Matt-W -> commuting & | |||
06:36
orafu left
06:37
orafu joined,
orafu left
06:39
rfordinal left
06:42
orafu joined
06:44
DemoFreak joined
06:54
azawawi left
06:57
orafu left,
orafu joined
06:59
rfordinal joined
07:02
spinclad joined
07:05
japhb joined
07:18
orafu left
07:19
meppl joined
07:20
orafu joined
07:23
ejs joined
07:26
mkindahl joined
|
|||
moritz_ | rakudo: say 'a' cmp 'b' | 07:27 | |
p6eval | rakudo 5351a3: OUTPUT«-1» | 07:28 | |
moritz_ | rakudo: say 'b' cmp 'b' | ||
p6eval | rakudo 5351a3: OUTPUT«0» | ||
moritz_ | rakudo: say 'c' cmp 'b' | ||
p6eval | rakudo 5351a3: OUTPUT«1» | ||
07:33
ejs1 joined
07:35
iblechbot joined
07:40
orafu left,
ejs left
07:41
orafu joined
|
|||
moritz_ | I just found out that mathematica has something similar to our [\...] meta operatr (called FoldList) | 07:42 | |
Matt-W back | 07:44 | ||
moritz_: o rly? | 07:46 | ||
list folds are generally very useful things | |||
07:48
mepplock joined
08:01
eMaX joined,
orafu left
08:02
orafu joined,
meppl left
08:19
rfordinal left
08:20
rfordinal joined
08:22
orafu left
08:23
orafu joined
08:24
last joined
08:25
sri_kraih joined
|
|||
moritz_ | I first searched for reduce in the mathematica docs, but that does something entirely different :-) | 08:27 | |
08:37
PacoLinux left
08:39
rfordinal left
|
|||
jnthn | morning | 08:41 | |
pmichaud++ # blogging | 08:43 | ||
moritz_ | indeed. | ||
08:43
orafu left
08:44
orafu joined,
orafu left
08:45
solarion left,
Chillance joined,
solarion joined
|
|||
Matt-W | moritz_: what we call reduce feels a lot like what they call a fold in Haskell | 08:45 | |
08:47
last left
08:49
rfordinal joined
08:50
pmurias joined
08:57
m-i-l-a-n left
08:59
m-i-l-a-n joined
09:00
orafu joined
09:04
m-i-l-a-n left
09:05
orafu left
09:06
orafu joined
|
|||
moritz_ | I know | 09:07 | |
09:08
m-i-l-a-n joined
09:09
Chillance left
09:12
ihrd left
|
|||
moritz_ | Matt-W: I just replied to your patch. There's nothing wrong with this particular move, I'm just wandering of the overall design of that operator is sound | 09:13 | |
09:14
m-i-l-a-n left,
mikehh joined
09:15
m-i-l-a-n joined
09:21
m-i-l-a-n left
09:22
m-i-l-a-n joined
09:26
orafu left
09:28
m-i-l-a-n left
09:29
m-i-l-a-n joined
09:35
m-i-l-a-n left,
orafu joined
09:36
m-i-l-a-n joined
09:40
orafu left
09:42
rfordinal left
09:50
synth left
10:15
cognominal left
10:18
payload joined
10:27
Muixirt joined
10:35
cognominal joined
10:44
masak joined
|
|||
masak | IO.eof is gone? | 10:53 | |
I do wish people would discuss these things a bit before attacking the spec... :/ | 10:54 | ||
jnthn | masak: I'm not sure it's gone as such, perhaps just gone missing. ;-) | ||
masak | to me, IO::Endable is perilously close to abstraction astronautism. | ||
just give me the IO.end and be done with it. | 10:55 | ||
no need for a whole interface for it. | |||
jnthn | (e.g. it was meant to be defined in IO::Endable, but somehow forgot) | ||
masak mutters into his beard | |||
jnthn | Yeah, it feels a bit...overkill. | ||
10:56
payload left
|
|||
masak | also, I think ruoso++ had an argument about why that kind of role (including IO::Readable) doesn't work in practice. | 10:56 | |
10:58
mjk joined
11:00
jlaire joined
|
|||
pugs_svn | r27349 | kyle++ | [t/spec] Fix a .WHAT test after review from jnthn++ | 11:03 | |
11:05
mjk left,
tarball joined
11:06
mikehh left
11:12
tarball left
|
|||
masak | rakudo: my @a := (1,2,3,4); say @a.WHAT | 11:14 | |
p6eval | rakudo 5351a3: OUTPUT«List()» | ||
masak | so far, so good. @a is bound to a List. I agree. | ||
rakudo: my @a := (1,2,3,4); @a.push(4); say @a.perl; say @a.WHAT | |||
p6eval | rakudo 5351a3: OUTPUT«[1, 2, 3, 4, 4]List()» | ||
masak | but this puzzles me. | ||
aren't Lists immutable? | |||
moritz_ | that's a rakudobug (known) | 11:15 | |
masak | oh. | ||
jnthn | I think that's one of the things pm's rw work is meant to solve. | ||
masak | ah. | ||
11:23
mikehh joined
11:25
pmurias left
11:27
last joined
11:28
stepnem left
11:32
rfordinal joined
11:37
stepnem joined,
stepnem left
11:38
eMaX left
11:45
stepnem joined
|
|||
dalek | ok: b1e7f47 | (Hinrik Örn Sigurðsson)++ | (6 files): Support xhtml output |
12:10 | |
ok: 86f0183 | (Hinrik Örn Sigurðsson)++ | lib/App/Grok/Pod (2 files): Forgot to bump these version numbers earlier |
|||
literal | @tell azawawi preliminary support for xhtml output: nix.is/grok-0.07_01.tar.gz | ||
lambdabot | Consider it noted. | ||
masak | nice! literal++ | 12:11 | |
literal | rakudo: say $?GRAMMAR | 12:12 | |
lambdabot | literal: You have 1 new message. '/msg lambdabot @messages' to read it. | ||
p6eval | rakudo 5351a3: OUTPUT«Symbol '$?GRAMMAR' not predeclared in <anonymous> (/tmp/f6Iuf7KPUx:2)in Main (src/gen_setting.pm:3279)» | ||
12:12
MrKrueger joined
12:27
mepplock left
|
|||
masak | rakudo: say '_' ~~ <alpha> | 12:29 | |
p6eval | rakudo 5351a3: OUTPUT«0» | ||
12:40
ruoso joined
|
|||
Matt-W | moritz_: Well argue that with the spec - I checked, and it just says it's defined in terms of ~$a cmp ~$b | 12:41 | |
moritz_: You may in fact be right about which way round things should be. | 12:42 | ||
ruoso | Bom dia, #perl6 | 12:43 | |
Matt-W | (trust me to pick an operator that causes a debate...) | ||
pmichaud | good morning, #perl6 | ||
Matt-W | hi ruoso, pmichaud | ||
jnthn | hi, pmichaud | 12:44 | |
pmichaud: Nice fixing and blogging! | |||
pmichaud | jnthn: thanks, you too :-) | 12:45 | |
12:45
pmurias joined
|
|||
pmurias | hi | 12:45 | |
Matt-W | between the two of you things are looking a mite shinier today :) | ||
12:47
stepnem left,
mizioumt joined
|
|||
literal | rakudo: say '_' ~~ /<alpha>/ | 12:50 | |
p6eval | rakudo 5351a3: OUTPUT«_» | ||
masak | oh, right. | ||
silly me. | |||
12:50
skids joined
12:51
synth joined
|
|||
pmurias | ruoso: do we have a long term smop plan/ROADMAP? | 12:52 | |
jnthn | Implement Perl 6. :-) | 12:53 | |
ruoso | heh... jnthn++ | ||
but seriously... that's the plan... I mean | |||
once we have multi and module loading working | |||
pugs_svn | r27350 | pmurias++ | [re-smop] correct indentation | ||
r27351 | pmurias++ | [re-mildew] fix if bug | |||
ruoso | we can start working on Perl 6 features | ||
pmurias | and when's the bootstrap point? | 12:54 | |
ruoso | well, there's the type system bootstrap | ||
that should happen soon after we have module loading | |||
but then there's a long way before we implement a grammar engine in SMOP | |||
12:55
Chillance joined
|
|||
ruoso | and then this grammar engine will have to be able to run STD | 12:55 | |
12:55
Molaf left
|
|||
ruoso | and we must be able to parse STD using that grammar engine | 12:56 | |
and, finally, have this grammar engine being used to compile STD to SMOP | |||
and that's the real bootstrap | |||
pmurias | a partial bootstrap would be to have mildew in Perl 6 and using the STD compiled down to perl5 | 12:57 | |
masak | rakudo: / <[\x10000..\xEFFFF]> /; say "alive" | ||
p6eval | rakudo 5351a3: ( no output ) | ||
masak | pmichaud: is this a known issue? | ||
pmurias | perl6: say [].true | ||
masak | pmurias: locally, I had a bus error. | ||
p6eval | elf 27351, rakudo 5351a3: OUTPUT«1» | ||
..pugs: OUTPUT«» | |||
masak | pmurias: oops, mistab. | 12:58 | |
pmichaud | masak: not known issue | ||
masak submits rakudobug | |||
pmichaud | I'm guessing parrotbug :-) | ||
masak | PGE-bug, possibly. | ||
ruoso | pmurias, even before that, just having all the Perl 6 type system written in Perl 6 is a very important milestone | ||
12:58
cls_bsd left
|
|||
masak | pmichaud: note that it hangs during execution, not during compilation. | 12:58 | |
pmichaud | rakudo: / <[\x100..\xEFF]> /; say "alive" | 12:59 | |
p6eval | rakudo 5351a3: OUTPUT«alive» | ||
pmichaud | PGE gets that one right. | ||
masak | and the hex numbers have to be high enough for it to trigger. | ||
pmichaud | right | ||
I suspect that Parrot strings are having difficulty with it. | |||
pmurias | ruoso: type system meaning ClassHOW,RoleHOW etc? | ||
ruoso | pmurias, and all the built-in types | 13:00 | |
pmichaud | rakudo: say 0xeffff; | ||
p6eval | rakudo 5351a3: OUTPUT«983039» | ||
pmichaud | oh, the problem could also be that Parrot doesn't like creating a 920+K string. | 13:01 | |
rakudo: say 0xeffff-0x10000; | |||
p6eval | rakudo 5351a3: OUTPUT«917503» | ||
pmurias | 14:59 <@pmichaud> I suspect that Parrot strings are having difficulty with it. | 13:04 | |
14:59 < pmurias> ruoso: type system meaning ClassHOW,RoleHOW etc? | |||
15:00 < ruoso> pmurias, and all the built-in types | |||
15:00 <@pmichaud> rakudo: say 0xeffff; | |||
ruoso | pmurias, I guess you have an issue with yuor touchpad | 13:05 | |
masak | rakudo: say "foo" ~~ /<[f] #[comment] + [o]>/ | 13:08 | |
p6eval | rakudo 5351a3: OUTPUT«perl6regex parse error: Error parsing enumerated character class at offset 30, found '['in Main (src/gen_setting.pm:3279)» | ||
masak | pmichaud: I posit that this should work. | ||
pmichaud | pge doesn't understand embedded comments. | 13:09 | |
masak | it does outside of <>. | ||
pmichaud | right | ||
masak | rakudo: say "foo" ~~ / fo #[ comment here! ] o / | ||
p6eval | rakudo 5351a3: OUTPUT«foo» | ||
pmichaud | huh. | ||
well, it's very likely that the part that parses <[ ... ]> doesn't understand them then. | 13:10 | ||
std: /<[f] #[comment] + [o]>/ | |||
p6eval | std 27351: OUTPUT«ok 00:03 36m» | ||
masak submits rakudobug | 13:11 | ||
13:12
iblechbot left
13:13
mizioumt1 joined
13:18
KyleHa joined
13:19
stepnem joined
|
|||
masak | rakudo: module M; grammar G {}; say "foo" ~~ /<M::G>/ | 13:20 | |
p6eval | rakudo 5351a3: OUTPUT«Null PMC access in set_attr_str()in regex M::_block62 (/tmp/9t1CmrXEZb:2)called from Main (/tmp/9t1CmrXEZb:2)» | ||
masak | I know that's not the way to match against a grammar, but -- look, a Null PMC access! | ||
masak submits a rakuodbug | |||
13:22
mj41 left,
mj41 joined
|
|||
PerlJam | why is that not a way to match against a grammar? | 13:22 | |
13:24
pmurias left
|
|||
masak | PerlJam: because what goes into the <> is regexes and the like. not types. | 13:24 | |
PerlJam: it's deceptively easy to try and do something like that, though. | |||
PerlJam | oh. Indeed. I apparently did a mental substitution of s/grammar/rule/ s/module/grammar/ | 13:25 | |
masak | that's part of why it's easy, I guess. | 13:26 | |
Matt-W | Must remember that grammars are just funny classes | ||
it's almost like 'grammar G' is sugar for 'class G is Grammar' | 13:27 | ||
13:27
clintongormley joined
|
|||
masak | I haven't found that rule of thumb to help me yet. :) | 13:27 | |
13:27
frew_ joined,
mizioumt left
|
|||
masak | at least not more than "a grammar is just a funny module". | 13:27 | |
Matt-W | masak: I don't usually think about it, I've just got the 'use the .parse method' thing in my head | ||
masak | aye. | 13:28 | |
moritz_ | but that doesn't work if you want to handle control to another grammar | ||
from within a grammar | |||
masak | g'ah, the error reporting sucks! | 13:29 | |
moritz_ | like rule link { '<a' 'href=' <URI::Gramamr::Call> ... } | ||
masak | does anyone want to help me diagnose a problem? | ||
masak tickles himself with the "don't ask to ask" feather | 13:30 | ||
hold on, I'll just push the latest commits | |||
there. if someone would clone grampa, run 'make test' and tell me whence the 'Null PMC access in find_method()' comes... | 13:32 | ||
13:34
mikehh left
13:36
Sark23 left,
stepnem left
|
|||
masak | ah, found it. nvm. | 13:37 | |
moritz_ | so what was it? | 13:38 | |
masak | rakudo: module A; grammar G {}; say ?G.parse("foo") | ||
p6eval | rakudo 5351a3: OUTPUT«Null PMC access in find_method()in Main (/tmp/jx8uygHmjM:2)» | ||
masak | rakudo: module A; grammar G {}; say ?A::G.parse("foo") | ||
p6eval | rakudo 5351a3: OUTPUT«The grammar has no TOP rule to invoke.in Main (/tmp/hezoJQJVrc:2)» | ||
13:38
stepnem joined
|
|||
masak | I don't know, but I have a feeling that one's reported. | 13:40 | |
still very hard to track down. I realised that was it when I had completely disables the whole grammar and the problem still remained. | 13:41 | ||
pmichaud | it's the general "we don't know how to handle nested namespaces" issue. | ||
masak | aye. | ||
pugs_svn | r27352 | kyle++ | [t/spec] Mark where RT #60992 is tested. | 13:42 | |
Matt-W | Hmm | 13:44 | |
Sounds like that one needs a fix | |||
pmichaud: thanks for commenting on my patch | |||
pmichaud | Matt-W: you're welcome -- thanks for the patch. | ||
Matt-W | I just poked around until I found an operator that looked nice and simple | 13:45 | |
pmichaud | You picked a good one. :-) | ||
There are some others lying about. | |||
Matt-W | Yeah I only had time for the one | ||
13:45
PacoLinux joined
|
|||
pmichaud | From a performance perspective, it might be worthwhile to also write a infix:<leg>(Str $a, Str $b) { ... } variant. | 13:46 | |
Matt-W | Mmm good point | ||
would save two calls to prefix:<~>(Str) | |||
pmichaud | but we can/should probably wait until we have a way to measure the performance :-) | ||
Matt-W | (in the str case) | ||
yes :) | |||
or perhaps until there aren't various other crippling performance issues :) | 13:47 | ||
13:48
krakan left,
PacoLinux left
|
|||
masak | I keep forgetting that the '?' quantifier creates Arrays in the Match tree... | 13:52 | |
jnthn | masak: Took me a while to remember that one too. :-) | ||
pmichaud | yes, I've had that trouble also. Especially since in an earlier draft of the spec the ? quantifier *didn't* create arrays. :-) | ||
masak | oh, so it was added? | 13:54 | |
would be interesting to hear the rationale for that. | |||
it doesn't feel immediately obvious that it should. | |||
pmichaud | "all quantifiers produce arrays" | ||
masak | ok, so consistency. | ||
pmichaud | right. | ||
also so that ? remains the same as ** 0..1 | |||
masak | oh, that's a nice reason. | 13:55 | |
pmichaud | previously ? was the exception to the rule... and I think the desire was to eliminate exceptions. | ||
Matt-W | it makes a nice consistency | ||
? not matching just gives you an empty array | |||
which suits me | |||
although I thought the whole capture thing was broken last night... turned out I'd made a stupid one-character mistake | 13:56 | ||
13:56
frew left
|
|||
Matt-W | no matter how cool Perl 6 is, it's not going to protect us from those | 13:56 | |
masak | no, but clueful error messages go a long way. | 13:57 | |
13:59
cls_bsd joined
|
|||
Matt-W | well my mistake was syntactically valid... | 13:59 | |
I was just ending up with an undefined value | |||
which should not have been undefined | |||
I thought it wasn't capturing properly | 14:00 | ||
but of course it was | |||
noooo | |||
$colleague over there *points* is eating an ice cream! | |||
14:01
frew joined
14:03
frew_ left
|
|||
masak | Matt-W: ice cream is overrated. it's just frozen sugar. | 14:04 | |
jnthn | Frozen flavorings too! | ||
14:10
mkindahl left
|
|||
Matt-W | and frozen cream! | 14:15 | |
14:16
dalek left
14:17
dalek joined
14:18
payload joined,
rfordinal left,
rfordinal joined
14:21
Lorn left
14:29
PacoLinux joined
|
|||
masak | Rakudo still returns 0 when it finds a syntax error. :/ | 14:29 | |
that way, running 'make test' proceeds to the tests even when the build fails. | 14:31 | ||
14:33
mkindahl joined
|
|||
masak | ooh, I found another one! | 14:33 | |
rakudo: regex foo { foo }; "foofoofoo" ~~ /<foo>+/; bar($<foo>); sub bar(@foos) {} | |||
p6eval | rakudo 5351a3: OUTPUT«Parameter type check failed; expected Positional, but got List for @foos in call to barin sub bar (/tmp/FtrwyZv3La:2)called from Main (/tmp/FtrwyZv3La:2)» | ||
masak | jnthn: how does that happen? | ||
masak submits rakudobug | 14:34 | ||
jnthn | Probably to do with the way Match objects are made perhaps | 14:37 | |
14:37
rfordinal left
|
|||
pmichaud | I'm guessing that ResizablePMCArray doesn't ~~ Positional | 14:37 | |
jnthn | rakudo: regex foo { foo }; "foofoofoo" ~~ /<foo>+/; say $<foo>.PARROT | ||
p6eval | rakudo 5351a3: OUTPUT«ResizablePMCArray» | ||
jnthn | Right. | ||
pmichaud | That's likely to be an issue. | ||
moritz_ | rakudo: my @a = 3, 4; say @a.PARROT | 14:38 | |
masak | it is an issue. | ||
p6eval | rakudo 5351a3: OUTPUT«Perl6Array» | ||
jnthn | Not sure quite what we can do about it off hand. | ||
moritz_ | can't you just invoke some magic that type-maps RPA to Perl6Array? | ||
pmichaud | moritz_: not easily. | ||
masak | more workaroundly, what's the easiest way to convert the former to the latter? | ||
buubot | masak: Sorry, no more output | ||
pmichaud | but in the larger sense, we need for non-Rakudo arrays to still be treated as Positional | ||
masak | buubot: shush! | 14:39 | |
buubot | Couldn't match input. | ||
moritz_ is about to kick buubot | |||
pmichaud | i.e., if we're ever to get language interop to work. | ||
jnthn | Probably need to as a fall-back check if it provides array from a Parrot POV too. | ||
pmichaud | I'd be fine with adjusting Positional.ACCEPTS to check "does array" | ||
jnthn | Me too, if that was actually easy to do. | 14:40 | |
pmichaud | it's not? | ||
masak | ah. .list worked. | ||
jnthn | Not until we have a decent way to provide a non-punning ACCEPTS on a role or something. | 14:41 | |
I (and afaict the spec) are a bit hazy on that area. | 14:42 | ||
pmichaud | how does Positional.ACCEPTS work now? | ||
jnthn | It's just Perl6Role::ACCEPTS | 14:43 | |
Positional is an instance of Perl6Role | |||
pmichaud | and we can't override ACCEPTS ? | ||
jnthn | Not without mixing another ACCEPTS into Positional, but not sure what else that would do as a side-effect. | 14:44 | |
pmichaud | okay. | 14:45 | |
jnthn | Though this is all tied into "how we do define non-punned methods on a role separate from punned ones?" | ||
pmichaud | I don't understand "non-punned" versus "punned" in this context. | ||
jnthn | And I've not seen an answer to that yet. | ||
role Foo { }; Foo.new # puns | |||
Foo.ACCEPTS($thingy) # can't pun | 14:46 | ||
At the moment, the dispatcher just has a "magic list" | |||
But that's almost certainly not the Right Answer. | |||
I just don't know what the right answer is. | |||
pmichaud | Oh. Do the :U, :D, etc modifiers have anything to do with that? | ||
or is that totally separate? | |||
jnthn | Possibly. | ||
Matt-W | hmm, a magic list sounds bad | 14:47 | |
jnthn | We could maybe make them mean that in the role invocant case. | ||
14:47
kidd_ joined
|
|||
jnthn | Would need to think some more on how sane that is. | 14:47 | |
Matt-W | In my head, it's all simple | 14:48 | |
Until I remember that PGE is a Parrot thing, and is going to speak Parrot types that don't know about things like ACCEPTS | |||
14:49
m-i-l-a-n left
|
|||
pmichaud | well, I may be able to get PGE to do some sort of type mapping, but specifying that mapping is a bit of a pain atm. | 14:49 | |
masak | interoperability theory is so much easier than interoperability practice. | ||
Matt-W | interoperability is easy the moment you try something more complicated than making something interoperate with itself | ||
*until the | |||
14:50
m-i-l-a-n joined
14:51
payload left
|
|||
Matt-W | Does this also have impact on things like getting objects back from, say, a Ruby module? | 14:52 | |
Or is that a different problem | |||
pmichaud | same problem. | ||
Matt-W | well that's something at least | ||
only have to solve it once... | |||
14:53
finanalyst left
|
|||
Matt-W | seems easy to say oh let's have some sort of mapping so that we know that RubyList and ResizablePMCArray do Positional, but I guess that could get big and fragile | 14:53 | |
pmichaud | jnthn: why is it the method that does the punning? | 14:54 | |
jnthn | pmichaud: I don't get the question. | ||
pmichaud: ah | |||
pmichaud | I would think it's vivification that forces punning. | ||
jnthn | pmichaud: It's the dispatcher that realizes you're calling a method on a role and decides "ah, we need to pun" | ||
vivification? | 14:55 | ||
pmichaud | well, Foo.new # vivifies, thus puns | ||
jnthn is confused | |||
pmichaud | Foo.bar # may not involve vivification, so no punning | ||
jnthn | Define vivifies. | ||
Oh | |||
pmichaud | S12: When the typename happens to be a role, autovivifying it involves | ||
attempting to create a punned class of the same name as the role. | |||
jnthn | Isn't that from the section on auto-vivifying protos, which we don't do yet anyway? | 14:56 | |
pmichaud | autovivifying objects, yes. | ||
Matt-W | how does it know the difference between .new and .bar? | ||
pmichaud | but that's the only place where I see any mention of role punning atm. | 14:57 | |
jnthn | Matt-W: There isn't one. | ||
pmichaud | Matt-W: presumably the difference would come about when .new attempts to do a CREATE | ||
14:57
justatheory left
|
|||
Matt-W | pmichaud: So the magic might actually be in CREATE then | 14:57 | |
pmichaud | Matt-W: right. | 14:58 | |
masak | how do I get all the named captures of a Match object? | ||
pmichaud | %/.hash | ||
%/.hash.kv # maybe | |||
masak | thanks. | ||
yes, that worked. I was trying .keys, but needed .hash.keys. | |||
pmichaud | it's not clear to me what .keys on $/ should produce. | 14:59 | |
moritz_ | I think it was decreed that it should die with a friendly message | ||
pmichaud | while we can do that, I'm curious then about: | ||
<a b c d>.keys | 15:00 | ||
moritz_ | (although I voted for a combined list of .list.keys, .hash.keys) | ||
masak | pmichaud: (0,1,2,3), no? | ||
pmichaud | masak: yes. But <a b c d> is just a capture, and a Match object is a capture, so.... | ||
Matt-W | Hmm. I thought .keys only had meaning on something which actually has keys | 15:01 | |
i.e. a Hash | |||
pmichaud | Matt-W: lists have keys also | ||
moritz_ | pmichaud: stop digging up problems, and solve them instead ;-)) | ||
masak | pmichaud: maybe die only in the Match case? though I wouldn't mind .keys being the same as .hash.keys for a Match. | ||
pmichaud++ # problem wrangler | 15:02 | ||
pmichaud | masak: I can make it die in the Match case, yes. | ||
Matt-W | pmichaud: they do?? | ||
pmichaud | masak: but should we then do the same for .kv, .values, .pairs, etc? | ||
masak | s'pose so. | ||
pmichaud | Matt-W: say <a b c d>.kv.perl; | ||
rakudo: say <a b c d>.kv.perl; | |||
p6eval | rakudo 5351a3: OUTPUT«[0, "a", 1, "b", 2, "c", 3, "d"]» | ||
pmichaud | rakudo: say <a b c d>.pairs.perl; | ||
moritz_ | please don't act on my possibly mis-rememebered answer | ||
p6eval | rakudo 5351a3: OUTPUT«[0 => "a", 1 => "b", 2 => "c", 3 => "d"]» | ||
pmichaud | rakudo: say <a b c d>.keys.perl; | 15:03 | |
p6eval | rakudo 5351a3: OUTPUT«[0, 1, 2, 3]» | ||
Matt-W | ooh | ||
okay | |||
that makes sense | |||
thanks pmichaud | |||
masak | pmichaud: right now it takes the patience of a saint to extract information out of Match trees. it's a really powerful tool, but it's far too easy to use it wrongly right now. | ||
pmichaud | masak: suggestions for things that would help? | 15:04 | |
masak | pmichaud: $<a><b> not dying when $<a> isn't defined. | ||
pmichaud | rakudo: my %h; say %h<a><b> | 15:05 | |
p6eval | rakudo 5351a3: OUTPUT«Method 'postcircumfix:{ }' not found for invocant of class 'Failure'» | ||
KyleHa | Where would be a good place for a test for this bug: rt.perl.org/rt3/Ticket/Display.html?id=67124 | ||
pmichaud | masak: I can fix that when I get containers cleaned up a bit. | ||
masak | \o/ | ||
pmichaud: right now, the if statements have to fill up with workaroundish circumscriptions due to that flaw. | 15:06 | ||
pmichaud | masak: okay, I'll prioritize that a bit. | ||
moritz_ | KyleHa: t/spec/S05-metasyntax/charset.t | ||
masak | yay | ||
KyleHa | moritz_: Thank you! | ||
15:08
rfordinal joined
|
|||
pmichaud | need lunch.... bbiaw | 15:09 | |
15:09
jaldhar joined
|
|||
dalek | kudo: 2dded8e | pmichaud++ | docs/spectest-progress.csv: spectest-progress.csv update: 412 files, 11592 passing, 52 failing S04-declarations/my.rakudo aborted 47 test(s) S12-enums/basic.rakudo 27 - short name of the enum without parenthesis is an enum S32-num/rand.rakudo aborted 4 test(s) |
15:12 | |
15:12
nihiliad joined
|
|||
masak | ok, Grampa now does something useful. it can now search for things like '//foo/bar', which puts it in an advantage versus just treating the Match tree directly. | 15:14 | |
so if you ever need to recurse through a tree of Matches, Grampa's the thing. | |||
pugs_svn | r27353 | kyle++ | [t/spec] Test for RT #67124 | 15:15 | |
15:16
exodist joined,
exodist left
|
|||
jnthn | grampa? | 15:17 | |
jnthn can't keep track of all the Perl 6 projects :-) | 15:18 | ||
masak | jnthn: it's easy, they're all listed in proto's projects.list :) | ||
jnthn: Grampa traverses Match trees with XPath expressions. | |||
since XPath is so darn useful in other places too, we'll likely make the core XPath engine pluggable. | 15:20 | ||
but DOM maps pretty nicely over Match trees, actually. | 15:21 | ||
15:22
mvuets left
|
|||
masak | the <from to Str> things can be mapped to DOM attributes, for example. | 15:22 | |
15:40
justatheory joined
15:47
nihiliad left,
mj41 left,
KyleHa left,
skids left,
christine left,
drbean left,
elmex left,
kcwu left,
mdxi left,
cosimo left,
hexmode left,
scrottie left,
yves left,
jiing_ left,
ascent_ left,
c9s left,
ashizawa left,
nihiliad joined,
mj41 joined,
KyleHa joined,
skids joined,
christine joined,
drbean joined,
elmex joined,
kcwu joined,
mdxi joined,
cosimo joined,
c9s joined,
ashizawa joined,
scrottie joined,
hexmode joined,
yves joined,
jiing_ joined,
ascent_ joined
|
|||
literal | @tell azawawi actually, just try 0.08 instead (it's on CPAN now) | 15:49 | |
lambdabot | Consider it noted. | ||
15:49
sri_kraih left
|
|||
masak | literal: I'm going swimming soon. see you at 19 UTC? | 15:50 | |
literal | yep | ||
15:50
mikehh joined,
sri_kraih joined
|
|||
dalek | ok: 2d5db1d | (Hinrik Örn Sigurðsson)++ | (6 files): Detect whether a file contains Pod 5 or Pod 6 |
15:55 | |
ok: 1259af1 | (Hinrik Örn Sigurðsson)++ | (2 files): Some minor Pod reformatting |
|||
15:55
masak left
15:59
bruce joined
|
|||
KyleHa | Where's a good place for the test for this bug: rt.perl.org/rt3/Ticket/Display.html?id=67024 | 16:08 | |
16:13
Lorn joined
16:25
cdarroch joined
|
|||
TimToady | ya know, if we made captures return captures instead of arrays, a ? capture would naturally work as either an array or a scalar | 16:27 | |
s:2nd/captures/Captures/ | |||
Matt-W | captures don't return Captures? Headache time... | 16:28 | |
TimToady | well, maybe they should be more unified :) | ||
Matt-W | maybe they should | 16:29 | |
TimToady | that was part of the reason we named them captures in the first place | ||
because they're *like* match captures | |||
maybe they should be liker | |||
er, other way around | |||
Matt-W | what are the captures with a small c that you're referring to? To be precise. | ||
TimToady | /(...)/ | 16:30 | |
Matt-W | ah captures in regexps | ||
good | |||
TimToady | masak was carping about ? producing an array like ** 0..1 | 16:31 | |
Matt-W | he was | ||
I agreed that consistency is good | |||
and that I tend to think of ? as a synonym for ** 0..1 anyway | |||
pmichaud | so, would the other quantifiers also have the same effect? | ||
for example: "foo" ~~ / ('foo')+ / | 16:32 | ||
the resulting single-element Capture would naturally work as either an array or a scalar? | |||
TimToady | yes, I think so | ||
the [0] becomes optional | |||
whereas currently it's mandatory | 16:33 | ||
Matt-W | what happens if it's captured multiple things and you treat it like a scalar? You get the first one? | ||
TimToady | no, you get all of them. | ||
a scalar capture is still just a capture until it's bound | |||
pmichaud | in my example above, what would be the value of +$0 ? | ||
16:33
m-i-l-a-n left
|
|||
TimToady | good question | 16:34 | |
pmichaud | or worse | ||
16:34
m-i-l-a-n joined
|
|||
pmichaud | "123,123" ~~ / (\d+) ** ',' /; # +$0 == 2 | 16:35 | |
"123" ~~ / (\d+) ** ',' /; # +$0 == ??? | |||
Matt-W | 1, surely? | 16:36 | |
pmichaud | Matt-W: surely not. | ||
We already have this issue to some extent, though: | |||
rakudo: say +<123 123>; | |||
p6eval | rakudo 2dded8: OUTPUT«2» | ||
pmichaud | rakudo: say +<123>; | ||
p6eval | rakudo 2dded8: OUTPUT«123» | ||
Matt-W | pmichaud: doesn't that match at all then? | ||
oooh | |||
hmm | |||
TimToady | if we went the total capture route, we'd have to train people to say $0.elems | 16:37 | |
pmichaud | or +@$0 | ||
rakudo: say +@(123) | 16:38 | ||
TimToady | might be worth it for the consistency | ||
p6eval | rakudo 2dded8: OUTPUT«1» | ||
Matt-W | I tend to say .elems anyway, somewher eI got in my head that the array in scalar context thing didn't work in perl 6 anyway | ||
I think the consistency is a big win, the trick is training people how captures behave | |||
pmichaud | rakudo: say +@(123,123) | ||
p6eval | rakudo 2dded8: OUTPUT«2» | ||
16:39
Psyche^ joined
|
|||
TimToady | rakudo: say (123).elems | 16:39 | |
p6eval | rakudo 2dded8: OUTPUT«1» | ||
Matt-W must learn about captures | 16:40 | ||
pmichaud must learn about captures, also. | |||
it'd be nice if our specs about captures were as immutable as the captures themselves :-P | 16:41 | ||
KyleHa | It'd be nice if the specs about captures were all in one place. | ||
Matt-W | it'd be nice if the specs for a lot of things were a bit more immutable! | ||
But that'll happen one day | |||
TimToady looks for a convenient bus to get run over by | |||
Matt-W | TimToady: you really want to leave it to us to finish? hah! | 16:42 | |
16:43
m-i-l-a-n left,
last left
|
|||
pmichaud | do we still have separate Capture and List types? Or are they fairly unified these days? | 16:43 | |
TimToady | maybe, or possibly a List is a Capture that guarantees to have no nameds | 16:44 | |
don't know if that's worth anything | |||
pmichaud | would we still have Array ~~ List, then ? | ||
TimToady | so what's the mutable analog of Capture? a Harry? | 16:46 | |
pmichaud | I don't know. But I have a sense that Match objects want to be mutable, at least inside of regexes. | 16:47 | |
Could be wrong about that. | |||
TimToady | in Cursor/STD we allow mutability to the extent that it doesn't interfere with simple backtracking by throwing away a cursor | 16:51 | |
pmichaud | okay. | ||
TimToady | it's not "pure", and it might in fact be a premature optimization, but it seems to work out okay | ||
Lorn | moritz++ #perl5_to_perl6 awesome | 16:52 | |
TimToady | it also sneakily reuses cursors when ratcheting when it knows it can get away with it | ||
but a user-embedded closure can kinda be considered a BUILDer for the next immutable closure, in a sense | 16:53 | ||
so it's allowed to cheat | |||
KyleHa | kinda considered cheat, in a sense. | 16:54 | |
TimToady | when you assign to $<foo> in a closure, it's actually changing $¢<foo>, not $/<foo> | ||
those start out the same, but $/ is the match object within the closure, and would | |||
KyleHa | See, even if I knew "user-embedded closure" and "BUILDer for immutable closure", I still wouldn't know what that meant. I'm guessing. | 16:55 | |
TimToady | be overridden by an inner match, whereas $¢ is not | ||
16:55
Patterner left,
Psyche^ is now known as Patterner
|
|||
TimToady | mumbling to pmichaud mostly | 16:55 | |
pmichaud | eagerly absorbing TimToady++'s mumblings (mostly) | 16:56 | |
servers for $otherjob crashed overnight, so today I'm having to resurrect them a bit. | 16:57 | ||
16:57
ejs1 left
|
|||
TimToady | now if we ever implement "let $<foo> = ..." then we'll likely have to generate a new $¢ at that spot and let the old one exist unchanged in any backtracking lists | 16:57 | |
[particle] | rakudo: '¢' ~~ /<alpha>/ | ||
p6eval | rakudo 2dded8: ( no output ) | ||
[particle] | rakudo: say '¢' ~~ /<alpha>/ | ||
p6eval | rakudo 2dded8: OUTPUT«» | ||
TimToady | no more alphabetic than $ | ||
pmichaud | $¢ is special, like $/ $! and $_ | ||
TimToady | or € | ||
[particle] | right | ||
why aren't i getting 0 there? | 16:58 | ||
pmichaud | you didn't ask for a boolean | ||
[particle] | what's the context from the smartmatch if i don't ask for boolean? | ||
pmichaud | it's the context of the say | ||
and that context is string | |||
arguably, though, a failed match might ought to throw a warning in that case | 16:59 | ||
[particle] | is the match returning Nil? | ||
pmichaud | it's returning a Match object that evaluates "false" in boolean context | ||
[particle] | rakudo: say ('¢' ~~ /<alpha>/).WHAT | ||
p6eval | rakudo 2dded8: OUTPUT«Match()» | ||
pmichaud | matches always return match objects. | ||
[particle] | ah, right | ||
TimToady | rakudo: say ~() | 17:00 | |
[particle] | and a Match in string context is the content of the match | ||
p6eval | rakudo 2dded8: OUTPUT«Use of uninitialized value» | ||
TimToady | rakudo: say ~Nil | ||
p6eval | rakudo 2dded8: OUTPUT«Nil()» | ||
pmichaud | so perhaps stringifying a failed match or otherwise using it for its value should throw an exception | ||
(i.e., it should act like a Failure) | 17:01 | ||
[particle] | yeah, i think so | ||
TimToady | again, Nil is really a value, not a type | ||
pmichaud | right -- I haven't been able to make that change yet. | ||
[particle] | it is a failure, not a match | ||
pmichaud | it's still a Match, but it has failure semantics in it. | ||
TimToady | rakudo: say ?/nonesuch/.defined | 17:02 | |
17:02
finanalyst joined
|
|||
p6eval | rakudo 2dded8: OUTPUT«1» | 17:02 | |
17:02
molaf joined
|
|||
TimToady | if failures report defined, foo() // die won't work | 17:02 | |
pmichaud | right | 17:03 | |
so I think I need to adjust Match objects to have Failure semantics on failed matches | |||
TimToady | we have failure to communicate :) | ||
pmichaud | the spec probably wants some explication there. | 17:04 | |
because I didn't pick that up from reading the current spec. | |||
TimToady | S02:616 | ||
pmichaud | I meant S05. | ||
TimToady | hmm. in the Cursor model, failure to match really is () | 17:05 | |
pmichaud | and ().defined is false? | ||
rakudo: say ().defined | |||
p6eval | rakudo 2dded8: OUTPUT«0» | 17:06 | |
pmichaud | failure to match is really (), but is that also something that does Match ? | ||
TimToady | rakudo: say () // "hi" | ||
p6eval | rakudo 2dded8: OUTPUT«hi» | ||
17:07
bruce left,
bruce joined
|
|||
TimToady | matching ? 0 times returns a new cursor with the same pos rather than () | 17:07 | |
dalek | ok: 8227fcc | (Hinrik Örn Sigurðsson)++ | TODO: Add a bunch of stuff to the TODO file |
17:10 | |
ok: 5446fa1 | (Hinrik Örn Sigurðsson)++ | (3 files): Add homepage and source repository to Makefile.PL |
|||
ok: 7d7f20f | (Hinrik Örn Sigurðsson)++ | (4 files): Refactor the code a bit and document public methods |
|||
ok: 5a0d6ae | (Hinrik Örn Sigurðsson)++ | (9 files): Add some author tests (Pod, Perl::Critic, etc) |
|||
ok: bb28e42 | (Hinrik Örn Sigurðsson)++ | (3 files): Various fixes suggested by Pod::Coverage and Perl::Critic |
|||
ok: b1dddd4 | (Hinrik Örn Sigurðsson)++ | (4 files): Bump version to 0.09 |
|||
TimToady | good think I have dalek lolighted in dark blue... | 17:11 | |
s/k/g/ | |||
pmichaud | okay, so let me briefly test my understanding of captures (in the Perl 6 sense, not the regex sense) | 17:12 | |
(), (1), and (1,2,3) all produce captures | 17:13 | ||
Nil is just another way of saying () | |||
Nil.perl and ().perl should result in "()" | |||
().elems is 0, (1,2,3).elems is 3 | 17:15 | ||
($x).elems would end up invoking $x's .elems method | |||
in fact, any capture with exactly one positional element delegates method calls to that element | 17:16 | ||
(@a, @b).elems would produce ... ? | 17:17 | ||
literal | is dalek's source available publicly? | 17:18 | |
pmichaud | I'm guessing (@a, @b).elems would be the same as @a.elems + @b.elems, because the .elems method on a capture will impose flattening list context on its positional elements | 17:23 | |
same for .keys, .values, etc. | |||
jnthn | pmichaud: But foo(@a, @b) doesn't flatten, no? | 17:24 | |
pmichaud | jnthn: depends on how it's bound | ||
bruce | what about (%a, %b).elems or (1, 2).elems? | 17:25 | |
pmichaud | (1, 2).elems would be 2 | ||
(%a, %b).elems would be %a.elems + %b.elems, or more precisely (@%a, @%b) | |||
(%a, %b).elems would be %a.elems + %b.elems, or more precisely (@%a, @%b).elems | |||
because .elems would implose flattening list context on %a and %b | 17:26 | ||
*impose | |||
in the foo(@a, @b) case, the arrays flatten if bound to a slurpy param | |||
they don't flatten if bound to scalar or array params | |||
17:28
braceta joined
|
|||
pmichaud | (perhaps "interpolate" is a better word than "flatten" here.) | 17:28 | |
bruce | so, (1, @a, %b).elems would work out as 1 + @a.elems + %b.elems, right? | 17:29 | |
pmichaud | yes. | ||
but we're not distributing .elems over the components of the capture, we're actually building a flattened list from the capture and counting the elements in that | 17:30 | ||
so it's more like [1, @a, %b].elems but without creating the Array component | |||
(because the array composer imposes interpolating list context on its elements) | 17:31 | ||
TimToady | I'm not sure about all that flattening in invocant position | 17:32 | |
I think the capture delegates methods it doesn't recognize itself | 17:33 | ||
17:34
payload joined
|
|||
TimToady | so there at least ought to be a .elems-ish method that a Capture can answer 1 to | 17:34 | |
pmichaud | what would it delegate to...? | ||
17:34
M_o_C left,
M_o_C joined
|
|||
TimToady | even if you say (@x).capelems | 17:34 | |
it only delegates if there's a single *mumble* in the Capture | 17:35 | ||
if it's not an element, what is it? | |||
.args? | |||
pmichaud | I agree it would be good to ask a capture for its positionals without any flattening | 17:36 | |
17:36
M_o_C left,
M_o_C joined
|
|||
pmichaud | would @x.capelems and (@x).capelems be different in that case, though? | 17:36 | |
jnthn -> dinner, hopefully some Rakudo time later on | |||
TimToady | there's no capture on the left one | 17:37 | |
pmichaud | so, it's no longer true that (@x) is the same as @x | ||
okay. | |||
TimToady | but capelems is unweildy | ||
and it's really strange to ask a Match object for .args | 17:38 | ||
pmichaud | jnthn: do we have an easy way to delegate methods (e.g., from a builtin?) | ||
well, normally for a Match object I recommend @$/.elems or %$/.elems | |||
which comes around to the earlier discussion that perhaps $/.keys (and $/.values $/.elems etc.) should throw an ambiguity exception of some sort | 17:39 | ||
TimToady | +@() | ||
ruoso | TimToady, I always understood that a capture returning an array something as "a capture returning something that behaves like an array" | 17:40 | |
dalek | ok: 8436b20 | (Hinrik Örn Sigurðsson)++ | lib/App/Grok (2 files): Make a couple of diagnostic messages friendlier |
||
TimToady | well, it does positional readonly, not necessarily read/write | 17:41 | |
I fear a lot of our roles are really two different roles for ro vs rw | |||
17:41
pmurias joined
|
|||
ruoso | TimToady, isn't ro/rw'ness a state? | 17:41 | |
TimToady | define state | 17:42 | |
ruoso | I mean... does it really make sense to have different roles for ro and rw? | ||
some list might be read only or read write depending on runtime issues | |||
is it really necessary to bring that distinction to the type system/ | |||
? | |||
17:43
clintongormley1 joined
|
|||
TimToady | it's just a little strange to say that something provides the Array interface but will fail at anything outside Positional | 17:43 | |
and does Positional include lvalue subscripts? | 17:44 | ||
17:44
japhb left
|
|||
ruoso | I always thought so | 17:44 | |
pmichaud | I've lost the thread here, I fear. | ||
ruoso | sometimes they are read only | ||
sometimes they are not | |||
pmichaud, I was backlogging | |||
and brought an issue from about 1 hour ago | 17:45 | ||
pmichaud | we're still discussing that same issue, I thought. | ||
ruoso | ok... trying to put it another way, if Capture has a capitalized C, it means any object can be a Capture | 17:46 | |
17:46
clintongormley left
|
|||
ruoso | since it's not a native type | 17:46 | |
pmichaud | thus far I've just been trying to nail down the behavior of captures, without worrying about whether it's a native type. | ||
ruoso | the behavior, imho, is the union of Array and Hash | 17:47 | |
but it is read-only | |||
pmichaud | in which case you really mean List and Mapping | ||
instead of Array and Hash? | |||
ruoso | is there really a difference in API between List and Array? | 17:48 | |
pmichaud | yes. | ||
Array.push | |||
ruoso | but, in theory, "my List $a = (1,2,3); $a[$a.elems] = 2" wouldn't fail in compile-time, right? | 17:49 | |
since List implements .[] | |||
pmichaud | it's a readonly .[] | 17:50 | |
TimToady | the compiler is allowed to complain about things it knows will fail | ||
pmichaud | but it's not required to complain here. | ||
it would complain at runtime, though. | |||
ruoso | does the Multi dispatch considers the return of the method when choosing the candidate? | ||
pmichaud | ruoso: consider my Range $a = 1..3; $a[$a.elems] = 2 # fail | 17:51 | |
ruoso | in run-time | ||
the compile can't know that the Range that will be stored in $a is read-only or not | 17:52 | ||
s/compile/compiler/ | |||
pmichaud | Ranges are immutable. | ||
ruoso | the default Range implementation is immutable | ||
pmichaud | at any rate, it can know as much in the Range case as it can in the List case you gave above, I think. | ||
ruoso | but I can have some weird object that says true to .does(Range) | ||
pmichaud, that's the poitn | |||
17:53
KyleHa left
|
|||
pmichaud | what's the point? | 17:53 | |
ruoso | it can't know about List as well | ||
17:53
fridim_ joined
|
|||
pmichaud | fair enough. | 17:53 | |
but I don't understand the larger point that you're getting at. | |||
ruoso | there's no point in having different roles for ro and rw | ||
this is a runtime state | |||
of each particular object | |||
pmichaud | there could be a point other than compile-time detection of things, though. | 17:54 | |
or we could compile-time detect things other than the examples you've given | |||
ruoso | I'm thinking about the API itself, not about the hints it gives to the compiler | 17:55 | |
pmichaud | I'm still lost. But I don't feel a strong need to find myself on this particular issue. | ||
ruoso | I'm proposing the merge of List and Array, Hash and Mapping | 17:56 | |
and Capture is a union of both APIs | |||
pmichaud | What methods would a capture object "recognize itself"? | ||
ruoso | what do you mean? | ||
pmichaud | 17:33 <TimToady> I think the capture delegates methods it doesn't recognize itself | 17:57 | |
ruoso | I'm not sure I see any delegation happening... | 17:58 | |
a Capture in Item context might return a different object, when there's only one item inside it | |||
but other than that, it's a regular container | |||
pmichaud | clearly ($x).foo delegates the foo method call to $x | ||
ruoso | that's because ($x).foo uses the capture in item context | ||
pmichaud | and in the case of ($x, $y).elems ? | 17:59 | |
ruoso | 2 | ||
pmichaud | right, but what received the .elems ? | ||
ruoso | the Capture | ||
pmichaud | so the Capture *does* understand some methods | ||
ruoso | and that's when the need for a capture sigil emerges | 18:00 | |
18:00
mvuets joined
|
|||
ruoso | pmichaud, the Capture understand the Array and Hash API | 18:00 | |
pmichaud | ruoso: I'm not disagreeing. But then TimToady made his comment that "the capture delegates methods it doesn't recognize itself" | 18:01 | |
thus my question | |||
17:56 <pmichaud> What methods would a capture object "recognize itself"? | |||
TimToady was blathering | |||
what can I say to get ((),(),()) to return 3 | |||
@@, I guess | 18:02 | ||
ruoso | ((),(),()).elems does return 3 | ||
pmichaud | No. | ||
it returns 0. | |||
TimToady | @ flattens | ||
@@ doesn't | |||
lambdabot | doesn't | ||
ruoso | where is the @ | ||
? | |||
pmichaud | ruoso: (@a, @b).elems | ||
ruoso | ah... that's a different case | 18:03 | |
pmichaud | it's not. | ||
ruoso | but... | ||
I'm not sure (@a, @b).elems return somethign different from 2 | |||
because it hasn't been flattened yet | |||
if you say | |||
pmichaud | You didn't read my comments from earlier. | ||
TimToady | then why does (@a).elems not return 1 | 18:04 | |
pmichaud | fair enough. If TimToady++ says that (@a, @b).elems returns 2, I'll make it happen that way in Rakudo. | ||
ruoso | my ¢foo = (@a, @b); say ¢foo.elems | ||
pmichaud | but I don't think that's been the expectation. | ||
ruoso | TimToady, because of the Capture DWIM | ||
PerlJam | ruoso: but what about what *I* mean? :) | ||
ruoso | the barrier that determines the flattening is not the infix:<,>, nor is the circumfix:<( )> | 18:05 | |
but the enforcing of the list context | |||
PerlJam | I've only been paying attention for about a minute here and it already seems confusing. I typically just look for a nice clear rule I can follow to predict how code will behave and I'm not seeing one. | ||
ruoso | when you assign to @a, for instance | ||
PerlJam, there are two ;) | |||
PerlJam | ruoso: that's one fewer than 0, 1, infinity at any rate :) | 18:06 | |
pmichaud | ruoso: as I speculated earlier, (@a, @b).elems returns @a.elems + @b.elems because .elems imposes list context on the capture. But if (@a, @b) is to return 2, I'll happily adjust my worldview to that position. I just want to see it clearly stated somewhere. | 18:07 | |
ruoso | pmichaud, how .elems imposes list context? | ||
TimToady | the original question was how we get 0/1 from /(...)?/ | ||
if we make it a real capture with the Capture DWIM | 18:08 | ||
pmichaud | yes, but I'm just looking for clarification of how captures work in general. | ||
ruoso | maybe the problem is the Capture DWIM | ||
pmichaud | Obviously ruoso++ and I don't have the same picture in mind. | ||
I don't mind if my picture is incorrect, but I'd like to know that's the case because... well, I'm tired of Rakudo reporting incorrect results for things like (), Nil, and the like. | 18:09 | ||
I'd really like to fix it. | |||
So I'm looking for clarification on what we really mean by something like (@a, @b).elems or +(@a, @b) | 18:10 | ||
as well as the other items that I speculated above, following the section of "let me briefly test my understanding of captures..." | 18:11 | ||
TimToady | so perhaps we should generate a short list of examples and what our various expectations of them might be | ||
ruoso | I see... one thing I'm trying to keep in mind is that premature flatenning was one of the worst mistakes in p5 | ||
pmichaud | yes, that's what I was doing above. | ||
(generate a short list of examples) | |||
TimToady | scattered throughout IRC is not my idea of a list :P | 18:12 | |
pmichaud | fair enough -- we have wikis. | ||
TimToady | we need to capture it :) | ||
ruoso | )PGUP,PGUP( | ||
pmichaud | we can also do something like google docs, which makes it easier to collaborate in real time | ||
pmichaud starts a google doc | |||
ruoso | trying to get to a more concrete question, | 18:13 | |
I think the issue resides in "where is the flattening barrier?" | |||
TimToady | ruoso: on a different subject (yesterday's), I'm currently thinking that for bare names we have an object in the stash that is not the type object but points to things like type object, stash, or value | 18:15 | |
biab & | |||
ruoso feels a disturbance in the force, by the remote presence of globs | |||
18:16
mizioumt joined
18:19
clintongormley joined,
athomason joined
|
|||
ruoso | TimToady, honestly, I think having more sigils, or even the "::" "post-sigil" is a much better elegant way to solve the problem | 18:22 | |
skids | Then there's www.perlfoundation.org/perl6/index....erl6_tasks But of course, if we follow OpenSource tradition every time "we need a wiki page for that" we make a new one, even if 3 more alrwady exist :-) | 18:23 | |
18:23
mberends joined,
nihiliad left
|
|||
pmichaud | skids: I specifically didn't aim directly for the perl6 wiki because I find editing it to be a pain. | 18:23 | |
(and I like wikis.) | 18:24 | ||
(other than the perl6 wiki, that is) | |||
18:24
clintongormley1 left
|
|||
ruoso | (social text)-- | 18:24 | |
Tene | pmichaud: ever tried the verious wiki-as-filesystem FUSE projects? | 18:27 | |
pmichaud | Tene: not really. | ||
Tene | Okay. Passingly curious. | 18:28 | |
18:28
nihiliad joined
|
|||
pmichaud | spreadsheets.google.com/ccc?key=rZO...mYnFt5Ck1g # a spreadsheet with initial capture notes | 18:28 | |
skids | .oO(collaborative editing mode/IRC integration for November?) |
||
pmurias | Tene: are you a FUSE user? | ||
Tene | pmurias: occasionally. | 18:30 | |
18:30
macae joined
18:33
mizioumt1 left
|
|||
pmichaud | ruoso: perhaps Capture ~~ Positional and Capture ~~ Associative | 18:35 | |
as opposed to Capture ~~ Array and Capture ~~ Hash ? | |||
if Capture ~~ Array, then I would expect to be able to do Capture.push | 18:36 | ||
ruoso | pmichaud, well... yeah... I still don't see much the boundaries between Array, List and Positional | ||
pmichaud | ruoso: that's reasonable. I'm working more from "what is currently specced" than from "what I'd like to see" | ||
I do know that it's traditional in Perl (5) to distinguish "list" and "array" | |||
one key distinction is that @a = .... is different from ($a, $b) ==== | 18:37 | ||
oops, one = | |||
@a = ... # array assignment | |||
lambdabot | Maybe you meant: activity activity-full admin all-dicts arr ask . ? @ v | ||
pmichaud | ($a, $b) = ... # list assignment | ||
which somewhat argues that array != list | 18:38 | ||
ruoso | is that *really* different? | ||
pmichaud | rakudo currently relies on the distinction, yes. | ||
ruoso | I mean, in both cases, you need to take the rhs, get an iterator, and push into the lhs the values... the difference is what you do before that | 18:39 | |
18:39
xomas left
|
|||
pmichaud | "push into the lhs" is a little different, though. | 18:40 | |
ruoso | only to the extent that the lhs is different | ||
not the process | |||
pmichaud | right, but the lhs being different is exactly what I'm referring to here. | ||
ruoso | but they are *implemented* differently | 18:41 | |
pmichaud | 18:38 <ruoso> is that *really* different? | ||
18:41 <ruoso> but they are *implemented* differently | |||
ruoso | but they follow the same API | ||
pmichaud | answer to your question: Yes, they're *really* different (in implementation) | ||
ruoso | does that needs to be represented as the presence of other built-in type? | 18:42 | |
pmichaud | just because things follow the same API doesn't mean they are the same. | ||
ruoso | couldn't it be private to the implementation? | ||
pmichaud | That's the whole point of an API :-) | ||
ruoso | pmichaud, but we're precisely discussing the API itself | ||
pmichaud | iiuyc, you're saying that Array and capture (list) are essentially the same | 18:43 | |
I'm pointing out a place where their behavior differ | |||
they may have the same api, but the fact that the behaviors differ argues for them being different types | |||
or for one being a subtype of another | |||
18:43
clintongormley left
|
|||
ruoso | ok, we're arguing about different things | 18:44 | |
I'm talking about what's the built-in API | |||
pmichaud | I'm still just trying to understand what a capture does :-) | ||
ruoso | as the Perl 6 spec defines | ||
each implementation is free to have different types to fulfill implementation details | |||
so, back to capture | |||
pmichaud | the primary way I know to understand a type is to know how it responds to certain stimuli | ||
skids | @a[0] := $a; @a[1] := $b; (@a[1],@a[2]) = ...; @a[1..2] = ...; @a = ...; # which does what? | ||
18:45
justatheory left
|
|||
ruoso | Capture does Positional | List | Array; # let's wait to collapse that later | 18:45 | |
Capture does Associative | Mapping | Hash; # let's wait to collapse that later | |||
pmichaud | ruoso: good by me | ||
skids: the first two assignments have the effect of modifying $a and $b | |||
the last assignment simply gives @a a new set of values. | 18:46 | ||
18:46
masak joined,
japhb joined
|
|||
skids | That's what I thought. thanks. | 18:46 | |
masak | #p6s in 14. | ||
pmichaud | ...#p6s ? | ||
literal | #perl6-soc | ||
pmichaud | ah, thanks. | ||
masak | weekly meeting. | ||
pmichaud | freenode? | 18:47 | |
masak | aye. | ||
pmichaud lurks. | |||
masak backlogs | |||
ruoso | pmichaud, we're saying that () generates a capture... so what's the role of infix:<,>? | 18:48 | |
pmichaud | it separates the elements of a capture | ||
ruoso | but what happens in | 18:49 | |
pmichaud | I should note that I still haven't grown comfortable with the idea of () generating a capture... that ends up being a bit new to me. | ||
ruoso | ¢foo = 1, 2, 3 | ||
is that just a syntax sugar for (1, 2, 3)? | |||
skids | .oO(implicit ()'s because there's a , ?) |
||
pmichaud | I'm okay if infix:<,> also produces a capture. | ||
ruoso | pmichaud, you mean instead of a List | 18:50 | |
pmichaud | internally I'm somewhat working from the premise that "capture" and "list" mean the same thing. | ||
and that it's really "argument list" | |||
but that we call it "list" for short. | |||
18:50
mizioumt1 joined
|
|||
ruoso | if your list support named elements as well... | 18:50 | |
pmichaud | yes | ||
ruoso | that's the only difference | ||
pmichaud | list might end up supporting named elements. | ||
ruoso | (that and the DWIM | ||
pmichaud | but that also make it fit better with the notion of "lists" from a syntactic sense, as in "argument lists" (which can have named elements) | 18:51 | |
ruoso | ok... if we switch from () generating captures to infix:<,> | 18:52 | |
pmichaud | if we simply say that infix:<,> produces captures, then I'm not sure that we need circumfix:<( )> to do so. | ||
ruoso | it might have some impact on the ($x).elems issue | ||
pmichaud | heh... great minds think alike :-) | ||
I think that ($x).elems should be the same as $x.elems | |||
ruoso | ok... how that works in "return $x"? | 18:53 | |
do we simply send $x instead of a capture | |||
? | |||
pmichaud | I don't know yet -- that part is still fuzzy to me. Along with how we deal with "take $x" inside of a loop. | ||
ruoso | in theory, it's the same issue | 18:54 | |
pmichaud | sure. | ||
ruoso | if I see what you mean | ||
pmichaud | the real question is how do we unpack the capture in $a = foo() where foo has done "return $x" | 18:55 | |
(assuming there's a capture) | |||
ruoso | that's when the DWIM emerged | ||
pmichaud | for "return $x" itself, we know there's a capture because that's what is passed to the return() function. | ||
I'm fine with capture of one element still delegating | |||
ruoso | it doesn't delegate | ||
it disappears | |||
leaving that object in its place | |||
pmichaud | just because ($x) doesn't produce a capture doesn't mean we still can't have captures-of-one-element | 18:56 | |
in particular, ($x,) could still be a capture. | |||
ruoso | right | ||
it would, indeed | |||
pmichaud | anyway, for $a = foo() I would guess that $a gets the item from the capture | 18:57 | |
ruoso | exactly | ||
pmichaud | somewhat more interesting is the case where foo does "return $x, $y" | ||
ruoso | in that case, it will store the capture | ||
pmichaud | in that case there probably ought to be a warning | ||
ruoso | not $x | ||
why? | |||
since my $a = (1,2,3) doesn't | 18:58 | ||
pmichaud | no, but foo(1,2) does give a mismatch | ||
dalek | ok: f2b5b09 | (Hinrik Örn Sigurðsson)++ | lib/App/Grok/Pod (2 files): Fix a typo and change the wording of an error msg |
||
ruoso | pmichaud, assignment is not binding | ||
pmichaud | right | ||
I know that. | |||
ruoso | if you try | ||
:($a) := foo(); and foo return 1,2 | 18:59 | ||
it will fail | |||
masak | rakudo: my $r = 1..9; $r.pop; say $r.perl # pmichaud: if ranges are immutable, how come I can pop from them? | ||
p6eval | rakudo 2dded8: OUTPUT«1..8» | ||
pmichaud | it will also fail with ($a, $b, $c) = foo() | ||
ruoso | fail? $c will still be undefined, but not failure | ||
pmichaud | no, it's failure. | ||
ruoso | by spec? | 19:00 | |
pmichaud | ($a, $b, $c) = (1, 2) # fails | ||
perhaps I'm misremembering | 19:02 | ||
the spec does say | |||
($a, $b) = (1, 2, 3, 4) # warns | |||
ruoso | that's fair.. since the runtime can detect that some items were lost | ||
TimToady | um, S03:2443 | ||
pmichaud | TimToady: okay, got it. Thanks. | 19:03 | |
TimToady | my ($a,$b,$c) is a degenerate case of =() | ||
pmichaud | so ($a, $b, $c) = (1, 2) # leaves $c as undef | ||
TimToady | yes | ||
pmichaud | my apologies for getting it wrong | ||
TimToady | not wrong, just not what is specced :) | 19:04 | |
pmichaud | still, having $a = foo() give $a the capture itself feels funny | ||
it feels like I should have a special notation that says "I want the capture" rather than that being the default | |||
ruoso | maybe we start requiring the capture sigil to get the capture | 19:05 | |
TimToady | that one is jsut the Capture DWIM | ||
ruoso | and item will always get the first element | ||
TimToady | no | ||
skids | But then if it does return a capture and you use the notation, do you get a capture of a capture? | ||
TimToady | no throwing away data like P5 | ||
ruoso | point taken | 19:06 | |
so | |||
my $a = foo(); | |||
will get a capture, | |||
which means that | |||
pmichaud | okay. | ||
ruoso | if foo return @a, @b | ||
$a.elems return 2 | |||
pmichaud | that still seems open for discussion. | ||
in the same sense that | |||
my $a = (@a, @b) | |||
could have .elems return something other than 2 | 19:07 | ||
ruoso | indeed... | ||
pmichaud | (I'm fine with $a = foo() causing $a to get a capture.) | ||
ruoso | it's a matter of where the flattening barrier is | ||
er... in my $a = (@a, @b), $a does get a Capture | |||
pmichaud | right. | 19:08 | |
although whether that's because of the infix:<,> or the circumfix:<( )> is undecided (based on earlier discussion in this thread) | |||
ruoso | I actually currently think infix:<,> is a more precise way of defining it | 19:09 | |
pmichaud | I do like the notion that 3*($a+5) doesn't involve any captures. | ||
at least, not because of the parens | |||
(we still get captures from infix:<*> and infix:<+>, I guess) | 19:10 | ||
ruoso | yeah | ||
pmichaud | (but they may be optimizable away) | ||
ruoso | indeed | ||
TimToady | return types have to be good for something... | ||
pmichaud | masak: (ranges) there was a spec change at npw that declares ranges as immutable. Rakudo hasn't caught up. | 19:13 | |
masak: in particular, .pop and .shift are now gone from that part of the spec. | |||
19:14
mizioumt left
|
|||
pmichaud | masak: indeed, part of the reason that rakudo hasn't caught up is because Ranges need to be refactored to be properly Positional, and doing that means we really need a good understanding of captures. Hence, the discussion today. | 19:14 | |
masak submits rakudobug | |||
pmichaud | we also need to remove the tests for .pop and .shift from the suite. | 19:15 | |
19:15
sri_kraih_ joined
|
|||
masak | I like ranges better when they're immutable. | 19:15 | |
pmichaud | yes, me also. | ||
TimToady | I'm thinking .elems should be undefined on a multi-arg capture, probably | ||
pmichaud | TimToady: same for values, prefix:<+>, .keys, etc? | 19:16 | |
keep in mind we get weird things like | 19:17 | ||
my $a = <a b c d>; say $a.elems | |||
which would not like having .elems undefined. | |||
(the correct formulation would have to be @$a.elems or something like that.) | 19:18 | ||
19:18
jlaire left,
ejs joined
|
|||
TimToady | $a[].elems | 19:19 | |
ruoso | I think we'll need to assume lists work differently in p5 than in p6 | ||
and that flattening needs to be explicit | |||
so | |||
TimToady, the problem about that is that the flattening will have to be implemented by the capture itself | |||
TimToady | or we need something VAR() like to get at naked capture | 19:20 | |
pmichaud | yes, there does seem to be a point where captures start to look like fancy containers. | 19:21 | |
19:21
nihiliad left
19:22
nihiliad joined
|
|||
ruoso | that's why I think the flattening needs to be external to the capture | 19:22 | |
by explicit operations | |||
$a[].elems kinda work | 19:23 | ||
because it means we have postfix:<[]> | |||
pmichaud | there's still prefix:<*> :-) | ||
TimToady | er, no | ||
19:23
caio joined
|
|||
masak | :) | 19:23 | |
TimToady | have to know whether to expect term/infix after | ||
pmichaud | okay. | 19:24 | |
ruoso | std: multi postfix:<[]> {}; say $a[].elems; | ||
p6eval | std 27353: OUTPUT«Potential difficulties: Variable $a is not predeclared at /tmp/pJNrZxsLxp line 1:------> multi postfix:<[]> {}; say $a[].elems;ok 00:03 43m» | ||
ruoso | yeah... postfix:<[]> is ok... and this operator is responsible for getting it flatten | 19:25 | |
so... | |||
(@a, @b)[].elems is different than (@a, @b).elems | |||
pmichaud | wait, I have a question about that. | ||
pugs_svn | r27354 | pmurias++ | [re-smop] | 19:26 | |
r27354 | pmurias++ | prefix:<-> | |||
r27354 | pmurias++ | Code.arity | |||
r27354 | pmurias++ | multis do simple sorting of signatures based on positionals | |||
r27354 | pmurias++ | stringifing negative integers works (as do negative integers) | |||
r27354 | pmurias++ | Role.ACCEPTS($object) also checks if the object has composed Role | |||
r27354 | pmurias++ | Array.true always returns true | |||
pmichaud | my $a = (@a, @b); say $a[5]; # flattens? | ||
19:26
amoc left
|
|||
ruoso | pmichaud, no | 19:26 | |
pmichaud | how would I get @a or @b themselves out of the capture? | ||
ruoso | $a[0] and $a[1] | ||
pmichaud | oh, and to get the 5th flattened element it would be $a[][5] ? | 19:27 | |
(6th, whatever) | |||
ruoso | my $a = (@a, @b)[]; otoh... | ||
TimToady | ick | ||
ruoso | it only looks ugly while we don't look at the use of unflattened lists | 19:28 | |
I mean... | 19:29 | ||
use @ if you want a flattened lsit | |||
pmichaud | (mostly eager flattened list) | ||
ruoso | or use @a <== | ||
if you want a mostly lazy flattened list | |||
19:30
sri_kraih left
|
|||
pmichaud | afk for a bit | 19:31 | |
ruoso | I think this is one of the things we can say "Hey! This is really different in Perl 6, you'll have to get used to it" | 19:32 | |
huf | what's the reason for it? | ||
19:33
ejs left
|
|||
huf | i'd like to know why it was changed because i kinda liked the automatic list flattening in perl5. | 19:33 | |
ruoso | it still has flattening | ||
but it requires you to use the sigil to have it | |||
skids | .oO(if lists/captures are the same and have named, what's an ordered list of pair objects look like as a literal?) |
||
ruoso | my @a = (@b, @c); will have it flattened | ||
huf | ah. | 19:34 | |
19:34
justatheory joined
|
|||
huf | so how would you have an array with the $ sigil? arrayref? | 19:35 | |
or one of these captures acts like an array in some contexts, but doesnt flatten? | |||
ruoso | huf, just backlog a bit, we've been discussing that exact issue | ||
huf | will do, thanks | 19:36 | |
skids | huf: reference is a dirty word around here :-) | ||
huf | yes, i know they are dead | ||
19:40
mvuets left
19:45
last joined
|
|||
PerlJam | ruoso: if @a = (@b,@c) flattens, then does (@a,@b) = (@c,@d) too? | 19:48 | |
ruoso | what is this line supposed to do? | ||
PerlJam | I'd want (@a,@b) = (@c,@d) to copy the values from @c into @a, and same for @d and @b. | 19:49 | |
ruoso | I'm not sure that will do it | 19:50 | |
:(@a is copy, @b is copy) := (@c, @d) | |||
that would do it | |||
but in the assignment, it doesn't really have a way to know when to stop putting things on @a | 19:51 | ||
19:51
finanalyst left
|
|||
ruoso | (except if @a has a pre-defined shape) | 19:51 | |
masak | could anyone with a bit more EBNF-fu than me explain how rules [3] and [11] would _not_ create an infinite regress in www.w3.org/TR/xpath ? because they do when I turn them into a Perl 6 grammar. | 19:54 | |
pmichaud | masak: ebnf doesn't concern itself with left-recursion issues | 19:55 | |
i.e., left-recursion is automatically taken care of | |||
19:56
xomas joined
|
|||
masak | pmichaud: I sense there's some theory behind that, probably to be found in the Dragon Book or something? | 19:57 | |
pmichaud | yes, or a theory of languages course | 19:58 | |
masak reads up on en.wikipedia.org/wiki/Left_recursion | 19:59 | ||
TimToady | [S09] add missing rat native types | ||
oops | |||
phone | 20:00 | ||
20:01
justatheory left
|
|||
TimToady | n | 20:03 | |
oops again | |||
masak feels the S/N ratio of the channel drop sharply... :) | 20:06 | ||
20:07
exodist joined,
exodist left,
macae left
|
|||
jnthn | masak: whoz up? | 20:07 | |
;-) | |||
masak | 哈哈 | 20:08 | |
ok, rewriting the Grampa XPath grammar so it'll take advantage of Perl 6 grammars instead of trying to stay true to the XPath spec. | 20:11 | ||
when I have a part of a Match tree $<foo><bar> which I know to be a list, and I want to loop over it, do I write 'for $<foo><bar> { ... }' or 'for $<foo><bar>.values { ... }'? | 20:14 | ||
pmichaud | maybe @($<foo><bar>) | 20:15 | |
or $<foo><bar>.list | |||
masak | ok. | 20:16 | |
pmichaud | using $<foo><bar> by itself seems like it would only give one iteration | ||
masak | yes. | ||
even though that particular thing is a List, the $ sigil makes Perl treat it like an item. | |||
jnthn | rakudo: for 1..15 -> $n { when $n % (3&5) { say "FizzBuzz" }; when $n % 3 { say "Fizz" }; when $n % 5 { say "Buzz" } } | 20:17 | |
p6eval | rakudo 2dded8: OUTPUT«Use of uninitialized valueUse of uninitialized valueUse of uninitialized valueUse of uninitialized valueUse of uninitialized valueUse of uninitialized valueUse of uninitialized valueUse of uninitialized valueUse of uninitialized valueFizzUse of uninitialized | ||
..valueUse of … | |||
jnthn | Am I being especially stupid this evening, or are those unit value warnings a bug? | ||
*uninit | |||
pmichaud | what are you matching against? | 20:18 | |
masak | jnthn: I thought 'when' matched against $_ | ||
jnthn | oh duh | 20:19 | |
pmichaud | note that $n % (3&5) isn't a boolean :-) | ||
jnthn | right | ||
gah | |||
masak | ?() should solve it, then. | ||
lambdabot | Maybe you meant: . ? @ bf ft id pl rc v wn | ||
masak | lambdabot: oh, hush. | ||
jnthn was pondering doing some Rakudo hacking tonight and now wonders if he really should... | |||
masak | @@ lambdabot is stupid | ||
lambdabot | lambdabot is stupid | ||
masak | :) | ||
jnthn | @@ sucks | ||
lambdabot | sucks | ||
jnthn | more input is given by all non-stupid bots | 20:20 | |
buubot | jnthn: Sorry, no more output | ||
jnthn | ...output too. | ||
masak | more output, buubot, please! we beg you! | ||
buubot | masak: Sorry, no more output | ||
jnthn | we wish. | ||
jnthn git stash apply's his traits work from Monday and continues hacking on it | 20:21 | ||
20:23
iblechbot joined
|
|||
jnthn wonders when S14 got marked [DRAFT] | 20:24 | ||
masak | is there any synopses which is not a draft? | 20:25 | |
ruoso | masak, there are several levels of draftness | ||
PerlJam | It would be interesting to see one marked "final" :) | ||
jnthn | S12 isn't marked DRAFT for example. | 20:26 | |
ruoso | the thing is that several concepts haven't been stressed out yet | ||
and usually, as the implementations get there, it requires a lot of changes | |||
jnthn | Aye, but S14 is probably the synopsis that Rakudo has the best coverage of. ;-) | 20:27 | |
masak | rakudo: take 5 | ||
p6eval | rakudo 2dded8: OUTPUT«Diedin Main (/tmp/uuckDsGlCB:2)» | ||
ruoso | masak, that's expected | ||
masak | do we suddenly have no error message for take without gather? | 20:28 | |
ruoso | take should throw an exception | ||
jnthn | Did we ever have one? | ||
ruoso | a control exception | ||
masak | I'd like one. | ||
Tene | 'take' does throw an exception, one that 'gather' catches. | ||
masak: you could add it to perl6.pir's global exception handler | |||
check the type of the exception | |||
masak | ok; let me just create the rakudobug first, in case I fail. :) | 20:29 | |
Tene | :) | ||
20:30
araujo left
|
|||
Tene | TimToady: is there any specced behavior for 'take' without 'gather' or another EH? | 20:30 | |
masak | I'm not 100% it should halt execution... | 20:31 | |
is there any way to resume it after giving a warning? | |||
Tene | Yes. | ||
In fact, you could just modify the 'take' sub to set the severity to 'normal' | |||
and it should auto-resume | |||
masak | cool! | 20:32 | |
Tene++ Parrot++ | |||
Tene | ... except I think that rakudo's global exception handler grabs everything, not just non-fatal exceptions | ||
so, maybe some issues there | |||
jnthn | rakudo: say infix:<+>(2,2) | ||
p6eval | rakudo 2dded8: OUTPUT«Statement not terminated properly at line 2, near ":<+>(2,2)"in Main (src/gen_setting.pm:3279)» | ||
jnthn | std: say infix:<+>(2,2) | ||
p6eval | std 27354: OUTPUT«ok 00:02 37m» | ||
Tene | masak: in fact, it *does* auto-resume with the EH disabled | 20:33 | |
jnthn | trait_mod:<is>($declarand, $trait, &arg); | ||
Tene | so, the EH needs to either rethrow or ignore non-fatals | ||
jnthn | std: trait_mod:<is>($declarand, $trait, &arg); | ||
p6eval | std 27354: OUTPUT«Potential difficulties: Variable $declarand is not predeclared at /tmp/Sy7NusDoT1 line 1:------> trait_mod:<is>($declarand, $trait, &arg); Variable $trait is not predeclared at /tmp/Sy7NusDoT1 line 1:------> trait_mod:<is>($declarand, $trait, | ||
..&arg);[0… | |||
Tene | probably the latter | ||
I can do that. | |||
masak | nice. | ||
I'll leave it in your competent hands, and go back to hacking on Grampa. :) | 20:34 | ||
Tene | masak: try changing != to <= on perl6.pir:217 | ||
masak | ok. | ||
Tene: doing only that didn't help. | 20:37 | ||
Tene: do I also need to check for the exception type? | |||
Tene | masak: no, you should not check for the exception type. You should use >= instead of <= like I told oyu the first time. | ||
ETENECANTREAD | |||
20:37
justatheory joined
|
|||
masak tries again | 20:38 | ||
20:38
KyleHa joined
|
|||
Tene | erm | 20:38 | |
just > | |||
Tene fail | 20:39 | ||
masak | :) | ||
Tene | but seriously, it should just be '>' | ||
I'm confident this time. | |||
Again. | |||
masak | I'll try that, then. | 20:40 | |
Tene: that seems to work. now it survives the take-outside-of-gather. | 20:42 | ||
Tene: still no useful message, though. | |||
just a blank line in STDERR. | 20:43 | ||
Tene | masak: well, no message is set in the take() function | ||
justatheory | What is "huffmanized" or "The Huffman principal"? groups.google.com/group/perl.perl6....c64556ad07 | ||
masak looks | |||
justatheory: he's headmaster at the Huffman academy. *scnr* | |||
justatheory | There should be a definition for this… | ||
PerlJam | justatheory: things that are used often have the shortest token | ||
Tene | add $P0['message'] = 'OMG HAI MASAK!!!' as line 88 of control.pir | ||
justatheory | masak: No, that's the Huffmanator. | ||
PerlJam: I see. | 20:44 | ||
masak | Tene: gotcha. | ||
20:44
skids left
|
|||
PerlJam | justatheory: or perhaps you'd say that the length of your tokens are inversely proportional to their frequency of use. | 20:44 | |
justatheory | Is there a name for TimToady's rule that similar things should have very different names? | 20:45 | |
PerlJam: That's nicely put, thans. | |||
*thanks | |||
masak | justatheory: similar things should have different names? that sounds backwards. | ||
isn't it different things that should have different names? :) | 20:46 | ||
justatheory | masak: Functions that do similar names should not be named too similarly. Something like that. | ||
Tene | masak: "things that can be easily confused should have something to clearly distinguish them" perhaps | ||
justatheory | right | ||
masak | justatheory: IMO, .values and .elems are too similar in that respect. | ||
PerlJam | Tene++ | ||
Tene | you wouldn't want "subst" and "substr" as functions that do slightly different things. | ||
masak | Tene: right. :) | 20:47 | |
PerlJam | Tene++ again :) | ||
justatheory | Yeah, is there a name for the concept? | ||
TimToady's Rule | |||
masak | "different things should be different" | ||
Tene | iirc there's a name in linguistics somewhere. | ||
for something similar | |||
justatheory | Hrm, allison would know, too, then. | 20:48 | |
pugs_svn | r27355 | pmurias++ | [re-smop] fix test count | 20:49 | |
20:49
RonOreck joined
|
|||
pmurias | masak: the point of "similiar things should be different" is that you don't confuse them | 20:50 | |
masak | pmurias: aye. I get it. | ||
jnthn | .oO( pisat vs pistat ) |
||
masak | .oO( honourous vs onerous ) |
20:51 | |
20:51
fridim_ left
|
|||
jnthn | .oO( laughter vs slaughter ) |
20:51 | |
jnthn watches the spectests roll by | 20:52 | ||
pmichaud | .oO( through versus though versus tough versus thorough versus throughout versus thought versus ...) |
||
dalek | kudo: 468c021 | masak++ | (2 files): [control.pir] take without gather now warns block halted the program without explanation. This commit makes the condition non-fatal and adds a warning message. Tene++ for guidance. |
||
20:53
KyleHa left
|
|||
jnthn | trait_auxiliary is dead. :-) | 20:53 | |
Long live trait_mod | |||
pmichaud | yay! die <trait_auxiliary> | 20:54 | |
masak | rakudo: die <trait_auxiliary> | ||
p6eval | rakudo 2dded8: OUTPUT«trait_auxiliaryin Main (/tmp/GyGvFtHLBn:2)» | ||
jnthn | Tomorrow trait_verb can go away. | ||
Then we start refactoring towards multi-dispatch. | 20:55 | ||
Tene | On that note, many years ago the Norwegian Broadcasting Corporation decided to require all its weathermen to use the non-standard form “aust” /æʉst/ (east) in lieu of the standard form “øst” /øst/, because the latter could easily be confused with “vest” /ʋest/ (west). | ||
jnthn | Apart from, I need to fix up multi-dispatch before that... | ||
Tene | -- from another channel, where I brought the question up | ||
20:55
caio left
20:56
bruce left
21:00
pmurias left
21:03
masak left
21:10
Whiteknight joined
21:18
braceta left
21:20
ruoso left
21:21
eternaleye left
21:25
eternaleye joined
21:26
eternaleye left
21:29
eternaleye joined
21:31
mizioumt1 left
21:36
mberends left
21:42
perl7 joined
21:44
netfish joined
21:51
alester joined
21:54
molaf left,
netfish left
21:55
perl7 left
22:01
iblechbot left
22:02
wknight8111 joined
22:07
Whiteknight left
22:11
drbean left
22:19
skids joined
22:24
nihiliad left
22:30
MrKrueger left
22:32
meppl joined
22:35
Limbic_Region joined
22:37
meppl left
22:39
netfish joined
|
|||
dalek | kudo: 59d2b7a | jnthn++ | (5 files): More work on bringing our traits support closer in line with S14 and STD.pm. This kills trait_auxiliary in favor of trait_mod, adds parsing and an implementation of will (just delegates to is) and parsing of hides too (not yet implemnted), so now we should parse all the trait mods that STD does. |
22:46 | |
kudo: 3d94ef4 | jnthn++ | : Merge branch 'master' of [email@hidden.address] |
|||
22:55
Muixirt left
22:58
kidd_ left
23:01
frew_ joined
|
|||
skids | justatheory: (backlogging) a close concept to the linguistic one you are looking for is the "avalanche effect" property of hash functions -- similar hash inputs must give much different outputs. | 23:14 | |
ruoso: what test should be run before committing to re-smop? | 23:25 | ||
23:33
nihiliad joined,
nihiliad left
23:37
M_o_C left
23:43
sri_kraih_ left
23:49
DemoFreak left
23:52
DemoFreak joined
23:58
wknight8111 left
|