01:47 ilbot3 joined 05:58 TimToady joined 05:59 RabidGravy joined 06:17 sno joined 06:31 lizmat joined 08:16 [TuxCM] joined, lizmat joined
dalek kudo/nom: 63fd14f | lizmat++ | src/core/Num.pm:
Streamline some Num infixes
 08:41
lizmat ok, I think we need to revisit NaN.Int and NaN.Rat 08:51
as well as Inf.Int and Inf.Rat
they both now fail
m: NaN.Int
camelia rakudo-moar 63fd14: OUTPUT«Cannot coerce NaN to an Int␤ in block <unit> at /tmp/14Mto5fMdk line 1␤␤Actually thrown at:␤ in block <unit> at /tmp/14Mto5fMdk line 1␤␤»
lizmat m: NaN.Rat
camelia rakudo-moar 63fd14: OUTPUT«Cannot coerce NaN to a Rat␤ in block <unit> at /tmp/QepqhxrXo3 line 1␤␤Actually thrown at:␤ in block <unit> at /tmp/QepqhxrXo3 line 1␤␤»
lizmat m: Inf.Int 08:52
camelia rakudo-moar 63fd14: OUTPUT«Cannot coerce Inf to an Int␤ in block <unit> at /tmp/nc9oDyzOT2 line 1␤␤Actually thrown at:␤ in block <unit> at /tmp/nc9oDyzOT2 line 1␤␤»
lizmat m: Inf.Rat
camelia rakudo-moar 63fd14: OUTPUT«Cannot coerce Inf to a Rat␤ in block <unit> at /tmp/309s0PH0QL line 1␤␤Actually thrown at:␤ in block <unit> at /tmp/309s0PH0QL line 1␤␤»
lizmat however, spectests indicate the opposite view
S32-num/rat.t, test 749-751 (which now fail) 08:53
and S02-types/infinity.t that has 3 todo'd tests
either we should match rakudo with the tests, or vice-versa
fwiw, *I* prefer the current behaviour, meaning tests should be adapted 08:54
if in the future, we manage to hack Inf into Int and Rat, we can lift the fail 08:55
dalek kudo/nom: 689d079 | lizmat++ | src/core/Rat.pm:
Streamline some Rats

  - Rat.perl if denominator is 1
  - return Failure instead of failing for FatRat.Rat		 08:57
ast: 61e65a4 | lizmat++ | S32-num/rat.t:
Todo NaN/Inf/-Inf.Rat tests

Since we've todo'd the NaN/Inf/-Inf.Int as well		 09:05
kudo/nom: 45be4ef | lizmat++ | src/core/Any-iterable-methods.pm:
Change some fails into Failure.new

Because if it's the value we're about to return anyway, we don't need the fail exception to deliver it		 09:13
Tux__ Cannot invoke this object (REPR: Null) 09:20
t/78_fragment.t ... Dubious, test returned 1 (wstat 256, 0x100)
No subtests run
broken between yesterday and now
p6 t/78_fragment.t
PASS
09:21 [TuxCM] joined
Tux__ consistent fail when invoked as «prove -j4 -e 'perl6 -I. -Ilib' t» 09:21
lizmat interesting... 09:22
does this include any of my patches of this morning ?
aka, what is "now" ?
Tux__ This is Rakudo version 2016.04-89-gec6c3b8 built on MoarVM version 2016.04 09:23
perl6 was built on 10:37 09:24
if a standalone run passes, but prove fails, where shall the cause be found? 09:25
lizmat if you include PERL6LIB=lib in standalone run ?
Tux__ env PERL6LIB=lib make test => PASS / make test => FAIL 09:30
This is Rakudo version 2016.04-89-gec6c3b8 built on MoarVM version 2016.04
test 21.623
test-t 13.254
csv-parser 37.589
p6 t/78_fragment.t => PASS, env PERL6LIB=lib p6 t/78_fragment.t => PASS 09:31
prove -j4 -e 'perl6 -I. -Ilib' t/78_fragment.t => PASS, prove -j4 -e 'perl6 -I. -Ilib' t => FAIL 09:32
so, parrallel testing conflict? 09:33
lizmat that would be weird ? 09:36
will look at it in a mo 09:39
dalek kudo/nom: a56d039 | lizmat++ | src/core/Any.pm:
Streamline some Any fallbacks

  - don't fail if we can directly return a Failure
  - use ternaries where possible
  - use postfix loops where possible
  - make smarter use of loop indexes where possible		 09:41
