pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, smop: etc.) || We do Haskell, too | > reverse . show $ foldl1 (*) [1..4] | irclog: irc.pugscode.org/
Set by TimToady on 25 January 2008.
04:20 ilogger2 joined 04:34 eternaleye joined 04:47 eternaleye left 04:58 eternaleye joined 05:02 Psyche^ joined
allbery_b wonders if that last message was a mistake 05:05
spinclad allbery_b: no, he did leave after 'good night all &' 05:06
:)
allbery_b mm, wrong venue :) 05:07
05:14 Psyche^ is now known as Patterner 05:48 Zaba_ joined
TimToady allbery_b: yes, it was. :) 05:53
allbery_b hm 05:54
06:16 Zaba_ is now known as Zaba
cathyal anyone using irssi 06:21
hi tim, allbery_b
Patterner is that a trick question, cathyal? 06:22
cathyal no
Patterner yes
cathyal ok so Irssi: Join to #irssi was synced in 253 secs 06:23
how does that work?
addition multiplication, not a single step procesS?
seems like a prime number
253..
fullermd It's not, it's 11*23 :)
cathyal wait go slow, what do you mean
fullermd shrugs. 06:24
It's not prime, it's a product of 2 primes. 06:25
cathyal is it not a single step process?
fullermd What, the syncing?
cathyal yeah
fullermd I dunno. It pulls a list of users at least. Not sure what else it does.
cathyal ok 06:26
Eevee wow 06:28
I've gotten 23 seconds before but not four minutes
cathyal thats my point
Eevee might have lost an unimportant response to something and irssi waited a while before giving up 06:29
cathyal shrugs 06:31
k
07:03 justatheory joined 07:04 justatheory left 07:07 araujo joined
pugs_svnbot r20338 | lwall++ | [STD5] throw out $depth and $binding params; should be done by caller, not callee 07:13
diff: dev.pugscode.org/changeset/20338
lambdabot Title: Changeset 20338 - Pugs - Trac
07:24 meppl joined 08:18 iblechbot joined 08:24 Schwern joined 08:40 luqui joined 09:01 FurnaceBoy joined 09:10 wknight8111 joined 09:20 icwiener joined 09:30 FurnaceBoy left 09:37 FurnaceBoy joined 09:39 barney joined 09:55 meppl left 09:56 meppl joined 10:05 FurnaceBoy left 10:06 smtms joined 10:24 nipotan joined 10:41 barney left 10:47 icwiener_ joined 10:59 icwiener left 11:04 yewenbin joined 11:32 meppl left 11:33 pbuetow joined 11:35 meppl joined 12:17 nipotan is now known as nipotaway 12:39 wknight8111 left 12:53 iblechbot left 13:25 sscaffidi joined 13:37 eternaleye left 13:46 riffraff joined 13:55 kcwu_ joined 14:02 TJCRI joined 14:11 Zaba_ joined, Lorn joined 14:14 iblechbot joined 14:23 Zaba left 14:24 Zaba_ is now known as Zaba, tzoa joined 14:32 chris2 joined 14:39 yewenbin left, syle joined 14:44 cognominal_ joined 14:55 FurnaceBoy joined 15:01 rhr joined
pugs_svnbot r20339 | lwall++ | [STD] fate should also be completely hidden from user view 15:07
diff: dev.pugscode.org/changeset/20339
lambdabot Title: Changeset 20339 - Pugs - Trac
15:08 yewenbin joined, mncharity joined 15:11 kyrbe joined, kyrbe left
TimToady now that I've cut out all the parameter bogosity and callee-binding, maybe I have some small hope of constructing a well-formed match tree... 15:19
at least what's left looks a heck of a lot cleaner now 15:20
kolibrie TimToady++ # tidying up
TimToady well, thanks, I just hate fighting my own past stupidities. but it's the only way forward... 15:21
15:32 kcwu_ is now known as kcwu 15:35 alester joined
[particle] so... does perl 6 have a 'reset' op? or is that a method on ::?COMPILER now? ;) 15:37
TimToady which reset are you referring to? 15:38
it was overloaded...
but I believe we've managed to get rid of all its meanings now
[particle] yes, i believe so too
was reset in perl 1? 15:39
TimToady I believe so
at least, the variant that clobbered lots of variables
Eevee wow I completely forgot reset even existed
TimToady not sure about resetting ?...?
[particle] i wonder about implementing that in punie.
Eevee hack from before lexicals existed? 15:40
TimToady indeed
[particle] shouldn't be hard, but i'm not sure pct supports it. there are ways around that, thought.
*though.
TimToady variable reset just needs to be able to navigate the symbol table 15:41
regex reset could be harder
mncharity "I just hate fighting my own past stupidities. but it's the only way forward...", oh yeah. :) 15:42
civilization and life as a bootstrap exercise
TimToady anyway, I think you'll find STD.pm rather prettier now
mncharity just to double check before I do a code =~ s/if\(/if (/g, 'if(3){4}', with no space after the if, is invalid p6, correct? 15:44
TimToady it's valid, it just doesn't mean what you think it means 15:45
mncharity :)
15:45 sscaffidi left
TimToady it calls the "if" subroutine, and then derefs as a hash subscript of 4 15:45
which, fortunately, is likely to blow up 15:46
especially if you've neglected to define an "if" sub
pugs_svnbot r20340 | jnthn++ | [spectest] A little fudging for Rakudo.
diff: dev.pugscode.org/changeset/20340
lambdabot Title: Changeset 20340 - Pugs - Trac
TimToady so it can catch it at compile time
(usually) 15:47
mncharity a new day, a new number sequence... (1) in statement_control:if, 'elsif' and 'else' should perhaps be followed by <nofat_space> to match if's behavior.
we'll need a new conversational idiom to distinguish "if()" from "if ()". :) "sc:if"? 15:48
TimToady the first one's pronounced "interface" :) 15:50
15:55 meppl left
TimToady re (1), yes, though interestingly repeat's while/until probably doesn't 15:56
15:56 meppl joined
pugs_svnbot r20341 | lwall++ | [STD] elsif and else need <nofat_space> since they could be a new statement 15:58
diff: dev.pugscode.org/changeset/20341
TimToady whoops, forgot your putter++ :)
biab & 16:03
mncharity lol
pugs_svnbot r20342 | putter++ | [elf_e] if's must be followed by a space.
diff: dev.pugscode.org/changeset/20342
lambdabot Title: Changeset 20342 - Pugs - Trac
16:13 luqui left
mncharity (2) q_balanced is still using the now non-existent $stop argument to EXPR. 16:22
What is the story behind subcall being commented out? 16:25
16:27 rindolf joined 16:29 yewenbin left 16:31 kanru joined 16:32 Chillance joined 16:36 rdice joined
pugs_svnbot r20343 | putter++ | [elf] else's must be followed by a space. 16:40
diff: dev.pugscode.org/changeset/20343
lambdabot Title: Changeset 20343 - Pugs - Trac
TimToady mncharity: the story is that it's currently handled by term:name because my LTM doesn't yet do backoff to tied or shorter tokens 16:41
rindolf Hi TimToady
TimToady same story as packagevar and fulltypename, basically
howdy
rindolf TimToady: I have more lines for my "I'm the Real TimToady song." 16:42
"And Randal Schwartz said... Nothing, you Idiot! Randal Schwartz's mad at you for not paying attention."
TimToady I don't recognize that tune...
rindolf TimToady: wait a sec.
TimToady: can you see YouTube?
TimToady not at the moment
Eevee TimToady: you're not really missing much
16:43 eternaleye joined
rindolf TimToady: well use www.youtube.com/watch?v=zCuwOG39HMo 16:43
lambdabot Title: YouTube - Oops The Real Sim Shady Did It Again
rindolf TimToady: you can also use youtube-dl.
TimToady: which is written in Python (Shavess!) but is still cool. 16:44
mncharity re subcall, ah, ok. then I'll continue using it for now. 16:45
rindolf TimToady: do you know Yiddish?
TimToady: I know a little of it.
mncharity (3) token dotty uses explict '.' rather than <sym>, so does endsym unspacey get used or not? 16:46
TimToady re (2), the quote languages should be using a derived terminator like the regex sublanguages 16:47
I'm still refactoring that
mncharity nod
TimToady rindolf: not enough to know whether I'm a schlemiel or a schlemazl
rindolf TimToady: heh. 16:48
TimToady++
TimToady endsym is only used on <sym>
obra pmichaud: ping 16:51
TimToady I'm disinclined to all unspace in the middle of .* et al. but after that token is probably okay 16:52
*allow
mncharity ok. just noting proto token dotty is ensym unspacey, but it no longer looks like there's a dotty <sym> to use it anywhere. 16:55
pugs_svnbot r20344 | lwall++ | [STD] dotty needs more unspaciness, putter++
diff: dev.pugscode.org/changeset/20344
lambdabot Title: Changeset 20344 - Pugs - Trac
mncharity ah :)
TimToady problem is that <sym> would match .* literally, rather than .+, .?, etc.
otherwise I have to split those all out as separate tokens 16:56
and that was one of the things that was making my lexers huger earlier
probably not as big a problem now that I split lexers on first char 16:57
16:58 sscaffidi joined
TimToady twigils also act as lexer multipliers if you're careful... 16:59
*not careful
[particle] depends on what you're being careful to accomplish 17:02
17:08 tzoa left
TimToady I/O, I/O, so off to work I go... & 17:09
rindolf A Bit or Bite so late at night. 17:10
I Bit a Bite so late at night.
mncharity oy :) 17:19
pmichaud 16:46 <obra> pmichaud: ping 17:21
pong
[particle] rats. now i gotta go. bbi~2h 17:22
obra pmichaud: hiya. 17:23
particle has been talking me through some of the bits of extracting and converting pugs tests.
I started poking at something at looked "easy" and got an interesting explosion: 17:24
then perl t/harness --fudge --keep-exit-code t/pugs/operators/arith.t
sub tryok ($ok, $todo = '') {
trips up rakudo's parser
pmichaud just a sec 17:25
I don't know if initializers are implemented yet
rindolf Hi pmichaud
Hi obra, [particle]
rindolf is editing www.perlfoundation.org/perl5/index.cgi?history
lambdabot Title: History / Perl 5 Wiki
pmichaud obra: it looks like rakudo doesn't understand the = '' part yet 17:26
17:26 justatheory joined
pmichaud not hard to implement, just hasn't been done yet. Could try it as $todo? though 17:26
obra poking 17:27
pmichaud oh, I misread rakudo's grammar -- looks like ? and ! aren't there yet either
oh wait, yes they are
obra there's other fudging I need to do 17:29
for undefine $a;
and ..some operator
but I'm doing the brute force thing right now 17:30
t/pugs/operators/arith......Scope not found for PAST::Var 'ok'
pugs_svnbot r20345 | clkao++ | use items for bind_pad.
diff: dev.pugscode.org/changeset/20345
lambdabot Title: Changeset 20345 - Pugs - Trac
17:30 tcliou joined
pmichaud we should be able to get the '=' initializer implemented relatively quickly 17:31
I'll file a ticket for it
obra cool. 17:33
mostly, I'm trying to understand the test extraction process
so that I can write it up for the list to maybe lure in some willing help
pmichaud feel free to ask questions here -- any of myself, particle, or TimToady can likely answer
pugs_svnbot r20346 | putter++ | [STD_red] cleanup continues. statement_control et.al. whitespace; term:BEGIN; <?stdstopper> calls added (disabled in expect_term due to massive regression); dotty changes (one deferred); EXPR argument list tweaked.
diff: dev.pugscode.org/changeset/20346
obra nods 17:34
pmichaud one potential workaround for now is sub foo($ok, $todo?) { $todo = $todo // ''; ... }
I *think* we've implemented infix:<//>
obra nods 17:35
pmichaud checks.
obra I don't know what that new failure I pasted means
pmichaud looks like a typo in the codegen somewhere 17:36
we shouldn't have a PAST::Var 'ok' -- it should be '$ok'
obra (Pasted to: paste.husk.org/11305
both failures and the currently hacked up t file
pmichaud oh 17:37
that's looking for &ok
(which gets automorphed into 'ok')
what is the &ok.nextwith(...) supposed to do? 17:38
obra looking
Any pugs test hackers able to shed light? 17:39
pmichaud my initial guess is that it's automatically counting tests
17:39 pmurias joined
pmichaud and that .nextwith is some sort of currying 17:39
(updating my pugs repo so I can check) 17:40
pmurias mncharity: do you use the elf_e executable?
mncharity TimToady: (4) why is stdstopper a regex rather than a token? also fulltypename. 17:41
obra (I sadly need to run away for a going-away lunch)
pmichaud no problem. I'll look into it a bit further and message you
I need to do lunch also
I'll be back around 1400 CDT
(80 mins from now) 17:42
mncharity pmurias: yes. and _nomoose.
pmichaud ah, .nextwith is in S06
mncharity pmurias: ... why? :) 17:43
pmichaud my opinion is that testing for arithmetics shouldn't depend on the availability of wrapping. 17:44
pmurias mncharity: i'm wondering if there is any point of keeping it 17:45
mncharity: why do you use elf_e instead of elf_e_nomoose? (testing?)
pmichaud: .nextwith is used to provide better error traces 17:47
pmichaud pmurias: how so? 17:49
regardless, I think it's a bit of a mistake to say that any given p6 implementation must have .wrap and .nextwith working before it can run the arithmetic tests. 17:50
mncharity nextwith is a tailcail, so caller remains the test line of interest
pmurias it's a bit pointless as &ok dosn't throw exceptions
mncharity don't think .wrap is needed. (could be wrong. and not expressing a preference on it's (non)existance) 17:51
17:51 jferrero joined
pmichaud oh. S06 describes .nextwith in its section on wrapping. 17:51
17:53 chris2 left
pmurias mncharity: will elf support named parameter? 17:54
pmichaud: do you want to change the test? 17:57
pmichaud definitely
(want it to change, yes.)
pmurias changing .nextwith to function application should work 17:58
pmichaud yes
also, particle and I were talking about adjusting the standard Test.pm functions a bit
but I don't have any specifics handy at the moment 17:59
mncharity pmurias: re why... given the very large amount of effort embedded in Moose, it's an attractive path. and elf_e_nomoose doesn't yet do variable default values. but I often use eenm for testing. and always(~) check that both bootstrap.
pmurias mncharity: i'm not really sure how much Moose features can we use 18:00
mncharity at some point in the not too distant future, someone has too look at the performance of autobox, and decide whether to continue building the EmitSimpleP5 object system on autobox or do something else. 18:01
pmurias and the moose on is too slow for me, so i don't update/use it all 18:02
mncharity: boxing everything would be the alternative to autobox 18:03
re named parameters they would change our calling convention 18:04
TimToady re (4), I tend to use "regex" to document the fact that I'm not actually trying to traverse a token
pmurias so we must choose if we do them properly, hack them on or omit them 18:05
mncharity re 'will elf support named parameter?', I'd rephrase that as will EmitSimpleP5 support named parameters. elf can be used to compile and run emitters which do anything. There's also the related question of whether the core elf code will depend on named parameters working. soo... ESP5 support, probably. but I don't want to take a runtime hit from
TimToady not sure why fulltypename has that, unless I had it backtracking in some form or other
mncharity it so it may be compiler analysis intensive. 18:06
I'm tempted to minimize the feature set of my elf core code
s/of/used by/, but... maybe not. So I'm unclear on whether using named parameters in the elf implementation itself is a good idea or not. 18:07
pmurias mncharity: i don't thing the runtime hit will be significant but the calling convention would be incompatible from the perl5 one 18:09
pugs_svnbot r20347 | lwall++ | [STD] fulltypename should probably be a rule 18:10
diff: dev.pugscode.org/changeset/20347
pmurias as one would have to pass the named parameters as one of the positionals 18:11
mncharity re calling convention properly/hack/omit, I am tempted to emit routines as two parts, one for when the compiler understands the arguments, and one which takes a Capture. providing fast case and general case. and with the elf core being mostly fast case. and named args... not clear. maybe included in fast case, perhaps restricted, or maybe not.
compatibility with p5 calling convention isn't really a priority. at least for me and EmitSimpleP5. but again, its easy to fork a EmitDifferentlySimpleP5. :) 18:14
pmurias if you don't care for compatibility i think it's worth having them in 18:15
mncharity actually, it would eventually be nice to be able to control calling convention on a per-sub basis.
though that requires cross-module analysis, which may fit the independently compiled modules story. 18:17
18:17 eternaleye left
mncharity *not fit 18:17
pmurias you have independently performed analysis then
mncharity re regex, ah, ok. 18:18
18:19 eternaleye joined
mncharity re independently, which requires either access to the non-compiled form, or requires the compiled form to contain all the information in the non-compiled form. not clear to me either is required by spec at present. 18:20
pmurias: but the real answer is anyone coming up with a more featureful calling convention and emitter, would be great. and, assuming we get any users, appreciated. and if fast and having an attractive development path, might displace the current one. 18:26
elf is intended to be more a family of compilers than a single monolithic thing like pugs. 18:27
if no one creates elf derivatives than something is wrong, because no single set of tradeoffs can possibly be appropriate for the wide range of things one might do with it (eg, run on different backends, or serve as a platform for developing (type analysis, compilation games, alternate calling conventions, etc, etc)). 18:29
and both the "it's all p6"(well, except the parser for now) and the architecture is designed to facilitate such use.
s/than/then/ 18:30
pmurias the current design of having a seperate executable for each variant would get in the way loads of derivatives 18:31
mncharity the demands of "elf as a way of doing parsing with grammars for p5 cpan modules" is very different than "elf as a reference p6 self-implementation" or my current focus "elf as a tool to shake down STD, and encourage people working on a p5 backend components, and start passing pugs t/ to provide test driven development opportunities". 18:33
18:34 FurnaceBoy left
pmurias what subset should elf be in? 18:36
the one shared by all|most backends, or the most complete one?
18:36 Zaba_ joined
mncharity elf_x EmitSomethingElse.pm foo.pm can run foo.pm with the new emitter (but which requires, of course, SomethingElse be compatible with the emitter which compiled elf_x - that's why you often want a separate executable). 18:37
elf_x EmitSomethingElse.pm -x -o foo.whatever foo.pm compiles foo.pm with the new emittter. 18:38
pmurias i'm aware of the monkey patching trick ;) 18:39
mncharity re what subset/dialect, good question. I'm tempted towards "be featureful where it simplifies architecture (ie, multimethods), but less so for only local bumming". but it's a pragmatic "what is most convenient for most people at the moment" question, with possible multiple forks. and we don't yet have even a second backend. 18:42
or no, I guess we do. that's _nomoose. currently maintained as a small fork. 18:43
18:44 rindolf left
mncharity feel free to start another one. :) I should probably move the RegexYare stuff out of elf as a fork until it matures. oh, there's also the smop emitter fork of elf_e (elf_d?). 18:45
someone is needed to take on the task of looking at Data::Bind and the rest of the cpan "this will help doing p6 like stuff in p5" and weave them together into runtime convention(s). 18:47
dev.pugscode.org/browser/perl5/Data-Bind 18:48
lambdabot Title: /perl5/Data-Bind - Pugs - Trac 18:49
pmurias mncharity: the problem with forks starts when they are incompatible with each other
mncharity: i used Data-Bind in the short-lived mp6v6
18:49 Zaba left 18:52 riffraff left
mncharity re forks incompatible, that, like, implies active development! more than one developer! that would be a wonderful problem to have. ;) 18:52
pmurias for example code emitted by RegexYare would either follow the named parameter convention, or the positional only one
mncharity and if bridging that difference is difficult, given collaborating developers working in a common environment and community, then it indicates something badly broken in p6 as a language, or a too-narrow implementation of same. 18:55
18:57 hermax_ joined, hermax_ left
mncharity elf, noun: (a) ~8 p6 files which happen to define a p6 backend capable of compiling files like themselves; (b) a p6 implementation based, in whole or in part, on those files or derivatives; (c) a movement; (d) one of santa's helpers. 19:04
but the key point is it's just a couple of files. encoding knowledge of what a p6 implementation looks like. no big infrastructure or entanglement. 19:07
you might even be able to run them in pugs. eventually at least (I haven't tried, and expect it would take some work). 19:09
anyone with an itch to scratch, a corner of the very very big p6 implementation picture you wish to pursue, is encouraged to grab and make use of the files and/or executables. 19:12
type analysis and such written in p6 seem likely to be just as useful for rakudo as elf-ish implementations, a new pugs, or whatever else. 19:14
issues of divergent IR's seem likely to be minor compared to shaking down spec and "getting the first one working". 19:15
bbiab 19:16
19:34 jferrero left
pmichaud obra: message about arith.t sent to perl6-compiler mailing list 19:37
obra pmichaud: thanks 19:39
pmichaud er, maybe not. checking 19:40
oops, sent to wrong address. Re-sending.
*now* it's sent.
(time to fix my mail aliases)
obra heh 19:41
my goal is more about getting down an easy recipe for taking old pugs tests and bringing them into the new world order easily
pmichaud this message somewhat addresses that, I think.
in the case of arith.t, I think we should get rid of the "helper subs" that are at the top of the file and just use what already exists in Test.pm 19:42
(where Test.pm might end up meaning "Rakudo's Test.pm")
19:44 rob__ joined 19:45 rob__ is now known as r0bby_ 19:46 r0bby_ left
mncharity obra: re the new world order, are there any docs? :) 19:55
pugs_svnbot r20348 | putter++ | t/operators/arith.t: .nextwith tailcalls commented out to help rakudo.
r20348 | putter++ | Probably degrades error messages, so restore once rakudo does .nextwith.
diff: dev.pugscode.org/changeset/20348
mncharity Oh, I should have mentioned I failed to test the modified file against pugs. :( I don't have a working one at the moment. :-( 19:56
pugs_svnbot r20349 | clkao++ | assign into pad for rw.
diff: dev.pugscode.org/changeset/20349
pmichaud per my message, I disagree with "restore .nextwith" 19:57
rakudo isn't the only other Perl 6 implementation
obra mncharity: mailing list conversation between pmichaud [particle] and TimToady with a bunch of existing work to create the spec/ hierarchy 19:59
what I'm trying to help get together is "and here's how to masssage the existing body of not-so-organized tests 20:00
[particle] obra++ 20:01
mncharity re nextwith, but setting up .nextwith as an alias to subcall is easy.
s/is/should be/ 20:02
obra does having .nextwith enhance the tests or are you suggesting it as a porting bandaid? 20:03
mncharity re massage, note that, at least the last time I looked, my impression was the t/spec and t/ test philosophies were rather different. t/ generally trying to avoid off-topic dependencies like .nextwith, and t/spec feeling free to use maximal p6. both have a role. t/spec beeing a good validation suite, but t/ being more useful as a new impl takes its first steps. 20:04
obra I am not qualifed to talk about this.
obra defers to [particle] and pmichaud
[particle] mncharity: i disagree with that perspective
t/spec/ should be well-factored 20:05
mncharity re suggesting, merely pointing out that for elf, I'd have hacked in .nextwith, rather than hacking the test.
[particle] it's not where it should be yet, because it needs a larger effort
tests should rely only on well-documented parts of perl 6 20:06
that is, whatever is required for Test.pm to work
of course, that may be different for each implementation
mncharity [particle]: validating p6 well will be quite hard. making it harder by using a restricted dialect seems a problematic choice. 20:07
[particle] how do i best say this...
ultimately, yes, we need to validate full perl 6. and it should be free to use macros, etc. 20:08
now, today, when there are multiple burgeoning implementations, we need to concentrate on developing tests that rely on a minimum of features
that set of features will grow as the implementations grow 20:09
there's really no one way to bootstrap
we have to be reasonable about it
so, when testing math, it's better not to rely on tailcalls
that's my feeling, at least. 20:10
mncharity "that set of features will grow as the implementations grow" that's a reprise of the approach taken with pugs. it was arguably a mistake then too. :) the difficulty is 20:11
Eevee not that I have any room to talk, but it seems to me that spec tests are only really useful if features are kept to a minimum except for what you're actually testing, so an implementation can get useful results no matter how far along it is, as long as it meets a known and very simple baseline 20:13
if you have a math test failing because you don't support tailcalls, what use is the math test
[particle] an important difference between the pugs approach an the t/spec/ approach is that the latter is organized by synopsis 20:15
20:15 Zaba joined
[particle] ...and the synopses are mainly numbered such that you can implement them in numeric order 20:15
so, for example, you don't need to have implemented s12-objects before s02-bits&pieces 20:17
mncharity ok, let's see... there is definitely a role for hand-holding. t/01-sanity has been *very* helpful in getting infant implementations moving. the next phase is making toy implementations less toyish. with t/ tending to avoid off-topic complexity, the main problem there has been 20:18
20:18 wknight8111 joined
mncharity the file based testing. parse fails somewhere in the file, or there's a runtime error, and you lose the file. 20:19
pugs dealt with that by being selective about what was actually put in .t files (no bulk dumping of failing tests), and individually tagging problematic tests. 20:20
redsix, and I believe PIL-Run dealt with it by trying to be incremental - trying to run as much of the file as possible.
don't remember what PIL2JS did.
[particle] we now have 't/spec/fudge' to do preprocessing 20:22
mncharity but the upshot of that experience was a feeling (at least by me;) that a less file-oriented approach was needed for the long talked about t/-next generation.
[particle] you no longer have to worry about parsefails, because '#?elf skipall "parsefail"' will take care of that for you
mncharity one where individual test setups and tests could succeed or fail on their own.
[particle] (i may have screwed up the syntax a bit there)
mncharity and the same infrastructure could serve for generative testing. 20:23
obra but writing your trivial test function to use .trynext seems to be counterproductive
mncharity so that's making implementations less toyish. (will backlog in a sec - one bit more). once an implementation is ceasing to be a toy, is passing much of the test suite, the set of what is useful changes. rather than being accessible to toy implementations, what's important is 20:24
shaking down a non-toy impl as hard and efficiently and well as possible. that's implicitly the same argument as "that set of features will grow as the implementations grow". grown implementations require a different set of tests than toy ones. 20:26
obra mncharity: do you object to having feature tests refactored to exercise fewer features which aren't what you're actually testing?
20:26 nipotaway is now known as nipotan
[particle] mncharity: you're getting ahead of yourself, and the rest of us. all perl 6 implementations are toys now. 20:26
some day near the release of Pelr 6.0 (official spec and test suite) 20:27
20:27 icwiener_ left
[particle] *Perl 20:27
mncharity but just like t/spec shouldn't be rewritten to look like t/01-sanity, it's not clear to me t/ itself should either. let alone a t/shake_the_last_incompatibilities_out_of_a_mature_impl (aka t/spec?).
backlogging...
[particle] we'll refactor the tests again to make them better
20:27 Schwern left, Zaba_ left
[particle] we're in a process of continuous refinement and refactoring 20:28
right now, t/spec/ better meets the needs of implementations
in the future, that's likely to change, and we'll change it.
obra (www.nntp.perl.org/group/perl.perl6....g1667.html has been linked here today, right?)
lambdabot Title: Proposal: refactor the test suite according to synopsis - nntp.perl.org, tinyurl.com/64882k
mncharity re "when testing math, it's better not to rely on tailcalls", yeah, I don't really disagree. but, for instance, I had the same feeling about adverbs (:todo). :) If .nextwith was harder to implement, it would be a clearer argument. but the suggested change to the test is identical to an implentation faking .nextwith as a regular subcall. I've no objection to 20:30
the change itself, but it seemed a useful discussion foil. a test suite without :todo<foo>'s could be nice too. :) 20:31
re "what use is the math test", a math test verifies, for some implementation, that the math is working. the key is 'for some implementation'. One could suggest "my implementation can't do operator precedence parsing - can math be rewritten using just subcalls?". Or "my implementation is robust and mature, can math be rewritten in non-toy p6 to give maximum testing bang?". the 20:34
issue is in part what development profile you expect. if it's a slow infancy, short childhood of rapidly developing capabilities, and long adulthood of trying to get things right, then, for instance, it's not clear whether you care that a toy implementation is handing Inf right or not. it should be focusing on other things until it is non-toy. 20:36
obra the point of the spec tests is to test specific features defined in the synopses. 20:38
pmichaud handling :todo<...>
is already being done with fudge
obra Broken down by synopsis.
pmichaud so we already eliminate those from the test suite
(or at least refactor them out into fudge-able todo markers instead of part of the call)
obra Trying to turn them into torture tests for whatever code some hacker wrote one evening is intentionally making them into something they're not supposed to be
Eevee why would you want to rewrite a math test in non-toy p6? everything you could possibly use should already be tested elsewhere 20:39
obra Eevee: right.
pmichaud "can math be rewritten using just subcalls" would mean that we're not really testing the math operators, which I presume to be the point of the test
mncharity re "organized by synopsis", tying tests to spec can certainly be useful. I'm unclear on how far that goes as an architectural principle. re "you can implement them in numeric order", eep, but it seems very unlikely to be that far.
[particle] mncharity: what's "official" about Perl 6? 20:40
Eevee isn't it *always* a good idea to make tests as specific as possible
[particle] 1) the Spec. 2) the test suite.
pmurias obra: what's wrong with torture tests?
pmichaud nothing's wrong with torture tests. But they should be identified as torture tests, and not part of the "simple mathematical operators" test. 20:41
obra ==pmichaud
[particle] t/spec/torture/some_crazy_tests.t
pmichaud also, fudge gives us a convenient way to segment out the torture tests so that a given implementation can still test the basic stuff and skip over the tortuous stuff
...as long as all of the tests aren't using the tortuous stuff :-) 20:42
20:42 lisppaste3 joined
mncharity oh, let's see, lots of threads... 20:42
pmichaud (er, as long as the basic stuff isn't using the tortuous constructs.)
phrasing it slightly different 20:43
I would posit that a Perl 6 implementation could be "non-toy" and still not have .nextwith implemented.
it's not complete, but I wouldn't say that ".nextwith" is something that is critical to any non-toy implementation of Perl 6 20:44
having operator precedence working is critical to any non-toy implementation
as is conditionals, loops, variables, etc.
Eevee yes, feature implementation order isn't guaranteed
and if you murk tests with other features then implementors get to figure out what order they have to implement features in before the tests are useful
mncharity re "why would you want to rewrite a math test in non-toy p6?" and "aving operator precedence working is critical to any non-toy", Eevee: so "ok(2 == 2);" requires non-toy. ;) 20:46
if we were serious about supporting toy no-opp impls, we would need to do "ok(eq(2,2));" or some such. 20:47
pmichaud yes, but that doesn't mean tests should also be using .nextwith or tailcalls or the like :-)
Eevee I think == is a liiittle bit more basic than tailcalls 20:48
pmichaud also, mncharity's logic doesn't quite follow
pmurias the .nextwith is a bad example as it serves no purpose in that particular test
pmichaud just because every non-toy implementation requires == doesn't mean you can't have == in a toy implementation :-)
mncharity at the risk of overly focusing on the discussion foil, re "posit that a Perl 6 implementation could be "non-toy" and still not have .nextwith implemented", the point is _not_ that tailcall is critical, but that subcall is, and that a non-toy can trivially fake nextwith as a subcall. 20:49
pmichaud mncharity: that's assuming that my subs are objects on which I can easily attach methods
20:49 justatheory left
pmichaud Parrot isn't quite there yet 20:49
20:49 justatheory joined
mncharity err, yeah. s/subcall/method call/g. 20:50
ah. hmm.
pmichaud so, "any non-toy can trivially fake..." isn't exactly true in Rakudo's case
obra so. every implementation could also implement a rot13 filter to keep the content of a test a surprise until runtime.
that doesn't make it useful
pmichaud but still, the point remains -- why does arithmetic testing need to rely on .nextwith? That doesn't belong in arithmethic testing -- those sorts of things should be factored out into the generic testing library 20:51
Eevee I don't want to have to implement $x higher-level "trivial" features just to run tests
obra implicitly requiring an unrelated feature to perform basic feature tests is pointless and frustrating.
mncharity: you'll note that nobody is arguing about initalizers on variables in signatures, which these tests also required. 20:52
mncharity ok, so that's the "what is a toy" thread. re 'has there ever been a non-toy', such things are relative of course, but pugs was at least sufficiently non-toy that people kept trying to use it as if were not one. PIL2JS had the next greatest test passing, but was slow. PIL-Run passed somewhat less. redsix was down around 1/4. I've no idea where rakudo is. 20:53
for the purposes of this discussion, I'd say pugs was non-toy. perhaps PIL2JS. 20:54
pmichaud I'm not too concerned with figuring out what is "toy" versus "non-toy", but I agree that Pugs is non-toy.
[particle] pugs and pil* all used the same parser, no?
pmichaud I don't know that toy versus non-toy is a useful label or distinction to try to definitively establish 20:55
mncharity re same parser, yes
re toy/non-toy, let's see, the core question is... 20:56
obra More blood has been shed over whether a given p6 implementation is/was/will be a toy than has been shed over many other more important religious debates. 20:58
mncharity what dialect do you write various subsets of tests in? it's clear very highly restricted dialects can be useful (ie, sanity). it's clear you can do a "non-fixed subset - dialect grows as some privileged impl grows". it's clear that doesn't as well serve other impls at differing stages of paths of development. what else... 20:59
*or paths
pmichaud I'd take the general guideline as being that tests should, as far as possible, use only those features in sanity and that are core to the thing being tested 21:01
mncharity ... there seems disagreement on whether the test suite for mature impls will use a rich dialect. "write validation suite richly, and consider impls toys until they have the rich dialect working", and "grow to rich with growning impl" both suggest yes, "why would you want it? be minimal" suggest no. 21:02
pmichaud "rich dialect" is a sliding scale, not a definitive item 21:03
if the purpose of the test suite is to make it possible to verify implementations and to assist implementers, then increasing the richness of the suite for its own sake makes it less useful
mncharity ok, so "why would you want it?", 21:04
pmichaud why would I want... what?
mncharity "why would you want to rewrite a math test in non-toy p6?" 21:05
pmichaud I wouldn't.
mncharity :)
pmichaud if "toy p6" is sufficient to test my math features, then I should use that for writing the test.
mncharity one can not only test math features, but implement a p6-ish backend, without array variables working. it's not clear that means the test suite should avoid using array variables outside of the array tests. 21:06
pmichaud arrays are currently part of sanity, I think. But I think we can agree there are basic features that we expect that a p6 implementation would handle sooner rather than later, and that arrays might be in that list. 21:08
I also think that if we asked the general population "is it reasonable to write p6 programs even if .nextwith isn't available", then a lot of people would agree.
mncharity I note that "complexity of dialect-of-tests will grow as implentation strength grows" and "use a minimal sanity-like dialect-of-tests" are incompatible positions.
pmichaud I disagree 21:09
mncharity ! say on :)
pmichaud one can have increasing complexity of the suite without having to increase the complexity of every test in the suite
"complexity of passable tests will grow as implementation strength grows" 21:10
mncharity so tests are written in varying dialects, whose complexity is a function of their position along some bootstrap path?
pmichaud ...whose complexity is a function of whatever functionality is needed to adequately describe the test. 21:11
tests for basic mathematical operations don't require complex functionality.
it's just like Perl 6 itself, as a language. We don't require someone to learn about .nextwith and currying if they don't need it to write a program. But it's there when they do need it. 21:13
someone should be able to use Perl 6 without having to know all of its richness. 21:14
The tests are the same say -- they should be able to test various parts of Perl 6 without having to know all of the rich features
s/say/way/
afk for a bit 21:15
Eevee pmichaud++ 21:17
mncharity let's see, wrapping up... it looks like areas of non-concensus include: () role of non-minimalism - is it ever useful? if useful, avoid it anyway? () selection of (locally) minimal dialect - is there an obvious choice? is it sanity-like? what is the cost of this? is it adequate? () what else...? 21:22
my take is () yes, no, () no, shudder, high, no. 21:23
21:23 felipe joined
mncharity my fuzzy impression is Eevee is () no, yes () ??, yes, ??, yes 21:24
and pmichaud: () ??, sometimes?? () yes, yes, acceptable??, ?? 21:25
Eevee ehh. if non-minimalism is useful your test might be too complicated 21:26
but as a general rule.. the more complex some feature, the more effort it is probably worth expending to not use it in an unrelated test
mncharity re what else... () variation of 'is there an obvious choice': is there an obvious complexity ordering - yes/no? 21:28
:)
Eevee re obvious choice: the line is blurry and depends per feature how often it's particularly useful for the rest of the suite 21:29
pmichaud obvious choice: as with most things of this nature, it may be better to get there by successive approximations with refinement rather than try to a-priori determine it at the outset 21:30
Eevee agreed
pmichaud and I don't think it has to be a strict ordering
but I think we can all agree that it's perfectly reasonable to do math tests without having .nextwith available :-)
Eevee if the test suite hits 70% complete and some feature X is only used (outside its tests) in one place, it's probably worth rewriting
pmichaud this isn't to say that none of the test suite can use .nextwith, but just that it's not really necessary or important for math tests 21:31
Eevee (fsvo '70%', 'complete', 'its'...)
pmichaud especially since if, as in this case, there's a far more straightforward way to do the tests using only basic Test.pm functionality
mncharity ... yes/no? is it a function of ease of (some) implementation, or of usefulness to test suite? is the concept flawed, or merely unknown-but-approximatable?
pmichaud function of both
mncharity re 70% agreed. 21:32
pmichaud is having .nextwith in the arith.t tests useful? I don't think it is.
so, ease of implementation concerns dominate.
Eevee well, I think those are somewhat similar 21:33
if X is particularly useful to the test suite then it's probably going to be useful in general
pmichaud I'm not so sure about that
21:33 Auzon joined
pmichaud I can think of features that would be particularly useful for testing but might not be terribly important for general purpose programming 21:33
END blocks come to mind 21:34
Eevee ah, hm
pmichaud I'm not saying END is generally unimportant, but simply that I can write a lot of useful programs without ever needing END
that said, END is important enough to testing that I think it's a reasonable candidate for sanity-level
mncharity the design points I'd like hit are () sanity (concensus) () not-too insane tests for test-driven-development of toys (some disagreement on details, but basic agreement), () 'pull out all the stops for maximal programmer productivity and test coverage' tests for validation (no concensus).
Eevee yeah that's fair
pmichaud "pull out all stops" -- we do that by using #skip blocks in the test files, and or separating them out 21:35
if by "maximal programmer productivity" you mean "maximal 'test programmer' productivity", I think that actually argues in favor of more simplicity because we increase the number of potential test authors 21:36
mncharity err, rephrasing "pull out all stops", "no holds barred", "anything goes", "maximal use of p6 power".
pmichaud in a particular test implementation?
in the test suite in general?
or in the language?
mncharity in the third "flavor of tests", whose focus is on validation of mature implementations, rather than helping immature ones. 21:37
pmichaud simply put the mature tests into test files that focus on the mature features
obra t/spec, which is what I thought was being discussed, is defined as validating particular features as defined in the synopses. 21:38
21:38 japhb joined
pmichaud yes, I thought our discussion was limited to t/spec tests 21:38
I'm not talking about all testing for modules written in Perl 6 21:39
obra which makes "anything goes" somewhat antithetical to the whole point.
mncharity sigh, so I'm clearly failing, let's see..
pmichaud give me an example of a "mature feature" that you think is appropriate for arith.t
21:40 rdice left
pmichaud oh, I've got one. heredocs. 21:40
obra . o { POD } 21:41
pmichaud I can see why someone would want to use a heredoc in arith.t, perhaps as a database of things to be tested inside of a loop or the like
however, I think we can do some basic tests in arith.t without heredocs, and then skip over the part that does use heredocs 21:42
fudge allows us to do that.
mncharity re t/spec, if t/spec's role is defined as validation of mature impls, rather than helping immature ones, then that's a very hard task which I'd like to write in real p6, not in some restricted dialect.
pmichaud mncharity: would you need "real p6" for *every* test ? 21:43
I'm not saying that tests can't contain "real p6". I'm saying that we should adjust the amount of "real p6" in each test to the level appropriate for each test. 21:44
clearly a mature impl should be able to pass any tests that an immature one passes.
obra t/spec is for validation of features.
I would expect that tests for arithmetic are going to require fewer interesting features than tests for overloading. 21:45
pmichaud exactly
21:46 pmurias left
obra In all cases within t/spec, if a refactoring can remove a feature not related to the spec being tested, that refactoring should be considered reasonable 21:46
er. remove a dependency on
pmichaud obra++
Eevee yes 21:47
mncharity I just got an out of band "please shut up now". so, I'm out. bbl
pmichaud in general it's better to reduce dependencies than to increase them :-)
Auzon Definitely.
I'll keep that in mind this summer.
21:51 jferrero joined
[particle] auzon, we'd like you to sign a cla so you can get a parrot commit bit if you need one this summer 21:56
cla?
pmichaud purl, CLA?
purl?
[particle] purl: cla is Contributor License Agreement or www.perlfoundation.org/contributor_..._agreement
pmichaud ENOPURL
(purl already knows cla :-)
Auzon ;) 21:57
[particle] Auzon: it's probably not necessary, but it can't hurt to send one in
Auzon Alright. I'll check it out
21:58 Zaba_ joined
mncharity unless there has been a profound culture shift here in pugs land, there is no 'the consensus' and no 'the plan' for technical discussion to constitute an attempt to derail. that kind of political crud and groupthink has had little role here, and hopefully this will remain the case. 21:59
perhaps it can't survive in the absence of a benevolent dictator. but the local culture has been quite distinct from p6l and parrot. 22:00
22:07 iblechbot left 22:12 Zaba left 22:16 Limbic_Region joined 22:24 TJCRI left 22:29 sscaffidi left 22:39 clintongormley joined
clintongormley heya 22:39
any idea why the dev.pugscode.org/changeset/xxxx links aren't working? 22:40
-> 500 errors
Eevee they've been off and on for me, not sure why 22:41
clintongormley dev.pugscode.org/browser is doing the same
Eevee looks like everything is 22:42
clintongormley damn python
.oO( always blame the language )
 22:43
