00:12 skids joined 00:47 timotimo joined
ugexe i wondered if that comment was related 00:58
05:44 sno joined 06:43 pyrimidine joined 07:06 RabidGravy joined, DrForr joined
dalek kudo/nom: d13c39c | niner++ | src/core/CompUnit/RepositoryRegistry.pm:
Fix "Cannot call method 'prefix' on a null object" during JVM build

tools/build/install-core-dist.pl works with a repo chain consisting only of the
  'perl' repository and missing 'vendor' and 'site'. This caused VMNull values in
the $custom-lib nqp hash over which name-for-repository stumbled later on.
Fix by removing those keys from the hash (if we would just leave them as is, they'd contain the path strings). With this the JVM build finishes successfully.		 07:15
nine psch: at least nom is in a better shape now :) 07:17
07:42 brrt joined
brrt what to do about perl6-gdb-m detaching and waiting forever? 08:45
grrr. precomp interferes with debugging 08:50
nine It has not always been this way I think 08:58
Have you tried my $perl6 = $*EXECUTABLE.subst('perl6-debug', 'perl6').subst('perl6-gdb', 'perl6'); in src/core/CompUnit/PrecompilationRepository.pm? 08:59
method precompile
dalek kudo/nom: 1e5df41 | peschwa++ | .travis.yml:
Only allow R-J failures on OSX.
 09:49
psch ...because that apparently hangs, currently
at least that's the only idea i have. stage parse for r-j on osx is about the same as linux, but osx gets terminated because it runs too long 09:50
is there any reason we let travis only test nqp-m? 09:51
|Tux| This is Rakudo version 2016.04-158-gd13c39c built on MoarVM version 2016.04-26-g1088538 09:54
test 21.693
test-t 13.366
csv-parser 35.002
psch ...it's "nobody wants constant reminders that nqp-j doesn't pass all tests", isn't it? :/ 09:55
dalek p: 0af5b62 | (Pawel Murias)++ | tools/build/ (2 files):
[js] Build NQPP5Regex.
 09:56
p: 87a487c | (Pawel Murias)++ | src/vm/js/nqp-runtime/core.js:
[js] When unable to type check return 0.