kudo/nom: 6a82e2a | lizmat++ | src/core/Array.pm:
Streamline some Array ops

  - return Failure if we can, instead of fail
  - use ternaries where possible
  - don't bother creating local aliases for private attribute		 10:03
RabidGravy boom 10:14
10:46 brrt joined
dalek kudo/nom: 1939405 | lizmat++ | src/core/Buf.pm:
Streamline Blob/Buf

  - don't fail when we can return a Failure
  - use ternaries where possible		 10:47
kudo/nom: 4e4cac0 | lizmat++ | src/core/Capture.pm:
Streamline Capture

  - return Failure instead of failing		 11:09
kudo/nom: 480709d | lizmat++ | src/core/Complex.pm:
Streamline Complex

  - use ternary when possible
  - return Failure rather than failing		 11:37
11:43 brrt joined 13:08 brrt joined
dalek kudo/nom: 1ee27e6 | jnthn++ | src/core/Promise.pm:
Harden Promise.result against spurious wakeups.

This prevents it from bogusly returning that a Promise was kept in cases where it was not, in fact, kept, and the OS just signalled the condvar spuriously.		 13:34
rakudo/nom: 475063a | jnthn++ | src/core/Mu.pm:
rakudo/nom: Harden Mu.Str against moving GC.
rakudo/nom:
rakudo/nom: We have various cases of this in tests:
rakudo/nom:
jnthn lizmat: 1ee27e6 hopefully nails that Promise issue you mentioned being kinda common on OSX 13:36
[Coke] 6.c-errata now failing tests: t/spec/S32-num/rat.rakudo.moar
(and t/spec/S17-supply/syntax.t just hung there again on os x) 13:37
also 2 passing todo'd tests.
dalek kudo/moar/reframe: 19e7a1b | jnthn++ | src/vm/moar/ops/perl6_ops.c:
Sync with MoarVM API changes.
 13:39
kudo/moar/reframe: df1db5e | jnthn++ | src/vm/moar/ops/perl6_ops.c:
Add an MVMROOT on ctx, now frames are GCable.
jnthn (just rebased that branch) 13:42
brrt you rebased reframe... i'll rebase reframe-jit too, then 13:45
shall i merge reframe-jit on top of reframe? 13:46
jnthn brrt: no, only the Rakudo moar/reframe branch
brrt oh, ok
nm :-)
jnthn Just to ease testing, 'cus otherwise I see failing spectests 'cus I'm missing Rakudo commits
[Coke] lizmat: I assume the failing 6.c tests are the same as irclog.perlgeek.de/p6dev/2016-05-04#i_12431564 - I'm opening a ticket, making it a blocker for the next release. 13:54
still no volunteer for the may release for rakudo/nqp 14:01
14:25 perlpilot_ joined 14:27 perlpilot joined 14:43 dalek joined 14:44 perlpilot_ joined 14:50 brrt joined 14:52 skids joined
Tux__ This is Rakudo version 2016.04-99-g475063a built on MoarVM version 2016.04 14:57
test 21.708
test-t 13.397
csv-parser 34.835
lizmat, na re-make
dus geen FAIL meer
sorry, that was Dutch
MadcapJake woah that seems to be quite the improvement! 15:06
jnthn I thought test-t used to be 12.something? Or did one of the other numbers I watch less get better? :) 15:07
MadcapJake jnthn: looks like it was even close to 11 at one point irclog.perlgeek.de/perl6/search/?ni...p;q=test-t 15:13
Tux__ tux.nl/Talks/CSV6/speed4.html includes the full history: tux.nl/Talks/CSV6/speed.log 15:15
dalek p: 5676e10 | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
[js] Support declaring a variable as a static lexical and then using it as a typevar.
 15:18
