dalek arVM: 2adf59f | jnthn++ | src/6model/reprs/CStruct.c:
Some cleanups to CStruct.
 00:05
00:25 ggoebel11113 joined 00:51 daxim joined 00:54 btyler joined 00:55 ggoebel11114 joined 01:00 btyler joined 01:02 daxim_ joined 01:04 btyler_ joined 01:08 rurban joined 01:18 rurban joined 01:31 tokuhirom joined, rurban joined 01:37 woosley joined 01:42 rurban joined 02:11 rurban joined 02:47 ilbot3 joined
JimmyZ .ask jnthn is it right? gist.github.com/zhuomingliang/9541417 03:03
03:18 woosley1 joined
dalek arVM: 5867a2a | jimmy++ | src/ (5 files):
some cleanups
 06:18
06:31 vincent22 joined
dalek arVM: 2ef7443 | jimmy++ | src/ (6 files):
more cleanups
 07:04
arVM: bad4243 | jimmy++ | src/mast/compiler.c:
Remove unused header files.
 07:10
07:55 FROGGS joined 07:56 zakharyas joined
dalek arVM: b14cf56 | jimmy++ | src/ (2 files):
Sets up some string constants a bit earlier
 08:15
08:27 brrt joined
dalek arVM: 6c5f57b | jimmy++ | src/6model/bootstrap.c:
updated outdated comments
 08:31
brrt jnthn - if i might ask, why is ConcBlockingQueue actually a c-level construct? 10:42
couldn't you implement it just as well in NQP
jnthn Not without doing other missing things first. 10:43
brrt fair enough
why do you need it before fixing those other mixing things :-)
missing things
jnthn Because nothing in Perl 6 depends on those missing things.
And lots (thread pool, channels) depend on having a concurrent blocking queue.
brrt i don't think channels are so obvious in concurrent blocking queue 10:44
especially as your implementation only 'blocks' on reads
jnthn The Perl 6 ones are unbounded so far also. But yeah, it needs to learn to bound. On JVM too. 10:45
Then it's just a question of what our default is.
brrt in a 'threaded copy' implementation i wrote it became obvious that go-like channel behaviour (where not only the receiver but also the sender waits) is a): ideal for reasoning and b): nontrivial with locks-and-condition-variables 10:48
unbounded channels are obviously ideal for message-passing / actor systems 10:49
unbounded queues
lets get the terminology strait :-)
straight
i don't know what it is with my language today
jnthn I think bounding the sender is OK with locks/condvars provided you have a condvar for the head and another for the tail. 10:50
"Just" need to signal in the right places. :)
dalek arVM: 9abc246 | jnthn++ | src/6model/reprs/CStruct.c:
Correct various errors in CStruct.

With this, it manages to compose.		 10:55
brrt hmmm 10:57
if you wish, you can check out github.com/bdw/lab/blob/master/jav...Queue.java - apologies for naming etc
works with a 'get' and 'put' lock
also works remarkably well, if i might be so honest, hadn't expect it 10:58
the last thing you'd want to do - it seems - is close 'queues' or channels 10:59
'close' not 'queue'
and anyway, that doesn't have sender-block 11:00
jnthn The sender needs to be able to close. 11:01
Completion notification is an important part of most things.
Especially as soon as you start allowing movement between paradigms. 11:02
A supply knows when the end is, as does a lazy list.
Of course, both of those may be unending too.
And so it should be with channels.
brrt exactly 11:03
but what about a fan-in channel :-)
i.e. many threads writing to a single channel
no single sender should be able to close it
but closing it from the receiving end might make a lot of sense 11:04
jnthn Depends on the topology. If you're in a producer/consumer situation and the fan-out/in is just because one stage got multiple workers, then the thing that spawned the workers likely wants to do it. 11:07
Promise.all(@workers).then({ $c.close }) # or so 11:08
brrt i see 11:10
concurrency is fun :-)
jnthn Yes :)
jnthn spent the last couple of weeks teaching a couple of classes in it :)
brrt in sweden? 11:11
jnthn Yeah
brrt pretty nice i guess :-) 11:12
jnthn Yeah, I enjoyed it. 11:19
And weather in places I went was rather nice too :)
dalek arVM: 0daccb8 | jnthn++ | src/moar.h:
First pass at an ALIGNOF macro.
 11:20
