02:59 skids joined
dalek kudo/nom: 67250d4 | ugexe++ | src/core/CompUnit/Repository/Installation.pm:
CURI.files :$name is required

perl6 -e '$*REPO.repo-chain[1].files("libssl.so").say'
   Cannot unbox a type object
   in block <unit> at -e line 1
  github.com/rakudo/rakudo/blob/e8fd...on.pm#L313		 07:35
rakudo/nom: cc8a9e4 | niner++ | src/core/CompUnit/Repository/Installation.pm:
rakudo/nom: Merge pull request #762 from ugexe/patch-4
rakudo/nom:
ast: 1804479 | usev6++ | S32-exceptions/misc.t:
Add test for RT #127062
 07:49
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127062
08:35 RabidGravy joined 09:34 Ven joined
[Tux] This is Rakudo version 2016.04-125-gcc8a9e4 built on MoarVM version 2016.04-26-g1088538 10:10
test 22.996
test-t 13.787
csv-parser 36.772
dalek kudo/precomp-store-redesign: bed2621 | niner++ | src/core/CompUnit/Loader.pm:
Implement CompUnit::Loader.load-precompilation

Needs an NQP bump		 10:14
kudo/precomp-store-redesign: 6c12141 | niner++ | src/core/CompUnit/PrecompilationRepository.pm:
Merge .deps and mbc files into a single precomp file

This will allow for us to atomically replace both parts and thus get rid of locking for simple reads.
rakudo/precomp-store-redesign: 78ed087 | niner++ | / (4 files):
kudo/nom: 2b74c90 | peschwa++ | .travis.yml:
Make travis require a successful install before 'make test'.

