Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-09-05

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

All times shown according to UTC.

Time Nick Message
00:39 avuserow joined #moarvm
01:58 FROGGS_ joined #moarvm
04:55 lastofthe left #moarvm
06:37 sergot morning o/
06:51 tokuhirom left #moarvm
07:04 brrt joined #moarvm
07:04 brrt SuchVM.. /me likes
07:04 brrt when it is time to deprecate MoarVM, we'll use that name
07:06 woolfy left #moarvm
07:13 xiaomiao joined #moarvm
07:17 zakharyas joined #moarvm
08:21 xiaomiao joined #moarvm
08:21 lizmat joined #moarvm
08:33 dalek MoarVM: 65e7bfd | moritz++ | build/probe.pm:
08:33 dalek MoarVM: Avoid unaligned reads on ARMv7
08:33 dalek MoarVM:
08:33 dalek MoarVM: closes issue 137. Patch courtesy of throwaway-moar-arm++
08:33 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/65e7bfdef2
08:50 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.
10:39 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:44 FROGGS daxim: have you created new issues?
10:44 daxim no, still untouched since a month.
10:45 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
10:45 FROGGS ahh, wait, let me try to find your issue
10:46 daxim moarvm #123
10:46 FROGGS https://github.com/MoarVM/MoarVM/issues/123
10:46 FROGGS found it
10:47 FROGGS your libuv is newer... we use 0.11.18, you use 0.11.28
10:52 FROGGS daxim: issue #81 is also related to libuv version mismatch...
10:53 daxim when can I expect a fix? mind that this is not only for me, but blocking packaging
10:54 FROGGS I try to come up with a solution quickly
11:13 lizmat joined #moarvm
11:35 lastofthe joined #moarvm
11:36 dalek MoarVM: ae6fb2f | (Tobias Leich)++ | / (2 files):
11:36 dalek MoarVM: conditionally set include dirs and install rules (e.g. --has-libuv)
11:36 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ae6fb2f024
11:37 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
11:38 FROGGS daxim: now I'd need a libuv on my system to test other versions then the bundled one :S
11:39 moritz lastofthe: I just applied it, I think nwc10++ is to "blame"
11:41 lastofthe I'm to blame, just saying thanks :)
11:41 lastofthe (for the application)
11:50 moritz oh
11:50 moritz lastofthe++
12:08 itz joined #moarvm
12:20 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
12:20 jnthn OK.
12:20 FROGGS jnthn: that was my plan B, update to that version if I cannot install such a version with apt
12:21 FROGGS 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...
12:21 jnthn FROGGS: OK. I leave it with you.
12:21 jnthn Lemme know if I need to look at something
12:21 FROGGS but it seems even a newer ubuntu offers an older libuv (I'm currently upgrading to 14.04)
12:21 jnthn grmbl
12:21 FROGGS k, will do it as plan A in a bit :o)
12:21 jnthn .oO( Bundling: the worst option except all the others... )
12:26 * jnthn has a 3-day weekend
12:26 jnthn Hopefully I don't spend all this one being ill, like last one...
12:26 nwc10 yay!
12:26 nwc10 what's the excuse for a public holiday?
12:27 jnthn No idea, guy at work said something about the moon :)
12:27 jnthn But it isn't even a full moon yet, so...hmm. :)
12:27 FROGGS ohh, then it is not "Mars is bright tonight" :o)
13:00 lizmat joined #moarvm
14:46 jnthn efff2fdbb8b8 breaks the build on MSVC
14:46 itz_ joined #moarvm
14:49 dalek MoarVM: 16ecaa8 | jonathan++ | src/moar.h:
14:49 dalek MoarVM: Unbust the MSVC build.
14:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/16ecaa8317
15:05 lizmat joined #moarvm
15:07 dalek joined #moarvm
15:12 kjs_ joined #moarvm
15:15 [Coke] jnthn++
15:16 timotimo oops, that was me ;(
15:17 [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...
15:19 jnthn 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 jnthn Otherwise the compiler barfs over the inconsistent export semantics...
15:19 jnthn s/one a/on a/
15:31 itz joined #moarvm
15:42 dalek MoarVM: 64f5ecb | jonathan++ | src/core/oplist:
15:42 dalek MoarVM: Fix spell-o.
15:42 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/64f5ecb93a
15:42 dalek MoarVM: 92a3472 | jonathan++ | / (11 files):
15:42 dalek MoarVM: Add a way to specify a type needs finalization.
15:42 dalek MoarVM:
15:42 dalek MoarVM: Nothing is done with this information as of yet, except storing it on
15:42 dalek MoarVM: the type's STable.
15:42 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/92a3472f1f
15:44 timotimo oooh, we're getting some more lazy initialization stuff
15:44 jnthn No
15:44 FROGGS joined #moarvm
15:44 jnthn The stuff nine++ needs.
15:45 timotimo ah!
15:45 timotimo aah, *finalization*
15:45 timotimo as in ... finalization!
15:46 jnthn ... :P
15:47 jnthn 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:48 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:49 jnthn timotimo: Maybe, but they're relatively rare...
15:49 jnthn Would JIT better though
15:50 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...
15:50 timotimo maybe we can do the check with existskey twice first and kick them out of the hash if they are?
15:50 jnthn That's not such a bad idea...
15:50 timotimo hm, but the caps are probably not something we'd be allowed to mutate
15:50 jnthn Right
15:50 jnthn Well
15:50 timotimo and cloning that... :\
15:50 jnthn Other way is to do an ordat to get the first char of the name and check if it's the $ char...
15:51 timotimo +                        if $name && nqp::ordat($name, 0) == 36 && ($name eq '$!from' || $name eq '$!to') {
15:51 timotimo that's already what your patch does :)
15:51 jnthn oh o.O
15:52 jnthn (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
15:52 timotimo so it'd be nicer to look at in the code
15:52 timotimo or at least i think we have that
15:52 jnthn Don't remember us having it.
15:52 timotimo at the very least in moar's code-gen.
15:53 FROGGS timotimo: might make sense to bench every change your make, what do you think?
15:53 timotimo heh.
15:54 itz_ joined #moarvm
16:24 TimToady I assume that's finalization as in "destroy", not as is "class is closed, final"
16:25 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
16:26 jnthn TimToady: Finalization is the widely used term for this in the GC world.
16:26 TimToady ain't overloading wonderful...
16:27 jnthn Thankfully, language exists within a context... :)
16:27 jnthn The src/gc/ context in this case :)
16:28 TimToady maybe we need a different term for what happens to a class...closed and...copyrighted, so no derivative works
16:29 TimToady closed and...neutered...
16:29 * jnthn has seen "sealed" used for it
16:29 TimToady well, that's kind of like a vasectomy...
16:29 jnthn canonize...
16:29 nwc10 jnthn: if you keep ++ing nine we'll loose track of whether he's now seventeen, fourty two, or several hundren
16:30 nwc10 er, hundred
16:30 TimToady closed and "fixed" :)
16:30 jnthn dead...uh...stable :)
16:30 TimToady not dead yet!
16:31 TimToady just...endangered, and resting...
16:31 TimToady senescent...
16:31 TimToady close and past caring :)
16:32 TimToady closed and shuttered
16:33 TimToady "not taking new patients"
16:35 diakopter cauterized?
16:37 diakopter heh, pun on sealed could be seared
16:37 diakopter (also has the engrish connotation)
16:38 timotimo shelved, shelled? crusty? breaded?
16:42 TimToady privatized and plundered, to go in the economics direction
16:43 diakopter heh more like overregulated
16:44 diakopter to go in the other economics direction
16:47 TimToady don't mess with me, don't try to be like me
17:03 lastofthe joined #moarvm
17:12 [Coke] moar is failing t/fudgeandrun t/spec/integration/99problems-51-to-60.t, but the test passes with MVM_SPESH_DISABLE=1
17:15 jnthn [Coke]: Yes, more specifically MVM_SPESH_INLINE_DISABLE, I believe
17:15 jnthn [Coke]: I didn't have much luck figuring out *why* yet, though :(
17:27 zakharyas joined #moarvm
17:32 [Coke] need a ticket?
17:37 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:39 japhb 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:40 TimToady well, there will still be levels of closures, till the inliner kicks in
17:41 TimToady you can't just ignore that map in the middle
17:41 TimToady .oO(map-in-the-middle attack!)
17:43 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:46 TimToady yes, one of the things we need to do is return raw arrays rather parcelizing at every level
17:47 TimToady "here's an unadorned batch of result"
17:47 TimToady *sults
17:47 TimToady or in the case of a negotiated lazy, this closure returns exactly one unadorned result
17:49 TimToady 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 ...
17:49 japhb Right.
17:49 TimToady everyone's using indexing to reprocess each array
17:49 TimToady the Whatevers are the .gimme(*) and .reify(*) probably
17:50 TimToady we could really use smart pointers into arrays, a la Go
17:50 japhb Ah, yes.  WBNI that case could use a singleton instead
17:50 japhb TimToady: You mean Go's "slice" concept?
17:51 TimToady yeah, something like that
17:51 TimToady an array pointer that knows its bounds, basically
17:51 TimToady it's one of the C fixes that Go actually got right, I think
17:52 TimToady and something we can probably use for pointers into native arrays
17:53 TimToady on JVM, of course, you probably have to remember the original structure to index into
17:53 TimToady but that can be largely transparent
17:54 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
17:58 timotimo yes, please
17:58 TimToady maybe 10_000_000 Whatever is LHF, since * is supposed to be a singleton
17:58 TimToady are we doing Whatever.new all over the place?
17:59 timotimo hopefully not, but perhaps we clone() it all the time?
17:59 TimToady clone on a singleton should just return self
18:01 japhb Whatever's method new() does nqp::create(self), and there's no clone override.
18:03 TimToady go for it!
18:05 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:06 timotimo since it usually just promotes 11kb it should only do a full collection very few times all in all
18:06 timotimo i think it waits for 30 mb of promoted data to accumulate before doing a gen2
18:07 timotimo 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 timotimo though ... perhaps a scatter plot is usually used for data where x and y have some expected correlation
18:09 TimToady hmm, ./libmoar.so: undefined reference to `MVM_gc_finalize_set'
18:10 TimToady did jnthn forget to check something in?
18:11 TimToady needs reconfig is all
18:11 timotimo ah
18:11 TimToady make clean ain't good enough
18:15 * TimToady is working on a reverse merge back into dynamic_gen2_tuning to keep it from getting too out of sync
18:16 TimToady (spectesting)
18:19 timotimo i wonder what i should test to figure out if the branch is mergable
18:21 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 #moarvm
18:28 teodozjan joined #moarvm
18:47 * 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:54 itz joined #moarvm
19:06 kjs_ joined #moarvm
19:09 brrt joined #moarvm
19:23 dalek MoarVM/libuv-0.11.29: fce509b | (Tobias Leich)++ | / (6 files):
19:23 dalek MoarVM/libuv-0.11.29: update libuv from 0.11.18 to 0.11.29
19:23 dalek MoarVM/libuv-0.11.29:
19:23 dalek MoarVM/libuv-0.11.29: This also includes minimal adjustments to our codebase, for example
19:23 dalek MoarVM/libuv-0.11.29: callbacks only get a handle and not an additional status and uv_fs_read
19:23 dalek MoarVM/libuv-0.11.29: wants an uv_but_t now instead of char*.
19:24 dalek MoarVM/libuv-0.11.29: review: https://github.com/MoarVM/MoarVM/commit/fce509b4fb
19:24 FROGGS testing this now on windows...
19:26 FROGGS damn, now I get spectest fails :(
19:28 FROGGS ohh
19:35 dalek MoarVM/libuv-0.11.29: 8a98741 | (Tobias Leich)++ | src/io/syncfile.c:
19:35 dalek MoarVM/libuv-0.11.29: uv_fs_write also takes an uv_buf_t instead of char*
19:35 dalek MoarVM/libuv-0.11.29: review: https://github.com/MoarVM/MoarVM/commit/8a98741d24
19:39 kjs_ joined #moarvm
19:45 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:48 nwc10 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 nwc10 so on little endian systems:
19:48 nwc10 lit_i32 = 13,
19:48 nwc10 lit_i16 = 13,
19:48 nwc10 lit_str_idx = 13,
19:49 nwc10 and all is happy (MVM_spesh_get_string(...) returns non-NULL, try_get_slot() loops but returns -1
19:49 nwc10 on big endian systems
19:49 nwc10 lit_i32 = 851968, lit_i16 = 13,
19:49 nwc10 lit_n32 = 1.19386145e-39, lit_str_idx = 851968, callsite_idx = 13,
19:50 nwc10 so MVM_spesh_get_string(...) is
19:50 nwc10 return g->sf->body.cu->body.strings[o.lit_str_idx];
19:51 nwc10 and o.lit_str_idx is 851968 not 13
19:51 nwc10 and g->sf->body.cu->body.strings[851968] is NULL
19:51 nwc10 and SEGV later on
19:51 nwc10 and, what I can't work out is what codeis wrong - is the write using lit_i16 wrong
19:51 nwc10 or the read using lit_str_idx
19:52 nwc10 as best I can work out, 3rd argument of MVM_OP_getattrs_n is 16 bit
19:52 nwc10 3rd argument of MVM_OP_getattr_n is 32 bit
19:52 nwc10 so, is that part of the confusion?
19:53 * lastofthe starts a portability slow clap
19:55 nwc10 what's that meant to acchieve?
19:56 lastofthe me?
19:56 nwc10 yes. I'm not sure what a slow clap is for
19:57 * 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 :)
19:57 nwc10 ah OK
19:57 lastofthe Or even a subset of everyone :)
19:58 lastofthe 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:59 nwc10 I suspect you more likely benefitted from the my ARM work that preceded the PPC work
19:59 lastofthe Ahh, make sense.
20:00 nwc10 and the PPC work was partly someone else - I forget who
20:00 nwc10 I mostly just found and fixed the last missing bit
20:00 lastofthe It usually is :) (partly someone else)
20:04 lastofthe 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
20:04 FROGGS nwc10: but if something is going to get weird, please let me know
20:05 dalek MoarVM: fce509b | (Tobias Leich)++ | / (6 files):
20:05 dalek MoarVM: update libuv from 0.11.18 to 0.11.29
20:05 dalek MoarVM:
20:05 dalek MoarVM: This also includes minimal adjustments to our codebase, for example
20:05 dalek MoarVM: callbacks only get a handle and not an additional status and uv_fs_read
20:05 dalek MoarVM: wants an uv_but_t now instead of char*.
20:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fce509b4fb
20:05 dalek MoarVM: 8a98741 | (Tobias Leich)++ | src/io/syncfile.c:
20:05 dalek MoarVM: uv_fs_write also takes an uv_buf_t instead of char*
20:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8a98741d24
20:12 nwc10 FROGGS: for me, t/nqp/19-file-ops.t seems to be hanging
20:12 FROGGS hmmm
20:13 FROGGS nwc10: it passes instantly on my box
20:14 nwc10 OK, some games with strace and ps suggest that moar was waiting on epoll with a zombie sh as a child
20:14 nwc10 no, I don't know why
20:15 FROGGS O.o
20:29 itz_ joined #moarvm
20:33 lizmat SPW shutting down for today...  see you later&
20:34 * japhb gets out of his block of meetings
20:36 japhb 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:37 itz joined #moarvm
20:37 TimToady japhb: we currently compile every * down to Whatever.new...  >.<
20:38 japhb Ouch.
20:38 japhb Why do we even create a new object?  Why not just pass the type object around?
20:38 TimToady as a datapoint, changing new to read our $star //= nqp::create(self) works, but is not yet optimal
20:38 TimToady we should create a singleton early and just use it
20:38 japhb (Meaning, changing that to clone is nice and all, but why not have no method call at all?)
20:39 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?
20:39 TimToady we would like to have Whatever undefined and * defined
20:39 japhb Ah, interesting.
20:39 japhb Why?
20:40 japhb (I've got a guess as to the reasoning, but I'm curious ....)
20:40 nwc10 FROGGS: regular debugging build is fine
20:40 nwc10 there's something very screwy with ASAN
20:40 nwc10 under ASAN, things end up with that deadlock hang
20:40 * TimToady is trying to remember where the distinction is important
20:41 TimToady 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 :/
20:42 TimToady oh, well, what about when you want to call *.^methods vs Whatever.^methods ?
20:42 itz_ joined #moarvm
20:42 japhb Unless it's been mixed into, wouldn't that be the same?
20:42 TimToady m: say *.DEFINITE
20:42 nwc10 FROGGS: well, I have no good idea, and I'm going to go to bed
20:42 camelia rakudo-moar fd9238: OUTPUT«True␤»
20:43 japhb m: say (3.^methods) eqv (Int.^methods)
20:43 camelia rakudo-moar fd9238: OUTPUT«True␤»
20:43 FROGGS gnight nwc10
20:43 TimToady no, what if you want to autoprime .^methods?
20:43 TimToady m: say (*.^methods) eqv (Whatever.^methods)
20:43 camelia rakudo-moar fd9238: OUTPUT«WhateverCode.new()␤»
20:44 TimToady hah
20:44 japhb Oh!
20:44 japhb Duh, I see what you mean.
20:44 TimToady use vs mention
20:45 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
20:45 japhb Don't we already do that for e.g. Inf?
20:48 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
20:48 nwc10 git submodules
20:48 itz joined #moarvm
20:48 nwc10 the trick is not to end up with libuv compiled with ASAN
20:48 FROGGS ahh!
20:48 nwc10 and the confusion is that git clean doesn't recurse into sub modules
20:49 nwc10 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 >.<
20:49 TimToady japhb: anyway the spectest passed with the memoized new and a clone self, so there's no semantic issue with having a singleton
20:50 TimToady just wanna do it right to avoid extra .new calls
20:52 * TimToady wonders how soon in the setting it actually tries to evaluate a *
20:54 TimToady hah, the first time it evaluates is trying to compile RESTRICTED, so there's circularity issues
20:54 TimToady *no circularity
20:56 TimToady I guess the setting does no autopriming
20:56 TimToady that makes it easy, I hope
20:57 japhb Oh, nice.
20:59 TimToady well, less difficult
21:06 lastofthe Hrmph.  Silencing pointer-sign warnings in a way that was meant to follow what the compiler might already be doing is busted.
21:07 lastofthe At least my first representation of it is busted.
21:21 itz_ joined #moarvm
21:25 woolfy joined #moarvm
21:32 itz joined #moarvm
21:37 lizmat joined #moarvm
21:38 itz_ joined #moarvm
21:40 * lastofthe glances at write_varint*
21:44 timotimo :(
21:44 timotimo that was my work, sorry
21:46 lastofthe timotimo: it was just a glance :)
21:48 lastofthe The four commits from different folks on different dates for a 15 line write_varint9 should mean that it's important :)
21:49 lastofthe s/should/must/
21:49 timotimo no, it was just wrong a bunch of times :)
21:50 itz joined #moarvm
23:00 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:08 tadzik +1
23:35 timotimo i think it'd be fine
23:39 TimToady in what sense is it not default now?
23:39 tadzik you need --enable-jit passed to Configure.pl
23:39 TimToady oh, you have to config
23:39 TimToady right
23:39 * TimToady always just does ". config.status" so forgets
23:40 lastofthe joined #moarvm
23:40 TimToady so +1 from me too
23:41 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:44 tadzik depends. Do we still regard it as experimental?
23:44 tadzik (did we ever? :)
23:46 itz_ joined #moarvm

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