| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:02 reportable6 left 00:03 reportable6 joined 01:03 committable6 left, squashable6 left, statisfiable6 left, releasable6 left, linkable6 left, benchable6 left, tellable6 left, bloatable6 left, notable6 left, quotable6 left, coverable6 left, bisectable6 left, evalable6 left, sourceable6 left, greppable6 left, shareable6 left, reportable6 left, unicodable6 left, nativecallable6 left, squashable6 joined 01:04 tellable6 joined, statisfiable6 joined, sourceable6 joined, coverable6 joined, nativecallable6 joined, bloatable6 joined, unicodable6 joined, notable6 joined 01:05 bisectable6 joined, greppable6 joined, linkable6 joined, releasable6 joined, evalable6 joined, shareable6 joined 01:06 committable6 joined, reportable6 joined, benchable6 joined, quotable6 joined
tbrowder .tell [Coke] i added the 3rd party warnings to the issue 01:30
tellable6 tbrowder, I'll pass your message to [Coke]
01:37 frost-lab joined 01:48 frost-lab left 02:03 frost-lab joined
[Coke] . 03:15
tellable6 2021-05-07T01:30:50Z #moarvm <tbrowder> [Coke] i added the 3rd party warnings to the issue
03:32 evalable6 left, linkable6 left 03:33 linkable6 joined 03:35 evalable6 joined 06:02 reportable6 left 06:04 reportable6 joined 06:23 domidumont joined 07:22 patrickb joined 07:37 geth_ joined 07:41 Geth left 08:22 sena_kun left
nwc10 good *, #moarvm 08:23
08:24 sena_kun joined 08:29 zakharyas joined
jnthn o/ 08:36
nwc10 \o 08:37
09:08 domidumont left 09:17 Altai-man_ joined 09:18 sena_kun left 11:20 zakharyas left 11:38 frost-lab left 11:40 frost-lab joined 12:02 reportable6 left 12:03 reportable6 joined
lizmat m: my str @a; say @a[0] # wonder whether this should be fixed at the MoarVM level, or at nqp::atpos_s level, or at Rakudo level 12:21
camelia concatenate requires a concrete string, but got null
in block <unit> at <tmp> line 1
lizmat m: my str @a; my $b := @a[0]; $b = "foo"; dd @a # apparently even though it's a null_s, it can be bound to ? 12:23
camelia array[str].new("foo")
lizmat hmmm... could be Rakudo doing that I gues 12:24
12:37 frost-lab left
jnthn You're binding a native ref 12:44
An interesting creature that we mostly pretend don't exist, but if they didn't then @native-int-array[$i]++ wouldn't work :) 12:45
lizmat but do you agree that at least the error message is LTA ? 12:47
jnthn Perhaps it should default the the empty str, not a null_s 12:49
Probbly the nulls shouldn't leak out
lizmat but at which level ?
if we do want to be able to spot "holes" in native string arrays 12:50
m: my str @a; say @a[0]:exists
camelia False
lizmat I guess we need the nqp::null_s
m: my int @a; say @a[0]:exists
camelia False
lizmat m: my int @a; @a[4] = 42; say @a[0]:exists
camelia True
lizmat meh 12:51
m: my str @a; @a[4] = "foo"; say @a[0]:exists
camelia True
lizmat also meh
so I guess we just check nqp::elems for the exists check on native arrays
which to me means that nqp::atpos_s on a slot with null_s should return "" 12:52
jnthn No, native arrays don't need to support :exists 12:54
lizmat you mean: not depend on "hole" checking, right? 12:55
jnthn Yes 12:56
Native array elements always exist, if they're within the size of the array 12:57
lizmat ok, in that case, I guess MoarVM needs a fix to have nqp::atpos_s return an empty string if there is a nqp::null_s
do you agree ? 12:58
jnthn It could equally well be done in the AT-POS implementation in Rakudo? 13:00
I don't really have a strong feeling either way. Keeping ops a bit simpler makes JITting a bit easier. 13:01
lizmat ok, will do it at the AT-POS implementation (for now) :-) 13:02
jnthn otoh, doing it in the VM means it could choose to memset-ish all the elements to the empty string up front and avoid the branch 13:03
lizmat there's that :)
jnthn otth, that means for a large str array we romp through memory at allocation time to handle the rare case of read-before-write
lizmat couldn't such an array be memcp'd from a constant array with X elements ? 13:04
supposing you'd have an array of 1K elems with empty strings sitting somewhere, from which you could memcp to se up new ones? 13:05
jnthn That'd probably come out worse than memset[32|64]
Because then it's having to get the source array into memory as well 13:06
lizmat but then you would have to loop or not?
I guess I have a bad understanding of the memory layout of str arrays
jnthn Both memcmp and the memset family are looping, though they're generally very good at it (e.g. using vector registers)
lizmat I would think a str array as an array of pointers ? 13:07
jnthn Yes 13:10
Pointers to MVMString
heh, s/memcmp/memcpy/ above. Fridays...
13:19 domidumont joined
lizmat so you could create an array with 1K pointers to an empty MVMString ? 13:21
and then memcpy off of that ?
afk for a few hours&
jnthn You could, I'm just saying that it's less efficient to do that than to take the pointer to the empty string and have it written into all of the elements 13:22
Because then the pointer to the empty string is just sat in a register, not being fetched repeatedly
15:06 cog_ left 15:07 cog joined 15:24 zakharyas joined
geth_ MoarVM/fpclassify: 190ba6c0b1 | (Nicholas Clark)++ | build/
Refactor the maths function probe logic to extract the common setup code.

