00:39 avuserow joined 01:58 FROGGS_ joined 04:55 lastofthe left
sergot morning o/ 06:37
06:51 tokuhirom left 07:04 brrt joined
brrt SuchVM.. /me likes 07:04
when it is time to deprecate MoarVM, we'll use that name
07:06 woolfy left 07:13 xiaomiao joined 07:17 zakharyas joined 08:21 xiaomiao joined, lizmat joined
dalek arVM: 65e7bfd | moritz++ | build/probe.pm:
Avoid unaligned reads on ARMv7

closes issue 137. Patch courtesy of throwaway-moar-arm++		 08:33
nine [Coke]: git maintains a commit id and a separate patch id which is just the hash of the diff. This way it can detect if a commit would do the exact same change and act sensibly. Helps for example when rebasing some branch and then rebasing a branch based on the previous one. 08:50
daxim can yall look at the crash bugs I submitted on github and fix them? does anyone care? for austrian perl workshop, I'd like to show a comparison with some parsers like marpa and peg.js and also would like to include perl6 grammars 10:39
FROGGS daxim: have you created new issues? 10:44
daxim no, still untouched since a month.
FROGGS daxim: was that the opensuse build issue were I tried to package it but failed? 10:45
daxim that's yet another unresolved one
FROGGS ahh, wait, let me try to find your issue
daxim moarvm #123 10:46
FROGGS github.com/MoarVM/MoarVM/issues/123
found it
your libuv is newer... we use 0.11.18, you use 0.11.28 10:47
daxim: issue #81 is also related to libuv version mismatch... 10:52
daxim when can I expect a fix? mind that this is not only for me, but blocking packaging 10:53
FROGGS I try to come up with a solution quickly 10:54
11:13 lizmat joined 11:35 lastofthe joined
dalek arVM: ae6fb2f | (Tobias Leich)++ | / (2 files):
conditionally set include dirs and install rules (e.g. --has-libuv)
 11:36
FROGGS daxim: this should let us at least build against the uv headers we're linking to 11:37
lastofthe moritz++: thank you for the clang/arm patch
FROGGS daxim: now I'd need a libuv on my system to test other versions then the bundled one :S 11:38
moritz lastofthe: I just applied it, I think nwc10++ is to "blame" 11:39
lastofthe I'm to blame, just saying thanks :) 11:41
(for the application)
moritz oh 11:50
lastofthe++
12:08 itz joined
jnthn FROGGS: Any reason you know of for us not to bump to a newer libuv? I could understand it if our HEAD was using something *newer* than distros are packaging. That we're using something older feels a little suboptimal... :) 12:20
FROGGS jnthn: don't know of a reason, no
jnthn OK.
FROGGS jnthn: that was my plan B, update to that version if I cannot install such a version with apt
because I'd like to reproduce the issue first 12:21
jnthn FROGGS: I'm happy enough if it's plan A, provided it builds...
FROGGS: OK. I leave it with you.
Lemme know if I need to look at something
FROGGS but it seems even a newer ubuntu offers an older libuv (I'm currently upgrading to 14.04)
jnthn grmbl
FROGGS k, will do it as plan A in a bit :o)
jnthn
.oO( Bundling: the worst option except all the others... )
jnthn has a 3-day weekend 12:26
Hopefully I don't spend all this one being ill, like last one...
nwc10 yay!
what's the excuse for a public holiday?
jnthn No idea, guy at work said something about the moon :) 12:27
But it isn't even a full moon yet, so...hmm. :)
FROGGS ohh, then it is not "Mars is bright tonight" :o)
13:00 lizmat joined
jnthn efff2fdbb8b8 breaks the build on MSVC 14:46
14:46 itz_ joined
dalek arVM: 16ecaa8 | jonathan++ | src/moar.h:
Unbust the MSVC build.
 14:49