arVM: 80158be | jnthn++ | src/6model/reprs/CStruct.c:
Uncomment ALIGNOF use in CStruct.
arVM: 087f7c0 | jnthn++ | src/6model/ (10 files):
Add align to storage_spec; set it.
nwc10 jnthn: what is "#eli defined" 11:29
ie a typo'd elif?
jnthn uh...yes, which MSVC apparently compiles o.O 11:32
wtf!!
brrt whut 11:34
haha
brrt is off for lunch
JimmyZ jnthn: is it right? gist.github.com/zhuomingliang/9541417 11:41
jnthn JimmyZ: Well, I think we should re-work compose and the way we do the attribute stuff to look more like P6opaque's compose does. 11:43
JimmyZ how soon? :-) 11:45
jnthn JimmyZ: Well, given the current code apparently doesn't work...sooner rather than later :) 11:49
oh, that's 'cus the gc_mark_repr_data function isn't in the table 11:51
JimmyZ I have another patch to it: gist.github.com/zhuomingliang/9541251 , it avoids MVMROOT current_class
which is not MVMROOTed yet 11:52
jnthn *and* that is busted
JimmyZ the patch is busted? 11:53
jnthn No, gc_mark_repr_data... 11:54
Anyway... *sigh*
Turns out that the first test for CStruct actually wants CArray to work
So I should probably go work on that first.
Anyway, yeah, I think instead of that patch we should do it the P6opaque way. 11:55
JimmyZ oh, I lost gc_mark_repr_data in the table :(
dalek arVM: c1d5a41 | jnthn++ | src/moar.h:
Correct #eli to #elif.

Not sure how the original wrong spelling ever compiled on MSVC, but it did!		 11:56
arVM: 070c1a5 | jnthn++ | src/6model/reprs/CStruct. (2 files):
Work towards attribute bind support in CStruct.
jnthn JimmyZ: 070c1a5 fixes that; it missed a null check too.
JimmyZ: I'm going to look at CArray first, though. 11:57
12:34 colomon joined
JimmyZ jnthn: can I port bind_attribute_boxed to bind_attribute in CSturct? 12:36
jnthn JimmyZ: Yeah, should go in the place I left die_no_attrs 12:44
JimmyZ: Moar doesn't break binding of attributes up into two pieces.
12:49 lizmat joined
dalek arVM: b96bc03 | jimmy++ | src/6model/reprs/CStruct.c:
Complete attribute bind support in CStruct
 12:51
12:52 lizmat joined
dalek arVM: a4d32f0 | jnthn++ | src/6model/reprs/CArray.c:
Move CArray setup logic into compose.
 12:58
jnthn "CArray representation does not fully positional storage yet" 12:59
:D
JimmyZ :D 13:00
dalek arVM: 0180a21 | jimmy++ | src/6model/reprs/CArray.c:
small cleanups to CArray
 13:08
13:15 lizmat joined 13:53 btyler joined 13:54 lizmat joined 13:58 tgt joined 13:59 flussence joined
dalek arVM: cea751f | jnthn++ | src/core/nativecall.c:
Handle CArray and CStruct returns.
 14:21
arVM: 26b7844 | jnthn++ | src/core/nativecall.c:
Avoid initialization when we've unmanaged result.
arVM: ea3877d | jnthn++ | src/6model/reprs/CArray.c:
Implement numeric case of atpos for CArray.
jnthn We now pass first 3 tests in 05-array.t 14:22
FROGGS \o/ 14:29
nwc10 \o/
tests are spectests or what? It's not obvious to me
jnthn No, NativeCall tests. 14:30
We don't include NativeCall in Rakudo core; it lives in a separate repo and is installable as a normal module 14:31
To give a Git analogy, it's the Perl 6 porcelain to the NQP-op native call plumbing.
dalek arVM: 7047838 | jnthn++ | src/6model/reprs/CArray.c:
bindpos for CArray of numeric type.
 14:33
arVM: 945a8b9 | jnthn++ | src/core/nativecall.c:
Support passing of CStruct and CArray.
jnthn 1 more test pass from those :)
JimmyZ I just updated linenoise to latest version... 14:43
14:50 retupmoca joined
dalek arVM: a896b55 | jnthn++ | src/6model/reprs/CArray.c:
Support looking up strings from a CArray.
 15:01
