dalek ast: 417f454 | usev6++ | S32-num/rat.t:
Skip test for RT #128264 on JVM
 04:34
[Tux] This is Rakudo version 2016.05-14-g1ab1fb6 built on MoarVM version 2016.05 07:29
test 20.456
test-t 13.220
csv-parser 34.131
masak [Tux]: what's the general trend lately? 08:13
[Tux] stable 08:18
tux.nl/Talks/CSV6/images/test-t-14.png 08:19
lizmat & me discussed the noise window yesterday and we think it is like 1.25 sec
dalek kudo/nom: 5638a13 | moritz++ | lib/Test.pm6:
Remove diag() call from subtest

this is not what diag is for, and the overall response to this has not been positive.		 09:08
travis-ci Rakudo build failed. Moritz Lenz 'Remove diag() call from subtest 10:10
travis-ci.org/rakudo/rakudo/builds/133326163 github.com/rakudo/rakudo/compare/1...38a13ab46b
jnthn A slide deck on work towards cancellation of promises in the JS world: docs.google.com/presentation/d/1V4...9e470d_0_0 10:16
Borrowing a good amount from the .Net approach also 10:17
A problem we'll want to take on at some point also. 10:18
masak jnthn: I find it interesting that people (notably getify) are upset about promises getting cancelable. 11:53
jnthn masak: One reason I didn't do anything about it in Perl 6 promises so far is 'cus it's, well, a hard problem :) 12:10
And I figured we might be able to borrow things from the best solutions that show up 12:11
masak: Any good reading on what they don't like about the plans?
masak yes, as it happens. let me find the reference for you. 12:22
but the tl;dr is: it's basically a philosophical disagreement, as in "the Promise interface (as ideally envisioned) doesn't do that" 12:23
"Promises cannot be canceled -- and shouldn't be as that would destroy the external immutability trust discussed in the "Promise Uncancelable" section later in this chapter -- so they can only be silently ignored." -- github.com/getify/You-Dont-Know-JS...nce/ch3.md 12:24
dalek kudo/nom: 13ad297 | lizmat++ | src/core/List.pm:
A little List.iterator streamlining
 12:25
masak "the problem is that it would let one consumer/observer of a Promise affect some other consumer's ability to observe that same Promise. This violates the future-value's trustability (external immutability)" 12:33
(ibid.)
jnthn aha 12:34
Yes, that's a good argument.
dalek kudo/nom: e0e8f30 | lizmat++ | src/core/ (2 files):
List.iterator -> Array, simplify List.iterator

Part one of some refactoring creating a better and faster Array.iterator		 12:48
Woodi "the problem is that it would let one consumer/observer of a Promise affect..." - there is some strange definition of promises there, IMO... I thinked promises are just functions "backgrounded" and private like normal variables. if somethink other can observe it then it is totally other system and only in this *other* system cancelling influence other observers... 12:58
masak Woodi: promises are objects. objects have references. references can be shared across the program. therefore, different consumers can observe the same promise. 13:10
that's not a strange definition. that's how it's set up to work.
Woodi masak: ok, so sharing makes computation processes waste cpu... canceled promise can be a NULL in some shared struct. 13:17
dalek p: 1b591b3 | peschwa++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java:
Revert "Revert "Merge pull request #287 from MasterDuke17/master""

This reverts commit 8e105721e877011ba317a5bed27db81949ebd4a5.
kudo/nom: 86e3e29 | (Daniel Green)++ | / (2 files):
Fix RT #128073. Also some further cleanup of IO::Path.dir to remove some VM specific code.
 13:18
kudo/nom: a80414e | peschwa++ | / (2 files):
Merge pull request #772 from MasterDuke17/RT128073

Fix RT #772
Confirmed locally that the current R-J failure mode doesn't change with this and NQP PR #287.
travis-ci Rakudo build failed. Elizabeth Mattijsen 'A little List.iterator streamlining' 13:28
travis-ci.org/rakudo/rakudo/builds/133366703 github.com/rakudo/rakudo/compare/5...ad297460b7
nwc10 not sure if this is old news, or the wrong channel 13:34
but commit 86e3e2955b733e77287a0c3d4807dc0f339a875b seems to set tools/build/NQP_REVISION to a revision that's in the future.
psch nwc10: ah, right 13:35
i saw that locally, but overlooked to fix it
dalek kudo/nom: e5bd09e | peschwa++ | tools/build/NQP_REVISION:
Fix NQP_REVISION

