dalek ast: cef40ed | LLFourn++ | / (4 files):
RT #128156 changing of file content

Changing a precompiled dependency's content would break it further re-precompilations. This seems to be caused by a mistake wrt to appending the SHA of the file to the filename.
Fixed in d0a00164e of rakudo		 00:25
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128156
Zoffix Have anyone tried to make the Rakudo release process more... automatic? 01:21
As in... will I be reinventing some wheel if I try to? :) 01:23
The cli rt keeps telling me incorrect login/pass :S 01:32
nm (you have to set up a pass separately) 01:35
that program would be a 1000% more helpful if it didn't chop off the subject line after like 10 characters... Srsly, lots of screen! i.imgur.com/kk4qkxS.png 01:46
timotimo urgh, that's terrible 01:49
Zoffix Getting rid of substr here fixed it: github.com/bestpractical/rt-client...t/rt#L1809 01:53
(knowing how to program)++ 01:54
jdv79 my $subject = substr($k->{Subject}, 0, 30);
that's rather boring and heavy handed:(
its probably best to detect the term width and adapt but who uses rt' 01:57
s cli anyway
sortiz That is the "prettylist" :-) 02:12
[Coke] Zoffix: no one is pursuing automated releases atm, i think
Zoffix m: sub foo ( Str:D :$a ) {}; foo 03:01
camelia rakudo-moar ac0dcd: OUTPUT«Parameter '$a' requires an instance of type Str, but a type object was passed. Did you forget a .new?␤ in sub foo at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤» 03:02
Zoffix m: method foo ( Str:D :$a ) {};
camelia rakudo-moar ac0dcd: OUTPUT«Potential difficulties:␤ Useless declaration of a has-scoped method in mainline (did you mean 'my method foo'?)␤ at <tmp>:1␤ ------> method⏏ foo ( Str:D :$a ) {};␤»
Zoffix m: class { method foo (Str:D :$a) {} }.new.foo 03:03
camelia rakudo-moar ac0dcd: OUTPUT«Parameter '$a' requires an instance of type Str, but a type object was passed. Did you forget a .new?␤ in method foo at <tmp> line 1␤ in block <unit> at <tmp> line 1␤␤»
Zoffix m: my Str:D $a = Str:D; 03:04
camelia rakudo-moar ac0dcd: OUTPUT«Type check failed in assignment to $a; expected Str:D but got Str:D␤ in block <unit> at <tmp> line 1␤␤»
Zoffix m: say Int(Int(3434)) 03:22
camelia rakudo-moar ac0dcd: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Unable to parse expression in typename; couldn't find final ')' ␤at <tmp>:1␤------> say Int(Int(⏏3434))␤»
Zoffix m: say Int(+Int(3434))
camelia rakudo-moar ac0dcd: OUTPUT«3434␤»
Zoffix m: say Int({Int(3434)}) 03:23
camelia rakudo-moar ac0dcd: OUTPUT«Cannot find method 'Int' on object of type Block␤ in block <unit> at <tmp> line 1␤␤»
Zoffix ... do I even want to know...
m: say name({Int(3434)})
camelia rakudo-moar ac0dcd: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Undeclared routine:␤ name used at line 1␤␤»
Zoffix hmm
m: say Int({name(3434)})
camelia rakudo-moar ac0dcd: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Undeclared routine:␤ name used at line 1␤␤»
Zoffix m: {}.name.say 03:24
camelia rakudo-moar ac0dcd: OUTPUT«%␤»
Zoffix m: {;}.name.say
camelia rakudo-moar ac0dcd: OUTPUT«␤»
Zoffix bisectable, sub foo() { return 42 }; for ^158 { foo } 03:27
bisect: sub foo() { return 42 }; for ^158 { foo }
bisectable Zoffix: (2016-06-01) github.com/rakudo/rakudo/commit/7250543
Zoffix bisectable, help
bisectable Zoffix: Like this: bisect: good=2015.12 bad=HEAD exit 1 if (^∞).grep({ last })[5] // 0 == 4 # RT 128181
Zoffix Would this be a release-stopping issue? rt.perl.org/Ticket/Display.html?id=128368 03:29
m: sub foo() { return 42 }; for ^158 { foo }
camelia rakudo-moar ac0dcd: OUTPUT«Attempt to return outside of any Routine␤ in block <unit> at <tmp> line 1␤␤»
Zoffix ^ that specifically
jdv79 [Coke]: i thought there were parts that were difficult to automate and that's why. i think i asked you about that once. 03:32
Zoffix I went through tickets since last release. There's just one (the one I show above) that IMO needs to be fixed before release. I also marked down a few that have a reasonable chance of affecting a number of users: gist.github.com/zoffixznet/25a3d15...3f2c6aa0ba 03:41
jdv79 the utf8-c8 one looks fun 03:51
lizmat I'm not sure the ^158 bug will be fixable before release with jnthn's availability 04:24
otoh, I *would* give that greater importance than the named param cache issue we talked about yesterday 04:25
commute to FRA& 04:34
[Tux] This is Rakudo version 2016.05-145-gac0dcdd built on MoarVM version 2016.05-18-g1339332 05:55
test 17.474
test-t 9.763
csv-parser 22.109
jdv79 it has something to do with that fixup clause after the decode for loop but my C skills can't penetrate the issue. oh well. 06:36
Ulti jnthn would your multi dispatch caching changes include this sort of use case? github.com/MattOates/BioInfo/blob/...nces.t#L30 07:02
because I have that sort of stuff in tight loops all over my code because I liked the interface style :S 07:03
masak really likes seeing that "9" next to "test-t" 07:16
nine Ulti: AFAIK it should 07:23
[Tux] masak, /me really hopes for a 5 when "next" is optimized 07:44
masak hope springs eternal :) 07:45
jnthn Ulti: Quite possibly 08:40
Ulti: Don't see why not, at least 08:41
Ulti then I'll bump up my anticipation accordingly >:3 09:01
dalek p/return-without-lexotic: 4bddc57 | jnthn++ | src/vm/moar/QAST/QASTOperationsMAST.nqp:
Map throw-by-exception-category op.