JimmyZ so what's the blocker to use lineniose? it works well on linux as far as I know... 15:08
jnthn JimmyZ: It hadn't used to work well.
JimmyZ: It was spewing prompts.
Dunno if the update fixes it. 15:09
JimmyZ hmm, I have linux box and it didn't do that
jnthn We can certainly try re-enabling it. 15:10
JimmyZ maybe it's on mac?
jnthn No, it did it on my Linux box.
And sure others reported it did so on Linux too
dalek arVM: 3f08640 | jnthn++ | src/6model/reprs/CArray.c:
Support binding strings into a CArray.
 15:15
arVM: 1ce7228 | jnthn++ | src/6model/reprs/CArray.c:
CArray bindpos of CArray/CPointer/CStruct elements
JimmyZ jnthn: I just tested, it works on CentOS release 6.2 (Final) X64 15:16
tested by nqp
FROGGS wasn't it that it just printed a gazillion of ">\n" ? 15:17
JimmyZ hmm
FROGGS I'm not sure I remember correctly
(as always)
JimmyZ not sure about it, seems that nqp uses readline 15:18
jnthn FROGGS: Yes, that's exactly it.
JimmyZ: The readlineint op in Moar is currently mapped to a normal readline instead 15:19
JimmyZ I don't think so 15:21
I mean the libreadline 15:22
btyler I'll be happy to test that on osx - I certainly had the infinite ">\n" problem
JimmyZ hmm, I don't know why nqp repl is using lib-readline on my linux box 15:24
jnthn JimmyZ: Yeah, I meant "just uses syncfile.c" or whatever 15:25
I'm not sure there's a codepath that can reach the libreadline or linenoise code today 15:26
dalek arVM: 0552364 | jnthn++ | src/core/nativecall. (2 files):
Expose functions to make C[Array|Pointer|Struct].
 15:31
arVM: 63fc411 | jnthn++ | src/6model/reprs/CArray.c:
Fix missing REPR mark function in CArray.
arVM: 45e1e0d | jnthn++ | src/6model/reprs/CArray.c:
atpos of CStruct/CArray/CPointer in CArray.
jnthn Up to 9 passing tests in 05-arrays.t now. 15:33
JimmyZ nice 15:35
jnthn And the next one blocks on CStruct getting better :) 15:36
JimmyZ get attr 15:37
jnthn Right.
dalek arVM: 076ab4c | jnthn++ | src/6model/reprs/CStruct.c:
Implement numeric case of CStruct attr lookup.
 15:57
arVM: 10d08e1 | jnthn++ | src/6model/reprs/CStruct.c:
Missing GC mark of CStruct REPR data members.
arVM: f74ca9d | jnthn++ | src/6model/reprs/CStruct.h:
Remove unused field.
arVM: cfac7eb | jnthn++ | src/6model/reprs/P6 (4 files):
Fix storage of sized int/num types.
 16:27
jnthn Passing first 4 of 06-struct.t now. 16:28
And 19 out of 26 of 05-array.t 16:29
FROGGS O.o 16:35
That Is NiceĀ® 16:36
dalek arVM: 00123d7 | jnthn++ | src/ (2 files):
Handle C[Struct|Array|Pointer] CStruct fields.
 16:46
arVM: 13d7493 | jnthn++ | src/6model/reprs/CStruct.c:
Cleanup, missing barrier, add sanity checks.
 17:26
17:30 woolfy joined 17:33 woolfy left
timotimo (o/ 18:21
\o)
(kermit arm flail emoticon) 18:22
18:24 FROGGS joined 18:33 tgt joined
jnthn If anybody fancies building latest Moar/NQP/Rakudo and trying out the NativeCall test suite, that'd be great. To see how it's progressing on other platforms :) 18:39
dalek arVM: 911dd19 | jnthn++ | src/6model/reprs/CStruct.c:
Hack to avoid crashes.

