Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_logs/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by AlexDaniel on 12 June 2018.
00:27 mst left 00:34 mst joined, mst left, mst joined 00:39 Ven` joined 00:43 Ven` left 01:04 Kaypie left 01:05 lizmat left
Geth rakudo: Kaiepi++ created pull request #2082:
Remove <?before> token in token term:sym<multi_declarator>		 01:25
01:51 fake_space_whale joined
Geth nqp/grammar-update: a86d643b1a | 陈梓立++ | src/NQP/Grammar.nqp
Remove <?before> token in token term:sym<multi_declarator>
 02:35
nqp: tison1++ created pull request #484:
Remove <?before> token in token term:sym<multi_declarator>		 02:36
03:00 Kaypie joined 03:53 MasterDuke left 04:11 Ven` joined 04:15 Ven` left 05:44 fake_space_whale left 05:58 fake_space_whale joined 06:12 fake_space_whale left 06:25 robertle joined, nebuchadnezzar joined 07:44 lizmat joined
lizmat Files=1243, Tests=76209, 373 wallclock secs (16.13 usr 5.65 sys + 2633.27 cusr 253.78 csys = 2908.83 CPU) 07:48
07:58 ilogger2 joined 08:15 Ven` joined 08:17 pmurias joined 08:29 pmurias left
samcv ok i fixed the SEGV problems gonna need a nqp and rakudo bump 09:52
releasable6: status
releasable6 samcv, Next release in ≈4 days and ≈9 hours. 10 blockers. 0 out of 210 commits logged (⚠ 12 warnings)
samcv, Details: gist.github.com/c7c25e2c27e24ff296...f2cfa5749d
Geth nqp: b939b50b00 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/MOAR_REVISION
[MoarVM Bump] 85bf30b0b In SCRef gc_free searc […]

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...g85bf30b0b		 09:54
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...g85bf30b0b
samcv essentially the issue is that i recently changed the hash implementation so it's a singly linked list not doubly, so only stores pointers to the next hash handle not the previous
Geth rakudo: bfa8d37e3f | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/NQP_REVISION
[NQP Bump] b939b50b0 [MoarVM Bump] 85bf30b0b I […]

NQP bump brought: github.com/perl6/nqp/compare/2018....gb939b50b0
¦ rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....gb939b50b0
samcv which exposed an issue in SCRef.c in the gc_free() function. For whatever reason the hash handle ends up in the wrong hash bucket. previously when it was dobuly linked it didn't matter if the hash handle was in a specific bucket or not. (well it could probably cause crashes honestly) 09:55
but it wouldn't happen except in rare cases. (like if the thing to be deleted were the first item in a bucket i would wager). in any case. the issue is fixed now because i just iterate through the scref hash and delete it when i find it 09:56
AlexDaniel cool 09:57
samcv so i likely solved some less producable (or maybe producable?) crashes
so it's good enough for release, though i'll try and fix the origin of the problem. even though the solution is non-ideal, i figure that it probably fixes other crashes to be a good enough reason that we can release it with my fix in it 09:58
10:09 travis-ci joined
travis-ci NQP build failed. Aleks-Daniel Jakimenko-Aleksejev '[MoarVM Bump] 85bf30b0b In SCRef gc_free searc […] 10:09
travis-ci.org/perl6/nqp/builds/404818883 github.com/perl6/nqp/compare/33e22...39b50b00b2
10:09 travis-ci left 10:13 robertle joined
tbrowder_ ref poster: “in the future” of the two choices sounds better to me... 10:19
lizmat just fixed a local spectest error by removing a Foo.pm6 from the system 10:20
AlexDaniel samcv: travis-ci.org/perl6/nqp/jobs/404818886#L577
samcv yeah it should be fixed in moarvm master, just gonna wait for all travis to finish then you can bump again :p 10:21
lizmat which means I'm down to 3 spectest: the in-loop (POST) one, a watch-path flapper (MacOS only) and a utf8-c8 one (also MacOS only)
samcv AlexDaniel: ok you can bump moarvm again 10:30
10:48 cognominal joined 10:54 travis-ci joined
travis-ci Rakudo build failed. Aleks-Daniel Jakimenko-Aleksejev '[NQP Bump] b939b50b0 [MoarVM Bump] 85bf30b0b I […] 10:54
travis-ci.org/rakudo/rakudo/builds/404818996 github.com/rakudo/rakudo/compare/d...a8d37e3ffe
10:54 travis-ci left
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. 10:54
10:59 stmuk joined 11:01 Zoffix joined
Zoffix m: class { has $!bar is required(Any) } 11:01
camelia 5===SORRY!5=== Error while compiling <tmp>
'is required' must be Cool
at <tmp>:1
Zoffix That's a weird choice...
lizmat I have no idea where that comes from, tbh 11:02
Zoffix It's from the same trait where the block for privates was
m: class { has $!bar is required(42) } 11:03
camelia ===SORRY!===
Object of type Int in QAST::WVal, but not in SC
Zoffix uh
lizmat Zoffix: I meant, the reasoning for only allowing Cool
Zoffix s: Attribute.new, 'set_required' 11:04
SourceBaby Zoffix, Something's wrong: ␤ERR: ./perl6-m: 2: exec: /home/zoffix/services/sourceable/building-perl6/install/bin/moar: not found␤
lizmat Zoffix: traits.pm
Zoffix .ask jnthn do you know why `is required` appears to accept various numeric values? It restricts to Cool and has `$attr.set_required(nqp::istype($required,Bool) ?? +$required !! $required)`... Is there any meaning other than "yes" and "no"? Wanting to change it to Any type and boolify it 11:08
yoleaux Zoffix: I'll pass your message to jnthn.
lizmat Zoffix: afaik, "is required" is not something jnthn was really involved in, it was more timotimo and moritz I believe 11:10
timotimo you could have put an error message there, for example?
lizmat got burned putting in an error message there already :-) 11:11
11:11 Ven` left
Zoffix m: class { has $!bar is required('nope') } 11:11
camelia ===SORRY!===
Object of type Str in QAST::WVal, but not in SC
timotimo ouchies :)
Zoffix :)
.tell jnthn nm, looks like it's for error message, but it's broken ATM: colabti.org/irclogger/irclogger_log...-07-17#l88 11:12
yoleaux Zoffix: I'll pass your message to jnthn.
Zoffix R#2084
synopsebot R#2084 [open]: github.com/rakudo/rakudo/issues/2084 `is required` can take an error message but currently broken
Geth nqp: 74f247d7dd | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/MOAR_REVISION
[MoarVM Bump] 0daa14c87 Make sure declarations […]

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...g0daa14c87		 11:15
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...g0daa14c87
rakudo: 20b1756a78 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/NQP_REVISION
[NQP Bump] 74f247d7d [MoarVM Bump] 0daa14c87 M […]

