Zoffix Any idea what $time_before and $time_after in Test.pm6 are all about? Specifically, why the hell are they backwards? github.com/rakudo/rakudo/blob/nom/...st.pm6#L93 02:11
timotimo they are supposed to measure what's between "ok" calls and such 02:16
you can set PERL6_TEST_TIMES
Zoffix Seems broken. I get negative and NaN times 02:17
Why are they used in a backwards manner? $time_after is assigned at the start of the test and $time_before at the end? Any idea?
(negative and NaN tests output: gist.github.com/zoffixznet/89a9f07...216d9b5104 ) 02:18
timotimo it probably hasn't been tried for a few months :P
at least the way it interacts with subtests
Zoffix jnthn, which behaviour preferred? That it uses relative tolerance by default? irclog.perlgeek.de/perl6/2015-12-15#i_11719919 02:25
Now this Sam person is commenting on my is-approx tickets saying the new relative tolerance should stay and the spec and docs that say it should be absolute are wrong.
And then I see people in the logs wanting is-approx to use ≅ altogether, which has tolerance ten orders of magnitude different. 02:26
Too many damn opinions 02:27
jnthn morning, #perl6-dev 09:21
lizmat: No, a slurpy array is very decidedly an *array*. :) Its mutability is a feature. If you want a List instead (and so the original containers of anything passed) then use `*@a is raw`. 09:22
lizmat: Just looked at List and its various from-slurpy methods (inherited by Array and used in that case too). We could tweak the various from-slurpy methods to fill out the reified part of a list up until they hit something iterable. 09:28
lizmat ok, that sounds like a plan :-) 09:29
jnthn Zoffix: On the tolerance thing, think you'll have to try and get an answer from TimToady on that one. :) 09:33
|Tux| This is Rakudo version 2016.05-32-g33ab868 built on MoarVM version 2016.05 10:10
test 19.667
test-t 12.510
csv-parser 33.775
Zoffix .ask TimToady would you have time to offer a ruling on what the default tolerance to is-approx in Test.pm6 should be? Is it relative or absolute, and what value? My ideal choice would be absolute with $*TOLERANCE to match ≅. The specs/docs use absolute at 1e-5. And current impl uses relative at 1e-6. My more detailed plan for rewrite of is-approx: github.com/zoffixznet/debug/blob/m...-rework.md 10:20
no robot? :/ 10:21
oh, ≅ doesn't use absolute 10:31
stmuk maybe if it's approx it should use a random tolerance? :) 10:46
jnthn bah, no wonder spectest in my VM is slow...I only gave it a core or two... 10:48
Zoffix stmuk, Congrats! You did it! I didn't think it was possible to add any more posibilities to bikeshed from, but you've done it :P
jnthn, the other day I spent 20 minutes debugging async code, wondering why it wasn't giving any speed up over non-async, until I reliazed my VM was set to use a single core :P 10:49
jnthn heh, that's ones of the easier reasons for it not to, yes ;) 10:50
This is sufficiently slow I think it might actually have been faster to shut down the VM, tweak the core count, then start it up, then spectest :P 10:51
nine jnthn: can't you up the core count on line? 11:05
jnthn nine: Apparently not.
I did try :)
dalek p: 89345b4 | jnthn++ | tools/build/MOAR_REVISION:
Bump MOAR_REVISION.

For performance improvements, spesh fixes.		 11:11
kudo/nom: 3cb602d | jnthn++ | tools/build/NQP_REVISION:
Bump NQP_REVISION for an improved MoarVM.

Various performance improvements, and a couple of spesh fixes.		 11:12
kudo/nom: 7250543 | jnthn++ | src/ (2 files):
Eliminate &EXHAUST and the use of it.

We used to use it to replace the RETURN lexical, used for implementing
  (lexotic) return. At one point, it would also give an improved error
