|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm 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/probe.pm 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. |
15:54 | |
| 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: Fpclassify |
16:01 | ||
| 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 | ||
| nod | |||
| 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, { Map.new((|$_, 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. web.stanford.edu/class/ee380/Abstr...eeHash.pdf | 17:25 | ||
| It's...intricate...to get right | |||
| docs.rs/crate/crossbeam/0.2.4/sour...d-skip.pdf 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: dev.azure.com/MoarVM/6b7ef196-3f6c...6/logs/300 | 18:23 | ||
| pass: dev.azure.com/MoarVM/6b7ef196-3f6c...1/logs/159 | 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 dev.azure.com/MoarVM/6b7ef196-3f6c...1/logs/212 | 18:27 | ||
| MS, you persons of dubious parentage | 18:28 | ||
| Pass: | |||
| 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 ppa.launchpad.net/ondrej/php/ubuntu xenial/main amd64 libzstd1 amd64 1.4.8+dfsg-2+ubuntu16.04.1+deb.sury.org+4 [321 kB] | |||
| 2021-05-05T07:46:32.6772066Z Get:8 ppa.launchpad.net/ondrej/php/ubuntu xenial/main amd64 libzstd-dev amd64 1.4.8+dfsg-2+ubuntu16.04.1+deb.sury.org+4 [392 kB] | |||
| Fail: | |||
| wail | |||
| 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 .../libzstd1_1.4.8+dfsg-2+ubuntu16.04.1+deb.sury.org+4_amd64.deb ... | |||
| 2021-05-05T07:46:34.8075214Z Unpacking libzstd1:amd64 (1.4.8+dfsg-2+ubuntu16.04.1+deb.sury.org+4) ... | |||
| 2021-05-05T07:46:34.8766378Z Selecting previously unselected package libzstd-dev:amd64. | |||
| 2021-05-05T07:46:34.8902448Z Preparing to unpack .../libzstd-dev_1.4.8+dfsg-2+ubuntu16.04.1+deb.sury.org+4_amd64.deb ... | |||
| 2021-05-05T07:46:34.8924825Z Unpacking libzstd-dev:amd64 (1.4.8+dfsg-2+ubuntu16.04.1+deb.sury.org+4) ... | |||
| 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 ppa.launchpad.net/ondrej/php/ubuntu xenial/main amd64 libzstd1 amd64 1.4.8+dfsg-2+ubuntu16.04.1+deb.sury.org+4 [321 kB] | |||
| 2021-05-05T07:46:32.6772066Z Get:8 ppa.launchpad.net/ondrej/php/ubuntu xenial/main amd64 libzstd-dev amd64 1.4.8+dfsg-2+ubuntu16.04.1+deb.sury.org+4 [392 kB] | |||
| In Fail: | |||
| 2021-05-07T18:10:58.9214872Z Get:3 azure.archive.ubuntu.com/ubuntu xenial/universe amd64 libzstd0 amd64 0.5.1-1 [112 kB] | 18:31 | ||
| 2021-05-07T18:10:58.9243229Z Get:4 azure.archive.ubuntu.com/ubuntu xenial/universe amd64 libzstd-dev amd64 0.5.1-1 [124 kB] | |||
| Dear MS, why did you previously get packages from ppa.launchpad.net/ondrej/php/ubuntu ? | |||
| 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 github.com/MoarVM/MoarVM/issues/1489 | 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
|
|||