[00:00] *** patrickb left
[04:41] *** unicodable6 left
[04:42] *** quotable6 left
[04:42] *** bloatable6 left
[04:42] *** shareable6 left
[05:24] <nine> https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/

[05:24] *** greppable6 left
[05:24] *** nativecallable6 left
[05:24] *** statisfiable6 left
[05:24] *** bisectable6 left
[05:24] *** notable6 left
[05:25] *** bisectable6 joined
[05:25] *** notable6 joined
[05:25] *** statisfiable6 joined
[05:25] *** greppable6 joined
[05:25] *** nativecallable6 joined
[05:26] *** sena_kun joined
[05:38] *** unicodable6 joined
[05:39] *** bloatable6 joined
[05:39] *** shareable6 joined
[05:40] *** quotable6 joined
[06:30] *** sena_kun1 joined
[06:39] *** sena_kun1 left
[07:31] *** patrickb joined
[08:02] *** domidumont left
[08:57] <Geth> ¦ MoarVM: 3c3a24bff6 | (Nicholas Clark)++ | 2 files

[08:57] <Geth> ¦ MoarVM: Fix two *printf size warnings reported on ILP32 platforms.

[08:57] <Geth> ¦ MoarVM: 

[08:57] <Geth> ¦ MoarVM: In debugserver.c, handle_id is 64 bit, so use PRId64.

[08:57] <Geth> ¦ MoarVM: 

[08:57] <Geth> ¦ MoarVM: In the profiler, we print out the difference between two pointers. This has

[08:57] <Geth> ¦ MoarVM: the type ptrdiff_t. It seems that on most platforms that ptrdiff_t is a

[08:57] <Geth> ¦ MoarVM: typedef for long. However, on (at least) arm32 and sparc32 it is a typedef

[08:57] <Geth> ¦ MoarVM: <…commit message has 6 more lines…>

[08:57] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3c3a24bff6

[09:08] <sena_kun> Hey. Any obvious release blockers from moarvm side?

[09:21] *** Altai-man joined
[09:23] *** sena_kun left
[09:24] <nine> The parametric interning issue. I think my commit has not yet been reverted

[09:26] <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:45] *** domidumont joined
[09:48] *** domidumont left
[10:42] <Geth> ¦ MoarVM: 1db1cd1488 | Altai-man++ | src/6model/serialization.c

[10:42] <Geth> ¦ MoarVM: Revert "Fix interning of parametric types in precompilation"

[10:42] <Geth> ¦ MoarVM: 

[10:42] <Geth> ¦ MoarVM: This reverts commit b6d064a698c50842086f15aedd1aacc279086ba3.

[10:42] <Geth> ¦ MoarVM: This commit caused some ecosystem modules (Uzu, MagickWand) fail compilation

[10:42] <Geth> ¦ MoarVM: with "Object does not exist in serialization context", so revert to original

[10:42] <Geth> ¦ MoarVM: code until there is a better fix.

[10:42] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1db1cd1488

[10:43] <Altai-man> Ouch.

[10:44] <nine> Altai-man: thanks!

[10:44] * Altai-man just broke master. :(

[10:45] <nine> oh, how?

[10:45] <Geth> ¦ MoarVM: f99bc2ce76 | Altai-man++ | src/6model/serialization.c

[10:45] <Geth> ¦ MoarVM: Revert "Fix memory leak in resolve_param_interns"

[10:45] <Geth> ¦ MoarVM: 

[10:45] <Geth> ¦ MoarVM: This reverts commit 8c41f6692e844f34e7a8322b5462bbef6b07202d.

[10:45] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f99bc2ce76

[10:45] <Altai-man> There was a next commit fixing a leak which was not reverted. :|

[10:45] <nine> ah, well, if it's just that

[10:46] <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

[10:47] <Altai-man> Let's hope for the best without burning anyone. \o/

[10:50] *** Geth left
[10:50] *** Geth joined
[10:51] *** travis-ci joined
[10:51] <travis-ci> MoarVM build failed. Altai-man 'Revert "Fix interning of parametric types in precompilation"

[10:51] <travis-ci> https://travis-ci.org/MoarVM/MoarVM/builds/738521763 https://github.com/MoarVM/MoarVM/compare/3c3a24bff6c8...1db1cd1488f3

[10:51] *** travis-ci left
[12:19] <Kaiepi> timotimo, are you on?

[12:26] <Kaiepi> .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
[16:27] <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

[16:29] <Kaiepi> hi

[16:34] <Kaiepi> 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] <Kaiepi> this snprintf call is one https://github.com/MoarVM/MoarVM/blob/master/src/profiler/heapsnapshot.c#L1734

