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
nine devblogs.microsoft.com/cppblog/c11...g-in-msvc/ 05:24
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)		 08:57
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.		 10:42
Altai-man Ouch. 10:43
nine Altai-man: thanks! 10:44
Altai-man just broke master. :(
nine oh, how? 10:45
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
travis-ci.org/MoarVM/MoarVM/builds/738521763 github.com/MoarVM/MoarVM/compare/3...b1cd1488f3
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
Kaiepi hi 16:29
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.)		 16:47
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
nwc10 \o/ 17:03
17:09 zakharyas joined
Geth MoarVM: Kaiepi++ created pull request #1366:
Fix zeroing of reallocated memory in MVM_recalloc		 17:18
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
 18:11
MoarVM/2020.10: 158e634b8e | Altai-man++ | VERSION
Bump VERSION for release
MoarVM: Altai-man++ created pull request #1367:
2020.10 release		 18:12
18:19 patrickb joined
Geth MoarVM: 544eb57ace | Altai-man++ | docs/ChangeLog
Update ChangeLog for 2020.10 release
 18:20
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

2020.10 release
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
patrickb :-) 18:50
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
*but*
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
ho
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!