|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:39
dogbert17 left
00:59
dogbert17 joined
01:09
frost-lab joined
02:38
notable6 left,
releasable6 left,
statisfiable6 left,
sourceable6 left,
committable6 left,
greppable6 left,
nativecallable6 left,
coverable6 left,
quotable6 left,
bloatable6 left,
tellable6 left,
squashable6 left,
unicodable6 left,
bisectable6 left,
shareable6 left,
benchable6 left,
evalable6 left,
linkable6 left,
bisectable6 joined
02:39
bloatable6 joined,
shareable6 joined,
committable6 joined,
releasable6 joined,
sourceable6 joined,
quotable6 joined,
unicodable6 joined,
statisfiable6 joined,
tellable6 joined
02:40
notable6 joined,
benchable6 joined,
greppable6 joined,
nativecallable6 joined,
squashable6 joined,
coverable6 joined,
evalable6 joined
02:41
linkable6 joined
03:41
bloatable6 left,
shareable6 left,
greppable6 left,
tellable6 left,
nativecallable6 left,
coverable6 left,
committable6 left,
bisectable6 left,
benchable6 left,
unicodable6 left,
notable6 left,
squashable6 left,
releasable6 left,
evalable6 left,
quotable6 left,
statisfiable6 left,
linkable6 left,
sourceable6 left
03:42
releasable6 joined,
sourceable6 joined
03:43
nativecallable6 joined,
greppable6 joined,
benchable6 joined,
evalable6 joined,
tellable6 joined,
statisfiable6 joined,
bisectable6 joined,
notable6 joined,
linkable6 joined,
committable6 joined,
squashable6 joined
03:44
bloatable6 joined,
unicodable6 joined,
quotable6 joined,
coverable6 joined,
shareable6 joined
05:12
Kaiepi left
|
|||
| nine | Snow.....everywhere 8) | 05:55 | |
| nwc10 | not here. We had snow yetsterday. And it even sort of settled for an hour. But now it's sunny and a bit cold | 06:06 | |
| .tell masterduke as an educated guess, two lines up should be struct MVMDLLRegistry **entry | 06:10 | ||
| tellable6 | nwc10, I'll pass your message to MasterDuke | ||
| nwc10 | I wonder how well that "tell"s | 06:11 | |
|
06:31
domidumont joined
06:58
Kaiepi joined
|
|||
| samcv | lizmat, japhb, MasterDuke if we need to update unicode would you like me to do that? | 07:41 | |
| and/or checkout what you are refering to | |||
|
07:58
sena_kun joined
08:18
zakharyas joined
|
|||
| lizmat | samcv would be cool if Raku would be up to date Unicode wise, so yes, please | 08:25 | |
| nwc10 | samcv: I'd certainly like you to, because I think that you'd do a better job of it than I would. | 08:42 | |
| and I seem to be failing to get my "backlog of other things" down to zero(ish) | |||
| and several of them have somewhat time deadlines | |||
| MasterDuke | . | 08:55 | |
| tellable6 | 2021-04-07T06:10:59Z #moarvm <nwc10> masterduke as an educated guess, two lines up should be struct MVMDLLRegistry ā*ā*entry | ||
| nwc10 | OK, that's howit mangled it | 08:56 | |
| MasterDuke | doesn't seem to help though | ||
| nwc10 | pointer-to-a-pointer, not just a pointer | ||
| and then deference it "more" | |||
| but OK, then I don't know | |||
| MasterDuke | (gdb) p entry | ||
| $1 = (struct MVMDLLRegistry **) 0x55555556fc50 | |||
| (gdb) p *entry | |||
| $2 = (struct MVMDLLRegistry *) 0x0 | |||
| nwc10: btw, i believe that even at HEAD of master, enabling HASH_DEBUG_ITER causes valgrind to complain when doing `raku -e ''` | 08:59 | ||
| nwc10 | Oh OK erk. | 09:00 | |
| I fear that I'm a bit busy until at least Friday | |||
| MasterDuke | whole bunch of 'Conditional jump or move depends on uninitialised value(s)' | 09:01 | |
| no worries | |||
| btw, we also had an odd day yesterday. snow, sun, snow, sun, snow (but all the snow was just a couple flakes swirling around in high winds). but not that cold, though my parents in the states said it was ~20F | 09:02 | ||
| lizmat | about 3cm of snow overnight here, rain expected for the rest of the day, so probably it'll be gone in a few hours | 09:34 | |
| MasterDuke | i thought the problem might have been that i was doing stuff too late in the destroy process, and some of the stuff in use had already been cleaned up, but moving it to the top of MVM_vm_destroy_instance didn't help | 10:23 | |
| nine | MasterDuke: what have you got so far? | 10:26 | |
| MasterDuke | github.com/MasterDuke17/MoarVM/com...5eda03R689 | 10:27 | |
| but *entryĀ is 0x0 | 10:28 | ||
| hm, i just copied the code i have in MVM_vm_destroy_instance and stuck it at the end of MVM_dll_load (i.e., after i know something was just inserted) and it works | 10:30 | ||
| causes a segfault because it actually freed the library, but no surprise there | 10:31 | ||
| oh interesting. if i run it repeatedly only sometimes is entry non-zero, even right after something was inserted! | 10:33 | ||
|
11:13
zakharyas left
|
|||
| lizmat | .ask samcv do you recall the rationale for uniprop-int / uniprop-bool / uniprop-str ? | 11:18 | |
| tellable6 | lizmat, I'll pass your message to samcv | ||
| lizmat | .ask samcv they are not documented and not tested, and am contemplating removing them | ||
| tellable6 | lizmat, I'll pass your message to samcv | ||
|
11:47
MasterDuke left
|
|||
| jnthn wonders if any properties have both a string and integer/boolean nature | 12:41 | ||
| lizmat | not according to the current code | 12:42 | |
| uniprop either returns a Str a Bool or an Int | |||
| well, also a Rat if we're talking about unival | 12:43 | ||
| jnthn | OK | 12:48 | |
|
13:02
frost-lab left
13:05
zakharyas joined
|
|||
| dogbert17 | nine: did you have any ideas what to do with Camelia? We're still stuck with a February release. | 13:42 | |
|
15:08
domidumont left
15:12
domidumont joined
15:21
leont left
15:24
leont joined
15:34
MasterDuke joined
|
|||
| Geth | MoarVM/fix_fixkey_hash_memory_corruption: c7a063e560 | (Stefan Seifert)++ | 2 files Fix corruption of fixkey hash entries Several places in the fixkey hash implementation assumed that entries will be pointers to strings. However the hash can store arbitrary structs. So when those structs contained more than just a pointer, often they overwrote other entries. Fix by replacing all occurences of sizeof(MVMString ***) with control->entry_size |
16:59 | |
| MoarVM: niner++ created pull request #1462: Fix corruption of fixkey hash entries |
|||
| nine | MasterDuke: please try this ^^^ | 17:00 | |
| lizmat | dogbert17: still not seeing context ? | 17:09 | |
|
17:10
domidumont left
|
|||
| lizmat | the confusion rises... :-) | 17:11 | |
|
17:17
vrurg left,
MasterDuke left
17:18
vrurg joined,
vrurg left
|
|||
| lizmat | Bytecode validation error at offset 266, instruction 42: | 17:44 | |
| operand type 64 does not match register type 56 for op decont in frame pred | |||
| how's that for an interesting error in Rakudo ? | |||
| turns out something like that happens if you do nqp::unbox_s rather than a nqp::box_s | 17:53 | ||
|
17:54
zakharyas left
18:03
patrickb joined
|
|||
| samcv | lizmat, well. they are mostly just useful for testing. and i guess in that case you could use nqp. But i'm thinking at least somebody may be using it, mostly to work around bugs in .uniprop | 18:03 | |
| tellable6 | 2021-04-07T11:18:30Z #moarvm <lizmat> samcv do you recall the rationale for uniprop-int / uniprop-bool / uniprop-str ? | ||
| 2021-04-07T11:18:51Z #moarvm <lizmat> samcv they are not documented and not tested, and am contemplating removing them | |||
| lizmat | samcv: are those bugs in the HLL part or in the MoarVM part ? | 18:04 | |
| samcv | well. could in the int/bool/str switch in rakudo. Or it could be in the MoarVM part I guess. From what I remember. But that's not really a good reason for them existing | 18:05 | |
| lizmat, ah. see this github.com/Raku/roast/blob/master/...rop.t#L280 | 18:08 | ||
| this one has strings and int values that (should) be returned. | |||
| lizmat | aaahh... ok, so that uniprop should actually return those as an IntStr ? | 18:09 | |
| patrickb | o/ | 18:13 | |
| samcv | yeah i think that is probably right lizmat | 18:14 | |
| lizmat | ok, lemme see if I can fix that | ||
| samcv | well. I think moarvm would need to have both integers and strings stored. like Canonical_Combining_Class=Above_Right is number 232. And I don't think moarvm has that. But i'm a bit rusty | 18:15 | |
| lizmat | ah, so the problem is deeper than Rakudo ? | ||
| then I won't be able to fix it :-) | 18:16 | ||
| I could do the Rakudo part, using the right nqp ops and trying to create the IntStr | |||
|
18:38
MasterDuke joined
|
|||
| MasterDuke | nine: huh. rebased on top of your branch. now the behavior is (at least more) consistent, but the entry from the iterator (immediately after it was inserted into the hash) is not correct | 18:50 | |
| nine | At least --full-cleanup doesn't crash anymore for me | 18:54 | |
| MasterDuke | gist.github.com/MasterDuke17/32832...fcd446a29d current diff | 18:56 | |
| btw, fixkey_hash has a bunch ofĀ stuff like `MVMString ***indirection` or `MVMString **entry = MVM_fixkey_hash_fetch_nocheck(tc, hashtable, key);`. should those MVMStrings really be MVMObjects? | 19:00 | ||
|
19:02
vrurg joined
|
|||
| nine | MasterDuke: this works: gist.github.com/niner/93eda8852910...6d18c59164 | 19:05 | |
| So...basically I just reverted the changes you made when trying to figure out why it breaks :) | |||
| MasterDuke | ha | 19:07 | |
| nine | I think there should be an MVMFixKeyHashHandle for those akin to MVMStrHashHandle | ||
| MasterDuke | i think i actually created one at first, but then didn't end up using it, because the strhash iterator functions didn't use it | 19:10 | |
| and my implementation was literally copying those and then `s/StrHash/FixKeyHash/g; s/str_hash/fixkey_hash/g` | 19:11 | ||
| nine | I was half way through changing the code to use MVMFixKeyHashHandle instead of MVMString*** before realizing that that wasn't actually a thing :) | ||
| MasterDuke | just changed to use your patch, but my 'for realz' still isn't getting printed... | 19:13 | |
| ah, entry->lib is 0x0 | 19:14 | ||
| blob_asciii of the hash_key is "PLXUUU"" | 19:15 | ||
| nine | huh | ||
| MasterDuke | there's still only one entry in the hash | ||
| nine | which is what's expected, isn't it? | 19:16 | |
| MasterDuke | yep | ||
| but it's become corrupted | |||
| the name/hash_key should be 'dynext/libperl6_ops_moar.so' | 19:19 | ||
| oh, right. is it in fact safe to do this after all the other stuff before it in MVM_vm_destroy_instance? i.e., `/* Run the GC global destruction phase. After this, no 6model object pointers should be accessed. */` sounds ominous | 19:21 | ||
|
19:22
rypervenche left
|
|||
| nine | Ah, because of the MVMStrings | 19:22 | |
| That's true. So an appropriate place for the code would be before that GC run but after threads are shut down | |||
| MasterDuke | a new failure mode! `MoarVM panic: Internal error: zeroed target thread ID in work pass` | 19:24 | |
| heh. moved it after `/* Run the normal GC one more time to actually collect the spesh thread */` and now `blob_ascii = 0x5555555cc878 "\b"` | 19:26 | ||
| same even when moved up to the top of MVM_vm_destroy_instance again | 19:28 | ||
|
19:29
rypervenche joined
19:31
vrurg left
|
|||
| Geth | MoarVM: 41f420ede0 | (Daniel Green)++ | 6 files Cleanup of a bunch of Unicode hashes Move static variables to be members of MVMInstance instead. This is safer if there are multiple MoarVMs running in the same process. Instead of needing to coordinate initializing/destroying these global variables, each instance can be responsible for its own hashes. ... (7 more lines) |
19:35 | |
| MoarVM: 598b79e23b | MasterDuke17++ (committed using GitHub Web editor) | 6 files Merge pull request #1461 from MasterDuke17/move_static_unicode_hashes_to_MVMInstance Cleanup of a bunch of Unicode hashes |
|||
|
20:03
patrickb left
20:06
zakharyas joined
20:16
vrurg joined
20:25
vrurg left
20:47
vrurg joined,
MasterDuke left,
MasterDuke joined
20:51
vrurg left
20:52
vrurg joined
20:57
vrurg left
21:03
zakharyas left
23:23
sxmx left
23:43
sxmx joined
|
|||