NQP bump brought: github.com/perl6/nqp/compare/2018....g74f247d7d
rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....g74f247d7d
7c349b7e80 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/BOOTSTRAP.nqp
lizmat pulls, configures, builds, installs and spectests 11:16
|Tux| Rakudo version 2018.06-211-gbfa8d37e3 - MoarVM version 2018.06-230-g0daa14c87
csv-ip5xs1.014 - 1.170
csv-ip5xs-208.359 - 8.615
csv-parser24.366 - 24.646
csv-test-xs-200.433 - 0.461
test8.512 - 9.460
test-t2.203 - 2.233
test-t --race0.945 - 0.951
test-t-2039.304 - 39.359
test-t-20 --race13.504 - 14.050
 11:22
AlexDaniel Zoffix++ # changelogging own commits 11:26
11:30 travis-ci joined
travis-ci NQP build passed. Aleks-Daniel Jakimenko-Aleksejev '[MoarVM Bump] 0daa14c87 Make sure declarations […] 11:30
travis-ci.org/perl6/nqp/builds/404850682 github.com/perl6/nqp/compare/b939b...f247d7dd8e
11:30 travis-ci left
lizmat Zoffix: fwiw, the "error message" functionality of "is required" was never documented, and apparently also not tested 11:43
although I'm pretty sure it *has* worked at one time, otherwise I wouldn't have added it 11:44
timotimo i think maybe my claim that "you could have put an error message there" sounded much more assured than it was %) 11:47
lizmat Zoffix: got a fix for "is required" 11:51
Zoffix lizmat++ 11:59
lizmat testing a better fix now :-) 12:00
12:00 Ven` joined
lizmat AlexDaniel: the docs/release_guide currently states: Remind people of the upcoming release, invite people to 12:05
update the ChangeLog file, update the ROADMAP, etc.
perhaps it would be handy to put a link to the ChangeLog wiki there (so people can find that easily)
Zoffix And in the bot's notices: colabti.org/irclogger/irclogger_log...07-16#l382 12:06
AlexDaniel ok
AlexDaniel does it
lizmat AlexDaniel++
AlexDaniel filed R#2085 12:08
synopsebot R#2085 [open]: github.com/rakudo/rakudo/issues/2085 [easy to resolve][meta] Move ROADMAP items into tickets
12:15 travis-ci joined
travis-ci Rakudo build passed. Aleks-Daniel Jakimenko-Aleksejev '[NQP Bump] 74f247d7d [MoarVM Bump] 0daa14c87 M […] 12:15
travis-ci.org/rakudo/rakudo/builds/404850739 github.com/rakudo/rakudo/compare/b...b1756a7892
12:15 travis-ci left
Geth rakudo: b5892dd85d | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/release_guide.pod
Don't mention ROADMAP in the release guide

  See R#2085 github.com/rakudo/rakudo/issues/2085		 12:19
rakudo: b6cc7168ad | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/release_guide.pod
Link to ChangeLog-Draft page and explain it
synopsebot R#2085 [open]: github.com/rakudo/rakudo/issues/2085 [easy to resolve][meta] Move ROADMAP items into tickets
12:21 Zoffix left 12:27 releasable6 joined, ChanServ sets mode: +v releasable6
AlexDaniel lizmat: done, I think 12:27
lizmat AlexDaniel++ # yeah thanks, working on adding commits now
Geth ¦ rakudo: jnthn self-unassigned “MVMHash representation requires MVMString keys” rescalar regression github.com/rakudo/rakudo/issues/2056 12:32
¦ rakudo: jnthn self-unassigned `Cannot call method 'ACCEPTS' on a null object` in Slang::SQL github.com/rakudo/rakudo/issues/2080
jnthn Unassigned since the bugs are fixed, but they're testneeded still, but it doesn't have to be me who adds tests :) 12:33
Geth roast: d34d852ab6 | (Elizabeth Mattijsen)++ | S12-class/attributes-required.t
Added test for "is required($reason)"
 12:45
12:54 j3nnn1 joined 12:56 buggable joined, ChanServ sets mode: +v buggable 13:03 Ven` left 13:09 Ven` joined 13:14 travis-ci joined
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Make "is required("reason")" work (again)' 13:14
travis-ci.org/rakudo/rakudo/builds/404870732 github.com/rakudo/rakudo/compare/2...349b7e8098
13:14 travis-ci left 13:16 brrt joined 13:25 skids joined
Geth rakudo: 7a7e5e96fe | (Elizabeth Mattijsen)++ | src/Perl6/World.nqp
Hide generated BUILDALL from backtraces

It was showing up in "attribute is required" stack traces. Since there is nothing to see there, as it is all generated code, it is best not to show it to people at all (unless you use --ll-exception of course).		 13:34
13:46 tbrowder_ left 13:47 tbrowder_ joined 14:05 fake_space_whale joined 14:19 brrt left 14:48 pmurias joined
releasable6 Next release in ≈4 days and ≈3 hours. 10 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 15:00
15:06 pmurias left, pmurias joined 15:11 pmurias left 15:22 pmurias joined 15:34 pmurias left 15:35 pmurias joined 15:39 pmurias left 15:55 pmurias joined 15:56 brrt joined 16:03 brrt left 16:06 robertle left 16:48 perlpilot joined
AlexDaniel lizmat++ 16:48
17:11 PufferBot joined 18:20 pmurias left 18:47 Ven` left 19:22 pmurias joined 19:30 japhb__ joined, japhb__ left 19:39 brrt joined, pmurias left 19:51 pmurias joined 20:02 brrt left
Geth nqp/nqp-in-the-browser: b42996b29c | (Paweł Murias)++ | src/vm/js/nqp-runtime/runtime.js
[js] Add support for loading compiled NQP code in the browser
 20:13
