|
00:00
lizmat joined
00:04
lizmat left
05:31
domidumont joined
05:38
domidumont left
05:39
domidumont joined
06:31
domidumont left
06:56
robertle joined
07:10
lizmat joined
07:13
ggoebel left
07:26
ggoebel joined
07:48
domidumont joined
07:53
brrt joined
|
|||
| brrt | ryu as source code repo: github.com/ulfjack/ryu | 07:53 | |
| MasterDuke++, nice rabbit hole to fall into | 07:54 | ||
|
08:16
robertle left
08:37
scovit left
09:13
lizmat left
09:14
lizmat joined
09:42
brrt left
09:53
zakharyas joined
09:54
robertle joined
11:44
brrt joined
11:47
zakharyas left
12:03
brrt left
12:21
zakharyas joined
13:18
lizmat left
13:27
zakharyas left,
zakharyas joined
13:28
brrt joined,
brrt left
13:55
lizmat joined
14:16
AlexDaniel left,
AlexDaniel joined
14:17
zakharyas left
14:22
ChanServ sets mode: +o AlexDaniel
|
|||
| AlexDaniel | github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm | ||
|
ChanServ sets mode: -o AlexDaniel
14:29
scovit joined
|
|||
| scovit | m: my $a; $a = $a // 0; say $a | 14:35 | |
| yoleaux | 2 Jun 2018 11:41Z <MasterDuke> scovit: a way to customize the error message from where constraints: class A { method c {} }; class B { method d {} }; my $e = A.new(); my $f = B.new(); sub ciao($g where so $g.^can("c") || die "Can't do c") {}; ciao($f);' | ||
| camelia | 0 | ||
| scovit | m: $ = $ // 0; say $ | ||
| camelia | (Any) | ||
| scovit | Do you know why? | 14:36 | |
| jnthn | m: for ^5 { say $++ ~ ' and ' ~ $++ } | 14:38 | |
| camelia | 0 and 0 1 and 1 2 and 2 3 and 3 4 and 4 |
||
| jnthn | Each anonymous variable is distinct | ||
| So you're talking about 3 different anonymous variablese | |||
| *variables | |||
| scovit | Ah thanks, I didn't get this. I thought that for convenience a $ was defined in each scope.. Instead $ is something different | 14:41 | |
| lizmat | .oO( we're all $ ) |
14:42 | |
| scovit | :) it is also a good obfuscated way to define state variables | 14:44 | |
| m: sub foo() { my $a := $; $a++; say $a; }; foo(); foo(); | |||
| camelia | 1 2 |
||
|
14:55
geekosaur left
15:08
geekosaur joined
15:25
ggoebel left
15:40
ggoebel joined
15:48
domidumont left
16:08
AlexDaniel`` left,
wictory[m] left,
ilmari[m] left
16:11
evalable6 left,
camelia left,
greppable6 joined,
evalable6 joined
16:14
MasterDuke left
16:15
camelia joined
16:23
robertle left
16:37
wictory[m] joined
16:44
domidumont joined
16:51
domidumont left
17:08
shareable6 joined
17:09
undersightable6 joined
17:18
AlexDaniel`` joined,
ilmari[m] joined
17:46
AlexDani` joined,
AlexDaniel left
17:50
lizmat left
17:52
AlexDani` is now known as AlexDaniel
|
|||
| Geth | MoarVM: 213f32324a | (Jeremy Studer)++ | 3 files Change getsignals output from hash to array Changed the output of getsignals from a hash to an array with signal names interleaved with signal values. The purpose of this is to allow for a more consistent ordering of signals when exposed to the HLL. |
18:51 | |
| MoarVM: 943980b3de | (Jeremy Studer)++ | 2 files JIT compile getsignals Although this probably isn't likely to be part of any hot code path, adding JIT support for the getsignals op. |
|||
| MoarVM: 6302ca74ee | (Aleks-Daniel Jakimenko-Aleksejev)++ (committed using GitHub Web editor) | 5 files Merge pull request #870 from jstuder-gh/sig_hash_to_arr Change getsignals output from hash to array |
|||
|
19:00
japhb joined
19:08
Ven`` joined
19:10
Ven`` left,
Ven`` joined
19:11
Ven`` left,
Ven`` joined
19:13
Ven`` left
19:14
Ven`` joined
19:16
Ven`` left,
Ven`` joined
19:18
Ven`` left
19:19
Ven`` joined
19:26
Ven`` left
19:27
Ven`` joined
19:31
Ven`` left
19:32
Ven`` joined
19:33
Ven` joined
19:36
Ven`` left
19:37
lizmat joined
19:38
Ven` left
19:40
Ven`` joined
19:41
Ven`` left
19:50
zakharyas joined
19:56
japhb left
20:37
zakharyas left
20:48
brrt joined
20:49
AlexDaniel`` left,
wictory[m] left,
ilmari[m] left
|
|||
| brrt | \o | 20:50 | |
|
20:51
reportable6 left
20:52
japhb joined,
coverable6 joined,
quotable6 joined,
reportable6 joined,
shareable6 left
|
|||
| lizmat | brrt: o/ | 20:59 | |
| perlmonks.org/?node_id=1216491 # segfaulting Perl 6 | |||
| brrt | :'-( | 21:02 | |
| i'll see what i can do | |||
| lizmat | well, it's basically the known issue that adding keys to a hash is not threadsafe | ||
| and racy | |||
| brrt | hmmmmmm | 21:04 | |
| i'm not fully convinced we want to pay the price of a concurrent hashmap for all cases | |||
| lizmat | well, it's bad that it segfaults / crashes | 21:05 | |
| being able to trivially do that, is sorta bad PR | |||
| brrt | yeah, i understand | ||
| lizmat | but I think jnthn had ideas about that for the future | ||
| I *think* it only happens when two threads attempt to add a key at the same time | 21:06 | ||
| brrt | there's things you can do to make it never crash (but still racy and quite possibly memory-leaking) | ||
| lizmat | I think I can live with leaking and racy, and not crashy :-) | 21:08 | |
| jnthn | Well, exception crashy is acceptable, segv not | 21:10 | |
|
21:10
wictory[m] joined
|
|||
| lizmat | ok, exception would be fine by me as well :-) | 21:11 | |
| jnthn | Well, you won't be getting a reliable exception, data loss will be equally likely. :) | ||
| (Basically, I figure we can detect concurrent resize attempts) | |||
| brrt | the thing is that I don't know how to make that exception crashy *without* some form of atomic-cas or locking | ||
| lizmat | well, as long as something can be caught | ||
| brrt | jnthn: having not looked at uthash at all, are concurrent resize attempts our biggest problem? | 21:12 | |
| i imagine that if uthash is linked there can be some dragons there | |||
| jnthn | brrt: The scheme I was figuring on is that we allocate a blob of memory, make sure to never leave its bounds, and then 1) free it using the FSA on resize/growth, and 2) throw if we see the pointer change (which you could do as an atomic op) | 21:13 | |
| brrt | also, maybe (probably?) the VM should expose a concurrent hash map | ||
| jnthn | No, we're not putting more data structures in at VM level. | ||
| Hashes are really darn useful as a VM/HLL interface so I'll live with that :) | 21:14 | ||
| And arrays you kinda have to | |||
| As for uthash - yes, it's a linked thing, which is why it can't really stay in the long run :) | |||
| Also it's not really memory efficient | 21:15 | ||
| brrt | I've been thinking of a hash table design that enables us to do links + big-blob allocations | ||
| as in, preallocated slots with links (and a tiny table) | 21:16 | ||
| jnthn | Yeah, there's plenty we can do :) | 21:17 | |
|
21:20
robertle joined
|
|||
| lizmat | perlmonks.org/?node_id=1216507 # my reply | 21:58 | |
| brrt | hmm. I kind of wish you *hadn't* written the first bit though :-) | 22:07 | |
| because that idiom does not at all dwym | 22:08 | ||
| lizmat | indeed, but that was the point :-) | 22:09 | |
| it runs to completion and *still* gives the wrong answer :-) | |||
| what jnthn was saying in his blog post: 6guts.wordpress.com/2014/04/17/rac...ess-leads/ | |||
| over 4 years ago already | |||
| afk& | 22:10 | ||
|
22:12
MasterDuke joined
|
|||
| jnthn | I like how I put the words in the post title in an somewhat broken word order as a kind of meta-pun :P | 22:27 | |
|
22:28
robertle left
|
|||
| timotimo | i didn't know that was considered wrong | 22:33 | |
| jnthn | It's not wrong so much as awkwarder :) | 22:34 | |
| timotimo | i'd have called it "poetic" | 22:37 | |
| jnthn | :) | ||
|
22:40
brrt left
|
|||
| geekosaur | same | 22:41 | |
| or rhetorical, since prose | |||
|
22:47
lizmat left
22:50
yoleaux joined
22:53
lizmat joined
23:16
wictory[m] left
23:37
wictory[m] joined
23:41
Kaiepi left
|
|||