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
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
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.
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
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 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
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
[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?).
[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