01:50 lue joined 02:12 JimmyZ joined 02:23 d4l3k_ joined 02:48 ilbot3 joined 07:40 lue joined 07:55 FROGGS joined 08:03 jimmy__ joined 08:29 lizmat joined 09:14 brrt joined 09:17 woolfy joined 09:21 woolfy left 09:28 kjs_ joined 09:30 woolfy joined
woolfy d0ttep0t 09:31
jnthn wonders what that password is for :P
JimmyZ_ IRC! 09:32
woolfy oh oh...
No, not IRC, fortunately...
Me wondering why I did not get access to that stupid website...
jnthn
.oO( Trust somebody from .nl to have a password involving pot... :P )
 09:33
woolfy Sorry for the intrusion...
jnthn So are we :D
(Kidding :))
woolfy (it was a nickname for our cat) 09:34
jnthn Ah.
brrt nicknames based on pets are common :-) 09:37
(now none of you may know the names of my rats)
woolfy My nickname is 'distraction'. :-) 09:48
brrt hang on... img-9gag-ftw.9cache.com/photo/aZWE729_460s.jpg 09:50
by the way 09:51
does moarvm have a logo of it's own yet
JimmyZ_ not yet
lizmat its own no
09:52 zakharyas joined
JimmyZ_ I wouldn't mind a small animal such as Honeybee ;) 09:53
tadzik chimera was one of the ideas 10:48
woolfy Some nice-looking caterpillar maybe? As the animal leading to the butterfly... 10:54
brrt hmmm 11:00
seems good to me 11:04
:-)
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:09
jnthn Oh! When I was in New Zeland I discovered... 11:27
There existed an animal called the Moa :D
MoaVM ;)
Close enough :P
It's probably simple enough to draw compared to some other animals too :P 11:28
"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
Almost as bit as a Camelia :P
*big
woolfy Big walking bird transforming into a butterfly. Interesting idea. www.google.nl/search?q=moa&biw...p;tbm=isch 11:50
But I am afraid people will make fun of it, since all types of Moa are extinct. en.wikipedia.org/wiki/Moa 11:51
brrt poor... 11:55
lizmat Well, since Perl *was* dead, we're reviving it by making a better Moa, a Moar ! 11:56
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:02
12:05 woolfy left 12:16 JimmyZ_ joined
JimmyZ_ jnthn: Does Moa live in the world now ? :P 12:17
13:01 ggoebel111111113 joined
jnthn Not yet, but it's a candidate for some...engineering :) 13:12
JimmyZ_ ;) 13:13
the talk of ' Perl x is died' and the extinct moa makes me thinking 'Moa is died' ... 13:23
14:36 lizmat joined 14:37 woolfy joined 14:46 dalek joined 15:16 brrt left 16:00 woolfy joined 17:07 kjs_ joined 17:24 woolfy left
TimToady surely moar should have some kind of cat-poster-cat that can haz cheezburger 17:37
jnthn True :D 17:52
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
TimToady doesn't expect scrolling through screen, and only uses it for programs like irssi that do their own paging 18:31
maybe something isn't conveying the window size correctly though? 18:32
18:32 FROGGS joined
jnthn Dunno 18:32
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
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 :)
Well, I'm inside lldb...
TimToady are you using putty? 18:34
jnthn Yeah
TimToady that's usually pretty decent
don't recall if there's any way to tweak the settings of Home or End though
jnthn Yeah. 18:35
TimToady maybe something in the longer chain is just assuming ANSI keys fortuitously
jnthn The double-bounce thing is because I'm on a train, which drops connection now and then.
And I don't want to lose my lldb session :)
Takes long enough to reach the reliable explodey point...
TimToady well, don't let me distract you from fixing osx!
timotimo "fixing osx" *snicker* 18:40
jnthn It's pretty odd 18:41
The actual gc_free method for MVMString would clear num_graphs
But it's still set in here
Suggesting something else freed the string body bforehand... 18:42
TimToady or that osx's malloc/free is just confused 18:43
jnthn Or that 18:44
TimToady it must set it's own bit somewhere to track that, surely...
and that bit could get corrupted maybe
buffer overflow from an earlier-in-memory string, perhaps 18:45
but then you'd think one of the tools would've caught it
anyway, only pay attention to me if I'm right, not if I'm wrong...
jnthn I wish Apple's debug malloc docs didn't assume you were using their shiny IDE... 18:47
aha... 18:49
Foudn the man page.
FROGGS jnthn: is it possible that osx treats differently from what we would expect? 18:52
treats unions*
jnthn Well, it'd be odd...those things normally vary by architecture, not OS...
Of course it takes even longer to reach exploding point with the guard malloc... :) 18:55
But hey, it's a 4 hour train ride :)
FROGGS Ć³.Ć² 18:56
of course I find something when I google for it... lists.cs.uiuc.edu/pipermail/llvmbug...29964.html 18:58
does not mean that it really is related
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
what's the clang version there? 19:00
jnthn "Stage parse : GuardMalloc[moar-60133]: attempted free of pointer 0x2774507fe0 that was not claimed by any registered malloc zone" 19:01
Darn.
FROGGS so, no insights from that run? 19:02
TimToady at least that's telling us that it was out-of-zone
jnthn Well, registered is the key
I guess that menas it was freed long ago 19:03
TimToady or perhaps deregistered too early
keeping a pointer out of something doing a custom arena? 19:04
jnthn tries it with malloc stack logging
TimToady something 3rdparty maybe?
jnthn That could explain the platform-specificness of it all... 19:05
"malloc: stack logs being written into /tmp/stack-logs.60512.100346000.moar.Zif3yb.index" 19:06
I wonder how big they get, and how big /tmp/ is :)
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?
of*
TimToady libatomic_ops plays a lot with malloc 19:12
3rdparty//libatomic_ops/doc/README_malloc.txt 19:13
of course libuv and dyncall play around a lot with allocators too 19:16
anything handling a signal might want a custom arena 19:17
19:17 kjs_ joined
jnthn There's no signal handling or dyncall use in CORE.setting compilation. libatomic_ops gets used all over though... 19:43
malloc_history fuck yeah 19:49
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
----
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
So, we'd better be taking a close look at MVM_proc_getenvhash 19:50
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:55
jnthn oh heck, I might see it 19:57
FROGGS but please tell me that it was not obvious :o) 20:02
dalek arVM: 0a9c998 | jonathan++ | src/io/procops.c:
Avoid a pointer getting outdated on the stack.

