»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'perl6: say 3;' or rakudo:, niecza:, std:, or /msg camelia perl6: ... | irclog: irc.perl6.org | UTF-8 is our friend! Set by sorear on 25 June 2013. |
|||
Mouq | You know how people have .vimrc configs, etc.? The mallebility of v6 makes me think that people would adopt such things to speak their lisp of Perl | 00:00 | |
zacts | BenGoldberg: not quite yet, I'm running FreeBSD-9.2BETA2 | ||
00:01
dmol left
00:07
benabik left
00:08
benabik joined
|
|||
Mouq | Am I doing something wrong here: | 00:08 | |
r: .say for 'a'..* X~ 1..* | |||
camelia | rakudo bc379f: OUTPUT«(timeout)» | ||
Mouq | Is X not supposed to be lazy? | 00:09 | |
r: .say for 'a'..* Z~ 1..* | |||
camelia | rakudo bc379f: OUTPUT«(timeout)» | ||
Mouq | n: .say for 'a'..* Z~ 1..* | 00:13 | |
s: .say for 'a'..* Z~ 1..* | |||
camelia | niecza v24-88-g1f87209: OUTPUT«(timeout)a1b2c3d4e5f6g7h8i9j10k11l12m13n14o15p16q17r18s19t20u21v22w23x24y25z26aa27ab28ac29ad30ae31af32ag33ah34ai35aj36ak37al38am39an40ao41ap42aq43ar44as45at46au47av48aw49ax50ay51az52ba53bb54bc55bd56be… | ||
Mouq | hmm | ||
BenGoldberg | Sometimes 'for' will re-ify a lazy list | 00:20 | |
rns: for gather { take 1; say 'oy' } { .say; last } | |||
r: say 'alive' | 00:21 | ||
camelia | rakudo bc379f: OUTPUT«alive» | ||
BenGoldberg | rpn: for gather { take 1; say 'oy' } { .say; last } | ||
camelia | niecza v24-88-g1f87209: OUTPUT«1» | ||
..rakudo bc379f, pugs: OUTPUT«oy1» | |||
Mouq | Huh. So who's right here? | 00:22 | |
BenGoldberg | niecza | ||
Mouq | Okay | ||
BenGoldberg | n: .say for 'a'..* Z~ 1..* | 00:23 | |
camelia | niecza v24-88-g1f87209: OUTPUT«(timeout)a1b2c3d4e5f6g7h8i9j10k11l12m13n14o15p16q17r18s19t20u21v22w23x24y25z26aa27ab28ac29ad30ae31af32ag33ah34ai35aj36ak37al38am39an40ao41ap42aq43ar44as45at46au47av48aw49ax50ay51az52ba53bb54bc55bd56be… | ||
BenGoldberg | r: .say for 'a'..* Z~ 1..* | ||
camelia | rakudo bc379f: OUTPUT«(timeout)» | 00:24 | |
Mouq | n: .say for 'a'..* X~ 1..* # just curious about the order | 00:26 | |
camelia | niecza v24-88-g1f87209: OUTPUT«(timeout)a1a2a3a4a5a6a7a8a9a10a11a12a13a14a15a16a17a18a19a20a21a22a23a24a25a26a27a28a29a30a31a32a33a34a35a36a37a38a39a40a41a42a43a44a45a46a47a48a49a50a51a52a53a54a55a56a57a58a59a60a61a62a63a64… | ||
Mouq | yeah | ||
BenGoldberg | Rakudo's "for" tests if the list given to it is infinite using the .infinite method, and if it is, keeps it lazy. If it isn't infinite, it reifys (expands) the list before handling the body of the loop. Since .infinite returns Nil when it doesn't know if the list is infinite or not, and Nil is false, it treats gather/take, and Z, the same as finite lists. | 00:28 | |
rn: my @a := 'a'..* Z~ 1..*; say @a[0..10] | 00:29 | ||
camelia | rakudo bc379f, niecza v24-88-g1f87209: OUTPUT«a1 b2 c3 d4 e5 f6 g7 h8 i9 j10 k11» | ||
00:29
fgomez left
|
|||
BenGoldberg | A workaround might be: | 00:30 | |
rn: my @a := 'a'..* Z~ 1..*; say @a[$_] for 0..Inf; | |||
camelia | niecza v24-88-g1f87209: OUTPUT«(timeout)a1b2c3d4e5f6g7h8i9j10k11l12m13n14o15p16q17r18s19t20u21v22w23x24y25z26aa27ab28ac29ad30ae31af32ag33ah34ai35aj36ak37al38am39an40ao41ap42aq43ar44as45at46au47av48aw49ax50ay51az52ba53bb54bc55bd56be… | 00:31 | |
..rakudo bc379f: OUTPUT«(timeout)a1b2c3d4e5f6g7h8i9j10k11l12m13n14o15p16q17r18s19t20u21v22w23x24y25z26aa27ab28ac29ad30ae31af32ag33ah34ai35aj36ak37al38am39an40ao41ap42aq43ar44as45at46au47av48aw49ax50ay51az52ba53bb54bc55bd56be57bf58b… | |||
BenGoldberg | Hmm, odd | ||
rn: my @a := 'a'..* Z~ 1..*; say @a[$_] for 0..60; | 00:32 | ||
camelia | niecza v24-88-g1f87209: OUTPUT«a1b2c3d4e5f6g7h8i9j10k11l12m13n14o15p16q17r18s19t20u21v22w23x24y25z26aa27ab28ac29ad30ae31af32ag33ah34ai35aj36ak37al38am39an40ao41ap42aq43ar44as45at46au47av48aw49ax50ay51az52ba53bb54bc55bd56be57bf58b… | ||
..rakudo bc379f: OUTPUT«a1b2c3d4e5f6g7h8i9j10k11l12m13n14o15p16q17r18s19t20u21v22w23x24y25z26aa27ab28ac29ad30ae31af32ag33ah34ai35aj36ak37al38am39an40ao41ap42aq43ar44as45at46au47av48aw49ax50ay51az52ba53bb54bc55bd56be57bf58bg59bh60… | |||
BenGoldberg | rn: my @a := 'a'..* Z~ 1..*; say @a[0..58]; | ||
camelia | niecza v24-88-g1f87209: OUTPUT«a1 b2 c3 d4 e5 f6 g7 h8 i9 j10 k11 l12 m13 n14 o15 p16 q17 r18 s19 t20 u21 v22 w23 x24 y25 z26 aa27 ab28 ac29 ad30 ae31 af32 ag33 ah34 ai35 aj36 ak37 al38 am39 an40 ao41 ap42 aq43 ar44 as45 at46 au47 av48 aw49 ax50 ay51 az52 ba53 bb54 bc55 bd56 be57 bf58 b… | ||
..rakudo bc379f: OUTPUT«a1 b2 c3 d4 e5 f6 g7 h8 i9 j10 k11 l12 m13 n14 o15 p16 q17 r18 s19 t20 u21 v22 w23 x24 y25 z26 aa27 ab28 ac29 ad30 ae31 af32 ag33 ah34 ai35 aj36 ak37 al38 am39 an40 ao41 ap42 aq43 ar44 as45 at46 au47 av48 aw49 ax50 ay51 az52 ba53 bb54 bc55 bd56 be57 bf58 bg59» | |||
BenGoldberg | rn: my @a := 'a'..* Z~ 1..*; say @a[0..57; | ||
camelia | niecza v24-88-g1f87209: OUTPUT«===SORRY!===Unable to parse subscript at /tmp/E0ERVbRCNI line 1:------> my @a := 'a'..* Z~ 1..*; say @a[⏏0..57;Couldn't find final ']'; gave up at /tmp/E0ERVbRCNI line 1 (EOF):------> my @a := 'a'..* Z~ 1..*; … | ||
..rakudo bc379f: OUTPUT«===SORRY!===Unable to parse expression in subscript; couldn't find final ']'at /tmp/mzqSz3A1Jq:1------> my @a := 'a'..* Z~ 1..*; say @a[0..57;⏏<EOL> expecting any of: postfix statement end statemen… | |||
BenGoldberg | rn: my @a := 'a'..* Z~ 1..*; say @a[0..57]; | ||
camelia | rakudo bc379f: OUTPUT«a1 b2 c3 d4 e5 f6 g7 h8 i9 j10 k11 l12 m13 n14 o15 p16 q17 r18 s19 t20 u21 v22 w23 x24 y25 z26 aa27 ab28 ac29 ad30 ae31 af32 ag33 ah34 ai35 aj36 ak37 al38 am39 an40 ao41 ap42 aq43 ar44 as45 at46 au47 av48 aw49 ax50 ay51 az52 ba53 bb54 bc55 bd56 be57 bf58» | ||
..niecza v24-88-g1f87209: OUTPUT«a1 b2 c3 d4 e5 f6 g7 h8 i9 j10 k11 l12 m13 n14 o15 p16 q17 r18 s19 t20 u21 v22 w23 x24 y25 z26 aa27 ab28 ac29 ad30 ae31 af32 ag33 ah34 ai35 aj36 ak37 al38 am39 an40 ao41 ap42 aq43 ar44 as45 at46 au47 av48 aw49 ax50 ay51 az52 ba53 bb54 bc55 bd56 be57 bf58»… | |||
BenGoldberg | rn: my @a := 'a'..* Z~ 1..*; say @a[0..56]; | ||
camelia | rakudo bc379f, niecza v24-88-g1f87209: OUTPUT«a1 b2 c3 d4 e5 f6 g7 h8 i9 j10 k11 l12 m13 n14 o15 p16 q17 r18 s19 t20 u21 v22 w23 x24 y25 z26 aa27 ab28 ac29 ad30 ae31 af32 ag33 ah34 ai35 aj36 ak37 al38 am39 an40 ao41 ap42 aq43 ar44 as45 at46 au47 av48 aw49 ax50 ay51 az52 ba53 bb54 bc55 bd56 be57» | 00:33 | |
BenGoldberg | Odd that camelia truncates overly long results differently depending on rakudo vs niecza | 00:34 | |
Mouq | I don't think so; she prepends a ".." to the second argument | 00:35 | |
Oh no | |||
I'm dumb | |||
idk | |||
BenGoldberg | I wonder where camelia bugs get reported? :) | 00:36 | |
Mouq | just msg »ö« | 00:37 | |
00:39
xinming left
|
|||
BenGoldberg | Who is »ö«? | 00:40 | |
Mouq | raw.github.com/perl6/mu/master/misc/camelia.txt | 00:41 | |
00:41
xinming joined
00:48
ssutch left
01:00
arcterus left
01:06
stevan_ joined
01:15
PacoAir left
01:20
crab2313 left
01:23
cooper left,
Mouq left
01:25
cooper joined
01:30
arcterus joined
01:36
arcterus left
|
|||
japhb_ | When using the Rakudo REPL, why is there a noticeable pause *after* entering the first line to be evaluated, before showing the result? This pause doesn't seem to happen after submitting following lines (assuming they don't take appreciable time to run, of course), and we've already paid the interpreter/setting startup cost in order to get to the first REPL prompt, so what gives? I'm seeing it on both Parrot and JVM builds .... | 01:56 | |
Are there significant caches that need to be warmed up? If so, why aren't they warmed by the thawing of the setting? | 01:57 | ||
02:03
fgomez joined
|
|||
japhb_ | Er, and why does the irclog search function seem to have nothing newer than mid-July? | 02:08 | |
moritz: ^ | |||
02:13
cognominal left
|
|||
colomon | japhb: you're absolutely right that it happens. I have a vague memory that the thawing of the setting only happens at that point? It's something like that, anyway. | 02:16 | |
02:19
pjcj left
02:23
aindilis joined
03:06
pjcj joined
03:11
arcterus joined
03:36
zamolxes_ joined
03:37
zamolxes left,
dylanwh joined,
atrodo joined
03:38
logie left
03:39
logie joined,
sjohnson joined
03:46
preflex_ joined,
ChanServ sets mode: +v preflex_,
preflex left,
preflex_ is now known as preflex
04:00
celesta joined
|
|||
celesta | hello all | 04:00 | |
04:12
BenGoldberg left
04:42
stevan__ joined
04:44
stevan_ left,
atrodo left,
dylanwh left,
atrodo joined
04:45
dylanwh joined
04:58
celesta left
05:02
arcterus left
|
|||
diakopter | zacts: nutty, not nutty, almond joy, mounds.. just candy after all | 05:02 | |
05:02
mstwu00 joined
05:06
ssutch joined,
arcterus_ joined
05:12
kaare_ joined
05:14
arcterus_ left
05:15
arcterus joined
05:18
arcterus left
05:28
arcterus joined
05:29
logie left
05:34
fridim_ left
05:53
fgomez left
05:56
lue left
06:06
arcterus left
06:09
lue joined
06:14
arcterus joined
07:02
Aww joined
08:02
sidus joined
|
|||
masak | greetings, earthlings. | 08:03 | |
\o/ weekend \o/ | |||
08:12
fgomez joined
|
|||
masak | lizmat: re 656c8cb -- I don't understand the "into" parameter. why should classify/categorize have it, but not, say, reverse? | 08:17 | |
08:19
xinming left,
xinming joined
08:29
rindolf joined
08:39
spider-mario joined
|
|||
moritz | \o masak, * | 08:41 | |
masak: how's that t3 review coming along? | |||
lizmat | masak: because I didn't get around to it ? | 08:42 | |
masak | lizmat: :( :( :( | 08:45 | |
08:45
stevan__ left
|
|||
masak | lizmat: from my viewpoint, you're painting the lily, implementing as named parameters what we already have as excellent builtins. | 08:45 | |
08:45
stevan_ joined
|
|||
masak | lizmat: :into is just .push! | 08:46 | |
moritz | japhb_: ah, the cronjob that updated the search index has a problem, and I didn't notice, because the host doesn't send any mails :/ | ||
masak | moritz: I read through all of the t3 submissions yesterday. before lunch today I'll do another pass through them, writing as I go. | ||
moritz: in the afternoon, I'll write up a blog post. | |||
lizmat | masak: how would you push to a typed hash or a KeyBag ? | ||
moritz | masak: \o/ | 08:47 | |
masak | lizmat: is it a trick question? why wouldn't .push work? | ||
lizmat | @list.classiify(foo()).push | ||
is what you're saying? | |||
masak | no, so let's take a real example. | 08:48 | |
r: my %h = foo => 42; %h.push( [1..9].classify(* % 2) ); say %h.perl | |||
camelia | rakudo bc379f: OUTPUT«("foo" => 42, "1" => [1, 3, 5, 7, 9], "0" => [2, 4, 6, 8]).hash» | ||
masak | as far as I understand, I just reproduced with .push what :into purports to do. | 08:49 | |
lizmat | r: my KeyBag %h = foo => 42; %h.push( [1..9].classify(* % 2) ); say %h.perl | 08:50 | |
camelia | rakudo bc379f: OUTPUT«Nominal type check failed for parameter '$x'; expected KeyBag but got Int instead in method STORE_AT_KEY at src/gen/CORE.setting:8389 in method STORE at src/gen/CORE.setting:8149 in block at /tmp/DxcRcbevHC:1» | ||
masak | lizmat: that's not how you type container types. | ||
lizmat: unless you want a hash of keybags. | |||
lizmat | r: my $h=KeyBag.new; $h.push( [1..9].classify(* % 2) ); say $h.perl | 08:51 | |
camelia | rakudo bc379f: OUTPUT«Cannot call 'push'; none of these signatures match::(Any:U \SELF: *@values, Mu *%_) in method push at src/gen/CORE.setting:1508 in block at /tmp/Ma6UH1gJ7f:1» | ||
lizmat | so at least we would need to create .push for keybags | ||
masak | *nod* | ||
lizmat | well, it may be that this will be more correct syntax wise | 08:53 | |
masak | anyway, :into breaks the FP-ish ideal of not modifying the original data structure just as much as the classify/categorize for hashes you already axed did. | ||
lizmat | but performance wise, this will suck major as you will have the resulting hash in memory twice | ||
as you cannot make it lazy | |||
masak | I see your point, but I don't think that's a good reason to pollute the API. | 08:54 | |
lizmat | do we want real world usage of Perl6 or not, would be my point | 08:56 | |
moritz | japhb_: irclog search hiccup fixed, thanks for the report | 08:57 | |
lizmat | thinking colomon type work | ||
moritz has slowly been making his way through the go tour, and mostly likes what he sees so far | |||
lizmat | masak: if you feel that strongly about it, I suggest your revert 656c8cb8b9b7eac69869cdbbac7c435e58661169 | 08:59 | |
masak | ok. | ||
lizmat: API mistakes are very hard to back out of, for backward-compatibility reasons. :into looks like a mistake to me. | |||
lizmat | it would be nice to see someone else make a commit to rakudo for a change | 09:00 | |
afk& | |||
masak | wow, that is an impressive list of commits. | 09:02 | |
09:04
Vlavv_ left
|
|||
masak | lizmat: I won't revert anything. for some reason I thought we were talking about the spec here. it feels slightly more OK for an implementation to be doing this for performance reasons. | 09:05 | |
still, something like :into feels to me like part of the "private interface" of .classify, something it can use internally to be performant. | 09:06 | ||
09:09
spider-mario left
09:12
FROGGS joined
09:21
spider-mario joined
09:30
celesta joined
|
|||
celesta | hello all | 09:30 | |
09:30
dmol joined
09:32
spider-mario left,
spider-mario joined,
Vlavv joined
|
|||
moritz | hello celesta | 09:35 | |
celesta | r: grammar G {rule TOP {<foo>*}; proto rule foo {*}; token foo:sym<bar> {<sym>}; token foo:sym<baz> {<sym> foo<bar>};}; say "Ok." if G.parse('barbazbar'); | 09:39 | |
camelia | rakudo bc379f: OUTPUT«Ok.» | ||
celesta | is foo<bar> the correct way to refer to foo:sym<bar>? | ||
GlitchMr | r: grammar G {rule TOP {<foo>*}; proto rule foo {*}; token foo:sym<bar> {<sym>}; token foo:sym<baz> {<sym> foo<bar>};}; say foo<bar>.perl; | 09:40 | |
camelia | rakudo bc379f: OUTPUT«===SORRY!===Undeclared routine: foo used at line 1» | ||
GlitchMr | r: grammar G {rule TOP {<foo>*}; proto rule foo {*}; token foo:sym<bar> {<sym>}; token foo:sym<baz> {<sym> foo<bar>};}; say G::foo<bar>.perl; | ||
camelia | rakudo bc379f: OUTPUT«Could not find symbol '&foo' in method <anon> at src/gen/CORE.setting:11261 in any at src/gen/Metamodel.nqp:2663 in any find_method_fallback at src/gen/Metamodel.nqp:2651 in any find_method at src/gen/Metamodel.nqp:946 in block at /tmp/uabKrmLRG4:1»… | ||
09:41
zby_home joined
09:43
Vlavv left
|
|||
moritz | celesta: no, you can't refer to individual branches of a proto token | 09:46 | |
celesta: if you need that, the solution is to introduce another layer of indirection | |||
that is, a named rule which you can call from one of the sym<...> branches, but also directly | |||
celesta | thank you, i will try | ||
moritz | celesta: also note that you can't call a rule as G::foo<bar> | 09:47 | |
celesta: the proper way is to say G.parse('yourstring', :rule<foo>); | |||
celesta | aha, thanks | ||
moritz | (regexes are essentially methods, but you can't call them directly, because they need a bit of setup before; that's why you go through .parse) | 09:48 | |
09:48
arcterus left
09:49
fgomez left
09:51
dmol left
09:53
sidus left
10:00
dmol joined
10:01
Vlavv joined
|
|||
dalek | kudo/nom: 71afa3b | (Elizabeth Mattijsen)++ | src/core/KeyBag.pm: Implement KeyBag.push |
10:12 | |
moritz | lizmat++ | 10:14 | |
masak | lizmat++ | 10:16 | |
ooh, this is eerily similar to what I drew a while back: i.imgur.com/tBgQkxi.jpg (relationships between concepts such as group, field, etc) | 10:17 | ||
10:17
arcterus joined
|
|||
masak | neat. | 10:18 | |
lizmat | $ perl6 -e 'KeyBag.new.push( (1,2,3,4,4,3).classify({$_}) ).say' | ||
keybag("1" => 1, "2" => 1, "3" => 2, "4" => 2) | |||
masak | looks right. | 10:19 | |
10:20
mstwu00 left
|
|||
moritz | r: say KeyBag.new(1, 2, 3, 4, 4, 3) | 10:20 | |
camelia | rakudo bc379f: OUTPUT«keybag("1" => 1, "2" => 1, "3" => 2, "4" => 2)» | ||
celesta | hey masak! nice drawing indeed. | 10:21 | |
10:23
arcterus left
|
|||
lizmat | moritz: afaik, that behaviour of KeyBag is not specced | 10:24 | |
r: Hash.new( 1,2,3,4,4,3).say # very different from Hash.new | 10:25 | ||
camelia | rakudo bc379f: OUTPUT«("1" => 2, "3" => 4, "4" => 3).hash» | ||
lizmat | which, by the way, is also not specced afaik | 10:26 | |
*KeyBag.new | |||
cycling& | 10:27 | ||
masak | hey celesta! nice to see you back! | 10:33 | |
tadzik | nice, the yapc schedules is up | 10:37 | |
and I only got like 3 collisions by default :) | |||
masak | I'm in the last day, twice, which means I have all conf to procrastinate! \o/ /o\ | 10:45 | |
tadzik | \o/ | 10:47 | |
10:59
xinming left
11:02
xinming joined
11:03
dmol left
11:06
ilbot_nextgen joined,
ilbot_nextgen left
11:07
_ilbot left,
_ilbot joined
11:09
Timbus left
|
|||
moritz is in the spot right after jnthn++ -- will be hard to make a good impression after that :-) | 11:10 | ||
11:10
Timbus joined
11:11
autumn left
11:14
autumn joined
11:19
ssutch left
11:22
rindolf left
11:47
sidus joined
|
|||
moritz | .oO( cool panda: www.tagesschau.de/multimedia/bilder...eowebl.jpg ) |
12:16 | |
masak | :) | 12:17 | |
GlitchMr | Is KeyBag like collections.Counter in Python? | 12:21 | |
12:40
mtk left
12:42
pmurias joined
12:44
mtk joined
12:48
rindolf joined
|
|||
tadzik | I think it will be easier for you to find out what KeyBag is than to find someone who knows what collections.Counter is :) | 12:49 | |
pmurias | having just read the docs for them, they seems to be very similiar. I'm not sure they implement equivalent methods. | 12:55 | |
masak | GlitchMr: fwiw, the docs.python.org/2/library/collections.html has links to Smalltalk's Bag. | 12:58 | |
so yes, probably quite similar. | |||
13:08
woosley1 joined
13:09
woosley1 left
13:16
arcterus joined
|
|||
masak | I just had a real-world need to do .=squish on an array, but using &infix:<eqv> equality semantics rather than &infix:<===>. | 13:21 | |
13:21
arcterus left
|
|||
masak | (and I bet a similar need could occur with .uniq) | 13:23 | |
colomon | hmmm... | 13:29 | |
13:33
rindolf left
13:35
mstwu00 joined
13:40
logie joined
13:50
census joined
13:51
Ayiko joined
13:53
ponbiki joined,
ponbiki is now known as Guest87971
|
|||
masak | std: my %h = bar => 1; False ?? "" !! %h{"bar"} :exists | 13:54 | |
camelia | std c2215f0: OUTPUT«ok 00:00 45m» | ||
masak | rn: my %h = bar => 1; say False ?? "" !! %h{"bar"} :exists | 13:55 | |
camelia | niecza v24-88-g1f87209: OUTPUT«===SORRY!===You can't adverb that at /tmp/TuCGkQiPc9 line 1 (EOF):------> 1; say False ?? "" !! %h{"bar"} :exists⏏<EOL>Unhandled exception: Check failed at /home/p6eval/niecza/boot/lib/CORE.setting line 1502 (d… | ||
..rakudo 71afa3: OUTPUT«===SORRY!===You can't adverb thatat /tmp/OND_emVHy2:1------> 1; say False ?? "" !! %h{"bar"} :exists⏏<EOL> expecting any of: pair value» | |||
masak | curious. | ||
13:55
dylanwh left,
japhb_ left
|
|||
masak | do we have a (non-jnthn) expert at adverb attachology present? | 13:55 | |
rn: my %h = bar => 1; say False ?? "" !! (%h{"bar"} :exists) | |||
13:55
japhb_ joined
|
|||
camelia | rakudo 71afa3, niecza v24-88-g1f87209: OUTPUT«True» | 13:55 | |
masak | I sort of want to submit a rakudobug here... but Niecza seems to take Rakudo's side (against STD). | 13:56 | |
13:56
dylanwh joined
|
|||
masak | I agree that one cannot adverb a ternary ?? !! op, but I wasn't trying to do that. | 13:56 | |
I was trying to adverb the .{} | 13:57 | ||
japhb | moritz, you're welcome for the report, I'm glad it was a quick fix. :-) | 13:59 | |
jercos | r: my %h = bar => Mu; say %h{'bar'} :exists; say %h{'bar'} // "default" | 14:12 | |
camelia | rakudo 71afa3: OUTPUT«Truedefault» | ||
jercos | r: my %h = bar => Mu; say %h{'bar'} :exists ?? %h{'bar'} !! "default" | 14:14 | |
camelia | rakudo 71afa3: OUTPUT«(Mu)» | ||
jercos | seems a bit longhand :| | ||
14:19
logie left
14:23
logie joined
|
|||
masak | jercos: what seems longhand? writing ?? !! instead of // ? | 14:25 | |
jercos: usually people don't store type objects in their hash values... and then you can use // just fine. | 14:26 | ||
the semipredicate problem will haunt anyone who's willing to look hard enough for it. | |||
jercos | Yeah :| | 14:27 | |
I wouldn't use that for a failure condition obviously, just "if this hash value was set, use it, otherwise, use the default value" | 14:28 | ||
Heh, rakudo becomes so much more friendly when one remembers to install libreadline-dev *before* running Configure.pl | 14:29 | ||
14:29
logie left
|
|||
masak | jercos: heck, if you know you won't ever store *undefined* values of any kind, you get away with '%h<bar> || "default"' :) | 14:30 | |
so // is already a reply to (the first iteration of) the semipredicate problem. | |||
if you really really care, I guess you could wrap your desired logic into an infix operator. | 14:31 | ||
r: sub infix:<??? ///)(%h, $e, $d) { %h{$e} :exists ?? %h{$e} !! $d }; my %h = bar => Mu; say %h ??? 'bar' /// "default" | 14:32 | ||
camelia | rakudo 71afa3: OUTPUT«===SORRY!===Missing blockat /tmp/8_TduKUL28:1------> xists ?? %h{$e} !! $d }; my %h = bar => ⏏Mu; say %h ??? 'bar' /// "default" expecting any of: colon pair quote words» | ||
masak | hrm. | ||
oh! | 14:33 | ||
r: sub infix:<??? ///>(%h, $e, $d) { %h{$e} :exists ?? %h{$e} !! $d }; my %h = bar => Mu; say %h ??? 'bar' /// "default" | |||
camelia | rakudo 71afa3: OUTPUT«===SORRY!===Regex not terminatedat /tmp/HXXZ_yrWkW:1------> ar => Mu; say %h ??? 'bar' /// "default"⏏<EOL> expecting any of: postfix infix stopper infix or meta-infix prefix or term … | ||
14:33
coax75ohm joined
|
|||
masak | r: sub infix:<??? !!!>(%h, $e, $d) { %h{$e} :exists ?? %h{$e} !! $d }; my %h = bar => Mu; say %h ??? 'bar' !!! "default" | 14:33 | |
camelia | rakudo 71afa3: OUTPUT«True» | ||
masak | r: sub infix:<??? !!!>(%h, $e, $d) { %h{$e} :exists ?? %h{$e} !! $d }; my %h = bar => Mu; say (%h ??? 'bar' !!! "default") | ||
camelia | rakudo 71afa3: OUTPUT«True» | ||
masak | ...True? | ||
r: sub infix:<??? !!!>(%h, $e, $d) { say "%h{} ??? $e !!! $d" }; my %h = bar => Mu; say (%h ??? 'bar' !!! "default") | 14:34 | ||
camelia | rakudo 71afa3: OUTPUT«True» | ||
masak | oh, it never triggers :/ | 14:35 | |
r: sub infix:<@@@ !!!>(%h, $e, $d) { %h{$e} :exists ?? %h{$e} !! $d }; my %h = bar => Mu; say (%h @@@ 'bar' !!! "default") | |||
camelia | rakudo 71afa3: OUTPUT«===SORRY!===Two terms in a rowat /tmp/45NP2lveG8:1------> $e} !! $d }; my %h = bar => Mu; say (%h ⏏@@@ 'bar' !!! "default") expecting any of: postfix infix stopper infix or meta-infix state… | ||
masak | disappointing. | ||
14:40
Psyche^ left
14:42
Psyche^ joined
|
|||
GlitchMr | masak: I don't think ternary operators like that would work | 14:51 | |
r: sub infix:<is not>($a, $b) { $a !eqv $b }; say 3 is not 2 | |||
camelia | rakudo 71afa3: OUTPUT«True» | ||
GlitchMr | For this reason | ||
14:52
pupoque_ left
|
|||
GlitchMr | Different things should be different. | 14:52 | |
14:52
pupoque_ joined
|
|||
masak | a good point. | 14:56 | |
though I distinctly recall the ternary operator ?? !! being described as infix:<?? !!> | |||
14:56
pupoque_ left
14:59
pupoque joined
|
|||
timotimo remembers seeing a grammar rule for exactly that ternary operator | 15:01 | ||
masak | right. | 15:02 | |
15:02
benabik left
|
|||
masak | I rather think infix:<?? !!> is the correct thing and infix:<is not> is an accidental feature. | 15:02 | |
15:03
benabik joined
|
|||
arnsholt | Well, I don't think there's anything in the synopses that forbids operators with whitespace in them O=) | 15:06 | |
benabik | It's something like `token infix:<?? !!> { '??' <expression('precedence')> '!!' }` | ||
It's an infix operator that happens to parse another expression as part of it. | |||
arnsholt | Yeah, the OPP sees it as an infix, but the production does shenanigans internally so that it actually takes three arguments | 15:07 | |
timotimo | how about infix:<is␣not>(...)? | 15:10 | |
masak | arnsholt: oh, that makes sense. | ||
and that would allow for both GlitchMr's wish and mine to come true at the same time. | |||
arnsholt | But I agree that defining operators with whitespace in them is not to be trifled with =) | 15:12 | |
It might not confuse the parser, but I'm not so sure about the reader | |||
GlitchMr | Python does fine with 'is not' operator. | ||
And 'not in' operator. | |||
15:21
pupoque left
15:22
pupoque_ joined
15:24
pupoque_ left
15:25
pupoque_ joined
|
|||
masak | just because it's possible doesn't mean it's a good idea, or completely clear what it does. | 15:29 | |
15:34
cognominal joined
15:37
dmol joined
15:44
hanekomu_ left
15:45
pupoque_ left
15:46
hanekomu joined,
hanekomu left,
pupoque_ joined,
hanekomu joined
15:55
dmol left
15:57
pupoque_ left
15:58
pupoque_ joined
|
|||
FROGGS | masak: I experimented a little more, and currently I have the problem that it doesnt do the tasks in parallel :/ | 16:00 | |
masak: gist.github.com/FROGGS/0cfae647d28c493df73e | |||
masak | FROGGS: have you talked to the #parrot folks about this? | ||
FROGGS | the add-i-mt.t script is sort of pir-only, and work pretty well, the other script calls a lexical sub, and just uses one core for the tasks | 16:01 | |
masak: not about this issue | |||
but I will do this, and I hope somebody of them is around :o) | |||
I fear it is serializing the tasks because they are accessing the same lexical sub (of the main task) | 16:02 | ||
16:18
arcterus joined
16:20
logie joined
16:22
arcterus left
16:54
mstwu00 left
16:59
pupoque_ left
17:00
pupoque_ joined,
ggoebel joined
17:01
mstwu00 joined
17:02
pupoque_ left
17:03
pupoque_ joined
17:10
logie left
17:16
benabik left
17:17
benabik joined
17:26
logie joined
|
|||
dalek | kudo/nom: e9523e3 | (Elizabeth Mattijsen)++ | src/core/KeyBag.pm: Simpplify Pair handling in KeyBag.new: auto-vivification is your friend |
17:26 | |
17:32
pecastro joined
17:40
fgomez joined
|
|||
[Coke] | pmichaud++ | 17:50 | |
17:51
zby_home left
|
|||
lizmat | [Coke]: not that I disagree, but why now ? | 17:51 | |
17:52
autumn left
|
|||
pmichaud | probably wrong window from a /privmsg I sent. | 17:52 | |
masak | pmichaud++ # just in case | 17:53 | |
pmichaud | or a sneaky way to get me to say something on-chan :) | ||
masak | pmichaud! \o/ | ||
lizmat | pmichaud! | ||
17:54
autumn joined
|
|||
pmichaud | good afternoon, #perl6 | 17:54 | |
lizmat | good evening, pmichaud! | ||
pmichaud | I'm only here for a few minutes; this is the first time I've sat at my desk in almost a week. :-/ | ||
masak | then I'm glad [Coke] outed you! :) | 17:55 | |
lizmat | glad to have you here nonetheless, however short! | ||
timotimo | we appreciate you taking the time out of those valuable few minutes to say hi to your loyal following ;) | ||
dalek | kudo/nom: e1bb352 | (Elizabeth Mattijsen)++ | src/core/KeyBag.pm: Abstracted .new behaviour into a separate subroutine REGISTER |
17:56 | |
17:58
fridim_ joined
|
|||
dalek | kudo/nom: 044950d | (Elizabeth Mattijsen)++ | src/core/KeyBag.pm: Make KeyBag.push work similar to KeyBag.new, suggested by colomon++ |
18:02 | |
celesta | delayed greetings pmichaud | 18:11 | |
FROGGS | hi pmichaud | 18:12 | |
GlitchMr | github.com/rakudo/rakudo/commit/08...df12760738 | 18:24 | |
wow, now I'm surprised | |||
is readonly was seriously removed? | |||
lizmat | only as a *variable* trait, not as an attribute or subroutine trait | 18:25 | |
GlitchMr | But, I actually used my $variable is readonly = something; | 18:26 | |
Well, guess I was wrong. | |||
lizmat | well, it didn't work before | ||
GlitchMr | And I'm sure I saw is readonly with my in roast. | ||
lizmat | well, no more :-) | 18:28 | |
I understand from TimToady that ::= is the syntax of choice | |||
GlitchMr | ::= is not a constant. | 18:29 | |
(but with constant values, it works like constant, I guess) | |||
Actually, it appears to be constant in Niecza. | |||
lizmat | FWIW, before jnthn++ implemented the variable traits framework, "my $a is foo" was basically a noop | 18:30 | |
celesta | r: my $x ::= 42; $x = 5; | 18:31 | |
camelia | rakudo 044950: OUTPUT«Cannot modify an immutable value in block at /tmp/sUF4lYJ4nY:1» | ||
diakopter | hi | 18:32 | |
GlitchMr | Yes, it appears to work, but... | ||
r: my $a = 2; my $b ::= $a; $b = 42; say ($a, $b); | |||
camelia | rakudo 044950: OUTPUT«42 42» | ||
diakopter | ingy: u around? | 18:33 | |
GlitchMr | But I assume it's Rakudo bug | ||
18:33
atta_ joined
|
|||
lizmat | more a NYI | 18:33 | |
18:33
atta_ is now known as atta
|
|||
celesta | r: my $a = 2; my $b ::= \$a; $b = 42; say ($a, $b); | 18:34 | |
camelia | rakudo 044950: OUTPUT«Cannot modify an immutable value in block at /tmp/gCXqLdMhlm:1» | ||
GlitchMr | \ doesn't mean what you think it means. | 18:35 | |
r: my $a = 2; my $b ::= \$a; say ($a, $b); | |||
camelia | rakudo 044950: OUTPUT«2 2» | ||
GlitchMr | r: my $a = 2; my $b ::= \$a; say ($a.perl, $b.perl); | ||
camelia | rakudo 044950: OUTPUT«2 Capture.new( list => (2,).list, hash => EnumMap.new())» | ||
GlitchMr | r: my $a = 2; my $b ::= \$a; say ($a + 3, $b + 3); | ||
camelia | rakudo 044950: OUTPUT«5 4» | ||
celesta | oh ^^ | 18:36 | |
colomon | pmichaud! \o/ | ||
GlitchMr | \ doesn't mean constant. | ||
Just like, + doesn't mean constant. | |||
r: my $a = 2; my $b ::= +$a; say ($a + 3, $b + 3); | |||
camelia | rakudo 044950: OUTPUT«5 5» | ||
GlitchMr | r: my $a = 2; my $b ::= +$a; $b = 1; say ($a + 3, $b + 3); | 18:37 | |
camelia | rakudo 044950: OUTPUT«Cannot modify an immutable value in block at /tmp/Uw_5TmwPcx:1» | ||
GlitchMr | Even when it works in that case. | ||
colomon | lizmat: I don't know KeyBag.push should work like KeyBg.new or not. Right now (unless I've missed changes), rakudo's KeyBag.new doesn't actually conform to the (possibly only in TimToady, pmichaud, and my heads) KeyBag spec. | 18:38 | |
dalek | kudo/nom: 103d5ea | (Elizabeth Mattijsen)++ | src/core/KeyBag.pm: Implement keybag(), so that at least KeyBag.perl can roundtrip |
||
colomon | lizmat: I need to port the Set/Bag/etc changes I made to Niecza back in June to Rakudo | 18:39 | |
lizmat | is there a diff I can look at, so I can do that for you? | ||
colomon | lizmat: it's basically all the commits to Niecza between June 7 and June 24. | 18:41 | |
lizmat: note that the Unicode set/bag operators can't work in Rakudo's core yet. | |||
lizmat | I'll add them as comments | 18:42 | |
:-) | |||
colomon | no! | ||
lizmat | no? | ||
colomon | it's the unicodeness of the operators that's the problem, it's still just as bad in comments | ||
lizmat | don't we want them in rakudo? | ||
masak | r: say { :foo<2>, :bar<4> }.invert.^name | ||
lizmat | ah, yuck | ||
camelia | rakudo 044950: OUTPUT«List» | ||
colomon | we do want them long term, but Parrakudo cannot handle codepoints > 256 without getting grotesquely slow in the parsing stage of the build. | 18:43 | |
dunno if the same problem exists in jakudo or not. | |||
lizmat | ok, gotcha, we don't want build to get much slowe still | ||
slower | 18:44 | ||
colomon | it was like 4x slower or something. | ||
lizmat | yuck, no, please :-) | ||
diakopter | YI*KES | ||
18:57
PacoAir joined
|
|||
lizmat | masak: wrt to squish/uniq needing a custom op, the code already says: | 18:57 | |
# This needs a way of taking a user-defined comparison | |||
# specifier, but AFAIK nothing has been spec'd yet. | |||
method uniq() { | |||
masak | oh, interesting. | 18:59 | |
seems colomon++ wrote that in 813c6ae2 :) | 19:00 | ||
colomon | that was like four years ago, wasn't it? | 19:01 | |
masak | 2011. | ||
quick, off-the-cuff suggestion: something like :by like the .sort-like functions use. | |||
doesn't have to be called :by, though -- in fact, that would probably just be confusing. | |||
19:01
ggoebel left
|
|||
lizmat | :using | 19:01 | |
masak | uniq(:using), yes, maybe. | 19:02 | |
lizmat | :using(&infix:<===>) | ||
would be the default, I guess | |||
masak hits the thesaurus | |||
lizmat | mind you, uniq() would be more difficult than .squish to implement | ||
masak | the candidates :under, :with or :through stand out for me. | 19:03 | |
lizmat: oh, good point. | |||
lizmat | .squish would be trivial | ||
so spec away, I would say :-) | 19:04 | ||
LHF, I like it | |||
masak | hehe | ||
no, let's discuss .uniq a bit more. | |||
what's a viable way to implement .uniq(:with(&[eqv])) ? | 19:05 | ||
masak doesn't like to spec unviable things | |||
lizmat | maybe don't use a hash to implement, but a binary chop on a list | 19:06 | |
hmmm… ok, lineair check ? | |||
masak | yes, hashes seem to work for === and eq | ||
colomon | use a hash, but it's of custom type that somehow does… nah, I don't see how to make that work | ||
masak | and maybe for things like == too | ||
but eqv is problematic | |||
lizmat | well, that would use a list then | 19:07 | |
and be slower | |||
19:07
isBEKaml joined
|
|||
colomon | much slower. might be the only way to make it work, though. <ponder> | 19:07 | |
lizmat | brb | 19:08 | |
masak | widening the gaze a bit -- would we accept *any* equivalence relation, even user-defined ones? | ||
if so, how? | |||
I feel the spec patch would run straight into Java's .equals/.hashCode territory. | |||
i.e. for every equivalence relation you would need not only a way to tell if two things are equal/equivalent, but also a canonical way to hash them. | 19:09 | ||
19:09
PacoAir_ joined
19:10
ggoebel joined
19:11
PacoAir left
19:14
PacoAir joined,
PacoAir_ left
19:15
ggoebel left
|
|||
lizmat | masak: not if you're building a list | 19:18 | |
and that's what uniq is doing anyway | 19:19 | ||
19:19
PacoAir left
|
|||
lizmat | it will just be slower for larger number of unique values | 19:19 | |
which could be offset by being able to do a binary chop somehow | |||
masak | ah, ok. | 19:20 | |
yes, I can see a binary chop being a workable optimization in the cases where we do have a canonical hash function. | |||
ok, I think we have enough to spec this, then. | |||
lizmat | maybe also spec binary chop on List ? | 19:21 | |
masak | lizmat: note, though, that the binary-chop list would need to be for internal use only, since .uniq still needs to preserve the original order. | ||
19:21
ggoebel joined
|
|||
lizmat | well, optionally indicate you're *not* interested in the order ? | 19:22 | |
:race ? | |||
masak | mmmmh | ||
feels to me we're straying too far away from the core semantics of .uniq, in that case. | 19:23 | ||
lizmat | perhaps, maybe if .uniq is called inside a block with :race setting | ||
masak | hrm, .uniq isn't even spec'd to preserve order. instead it talks a bit about implementation details. :( | 19:24 | |
lizmat | see? problem solved :-) | 19:25 | |
19:25
ggoebel2 joined,
ggoebel left
19:26
census left
|
|||
masak | hehe | 19:26 | |
colomon | interesting. | 19:27 | |
if it doesn't have to keep order, it could be a simple one-liner. | |||
still, I reckon it should keep order. | 19:28 | ||
should it be lazy? | |||
masak | it should definitely keep order. | ||
lizmat | it is lazy now, by virtue of map {} | ||
masak | it seems to me it *can* be lazy. | ||
lizmat | I think there are spectest checking its laziness | 19:29 | |
colomon | lazy definitely feels right to me. | ||
lizmat | also, you could consider .uniq as a sort of KeyBag | 19:30 | |
but that would not be lazy :-) | 19:31 | ||
19:32
lue left
|
|||
dalek | ecs: 02ee80d | masak++ | S32-setting-library/Containers.pod: [S32/Containers] explain uniq/squish a bit more - both uniq and squish preserve order - omit some implementation details which shouldn't be in the spec - give examples |
19:34 | |
masak | will spec :with in a separate commit. | ||
for easier revertability :) | |||
(and that's also why I made this commit first, because it's less controversial) | |||
19:37
coax75ohm left
|
|||
lizmat | looks fine to me | 19:39 | |
19:40
dmol joined
|
|||
jnthn returns from vacation | 19:41 | ||
yoleaux | 29 Jul 2013 11:54Z <lizmat> jnthn: spectests are clean on github.com/rakudo/rakudo/commit/f8e970b1b9 , I can hardly believe it | ||
preflex | yoleaux: you have 1 new message. '/msg preflex messages' to read it. | ||
dalek | ecs: ec1b7c6 | masak++ | S32-setting-library/Containers.pod: [S32/Containers] specify :with for .uniq/.squish See irclog.perlgeek.de/perl6/2013-08-03#i_7407490 for relevant spec discussion. |
||
masak | jnthn!!! \o/ | ||
lizmat | jnthn! | ||
timotimo | hey jnthn, had a good time? :) | ||
jnthn | timotimo: Yes, thanks. The weather was great for looking at mountains, though I never experienced Switzerland being so hot! | 19:42 | |
lizmat | yes, that was quite extraordinary | 19:43 | |
timotimo | quite; this whole part of europe has been hotter than usual it seems to me | ||
lizmat | otoh, we had 35.7 degrees here yesterday | ||
which was the hottest 2nd August on record | |||
masak .oO( Orthax laughs at the humans puny records! ha. ha. ) | 19:44 | ||
jnthn | lizmat: In github.com/rakudo/rakudo/commit/f8...1b9#L1R188 any reason not just $!items := nqp::list() | ||
masak | humans'* | ||
jnthn | lizmat: Was only a few under that where I was staying at the hottest times... | 19:45 | |
labster | ^^ masak++ knows how to use apostrophes in English better than most Americans. | ||
good postnoon, #perl6 | |||
jnthn | .oO( humans's ) |
||
19:45
lue joined
|
|||
lizmat | jnthn: probably cargo culting | 19:46 | |
masak | jnthn: no, "humans's" is Gollum, not English ;) | ||
isBEKaml | humansssss | 19:47 | |
perigrin | nasty humanses | ||
labster | this topic has precious little to do with perl 6 | ||
lizmat | .oO( some Ferengi in there ? ) |
||
masak | labster: I just pushed two spec commits, I deserve some off-topic pronunciation discussion ;) | 19:48 | |
lizmat | jnthn: on later commits, I already got rid of that | 19:49 | |
jnthn | lizmat: OK. I haven't been following at all :) | ||
GlitchMr | github.com/rakudo/rakudo/commit/b1...58f9a89b6a | ||
github.com/rakudo/rakudo/commit/84...ac20806d85 | |||
lizmat | masak: maybe it should be specced that the *first* of the "unique" values is returned ? | ||
GlitchMr | This is so fun | ||
perigrin | jnthn: I read somewhere not too long ago that since the plural possesive in thsi case (humans') sounds like the simple plural (humans) that masak was correct ... if there had been an extra 's' sound they're starting to allow / adopt using a 's (humans's) | ||
GlitchMr | Insert, remove, insert, remove, insert... | ||
Just to avoid git blame? | 19:50 | ||
lizmat | well, yes, I'd like to preserve history | ||
masak | lizmat: yes, that should be more clear. stand by for fix. | ||
timotimo | personally, i would even have gone so far as to git push -f a rebased version or something | ||
GlitchMr | This is the strangest thing I've seen yet in this repository. | ||
lizmat | well, it was hot :-) | 19:51 | |
labster | github needs a memory hole button | ||
lizmat | maybe also put in a reference to .classify, if one would like to keep the uniq values grouped, rather than just the first | ||
GlitchMr | I like reading commits in Rakudo repository. | 19:52 | |
masak | oh, I just noticed that .uniq says it returns Positional:D. I think that's too weak. it should be brave and say it returns List:D. | ||
GlitchMr | Then again, I sometimes used git push -f, so well... | ||
Not in Rakudo repository, but well... | |||
lizmat | implementation may not be able to do that at that point in the setting yet | 19:53 | |
GlitchMr | github.com/rakudo/rakudo/commit/4a...00f34b7cf2 | 19:54 | |
classify_list? Seriously? Why not classify-list? | 19:55 | ||
lizmat | jnthn: I found out that nqp::p6listitems(self); already did what I wanted to do | ||
GlicthMr: classify_list is not part of the API or spec | 19:56 | ||
GlitchMr | r: 0 / 0 | ||
camelia | rakudo 103d5e: OUTPUT«Divide by zero in method sink at src/gen/CORE.setting:11264 in method BUILDALL at src/gen/CORE.setting:887 in method bless at src/gen/CORE.setting:828 in method new at src/gen/CORE.setting:813 in method new at src/gen/CORE.setting:811 in sub DIVIDE_NUMB… | ||
GlitchMr | r: 3 / 0 | ||
camelia | rakudo 103d5e: ( no output ) | ||
GlitchMr | Like... 0 / 0 is more of divide by zero than 3 / 0? | ||
I | 19:57 | ||
I'm not sure. Is 0/0 more wrong than 3/0? | |||
dalek | ecs: fa46a81 | masak++ | S32-setting-library/Containers.pod: [S32/Containers] clarify that the *first* is kept ...in .uniq and .squish -- not the last, or an arbitrary one. The first. |
19:58 | |
ecs: 29aeb7d | masak++ | S32-setting-library/Containers.pod: [S32/Containers] .uniq/.squish returns List We can be more precise than just Positional. Generality is only appreciated in parameter types, not in return types. |
|||
osystem: 335207b | tadzik++ | META.list: Add JSON::Unmarshal |
19:59 | ||
tadzik | yay, contribution | ||
labster | yaya | 20:03 | |
*yay | 20:04 | ||
reminds me that I have some broken modules to fix. | |||
tadzik | yeah, me too :( | 20:05 | |
20:05
FROGGS left
|
|||
colomon | me too. | 20:06 | |
tadzik | don't we all :) | ||
20:06
jaldhar joined
|
|||
moritz | \o | 20:07 | |
colomon | o/ | ||
colomon is not sure his schedule will permit him to do any significant p6 work in August. :( | |||
lizmat | colomon:: consider porting KeyBag/Set work of Niecza off your plate | 20:08 | |
colomon | \o/ | ||
lizmat++ | |||
20:08
FROGGS joined
20:13
ggoebel2 left
20:14
ggoebel joined
|
|||
dalek | kudo/nom: 8364f64 | (Elizabeth Mattijsen)++ | src/core/ (3 files): Ununderscore internal methods for classification as suggested by GlitchMr We don't to keep the best captain unhappy, now, do we? :-) |
20:19 | |
lizmat | actually, that should have read helmsmen | 20:21 | |
isBEKaml | lizmat: "we don't to keep" ? :-) | 20:22 | |
lizmat | *want | ||
*sigh* | |||
:-) | |||
20:23
jaldhar left
20:25
jaldhar joined
|
|||
tadzik | we want to keep? :P | 20:25 | |
20:26
ggoebel left
|
|||
timotimo | tadzik: would you like to comment on my not-yet-complete re-implementation of pod6 table parsing? | 20:27 | |
gist.github.com/timo/6132249 - here it is | |||
lizmat | I was trying to refer to the saying "the best helmsmen stand on shore" | 20:29 | |
masak | *zing*! | 20:31 | |
oh, it's a Dutch proverb, apparently. | 20:33 | ||
lizmat | Bachelors' wives and maidens' children are well taught. | ||
literal meaning: "The watchers always know better than the doers" | 20:34 | ||
isBEKaml | masak: did you just have a late realisation after laser-firing lizmat? :-) | ||
masak | isBEKaml: yes, when I understood what proverb was alluded to. | 20:37 | |
20:37
kst` joined
20:38
ggoebel joined
|
|||
isBEKaml | masak: I didn't make much of it since I thought that alluded to armchair critics. :D | 20:38 | |
lizmat | you shouldn't make much of it | 20:39 | |
and I should get my proverbs right before trying to be funny | 20:40 | ||
isBEKaml | armchair critics are more of a nuisance than funny. | ||
masak | I have no experience with armchair critics, but from what I can deduce, they're a damn nuisance! :P | 20:41 | |
timotimo | haha, did you just manage to pull of armchair criticism of armchair critics? | ||
isBEKaml | YEGAWDS another autopun! | ||
jnthn | autopun :P | ||
lizmat is not looking forward to act.yapc.eu/ye2013/talk/4573 | 20:42 | ||
masak | nice, I don't even have to tag them myself anymore... | ||
lizmat | talk about armchair critics | ||
masak | lizmat: wow, the abstract gives me a gag reaction. | ||
lizmat: you will not find me in that discussion. | 20:43 | ||
isBEKaml | masak: you're listed among the attendees. | ||
masak | though apparently I starred it. hm. | ||
yeah. | |||
lizmat | I will be there | ||
masak | oh, it's one of the end-of-the day things. | ||
lizmat | nope: 10:50 is not end of the day in my book | 20:44 | |
masak | *sigh*, and there are so many important things to spend community time talking about... | ||
isBEKaml | Oh, next week - Have fun in EU! | ||
masak | lizmat: troo. it's beginning of last day. | ||
so people who oversleep don't have to attend it? :D | |||
jnthn | masak: All the more reason to drink plenty of the cruise :P | ||
*on | |||
masak | "*yawn* what did I miss?" -- "you lucky bastard" | ||
isBEKaml | that sounds a lot like [Coke] *yawn* *yawn* | 20:45 | |
FROGGS | hi jnthn | ||
jnthn | o/ FROGGS | ||
lizmat | would it make much sense to keep a separete candidate of .squish around with === hardwired, as opposed to calling a sub passed as a parameter? | 20:46 | |
masak | if by 'candidate' you mean 'multi', sure. | 20:47 | |
lizmat | ok | ||
masak | that's an implementation detail, since the signature belongs to the proto ;) | ||
lizmat | yes, it's about the implementation :-) | 20:50 | |
tadzik | timotimo: why the changes? :) | 20:52 | |
timotimo | tadzik: i felt it was nicer to split the columns and rows already in the grammar rather than when the table is finished | 20:55 | |
and i think it'll be easier to make formattingcode parsing working with this setup | |||
although i find it hard to imagine i can easily put it into the $<column>= part without too much troubl | 20:56 | ||
tadzik | oh! | 20:57 | |
lizmat | $ perl6 -e '(1,2,2,3,33,34,4).squish( :with( -> $a,$b { substr( $a,0,1 ) eq substr( $b,0,1 ) } ) ).say' | ||
1 2 3 4 | |||
timotimo | also, perl6 is supposed to be "1 pass parsing" throughout ;) | ||
that's cute, lizmat :) | |||
masak | lizmat++ | ||
timotimo | tadzik: and i think i can make this rule work with both =begin table/=end table and =for table, for re-use reasons | 20:58 | |
tadzik | timotimo: I'm all for the idea | ||
20:59
pippo joined
|
|||
timotimo | the only way i'll probably be able to make formatting code parsing work is to keep a stack of openers/closers around and do the proper parsing after the table cell is finished :( | 20:59 | |
tadzik | I wonder though, do you cover all the cases? | ||
timotimo | not yet | ||
there is not much example data to work with, sadly | |||
tadzik | I think there was a reason why I did it the way I did it | ||
dalek | kudo/nom: 0f658e9 | (Elizabeth Mattijsen)++ | src/core/List.pm: Updated List.squish to spec |
21:00 | |
tadzik | I mean, you may not know where the column delimiter is until the last table row | ||
timotimo | ... for real? | ||
tadzik | let me craft an example | ||
timotimo | my code already knows to construct delimiters on the fly. | ||
tadzik | gist.github.com/tadzik/6147963 | 21:01 | |
this table turns out to be 1-column wide | |||
timotimo | no, that's terrible! | ||
tadzik | but you only know that when you reach the last row | ||
yes | |||
but I'm afraid the spec allows that | |||
and that was the reason why I did it the way I did it | 21:02 | ||
I'd be happy to be wrong tho :P | |||
or we may just choose to sanitize the spec a bit | |||
timotimo | i don't think the spec allows that | ||
not only does it say that the cells are to be parsed as nested para blocks, meaning whitespace will be squished | |||
also, i interpret this: Columns are separated by two or more consecutive whitespace characters, or by a vertical line (|) or a border intersection (+), either of which must be separated from any content by at least one whitespace character. | |||
as saying that two or more consecutive whitespace characters *will* separate columns | 21:03 | ||
tadzik | hm | ||
timotimo | and i'd be inclined to make too many whitespace in the wrong place give an error. | ||
i'll still add more stuff to be allowed as separators, like BOX DRAWINGS | |||
21:03
kaare_ left
|
|||
pippo | Hello to everybody. My rakudo JVM crashes when executing: "my $string = ""; for 1..2000 {$string ~= "Text\n"}; $string.lines;" | 21:04 | |
tadzik | looking at it now, I think I agree with you :) | ||
timotimo | yay! \o/ | ||
tadzik | maybe I overthought that a bit | ||
you may want to ask TheDamian though | |||
it's possible that I did :P | |||
timotimo | pippo: i think the "maximum stack size" or "maximum heap size" or something is set too low in the "perl6" starter script | ||
but TheDamian is famous and i'm scared! | 21:05 | ||
lizmat | fwiw, I'm not seeing any difference in performance between the hard wired === .squish variant and the one with :with | ||
so I'm going to go back to just a single method for simplicity | |||
21:05
Bzek joined
|
|||
timotimo | anyway, gotta run now, going to watch a movie with a few friends :) | 21:05 | |
pippo | Thank you. I have started java with -Xmx2g | ||
jnthn | pippo: How does it crash, exactly? | 21:06 | |
pippo | It exits the program. | 21:07 | |
timotimo | maybe --ll-exception will give you a nicer error message? | 21:08 | |
tadzik | timotimo: you should be scared :P | ||
I had a few conversations with TheDamian about Pod and its spec | |||
21:09
aindilis left,
aindilis joined
|
|||
tadzik | they have been insightful, and sometimes left me with a reaction like goo.gl/87XQqi | 21:09 | |
there are funny things in S26, very much in the spirit of "tormenting implementors for the sake of users" | 21:10 | ||
diakopter | well they could rename it Perl 1 | ||
tadzik | which is fair enough | ||
oh, yapc tickets | 21:11 | ||
colomon | jnthn! \o/ | ||
jnthn | hi colomon | ||
saw your blog post :) | |||
colomon | jnthn++ | ||
masak links to pmthium.com/2013/06/a-perl-6-develo...l-podcast/ because it's required reading for anyone who's planning to come to YAPC::EU, according to masak | 21:13 | ||
diakopter | awesome, so if I mail [email@hidden.address] it will go to everyone who hasn't purchased a ticket but has registered? awesome. way to go. | ||
colomon | jnthn: is there a good way to profile jakudo yet? I'm curious where the 11 minutes are spent. : | 21:14 | |
:) | |||
lue | hello world! o/ | 21:15 | |
dalek | kudo/nom: 239ee15 | (Elizabeth Mattijsen)++ | src/core/List.pm: There is no performance difference between candidates, so lose them |
||
kudo/nom: 5d9f71d | (Elizabeth Mattijsen)++ | src/core/Any.pm: Make sure the sub and generic method version pick up optional :with |
|||
masak | lue! \o/ | ||
21:15
dmol left
|
|||
jnthn | colomon: jvisualvm may give some ideas | 21:18 | |
21:19
dmol joined
|
|||
colomon | k, bookmarked in case I have slow moments next week. :) | 21:20 | |
dalek | ast: e9c1af8 | (Elizabeth Mattijsen)++ | S32-list/squish.t: Added tests for :with parameter to squish |
21:25 | |
21:30
isBEKaml left
|
|||
lizmat | masak: would something like this make sense (to spec)?: squish( (1,2,2,3,33,34,4), :with<===> ).say | 21:36 | |
not operator specified as string | |||
21:37
xinming left
21:39
xinming joined
|
|||
lizmat | r: my $a; my $b; my $w="==="; say eval("&[$w]")($a,$b) # better way than using eval() ? | 21:39 | |
camelia | rakudo 0f658e: OUTPUT«True» | ||
21:49
FROGGS left
21:50
arcterus joined
21:51
coax75ohm joined
|
|||
masak | lizmat: specifying operators as strings feels "poor man's" to me. we never do that anywhere else in the language API. | 21:54 | |
21:55
arcterus left
|
|||
lizmat | oddly enough it feels very natural to me. What does that say about me? :-) | 21:55 | |
masak | there's something to be said for rich objects carrying their own full information (like function objects), instead of strings having to be parsed and decoded and dereferenced and stuff. | ||
lizmat: it's a matter of habit, to be sure. | |||
21:56
raiph joined
|
|||
lizmat | well, let me put it this way: the &[===] syntax was new to me | 21:56 | |
raiph | hi #perl6 | ||
masak | it's just sugar for &infix:<===> | ||
lizmat | and I wonder how many Perl6 newbies will know &[===] or &infix:<===> | ||
masak | r: say &infix:<===> === &[===] | ||
camelia | rakudo 0f658e: OUTPUT«True» | ||
masak | raiph: hai | 21:57 | |
lizmat | *that* seems esoteric to me, whereas :with<===> feels natural to me | ||
21:57
coax75ohm left
|
|||
lizmat | the fact that internally it would have to be parsed and decoded etc, doesn't matter for the casual Perl6 programmer much, I would think | 21:58 | |
masak | I don't find much sway in that argument. the casual Perl 6 programmer should probably stay away from :with, then :) | 21:59 | |
at least until he's less... casual. | |||
I don't think it's a good idea to let strings substitute for actual functions. | |||
we don't do that anywhere else. | 22:00 | ||
(and for good reasons) | |||
jnthn | Strings don't carry a lexical scope with them for one. | ||
masak | and (though it doesn't matter in this case), just '===' doesn't convey whether it's an infix or some other category. | 22:01 | |
raiph | Fwiw I'm pretty sure P6 newbies will end up encountering &infix:<===> etc. very early. | ||
pippo | r: say "Hello" | 22:03 | |
camelia | rakudo 0f658e: OUTPUT«Hello» | ||
masak | it does require understanding that subs end up in the & sigil-space. | ||
but that's good to learn early on, too :) | 22:04 | ||
r: sub hello { say "Hello }; my $f = &hello; $f() | |||
camelia | rakudo 0f658e: OUTPUT«===SORRY!===Variable '$f' is not declaredat /tmp/20ilqBweq7:1------> sub hello { say "Hello }; my $f⏏ = &hello; $f() expecting any of: postfix» | ||
masak | r: sub hello { say "Hello" }; my $f = &hello; $f() | ||
camelia | rakudo 0f658e: OUTPUT«Hello» | ||
lizmat | ok, idea scratched, code put in a branch :-) | 22:05 | |
well, at least I write some real code today: now up to 62 consecutive commits (ok let's scratch about 10 silly ones) | 22:08 | ||
I hope jnthn, or someone else, will break this streak soon | |||
masak | :) | 22:11 | |
lizmat++ | 22:12 | ||
lizmat | gnight #perl6! | ||
raiph | lizmat++ # practical, patient, persistent | ||
celesta | farewell lizmat | ||
22:14
pippo left
|
|||
raiph | what's the near term prognosis for jakudo, in comparison to parakudo, for running programs, memory-wise? | 22:16 | |
lue | I'm looking at &[===] with the thought "Waitaminute! I can treat an operator as a function to pass around /without/ that cumbersome infix: business? Cool!" | 22:19 | |
masak | raiph: try it and see? compile both and measure memory consumption? | ||
lue: I was going to say it's fairly new syntax -- but it turns out it's from January 2009. | 22:22 | ||
'night, #perl6 | 22:26 | ||
raiph | goodnight masak | 22:32 | |
22:33
pmurias left
|
|||
celesta | gnight masak | 22:33 | |
22:39
lizmat joined
22:42
spider-mario left
22:52
arcterus joined
23:01
nebuchadnezzar left,
nebuchadnezzar joined
23:04
arcterus_ joined
23:05
arcterus left
23:09
pippo joined,
pippo left
|
|||
celesta | please, somebody help perl 6 newbie with grammar? | 23:15 | |
colomon | yes? | 23:20 | |
celesta | colomon: private message ok for you? | 23:21 | |
colomon | sure, but you're more likely to get a good answer if you ask in public. I don't know everything. Not even close. | ||
(not to mention I'm currently in charge of a 4-year-old… though we've got maybe 15 minutes until this Shaun the Sheep runs out.) | 23:22 | ||
raiph | colomon: did you get an idea of the memory usage of jakudo vs parkudo for the STEP script you discussed in your blog post? | 23:37 | |
celesta | thank you very much colomon++ | ||
colomon | raiph: not really, because jakudo requires the -Xmx max memory argument, but then seems to instantly allocate that much memory. | 23:38 | |
raiph: there's probably a way to analyze that, but I don't know how. | |||
raiph | gotchya. thanks. | 23:39 | |
celesta | farewell #perl6 good night | ||
raiph | goodnight | ||
23:39
celesta left
|
|||
colomon | raiph: one interesting tidbit is that java is using multiple cores -- I'm presuming the others are doing GC or something. On the small sized test, the two systems use the same amount of CPU time, but jakudo splits it across two processors and parrakudo only uses one. | 23:40 | |
23:49
BenGoldberg joined
23:54
PacoAir joined
|
|||
raiph | colomon: that is indeed interesting, thanks. | 23:56 | |
colomon: did you use the open jvm (openjdk?) or an oracle jvm? | 23:57 |