So we will be able to use it in Rakudo for next/last/redo speedup.		 09:21
psch so, the difference between moar and jvm in how we have to handle mast_frames is probably also why moar doesn't get any hiccup with getting a Hash instead of a BOOTHash in %*COMPILING<%?OPTIONS><mast_frames> 09:27
as in, moar only ever gets an nqp::hash from HLL::Backend, fills that itself when it needs to, and afterwards it gets added to the CU
while on jvm we need information from the outer CU inside the nested CU 09:28
and that information comes HLLized
'cause we can't just say "here, these methods also go into the class", because we have more to add than just methods 09:29
like, the J::Class that represents the outer CU has to know that it has a nested CU, so we can visit the nested class that represents the nested CU during codegen 09:30
and of course the nested class also has to visit its containing class during codegen
and we also kind of have to carry the whole JCLASS from inside the nested CU with us to the outer CU, so we can figure out which method to call as mainline of the nested CU in the outer CU 09:33
lizmat waves from FRA 09:34
moritz waves to FRA 09:35
lizmat sees moritz waving 09:37
DrForr On your way to MCO? 09:40
masak waves to all the TLA
or TLAs
DrForr TDM TLA. 09:41
lizmat DrForr: yup 09:44
DrForr I'll be in on Saturday. Reminds me that I need to book my airport shuttle... 09:45
jnthn There actually is a TLA airport: en.wikipedia.org/wiki/Teller_Airport 09:56
dalek kudo/return-without-lexotic: 76afba8 | jnthn++ | src/core/control.pm:
Use new throwextype to cheapen next/last/redo.

Cuts ~12% of CPU instructions off 'my $i = 0; for ^500000 { next if $_
  >= 50000; $i++ }; say $i'.		 10:06
