Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:03 reportable6 left 00:05 reportable6 joined 04:35 samcv_ joined 04:36 harrow` joined 04:37 quotable6 left, linkable6 left, notable6 left, committable6 left, shareable6 left, benchable6 left, releasable6 left, reportable6 left, unicodable6 left, bartolin left, samcv left, harrow left, squashable6 left, MasterDuke left, squashable6 joined 04:38 bartolin joined 04:39 benchable6 joined 04:40 reportable6 joined, quotable6 joined 04:41 shareable6 joined, releasable6 joined, notable6 joined 04:42 committable6 joined, linkable6 joined, unicodable6 joined 05:22 squashable6 left 05:23 frost joined 05:25 squashable6 joined 06:02 reportable6 left 06:05 reportable6 joined 06:36 Kaiepi left, japhb left, LizBot left, moon-child left, cognominal left, leont left, JRaspass left 06:37 Kaiepi joined, japhb joined, LizBot joined, moon-child joined, cognominal joined, leont joined, JRaspass joined
nine That bit about sorted_keys makes me wonder if there's another way to get reproducible builds (which are important because precomp management relies on SHA hashes of file contents) 09:24
We don't require that hash entries are sorted. We only require that they are written in the same order every time. Currently they are not due to hash randomization.
So what if we simply disable hash randomization for precompilation instead?
That would fix the reproducibility issue for compilation of the setting as well as precompiled modules. 09:26
japhb nine: Do they get randomized when read back in and thawed? 09:34
(Otherwise I worry that we bake in well-known orderings that attackers can count on) 09:35
nine japhb: yes, we create a completely new hash which would get a random salt and then just bind all the keys 09:38
japhb Ah, well that handles that worry at least. 09:49
11:43 committable6 left, nativecallable6 left, benchable6 left, releasable6 left, unicodable6 left, coverable6 left, evalable6 left, greppable6 left, sourceable6 left, notable6 left, linkable6 left, reportable6 left, bloatable6 left, statisfiable6 left, tellable6 left, bisectable6 left, quotable6 left, shareable6 left, squashable6 left 11:44 linkable6 joined, shareable6 joined, releasable6 joined, squashable6 joined, sourceable6 joined 11:45 bisectable6 joined, benchable6 joined, nativecallable6 joined, reportable6 joined, bloatable6 joined, notable6 joined, greppable6 joined, evalable6 joined, quotable6 joined 11:46 tellable6 joined, unicodable6 joined, coverable6 joined, committable6 joined 11:47 statisfiable6 joined 12:02 reportable6 left 12:06 reportable6 joined 13:40 MasterDuke joined
MasterDuke nine: i thought disabling hash randomization required moarvm source changes? do you propose making that configurable at a higher level? or just seeding the rng with a constant value during precomp? 13:46
13:50 squashable6 left 13:51 squashable6 joined
timo now why would ack give a result from a .o file? 14:09
nine MasterDuke: it does. But maybe we can make that configurable. Maybe even on a per-hash basis. 14:12
Geth MoarVM/turn_off_hash_rando_while_precompiling: 6ce862e04d | (Timo Paulssen)++ | 2 files
let's try moving hashSecrets out of the way while precompiling
14:17
timo who wants to try it?
nine:? :)
of course it won't do much if we don't remove all the sorting that has been added to make precomp deterministic 14:20
though will this work when a hash has already been created?
is it enough if this only impacts hashes that have been created since we've entered compilation? what about hashes we've created before entering compilation, but that will enter into the precomp directly or indirectly 14:22
do we enter precomp mode before doing parsing for example? i guess we have to since some things already run during parse time 14:23
welp.
haha that patch immediately crashes when trying to go through nqp compilation 14:24
MasterDuke whoops 14:26
timo: btw, are you going to create appimages for the most recent releases?
also, while moarperf is much faster at loading large profiles than the html version, if the allocations are large it doesn't ever seem to load that tab 14:27
i.e., i have to tell chrome/firefox to not cancel the script a couple times, but they do *eventually* show the allocations tab of a normal profile (of this nativecall example we've been playing with), but moarperf just sits and says loading, but never does 14:29
timo oh dang 14:30
does moarperf finish doing its thing before the browser's problem starts/happens? 14:31
i guess i'll want to put some pagination in if there's a boatload of different types
i'll be AFK again but then i'll have a few looks 14:32
MasterDuke no, the browser problems are only with the normal html profile 14:45
timo oh i misread it literally doesn't give the results from backend to frontend or something else is going wrong 15:24
can you send me the sqlite3 file? or maybe i should ask first: how big is it? :D 15:28
and what are all of these types anyway; versions of Callable that have lots and lots of different signatures mixed in and return types and such?
github.com/timo/rakudo-appimage/re...ag/2021.05 MasterDuke, wanna give it a try? 15:52
MasterDuke lots of nativecall types 15:53
timo like different cstructs and such?
MasterDuke sqlite3 is only 7.2mb
timo i'll take it 15:55
MasterDuke appimage works, thanks
what's that file transfer service? 15:56
timo i'd say just plop it onto u.setxkbmap.de
MasterDuke blob:u.setxkbmap.de/0bf0f470-7e1b-418e-...360db12134 15:57
it's a --profile-compile of this u.setxkbmap.de/#85ky0cbWL3Ac9R7PUWd6Pg 15:58
probably afk for a bit 15:59
timo that link isn.t going to cut it :D 16:03
the blob: one 16:04
MasterDuke u.setxkbmap.de/#8zZQH9WNDqYA53Xp-H_Weg 16:05
timo thank you 16:08
now i get to eat
i think i should probably delete that dumb branch before someone tries it out :D 16:53
17:26 RakuIRCLogger left, LizBot left, lizmat_ joined 17:27 LizBot joined, RakuIRCLogger joined 17:28 lizmat left 17:29 lizmat_ is now known as lizmar, lizmar is now known as lizmat, lizmat left, lizmat joined 18:02 reportable6 left 18:05 reportable6 joined
MasterDuke well, now we know what not to do... 18:39
timo one down, fifty bajillion to go 18:55
19:56 dogbert11 joined 19:59 dogbert17 left 21:22 njm joined 21:24 njm left