ugexe m: say ("a" eqv "a") === True; # cxreg | i think that's a regression, i have an old build that returns True 01:23
camelia rakudo-moar ac36d2: OUTPUT«False␤»
ugexe i saw a known regression for ===, but not sure its known for eqv 01:24
04:10 sortiz joined
sortiz Seems that github.com/rakudo/rakudo/commit/46...ba643717R6 should be "nqp::p6bool(nqp::eqaddr(a,b) || (nqp::eqaddr(a.WHAT,b.WHAT) && (a cmp b) == 0))" 07:55
lizmat m: say Int =:= Int 07:59
camelia rakudo-moar ac36d2: OUTPUT«True␤»
lizmat sortiz: it could be... but what is wrong with what's there now ? 08:02
sortiz lizmat, see ugexe report a few hours before. 08:04
irclog.perlgeek.de/p6dev/2016-05-07#i_12446159
lizmat ah, it's missing a boolify 08:05
sortiz Yep
lizmat testing a fix 08:06
:q 08:07
oops
sortiz And I don't have yet your list that operators that now don't need the nqp variant ;-) 08:10
s/that/of/ 08:11
lizmat I am still failing to understand why it returned 1 instead of True 08:17
m: say ("a" cmp "b") == 0
camelia rakudo-moar ac36d2: OUTPUT«False␤»
lizmat m: say "a" =:= "a"
camelia rakudo-moar ac36d2: OUTPUT«True␤»
lizmat m: sub a(\a,\b) { a =:= b || (a.WHAT =:= b.WHAT && (a cmp b) == 0) }; say a("a","a") === True 08:19
camelia rakudo-moar ac36d2: OUTPUT«True␤»
[Tux] This is Rakudo version 2016.04-99-g475063a built on MoarVM version 2016.04 08:20
test 24.333
test-t 14.947
csv-parser 36.061
:(
lizmat [Tux]: looking at that degradation 08:23
[Tux] lizmat++
lizmat since the only difference is really all of the optimizing commits I did, perhaps they're not optimizing when combined :-( 08:24
m: my $a = "a"; say $a =:= $a # yeah, True 08:29
camelia rakudo-moar ac36d2: OUTPUT«True␤»
lizmat m: my $a = "a"; say $a =:= $a || 0 # WAT?
camelia rakudo-moar ac36d2: OUTPUT«1␤»
sortiz Oops! 08:31
lizmat *that's* the underlying bug
08:32 RabidGravy joined
lizmat m: say "a" =:= "a" || 0 # must be runtime 08:32
camelia rakudo-moar ac36d2: OUTPUT«True␤»
sortiz That seems of another level to me. 08:33
lizmat looks like an optimizer bug:
$ perl6 --optimize=0 -e 'my $a = "a"; say $a =:= $a || 0'
True
$ perl6 --optimize=2 -e 'my $a = "a"; say $a =:= $a || 0' 08:34
1
level 2 and up
lizmat submitted RT #128092 08:39
rt.perl.org/Ticket/Display.html?id=128092
dalek kudo/nom: 411e76f | lizmat++ | src/core/Stringy.pm:
Temporary fix for RT #128092

  ugexe++ for spotting, sortiz++ for following up		 08:44
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128092
psch hm, travis as-is isn't that useful for croaking about install-core-dist.pl :/ 08:45
as in, since it runs "make test" last it doesn't show the build as failed when install-core-dist.pl failed 08:46
lizmat [Tux]: I cannot reproduce your findings: 08:52
I went back to 631a36cbe32c98fba0 (2 May)
on that version, test-t runs for me in 13.153 seconds
whereas at nom, it runs in 12.044 seconds 08:53
m: say 12.044 / 13.153
camelia rakudo-moar 411e76: OUTPUT«0.915685␤»
lizmat so almost 9% faster
maybe I should start posting my numbers everyday as well :-) 08:55
masak yes :)
m: say ((1 - 12.044 / 13.153) * 100).fmt("%5.2f%% faster") 08:56
camelia rakudo-moar 411e76: OUTPUT« 8.43% faster␤»
sortiz psch, btw, as the provides are installed and precompiled in order, don't need "NativeCall" be after the others? That can be the explanation nadim++ reported problem. 08:57
psch sortiz: i have no idea. what did nadim report? 08:58
masak in other news, on a nicks-that-weird-me-out scale, "hotel" wins some kind of prize. I don't know why :P
sortiz psch, see irclog.perlgeek.de/perl6/2016-05-07#i_12446630 08:59
lizmat
.oO( you can never leave )
 09:00