nine psch: sounds like you at least have a pretty good picture of what's going on and what's needed now :) 10:07
psch nine: yeah, i largely think so. figuring out how to implement the codegen bits is gonna be lots of fun, though 10:08
well, and also figuring out how i can get the necessary information from the outer JAST::Compiler instance to the inner also still is some challenge
dalek p/return-without-lexotic: 412d997 | jnthn++ | src/vm/jvm/ (2 files):
Add RETURN exception category to JVM backend.
 10:11
kudo/nom: 781c6cd | lizmat++ | src/core/Version.pm:
Fix for RT #128408, Zefram++ for spotting
 10:12
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128408
dalek kudo/nom: e423a0a | lizmat++ | src/core/Version.pm:
Fix incorrect use of the word sentinel

When highlander (there can only be one) was intended		 10:17
kudo/nom: b3e9f5d | lizmat++ | docs/ChangeLog:
Mention Version fix in ChangeLog
 10:19
jnthn Gee, working on JVM stuff is slow going.... 10:40
psch sighs 10:42
Zoffix Is avoiding the ^158 bug in the release more involved than simply omitting this commit? github.com/rakudo/rakudo/commit/7250543
It looks scary enough that I'd say its presence is a legitimate reason to delay the release.
m: sub foo() { return 42 }; for ^158 { foo } # I mean this one 10:43
camelia rakudo-moar b3e9f5: OUTPUT«Attempt to return outside of any Routine␤ in block <unit> at <tmp> line 1␤␤»
psch star-m: sub foo() { return 42 }; for ^158 { foo }
camelia ( no output )
lizmat Zoffix: I think it will just revert a performance gain 10:44
spectesting it now
Zoffix oh :(
lizmat Zoffix: spectests clean, with even 1 todo passing :-) 10:56
commute to MCO& 10:57
catch ya on the flip side!
Zoffix nice. Thanks, lizmat++
nine Zoffix: the commit in question does not cause the bug but just unhides it. 11:01
Zoffix :( 11:02
star-m: sub foo() { return $++ }; my $x; for ^200 { $x = foo }; say $x
camelia star-m 2016.04: OUTPUT«199␤»
Zoffix m: sub foo() { return $++ }; my $x; for ^200 { $x = foo }; say $x
camelia rakudo-moar b3e9f5: OUTPUT«Cannot resolve caller postfix:<++>(); none of these signatures match:␤ (Mu:D $a is rw)␤ (Mu:U $a is rw)␤ (Int:D $a is rw)␤ (int $a is rw)␤ (Bool:U $a is rw)␤ (Bool:D $a is rw)␤ (Num:D $a is rw)␤ (Num:U $a is rw)␤ …»
Zoffix :S 11:03
psch that doesn't help with deciding if it's fixed or hidden 11:04
i mean, the bug itself isn't with &EXHAUST, but somewhere in (i think) inlining in moar
Zoffix m: sub foo() { state $x = 0; return $x++ }; my $x; for ^200 { $x = foo }; say $x
camelia rakudo-moar b3e9f5: OUTPUT«199␤»
psch so if we prevent that case of inlining, we don't exercise the bug
jnthn Yeah, that's where I tracked it down to
psch jnthn: right, i'm mostly defering to what i think i remember you writing might cause it :) 11:05
also i'm reminded of the 'sub { sub { 1 } }' bug on jvm 11:06
Zoffix So &EXHAUST stuff prevents inlining?
psch which is also gonna be lots of fun
Zoffix: afaiu it's something about lexical resolution that makes it too complicated for inlining. the clog or jnthn++ probably have a better explanation :)
jnthn Zoffix: Yes, pretty much 11:07
dalek p/return-without-lexotic: 5e5d1c6 | jnthn++ | src/vm/jvm/QAST/Compiler.nqp:
Map some new (currently NYI) ops on JVM.
 11:43
p/return-without-lexotic: ba99288 | jnthn++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/ (3 files):
Implement new lexical handling related ops.
p/return-without-lexotic: 8b55ed4 | jnthn++ | src/vm/jvm/QAST/Compiler.nqp:
Implement handlepayload on JVM.
 11:44
jnthn Phew, I think I got it working... 11:48
oh wow, no wonder I'm hungry, it's nearly 2pm!
|Tux| 12% off. Wonderful. jnthn++ 11:51
brrt stuff well jnthn
|Tux| eager to test once integrated 11:52
psch hrm 11:54
so, trying to fiddle with a named parameter in QAST::Compiler.jast somehow breaks stuff in CodeRefBuilder.jastify
probably something about binding..? vOv 11:55
jnthn |Tux|: Well, that branch merge blocks on me getting the JVM backend updated with the other stuff I was donig in there. I just got NQP working again though (I think)...then will see if Rakudo Just Works :)
*doing
psch jnthn: as long as you don't need to install any CUR for your r-j testing... :S
dalek p/return-without-lexotic: afd690d | jnthn++ | src/NQP/Actions.nqp:
Workaround for until after re-bootstrap.
 12:00