Eevee could be damn apache -> damn C
22:43 eternaleye left
clintongormley :) 22:44
this has probably been asked a million times before, but... 22:47
how can i contribute? i'm a reasonably experienced Perl programmer, but zero C experience
are there a list of small finite tasks that i could choose from?
obra clintongormley: one of the things that needs lots of help is fleshing out the p6 spec tests
clintongormley i presume there isn't a list of tests that need writing, but rather : here are the specs, add the missing tests? 22:48
[particle] is very glad obra++ is still here
obra rakudo, the p6 implementation on top of parrot finally got its milestone act together
so there's a list of milestones which roughly tie to p6 'synopses' (specs)
Eevee clintongormley: ha, same boat as I 22:49
clintongormley yeah, i saw that post
obra and there is a huge mass of disorganized tests built up over time as pugs (the haskell implementation) has grown.
so basically, it's a matter of picking a section of one of the synopses tied to a near-term milestone and starting to enumerate clean, simple tests for that syn's features 22:50
either pulled from the existing pugs tests or out of whole cloth
clintongormley that last line just answered the question i was writing :)
Eevee oh, there are pugs tests outside of t/spec? where are they? (or is it obvious like pugs/t/)
clintongormley which would be a good syn to start with?
obra pugs/t 22:51
[particle] eevee: occam's razor
Eevee the world would be a better place if occam's razor always applied to programming
so far its success rate for me is around 7%
obra [particle]: opinions on good syns to start with?
[particle] i say go to spec.pugscode.org 22:52
clintongormley and the tests are written in p5 or p6 or other
[particle] pick a synopsis from the list
obra tests are written in p6
svn co svn.perl.org/parrot/trunk parrot
lambdabot Title: Revision 27277: /trunk
obra cd parrot
perl Makefile.PL
make
cd languages/perl6
make spectest
[particle] however... rakudo sorely needs more oo tests
obra that will grab all of the existing t/spec from the pugs repo and run it
clintongormley you've never done that before, have you ;) 22:53
Auzon Aha, obra++ for make spectest
I was looking for that recently
obra Auzon: I didn't do that
I tried this for the first time today
Auzon No, pointing it out
obra I'm cribbing from my notes
[particle] so t/oo/ is a good place to start
obra ah :)
particle++ created it
Auzon Can we run Rakudo against pugs/t yet?
[particle] no
probably never will 22:54
obra [particle]: can I nopaste our this-morning conversation about tests and tools
[particle] auzon: we need to convert all pugs/t/ to pugs/t/spec
Eevee isn't the idea to get rid of pugs/t and merge it into t/spec?
[particle] obra: feel free
i'll throw some tuits into converting tests in the next week
obra Eevee: let's not go there ;) 22:55
Auzon I'll have tuits starting a week from today
obra there will always be a wide variety of tests that aren't spec-based
[particle] Auzon: good to know!
Auzon I'd love to jump in now, but I have finals.
[particle] something that would really help us out, and is very easy to do, is to convert all pod blocks to pod6
obra paste.husk.org/11312 22:56
[particle] replace =begin with =begin pod and =cut with =end pod
obra that's the conversation [particle] and I had about how to start doing this
clintongormley particle - that's it?
just search all available code and change those lines? 22:57
[particle] no, but it's a start
Auzon Hm... I bet I could automate that ;)
[particle] clintongormley: for the pod, basicly, yes
as soon as the pod parses, it means rakudo will actually parsefail source, instead of docs
clintongormley :)
ok - so just the rakudo files?
obra clintongormley: Eevee: would the two of you like commit bits to the pugs repo so you can start to commit to t/spec? 22:58
[particle] no.
pugs/t, except t/spec/
clintongormley and for committing changes?
obra yes
clintongormley yes please
Eevee sure
obra email addresses, pelase
please
clintongormley time is short, so can't promise results, but....
[email@hidden.address]
mncharity pugs: my $a = [3,4,5]; my @b = @($a); say pop(@b); say $a;
exp_evalbot OUTPUT[5␤3 4 5␤]
obra even a single commit is good :)
clintongormley svn ci "changed whitespace"
obra if it's more readable :) 22:59
clintongormley svn revert
obra traditional first commit is to add yourself to AUTHORS
Eevee [email@hidden.address]
obra just to test everything
ok. you should each have a commit bit in your inbox
clintongormley is there a syntax highlighter available for p6 yet? 23:00
i suppose it is changing too fast
Eevee I vaguely recall seeing something for vim a while back
so there might be an up-to-date one floating around
clintongormley will google 23:01
commit bit received - thanks
obra look in pugs/util when you check out the pugs repo
Eevee got bit
obra I see a vim mode at the least
"updates to that would be cool too"
Ok. I'm brain-fried and need to wander off
Eevee what a coincidence! I've always meant to figure out vim syntax highlighting
obra good luck, guys 23:02
clintongormley thanks :)
Eevee seeya 23:03
clintongormley commits to trunk? a branch? 23:06
Auzon I believe everything is in trunk
clintongormley ok 23:07
Auzon I don't actually see any branches.
clintongormley svn.perl.org/viewvc/parrot/branches/ 23:08
lambdabot Title: 1 [ 6 parrot 1 ] 1 12 Index of /branches 30
Auzon oh, that's parrot.
^_^'
Are you committing to Parrot or Pugs? 23:09
clintongormley ummm which one should i be committing to :)
Auzon Commitbit is for Pugs.
clintongormley isn't the focus on rakudo (and thus parrot) now?
Auzon Yes, but a lot of stuff still lives in Pugs 23:10
clintongormley ah ok
clintongormley is puzzled
23:10 vaughn joined
Auzon Yeah. You'll be working in the Pugs repo 23:11
That's where the big test suite resides.
And pretty much all Perl6 code that isn't Rakudo.
clintongormley so, i should be writing tests in pugs but running them with rakudo? 23:12
[particle] clintongormley: the perl 6 tests are in the pugs repo, because it's very easy to get a pugs commit bit
that makes it easy to recruit testers
clintongormley so: pugs/trunk/t
[particle] rakudo does an 'svn co' of pugs/t/spec/ 23:13
no, there's no trunk iirc
svn co svn.pugscode.org/pugs pugs
lambdabot Title: Revision 20349: /
[particle] or, if you don't want it to take all day,
svn co svn.pugscode.org/pugs/t pugs/t
lambdabot Title: Revision 20349: /t
clintongormley ahhh - ok, so not : svn.perl.org/viewvc/perl6/pugs/
lambdabot Title: 1 [ 5 perl6 1 ] 1 e Index of /pugs 30 23:14
[particle] no, go with pugscode
pugscode.org for more
lambdabot Title: Pugs - pugscode
clintongormley so the previous instructions for rakudo : "make spectest" - does this require me to have the pugs tests downloaded and in a particular directory? 23:15
clintongormley promises to stop annoying shortly 23:16
[particle] no
clintongormley ok - ta
[particle] you need to have and build parrot
clintongormley will shut up now and give things a try :)
[particle] then build languages/perl 6/
*perl6 23:17
if you look at the Makefile in languages/perl6/ it'll tell you all you need to know
clintongormley many thanks
g'night all
[particle] ~~
Auzon see you
23:18 clintongormley left 23:23 felipe left 23:33 cookys_ joined
mncharity TimToady: (5) it seems at eos, statementlist -> EXPR which calls expect_term, which succeeds on stdstopper, and exists the loop because pos hasn't moved. but EXPR then panics because @termstack is empty? 23:34
23:35 felipe joined
mncharity works if panic() is replaced by regex failure. 23:44
*search failure 23:45
meppl good night 23:48
mncharity good night meppl :) 23:52
meppl ;) 23:53
23:53 meppl left
mncharity TimToady: (6) It looks like dotty doesn't get prec set? perhaps dotty --> Term and an additional prec case in post. 23:55
23:58 japhb 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!