psch sortiz: i don't know if that could be related to provides order. maybe if NativeCall was before NativeCall::Types, but since the former 'use'es the latter that should sort itself out, afaiu 09:01
sortiz I.e NativeCall uses NativeCall::Types, so if installed first can use an older NC::Types (preinstalled) version.
psch hm, yeah, maybe 09:02
sortiz The install can't know the dependency order.
psch i don't really understand this part of the code base particularly well :)
lizmat [Tux]: do you do a configure every morning as well? or just a "make install" ?
masak .oO( you can never `leave` ) 09:03
sortiz psch Me neither, just guessing :-)
psch sortiz: yeah. the overlap is that the issue on r-j i'm trying to understand dies when trying to load NativeCall::Types
but reordering the provides in install-core-dist.pl didn't help there... :) 09:04
...is it just me or does "handle data passed into a sub via a hash in order" seem somewhat impossible? 09:09
sortiz Seems so, and I think that in this case order matters. 09:14
psch i don't know. it didn't seem to matter before... :) 09:16
and as far as i know no one touched CUR stuff since the moveable-precomp merge 09:17
which means the question is, did nadim see that error due to the merge or is something else going on?
sortiz There are lots of reports in where nuking the install or .perl6 solved the problem. 09:19
And travis-ci, as is always clean, don't show. 09:21
lizmat jnthn: looking at Junction, what is the reason for making $!storage a high level list (other than being able to .map on it?) 09:41
09:41 cognominal joined
lizmat jnthn: also, what is the function of the STATEMENT_LIST symbol ? 09:42
dalek kudo/nom: cf199c9 | lizmat++ | src/core/Junction.pm:
Eliminate some dead code
 09:56
[Tux] lizmat, rakudobrew build moar 10:24
but I can force a rebuild of everything by nuking the source code 10:25
lizmat [Tux]: rm -rf install; rm -rf ~/.perl # what I just did 10:27
RabidGravy anyone want to close rt.perl.org/Ticket/Display.html?id=128091 as spam? 10:29
psch can't close 10:30
but i did report it
i like how "How are we different from others" is one of their suggested questions, along with "REMOVE" 10:31
bartolin marked 128091 as SPAM 10:39
psch ...that button is actually confusing :/ 10:40
well, RT now says the ticket is deleted
[Tux] This is Rakudo version 2016.04-120-gcf199c9 built on MoarVM version 2016.04-26-g1088538 10:44
test 22.437
test-t 14.258
csv-parser 36.310
that is starting from scratch
lizmat [Tux] hhmmm... is this with blead from all ? 10:49
afk& 10:52
sortiz psch, about the install-core-dist.pl problem, it occurs to me in the script first try to uninstall that "CORE" distro and then proceed. 11:08
psch sortiz: it does? it looks to me like it just tries to force install over it 11:09
sortiz Yes, but the forced install can't be in parallel, so, if as I suspect the problem is the order, that can be solved. 11:12
psch well, i strongly hope that whatever exactly the issue is it can be solved... :) 11:14
anyway, i'm not looking at anything broken in moar with install-core-dist.pl right now, r-j dies in there for a bit longer already 11:15
sortiz Ah, ok. 11:16
psch sortiz: i don't think having to order provides in a specific way (which, as it's a hash anyway, is kinda hard) is the right solution
sortiz: we'd probably need some kind of dependency detection if that's really the problem
sortiz psch, a few days ago I was asking if the provides keys can include a ':ver<x.y.z>', part that can help to solve this kind of problems, but get warnocked :( 11:21
psch i don't see how that can solve the current "we can't reinstall the same rakudo version into the same prefix" problem 11:22
and for any solution i can imagine (without a lot of actual code knowledge here, though) doesn't really need to know if the version is the same or great or anything 11:23
s/for//
sortiz Well, part of the problem is that those libraries, part of rakudo, aren't in settings, so should be installed like any other module, and exposed to the same problems about versioning and dependencies. 11:25
psch i don't think that's part of the problem that we can't force-install a distribution if it already is installed 11:26
i mean, it's a general concern with supplying standard libraries, yes
but it's not directly related to "we erronously reuse an already installed dependency of an already installed module that we want to force-reinstall" 11:27
sortiz I need to understand that part of the code. Right now I'm just speculating. 11:32
psch well, i'm mostly arguing from how i understand you see the problem :) 11:33
consider (1) we have a distribution installed (2) this distribution has two modules of which one depends on the other (3) we want to reinstall the same distribution (4) we get an error because installation of the depending module tries to use the installed dependency instead of force-installing the dependency first 11:34
i don't see any way to solve that with version checking alone
but yeah, i'm all for more people understanding the rakudo source, ++sortiz :) 11:35
bartolin btw, here is a gist with the issues I've seen with rakudo-j after the merge of 'relocateable-precomp': gist.github.com/usev6/607c0f00e4e6...592e29bcda 12:03
maybe I should rakudobug that. any thoughts? 12:04
psch bartolin: i'm poking at the prefix thingy, but in general i'd say yes to RT tickets 12:05
even for what i'm poking at right now, 'cause i might not figure it out ;)
bartolin psch++ # poking :-) 12:07
[Tux] lizmat, yes 12:58
command is rakudobrew build moar-blead 12:59
(previous paste was wrong. sorry if that caused confusion)
bartolin psch: reported as #128094 13:09
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128094
stmuk whats the status of the jvm build? is it getting better? 13:14
psch ...not really. well, at least not on my end 13:15
it was working, but then the relocatable-precomp branch was merged :S
$ ./perl6-j tools/build/install-core-dist.pl /home/psch/rakudo/rakudo/install/share/perl6 13:55
installed!
that looks pretty good from here... :)
bartolin \o/
psch gonna check if building r-m into the same prefix works, and then gonna build with both backends, again into the same prefix 13:59
hm, "Missing or wrong version of dependency 'src/Perl6/Pod.nqp'" still 14:11
why is the precomp'd version of that in $prefix/share/nqp/..? 14:13
well, $prefix/share/nqp/lib/Perl6 to be precise
i mean, i'd have thought that share/nqp/ contains nqp libs 14:15
well, it's the same across the backends... vOv 14:16
14:23 TimToady joined
psch hrm 14:49
actually i think my solution there is bad
what i'm doing is skipping the target repo in the repo chain when precompiling 14:50
but that obviously breaks when we're precompiling something that correctly has its dependencies already precompiled
yeah, i guess that'd mean dependecy analysis... 14:52
ugexe it might be nice to have some basic precomp api stuff (or a blog post on how to use what exists now) for invalidating/deleting precomps 15:21
like, say, .invalidate-rev-deps($dep-spec)
that might give enough to work with for the time being to allow the fully engineered solution to manifest 15:22
s/allow/allow time for/ 15:23
psch doesn't really understand CUR stuffs well enough to say if that's a good idea 15:26
jnthn lizmat: (On Junction's $!storage) just implementation convenience (so you can map on it, for example :)) 16:12
lizmat: STATEMENT_LIST looks to be just another way to write nqp::stmts or so 16:13
lizmat: Equivalent to do { ... } but without the lexical scope I guess
timotimo that's right; i've used STATEMENT_LIST in JSON::Fast to make a loop curly-free 16:20
.o( curly-fries? )
TimToady another way to look at STATEMENT_LIST is that its semantics are like a C comma operator 17:00
it used to be SEQ, but we decided to de-overload sequences a bit 17:01
timotimo oh, in C you can get much better performance by using the comma operator? i have to put that into all MoarVM's code !!
TimToady C doesn't turn {} into closures, so you shouldn't really need that... 17:02
timotimo :) 17:03
TimToady what's really hilarious in C is the do { ... } while 0 workaround so that macros interpolate as single expressions
timotimo yeah, that's funny 17:04
should be possible to make a macro for that
TimToady
.oO("Why should we fix the language when there's an arduous workaround we can inflict on generations of users?")
lizmat jnthn: since the type of junction is basically set at Junction creation time, and .Bool and .ACCEPTS all check what type they are 18:48
jnthn: would it be an idea to create a subclass for each type of Junction with dedicated .Bool and .ACCEPTS in them ?
so Junction.new(@a,:type<any>) would create an JunctionAny is Junction { method Bool {}, method ACCEPTS {} } ? 18:49
psch i have an urge to suggest "shouldn't that be role?" right here 18:50
+a 18:51
i think that's mostly memetic though 18:53
'cause there's a lot "i find OO works easier with roles" in our echochamber
i do like the idea of having specific kinds of Junctions instead of one kind that has to handle multiple... kinds 18:54
s:1st,:2nd/kind/type/
lizmat m: dd (Junction.new((1,2,3),:type<any>) but role JunctionAny { }).WHAT
camelia rakudo-moar cf199c: OUTPUT«Junction+{JunctionAny}␤»
lizmat dd class JunctionAny is Junction { }; (JunctionAny.new((1,2,3),:type<any>)).WHAT 18:55
m: dd class JunctionAny is Junction { }; (JunctionAny.new((1,2,3),:type<any>)).WHAT
camelia rakudo-moar cf199c: OUTPUT«JunctionAny␤»
lizmat the reason for this is optimization, so whatever is fastest :-)
psch that probably has to be measured, yeah 18:57
lizmat: i was more thinking < class AnyJunction does Junction { ... } >, fwiw 18:58
lizmat ah, that would work too :-) 18:59
psch well, or JunctionAny of course vOv
the point being that there's, afaict, 4 spots where it matters what kind of Junction we have inside Junction.pm,
-,
lizmat yeah, which would allow you to create your own JunctionTwo easily :-)
psch exactly
lizmat there's more places: sub any/all/one/none and infix | & ^ 19:00
and methods Any.any/all/one/none
psch well, those have to create the correct junctions, yeah 19:01
-s
lizmat fwiw, I'm streamlining Junction atm
timotimo having multiple classes would also make junctions extendable 19:09
you already said that, i nee 19:10
see
lizmat making Junction a role, yes... 19:11
however, knowing that Junction is already set up in the BOOTSTRAP, is not going to make that easy, no ?
timotimo oh, er, hmm 19:12
lizmat so I guess mixing in a role or subclassing is more easily feasible, by the looks of it 19:17
psch i'd try something like "my stub Junction metaclass Perl6::Metamodel::ConcreteRoleHOW" or so in BOOTSTRAP.nqp 19:18
although that might be the wrong metaclass 19:19
timotimo hmm 19:20
psch we don't do anything like that yet though, which means nothing around to cargo cult
otoh, that might also mean "good idea to try to spot bugs"... :)
19:29 hankache joined
dalek kudo/nom: f9db924 | lizmat++ | src/core/Junction.pm:
Eliminate some more dead code
 19:34
lizmat m: use nqp; my $h := nqp::hash("a",42); my $iter := nqp::iterator($h); nqp::iterval(nqp::shift($iter)) := 666; dd $h # too bad this doesn't work 20:09
camelia rakudo-moar f9db92: OUTPUT«===SORRY!=== Error while compiling /tmp/M4w3laWjz7␤Cannot use bind operator with this left-hand side␤at /tmp/M4w3laWjz7:1␤------> ; nqp::iterval(nqp::shift($iter)) := 666⏏; dd $h # too bad this doesn't work␤»
psch m: use nqp; my $h := nqp::hash("a",42); my $iter := nqp::iterator($h); $h{nqp::iterkey_s(nqp::shift($iter))} := 666; dd $h 20:16
camelia rakudo-moar f9db92: OUTPUT«{:a(666)}␤»
psch i don't think we have any nqp op that returns an l-value, do we?
lizmat psch: not sure 20:17
m: use nqp; my $h := nqp::hash("a",42); my $iter := nqp::iterator($h); my $a := nqp::iterval(nqp::shift($iter)); $a := 666; dd $h # no error, but not the right thing either 20:19
camelia rakudo-moar f9db92: OUTPUT«{:a(42)}␤»
timotimo we obviously need an "akteyerf" object :P 20:25
lizmat no, not obviously
it would just simplify one case in the autothreader 20:26
timotimo ah, when we autothread over a hash?
lizmat yup
no, when we autothread with named parameters
timotimo oh 20:28
oh!
yeah, now i get it :) 20:29
we could split the list of nameds into "part that get changed" and "part that stays the same" and "just" flatten them together in the invocation. i wonder if that's fast at all 20:30
lizmat well, it's already pretty naughty, :-) 20:31
timotimo oh, i remember that part! :D 20:40
jnthn lizmat: I think having a type explosion around Junction would be ugly. I the end we should be able to compile simple given/when over integers into jump tables, at which point it'll be pretty cheap as it is today with the flag. 20:44
lizmat what about the idea of a Junction Role ?
jnthn What would that win us?
lizmat the possibility to create things like two() that would be true if two in the junction were true ? 20:45
see earlier discussion
jnthn It's possible today, just subclass. :)
lizmat ok, fair enough :-) 20:46
jnthn But since you have to check all the things anyway, you don't come out ahead of a .grep(...).elems, I'd guess?
lizmat yeah, in that case, yes 20:47
jnthn Well, you can short-circuit on the third I guess :)
timotimo oh, of course you can do it with a subclass
timotimo facepalms
i should have seen that
lizmat timotimo: that was my original idea :-)
jnthn But I can't say I've seen a lot of demand for such a feature :)
lizmat true, I was just looking at optimizing :-) 20:48
fwiw, I'm trying to measure the changes I did to method AUTOTHREAD 20:49
but I can't seem to get it called :-(
jnthn: do you have a simple example of autothreading I could use for benchmark ?
jnthn m: sub foo($a) { say Backtrace.new.full }; foo(1 | 2) 20:50
camelia rakudo-moar f9db92: OUTPUT« in block at gen/moar/m-CORE.setting line 20861␤ in method new at gen/moar/m-CORE.setting line 20862␤ in sub foo at /tmp/1s_QBz9DS7 line 1␤ in block at gen/moar/m-CORE.setting line 7374␤ in method sink-all at gen/moar/m-CORE.setting line 419…»
jnthn m: sub foo($a) { say Backtrace.new.full ~~ /AUTOTHREAD/ }; foo(1 | 2)
camelia rakudo-moar f9db92: OUTPUT«｢AUTOTHREAD｣␤｢AUTOTHREAD｣␤»
jnthn Seems that hits it?
lizmat yup 20:51
I was also thinking of adding really async autothreading 20:57
jnthn: or do you have any specific ideas about that ?
was thinking of farming off if there are more than 100 states 21:00
jnthn lizmat: I think it's get .race and .hyper really solid first, and then just do it in terms of those :)
s/it's/I'd/ 21:01
lizmat ok 21:03
dalek kudo/nom: e093ccd | lizmat++ | src/core/Junction.pm:
Make autothreader 2x to 3x faster

  - my @a = flat 0 xx 999, 1; sub a($a) {$a}; for ^100 {++$i if a(@a.any)} # 2x
  - my @a = flat 1, 0 xx 999; sub a($a) {$a}; for ^100 {++$i if a(@a.any)} # 3x		 21:17
timotimo *nice* 21:18
jnthn lizmat++ 21:20
lizmat that's only part 1 :-)
timotimo jnthn: calling .list on a Channel from multiple threads is no problem, correct? we might want to note that as an explicit "good pattern" in the docs, then 21:21
jnthn Well, so long as you know that they're racing :) 21:22
I'd be reluctant to call it a good pattern
timotimo yeah, in this case i'm spreading work out to multiple workers
that's the "good" kind of race, right?
jnthn Yeah
In that whether it's good is highly situational 21:23
I mean, it's fine if the work isn't very fine-grained.
And if you don't need it to scale
(As in, you don't expect to be doing it in tons of places)
'cus it actually ties up the thread doing the iteration.
timotimo um, i'm not sure i understand 21:24
jnthn But those aside, yes, it's a good thing.
timotimo ties up the thread that does the iteration?
jnthn for $channel.list { } # between receiving items, the thread doing the looping is blocked and can't be used for anything else.
timotimo oh, right 21:26
well, that wasn't a notable thing for me, because i expected it to be like that 21:27
jnthn Right, as I said, it's situational, just something to be aware of :)
I'm always reluctant with things like "good patterns" and "best practices".
'cus they get carried away without their context... :) 21:28
timotimo that's true
happens way too often in comp-sci, and probably everywhere else, too
dalek kudo/nom: 626b5a9 | lizmat++ | src/core/ (2 files):
Make Any.any|all|none|one 14x faster

  - create internal SET-SELF method which also tests for valid type
  - add another Junction.new candidate that only uses positionals
  - call new positional Junction.new from Any.any|all|none|one
  - no longer listify inside Any.any|all|none|one, as SET-SELF does that		 21:49
timotimo damn. that's a fine improvement 21:51
lizmat good night, #p6dev 21:58
jnthn 'night, lizmat :) 21:59
lizmat oh, BTW 22:00
I'm not sure hyper/race would be a good fit for authothreading
as they would need to short-circuit
will sleep on that more& 22:01
timotimo i somehow b0rked the naive version :\ 22:07
jnthn lizmat: last works in map/grep :) 22:09
timotimo i think it was about using when directly inside a while ($_ = ...) { } loop 22:10
but what do i know
Internal error: zeroed target thread ID in work pass 22:18
sorry, jnthn, i can't figure out how much faster it is :(
jnthn grmbl
Guess it ran into one of the outstanding things to fix in that branch 22:19
timotimo could be, yeah
jnthn I had it in single-threaded tests too :)
timotimo let's see if it can do the naive non-threaded version 22:20
hm, might be that it's a tiny bit faster 22:22
do we have something that makes reading ascii encoded files ridiculously fast by ignoring the whole NFG thing? 22:29
jnthn It can't totally ignore it since \r\n is a synthetic 22:33
timotimo oh
beh.
jnthn But it saves on the UTF-8 decoding of course :) 22:35
Last I checked though the most expensive part of reading lots of small lines was malloc/free of buffers :P 22:36
timotimo i'd expect i can get a nice factor improvement by using Buf instead of Str here
oh, btw 23:13
perf says 45% in fixed_size_alloc, 6% in fixed_size_free
jnthn timotimo: Yeah...that's part of what reframe already gets rid of, and will later rid us of more in there 23:16
timotimo yup
jnthn FSA also wants to get better :)

Powered by Cro and the Raku® Programming Language.

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

Thank you!