jnthn psch: No...I changed the way return works, so a "make test" in reasonable shape should be fairly sufficient given how common return is :) 12:01
psch jnthn: does 'make test' work without 'make install'?
jnthn: 'cause 'make install' is what we're broken in on r-j atm 12:02
jnthn It should. I mean, it does on Moar.
And it did on JVM back when I originally ported it ;)
psch alright :) 12:03
i mean, yeah, semantically it definitely should, i just don't know if install-core-dist.pl really sits behind 'make install' or not, although i do assume so...
nine It should work, yes. 12:04
And it does on rakudo-m 12:05
jnthn Hm, oddly one continuation test is a bit unhappy in NQP's make test on JVM. Building r-j now. 12:08
Really lunch, while it works at that :) & 12:09
mmm....gorgonzola :) 12:38
Stage parse : Killed
make: *** [CORE.setting.jar] Error 137
gee, that's helpful...
ah, OOM killer :/ 12:39
dalek p/return-without-lexotic: d6bb499 | jnthn++ | src/vm/jvm/QAST/Compiler.nqp:
Add another missing constant.
 12:40
|Tux| one should not mix program code with gorgonzola. Both are awesome, but mixing them is heading for (sticky and smelly) trouble 12:50
psch imagines platters covered in gorgonzola 12:52
dalek p/return-without-lexotic: 891e760 | jnthn++ | src/vm/jvm/QAST/Compiler.nqp:
Add some missing :!inlinable markers.
 12:57
jnthn grr, the nqp-j install is messed up on Windows. It emits an nqp-j.bat that mentions 3rdparty/thing/thing.jar but the things are really installed to just thing.jar 13:52
And that files generated by a Perl script that in turn is generated... :/
nine oh my 13:53
jnthn The reason I discovered this is 'cus I'm seeing if the rakudo-j build works outside of my VM 13:55
Because the reboot after trying to disable the OOM detection gave me an ubuntu that hangs on login 13:56
(Graphical, that is)
And of course reverting what I tweaked didn't help, but I know it installed a bunch of updates too and it was the first reboot since those also :/ 13:57
Anyway, turns out that Rakudo runs into the same error that the NQP continuations test fails with over on Windows, rather than hitting the OOM killer 14:07
So it may just be my VM had too little memory allocated to it
Hm, seems some desktop config got corrupted or something...rescused the VM now too :) 14:24
sexy-coder-girl bisect: my @list = 1; say @list.permutations 14:49
bisectable sexy-coder-girl: exit code on a “good” revision is 1 (which is bad), bisecting with inverted logic
sexy-coder-girl: (2016-04-03) github.com/rakudo/rakudo/commit/0fafd86
sexy-coder-girl star: my @list = 1; say @list.permutations
camelia star-m 2016.04: OUTPUT«((1))␤»
hoelzro Zoffix: it was a *really* out of date rakudo (on my laptop) 15:05
dalek p/return-without-lexotic: 3bd1bdb | jnthn++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/ResumeStatus.java:
Fix return/continuation interaction.