If the box operations allocates, then a now-outdated `key` pointer was already copied onto the stack to pass to the bind_key. Thus it came to work on this now-moved object body. This may have been the cause of the various mostly-on-OSX failures, given it was discovered using the OSX guardmalloc while investigating the issues there.		 20:10
FROGGS ohh 20:13
jnthn Clang. It doesn't half clang. 20:15
It writes warning. In magenta.
Is that meant to make he hate it enough to fix the warning?
*me
FROGGS yes, exactly :o) 20:16
TimToady this just in: the nfa currently takes about 11% of the cpu time when parsing the setting
FROGGS that's also a reason it shows like 12 lines of output for a single warning
TimToady well, wall-clock time
that percentage will go up as the rest of the parser gets faster 20:17
so basically about 3 seconds out of 30
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...
TimToady this includes the copy-out
FROGGS .oO( nźœ¤ )
TimToady I timed it at the nqp::runnfaproto/alt level
anyway, at some point it'll be worth slapping a DFAish state-set cache onto it 20:19
FROGGS nźœ¤ā…ž
erg
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.
There might be some way to improve there too
TimToady yes, some have 5000 states
well, one does, anyway 20:24
and there's a 2000 in there too
though it's the states with 50-60 edges that are the killers, I suspect 20:25
it's easy to fill up one's disk with logging the intricate bits of the nfa, I've found :)
jnthn hah! 20:26
Such state.
TimToady so edgy
jnthn wonders if the huge one is the alternation in statement :)
TimToady probably, considering you can start with any term 20:27
at the moment, don't know for sure because the nfa doesn't know it's name 20:28
*its 20:29
jnthn hm, not sure if faling to SEGV or wedged connection... :)
ah, I hit enter and it did a line break.
Guess it's alive.
It's doing an insane number of GC runs...
FROGGS gee 20:30
jnthn: you are stress testing the patch atm?
jnthn ('cus I cranked them up to try and reveal the SEGV)
FROGGS: Yeah.
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:31
Darnit, how on earth do you use top... 20:34
When the think you're looking for isn't...on top... :)
FROGGS well, q quit it :o) 20:35
jnthn yes, I know *that* :P
FROGGS and h gives you hints... that's all I know
jnthn ah, ocpu 20:36
Sorts by CPU usage
That puts moar on top :)
oh...it got past stage parse
So GC. State optimize took 3 minutes o.O 20:38
TimToady Optimizer, optimize thyself. 20:42
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:44
and if you make the rest of the parser twice as fast, it'll be more like 20% 20:45
jnthn True :) 20:58
Darn, some failures 21:04
Though I guess this Rakudo is a week old. 21:05
and it pulled fresh spectest repo
oh...no ownder the spectest takes a while 21:14
You have to spell set as export away from Windows...
nwc10 jnthn: All tests successful. 21:32
all the way to spectest, ASAN, master/master/nom 21:33
no idea why that bug you found was only spotted by OS X
jnthn Bollocks. Still various failures on OSX. 22:02
TimToady but are any of them on free? 22:04
jnthn Hard to tell from make spectest 22:05
And doesn't fail when run alone.
Running those that fail through t/harness doesn't make them fail again. 22:10
There are notably less of them than before the previous fix 22:11
So yeah, progress, a fix, but still a problem to find. :( 22:15
23:08 lizmat joined
jnthn Managed to get a GC invariant breakage to be hit consistently after some fiddling with various sizes...will debug more tomorrow. 23:57
'night

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!