15:05 lizmat joined 15:07 dalek joined 15:12 kjs_ joined
[Coke] jnthn++ 15:15
timotimo oops, that was me ;( 15:16
[Coke] you were fixing my bug! ;( 15:17
jnthn timotimo: Yeah. Since MVM_PUBLIC doesn't equate to anything on non-Windows, there was no chance of a warning...
The basic rule is that if MVM_PUBLIC is one a declaration of something, it has to go on a forward-decl of it elsewhere too 15:19
Otherwise the compiler barfs over the inconsistent export semantics...
s/one a/on a/
15:31 itz joined
dalek arVM: 64f5ecb | jonathan++ | src/core/oplist:
Fix spell-o.
 15:42
arVM: 92a3472 | jonathan++ | / (11 files):
Add a way to specify a type needs finalization.

Nothing is done with this information as of yet, except storing it on the type's STable.
timotimo oooh, we're getting some more lazy initialization stuff 15:44
jnthn No
15:44 FROGGS joined
jnthn The stuff nine++ needs. 15:44
timotimo ah! 15:45
aah, *finalization*
as in ... finalization!
jnthn ... :P 15:46
Don't have the energy to actually get it in place tonight, but figured I'd do the easy prep work so I can dive into the heart of it tomorrow. :) 15:47
timotimo i wonder if we'd get better code-gen if we split the $key eq '$!from' || $key eq '$!to' into two ifs and use a constant string for bindattr inside ... 15:48
jnthn timotimo: Maybe, but they're relatively rare... 15:49
Would JIT better though
timotimo then it's kinda not so cool to be checking for them each and every single iteration, eh? 15:50
jnthn Yeah, that's the bigger issue...
timotimo maybe we can do the check with existskey twice first and kick them out of the hash if they are?
jnthn That's not such a bad idea...
timotimo hm, but the caps are probably not something we'd be allowed to mutate
jnthn Right
Well
timotimo and cloning that... :\
jnthn Other way is to do an ordat to get the first char of the name and check if it's the $ char...
timotimo + if $name && nqp::ordat($name, 0) == 36 && ($name eq '$!from' || $name eq '$!to') { 15:51
that's already what your patch does :)
jnthn oh o.O
(jnthn of the optimization past)++ :P 15:52
timotimo though we have an optimization in place that'll turn an eqat with length 1 into an ordat *and* convert the character to its ordinal for you
so it'd be nicer to look at in the code
or at least i think we have that
jnthn Don't remember us having it.
timotimo at the very least in moar's code-gen.
FROGGS timotimo: might make sense to bench every change your make, what do you think? 15:53
timotimo heh.
15:54 itz_ joined
TimToady I assume that's finalization as in "destroy", not as is "class is closed, final" 16:24
jnthn TimToady: Correct 16:25
TimToady since you can't tell that a class needs finalization, only that it's allowed if no one wants it non-final
jnthn TimToady: Finalization is the widely used term for this in the GC world. 16:26
TimToady ain't overloading wonderful...
jnthn Thankfully, language exists within a context... :) 16:27
The src/gc/ context in this case :)
TimToady maybe we need a different term for what happens to a class...closed and...copyrighted, so no derivative works 16:28
closed and...neutered... 16:29
jnthn has seen "sealed" used for it
TimToady well, that's kind of like a vasectomy...
jnthn canonize...
nwc10 jnthn: if you keep ++ing nine we'll loose track of whether he's now seventeen, fourty two, or several hundren
er, hundred 16:30
TimToady closed and "fixed" :)
jnthn dead...uh...stable :)
TimToady not dead yet!
just...endangered, and resting... 16:31
senescent...
close and past caring :)
closed and shuttered 16:32
"not taking new patients" 16:33
diakopter cauterized? 16:35
heh, pun on sealed could be seared 16:37
(also has the engrish connotation)
timotimo shelved, shelled? crusty? breaded? 16:38
TimToady privatized and plundered, to go in the economics direction 16:42
diakopter heh more like overregulated 16:43
to go in the other economics direction 16:44
TimToady don't mess with me, don't try to be like me 16:47
17:03 lastofthe joined
[Coke] moar is failing t/fudgeandrun t/spec/integration/99problems-51-to-60.t, but the test passes with MVM_SPESH_DISABLE=1 17:12
jnthn [Coke]: Yes, more specifically MVM_SPESH_INLINE_DISABLE, I believe 17:15
[Coke]: I didn't have much luck figuring out *why* yet, though :(
17:27 zakharyas joined
[Coke] need a ticket? 17:32
japhb After watching a job that processes output from a child process take half an hour to complete -- when I know the underlying child process runs in a minute at most -- I decided to try the profiler. And began to weep inside. 17:37
The list refactor can't come soon enough. Partly because trying to trace the call graph goes through so many levels of anon/gimme/reify/etc. that finding actual work done is painful. And partly because the GC list shows 13000 runs of "31KB / 11KB / 4053KB" for nursery retained/promoted/freed -- or even worse. 17:39
TimToady well, there will still be levels of closures, till the inliner kicks in 17:40
you can't just ignore that map in the middle 17:41
.oO(map-in-the-middle attack!)
japhb The input data is a little under 37_000 lines. Processing it creates 88_000_000 or so BOOTArray objects, or so the Allocations tab claims. I'm pretty sure my code isn't *that* insane. 17:43
TimToady yes, one of the things we need to do is return raw arrays rather parcelizing at every level 17:46
"here's an unadorned batch of result" 17:47
*sults
or in the case of a negotiated lazy, this closure returns exactly one unadorned result
and for the most part, batches have to be stealable, so you can just use the returned batch as your own basis of computation without copying it 17:49
japhb I'm a bit surprised by the next couple things on the list too ... 35_000_000 BOOTInt, 19_000_000 Int, 10_000_000 Whatever, 9_000_000 BOOTCode, 8_000_000 each of NQPArray, BOOTIter, and Scalar ...
Right.
TimToady everyone's using indexing to reprocess each array
the Whatevers are the .gimme(*) and .reify(*) probably
we could really use smart pointers into arrays, a la Go 17:50
japhb Ah, yes. WBNI that case could use a singleton instead
TimToady: You mean Go's "slice" concept?
TimToady yeah, something like that 17:51
an array pointer that knows its bounds, basically
it's one of the C fixes that Go actually got right, I think
and something we can probably use for pointers into native arrays 17:52
on JVM, of course, you probably have to remember the original structure to index into 17:53
but that can be largely transparent
japhb nodnod 17:54
TimToady so among other things, our list refactor has to be able to return batches of natives as a native array
timotimo yes, please 17:58
TimToady maybe 10_000_000 Whatever is LHF, since * is supposed to be a singleton
are we doing Whatever.new all over the place?
timotimo hopefully not, but perhaps we clone() it all the time? 17:59
TimToady clone on a singleton should just return self
japhb Whatever's method new() does nqp::create(self), and there's no clone override. 18:01
TimToady go for it! 18:03
timotimo japhb: i'd be interested to see how that script of yours behaves when you merge in my dynamic_gen2_tuning branch of MoarVM 18:05
since it usually just promotes 11kb it should only do a full collection very few times all in all 18:06
i think it waits for 30 mb of promoted data to accumulate before doing a gen2
i'd kind of like to see a scatter plot of gc runs with x being kept and y being promoted or something 18:07
though ... perhaps a scatter plot is usually used for data where x and y have some expected correlation
TimToady hmm, ./libmoar.so: undefined reference to `MVM_gc_finalize_set' 18:09
did jnthn forget to check something in? 18:10
needs reconfig is all 18:11
timotimo ah
TimToady make clean ain't good enough
TimToady is working on a reverse merge back into dynamic_gen2_tuning to keep it from getting too out of sync 18:15
(spectesting) 18:16
timotimo i wonder what i should test to figure out if the branch is mergable 18:19
TimToady well, it's certainly mergable, since the merge succeeds :P 18:21
dalek Heuristic branch merge: pushed 25 commits to MoarVM/dynamic_gen2_tuning by TimToady
18:22 brrt joined 18:28 teodozjan joined
lastofthe waits for the ocean swell to fill in, and the car is in the shop, must be time to pick some toe jam and squash some compiler warnings... 18:47
18:54 itz joined 19:06 kjs_ joined 19:09 brrt joined
dalek arVM/libuv-0.11.29: fce509b | (Tobias Leich)++ | / (6 files):
update libuv from 0.11.18 to 0.11.29

This also includes minimal adjustments to our codebase, for example callbacks only get a handle and not an additional status and uv_fs_read wants an uv_but_t now instead of char*.		 19:23
FROGGS testing this now on windows...
damn, now I get spectest fails :( 19:26
ohh 19:28
dalek arVM/libuv-0.11.29: 8a98741 | (Tobias Leich)++ | src/io/syncfile.c:
uv_fs_write also takes an uv_buf_t instead of char*
 19:35
19:39 kjs_ joined
nwc10 jnthn: PPC spesh SEGV is because MVMint64 slot = try_get_slot(tc, repr_data, ch_facts->type, MVM_spesh_get_string(tc, g, ins->operands[3])); 19:45
for OP MVM_OP_getattrs_n, third ins is a register (if I understand this stuff correctly), so was written into the union in ins->operands[3] as (as far as I can work out) ani16 19:48
so on little endian systems:
lit_i32 = 13,
lit_i16 = 13,
lit_str_idx = 13,
and all is happy (MVM_spesh_get_string(...) returns non-NULL, try_get_slot() loops but returns -1 19:49
on big endian systems
lit_i32 = 851968, lit_i16 = 13,
lit_n32 = 1.19386145e-39, lit_str_idx = 851968, callsite_idx = 13,
so MVM_spesh_get_string(...) is 19:50
return g->sf->body.cu->body.strings[o.lit_str_idx];
and o.lit_str_idx is 851968 not 13 19:51
and g->sf->body.cu->body.strings[851968] is NULL
and SEGV later on
and, what I can't work out is what codeis wrong - is the write using lit_i16 wrong
or the read using lit_str_idx
as best I can work out, 3rd argument of MVM_OP_getattrs_n is 16 bit 19:52
3rd argument of MVM_OP_getattr_n is 32 bit
so, is that part of the confusion?
lastofthe starts a portability slow clap 19:53
nwc10 what's that meant to acchieve? 19:55
lastofthe me? 19:56
nwc10 yes. I'm not sure what a slow clap is for
TimToady suspects a slow clap implies that it might get faster later :) 19:57
lastofthe Oh, I get giddy when folks port. Any attempt at starting a slow clap is to get everyone to clap along :)
nwc10 ah OK
lastofthe Or even a subset of everyone :)
I believe I've benefited from some of your PPC work while I've (just recently) jumped in and thwacked on some ARMv7 stuffs. The clap (not that kind!) is just me appreciating that work. 19:58
nwc10 I suspect you more likely benefitted from the my ARM work that preceded the PPC work 19:59
lastofthe Ahh, make sense.
nwc10 and the PPC work was partly someone else - I forget who 20:00
I mostly just found and fixed the last missing bit
lastofthe It usually is :) (partly someone else)
Do we have a way to share branches that doesn't involve creating a github account and clicking buttons? Is it cool to attach publicly available non github branches to tickets? 20:04
FROGGS nwc10: I'm going to merge the libuv-update branch... I don't see any fallout on windows and linux
nwc10: but if something is going to get weird, please let me know
dalek arVM: fce509b | (Tobias Leich)++ | / (6 files):
update libuv from 0.11.18 to 0.11.29

This also includes minimal adjustments to our codebase, for example callbacks only get a handle and not an additional status and uv_fs_read wants an uv_but_t now instead of char*.		 20:05
arVM: 8a98741 | (Tobias Leich)++ | src/io/syncfile.c:
uv_fs_write also takes an uv_buf_t instead of char*
nwc10 FROGGS: for me, t/nqp/19-file-ops.t seems to be hanging 20:12
FROGGS hmmm
nwc10: it passes instantly on my box 20:13
nwc10 OK, some games with strace and ps suggest that moar was waiting on epoll with a zombie sh as a child 20:14
no, I don't know why
FROGGS O.o 20:15
20:29 itz_ joined
lizmat SPW shutting down for today... see you later& 20:33
japhb gets out of his block of meetings 20:34
timotimo: While certainly the full collections are more expensive than nursery collections, I think that is actually dwarfed by the sheer churn of it all. Meaning if you don't get rid of the 13_000 or so nursery collections (and all the associated object construction and tear down), making the full collections rarer will only have a small effect on total run time. 20:36
20:37 itz joined
TimToady japhb: we currently compile every * down to Whatever.new... >.< 20:37
japhb Ouch. 20:38
Why do we even create a new object? Why not just pass the type object around?
TimToady as a datapoint, changing new to read our $star //= nqp::create(self) works, but is not yet optimal
we should create a singleton early and just use it
japhb (Meaning, changing that to clone is nice and all, but why not have no method call at all?)
TimToady well, the type object itself is different from the instance 20:39
japhb I guess I was asking, why does * need to be concrete?
TimToady we would like to have Whatever undefined and * defined
japhb Ah, interesting.
Why?
(I've got a guess as to the reasoning, but I'm curious ....) 20:40
nwc10 FROGGS: regular debugging build is fine
there's something very screwy with ASAN
under ASAN, things end up with that deadlock hang
TimToady is trying to remember where the distinction is important
but you certainly want Whatever for the manifest type check in signatures, not a literal * 20:41
FROGGS nwc10: this can of course be a problem upstream too :/
TimToady oh, well, what about when you want to call *.^methods vs Whatever.^methods ? 20:42
20:42 itz_ joined
japhb Unless it's been mixed into, wouldn't that be the same? 20:42
TimToady m: say *.DEFINITE
nwc10 FROGGS: well, I have no good idea, and I'm going to go to bed
camelia rakudo-moar fd9238: OUTPUTĀ«Trueā¤Ā»
japhb m: say (3.^methods) eqv (Int.^methods) 20:43
camelia rakudo-moar fd9238: OUTPUTĀ«Trueā¤Ā»
FROGGS gnight nwc10
TimToady no, what if you want to autoprime .^methods?
m: say (*.^methods) eqv (Whatever.^methods)
camelia rakudo-moar fd9238: OUTPUTĀ«WhateverCode.new()ā¤Ā»
TimToady hah 20:44
japhb Oh!
Duh, I see what you mean.
TimToady use vs mention
japhb OK, so that does argue with the early-created singleton instance, and then use that whenever we see '*' used as Whatever:D 20:45
TimToady anyway, yeah, we need to figure out how to create a Whatever.new singleton early enough to use it in src/Perl6/*.nqp
japhb Don't we already do that for e.g. Inf?
TimToady looks to me like we compie Inf and -Inf down to inf and neginf opcodes 20:48
nwc10 FROGGS: I didn't. I think I have accidentally foundthe problem/solution
git submodules
20:48 itz joined
nwc10 the trick is not to end up with libuv compiled with ASAN 20:48
FROGGS ahh!
nwc10 and the confusion is that git clean doesn't recurse into sub modules
so the compilation flag state of the submodules may be wrong 20:49
FROGGS I also updated libuv twice just to let realclean revert it >.<
TimToady japhb: anyway the spectest passed with the memoized new and a clone self, so there's no semantic issue with having a singleton
just wanna do it right to avoid extra .new calls 20:50
TimToady wonders how soon in the setting it actually tries to evaluate a * 20:52
hah, the first time it evaluates is trying to compile RESTRICTED, so there's circularity issues 20:54
*no circularity
I guess the setting does no autopriming 20:56
that makes it easy, I hope
japhb Oh, nice. 20:57
TimToady well, less difficult 20:59
lastofthe Hrmph. Silencing pointer-sign warnings in a way that was meant to follow what the compiler might already be doing is busted. 21:06
At least my first representation of it is busted. 21:07
21:21 itz_ joined 21:25 woolfy joined 21:32 itz joined 21:37 lizmat joined 21:38 itz_ joined
lastofthe glances at write_varint* 21:40
timotimo :( 21:44
that was my work, sorry
lastofthe timotimo: it was just a glance :) 21:46
The four commits from different folks on different dates for a 15 line write_varint9 should mean that it's important :) 21:48
s/should/must/ 21:49
timotimo no, it was just wrong a bunch of times :)
21:50 itz joined
japhb Is it still the plan to enable jit by default for 2014.09? If so, we probably ought to flip the default to enabled now, to increase the number of people testing. 23:00
tadzik +1 23:08
timotimo i think it'd be fine 23:35
TimToady in what sense is it not default now? 23:39
tadzik you need --enable-jit passed to Configure.pl
TimToady oh, you have to config
right
TimToady always just does ". config.status" so forgets
23:40 lastofthe joined
TimToady so +1 from me too 23:40
japhb Given that you can disable jit via the environment, do we still need to have an option to *not* build it in the configure step? 23:41
tadzik depends. Do we still regard it as experimental? 23:44
(did we ever? :)
23:46 itz_ joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!