github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:25 Kaiepi left 00:29 vrurg joined 00:32 Kaiepi joined 00:40 lucasb left 00:57 vrurg left 01:04 vrurg joined 01:19 colomon joined 02:47 Ven`` left 02:49 ZzZombo left 02:54 ZzZombo joined 03:40 colomon left 08:16 AlexDaniel left 08:23 lizmat left 09:34 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 09:43 MasterDuke joined 09:48 domidumont joined 10:06 domidumont left 10:11 lizmat joined, domidumont joined
Geth MoarVM/master: 4 commits pushed by (Stefan Seifert)++ 10:34
MoarVM/master: 4 commits pushed by (Stefan Seifert)++ 10:48
10:58 sena_kun joined 11:01 domidumont left
Geth MoarVM/master: 5 commits pushed by (Stefan Seifert)++ 11:02
11:09 colomon joined
lizmat nine++ # on a roll! 11:14
11:18 colomon left
MasterDuke indeed, nine++ 11:20
nine: btw, i assume you've seen the appveyor failures? `src\core\interp.c(5553) : error C2275: 'MVMuint64' : illegal use of this type as an expression src\moar.h(45) : see declaration of 'MVMuint64'src\core\interp.c(5553) : error C2146: syntax error : missing ';' before identifier 'value'src\core\interp.c(5553) : error C2065: 'value' : 11:22
undeclared identifier`
nine MasterDuke: no, where do I see those? 11:33
MasterDuke ci.appveyor.com/project/samcv/moar...uldqtigutr
nine Oh, I think it's about mixing declarations and statements 11:34
So...how do we configure AppVeyor to compile in a way that those aren't an issue anymore?
MasterDuke i thought we don't allow that (mixing declarations and statements) anywhere? 11:37
nine Well, I've had it with that nonsense. I removed the error in an attempt to fix the build on older compiler versions, which it did: github.com/MoarVM/MoarVM/commit/a0...960f257bf6 11:44
Now I'm looking for the switch to enable C99 support on MSVC
Geth MoarVM: 21f9c3284b | (Stefan Seifert)++ | build/setup.pm
Try to enable C99 features on MSVC
 11:58
nine Fails, because that switch is only available in VS 2017 and AppVeyor builds on VS 2015. The build on 2017 is disabled because we don't know where "setenv.cmd" is 12:04
Geth MoarVM: 3d2f8d739f | (Stefan Seifert)++ | .appveyor.yml
Try to switch AppVeyor to VS 2017 for C99 support
 12:09
nine Docs said so: www.appveyor.com/docs/lang/cpp/
Geth MoarVM: bed44f1d51 | (Stefan Seifert)++ | .appveyor.yml
Try to fix syntax error in .appveyor.yml
 12:11
dogbert17 nine: how am I supposed to find any bugs when you fix all of them :) 12:12
12:18 domidumont joined
Geth MoarVM: 795b320b02 | (Stefan Seifert)++ | 2 files
Avoid empty initializers to help syntactically challenged compilers

The last field is an array, so at least give it the initial 0 (which it will replicate onto the remaining slots)		 12:18
nine There we have it! Never again write worse code just to appease ancient versions of compilers limited by their vendor's politicking :) ci.appveyor.com/project/samcv/moar...p018c6qdtq 12:24
sena_kun nine++ 12:25
Geth MoarVM: 631d361c6f | (Stefan Seifert)++ | src/moar.c
Add some parens to make the author's intentions clear

The && was indeed intended and the expression is correct. Sorry jnthn		 12:30
MoarVM: bfce0c9087 | (Stefan Seifert)++ | src/core/interp.c
Make it clear that the label is only used if computed goto is not available
 12:38
MoarVM: 31a1b22c6c | (Stefan Seifert)++ | build/setup.pm
Enable -Wall with only a few exceptions

The exceptions are:
  -Wunused-parameter which would generate lots of warnings about parameters that
   are not used by all implementations of an interface.
  -Wunused-function which would generate lots of warnings about static inline
   functions defined in header files but not used by all files that include the
   header.
  -Wmissing-braces which would generate lots of apparently bogus warnings. Might
   be due to a compiler bug.
12:38 Geth left, Geth joined 12:55 ZzZombo left, ZzZombo joined
Geth MoarVM: 1f31143e75 | (Stefan Seifert)++ | src/6model/reprs/MVMSpeshPluginState.c
Implement MVMSpeshPluginState's unmanaged_size function

Helps the GC estimate memory pressure.		 12:58
MoarVM: e556879ad7 | (Stefan Seifert)++ | src/6model/reprs/MVMSpeshPluginState.c
Remove unimplemented describe_refs from MVMSpeshPluginState
12:59 Altai-man_ joined 13:00 Altai-man_ left 13:02 sena_kun left, sena_kun joined 13:05 sena_kun left
Geth MoarVM: 5464dd47ce | (Stefan Seifert)++ | 4 files
Move internal shift_jis functions to shiftjis.c and mark them static

This fixes compiler warnings about unused variables caused by them getting declared static in a header file that was included in 2 .c files. The functions in question were used only in shiftjis.c, so move them there.		 13:08
nine So that's it. Only 3 warnings left which I'm not sure what to do about. 13:09
13:12 travis-ci joined
travis-ci MoarVM build passed. Stefan Seifert 'Enable -Wall with only a few exceptions 13:12
travis-ci.org/MoarVM/MoarVM/builds/618910806 github.com/MoarVM/MoarVM/compare/6...a1b22c6c28
13:12 travis-ci left
Geth MoarVM: 1de3c40c02 | (Stefan Seifert)++ | src/jit/x64/emit.dasc
Add missing pragma push
 13:16
13:22 travis-ci joined
travis-ci MoarVM build passed. Stefan Seifert 'Remove unimplemented describe_refs from MVMSpeshPluginState' 13:22
travis-ci.org/MoarVM/MoarVM/builds/618914742 github.com/MoarVM/MoarVM/compare/3...56879ad738
13:22 travis-ci left 13:34 travis-ci joined
travis-ci MoarVM build passed. Stefan Seifert 'Move internal shift_jis functions to shiftjis.c and mark them static 13:34
travis-ci.org/MoarVM/MoarVM/builds/618916989 github.com/MoarVM/MoarVM/compare/e...64dd47ce48
13:34 travis-ci left 13:52 sena_kun joined 14:12 AlexDaniel left 14:33 sena_kun left 14:34 sena_kun joined
lizmat nine: time for a bump ? 14:44
Kaiepi nine is github.com/MoarVM/MoarVM/pull/1214 ok now? 14:46
14:47 sena_kun left 14:50 sena_kun joined 15:01 sena_kun left 15:17 sena_kun joined
MasterDuke nine++++. still an apveyor error however, `src\core\interp.c(183): error C2094: label 'runloop' was undefinedNMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64\cl.EXE"' : return code '0x2'` 15:21
Geth MoarVM: MasterDuke17++ created pull request #1217:
Remove unused variable declaration		 15:28
15:32 domidumont left
Geth MoarVM: MasterDuke17++ created pull request #1218:
Fix sometimes uninitialized warning		 15:34
MoarVM: c31a7ac1a2 | (Stefan Seifert)++ | src/core/interp.c
Revert "Make it clear that the label is only used if computed goto is not available"

