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.
patrickb .tell vrurg I got it working! 00:46
yoleaux patrickb: I'll pass your message to vrurg.
01:40 patrickb left
AlexDaniel .tell kawaii one extra blin run please (wanna see results with the latest change), and then we can start the release branch and release relatively soon 02:10
yoleaux AlexDaniel: I'll pass your message to kawaii.
04:05 vrurg left, vrurg joined
lizmat Files=1275, Tests=108166, 208 wallclock secs (26.78 usr 7.65 sys + 2900.23 cusr 288.58 csys = 3223.24 CPU) 04:12
japhb Of possible interest to folks here: github.com/japhb/Terminal-QuickCharts 04:43
The examples/* work, but it's pretty rough, so I'm not actually putting it in the ecosystem yet.
Still, if anyone plays with it and finds it useful (or has comments), I'd be interested. 04:44
05:51 coverable6 left, unicodable6 left, nativecallable6 left, bloatable6 left, statisfiable6 left, quotable6 left, notable6 left, evalable6 left, reportable6 left, committable6 left, releasable6 left, benchable6 left, greppable6 left, bisectable6 left, squashable6 left, undersightable6 left, shareable6 left 05:52 bisectable6 joined, releasable6 joined, unicodable6 joined, ChanServ sets mode: +v unicodable6, greppable6 joined, ChanServ sets mode: +v greppable6 05:53 statisfiable6 joined, quotable6 joined, undersightable6 joined, ChanServ sets mode: +v undersightable6 05:54 reportable6 joined, evalable6 joined, squashable6 joined 05:55 notable6 joined, coverable6 joined, ChanServ sets mode: +v coverable6 05:56 shareable6 joined, nativecallable6 joined, bloatable6 joined, ChanServ sets mode: +v bloatable6, benchable6 joined, ChanServ sets mode: +v benchable6, committable6 joined, ChanServ sets mode: +v committable6 06:20 ufobat__ joined 06:25 ufobat_ left 06:51 vrurg left, vrurg joined 06:56 hankache joined 06:57 hankache left 08:45 hankache joined 09:05 tyil left 09:08 tyilanmenyn joined 09:31 tyilanmenyn is now known as tyil 09:44 hankache left 11:16 tyil is now known as akagi
[Tux] Rakudo version 2019.03.1-666-ga26e95bab - MoarVM version 2019.05-95-g065b2b427
csv-ip5xs0.710 - 0.731
csv-ip5xs-205.362 - 5.453
csv-parser23.846 - 24.254
csv-test-xs-200.434 - 0.461
test6.938 - 6.987
test-t1.729 - 1.753
test-t --race0.914 - 0.932
test-t-2028.302 - 30.861
test-t-20 --race9.243 - 9.824
 11:21
11:30 akagi is now known as tyil 11:43 hankache joined
hankache hello #perl6-dev 11:43
This is the definition of MVM_string_split: MVMObject * MVM_string_split(MVMThreadContext *tc, MVMString *separator, MVMString *input); 11:45
does anyone know what MVM_string_split does exactly?
why does it return an MVMObject and not an MVMString? Do I need to loop to get all splits or is it doing it? 11:46
MasterDuke hankache: because it returns an array of all the parts. it's doing it 11:51
hankache MasterDuke great! then no need to loop 11:52
MasterDuke thanks 11:53
MasterDuke np
AlexDaniel MasterDuke: is it really an array or some sort of iterator? 11:54
MasterDuke `result = MVM_repr_alloc_init(tc, hll->slurpy_array_type);`
it's not a native C array if that's what you mean 11:55
AlexDaniel just wondering if that thing can split an infinite string 11:56
m: say (‘foobarbaz’ x 99999999).split(‘b’)[20] 11:57
well, that can't
camelia MoarVM panic: Memory allocation failed; could not allocate 115323896 bytes
lizmat m: ‘foobarbaz’ x 99999999 # that should be enough
camelia WARNINGS for <tmp>:
Useless use of "x" in expression "‘foobarbaz’ x 99999999" in sink context (line 1)
lizmat no? 11:58
AlexDaniel lizmat: no.
lizmat hmmm
AlexDaniel lizmat: it stores it as ‘foobarbaz’ repeated n times
lizmat aahhh... yes, and then the split flattens it
AlexDaniel lizmat: you can even access substrings of it
hankache so what should I store the return value of MVM_string_split in? just an MVMObject? or is there something more specialized?
AlexDaniel m: say (‘foobarbaz’ x 99999999).substr(0, 10)
camelia foobarbazf
AlexDaniel m: say (‘foobarbaz’ x 99999999).substr(*-10, *)
camelia zfoobarbaz
AlexDaniel lizmat: even if you index from the end 11:59
and I'm pretty sure you can also join that with other strings
lizmat feels like we need to implement split on static str at the VM level :-)
AlexDaniel m: say (‘start’ ~ (‘foobarbaz’ x 99999999) ~ ‘end’).substr(*-10, *)
camelia obarbazend
MasterDuke hankache: i think an MVMObject should be fine 12:00
hankache basically what I am trying to do is the following: I have an MVMString containing a token, and another one containing a string of tokens separated by a semicolon 12:01
AlexDaniel lizmat: or maybe somehow make sure .split()[$index] just goes straight to returning an element without going through all the hoops
lizmat .split() returns a Seq... so that'd be hard 12:02
hankache so step 1: split the string using MVM_string_split and store in an MVMObject
then what should I do next? what functions can I use on MVMObject? 12:03
MasterDuke hankache: what do you want to do with the results of the split? 12:04
AlexDaniel lizmat: but don't we see the .split()[$index] construct during the compilation?
hankache Sorry to bother you guys but I never wandered in MoarVM land before and I am trying the get my feet wet with fixing an issue
AlexDaniel lizmat: as long as we can make sure that it's the core [] operator it should be possible, no? 12:05
hankache Masterduke I want to see if MVMString is == to any of those splits
AlexDaniel lizmat: although… $index could be anything…
hankache MasterDuke I want to see if MVMString is == to any of those splits
lizmat not unless we make the Seq returned by a .split somehow special
which feels wrong to me
AlexDaniel lizmat: no, that's too late for that optimization 12:06
lizmat AlexDaniel: in any case, how real life is that situation ?
AlexDaniel lizmat: get a single element from a split? I think pretty common 12:07
greppable6: split.*\[
greppable6: split.*\(\[
greppable6: split.*\)\[
greppable6 AlexDaniel, 25 lines, 8 modules: gist.github.com/5cbc0bd622c348074c...6056544271
AlexDaniel, 479 lines, 90 modules: gist.github.com/c3c6d3d30e3bb4d141...4e53b76d38
AlexDaniel, 155 lines, 48 modules: gist.github.com/ca3e4b3b6b22688a13...3b7c97214d
AlexDaniel lizmat: so 0, 1 or *-1 are the most common 12:08
MasterDuke hankache: then might be more efficient to just take out the part of MVM_string_split that does the actual splitting of the string and compare your MVMString with each part as it's produced 12:09
lizmat which could be easily replaced with .head, .skip.head and .tail
AlexDaniel lizmat: that wouldn't help, right?
lizmat: because the vm still has to split
MasterDuke instead of doing the entire split and then (maybe) throwing away the results
lizmat well... if it is not a constant string, it would have to do that anyway 12:10
AlexDaniel lizmat: constant string? Like any string on a vm level? :)
MasterDuke but i think i'd need a higher level explanation of what you're trying to accomplish to be more help
AlexDaniel I'm talking about hacking the static optimizer to make a direct call to the vm to get just one element
if that makes sense? 12:11
lizmat feels like an optimization for a case that doesn't happen too often IRL, if ever
hankache MasterDuke: github.com/MoarVM/MoarVM/pull/1122 12:12
AlexDaniel lizmat: so that's not often enough? gist.github.com/Whateverable/ca3e4...3b7c97214d
lizmat please note that on any Seq, you can do .skip(N).head to get to [N], *without* caching the values in between
hankache MasterDuke: nine's recommendation was this: "since the file name is originally an MVMString and you have an MVMString *fileext you may as well turn the PATHEXT into an MVMString and use MVM_string_split and MVM_string_equal_at_ignore_case" 12:13
lizmat AlexDaniel: I don't see any big values for N in there ?
AlexDaniel lizmat: the N we care about in this case is string length
that's the point, if we want just the 0th element, why split the whole string 12:14
lizmat I don't think we split the whole string if we only want the first occurrence
the problem is that a big string currently is being flattened 12:15
AlexDaniel mm
MasterDuke hankache: ah. likely not big strings or big loops, so absolute efficiency isn't top priority. i'm not sure how to iterate over the result of MVM_string_split, timotimo would probably be a good person to ask
AlexDaniel lizmat: maybe you're right 12:16
lizmat AlexDaniel: well, looking at the current implementation of split, that could definitely be improved :-)
specifically the candidate taking a Regex 12:17
AlexDaniel Geth: hello?
lizmat Geth has been gone for at least ~ 20 hours or so already :-(
AlexDaniel tyil: something seems to be wrong?
MasterDuke lizmat: fwiw, MVM_string_split doesn't flatten strings. if they are being flattened it's "earlier" in moarvm
AlexDaniel tyil: that's down: geth.svc.tyil.net/
tyil AlexDaniel: ah
I'll take a look in a bit, I'm not entirely done migrating to the new cluster yet 12:18
MasterDuke lizmat: hm, i'm only partly correct. MVM_string_substring, called by MVM_string_split sometimes flattens strings 12:20
12:21 patrickb joined 12:22 discord6 left
lizmat AlexDaniel: looking further into internals of split, indeed, nqp::split() will split the entire string 12:22
MasterDuke oh, of the resultant string
lizmat AlexDaniel: perhaps we need a nqp::split_iterator that gives an iterator 12:23
like you can with nqp::iterator on an nqp::hash
12:23 discord6 joined, discord6 left, discord6 joined
AlexDaniel m: say (‘foobarbaz’ x 99999999).index(‘zfoo’, 10) 12:24
camelia 17
AlexDaniel m: say (‘foobarbaz’ x 99999999).index(‘zfoo’, 10000)
camelia 10007
12:24 Geth joined
AlexDaniel m: say (‘foobarbaz’ x 99999999).index(‘zfoo’, 100000000) 12:24
camelia 100000007
AlexDaniel hmm, how can I get nth occurrence?
12:25 synopsebot joined
lizmat you will need to keep record of where you found the last one and count :-) 12:25
but that's definitely another way to implement .split on large strings 12:26
and be lazy
something to look into after the release, I'd say :-)
tyil AlexDaniel: once dns propagates to new cluster, new geth should be working again 12:27
new cluster has about 5gb extra memory, so perl 6 stuff should have less OOM problems
AlexDaniel lizmat: I'm not sure about that. I think .contains works across strands, right? So .match and .index theoretically can too, but I'm not sure if repetitions are used at all in real life, so…
lizmat .contains is just short for nqp::index 12:28
AlexDaniel m: say ((‘foo’ x 99999999) ~ ‘end’).contains(‘foofooend’, 100000000)
camelia True
AlexDaniel m: say ((‘foo’ x 99999999) ~ ‘end’).contains(‘foofooend’)
camelia True
AlexDaniel m: say ((‘foo’ x 99999999) ~ ‘end’).contains(‘ofoofooend’) 12:29
camelia True
AlexDaniel why is it so slow though
lizmat I'd say, flattening the string
AlexDaniel I don't think there was enough time to iterate through all repetition?
lizmat: it'll run out of mem if it attempts to flatten that
lizmat then it's the iteration :-) 12:30
AlexDaniel m: say ((‘foo’ x 999999999) ~ ‘end’).contains(‘ofoofooend’)
yeah, seems like. Alright then
camelia (timeout)
lizmat profile says 99.89% of time is spent in .contains
and that's just doing: nqp::hllbool(nqp::isne_i( 12:31
nqp::index($!value,nqp::getattr($needle,Str,'$!value'),0),-1
))
so it's spending all the time inside the nqp::index
Geth rakudo: a26e95bab4 | (Elizabeth Mattijsen)++ | src/Perl6/Actions.nqp
A more complete solution to #3000

  - pre-check EXPRessions, filter out the undefined ones
  - refactor circumfix() and circumfix[] code into single sub
  - remove dead code		 12:32
synopsebot RAKUDO#3000 [open]: github.com/rakudo/rakudo/issues/3000 [regression][tests needed] “parser did not give circumfix an EXPR” after “Re-implement colon list processing” commit
AlexDaniel just testing the delivery
hmm 12:34
do I understand correctly that modules are not precompiled during installation? (when using zef) 12:40
lizmat that could very well be true 12:43
AlexDaniel and precompilation is not multithreaded?
lizmat precomp is not multithreaded, afaik
AlexDaniel balls
lizmat and I have a test-suite at $work that will fail when run with -J16 if a precomp is needed 12:44
AlexDaniel I think I'm waiting for a few minutes for a whateverable bot to start up…
tyil AlexDaniel: can u make github send a test message? 12:45
AlexDaniel I'll be able to tell how much that was when it finisheh…
tyil to see if geth is ok again
AlexDaniel tyil: already did ↑
tyil oh
sorry, completely missed it
AlexDaniel tyil: thank you
lizmat that was one I did last night :-)
jnthn lizmat: If we want really lazy split, we should just skip the op and implement it using index and substr :)
yoleaux 03:23Z <Xliff> jnthn: Is this a known issue for IO::Socket::Async -> Type check failed for return value; expected OpenSSL::Bio::BIO_METHOD but got Whatever (*)
03:23Z <Xliff> jnthn: Is there a workaround?
tyil now we hope it stays stable :D
I'll be around irc all day, so just highlight me if anything is needed 12:46
lizmat jnthn: yeah, that's what I was thinking :-)
AlexDaniel tyil: cool, thanks
jnthn .tell Xliff Did you mean IO::Socket::Async::SSL? I've not seen that error before; please open an issue.
yoleaux jnthn: I'll pass your message to Xliff.
AlexDaniel … this is not normal, I'm still waiting :S 12:47
jnthn lizmat: could make an iterator that, on push-all, just uses nqp::split :)
AlexDaniel I wonder if it's me being an idiot and having an infiloop somewhere or if it's an actual new problem
jnthn And otherwise does the other thing. Then we maybe get best of both worlds.
lizmat jnthn: almost, but push-all can technically be called after already a single pull-one has been done
jnthn Well, yeah, you'd need a `$!start-index == 0` check guarding it I guess 12:48
lizmat yup
after the release :-) and some benchmarking :-)
AlexDaniel lizmat++
jnthn I think I know how to make the regex split quite a bit faster too...will tinker with that in a free moment :) 12:50
fwiw, I was under the impression that zef *does* precomp modules on install, but if one upgrades their Rakudo they'll have to be re-compiled on first use 12:51
lizmat or with an -Ilib and stuff, that would cause a recomp also, no ?
jnthn Yes, though iirc there's some smarts to avoid some of it some of the time, maybe? :) 12:52
I have sometimes wondered about trying to do some kind of multi-threaded precomp (really multi-process precomp) also. But...the thought of then being on the hook to debug all the fallout puts me off :P
It'd have to be speculative, to some degree
But if we see a series of `use` statements one after the other, we can at least rough-parse those and ask for the modules ahead to be loaded/precomp'd in parallel 12:53
If there's a language switch in one of the modules that swaps out the grammar totally and `use` means something different, well, we did throwaway work. But I think there's approximately zero cases of this in the wild :) 12:54
lizmat perhaps we need the concept of a pre-compilation server ?
jnthn No.
.oO( Let's take a hard problem AND add networking! )
lizmat well... perhaps... but it would centralize the logic of the dependencies in one process 12:55
jnthn I think it's easy enough to trigger it in parallel without that.
It wouldn't, because pre-comp involves creating multiple procs, which may themselves discover further needs and spawn more procs... 12:56
lizmat which would all talk to the same server ?
AlexDaniel ok it's not a precomp issue, phew :) 12:57
lizmat Actually, having a server *produce* bytecode, could have it's definite uses as well :-) 12:58
*its 12:59
lizmat is going to watch some semi-organized car crashes
jnthn That sounds...strangely entertaining 13:00
patrickb I'm in progress of turning the installed nqp executable into a binary similar to perl6 (i.e. directly linking libmoar). Is there any potential backwards compatibility breakage that might cause? 13:02
After the pain my changes to perl6 caused (I guess I should have communicated a bit better), I want to make sure I'm not repeating the same now... 13:03
jnthn, lizmat, timotimo: ^ 13:04
jnthn patrickb: I suspect the vast majority of the invocations of NQP are for the purpose of compiling Rakudo. :)
patrickb OK, so less potential of breaking tools I didn't think off. 13:05
hankache hor do you create an MVMString from a char* 13:07
?
MasterDuke hankache: MVM_string_ascii_decode_nt 13:08
hankache MasterDuke thanks
MasterDuke np. there's also *_utf8_decode 13:09
hankache thanks 13:13
MasterDuke anyone have a thought about what section in the Changelog to put a note about profiles having (some of) the overhead of the profiling itself removed from the results? 13:23
or just not include it at all? 13:24
kawaii AlexDaniel: sorry for the delay, started a Blin run now 13:33
yoleaux 02:10Z <AlexDaniel> kawaii: one extra blin run please (wanna see results with the latest change), and then we can start the release branch and release relatively soon
kawaii yes yoleaux, I... I know... :(
AlexDaniel it's good, I wanted a fresh one anyway 13:38
patrickb Release! Whooot! 13:47
kawaii We can hope so 13:48
Should be a good one too, lots of good changes
AlexDaniel: I have a rough draft of a new release process that lessens the load (RE: changelog) on us, and doesn't add _too much_ overhead to those making commits, aim to post it sometime in the next few days. 13:49
14:03 hankache left 14:34 patrickb left 14:56 discord6 left, tyil left 14:57 Geth left, synopsebot left 14:58 discord6 joined, discord6 left, discord6 joined, synopsebot joined, Geth joined 14:59 discord6 left 15:00 synopsebot left, Geth left 15:01 discord6 joined, discord6 left, discord6 joined, synopsebot joined 15:02 Geth joined 15:03 tyilanmenyn joined, tyilanmenyn is now known as tyil
lizmat jnthn: the F1 in Austria was indeed strangely entertaining :-) 15:33
kawaii ⏳ 945 out of 1307 modules processed 15:39
15:47 vrurg left, vrurg joined 17:17 vrurg left, vrurg joined
AlexDaniel` Yaay 17:31
17:45 pamplemousse joined 18:00 patrickb joined 18:11 pamplemousse left, pamplemousse joined
timotimo Kaiepi: can we talk about the necessity of adding more rebootstraps? i'm sure we can avoid most of that, and i'd be glad if we could 18:24
Kaiepi sure 18:26
18:26 pamplemousse left, pamplemousse joined
timotimo rebootstraps make the git repo so much bigger :( 18:26
and a rebootstrap should only be necessary if a newly introduced feature is actually needed to compile nqp itself 18:27
you were working on wide char stuff, right?
Kaiepi i'm doing it atm because i made changes to the P6int and P6num reprs to store information about what native type they contain so the P6str and CStr reprs can use it later on
yeah
timotimo what changes are needed in nqp for that purpose?
Kaiepi lemme check 18:28
timotimo if there's just some parameters being passed to the nqp::compose op, surely the moarvm side could assume default values for anything that's not passed
18:28 pamplemousse left
Kaiepi it does 18:29
it's why i don't implement `is ctype` in nqp 18:30
originally there were more changes, but it looks like the only change left is changing the C_TYPE_* nqp constants to be P6INT_C_TYPE_* and P6NUM_C_TYPE_*, which isn't really necessary anymore since i changed how i was going to implement the changes to CStr and P6str 18:31
timotimo sounds a little like the last reason to rebootstrap is already gone 18:32
that sounds good
Kaiepi the way i'm thinking of making CStr and P6str support wide strings is passing a typeobj through their compose protocol, originally i was going to pass P6STR_C_TYPE_* constants through type instead but this is more robust 18:33
timotimo oof, giving P6str support for "wide strings" seems like a bad idea 18:34
18:35 [Coke] left
Kaiepi why? 18:35
timotimo because p6str is NFG strings
that's not something any library out there expects
so suddenly p6str would either be a perl 6 string, or a list of unicode code points 18:36
we do at some point want to have p6str with support for non-nfg, but that'll probably look a bit different from what i imagine you're thinking of
Kaiepi oh 18:37
timotimo it'll for sure be more work than just a few hundred lines of patch, too
more like a few thousand lines
Kaiepi the only thing i'm really stuck on is how i'm going to implement support for char16_t strings on moarvm 18:41
they're just utf16 strings, but it looks like i can only use the utf16 string handling functions on char * and MVMString *, and MVMString * doesn't store anything related to utf16 18:42
timotimo yeah, it's not about strings, it's about functions 18:43
MVMString is always serialized and deserialized into and out of C land anyway
there is no concept of "this string was an utf16 string" 18:44
if you want that, you'll be working with CString or CArray or Buf
Kaiepi the problem is i need to be able to represent utf16 strings as an array of MVMchar16 18:45
which is uint_least16_t 18:46
timotimo MVMString is definitely not the right place for that, strings inside of moarvm have signed pieces rather than unsigned
18:47 vrurg left 18:48 vrurg joined
Kaiepi i wasn't planning on that, i was thinking of making changes to src/string/utf16.c to allow encoding to/decoding from MVMchar16 * (or another type specifically made for utf16 strings) 18:48
timotimo oh, that 18:49
yeah it's currently a bit odd that decoders and encoders explicitly and only want 8bit bufs
casting is a lot cheaper in some other languages like C
Kaiepi maybe it'd be safer just to leave it nyi for now since making it possible to implement could involve design changes elsewhere 18:52
dealing with wide strings' encodings is easy, i only need to use mbstowcs/wcstombs 18:53
18:59 patrickb left
Kaiepi btw the changes i made to P6int and P6num don't use any more memory than they did before on 64 bit systems, and on 32 bit systems, only P6num requires more 18:59
(unless i'm getting how struct alignment works on 32 bit systems wrong) 19:00
timotimo i would have expected all changes to live inside the reprdata 19:07
Kaiepi they do 19:14
wait, i thought the reprdata had MVMStorageSpec *, not MVMStorageSpec 19:16
disregard that then
19:56 lucasb joined
Kaiepi waaaait i forgot about something 21:04
timotimo, i think i still need to rebootstrap because i made a breaking change to serialization 21:05
P6int and P6num need to be able to serialize their native type info, but i can't do that in a backwards compatible way without risking getting the type wrong when deserializing 21:06
timotimo um, but the version of the serialization format is in the serialized file 21:13
so you can just decide based on the version of the file how to read it 21:14
Kaiepi i know 21:30
but if you serialize, say, a P6int with type size_t, there isn't a good way to be able to deserialize it with the right type from older versions
timotimo huh? 22:00
sorry, i was afk for a bit, but why would you need to do that?
Kaiepi i meant if it was already serialized from an older version, but i'm not sure if that happens outside of bootstrapping or not 22:39
i was thinking that it could mess with nativecall if it assumes size_t is a ulonglong or something instead but that doesn't really matter, it would get passed to dyncall/libffi the same 22:40
timotimo not really; rebuilding a newer moarvm would usually mean you're also rebuilding nqp and rakudo, and then you'll only have newest-version serialized files
Kaiepi so i guess it's not a breaking change after all 22:41
timotimo rebootstrap is really only necessary when the last built stage0 is no longer able to parse the current nqp source code for some reason 22:43
also, recently i introduced #?stage1 into gen-cat
because i didn't want to introduce a rebootstrap just so that nqp::installconfprog could be used for rakudo 22:44
Kaiepi what happens in the stages of bootstrapping?
timotimo well, we generally split bootstrapping into five stages 22:45
the first one of them is denial
just kidding
rebootstrap is literally just asking the currently built nqp to compile nqp to .moarvm files and putting them into src/vm/stage0/ 22:46
and a regular build is bootstrapped by using the stage0 to compile nqp's source into stage1, which then compiles the current nqp source to stage2
so first we have an nqp that's built by a way older nqp, which is stage0
we use that way older nqp to build current nqp, that's stage1 22:47
then we use the current nqp built by an older nqp to get stage2, which is then an nqp with current nqp source code built by an nqp with current nqp source code built by an older nqp
Kaiepi ah, ok 22:48
that explains how nqp parses itself
timotimo if we wanted, we could also have a version of nqp that's cut down a little and have that as the stage0
not sure if that's worth anything, though
an nqnqp
22:57 evalable6 left 22:58 evalable6 joined
AlexDaniel I found a bug \o/ 23:00
m: sub ztask( (:$key, :$value) ) {}; ztask ‘foo’.any => ‘bar’; 23:04
camelia (timeout) 23:05
AlexDaniel so passing a pair where a junction is in the key to a sub where destructuring happens results in an infiloop
let's see how new that is
c: 2018.01 sub ztask( (:$key, :$value) ) {}; ztask ‘foo’.any => ‘bar’;
ok very not new
committable6 AlexDaniel, ¦2018.01: ««timed out after 10 seconds» «exit signal = SIGHUP (1)»»
AlexDaniel c: 2016.05 sub ztask( (:$key, :$value) ) {}; ztask ‘foo’.any => ‘bar’; 23:06
committable6 AlexDaniel, ¦2016.05: «cannot stringify this␤ in sub ztask at /tmp/qg8ITvaycY line 1␤ in block <unit> at /tmp/qg8ITvaycY line 1␤␤ «exit code = 1»»
AlexDaniel c: 2016.08 sub ztask( (:$key, :$value) ) {}; ztask ‘foo’.any => ‘bar’;
committable6 AlexDaniel, ¦2016.08: «cannot stringify this␤ in sub ztask at /tmp/980ex6_Bmd line 1␤ in block <unit> at /tmp/980ex6_Bmd line 1␤␤ «exit code = 1»»
AlexDaniel c: 2017.01 sub ztask( (:$key, :$value) ) {}; ztask ‘foo’.any => ‘bar’;
committable6 AlexDaniel, ¦2017.01: ««timed out after 10 seconds» «exit signal = SIGHUP (1)»»
AlexDaniel c: 2015.12 sub ztask( (:$key, :$value) ) {}; ztask ‘foo’.any => ‘bar’;
committable6 AlexDaniel, ¦2015.12: «cannot stringify this␤ in sub ztask at /tmp/ZsD5PXreda line 1␤ in block <unit> at /tmp/ZsD5PXreda line 1␤␤ «exit code = 1»»
AlexDaniel bisect: sub ztask( (:$key, :$value) ) {}; ztask ‘foo’.any => ‘bar’; 23:07
bisectable6 AlexDaniel, Bisecting by exit signal (old=2015.12 new=a26e95b). Old exit signal: 0 (None)
AlexDaniel I probably know when it changed
but yeah, not that it ever worked
bisectable6 AlexDaniel, bisect log: gist.github.com/5b7374bae3e2bba422...4a1054c716 23:08
AlexDaniel, (2016-09-21) github.com/rakudo/rakudo/commit/3e...f2d7de41d5
AlexDaniel c: 3ed51de39^,3ed51de39 sub ztask( (:$key, :$value) ) {}; ztask ‘foo’.any => ‘bar’; 23:09
committable6 AlexDaniel, ¦3ed51de39^: «cannot stringify this␤ in sub ztask at /tmp/TNpwF1HLY2 line 1␤ in block <unit> at /tmp/TNpwF1HLY2 line 1␤␤ «exit code = 1»» ¦3ed51de: ««timed out after 10 seconds» «exit signal = SIGHUP (1)»»
AlexDaniel weird
23:55 lucasb left

Powered by Cro and the Raku® Programming Language.

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

Thank you!