02:52 vendethiel joined 03:39 lucs joined 04:05 sortiz joined 04:13 ugexe joined 04:18 ugexe joined 04:36 ugexe joined 05:11 skids joined
[Tux] This is Rakudo version 2016.03-131-gbd44009 built on MoarVM version 2016.03-108-gca1a21a 06:14
test 22.047
test-t 12.635
csv-parser 25.626
06:52 RabidGravy joined 07:43 lizmat joined 07:48 azawawi joined
azawawi hi 07:48
moritz: it seems that the recently added AppVeyor badge is not working for some reason github.com/rakudo/rakudo 07:49
moritz: ci.appveyor.com/project/rakudo/rak...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
azawawi i see 07:51
moritz ci.appveyor.com/project/moritz/rakudo
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ā¤ā¤Ā»
moritz lizmat: possibly with nativecast? 07:58
lizmat looks up nativecast 07:59
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
lizmat nine_: I'll pass that bridge when we get to that :-) 08:01
azawawi bartolin: it is fairly slower than travis ci given that it is one per build 08:03
moritz: i guess we can disable some builds for windows. Which do you recommend?
lizmat looks at cranes passing by smoothly 08:09
moritz azawawi: disable JVM builds 08:17
azawawi moritz: sure 08:31
09:29 brrt joined
azawawi would be cool if we have something like `rakudobrew build moar --stable' 09:32
psch fwiw, none of getattr{,_i,_n,_s} works for accessing the $!call Attribute of a Sub+{Native[...]} 09:38
i'm not exactly sure what that means, but i think it's probably codegen, plus maybe precomp 09:39
ahh 09:41
the mixin doesn't work right
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
the hints start at 15 for $!setup
oh, wait, delegates... 09:43
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
dalek ast: 4d61fbd | usev6++ | integration/weird-errors.t:
(Re-)fudge test for RT #127878 for JVM
 10:27
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 10:36
dalek ast: 70af688 | usev6++ | S (6 files):
Fudge for JVM to prevent UnwindExceptions
 11:11
timotimo i expected liz would have already written that mail about floats and bufs, but it seemed not so
so i went ahead and shared that knowledge with the mailing list 11:12
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
timotimo: that makes me think that codegen doesn't work out, somehow
timotimo oh, it's repr nativecall! 11:46
have you looked at how the nativecall repr is implemented on the jvm to handle attribute access?
psch the nativecall repr is the attribute, fwiw 11:47
timotimo oh!
not the thing, OK
psch and that's where it gets extra complicated, kinda :P
timotimo one thing we do during code gen is try to get a hint to supply for the given attribute
psch like, nqp-m can use nqp::getattr for a native attribute
timotimo can you try making it non-obvious to the compiler/optimizer what the value is, or turn optimization off altogether?
then we wouldn't try to give it a hint for the attribute index 11:48
and we may hit a different code path
psch --optimize=off does the exact same 11:49
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ā¤Ā»
psch 'cause r-j can't use nqp::getattr for a native attribute
and inlineBind codegen stuff that wants a native_j
anyway, i also tried with 'use lib ...' just now, that also dies the same way 11:52
timotimo: i think attr hinting isn't on nqp-j at all. getattr and friends are all hard-coded with STable.NO_HINT 11:53
timotimo the optimizer may supply the hint, though? 11:54
dalek ast: c264eab | usev6++ | S0 (4 files):
Fudge (skip) some tests for JVM

all of those tests die with
  'Cannot access a native attribute as a reference attribute'
psch i don't know how: github.com/perl6/nqp/blob/master/s...java#L2716 11:56
oh duh
half a page down... :)
timotimo a-ha! something java has that C doesn't! :)
psch ...half pages down? 11:57
i mean, there's a getattr candidate that takes a hint
timotimo yup, i saw those
psch hrm 11:59
i'm just getting more confused
that snippet above with getattr for a native int also works on r-j
oh wait, that's because i hacked that in there
it doesn't help for repr NativeCall, though 12:00
timotimo oh no we got hacked!
:(
psch yeah, i mean, i'm calling it "hacked" because it's terrible :P
timotimo i don't understand why the getattr without a _ wouldn't work for your case
psch gist.github.com/peschwa/386df8991a...9e664b379e
i am perfectly correct calling that a hack :P
timotimo :D
yup, seems legit 12:01
psch so, repr NativeCall says it has a 64 bit wide inlined storage spec
...we don't have a getattr for tc.native_j 12:03
hm, i don't get it 12:05
12:06 b2gills joined
psch huh, i think that might be the actual problem 12:08
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 )
native_j is a java object in the TC
like, tc.native_i has the result of a obj.get_attribute_native 12:10
and tc.native_j is the same for java objects
still curious how that hasn't mattered before 12:12
but then it's probably like 4 or so months that it was somewhat broken 12:13
with lots of other breakage inbetween, which might make it hard to find out what caused it... :)
timotimo oh, huh
dalek ast: dc23077 | usev6++ | S06-advanced/wrap.t:
Skip another test on JVM
 12:29
psch well then 12:32
how oh how do i instantiate a JavaWrap
'cause i think that's what i have to do to return the nativecall body from getattr
dalek ast: 5534e7e | usev6++ | S12-coercion/coercion-types.t:
Skip test for RT #127841 on JVM
psch hm, although that might be wrong. BOOTJava is involved with jvminterop only... 12:34
oh, i think i know what caused this 12:36
hm, no :P 12:37
12:50 skids joined
dalek ast: ecf35bc | usev6++ | S32-str/pack.t:
Skip tests for 'pack' for JVM
 12:55
ast: 96409d3 | usev6++ | S32-io/socket-recv-vs-read.t:
Skip two more tests on JVM
 13:26
ast: da9be7b | usev6++ | S32-str/encode.t:
Fudge utf-16 tests for JVM
 13:40
[Coke] p6 release should happen tonight. 14:02
dalek ast: 14a9efd | usev6++ | S10-packages/precompilation.t:
Fudge (todo) some precomp tests for JVM
 14:07
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:11
moritz bartolin: yes 14:12
14:20 lizmat joined
dalek ast: b0bdd90 | usev6++ | S02-types/int-uint.t:
Fudge tests for native int overflow/underflow for JVM
 14:28
kudo/nom: 75b8966 | azawawi++ | appveyor.yml:
Disable JVM CI builds on Windows (AppVeyor) for performance reasons
 14:35
kudo/nom: 1da9193 | lizmat++ | appveyor.yml:
Merge pull request #749 from azawawi/nom

Disable JVM CI builds on Windows (AppVeyor) for performance reasons
kudo/nom: 4bc967a | bartolin++ | t/spectest.data:
Run S02-types/resolved-in-setting.t on moar only

This file produces an IllegalArgumentException on rakudo-j		 14:36
kudo/nom: baf8ac3 | lizmat++ | t/spectest.data:
Merge pull request #750 from usev6/patch-1

Run S02-types/resolved-in-setting.t on moar only
14:44 lizmat joined 14:55 [Sno] joined
[Sno] ah - this channel was meant by lizmat 14:56
[Sno] is so not-up-to-date :)
dalek ast: 32110a6 | usev6++ | S17-supply/Channel.t:
Skip test for RT #127629 on JVM

  ... because it often hangs in spectests
[Sno] www.netbsd.org/~sno/talks/nrpm/Cros...andout.pdf <-- jnthn, timotimo, nine_ ... :)
perlpilot: as lizmat suggested, better here :) 15:04
15:04 lizmat joined
perlpilot ah, good point 15:04
[Sno] perlpilot: 9/10 talks about host-files vs. build-sysroot vs. target-sysroot 15:05
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
than you first have to make some choices: bootloader, kernel, toolchain (binutils, gcc, ...) 15:07
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
this build-toolchain is used to compile yourself the cross-toolchain
the build-toolchain is further used to compile build-tools (perl5: miniperl, perl6 - maybe the lua used in configure stage ...) 15:09
in my example project I'm going to demonstrate a later niederrhein.pm, I cross-build p6 using a cross-build OpenJDK8
but the cross-openjdk8 is bootstrapped on build-host using jikes -> ecj -> java6 -> java7 -> java8 15:10
it got the "which stdlib.h"? from that long explanation? 15:11
dalek p: 125eb32 | (Stefan Seifert)++ | src/HLL/World.nqp:
Allow for subclasses of HLL::World to use a subclass of CompilationContext
 15:13
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 :)
I think, after dinner for around 90min-2hrs 15:15
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)
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:17
perl6 build fails the "don't run from target build" rule 15:18
and the configure stage doesn't clarify / log properly
I wonder if a patch using metacpan.org/release/Config-AutoConf will be accepted for configuring MoarVM, NQP and Rakudo :D 15:19
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:25
[Sno] jnthn: that's true but wrong :) 15:26
jnthn Virtual machines are wrong? Wow! :P
[Sno] jnthn: slide 15 explains a little bit why the artifacts must not run in build-environment 15:27
nine_: better here than there ;) 15:29
nine_: was my fault - I didn't read lizmat's mail not carefully enough
jnthn: did you read the slides and get the sysroot-fiasco? 15:30
and read my explanation about host vs. build vs. target environment above? 15:31
bartolin spectests rakudo-j and hopes for a clean run (after some heavy fudging and with his patches from PR 748 applied) 15:35
dalek rakudo/fix_eval_in_precomp: efe73eb | (Stefan Seifert)++ | src/ (4 files): 15:42
rakudo/fix_eval_in_precomp: Fix EVAL during precompilation
rakudo/fix_eval_in_precomp:
rakudo/fix_eval_in_precomp: EVALed code is considered an independent compilation unit that gets compiled
rakudo/fix_eval_in_precomp: using a new World which contains an independent serialization context. It also
rakudo/fix_eval_in_precomp: gets its own QAST compiler.
rakudo/fix_eval_in_precomp:
rakudo/fix_eval_in_precomp: When a BEGIN time EVAL is run during precompilation of a module, the
rakudo/fix_eval_in_precomp: independent SC would not be written into any file but would still be referenced
rakudo/fix_eval_in_precomp: from the outer compilation unit. We therefor use the outer world's
rakudo/fix_eval_in_precomp: CompilationContext which contains the SC. We also need to share a couple of
rakudo/fix_eval_in_precomp: other attributes that keep track of the compilation's state.
rakudo/fix_eval_in_precomp:
rakudo/fix_eval_in_precomp: The QAST compiler's frames are shared by adding them to the hash that's used
nine_ for initializing the QAST compiler's frames lookup hash. 15:43
Fixes RT #124324
commit 17523cecfbb2e4e6093cd5bd38c7a554063a1457
Refactor sharing the compilation context
Put the shared attributes into a subclass of NQP's CompilationContext to get
rid of the fragile binding hack.
Please, please review: github.com/rakudo/rakudo/commit/ef...9ede4aa8ab github.com/rakudo/rakudo/commit/17...54063a1457 15:44
psch yes! t/04-nativecall/01-argless.t passes on r-j \o/ 16:03
still plus debug output, and fixed in a terribly clutchy way, but at least i found the spot to tweak
s/clutchy/kludgy/ # probably, according to the jargon file at least i think 16:04
bartolin psch++ 16:05
nine_ psch++ # enjoy that moment! 16:06
17:30 vendethiel joined
dalek kudo/nom: e1e1811 | (Salve J. Nilsen)++ | / (2 files):
Make usage text fit in 80 columns

Also, update running.pod usage text example to match actual usage text.		 18:07
kudo/nom: 2d6f5c8 | niner++ | / (2 files):
Merge pull request #751 from sjn/usage-text-1

Make usage text fit in 80 columns
p: 6b71554 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
[js] Remove old TODO.
 18:11
p: f6b5db3 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
[js] Avoid setting the REPR names manually.

Throw meaningful things from badReference and badNative.
We need to distinguish them for native-capable getattr, because catching all RuntimeExceptions there muddles the ones we care about (which is badReference) up with e.g. "No such attribute".
18:11 dalek joined
psch something tangentially related i found while hunting the jvm NC bug: 18:27
m: my $name = "foo"; say "$name.{1+1}"
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ā¤ā¤Ā»
psch that apparently used to work, 'cause that's how $*VM.platform-library-name does it in the jvm path
in any case, i'm still kinda stuck how to make this a good solution 18:38
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:39
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
or there's a smart solution that gets closer to emulating the "chasing pointers" style of moar
...at least that's what i understand moar is doing
timotimo :S 18:42
psch my hunch would something akin to P6OpaqueBaseInstance.resolveAttribute, a la resolveAttributeType maybe 18:43
which could be ref, int, str, num, obj
i don't know how well that fits into sixmodel, though 18:44
and, well, moar doesn't even need it so maybe it's a bad idea..? vOv
timotimo to be honest i'm still confused why native attributes are even a thing
psch timotimo: huh? like, int? 18:45
timotimo no, i mean java native 18:48
psch oh 18:49
the comments and commit messages seem to suggest inlining..?
timotimo hm, right 18:50
but how come we don't just box it into a proper object on the way out?
like, p6opaque can inline other things's REPRs and REPRData
that's enough to turn it into a normal object on the way out?
i must be missing something 18:51
psch well, it needs to have a StorageSpec.INLINED to be inlined i suppose
and nqp-j codegen says that that already means it gets accessed by REPR.get_attribute_native
timotimo huh
how would things change when we claim NativeCall *isn't* inlinable? 18:52
psch then my first idea for fixing it could probably work
'cause that was to fix inlineGet and inlineBind to add/strip NativeCallInstance around the NativeCallBody
but then it probably also wouldn't get inlined... vOv 18:53
i do lean towards "just hack it together while relying on exceptions figuring out the type" 18:56
because it fixes two problems here, which is the NC bug as well as general access to native attrs via nqp::getattr
s/figuring/to figure/
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
as mentioned, in the worst case that's throwing and catching 4 exceptions
oh duh 19:04
tc.native_type exists
which means there's only one catch involved 19:05
timotimo hooray
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:07
i mean, assuming a general case where it's not known that it's a NativeCallBody and needs a NativeCallInstance 19:15
19:20 sortiz joined
psch gist.github.com/peschwa/1339399161...9bea6ca6ec 19:47
i think i'll take that for today 19:48
timotimo that's better than exclusively fails :) 19:49
which is what it was before, right?
psch yeah, previous was exclusively "No subtests run" iirc 19:50
timotimo excellent!
psch 'cause the BUILDPLAN for a Sub+{Native[...]} always failed
p: 5981bf0 | peschwa++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java:
Handle all kind of attribute access via getattr.

The NATIVE_JVM_OBJ case is clearly a bit brittle like this, but I haven't come across a case where that's not what we want. Of course this doesn't mean there isn't one...
kudo/nom: abfb8da | peschwa++ | tools/build/NQP_REVISION:
Bump NQP_REVISION

This gets us a more moar-like handling of nqp::getattr, which is transparent to native attributes.
psch huh, dalek didn't mention d6ed4c1 and didn't get floodkicked either..? 19:57
timotimo huh
psch 'cause there's another commit after the NQP_REVISION bump 19:58
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 :)
nine_ ok :) 20:04
dalek ast: 68a55df | usev6++ | S0 (3 files):
Unfudge tests for JVM

fixed by nqp commit 5981bf0439, psch++		 20:33
21:19 geekosaur joined 21:21 hankache joined 21:40 lizmat joined 21:55 synopsebot6 joined 22:48 ugexe joined
lizmat intriguing: arxiv.org/abs/1604.03641 23:03
[Coke] starting release. 23:13
dalek p: 804fdec | coke++ | tools/build/MOAR_REVISION:
bump MOAR revision
 23:16
p: 4011515 | coke++ | VERSION:
bump VERSION
[Coke] is nqp-js good enough to run as part of the release now? 23:17
(i'll find out soon enough...)
guess not. 23:20
nqp 2016.04 done, tagged, tarballed 23:54
rant: instructions suggest "perl6 tools/contributes.pl6" but that will never work if you have an installed p6 and a fresh dev. 23:56

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!