»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'p6: say 3;' or rakudo:, or /msg camelia p6: ... | irclog: irc.perl6.org or colabti.org/irclogger/irclogger_logs/perl6 | UTF-8 is our friend! Set by moritz on 22 December 2015. |
|||
teatime | that doesn't seem to be the case | 00:00 | |
00:00
dfcarpenterak joined
|
|||
geekosaur | (\X being a codepoint followed by any number, including zero, of modifiers) | 00:00 | |
teatime | m: say '"̃"' ~~ rx:Perl5/^./ | ||
camelia | rakudo-moar ec6c3b: OUTPUT«「"̃」» | ||
geekosaur | er, of combining codepoints | ||
00:00
luser1 left
|
|||
geekosaur | if you hadn't noticed, rx:perl5 is not complete (and I would say in this example not correct) | 00:00 | |
probably as NYI as the modifiers :bytes etc | 00:01 | ||
I'm testing them locally in perl5 | |||
remember that in perl 6, the string '"̃"' itself has only one character in it: a synthetic codepoint | 00:03 | ||
..,wow, hexchat mangled that | |||
teatime | well that string has two | ||
but yes I understand it doesn't have three | 00:04 | ||
geekosaur | yeh, I copy-pasted and hexchat doubled the " | ||
but that means that rx:p5 would have to undo that to work just like perl 5, and it doesnt know that it needs to do that | |||
so it's matching more than it should with ^. | |||
teatime | yes | ||
I understand it's nyi, that's fine | 00:05 | ||
geekosaur | if youi do it in actual perl 5, it matches only one codepoint | ||
teatime | I was just testing and hoping. | ||
interestingly, putting a ZWNJ after the opening " does not break up the grapheme, either to perl or on my terminal | |||
would have thought it would | |||
geekosaur | I think that's a known glitch | 00:06 | |
actually ZWNJ is misrecognized/misimplemented all over the place | |||
teatime | I figured P6 would implement that w/ maybe 50% probability, but really shocked it doesn't work in my terminal | ||
geekosaur | I think jnthn ran into that while developing the current grapheme implementation | ||
00:15
dolmen left
00:16
Ben_Goldberg joined,
BenGoldberg left,
Ben_Goldberg is now known as BenGoldberg
00:20
atweiden left
00:22
araujo joined,
spider-mario left
00:24
dfcarpenterak left
00:27
Ben_Goldberg joined,
BenGoldberg left,
Ben_Goldberg is now known as BenGoldberg
00:31
cpage_ left
00:32
dolmen joined
00:33
sufrostico left
00:34
hotel joined
00:35
hotel_california left
00:36
BenGoldberg left
00:37
BenGoldberg joined
00:39
dfcarpenterak joined
00:47
dfcarpenterak left
00:57
zwu joined
01:01
dolmen left
|
|||
zwu | I understand it is too early to test the performance of perl6, due to my interesting, I tested perl6 performance for the same task at github.com/famzah/langs-performance, sorry I don't have the perl 6 code right on my computer, but from my test on perl 6 April release, it is about 18x slower than python2. | 01:01 | |
the benchmark of other language performance are there. | |||
The code for perl 6 is very similar to other code for the implementation, I could post it tomorrow too. | 01:02 | ||
gfldex | it is for sure not to early to test the performance of Perl 6. It is however to early to expect the same performance then a language that was released in 1991. | 01:03 | |
timotimo | please ping me with the code when you have it :) | ||
zwu | here is the benchmark of other language: blog.famzah.net/2016/02/09/cpp-vs-...mark-2016/ | ||
timotimo | i wonder if you used "int" or "Int" in the perl6 code | 01:04 | |
zwu | I used Int and @array using push | ||
timotimo | wow, your get_primes7 has a prototype definition | 01:05 | |
in the perl5 code, i mean | |||
zwu | so that could be the performance problem. | ||
timotimo | not necessarily :) | ||
zwu | btw: it is not my code on the git github.com/famzah/langs-performance. | ||
timotimo | as long as the numbers don't exceed 32bit, we at least don't allocate a full mp_int | ||
but we're currently pretty dumb when it comes to creating far too many intermediate boxed results, and we have a few things that immediately prevent inlining in some cases, which really hurts performance | 01:06 | ||
but all in all, 2016 is the year where many performance improvements will be made | |||
zwu | I believe there will be many performance improvements !!! | 01:07 | |
timotimo | just yesterday lizmat gave Int a little performance optimization pass with results like div and / for Int, Int being about 50% faster | ||
01:08
molaf left
|
|||
timotimo | i'm interested in running the code you came up with under --profile | 01:10 | |
zwu | ok, I put my primes.p6 code there gist.github.com/anonymous/f31c6b7e...9a1085894, sorry for I didn't create a github repo. | 01:14 | |
timotimo | not important, a gist is good enough | 01:15 | |
there seem to be some tab characters mixed in there :) | 01:16 | ||
how long does it take on your machine, approximately? | |||
zwu | 531 seconds | 01:17 | |
run at a virtual machine. | 01:18 | ||
for python2 it is about 31 seconds. | |||
timotimo | thanks | ||
i'll probably have my sleep before actually working on this, though | |||
01:20
molaf joined
01:23
winger__ joined
01:27
winger_ left
|
|||
timotimo | already a c-level profile reveals 8.2% spent in total just marking an array of objects | 01:28 | |
17% of overhead related to invoking frames, which means the optimization we're going to get this or next week will give a decent benefit here even before the code itself has been optimized | 01:29 | ||
well, i'd even go as high as 25% | |||
01:37
BenGoldberg left
01:38
pierre_ joined
|
|||
gfldex | it's filling up 1.3GB of RAM | 01:38 | |
timotimo | it's going gc-crazy, too | 01:39 | |
01:39
Actualeyes joined
|
|||
timotimo | 69660380 Int objects, 59977737 Scalar objects | 01:39 | |
01:39
Actualeyes left
|
|||
timotimo | and an astronomical amount of BOOTHash, which i'm not 100% sure about their correctness | 01:40 | |
gfldex | does `Int(sqrt($n))` acutally create an Int obj, even if the result ends in `int`? | 01:41 | |
timotimo | "ends in"? | ||
gfldex | like in `my int $mroot = Int(sqrt($n))`; | ||
timotimo | just by sprinkling a few "int" around, i get from 272504.78ms to 159403.75ms | ||
(but this is only 5 runs, not 10) | |||
it will create an Int, yes | 01:42 | ||
gfldex | m: my @primes = (1..10000000).grep(*.is-prime); say @primes.elems; | ||
timotimo | i see a tremendous amount of IntLexRef being generated, which tells me my nativifying is doing the "stop all inlining now!" thing | 01:43 | |
camelia | rakudo-moar ec6c3b: OUTPUT«(timeout)» | ||
01:43
BenGoldberg joined
01:45
ilbot3 left
|
|||
timotimo | gfldex: wanna try out if you can do better than the loop that puts odd numbers into the @s array? | 01:46 | |
like with a "..." for example | |||
or by using the return value of a loop | 01:47 | ||
01:47
ilbot3 joined
|
|||
gfldex | i would like to keep the algorithm the same for a start to see how far I get that way. I do know the max size of the result array, so a native shaped is worth a try. | 01:48 | |
timotimo | no, definitely not native shaped; they are currently the opposite of optimized | 01:49 | |
they will give you terrible performance | |||
01:50
cdg left
|
|||
timotimo | it seems like 3, 5, 7 ... * > $n is slower than the loop with push in it :) | 01:50 | |
gfldex | if it gets cache friendly it may still lead to a win | ||
timotimo | no. no, it will very much not be. it will still be 100x slower than a regular native array | 01:51 | |
01:51
cdg joined
|
|||
timotimo | do a small test up front and you'll see just how terrible performance of shaped arrays is right now | 01:51 | |
01:52
mohae joined
01:55
huggable left,
huggable joined
|
|||
timotimo | wow, using the return value from a loop causes the program to run about 2x as long, and also eats up more than 2x more memory | 01:55 | |
01:55
cdg left
|
|||
BenGoldberg | If you use := instead of = for the array assignment, does it speed it up? | 01:57 | |
timotimo | i don't have an array assignment at the moment; do you mean for the loop, or for a "..." call? | ||
using int32 for the arrays makes memory usage a bit lower, but has nearly no impact on run time | |||
BenGoldberg | 'my @res = get_primes(10000000);' vs 'my @res := get_primes(10000000);' | 01:59 | |
Also for doing 'my @s = do loop ...' vs 'my @s := do loop ...' | 02:00 | ||
timotimo | the @s will be modified later on, so just putting a Seq in there won't fly | 02:01 | |
02:01
cpage_ joined
|
|||
timotimo | no change between = and := | 02:02 | |
er | |||
it halves maximum resident set size, but it doesn't make things faster | |||
better than half, actually | |||
BenGoldberg | Ok, what about replacing the 'for @s' loop with 'return @s' | 02:03 | |
Hmm, need to do unshift(@s, 2), first, to make the results correct. | 02:04 | ||
timotimo | wouldn't that change semantics? | ||
BenGoldberg | ? | ||
timotimo | that for loop basically implements .grep(*.so) | 02:05 | |
BenGoldberg | Oh, I see. | ||
Ok, then how about unshifting 2 onto the front of @s, then doing 'return @s.grep: @.so;' | 02:06 | ||
Without putting stuff in @r. Actually, I don't think @r is really necessary. | |||
timotimo | i'm trying | ||
the "original"(?) python code has the result thing anonymous in a return clause | 02:07 | ||
return [2] + [x for x in s if x] | |||
BenGoldberg | That can be mimiced with 'return 2, |(@s.grep: *.so);' ... I'm not sure which would be faster. | 02:08 | |
timotimo | my attempt at that makes it slower and use more memory | ||
i'm going to bed | 02:10 | ||
BenGoldberg | G'night, then. | ||
timotimo | i have a hot water bottle waiting for me in bed <3 | 02:11 | |
have fun with the benchmark, if you're going to continue working on it :) | 02:12 | ||
02:19
noganex_ joined
02:21
noganex left
02:25
dwarring left
02:28
zwu left
02:43
kid51 left,
BenGoldberg left
02:45
BenGoldberg joined
02:46
BenGoldberg left
02:47
BenGoldberg joined
02:49
mattp_ left
02:51
mattp_ joined
02:52
jack_rabbit joined
|
|||
sortiz | m: use Test; my @a; my $p = @a; does-ok $p, Positional; # So far, so good | 02:57 | |
camelia | rakudo-moar ec6c3b: OUTPUT«ok 1 - The object does role 'Positional'» | ||
sortiz | m: use Test; my @a; does-ok @a, Positional; # Missing signature? | ||
camelia | rakudo-moar ec6c3b: OUTPUT«ok 1 - The object does role 'Positional'» | ||
sortiz | Hmm | ||
02:58
finanalyst joined
03:03
pierre_ left
03:11
grondilu left
03:19
Ben_Goldberg joined,
BenGoldberg left,
Ben_Goldberg is now known as BenGoldberg
|
|||
MadcapJake | what do you mean missing signature? | 03:21 | |
m: @a.^roles.say | |||
03:21
skids left
|
|||
MadcapJake | m: "hello?".say | 03:22 | |
camelia | rakudo-moar ec6c3b: OUTPUT«5===SORRY!5=== Error while compiling /tmp/ORxwbtUUbjVariable '@a' is not declaredat /tmp/ORxwbtUUbj:1------> 3<BOL>7⏏5@a.^roles.say» | 03:23 | |
rakudo-moar ec6c3b: OUTPUT«hello?» | |||
MadcapJake | m: my @a; @a.^roles.say | 03:24 | |
camelia | rakudo-moar ec6c3b: OUTPUT«((Positional) (Iterable))» | ||
03:25
yqt left
03:27
musca joined
|
|||
sortiz | MadcapJake, nothing, a random glitch in the matrix ;-) | 03:28 | |
03:30
pierre_ joined
|
|||
sortiz | I'm writing json-c's NativeCall bindings, and was testing the properties of my objects. :-) | 03:30 | |
MadcapJake | ahh i see! :) if there was a glitch, the agents might be on to you! Get to a phone quickly! ;) | 03:35 | |
sortiz | :P | 03:36 | |
03:37
jack_rabbit left,
jack_rabbit joined
03:53
Ben_Goldberg joined,
BenGoldberg left,
Ben_Goldberg is now known as BenGoldberg
03:54
milwaukee joined
04:08
hotel_california joined
04:09
hotel left
04:20
milwaukee left
04:26
BenGoldberg left
04:27
BenGoldberg joined
04:32
BenGoldberg left
04:34
BenGoldberg joined
04:37
khw left
04:46
BenGoldberg left
04:47
pierre_ left
04:59
Cabanossi left
05:02
Cabanossi joined
05:06
richi235 left,
richi235 joined
05:07
firstdayonthejob joined,
hotel_california left,
hotel joined
05:18
sno left
05:32
domidumont joined
05:36
domidumont left
05:37
domidumont joined
05:40
hotel_california joined
05:41
hotel left
05:44
macsnowball left,
finanalyst left
05:45
domidumont left
05:47
pierre_ joined,
rurban joined
05:52
pierre_ left
05:55
huggable left,
huggable joined
05:58
TimToady left,
TimToady joined
05:59
nadim joined,
RabidGravy joined
06:00
pierre_ joined
06:02
_nadim left,
CIAvash joined
06:03
domidumont joined,
domidumont left
06:04
xinming_ joined,
domidumont joined
06:07
xinming left
|
|||
RabidGravy | Boom! | 06:08 | |
06:12
daxim joined
06:17
sno joined
06:29
wamba joined
06:31
lizmat joined
06:34
_mg_ joined
06:35
firstdayonthejob left
06:38
sjoshi joined
06:50
dolmen joined
06:56
dolmen left
07:05
rurban left
07:06
domidumont left,
domidumont joined
07:14
lizmat left,
Amnez777 left
|
|||
ufobat | good morning :) | 07:15 | |
RabidGravy | erp | 07:17 | |
07:24
zakharyas joined
07:32
pierre_ left
07:41
pierre_ joined
07:51
darutoko joined,
abraxxa joined
07:59
devtom30 joined
08:00
dakkar joined
08:05
zakharyas left,
avenj left
08:06
[particle] left
08:08
pierre_ left
08:15
domidumont left
08:16
[TuxCM] joined,
lizmat joined,
avenj joined
08:18
domidumont joined
08:19
infina left,
finanalyst joined
08:22
pierre_ joined,
avenj left
08:29
Sound joined
08:31
avenj joined
08:34
winger_ joined
08:35
_28_ria joined
08:38
winger__ left
08:43
[particle] joined
08:49
[TuxCM] left
08:50
Amnez777 joined
08:51
jack_rabbit left
08:52
Hor|zon joined
08:54
Amnez777 left,
Amnez777 joined
|
|||
moritz | .oO( RabidGravy seems to like ERP systems :-) |
09:01 | |
09:01
Sound left
09:02
CIAvash left
09:04
pierre_ left
09:05
pierre_ joined
09:10
CIAvash joined
09:19
sjoshi left
09:21
[TuxCM] joined,
rindolf joined
|
|||
RabidGravy | last time I worked with SAP it made me go blind or something | 09:31 | |
09:41
TEttinger left
09:50
domidumont left
09:51
Relsak joined
09:54
domidumont joined
09:55
huggable left,
huggable joined
10:02
[TuxCM] left
10:06
uruwi_ joined
10:09
uruwi left
10:10
uruwi_ left
10:12
uruwi joined
10:15
kid51 joined
10:22
rindolf left,
zakharyas joined
10:24
boegel left
10:26
boegel joined,
kaare_ joined
10:39
finanalyst left
10:41
pierre_ left
10:46
brrt joined
10:53
infina joined,
infina left,
infina joined
10:55
Brock left
11:08
[particle] left
11:09
[particle] joined
11:16
wamba left
11:17
brrt left
|
|||
stmuk | SAP also made people rich | 11:27 | |
timotimo | i didn't expect only a quarter screenful of irc to happen while i'm asleep :P | 11:34 | |
11:34
milwaukee joined
|
|||
nine_ | It's a quiiiiet day | 11:41 | |
jnthn | Not here it ain't. It was the day of the month they decided to test the air raid siren. :P | 11:42 | |
Or nuke siren, or whatever it's for. | |||
11:43
AlexDaniel joined
|
|||
nine_ | preferably at 6 in the morning? | 11:43 | |
jnthn | No, at midday at least :) | ||
11:43
brrt joined,
flaviusb joined
|
|||
jnthn | They anounce the test in English too, funnily enough, but the speaker is so bad that it took me a year of hearing the announcements to realize that part of it even was in English. :) | 11:44 | |
AlexDaniel | yea, just using native ints in primes.p6 thingy makes it run in like 50% time | ||
jnthn | So...nativism trumps again... :P | 11:45 | |
11:47
pmurias joined,
kid51 left
|
|||
brrt puzzles whether that is a pun | 11:51 | ||
AlexDaniel | “for @s { @r.push($_) if $_ }” is significantly faster than “@r.append: @s.grep: {$_}” | 11:54 | |
nine_ | I'm not entirely surprised | ||
12:01
rindolf joined
|
|||
AlexDaniel | it seems like just pushing these numbers takes a lot of time | 12:01 | |
12:03
cgfbee joined
|
|||
AlexDaniel | also, @a.append: @b is much faster than @a.push: |@b | 12:04 | |
12:05
cpage_ left
|
|||
AlexDaniel | m: my @a = 1..100000; my @b; @b.push: |@a | 12:05 | |
camelia | rakudo-moar 480709: OUTPUT«Too many arguments in flattening array. in block <unit> at /tmp/WYXkksBAXL line 1» | ||
AlexDaniel | mmmhm… | ||
I haven't thought about it | |||
12:08
wamba joined
|
|||
timotimo | i suppose the reason for grep with a block is slower is because we don't have trace jit yet, which means it'll invoke a code object for every single test | 12:09 | |
whereas in the for + if that's in-line for free | |||
moritz | maybe laziness is to blame | ||
jnthn | `@a.push: |@b` is a pretty bad idea :) | 12:10 | |
timotimo | hm, append won't try to eagerly nom the whole list? | ||
that'd be a bad miss :) | |||
or do we want it to act like "plan"? | |||
jnthn | It actually flattens all the arguments | ||
Into the callsite | |||
timotimo | yes, that's pretty terrible | 12:11 | |
AlexDaniel | @s .= grep({$_}); @r.append: @s; is slightly faster than everything | ||
jnthn | And produces a callsite descriptor along the way | ||
timotimo | it'd end up like a triple copy of the whole list | ||
jnthn | Yeah, plus making the huge callsite descriptor. And, worse, while the argument limit in MoarVM is fairly high, the one on the JVM is 255 iirc. | ||
12:11
infina left
12:15
sergot_ is now known as sergot
12:16
dj_goku joined,
infina joined,
infina left,
infina joined
|
|||
AlexDaniel | ah… well, some things work faster without native ints | 12:22 | |
m: my int $x = 2; $x /= 2; say $x | 12:26 | ||
camelia | rakudo-moar 480709: OUTPUT«This type cannot unbox to a native integer in block <unit> at /tmp/RXCVNLBO3x line 1» | ||
AlexDaniel | is it ok? | ||
timotimo | yes, the GC time hardly gets reduced at all, which is because of all the IntLexRef objects being created and immediately tossed again | ||
that's fine | 12:27 | ||
m: my int $x = 2; $x div= 2; say $x | |||
camelia | rakudo-moar 480709: OUTPUT«1» | ||
timotimo | you want this anyway ^ | ||
AlexDaniel | right | ||
timotimo | i'm still looking for the right peg to hang "turn this num into an int without going through Int" off of | ||
it's just a matter of using the nqp op that i've already bound on a local branch, but how do i expose it to the user's code? | |||
12:28
brrt left
12:29
ZoffixW joined
|
|||
ZoffixW | What does rakudobrew rehash do? | 12:29 | |
timotimo | i think it just rebuilds the scripts in bin/ that point "to the actual things" | 12:30 | |
ZoffixW | I see | ||
12:32
rindolf left
12:33
cpage_ joined
12:35
pierre_ joined,
infina left,
infina joined,
infina left,
infina joined
12:39
zwu_ joined,
rindolf joined
12:40
wamba left
12:41
zwu_ left
12:42
wamba joined
|
|||
AlexDaniel | looking at this comparison again, I think that it is pretty stupid. If you look closely, then in both P5 and suggested P6 versions there is a temp array @r that is there for no reason | 12:42 | |
while in e.g. python version there is no such thing | |||
in perl 6, getting rid of this @r array actually makes things significantly faster | 12:43 | ||
RabidGravy | gosh the chromaprint api is really rather simple | ||
timotimo | AlexDaniel: in the python version it returns [2] + [a for a in s if a] or something | 12:49 | |
which is equivalent to @r | |||
12:49
awwaiid2 joined
|
|||
AlexDaniel | timotimo: saving the result into array is a redundant step, which may have some impact | 12:53 | |
dalek | osystem: bd5e63c | (Salvador Ortiz)++ | META.list: Add JsonC to ecosystem. NativeCall bindings to json-c library |
||
AlexDaniel | and if you use @s as an array of native ints, then indeed it does | ||
timotimo | right. you still need to filter it and put the 2 in front :) | ||
the filter thing could surely be done easily with a two-pointer algorithm in-place, though | 12:54 | ||
RabidGravy | ah sortiz++ | ||
sortiz | Yet another JSON module for Perl6 :-) | ||
RabidGravy | I looked at that a while back, decided it was too complicated to do quickly and for forgot about it | 12:55 | |
timotimo | if it's a drop-in replacement for JSON::Fast, it'll probably eat its lunch :) | 12:56 | |
RabidGravy | or at least it's breakfast | ||
sortiz | panda's projects.json is parsed in Parsed in 0.0034288s. | 12:57 | |
12:58
cdg joined,
cdg left,
sufrostico joined
12:59
cdg joined
|
|||
ZoffixW | sortiz++ | 12:59 | |
sortiz | The idea is that the C library eat the file, and the unmarshaling is be lazy and on demand. | ||
ZoffixW | Now me need JSON::MaybeC :) | ||
s/me/we/ | |||
stmuk | we need more YAML parsing (not that I like the format)! | 13:00 | |
ZoffixW | Why? | ||
stmuk | I don't think there is any module to read it | 13:02 | |
RabidGravy | I made one in C# once | ||
ZoffixW | ugexe, doesn't look like #86 got resolved. I'm still having the same issue. That's after nuking everything and starting from scratch (github.com/ugexe/zef/issues/86) | ||
stmuk | ZoffixW: or was the Q why I don't like YAML? :) | 13:03 | |
ZoffixW | stmuk, no, you said "more", so I assumed we already had YAML and needed more :) | ||
I don't like it either | |||
sortiz | Any code review/comments/suggestions will be appreciated. | 13:04 | |
ZoffixW | It's the Python equivalent of configuration files 😂😂😂 | ||
stmuk | yes the whitespace sensitivity is a misfeature | ||
RabidGravy | it was the new hotness back in, oh, 2002 | 13:05 | |
timotimo | we have one yaml module that doesn't work, iirc | 13:06 | |
stmuk | YAMLish looks hopeful | 13:07 | |
sortiz | The json-c library is a little more permissive than JSON::Fast, so five 'should fail to parse' tests fails. | 13:08 | |
AlexDaniel | anyway, here is the what I got: gist.github.com/AlexDaniel/ce3c60e...bedea03ff5 | ||
13:08
brrt joined
|
|||
timotimo | sortiz: that's not "permissive", that's "wrong" :) | 13:08 | |
AlexDaniel | it runs about twice faster | ||
but I am sure that there is a way to make it even faster if you manage to get rid of this .grep | 13:09 | ||
sortiz | timotimo, Indeed, but json-c is in github, so that can be fixed. ;-) | 13:11 | |
13:11
cpage_ left
|
|||
ZoffixW | sortiz, which tests are that? | 13:11 | |
I see JSON::Fast is broken and doesn't handle newer spec | 13:12 | ||
timotimo | oh? please elaborate | ||
ZoffixW | perl6 -MJSON::Fast -e 'from-json q{"foo"} error: 'a JSON string ought to be a list or an object | ||
That's no longer true. Anything can be at top level | |||
sortiz | That is supported in JsonC. | 13:13 | |
ZoffixW | rfc7159.net/rfc7159#rfc.section.2 (second paragraph, especially) | ||
timotimo | from when is that? | ||
ZoffixW | March 2014 | ||
timotimo | oops. | 13:14 | |
RabidGravy | ZoffixW, I'll alter the source-url in the App::ModuleSnap | ||
AlexDaniel | ZoffixW: but still no trailing commas allowed? :( | ||
moritz | JSON::Fast copied JSON::Tiny, which used to follow ECMA-404 | 13:15 | |
13:15
pierre_ left
|
|||
moritz | later, JSON::Tiny relaxed its parsing | 13:15 | |
ZoffixW | RabidGravy, alright. I'll be mentioning it in an upcoming article, and didn't want people having issues installing it :) | ||
moritz | ("copied" is wrong, it just implemented the same interface) | ||
sortiz | Right now JsonC is faiing t/01-parse.t's 75-76, 78, 80-81 | ||
RabidGravy | I'll make it "git://github.com/jonathanstowe/App-ModuleSnap.git" which is the form that App::NoPaste uses | 13:16 | |
13:21
zwu_ joined
13:23
Sgeo left
13:28
pierre_ joined
13:32
ZoffixW left,
zwu_ left
13:33
pmurias left
13:35
pierre_ left
13:37
pierre_ joined
13:40
pmurias joined
13:42
grondilu joined
13:51
brrt left
13:55
huggable left,
huggable joined
14:04
wamba left
14:08
zakharyas left
14:09
zakharyas joined
14:11
finanalyst joined
14:13
zakharyas left
14:14
grondilu left,
tharkun left
14:15
grondilu joined
|
|||
grondilu | m: say { $^n ?? $n*&?BLOCK($n-1) !! $n }(4) | 14:16 | |
camelia | rakudo-moar 475063: OUTPUT«0» | ||
14:16
tharkun joined
|
|||
grondilu | m: say { $^n ?? $n*&?BLOCK($n-1) !! 1 }(4) | 14:16 | |
camelia | rakudo-moar 475063: OUTPUT«24» | ||
14:18
milwaukee left
|
|||
grondilu | I remember long time ago I wanted to talk about tail recursion and asked if Perl 6 would support it. You guys told me that it would probably not for various complicated reasons. We have at least two kinds of Callables structures though: Sub and Block. Couldn't at least one of them support tail recursion optimization? So that we can have efficient recursive functions? | 14:18 | |
jnthn | m: say { [*] 1..$^n }(4) # it's so esay to write this one iterative :P | 14:19 | |
camelia | rakudo-moar 475063: OUTPUT«24» | ||
timotimo | my uneducated opinion is that once we have trace jit, TCO becomes a potential possibility | 14:20 | |
probably a case of "SMOP", with all the things that entails | |||
jnthn | We don't in general know if anything "downstream" will do things like CALLER:: | ||
I think the question isn't "can we do TCO some of the time" | 14:21 | ||
It's "can we do it predictably enough that can rely on it happening" | |||
Can we do it at all is "surely yes", it's the latter I'm highly doubtful about. | |||
timotimo | oof. | 14:22 | |
14:22
pierre_ left
|
|||
timotimo | right, fair enough | 14:22 | |
grondilu | Could we not have a Calleable type that would prohibit anything that's incompatible with TCO? | ||
jnthn | Even if that's a dynamic prohibition? | ||
(You'd get a runtime exception for doing something incompatible with it, that is) | 14:23 | ||
grondilu | jnthn: I don't know, but you make it sound like TCO is impossible or something. Some languages do it, just do whatever they do. | ||
jnthn | That's stupid. | 14:24 | |
grondilu | rude | ||
jnthn | Other languages can do it because they made the trade-offs. | ||
Saying "in return we can't do X" | |||
14:24
brabo joined
|
|||
[Coke] | I think a better question than "can we do TCO" is "what is the plan for making rakudo faster". | 14:25 | |
MadcapJake | sub tco($arg) is MONKEY-TAIL { ... } | ||
timotimo | accessing a caller's lexical variables, for example ... (only if they are marked dynamic, of course) | ||
14:25
perlpilot_ joined
|
|||
jnthn | Language design is always trade-offs. | 14:25 | |
pmichaud | good morning #perl6 | 14:26 | |
grondilu | my concern is that there are function that are very much easier to write recursively, but we always end up not writing them because of performance issues. That's very LTA. | ||
jnthn | And the langs I know where you can rely on tail calls all made it so you can analyze that. | ||
o/ pmichaud | |||
MadcapJake | jnthn: could you explain a bit what the trade-offs are for TCO? I'm not following what the CALLER:: argument means | ||
jnthn | MadcapJake: In various languages, it's possible to staticly analyze things such that you can rewrite a recursion into an iteration. | 14:27 | |
MadcapJake: That relies on you knowing that you won't break anything in the process of doing so. | |||
14:27
perlpilot joined
|
|||
jnthn | MadcapJake: And as a result of the rules around when it happens being fairly simple, folks can write code relying on it. | 14:28 | |
In Perl 6, various features make that static analysis fraught while others mean we simply can't do it. | |||
14:28
wamba joined
|
|||
pyrimidine | jnthn: re: recursion to iteration, IIRC there is a fair amount in Higher Order Perl that covers doing so (for p5 of course) | 14:28 | |
pmichaud | aren't C<nextsame> and C<nextwith> supposed to help with tailcalls? Or is that a fossil? (Or are we strictly discussing automatic TCO?) | 14:29 | |
14:29
ZoffixW joined
|
|||
jnthn | The moment you make a method call, it's late-bound and you don't know whether that code will do anything, like access CALLER::. | 14:29 | |
pmichaud: They're for iterating through pre-determined candidate lists. They potentially could make use of tail call optimization, though you could construct cases where the optimization would break things. | 14:30 | ||
pmichaud | I guess nextsame/nextwith aren't recursive tailcalls. But perhaps they point the way to there. | ||
ZoffixW | Is anyone feeling adventurous and wants to add Perl 6 to CodeMirror? :P codemirror.net/mode/index.html | ||
jnthn | method foo() { my $*x = 42; nextsame() } | ||
Does the thing you nextsame to see $*x or not? | 14:31 | ||
ZoffixW | The Perl 5 version is 800 lines long :( Perl 6 version would probably be much larger: github.com/codemirror/CodeMirror/b...rl/perl.js | ||
MadcapJake | ZoffixW: I'm partway through a highlightjs mode but I got discouraged when I discovered heredocs were impossible | ||
timotimo | i think we already have a bit of codemirror for perl6 | ||
jnthn | (The answer today is "yes"; replacing the callframe would change that answer, for example) | ||
ZoffixW | MadcapJake, :( | 14:32 | |
timotimo | github.com/azawawi/farabi6/blob/ma...l6-mode.js <- ZoffixW | ||
MadcapJake | timotimo: that isn't usable actually, it's basically a copy-and-paste of perl5-mode | ||
jnthn | nextsame today functions as return callsame(...) | ||
ZoffixW | Yey! timotimo++ azawawi++ | ||
timotimo | OK, sorry about that | ||
pmichaud | jnthn: and yes, I'd expect nextsame to be that way. | ||
MadcapJake | ZoffixW: do not use that, azawawi informed me that it's not implemented beyond just copying perl5-mode into a new file | ||
jnthn | It's really tail calls as a language feature, vs. tail calls as an optimization. | 14:33 | |
ZoffixW | MadcapJake, aw. Too bad | ||
jnthn | The latter I'm pretty sure we could do in some cases; the former is a lot harder than "just copy what another language does". | 14:34 | |
pmichaud | jnthn: agreed | ||
ZoffixW | MadcapJake, how come heredocs are impossible? | ||
14:34
dakkar left
|
|||
pyrimidine | jnthn: could you indicate a method can be TCO, e.g. method foo() is tco { ... } | 14:34 | |
MadcapJake | ZoffixW: the highlight.js lexing engine doesn't support capturing delimiters and reusing them | ||
ZoffixW | Ah | 14:35 | |
MadcapJake | there's an issue in their tracker wrt to it and the author basically says "not possible and we're not implementing it any time soon" | ||
ZoffixW | :/ | ||
jnthn | pyrimidine: What would that actually do? | ||
I mean, sure we can indicate things, but what semantics go with it? | 14:36 | ||
MadcapJake | ZoffixW: I started a CodeMirror perl6 mode a little ways back actually (I forgot about it :). I'll try and get it finished this week (perhaps more likely next) | ||
ZoffixW | Sweet. No rush :) | ||
jnthn | If anything, the "this is a tailcall" mark would want to go on the call that should function that way. | ||
ufobat | ZoffixW, thanks for the PR | ||
jnthn | Which would mean you're explicitly saying "and if anything downstream isn't OK with that, it's my fault" | 14:37 | |
pyrimidine | jnthn: yeah, true | ||
ZoffixW | ufobat, no problem | ||
timotimo | there's monsters in the basement preventing me from TCO! :( | ||
jnthn | Which, as pmichaud points out, is kinda taking the nextsame/callsame approach by making explicit what you want to happen | 14:38 | |
14:38
ptolemarch joined
|
|||
CIAvash | github.com/jneen/rouge also needs a Perl 6 lexer. It's being used in Gitlab and Jekyll | 14:38 | |
14:40
tbrowder joined
|
|||
dalek | pan style="color: #395be5">perl6-examples: 8e9d84e | (Tom Browder)++ | Makefile: module 'Web::Request' not needed |
14:42 | |
perl6-examples: 1e2191e | (Tom Browder)++ | categories/99-problems/P40-rhebus.pl: | |||
perl6-examples: add tilde to remove parens in output; remove last integer as input (or could add it to the test output if desired) | |||
14:42
dalek left
14:43
dalek joined,
ChanServ sets mode: +v dalek,
perlpilot left
|
|||
MadcapJake | jnthn: In Perl 6, if you use {call,next}{with,same} and multi-dispatch heavily, will you run into issues? Because I think TCO is really about supporting that recursive paradigm more than anything and if we can support it without TCO then it's kind of a moot point. | 14:43 | |
14:43
khw joined,
perlpilot_ is now known as perlpilot
14:44
perlpilot_ joined
|
|||
MadcapJake | CIAvash: ok it's on the todolist! I usually only have so much syntax highlighting juice in any given month though :P | 14:44 | |
jnthn | MadcapJake: {call,next}{with,same} aren't for recursing anyway, they're through walking through (usually short, pre-destined) lists of implementations, so you can defer control to a more general candidate. | 14:45 | |
CIAvash | MadcapJake: nice :) | 14:46 | |
jnthn | MadcapJake: If you write heavily recursive stuff today - yes, you'll allocate a lot of stack frames. | ||
And yes, tailcall as an explicit language feature is a lot more hopeful in Perl 6 than TCO. | |||
MadcapJake | jnthn: ok so those keywords are more about the dispatching than about recursing. specifically call{with,same} would seem related to recursion, at least at first glance. | 14:47 | |
nine_ | I think there's still the endless loop issue with nextsame | 14:48 | |
14:48
dakkar joined
|
|||
jnthn | nine_: Yeah, that one should never be able to happen. I think I figured out how to fix it though: capture the frame that set the dispatcher. | 14:48 | |
nine_: And check that it's the caller of the thing trying to take it. | |||
Then it won't be stolen by accident | 14:49 | ||
Alternatively, we might be able to fix it with better code-gen. | |||
nine_ | jnthn: sounds like a step or two above my pay grade, so I'm no longer ashamed that I couldn't fix it :) | ||
jnthn | Just by forcing the takedispatcher to be earlier. | ||
nine_: I dunno, I think you've done plenty of trickeir things ;-) | |||
14:50
brrt joined
|
|||
nine_ | Well I guess things usually seem much less tricky after you've done them ;) | 14:50 | |
jnthn | Don't they just... | ||
jnthn looks forward to the current invocation changes he's doing seeming much less tricky... | 14:52 | ||
MadcapJake | I think another point wrt tailcall/TCO: Perl 6 has much more powerful iterative facilities that make recursion not so necessary. | ||
14:52
prammer left,
skids joined
14:53
prammer joined
|
|||
pmurias | MadcapJake: TCO is only truly necessary in functional languages | 14:55 | |
the python philosophy is that they won't implement it because it's not worth having worse stack traces | 14:58 | ||
MadcapJake | pmurias: yeah, as much as I like to think of Perl 6 as multi-paradigm, it seems there are certain things that require you to become entrenched in a particular paradigm (like TCO here). | 14:59 | |
15:00
rurban joined
|
|||
MadcapJake | interesting: ES6 has TCO actually www.2ality.com/2015/06/tail-call-op...ation.html | 15:01 | |
ZoffixW | MadcapJake, I think azawawi did more work on the CodeMirror thing. It looks usable enough: i.imgur.com/DxB7sNf.png | 15:03 | |
15:03
domidumont left
|
|||
ZoffixW | Still highlighted code inside a heredoc as code, but at least nothing is broken (like in SubLime text 2 :P) | 15:04 | |
pmurias | MadcapJake: according to the v8 team the want to change the spec to have implicit tail calls | ||
MadcapJake | yeah it works but it's mostly just perl 5 with a few added keywords. one negative is that perl 5 keywords and such will also be highlighted | ||
pmurias: what does that mean? | 15:05 | ||
ZoffixW | JS spec? | 15:06 | |
15:07
_mg_ left
|
|||
pmurias | MadcapJake: you will have to syntactically mark that you want to have a tail call | 15:07 | |
nine_ | explicit not implicit | 15:09 | |
pmurias | nine_: yes, sorry | ||
what they want to have: github.com/tc39/proposal-ptc-syntax | |||
MadcapJake | ahh yeah that's what my confusion was, I think that's a fine idea | 15:12 | |
brrt | it's weird to specify an optimization in the language, i'd think | 15:15 | |
ZoffixW | Well, we do have is cached already :P | 15:17 | |
grondilu | and 'is pure' (?) | 15:18 | |
pmurias | brrt: tail calls change semantics | ||
brrt | hmm, not necessarily | ||
15:18
lichtkind_ joined
|
|||
pmurias | brrt: when they eat your stack trace they do | 15:19 | |
brrt | or, well, it depends on whether your semantics include this notion of the stack | ||
keep a parameter 'i'm N tail calls deep', reconstruct the stack trace, done :-) | |||
actually, call trace | 15:20 | ||
but anyway | |||
i'm nitpicking | |||
perlpilot | brrt: have you ever had to debug a Perl 5 program where perl optimized away some of your call frames? | ||
brrt | my point is that the stack is an implicit assumption of routine local storage, which is not necessary to specify in a language | ||
no, haven't, actually | |||
that's using goto right? | |||
ZoffixW |