Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
lizmat Files=1255, Tests=75811, 341 wallclock secs (15.79 usr 5.52 sys + 2391.35 cusr 251.70 csys = 2664.36 CPU) 06:16
pmurias lizmat: had a .sum optimization idea last night: for integer sizes < int64 we can calculate if the sum can potentially overflow (int32 arrays that have less then 2**32 elements can't) 09:20
lizmat yeah, that makes sense 09:21
[TuxCM] Rakudo version 2018.09-404-g8cc3d5d7d - MoarVM version 2018.09-124-g588873f7a
csv-ip5xs0.906 - 0.914
csv-ip5xs-207.091 - 7.423
csv-parser20.613 - 21.080
csv-test-xs-200.421 - 0.443
test7.718 - 8.158
test-t1.647 - 1.680
test-t --race0.787 - 0.791
test-t-2028.381 - 28.546
test-t-20 --race10.412 - 10.665
 09:28
2018-10-03 10:02:43 test-t 1.682
2018-10-11 11:19:52 test-t 1.680
2018-10-01 10:44:01 test-t 1.674
2018-09-28 12:01:04 test-t 1.662
2018-10-11 11:16:39 test-t 1.647
lizmat I bet that was the /assign/p6assign/ I did yesterday 09:31
cool
lizmat almost 1% faster 09:31
lizmat .ask jnthn is there a way during compilation that we're compiling inside an EVAL ? 09:33
yoleaux lizmat: I'll pass your message to jnthn.
lizmat .ask jnthn *to find out 09:33
yoleaux lizmat: I'll pass your message to jnthn.
timotimo lizmat: check the callstack inside of a BEGIN block? 10:01
lizmat found an easier way: add a $*INSIDE-EVAL inside EVAL and check that :-) 10:04
timotimo sounds like someone could trick you if they wanted :) 10:05
lizmat well, they probably have a reason then 10:06
.tell jnthn fixed by adding an my $*INSIDE-EVAL inside sub EVAL and checking that 10:07
yoleaux lizmat: I'll pass your message to jnthn.
nine lizmat: $*W.is_nested 10:53
lizmat ah, even better :-) 10:54
nine++
nine err...that will only tell you if it's a BEGIN time EVAL 10:55
Because there the compilation is nested in another compilation
lizmat ah, ok, I'll keep my hack in then :-) 10:56
nine lizmat: I wonder what the use case is? 11:00
lizmat refactored MAIN handling
not executing MAIN when inside an EVAL : there is test for it
timotimo can always BEGIN $*INSIDE-EVAL = 0 11:11
masak in practice today, is a "constant" regex literal precompiled in Rakudo? 11:44
(guessing yes, because it seems like an early optimization to do)
masak by "constant" I mean "doesn't interpolate variables that can change over time" 11:45
[TuxCM] like what was the original intent of m//o in perl5 :)
masak yes, I think so 11:46
"the original intent"... did the intent drift? I haven't been following that
timotimo yeah, regexes turn into QAST nodes that are specifically for regex stuff and get compiled into MAST or whatever the backend has 11:50
lizmat masak: afaik, /o has been a noop for a long time already ? 11:57
masak lizmat: because it applies the optimization when it can instead of when there's a /o hint? 12:00
lizmat not sure... 12:01
it's been a while
masak timotimo: oh, so it's not so much optimized as code-gen'd fast by default?
lizmat maybe [TuxCM] knows
masak lizmat: I looked for /o in `perldoc perlre`, but it's not mentioned there AFAICS
lizmat yeah, it's been gone for a while 12:02
lizmat and silently ignored nowadays 12:02
masak it reminds me of a compiler hint that existed in FORTRAN, about the likelihood a branch (in an `if` etc) would be taken, so that the compiler could generate more optimal code 12:03
masak the compiler hint was mostly ignored 12:03
timotimo masak: the static optimizer also has some transformations on the QAST, and every piece of moarvm bytecode is subject to spesh, though spesh doesn't have anything specific to the regex-relevant bytecodes AFAIK 12:15
it's in nqp under src/QRegex/P6Regex/Optimizer.nqp 12:16
it's only 185 lines of code
lizmat timotimo: would that be the place to convert something like / foo / that builds a Match object out of a successfil nqp::index? 12:21
nine Btw. from what I've seen in QASTRegexCompilerMAST, I got the impression that it's more like a first working version rather than carefully optimized code
geekosaur iirc that's been specifically confirmed :) 12:24
masak so there is opportunity for easy wins still
dammit, I should get me some more copious spare time somehow 12:25
[TuxCM] sorry, busy, yes, AFAIK, /o is a no-op nowadays 12:54
[TuxCM] does a check
[TuxCM] perl -wE'$a="a";$b="abacd";$b=~m/$a/o and say "A";$a="x";$b=~m/$a/o and say "B"; 12:56
prints only "A", so /o prevents a re-evaluation of an embedded variable
which was the main purpose of /o to begin with 12:57
timotimo lizmat: i'm not sure, but perhaps it would be. 13:22
timotimo yo lizmat, wanna have a bit of silly fun with a prototype today? 13:39
lizmat sure... but after I've written my longest commit message ever :-) 13:40
timotimo oooh 13:41
Geth rakudo: 73b7c60392 | (Elizabeth Mattijsen)++ | src/core/ForeignCode.pm6
Add $*INSIDE-EVAL dynamic variable