Thanks nwc10++ for the reminder.		 13:36
nwc10 thanks for the fix - past the Configure.pl stage and into testing the build... 13:37
psch it still breaks during install-core-dist.pl
nine++ says that's because the "BEGIN EVAL during precomp" fix hasn't landed for r-j yet 13:38
unfortunately i don't know what to look at to find that fix, nor how to fix it without cargo-culting the moar solution
lizmat afk for a few hours& 14:03
nwc10 it worked. building jnthn's next MoarVM iteration... 14:04
travis-ci Rakudo build failed. Elizabeth Mattijsen 'List.iterator -> Array, simplify List.iterator 14:21
travis-ci.org/rakudo/rakudo/builds/133371745 github.com/rakudo/rakudo/compare/1...e8f3010d76
masak Woodi: "waste CPU" is also not the issue. 14:45
Woodi: let's say consumers A and B are each holding a reference to the same promise. what's the *guarantee* that an unresolved promise gives? right, that it succeeds or fails. 14:46
now, let A cancel the promise. that guarantee is now broken for B.
MadcapJake But not broken, according to that presentation, it's a third state: canceled 14:53
which is why the promise api mentioned also has to be reworked to include cancel callbacks 14:54
Woodi masak: cancelling by A can result in failure for B (and A too). but main problem for me is: hey thread buddy, allow me to share this function *call* with you! :) promise result can be shared freely, but a "function call" ? 14:56
MadcapJake the "trustability" argument rings false to me because, at least according to the presentation, it would be entirely dependent on the producer handling a CancelToken, iiuc 14:57
travis-ci Rakudo build failed. peschwa 'Merge pull request #772 from MasterDuke17/RT128073 15:06
travis-ci.org/rakudo/rakudo/builds/133378699 github.com/rakudo/rakudo/compare/e...0414edc119
psch i *really* wish i knew how to fix that setcodeobj bug :( 15:08
masak I wonder how much already-written JS code that uses Promises will become wrong in the face of cancellation. 15:10
MadcapJake none, it's the last argument in all cases 15:11
travis-ci Rakudo build failed. Pepe Schwarz 'Fix NQP_REVISION 15:48
travis-ci.org/rakudo/rakudo/builds/133383717 github.com/rakudo/rakudo/compare/a...bd09e3f99c
nine psch: in short the fix is about breaking the assumption that there's a 1:1:1 relationship between compilation unit, serialization context and byte code compiler instance 17:03
psch ...i don't think that helps me understand :) 17:04
nine psch: usually the compiler has to compile one compilation unit, store the objects created during compilation into the current serialization context and have a byte code compiler serialize the result into a file. 17:05
psch: EVALs though are a compilation unit of their own. But they do not have their own file where the result could be stored. 17:06
psch: so instead we store those objects into the serialization context of the surrounding comp unit.
Sounds rather easy and straight forward conceptually, but it breaks the assumption I mentioned in several places in the whole compiler stack. 17:08
psch nine: i think i'll have to retrace this with a fresher brain than i have available right now, to even understand it 17:12
i doubt i'll come to a solution, still
fwiw, i'd still like the commit that fixed it on moar, if you still have its hash around 17:13
nine psch: github.com/perl6/nqp/commit/cbdf5b...4c9a73bd63 github.com/perl6/nqp/commit/125eb3...4af6cc0e84 github.com/rakudo/rakudo/commit/ad...934af3184c github.com/rakudo/rakudo/commit/6d...5be0ed72c4 17:17
psch nine: thanks. i'll see if i get around to digging into that, coupled with your explanation, during the weekend 17:19
nine psch: I guess that the modifications to src/vm/moar/QAST/QASTCompilerMAST.nqp the first NQP commit does are the key
psch: that would be awesome :) Will visit my parents over the weekend so will not have real coding time. And so far I've not exactly made good progress :/ 17:20
I'm a complete newbie to the JVM backend after all and it's quite different to MoarVM in places
psch nine: well, i'd really like travis to finally shutup, without having to tell it not to report r-j build failures... :)
nine: and i really just have no idea right now what is even wrong in the first place 17:21
symtomatically it's just "we hand a null value to setcodeobj", but clearly there's a lot more going on
and even if i'm somewhat familiar with nqp-j, i'm really not particularly familiar with the architecture as such
nine Could be that we share too many bits between the EVAL's compilation unit and the outer compilation unit. 17:22
or too few 17:23
psch well, my naive interpretation of the error message would be that we lose the reference to the EVAL coderef while writing the surrounding CU 17:25
but yeah, i have no idea how good a guess that is, because i don't really know what's actually going on... :) 17:26
nine That's probably quite close to the truth. Only compilcated by the fact that for code objects rakudo installs a stub (in finish_code_object) that when called finishes compilation of this code object early so it can be called during compilation. 17:30
That's how BEGIN stuff works and what we need for the EVAL in question. Because it's run as part of module loading, which usually means a "use" or "need" statement which are BEGIN time by definition. 17:31
psch so the crux of the issue probably comes down to "finish_code_object doesn't handle one specific edge case correctly"? 17:33
well, i think i have enough to go on for tomorrow right now, thanks for the explanations :) 17:34
nine More or less, yes. Thanks for having a look :) 17:38
[Coke] RT: 1299; CONC: 7; GLR: 6; JVM: 68; LHF: 1; LTA: 74; NYI: 28; OSX: 6; PERF: 15; POD: 3; PRECOMP: 3; RFC: 19; SEGV: 19; STAR: 1; TESTNEEDED: 29; TODO: 9; UNI: 5; WEIRD: 3 18:04
dalek kudo/nom: d2f6e6a | lizmat++ | src/core/Rakudo/Internals.pm:
Add EmptyIterator class