All NQP tests now pass on JVM again.		 15:45
FROGGS[mobile] o/ 16:40
dalek kudo/nom: 66ebd86 | niner++ | src/core/CompUnit/PrecompilationRepository.pm:
Remove obsolete argument of PrecompilationRepository::precompile

The :since argument has not been used anymore since commit c59e4dc44772cb09edeb8aa7f0ce0385f951cf5d and is superseeded by better use of the :force argument.		 17:41
nine Do we have access to something like pubs.opengroup.org/onlinepubs/96999...dtemp.html in the core? 18:01
i.e. a temporary directory?
actually mkstemp would be just as fine 18:03
[Coke] m: IO::Spec::Unix.can('tmpdir').say 18:07
camelia rakudo-moar 66ebd8: OUTPUT«(tmpdir)␤»
nine m: m: ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hm: say $*TMPDIR 18:09
camelia rakudo-moar 66ebd8: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Bogus statement␤at <tmp>:1␤------> m:⏏ ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hm: say $*TMPDIR␤ expecting any of:␤ prefix␤ term␤»
nine m: say $*TMPDIR 18:10
camelia rakudo-moar 66ebd8: OUTPUT«"/tmp".IO␤»
nine That's just the place for temporary files but not the name of a temporary file
BrokenRobot There's File::Temp in ecosystem, so I'm guessing there's no core way to do it 18:11
geekosaur there's differences between platforms. like, on unix you often want to get a temporary file handle with no file associated; you can't do that on Windows, or at least not in anything like the same way 18:12
nine Just to be sure: there are PIDs on Windows, are there? 18:15
geekosaur there are process handles. they are not pids in the unix sense (at some level, they're pointers) 18:16
nine But $PID still gives a unique process identifier that I can use to generate a unique file name? 18:17
FROGGS nine: if you, say, work in a directory exclusively, yes 18:18
nine If I work in a directory exclusively I don't need a unique file name anymore :) I'm thinking about something like my $io = $*TMPDIR.child($*PID ~ '-' ~ $precomp-id); 18:19
FROGGS well, it is unlikely that such a file exists already, but it is technically not impossible 18:21
nine Darn....there's still those .rev-deps files in the way anyway 18:23
I wonder whether I should just go forward with gist.github.com/niner/4910787a3b77...bd401362b8 18:30
Anyone up for discussion?
FROGGS I am if I can be of help 18:31
nine Those .rev-deps files were a good idea at the time for tracking which reverse-dependencies we have to recompile after updating a module. But that was when we only ever used a single precomp store at a time, so everything of interest would be found in the same store. 18:37
Now a reverse dependency may be in a store further up the chain and .rev-deps files are possibly incomplete.
Considering that everything still seems to work, I wonder if we should remove tham alltogether. If not, they have to be integrated better into the PrecompilationStore abstraction which right now is leaky as hell. 18:38
They are also a problem for packaging modules as they are changed on installation of other modules. 18:42
FROGGS hmmm 18:48
but if we would remove them right now, wont we introduce the bug again that I fixed the other day? 18:49
nine FROGGS: indeed! 18:50
All the more reason for finding a good alternative. Because if we depend on .rev-deps files to get this right, the bug should still be present if the files in question are in different repos. 18:52
FROGGS hmmm 18:54
is there something in the git architecture that is similar to our problem? 18:55
nine I wouldn't think so. git objects are immutable.
FROGGS no, I mean searching for reverse dependencies 18:56
nine I don't think this would be enough. The precomp file we need to outdate can be in a repo that's not even in the repo-chain right now. 18:57
FROGGS what if we do it the other way around? 18:58
not trying to recompile the revdeps but to recompile a branch when we see that a depdepdep got changed 18:59
nine The bug is in that we do not correctly detect that a dependency has changed or do not act accordingly and has just been hidden by removing reverse dependencies on precompilation
FROGGS we need an op similar to leadbytecode that reads in a .moarvm, and checks its deps for modified files, recursively 19:01
probably as one op
than you can invalidate an entire branch at once, and can start recompiling
nine It's not only the precompiled dependencies themselves but also their source files 19:02
FROGGS that also solves the case when a repo change is not yet in use, but will be later
yes, that op has to check both
but I believe this is the only robust solution 19:03
nine I think I know what's going wrong in !load-dependencies.
It's quite simple actually.
Given A.pm: use C; use B;
B.pm: use C; 19:04
C.pm: use D;
FROGGS aye, I know that example very vell
nine We try to load A and get the following dependencies: C, B, C, D 19:05
Sorry: D, C, B, D, C 19:06
FROGGS not DCDCB?
I'm confused 19:07
nine just a sec
Damn I sometimes have huge input lag and no idea where it's coming from.
FROGGS on which side of the keyboard? 19:08
nine the digital one
FROGGS k 19:09
nine Ok, maybe I'm wrong after all. Klling the stderr buffering in .precompile to make the order less confusing
Oooook, without completely understanding what's going wrong I have a fix that should make sense. 19:30
Instead of checking each dependency and immediately loading it if it checks out, I now first check all dependencies and load nothing iv ^H^Hf any of them is outdated. 19:31
FROGGS yes, that sounds sane
nine Sucks that I can't seem to be able to figure out why this fixes this specific bug. 19:32
FROGGS you basically have to check the entire tree, and then load the tree if all is fine
nine I'm still not sure why it's needed though. Since dependencies are checked bottom up, they really should not change anymore once we checked them out 19:34
MasterDuke .tell Zoffix i've tried replying to your question on RT #128280 twice, but nothing is showing up. short answer, on arch linux and kubuntu 16.04, both x64 with an up to date rakudo, i get the same seg fault 20:30
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128280
yoleaux2 MasterDuke: I'll pass your message to Zoffix.
nine Of course!
We just don't check dependencies that are already loaded. That's why we don't recognize that B has to be recompiled as well and just try to load it. 20:31
FROGGS: ^^^
FROGGS ohh! 20:33
nine And that's why my check-dependencies-first patch fixes the issue because it unconditionally checks dependencies and only puts the actual loading of the dependency inside the "unless %!loaded{$dependency.id}:exists {"
FROGGS nine: does that mean you can remove the .rev-deps already? 20:37
dalek rakudo/nom: c7cd003 | niner++ | src/core/CompUnit/PrecompilationRepository.pm: 20:40
rakudo/nom: Real fix for RT #128156
rakudo/nom:
rakudo/nom: Check all dependencies first before starting to load any of them.
rakudo/nom: More importantly: unconditionally check all dependencies before trying
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128156
dalek rakudo/nom: to load a precomp file. Previously we did not check a dependency if it
rakudo/nom: has already been loaded.
rakudo/nom:
rakudo/nom: Consider: A depending on C and B. B depending on C. If C is outdated,
rakudo/nom: we already notice that trying to load A. We recompile C and load it.
rakudo/nom: Then when it's time to check B's dependencies, we don't check C because
rakudo/nom: it's already been loaded and therefore not notice that B is outdated, too.
rakudo/nom:
nine FROGGS: testing now
[Coke] nine++ 20:42
FROGGS yeah, nine++ 20:43
gnight 20:46
Zoffix MasterDuke, I'm guessing by up-to-date you mean brewed freshly from source? 20:53
yoleaux2 20:30Z <MasterDuke> Zoffix: i've tried replying to your question on RT #128280 twice, but nothing is showing up. short answer, on arch linux and kubuntu 16.04, both x64 with an up to date rakudo, i get the same seg fault
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128280
nine All tests successful. ==> Successfully installed Task::Star
Zoffix Weird that it works on my box.
nine Looks really good :)
Zoffix nine++
MasterDuke This is Rakudo version 2016.05-145-gac0dcdd built on MoarVM version 2016.05-34-gfbe9e24 implementing Perl 6.c. 20:57
This is Rakudo version 2016.05-145-gac0dcdd built on MoarVM version 2016.05-17-g6075599 implementing Perl 6.c.
Zoffix m: say 'test'
camelia rakudo-moar c7cd00: OUTPUT«test␤»
MasterDuke no crashes after 30+ runs without --profile 20:58
about 1 in 5 crashes with --profile 20:59
Zoffix starts 100 runs 21:01
MasterDuke Zoffix: gist.github.com/MasterDuke17/4c7bb...113be72156 21:08
from the kubuntu system
dalek kudo/fix_precompilationstore_abstraction: 07c8267 | niner++ | src/core/CompUnit/ (2 files):
Remove .rev-deps cache

  .rev-deps files were a good idea at the time for tracking which reverse-