nqp/nqp-in-the-browser: e298dd68cf | (Paweł Murias)++ | src/vm/js/nqp-runtime/browser.js
[js] Make nqp::stderr and nqp::stdout output to console.error and console.log
b2gills Is it intentional that the iterator for `Range.roll(*)` has a native `int` for `$!min`? (same for `Range.roll(42)`) 20:14
I ask because some code I'm writing works for `Range.roll() xx *, but not for `Range.roll(*)`
20:14 Ven`` joined 20:15 perlpilot left
timotimo that doesn't sound right. doesn't it switch to an Int version when it's outside of the range? 20:16
b2gills github.com/rakudo/rakudo/commit/6e...d4e8be2c40
timotimo by "that doesn't sound right" i mean "looks like you found a bug"
b2gills The previous code was `gather loop { take self.roll }` 20:17
It only checks that it `$!is-int`
timotimo yeah i think that should be fixed
lizmat b2gills: is there a ticket for it already ? 20:34
yoleaux 18:05Z <Zoffix> lizmat: do you remember what was the usecase for .toggle? I need something nice and awesome for a 6.d teaser poster
b2gills I have no idea 20:35
lizmat b2gills: sorry for the confusion: did you make a ticket already ?
b2gills Nope, was going to ask for your input first 20:36
lizmat I think this is from the time that "is-int" (not the lowercase) actually meant it's in native integer range 20:38
b2gills .pick(42) has the same issue
lizmat same reason 20:39
b2gills: please make a ticket, will assign it to me 20:41
b2gills I actually didn't test .pick(42). I was looking at the code, and it also uses a native int
20:56 skids left
b2gills github.com/rakudo/rakudo/issues/2090 20:59
lizmat b2gills: thanks!
Geth rakudo: 6ad096c8a6 | (Elizabeth Mattijsen)++ | src/core/Range.pm6
Decont min/max on Range creation

