00:27 vendethiel joined 00:58 vendethiel joined 01:39 zakharyas joined 02:03 vendethiel joined 02:50 jimmy_ joined, vendethiel joined 03:35 vendethiel joined 04:48 vendethiel joined 05:15 vendethiel joined 05:41 vendethiel joined 06:27 vendethiel joined 06:38 kjs_ joined 07:45 FROGGS joined 07:58 zakharyas joined 08:03 vendethiel joined
nwc10 "All tests successful." - ASAN still doesn't spot anything 08:55
FROGGS I'd like to get these OSX failures nailed down :/
JimmyZ FROGGS: github.com/MoarVM/MoarVM/commit/33...130f8cR879 08:57
FROGGS JimmyZ: I replied today via phone... did you get my message? 08:59
JimmyZ FROGGS: I didn't see it anywhere 09:01
FROGGS JimmyZ: k... I said that reverting it is fine by me, in exchange that you'd take a look at issue #154 :o)
my gut feeling is that the string allocated here: github.com/MoarVM/MoarVM/blob/mast...ops.c#L826 09:03
JimmyZ doesn't have OSX :( 09:04
FROGGS causes trouble when we do not use it because of: github.com/MoarVM/MoarVM/blob/mast...ops.c#L883 09:05
JimmyZ: but you have brains! :D 09:06
JimmyZ FROGGS: it's not a problem with allocating unused MVMString. 09:07
FROGGS but it is about trying to free that union
maybe clang+osx needs special treatment when it comes to unions? 09:08
... or onions
JimmyZ and I don't think the bt give me any info :(. I think it's about GC movement which causes *any pointing to wrong place :P 09:11
FROGGS hmmm 09:14
but any points to memory managed by C
JimmyZ FROGGS: yeah, but GC maybe move its address to wrong place, something like off-by-one on OSX 09:18
MVM_gc_allocate_object allocates zero memory be default 09:19
*zeroed
FROGGS yes yes, I know now :o) 09:22
lizmat The MoarVM build is filled with warnings... maybe that can be a source of inspiration ? 09:23
JimmyZ saw some warnings with NFC.c
*NFA.c 09:24
lizmat afk for a few hours& 09:34
FROGGS JimmyZ: these warnings are about debug message printing only AFAIK... but wants fixing anyway 09:47
lizmat: would be nice if you could provide a build log then :o)
JimmyZ yeah, I didn't see any other warnings :P
09:48 vendethiel joined 10:15 dalek joined 11:01 vendethiel joined
lizmat FROGGS: here you go: a copy of a new build log on OS X: gist.github.com/lizmat/862c5a8868a916122c42 11:32
it's only 5.6K lines and 370K bytes 11:34
11:58 vendethiel joined 12:22 vendethiel joined 13:14 vendethiel joined 13:56 brrt joined
dalek arVM: 2508b40 | (Elizabeth Mattijsen)++ | src/core/frame.c:
Fix warnings

  "using the result of an assignment as a condition without parentheses" on OS X
  (clang)		 14:11
14:27 hoelzro joined 14:34 JimmyZ joined
dalek arVM: 6cd9478 | (Elizabeth Mattijsen)++ | src/ (4 files):
Fix "'&&' within '||'" warnings on OS X (clang)
 14:34
arVM: 85b1a50 | (Elizabeth Mattijsen)++ | src/6model/serialization.c:
Fix suspect warning on OS X (clang)

type specifier missing, defaults to 'int'. Since all of the similar functions where void as well, I made this one also void (instead of the default int). This also fixed the related "control reaches end of non-void function" warning.		 14:46
brrt lizmat++ 14:50
now if you could speed up clang in the first place.. :-P
lizmat I would much rather prefer a stable rakudo on OS X :-(
brrt isn't it? 14:53
hmmm
14:53 kjs_ joined
[Coke] brrt: not for a month now. 15:00
lots of segfaults (jit) and invalid memory usage errors (nonjit) 15:01
brrt ok, that's odd
in spectests?
[Coke] one of the latest tickets has a backtrace on a memory issue.
brrt: yes.
brrt ok
let me see if i can repeat that a bit
things are rarely memory issues though
[Coke] brrt: Just telling you what rakudo is telling us. :) 15:02
brrt :-) i know, just telling you my gut feeling 15:03
memory issues are fairly rare
[Coke] note that the backtrace I have there, I only got when running under the test_summary test harness. (was definitely coming from rakudo, though, not the perl5 harness)
dalek arVM: 910a06c | (Elizabeth Mattijsen)++ | src/mast/driver.c:
fix another assignment in condition warning
 15:11