p: f280dff | (Pawel Murias)++ | src/vm/js/Operations.nqp:
[js] Expose the BOOL type when declaring ops from compiled code.
p: 25600fd | (Pawel Murias)++ | src/vm/js/ (7 files):
[js] Keep privates attributes from ancestor classes separate.
p: 510670b | (Pawel Murias)++ | src/vm/js/RegexCompiler.nqp:
[js] Access the attributes of the cursor in regexes properlyy
p: 0e80681 | (Pawel Murias)++ | src/vm/js/RegexCompiler.nqp:
[js] Remove debugging leftover.
 15:21
p: 3011392 | (Pawel Murias)++ | src/vm/js/nqp-runtime/runtime.js:
[js] Remove dead code.
MadcapJake Tux__: cool thanks for the link! 15:22
dalek p: 116df25 | (Pawel Murias)++ | src/vm/js/nqp-runtime/core.js:
[js] Implement nqp::hintfor.
 15:29
p: a69e45c | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
[js] Fix bug.
 16:28
p: 10069d7 | (Pawel Murias)++ | src/vm/js/nqp-runtime/core.js:
[js] Make nqp::hintfor return -1 when encountering something that's not a P6opaque.
p: 43fb5d6 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
[js] Fix bug.
MadcapJake .seen Skarsnik 17:01
17:54 hankache joined 18:21 dalek joined 18:34 perlpilot joined
lizmat jnthn: re 475063a , shouldn't we harden .WHERE ? 18:57
jnthn lizmat: ??? 18:58
No
The point of .WHERE is "where is the object in memory"
lizmat ok
jnthn There's nothing to harden
lizmat but where it is in memory, is basically volatile info 18:59
jnthn Correct :)
Which is why we've nqp::objectid (which .WHICH uses)
lizmat if an object has moved out of the nursery, can we be sure that it will stay at the same memory address ?
jnthn Well, the present MoarVM answer is yes, but the Perl 6 answer in general is no 19:00
lizmat ah, ok, gotcha...
jnthn All it'd take for it not to be true on Moar is us stating to compact gen2 also
And the JVM has a range of collectors 19:01
lizmat I wonder whether we should mix in a role in the .WHERE value
that would make it croak when used in a NativeCall related environment ?
because that would be obviously a wrong thing to do ?
jnthn It'd be a weird thing to do though
I mean, you'd be passing the address of a Perl 6 object, not something that'll make sense in C-land. 19:02
lizmat well, some people might think that
especially coming from p5 land
jnthn It's still a stretch IMO...you'd have gotten an Int back from WHERE, and so to be able to pass it would have had to purposefully translate the signature of the C function you planned to call in such a way that you wrote Int in the signature in place of something wanting a pointer. 19:05
sub foo(SomeCStruct $foo) is native(...) {*}; will die if called as foo($something.WHERE) already 19:06
bbi10
lizmat jnthn: fwiw, 1ee27e660a8dce3ae03177 makes spectest run with HARNESS_TYPE=6 19:11
running one now with TEST_JOBS=1
hmmm... had a test hanging, now ran it with TEST_JOBS=8, and got a segfault 19:20
I guess I'm going to try this again when the Moar changes have landed :-)
jnthn Still, progress... 19:26
I've still got various smaller ways to trigger problems that I need to hunt down. 19:27
(Beyond the ones I already fixed in the reframe branch) 19:28
lizmat yes, definitely progress
jnthn So I'll chug through those before trying to find 'em from the 6harness :)
lizmat also, the hang could have been caused by me recompiling rakudo underneath :-)
jnthn ah
Maybe
lizmat I'll start another run before going to bed
it's slow with TEST_JOBS=1 :-) 19:29
jnthn lol
No
It's slow with an 11.5KB nursery :P
That run came out really well compared to the one I did a couple of weeks ago, though. 19:30
lizmat m: sub a(--> Nil) { Failure.new("foo") }; a.defined # this feels peculiar 19:51
camelia rakudo-moar 475063: OUTPUT«foo␤ in block <unit> at /tmp/CiklublGPh line 1␤␤Actually thrown at:␤ in sub a at /tmp/CiklublGPh line 1␤ in block <unit> at /tmp/CiklublGPh line 1␤␤»
lizmat m: sub a() { Failure.new("foo") }; a.defined # silent without the --> Nil
camelia ( no output )
geekosaur guessing... it's smart enough to not bother trying to sink something that is known at compile time not to produce a result? 19:54
(thus the a.defined never "happens")
jnthn I think the --> Nil makes it sink the body and return Nil 19:56
So the Failure just gets sunk inside the sub
And so what geekosaur said - you never hit defined
lizmat guess so :-)
jnthn sub a(--> Nil) { ... } I think compiles into sub a() { ...; Nil } roughly 19:57
timotimo hm, is --> Nil for subs/methods that aren't supposed to return anything a good performance optimization already?
jnthn Not sure it makes a huge difference. With sub calls the static optimizer could spot the sink call ain't needed and throw it out I guess 19:58
Spesh is making a kinda lame job on the .sink calls at the moment. 19:59
timotimo yeah, i remember something about that 20:02
20:03 sno joined
jnthn Spesh is also on my list of "things in MoarVM due some good attention soon" :) 20:03
nine_ How could this give a "Too many positionals passed; expected 1 argument but got 2"? $precomp-file.print($*REPO.id ~ "\n" ~ $dependencies ~ "\n"); 20:34
lizmat are you looking at the right place ?? (--ll-exception maybe?) 20:37
nine_ Oh, I did not pass a mode to open(), so $precomp-file may be a Failure and it's Mu's print I'm calling 20:38
lizmat there you go :)
those pesky Failures! :-)
nine_ In this case, getting a Failure really does not help more than Perl 5's silence on open failures :/
lizmat well, in newio I once tried to throw the failure immediately 20:47
and it caused quite some spectest breakage :-(
(at least in my memory)
jnthn It's more that .print is a method in Mu, so the Failure fallback doesn't apply 20:49
Method fallback, that is 20:50
nine_ And .print is at the same time something you'd quite often want to do on a file handle
jnthn Yeah. I agree it's LTA. Too tired to know the right place to fix it. :) 20:53
nine_ Well on the up side, my failure case was "file does not exist and stupid programmer forgot to specify write mode on open()", i.e. it's a fail during development, not a case you'd encounter in production 20:54
[Coke] xkcd.com/1676/ - mmm, new unicode to look forward to (hover text) 21:05
nine_ It's a snake! 21:12
dalek kudo/nom: c403742 | lizmat++ | src/core/ (16 files):
A lot more streamlining

  - use ternaries where possible
  - return Failure rather than failing
  - boolify reverse logic ternaries
nine_ Who's idea was it to de-huffmanize ternaries because they are rarely used? 21:13
lizmat :-)
fwiw, I like the congruity with && || 21:14
timotimo "boolify reverse logic ternaries"? 21:15
nine_ Yep, I actually like their look more in Perl 6. I also seem to use them more in Perl 6 than in other languages... 21:16
timotimo i also prefer the way they look in p6, tbh
nine_ Wow...I'm scared. I actually have a working combined mbc + dependency info precomp file implementation 21:20
lizmat timotimo: 21:22
complication expression ?? False !! True
*complicated 21:23
timotimo oh 21:29
jnthn They're flow control, so I think it's kinda nice they stand out :) 21:36
nine_: ooh, nice :) 21:37
lizmat nine_++ 21:38
timotimo whooooaaa 21:40
good work, nine :)
jnthn hopes he sleeps well enough to night to have the concentration to get his frame refactors mostly finished up tomorrow :)
*tonight 21:41
timotimo \o/
[Coke] RT: 1286; GLR: 6; JVM: 60; LHF: 2; LTA: 68; OSX: 3; PATCH: 3; PERF: 16; POD: 3; PRECOMP: 3; SEGV: 22; STAR: 1; TESTNEEDED: 17; UNI: 5; WEIRD: 2
jnthn This part is less bad in so far as if I screw it up I can have Moar reliably explode (as in, no stress test required) :)
timotimo \o/ 21:42
jnthn Also I'll do the minimum "make it work" to get to the merge point, but then there'll be further optimizations on top of it afterwards. 21:43
lizmat jnthn ++ 21:50
good night, #perl6! 22:03
timotimo gnite lizmat
lizmat eh, #p6dev :-)
RabidGravy harr
jnthn 'night, lizmat 22:10
jnthn sleeps also :) 'night 22:30

Powered by Cro and the Raku® Programming Language.

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

Thank you!