Needed for List/Array.iterator streamlining		 21:33
kudo/nom: 1b13351 | lizmat++ | src/core/Hash.pm:
Bring Hash.keyof up to date, dogbert17++
kudo/nom: 1135805 | lizmat++ | src/core/Hash.pm:
Revert "Bring Hash.keyof up to date, dogbert17++"

This reverts commit 1b13351eacf7ebc1a460151301180705c269b50a.
Will look at this later		 21:36
kudo/nom: be4e439 | jnthn++ | src/Perl6/Metamodel/CoercionHOW.nqp:
Implement shortname method in CoercionHOW.
 21:41
jnthn m: use Test; is Str(Any).gist, 'Str(Any)', 'Can gist a coercion type'; 21:44
camelia rakudo-moar e5bd09: OUTPUT«Method 'shortname' not found for invocant of class 'Perl6::Metamodel::CoercionHOW'␤ in block <unit> at /tmp/ONwb9iR_vD line 1␤␤»
dalek ast: de11e00 | jnthn++ | S12-coercion/coercion-types.t:
Add test for coercion type .gist.
 21:45
jnthn lizmat: That bit's fixed, at least :)
lizmat jnthn: if we're iterated over a list once, should be expect all elements to be reified ? 22:02
*we've
*we
*sigh*
I guess I have more jetlag than I thought
jnthn lizmat: Well, if we completed the iteration, yes 22:03
lizmat ok, I guess we're not resetting $!todo in the List.iterator 22:04
so any subsequent iteration will take the slow path
jnthn $!todo should be cleared after the list is fully reified.
lizmat ack
jnthn iirc anyway :)
sleep time & 22:09
timotimo rest well, jnthn :)
lizmat good night, jnthn 22:10
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Bring Hash.keyof up to date, dogbert17++' 22:34
travis-ci.org/rakudo/rakudo/builds/133495837 github.com/rakudo/rakudo/compare/e...13351eacf7
timotimo looks like it's just java interop and nativecall on the jvm backend b0rking 22:37
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Revert "Bring Hash.keyof up to date, dogbert17++" 23:27
travis-ci.org/rakudo/rakudo/builds/133496504 github.com/rakudo/rakudo/compare/1...3580583895

Powered by Cro and the Raku® Programming Language.

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

Thank you!