It's not very elegant but other backends to it this way and rakudo relies on it.
timotimo psch: not to mention nqp-p 10:02
psch timotimo: well, in contrast to nqp-p there's at least one person with somewhat of an interest around to make nqp-j pass the nqp test suite... :P 10:03
timotimo that's right 10:04
psch but yeah, i'll put that off until we do actually pass the test suite
timotimo i appreciate your work in this matter in any case :) 10:07
nine Oh yes, absolutely! 10:08
psch ooc, what's with the macros MAX and P6OMAX in MoarVM/src/6model/reprs/P6opaque.c? 10:14
'cause they look kind of identical to me 10:16
jnthn Well P6OMAX was added to avoid some compiler warning 10:17
And has been there since April 2013
psch jnthn: ah. well, as i said, just curious :) 10:18
jnthn 24b38672 added MAX
Apparently for...something to do with libtommath bundling? o.O
And it seems totally unused in P6opaque.c 10:19
psch that does sound a bit weird from here
jnthn Yeah, to me too
timotimo well, since we concatenate all .c files before compiling into one big .c file, we can't easily know if it's used or not! 10:20
wait, something's not quite right about that ...
psch CORE.setting.c..? :)
timotimo totally don't see a problem with that
psch well, MOAR.setting.c i suppose :P
nine I wonder if there'd actually be a way to not concatenate setting file in rakudo and speed up compilation that way 10:23
I guess we would need a way to concatenate byte code files instead. 10:24
psch intuitively i'd guess we could only make it slower because of lots of GLOBALs merging and fixups
as CORE:: still is supposed to be one lexical scope
nine Compiling the whole setting would definitively be slower, but change/compile/test turnaround times could be much improved. 10:25
timotimo BBL
jnthn nine: All the stubbing and later declarations would get in the way for one :)
psch jnthn: the closest nqp-j equivalent to {get,set}_obj_at_offset we have is {get,bind}attr with a hint, isn't it? 10:26
nine jnthn: not if we compile every file with a setting which is the concatenation of the previously compiled files. Or put differently: if we add a newly compiled file to the concatenated setting and use that as setting for the next file. 10:27
psch hm, i guess the closest thing i could do is introspecting for the corresponding .field_, but i don't really want to do that... :S 10:31
jnthn psch: The problem really is that in C you can easily implement taking and passing a reference into the middle of some other object 10:33
psch: And if Java there's no way to do that
psch: And the way it's implemented on Moar uses that feature
So a direct port isn't really possible
psch considers throwing "Sorry, auto vivification of containers NYI" 10:34
i think i don't quite complete grasp the purpose of that branch in get_attribute yet, anyway 10:35
*if branch
the !attr_st case is for inlined natives? 10:36
10:37 brrt joined
jnthn No, the !attr_st case is for when we want an object and simply have one 10:37
We must implement the autoviv already I think, because otherwise a lot of other things woudln't work 10:38
It's the case we *do* have attr_st that is trickier on JVM
lunch; bbiab
psch hm, the problem i'm seeing now is that i don't know where on the allocated SMO i have to hang the attr that we are getting 10:57
i think that's what moar solves with "passing a reference into the middle of some other object"..?
jnthn psch: It's more that you'd need to .allocate an instance of the flattened-in type's REPR 11:00
And "copy" to that 11:01
psch jnthn: right, that's what i mean. the allocated SMO is the one that comes from flattenedSTables[slot]
but copying to that freshly allocated SMO is what's hard, because i can't just do pointer arithmetic but have to know the name of the field 11:08
jnthn Right 11:10
Which is why it was cheated around so far ;)
psch ugh 11:19
so i'm getting this right that the SMO could have an arbitrary amount of fields too right?
jnthn psch: Yes. Though if you know the position of the first field (if there's not already a table then it's probably easy enough to keep one) then you can just grab the field reflection object from that point and go over those from the target object assigning 11:23
psch jnthn: oh, right now i'm mostly trying really hard to not need to reflect... i don't think it's working, fwiw :) 11:24
psch .oO( catch (IllegalAccessException iae! iae! cthulhu fhtagn!) ) 11:32
jnthn ;) 11:33
psch jnthn: what's a test for the !attr_st/autoviv case? 11:42
jnthn Well, any Scalar attribute access in a Perl 6 object pretty much 11:43
psch ah, okay 11:45
so i'll notice during the rakudo build if i broke that i suppose.. :) 11:46
well, building r-j with the getattr patch worked 12:10
now for the other two nqp make test failures...
'cause maybe then we can also enable nqp-j on travis :)
one of the failures is the contvar test in qast/01-qast.t 12:18
and the other is "Missing serialize function for REPR P6bigint" in serialization/02-types.t (and potentailly more after that vOv) 12:19
12:19 MadcapJake joined
psch the latter is apparently just NYI 12:21
12:50 brrt joined 13:17 skids joined 13:47 dalek joined
[Coke] RT: 1289; CONC: 7; GLR: 6; JVM: 70; LHF: 2; LTA: 69; NYI: 26; OSX: 3; PERF: 15; POD: 3; PRECOMP: 3; RFC: 16; SEGV: 19; STAR: 1; TESTNEEDED: 23; TODO: 10; UNI: 5; WEIRD: 2 13:57
[Coke] wonders if "REGEX" would be a helpful tag 14:07
14:31 sortiz joined
[Coke] m: let $a = 3; 15:05
camelia rakudo-moar 1e5df4: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/AGj4pywA_zā¤Variable '$a' is not declaredā¤at /tmp/AGj4pywA_z:1ā¤------> let ā$a = 3;ā¤Ā»
[Coke] m: my $a; {let $a = 3;}
camelia ( no output )
[Coke] m: BEGIN { say "a".subst(/a/, "b"); } 15:06
camelia rakudo-moar 1e5df4: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/IqguIOqriYā¤An exception occurred while evaluating a BEGINā¤at /tmp/IqguIOqriY:1ā¤Exception details:ā¤ Type check failed in binding cds; expected Any but got Mu (Mu)ā¤ in block at /tmp/IqguIOqriY lineā€¦Ā»
[Coke] m: my $a="a";my $b="b"; ($a, $b) := ($b, $a); say $a; say $b; 15:07
camelia rakudo-moar 1e5df4: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/cmHPsI_PQYā¤Cannot use bind operator with this left-hand sideā¤at /tmp/cmHPsI_PQY:1ā¤------> y $a="a";my $b="b"; ($a, $b) := ($b, $a)ā; say $a; say $b;ā¤Ā»
nine Oh I hate this so much! Unhandled exception: java.lang.RuntimeException: Missing or wrong version of dependency 'src/Perl6/Pod.nqp' 15:29
psch too 15:30
i don't know how to fix it though :S
nine rm install/share/nqp/lib/Perl6/* ; make clean ; make install 15:38
make clean is not enough since it then uses the outdated installed files
dalek p: 6aa109b | niner++ | src/vm/jvm/ (2 files):
Implement loadbytecodebuffer op for JVM
 15:40
nine I don't know why but it seems like my first implementation attempt actually works :) 15:41
jnthn Maybe you got it right? o.O ;)
nine nah....can't be it
Also there's very probably a difference between "right" and "just working" 15:42
Can "Cannot unbox a type object" appear because a type object was passed to an nqp sub expecting an int argument? 15:47
jnthn nine: yes 15:48
ugexe nqp master stopped building on windows yesterday in case anyone missed it: ci.appveyor.com/project/moritz/rak...evd8cuy3pc 16:01
(line 114) 16:02
psch nine: sure nuking the installed files make the builds "work" again, but ISTR someone telling me that's only hiding the problem... ;) 16:03
nine oops...it's actually nqp
s/nqp/MoarVM/
ugexe i dont think the appveyor notices will show up on github unless its specifically under the rakudo name 16:04
nine Created a PR for Moar 16:08
16:19 sno joined
nine j: my sub parse-string(int $pos is rw) { loop { my int $ord = nqp::ordat('', $pos); } } 16:29
camelia rakudo-jvm 40a953: OUTPUTĀ«cannot connect to eval server: Connection refusedā¤Ā»
nine meh
However that's the golfed code that gives the Cannot unbox a type object in src/vm/jvm/QAST/Compiler.nqp:4427
Trying to pass NQPMu to sub result
psch nqp-m: nqp::ordat("", 0) 16:36
camelia ( no output )
psch nqp-m: say(nqp::ordat("", 0))
camelia nqp-moarvm: OUTPUTĀ«-1ā¤Ā»
psch the ordat call itself throws StringIndexOutOfBounds locally..? 16:38
hm, maybe i'm not paying enough attention... :) 16:39
nine $cur_block.lexical_type($name) is NQPMu which ends up in $type and passed to result() 16:42
psch hm, lexref underimplemented? 16:43
i think native rw params are lexical refs... :S 16:44
nine Further golfed it down: my sub parse-string(int $pos is rw) { { my int $ord = $pos; } } 16:45
And yes the inner block is necessary to trigger it
psch nine: yeah, it's the combination of int and 'is rw', Int or no 'is rw' makes it work 16:47
which is one of those *ref_i thingies, i'm not sure if nativeref_i or lexicalref_i though 16:48
17:07 RabidGravy joined
nine Has anyone besides psch tested the precomp-store-redesign branch so far? 18:00
psch: the "java.lang.RuntimeException: This type does not support positional operations" occurs when slurp-rest()ing a file with a certain minimum length. It won't happen on short files... 18:10
18:20 brrt joined
psch nine: that sounds a bit weird... 18:20
nine: i don't see anything obvious in StandardReadHandle or SyncHandle that could cause that 18:21
nine: although maybe finding the actual boundary helps there... vOv
nine 32768 bytes is the limit
2^15 18:22
Intriguingly that's the file size. Seems to be independent of how much slurp-rest actually is reading (using .get() before)
Yep, 32768 is still ok, 32769 is too much 18:23
psch i'd guess that means that the "are we over the limit" code is faulty? 18:24
nine which limit? 18:25
curBuffer = ByteBuffer.allocate(32768); 18:26
Must be relevant
psch that should be fine, actually... 18:27
nine OTOH the error comes from nqp not the JVM 18:28
psch the while loop that allocates reads the ByteChannel, replacing the buffer it reads into every 32kib
well, slurp returns a String in any case 18:29
so i mostly wonder why it wants to do positional access in the first place
nine slurp-rest, not slurp 18:31
psch slurp-rest calls readallfh, which calls SyncHandle.slurp :)
nine slurp-rest(:bin) 18:32
Which uses readfh and pushes blocks into $res
psch oh, yeah i wondered about that, but forgot to ask
...and then operated on the wrong assumption /o\ 18:34
nine: i'd try having SyncHandle.read() do a similar thing as SyncHandle.slurp does 18:35
nine: i.e. gather multiple buffers into an arraylist and decode that 18:36
nine no decoding necessary for :bin
psch no, i mean decode the ArrayList<ByteBuffer> into a VMArrayInstance 18:37
nine But that seems to be essentially what slurp-rest(:bin) does, just at a higher level in nqp
Lowering the 0x100000 to 0x10000 in slurp-rest does not change the 32768 limit 18:42
psch that's really weird tbh :) 18:44
ugh, how does dd work again... >_> 18:45
nine ddrescue or dd_rescue or de-rescue however it's spelled has a much nicer interface 18:46
psch well, that doesn't seem to be on hack
ah, bs=1b was the bit i did wrong 18:47
bs=1 does what i mean 18:48
18:50 dalek joined
psch humm 18:51
my $fh = open "16384.bin"; $fh.slurp-rest :bin # gives me the same error
oh duh 18:52
forgot bs=1 there >_>
yeah, but still, 16kb file, with that p6 invocation throws the same error
ok, so i'm now running if=/dev/random instead of if=/dev/zero, and only writing 2 bytes 18:55
and that throws the same way too
nine: am i doing slurp-rest wrong..?
nine Maybe depends on the Java version/implementation? Using java-1_8_0-openjdk-headless-1.8.0.77-1.1.x86_64 18:59
psch ah, hack is on java version "1.7.0_101" 19:00
anyway, i've subclassed RTE so i know which one to catch
'cause we use them for... other things
like, CX i wanna say, but i'm not sure 19:01
m: my $b = Buf.new; $b.push(Buf.new([1, 2])) 19:17
camelia ( no output )
psch nine: ^^^ that's your golf
nine Wow...that's quite a bit shorter :) 19:18
psch i don't know about that
but it's less semantically dense at least :)
but yeah, that's what throws the "does not support positional"
nine I have to admit that I don't understand how this could go wrong
psch interestingly, passing an Int into $buf.push works 19:28
nine Sometimes I think this API redesigning will never end
dalek kudo/nom: 33ef5a9 | niner++ | / (2 files):
Implement CompUnit::Loader.load-precompilation

Needs an NQP bump		 19:34
kudo/nom: 2511398 | niner++ | src/core/CompUnit/PrecompilationRepository.pm:
1dca2d8 | niner++ | src/core/ (7 files):

We need the path of a dependency's source file to check the .modified time. We also want to be able to move repositories without invalidating all precomp files. So we use the same trick as for the source-names that we use for backtraces and use paths relative to well known repositories.
19:35 dalek joined
timotimo that's a merge? 19:36
psch ugh 19:37
my hunch was correct :/ 19:38
- nqp::splice(self,$buf,nqp::elems(self),0)
+ nqp::splice(self,nqp::decont($buf),nqp::elems(self),0)
and Buf.push(Buf) works
nine ah....forgot the --no-ff again
psch: what's with all those decont issues?
psch nine: i have no idea. the only hint i ever got was for #126493, my last comment links to jnthn++'s suggestion regarding that 19:39
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126493
psch otoh, jnthn did say recently that it's probably not because of that (i.e. signature compilation)
oh, there also was this bit about "don't ro-cont if it can't flatten" in the slow path binder 19:45
but i couldn't get that to work because i didn't figure out how i can put Iterable into GlobalExt 19:46
nine Seems to me like this comes up again and again :/
Since the GLR anyway
psch yeah, sounds about right 19:49
20:27 perlpilot joined 20:49 travis-ci joined
travis-ci Rakudo build failed. Stefan Seifert 'Work around JVM not having loadbytecodefh' 20:49
travis-ci.org/rakudo/rakudo/builds/129825917 github.com/rakudo/rakudo/compare/1...6ddfd43420
20:49 travis-ci left 20:59 Skarsnik joined
nine Those were JVM failures. 21:00
21:35 cognominal joined
nine Aaand this should be the final piece of the puzzle allowing for us to package modules :)
Will give it a try this weekend and see if I'm correct. But for now, good night! 21:48
timotimo awesomazing! 21:49
22:10 ZoffixWin joined 22:56 ZoffixWin 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!