The tests for pow(), log() and trig functions had a lot of copy-paste-edit in the code that tried to create values in a way that defeated compile time constant folding. That is now all in one place.
MoarVM/fpclassify: 285ac37efb | (Nicholas Clark)++ | 4 files
Implement `MVM_num_isnanorinf` using `isinf` and `isnan` if we find them.

These are part of C99, and result in much tighter machine code - it seems that compiler optimisers can't map the logic of our fallback floating point implementation into the semantically equivalent checks on exponent and mantissa.
MoarVM: nwc10++ created pull request #1488:
jnthn Hm, Windows build goes boom 16:18
nwc10 it was windows? 16:19
jnthn oh no, one of them was maybe
nwc10 I was still trying to figure out the cause of the SEGVs
but then my window manager decided to be sluggish
anyway, it is a strange SEGV
OK, one is a SEGV in NQP 16:20
one is a SEGV in building Rakudo
and "not know"
but ASAN was just fine
oh my, one is a spew of compiler errors in MoarVM 16:21
2021-05-07T16:11:26.0297008Z src/profiler/heapsnapshot.c: In function ‘serialize_attribute_stream’: 16:22
2021-05-07T16:11:26.0298996Z src/profiler/heapsnapshot.c:882:5: error: unknown type name ‘ZSTD_CStream’
2021-05-07T16:11:26.0299491Z ZSTD_CStream *cstream;
2021-05-07T16:11:26.0299811Z ^
2021-05-07T16:11:26.0305351Z src/profiler/heapsnapshot.c:884:22: warning: implicit declaration of function ‘ZSTD_CStreamOutSize’ [-Wimplicit-function-declaration]
*I* think that Azure had a bit too much to drink for lunch
jnthn There's a lot of changes to the probes in that PR that don't seem immediately related to the nanorinf thing? 16:23
nwc10 I'm going to wait a few hours then hit re-run
first commit is a DRY de-dup
jnthn ah, right 16:24
nwc10 to avoid a 4th copy of the same setup
jnthn Still maybe worth pushing that probe change as a separate PR just in case 16:25
nwc10 I thought I'd hit "re-run" first, and if that doesn't "fix" it then I'll split it. At least, that was my first plan 16:26
jnthn Though I still struggle to see how we end up in segv land
nwc10 I struggle to see how we end up with zstd compile failures
jnthn Yeah, it's weird
nwc10 I think that MS goofed something (hopefully temporarily)
[Coke] fires up his windows aws workspace to retry the windows build now that he's thinking of it 16:27
/win 3 16:28
nwc10 oh, where did the /win lottery go?
[Coke] notes that "/win 3" does not somehow start his AWS windows box 16:33
16:35 domidumont left
lizmat so I have multiple threads wanting access to the same hash 16:59
and one of more threads making changes to that hash
changing is serialized with a lock
but I would like to be able to not have to use a lock to access the hash
would an nqp::clone() of the underlying nqp::hash provide safe (albeit maybe incomplete) thread safe access ? 17:00
I guess this question directed at nwc10 / jnthn / samcv
jnthn Yes, but I'd not break the encapsulation of Hash, I'd just use Map 17:08
And construct a new/changed one 17:09
lizmat basically nqp::p6bindattrinvres(nqp::create(Map),Map,q/$!storage/,nqp::clone(...) 17:10
jnthn You can even do away with the write lock in favor of `cas $cur-version, {|$_, new-key => 'new-value')) }` or so
lizmat that feels like a lot of work for bigger hashes ?
I'm talking all nicks on all Raku channels since 2005 :-) 17:11
jnthn That's still not huge? :) 17:12
lizmat well.. I guess :-)
jnthn The ideal here would be to have a Concurrent::Hash module 17:13
Unfortunately, I'm well aware of how hard those are to get right :)
lizmat well... perhaps it's easier to do with Array::Sorted::Util
on which e.g. Hash::Sorted is based 17:14
basically use a native str array and an associated array
but yeah...
it's hard to get a generally useful solution to that 17:15
that isn't basically open to very simple deadlocking issues, right?
jnthn To what exactly? A concurrent lock-free hash data structure? 17:24
It's been done. 17:25
It' get right looks more concrete 17:27
lizmat hmmm. the latter one says "blocked plugin" to me 17:28
jnthn Odd
Time to wander afk. Dinners don't make 'emselves... 17:29
18:02 reportable6 left 18:04 reportable6 joined
[Coke] oh, hey, much easier to compile rakudo when you have a C or C++ compiler installed 18:14
nwc10 OK, so 18:20
ztsd 0.5.1 doesn't have ZSTD_CStream
Ubuntu 16.04 has that version
all the compiler errors are about that missing
so, OK, why has Azure's Ubuntu now decided that it can give us zstd (which is too old for us) when previously it did not 18:21
today. not two days ago
fail: 18:23
pass: 18:24
pass, because it did not start with that apt stuff for package updates
so, sigh, we need a probe for zstd
WTF, but my passing testcase was rebased onto master that contained the commit to azure-pipelines.yml 18:26
aha, no, *this* is the full pass log 18:27
MS, you persons of dubious parentage 18:28
2021-05-05T07:46:23.4688116Z Ubuntu
2021-05-05T07:46:23.4688283Z 16.04.7
2021-05-05T07:46:23.4688454Z LTS
2021-05-05T07:46:32.6041408Z Get:7 xenial/main amd64 libzstd1 amd64 [321 kB]
2021-05-05T07:46:32.6772066Z Get:8 xenial/main amd64 libzstd-dev amd64 [392 kB]
more PAss: 18:29
2021-05-05T07:46:34.7884770Z Selecting previously unselected package libzstd1:amd64.
2021-05-05T07:46:34.8048740Z Preparing to unpack .../ ...
2021-05-05T07:46:34.8075214Z Unpacking libzstd1:amd64 ( ...
2021-05-05T07:46:34.8766378Z Selecting previously unselected package libzstd-dev:amd64.
2021-05-05T07:46:34.8902448Z Preparing to unpack .../ ...
2021-05-05T07:46:34.8924825Z Unpacking libzstd-dev:amd64 ( ...
2021-05-05T07:46:34.9699536Z Selecting previously unselected package libc6-dbg:amd64.
whereas in Fail:
2021-05-07T18:11:03.3281354Z Setting up libzstd0 (0.5.1-1) ...
2021-05-07T18:11:03.3341003Z Setting up libzstd-dev (0.5.1-1) ...
In Pass: 18:30
2021-05-05T07:46:32.6041408Z Get:7 xenial/main amd64 libzstd1 amd64 [321 kB]
2021-05-05T07:46:32.6772066Z Get:8 xenial/main amd64 libzstd-dev amd64 [392 kB]
In Fail:
2021-05-07T18:10:58.9214872Z Get:3 xenial/universe amd64 libzstd0 amd64 0.5.1-1 [112 kB] 18:31
2021-05-07T18:10:58.9243229Z Get:4 xenial/universe amd64 libzstd-dev amd64 0.5.1-1 [124 kB]
Dear MS, why did you previously get packages from ?
To be clear, MS have fixed their shit 18:32
(and exposed our own bug)
18:32 kawaii left 18:34 zakharyas left 18:35 kawaii joined
[Coke] feels like the windows *build* is pretty zippy on this machine, running anything seems... slow. 18:37
19:22 MasterDuke joined
geth_ ¦ MoarVM: nwc10 self-assigned MVM_Ub_16_gcc and MVM_Ub_16_clang builds now broken due to Azure fixing their Ubuntu package setup 19:41
nwc10 much easier to read than IRC
19:59 zakharyas joined 20:08 MasterDuke left 20:16 vrurg_ joined 20:18 vrurg__ joined 20:19 vrurg left 20:21 vrurg_ left 20:25 vrurg__ left 21:42 zakharyas left 21:45 Geth joined 21:49 geth_ left 22:37 patrickb left 23:19 Kaiepi left 23:20 Kaiepi joined