brrt ryu as source code repo: github.com/ulfjack/ryu 07:53
MasterDuke++, nice rabbit hole to fall into 07:54
AlexDaniel github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
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
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
brrt \o 20:50
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
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
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
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
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 :)
geekosaur same 22:41
or rhetorical, since prose