Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-11-28

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

All times shown according to UTC.

Time Nick Message
01:50 lue joined #moarvm
02:12 JimmyZ joined #moarvm
02:23 d4l3k_ joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
07:40 lue joined #moarvm
07:55 FROGGS joined #moarvm
08:03 jimmy__ joined #moarvm
08:29 lizmat joined #moarvm
09:14 brrt joined #moarvm
09:17 woolfy joined #moarvm
09:21 woolfy left #moarvm
09:28 kjs_ joined #moarvm
09:30 woolfy joined #moarvm
09:31 woolfy d0ttep0t
09:31 * jnthn wonders what that password is for :P
09:32 JimmyZ_ IRC!
09:32 woolfy oh oh...
09:32 woolfy No, not IRC, fortunately...
09:32 woolfy Me wondering why I did not get access to that stupid website...
09:33 jnthn .oO( Trust somebody from .nl to have a password involving pot... :P )
09:33 woolfy Sorry for the intrusion...
09:33 jnthn So are we :D
09:33 jnthn (Kidding :))
09:34 woolfy (it was a nickname for our cat)
09:34 jnthn Ah.
09:37 brrt nicknames based on pets are common :-)
09:37 brrt (now none of you may know the names of my rats)
09:48 woolfy My nickname is 'distraction'.  :-)
09:50 brrt hang on... http://img-9gag-ftw.9cache.com/photo/aZWE729_460s.jpg
09:51 brrt by the way
09:51 brrt does moarvm have a logo of it's own yet
09:51 JimmyZ_ not yet
09:51 lizmat its own no
09:52 zakharyas joined #moarvm
09:53 JimmyZ_ I wouldn't mind a small animal such as Honeybee ;)
10:48 tadzik chimera was one of the ideas
10:54 woolfy Some nice-looking caterpillar maybe?  As the animal leading to the butterfly...
11:00 brrt hmmm
11:04 brrt seems good to me
11:04 brrt :-)
11:09 woolfy I've been looking for some nice ones, but many caterpillars are looking agressive with spikes, some are seemingly amorphous blobs, and some that are quite nice lead to hideous butterflies.  Difficult...
11:27 jnthn Oh! When I was in New Zeland I discovered...
11:27 jnthn There existed an animal called the Moa :D
11:27 jnthn MoaVM ;)
11:27 jnthn Close enough :P
11:28 jnthn It's probably simple enough to draw compared to some other animals too :P
11:30 jnthn "The two largest species, Dinornis robustus and Dinornis novaezelandiae, reached about 3.6 m (12 ft) in height with neck outstretched, and weighed about 230 kg (510 lb)"
11:30 jnthn Almost as bit as a Camelia :P
11:30 jnthn *big
11:50 woolfy Big walking bird transforming into a butterfly.  Interesting idea.   https://www.google.nl/search?q=moa&biw=1920&bih=910&tbm=isch
11:51 woolfy But I am afraid people will make fun of it, since all types of Moa are extinct.  http://en.wikipedia.org/wiki/Moa
11:55 brrt poor...
11:56 lizmat Well, since Perl *was* dead, we're reviving it by making a better Moa,  a Moar  !
12:02 woolfy Hmm, using an extinct bird to promote a language that is considered dead by some people is not the best marketing ploy I know about...
12:05 woolfy left #moarvm
12:16 JimmyZ_ joined #moarvm
12:17 JimmyZ_ jnthn: Does Moa live in the world now ? :P
13:01 ggoebel111111113 joined #moarvm
13:12 jnthn Not yet, but it's a candidate for some...engineering :)
13:13 JimmyZ_ ;)
13:23 JimmyZ_ the talk of ' Perl x is died' and the extinct moa makes me thinking 'Moa is died' ...
14:36 lizmat joined #moarvm
14:37 woolfy joined #moarvm
14:46 dalek joined #moarvm
15:16 brrt left #moarvm
16:00 woolfy joined #moarvm
17:07 kjs_ joined #moarvm
17:24 woolfy left #moarvm
17:37 TimToady surely moar should have some kind of cat-poster-cat that can haz cheezburger
17:52 jnthn True :D
18:30 jnthn dammit, windows -> ssh -> screen on linux -> ssh -> osx does some odd stuff with scrolling...
18:30 * TimToady is not sure what the iconic paraphenalia of a lolcat would be though
18:31 * TimToady doesn't expect scrolling through screen, and only uses it for programs like irssi that do their own paging
18:32 TimToady maybe something isn't conveying the window size correctly though?
18:32 FROGGS joined #moarvm
18:32 jnthn Dunno
18:33 jnthn Well, I found the pointer I wanted in the bit of the bt that didn't vanish, anyways...
18:33 TimToady if the window size is right, there's always piping to more or less
18:33 jnthn Bizzarely, the Home and End keys do work prpoerly in this double-ssh setup, whereas they don't when I SSH directly into the OSX box :)
18:33 jnthn Well, I'm inside lldb...
18:34 TimToady are you using putty?
18:34 jnthn Yeah
18:34 TimToady that's usually pretty decent
18:34 TimToady don't recall if there's any way to tweak the settings of Home or End though
18:35 jnthn Yeah.
18:35 TimToady maybe something in the longer chain is just assuming ANSI keys fortuitously
18:35 jnthn The double-bounce thing is because I'm on a train, which drops connection now and then.
18:35 jnthn And I don't want to lose my lldb session :)
18:35 jnthn Takes long enough to reach the reliable explodey point...
18:35 TimToady well, don't let me distract you from fixing osx!
18:40 timotimo "fixing osx" *snicker*
18:41 jnthn It's pretty odd
18:41 jnthn The actual gc_free method for MVMString would clear num_graphs
18:41 jnthn But it's still set in here
18:42 jnthn Suggesting something else freed the string body bforehand...
18:43 TimToady or that osx's malloc/free is just confused
18:44 jnthn Or that
18:44 TimToady it must set it's own bit somewhere to track that, surely...
18:44 TimToady and that bit could get corrupted maybe
18:45 TimToady buffer overflow from an earlier-in-memory string, perhaps
18:45 TimToady but then you'd think one of the tools would've caught it
18:45 TimToady anyway, only pay attention to me if I'm right, not if I'm wrong...
18:47 jnthn I wish Apple's debug malloc docs didn't assume you were using their shiny IDE...
18:49 jnthn aha...
18:49 jnthn Foudn the man page.
18:52 FROGGS jnthn: is it possible that osx treats differently from what we would expect?
18:52 FROGGS treats unions*
18:52 jnthn Well, it'd be odd...those things normally vary by architecture, not OS...
18:55 jnthn Of course it takes even longer to reach exploding point with the guard malloc... :)
18:55 jnthn But hey, it's a 4 hour train ride :)
18:56 FROGGS ó.ò
18:58 FROGGS of course I find something when I google for it... http://lists.cs.uiuc.edu/pipermail/llvmbugs/2013-August/029964.html
18:58 FROGGS does not mean that it really is related
18:59 jnthn tbh, if I had to compile C++ code, I'm not sure I'd feel much like it :P
18:59 TimToady the fix was to upgrade to 3.3
19:00 TimToady what's the clang version there?
19:01 jnthn "Stage parse      : GuardMalloc[moar-60133]: attempted free of pointer 0x2774507fe0 that was not claimed by any registered malloc zone"
19:01 jnthn Darn.
19:02 FROGGS so, no insights from that run?
19:02 TimToady at least that's telling us that it was out-of-zone
19:02 jnthn Well, registered is the key
19:03 jnthn I guess that menas it was freed long ago
19:03 TimToady or perhaps deregistered too early
19:04 TimToady keeping a pointer out of something doing a custom arena?
19:04 * jnthn tries it with malloc stack logging
19:04 TimToady something 3rdparty maybe?
19:05 jnthn That could explain the platform-specificness of it all...
19:06 jnthn "malloc: stack logs being written into /tmp/stack-logs.60512.100346000.moar.Zif3yb.index"
19:06 jnthn I wonder how big they get, and how big /tmp/ is :)
19:09 TimToady dyncall with a callback might easily lose track of something, I suppose
19:09 FROGGS we're not using that outside or NativeCall, right?
19:09 FROGGS of*
19:12 TimToady libatomic_ops plays a lot with malloc
19:13 TimToady 3rdparty//libatomic_ops/doc/README_malloc.txt
19:16 TimToady of course libuv and dyncall play around a lot with allocators too
19:17 TimToady anything handling a signal might want a custom arena
19:17 kjs_ joined #moarvm
19:43 jnthn There's no signal handling or dyncall use in CORE.setting compilation. libatomic_ops gets used all over though...
19:49 jnthn malloc_history fuck yeah
19:49 jnthn ALLOC 0x2775d7afe0-0x2775d7afff [size=32]: thread_7fff76579300 |start | main | MVM_vm_run_file | MVM_interp_run | MVM_proc_getenvhash | MVM_string_substring | allocate_strands | MVM_malloc | GMmalloc_zone_malloc_internal
19:49 jnthn ----
19:49 jnthn FREE  0x2775d7afe0-0x2775d7afff [size=32]: thread_7fff76579300 |start | main | MVM_vm_run_file | MVM_interp_run | MVM_proc_getenvhash | MVM_repr_bind_key_o | bind_key | extract_key | MVM_string_flatten | MVM_free | GMmalloc_zone_free
19:50 jnthn So, we'd better be taking a close look at MVM_proc_getenvhash
19:55 FROGGS jnthn: actually, I was thinking that spawned things might lead to that problem, because often the failing spectests where tests that shell()ed or run()ed
19:57 jnthn oh heck, I might see it
20:02 FROGGS but please tell me that it was not obvious :o)
20:10 dalek MoarVM: 0a9c998 | jonathan++ | src/io/procops.c:
20:10 dalek MoarVM: Avoid a pointer getting outdated on the stack.
20:10 dalek MoarVM:
20:10 dalek MoarVM: If the box operations allocates, then a now-outdated `key` pointer was
20:10 dalek MoarVM: already copied onto the stack to pass to the bind_key. Thus it came to
20:10 dalek MoarVM: work on this now-moved object body. This may have been the cause of the
20:10 dalek MoarVM: various mostly-on-OSX failures, given it was discovered using the OSX
20:10 dalek MoarVM: guardmalloc while investigating the issues there.
20:10 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0a9c9980d4
20:13 FROGGS ohh
20:15 jnthn Clang. It doesn't half clang.
20:15 jnthn It writes warning. In magenta.
20:15 jnthn Is that meant to make he hate it enough to fix the warning?
20:15 jnthn *me
20:16 FROGGS yes, exactly :o)
20:16 TimToady this just in: the nfa currently takes about 11% of the cpu time when parsing the setting
20:16 FROGGS that's also a reason it shows like 12 lines of output for a single warning
20:16 TimToady well, wall-clock time
20:17 TimToady that percentage will go up as the rest of the parser gets faster
20:17 TimToady so basically about 3 seconds out of 30
20:18 jnthn TimToady: Really? Interesting...my readings from the VS sampling profiler had it only at 2%-3%.
20:18 FROGGS if you could cut that in half...
20:18 TimToady this includes the copy-out
20:18 * FROGGS .oO( nꜤ )
20:18 TimToady I timed it at the nqp::runnfaproto/alt level
20:19 TimToady anyway, at some point it'll be worth slapping a DFAish state-set cache onto it
20:19 FROGGS nꜤ⅞
20:19 FROGGS erg
20:23 TimToady or maybe avoid rerunning nfa in subrules by doing std's trick of passing down known fates from the outer nfa's run, but my gut says the DFA would win us more performance, if memory effects don't dominate
20:23 jnthn I think some of our NFAs are quite huge.
20:23 jnthn There might be some way to improve there too
20:23 TimToady yes, some have 5000 states
20:24 TimToady well, one does, anyway
20:24 TimToady and there's a 2000 in there too
20:25 TimToady though it's the states with 50-60 edges that are the killers, I suspect
20:25 TimToady it's easy to fill up one's disk with logging the intricate bits of the nfa, I've found :)
20:26 jnthn hah!
20:26 jnthn Such state.
20:26 TimToady so edgy
20:26 * jnthn wonders if the huge one is the alternation in statement :)
20:27 TimToady probably, considering you can start with any term
20:28 TimToady at the moment, don't know for sure because the nfa doesn't know it's name
20:29 TimToady *its
20:29 jnthn hm, not sure if faling to SEGV or wedged connection... :)
20:29 jnthn ah, I hit enter and it did a line break.
20:29 jnthn Guess it's alive.
20:29 jnthn It's doing an insane number of GC runs...
20:30 FROGGS gee
20:30 FROGGS jnthn: you are stress testing the patch atm?
20:30 jnthn ('cus I cranked them up to try and reveal the SEGV)
20:30 jnthn FROGGS: Yeah.
20:31 jnthn If this works out (no idea at all how long that may take) then I will stash my GC stress patches and try a make spectest
20:34 jnthn Darnit, how on earth do you use top...
20:34 jnthn When the think you're looking for isn't...on top... :)
20:35 FROGGS well, q quit it :o)
20:35 jnthn yes, I know *that* :P
20:35 FROGGS and h gives you hints... that's all I know
20:36 jnthn ah, ocpu
20:36 jnthn Sorts by CPU usage
20:36 jnthn That puts moar on top :)
20:36 jnthn oh...it got past stage parse
20:38 jnthn So GC. State optimize took 3 minutes o.O
20:42 TimToady Optimizer, optimize thyself.
20:44 TimToady anyway, if the rest of the parser is 4 times faster than what it used to be, then 2-3% could easily end up 11%, since your spesh/jit optimizations don't touch the nfa code
20:45 TimToady and if you make the rest of the parser twice as fast, it'll be more like 20%
20:58 jnthn True :)
21:04 jnthn Darn, some failures
21:05 jnthn Though I guess this Rakudo is a week old.
21:05 jnthn and it pulled fresh spectest repo
21:14 jnthn oh...no ownder the spectest takes a while
21:14 jnthn You have to spell set as export away from Windows...
21:32 nwc10 jnthn: All tests successful.
21:33 nwc10 all the way to spectest, ASAN, master/master/nom
21:33 nwc10 no idea why that bug you found was only spotted by OS X
22:02 jnthn Bollocks. Still various failures on OSX.
22:04 TimToady but are any of them on free?
22:05 jnthn Hard to tell from make spectest
22:05 jnthn And doesn't fail when run alone.
22:10 jnthn Running those that fail through t/harness doesn't make them fail again.
22:11 jnthn There are notably less of them than before the previous fix
22:15 jnthn So yeah, progress, a fix, but still a problem to find. :(
23:08 lizmat joined #moarvm
23:57 jnthn Managed to get a GC invariant breakage to be hit consistently after some fiddling with various sizes...will debug more tomorrow.
23:57 jnthn 'night

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