[16:36] <Kaiepi> 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] <Kaiepi> s/on my system\.//

[16:38] <timotimo> it's true, and shameful, that i'm not being dilligent enough using the right formatting codes for my printfs

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: a37cd76332 | (Nicholas Clark)++ | src/6model/serialization.c

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: The inline `memcpy` replacement can be used on all little-endian platforms.

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: 

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: The `memcpy` in `MVM_serialization_read_int` was to avoid unaligned access

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: to a MVMint64 value. The replacement code that unwraps and inlines it only

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: does byte access to memory, so it's quite safe to *also* use this on

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: platforms that can't do unaligned 64-bit reads.

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: 

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: (If the compiler on platforms that can read unaligned spots that it can

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: optimise our byte accesses to larger reads, that's just fine, because it

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: doesn't affect the platforms where this is fatal.)

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: review: https://github.com/MoarVM/MoarVM/commit/a37cd76332

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: cbb92b038b | (Nicholas Clark)++ | src/6model/serialization.c

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: The inline `memcpy` replacement can be adapted for big-endian platforms.

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: 

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: The `memcpy` in `MVM_serialization_read_int` was to avoid unaligned access

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: to a MVMint64 value. The that unwraps and inlines for little-endian

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: platforms can also be adapted for big-endian platforms, by changing the byte

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: offsets.

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: review: https://github.com/MoarVM/MoarVM/commit/cbb92b038b

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: dfbdcc9de8 | (Nicholas Clark)++ | src/6model/serialization.c

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: Add casts to calls to `switch_endian` to avoid compiler warnings.

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: 

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: `switch_endian` takes a `char *` pointer - for the read* functions where we

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: are passing a pointer to the integer variable that we read into, we need a

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: cast else the compiler rightly warns.

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: 

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: Mark `switch_endian` itself as MVM_STATIC_INLINE - the compiler probably

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: assumes this already, but let's just be clear.

[16:47] <Geth> ¦ MoarVM/big-endian-deserialisation: review: https://github.com/MoarVM/MoarVM/commit/dfbdcc9de8

[16:48] <Kaiepi> tbf, this is a mistake i was making as well before trying my hand at fixing this sort of warning

[16:49] <Kaiepi> so it's understandable

[16:49] <Geth> ¦ MoarVM: nwc10++ created pull request #1365: Big endian deserialisation

[16:49] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1365

[16:51] *** patrickb left
[17:01] <sena_kun> It's release time!

[17:03] <nwc10> \o/

[17:09] *** zakharyas joined
[17:18] <Geth> ¦ MoarVM: Kaiepi++ created pull request #1366: Fix zeroing of reallocated memory in MVM_recalloc

[17:18] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1366

[17:21] *** Altai-man joined
[17:24] *** sena_kun left
[18:11] <Geth> ¦ MoarVM/2020.10: 544eb57ace | Altai-man++ | docs/ChangeLog

[18:11] <Geth> ¦ MoarVM/2020.10: Update ChangeLog for 2020.10 release

[18:11] <Geth> ¦ MoarVM/2020.10: review: https://github.com/MoarVM/MoarVM/commit/544eb57ace

[18:11] <Geth> ¦ MoarVM/2020.10: 158e634b8e | Altai-man++ | VERSION

[18:11] <Geth> ¦ MoarVM/2020.10: Bump VERSION for release

[18:11] <Geth> ¦ MoarVM/2020.10: review: https://github.com/MoarVM/MoarVM/commit/158e634b8e

[18:12] <Geth> ¦ MoarVM: Altai-man++ created pull request #1367: 2020.10 release

[18:12] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1367

[18:19] *** patrickb joined
[18:20] <Geth> ¦ MoarVM: 544eb57ace | Altai-man++ | docs/ChangeLog

[18:20] <Geth> ¦ MoarVM: Update ChangeLog for 2020.10 release

[18:20] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/544eb57ace

[18:20] <Geth> ¦ MoarVM: 158e634b8e | Altai-man++ | VERSION

[18:20] <Geth> ¦ MoarVM: Bump VERSION for release

[18:20] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/158e634b8e

[18:20] <Geth> ¦ MoarVM: 817937f92f | Altai-man++ (committed using GitHub Web editor) | 2 files

[18:20] <Geth> ¦ MoarVM: Merge pull request #1367 from MoarVM/2020.10

[18:20] <Geth> ¦ MoarVM: 

[18:20] <Geth> ¦ MoarVM: 2020.10 release

[18:20] <Geth> ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/817937f92f

[18:23] <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.

[18:38] <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: https://travis-ci.org/github/nxadm/rakudo-pkg/builds/738534305#L1094

[18:38] <tellable6> 2020-10-24T12:36:21Z #raku <El_Che> patrickb: only on he newly released ubuntu 20.10

[18:49] <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:50] <patrickb> :-)