for the case of returning from an already returned routine. However, at this point it did not do so, and there are better ways to make that happen. It did, however, carry a high cost, and frustrated inlining. Its removal made one simple loop/methodcall/increment benchmark run in 63% of the CPU cycles it previously did, which is a nice win.		 11:16
RabidGravy looks good 11:28
jnthn That MoarVM bump includes a change that should give rather faster Rakudo builds too 11:52
travis-ci Rakudo build failed. Jonathan Worthington 'Bump NQP_REVISION for an improved MoarVM. 12:15
travis-ci.org/rakudo/rakudo/builds/134417129 github.com/rakudo/rakudo/compare/3...b602d2ce51
perlpilot heh 12:33
"faster builds" ... "build failed" That *is* fast :)
jnthn That's the already-busted "make install" on JVM rather than a regression 12:37
Or at least, the mail I got said "still failing"
dalek kudo/nom: ef376d1 | peschwa++ | .travis.yml:
Ignore JVM on all platforms again.

  ...because it's apparently too hard to fix and thus just noisy.		 13:00
psch ...i give up :P
well, at least with maintaining my position re "that should be reported", for now
dalek ast: 5dcca8c | (Tom Browder)++ | S26-documentation/07-tables.t:
comment out the test because it causes an exception even with the 'todo' function
 13:09
ast: c2e994d | (Tom Browder)++ | S26-documentation/07-tables.t:
Merge pull request #122 from tbrowder/mod-roast-table-test

comment out the test because it causes an exception even with the 'to…
psch shouldn't that be a 'skip' instead of commented?
dalek kudo/rt128156_fix_precomp_deps_validation: ab446d6 | niner++ | src/core/CompUnit/Precompilation (3 files):
Fix precomp dependency checks on file systems with coarse timestamps.

Replace fragile timestamp check by checksums for deciding whether a precompiled dependency is still the same.
Many thanks to pmurias++ for suggesting using a hash!
travis-ci Rakudo build failed. Jonathan Worthington 'Eliminate &EXHAUST and the use of it. 13:10
travis-ci.org/rakudo/rakudo/builds/134417965 github.com/rakudo/rakudo/compare/3...5054360efa
Rakudo build failed. Pepe Schwarz 'Ignore JVM on all platforms again. 14:03
travis-ci.org/rakudo/rakudo/builds/134440810 github.com/rakudo/rakudo/compare/7...376d197ab3
[Coke] is t/fudgeandrun failing for other folks? 14:49
I used to be able to use that to run & fudge multiple t/spec tests, now it's complaining about missing Test 14:50
psch oh, of course i mess up the travis.yml /o\ 14:54
dalek p: a9ec466 | jnthn++ | src/vm/moar/QAST/QASTOperationsMAST.nqp:
Improve code-gen by avoiding redundant deconts.

