|
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
|
|||