Really obscure ones. Maybe on another platform we get some better info on why uncommenting this causes issues.		 18:43
jnthn Dinner time; after it I'll look at 07-writebarrier.t. 18:44
18:53 zakharyas joined
nwc10 I guess ~/Sandpit/moar-g/bin/perl6-m -Ilib t/01-argles 19:03
s.t
0: Big shouty lines about "/bin/sh: PREFIX: command not found" but this does not cause failures 19:06
0.5: t/01-argless.t
is missing a terminating newline in its output
t/02-simple-args.t SEGVs 19:11
but valgrind reports errors on -e0
so all bets are off
(dynamic linking)-- # I have no line numbers 19:13
yes, technically this is the toolchain's fault
retupmoca Terminal dump of my results on 64bit linux: gist.github.com/retupmoca/00328e01ee438ee94126 19:19
nwc10 that was what I got 19:20
bollocks. Configuring MoarVM with --static breaks the Rakudo build
19:54 colomon joined
nwc10 OK. tried on a debian box. Same frustrations as the CentOS box 19:54
paste.scsys.co.uk/325137
but NO LINE NUMBERS :-(
and --db-attach=yes fails
I suspect that libuv is doing something evil to STDIN, but that's a WAG and therefore wrong 19:55
but whatever is doing whatever, it's annoying
because it stops my plan B to get line numbers.
jnthn The results seem to match my ones 19:58
02 segfaults here also
The interesting thing is what the failure mode is, if any, with 911dd19 reverted
dalek arVM: ca7996f | jnthn++ | src/core/nativecall.c:
Implement nativecall write barriers.
 20:26
nwc10 aaaaaaaaaaaaaaaaaaaaaaaaaaaaargh. Even with ASAN under gdb no $expletive line numbers. 20:27
so, sigh. There is a BUG.
but other crap is getting in the way of being able to find it 20:28
jnthn urgh
nwc10 yes
jnthn The debugger here doesn't get upset over the dynamic loading...
nwc10 neither valgrind nor gdb get line numbers from libmoar.so
my suspicion is that it doesn't have debugging info in it 20:29
jnthn Do they normally for you?
nwc10 this is a good question. I rarely build perl 5 that way
jnthn Is it specific to when running code with nativecall?
nwc10 no
./perl6-m -e0 has the bug
jnthn As in, no line numbers in valgrind?
nwc10 as in, valgrind reporting a read beyond an allocated region, and not giving line numbers 20:30
jnthn oh hang on
nwc10 I haven't even *got* back to the SEGV
jnthn I think we're talking about two different bug hunts...
nwc10 yes.
jnthn d'oh :)
nwc10 I'm not going to even try to read the valgrind report on the zavolaj problems until the earlier valgrind stuff is cleared up 20:31
because I have no clue what screwed up what
and the nasal demons are already painful enough
jnthn Hmmm... MVM_args_proc_to_callsite eh. 20:32
I fixed a memory leak involving that a week or two ago, I think.
nwc10 with that commit reverted NQP and Rakduo pass tests 20:41
t/02-simple-args.t still goes SEGV 20:42
gdb says:
#0 0x00007ffff79e1762 in MVM_string_equal () from /home/nick/Sandpit/moar-g/lib/libmoar.so
#1 0x00007ffff79e5314 in MVM_string_find_encoding () from /home/nick/Sandpit/moar-g/lib/libmoar.so
#2 0x00007ffff79c26b9 in set_str () from /home/nick/Sandpit/moar-g/lib/libmoar.so
#3 0x00007ffff7955a5b in MVM_interp_run () from /home/nick/Sandpit/moar-g/lib/libmoar.so
#4 0x00007ffff79f741f in MVM_vm_run_file () from /home/nick/Sandpit/moar-g/lib/libmoar.so
#5 0x0000000000400e01 in main ()
jnthn nwc10: gist.github.com/jnthn/619fb15326bebd9dc250 20:43
nwc10: Try that for the args thingy
nwc10: Yes, 02 fails either way...I know what one is still to fix.
nwc10: It's 05/06 that blew up here with that commit reverted. 20:44
nwc10: And pass with it.
nwc10 ah OK. Having a rebuild with different debugging options.
"there will be a short delay"
jnthn nwc10: np, I've plenty to do here ;) 20:45
nwc10 ooh, PEBKAC 20:50
don't use --debug=1 20:51
your SEGV in 02 is:
(gdb) where
#0 0x00007ffff79e1666 in MVM_string_equal (tc=0x6024f0, a=0x0, b=0x1cac428) at src/strings/ops.c:610
#1 0x00007ffff79e520c in MVM_string_find_encoding (tc=0x6024f0, name=0x0) at src/strings/ops.c:1561
#2 0x00007ffff79c25d1 in set_str (tc=0x6024f0, st=0x49adfe0, root=0x7ffff68eb8c0, data=0x7ffff68eb8d8, value=0x589f510) at src/6model/reprs/CStr.c:57
#3 0x00007ffff7955a52 in MVM_interp_run (tc=0x6024f0, initial_invoke=0x7ffff79f71d7 <toplevel_initial_invoke>, invoke_data=0x661f10) at src/core/interp.c:2358
#4 0x00007ffff79f730f in MVM_vm_run_file (instance=0x602010, filename=0x7fffffffeca9 "/home/nick/Sandpit/moar-g/languages/perl6/runtime/perl6.moarvm") at src/moar.c:153
#5 0x0000000000400e01 in main (argc=7, argv=0x7fffffffe948) at src/main.c:146
jnthn Hmmm.
jnthn looks 20:52
nwc10 t/05-arrays.t and t/06-struct.t are (I think) unchanged.
No crash, fewer tests than planned
I can haz line numbers 20:53
--debug=1 is bogus :-(
jnthn I think the 1 sets some kind of "level"
The fewer tests than planned disappears under prove
Thing is that the tests from C land say "ok" but without a number
That seems legal TAP 20:54
But Rakudo's Test.pm likes to warn that *it* didn't see enough tests.
nwc10 the report for just -e0 paste.scsys.co.uk/325168
I see
jnthn nwc10: Is that with the patch I just provided, or before it? 20:55
nwc10 anyway, not sure if it's legal TAP to have bad counts
jnthn Yeah. prove happily copes, though, it seems...
nwc10 it's for rakudo at 4a3a406840ba87da7d10ccb1d8dbcf6e132d26ba, nqp at 4a3a406840ba87da7d10ccb1d8dbcf6e132d26ba, MoarVM at 911dd19ce8a566b6eca98fdb70a09f6e16420e2e plus 911dd19ce8a566b6eca98fdb70a09f6e16420e2e reverted 20:56
I'm not sure what answer you needed
jnthn < jnthn> nwc10: gist.github.com/jnthn/619fb15326bebd9dc250
Trying that fix for the valgrind issues on -e0
nwc10 that patch cures all valgrind issues for -e0 20:58
will now go back to HEAD/HEAD/HEAD, add it and test
jnthn arrrghh...set_str fail 20:59
Dear everybody, you can NEVER EVER EVER EVER invoke user-land code within a REPR function. 21:00
nwc10 not even Chuck Noris would get away with this?
jnthn Well, Chuck Norris can probably handle the resulting SEGV... 21:01
nwc10 mmm, maybe Chuck Norris is secretly a VAX. 21:02
jnthn: is it possible to enforce that? Is there a way to have a "DEBUGGING" build that tracks state and abort()s on such an invoke attempt? 21:04
if it is possible, is it worth it?
jnthn nwc10: tbh, if you do it you're so likely to ruin the interpreter state anyway... 21:05
nwc10 patch at gist.githubusercontent.com/jnthn/6...tfile1.txt works
NQP and Rakudo pass tests
jnthn nwc10: though the rest of the VM may actually be robust enough to let you sort-of surive it... 21:06
nwc10 By abort() I meant abort()
jnthn Yeah. It's not too easy to detect it's happening, tbh.
nwc10 "exit, coredump, you know about it" sort of thing
oh :-(
jnthn Very easy to spot by reading the code, though.
I suspect you typically end up writing to a bit of the C stack 21:07
But the VM typically runs very shallow, so you might be too shallow for it to matter when it all goes wrong.
nwc10 valgrind report for t/02*.t now starts with this just after ok 9: 21:09
==15590== Use of uninitialised value of size 8==15590== at 0x4F96C91: MVM_repr_get_str (reprconv.c:216)
==15590== by 0x4FB6A62: set_str (CStr.c:57)
==15590== by 0x4F49A7D: MVM_interp_run (interp.c:2358)
==15590== by 0x4FEB796: MVM_vm_run_file (moar.c:153)==15590== by 0x400E00: main (main.c:146)
==15590==
jnthn yeah, I've got a nearly-done re-write of all that code
nwc10 OK.
but good news is that it's clean to that point
so it's back to being a useful tool
nwc10 applies gist patch and tries with ASAN 21:11
"to the pain"
jnthn Whee. Bye bye SEGV, it seems... 21:24
nwc10 paste.scsys.co.uk/325179 makes valgrind unhappy, but it sort of looks like it's what the test is trying to do
OK, all Rakudo build and tests pass with ASAN after that patch 21:25
dalek arVM: 6ca39c9 | jnthn++ | src/6model/reprs/CStr. (2 files):
Fix CStr REPR.
 21:27
arVM: 7086858 | jnthn++ | src/core/nativecall.c:
Add CStr handling to string marshal code.
arVM: d517939 | jnthn++ | src/core/args.c:
Copy correct size of arg flags buffer.

Fixes error discovered by nwc10++ and makes Valgrind clean again.		 21:29
21:54 flussence joined
nwc10 paste.scsys.co.uk/325196 -- unhappiness on 32 bit linux 22:15
x86, hence little endian
22:18 colomon joined
nwc10 r: printf "%x\n", 911352958828937218 22:20
camelia rakudo-parrot a2db06, rakudo-jvm a2db06: OUTPUTĀ«ca5c6b000000002ā¤Ā»
..rakudo-moar a2db06: OUTPUTĀ«ca5c6b000000000ā¤Ā»
nwc10 that would be a MoarVM bug
and it's ca5c6b000000002, expected 2
similar for the other wrongness in t/05-arrays.t 22:21
top 32 bits are garbage
size issue?
22:23 jnap joined
nwc10 valgrind is like an explody thing on 06...t 22:24
paste.scsys.co.uk/325200
jnthn nwc10: "just" on 32-bit?
nwc10 yes. 22:25
64 bit x86_64 systems are 100% happy
jnthn What is sizeof(long)?
nwc10 on that machine, 4
jnthn oh hmm.
nwc10 bog standard x86 Linux
jnthn Right.
So the thing I ran and worked around on Windows earlier needs a general solution. 22:26
nwc10 "upgrade everyone to Win 8.1, er, x86_64"? :-)
since 2006 "get a Mac" won't work, as they're no longer PPC 22:27
general solution is "go to bed, use a fresh head tomorrow" ?
jnthn Well, it's mostly that we need a way to convey what "long" is 22:28
(stash it in configuration or so) 22:29
dalek arVM: 42be074 | jnthn++ | / (2 files):
Reference and install dyncallback header.
 22:43
arVM: b6e4a61 | jnthn++ | src/ (3 files):
Add data structure for representing a callback.
arVM: b9b540d | jnthn++ | src/gc/roots.c:
GC marking for callback cache.
 22:51
arVM: 2546910 | jnthn++ | src/ (3 files):
Implement callback setup work.

Gets us to the point of having a dyncallback callback object to pass, which then does get invoked by the C function we called. For now, it does nothing, however.
arVM: 0dde848 | jnthn++ | src/core/nativecall.c:
Basic callback invocation with arguments.
 23:39
timotimo want me to try zavolaj with moarvm now? :) 23:43
jnthn timotimo: Gimme a little more time :) 23:44

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!