perl6-projects.org/ | nopaste: sial.org/pbot/perl6 | evalbot: 'perl6: say 3;' | irclog: irc.pugscode.org/ | UTF-8 is your friend! Set by moritz_ on 4 May 2009. |
|||
00:05
frew joined
00:15
eMaX left
00:17
justatheory left
00:30
DemoFreak left,
bacek__ joined
00:33
ElectricHeavyLan joined
00:53
drbean_ joined
00:55
dalek left,
amoc left,
dalek joined
|
|||
Tene | pmichaud: pushed HLL changes. You can change RAKUDO_HLL after review. | 00:55 | |
00:57
PhatEddy left
01:02
d4l3k_ joined
01:04
aindilis left,
bacek left,
Infinoid left,
bacek__ left,
LylePerl left,
rhr left,
baest left,
Khisanth left,
ascent_ left,
ingy left,
cj left,
nbrown left,
H1N1[A] left,
clkao left,
kbrandt left,
estrabd_ left,
frew|work left,
Helios left,
gfldex left,
stepnem left,
raiph_ left,
raiph left,
japhb left,
Aisling left,
r0bby left,
frew left,
skids left,
hercynium left,
NoirSoldats left,
PacoLinux left,
sri_kraih_ left,
hcchien left,
rewt left,
dukeleto left,
allbery_b left,
avar left,
frodwith left,
pdc303 left,
silug left,
cavelife^ left,
simcop2387 left,
REPLeffect left,
Patterner left,
araujo left,
phenny left,
drbean_ left,
jan___ left,
szabgab_ left,
c9s left,
cxreg left,
revdiablo left,
yahooooo left,
pasteling left,
rafl left,
kcwu left,
awwaiid left,
spx2 left,
lisppaste3 left,
zev left,
moritz_ left,
gbacon left,
arnsholt left,
StephenPollei left,
vx64z left,
cdarroch left,
jferrero left,
drbean left,
agentzh left,
cosimo left,
donaldh left,
[particle]1 left,
p6eval left,
sbp left,
LadyLuna2y left,
cognominal left,
elmex left,
plu left,
xinming left,
mj41 left,
kolibrie left,
omega left,
pjcj left,
tarbo2 left,
pugs_svn left,
TimToady left,
Trey left,
Eevee left,
PerlJam left,
Caelum left,
sunnavy left,
dalek left,
payload1 left,
alester_away left,
ElectricHeavyLan left,
Kisu left,
mikehh left,
lambdabot left,
orafu left,
[particle]- left,
ashizawa left,
kirillm left,
Gothmog_ left,
scrottie left,
felipe left,
ilbot2 left,
eiro left,
hexmode left,
mattp left
01:09
jnthn joined,
Maddingue joined,
buu joined,
kirillm_ joined,
AzureStone_ joined,
dalek joined,
drbean_ joined,
ElectricHeavyLan joined,
bacek__ joined,
frew joined,
nbrown joined,
vx64z joined,
donaldh joined,
skids joined,
payload1 joined,
raiph_ joined,
hercynium joined,
LadyLuna2y joined,
NoirSoldats joined,
PacoLinux joined,
alester_away joined,
Kisu joined,
jan___ joined,
cognominal joined,
REPLeffect joined,
cdarroch joined,
Patterner joined,
mikehh joined,
H1N1[A] joined,
ashizawa joined,
clkao joined,
jferrero joined,
LylePerl joined,
sri_kraih_ joined,
hcchien joined,
lambdabot joined,
orafu joined,
[particle]1 joined,
szabgab_ joined,
aindilis joined,
bacek joined,
raiph joined,
kbrandt joined,
[particle]- joined,
irc.freenode.net sets mode: +o jnthn,
araujo joined,
gbacon joined,
drbean joined,
xinming joined,
gfldex joined,
ingy joined,
ascent_ joined,
rhr joined,
Infinoid joined,
Aisling joined,
cj joined,
Khisanth joined,
r0bby joined,
baest joined,
Helios joined,
estrabd_ joined,
frew|work joined,
stepnem joined,
japhb joined,
allbery_b joined,
avar joined,
rewt joined,
silug joined,
dukeleto joined,
pdc303 joined,
cavelife^ joined,
frodwith joined,
simcop2387 joined,
agentzh joined,
c9s joined,
kidd joined,
AzureStone joined,
Grrrr joined,
antiphase joined,
smtms joined,
integral joined,
broquaint joined,
pmichaud joined,
s1n joined,
Woody2143 joined,
cotto joined,
hatseflats joined,
Tene joined,
mtve joined,
literal joined,
diakopter joined,
phenny joined,
cxreg joined,
pasteling joined,
kcwu joined,
revdiablo joined,
yahooooo joined,
irc.freenode.net sets mode: +oo pmichaud Tene,
awwaiid joined,
rafl joined,
elmex joined,
cosimo joined,
p6eval joined,
kirillm joined,
StephenPollei joined,
arnsholt joined,
mj41 joined,
Gothmog_ joined,
kolibrie joined,
omega joined,
pjcj joined,
tarbo2 joined,
pugs_svn joined,
TimToady joined,
sbp joined,
Trey joined,
scrottie joined,
mattp joined,
felipe joined,
ilbot2 joined,
eiro joined,
plu joined,
hexmode joined,
irc.freenode.net sets mode: +o TimToady
01:11
moritz_ joined,
spx2 joined,
jiing joined,
cls_bsd joined,
jrockway joined,
lisppaste3 joined,
zev joined,
irc.freenode.net sets mode: +o moritz_,
jferrero left,
dalek left,
drbean left,
d4l3k_ is now known as dalek
01:16
Caelum joined,
meehav joined,
PerlJam joined
01:17
kirillm left
01:19
IRSeekBot joined
01:20
AzureStone left
01:21
meteorjay joined
01:26
amoc joined
01:27
Caelum left,
ray joined
01:31
Caelum joined
01:39
alc joined
01:40
dukeleto left
01:41
amoc left,
amoc joined
|
|||
dalek | kudo: bf281cf | pmichaud++ | src/parser/ (2 files): Add ability to recognize operator subs. The ability to define |
02:15 | |
02:15
dukeleto joined
02:31
autin joined
02:51
dbezborodov joined
02:54
dbezborodov left
02:59
sri_kraih_ left,
sri_kraih joined
03:08
nihiliad joined
03:20
donaldh left,
donaldh joined
03:31
kst joined
03:33
cdarroch left
03:49
orafu left,
orafu joined
03:54
sri_kraih left
04:08
dukeleto left
04:10
skids left
04:20
hercynium left
04:30
eternaleye joined
04:34
Jedai joined
04:37
sri_kraih joined
04:38
eternaleye left,
eternaleye joined
|
|||
s1n | moritz_: s1n.dyndns.org/index.php/2009/05/14...confusion/ | 04:49 | |
05:01
sparc joined
05:18
frew left
05:19
vx64z left
|
|||
Tene | Ā»Ć¶Ā« | perl6-projects.org/ | nopaste: sial.org/pbot/perl6 | evalbot: 'perl6: say 3;' | irclog: irc.pugscode.org/ | UTF-8 is your friend! | 05:31 | |
Tene | There, now we have Camelia to watch over us. | 05:31 | |
05:40
nihiliad left
05:53
ejs joined
06:00
raiph_ left
06:03
amoc left
06:05
amoc joined
06:09
ejs left
06:18
ElectricHeavyLan left,
LadyLunacy joined
|
|||
patmat | Welcome LadyLunacy!! | 06:22 | |
06:27
LadyLuna2y left,
ElectricHeavyLan joined,
ElectricHeavyLan left
|
|||
moritz_ | good morning | 06:29 | |
06:31
mberends joined
|
|||
mberends | whoz op ? | 06:32 | |
patmat | hey moritz_! | ||
moritz_ | OH HAI P6BUGS ;-) | ||
06:34
ChanServ sets mode: +o Tene
|
|||
Tene | I'm op, what's up? | 06:34 | |
mberends | ok Tene s op. how do u make your own chanle? | 06:36 | |
06:36
ab5tract joined
|
|||
Tene | I saw this before from masak I think... I think I missed something. | 06:36 | |
mberends | im being polite, not using caplock. so how do u? | 06:37 | |
moritz_ | ;-) | ||
Tene: just a funny incident with somebody not used to IRC | 06:38 | ||
Tene | ah | ||
OK | |||
mberends | Tene: but srsly, how is the blogserver doing? | 06:39 | |
moritz_ | Tene: irclog.perlgeek.de/perl6/2009-05-12#i_1138627 if you're interested ;-) | 06:40 | |
Tene | mberends: I haven't touched it since i put it up. | ||
blogs.gurulabs.com/stephen/2009/05/...d-run.html | |||
pleasedieinafire.net:2080/ | |||
mberends | Tene: tried, that's why I was curious. Hmm, my post is gone :( | 06:41 | |
Tene | I'd really enjoy feedback. :) | 06:42 | |
mberends: oh, I put it up earlier from a different server. | |||
yeah, I see your post here in /tmp on my laptop. :) | |||
mberends | I was collaborating with masak on Yarn, any chance of merging the two sources? | 06:43 | |
Tene | probably | ||
mberends | :) I'd like to add registration, authentication etc. | ||
Tene | Well, probably not. It wasn't really meant to be a serious blog. Mostly just an experiment. | ||
06:44
DemoFreak joined
|
|||
Tene | I'll probably use it to test out features like that, and different ways of integrating them. | 06:44 | |
so, I don't have any real feelings of trying to work to make something good, yet. | 06:46 | ||
mberends | fine. On another topic, I tried mimicking a Net::SMTP and hd socket IO problems. Could you help troubleshoot the parrot bits? | 06:47 | |
*had # gah | |||
Tene | yes | 06:48 | |
mberends | great, I'll reduce the failing code to a tiny test case later | 06:49 | |
Tene | mberends: if you email it to me, I can take a look at it during the day. | ||
I'll be offline during work | 06:50 | ||
mberends | thanks, in a few hours | ||
Tene | that will be great. | ||
and it doesn't need to be *too* minimal, btw. | 06:51 | ||
if you can't get it minimal, just send what you can. | |||
mberends | ok, but I have @family.life() & to multithread | 06:53 | |
pugs_svn | r26824 | pmichaud++ | [t/spec]: Rakudo fudge a test we now regress. | ||
Tene | you've got 7 hours before I start waking up. :) | ||
mberends | that's doable | 06:54 | |
06:54
amoc left,
ejs joined
|
|||
mberends | Tene: it was already all at gitorious.org/net-smtp/mainline/trees/master | 06:58 | |
Tene | thx | 06:59 | |
07:01
dukeleto joined
07:03
ejs1 joined
07:10
mikehh_ joined
07:11
ejs left
|
|||
Matt-W | Morning | 07:14 | |
07:14
pnu left
|
|||
mberends | morning; afk & | 07:15 | |
07:16
iblechbot joined
|
|||
pmichaud | yay, I have operators in rakudo -- just need to run spectests and then push. :-) | 07:17 | |
Tene | pmichaud++ | 07:18 | |
pmichaud: I will see about getting pugs' Set.pm running on rakudo | |||
pmichaud | we're still limited in that the tighter/equiv/looser traits aren't implemented yet. | 07:19 | |
I'll work on that tomorrow. | |||
07:20
donaldh left,
ElectricHeavyLan joined,
donaldh joined
|
|||
Matt-W | pmichaud++ | 07:24 | |
07:25
mikehh left
|
|||
dalek | kudo: 8349d75 | pmichaud++ | src/parser/ (2 files): Add ability to define operator subs. |
07:56 | |
kudo: ad9e008 | pmichaud++ | (2 files): Add ability to declare infix: subs. |
|||
kudo: 9dcaf47 | pmichaud++ | src/parser/actions.pm: Update parse table both immediately and in saved code. |
|||
pmichaud | rakudo: sub postfix:<!>($n) { [*] 1..$n }; say 7!; | 07:58 | |
07:58
jferrero joined
|
|||
p6eval | rakudo bf281c: OUTPUTĀ«Malformed routine definition at line 1, near "postfix:<!"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)ā¤Ā» | 07:58 | |
pmichaud | rakudo: say &infix:<+>(3,4); | ||
p6eval | rakudo bf281c: OUTPUTĀ«7ā¤Ā» | ||
moritz_ | rakudo: sub infix:<foo>($a, $b) { say $a + $b }; 3 foo 4 | 07:59 | |
p6eval | rakudo bf281c: OUTPUTĀ«Malformed routine definition at line 1, near "infix:<foo"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)ā¤Ā» | ||
pmichaud | hasn't updated yet | ||
moritz_ | aye | ||
anyway, pmichaud++ | 08:00 | ||
pmichaud | rakudo: say 'ready yet?' | ||
p6eval | rakudo bf281c: OUTPUTĀ«ready yet?ā¤Ā» | ||
pmichaud | (not yet.) | ||
rakudo: sub postfix:<!>($n) { [*] 1..$n }; say 7!; | 08:01 | ||
p6eval | rakudo bf281c: OUTPUTĀ«Malformed routine definition at line 1, near "postfix:<!"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)ā¤Ā» | ||
pmichaud | rakudo: say 'ready yet?' | ||
p6eval | rakudo bf281c: OUTPUTĀ«ready yet?ā¤Ā» | ||
pmichaud | (sigh) | ||
moritz_ | pmichaud: I'm starting the rebuild now | ||
pmichaud | Impatience is a virtue. | 08:02 | |
Doesn't the rebuild normally start by itself at the top of the hour...? | |||
08:03
eMaX joined
|
|||
pmichaud | rakudo: sub postfix:<!>($n) { [*] 1..$n }; say 7!; | 08:03 | |
p6eval | rakudo bf281c: OUTPUTĀ«./perl6: error while loading shared libraries: libparrot.so.1.1.0: cannot open shared object file: No such file or directoryā¤Ā» | ||
moritz_ | pmichaud: it needs to recompile parrot, takes a while on a single CPU machine | ||
pmichaud goes back to playing solitaire. :-) | 08:04 | ||
08:08
ab5tract left
|
|||
pmichaud | rakudo: sub postfix:<!>($n) { [*] 1..$n }; say 7!; | 08:09 | |
p6eval | rakudo bf281c: OUTPUTĀ«sh: ./perl6: No such file or directoryā¤Ā» | ||
pmichaud | oh well. I need sleep, so will try it out tomorrow. | ||
moritz_ | it compiles gen_settings.pm right now | ||
good night | |||
rakudo: sub postfix:<!>($n) { [*] 1..$n }; say 7!; | 08:11 | ||
p6eval | rakudo 9dcaf4: OUTPUTĀ«5040ā¤Ā» | ||
moritz_ | pmichaud+++ | ||
08:17
autin left
08:18
autin joined,
tombom joined
|
|||
moritz_ | rakudo: my $a; &infix:<=>($a, 4); say $a | 08:19 | |
p6eval | rakudo 9dcaf4: OUTPUTĀ«4ā¤Ā» | 08:20 | |
moritz_ | rakudo: my Str $a; &infix:<=>($a, 4); say $a | ||
p6eval | rakudo 9dcaf4: OUTPUTĀ«Type mismatch in assignment; expected something matching type Str but got something of type Int()ā¤current instr.: 'die' pc 16712 (src/builtins/control.pir:225)ā¤Ā» | ||
moritz_ | rakudo: my Int $a; &infix:<=>($a, 4); say $a | ||
p6eval | rakudo 9dcaf4: OUTPUTĀ«4ā¤Ā» | ||
08:23
pnu joined
|
|||
pugs_svn | r26825 | moritz++ | [t/spec] unfudge assign.t, and extend a bit (you know, 318 assignment test just were not enough) | 08:27 | |
moritz_ | pmichaud: the form with french quotes (infix:Ā«somethingĀ») also needs to be done ;-) | 08:30 | |
Matt-W | rakudo: sub infix:<pointless>($a, $b) { $b ~ $a }; say "world" pointless "hello " | ||
p6eval | rakudo 9dcaf4: OUTPUTĀ«hello worldā¤Ā» | ||
Matt-W | that is so cool | 08:31 | |
pmichaud++ | |||
08:36
masak joined
|
|||
masak | I'm on my way to work. just stopping by to say pmichaud++ pmichaud++ pmichaud++ | 08:36 | |
08:36
masak left
|
|||
pugs_svn | r26826 | moritz++ | [t/spec] fudge sub.t for rakudo | 08:36 | |
dalek | kudo: 1af7e29 | moritz++ | t/spectest.data: we pass an operator definition/overloading test |
08:41 | |
08:50
eMaX left
|
|||
Matt-W | @tell masak Clearly there is a lot of love for pmichaud++ at the moment | 08:50 | |
lambdabot | Consider it noted. | ||
08:52
baest left,
baest joined
|
|||
pugs_svn | r26827 | moritz++ | [t/spec] unfudge proto.t for rakudo | 08:53 | |
08:54
meppl joined,
kane_ joined
08:55
kane___ joined
08:57
wollmers joined
09:11
kane__ left,
kane_ left
|
|||
wollmers | S01: 'Perl is written in Unicode.' | 09:17 | |
Yesterday IRC log: Text files are in Unicode. | 09:18 | ||
moritz_ | we certainly have a Unicode bias in here ;-) | ||
wollmers | There is no save way to autodetect UTF-8 versus UTF-16 for text files, for perl source - maybe, because source contains chars in the ASCII rabge. | 09:20 | |
*range | |||
moritz_ | wollmers: the presence of a BOM makes it rather safe | 09:21 | |
wollmers: and the spec is quite clear that if it's not UTF-16, UTF-8 is the fallback | |||
i'm not 100% happy with it, but it seems to mostly work | |||
lunch & | |||
wollmers | I cannot find it in the specs ... | 09:22 | |
Matt-W | unicode is always a nasty mess it seems | ||
wollmers | Matt-W: Encoding is the most simple thing, but mostly underestimated as a main source of problems. | 09:24 | |
09:27
bacek__ left
|
|||
jnthn | H H | 09:29 | |
pmichaud++ # yay! | 09:34 | ||
mikehh_ | I've been getting failures in spectest for the last few days - both on Kubuntu Jaunty Amd64 and Ubuntu Jaunty i386 | 09:41 | |
t/spec/S32-io/IO-Socket-INET.t fails test 2-3 - but when I run ./perl6 t/spec/S32-io/IO-Socket-INET.t it passes | 09:42 | ||
t/spec/S09-subscript_slice/slice.rakudo passes all the tests says #Fudged and then segfaults | 09:43 | ||
wollmers | mikehh_: cd rakudo; make t/spec/S32-io/IO-Socket-INET.t | 09:45 | |
mikehh_: runs here on Debian/Sid | |||
mikehh_ | wolmers: that passes | 09:47 | |
09:47
autin left
|
|||
mikehh_ | it just seems that when I run make spectest the test fails - maybe a threading problem? | 09:48 | |
09:48
cognominal left
09:50
autin joined
|
|||
mikehh_ | it has consistently failed on my last few builds both on Amd64 and i386 | 09:51 | |
sorry that should have been wollmers | 09:56 | ||
09:56
Kyosuke_Kiryu joined
09:57
mikehh_ is now known as mikehh
|
|||
jnthn | mikehh: I see the slice.t one too - I looked into it a bit, but it ain't gonna be easy to fix, I fear. :-( | 10:00 | |
10:01
Kyosuke_Kiryu left
|
|||
wollmers | mikehh: IO-Socket-INET.t does ugly things (look into source); the reasons for the difference can be many ... | 10:05 | |
10:09
TRM_PEMROGRAMAN_ joined
10:10
TRM_PEMROGRAMAN_ left
|
|||
mberends | mikehh: ugliness is my bad. I'd like to improve it... | 10:14 | |
wollmers: the problem I had writing it, was determining an available port number on the fly. | 10:15 | ||
mikehh | jnthn: as far as I can see it in the exit code | 10:18 | |
all the other tests pass | 10:19 | ||
jnthn | mikehh: It doesn't make it through all of them for me, crashes along the way. | 10:20 | |
mikehh: I hunted it down a bit and it looks like a GC bug. | |||
In which case it's liable to manifest itself in different ways in different places. | |||
mikehh | jnthn: thats what I think too | 10:21 | |
It seems to be in the gc cleanup | |||
jnthn | I thought so far that was mostly re-naming things, but maybe not. | 10:23 | |
mikehh | anyway I'm trying to debug now - will let you know if I find anything | ||
jnthn | mikehh: Thanks. I did also write a ticket on this that you may wish to look up. | 10:25 | |
With some initial analysis. | |||
mikehh: It was this one: rt.perl.org/rt3/Ticket/Display.html?id=65396 | 10:29 | ||
10:33
cognominal joined
10:37
iblechbot left
10:39
pastorn joined
|
|||
mikehh | jnthn: when I run as per the ticket I get maximum recursion depth exceeded then similar output | 10:40 | |
pugs_svn | r26828 | moritz++ | [t/spec] unfudge postfix:<!> test for rakudo | 10:42 | |
mikehh | with -G that is | 10:43 | |
jnthn: when I run the test -> ../parrot.t/parrot -G perl6.pbc t/spec/S09-subscript_slice/slice.rakudo the same stuff happens | 10:49 | ||
jnthn: but it fails after ok 7 - slice from array slice, part 2, maximum recursion depth exceeded | 10:51 | ||
jnthn: without the -G it gets past the say "# FUDGED!" then Segmentation fault | 10:53 | ||
10:55
payload1 left
10:57
zamolxes joined
|
|||
jnthn | mikehh: I know. | 10:57 | |
10:58
amoc joined
|
|||
jnthn | mikehh: The ticket gives a smaller example too. | 10:58 | |
mikehh | jnthn: ok and now for something completely different - or something to that effect :-} | 10:59 | |
10:59
masak joined
|
|||
masak | oh hai | 11:00 | |
lambdabot | masak: You have 1 new message. '/msg lambdabot @messages' to read it. | ||
masak | whoz user-defined op? | ||
@messages | |||
lambdabot | Matt-W said 2h 9m 27s ago: Clearly there is a lot of love for pmichaud++ at the moment | ||
masak | pmichaud++ | ||
moritz_ | rakudo: sub postfix:<!>($x) { [*] 1..$x }; say 5! | ||
p6eval | rakudo 1af7e2: OUTPUTĀ«120ā¤Ā» | ||
moritz_ | rakudo: { sub postfix:<!>($x) { [*] 1..$x }; }; say 5! | 11:01 | |
p6eval | rakudo 1af7e2: OUTPUTĀ«120ā¤Ā» | ||
masak | I have a few edge cases I'd like to discuss. | ||
rakudo: sub infix:<,> { 42 }; say 5, 5 | |||
p6eval | rakudo 1af7e2: OUTPUTĀ«55ā¤Ā» | ||
masak | I think this one should at least warn of overriding. | ||
(secondly, it doesn't work.) | |||
moritz_ | it's not lexically scoped yet | 11:02 | |
Matt-W | it just... doesn't do anything noticeable | ||
masak | moritz_: that is neither here nor there. | ||
jnthn | mikehh: I tried to debug it a bit but it's kinda hard. :-| | ||
moritz_ | masak: a warning isn't that easy... | ||
Matt-W lunch & | |||
moritz_ | masak: because the setting will define a 'proto infix:<,>' | ||
masak: so that any 'sub infix:<,>' is automatically a multi sub | |||
masak | moritz_: oh. | ||
moritz_ | masak: and adding a new multi never warns | ||
11:02
zamolxes left
|
|||
masak | moritz_: well, then it shouldn't warn. | 11:03 | |
moritz_: but I bet it shouldn't not work either. | |||
rakudo: sub infix:<#> { 42 }; say 5 # 5 | |||
p6eval | rakudo 1af7e2: OUTPUTĀ«5ā¤Ā» | ||
moritz_ | masak: it should do an ordinary multi dispatch | ||
masak | along the same lines... | ||
moritz_: aye. | |||
moritz_: and probably ambig-fail. | |||
moritz_ | rakudo: sub infix:<,>(Int $x where 1, Int $y where 1) { 42 }; say 1, 1 | ||
p6eval | rakudo 1af7e2: OUTPUTĀ«11ā¤Ā» | ||
masak | rakudo: sub infix:<+> { 42 }; say 5 + 5 # so should this | 11:04 | |
p6eval | rakudo 1af7e2: OUTPUTĀ«42ā¤Ā» | ||
moritz_ | now *that* should be tighter, and give 42 | ||
masak submits rakudobug | |||
11:04
zamolxes joined
|
|||
moritz_ | masak: a sub without a signature has slurpy @_ | 11:04 | |
masak | oh, right. | 11:05 | |
moritz_ | masak: so that it's not very specific, and will practically never match in the multi dispatch | ||
masak | rakudo: sub infix:<+>() { 42 }; say 5 + 5 # so should this | ||
p6eval | rakudo 1af7e2: OUTPUTĀ«42ā¤Ā» | ||
moritz_ | that should be 10, no? | ||
masak | I think so. | ||
rakudo: sub infix:<+>($a, $b) { 42 }; say 5 + 5 | |||
jnthn | I think the issues with overloading existing rather than defining new, may be an interaction between the existing ones using Parrot's MMD. | ||
p6eval | rakudo 1af7e2: OUTPUTĀ«42ā¤Ā» | ||
jnthn | And the new ones using Rakudo's. | 11:06 | |
masak | aha. | ||
jnthn: is there a plan to do something about that? | |||
moritz_ | rakudo: multi sub infix:<+>() { 42 }; say 5 + 5 | ||
p6eval | rakudo 1af7e2: OUTPUTĀ«Null PMC access in find_method()ā¤current instr.: '_block18' pc 78 (EVAL_20:54)ā¤Ā» | ||
moritz_ | masak: ^^ | ||
masak bug | |||
jnthn | masak: Oh, actually, that bug is exactly coming up because of this issue. | 11:07 | |
masak: The other issue is that since we're not really defining a proto yet, your sub is just supplanting the existing operator. | |||
masak: And yes, plan is to define all operators in Perl 6. (With inline PIR, no doubt.) | |||
When that happens, the special-cased auto-threading froms can go away too. :-) | 11:08 | ||
masak | rakudo: sub postfix:<km>($n) { $n ~ ' kilometers' }; say 42\km | 11:16 | |
p6eval | rakudo 1af7e2: OUTPUTĀ«Statement not terminated properly at line 1, near "\\km"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)ā¤Ā» | ||
masak | rakudo: sub postfix:<km>($n) { $n ~ ' kilometers' }; say 42km | 11:17 | |
p6eval | rakudo 1af7e2: OUTPUTĀ«42 kilometersā¤Ā» | ||
masak | \o/ | ||
but the first one should work too, right? | 11:18 | ||
jnthn | masak: Yes | 11:19 | |
rakudo: sub postfix:<km>($n) { $n ~ ' kilometers' }; say 42 \km | |||
p6eval | rakudo 1af7e2: OUTPUTĀ«Statement not terminated properly at line 1, near "\\km"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)ā¤Ā» | ||
masak submits a slam dunk | |||
jnthn | oh | ||
rakudo: sub postfix:<km>($n) { $n ~ ' kilometers' }; say 42\ km | |||
I meant that. | |||
p6eval | rakudo 1af7e2: OUTPUTĀ«42 kilometersā¤Ā» | ||
masak | oh, ah. | ||
11:20
donaldh left
|
|||
masak | well, I un-submit then. | 11:20 | |
jnthn | My previous one should not work. | ||
masak | no. | ||
and the case of \ without ensuing ws is already in RT. | |||
11:21
donaldh joined
|
|||
jnthn | aye | 11:22 | |
I think I know where to fix that too. | |||
Ouch, LolDispatch abuses Rakudo guts. | |||
moritz_ | aye | 11:23 | |
jnthn | That's gonna break in not too long. Happily, first I'm going to make the Right Way work. :-) | ||
masak | LolDispatch is cool. | 11:25 | |
but I was really surprised that what it does works already. | |||
turns out it cheats. :P | |||
jnthn | masak: I'm going to write an example very much like loldispatch and make it work the proper way. | 11:26 | |
masak | yay! | ||
wollmers | rakudo: sub infix:<cut> ($a, $b) { "Prolog: $a,!,$b." }; say 'a' cut 'b'; | 11:30 | |
p6eval | rakudo 1af7e2: OUTPUTĀ«Prolog: a,!,b.ā¤Ā» | ||
masak senses a new era in Rakudo hacking is about to begin... | 11:31 | ||
jnthn needs to blog about some of the stuff he's been doing on his not-yet-approved grant at some point... | 11:33 | ||
11:36
ejs1 left
11:39
ejs1 joined
|
|||
jnthn | woo, got cut-down LolDispatch-y thing working the Official Way. | 11:50 | |
With one annoying quirk that I can now fix hopefully... | |||
masak | ok, here's what I'd like: a Perl 6 project on github or wherever which took a Perl 6 source file as input, and gave a parse tree as output. it might be built on either STD or Rakudo, doesn't matter. the parse tree might be made of Match objects or just plain hashes, doesn't matter. | 11:55 | |
jnthn | gist.github.com/111625 | 11:56 | |
masak | my main requirement is mainly that I don't have to do the dirty work of joining the piping together. :) | ||
moritz_ | once Perl6::Grammar returns a proper match object, that's a piece of cake. | ||
masak | indeed. | ||
that's a legit solution too. | 11:57 | ||
jnthn | @tell Tene Here is the more proper way to do LolDispatch: gist.github.com/111625 - am comitting the changes to enable this Real Soon Now. Will not break the previous hacky way...yet. | ||
lambdabot | Consider it noted. | ||
moritz_ | jnthn: I don't think you need to worry about loldispatch | ||
jnthn: if I understood Tene correctly it's meant as a throw-away thingy for now anyway | |||
masak | jnthn: is 'handler' in the signature a type? | 11:58 | |
jnthn | masak: Yes | ||
masak | oh. | ||
masak sees now | |||
it's defined at the top. | |||
jnthn | See role handler { } | ||
Yeah | |||
But in Rakudo we're I think more liberal on the parse at the moment than STD | |||
std: sub foo() is nonexistantthing { } | 11:59 | ||
p6eval | std 26828: OUTPUTĀ«ok 00:02 35mā¤Ā» | ||
jnthn | oh, maybe not. :-) | ||
masak | um. that feels like a STDbug. | ||
moritz_ | IMHO that should be an error | ||
masak | TimToady: is it? | ||
12:00
iblechbot joined
|
|||
jnthn | Yeah, I was expecting STD to complain there, but I suspect it may more be out of pragmatism/incompleteness that it doesn't do so yet. | 12:00 | |
masak likes how the power of backlogging allows us to send messages through time | |||
jnthn | Or maybe it's to give the compiler a shot at handling special ones. | ||
moritz_ | oh wait | ||
masak | jnthn: maybe it's so that the subs can be defined before the handlers. | ||
moritz_ | it should be a compile time error, but does it have to be a parse time error? | ||
masak | moritz_: maybe not. | 12:01 | |
moritz_ | I mean is thing after the 'is' always a type name? | ||
jnthn | moritz_: I'm not 100% clear on that. | ||
S14 says | |||
pmichaud | good morning, #perl6 | ||
jnthn | To define a trait handler for an "is xxx" trait, define one or | ||
more multisubs into a property role like this: | |||
Suggesting that xxx is a type name. | |||
masak , for one welcomes our op overlord pmichaud | |||
jnthn | pmichaud: oh hai | ||
12:01
mizioumt joined
|
|||
masak | s/s// | 12:01 | |
jnthn spectests his intial patch to get us started on the road to traits | 12:03 | ||
12:05
payload joined
12:09
orafu left
12:10
orafu joined
|
|||
pmichaud | masak: in "say 5,5" the infix:<,> is never called. | 12:12 | |
say (5,5) would call infix:<,> however. | 12:13 | ||
masak | pmichaud: is that specced? | ||
moritz_ | and, more interestingly, why? ;-) | ||
pmichaud | I don't know if it's specced that way. But "say 5,5" passes two arguments to the say() function. | 12:15 | |
i.e., it never forms a list (it does form a capture) | |||
moritz_ | that's... weird | ||
pmichaud | "say (5,5)" sends one argument to the say() function; that one argument is the result of infix:<,> on two values. | ||
jnthn doesn't find that surprising | 12:16 | ||
It's like you'd not expect :($x, $y) to call it 'cus it's a signature. | |||
I guess we know when we're expecting to parse a capture and when not. | 12:17 | ||
Matt-W | would say(5,5) pass two arguments? | ||
jnthn | yes | ||
Matt-W | good | ||
masak | jnthn: but isn't the ',' within the signature also an operator? | ||
12:17
orafu left
|
|||
jnthn | masak: No. | 12:17 | |
It's just a parameter seperator | |||
masak | ok. | ||
fair enough. | 12:18 | ||
jnthn | (As are ;; and :) | ||
masak | aye. | ||
jnthn | See param_sep in STD.pm | ||
masak | oh, oh, how does the thing with trailing commas in lists really work, by the way? | 12:19 | |
they can't be pure infix if they're trailing. | |||
pmichaud | PGE handles it by having a notion of a "null term" | 12:21 | |
I'm not sure how STD.pm handles it yet | |||
moritz_ | which implies they're probably a special syntactic form (in STD.pm) | ||
masak | rakudo: sub foo($a,) {}; say &foo.arity | 12:23 | |
p6eval | rakudo 1af7e2: OUTPUTĀ«1ā¤Ā» | ||
masak | seems to work in sigs as well. | ||
12:23
orafu joined
|
|||
masak | meeting & | 12:24 | |
jnthn | Probably has to for method foo($inv:) {} to work. | ||
Matt-W | I'd expect so | 12:26 | |
unless : was excessively special-cased | |||
12:36
elmex_ joined,
elmex left
12:37
elmex_ is now known as elmex
12:42
payload left
12:47
kirillm_ is now known as kirillm
12:48
payload joined
|
|||
jnthn | -> slovak class, bbiab | 12:49 | |
12:53
lichtkind joined
13:01
ejs2 joined
13:11
ejs1 left
13:15
skids joined
13:18
iblechbot left
13:19
jferrero left
13:23
ruoso joined
13:27
mizioumt1 joined
13:28
ejs2 left
|
|||
ruoso | Hello! | 13:31 | |
masak | ruoso: oh hai. | ||
ruoso: I read through your Faz source code yesterday, before blogging. | 13:32 | ||
ruoso | masak, how does the trait handler works in LoLDispatch?... | ||
masak, I've just read your blog post... | |||
masak | ruoso: very well, thank you? :) | ||
dalek | kudo: 705cb2b | pmichaud++ | src/parser/grammar.pg: Fix use of ōæ½xAB ōæ½xBB and << >> in postcircumfix (and operator definitions). moritz++ |
||
masak | ruoso: actually, it works by cheating, AFAIU. | ||
ruoso: I had the impression Faz would use .reduce, but it does not seem to do that at all... | 13:33 | ||
ruoso | masak, we need .reduce to support different arity in the multies | ||
but we can have a different dispatcher as well | |||
13:34
exodist joined
|
|||
masak | ruoso: actually, Faz feels like a more syntax-rich LolDispatch. | 13:34 | |
ruoso | masak, plus the chained dispatch | ||
masak | yes, I noticed the word 'chained'. | ||
13:34
payload left
|
|||
masak | does that mean several things can match, in order? | 13:35 | |
ruoso | yes | ||
note the %*stash<posts> is populated at the root action's begin | |||
which is re-used by both create and inde | |||
*index | |||
masak | that seems to presuppose an application which survives single requests. | 13:36 | |
ruoso | what do you mean? | 13:37 | |
masak, the regex of the chained actions are concatenated | 13:38 | ||
so... | |||
if root regex is / ^ / | |||
and index regex is / \/? $ / | |||
the full regex that will match index is | |||
/^ \/? $/ | |||
then create also chains root... so, in the end, you get a regex like | |||
masak | ruoso: ah, nice. | 13:39 | |
that makes a lot of sense. | |||
ruoso | / ^ [ \/? $ { make $index } | \/create \/? $ {make $create} ] / | ||
actually | |||
there are some named captures in the way, so I can get parameters in the middle | 13:40 | ||
so the capture of the regex for that specific action is used as the capture when calling the closures for that action | |||
13:41
LadyLunacy left,
plu left
13:43
LadyLunacy joined,
plu joined
13:45
sjn joined,
wollmers left
13:48
ElectricHeavyLan left,
autin left
13:49
mizioumt left
13:54
pmurias joined
|
|||
ruoso | masak, I'm adding a view_post action in Faz' Yarn, so you can see the capture in action | 13:54 | |
hi pmurias | 13:55 | ||
masak | ruoso: nice. | 13:56 | |
pmurias | ruoso: hi | ||
ruoso | pmurias, I think now we can just try to fix the tests, and the refactoring is over | 13:57 | |
pmurias | we mostly have sigantures and perl 5 integration to restore | 13:59 | |
14:00
sjn left
|
|||
pmurias | ruoso: and we have a leak in re-smop :( | 14:02 | |
masak | mberends: ping. | ||
ruoso | pmurias, a new one? | ||
pmurias | yes | 14:05 | |
mberends | masak: OH HAI | 14:06 | |
masak | mberends: oh hai, whoz op? | ||
so I attempted the Ecosystem patch yesterday. | 14:07 | ||
ran into a smallish number of interesting issues. | |||
mberends git-pulls | 14:08 | ||
masak | haven't pushed anything from that yet. | ||
the last issue is kind of a blocker... | |||
mberends | I'm going to distil yesterday's todo list into PIONEER and README, for your comment. What's the blocker? | 14:09 | |
ruoso | masak, just pushed the version using the capture.... | 14:10 | |
masak | mberends: PERL6LIB not set when compiling lib/Installer.pm | ||
mberends: I think we need that full-fledged build system. | |||
ruoso: ok, will check. | |||
14:16
alester_away left
|
|||
mberends | lib/Installer.pm did not nest any 'use' commands, therefore it compiled anyway. You could insert PERL6LIB into proto:59. | 14:17 | |
moritz_ | rakudo: say ?("ab" ~~ /a <!after b>/) | ||
p6eval | rakudo 705cb2: OUTPUTĀ«1ā¤Ā» | ||
moritz_ | rakudo: say ?("ab" ~~ /a <!before b>/) | ||
p6eval | rakudo 705cb2: OUTPUTĀ«0ā¤Ā» | ||
moritz_ | rakudo: say ?("ab" ~~ /<!after a> b/) | ||
p6eval | rakudo 705cb2: OUTPUTĀ«0ā¤Ā» | ||
masak | mberends: yes, I'll try doing that first. but I do think that a full build system is the long-term solution. | 14:18 | |
14:18
alester joined
|
|||
mberends | masak: agreed | 14:18 | |
'env -i ...' would be even better, rtfm | 14:19 | ||
masak | :) | 14:20 | |
yes, ISTR someone said I should use env, because the env-less form is bash-specific or some such. | |||
mberends | Bourne and Korn do it env-less too, but the -i is FTW | 14:23 | |
14:23
iblechbot joined
|
|||
ruoso | masak, btw... wait a bit more before checking Faz Yarn... I'm doing some other cool thing now | 14:23 | |
jnthn back | |||
masak | ruoso: :) | ||
ruoso | masak, it seems you're working on some kind of templating engine... is it? | 14:24 | |
14:24
jferrero joined
|
|||
pugs_svn | r26829 | moritz++ | [t/spec] unfudge infix:ĆĀ«...ĆĀ» test for rakudo | 14:24 | |
14:28
LadyLunacy left
14:30
LadyLunacy joined
|
|||
masak is fascinated by the tests in t/spec/S01-perl-5-integration | 14:31 | ||
jnthn | livemocha++ # most interesting site I've found in a while | 14:33 | |
OK, back to debugging my test fail from my traits patch... | |||
pugs_svn | r26830 | pmurias++ | [re-smop] ported over Attribute | ||
r26831 | pmurias++ | [re-smop] | |||
r26831 | pmurias++ | started porting over DefaultBlockSignature | |||
r26831 | pmurias++ | t/control_exception.t passes | |||
pmurias | ruoso: what is Faz Yarn? | 14:34 | |
ruoso | pmurias, Faz is an Action Dispatcher in Perl 6 | ||
and Yarn is a blog engine masak started and that I later ported to Faz | 14:35 | ||
masak | there's also LolDispach Yarn, but it goes under the name "omgblog". :) | ||
ruoso | github.com/ruoso/faz/blob/a7a806ed8...ib/Yarn.pm | 14:36 | |
that's the latest version... that does fair use of Chained actions and of the different steps of the processing | |||
masak | jnthn: yes, livemocha seems really cool. will probably get a language partner on that site once my afk language partner has left town... | ||
ruoso | masak, now you can look at it ;) | 14:37 | |
masak | ruoso: well, after my workday finishes, I can. :) | ||
pmurias is remainded that he should be working on his project for uni rather than making smop pass tests... | 14:39 | ||
ruoso | the cool part is around line 91\ | ||
pmurias | * reminded | ||
jnthn | masak: Yeah, I'm getting some additional Slovak practice with it. Seems to work well. :-) | 14:40 | |
masak | jnthn: sounds promising. | ||
pmichaud | rakudo: sub postfix:<<!>>($x) { [*] 1..$x }; say 7!; | 14:41 | |
p6eval | rakudo 705cb2: OUTPUTĀ«5040ā¤Ā» | ||
masak | wow, that trick never gets old. :) | ||
pmichaud | rakudo: sub postfix:Ā«!Ā»($x) { [*] 1..$x }; say 7!; | ||
p6eval | rakudo 705cb2: OUTPUTĀ«5040ā¤Ā» | ||
moritz_ | masak: it used to work only with <>, not with <<>> or Ā«Ā» | 14:42 | |
pmichaud | rakudo: say Ā«hello worldĀ»; | ||
masak | oh! | ||
p6eval | rakudo 705cb2: OUTPUTĀ«helloworldā¤Ā» | ||
masak | pmichaud++ | ||
Matt-W | wow. Livemocha looks really interesting. | ||
moritz_ | pmichaud: we have tests for Ā«...Ā», but not for <<...>> I think | ||
pmichaud | rakudo: my $foo = 'hello world'; say Ā«$fooĀ».elems | ||
p6eval | rakudo 705cb2: OUTPUTĀ«1ā¤Ā» | ||
pmichaud | oops. | ||
oh well :-) | |||
moritz_ | it's not yet christmas ;-) | 14:43 | |
jnthn | pmichaud: I added trait_auxiliary as a category, and it all Just Worked on the parsing side. Thanks! :-) | ||
masak submits rakudobug | |||
ruoso | masak, please consider adding .redirect in the Web::Response module... | 14:44 | |
14:44
eternaleye left
|
|||
masak | ruoso: I've been wanting that too. so yes. | 14:45 | |
14:45
nihiliad joined
|
|||
mberends | nice, ōæ½xAB ōæ½xBB were bad in Pod::Parser, they might start working too | 14:47 | |
masak | mberends: please check the encoding settings in your IRC client. :) | 14:48 | |
(quoting /topic: "UTF-8 is your friend!") | |||
jnthn | masak: They looked fine to me. ;-) | ||
14:49
payload joined
|
|||
pmichaud | jnthn: (trait_auxiliary) I should probably fix it so that rakudo doesn't attempt to add those as tokens. | 14:49 | |
jnthn | pmichaud: Oh? Would that be in the category action? | ||
masak | jnthn: ok. Emacs does the Right Thing often enough that I just tend to assume that it's right and other clients are wrong. :) | ||
jnthn | I didn't commit yet... | ||
pmichaud | jnthn: no, it's in the add_optoken sub (actions.pm) | ||
mberends | it's XChat, cannot see what might need changing | ||
moritz_ | they look fine here too, but my irssi is configured to do some latin1/utf8 autodetection | 14:50 | |
pmichaud | you can go ahead and commit, I'll fix it up. I have other things to fix there also. | ||
jnthn | masak: If you used vi it'd do the right thing even more often. ;-) | ||
jnthn runs off back to his Visual Studio | |||
masak | jnthn: I do use vi. just not for IRC. | ||
jnthn: I do most of my Perl 6 coding in vim, actually. | |||
practically all of it. | 14:51 | ||
jnthn | masak: I know what :q does ;-) | ||
masak | jnthn: it's, er, a smiley. :q | ||
jnthn | .oO( sticking out a tongue with a tongue-ring ) |
||
masak | heh. | ||
jnthn | Or "licking nose" perhaps | 14:52 | |
moritz_ | on #perlde we have a bot that responds to :q ;-) | ||
16:51 <@moritz> :q | |||
16:51 <+dustpuppy> moritz: E37: No write since last change (add ! to override) | |||
jnthn | :!q ? | ||
Matt-W | moritz_++ | ||
But shouldn't it use the German translation? | |||
Matt-W ponders setting his laptop to be in German and seeing how long it takes him to learn how to use it | 14:53 | ||
moritz_ | Matt-W: dunno, dustpuppy mixes the languages a bit | ||
ruoso now needs to implement both Model and View in Faz... the controller part is set already... | |||
moritz_ | Matt-W: but I fear that most people wouldn't recognize the German translation ;-) | ||
Matt-W | moritz_: quite possible | ||
14:54
skids left
|
|||
Matt-W home & | 14:54 | ||
14:54
amoc left
|
|||
mberends | dutch IT people hate using dutch-localized software | 14:54 | |
masak | I'd say it depends among Swedes, but I sure don't enjoy running software in non-English localisation. | 14:58 | |
English is the lingua franca of software development. | 14:59 | ||
moritz_ | isn't that lingua anglica, or so? ;-) | ||
Tene | jnthn: please don't bother worrying about keeping loldispatch working. It was a 10-minute hack to see if I could do it. Thank you for making the right way work. | 15:00 | |
lambdabot | Tene: You have 1 new message. '/msg lambdabot @messages' to read it. | ||
masak | moritz_: no, because 'lingua franca' was lexicalized at the time when the Frankish tongue was predominant. | 15:01 | |
moritz_: in the same way, my collegues order a Coke with their food and are happy with getting a Pepsi. | |||
pmichaud | ick, Pepsi. | 15:02 | |
15:02
skids joined
|
|||
moritz_ | masak: that wasn't entirely serious | 15:02 | |
masak | moritz_: I know. :) | ||
moritz_ | (man smiley ;-) | ||
pmichaud | Whenever offered a Pepsi in lieu of a Coke, I choose water. | ||
masak | moritz_: I just felt like giving a serious answer. | ||
moritz_ | masak: I know that feeling | ||
masak | pmichaud: I tend go directly for the water. YMMV. | ||
moritz_ | masak: I also answer rhetorical questions sometimes, when I feel like | 15:03 | |
masak | moritz_: aye. moi aussi. | ||
dalek | kudo: 90dbe0b | pmichaud++ | docs/spectest-progress.csv: spectest-progress.csv update: 388 files, 11258 passing, 1 failing |
||
masak | moritz_: dictionary.com suggests that 'franca'/Frankish might have meant something more like 'European' at some point. | ||
15:04
alc left
15:09
kidd left
15:10
kidd joined
15:12
mofino joined
|
|||
mofino | evalbot: 'perl6: say 3;' | 15:13 | |
moritz_ | perl6: say 3 | ||
mofino | oh | ||
haha | |||
p6eval | elf 26831, pugs, rakudo 90dbe0: OUTPUTĀ«3ā¤Ā» | ||
masak | perl6: loop { print 'a' } | 15:14 | |
moritz_ | masak: pfui! | ||
masak | was that bad? :P | ||
moritz_ | masak: "pfui" is what we say to a dog that does something forbidden ;-) | ||
masak | oh. we have 'fy!' in Swedish. must be parellel. | 15:15 | |
dalek | kudo: 612bcf3 | moritz++ | docs/ChangeLog: [docs] ChangeLog updates |
||
jnthn | Tene: It was not going to break too soon more out of because I have to refactor other bits first more than trying to keeo loldispatch working ;-) | 15:16 | |
alester | Anyone else getting any traffic out of google/gmail/etc now? | ||
masak | alester: gmail works here. | 15:17 | |
15:20
donaldh left,
donaldh joined
|
|||
p6eval | pugs, rakudo 612bcf: | 15:20 | |
..OUTPUTĀ«aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa... | |||
..elf 26831: OUTPUTĀ«Can't call method "match_hash" on an undefined value at ./elf_h line 3238.ā¤Ā» | |||
masak | ok, I won't do that again, promise. | 15:21 | |
jnthn | lol | ||
Talk about delayed reaction... | |||
pmichaud | rakudo: say "masak: s{ 'u' x 100 }re you won't." | ||
p6eval | rakudo 612bcf: OUTPUTĀ«masak: suuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuure you won't.ā¤Ā» | ||
masak | :P | 15:22 | |
15:22
eternaleye joined
|
|||
jnthn | rakudo: sub infix:<ƶ>($x, $y) { say "flyyy" }; (1,2,3) Ā»Ć¶Ā« (4,5,6) | 15:23 | |
masak | (why do I get the feeling that pmichaud might have been slightly sarcastic?) | ||
p6eval | rakudo 612bcf: OUTPUTĀ«Statement not terminated properly at line 1, near "\x{bb}\x{f6}\x{ab} (4,5,6"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)ā¤Ā» | ||
jnthn | aww. | 15:24 | |
masak | is that a new bug? | ||
jnthn | Yes. No. | ||
moritz_ | jnthn: I think meta-ops are pre-generated | ||
masak | I mean, apart from being a known butterfly. | ||
jnthn | (Can't parse unicode hypers is none.) | ||
erm, known | |||
masak | ok. | ||
moritz_ | rakudo: sub infix:<ƶ>($x, $y) { say "flyyy" }; (1,2,3) >>ƶ<< (4, 5, 6) | ||
p6eval | rakudo 612bcf: OUTPUTĀ«Statement not terminated properly at line 1, near ">>\x{f6}<< (4, "ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)ā¤Ā» | ||
jnthn | But as moritz_ said, we don't handle generating meta-op forms yet. | 15:25 | |
For user defined ops. | |||
pmichaud | ....but we might be able to do so. | ||
moritz_ | aka it's a "todo bug" ;-) | ||
jnthn | Oh, I'm sure we can. | ||
It's just whether it's worth hacking it in now, or waiting for when we can parse them the more STD-ish way, if that's teh plan. | |||
moritz_ | heh, rakudo now parses STD.pm up to line 163 | 15:26 | |
masak submits TODO bug | |||
TimToady | sounds like it's about time for a rakudo emitter for viv | 15:27 | |
alester is getting 500ms+ pings to google.com and gmail.com :-( | |||
moritz_ | but I can't figure out why it stops parsing there | ||
pmichaud | google.com was slow for me a bit earlier. | ||
mofino | alester, flush out your tubes | ||
google is fine from the end | 15:28 | ||
this | |||
TimToady | oh, bizarre | ||
moritz_ | there's nothing obvious advanced in that region | ||
alester | I am not the Tube Keeper. | 15:29 | |
TimToady | when I ping google.com, it only returns every packet for which the seq# is !%5 | ||
but it's consistently 86 ms | |||
pmichaud | heh | ||
mofino | TimToady, yeah | ||
pmichaud | that is weird. I only get the packets where %5 == 1|2 | 15:30 | |
mofino | TimToady, it is weird | ||
I suspect they treat ICMP with very low priority | |||
TimToady | but they've obviously got it running on some kind of commutator | ||
maybe they're under ping attack :) | |||
pmichaud | oh, now I'm getting every packet. | ||
TimToady | so am I | 15:31 | |
weird | |||
pmichaud | from a different IP, though. | ||
TimToady | yes | ||
jnthn | TimToady: Should trait_auxiliary eventually be looking for a type name? | ||
pmichaud | 74.125.67.100 gives me 40% of the packets. | ||
jnthn | TimToady: So is Foo requires Foo to be a typename? | ||
(or checking what <longname> hands back is a typename, perhaps.) | 15:32 | ||
TimToady | STD doesn't check trait_auxiliary:<is> for semantics currently | 15:33 | |
pmichaud | jnthn: what about something like sub infix:<xyz> is equiv(&infix<+>) ... | ||
TimToady | it doesn't even care whether hte name exists | ||
pmichaud | would "equiv" need to be a type name there? | ||
TimToady | shouldn't care right now | 15:34 | |
std: sub infix:<xyz> is equiv(&infix<+>) {...} | |||
p6eval | std 26831: OUTPUTĀ«ok 00:03 47mā¤Ā» | ||
TimToady | std: sub infix:<xyz> is elephant(&infix<+>) {...} | ||
p6eval | std 26831: OUTPUTĀ«ok 00:03 47mā¤Ā» | ||
pmichaud | yes, but if we fix trait_auxiliary:<is> to require a typename, would that pose a problem? | ||
s/fix/change/ | |||
or would we expect "equiv" to be a role/type name | 15:35 | ||
jnthn | pmichaud: I would expect that equiv would be yes. | ||
pmichaud: Unless there are some that we magically recognize in the parser and don't try to dispatch. | |||
ERm, in the actions... | |||
And don't emit a dispatch for. | |||
masak | TimToady: do I recall correctly that forward gotos were problematic due to not-declared-yet-ness? | ||
TimToady | yes, we require goto "label" for forward goto | 15:36 | |
masak | ah, quotes. | ||
worksforme. | |||
goto <label> | |||
pmichaud | jnthn: if "equiv" is a type or role name, does that pose difficulties with creating a sub named 'equiv' ? | ||
i.e., are we eating up major portions of the namespace? | |||
jnthn | pmichaud: I think so; that's one of the things I'm bothered about. | 15:37 | |
pmichaud: But unless we special case some traits, I'm not quite sure how we handle this. | |||
15:38
M_o_C joined
|
|||
jnthn | I'm just going on what S14 says for user-defined traits. | 15:38 | |
Which is that you do it by introducing a role or class of that name (though I figure any typename will do...) | |||
TimToady | S14 doesn't really connect all the dots | 15:39 | |
as you have noticed | |||
typenames doesn't feel quite right to me for some reason | |||
pmichaud | same here. | ||
jnthn | TimToady: Are they connected elsewhere, or do you have a sense of how you want them connected? :-) | ||
TimToady | well, I've never thought about how they actually show up in your lexical scope | 15:40 | |
jnthn | I'm fine with use not parsing a typename there. I do need to know what we should do with the <longname> we parse there though. | ||
I'd guessed they were just roles that were in the setting, just like any other role. | 15:41 | ||
TimToady | well, but the intent was to do things beyond what roles normally do | 15:42 | |
pmichaud | +1 | ||
(beyond what roles normally do) | |||
afk for a bit | |||
TimToady will try drinking more coffee and see if it helps... | |||
jnthn | So far as I can follow S14, the main point of introducing something is so you have a name to write for the type of the first param to trait_auxiliary | 15:43 | |
TimToady: Also while you are pondering over your coffee, I'm also curious in: | 15:44 | ||
multi trait_auxiliary:<is>(xxx $trait, Class $container; $arg?) {...} | |||
What Class is there. | |||
TimToady | I suspect that means any typename | 15:45 | |
jnthn | Can it be a subset? | 15:46 | |
I can probably do it easily enough as one. | |||
TimToady | it's just intended to let you multi dispatch on different kinds of containers | 15:47 | |
jnthn | Sure | ||
TimToady | where "container" is subject to negotiation | ||
since pretty much any object could be considere a container of sorts | |||
skids | pmichaud++ operator subs booyah! | 15:48 | |
jnthn | The name Class is just curious since there is no class class :-) | ||
TimToady | we didn't know that back then | ||
jnthn | Ah, OK. | ||
TimToady | that's actually very ancient doc | ||
15:48
Psyche^ joined,
ab5tract joined
|
|||
TimToady | pre protoobject, pre STD, almost prehistoric | 15:48 | |
jnthn | I guess now you could write it as $container where { .BUILT } | ||
erm | 15:49 | ||
!(.BUILT) | |||
To get type objects. | |||
TimToady | we're not trying to get a type object, I don't think | ||
we're trying to get the actual container, like the array or hash object | 15:50 | ||
since that's what has to be modified | |||
jnthn | What about the class Foo is Bar { } style thing though? | ||
15:50
ingy is now known as ingynap
|
|||
jnthn | We'd like to be able to do a meta-class call to add_parent on Foo to add Bar. | 15:50 | |
15:51
eternaleye left
|
|||
jnthn | And I figured we'd call trait_auxiliary:<is>(Bar, Foo) | 15:51 | |
And Foo at that point is the type-object of the currently-under-construction class. | 15:52 | ||
I maybe figured wrong though. :-) | |||
TimToady | well, but maybe a trait on class passes the metaobject, not the typeobject | ||
15:52
Patterner left,
Psyche^ is now known as Patterner
|
|||
jnthn | Well, at least in the smop world there is no meta-object. | 15:53 | |
TimToady | because that's the actual container the trait is being applied to | ||
jnthn | So far as I understand it. | ||
TimToady | indeed, and that's why class Foo {...} fails there | ||
jnthn | The meta-class is more "singleton" rather than an instance. | ||
Did you see the meta-class being something we have an instance of per class that gets declared? | 15:54 | ||
That's how Rakudo currenlty does it, fwiw. | |||
TimToady | I think of it as an instance whose attribute values define the class | ||
jnthn | How does that play into the representation stuff? | 15:55 | |
TimToady | I don't know what you're meaning by "play into" | 15:56 | |
jnthn | OK, maybe a better question then | ||
What does it mean to create a class based on a P5Hash? | |||
ERm, an instance? | |||
phone | |||
back | 15:57 | ||
TimToady | I don't really care what it means, as long as it works :) | 15:58 | |
jnthn | Yes, but I't not convinced I know what "works" means in this case. | 15:59 | |
Do you see a class based upon a P5Hash as using that hash for its attribute storage? | |||
TimToady | I'm not in a mental state this morning yet to generate the alternatives | ||
as opposed to what? | |||
and are you speaking of P5Hash as a type or a representation that .CREATE knows about? | 16:01 | ||
jnthn | I haven't really figured out how they separate out yet. | ||
TimToady | the argument to .CREATE is just a string, as far as I know | ||
jnthn | Is there something that basically says "here is how to use the type P5Hash for instance storage"? | 16:02 | |
Which allows it to work as a representation? | |||
TimToady | how that picks the right MOP is beyond my ken | ||
it seems to be that different VMs are going to differ in how you write a RI, so this is beyond the design of P6 | 16:04 | ||
jnthn | That's fair enough, I just want to try and make sure I've got the relationship between the parts worked out. | ||
TimToady | I don't guarantee that ruoso sees it the same way I do :) | 16:05 | |
but it stands to reason that the implementation of P5Hash is going to be very different on a platform which supports P5 than on one that doesn't... | 16:06 | ||
16:06
justatheory joined
|
|||
TimToady | as a limiting case | 16:06 | |
jnthn | On one it's non-existent? ;-) | ||
pmichaud | rakudo: say 11258-10467; | 16:07 | |
p6eval | rakudo 612bcf: OUTPUTĀ«791ā¤Ā» | ||
pmichaud | not bad for May release. :-) | ||
jnthn | I hadn't known for sure up to now though, that you viewed the metaclass as "an instance whose attribute values define the class" | 16:08 | |
moritz_ | I once calcualted that 690 or os is the average number of new passing tests per month | ||
perlgeek.de/blog-en/perl-6/rakudo-r....writeback | |||
TimToady | just because I view it that way doesn't mean it's the right way forward, but the data about the class has to be stored somewhere | ||
and I don't think it's the undefined type object | |||
pmichaud | moritz_: yes, but April was a bit of an anomaly, and I was thinking that we might see a slowdown after that spike. | 16:09 | |
jnthn | A model where the meta-class knows this stuff fits well for me. | ||
TimToady | a given metaclass may well delegate a lot of this to the RI, of course | ||
masak | rakudo: say (16000 - 11300) / 715 | ||
p6eval | rakudo 612bcf: OUTPUTĀ«6.57342657342657ā¤Ā» | ||
masak | we're running out of tests. o_O | 16:10 | |
moritz_ | pmichaud: yes, but April wasn't part of may analysis | ||
so the anomaly didn't make it into the average | |||
pmichaud | moritz_: sure; I just knew that we were averaging ~700 tests per month, and I had been expecting May release to be somewhat less than that. Looks like it won't be. :-) | ||
moritz_ | pmichaud: ;-) | 16:11 | |
mberends | May + 6.5 months < Christmas ;) | ||
jnthn | TimToady: OK, that makes sense. | ||
pmichaud | rakudo: say 11258/16584 | ||
p6eval | rakudo 612bcf: OUTPUTĀ«0.678847081524361ā¤Ā» | ||
masak | mberends: :) | 16:12 | |
rakudo: enum Month <Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec>; say May + 6.5 | |||
p6eval | rakudo 612bcf: OUTPUTĀ«10.5ā¤Ā» | 16:13 | |
masak | is there any way I can get a month back from that? | ||
jnthn | TimToady: So I guess if we have a way of knowing if something is a metaclass, we can write that into our trait_auxiliary signature. | ||
moritz_ | masak: NYI I think | ||
masak | moritz_: but theoretically possible? | ||
moritz_ | masak: the spec says Month(10.5.int) | ||
masak | moritz_: ooh, nice. | ||
pmichaud | rakudo: enum Month <Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec>; say Month((May + 6.5).int).name; | 16:14 | |
p6eval | rakudo 612bcf: OUTPUTĀ«invoke() not implemented in class 'Perl6Role'ā¤current instr.: '_block30' pc 93 (EVAL_21:54)ā¤Ā» | ||
pmichaud | rakudo: enum Month <Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec>; say (May + 6.5).int; | ||
p6eval | rakudo 612bcf: OUTPUTĀ«10ā¤Ā» | ||
masak submits TODO ticket | 16:15 | ||
jnthn | Need postcircumfix... | ||
erm | |||
postcircumfix:<( )> | |||
And invoke in Parrot to be fixed. | |||
Or at least, need to be able to pun... | |||
And invoke the pun. | |||
pmichaud | I'll have to think about that one. | ||
jnthn | pmichaud: Yeah, I suspect we're blocked on doing anything implementation wise until Parrot's invoke overriding is fixed though. :-) | 16:16 | |
erm | |||
:-( | |||
pmichaud | we could recognize it syntactically. | ||
jnthn | So I've really not given it a lot of thought yet. | ||
Yeah, that's probably one way. | |||
ruoso | jnthn, TimToady, my vision for building an object with a Hash or P5Hash is that you're going to need a RI specific to support using that object as the representation | ||
pmichaud | In particular, I wonder if (Month)(10) works | ||
(according to the spec) | 16:17 | ||
TimToady | it should | ||
pmichaud | okay. | ||
Then yes, we'll need to fixup Parrot invoke. | |||
jnthn: "fixing Parrot invoke" is one of those things we should put on our "important to Rakudo" list. | |||
TimToady | in fact, Month(10) is exactly the same, since Month doesn't look for args | ||
ruoso | TimToady, additionally, selecting the MOP is a different issue than selecting the representation... you can interchange them, in the way I see things (that's what the REPR API is all about) | 16:18 | |
TimToady | (since types never do, or you couldn't say May + 6.5 | ||
jnthn | ruoso: That's fine, the issue here is more that it looks like meta-classes need to be instantiable if they're to be used as "the thing we send over to trait_auxiliary". | ||
TimToady | ) | ||
ruoso | jnthn, they can be... even in SMOP... | 16:19 | |
masak | pmichaud: speaking of which -- and I don't mean to stress you out unnecessarily -- how's the ROADMAP coming? | ||
pmichaud | I'm thinking it'll be today's task. | ||
ruoso | the question is wether the type metadata will be stored in the HOW object or in the type object | ||
masak | yay! | ||
ruoso | in SMOP, it currently stores it in the type object | ||
jnthn | ruoso: I'm thinking that'll be up to the HOW. | ||
pmichaud | Since I got operators done yesterday, I feel like I've accomplished something code-wise . | ||
ruoso | jnthn, oh... certainly it is... | ||
TimToady | the HOW decides where to store it | ||
ruoso | yes | ||
it's the HOW who receives the .add_method calls | |||
jnthn | Right, agree | 16:20 | |
But the issue I'm trying to get at is | |||
ruoso | but that's unrelated with choosing the represetnation | ||
jnthn | class Foo { method bar() { } } | ||
argh | |||
class Foo is Bar { } | |||
ruoso | you should be able to use whatever representation you want with whatever HOW you want | ||
TimToady | that doesn't seem obvious to me | 16:21 | |
jnthn | When we dispatch on trait_auxiliary:<is>(Bar, Foo) what is passed for Foo. | ||
If it's the meta-class that's fine, but in that case, and if the meta-class is delegating to the representation, how does that representation come to exist. | |||
ruoso | Foo.HOW.add_parent(Foo, Bar) | ||
16:22
ejs joined
|
|||
jnthn | ruoso: No, you missed the point. | 16:22 | |
We need to do a multi-dispatch to trait_auxiliary:<is> | |||
ruoso | ok | ||
oh... I see.. | |||
the problem is that usually you have a symbol for the trait | 16:23 | ||
like | |||
is export | |||
or | |||
is foo | |||
jnthn | Right, so it's a two fold issue. | ||
ruoso | in this case you have what usually would be an argument to the trait | ||
jnthn | 1) What do we pass for Foo - the thing that is currently under construction? | ||
ruoso | yes | ||
jnthn | 2) What do we write in the signature of the multi? | ||
ruoso | I guess there can be some catch in the syntax to realize that this is a specialized trait | 16:24 | |
and generate the equivalent to | |||
16:24
payload left
|
|||
jnthn | Ugh, no. | 16:24 | |
ruoso | is subclass_of Bar | ||
jnthn | Yeah but | ||
That still doesn't solve the problem of users writing traits of their own. | |||
TimToady | syntax knows whether Bar is type or not | 16:25 | |
ruoso | it doesn't? | ||
jnthn | class Foo is MyThingy { } | ||
TimToady | the syntax could map that differently depending on the typehood of MyThingy | ||
jnthn | multi trait_auxiliary:<is>(MyThingy $trait, ??? $class) { } | ||
TimToady | so the multi only sees non-type traits | ||
16:25
NoirSoldats_ joined
|
|||
TimToady | is one possibility | 16:26 | |
16:26
NoirSoldats left
|
|||
TimToady | it's more in line with the original thought than to make all traits into types | 16:26 | |
jnthn | TimToady: Here I'm not wanting to inherit from MyThingy, but write my own custom trait. | ||
TimToady | but doesn't solve the namespace problem | ||
jnthn | Which applies to classes. | ||
ruoso | I guess the syntax can reserve some uses for the "is" | ||
pmichaud | (jnthn: class Foo is mytrait(...) { ... } ) | ||
TimToady | in that case, *don't* make it a type, and it dispatches to the multi | ||
jnthn | In which case I need to know what to write for ??? | 16:27 | |
16:27
FurnaceBoy joined
|
|||
TimToady | well, the incipient type object is sufficient to get at anything else | 16:27 | |
(in this case) | 16:28 | ||
since the container is really mediated by .HOW | |||
jnthn | What does incipient mean? | ||
TimToady | "about to come into being" | ||
jnthn | ah, ok | ||
TimToady | but I still don't know what namespace mytrait sits in | 16:29 | |
16:29
alester left
|
|||
ruoso | I guess if it isn't a type, it's a sub | 16:29 | |
TimToady | doesn't follow | 16:30 | |
ruoso | (that's how it works everywhere else, afaics) | ||
jnthn | So this means that the thing we pass along is the incipient type object, and thus what goes in the signature is the same thing we use anywhere else to check if we've been passed a type object. | ||
ruoso | when you parse: Foo.bar | ||
if there is a type with the name "Foo" | |||
that's just a method call on the type object | |||
jnthn | ruoso: I'm not sure the problem is with it being a type, it's about namespace pollution. | ||
ruoso | but if there isn't a type, | ||
TimToady | std: rw | ||
p6eval | std 26831: OUTPUTĀ«Undeclared routine:ā¤ rw used at 1 ā¤ok 00:02 35mā¤Ā» | ||
TimToady | that is as it should be | ||
there is no rw sub | |||
ruoso | ok | ||
point taken | |||
pmichaud | and we don't necessarily want to preclude the definition of a "rw" sub. | 16:31 | |
TimToady | it's got it's own namespace somewhere | ||
a sigil or a subpackage | |||
like export tags do | |||
ruoso | a sigil is more interesting... | ||
because it's lexical | |||
TimToady | well, I'm always fascinated when a new sigil or twigil is proposed; we usually add it, and then remove it later :) | 16:32 | |
moritz_ | we didn't remove the : sigil yet | ||
ruoso | well... the other option would be to accept a bare | ||
jnthn | ruoso: I guess it works if we can write role Ā£rw { } or something. | ||
moritz_ | although I've never seen it in use | ||
erm, twigil | |||
(except in tests) | |||
jnthn | ruoso: I'd prefer subpackage myself. | 16:33 | |
role TRAIT::rw { ... } | |||
ruoso | but then you loose it as being lexically scoped | ||
TimToady | moritz_: well, okay, some of them stick :) | ||
why? | |||
jnthn | my role TRAIT::rw { ... } # :) | ||
ruoso | er | ||
TimToady | names containing :: can be lexically scoped these days | ||
ruoso | they can? | 16:34 | |
Trey | msg [particle]-: hey there... quick q i thought you might know of the top of your head. if an uploaded CPAN module had no license information anywhere in it, either in the meta or the makefile.pl or the text docs, is there a default license? or can one just not use it legally in a redistributed product? | ||
TimToady | std: my class Foo::Bar {...}; my Foo::Bar $x; | ||
p6eval | std 26831: OUTPUTĀ«ok 00:02 36mā¤Ā» | ||
ruoso | and what if the traits are stored in the lexical scope without a sigil? | ||
just as types are | |||
TimToady | then you'd get hash key collisions | 16:35 | |
symbol tables are just hashes | |||
ruoso | but do you really want to allow traits and types to have clashes? | ||
jnthn | I guess lexical names just act as flat names in the lexpad rather than packages per se though? | ||
Trey | oops, sorry about that missend. i need an extra slash... does TimToady, can you remove a slash from some feature so I can use it to message [particle]? | ||
TimToady | ruoso: huh? I'm trying to prevent clashes | ||
jnthn: no, they make subpackages | 16:36 | ||
jnthn | Trey: You use @tell on this channel | ||
ruoso | TimToady, I mean... is it ok to define both a type MyTrait and a trait MyTrait? | ||
jnthn | ruoso: No, thus the suggestion of TRAIT::MyTrait instead. | ||
ruoso | so my point is to store both in the lexpad without sigils... so you can't define both | 16:37 | |
TimToady | oh, no that level. but generally classes will be uppercase and traits lowercase, so I'm not worried about type clashes much | ||
but sub clashes are more likely | |||
ruoso | subs are stored with & | ||
so no clash | |||
TimToady | right, in which case they might as well be types | ||
hmm | 16:38 | ||
ruoso | but they aren't types | ||
so they get parsed different | |||
jnthn | huh? | ||
ruoso | their use get parsed different | ||
is <type> # parses one way | 16:39 | ||
jnthn | ruoso: A trait name is just so far as I can tell something you can look up and then use in a multi-dispatch. | ||
ruoso | exactly | ||
jnthn | But in a signature | ||
ruoso | is <somethingelse> # parses other way | ||
jnthn | :(Foo $x) # Foo should be a typename here | ||
ruoso | right | 16:40 | |
TimToady | but if they're not types, why not just give them their own sigil in the symbol table so as to prevent confusion with sub rw | ||
(when called without &) | |||
ruoso | but nobody looks in the lexpad without the & | ||
masak | two questions: is someone willing to be grant manager for my Collections grant proposal? are there any general guidelines for knowing what amount of money to request? | ||
TimToady | otherwise parsing a bare rw has to figure out what rw is | ||
ruoso | except when the parser knows it is a Type | ||
and I'm proposing that it also looks when it's a trait | 16:41 | ||
jnthn | ruoso: I don't understand "when it's a trait". | ||
TimToady | I think a sigil would be cleaner here | ||
ruoso | jnthn, is something # something is either a type or a trait | ||
but I'm ok with a sigil as well... | 16:42 | ||
jnthn | TimToady: So supposeing we chose Ā£ as the sigil (I guess we won't ;-)) then | ||
is rw # actually looks up Ā£rw | 16:43 | ||
16:43
[particle] joined
|
|||
ruoso | yes | 16:43 | |
TimToady | going up the lexical scope till it finds it, or doesn't | ||
jnthn | And you could write a role Ā£rw { ... } or whatever you wanted to introduce that label? | ||
TimToady | or maybe it's just exported that way, maybe | 16:44 | |
ruoso | bare Ā£rw; | ||
jnthn | ? | ||
ruoso | since it's just used for identity | ||
my bare rw; # declares Ā£rw | |||
jnthn | Well, if you read S14 note that you often want to introduce a role so you can mix in it as part of applying the trait. | 16:45 | |
In fact, well-behaved traits generally should. | |||
16:45
plu left
|
|||
jnthn | I guess you could declare a separate role too, but when where would it go? | 16:46 | |
It's probably better to hang everything off the same name. | |||
TimToady | the question is whether the role itself needs to be exported, or just the Ā£rw that knows about it | ||
a trait isn't required to use a role | 16:47 | ||
jnthn | TimToady: Sure, S14 says a class is just fine too. | ||
TimToady | it doesn't have to use a class either | ||
jnthn | I guess you can alias whatever to Ā£rw | ||
TimToady | Ā£rw just knows how to call the trait_auxiliary multi, and that's what has to be visible in the user's scope | 16:48 | |
ruoso | it's just used for identity | ||
jnthn | TimToady: OK, but it needs to be something you can write in a signature, no? | ||
TimToady | it? | ||
ruoso | you can write a bare value in a signature | ||
TimToady | there are too many its floating around | ||
as a constraint? yes | 16:49 | ||
ruoso | std: multi foo(1) { }; multi foo(2) { }; | ||
p6eval | std 26831: OUTPUTĀ«ok 00:02 38mā¤Ā» | ||
TimToady | and Ā£rw is a bare value, you're saing | ||
*saying | |||
ruoso | yes | ||
we can even omit the sigil | |||
jnthn | I'd seen more Ā£rw as an alias to something. | 16:50 | |
ruoso | std: multi trait_auxiliary:<is>(export, $code) | ||
p6eval | std 26831: OUTPUTĀ«##### PARSE FAILED #####ā¤Malformed block at /tmp/5lgy1jOZHl line 1:ā¤------> multi trait_auxiliary:<is>(export, $code)ā¤ expecting any of:ā¤ parameterā¤ signatureā¤ type_constraintā¤ typenameā¤ whitespaceā¤FAILED 00:02 37mā¤Ā» | ||
ruoso | right... it wasn't meant to be sent to std | ||
ruoso 's brain-- | |||
TimToady | that only works if "export" is a type, or an enum-like value | 16:51 | |
which parses like a type | |||
16:51
alester joined
|
|||
TimToady | but happens not to be undefined | 16:51 | |
ruoso | my point is that it would look for bare names as well | ||
TimToady | I'd still like to keep bare trait names out of the user's normal namespace, if possible | 16:52 | |
generally it can only lead to confusion | |||
since most people aren't going to be writing trait handlers | |||
ruoso | it is out of the normal namespace | ||
only certain things look for it | |||
TimToady | you can't write bare export in a signature without it being there in the namespace, it seems | 16:53 | |
jnthn | You could write Ā£export perhaps, though. | 16:54 | |
ruoso | yes... but it only look for "bare" in a few specific sport | ||
*spots | |||
TimToady | list of exceptions, bah | ||
ruoso | it's the same list of exceptions that Types have | ||
jnthn | Aye, just seeing that we are about to parse a trait_auxiliary should not make us parse the signature differently... | ||
16:55
cdarroch joined
|
|||
TimToady | shower & | 16:58 | |
jnthn | cooking dinner & | 16:59 | |
17:00
[particle]- left
17:02
ejs left
17:08
DemoFreak left
17:09
DemoFreak joined
|
|||
masak | what'll happen to the Perl 6 spec after Christmas? | 17:09 | |
moritz_: how's the implementation of infix:<...> going? | 17:11 | ||
17:20
hercynium joined
|
|||
jnthn | masak: iirc it neeeded laziness too | 17:21 | |
s/e// | 17:22 | ||
17:22
zamolxes left
|
|||
masak | jnthn: oh, right. | 17:23 | |
couldn't laziness be faked in this case? | 17:24 | ||
(implemented in pure Perl 6 in some way) | |||
jnthn | Perhaps. | 17:26 | |
Well, I don't know exactly what moritz_ has in mind. :-) | |||
Anyway, I hope laziness ain't *that* far off. | 17:27 | ||
We've put it off for quite a while already. ;-) | |||
rakudo: my @a = -1,2,-3; for @a { .= abs }; say @a.perl; | 17:29 | ||
p6eval | rakudo 612bcf: OUTPUTĀ«Unable to parse block; couldn't find final '}' at line 1, near ".= abs }; "ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)ā¤Ā» | ||
jnthn | rakudo: my @a = -1,2,-3; for @a { .=abs }; say @a.perl; | ||
p6eval | rakudo 612bcf: OUTPUTĀ«[1, 2, 3]ā¤Ā» | ||
jnthn | masak: Not sure if you missed it, but that works now. :-) | ||
(remember you asking about it) | |||
Though of course this is shorter... | |||
rakudo: my @a = -1,2,-3; @a>>.=abs; say @a.perl; | 17:30 | ||
p6eval | rakudo 612bcf: OUTPUTĀ«[1, 2, 3]ā¤Ā» | ||
masak | jnthn: that's great. I'll update the pun README, then. | 17:33 | |
jnthn: well, pun can only use the first variant. | |||
jnthn | oh wow, PayPal finally caught up with Slovakia having joined the euro... | 17:35 | |
Only took a few months. :-| | |||
BTW, anyone who has requests for Rakudo day tomorrow, please let me know. | 17:39 | ||
Other than any "help with moving to .HLL" tasks, I don't have anything planned yet. | |||
masak browses through the recent RT tickets | |||
jnthn: if you have a minute, I'd appreciate if you'd skim through this: gist.github.com/111790 | 17:40 | ||
mberends | jnthn: with luck, there might be a first cut of Temporal.pm to add to setting | ||
jnthn | mberends: Ooh, I'm happy to help on that. | 17:41 | |
(On getting it into the setting, that is.) | |||
mberends | :) | ||
jnthn | I guess it'll win us some spectests too? | ||
TimToady | at some point we need to move rakudo's setting to lexically outside of the user's program | ||
dunno how close that is to doable | 17:42 | ||
jnthn | masak: Ah, I can do that today. In fact, now, amongst dealing with preparing dinner... | ||
masak | excellent. | ||
I must detach soon to do likewise, but I will backlog. | |||
mberends | jnthn: the Pugs time.t is P5 style obsolete, I'm making new tests | 17:43 | |
jnthn | mberends: Great. :-) | ||
17:43
justatheory left
|
|||
jnthn | TimToady: It's probably not so bad in some senses. But none of the built-ins are lexical yet. | 17:43 | |
Plus we didn't get lexical importation working. | |||
S11 may need a little clarification on the route to that. | 17:44 | ||
masak | jnthn: I wouldn't mind if you took a look at [perl #65208], on the theory that the less broken Match objects are the more pleasant they are to work with. OTOH, maybe it's pmichaud's area of expertise, I dunno. | ||
jnthn | I've been working on some issues to get us closer - lexical multis now essentially work. | ||
And lexical subs etc. Lexical classes/roles shouldn't be much harder. | 17:45 | ||
But we probably gotta fix the "can't see lexicals outside a class" issue... | |||
17:46
[particle]2 joined
|
|||
masak | jnthn: [perl #64876] is slightly disturbing. | 17:46 | |
jnthn: but, to be honest, I don't actually have any wtf bugs right now, not that I can remember. | 17:47 | ||
oh, [perl #64656] is "unfortunate". | |||
masak ponders building his own nomenclature of bug severity | 17:48 | ||
anyway, food & | |||
17:48
masak left
|
|||
jnthn | Oh, 64876 I think I know how to fix. | 17:51 | |
rakudo: module A { sub foo() { return 42 }; say foo } | 17:52 | ||
p6eval | rakudo 612bcf: OUTPUTĀ«Null PMC access in find_method()ā¤current instr.: 'parrot;A;foo' pc 200 (EVAL_22:99)ā¤Ā» | ||
moritz_ | Matt-W: it still waits on lazy lists | ||
jnthn | rakudo: module A { sub foo() { 42 }; say foo } | ||
moritz_ | sorry, meant masak | ||
p6eval | rakudo 612bcf: OUTPUTĀ«42ā¤Ā» | ||
moritz_ | Matt-W: ignore me ;-) | ||
jnthn | Aye, I know about that bug. | ||
(or why we have it, at least) | |||
17:56
Morpheus^ joined
|
|||
pmichaud | 16:40 <ruoso> but nobody looks in the lexpad without the & | 18:01 | |
fwiw, rakudo doesn't store its subs with the & (there are a variety of parrot-related reasons for this) | |||
18:01
[particle] left
|
|||
pmichaud | it will probably convert to using the &, but at present it does not. | 18:02 | |
ruoso | but that's not correct in terms of spec, is it? | ||
pmichaud | I don't believe the spec is specific about that point, other than one needs to be able to look up subs using the sigil in a namespace or symbol table. | ||
ruoso | rakudo: sub foo { say OUTER::<&foo>.WHAT }; foo(); | ||
pmichaud | But an overload of postcircumfix:<{ }> could achieve this. | ||
p6eval | rakudo 612bcf: OUTPUTĀ«Could not find non-existent sub OUTERā¤current instr.: 'foo' pc 107 (EVAL_18:71)ā¤Ā» | ||
ruoso | rakudo: sub foo { say CALLER::<&foo>.WHAT }; foo(); | ||
p6eval | rakudo 612bcf: OUTPUTĀ«Could not find non-existent sub CALLERā¤current instr.: 'foo' pc 107 (EVAL_18:71)ā¤Ā» | ||
ruoso | meh | ||
jnthn | Aye, I'm not sure the spec is specific on that either. | 18:03 | |
jnthn -> nom | |||
TimToady | the & must be used with .{} to look up a sub name in a symtab | 18:04 | |
pmichaud | correct. | ||
that part I knew about. | |||
ruoso | hm? | ||
you mean it's different than other variables? | |||
TimToady | no, it's not | 18:05 | |
OUTER::<$foo> | |||
OUTER::<&foo> | |||
just the same | |||
ruoso | ah | ||
ok | |||
TimToady | S11 even gives some examples | ||
ruoso | but... | 18:06 | |
sub foo { }; say MY::<foo>; should not return the sub | |||
TimToady | that is correct | ||
pmichaud | that's my understanding as well. | 18:07 | |
TimToady | if foo is not a type or a named value, it shouldn't find it | ||
ruoso | but if you store the sub without the '&' | ||
TimToady | then you have to patch up that side too | ||
pmichaud | correct. | 18:08 | |
TimToady | so certainly we'll be pushing parrot in that direction | ||
pmichaud | I'm not saying that rakudo is taking the most straightforward or easiest approach here -- but for a variety of parrot-related reasons I'm not entirely at liberty to suddenly switch everything to using the &'s | ||
ruoso | right... so conceptually, rakudo does store with the '&' | ||
TimToady | at least for Perl 6, if not for other langauges | ||
pmichaud | and in some languages we can't use the & | ||
TimToady | conceptually, rakudo implements Perl 6 :P | 18:09 | |
18:09
justatheory joined
|
|||
[particle]2 | in theory, theory and practice are the same. only in practice do they differ. | 18:12 | |
18:12
[particle]2 is now known as [particle]-
|
|||
TimToady | only if you practice enough, in theory | 18:13 | |
but sometimes you can get lucky | |||
justatheory | TimToady: I am not a woodshed. | ||
TimToady | no, you just need to be taken out to one :) | ||
[particle]- | just a framework | ||
TimToady | while we're refactoring traits, I still wonder if we should also rename them... | 18:15 | |
[particle]- loads his shotgun | |||
...couldn't afford an electron gun... | |||
TimToady | just shoot yourself | 18:16 | |
justatheory | TimToady: I saw something nasty in the woodshed. | ||
TimToady | well, if you'd patched the roof like I asked you to, there wouldn't be fungus growing on the woodpile | 18:17 | |
[particle]- | well, heck, if we get some mold growing, we won't even have to paint it | ||
justatheory | heh | 18:18 | |
ruoso | I like mold... I even deprecated slime in favor of it in SMOP... | ||
TimToady | woodsheds mold character | ||
so maybe we should rename traits to characteristics | 18:19 | ||
just to discourage people | |||
characteristic_auxiliary:<is> | |||
justatheory | or distinctions | ||
ruoso | I think the _auxiliary:<is> part is discouraging enough | ||
jnthn <- nom | 18:20 | ||
justatheory | www.imdb.com/title/tt0112701/quotes | ||
pmichaud | masak: (RT #65208) I know why .print isn't working on Match objects... I'm not quite sure how to fix/resolve it, though. | 18:25 | |
jnthn | @tell masak I just looked through your grant proposal - looks good overall. | ||
lambdabot | Consider it noted. | ||
pmichaud | .print on match objects is conflicting with the predefined <print> subrule. | 18:27 | |
jnthn | TimToady: I wouldn't be against re-naming them. | ||
ruoso likes trait as well | 18:28 | ||
18:28
mofino left
|
|||
pmichaud | print(A.parse('foo')) works, however. | 18:28 | |
jnthn | pmichaud: What's the <print> subrule? | 18:29 | |
pmichaud | matches a printable character | ||
like <upper> matches an uppercase character | |||
jnthn | ah, ok | ||
pmichaud | also, A.parse('foo').Str.print works, though, as does (~A.parse('foo')).print | 18:30 | |
jnthn | No shortage of work-arounds then. :-) | ||
pmichaud | (updated ticket) | 18:36 | |
moritz_ just held a talk about Perl 6 regexes/grammars | 18:44 | ||
called "regexes on crack" | |||
it was received quite well | |||
pmichaud | excellent. Maybe I can borrow some notes/slides for my talk(s) on regexes/grammars? | ||
18:45
plu joined
|
|||
moritz_ | pmichaud: they are quite rudimentary, but it might give you some inspiration | 18:46 | |
oh, and they are in German ;-) | |||
pmichaud | well, I've given talks on regexes/grammars before, but it's always good to grab examples/ideas from others | ||
German is no problem, I think I can read the code at least. | |||
and I can often decipher my way through the german | |||
18:47
M_o_C left
|
|||
moritz_ | moritz.faui2k3.org/tmp/slides.vroom | 18:47 | |
you can view them with vim + Vroom::Vroom ;-) | 18:48 | ||
the theme is "why don't you write parsers in regular expression?" | |||
pmichaud | got it, thanks! | 18:49 | |
18:49
mizioumt joined
|
|||
moritz_ | you're welcome | 18:49 | |
pmichaud | heh, I like this part: | ||
+* Backtracking | |||
moritz_ | ;-) | 18:50 | |
each + makes that line appear on the next slide | 18:51 | ||
pmichaud | right, similar to Spork. | ||
(which is what I typically use for my presentations) | |||
18:51
masak joined
|
|||
masak | radical suggestion: how about renaming the subrule "printable"? | 18:51 | |
lambdabot | masak: You have 1 new message. '/msg lambdabot @messages' to read it. | ||
moritz_ | I should look into that too | 18:52 | |
masak | @messages | ||
lambdabot | jnthn said 26m 28s ago: I just looked through your grant proposal - looks good overall. | ||
masak | jnthn: thank you. | ||
moritz_ | masak: what's the URL? | ||
I can look throug it too, if you want | |||
pmichaud | masak: I think the subrules were original intended to correspond with the ctype function names | ||
masak | moritz_: gist.github.com/111790 | ||
pmichaud | like isalpha, isupper, isspace, isprint, isgraph, etc. | ||
masak | pmichaud: I'd be happy if you have a look at gist.github.com/111790 too :) | ||
pmichaud: I see. | 18:53 | ||
literal | you're applying for a TPF grant? | ||
masak | literal: a Hague grant. | ||
literal | cool | ||
masak | pmichaud: well, collision with an already defined method might or might not be considered a sufficient reason to deviate from the rule... | 18:54 | |
[particle]- | <:print> would be better, maybe, or <printable> or <isprint> | ||
pmichaud | masak: Overall I agree; I'm just not sure what @Larry will settle on. :-) | ||
masak | pmichaud: understood. :) | 18:55 | |
moritz_ | masak: (re grant, Buf) you could mention that Buf is the thing that keeps binary data / blobs in Perl 6 | 18:56 | |
masak: I'm not sure how well the people now Perl 6 and Str | |||
and know about decoded and undecoded stuff etc. | 18:57 | ||
18:57
Morpheus^ left
|
|||
pmichaud | "the people" tends to be rdice and the folks he passes the proposal to | 18:57 | |
18:57
plu left
|
|||
masak | moritz_: based on your previous comments, I added a bit about the deconding/encoding. I could add something about blobs and binary data too. | 18:57 | |
pmichaud | it would be good to mention blobs/binary data | ||
moritz_ | masak: I revise my previous comment ;-) | 18:58 | |
masak | :) | ||
pmichaud | especially since I just switched open() to default to text/utf8 | ||
18:58
mizioumt2 joined
|
|||
pmichaud | it would be good to have some way to treat files as blobs again :-) | 18:58 | |
masak | I'll probably also add a few details about what we know about Set et al. | ||
pmichaud: oh, I'll mention that. thanks. | |||
pmichaud | (and yes, I'll happily serve as grant manager for this project) | 18:59 | |
masak | \o/ | ||
pmichaud: I forgot to ask; making you read the proposal draft wasn't a circumspect way of asking. :P | 19:00 | ||
pmichaud | masak: it's no problem, really :-) | 19:01 | |
moritz_ | masak: you could also mention your impressive number of submitted tickets in your bio | ||
masak: IMHO it proves some of your qualification | |||
masak | moritz_: good idea. | ||
by last count (before Oslo) I had submmitted 314 tickets. | 19:02 | ||
should be over 350 by now. | |||
moritz_ | masak: you also had 76 commits to t/ and 85 to docs/ in pugs, an 40 in the rakudo repo ;-) | 19:03 | |
masak | moritz_: thank you. :) | 19:04 | |
moritz_ | git log|grep|wc -l is a nice combination ;-) | ||
masak | is it 40 already on Rakudo? I wouldn't have guessed. | ||
moritz_ | (which makes you the top 9 commiter in rakudo) | ||
pmichaud | overall the grant proposal looks pretty good to me. | 19:05 | |
masak | moritz_: could you paste that list? sounds interesting. | ||
moritz_ | masak: nopaste.snit.ch/16549 | ||
(no attempt was made at unifying multiple email addresses) | 19:06 | ||
Infinoid | There's also www.ohloh.net/p/rakudo/contributors | ||
moritz_ | you can also run `perl tools/commit-stats.pl' in the rakudo repo | ||
Infinoid | But I think that's affected by rakudo's history in the parrot repo. | ||
Tene | jnthn: defining a multi sub in a class fails | ||
I know why, but can't fix now | |||
masak | moritz_: thank you. I like to make similar statistics, but I've mainly attempted it on RT and the different Perl 6 projects. | 19:07 | |
moritz_: ooh! | |||
masak does so | |||
moritz_ | Infinoid: sure it is | ||
Tene | rakudo: class A { multi sub foo { ... } } | ||
p6eval | rakudo 612bcf: OUTPUTĀ«No method named 'foo' to remove in class 'A'.ā¤current instr.: '!TOPERL6MULTISUB' pc -5310275 ((unknown file):-1)ā¤Ā» | ||
Infinoid | Which explains why I'm on there, despite not being sure whether I have a rakudo commit bit. :P | ||
moritz_ | masak: ticket! | ||
Tene | can someone make ticket? | ||
I must teach now | |||
masak | rakudo: class A { multi foo() {} } | 19:08 | |
p6eval | rakudo 612bcf: OUTPUTĀ«No method named 'foo' to remove in class 'A'.ā¤current instr.: '!TOPERL6MULTISUB' pc -5310275 ((unknown file):-1)ā¤Ā» | ||
masak makes a ticket! | |||
19:08
mizioumt left
|
|||
masak | uuh, flaky connection... | 19:09 | |
jnthn | Ah, yes. We actually re-bless blocks now so that's an easy fix too (wasn't really fixable back when multis were first put in...) | ||
19:12
mizioumt1 left,
ejs joined
19:13
masak left
19:17
justatheory left
19:20
donaldh left,
donaldh joined
19:23
masak` joined,
masak joined,
masak left
19:24
[particle]1 left
19:31
masak` left
19:54
nihiliad left,
nihiliad joined
|
|||
TimToady | pmichaud: I believe the distinction between Cursor and Match objects will solve the .print problem | 20:00 | |
20:00
pmurias left,
pmurias joined
|
|||
TimToady | $cursor.print is <print>, whereas $match.print is Any.print | 20:01 | |
a Match is basically a "dead" Cursor | |||
with not much more interface than Capture | 20:02 | ||
and it's the .parse boundary that kills the returned Cursor and makes it a Match | 20:03 | ||
pmichaud | would it be (more) correct to say that we build a Match from the returned Cursor ? | 20:04 | |
TimToady | possibly | ||
pmichaud | okay. | ||
I like that distinction. It makes several things much easier. | |||
TimToady | maybe the Match is just a Capture plus link to the returned Cursor | ||
to which we delegate .from and .to | |||
and it makes it possible to continue a match from a Match object using Match.parse, maybe | 20:05 | ||
pmichaud | currently PGE has Match.next (but Match.parse would be fine) | ||
20:05
mib_5ckh6m joined
|
|||
TimToady | well, whatever, we just want to keep the accidental collisions down | 20:06 | |
pmichaud | Agreed, and that explanation (plus the one you gave last week) is a huge help. | ||
20:06
ingynap is now known as ingy
|
|||
TimToady | anyway, that seems to be closer to the STD model of Cursor vs Match | 20:06 | |
jnthn | I think I even sort of get it now. :-) | ||
TimToady: I'm guessing on the traits, it's best if I leave you to ponder exactly what to do there for a while, and look out for some updates to S14, before digging in with implementation. | 20:07 | ||
TimToady | yeah, still puzzling that out | ||
jnthn | OK, thanks. :-) | ||
pmichaud | I'm wondering how I can get the Cursor/Match distinction into PGE without breaking too much existing code. | 20:08 | |
ingy | 5hola | ||
pmichaud | I guess I should start by (re)writing it the way I want it to ultimately look, and then I'll figure out what shims I need for backwards compat | ||
ingy | hmmm | ||
TimToady | pmichaud: you could rebless for now | ||
we've been ingified! | 20:09 | ||
ingy | hi gang | ||
pmichaud | well, I can certainly get Rakudo to do something close to the right thing, by giving Rakudo its own Match class (which it has) that treats PGE's Match class as if it is a Cursor | ||
TimToady | what's cookin'? | ||
ingy | y'all headed to YAPC? | ||
jnthn | hi ingy | ||
TimToady | which one? | 20:10 | |
jnthn | wh...? :-) | ||
pmichaud | instead of making Rakudo's Match class as a subclass of PGE's Match | ||
ingy | I was thinkng PA | ||
jnthn | Ah, not me. | ||
pmichaud | I'm headed to ::NA and (hopefully) ::EU | ||
TimToady | YAPC::PA haven't heard of that one | ||
jnthn | I'm doing ::EU and ::Asia. | ||
ingy | YAPC Perl America | ||
TimToady | ::Asia is the only doubtful one currently | ||
20:11
justatheory joined
|
|||
TimToady | well, not even doubtful, just a bit doubted | 20:11 | |
ingy | jnthn: awesome. look forward to seeing you in tokyo | ||
TimToady | just haven't planned autumn at all yet | ||
ingy | TimToady: you are BIG in Japan | ||
TimToady | only among the grannies | ||
pmichaud | yapc::asia would be fun. | 20:12 | |
TimToady | the youngsters tend to be larger | ||
ingy | TimToady: I been cooking on this testml.org/spec/ | ||
TimToady | ah, yes | ||
pmichaud | I don't have a September trip planned yet :-). So far I've had a trip every month this year. | ||
jnthn | pmichaud: BTW, I plan to go wonder around Japan and South Korea for a few weeks after YAPC::Asia. | ||
TimToady | I try to keep it to once a month | ||
pmichaud | (and have one-per-month through August) | ||
jnthn | pmichaud: So don't expect too much of me on Rakudo in sep. ;-) | 20:13 | |
ingy | pmichaud: do tokyo! | ||
pmichaud | jnthn: okay, I'll try not to expect too much. | ||
TimToady | jnthn: you won't be done by then? | ||
pmichaud | ingy: depends on funding. :-) | ||
ingy | I'll buy you some soba and beer | ||
jnthn | TimToady: Depends on the spec being done by then. ;-) | 20:14 | |
TimToady | oh well... | ||
20:14
mib_5ckh6m left
|
|||
ingy | seen masak | 20:14 | |
moritz_ | @seen masak | 20:15 | |
lambdabot | I saw masak leaving #perl6 51m 6s ago, and . | ||
ingy | thx | ||
pmichaud | That dangling conjunction leaves a lot of room for imagination... :-) | ||
jnthn | pmichaud: I'm having some bits of vacation in June and July too, but be doing bits when I'm around. :-) | ||
pmichaud | jnthn: Good. | ||
vacation++ | |||
jnthn | Yeah, will want it. | 20:16 | |
ingy is on permanent vacation | |||
pmichaud | I'm doing vacations in June/July as well. After YAPC::NA Paula and I are doing some travelling in PA | ||
jnthn | Ah, that overlaps with when I'm away too. | ||
moritz_ is away most of June | 20:17 | ||
in beautiful norway | |||
jnthn | moritz_: You must learn to hate beer before you travel there. | ||
TimToady | or hate money | ||
moritz_ | jnthn: I already do. | ||
pmichaud | jnthn: due to quality or cost? ;-) | 20:18 | |
jnthn | pmichaud: Cost. The quality is pretty OK. ;-) | ||
(And sometimes very OK.) | |||
dalek | kudo: bd9fafc | pmichaud++ | src/builtins/match.pir: Update make() to give a slightly more useful warning when $/ not set. |
||
ingy | beer is frickin expensive in .no | ||
jnthn | yeah...makes Sweden look like good value. | 20:19 | |
ingy | :) | ||
20:19
Eevee joined
|
|||
pmichaud | hey, dalek, where's the other commit?!? | 20:19 | |
Hmmpf. | 20:20 | ||
jnthn | dalek has selective interests. | ||
moritz_ | pmichaud CAN HAZ COMMIT, BUT DALEK EATED IT | ||
20:20
wtm joined
|
|||
jnthn | oh, hmm, I think I forgot to push some stuff I comitted earlier.. | 20:21 | |
20:21
wtm left
|
|||
jnthn | oh yes, I did. fail | 20:21 | |
Tene | pmichaud: any chance you can get export working on ops? | ||
pmichaud | Tene: it doesn't work? | 20:22 | |
Tene | not as of this morning | ||
pmichaud | I'm surprised. Seems like it shouldn't make a difference. | ||
can you post a simple example, when you get a chance? | |||
jnthn | fwiw I exported a trait_auxiliary and it worked... | 20:23 | |
moritz_ | it works here | ||
jnthn | Tene: Is it a new operator or an overload of an existing one? | ||
moritz_ | (for a new operator) | ||
dalek | kudo: 52d8f28 | jnthn++ | src/builtins/guts.pir: First crack at applying custom user traits to blocks. Hopefully we can eventually get rid of the special cases. A spectest fails if we blow up on unknown triats, so for now we'll just warn. |
20:24 | |
kudo: ce81644 | jnthn++ | src/parser/ (2 files): Start parsing and emitting trait_auxiliary definitions. |
|||
jnthn | dalek. I totally comitted those in the _opposite_ order. | ||
pmichaud | dalek often gets them backwards. | ||
moritz_ | nopaste.snit.ch/16550 | 20:25 | |
Tene | Foo.pm: multi sub infix:<Ā±> { ... } | ||
20:25
ejs left
|
|||
Tene | test.pl: use Foo; 1 Ā± 2 | 20:25 | |
even with an "is export" which is implied by multi | 20:26 | ||
moritz_ | Tene: look at my nopaste above | ||
pmichaud | I don't know if Rakudo has "multi implies export" yet. | ||
Tene | moritz_: can't conveniently. | ||
TimToady | do you have it in a module or a role? | 20:27 | |
Tene | oh, it works for infix:<xxxxx> | ||
but not for Ā± | |||
moritz_ | module Foo { multi sub postfix:<!>(Int $x) is export(:DEFAULT) { ... } }; | ||
Tene | but works for Ā± if deffined in the same file | 20:28 | |
moritz_ | Tene: Unicode doesn't work on -e ... | 20:29 | |
jnthn | Tene: You ain't pre-compiling at all? | ||
Tene | moritz_: no -e | ||
files | |||
no pre-compiling | |||
moritz_ | ah, I can reproduce it here | ||
pmichaud | I can reproduce it also. But it doesn't quite make sense to me. | ||
Tene | I'm playing with set ops... :) | 20:30 | |
jnthn | pmichaud: Maybe it's losing its unicode-ness somewhere during the export? | ||
(Don't ask me where... :-|) | |||
(But it wouldn't entirely surprise me...) | |||
pmichaud | I'm wondering if this is more of that weird Parrot bug we once found | ||
jnthn | The hashes one? | 20:31 | |
pmichaud | yes. | ||
jnthn | Namespaces are based on hashes. | ||
pmichaud | but it's also not working for me with infix:<abc> | ||
jnthn | So entirely possible. | ||
pmichaud | (which doesn't have any unicodeness) | ||
No applicable candidates found to dispatch to for 'infix:abc' | |||
moritz_ | but it parses infix:abc, no? | 20:32 | |
pmichaud | yes. | ||
jnthn | pmichaud: What are you defining? a multi in a class|role|module? | ||
pmichaud | yes, in a module. | 20:33 | |
jnthn | OK | ||
pmichaud | gist.github.com/111891 | ||
jnthn | looking | 20:34 | |
pmichaud: Well no wonder | 20:35 | ||
You wrote an arity 0 multi candidate. | |||
pmichaud | multis require a signature? | 20:36 | |
okay. | |||
jnthn | multi sub infix:<abc>($x, $y) is export(:DEFAULT) { 1 } | ||
# works fine | |||
No, but if you're going to define an infix operator you need to define parameters to tkae the two operands, surely? | |||
pmichaud | no, with no signature it should default to (*@_, *%_) | 20:37 | |
jnthn | ugh | ||
pmichaud | ....which might not be properly implemented yet | ||
because I still haven't finished fixing @_ and %_ | |||
jnthn | rakudo: sub foo { }; say &foo.signature.perl | ||
pmichaud | (which are seriously broken) | ||
p6eval | rakudo 52d8f2: OUTPUTĀ«:()ā¤Ā» | ||
jnthn | Ah | ||
moritz_ | rakudo: sub foo { }; foo(3) | ||
pmichaud | rakudo: sub foo { @_ }; say &foo.signature.perl | ||
jnthn | I think it's jsut that they're not defining a signature. | ||
p6eval | rakudo 52d8f2: ( no output ) | ||
rakudo 52d8f2: OUTPUTĀ«:(Any *@_)ā¤Ā» | |||
pmichaud | see? @_ is broken :-) | 20:38 | |
moritz_ | that's wrong. | ||
why the Any? | |||
anyway | |||
moritz_ works on tests for exporting operators | |||
jnthn | pmichaud: Once those get signatures the MMD should be happy. | ||
pmichaud | because subs assume Any on their parameters. I agree it should be Object. | ||
okay, so we know why the infix:<abc> was failing and now works. Now for unicode. | 20:39 | ||
gist.github.com/111898 | 20:40 | ||
jnthn | heh, my first attempt got me | ||
Malformed UTF-8 string | 20:41 | ||
pmichaud | I'm almost certain it's the hash issue again. | ||
oh, perhaps not. Hmmm. | 20:42 | ||
moritz_ | rakudo: sub infix:<a>($a, $b) { $a + $b }; say eval '3 a 5' | ||
p6eval | rakudo 52d8f2: OUTPUTĀ«8ā¤Ā» | ||
ruoso often still types $foo.'bla' instead of $foo ~ 'bla' | |||
moritz_ | ruoso: you don't write enough Perl 6 ;-) | ||
jnthn | pmichaud: OK, now after getting my editor not to save it was the wrong thing it works... :-) | 20:44 | |
erm | |||
damm | |||
it gives the same error as your'e seeing | |||
pmichaud | "name" => "infix:\x{c2}\x{b1}", | 20:45 | |
moritz_ | that loos so wrong. | 20:46 | |
*looks | |||
pmichaud | yes, it's saving the utf-8 version. | ||
jnthn | ah. | 20:47 | |
pmichaud | I don't understand why/how, though. | ||
jnthn | pmichaud: Is that in the call to the parser to register the token? | ||
ruoso | does rakudo tries to load .pbc files first when in "use"? | ||
pmichaud | ruoso: yes. | 20:48 | |
ruoso | cool | ||
pmichaud | jnthn: no | ||
here's the call to register the token (that is in the Foo PIR) | |||
$P45."newtok"(unicode:"infix:\x{b1}", "infix:+" :named("equiv")) | |||
but there are two calls. | |||
moritz_ | perl6: say chr(:16('b1')) | ||
p6eval | pugs, rakudo 52d8f2: OUTPUTĀ«Ā±ā¤Ā» | ||
..elf 26831: OUTPUTĀ«Unknown rule: rad_numberā¤It needs to be added to ast_handlers.ā¤ at ./elf_h line 2850ā¤Ā» | |||
pmichaud | there's a call to add the token to the optable immediately after parsing the signature | 20:49 | |
and then of course the generated code has one that occurs at :load :init | |||
jnthn | Yes, and one in the PIR for the PBC. | ||
OK, and the one to do it immediately is wrong? | 20:50 | ||
pmichaud | I can't see how. If it was wrong, then it wouldn't work in the case where we're defining a token in the same file. | ||
jnthn | pmichaud: If I pre-compile Foo.pm to Foo.pir it works. | ||
pmichaud | yes. | ||
but there must still be something else happening here. | 20:51 | ||
when I do 'use Foo.pm', it should still be invoking the :load :init calls that are generated in the PIR | |||
and that should be adding the token to the optable. | |||
jnthn | Right, 'cus they are :init | ||
pmichaud | er, "use Foo" (from the .pm) | ||
jnthn | pmichaud: It couldn't be that the second time causes a problem because it fails to detect the token is already registered or something? | 20:52 | |
pmichaud | as far as the optable is concerned, they should be different tokens. | ||
jnthn | Wait, that still wouldn't make sense...hmm | ||
pmichaud | because they have different names. | ||
pugs_svn | r26832 | moritz++ | [t/spec] importing operators | 20:54 | |
pmichaud | what really confuses me is that it does all seem to work for Ā« and Ā» | 20:59 | |
20:59
tombom left
|
|||
dalek | kudo: fe54884 | moritz++ | t/spectest.data: test importing of operators |
20:59 | |
moritz_ | rakudo: sub infix:< ab >($a, $b) { say $b, $a }; 3 ab 4; | 21:00 | |
p6eval | rakudo fe5488: OUTPUTĀ«43ā¤Ā» | ||
jnthn | pmichaud: Those are also in Latin-1 - wonder if there's some confusion somewhere... | ||
moritz_ | rakudo: sub infix:Ā« ab Ā»($a, $b) { say $b, $a }; 3 ab 4; | ||
p6eval | rakudo fe5488: OUTPUTĀ«43ā¤Ā» | ||
pmichaud | \xb1 is latin-1 also, though. | 21:01 | |
jnthn | ah, true | ||
21:01
ZuLuuuuuu joined
|
|||
jnthn | pmichaud: In perl6.pir we do | 21:03 | |
## tell PAST::Var how to encode Perl6Str and Str values | |||
We're not somehow missing this setup (or other encoding related setup) when we invoke PAST::Compiler, are we? | |||
pmichaud | that just tells PAST that it needs to escape strings. | ||
it's global, and by the time PAST::Compiler is run from actions.pm it's been long setup. | 21:04 | ||
jnthn | OK. | ||
pmichaud | if that was missing, then Perl6Str and Str would end up completely unquoted (and we'd have PIR syntax errors) | ||
jnthn | Ah, true. | ||
pmichaud | i.e., the pir output would say (bare) infix:+- instead of unicode:"infix:\x{b1}" | 21:05 | |
jnthn | Right. | 21:06 | |
Hmm. | |||
pmichaud | Oh! | ||
I might know the problem. | |||
21:07
skids left
21:08
frew|work left
|
|||
pmichaud | a-ha! | 21:08 | |
result = 'evalfile'(realfilename, 'lang'=>'Parrot') | |||
it's not reading it as utf-8 | |||
(this is inside of 'require', which is called by 'use') | |||
jnthn | Ah! | 21:09 | |
That'd do it. | |||
pmichaud | in particular | 21:10 | |
.tailcall compiler.'evalfiles'(filename) | 21:11 | ||
I think HLLCompiler needs some attributes to indicate what its preferred input encoding and transcoding are | |||
instead of requiring them from the options | 21:12 | ||
jnthn | That could be a neater way, yes. | ||
pmichaud | well, 'evalfile' takes a :lang parameter, and other languages might not assume utf8, so we really shouldn't be forcing it. | ||
[particle]- | you should look it up in the lang, then | 21:13 | |
pmichaud | no, just let the compiler itself decide. | ||
for a Perl 6 compiler, it would default to utf8 | 21:14 | ||
actually, each HLLCompiler should probably have a hash of any defaults it wants to set. | |||
ruoso | hmmm... interesting... even after having everything compiled down to pbc... it still takes a huge time to start... | ||
pmichaud | instead of separate attributes for each possible option. | ||
ruoso: parsing speed is no longer our only bottleneck. | 21:15 | ||
ruoso | but I mean... it still takes a huge time... | ||
oh wait... | |||
the Web.pm files are not compiled | |||
pmichaud | gist.github.com/111930 # now works! | 21:17 | |
moritz_ | pmichaud: I also committed a test file for that | 21:18 | |
jnthn | pmichaud: Nice! | ||
moritz_ | 20 minutes ago or so | ||
ruoso | pmichaud, :DEFAULT is now the default in the spec | ||
pmichaud | I'll go ahead and push this change without doing a spectest first -- it's really minor. | ||
ruoso | (or did someone revert that?) | ||
pmichaud | ruoso: yes, :DEFAULT may be the default -- I was just being extra-explicit to reduce number of potential variables. | 21:19 | |
jnthn | ruoso: Shouldn't need to write :DEFAULT in Rakudo. | ||
ruoso | ok then | ||
[particle]- | ruoso: he was testing unicode operators there, not export tags, in case you missed it | ||
ruoso | ah... | 21:20 | |
pmichaud | yes, it works without :DEFAULT | 21:22 | |
(running a complete spectest now, too) | |||
dalek | kudo: c223b06 | pmichaud++ | src/builtins/eval.pir: When reading Perl 6 files, evalfiles needs to assume utf8 encoding. |
21:23 | |
kudo: f7dbcce | pmichaud++ | : Merge branch 'master' of [email@hidden.address] |
|||
moritz_ | wow, compiling perl6 with optimization really needs much memory | 21:25 | |
like, 1.3G or so | |||
21:26
exodist left
|
|||
moritz_ | pmichaud: you'll see a plan failure in imported-subs.t | 21:27 | |
pmichaud: that's my error, no need to worry ;-) | 21:28 | ||
pugs_svn | r26833 | moritz++ | [t/spec] unfudge and fix imported-subs.t | ||
ruoso hits some weird bug again | 21:32 | ||
21:32
hercynium left,
hercynium joined
21:36
frew joined
|
|||
moritz_ | assign.t segfaults after 166 tests here | 21:36 | |
rakudo: say (1..10).reduce: &infix:<+> | 21:39 | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«Null PMC access in find_method()ā¤current instr.: 'parrot;P6object;WHAT' pc 83 (runtime/parrot/library/P6object.pir:114)ā¤Ā» | ||
moritz_ | rakudo: say &infix:<+>(3, 4) | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«7ā¤Ā» | ||
moritz_ | rakudo: say &infix:<+>(3, 4, 5) | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«too many arguments passed (3) - 2 params expectedā¤current instr.: 'infix:+' pc 22572 (src/builtins/op.pir:292)ā¤Ā» | ||
moritz_ | rakudo: say (1..10).list.reduce: &infix:<+> | 21:40 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«Null PMC access in find_method()ā¤current instr.: 'parrot;P6object;WHAT' pc 83 (runtime/parrot/library/P6object.pir:114)ā¤Ā» | ||
ruoso getting invoke() not implemented in class 'ResizablePMCArray' when trying to invoke a method in a object... any idea of what it can be? | 21:41 | ||
ruoso getting that line twice, which is the most strange part | |||
moritz_ | I'm sure I've seen that before... | ||
ruoso: are junctions involved? | 21:42 | ||
ruoso | no... | ||
21:42
LylePerl left
21:43
hercynium left,
jnthn left,
buu left,
Maddingue left
|
|||
moritz_ | rakudo: my $p = &infix:<+>; say (1..10).list.reduce: $p; | 21:43 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«Parameter type check failed; expected something matching Code but got something of type Array() for $expression in call to reduceā¤current instr.: 'die' pc 16712 (src/builtins/control.pir:225)ā¤Ā» | ||
ruoso | it's a plain method call, and I have a line with say $action.WHAT just before the failure | ||
moritz_ | rakudo: my $p = &infix:<+>; say $p.PARROT | 21:44 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«Perl6Scalar->Perl6Arrayā¤Ā» | ||
moritz_ | rakudo: my $p = &infix:<+>; say $p.perl | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«[{ ... }, { ... }, { ... }, { ... }, { ... }, { ... }, { ... }, { ... }]ā¤Ā» | ||
moritz_ | rakudo: my $p = &infix:<+>; say $p.map: { .WHAT } | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«Code()Code()Code()Code()Code()Code()Code()Code()ā¤Ā» | ||
moritz_ | rakudo: my $p = &infix:<+>; say $p.map: { .signature.perl } | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«undefundefundefundefundefundefundefundefā¤Ā» | ||
moritz_ | "Huh." | 21:45 | |
21:45
jnthn joined,
Maddingue joined,
buu joined,
irc.freenode.net sets mode: +o jnthn,
ab5tract left
|
|||
pasteling | "ruoso" at 189.97.48.190 pasted "failure when trying to invoke a method...." (2 lines, 133B) at sial.org/pbot/36622 | 21:47 | |
pmichaud | rakudo: say Multi ~~ Code; | 21:48 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«1ā¤Ā» | ||
pmichaud | rakudo: say &infix:<+>.WHAT; | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«Null PMC access in find_method()ā¤current instr.: '!dispatch_method' pc 17954 (src/builtins/guts.pir:113)ā¤Ā» | ||
pmichaud | rakudo: say &infix:<+> ~~ Code; | 21:49 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«Null PMC access in find_method()ā¤current instr.: 'parrot;P6object;WHAT' pc 83 (runtime/parrot/library/P6object.pir:114)ā¤Ā» | ||
21:49
iblechbot left
|
|||
pmichaud | I'm guessing that infix:<+> isn't blessed as a Perl6MultiSub | 21:50 | |
21:51
amoc joined
|
|||
frew | if I have a class method, (A.bar vs $a.bar) how do I distinguish which is being called in the method? | 21:51 | |
moritz_ | if self === A { class method } else { instance method } | 21:52 | |
but usually you don't need any distinction | |||
ruoso commits his last version of Faz+Yarn and pushes... | |||
frew | I was just curious | 21:53 | |
21:53
nihiliad left
|
|||
moritz_ | curiosity is good ;-) | 21:53 | |
frew | and is there a modifier to do that with dispatch? | ||
pmichaud | also potentially use defined | ||
ruoso decommute & | |||
21:53
ruoso left
|
|||
pmichaud | if .defined { class method } else { instance method } | 21:53 | |
er, backwards | |||
if .defined { instance method } else { class method } | 21:54 | ||
to do it in a signature, perhaps | |||
moritz_ | pmichaud: $.defined, not .defined | ||
frew | gotcha | ||
pmichaud | method bar($_ where .defined:) { ... } | ||
moritz_ | pmichaud: uhm, can there be any more constraints on the invocant? | ||
rakudo: class A { multi method bar ($_ where .defined:) { say "a" } }; A.new.bar | 21:55 | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«aā¤Ā» | ||
moritz_ | rakudo: class A { multi method bar ($_ where .defined:) { say "a" } }; A.bar | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«Could not locate a method 'bar' to invoke on class 'A'.ā¤current instr.: 'die' pc 16712 (src/builtins/control.pir:225)ā¤Ā» | ||
pmichaud | :-) | ||
frew | I'm surprised that there's no sugar for class vs instance methods | ||
moritz_ | frew: that's because it's usually not needed | ||
frew | but that's still multi dispatch, so in my mind, still turtles | ||
yeah, definitely | 21:56 | ||
moritz_ | frew: if one needs it, there's always the option of writing a module for that (for example via a trait) | ||
frew | I don't think I've actually used Class methods at work ever | ||
moritz_ | frew: I'm sure you did ;-) | ||
frew | sure, and I'm all for that. I never said it should be in the language | ||
moritz_ | frew: constructors are usually class methods, in some sense | ||
frew | ok, those don't count | ||
moritz_ | ;-) | ||
frew | although I think the config stuff I do probably is | 21:57 | |
21:57
payload joined
|
|||
pmichaud | I've used class methods a fair bit, but rarely in situations where I needed them to be completely separate from instance methods. | 21:57 | |
There was discussion last week about method, metamethod, and meta to distinguish the invocants | |||
frew | interesting | ||
moritz_ | "I never metamodel not obsessed with reflection" -- chromatic | ||
pmichaud | irclog.perlgeek.de/perl6/2009-05-08#i_1128584 | 21:58 | |
frew | well, the where thing is fine for starters and if it becomes a need using an attribute would prorbaly be fine | ||
that doesn't parse...should it? | |||
moritz_ | frew: what? | ||
frew | what chromatic said | 21:59 | |
it seems like it's missing a word or something... | |||
moritz_ | frew: metamodel and met a model | ||
frew: it's an intional pun/misparse | |||
perlgeek.de/blog-en/perl-6/custom-o....writeback | |||
frew | got it | 22:00 | |
Tene | I'm going to implement "is autodispatched" for methods for s1n. | 22:02 | |
pmichaud | Tene: hmmm? | ||
Tene | afk, driving. | ||
lichtkind | moritz_: why you dont use macro in the example in >perlgeek.de/blog-en/perl-6/custom-o....writeback ? | 22:05 | |
moritz_ | Tene: if you have some spare tuits, I'd know a good task: 'class Foo is also' is now called 'augment class Foo', and we're regresssing on a few tests there. | ||
lichtkind: because macros are not yet implemented | |||
22:05
plu joined
|
|||
lichtkind | moritz_: gute antwort :) | 22:05 | |
pmichaud | I do have to say that changing 'is also' to 'augment' is (to me at least) very non-trivial. | ||
frew | plus, isn't defining an operator cleaner than a macro? | 22:06 | |
rakudo: say [*] 1..8 | |||
p6eval | rakudo f7dbcc: OUTPUTĀ«40320ā¤Ā» | ||
moritz_ | pmichaud: that's why I ask Tene to do it, and don't try myself ;-) | ||
frew | rakudo: say [*] 1..3 | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«6ā¤Ā» | ||
frew | rakudo: say [+] 1..3 | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«6ā¤Ā» | ||
frew | rakudo: say [~] 1..3 | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«123ā¤Ā» | ||
lichtkind | frew: macros are sub called at compiletime | ||
frew | ah, got it | 22:07 | |
I can see how that could be good I guess | |||
rakudo: say (1..3).reduce({ $^a + $^b }) | |||
p6eval | rakudo f7dbcc: OUTPUTĀ«6ā¤Ā» | ||
frew | rakudo: say (1..3).reduce({ $^a * $^b }) | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«6ā¤Ā» | ||
frew | how does it know the initial value? | ||
moritz_ | macros can also have more syntactic freedom than operators | 22:08 | |
pmichaud | frew: it's (1 + 2) + 3 | ||
moritz_ | frew: it just takes the first item as initial value (reduce, at least) | ||
pmichaud | frew: and (1 + 2) * 3 | ||
er, | |||
(1 * 2) * 3 | |||
moritz_ | rakudo: say [+] () | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«0ā¤Ā» | ||
moritz_ | rakudo: say [*] () | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«1ā¤Ā» | ||
moritz_ | those are hard-coded for now | 22:09 | |
pmichaud | oh, for the reduction operators -- yes, they're defined by the spec. | ||
moritz_ | the spec says we just call nullary infix:<+>() | ||
which returns the initial value | |||
frew | that's cool | ||
moritz_ | so that when you define new operators, you can also provide your own initial value | ||
frew | rakudo: my $c = 3; say (1..3).reduce({ $^a + $^b * $c-- }) | 22:10 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«13ā¤Ā» | ||
moritz_ | rakudo: say 1 + (2*3) + (2*2) | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«11ā¤Ā» | ||
moritz_ | rakudo: say 1 + (2*3) + (3*2) | 22:11 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«13ā¤Ā» | ||
jnthn | (backlogging) (operators not Perl 6 multi subs) I figured that'd come when we could define the operators in Perl 6 | ||
moritz_ | it helps not to mis-type ;-) | ||
frew | and if I wanted to set the first one? | ||
pmichaud | jnthn: I'm experimenting with registering MultiSub as Multi | ||
moritz_ | frew: what do you mean by "set the first one"? | 22:12 | |
frew | the initial value, sorry | ||
just change the list? | |||
moritz_ | yes | ||
frew | hmmm | ||
pmichaud | but even then it doesn't get us as far as we'd probably like | 22:13 | |
multi sub a(Int $x, Int $y) { return 1; } | |||
multi sub a(Str $x, Str $y) { return 'foo'; } | |||
say <1 2 3>.reduce(&a); | |||
Unknown introspection value 'pos_required' | |||
frew | the reason was that I was thinking I could refactor this: rafb.net/p/DP9Eqm13.html to use a reduce | ||
and in p5 it actually turned out to be harder to use a reduce than a regular for loop | 22:14 | ||
but I guess that is really because it has side effects | |||
jnthn | (still backlogging) (augment) I've been thinking that gets cleaner with context vars | ||
pmichaud | jnthn: (context vars) yes, but we have to be able to define and set them in the grammar. | 22:15 | |
moritz_ | frew: there's something better for Perl 6, I guess.. | ||
pmichaud | sure, the checkdigit is easier in perl6 | ||
moritz_ | rakudo: say (1, 0, 1, 0 Ā»*Ā« 1..4).perl | ||
frew | ... | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«Multiple Dispatch: No suitable candidate found for 'cmp', with signature 'PP->I'ā¤current instr.: 'parrot;Range;!to_test' pc 9563 (src/classes/Range.pir:250)ā¤Ā» | ||
jnthn | pmichaud: Registering multisub (parrot's) as multi probably won't help. | ||
frew | moritz_: is that really equiv? | 22:16 | |
pmichaud | [+] @digits[*] >>*<< 1..@digits | ||
moritz_ | rakudo: say (1, 0, 1, 0 Ā»*Ā« (1..4).list).perl | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«[1, 0, 1, 0, 0, 0, 0]ā¤Ā» | ||
22:16
lichtkind_ joined
|
|||
pmichaud | my @digits = <1 2 3 4>; say @digits >>*<< 1..@digits; | 22:16 | |
rakudo: my @digits = <1 2 3 4>; say @digits >>*<< 1..@digits; | |||
moritz_ | uhm... that looks wrong | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«Non-dwimmy hyperoperator cannot be used on arrays of different sizes or dimensions.ā¤current instr.: 'die' pc 16712 (src/builtins/control.pir:225)ā¤Ā» | ||
jnthn | pmichaud: Either we can move operators to the setting, or we need to do the equivalent of giving the blocks a loadinit kinda thing. | ||
pmichaud | rakudo: my @digits = <1 2 3 4>; say @digits[*] >>*<< 1..@digits; | 22:17 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«Non-dwimmy hyperoperator cannot be used on arrays of different sizes or dimensions.ā¤current instr.: 'die' pc 16712 (src/builtins/control.pir:225)ā¤Ā» | ||
pmichaud | rakudo: my @digits = <1 2 3 4>; @digits[*].perl.say | ||
jnthn | pmichaud: That calls !TOPERL6MULTISUB | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«["1", "2", "3", "4"]ā¤Ā» | ||
moritz_ | rakudo: say 1, 2, 3 >>*<< 3, 4, 5 | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«12945ā¤Ā» | ||
moritz_ | rakudo: say 1, 2, 3 >>*<< 3..5 | ||
pmichaud | jnthn: for the problem I'm trying to resolve, even converting to Perl6MultiSub doesn't help. | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«Multiple Dispatch: No suitable candidate found for 'cmp', with signature 'PP->I'ā¤current instr.: 'parrot;Range;!to_test' pc 9563 (src/classes/Range.pir:250)ā¤Ā» | 22:18 | |
jnthn | pmichaud: I think I missed the problem? | ||
pmichaud | jnthn: suppose we want @list.reduce(&infix:<+>) | ||
frew | rakudo: say (1..3) >>*<< (3..5) | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«3815ā¤Ā» | ||
pmichaud | there's not presently a way to determine .arity of &infix:<+> | ||
(or of any Multi) | |||
jnthn | rakudo: multi foo() { }; multi foo($x) { }; say &foo.candidates>>.arity | 22:19 | |
moritz_ | rakudo: my @a = 4, 2, 3, 1; say @a Ā»+Ā« (1..@a) | ||
22:19
LadyLunacy left
|
|||
p6eval | rakudo f7dbcc: OUTPUTĀ«01ā¤Ā» | 22:19 | |
rakudo f7dbcc: OUTPUTĀ«5465ā¤Ā» | |||
jnthn | pmichaud: Like that. | ||
pmichaud | jnthn: in which case .reduce needs to know to call >>.arity instead? | 22:20 | |
moritz_ | rakudo: my @a = 4, 2, 3, 1; say [+] @a Ā»+Ā« (1..@a) | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«20ā¤Ā» | ||
moritz_ | frew: see above ;-) | ||
jnthn | pmichaud: What does reduce need to know? | ||
pmichaud: The arities of the available candidates? | |||
pmichaud | how many arguments to pass to the sub provided as an argument | ||
frew | moritz_: it doesn't seem to be doing what I expect, but I'm playing with it | ||
either way, I see what you mean | |||
jnthn | pmichaud: Even if you define .arity on multi, there's no one answer so I guess you'd get a junction back. | 22:21 | |
pmichaud | jnthn: right. | ||
rakudo: say &infix:<+>.candidates>>.arity; | |||
p6eval | rakudo f7dbcc: OUTPUTĀ«Null PMC access in find_method()ā¤current instr.: '!dispatch_method' pc 17954 (src/builtins/guts.pir:113)ā¤Ā» | ||
jnthn | pmichaud: Thing is, you can't easily know even then because what if the multi has an arity 2 that was incompatible with the types you were offering? | ||
pmichaud | jnthn: right, I'm saying it's a place where the spec doesn't quite dwim (for various values of "im") | 22:22 | |
i.e., people will expect one thing but not get quite what they expect. | |||
jnthn | pmichaud: The other thing about a multi in reduce is that if there's different types in the list things are gonna get fun too. | ||
frew | what does @f >>*<< @f[*] do? | 22:23 | |
jnthn | You won't even dispatch to the same variant each time then...and again, in the worst case, the arity available would depend on types... | ||
frew | $x * index_of_$x ? | ||
pmichaud | frew: gives you an array of the squares | ||
jnthn | frew: Shouldn't it be the same as @f >>*<< @f? | ||
frew | I don't know | 22:24 | |
moritz_ | rakudo: my @a = 1..5; @aĀ».sqrt; say @a.perl | ||
pmichaud | my @a = <1 2 3 4>; say [+] @a >>*<< (1..@a) | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«[1, 2, 3, 4, 5]ā¤Ā» | ||
moritz_ | rakudo: my @a = 1..5; @aĀ».=sqrt; say @a.perl | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«[1, 1.4142135623731, 1.73205080756888, 2, 2.23606797749979]ā¤Ā» | ||
pmichaud | rakudo: my @a = <1 2 3 4>; say [+] @a >>*<< (1..@a) | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«30ā¤Ā» | ||
pmichaud | rakudo: my @a = <4 3 2 1>; say [+] @a >>*<< (1..@a) | 22:25 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«20ā¤Ā» | ||
moritz_ | bed & | ||
frew | what if I want to do this: | ||
rakudo: [+] @a >>*<< (@a..1) | |||
p6eval | rakudo f7dbcc: OUTPUTĀ«Scope not found for PAST::Var '@a' in ā¤current instr.: 'parrot;PCT;HLLCompiler;panic' pc 146 (src/PCT/HLLCompiler.pir:105)ā¤Ā» | ||
pmichaud | frew: @a >>*<< (1..@a) produces ($a[0]*1, $a[1]*2, $a[2]*3, $a[3]*4, ...) | ||
rakudo: my @a = <4 3 2 1>; say [+] @a >>*<< (1..@a).reverse | 22:26 | ||
frew | right, what if I want the reverse of that, so $a[0] * @a.elems | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«30ā¤Ā» | ||
frew | ahh | ||
nice | |||
pmichaud | rakudo doesn't implement it yet, but one could also do @a..1 :by(-1) | ||
frew | for some reason the check digit isn't working... | 22:27 | |
22:27
LadyLunacy joined
|
|||
frew | I need to play with it some thing | 22:27 | |
thanks guys | |||
pmichaud | have an example input? | ||
frew | yeah | ||
773218 should check to 5 | |||
and rafb.net/p/NsOkuA12.html | 22:28 | ||
that's the algorithm we use at work | |||
pmichaud | rakudo: my @digits = '773218'.split(''); @digits.perl.say; | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«["7", "7", "3", "2", "1", "8"]ā¤Ā» | ||
pmichaud | rakudo: my @digits = '773218'.split(''); say [+] @digits >>*<< 1..@digits; | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«Non-dwimmy hyperoperator cannot be used on arrays of different sizes or dimensions.ā¤current instr.: 'die' pc 16712 (src/builtins/control.pir:225)ā¤Ā» | ||
jnthn is a little confused by that error | |||
pmichaud | rakudo: my @digits = '773218'.split(''); say [+] @digits >>*<< (1..@digits); | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«91ā¤Ā» | 22:29 | |
frew | rakudo: my @digits = '773218'.split(''); say [+] @digits >>*<< (1..@digits) % 10; | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«6ā¤Ā» | ||
pmichaud | rakudo: my @digits = '773218'.split(''); say [+] @digits.reverse >>*<< (1..@digits); | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«105ā¤Ā» | ||
frew | rakudo: my @digits = '773218'.split(''); say [+] @digits.reverse >>*<< (1..@digits) % 10; | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«6ā¤Ā» | ||
frew | should be 5 | ||
pmichaud | rakudo: my @digits = '773218'.split(''); say [+] @digits >>*<< (1..@digits).reverse; | 22:30 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«105ā¤Ā» | ||
pmichaud | rakudo: my @digits = '773218'.split(''); say ([+] @digits >>*<< (1..@digits).reverse) % 10; | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«5ā¤Ā» | ||
frew | rakudo: my @digits = '773218'.split(''); say [+] (@digits.reverse) >>*<< (1..@digits) % 10; | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«6ā¤Ā» | ||
frew | wow | ||
er | |||
rakudo: my @digits = '773218'.split(''); say [+] @digits >>*<< ((1..@digits).reverse) % 10; | |||
p6eval | rakudo f7dbcc: OUTPUTĀ«6ā¤Ā» | ||
frew | oh | ||
parens | |||
pmichaud | you want to %10 the entire sum, not just the last part | 22:31 | |
22:31
eternaleye joined
|
|||
frew | right | 22:31 | |
rakudo: my @digits = '773218'.split(''); say ([+] @digits.reverse >>*<< (1..@digits)) % 10; | |||
p6eval | rakudo f7dbcc: OUTPUTĀ«5ā¤Ā» | ||
frew | wow | ||
that is awesome | |||
eternaleye | perl6: sub infix:<...> ( Object @starter, Code &generator ) { -> { my Object @tmp = (); for 1 .. &generator.arity() -> $i { @tmp.unshift( @starter[-$i] ); }; return( &generator.( |@tmp) ); }; }; .say for ( 1, 1 ... { $^a + $^b } ); | 22:32 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«Null PMC access in get_string()ā¤current instr.: 'parrot;Role;perl' pc 255242 (src/gen_metaop.pir:23)ā¤Ā» | ||
..pugs: OUTPUTĀ«1ā¤<SubPointy(<anon>)>ā¤Ā» | |||
..elf 26833: OUTPUTĀ«/home/evalenv/pugs/misc/STD_red/match.rb:141:in `block in to_dump0': undefined method `to_dump0' for true:TrueClass (NoMethodError)ā¤ from /home/evalenv/pugs/misc/STD_red/match.rb:140:in `each'ā¤ from /home/evalenv/pugs/misc/STD_red/match.rb:140:in `map'ā¤ from | |||
../home/evalenv/pugs/mi... | |||
22:32
skids joined
|
|||
frew | rakudo: my @digits = '773218'.split(''); say ([+] @digits.reverse >>*<< (1..@digits)) % 10 == 5; | 22:32 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«1ā¤Ā» | ||
22:32
lichtkind left
|
|||
eternaleye | perl6: sub infix:<...> ( Object @starter, Code &generator ) { -> { my Object @tmp = (); for 1 .. &generator.arity() -> $i { @tmp.unshift( @starter[-$i] ); }; return( &generator.( |@tmp) ); }; }; .().say for ( 1, 1 ... { $^a + $^b } ); | 22:32 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«Null PMC access in get_string()ā¤current instr.: 'parrot;Role;perl' pc 255242 (src/gen_metaop.pir:23)ā¤Ā» | ||
..elf 26833: OUTPUTĀ«/home/evalenv/pugs/misc/STD_red/match.rb:141:in `block in to_dump0': undefined method `to_dump0' for true:TrueClass (NoMethodError)ā¤ from /home/evalenv/pugs/misc/STD_red/match.rb:140:in `each'ā¤ from /home/evalenv/pugs/misc/STD_red/match.rb:140:in `map'ā¤ from | |||
../home/evalenv/pugs/mi... | |||
..pugs: OUTPUTĀ«*** Cannot cast from VInt 1 to Pugs.AST.Types.VCode (VCode)ā¤ at /tmp/z2qne2sG1B line 1, column 189-197ā¤Ā» | |||
eternaleye | Hm. I've got most of it figured, but how can I get it to return a lazy list? | 22:33 | |
Maybe... | 22:34 | ||
pmichaud | eternaleye: note that in order for that to work, infix:<...> would have to have lower precedence than infix:<,> | ||
eternaleye | Ah | ||
pmichaud | you could parenthesize, though. | ||
eternaleye | perl6: sub infix:<...> is looser infix<,> ( Object @starter, Code &generator ) { -> { my Object @tmp = (); for 1 .. &generator.arity() -> $i { @tmp.unshift( @starter[-$i] ); }; return( &generator.( |@tmp) ); }; }; .say for ( 1, 1 ... { $^a + $^b } ); | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«Malformed routine definition at line 1, near "infix:<..."ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)ā¤Ā» | ||
..pugs: OUTPUTĀ«*** ā¤ Unexpected "infix"ā¤ expecting trait or blockā¤ at /tmp/kApkTwJlws line 1, column 27ā¤Ā» | |||
..elf 26833: OUTPUTĀ«Parse error in: /tmp/xWhYjKJvb1ā¤panic at line 1 column 16 (pos 16): No previous operator visible to adverbial pair ([#<Match:0x81c80b0 @on_str="sub infix:<...> is looser infix<,> ( Object @starter, Code &generator ) { -> { my Object @tmp = (); for 1 .. &generator.arity() -> $i { | |||
..... | |||
eternaleye | perl6: sub infix:<...> is looser infix:<,> ( Object @starter, Code &generator ) { -> { my Object @tmp = (); for 1 .. &generator.arity() -> $i { @tmp.unshift( @starter[-$i] ); }; return( &generator.( |@tmp) ); }; }; .say for ( 1, 1 ... { $^a + $^b } ); | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«Malformed routine definition at line 1, near "infix:<..."ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)ā¤Ā» | ||
..pugs: OUTPUTĀ«*** ā¤ Unexpected "infix"ā¤ expecting trait or blockā¤ at /tmp/6u5aLhNXHk line 1, column 27ā¤Ā» | |||
..elf 26833: OUTPUTĀ«Parse error in: /tmp/Yi989QbUpwā¤panic at line 1 column 16 (pos 16): No previous operator visible to adverbial pair ([#<Match:0x81c7624 @on_str="sub infix:<...> is looser infix:<,> ( Object @starter, Code &generator ) { -> { my Object @tmp = (); for 1 .. &generator.arity() -> $i | |||
..{... | |||
[particle]- | eternaleye: use rakudo: instead of perl6: to reduce noise | 22:35 | |
eternaleye | Okay | ||
pmichaud | and rakudo doesn't implement is looser/tighter/etc yet. | ||
rakudo: multi sub a() { 1; }; multi sub a($x) { $x; }; say &a ~~ Callable; | 22:36 | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«0ā¤Ā» | ||
pmichaud | rakudo: multi sub a() { 1; }; multi sub a($x) { $x; }; sub b(&x) { &x() }; b(&a); | 22:37 | |
jnthn | :-( That's a ticket. | 22:38 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«Parameter type check failed; expected something matching but got something of type Multi() for x in call to bā¤current instr.: 'die' pc 16712 (src/builtins/control.pir:225)ā¤Ā» | ||
jnthn | And that's the upshot of the first problem. | ||
pmichaud: If you file, I can fix that tomorrow. | |||
pmichaud files ticket. | |||
jnthn | pmichaud: Do you expect we'll move operators to the setting, once is tighter and is looser traits are in place? | 22:39 | |
eternaleye | rakudo: sub infix:<...> ( Object @starter, Code &generator ) { return( gather { while Bool::True { my Object @tmp = (); for 1 .. &generator.arity() -> $i { @tmp.unshift( @starter[-$i] ); }; take( &generator.( |@tmp) ); } }; ); }; .say for ( 1, 1 ... { $^a + $^b } ); | 22:40 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«Statement not terminated properly at line 1, near "( gather {"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)ā¤Ā» | ||
pmichaud | jnthn: operators don't depend on tighter/looser | ||
but beyond that, I'm getting very concerned about our startup time. | 22:41 | ||
eternaleye | rakudo: sub infix:<...> ( Object @starter, Code &generator ) { return( -> { gather { while Bool::True { my Object @tmp = (); for 1 .. &generator.arity() -> $i { @tmp.unshift( @starter[-$i] ); }; take( &generator.( |@tmp) ); }; }; }; ); }; .say for ( 1, 1 ... { $^a + $^b } ); | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«Statement not terminated properly at line 1, near "( -> { gat"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)ā¤Ā» | ||
pmichaud | (operators do depend on equiv) | 22:42 | |
eternaleye | rakudo: sub infix:<...> ( Object @starter, Code &generator ) { -> { gather { while Bool::True { my Object @tmp = (); for 1 .. &generator.arity() -> $i { @tmp.unshift( @starter[-$i] ); }; take( &generator.( |@tmp) ); }; }; }; }; .say for ( 1, 1 ... { $^a + $^b } ); | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«Null PMC access in get_string()ā¤current instr.: 'parrot;Role;perl' pc 255242 (src/gen_metaop.pir:23)ā¤Ā» | ||
eternaleye | Well that's something different. | ||
pmichaud | anyway, I'd be okay with beginning to move selected operators into the setting to see how it goes. | ||
eternaleye | rakudo: sub infix:<...> ( Object @starter, Code &generator ) { -> { gather { while Bool::True { my Object @tmp = (); for 1 .. &generator.arity() -> $i { @tmp.unshift( @starter[-$i] ); }; take( &generator.( |@tmp) ); }; }; }; }; .().say for ( 1, 1 ... { $^a + $^b } ); | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«Null PMC access in get_string()ā¤current instr.: 'parrot;Role;perl' pc 255242 (src/gen_metaop.pir:23)ā¤Ā» | ||
pmichaud | I'm still a little uncertain about how some of the basic operators will fare. We can certainly try them. | 22:43 | |
jnthn | pmichaud: Are you thinking of keeping grammar-oper.pg? | ||
pmichaud | only to define the base precedence tokens. | 22:44 | |
jnthn | pmichaud: And having that define the precedence? | ||
OK. | |||
pmichaud | Either that or we add "is precedence(...)" to the setting. | ||
jnthn | *nod* | ||
On startup time... | |||
I have a few ideas for that. | |||
pmichaud | I think I somewhat prefer the precedence identifiers to remain in grammar-oper.pg for now. That most closely matches STD.pm's approach, I think. | 22:45 | |
frew | rakudo: sub foo ( $bar where { $bar ~~ 'test' } ) { say 'test'; }; foo('test') | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«testā¤Ā» | ||
frew | rakudo: sub foo ( $bar where { $bar ~~ 'test' } ) { say 'test'; }; foo('tes') | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«Parameter type check failed; expected something matching all(Any, { ... }) but got something of type Str() for $bar in call to fooā¤current instr.: 'die' pc 16712 (src/builtins/control.pir:225)ā¤Ā» | ||
jnthn | 1) Can we collapse all of the loadinits into a single Parrot sub rather than having one for everything? | ||
pmichaud | jnthn: we can start to move that direction, yes. Having them separate makes for slightly easier debugging, though. | ||
I might be able to add annotations to simplify it when in loadinit. | 22:46 | ||
jnthn | pmichaud: We could have a "turn it off" flag somewhere. | ||
e.g. it's an opt | |||
Yes, or annotations. | |||
pmichaud | annotations would probably be sufficient. Or even :inline('# comment identifying block being loadinited') | ||
frew | rakudo: 1 ~~ /(\d)/; | ||
p6eval | rakudo f7dbcc: ( no output ) | ||
jnthn | That would mean we don't have to fall in and out of the runloop but also means we get to unpack a bunch less Sub PMCs on load. | ||
frew | rakudo: if 1 ~~ /(\d)/ { say 'true' }; | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«trueā¤Ā» | ||
jnthn | And our .pbc would shrink too. | ||
frew | rakudo: if 1 ~~ /(\d{1,8})/ { say 'true' }; | 22:47 | |
p6eval | rakudo f7dbcc: OUTPUTĀ«Statement not terminated properly at line 1, near "~~ /(\\d{1,"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)ā¤Ā» | ||
frew | rakudo: if 1 ~~ /(\d<1-8>)/ { say 'true' }; | ||
p6eval | rakudo f7dbcc: OUTPUTĀ«Statement not terminated properly at line 1, near "~~ /(\\d<1-"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)ā¤Ā» | ||
pmichaud | I had tested combining the loadinits into one previously (with only a few problems) -- I can see about doing it again. | ||
22:47
ZuLuuuuuu left
|
|||
jnthn | Another thing is trying to work out what takes time during the loadinit, since I suspect that's our main source of performance issues. | 22:47 | |
Startup performance issues, I mean. | 22:48 | ||
pmichaud | I suspect it's largely that there's a huge amount of work to be done :-| | ||
a profiler would help. :-) | 22:49 | ||
er, :-( | |||
skids | oprofile seems to work OK | ||
jnthn | I'd kind of hoped we'd not have to approach the issue too soon, but in the long run I liked to hope that we'd not construct classes and signatures at startup eventually, but instead freeze them as PMCs. | ||
pmichaud | I've never quite figured out how that's going to work | 22:50 | |
jnthn | :immediate can run a chunk of code and then it replaces the sub PMC with the PMC that the sub returned. | ||
so a .const (in theory at least) can get at it. | 22:51 | ||
pmichaud | I understand that part | ||
but how does it maintain references to the things that aren't part of the class? | |||
for example, how does the frozen PMC keep the fact that it 'isa P6object' ? | |||
22:52
justatheory left
|
|||
jnthn | Aye, freezing the parents list for parents outside of the assembly gets tricky. | 22:52 | |
pmichaud | and it's not just parents -- it might have references to other things | ||
jnthn | I don't think Parrot gives us what we need to do this today. | ||
pmichaud | that aren't actually loaded/constructed until runtime | 22:53 | |
namespace entries come to mind. | |||
jnthn | And we might need to be selective in what we can do. | ||
eternaleye | I can't figure out how to make the coderef '&generator' be triggered by an access beyond the lazy list's bounds. Is there some way to tie accesses to a list to a callback which extends the list? | ||
pmichaud | eternaleye: we don't implement laziness yet. | ||
22:53
justatheory joined
|
|||
jnthn | pmichaud: I suspect a bunch of our expense at the moment is in signature object creation. | 22:54 | |
frew | is $1 etc implemented in rakudo? | ||
jnthn | frew: yes, should be | ||
frew | and I still capture with () ? | ||
pmichaud | I agree with that. Even there, I'm not sure exactly how to freeze those, since they depend on a (dynamically-created) Signature class. | ||
eternaleye | Drat. I can't wait until we have laziness; I'm looking forward to the Coolest Perl6 Operator ( AKA infix:<...> ) | ||
pmichaud | capture with () yes, but the first one is $0 | 22:55 | |
jnthn | pmichaud: Worse, if you have a type that is a Class, then to freeze the sig you'd need a frozen reference to that. | ||
pmichaud | jnthn: exactly. | ||
frew | cool | ||
pmichaud | jnthn: which is why I've been concerned that the ability to freeze PMCs is far more limited than anyone had expected. | ||
I should rephrase that | 22:56 | ||
frew | should it be giving warnings about uninitialized values because of $0 et al? | ||
pmichaud | jnthn: which is why I've been concerned that the ability to freeze ['parrot';'Object'] (and descendents) .... | ||
frew: if you use $0 and it hasn't been set, you get the warning, yes. | |||
frew | hmmm | 22:57 | |
I'm trying to validate my input in the signature constraint | |||
is that a bad idea? | |||
pmichaud | depends on the use case; in general, having pattern-match signature constraints is supposed to be supported, yes. | 22:58 | |
frew | and being able to get at the $0 from the match? | ||
inside the method? | |||
pmichaud | that probably won't work, since it's a different lexical scope. | 22:59 | |
frew | ah, ok | ||
pmichaud | oh, it might be made to work somehow. I'd have to play with it a bit. | ||
jnthn | pmichaud: To construct a signature at the moment takes quite a bunch of method calls. And those - including parameter passing - ain't awessomely fast. :-( | 23:00 | |
pmichaud | jnthn: well, this is one of the reasons I wasn't a big fan of signature objects :-| | ||
(I agree we need them. But they're expensive at startup.) | |||
jnthn | Aye. :-| | 23:02 | |
pmichaud | if we can come up with a constant string-or-other implementation that could be quickly decoded to build the signature, or at least big parts of it, that might be useful. | 23:03 | |
jnthn | The main things we can't freeze are the type references. | 23:04 | |
pmichaud | even nicer would be if we could build signatures lazily. :-) | ||
jnthn | Being able to build them without a bunch of method calls would help too... | ||
pmichaud | well, we could certainly turn those method calls into (private) sub calls. | 23:05 | |
but I don't know if that's more or less expensive. | |||
jnthn | Avoids the method dispatch cost but not the parameter passing cost. | ||
pmichaud | and I don't think the method dispatch cost ought to be that high here. | 23:06 | |
looking up a method shouldn't be much more expensive than searching lexical+package+global scopes. | |||
(which is what a sub call would do) | 23:07 | ||
jnthn | Right, especially as they are defined right in the child hash anyway so would be a direct hit on the method table. | ||
pmichaud | exactly. | ||
otoh, we could look up the sub once (at the beginning of the loadinit) and then use it thereafter | |||
so there'd be no lookups, just argument passing. | 23:08 | ||
jnthn | ooh, that's true. | ||
pmichaud | of course, I guess we could do that with the method as well :-) | ||
jnthn | find_method ... ;-) | ||
Yeah! | |||
pmichaud | anyway, I suspect method dispatch (in this case single dispatch) is negligable to the argument passing cost | ||
jnthn | Me too. | 23:09 | |
Argument passing is known to be slow. | |||
pmichaud | anyway, in the next few days I'll see about moving the loadinits to one sub and see what we get. | ||
jnthn | It can't hurt, and it may make a reasonably sized difference. | ||
pmichaud | well, if it fails it can hurt :-| | 23:10 | |
it shouldn't fail, but... | |||
TimToady | well, setting everything up when you compile CORE.pm should have much the same effect | ||
when you dump the setting, it should have precompiled everything it can | 23:11 | ||
pmichaud | TimToady: agreed in theory; in practice, Parrot doesn't give us a lot of options for storing precompiled data structures, so we end up building them at load-time. | 23:12 | |
TimToady | well, that's gonna bite | ||
on arity, we can probably take minimum arity from the proto | 23:13 | ||
pmichaud | Agreed. I've been bristling about it for some time but haven't see any relief on the horizon | ||
TimToady | also &[x] form is defined to be arity 2 regardless of the underlying operaotr | ||
pmichaud | for example, it bugs me that the way we currently build operator precedence tables is by loading the tokens one-at-a-time. | 23:15 | |
(at program startup) | |||
TimToady | e.g. &[~] is concatenate two things even though ~ itself is list assoc | ||
pmichaud | IWBNI Parrot gave me a way to easily serialize data structures in PIR or some other representation. | ||
23:16
eternaleye left
|
|||
pmichaud | we might need to look at adding libyaml or something like that to do that. | 23:16 | |
anyway, dinner time here, $wife is calling | |||
bbl | |||
TimToady | chow | ||
jnthn | pmichaud: At startup, Parrot loops through all of the subs looking for loads or inits or whichever it wants. When it finds one, it calls do_1_sub_pragma which then works out what needs to be done and runs the sub. Since in theory it may be a :immediate it invokes it with Parrot_runops_fromc_args which involves playing the calling conventions game. We then call runops_args which along the way creates a return continuation PMC plus a context. | ||
23:17
eternaleye joined
|
|||
jnthn | ...so doing that once rather than for every single method/sub in the setting might just be cheaper. ;-) | 23:17 | |
23:17
mberends left
|
|||
jnthn | (I approximate us currently to do this 150 times from a quick grepping.) | 23:18 | |
(Plus once for every class.) | |||
TimToady | one begins to see why many Smalltalk implementations just provide a way to dump/restore the whole memory image... | 23:19 | |
23:20
donaldh left
|
|||
TimToady | the setting notion isn't so far off of that | 23:20 | |
23:20
donaldh joined
|
|||
jnthn | TimToady: Aye, the challenge is how that dump is linked up with objects from other dumps. | 23:20 | |
23:21
pmurias left
|
|||
TimToady | just compile, say, CORE.pm, and all its dependencies, then dump everything visible to the lexical scope at YOU_ARE_HERE | 23:21 | |
jnthn | TimToady: We already to compile, the problem is the data structures rather than the code (e.g. signatures). | ||
TimToady | it all ends up in the one dump, because the use made everything in the other dump visible | ||
23:22
payload left
|
|||
jnthn | Sadly, while it's fairly easy to say that, achieving it is slightly harder. ;-) | 23:22 | |
TimToady | all data structures are visible to the setting's lexical scope, because GLOBAL is just a part of CORE | 23:23 | |
details, details :) | |||
jnthn | Yeah, but it does back to what pm said - Parrot's support for freezing the data structures at the moment isn't giving us what we want. | ||
Or rather, what we need. | 23:24 | ||
TimToady | but anyway, it's one of the reasons officially installed modules are considered immutable | ||
so we don't have to worry about recompiling them every time | |||
jnthn | To allow pre-compilation? | ||
Right. | |||
TimToady | and not just pre-comp of themselves, but their incorporation into CORE | ||
the *use* is also precompiled | |||
anyway, that's the ideal | 23:25 | ||
jnthn | Aye. | ||
TimToady | the current approach is a bit like not taking invariant code out of the loop when you could | ||
23:26
DemoFreak left
|
|||
jnthn | I agree with you on the ideal. I just know the work involved in getting there. | 23:26 | |
And I mostly hold to, it'll be better to do all of Perl 6.0.0 and then optimize, rather than run a subset fast. | 23:27 | ||
TimToady | well, sure, up until the point where people are depending on the bugs for production code | ||
Tene | jnthn: did you see my comments earlier about how rakudo is slower when in .HLL 'perl6' ? | 23:28 | |
jnthn | Tene: I saw them. Do you have much thought about why? | ||
TimToady | things in parrot that prevent atomicity of startup will tend to prevent other things as well | ||
Tene | none whatsoever. | ||
jnthn | Tene: OK. Did you measure how much slower? | 23:30 | |
TimToady | I wonder how long it would take to (pseudo-)fork a parrot interpreter that was preloaded with the compiler... | 23:31 | |
jnthn | TimToady: Parrot certainly has issues. | ||
Tene | jnthn: nopaste.snit.ch/16544 | 23:32 | |
'make test' times compared similarly | |||
jnthn | TimToady: Much as I would love to dig in and help be a part of solving them sooner, trying to commit to Parrot as I do with Rakudo right now just ain't going to happen. At least, not without burning me out in the process. | 23:33 | |
And that'd probably be worse. | 23:34 | ||
Tene: Looking. | |||
Tene: Ouch. Notable. | 23:35 | ||
Tene: Think we'll have to just accept it. | 23:36 | ||
For now anyways. | |||
When I finally stop procrastinating and implementing fun things, I'll eventually get around to the refactor that method dispatch needs, and we'll be less slow on quite a few bits... | 23:39 | ||
23:39
mizioumt2 left
|
|||
jnthn | Tene: BTW, the trait version of your LolDispatch should run just fine now on Rakudo. :-) | 23:40 | |
Impressive cheat though! | |||
Infinoid | jnthn: Are there parrot tickets for the things rakudo needs? | 23:41 | |
jnthn | Infinoid: Yes, some, though we could maybe do with somehow tagging them. | ||
Infinoid: Some are just more general though. Like, calling performance. | |||
Infinoid | true, that effects everyone | 23:42 | |
23:42
frew left
|
|||
jnthn | I'm hoping that Allison's latest work on this will deliver us performance wins. | 23:42 | |
Parrot seems to have got people in the right order. | 23:43 | ||
We had somebody how came along and optimized the hell out of stuff. Then we had someone come along and work out the architecture for 1.0. :-| | |||
(Yes, I know it's more complex than that really. :-)) | |||
23:43
bacek_ joined
|
|||
TimToady | Fire! Aim! Ready! is good XP | 23:44 | |
jnthn | ŠŃŠøŠ²ŠµŃ, bacek :-) | ||
jnthn uses XP every day. | 23:45 | ||
;-) | |||
bacek_ | jnthn: Ń Š“Š¾Š±ŃŃŠ¼ ŃŃŃŠ¾Š¼! | 23:46 | |
jnthn | bacek_: ŠŠ°Šŗ Š“ŠµŠ»Š°? | 23:47 | |
.oO( my Russian probably runs out of steam in another sentence or two :-( ) |
|||
meppl | good night | 23:49 | |
23:50
meppl left
|
|||
s1n | Tene: 'is autodispatched' sounds like a good idea :) | 23:51 | |
pmichaud: ping | 23:52 | ||
pmichaud | s1n: pong | ||
Tene | s1n: "method foo(...) is autodispatched { ... }" meaning "There's a 'sub' form of foo that looks up 'self' in the caller and calls the 'foo' method on it" sound about right? | ||
s1n | pmichaud: what was wrong with $.method? | 23:53 | |
pmichaud | s1n: nothing, as it turns out, other than rakudo has a known bug with it. | ||
s1n | oh okay | ||
$.method is much better | 23:54 | ||
pmichaud | but from a Perl 6 perspective, $.method is just fine. | ||
bacek_ | jnthn: Š¾ŃŠ»ŠøŃŠ½Š¾! | ||
s1n | Tene: sounds like a decent idea | ||
Tene | s1n: so I'm misremembering you having an objection to $.method ? | ||
s1n | pmichaud: yeah, it's much better than self.method, but I like Tene's idea | ||
Tene: well, it's just not fully huffmanized :) | 23:55 | ||
that idea of yours sounds somewhat reasonable | |||
Tene | "All is fair if you predeclare." | ||
pmichaud | 23:36 <jnthn> Tene: Think we'll have to just accept it. | ||
s1n | Tene: yeah, i'll agree with that | ||
pmichaud | Given that, I'm fine with switching Rakudo over to .HLL 'perl6' at your convenience. | ||
Tene | pmichaud: OK, I'll commit now then. | 23:56 | |
pmichaud | be sure to spectest with latest changes :-) | ||
s1n | Tene: i saw your LolDispatcher | ||
i wanted to ask about that, it looks pretty amazing, can you explain how that works to me? | |||
pmichaud | (or prepare to hear lots of flames if spectest breaks :-) | ||
Tene | s1n: sure. lemme move it to use the real syntax... | 23:57 | |
pmichaud | "No!! Not THE REAL SYNTAX!!!" :-P | ||
dalek | kudo: b41e13b | tene++ | perl6.pir: Migrate Rakudo to use .HLL 'perl6' |
||
Tene | pmichaud: spectest is clean for me... this is the only way to get anyone else to actually test it. :) | ||
jnthn | pmichaud: It sucks to perform even worse, but putting off something that needs to happen when we have a patch ready to make it happen seems like a potential missed opportunity. | 23:58 | |
pmichaud | I have to disappear for a bit, I'll run a spectest while gone. | ||
Tene | jnthn: there are tests for sub traits now? | ||
pmichaud | jnthn: I agree -- I only wanted to get your opinion before pulling the trigger. | ||
jnthn | Tene: No, I didn't get to writing the tests yet, mostly because TimToady++ wants to review traits anyway and I've decided to hold fire on further traits stuff until he's done so. | 23:59 | |
Tene++ for HLL stuff. :-) | |||
pmichaud | Indeed. | ||
jnthn | As in, *really* Tene++. :-) | ||
pmichaud | Now we should start trying 'hll_map' :-) |