Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-09-08

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:24 samcv i almost forgot how many of the libs i made for the unicode database rewrite that ended up being used for the collation arrays stuff now that i'm working on integrating it into moarvm codebase
00:24 samcv neat
01:55 ilbot3 joined #moarvm
01:55 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
01:58 geekosaur joined #moarvm
02:43 geekosaur joined #moarvm
05:08 brrt joined #moarvm
05:14 brrt good * #moarvm
05:28 tartal joined #moarvm
06:12 brrt joined #moarvm
06:26 leont joined #moarvm
07:35 leont joined #moarvm
08:05 domidumont joined #moarvm
08:06 zakharyas joined #moarvm
08:18 dogbert2 joined #moarvm
08:31 jnthn morning o/
09:01 zakharyas joined #moarvm
09:07 AlexDaniel joined #moarvm
09:27 brrt morning jnthn
09:31 zakharyas1 joined #moarvm
09:42 ggoebel joined #moarvm
09:49 zakharyas joined #moarvm
09:51 Skarsnik joined #moarvm
10:11 dogbert17_ joined #moarvm
10:17 Voldenet joined #moarvm
10:17 Voldenet joined #moarvm
10:28 stmuk_ I think moar is broken on windows -- "Unhandled exception: Unable to allocate an array of 8 elements"
10:29 jnthn Weird. Sounds like a job for bissect.
10:32 stmuk_ ok I'll try once virtualbox windows updates ok
10:33 jnthn Yeah, I can't guess where that mighta come from...
10:33 jnthn It looks like an out of memory error but...8 elements ain't much
10:33 jnthn And why would it be out of memory, etc.
10:34 timotimo the calculation for how many elements we're allowed to allocate could just be bogus in some corner case
10:34 jnthn Ah, ok
10:36 Skarsnik Does Moar know how much total memory is allocated?
10:36 Skarsnik for the thing he allocated I mean
10:36 timotimo it asks for that value to figure out when a gen2 gc is appropriate
10:37 timotimo https://github.com/MoarVM/MoarVM/blob/master/src/6model/reprs/VMArray.c#L350 - stmuk_ can you attach a debugger and break on this exception throw?
10:48 timotimo https://github.com/MoarVM/MoarVM/pull/577/files - it'd still be awesome if this could land soon-ish :S
10:49 Skarsnik hm?
10:49 timotimo a pull request from long, long ago
10:50 timotimo bringing a feature that's very, very nice
10:50 Skarsnik to be able to bind struct s[]; ?
10:51 timotimo something like that yeah
10:51 Skarsnik nativecallable6, struct s {char *a;}; extern struct s foo[];
10:51 nativecallable6 Skarsnik, class s is repr('CStruct') is export {␤ has Str $.a; # char* a␤}␤our $foo is export = cglobal(LIB, "foo", CArray[s]);
10:52 timotimo it'll have to be CStructArray i assume
10:52 timotimo otherwise we'd have to force all of the ecosystem to rewrite code to have CArray[Pointer[s]] instead
10:52 Skarsnik dunno, why a special type?
10:53 timotimo otherwise suddenly things would behave completely differently
10:53 Skarsnik nativecallable6, struct s {char *a;}; extern struct s foo[]; extern struct s* foo[]
10:53 nativecallable6 Skarsnik, https://gist.github.com/78af5d5300898452968a6a5ea7128cee
10:53 Skarsnik nativecallable6, struct s {char *a;}; extern struct s foo[]; extern struct s* foo[];
10:53 nativecallable6 Skarsnik, https://gist.github.com/27bba45606df0dc0d2464379c429d6fb
10:54 Skarsnik nativecallable6, struct s {char *a;}; extern struct s foo[]; extern struct s* foo2[];
10:54 nativecallable6 Skarsnik, class s is repr('CStruct') is export {␤ has Str $.a; # char* a␤}␤our $foo is export = cglobal(LIB, "foo", CArray[s]);␤our $foo2 is export = cglobal(LIB, "foo2", CArray[s]);
10:54 Skarsnik right
10:54 timotimo yeah
10:54 timotimo we can't really have a transition period for switching both around, can we?
10:55 Skarsnik I think it could be worth to check if people use this form
10:59 Skarsnik I think a better question: is there a test that rely on this?
11:01 timotimo you remember testshellmem.p6?
11:02 Skarsnik https://github.com/rakudo/rakudo/blob/nom/t/04-nativecall/05-arrays.t#L79
11:02 Skarsnik hm
11:03 Skarsnik not really ^^
11:04 timotimo https://gist.github.com/Skarsnik/6adfba55ff9b0d179a8ffee923112393
11:04 Skarsnik ohh this
11:04 Skarsnik well it show the virtual memory not the resident
11:05 timotimo oh, that's a thing.
11:05 timotimo anyway, if you run it more than just once, for example 5 times, you'll see it plateau after just a few runs
11:06 Skarsnik Yeah it grows up to 300Mb for me and stop growning
11:06 timotimo https://gist.github.com/timo/6a6550b8eac823d3ac47a0728e4ff3cb - check it
11:06 dogbert2 stmuk_, jnthn: dunno if it's related but the array allocation check was changed with commit https://github.com/MoarVM/MoarVM/commit/f9b65a9e37979ab39fd1283a65ad4e1351ca6058 in order to fix an  RT
11:07 timotimo 263 megs of maxrss for me
11:07 timotimo let's see how it goes without force_gc
11:08 Skarsnik I think jnthn explained that it was since proc:async create a thread it take virtualy like 8Mb of memory
11:08 Skarsnik for the thread
11:08 Skarsnik timotimo, if you have an updated l:p:s you can replace the mem call with like get-statm-human.perl
11:09 timotimo i do
11:11 timotimo wow, it really doesn't have to spawn these threads though
11:12 timotimo these threads should totally already be free for more work the moment new work is asked for
11:14 Skarsnik *need to start a game to free some ram*
11:21 * timotimo puts some debug info into the ThreadPoolScheduler
11:22 Skarsnik https://rt.perl.org/Ticket/Display.html?id=131003 hm this leak I think, each pass make the process grow in memory
11:22 Skarsnik (aside from crashing after while)
11:23 Skarsnik maybe it's related
11:23 timotimo i'm still convinced that's a user error there
11:24 timotimo probably a problem in the binding
11:28 timotimo i think i found a mistake in the calculation for "do we need more threads"
11:31 timotimo i don't understand why asking the scheduler for its queue would always start a new thread unconditionally (except if the thread limit is already reached)
11:34 Skarsnik timotimo, dunno, I checked the binding lot of time and I respect what the C lib expect and the C lib handle its memory alone, you never have to free stuff it give you, you call a function when it's done and it do it
11:36 Skarsnik The only thing I don't trust from NC is cglobals/extern https://github.com/Skarsnik/perl6-gumbo/blob/master/lib/Gumbo/Parser.pm6#L56 I hope this var is never messed by Moar
11:36 timotimo OK, then what causes the destroy function to be called?
11:36 Skarsnik I call it manually
11:36 timotimo and somehow you use the result again afterwards?
11:37 Skarsnik result?
11:37 timotimo something gets nativecall_refresh called on it
11:38 Skarsnik I mean the gist is : gumbo_parse(my_html); parse the tree and construct p6 XML tree; gumbo_destroy;
11:38 timotimo like a cstruct or something that was passed in some call
11:38 timotimo can you figure out what nativecall is invoked where it does the invalid read of size 8?
11:38 timotimo i think telemeh has something to print that out?
11:39 timotimo anyway, the thread run thingie now only spawns up to 4 threads
11:39 timotimo i hope this doesn't deadlock in spec tests or something
11:40 Skarsnik hm do I need to do something to run valgrind?
11:40 timotimo perl6-valgrind-m does it for you
11:41 timotimo telemeh is nonblocking, though. results will appear a bit after they have happened
11:41 timotimo and since valgrind serializes threads, you might wait for a long time before it outputs the thing
11:42 Skarsnik I hate this bug, because I try to reproduce on my 32 bit VM on a Moar where I printf every NC_invoke it does not crash xD
11:44 timotimo 32bit VMs are terrible, clearly
11:45 Skarsnik good changing the website fetched it crash faster
11:47 timotimo a whole bunch of tests were failing because ThreadPoolScheduler was outputting stuff on stderr ...
11:49 Skarsnik timotimo, btw I changed https://github.com/MoarVM/MoarVM/blob/master/src/core/nativecall.c#L761 libefence was crashing on this. I think there was a * too much x)
11:51 timotimo which * did you throw out?
11:52 Skarsnik I changed it to cptr = (void*)((uintptr_t)storage + (uintptr_t)repr_data->struct_offsets[i]);
11:53 Skarsnik the uintptr_t are here after reading a bit of https://www.securecoding.cert.org/confluence/display/c/INT36-C.+Converting+a+pointer+to+integer+or+integer+to+pointer
11:58 Skarsnik (still running with efence) weird thing before changing this line I had some mmap error (that were uncatched since it did not crash?) but they disapeared
11:58 Skarsnik maybe I mess up this function x)
12:00 Skarsnik it's annoying, each iteration take more time that the previous one when running this in valgrind :(
12:01 timotimo mhm
12:05 Skarsnik and of course it does not crash as fast as without it x)
12:06 timotimo #      got out: "start\nstart\nstart\nstart\nend\nend\nstart\nstart\nend\nend\nstart\nstart\nend\nend\nstart\nend\nend\nend\n"
12:06 timotimo # expected out: "start\nstart\nstart\nstart\nstart\nstart\nstart\nstart\nstart\nend\nend\nend\nend\nend\nend\nend\nend\nend\n"
12:07 Skarsnik the thread test?
12:08 timotimo yeah
12:08 Skarsnik I love how memory grow show in stuff like valgrind
12:08 Skarsnik {data => 640.672 kB, dirty => 0 kB, lib => 0 kB, resident => 557.464 kB, share => 21.804 kB, size => 695.312 kB, text => 2.808 kB}
12:08 Skarsnik 41
12:08 Skarsnik {data => 649.928 kB, dirty => 0 kB, lib => 0 kB, resident => 563.308 kB, share => 21.808 kB, size => 704.568 kB, text => 2.808 kB}
12:08 Skarsnik 42
12:08 Skarsnik {data => 650.760 kB, dirty => 0 kB, lib => 0 kB, resident => 568.696 kB, share => 21.808 kB, size => 705.400 kB, text => 2.808 kB}
12:08 timotimo i must have totally messed up the scheduler with my naive ideas
12:11 timotimo "only start a new thread if there's less than 1 idle thread"
12:11 timotimo is what i thought
12:11 timotimo before my change to one thing it was "start a new thread if there's enough free threads"
12:12 timotimo which i thought was wrong
12:12 timotimo but there were other operations that called "maybe_new_thread" and i'm pretty sure at least some of them are not useful in the slightest
12:12 timotimo the number of loads is not what i expected here
12:14 [Coke] I just did a git pull on rakudo, reconfig'd and moarvm built ok. was it a master-only issue?
12:15 [Coke] (for the windows thing)
12:15 timotimo no clue :(
12:15 stmuk_ I was mistaken moar.exe builds .. the error is in NQP it seems
12:15 timotimo probably?
12:15 timotimo moar doesn't execute moar while it builds
12:16 timotimo and the error you're getting is one you can only get if you're executing moar bytecode
12:16 * [Coke] reconfig's with master/master
12:16 timotimo i see what's wrong
12:17 Skarsnik timotimo, I just have a summarized leak report for valgrind. probably not useful?
12:17 Skarsnik ==6682==    definitely lost: 5,022,912 bytes in 131,826 blocks
12:17 Skarsnik ==6682==    indirectly lost: 27,800 bytes in 782 blocks
12:17 timotimo not useful, no. we need the invalid read
12:17 timotimo so my code makes the mistake of assuming $!loads is accurate enough to plan ahead
12:18 timotimo but there's a time span between "should i spawn a new thread to handle this task?" and "the thread has started up, grabbed the work, and increased the $!loads accordingly"
12:18 Skarsnik what could I give to valgrind to be more useful?
12:18 [Coke] c:\users\user\rakudo\nqp\moarvm\src\strings\parse_num.c(265) : warning C4715: 'parse_simple_number': not all control paths return a value
12:18 [Coke] c:\users\user\rakudo\nqp\moarvm\src\strings\parse_num.c(265) : warning C4715: 'parse_simple_number': not all control paths return a value
12:18 [Coke] oops
12:18 [Coke] c:\users\user\rakudo\nqp\moarvm\src\strings\parse_num.c(265) : warning C4715: 'parse_simple_number': not all control paths return a value
12:18 [Coke] ... this cut and past thing is proving problematic. :)
12:19 [Coke] src\profiler\heapsnapshot.c(823): warning C4293: '<<': shift count negative or too big, undefined behavior
12:19 [Coke] \o/
12:20 [Coke] (small victories)
12:20 [Coke] I was able to build with --gen-nqp=master and --gen-moar=master on win64 with strawberry perl and msvc.
12:20 [Coke] er, s/build/config/
12:21 [Coke] (running nmake now)
12:24 [Coke] nmake test: the cpp nativecall tests failed, but that's it
12:24 timotimo cool i think i have a properer ThreadPoolScheduler pool size handling thingie now
12:32 timotimo jnthn: wanna review a change i made to the ThreadPoolScheduler? :)
12:32 timotimo i'm almost done with a spectest run
12:33 timotimo aha! spec tests green!
12:34 Skarsnik ^^
12:34 stmuk_ I still get the array error with --gen-nqp=master and --gen-moar=master on strawberry perl
12:34 stmuk_ there was another report of this error with windows as well (which is why I tried it)
12:34 [Coke] stmuk_: what compiler?
12:35 [Coke] (works fine with strawberry perl + msvc2017 here)
12:35 stmuk_ gcc version 4.9.2 (x86_64-posix-sjlj, built by strawberryperl.com project)
12:36 timotimo Skarsnik: check out the rakudo branch economic_thread_pool_scheduler
12:38 timotimo hm, it still spawns more threads than i'd hoped for
12:39 * [Coke] can't even start a build with gcc, it seems. moar detection dies immediately
12:40 stmuk_ [Coke]: which gcc?
12:40 [Coke] whatever sperl installed; ... ah. had to get clean -xdf rakudo/nqp and moarvm to get rid of previous build cruft, apparently.
12:41 stmuk_ sperl installs different versions depending on its own version
12:41 timotimo aha, found my mistake
12:43 stmuk_ bbl
12:44 [Coke] gcc (x86_64-posix-seh, Built by strawberryperl.com project) 7.1.0 -- yup, there's the error.
12:44 stmuk_ I couldnt get appveyor builds working with sperl gcc > 7.something
12:45 stmuk_ maybe appveyor problem dunno
13:02 timotimo hmpf. my attempt fails the sleepsort one looks like
13:04 timotimo who would have thought: the thing i thought would be easy is actually difficult!
13:12 AlexDaniel joined #moarvm
13:14 jnthn Scheduling *is* difficult :)
13:15 timotimo especially if you have to appease someone who wants sleepsort to work :D
13:16 * timotimo deleted the branch
13:19 brrt joined #moarvm
13:26 timotimo Skarsnik: i suggest you instantiate your own ThreadPoolScheduler and set its max threads to 2 or 3 :P
13:27 timotimo except you have to be careful because those are app-lifetime threads that won't be shut down when the TPS gets destroyed
13:40 brrt joined #moarvm
13:42 Skarsnik timotimo, I don't have the invalid read size http://www.nyo.fr/~skarsnik/tmp/valgrind.txt
13:47 dogbert2 jnthn: didn't you fix RT #132042 the other day or am I dreaming?
13:47 synopsebot6 Link:  https://rt.perl.org/rt3/Public/Bug/Display.html?id=132042
13:48 jnthn dogbert2: ugexe wrote a PR that probably does, I commented on it, maybe that feedback is already handled :)
13:49 dogbert2 aha, thx, just run the example a number of times and it seemed to work without a hitch
13:49 dogbert2 *ran
13:54 timotimo Skarsnik: that's something i've never seen before
13:55 dogbert2 timotimo: are you looking at the Gumbo bug?
13:55 timotimo not completely
13:56 timotimo i was looking through tabs i had kept open, one of them was the memory increase from the "run a shell command" thing
13:56 timotimo and i wanted to perhaps look closer at Log::Async
13:56 timotimo but i got sidetracked and lost
13:59 dogbert2 oh no
14:08 dogbert2 shouldn't we update libuv at some point?
14:09 brrt we should do so regularly, in fact
14:09 dogbert2 we're at 1.8 atm
14:09 timotimo yeah
14:09 timotimo we should
14:09 timotimo someone should :P
14:09 dogbert2 is it easy?
14:09 timotimo should be
14:10 dogbert2 I guess there's a place where we tell it which commit to use?
14:11 dogbert2 1.14.1 is the latest and greatest
14:11 timotimo you can cd into the folder it's in, pull and checkout something, then cd up and "git add" the folder as if it were a file
14:13 dogbert2 is that how it's usually done?
14:15 timotimo i think so
14:16 timotimo it's git submodules. they aren't intuitive until you learn what they are
14:18 dogbert2 brr, nothing for me then, at the very least I can check out the latest ver locally and run a spectest
14:19 * dogbert2 spectesting with libuv 1.14.1
14:20 dogbert2 timotimo: didn't you fight with submodules before?
14:21 Skarsnik submodule are kinda annoying, since they are tied to a commit on the subrepo
14:21 Skarsnik You can't say 'follow master on this'
14:24 dogbert2 FWIW, the latest libuv doesn't upset the spectests one bit :)
14:24 timotimo i did a very bad thing with submodules
14:25 timotimo there was a folder in the repo that had stuff in it. i later replaced that folder with a submodule. git was *not* allowing people to just "git pull" that change because "hey there's already a folder here where i'm supposed to put this submodule file thingie"
14:26 dogbert2 the last libuv merge was done by Bart W.
14:26 dogbert2 could that be brrt
14:27 timotimo yes
14:27 dogbert2 can we entice him to do it again :)
14:27 timotimo oh, you don't have to learn much about submodules, you just need to do what i told you :P
14:28 dogbert2 but it should be done in a PR I guess
14:28 timotimo sure
14:29 dogbert2 hmm, I could give it a shot I guess
14:30 timotimo cool
14:30 dogbert2 timotimo: "pull and checkout something", do you mean checkout master, pull and then checkout the 1.14.1 commit ?
14:31 timotimo hm, right, it might be a better idea to fetch instead of pull
14:31 timotimo submodules tend to be in "detached head" state
14:32 Skarsnik it's probably the same?
14:32 Skarsnik since the git add will tie it to the specific commit
14:32 timotimo git pull might complain that you're not on a branch
14:32 dogbert2 so 'git checkout master' followed by 'git fetch' and then 'git checkout b0f9fb2a07a5e6'
14:34 timotimo with the fetch you don't need the first checkout, but i suppose that'd work
14:35 dogbert2 then I'll do it, PR coming
14:55 Geth ¦ MoarVM: dogbert17++ created pull request #682: Bump libuv to ver. 1.14.1
14:55 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/682
14:55 * dogbert2 brrr
15:13 stmuk_ timotimo: https://gist.github.com/stmuk/365b6cd98ed3e3083a256680f2369128
15:14 timotimo can you go into the set_elems frame and print the relevant locals and the result of that expression it uses?
15:14 timotimo ssize, CHAR_BIT, elem_addr_size
15:23 stmuk_ something like "break set_elems" and "info frame"?
15:24 timotimo no, just "thread " the right thread and then up up up up up until you're in set_elems
15:27 geekosaur joined #moarvm
15:28 stmuk_ ok I'm in set_elems
15:29 timotimo you can only print one thing at a time, annoyingly
15:29 timotimo because of how the , operator in c works
15:34 stmuk_ https://github.com/MoarVM/MoarVM/blob/master/src/6model/reprs/VMArray.c#L455
15:35 stmuk_ I don't see ssize etc.
15:35 timotimo oh sorry
15:35 timotimo has to be set_size_internal
15:37 geekosaur joined #moarvm
15:43 stmuk_ arggg I can't single step due to no line information
15:43 stmuk_ I just compiled moar with --debug .. is there anything else I need?
15:45 brrt joined #moarvm
16:09 timotimo i tend to --debug=3, in order to have variables not say "value optimized out" all the damn time you should also --optimize=0
16:41 stmuk_ hmm I get full debug info on linux but not on windows .. must be the toolchain
16:42 timotimo we should be passing -g to the linker as well, that should keep debug symbols in the exe and dll files
16:43 Skarsnik can we have debug symbol in a separate file?
16:44 Skarsnik it's kinda handy in debien when you can just apt-get install lib-debug
16:44 Skarsnik to have the debug symbol
16:46 timotimo we can, yeah
16:56 zakharyas joined #moarvm
17:07 TimToady joined #moarvm
17:18 domidumont joined #moarvm
18:07 Geth ¦ MoarVM: 1396733271 | (Nick Logan)++ (committed using GitHub Web editor) | src/io/io.c
18:07 Geth ¦ MoarVM: Mark GC blocked when acquiring mutex
18:07 Geth ¦ MoarVM:
18:07 Geth ¦ MoarVM: Fixes: `perl6 -e 'my $foo = 0; for ^50000 { start { say $foo++ } };'`
18:07 Geth ¦ MoarVM:
18:07 Geth ¦ MoarVM: https://irclog.perlgeek.de/perl6-dev/2017-09-06#i_15127640
18:07 Geth ¦ MoarVM: https://rt.perl.org/Ticket/Display.html?id=132042
18:07 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1396733271
18:07 Geth ¦ MoarVM: 1de91704d7 | (Nick Logan)++ (committed using GitHub Web editor) | src/io/io.c
18:07 Geth ¦ MoarVM: MVMROOT remaining pointers to GC objects
18:07 Geth ¦ MoarVM:
18:07 Geth ¦ MoarVM: All pointers to garbage collected objects accessed after a GC triggering function must be rooted.
18:07 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1de91704d7
18:07 Geth ¦ MoarVM: 32322f3933 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/io/io.c
18:07 Geth ¦ MoarVM: Merge pull request #679 from ugexe/patch-1
18:07 Geth ¦ MoarVM:
18:07 Geth ¦ MoarVM: Mark GC blocked when acquiring mutex
18:07 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/32322f3933
18:08 Geth ¦ MoarVM: d05764fb83 | Mario++ (committed using GitHub Web editor) | src/6model/reprs/P6bigint.h
18:08 Geth ¦ MoarVM: MVM_IS_32BIT_INT(i) with explicit casts
18:08 Geth ¦ MoarVM:
18:08 Geth ¦ MoarVM: see also
18:08 Geth ¦ MoarVM: https://github.com/MoarVM/MoarVM/issues/594#issuecomment-326253445
18:08 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d05764fb83
18:08 Geth ¦ MoarVM: 1e735a8998 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/6model/reprs/P6bigint.h
18:08 Geth ¦ MoarVM: Merge pull request #671 from duke-m/patch-1
18:08 Geth ¦ MoarVM:
18:08 Geth ¦ MoarVM: MVM_IS_32BIT_INT(i) with explicit casts
18:08 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1e735a8998
18:15 Geth ¦ MoarVM/master: 5 commits pushed by MasterDuke17++, (Jonathan Worthington)++
18:15 Geth ¦ MoarVM/master: 4e70bed658 | Alloc proc read buffer based on amount last read
18:15 Geth ¦ MoarVM/master: af649435ce | Enforce minimum size in on_alloc
18:15 Geth ¦ MoarVM/master: a7debca86a | Make size check and bit-twiddling an if/else
18:15 Geth ¦ MoarVM/master: 2b7ecb92cb | Use existing next-power-of-two function, cygx++
18:15 Geth ¦ MoarVM/master: e70f8972b2 | Merge pull request #631 from MasterDuke17/smarter_on_alloc
18:15 Geth ¦ MoarVM/master: review: https://github.com/MoarVM/MoarVM/compare/1e735a8998...e70f8972b2
18:23 jnthn Well, at least a tad less behind on review now :)
18:25 dogbert2 jnthn: preparing an answer to your comment wrt https://github.com/MoarVM/MoarVM/pull/682
18:26 timotimo bleh, the mac builds aren't even starting for that pr
18:26 dogbert2 timotimo ?
18:27 timotimo it has been going for almost 4 hours now
18:27 timotimo 8 x 3 minutes + 3 more minutes for covering
18:27 timotimo and lots of waiting for the mac builds to start
18:27 dogbert2 is it Travis causing trouble?
18:27 timotimo no clue
18:28 [Coke] need a mac build on something?
18:30 timotimo no
18:30 timotimo well, we could use a test on mac
18:30 [Coke] any branch in particular?
18:31 dogbert2 it's a scary change, things work for me but I only have a 32 bit Linux to play with
18:31 timotimo Pull Request #682 Bump libuv to ver. 1.14.1
18:31 timotimo in dogbert17/update-libuv
18:32 dogbert2 the more people who tests the PR the better :)
18:33 [Coke] trying perl Configure.pl --backends=moar --gen-nqp=master --gen-moar=dogbert17/update-libuv in a fresh rakudo....
18:34 * dogbert2 hides
18:34 [Coke] ah, PR. slightly more complicated, will report back.
18:47 dogbert2 timotimo: you there?
18:59 Skarsnik *3h of crashgumbo.p6 with efence, only 14 iterations*
19:09 [Coke] dogbert2: ... work busy, will get to this tonight.
19:14 dogbert2 [Coke]: thx, realised that my own testing had been bogus so I had to redo it, still works for me though
19:16 dogbert2 my mistake was that I checked out the latest libuv into the 3rdparty/libuv dir and then promptly did 'perl Configure.pl  --debug  --prefix=<installdir>'
19:17 dogbert2 I failed to realise that perl Configure.pl syncs all submodules so I was back to ver 1.8 :(
19:23 timotimo dogbert2: i was grocery shopping
19:25 dogbert2 timotimo: what do you think about my nOoB mistake above :)
19:27 dogbert2 perhaps it would have been better if you or Brrt did this
19:28 timotimo i would probably have been bitten by the same thing
19:29 timotimo weird. configure.pl didn't revert the version on my machine
19:31 zakharyas joined #moarvm
19:32 dogbert2 if (-d '.git') {
19:32 dogbert2 print dots("Updating submodules");
19:32 dogbert2 my $msg = qx{git submodule sync --quiet && git submodule --quiet update --init 2>&1};
19:32 dogbert2 if ($? >> 8 == 0) { print "OK\n" }
19:32 dogbert2 else { softfail("git error: $msg") }
19:32 dogbert2 }
19:32 timotimo yeah, i know it did that
19:32 timotimo but the submodule stayed at the tag i checked out
19:33 dogbert2 I had to remove those line temporarily when testing
19:34 timotimo releasable6: status
19:34 releasable6 timotimo, Next release in 7 days and ≈23 hours. 1 blocker. Changelog for this release was not started yet
19:34 releasable6 timotimo, Details: https://gist.github.com/aaf4a7447d2e6200c55709aad93c82a2
19:50 domidumont joined #moarvm
21:04 tartal joined #moarvm
21:35 samcv i'm trying to get the collation data to concatenate in the creation of unicode.c but it's not working
21:38 MasterDuke samcv: btw, did you see the thing dogbert17_ found recently that bisected to one of the grapheme iterator commits?
21:38 samcv no
21:39 MasterDuke https://irclog.perlgeek.de/moarvm/2017-09-07#i_15131058 i think
21:40 timotimo i ran stresstest and it's all green except for t/spec/S17-procasync/bind-handles.t which hung (0 cpu) when run in the harness, but running it on its own does nothing to it
21:40 samcv $(CMD)$(CAT) src/strings/unicode_db.c src/strings/unicode_uca.c src/strings/unicode_ops.c > $@ $(NOERR)
21:40 samcv i have this in Makefile. and i added to Makefile.in
21:41 samcv but it doesn't seem to include src/strings/unicode_uca.c in the output file
21:41 samcv not sure how to figure out why
21:41 samcv if i do cat .... > src/strings/unicode.c with the three as listed in the flie it works but not when i run make
21:42 jnthn You re-configured?
21:43 samcv uh
21:43 jnthn Oh, you said you have it in Makefile, so yes
21:43 samcv i changed Makefile.in
21:43 samcv and then ran configure again
21:43 jnthn Right, that'd be sufficient
21:43 samcv hm
21:43 jnthn (I figured you'd have done so, but I know I've forgotten before and had a confused moment... :))
21:44 AlexDaniel joined #moarvm
21:44 samcv https://gist.github.com/9b922187b33eee81cd5b552933d3e8cf here's the Makefile.in
21:44 jnthn Should there be a space between $(CMD) and $(CAT) ?
21:44 samcv feels like it should be right. but it doesn't concat it
21:44 samcv CMD isn't defined to antything on linux
21:45 samcv i think
21:45 jnthn Yeah
21:45 jnthn I note the other places that use $(CAT) don't put $(CMD) before it
21:45 samcv hmm lemme remove
21:46 jnthn Curiously, none of the other examples of $(CAT) in that Makefile invoke it with multiple files
21:46 samcv works
21:46 samcv if i remove $(CMD)
21:47 jnthn hm, curious
21:51 samcv hmm i think i maybe found the issue
21:51 samcv gi->start isn't initialized in MVM_string_gi_init
21:51 samcv if it's a flat string
21:51 samcv or could be unrelated
21:53 samcv ah no that makes perfect sence
21:53 samcv i'm not seeing the error
21:54 MasterDuke might be a 32bit thing
21:55 samcv no i get it too
21:55 samcv move_ti for grapheme iterater doesn't set gi->start for flat strings
21:59 samcv at least it didn't cause an issue since flat strings don't have to move to future strands so it was alright
22:05 Geth ¦ MoarVM: 0441e075b4 | (Samantha McVey)++ | src/strings/iter.h
22:05 Geth ¦ MoarVM: Ensure gi->start is set to 0 for flat strings in MVM_string_gi_init
22:05 Geth ¦ MoarVM:
22:05 Geth ¦ MoarVM: This was causing a valgrind warning about an uninitialized value being
22:05 Geth ¦ MoarVM: used. This did not cause any actual bug since start is an unsigned
22:05 Geth ¦ MoarVM: integer and we don't actually have to move to other strands for flat
22:05 Geth ¦ MoarVM: strings.
22:05 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0441e075b4
22:05 samcv dogbert17_, fixed :)
22:07 samcv jnthn, putting a space between $(CMD) and $(CAT) also fixes the issue
22:11 jnthn ah, nice
22:11 jnthn Well, happy it works :)
22:22 dogbert2 joined #moarvm
22:22 dogbert2 samcv++
22:27 samcv cool. i got both the nodes and the collation array data using my bitfield packing module to ensure both are packed properly
22:27 samcv not sure if it matters for either after the change but at least i know in the future it can change in case more are added

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary