Zoffix ARRRRGGGGGGGGGDk.sadjsa dcuwae;kl'rwqeURL;WAsdudrvksadryuads.krhsda.rhsad.hrf.asdfdsahjf.hsdaJF.,M HSadf/hADS.,HDSA.HFASD,H. 00:23
This bug is getting the best of me :(
timotimo precompilation related? 00:24
Zoffix rt.perl.org/Ticket/Display.html?id=128457 00:26
These are print outs generated with my debug statements lol: gist.github.com/zoffixznet/2ad0b22...f9dec9cd33
I just don't get why the working version calls some things just twice and not three times (one for each module).
I think I'll call it a day and release my frustration in Far Cry 4 >_< 00:27
Just kinda annoying, 'cause tomorrow and the day after I'll be at Damian Conway's talks so I won't be able to return to this bug until Wednesday :/
timotimo has to go to bed :\ 00:29
though ... do i really have to? 00:43
Zoffix Well, I'm stumped... Here's a line... literally two say()s in a row: github.com/zoffixznet/rakudo/blob/...tem.pm#L75 00:44
YET, in the working version, only 2 "WHERE IS THE HANDLE" printed, despite 3 '#### CU::FileSystem: $base = `/home/zoffix/CPANPRC/rakudo/bug-test/' printed gist.github.com/zoffixznet/b3ba61a...adf1332ecf 00:45
I just don't get it :S
timotimo change the line that does get printed to see if the same code is running in both versions
also, strace it to force system calls to behave differently with regards to buffering and such?
also, i usually use note instead of say 00:47
so it goes to stderr, not stdout. though that no longer b0rks precomp, so that's not a/the problem 00:48
Zoffix Using note fixed it thanks... 00:54
timotimo :)
jup, IO.
we should stop using async i/o for our blocking IO in any case.
we've had a branch that started that in the past. it didn't work out so cleanly, so it got postposed 00:58
postponed* 00:59
Zoffix timotimo++ replacing all my say()s with note()s actually gave me debug output that makes sense :) 01:08
timotimo yays
i'm glad
and at the same time i'm sad it's necessary
Zoffix m: use nqp; nqp::getcomp('perl6').compile(Q{ run 'ls' })() 01:45
camelia rakudo-moar e071e4: OUTPUTĀ«Perlitoā¤dalek-queueā¤evalbotā¤evalbot.logā¤fooā¤libā¤logā¤mboxā¤nqp-jsā¤p1ā¤p2ā¤p6eval-tokenā¤perl5ā¤rakudo-j-1ā¤rakudo-j-2ā¤rakudo-j-instā¤rakudo-j-inst-1ā¤rakudo-j-inst-2ā¤rakudo-m-1ā¤rakudo-m-2ā¤rakudo-m-instā¤rakudo-m-inst-1ā¤rakā€¦Ā»
Zoffix tsk tsk :)
timotimo oh, it's using a different setting?
Zoffix ĀÆ\_(惄)_/ĀÆ 01:46
timotimo the restricted setting is super weak anyway
and as soon as you have nqp, you can do whatever the hell you want anyway
and NativeCall, of course
dalek kudo/nom: 7489a28 | (Daniel Green)++ | src/core/allomorphs.pm:
Speed up allomorphs.pm's val() by ~5% by converting some statements to their nqp::* equivalents
 02:11
kudo/nom: 4b257a3 | lizmat++ | src/core/allomorphs.pm:
Merge pull request #804 from MasterDuke17/allomorphs.pm_optimizations

Speed up allomorphs.pm's val() by ~5% by converting some statements tā€¦
[Tux] This is Rakudo version 2016.06-49-g4b257a3 built on MoarVM version 2016.06 06:42
test 16.034
test-t 9.718
csv-parser 21.730
psch gist.github.com/peschwa/37e480db6f...c0e2e51a8a that's the (bytecode of) the jmeth that gets somehow tossed after we compile the EVAL that gets invoke inside it... 11:27
the really, really weird part about this is, that, as mentioned yesterday, we seem to compile (in this case) Foo.pm 11:28
which is really just < module Foo { BEGIN EVAL 'say "hi"' } >
and during an apparent first-pass, we get that method for the BEGIN block (i assume, 'cause it has the call to EVAL)
then we compile the nested CU, which apparently is the EVAL itself 11:29
and then we start over compiling Foo.pm, which somehow lost that BEGIN block
hence my approach from yesterday, which is literally "keep every compiled or compiling CU around in the compiler and look there for missing methods"
buuut, for some reason, we don't have *any* static info for a thus-recovered CR 11:30
the thing is, the method looks pretty great from here 11:31
so it's really just down to "how do i get the static info back"
well, and maybe thinking of a way to not have to carry literally everything around while the compiler is alive
nine I can't imagine us really starting over compilation? 11:32
psch well, that's what it looks like from here
i agree though, it'd be really weird
gist.github.com/peschwa/37e480db6f...c0e2e51a8a 11:33
second file
the "compiling $sha, $file" is in method jast in JAST::Compiler
err, QAST::Compiler
so, we somehow do reenter that method 11:34
nine Could be due to Perl6::World::finish_code_object first creating a stub that on execution replaced itself with a Perl6::World::compile_in_context dynamically compiled version of the actual code and executes that. 11:38
psch ...there's too many layers involved for me /o\ 11:43
nine That's exactly what makes this soooo hard :( 11:44
psch yeah, and it's also really damn opaque :| 11:46
like, if it was feasible to step through at least a simple module compilation, *maybe* i'd gain some insight from those 2-3 hours 11:47
but the layers make that already nigh-impossible
dalek p: 2bd6b44 | (Pawel Murias)++ | src/vm/js/const_map.nqp:
[js] Implement nqp::const::CONTROL_RETURN.
 13:02
p: b9dadd8 | (Pawel Murias)++ | src/vm/js/ (2 files):
[js] Implement nqp::handlepayload/nqp::throwpayloadlex/nqp::lastexpayload.

Pass all tests again.
lizmat and yet another quick one from Orlando: p6weekly.wordpress.com/2016/06/27/...m-orlando/ 15:43
BrokenRobot lizmat++ # Good Weekly 16:07
lizmat sits in the lobby of the hotel, spending some hours before really needing to get on the road 16:40
m: MY::.elems # jnthn: is this a bug, or a case of DIHWIDT ? 16:53
camelia rakudo-moar 4b257a: OUTPUTĀ«MVMContext representation does not support elemsā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
lizmat m: say MY::.pairs 16:54
camelia rakudo-moar 4b257a: OUTPUTĀ«($=pod => [] !UNIT_MARKER => (!UNIT_MARKER) EXPORT => (EXPORT) $_ => (Any) $! => Nil ::?PACKAGE => (GLOBAL) GLOBALish => (GLOBAL) $Ā¢ => Nil $=finish => (Mu) $/ => Nil $?PACKAGE => (GLOBAL))ā¤Ā»
lizmat so I have a nice patch that would re-instate "count-only" and "bool-only" for iterators 17:11
and it's breaking on this ^^^
Woodi lizmat: "count" on iterator is strange... IMO, iterators/cursors are interface to walking a struct that allows to hide internals. counting iterators looks to me like special kind of iterators so giving "count" ability to general case is too much... 17:24
lizmat m: my %h = a => 42, b => 666; say %h.elems # why walk here when you know how many elems there are ? 17:26
camelia rakudo-moar 4b257a: OUTPUTĀ«2ā¤Ā»
Woodi when num .elems is known or for traditional structures then using iterators is overkill... 17:29
lizmat indeed... 17:32
so %h.values.elems currently walks the whole hash, I'd like to prevent that
yes, I know it's stupid written like that, but under the hood, these situations may occur more often 17:33
especially in code that polymorphically handles both lists and hashes and ranges 17:34
nine Like in sub foo($values) { do-something-with($values.elems) }; foo(%hash.values)
Woodi maybe here is conflict of abstractions between traditional lists+laziness and OO iterators ? 17:38
lizmat not really a conflict: the count-only/bool-only should *only* be implemented in an Iterator if they can deduce elems/bool *without* producing any values 17:43
like in a string (.comb), or in a hash 17:44
nine I wonder where exactly I took a wrong turn to end up trying to retroactively fix backwards compatibility of a PR that was clearly neither written to be compatible nor has ever tested. 17:48
jnthn lizmat: (.elems) looks like something we should be able to fix. 18:02
dalek kudo/ugexe-dist-interface: 13e845a | niner++ | / (7 files):
Merge branch 'dist-interface' of github.com/ugexe/rakudo into ugexe-dist-interface
 18:03
kudo/ugexe-dist-interface: 1256808 | niner++ | / (5 files):
Fix backwards compatibility issues with repository versions < 2
kudo/ugexe-dist-interface: eaaf51d | niner++ | / (34 files):
Merge branch 'ugexe-dist-interface' of github.com:rakudo/rakudo into ugexe-dist-interface
kudo/ugexe-dist-interface: 0a1b86a | niner++ | src/core/CompUnit/Repository/Installation.pm:
Fix missing scripts and resources of dists installed using legacy interface
lizmat jnthn: fixing nqp::elems on an MVMContext, would be great 18:12
as I'm banging my head for an hour now to work around it and the solutions keeps getting worse and worse 18:13
dalek rakudo/nom: 5a4963f | lizmat++ | src/core/ (7 files): 18:33
rakudo/nom: Re-instate Iterator.countr|bool-only with a twist
rakudo/nom:
rakudo/nom: I too didn't like the removal of .count-only and .bool-only last
rakudo/nom: week. Then I realized it could still work *if* the methods would
rakudo/nom: only be called if they could produce the info *without* generating
rakudo/nom: any values. So now, an Iterator *can* provide these methods for
rakudo/nom: efficiency: if they're not there, then the normal cause of action
rakudo/nom: (generating the values and cache them, then return its result) will
rakudo/nom: be used. If they *do* exist, then they're supposed to return the
rakudo/nom: info *without* generating any values.
rakudo/nom:
rakudo/nom: This breaks one test in t/spec/S02-names/pseudo.t because MVMContext
rakudo/nom: does not know how to provide nqp::elems. This should be fixed one
lizmat commute to MCO& 18:39
[Coke] waves from the highway 20:58
lizmat waves from MCO 21:02
DrForr_ On the way out finally? 21:08
timotimo o/ 21:10
lizmat DrForr_: yup
after a nice visit to Kennedy Space Center yesterday
DrForr_ Looks like you at least had a good time, I saw that. 21:11
lizmat hehe, yeah that picture has been liked a lot :-)
boarding& 23:39

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!