lizmat timotimo: looking at src/spesh/optimize.c, line 310 15:12
if ((safety_cur->info->operands[0] & MVM_operand_rw_mask == MVM_operand_write_reg)
I think we need parens here (suggestion by clang) 15:13
clang is doing the == before the &
brrt: don't you agree? 15:14
brrt lett me see 15:16
jnthn Not jut in Clang, it's that way in the C standard... en.cppreference.com/w/c/language/op...precedence
brrt wait
that seems... wrong
i /think/ we should have two &'s there
jnthn No, & is right; it's a bitmask
lizmat from the wording of the wording of the variables, I think we just need parens 15:17
brrt but a == b isn't guaranteed to set 1
or is it
lizmat that's why I think there's () missing
feels to me it should first mask, and then compare
jnthn lizmat: Yes, that's the intent. Mask then compare. 15:18
lizmat: So I think the code is wrong.
lizmat ok, that's one bug fixed then...
lizmat goes to test effect on rakudo
still flaky spectest :-( 15:25
15:25 zakharyas joined
dalek arVM: 018a260 | (Elizabeth Mattijsen)++ | src/spesh/optimize.c:
First mask bitmap, then compare
 15:27
lizmat src/spesh/inline.c:96 gives "add explicit braces to avoid dangling else" warning 15:29
not sure what to make of that... 15:30
dalek arVM: 434de0c | (Elizabeth Mattijsen)++ | src/spesh/inline.c:
Fix dangling else (hopefully the right way)
 15:37
brrt is running spectests 15:38
hmmm
lizmat ? 15:39
brrt for so far as these are clang issues, i could test them at home
my mac-access is limited to $work
lizmat that would be great...
brrt :-)
lizmat I mean, the noise of the clang build is deafening, drowning out any other squeaks
brrt agrees
which is why i always build with gcc ;-) 15:40
otherwise... i'd fear to think what could possibly be so mac-os-x specific that moar would be sensitive for 15:42
dalek arVM: cf39e6c | jimmy++ | src/strings/ops.c:
Revert "attempt to fix a non-alloc+free #154"

This reverts commit 33970c6dfdddb5f1d3d667bf1e294ee8f09185d0.		 15:46
arVM: c8b0b97 | jimmy++ | src/gc/debug.h:
remove an unused semicolon
jnthn sleep & 15:53
lizmat gnight jnthn !
brrt tests are flaky indeed 15:54
sleep well jnthn :-)
JimmyZ good night too 15:55
lizmat implicit declaration of function 'MVM_panic' 16:14
guess we forgot to include a .h somewhere ?
16:17 FROGGS[mobile] joined
dalek arVM: 4f1ba61 | (Elizabeth Mattijsen)++ | src/platform/posix/mmap.c:
Add missing include
 16:18
arVM: 8f4d53f | (Elizabeth Mattijsen)++ | src/jit/graph.c:
Fix another assignment as condition warning
 16:28
16:36 vendethiel joined
dalek arVM: 933a2a2 | (Elizabeth Mattijsen)++ | tools/ucd2c.pl:
Fix a *lot* of warnings in strings/unicode.c
 16:36
16:47 FROGGS joined
[Coke] no love on the daily run, though it predates a bunch of the warnings commits. 16:59
sounds like brrt was able to reproduce some flakiness, that's good. 17:03
lizmat: btw, I'm not running the spec tests in parallel. 17:12
and I'm still seeing the fails. (I'm using test_summary, which is currently single-threaded)
lizmat ah? and still flakiness?
hmmm.... lemme try that as well
[Coke] but same thing; fails only when running through a harness; run by hand, most of the time ok. 17:13
I ended up making it reproducable by making a single line spectest.data, and always using test summary to launch.
lizmat does anybody know how and when to run tools/ucd2c.pl ?
[Coke]: is there a difference between "make spectest" and "make t/spec/foo.t" ? 17:14
wrt to harnessing ?
[Coke] I never use make .../foo.t, I unno off the top of my head. 17:16
(if I'm running a single file, I almost always use prove -v -e t/fudgeandrun t/spec/foo.t
looking at the makefile, looks like make *.t uses the harness, yes. 17:19
lizmat I *rarely* get an error testing like that
[Coke] right. any of the memory issues, if you run it by itself, it's fine. 17:20
lizmat fwiw, in the past weeks I also got errors *in* the perl5 harness
[Coke] I suspect *some* kind of memory pressure, but I have 16G, not sure that's really teh issue.
lizmat only twice, but still
lizmat has 16G as well
maybe we haz 2much
[Coke] OHNOES 17:33
lizmat [Coke]: datapoint with TEST_JOBS=1: only 1 flapper 17:37
but not none :-(
17:51 FROGGS_ joined 18:47 vendethiel joined 22:13 kjs_ joined 23:00 kjs_ joined 23:08 kjs_ joined 23:33 vendethiel 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!