|
02:48
ilbot3 joined
|
|||
| Geth | arVM: e167934e83 | TimToady++ | src/6model/reprs/NFA.c Allow for fate offsets when unique fates in use Prior to this, fates were always numbered starting with 1 for protos and starting with 0 for alts. We are moving to a model in which all fate numbers are unique across the process. Every NFA now knows its own range of fates, in the range of fbeg ..^ fend. Most of this is handled in nqp, but MoarVM has to know about fate offsets for dealing with the results of alts. Conveniently, for both protos and alts, the 0th fate name entry was already unused and set to 0, so we encode the new fbeg and fend into the 0th fate name. (For alts, these fate names were set to 0,1...*, and the array was only used by MoarVM to determine how many different fates might be returned. But importantly, ... (2 more lines) |
03:31 | |
| diakopter | TimToady: lolwut | 03:42 | |
| Geth | arVM: d197cf0822 | TimToady++ | src/6model/reprs/NFA.c clean out ancient "remove after rebootstrap" line This could've gone away a long time ago already. |
04:50 | |
|
08:07
domidumont joined
08:10
FROGGS joined
08:13
domidumont joined
12:22
TimToady joined
12:51
Geth joined
14:03
zakharyas joined
14:36
domidumont joined
14:45
domidumont joined
|
|||
| dogbert17 | any ideas why | 14:56 | |
| ignore that comment | |||
| where should I put a breakpoint in order to catch the following message? | 14:57 | ||
| *** Error in `/home/dogbert/repos/rakudo/install/bin/moar': malloc(): smallbin double linked list corrupted: 0xb5381484 *** | |||
| Aborted | |||
| Geth | arVM: MasterDuke17++ created pull request #500: Fix typo in comment |
15:09 | |
| arVM: MasterDuke17++ created pull request #501: Fix warnings during compile |
15:12 | ||
| arVM: MasterDuke17++ created pull request #502: Fix order of args in mvm callocs |
15:15 | ||
| arVM: b988616ea2 | MasterDuke17++ | src/6model/reprs/SCRef.h Fix typo in comment |
15:45 | ||
| arVM: 1fd5d64973 | niner++ | src/6model/reprs/SCRef.h Merge pull request #500 from MasterDuke17/fix_typo_in_SCRef.h Fix typo in comment |
|||
|
15:48
zakharyas joined
|
|||
| Geth | arVM/master: 4 commits pushed by niner++ | 15:48 | |
|
15:57
zakharyas joined
|
|||
| dogbert17 | jnthn: wrt the second part of RT #128833, does the following gist provide any useful information? gist.github.com/dogbert17/6deb8bdd...e7bbfa477c | 18:14 | |
| timotimo | when you get "double linked list corrupted", it's already too late | 18:19 | |
| you need something like valgrind or asan to make the code explode the moment it does an incorrect write to corrupt that datastructure | 18:20 | ||
| dogbert17 | timotimo: so the SEGV is to late in this case then? | 18:21 | |
| timotimo | it's not a segv, it's an abort most likely | 18:23 | |
| but yeah, it's too late | 18:24 | ||
| dogbert17 | are you looking at the gist or my earlier comment from a few hours ago? | 18:25 | |
| timotimo | looking at the gist now | 18:27 | |
| not very helpful, no :( | |||
| you're doing something multithreaded in that code? | 18:36 | ||
| dogbert17 | :( | ||
| code is here: rt.perl.org/Public/Bug/Display.html?id=128833 | |||
| timotimo | 2016? that's already a year old! :P | 18:37 | |
| dogbert17 | indeed, it's getting harder and harder to find new ones :-) | ||
| timotimo: do you know how to enable ASAN? | 18:40 | ||
| timotimo | yeah, just give --asan to moarvm's Configure.pl and make install again | 18:42 | |
| dogbert17 | cool, will try that since using valgrind will take forever | 18:43 | |
| jnthn | I suspect there'll be some dodgy code-gen somewhere that means a hash gets shared between threads where it shouldn't. | 19:00 | |
| The Perl 6-level stack trace will probably tell us which hash | 19:01 | ||
| timotimo | something like that, yeah | ||
| jnthn | Then we can audit its use locations and look at code-gen some | ||
| Oh, the cross-thread write logging is also useful for these and make cut out the audit step :) | |||
| dogbert17 | hmm, ==20137== ERROR: AddressSanitizer: SEGV on unknown address 0x0000000c (pc 0xb57f3626 sp 0xa3577dc0 bp 0xa3577e48 T1) | 19:17 | |
| timotimo | whoops :) | 19:18 | |
| dogbert17 | that was on the 4th attempt to run the program in loop 15 times | 19:19 | |
| timotimo | doesn't seem like a useful explosion | 19:20 | |
| dogbert17 | no, it did provide some info but it almost seems that there is no debug info available, see gist.github.com/dogbert17/8d728478...ea4269da38 | 19:22 | |
| here's my configure cmd: perl Configure.pl --no-optimize --debug --asan --prefix=/home/dogbert/repos/rakudo/install/ | 19:23 | ||
| timotimo, jnthn: I might finally have gotten something: gist.github.com/dogbert17/8d728478...ea4269da38 | 19:36 | ||
|
20:43
Ven joined
|
|||
| dogbert17 | I have updated the gist above again, it now contains everything logged by ASAN and MVM_CROSS_THREAD_WRITE_LOG | 20:55 | |
|
20:58
lizmat joined
|
|||
| samcv | jnthn, do we care about the Unicode database being small ( as a c file ), or only care about its final compiled size | 21:43 | |
| timotimo | as long as it doesn't cause the compler to take minutes to compile it, i think having a bigger .c file doesn't matter | 21:54 | |
| samcv | ok cool | ||
| timotimo | we can't get much worse than interp.c on clang | 21:55 | |
| moritz | [X] challenge accepted! | 21:59 | |
| lizmat | .oO( same for me, but more like X challenge accepted :-) |
22:00 | |
| as I'm working on speeding up infix:<X> atm | |||
| timotimo | nice! | ||
| jnthn | samcv: Compiled output size is the more important of the two by a good way | 22:49 | |
| samcv | yeah. i mean i have a 12MB text file compiling to 8.5K | ||
| right now | |||
| jnthn | samcv: With the "don't blow up the compiler" caveat :) | ||
| samcv | yeah | ||
| timotimo | not going to be able to compile moarvm on my n3ds, i don't think | 22:50 | |
| jnthn | Well, on the one hand CORE.setting needs a bit over a gig to compile | ||
| On the other, you can build that on another box and ship it onto a smaller machine, provided MoarVM is a sensible build. | 22:51 | ||
| timotimo | of course | 22:52 | |
| i'm not sure anybody wants to port libuv to the n3ds :) | |||
| jnthn | Oh the other issue is that we check the generated C source into git | ||
| Because it only needs regenerating very occasionally | 22:53 | ||
| Not to mention you'll need a Perl 6 to regenerate it :P | |||
| timotimo | you can at least have threads, the device has 4 cores, one is nommed up by the OS | ||
| jnthn | But git compresses stuff on the wife. | ||
| uh | |||
| on the wire | |||
| timotimo | other than that, the n3ds is so memory-starved that you won't be running rakudo on it | 22:56 | |
| not to mention the CPU is quite weak | |||
| well, it has two CPUs, but the other one is much less likely to run anything moarvmy | |||
| jnthn | aye :) | 22:57 | |
| timotimo | it doesn't have bluetooth so if you wanted to REPL or code-edit on the go with it ... tough luck, use the stylus on the touchpad :) | 22:59 | |
| jnthn | :) | 23:00 | |
| Time to rest up for whatever the next week decides to throw at me. :-) | |||
| 'night | |||
| timotimo | gnite jnthn | 23:01 | |
| 804 MHz ARM11 MPCore quad-core + extra weaker single-core (one reserved for OS)[citation needed] | 23:03 | ||
| 256 MB (64MB dedicated to the OS), 10 MB VRAM | 23:04 | ||
| lizmat | night jnthn | ||
| timotimo | i *thought* you could clock the arm11 core up to almost 1ghz | 23:11 | |
| but the 804 MHz is apparently the upper limit | 23:16 | ||
| which is absurdly low-power, even for a mobile gaming device that's meant to just be a slight upgrade for a device 5 years old | |||