So that code can figure out it is running inside an EVAL. Which can be useful when e.g. determining whether a MAIN should be run or not. Not sure whether this should be considered public or not.		 13:56
rakudo: fbfccfa2ff | (Elizabeth Mattijsen)++ | 2 files
Make handling of MAIN completely pluggable and documentable

But keep the old interface working as to not break any ecosystem modules that rely on the old interface.
An ecosystem module now has 3 intercept vectors it can use:
... (35 more lines)
lizmat timotimo: ^^
Geth roast: 657bd5c380 | (Elizabeth Mattijsen)++ | S06-other/main-eval.t
Unfudge now passing test
 13:58
timotimo yikes, that'll noticeably increase the time it takes to git clone rakudo :P
lizmat bonus from the MAIN refactor
RT #124662 13:59
synopsebot RT#124662 [new]: rt.perl.org/Ticket/Display.html?id=124662 Roast rakudo skip/todo test:./S06-other/main-eval.t line:21 reason: 'MAIN in EVAL'
timotimo very nice 14:00
lizmat I guess someone can close that one now, /me has given up on trying to login to RT
timotimo i was going to push my code but i've got to hold my nose shut so it don't spill red everywhere 14:03
lizmat ?? 14:04
ENOTENOUGHHANDS
timotimo anyway 14:05
i've got a shiny new nqp op for you to try to put into rakudo
it's not necessarily here to stay, but we're free to deprecate and/or replace nqp ops as we see fit anyway, i believe
lizmat yup 14:06
so?
timotimo it currently doesn't really jit
but that's easy enough to fix right now
pmurias m: my uint8 $u = 2**63; 14:07
camelia ( no output )
pmurias m: my int8 $i = 2**63; 14:08
camelia Cannot unbox 64 bit wide bigint into native integer
in block <unit> at <tmp> line 1
lizmat .ask jnthn twitter.com/JohnDCook/status/10503...2555891717 # opinions? 14:08
yoleaux lizmat: I'll pass your message to jnthn.
pmurias ^^ do we want this semantics 14:08
lizmat pmurias: yeah, there's a lot of inconsistency in that 14:09
I think the interpretation was that if it doesn't fit in an assignment, it should die
Geth nqp/vectorization: 20d0a73b78 | (Timo Paulssen)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
map vectorapply op
pmurias lizmat: we have tests in roast that check that it overflows :/ 14:13
and TODOed test that want to check that it fails
lizmat ack
Zoffix .tell pmurias to my best knowledge the argeed-upon semantic for natives is giving a value should throw, but mutating an existing value should overflow. So `my int8 $x = 2⁷` should throw, but `my int8 $x = 2⁷-1; $x++` should overflow. Note: I don't know where this puts operations like `+=`. There are also R#2318 and RT#127409 15:10
yoleaux Zoffix: I'll pass your message to pmurias.
synopsebot RT#127409 [new]: rt.perl.org/Ticket/Display.html?id=127409 [BUG] Inconsistencies and Bugs in Native Types Behaviours
R#2318 [open]: github.com/rakudo/rakudo/issues/2318 Size doesn't matter for native assignment when deciding to throw
jnthn fwiw, the logic behind the current behavior is that unboxing throws, for truncating doesn't, and unboxing is always to full width 15:19
yoleaux 14:08Z <lizmat> jnthn: twitter.com/JohnDCook/status/10503...2555891717 # opinions?
jnthn (Not saying we shouldn't revisit it, just noting the way things currently work) 15:20
Zoffix .tell pmurias more comments: colabti.org/irclogger/irclogger_log...10-11#l298 15:20
yoleaux Zoffix: I'll pass your message to pmurias.
pmurias jnthn: that how things work or how they where intended to be? 15:50
yoleaux 15:10Z <Zoffix> pmurias: to my best knowledge the argeed-upon semantic for natives is giving a value should throw, but mutating an existing value should overflow. So `my int8 $x = 2⁷` should throw, but `my int8 $x = 2⁷-1; $x++` should overflow. Note: I don't know where this puts operations like `+=`. There are also R#2318 and RT#127409
15:20Z <Zoffix> pmurias: more comments: colabti.org/irclogger/irclogger_log...10-11#l298
synopsebot RT#127409 [new]: rt.perl.org/Ticket/Display.html?id=127409 [BUG] Inconsistencies and Bugs in Native Types Behaviours
R#2318 [open]: github.com/rakudo/rakudo/issues/2318 Size doesn't matter for native assignment when deciding to throw
jnthn pmurias: How things work; it's the consequence of the two independent choices that unboxing to something that won't fit a 64-bit will always throw (sensible) and operations involving native types quietly overflow (the question being if we thing this should extend to the truncate operation as it presently does, or if truncation is considered different) 16:06
*think 16:07
pmurias there is also a question if my int32 $i = $Int should first unbox to 64bit and then truncate or unbox to 32bits 16:09
it's currently treated as two operations but does it have to? 16:10
jnthn At an API level, I think that's sane; a JIT might be able to find a way to merge the two 16:11
Otherwise we end up with a proliferation of unbox instructions
pmurias jnthn: I mean on the language level 16:17
pmurias jnthn: truncation between native types quitely overflowing seems like something that we want 16:23
jnthn: it's the take an Int and the put it in a 32bit variable case that seem weird to me 16:24
pmurias m: my uint8 $i = -2**30;say($i) 17:13
camelia 0
pmurias m: my uint8 $i = -2**30+4;say($i)
camelia 4
pmurias m: my uint8 $i = -2**40+4;say($i)
camelia Cannot unbox negative bigint into native unsigned integer
in block <unit> at <tmp> line 1
pmurias jnthn: ^^ other super weird semantics 17:14
Geth nqp: 21a7529b18 | (Paweł Murias)++ | src/vm/js/nqp-runtime/runtime.js
[js] Remove old debug leftover
 17:24
nqp: 788b1ccb49 | (Paweł Murias)++ | 9 files
[js] Very basic int64 and uint64 support
Geth rakudo: 3caccd5c41 | (Paweł Murias)++ | 6 files
[js] Very basic int64/uint64 support

Currently only ++/-- and converting them back and forth between Int works		 18:44
Geth rakudo: b3a57fce38 | (Paweł Murias)++ | tools/build/gen-js-makefile.nqp
[js] Add a js-install target
 18:49
Geth roast: ecfba11780 | (Elizabeth Mattijsen)++ | S06-other/main-refactored.t
Add tests for refactored MAIN handling
 20:55
rakudo: 341190e283 | (Elizabeth Mattijsen)++ | t/spectest.data
Run tests for refactored MAIN handling
 21:04
AlexDaniel so if I'm making a module, should I create a repo in github.com/perl6-community-modules or github.com/perl6/ ? Should I move whateverable and sake to perl6-community-modules ? 22:24
timotimo hm, is there precedent for modules like that under perl6/ ? 22:26
oh, 6pad lives there, too, and sake actually also has a repo there it seems like?
oh, that's what you mean by "move"
never mind :)
AlexDaniel well, I recommended to move sake to perl6/, without thinking enough about the existence of perl6-community-modules 22:27
and perl6/ is full of modules, but do we want that? 22:28
perl6/ has 313 people in it 22:31
perl6-community-modules has 18
AlexDaniel is that good? Is that bad? I don't know 22:32
timotimo well, perl6-community-modules has been used to fork modules whose original authors have become unresponsive and there were issues that needed solving 23:05
that doesn't mean it can't be used to hold original modules, though

Powered by Cro and the Raku® Programming Language.

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

Thank you!