Sometimes, we can cheaply figure out we don't need to insert them into the code at all. Do so. Shaves 3.6KB off NQP build size, 16.2KB off Rakudo compiler build size, and 55.8KB off CORE.setting bytecode size. A loop/method call/increment benchmark runs 0.3% less CPU instructions thanks to this change also.
japhb jnthn: Pretty please add said benchmark to perl6-bench. :-) 14:58
dalek kudo/nom: 4a2929c | peschwa++ | .travis.yml:
Fix allow_failures, hopefully.
psch kind of weird that the previous attempt doesn't work, but then i don't really know YAML either vOv
RabidGravy anyway, all my modules are good with the "Rakudo version 2016.05-35-gef376d1 built on MoarVM version 2016.05-17-g6075599" 15:27
travis-ci Rakudo build passed. Pepe Schwarz 'Fix allow_failures, hopefully.' 16:17
travis-ci.org/rakudo/rakudo/builds/134472643 github.com/rakudo/rakudo/compare/e...2929cf864a
nine psch: have you made any progress at all on the EVAL issue? 18:29
psch nine: no, none at all. hence the change to .travis.yml 18:30
nine Do you at least have an idea which direction may be worth looking into? 18:31
psch my last idea was trying to look into the generated .class file and see what's up with the setcodeobj calls, but that didn't really get going, because i didn't really find out *which* class file i'd have to examine... 18:32
aside from that, i think we agreed that writing the coderef probably works, but somewhere between deserialization and loading it breaks?
nine Yes, when I prevent it from serializing the EVAL's code objects I get an NPE in SerializationReader::deserialize because it expects a larger number of code refs than stored. 18:39
psch iirc not calling deserialize_code if the current CU is_nested did compile, but broke later in rakudo during make 18:40
in case that's any kind of hint 18:41
i really didn't get far into understanding all of this :/
nine # Add code object fixups.
if !$is_nested && $cu.code_ref_blocks() {
psch i mean in vm/jvm/QAST/Compiler.nqp:3370 or thereabout 18:42
i'm not sure i don't have any changes left locally that might change the line number :)
nine # If we need to do deserialization, emit code for that.
if $*COMP_MODE && !$is_nested {
is what I currently have there
psch right, that's what i was working with too 18:43
nine Well to me the $is_nested check I posted first would make sense. It's just that we use the $cu.code_ref_blocks() array as is for determining how many code blocks we have to deserialize even though with this check we store less of them. 18:44
So I now give simply adding a null check a try and see how far I come.
Well.... Unhandled exception: java.lang.RuntimeException: Missing or wrong version of dependency 'src/Perl6/Pod.nqp'
psch yeah, that one's horribly annoying as well :/ 18:45
i usually git clean -xdf in rakudo, make install in nqp, and then Configure.pl --backends=jvm --make-install
nine Because a 3 minute compile cycle is not horrible enough
psch heh 18:46
nine rm blib/Perl6/* install/share/nqp/lib/Perl6/* seems to do the trick
psch on hack moar with a clean prefix is over 3 minutes :P
nine This is...difficult. On the one hand the compiler seems to need code_ref_blocks to contain the EVAL's code refs, too. On the other hand, it may not serialize those code refs. 19:08
I wonder why the JVM needs this setcodeobj call and Moar doesn't 19:19
geekosaur you can't add features to the jvm the way you can to moar 19:20
you have to come up with ways to work with what it has
nine I don't get that when I add the !$is_nested condition, the code objects seem to be missing from the serialization file. The condition only prevents the code from running during the EVAL's compilation, but it should still be done during the outer comp unit's. 19:53
But it clearly isn't. Otherwise those code objects shoud appear twice in the debug output 20:07
Oh...we simply don't make it that far! 20:24
The setcodeobj error occurs during compilation of the EVAL 20:25
So I'm back to thinking that the !$is_nested check is actually correct 20:27
dalek kudo/nom: 99dfd47 | lizmat++ | src/core/List.pm:
Streamline List.reifiers a bit (gives a few %)
 21:52
kudo/nom: 069b789 | lizmat++ | src/core/Array.pm:
Streamline Array.iterator, fix handling of holes

  - gives about 10% improvement in iterating over Arrays
  - separate iterator for reifying/non-reifying case
  - make sure a fully reified Array resets the todo list
  - don't check for elems, handle null as a sign for something special
  - create a vivifying container for holes in the Array
jnthn is glad the GLR lists impl has ended up with a decent bus number :) 21:58
lizmat++ # optimizing
lizmat :-) 21:59
next step: sequential-map's sink-all implementation
jnthn: can we actually shift something non-concrete from a nqp::list ? 22:01
jnthn Certainly
m: say [Any, Any].shift
camelia rakudo-moar 4a2929: OUTPUT«(Any)␤»
jnthn For example :)
lizmat hmmm... 22:02
I guess I still don't fully grok the difference between .DEFINITE and nqp::isconcrete
good night, #perl6-dev! 22:08
timotimo i think the only difference is that .DEFINITE maps to p6definite 22:14
jnthn x.DEFINITE is just nqp::p6bool(nqp::isconcrete(x)) 22:16
timotimo oh 22:28
jnthn sleep & 22:37
tomboy64 nine: may i inquire about the progress of your jvm work? 22:38

Powered by Cro and the Raku® Programming Language.

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

Thank you!