This reverts commit bfce0c90871fb609e7ea4b6e8299368288a08701 which apparently breaks the build on MSVC.		 15:54
MoarVM: 3c2a933b55 | (Daniel Green)++ | src/6model/reprs/P6opaque.c
Remove unused variable declaration
 15:55
MoarVM: d3eebfe3b1 | niner++ (committed using GitHub Web editor) | src/6model/reprs/P6opaque.c
Merge pull request #1217 from MasterDuke17/fix_unused_variable_warning

Remove unused variable declaration
15:57 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 16:00 sena_kun left 16:01 sena_kun joined 16:10 brrt joined
brrt \o 16:12
dogbert17 hi brrt 16:20
nine: are you still around and about?
17:02 sena_kun left 17:07 zakharyas joined 17:15 sena_kun joined, zakharyas left
nine dogbert17: back 17:41
17:44 brrt left 17:47 domidumont joined
dogbert17 nine: the RPi 4 was a bit sceptical wrt one of the changes 17:57
src/strings/gb2312.c: In function ‘MVM_string_gb2312_decode’:
src/strings/gb2312.c:15:15: warning: comparison is always true due to limited range of data type [-Wtype-limits]
if (0 <= gb2312[i]) {
and a few more places, i.e. src/strings/gb2312.c:26 and src/strings/gb18030.c:60 17:58
nwc10 o/ 18:30
tellable6 2019-11-29T11:27:19Z #raku-dev <Guest38485> nwc10: I actually had my RPi 4 standing vertically. It did help a little. Anyway I have since bought a flirc.tv/more/raspberry-pi-4-case
japhb nine++ # Catching up on the last several days of #moarvm irclog has been an absolute pleasure. :-) 18:40
19:02 sena_kun left 19:15 domidumont left 19:16 sena_kun joined 19:17 lucasb joined 19:49 zakharyas joined 20:58 sena_kun1 joined, sena_kun left
nine dogbert17: that doesn't make any sense, as gb2312 is now a char *, i.e. signed. So why would a comparison vor >= 0 be always true? 21:01
21:02 sena_kun1 left 21:11 zakharyas left 21:17 sena_kun joined
dogbert17 nine: "char is signed on Intel and unsigned on ARM (the Pi)" according to answer on www.raspberrypi.org/forums/viewtop...p?t=233557 21:21
lizmat YUK
dogbert17 could that be the reason assuming that the information in the link is correct?
nine WHAT? 21:23
dogbert17 shocking ? 21:24
lizmat to me that is a WAT
stackoverflow.com/questions/205493...by-default 21:25
"The standard does not specify if plain char is signed or unsigned" 21:26
MasterDuke then maybe we should add `-fsigned-char` to the compiler options for rpi 21:27
dogbert17 MasterDuke: perhaps for other systems as well: "This causes problems on ARM based machines since "char" is of the "unsigned" variety, which allows the compiler to generate faster, more efficient code. ARM is not alone in this - SGI Mips running IRIX also encounters this problem."
Dunno if those systems are still in use 21:28
the Irix stuf that is
lizmat so why do we assume chars are signed? wouldn't it be better to thing of them as unsigned ? 21:29
nine I think the best course of action is to revert my changes to that file and just disable the warning. It's quite ironic that it's the same warning that now pointed out correctly that the code is wrong. Previously it read if (0 <= gb2312[i] && gb2312[i] <= 127) which covers both the signed and unsigned cases but will do one superfluous check in any case 21:30
dogbert17 nine: it was two files
japhb lizmat: Not looking at that particular code, so this could be unrelated, but don't we use negative values for signed char/short/int in strings to indicate that we've created an artificial combined grapheme "codepoint" to allow fast string indexing by grapheme? 21:32
dogbert17 gb2312.c and gb18030.c
lizmat yeah, but those are 32-bit ints
I believe?
japhb lizmat: I thought we did an 8-bit form as well for efficiency with european codepages? 21:33
To whit, making latin-1 fast
lizmat ah, in that case, it's above my pay level
japhb It's a vague memory for me as well.
nine negative graphemes are synthetics, but that's distinct from our 8-bit encoding handling 21:34
Will push a fix tomorrow 21:35
21:41 Kaiepi left 21:44 patrickb joined 21:53 Kaiepi joined 21:54 Kaiepi left 22:11 Kaiepi joined 22:17 lucasb left 22:19 Kaiepi left
jnthn We should really use MVMint8 and MVMuint8, rather than relying on the signedness of `char` 22:36
22:39 Kaiepi joined 23:02 sena_kun left 23:05 colomon joined 23:16 sena_kun joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!