github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:00 patrickb left 04:41 unicodable6 left 04:42 quotable6 left, bloatable6 left, shareable6 left
05:24 greppable6 left, nativecallable6 left, statisfiable6 left, bisectable6 left, notable6 left 05:25 bisectable6 joined, notable6 joined, statisfiable6 joined, greppable6 joined, nativecallable6 joined 05:26 sena_kun joined 05:38 unicodable6 joined 05:39 bloatable6 joined, shareable6 joined 05:40 quotable6 joined 06:30 sena_kun1 joined 06:39 sena_kun1 left 07:31 patrickb joined 08:02 domidumont left
|Geth||MoarVM: 3c3a24bff6 | (Nicholas Clark)++ | 2 files
Fix two *printf size warnings reported on ILP32 platforms.
In debugserver.c, handle_id is 64 bit, so use PRId64.
In the profiler, we print out the difference between two pointers. This has the type ptrdiff_t. It seems that on most platforms that ptrdiff_t is a typedef for long. However, on (at least) arm32 and sparc32 it is a typedef ... (6 more lines)
|sena_kun||Hey. Any obvious release blockers from moarvm side?||09:08|
09:21 Altai-man joined 09:23 sena_kun left
|nine||The parametric interning issue. I think my commit has not yet been reverted||09:24|
|Altai-man||nine, thanks. It has not been yet, I am now doing a simple run to see an updated picture of what happened when I was absent.||09:26|
09:45 domidumont joined 09:48 domidumont left
|Geth||MoarVM: 1db1cd1488 | Altai-man++ | src/6model/serialization.c
Revert "Fix interning of parametric types in precompilation"
This reverts commit b6d064a698c50842086f15aedd1aacc279086ba3. This commit caused some ecosystem modules (Uzu, MagickWand) fail compilation with "Object does not exist in serialization context", so revert to original code until there is a better fix.
|Altai-man just broke master. :(|
|Geth||MoarVM: f99bc2ce76 | Altai-man++ | src/6model/serialization.c
Revert "Fix memory leak in resolve_param_interns"
This reverts commit 8c41f6692e844f34e7a8322b5462bbef6b07202d.
|Altai-man||There was a next commit fixing a leak which was not reverted. :||
|nine||ah, well, if it's just that|
|Altai-man||There is still a regression in another module caused by one of vrurg++ commits, so not sure if we are making a release. At least prepare most of it, I guess.||10:46|
|nine||With a little luck we'll have working interning of parametrics in 2020.11|
|Altai-man||Let's hope for the best without burning anyone. \o/||10:47|
10:50 Geth left, Geth joined 10:51 travis-ci joined
|travis-ci||MoarVM build failed. Altai-man 'Revert "Fix interning of parametric types in precompilation"||10:51|
10:51 travis-ci left
|Kaiepi||timotimo, are you on?||12:19|
|.tell timotimo, can you get back to me when you get the chance? nothing too serious||12:26|
|tellable6||Kaiepi, I'll pass your message to timotimo|
12:35 patrickb left 13:22 sena_kun joined 13:23 Altai-man left 14:15 codesections left 14:55 patrickb joined
|timotimo||hey Kaiepi i'm here||16:27|
|tellable6||2020-10-24T12:26:03Z #moarvm <Kaiepi> timotimo, can you get back to me when you get the chance? nothing too serious|
|from time to time, i get compiler warnings that others don't seem to when building moarvm with my setup. a common theme with them is to do with how printf formatting is handled with integers in your code||16:34|
|this snprintf call is one github.com/MoarVM/MoarVM/blob/mast...ot.c#L1734|
|formatting a MVMuint64 like col->start_time on my system requires %llu on my system. inttypes.h comes with some macros for formatting things like 64 bit unsigned integers in a portable way||16:36|
|s/on my system\.//|
|timotimo||it's true, and shameful, that i'm not being dilligent enough using the right formatting codes for my printfs||16:38|
|Geth||MoarVM/big-endian-deserialisation: a37cd76332 | (Nicholas Clark)++ | src/6model/serialization.c
The inline `memcpy` replacement can be used on all little-endian platforms.
The `memcpy` in `MVM_serialization_read_int` was to avoid unaligned access to a MVMint64 value. The replacement code that unwraps and inlines it only does byte access to memory, so it's quite safe to *also* use this on platforms that can't do unaligned 64-bit reads.
(If the compiler on platforms that can read unaligned spots that it can
optimise our byte accesses to larger reads, that's just fine, because it doesn't affect the platforms where this is fatal.)
|MoarVM/big-endian-deserialisation: cbb92b038b | (Nicholas Clark)++ | src/6model/serialization.c
The inline `memcpy` replacement can be adapted for big-endian platforms.
The `memcpy` in `MVM_serialization_read_int` was to avoid unaligned access to a MVMint64 value. The that unwraps and inlines for little-endian platforms can also be adapted for big-endian platforms, by changing the byte offsets.
|MoarVM/big-endian-deserialisation: dfbdcc9de8 | (Nicholas Clark)++ | src/6model/serialization.c
Add casts to calls to `switch_endian` to avoid compiler warnings.
`switch_endian` takes a `char *` pointer - for the read* functions where we
are passing a pointer to the integer variable that we read into, we need a cast else the compiler rightly warns.
Mark `switch_endian` itself as MVM_STATIC_INLINE - the compiler probably assumes this already, but let's just be clear.
|Kaiepi||tbf, this is a mistake i was making as well before trying my hand at fixing this sort of warning||16:48|
|so it's understandable||16:49|
|Geth||MoarVM: nwc10++ created pull request #1365:
Big endian deserialisation
16:51 patrickb left
|sena_kun||It's release time!||17:01|
17:09 zakharyas joined
|Geth||MoarVM: Kaiepi++ created pull request #1366:
Fix zeroing of reallocated memory in MVM_recalloc
17:21 Altai-man joined 17:24 sena_kun left
|Geth||MoarVM/2020.10: 544eb57ace | Altai-man++ | docs/ChangeLog
Update ChangeLog for 2020.10 release
|MoarVM/2020.10: 158e634b8e | Altai-man++ | VERSION
Bump VERSION for release
|MoarVM: Altai-man++ created pull request #1367:
18:19 patrickb joined
|Geth||MoarVM: 544eb57ace | Altai-man++ | docs/ChangeLog
Update ChangeLog for 2020.10 release
|MoarVM: 158e634b8e | Altai-man++ | VERSION
Bump VERSION for release
|MoarVM: 817937f92f | Altai-man++ (committed using GitHub Web editor) | 2 files
Merge pull request #1367 from MoarVM/2020.10
|Altai-man||MoarVM release is done, merge time for anything dangerous yet awesome since Monday.||18:23|
|tellable6||2020-10-24T16:04:17Z #raku-dev <vrurg> Altai-man It's a bug in GDBM – BUILD should not be a method. And they have both method and submethod. I'll submit a PR to the module when have time. But it shouldn't be an obstacle for the release.|
|patrickb||Altai-man++ Thanks for your (I imagine sometimes thankless) work on the releases. It is very valuable. What would we do without releases?||18:38|
|tellable6||2020-10-24T12:35:57Z #raku <El_Che> patrickb: habe you seen this when runnig make for moarvm: travis-ci.org/github/nxadm/rakudo-...4305#L1094|
|2020-10-24T12:36:21Z #raku <El_Che> patrickb: only on he newly released ubuntu 20.10|
|Altai-man||patrickb, thank you! Well, cannot say they are in any way thankless, as people here are really nice to be around and I am grateful for that.||18:49|
|Altai-man||I am really happy someone like you looks into build/tooling issues. It is not your typical "coding" thing and needs some mastery, so many hesitate to try to deal with it.||18:52|
|Or, rather, some "special" kind of mastery compared to coding as e.g. I usually do.||18:53|
19:17 patrickb left, patrickb joined
|nwc10||.tell brrt it's getting worse. Now I'm looking at assembler output from *gdb*||19:43|
|tellable6||nwc10, I'll pass your message to brrt|
20:32 Kaiepi left 20:33 Kaiepi joined 20:43 Kaiepi left 20:44 Kaiepi joined 20:49 Kaiepi left 20:51 Kaiepi joined
|timotimo||is this in the interest of optimization, or to figure out alignment issues or something?||20:54|
|nwc10||"why do 2 nativecall tests fail on sparc?"||20:55|
|one fails with a SIGBUS which might be our fault (it's trying to write a 64 bit value to a pointer that is only 4-byte aligned)|
|the other fails bceause 0xFE != 0xFE. ish||20:56|
|which *seems* to be bceause the test function (TakeUint8) is compiled to assembly language that assumes that the Uint8 value is *not* sign extended by the caller|
|but the caller (dyncall, I think) is||20:57|
|as in - I think that clang and gcc are both correct, and either dyncall is wrong or we're using dyncall wrongly|
|TakeUint32 assumes that the caller is sign extending the 32 bit parameter|
|and TFM most definately says that this is wrong|
|so, OK, is this really a bug in both gcc and clang on sparc linux||20:58|
|or does sparc linux have an ABI which doesn't quite match what Orracle and sparc.org say in their docs|
|and I knew *none* of this a few hours ago|
|anyway, I should go to bed|
|I realise that somewhere on the gcc compile farm there are Solaris machines|
|so I can see what their compilers compile the test fucntions to|
|but I suspect I need to write some C test code that takes MoarVM etc out of the picture||20:59|
|also in "Today I Laerned" - how to single step instructions in gdb||21:00|
|and that sparc has delay slots|
|and the implication of this is that you have no clue (in gdb) which way the branch went until after you've stepped past the delay slot|
|timotimo||oh yes sign expansion is always fun||21:02|
|MVP_round_up_log_base2 - is it really MVP?||21:03|
|nwc10||er, good spot, no||21:04|
|MVP was the test codebase "Minimum Viable Product"|
|that should be fixed|
|but not by me tonight|
21:21 zakharyas left 21:22 sena_kun joined 21:23 patrickb left 21:24 Altai-man left 21:43 Kaiepi left 21:44 Kaiepi joined 21:56 patrickb joined 22:12 Kaiepi left 22:13 Kaiepi joined 22:15 patrickb left 22:20 patrickb joined 22:23 sena_kun left 22:42 sena_kun joined 22:47 sena_kun left