Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-04-19

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

All times shown according to UTC.

Time Nick Message
02:52 vendethiel joined #p6dev
03:39 lucs joined #p6dev
04:05 sortiz joined #p6dev
04:13 ugexe joined #p6dev
04:18 ugexe joined #p6dev
04:36 ugexe joined #p6dev
05:11 skids joined #p6dev
06:14 [Tux] This is Rakudo version 2016.03-131-gbd44009 built on MoarVM version 2016.03-108-gca1a21a
06:14 [Tux] test            22.047
06:14 [Tux] test-t          12.635
06:14 [Tux] csv-parser      25.626
06:52 RabidGravy joined #p6dev
07:43 lizmat joined #p6dev
07:48 azawawi joined #p6dev
07:48 azawawi hi
07:49 azawawi moritz: it seems that the recently added AppVeyor badge is not working for some reason https://github.com/rakudo/rakudo
07:50 azawawi moritz: https://ci.appveyor.com/project/rakudo/rakudo/branch/nom # Project not found or access denied
07:50 moritz azawawi: probably because I only managed to enable it in the appveyor/moritz account
07:51 azawawi i see
07:51 moritz https://ci.appveyor.com/project/moritz/rakudo
07:57 lizmat m: use nqp; my $b = Blob[uint64].new(42); nqp::rebless($b,Blob[uint8]); dd $b   # was hoping this would be a cheap way for converting an int64 into its constituent bytes
07:57 camelia rakudo-moar bd4400: OUTPUT«This REPR cannot change type␤  in block <unit> at /tmp/BJqG9pylgh line 1␤␤»
07:58 moritz lizmat: possibly with nativecast?
07:59 * lizmat looks up nativecast
08:00 bartolin azawawi moritz: with my PR from yesterday AppVeyor started a build after more than one hour -- but at least the jvm builds timed out after 59 min 59 sec :-(
08:00 nine_ lizmat: won't this lead to problems with endianness?
08:00 TimToady joined #p6dev
08:01 lizmat nine_: I'll pass that bridge when we get to that  :-)
08:03 azawawi bartolin: it is fairly slower than travis ci given that it is one per build
08:03 azawawi moritz: i guess we can disable some builds for windows. Which do you recommend?
08:09 * lizmat looks at cranes passing by smoothly
08:17 moritz azawawi: disable JVM builds
08:31 azawawi moritz: sure
09:29 brrt joined #p6dev
09:32 azawawi would be cool if we have something like `rakudobrew build moar --stable'
09:38 psch fwiw, none of getattr{,_i,_n,_s} works for accessing the $!call Attribute of a Sub+{Native[...]}
09:39 psch i'm not exactly sure what that means, but i think it's probably codegen, plus maybe precomp
09:41 psch ahh
09:41 psch the mixin doesn't work right
09:42 psch the object that get passed to getattr has a REPRData that includes 4 nameToHintMaps, of which the last one is for role Native
09:42 psch the hints start at 15 for $!setup
09:43 psch oh, wait, delegates...
09:43 psch yeah, that was wrong.  the delegate has enough fields, the obj itself doesn't, but that's what a mixin does :/
10:06 pmurias joined #p6dev
10:27 dalek roast: 4d61fbd | usev6++ | integration/weird-errors.t:
10:27 dalek roast: (Re-)fudge test for RT #127878 for JVM
10:27 dalek roast: review: https://github.com/perl6/roast/commit/4d61fbd7ec
10:36 timotimo psch: forgetting some "REAL_DATA" like thing? moar has those all over the place to follow the delegate whenever something's gotten mixed-into
11:11 dalek roast: 70af688 | usev6++ | S (6 files):
11:11 dalek roast: Fudge for JVM to prevent UnwindExceptions
11:11 dalek roast: review: https://github.com/perl6/roast/commit/70af688d2f
11:11 timotimo i expected liz would have already written that mail about floats and bufs, but it seemed not so
11:12 timotimo so i went ahead and shared that knowledge with the mailing list
11:45 psch timotimo: i don't think that's the problem.  as mentioned, there's no way to getattr for $!call (which has repr('NativeCall')) that doesn't complain
11:45 psch timotimo: that makes me think that codegen doesn't work out, somehow
11:46 timotimo oh, it's repr nativecall!
11:46 timotimo have you looked at how the nativecall repr is implemented on the jvm to handle attribute access?
11:47 psch the nativecall repr is the attribute, fwiw
11:47 timotimo oh!
11:47 timotimo not the thing, OK
11:47 psch and that's where it gets extra complicated, kinda :P
11:47 timotimo one thing we do during code gen is try to get a hint to supply for the given attribute
11:47 psch like, nqp-m can use nqp::getattr for a native attribute
11:47 timotimo can you try making it non-obvious to the compiler/optimizer what the value is, or turn optimization off altogether?
11:48 timotimo then we wouldn't try to give it a hint for the attribute index
11:48 timotimo and we may hit a different code path
11:49 psch --optimize=off does the exact same
11:50 psch m: use nqp; class A { has int $.x }; say my int $x = nqp::getattr(A.new, A, '$!x') # this i think matters
11:50 camelia rakudo-moar bd4400: OUTPUT«0␤»
11:50 psch 'cause r-j can't use nqp::getattr for a native attribute
11:50 psch and inlineBind codegen stuff that wants a native_j
11:52 psch anyway, i also tried with 'use lib ...' just now, that also dies the same way
11:53 psch timotimo: i think attr hinting isn't on nqp-j at all.  getattr and friends are all hard-coded with STable.NO_HINT
11:54 timotimo the optimizer may supply the hint, though?
11:54 dalek roast: c264eab | usev6++ | S0 (4 files):
11:54 dalek roast: Fudge (skip) some tests for JVM
11:54 dalek roast:
11:54 dalek roast: all of those tests die with
11:54 dalek roast: 'Cannot access a native attribute as a reference attribute'
11:54 dalek roast: review: https://github.com/perl6/roast/commit/c264eab586
11:56 psch i don't know how: https://github.com/perl6/nqp/blob/master/src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java#L2716
11:56 psch oh duh
11:56 psch half a page down... :)
11:56 timotimo a-ha! something java has that C doesn't! :)
11:57 psch ...half pages down?
11:57 psch i mean, there's a getattr candidate that takes a hint
11:57 timotimo yup, i saw those
11:59 psch hrm
11:59 psch i'm just getting more confused
11:59 psch that snippet above with getattr for a native int also works on r-j
11:59 psch oh wait, that's because i hacked that in there
12:00 psch it doesn't help for repr NativeCall, though
12:00 timotimo oh no we got hacked!
12:00 timotimo :(
12:00 psch yeah, i mean, i'm calling it "hacked" because it's terrible :P
12:00 timotimo i don't understand why the getattr without a _ wouldn't work for your case
12:00 psch https://gist.github.com/peschwa/386df8991a91852c31db9a9e664b379e
12:00 psch i am perfectly correct calling that a hack :P
12:00 timotimo :D
12:01 timotimo yup, seems legit
12:01 psch so, repr NativeCall says it has a 64 bit wide inlined storage spec
12:03 psch ...we don't have a getattr for tc.native_j
12:05 psch hm, i don't get it
12:06 b2gills joined #p6dev
12:08 psch huh, i think that might be the actual problem
12:09 timotimo i .. don't even know what native_j is or why we'd have to have a getattr for that?!?
12:09 * psch .oO( that i don't get it )
12:09 psch native_j is a java object in the TC
12:10 psch like, tc.native_i has the result of a obj.get_attribute_native
12:10 psch and tc.native_j is the same for java objects
12:12 psch still curious how that hasn't mattered before
12:13 psch but then it's probably like 4 or so months that it was somewhat broken
12:13 psch with lots of other breakage inbetween, which might make it hard to find out what caused it... :)
12:13 timotimo oh, huh
12:29 dalek roast: dc23077 | usev6++ | S06-advanced/wrap.t:
12:29 dalek roast: Skip another test on JVM
12:29 dalek roast: review: https://github.com/perl6/roast/commit/dc23077272
12:32 psch well then
12:32 psch how oh how do i instantiate a JavaWrap
12:32 psch 'cause i think that's what i have to do to return the nativecall body from getattr
12:32 dalek roast: 5534e7e | usev6++ | S12-coercion/coercion-types.t:
12:32 dalek roast: Skip test for RT #127841 on JVM
12:32 dalek roast: review: https://github.com/perl6/roast/commit/5534e7e6da
12:34 psch hm, although that might be wrong.  BOOTJava is involved with jvminterop only...
12:36 psch oh, i think i know what caused this
12:37 psch hm, no :P
12:50 skids joined #p6dev
12:55 dalek roast: ecf35bc | usev6++ | S32-str/pack.t:
12:55 dalek roast: Skip tests for 'pack' for JVM
12:55 dalek roast: review: https://github.com/perl6/roast/commit/ecf35bc75b
13:26 dalek roast: 96409d3 | usev6++ | S32-io/socket-recv-vs-read.t:
13:26 dalek roast: Skip two more tests on JVM
13:26 dalek roast: review: https://github.com/perl6/roast/commit/96409d3789
13:40 dalek roast: da9be7b | usev6++ | S32-str/encode.t:
13:40 dalek roast: Fudge utf-16 tests for JVM
13:40 dalek roast: review: https://github.com/perl6/roast/commit/da9be7b53a
14:02 [Coke] p6 release should happen tonight.
14:07 dalek roast: 14a9efd | usev6++ | S10-packages/precompilation.t:
14:07 dalek roast: Fudge (todo) some precomp tests for JVM
14:07 dalek roast: review: https://github.com/perl6/roast/commit/14a9efde5a
14:11 bartolin S02-types/resolved-in-setting.t does not run at all on rakudo-j. would it make sense to mark that file as 'moar only' in t/spectest.data?
14:12 moritz bartolin: yes
14:20 lizmat joined #p6dev
14:28 dalek roast: b0bdd90 | usev6++ | S02-types/int-uint.t:
14:28 dalek roast: Fudge tests for native int overflow/underflow for JVM
14:28 dalek roast: review: https://github.com/perl6/roast/commit/b0bdd90ab7
14:35 dalek rakudo/nom: 75b8966 | azawawi++ | appveyor.yml:
14:35 dalek rakudo/nom: Disable JVM CI builds on Windows (AppVeyor) for performance reasons
14:35 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/75b896690f
14:35 dalek rakudo/nom: 1da9193 | lizmat++ | appveyor.yml:
14:35 dalek rakudo/nom: Merge pull request #749 from azawawi/nom
14:35 dalek rakudo/nom:
14:35 dalek rakudo/nom: Disable JVM CI builds on Windows (AppVeyor) for performance reasons
14:35 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1da9193548
14:36 dalek rakudo/nom: 4bc967a | bartolin++ | t/spectest.data:
14:36 dalek rakudo/nom: Run S02-types/resolved-in-setting.t on moar only
14:36 dalek rakudo/nom:
14:36 dalek rakudo/nom: This file produces an IllegalArgumentException on rakudo-j
14:36 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/4bc967a1bf
14:36 dalek rakudo/nom: baf8ac3 | lizmat++ | t/spectest.data:
14:36 dalek rakudo/nom: Merge pull request #750 from usev6/patch-1
14:36 dalek rakudo/nom:
14:36 dalek rakudo/nom: Run S02-types/resolved-in-setting.t on moar only
14:36 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/baf8ac3777
14:44 lizmat joined #p6dev
14:55 [Sno] joined #p6dev
14:56 [Sno] ah - this channel was meant by lizmat
14:56 * [Sno] is so not-up-to-date :)
14:56 dalek roast: 32110a6 | usev6++ | S17-supply/Channel.t:
14:56 dalek roast: Skip test for RT #127629 on JVM
14:56 dalek roast:
14:56 dalek roast: ... because it often hangs in spectests
14:56 dalek roast: review: https://github.com/perl6/roast/commit/32110a69b0
14:56 [Sno] http://www.netbsd.org/~sno/talks/nrpm/Cross-Compiling-For-Perl-Hackers-Handout.pdf <-- jnthn, timotimo, nine_ ... :)
15:04 [Sno] perlpilot: as lizmat suggested, better here :)
15:04 lizmat joined #p6dev
15:04 perlpilot ah, good point
15:05 [Sno] perlpilot: 9/10 talks about host-files vs. build-sysroot vs. target-sysroot
15:06 perlpilot [Sno]: Are you going to mention "cross compiling for Perl 6 hackers" too?  :)
15:06 [Sno] given you take a "normal" debian-linux to cross-compile yourself a tiny system to run perl6 on it :D
15:07 [Sno] than you first have to make some choices: bootloader, kernel, toolchain (binutils, gcc, ...)
15:08 [Sno] for those toolchain, you first build yourself the toolchain using the host-toolchain but the version you're going to use to cross-compile (build-toolchain)
15:08 [Sno] this build-toolchain is used to compile yourself the cross-toolchain
15:09 [Sno] the build-toolchain is further used to compile build-tools (perl5: miniperl, perl6 - maybe the lua used in configure stage ...)
15:09 [Sno] in my example project I'm going to demonstrate a later niederrhein.pm, I cross-build p6 using a cross-build OpenJDK8
15:10 [Sno] but the cross-openjdk8 is bootstrapped on build-host using jikes -> ecj -> java6 -> java7 -> java8
15:11 [Sno] it got the "which stdlib.h"? from that long explanation?
15:13 dalek nqp: 125eb32 | (Stefan Seifert)++ | src/HLL/World.nqp:
15:13 dalek nqp: Allow for subclasses of HLL::World to use a subclass of CompilationContext
15:13 dalek nqp: review: https://github.com/perl6/nqp/commit/125eb32eb1
15:14 perlpilot [Sno]: How long are they going to let you speak?  Sounds like you've got a lot of ground to cover
15:14 [Sno] perlpilot: we have the entire evening :)
15:15 [Sno] I think, after dinner for around 90min-2hrs
15:16 perlpilot neat.   I hope you inspire some people to try their hand at cross-compiling.
15:16 [Sno] perlpilot: the motivation is finally to enlighten more people wrt. cross-building (or at least be aware of that)
15:17 [Sno] p6 is more important than p5 - but I have much more examples for p5, since I fight with lot's of details in cross-compiling perl6
15:18 [Sno] perl6 build fails the "don't run from target build" rule
15:18 [Sno] and the configure stage doesn't clarify / log properly
15:19 [Sno] I wonder if a patch using https://metacpan.org/release/Config-AutoConf will be accepted for configuring MoarVM, NQP and Rakudo :D
15:25 jnthn [Sno]: Note that all the artefacts you build in NQP are platform-agnostic, and in Rakudo only one thing (written in C) is platform-specific.
15:26 [Sno] jnthn: that's true but wrong :)
15:26 jnthn Virtual machines are wrong? Wow! :P
15:27 [Sno] jnthn: slide 15 explains a little bit why the artifacts must not run in build-environment
15:29 [Sno] nine_: better here than there ;)
15:29 [Sno] nine_: was my fault - I didn't read lizmat's mail not carefully enough
15:30 [Sno] jnthn: did you read the slides and get the sysroot-fiasco?
15:31 [Sno] and read my explanation about host vs. build vs. target environment above?
15:35 * bartolin spectests rakudo-j and hopes for a clean run (after some heavy fudging and with his patches from PR 748 applied)
15:42 dalek rakudo/fix_eval_in_precomp: efe73eb | (Stefan Seifert)++ | src/ (4 files):
15:42 dalek rakudo/fix_eval_in_precomp: Fix EVAL during precompilation
15:42 dalek rakudo/fix_eval_in_precomp:
15:42 dalek rakudo/fix_eval_in_precomp: EVALed code is considered an independent compilation unit that gets compiled
15:42 dalek rakudo/fix_eval_in_precomp: using a new World which contains an independent serialization context. It also
15:42 dalek rakudo/fix_eval_in_precomp: gets its own QAST compiler.
15:42 dalek rakudo/fix_eval_in_precomp:
15:42 dalek rakudo/fix_eval_in_precomp: When a BEGIN time EVAL is run during precompilation of a module, the
15:42 dalek rakudo/fix_eval_in_precomp: independent SC would not be written into any file but would still be referenced
15:42 dalek rakudo/fix_eval_in_precomp: from the outer compilation unit. We therefor use the outer world's
15:42 dalek rakudo/fix_eval_in_precomp: CompilationContext which contains the SC. We also need to share a couple of
15:42 dalek rakudo/fix_eval_in_precomp: other attributes that keep track of the compilation's state.
15:42 dalek rakudo/fix_eval_in_precomp:
15:42 dalek rakudo/fix_eval_in_precomp: The QAST compiler's frames are shared by adding them to the hash that's used
15:43 nine_ for initializing the QAST compiler's frames lookup hash.
15:43 nine_ Fixes RT #124324
15:43 nine_ commit 17523cecfbb2e4e6093cd5bd38c7a554063a1457
15:43 nine_ Refactor sharing the compilation context
15:43 nine_ Put the shared attributes into a subclass of NQP's CompilationContext to get
15:43 nine_ rid of the fragile binding hack.
15:44 nine_ Please, please review: https://github.com/rakudo/rakudo/commit/efe73eb9decfec23b5447e2a379d799ede4aa8ab https://github.com/rakudo/rakudo/commit/17523cecfbb2e4e6093cd5bd38c7a554063a1457
16:03 psch yes!  t/04-nativecall/01-argless.t passes on r-j \o/
16:03 psch still plus debug output, and fixed in a terribly clutchy way, but at least i found the spot to tweak
16:04 psch s/clutchy/kludgy/ # probably, according to the jargon file at least i think
16:05 bartolin psch++
16:06 nine_ psch++ # enjoy that moment!
17:30 vendethiel joined #p6dev
18:07 dalek rakudo/nom: e1e1811 | (Salve J. Nilsen)++ | / (2 files):
18:07 dalek rakudo/nom: Make usage text fit in 80 columns
18:07 dalek rakudo/nom:
18:07 dalek rakudo/nom: Also, update running.pod usage text example to match actual usage text.
18:07 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e1e18112aa
18:07 dalek rakudo/nom: 2d6f5c8 | niner++ | / (2 files):
18:07 dalek rakudo/nom: Merge pull request #751 from sjn/usage-text-1
18:07 dalek rakudo/nom:
18:07 dalek rakudo/nom: Make usage text fit in 80 columns
18:07 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2d6f5c8137
18:11 dalek nqp: 6b71554 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
18:11 dalek nqp: [js] Remove old TODO.
18:11 dalek nqp: review: https://github.com/perl6/nqp/commit/6b71554a5a
18:11 dalek nqp: f6b5db3 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
18:11 dalek nqp: [js] Avoid setting the REPR names manually.
18:11 dalek joined #p6dev
18:27 psch something tangentially related i found while hunting the jvm NC bug:
18:27 psch m: my $name = "foo"; say "$name.{1+1}"
18:27 camelia rakudo-moar 2d6f5c: OUTPUT«Type Str does not support associative indexing.␤  in block <unit> at /tmp/_MiGDdfart line 1␤␤Actually thrown at:␤  in block <unit> at /tmp/_MiGDdfart line 1␤␤»
18:27 psch that apparently used to work, 'cause that's how $*VM.platform-library-name does it in the jvm path
18:38 psch in any case, i'm still kinda stuck how to make this a good solution
18:39 psch the problem as it exists is that $!call is codegen'd to be accessible with get_attribute_native, but we don't lead into that get_attribute_native anywhere
18:40 psch so either i hack around that in Ops.getattr somehow, which would either be able to learn the native type of the attribute (which we don't have a means of finding out, afaict) or would catch and throw up to 4 layers of exceptions
18:40 psch or there's a smart solution that gets closer to emulating the "chasing pointers" style of moar
18:40 psch ...at least that's what i understand moar is doing
18:42 timotimo :S
18:43 psch my hunch would something akin to P6OpaqueBaseInstance.resolveAttribute, a la resolveAttributeType maybe
18:43 psch which could be ref, int, str, num, obj
18:44 psch i don't know how well that fits into sixmodel, though
18:44 psch and, well, moar doesn't even need it so maybe it's a bad idea..? vOv
18:44 timotimo to be honest i'm still confused why native attributes are even a thing
18:45 psch timotimo: huh?  like, int?
18:48 timotimo no, i mean java native
18:49 psch oh
18:49 psch the comments and commit messages seem to suggest inlining..?
18:50 timotimo hm, right
18:50 timotimo but how come we don't just box it into a proper object on the way out?
18:50 timotimo like, p6opaque can inline other things's REPRs and REPRData
18:50 timotimo that's enough to turn it into a normal object on the way out?
18:51 timotimo i must be missing something
18:51 psch well, it needs to have a StorageSpec.INLINED to be inlined i suppose
18:51 psch and nqp-j codegen says that that already means it gets accessed by REPR.get_attribute_native
18:51 timotimo huh
18:52 timotimo how would things change when we claim NativeCall *isn't* inlinable?
18:52 psch then my first idea for fixing it could probably work
18:52 psch 'cause that was to fix inlineGet and inlineBind to add/strip NativeCallInstance around the NativeCallBody
18:53 psch but then it probably also wouldn't get inlined... vOv
18:56 psch i do lean towards "just hack it together while relying on exceptions figuring out the type"
18:56 psch because it fixes two problems here, which is the NC bug as well as general access to native attrs via nqp::getattr
18:56 psch s/figuring/to figure/
18:57 psch but that's only from a "it'll at least be solved" perspective, because it'd probably make native attr access via nqp::getattr completely not worth it at all because really slow
18:57 psch as mentioned, in the worst case that's throwing and catching 4 exceptions
19:04 psch oh duh
19:04 psch tc.native_type exists
19:05 psch which means there's only one catch involved
19:05 timotimo hooray
19:07 psch well, figuring out the boxing type for the NATIVE_JVM_OBJ case is kinda iffy, but otherwise it should be fine i think
19:15 psch i mean, assuming a general case where it's not known that it's a NativeCallBody and needs a NativeCallInstance
19:20 sortiz joined #p6dev
19:47 psch https://gist.github.com/peschwa/1339399161679786bd91439bea6ca6ec
19:48 psch i think i'll take that for today
19:49 timotimo that's better than exclusively fails :)
19:49 timotimo which is what it was before, right?
19:50 psch yeah, previous was exclusively "No subtests run" iirc
19:50 timotimo excellent!
19:50 psch 'cause the BUILDPLAN for a Sub+{Native[...]} always failed
19:56 dalek nqp: 49dfcad | peschwa++ | src/vm/jvm/runtime/org/perl6/nqp/sixmodel/reprs/P6OpaqueBaseInstance.java:
19:56 dalek nqp: Throw meaningful things from badReference and badNative.
19:56 dalek nqp:
19:56 dalek nqp: We need to distinguish them for native-capable getattr, because catching all
19:56 dalek nqp: RuntimeExceptions there muddles the ones we care about (which is badReference)
19:56 dalek nqp: up with e.g. "No such attribute".
19:56 dalek nqp: review: https://github.com/perl6/nqp/commit/49dfcad137
19:56 dalek nqp: 5981bf0 | peschwa++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java:
19:56 dalek nqp: Handle all kind of attribute access via getattr.
19:56 dalek nqp:
19:56 dalek nqp: The NATIVE_JVM_OBJ case is clearly a bit brittle like this, but I haven't come
19:56 dalek nqp: across a case where that's not what we want.  Of course this doesn't mean there
19:56 dalek nqp: isn't one...
19:56 dalek nqp: review: https://github.com/perl6/nqp/commit/5981bf0439
19:56 dalek rakudo/nom: abfb8da | peschwa++ | tools/build/NQP_REVISION:
19:56 dalek rakudo/nom: Bump NQP_REVISION
19:56 dalek rakudo/nom:
19:56 dalek rakudo/nom: This gets us a more moar-like handling of nqp::getattr, which is transparent to
19:56 dalek rakudo/nom: native attributes.
19:56 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/abfb8dadfd
19:57 psch huh, dalek didn't mention d6ed4c1 and didn't get floodkicked either..?
19:57 timotimo huh
19:58 psch 'cause there's another commit after the NQP_REVISION bump
20:00 psch well, it shows in the GH web interface, so there vOv
20:00 jnthn nine_: Really tired right now, but got all day for Perl 6 things tomorrow, so will review your two commits then :)
20:04 nine_ ok :)
20:33 dalek roast: 68a55df | usev6++ | S0 (3 files):
20:33 dalek roast: Unfudge tests for JVM
20:33 dalek roast:
20:33 dalek roast: fixed by nqp commit 5981bf0439, psch++
20:33 dalek roast: review: https://github.com/perl6/roast/commit/68a55dfce0
21:19 geekosaur joined #p6dev
21:21 hankache joined #p6dev
21:40 lizmat joined #p6dev
21:55 synopsebot6 joined #p6dev
22:48 ugexe joined #p6dev
23:03 lizmat intriguing: https://arxiv.org/abs/1604.03641
23:13 [Coke] starting release.
23:16 dalek nqp: 804fdec | coke++ | tools/build/MOAR_REVISION:
23:16 dalek nqp: bump MOAR revision
23:16 dalek nqp: review: https://github.com/perl6/nqp/commit/804fdecc28
23:16 dalek nqp: 4011515 | coke++ | VERSION:
23:16 dalek nqp: bump VERSION
23:16 dalek nqp: review: https://github.com/perl6/nqp/commit/40115150b7
23:17 [Coke] is nqp-js good enough to run as part of the release now?
23:17 [Coke] (i'll find out soon enough...)
23:20 [Coke] guess not.
23:54 [Coke] nqp 2016.04 done, tagged, tarballed
23:56 [Coke] rant: instructions suggest "perl6 tools/contributes.pl6" but that will never work if you have an installed p6 and a fresh dev.

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