[18:52] <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:53] <Altai-man> Or, rather, some "special" kind of mastery compared to coding as e.g. I usually do.

[19:17] *** patrickb left
[19:17] *** patrickb joined
[19:43] <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
[20:54] <timotimo> is this in the interest of optimization, or to figure out alignment issues or something?

[20:55] <nwc10> "why do 2 nativecall tests fail on sparc?"

[20:55] <nwc10> 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)

[20:56] <nwc10> the other fails bceause 0xFE != 0xFE. ish

[20:56] <nwc10> 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

[20:57] <nwc10> but the caller (dyncall, I think) is

[20:57] <nwc10> as in - I think that clang and gcc are both correct, and either dyncall is wrong or we're using dyncall wrongly

[20:57] <nwc10> *but*

[20:57] <nwc10> TakeUint32 assumes that the caller is sign extending the 32 bit parameter

[20:57] <nwc10> and TFM most definately says that this is wrong

[20:58] <nwc10> so, OK, is this really a bug in both gcc and clang on sparc linux

[20:58] <nwc10> or does sparc linux have an ABI which doesn't quite match what Orracle and sparc.org say in their docs

[20:58] <nwc10> ho

[20:58] <nwc10> and I knew *none* of this a few hours ago

[20:58] <nwc10> anyway, I should go to bed

[20:58] <nwc10> I realise that somewhere on the gcc compile farm there are Solaris machines

[20:58] <nwc10> so I can see what their compilers compile the test fucntions to

[20:59] <nwc10> but I suspect I need to write some C test code that takes MoarVM etc out of the picture

[21:00] <nwc10> also in "Today I Laerned" - how to single step instructions in gdb

[21:00] <nwc10> and that sparc has delay slots

[21:00] <nwc10> 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

[21:02] <timotimo> oh yes sign expansion is always fun

[21:03] <timotimo> MVP_round_up_log_base2 - is it really MVP?

[21:04] <nwc10> er, good spot, no

[21:04] <nwc10> MVP was the test codebase "Minimum Viable Product"

[21:04] <nwc10> that should be fixed

[21:04] <nwc10> 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