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.
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
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
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
MasterDuke well, now we know what not to do... 18:39
timo one down, fifty bajillion to go 18:55

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!