Otherwise failures caused by e.g. install-core-dist.pl don't get reported.		 10:21
psch ...and as soon as i get r-j building successfully again that gets tossed from allow_failures 10:22
11:06 Ven joined
nine_ psch: the correct solution for force re-installing a dist is not to impose any order on the provides hash but to remove the existing precompiled files before installing again, so it's no longer possible that precompiling a module will use a dependency that gets overwritten later. 11:11
Also nuking _never ever_ fixes problems. It only hides them again. We've been backwards compatible since 2015.12 and will remain being so. Only modules installed on a pre 2015.12 version may warrant a nuke. 11:13
psch nine_: so Installation.install(:force) should remove the already installed Distribution before actually installing? 11:17
that's probably a lot more sensible than all the things i tried up to now 11:19
RabidGravy I must admit I have nuked because of what appears to be the problem you describe with versioned dependencies
psch although i'm not sure it's really Installation that should take care of that
dalek ast: d2eb961 | usev6++ | / (2 files):
Add test for RT #127176
 11:58
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127176
12:45 Ven joined
RabidGravy m: say $*IN.path.r, $*OUT.path.w; # This is fixed by github.com/rakudo/rakudo/pull/763 if someone want to merge 13:10
camelia rakudo-moar 2b74c9: OUTPUTĀ«FalseFalseā¤Ā»
psch well, adding 'self.uninstall($dist)' around CUR/Installation.pm:180 doesn't work vOv 13:53
it brings back the same "prefix on a null object" that i could only remove before by removing the path that includes the to-be-overinstalled precomp'd version of the Distribution 14:01
hm, or maybe just "keeps it around" 14:02
so the combination of RAKUDO_LOG_PRECOMP and RAKUDO_MODULE_DEBUG tells me that installation of NativeCall apparently works, but precompilation doesn't 14:36
14:51 Ven joined
ugexe i dont think the current uninstall removes everything 15:13
you also have to give it a $dist that coincides with what is installed, not what you would pass to .install 15:14
psch ugexe: but the dist i want to install is exactly the one that's already installed, which is why i need :force in the first place 15:15
moritz what's the plan for from-json and to-json in the setting? 15:18
I seem to recall that it's not supposed to be publicly available
if so, should I move it to Rakudo::Internals?
jnthn moritz: Yes, please. I somehow thought that'd happened already... 15:19
RabidGravy anyone fancy merging github.com/rakudo/rakudo/pull/763 ? Fixes $*IN.path.r etc 15:23
ugexe psch: CURI mangles the distribution META6.json 15:24
so its no longer the same once you install it
psch ugexe: i'm not reading any META6.json
ugexe uninstall uses it
provides specifically gets mangled on install 15:25
a gist of it is you need to get the dist object from .resolve and uninstall that 15:26
moritz jnthn: ok, I'll try to prepare a patch 15:27
ugexe this is how zef is able to uninstall 15:28
this can be solved with the distribution PRs as well 15:29
psch ugexe: okay, i'll note that down. although i just realized i'm actually blocked by a different problem still... 15:32
moritz Stage parse : P6opaque: must compose before allocating 15:33
ugexe zef
oops
psch namely still "Cannot call method prefix on a null object", which i don't really understand either vOv
ugexe where is it pointing to with --ll-exception? 15:34
psch i've chased it around a bit, and it does go away when i remove the repo from $*REPO.repo-chain that has a path-spec that matches $path, in PrecompilationRepository around line 178 15:36
i don't have --ll-exception handy right now, just tossed all the misguided uninstall debug code... :)
i'll get that in about 10 minutes though, 'cause nqp-j build and all... 15:37
timotimo ugh 15:38
so slow :<
ugexe psch: i havent been following, but what repo are you removing? one of the built in nom ones? or a new one? 15:40
psch ugexe: i'm trying to run install-core-dist.pl during make install on r-j 15:41
ugexe ah, so i should be able to reproduce it with make install on r-j? 15:42
psch yeah, should 15:43
the relocatable-precomp branch broke that afaict, although bisect pointed me at a commit that can't have been it... vOv
ugexe: i suppose that means i don't need to gist the --ll-exception output? :) 15:50
ugexe psch: maybe not... but `make install` seems like it might be frozen for me 16:01
ok make install finished without any errors... 16:02
psch ...wha
16:02 hankache joined
ugexe gist.github.com/ugexe/fa61ecac4239...2b339a338f 16:03
psch travis-ci.org/rakudo/rakudo/jobs/128619329#L411 that's the latest travis build
is that the tag 2016.04?
ugexe yeah
16:04 hankache joined
psch yeah, that worked 16:04
relocatable-precomp was merged earlier this week
you're some 110 or so commits before the breakage :)
m: say 1
camelia rakudo-moar 2b74c9: OUTPUTĀ«1ā¤Ā»
ugexe seems like so long ago
psch m: say $*PERL.compiler 16:05
camelia rakudo-moar 2b74c9: OUTPUTĀ«rakudo (2016.04.126.g.2.b.74.c.90)ā¤Ā»
psch 126 patches behind
16:05 hankache_ joined
psch oh, it was sunday last week actually 16:05
16:05 hankache joined
ugexe ok lets try this again *laptop melts* 16:06
16:06 cognominal joined
bartolin ugexe: here is the output with --ll-exception: gist.github.com/usev6/607c0f00e4e6...nt-1772107 16:08
"This is Rakudo version 2016.04-123-g626b5a9 built on JVM"
ugexe psch: any hunches? looking at it it appears to do with CURI not properly passing `self` with CompUnit::RepositoryRegistry.name-for-repository(self) 16:13
psch ugexe: well, as mentioned, the only thing i could figure out is that the problem goes away when the repo with a path-spec matching $path gets removed from the repo-chain before installation 16:14
err, before precompilation
ugexe hmm, i thought there was an issue with using `my $xxx` in a class outside of a method 16:17
with jvm
see github.com/rakudo/rakudo/commit/f6...17fae565a9
nine_ psch: I actually don't think the relocateable-precomp branch broke anything. It's more like those precomp files have always been broken and only now we actually load them. The precomp files created on installation of a dist were not used before. 16:20
psch nine_: fair enough, i do admit i don't know what exactly is the cause for the breakage, i just have a rough idea when it started to appear :) 16:22
ugexe name-for-repository will return Nil if it doesnt find what it wants, and later the result of name-for-repository is used to call .prefix on without checking it
nine_ psch: of course it's entirely possible that I screwed up somewhere, too :) 16:23
ugexe id guess its secretly been broken for awhile as well 16:26
psch nine_: if anything it's more likely that nqp-j breakage like what the commit ugexe linked to above is to blame
that is, assuming it wasn't secretely broken
well, that's what i think at least :) 16:27
ugexe it could always have been secretly broken because of what caused that (possibly) similar breakage 16:34
dalek kudo/nom: 86a2b4f | RabidGravy++ | src/core/IO/Special.pm:
Fix the r/w file tests

The code expected $!what to be '<IN>', '<OUT>' or '<ERR>' but the objects are initialised with '<STDIN>', '<STDOUT>' and '<STDERR>' in io_operators when the handles are setup. Thus the file tests which do a string comparison to $!what were incorrect.
kudo/nom: 02d63fd | lizmat++ | src/core/IO/Special.pm:
Merge pull request #763 from jonathanstowe/io-special

Fix the r/w file tests
ugexe its weird that CU::RR has a `my $lock = Lock.new` but every method that uses $lock has a `state $lock = Lock.new` 16:38
nine_ Not weird...just a leftover I've overlooked 16:39
ugexe i thought it was a "one weird trick to make jvm work" type thing
nine_ All the locking stuff is from the previous implementation. 16:40
ugexe would you want the same lock to be available to each method though? 16:41
wouldnt^
nine_ Probably yes. I haven't spent a minute on thinking about multi threaded module loading. 16:43
I see making module loading thread safe as nice little bonus once the basics are all as they should be 16:44
16:45 RabidGravy joined
dalek kudo/nom: e84804c | lizmat++ | src/core/Junction.pm:
Make Junction.ACCEPTS 4x, Junction Bool 20x faster