dependencies we have to recompile after updating a module. But that was when we only ever used a single precomp store at a time, so everything of interest would be found in the same store.
Now a reverse dependency may be in a store further up the chain and .rev-deps files are possibly incomplete. They are also a problem for packaging modules as they are changed on installation of other modules. Removing them also clears the way for fixing the PrecompilationStore abstraction.		 21:24
rakudo/fix_precompilationstore_abstraction: 7da09ea | niner++ | src/core/ (4 files):
Zoffix Nothing in 100 runs: gist.github.com/zoffixznet/2611df3...dfac525e8f 21:25
MasterDuke arch linux: gist.github.com/MasterDuke17/ac18f...66dad3034b 21:28
kubuntu: gist.github.com/MasterDuke17/657a2...264ea70c93 21:31
Zoffix m: use Test; subtest 'foo', { ok 1 }; 22:39
camelia rakudo-moar c7cd00: OUTPUT« ok 1 - ␤ 1..1␤ok 1 - foo␤»
Zoffix m: use Test; subtest 'foo' 22:41
camelia rakudo-moar c7cd00: OUTPUT«Type check failed in assignment to &subtests; expected Callable but got Str ("foo")␤ in sub subtest at /home/camelia/rakudo-m-inst-1/share/perl6/sources/C712FE6969F786C9380D643DF17E85D06868219E (Test) line 330␤ in block <unit> at <tmp> line 1␤␤»
Zoffix This should be reverted. The issue is in the roast test itself. It assumes too much about implementation of throws-like. github.com/rakudo/rakudo/commit/9e...c0f0485a3e 22:42
Zoffix is unfamiliar with how such stuff is handled with respect to the roast 22:43
(and the test is fixed in latest and greatest roast) 22:44
bisect: Inf.Rat == 1/0 or die 22:50
bisectable Zoffix: (2016-05-02) github.com/rakudo/rakudo/commit/e2f1fa7
Zoffix m: use Test; subtest { ok 1; }, 'foo1'; subtest { ok 1; }, 'foo2'; subtest { ok 1; }, 'foo3'; 22:54
camelia rakudo-moar c7cd00: OUTPUT« ok 1 - ␤ 1..1␤ok 1 - foo1␤ ok 1 - ␤ 1..1␤ok 2 - foo2␤ ok 1 - ␤ 1..1␤ok 3 - foo3␤»
Zoffix m: for ^1000000 { class Foo {}.new }; say now - INIT now 23:45
camelia rakudo-moar c7cd00: OUTPUT«2.0058901␤»
Zoffix star: for ^1000000 { class Foo {}.new }; say now - INIT now
camelia star-m 2016.04: OUTPUT«5.6419404␤»
Zoffix m: say 5.64 / 2
camelia rakudo-moar c7cd00: OUTPUT«2.82␤»
Zoffix
.oO( seems much faster than the 1.8x the commit indicates... lizmat++ )
 23:46
timotimo try adding some more attributes, that'll probably get you closer to the 1.8x 23:53
Zoffix There's actually another later commit with "another 1.8x" :) 23:55
timotimo oh 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!