Since they're immutable, there's no reason not to. And in some places that saves an awkward (repeated) decont.		 21:00
b2gills I can see `.pick` having a `int` check, but since `(^(2**12*)).roll(*)` works, and works well, I think it may be as simple as s/int/Int/ for the .roll(*) and .roll(42) cases 21:04
^(2**128)
Geth rakudo: 806752fb54 | (Elizabeth Mattijsen)++ | src/core/Range.pm6
Abstract check for Range being inside native integer range
 21:25
21:38 MasterDuke joined
Geth rakudo: b30800c8ec | (Elizabeth Mattijsen)++ | src/core/Range.pm6
Fix Range.roll(*)/roll(N)/pick(N) wrt big ints

For no apparent reason, native ints were used internally for some value keeping. Fixes R#2090		 21:39
synopsebot R#2090 [open]: github.com/rakudo/rakudo/issues/2090 Range.roll(*) doesn't work with large minimums
lizmat b2gills: ^^^
lizmat calls it a day& 21:58
22:23 Zoffix joined
Zoffix Is there something good I can read to learn the regex stuff? Like the "NFA", "Epsilon", "Fate", "to edge", "state"... all these things. 22:23
jnthn Yes, read up on finite automaton 22:26
Which will get you everything except "fate"
Zoffix Thanks.
jnthn And fate = an edge in the state machine that indicates a proto regex or alternation we are picking as a result 22:27
Zoffix huggable: fate :is: fate = an edge in the state machine that indicates a proto regex or alternation we are picking as a result 22:28
huggable Zoffix, Added fate as fate = an edge in the state machine that indicates a proto regex or alternation we are picking as a result
jnthn Which will probably make more sense after reading up on automta
Zoffix Cool.
:)
TimToady is currently working on returning multilevel fates from the NFA as STD used to do, but it's quite the brain burner... 22:38
22:39 Ven`` left
MasterDuke Zoffix: have you read Friedl's book, Mastering Regular Expressions? it's one of two programming reference books i've read cover to cover (the other being Programming Perl (twice)) 22:41
yoleaux 12:39Z <AlexDaniel> MasterDuke: you now have a commit bit for MoarVM repo \o/
MasterDuke infinite cosmic power! 22:42
[Coke] itty bitty memory footprint 22:43
jnthn: I feel like I might be able to abuse it with CALLER somehow. :P
(ww)
Zoffix MasterDuke: nope 22:44
MasterDuke: so you know all those terms from that book?
MasterDuke [Coke]: ah, you too watched some disney ~25 years ago 22:45
Zoffix 544 pages.. ain't nobody got time for that
MasterDuke Zoffix: some of them. i definitely felt it helped me understand regexes at a deeper level than just what syntax does my current programming language use 22:47
a lot (i think, don't remember exactly) of those pages are in-depth descriptions of how they
Zoffix I bet it's not that complex once you get past all the lofty waffle like "self-propelled" "finite state" and "automata"
MasterDuke 're implemented in a couple different languages and the differences in syntax and capability 22:48
[Coke] MasterDuke: that wasn't 25 years ago it, it wa... oh my god.
MasterDuke which of course isn't really required reading if you're just interested in the theory part
[Coke]: that was my reaction also 22:49
[Coke] I remember going to see it in the theatre at college. :|
22:50 Zoffix left
jnthn TimToady: I've been pondering it a bit. I wondered about introducing some kind of object (as a REPR) that holds the current parse state, and various ops to interrogate it 22:50
TimToady: And it can keep hold of what it already figured out
And we're not trying to shuffle it through some relatively narrow interface 22:51
TimToady I've been thinking similar thoughts 22:52
one important thing is that we need to keep names rather than just fate numbers, I think
since we need the names anyway
jnthn Also that maybe we want to stop flattening subrule NFAs into the overall NFA and instead "invoke" them
TimToady and the names work even when other fate numbering systems are incorporated 22:53
jnthn Though we need to be a bit careful in various ways on that
TimToady or there needs to be "universe tree" of possibilities for each NFA, and then the numbers pick from that
jnthn Though it might massively decrease memory footprint too
TimToady at each level you can get ties as well
jnthn eeek, yes
I didn't really get past thinking through the data logistics :) 22:54
TimToady originally I was just going to assign everything a unique fate number, but that doesn't work so well at deserialize time
the universe tree can be reused, and the fate tree can be tail-reffed such that each step just follows a link to the next level 22:55
that's all assuming we still want to run the NFA at every step, though there are also schemes where we cache through a trie for commonly seen longest tokens and just remember the fate tree for specific matches 22:56
but my gut feel is we should make the NFAs faster first
jnthn Probably, yes 22:57
TimToady another approach on the ties business is to assume that the first match is likeliest and throw away the less likely info
(as we currently throw away all the info)
and just re-NFA at the lower level if something unlikely happens
though there are spots in the grammar that might rely rather heavily on rejecting the LTM
jnthn EXPR for sure 22:58
TimToady and if not in our grammar, maybe in someone else's
jnthn It wants to know there's no infixish
So it can stop expr parsing
TimToady so if we can efficiently generate and keep the whole tree, that would be more scalable, but that's a big if 22:59
jnthn Yeah, I fear that's subject to combinatorial explosions
TimToady at that point, however, if you can cache and reuse the common trees, it might be a win 23:00
or just figure out where it's a win, and only do it there, somehow
jnthn We do plenty of dynamic adaptation elsewhere :)
TimToady other things that need to happen eventually is figure out which NFAs make sense to turn into a DFA 23:01
but that's not so important for parsing
except maybe for the first char or so of each token could use something trie-ish
to cut the statespace way down
jnthn Yes; did you see my recent-ish patch that shaved 13% off the time we spend in NFAs by storing all the literal grapheme matches in codepoint order, then binary searching them? 23:02
The infix category is *huge* but almost entirely starts with a literal 23:03
So it made the first char match of that O(log(n)) in the number of infixes, not O(n)
TimToady I saw you talking about that, and thought maybe we could do even better with the ASCII subset indexing into a table
but certainly we have things outside of ASCII too
jnthn Yeah, true.
TimToady there are also adaptive caches that put the most recent things into more accessible places 23:04
that kinda depends on the distribution though
and maybe we'd already get that effect with normal cache lines 23:05
a lot of my caching wisdom is from the dark ages where all memory accesses were equally expensive :)
jnthn That's way untrue by now, alas. :) 23:06
TimToady but right now my goal is not repeating the identical lexer scan four or five times at each spot... 23:07
jnthn One other thing I realized that may help some grammars: some tokens are 100% declarative, and so we needn't call them in theory. In practice, though, they may have action methods. But the new spesh plugin stuff means we can look into that and cache that by actions type (which is presumably not very polymorphic) and then just let the NFA tell us the lot matches. :) 23:08
TimToady we can also skip over some amount of literal rematching knowing what the longlit match was 23:10
jnthn But mroe simply than that, it'd be good if we could for decalrative prefixes with not capturing etc. to get a point to "jump" directly to
TimToady what I just said :)
jnthn Well, except we could potentially do it for \w* too :) 23:11
Not just long lit
TimToady true, though generally you're into capture stuff by then
we don't have many keywords with optional endings... 23:12
23:12 test567 joined
TimToady well, unless you count \s+ 23:12
jnthn For our grammar yes, though maybe that's less true for user ones 23:14
TimToady but something would actually have to record the position en passant if that's not the end of the token
23:14 test567 left
jnthn Yeah. To the degree I pondered it (not a huge deal), I thought about an edge that just records taht 23:15
23:16 pmurias left
jnthn But then I wasn't sure how well we can correlate it to the eventual fate 23:17
Then figured that's probably the same problem as the sub-fates
TimToady each of those needs to correlate with its immediately outer fate
we get away with the longlit correlating to the final fate currently because we throw away the subfates 23:18
and usually the longlit is the same for subrules, though not necessarily 23:19
if all subrules are totally literal, we can recombine and continue litting 23:20
(as currently coded)
jnthn Ooh, yes. Tricky. 23:21
TimToady but in that case we probably don't need the longlit disambiguator for the subrules anyway
anyway, we should structure the tree such that whenever we follow a pointer to the next bit, that sub-tree looks identical to what the lexer would've returned if we ran it again 23:25
jnthn Indeed 23:27
We can probably even have a debugging mode that *does* run it again and checks
TimToady as for data structure, I was gonna hijack states[0] for most of that, but if we want to do something more official, I'm happy to let someone else write the new opcode :)
currently the only real constraint on states[0] (in the C code) is that we use .elems to presize the fates array; everything else is done in nqp, so it could be retargeted by nqp code that stays sufficiently in sync with the bootstrap 23:29
I sound pretty smart when I talk about the individual bits of it, but my aged brain complains about trying to keep everything in there at once :) 23:31
TimToady is an expert on various pieces of the elephant, taken one at a time... 23:33
timotimo don't overexpert yourself 23:34
TimToady when I actually try to construct the elephant in the room, everything goes kinda gray... 23:35
.oO(Life is a process for turning gray matter into gray hairs.)
 23:36
jnthn :)
I guess "first, make it work" :) 23:37
TimToady then figure out a way to turn the amoeba into an elephant... 23:38
okay, well, unless someone volunteers to figger out the fancy repr-based way, I'll continue to think about prototyping with arrays of arrays of arrays, and we can translate to real objects later 23:43
jnthn That works for me 23:44
TimToady is assuming that if he pokes extra arrays into states[0][0] they'll get serialized...
jnthn My brane is pretty occupied with optimizer stuff for the moment :)
Should do 23:45
TimToady then I will not only presume it, but also postsume it
even in the current setup, states[0][0] is unused, since fates start at 1
(for protos) 23:46
anyway, thanks for the thinks 23:47
jnthn Welcome :) 23:49
I'm kinda interested in this area also, since I need to get the Comma IDE parser faster also :) 23:50
Though that's really a bear of little brain at the moment :)
(It doesn't even do an NFA.) 23:51

Powered by Cro and the Raku® Programming Language.

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

Thank you!