The idea of using a scopeless STATEMENT_LIST is fine, but not if you're starting a new scope for each iteration of the map. On top of that, a map needs to handle Slip's, and that only to be able to potentially return from that scope. This patch reforms the maps to a postfix while with a conditional return in it. So no new scope for each iteration. On top of that, if not returning on the way, we just set the final value, rather than returning that: so no explicit return in that case either.		 16:49
timotimo holy wow. 16:54
tadzik that's quite awesome 16:55
lizmat++
hankache lizmagic++
dalek kudo/nom: 3f9f60e | moritz++ | / (8 files):
move {from,to}-json to Rakudo::Internals::JSON

  ... and add deprecations for the old locations.		 17:04
moritz this seemingly small commit took me way too long and too many tries to get it right
dalek ast: 8c348b2 | moritz++ | S02-types/WHICH.t:
remove JSONPrettyActions
 17:07
moritz shit, seems like I broke curli-install.t 17:09
testing a patch now
dalek kudo/nom: 2ba21b9 | moritz++ | src/core/ (2 files):
Fix installation
 17:13
ugexe removing the `is required` from CUR::Locally gets `Unhandled exception: java.lang.RuntimeException: Missing or wrong version of dependency 'src/Perl6/Pod.nqp' 17:15
during install-core-dist.pl. Im not sure if thats further along or not
psch ugexe: on a clean build or on a rebuild? 17:16
ugexe clean. on a rebuild it ran out of memory during jast 17:17
psch 'cause Pod.nqp is one of those that likes to fail if the target prefix already has an r-j install there..
oh, curious
ugexe i have some `note` debugging statements that may have affected that, but i gotta run. maybe try just s/is required// in CUR::Locally 17:18
tomboy65 i think he went off
pardon, wrong channel 17:19
bartolin by the way, a simple 'use Test' really taku 17:22
oops
by the way, a simple 'use Test' really takes much longer on rakudo-j after the merge: gist.github.com/usev6/607c0f00e4e6...nt-1772137
psch o.o 17:24
bartolin aha, setting RAKUDO_MODULE_DEBUG=1 shows that Test.pm is precompiled every time it's used. 17:25
it did work before (precompiled module was loaded) 17:26
bartolin added the output with RAKUDO_MODULE_DEBUG=1 to the gist 17:29
17:44 cognominal joined
bartolin nine_: do you have any pointer how to debug, why the precompiled Test.pm is not used here (with rakudo-j): gist.github.com/usev6/607c0f00e4e6...nt-1772158 17:58
nine_ bartolin: is it possible that Strings on the JVM are not null safe? 19:12
I'm using \0 as separator
bartolin: would also help to have a look at /usr/home/christian/perl6/tmp/rakudo_1/lib/.precomp/5D6AFAC14232683770BAF3B18E5F160560397209.1.462617444339E9/CD/CD7CA147D04D07DEDFB4B697B464E644541AD23A.deps 19:15
It should have a 40 character id on the first line and then some lines with id, source path and DependencySpecification separated by \0
bartolin nine_: thanks, I'll take a look (but probably tomorrow) 20:01
dalek kudo/nom: 283b859 | lizmat++ | src/core/Junction.pm:
Make Junction.gist|perl|sink up to 9x faster
 21:21
rakudo/precomp-store-redesign: d17fe96 | niner++ | src/core/CompUnit/Precompilation (3 files): 21:29
rakudo/precomp-store-redesign: Split off repo-id from precomp files
rakudo/precomp-store-redesign:
rakudo/precomp-store-redesign: The repo-id is the identity of $*REPO (representing its contents and the whole
rakudo/precomp-store-redesign: repo chain) at the time when a precomp file's dependencies were last resolved.
rakudo/precomp-store-redesign: As long as the repo-id is the same, we can just load the dependencies by their
rakudo/precomp-store-redesign: ids and do not have to resolve them from their DependencySpecifications.
rakudo/precomp-store-redesign:
rakudo/precomp-store-redesign: When the repo-id is different, we need to re-resolve and check if the
rakudo/precomp-store-redesign: dependencies still resolve to the same precomp files. If they do, we can still
rakudo/precomp-store-redesign: use them and now store the updated repo-id in a precomp store. In other words:
rakudo/precomp-store-redesign: the repo-id is volatile information compared to the byte code and the
bartolin nine_, psch: I think I found the cause for one of the precomp issues on rakudo-j: the FIRST phaser in github.com/rakudo/rakudo/blob/nom/...ory.pm#L87 does not work for rakudo-j. because of that rakudo-j did not load a freshly precompiled Module. 21:56
m: for 1 { FIRST { next }; say "should not be here" } # prints "should not be here" on rakudo-j 21:57
camelia ( no output )
timotimo damn
bartolin I guess, that's behind my stresstest runs taking 10 hours :-/
timotimo ;( 21:58
bartolin he, I already put it in RT last november: RT #126701 :-) 22:07
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126701
22:57 ugexe joined 23:28 tomboy64 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!