The topic for #perl6 is: | nopaste: | pugs: [~] <m oo se> (or rakudo:, kp6:, elf: etc.) (or perl6: for all) | irclog:
Set by TimToady on 25 November 2008.
00:00 dduncan left
pugs_svn r24123 | hinrik++ | [util/perl6.vim] more types and functions, and a few operator fixes 00:07
00:07 ruoso joined 00:09 Khisanth left 00:11 dr_df0 left, cdavaz left
literal is there a name for keywords like is, but, does, trusts, of, returns ? 00:19
constraints, maybe 00:20
masak literal: very difficult to ack the specs for an answer to that question. :) 00:23
00:41 Khisanth joined 00:50 alc joined, kst````` left 00:51 kst````` joined
masak literal: you might want to check what they're called in STD 00:52
literal maybe
00:56 xuser joined
masak literal: at least 'is', 'does', and 'will' are called "trait auxiliary" in STD 00:56
literal hm yeah, but that's narrower than what I was looking for, since it doesn't cover the other stuff like "but", "returns" 00:58
the name isn't crucial, I'm just wondering what I should call them in perl6.vim
TypeConstraint or something will do 00:59
masak literal: ok.
thei0s literal: are you doing a perl6 vim colouring plugin?
masak returns is called a "trait verb", and "but" is an infix operator.
literal thei0s: I'm editing the one that's in the pugs repository (util/perl6.vim) 01:00
thei0s good to know it exists :)
literal masak: yeah, but one might argue that they all place constraints on something, and vim's syntax groups aren't very broad so that definition is narrow enough 01:01
er, aren't very narrow, I meant to say
01:04 mncharity joined 01:11 Limbic_Region left 01:20 FurnaceBoy joined 01:25 FurnaceBoy left 01:27 ChrisDavaz joined 01:40 apeiron left, apeiron joined 01:45 alester joined
literal perl6: my @l = <asdf\>asdf>; print @l.perl 01:52
p6eval elf 24123: OUTPUT[Parse error in: /tmp/OpBx7GOITs␤panic at line 1 column 0 (pos 0): Can't understand next input--giving up␤WHERE: my @l = <asdf\>asdf>; print @l␤WHERE:/\<-- HERE␤ STD_red/prelude.rb:99:in `panic'␤ STD_red/std.rb:76:in `scan_unitstopper'␤ STD_red/std.rb:224:in `comp_unit'␤
..pugs: OUTPUT[\("asdf>asdf",)]
..rakudo 33391: OUTPUT[["asdf>asdf"]]
01:54 apeiron left
literal perl6: my @l = <<asdf>asdf>>; print @l.perl 01:55
p6eval pugs: OUTPUT[\("asdf>asdf",)]
..rakudo 33391: OUTPUT[["asdf>asdf"]]
..elf 24123: OUTPUT[["a"]]
literal perl6: my @l = <<asdf>\>asdf>>; print @l.perl
p6eval rakudo 33391: OUTPUT[["asdf>>asdf"]]
..pugs: OUTPUT[\("asdf>>asdf",)]
..elf 24123: OUTPUT[["a"]]
mncharity I repeatedly manage to forget what a bleeping monster is. It's comparable in size to the rest of elf combined. Boy this is going to be a lot of work.
02:02 ChrisDavaz left, apeiron joined
masak mncharity++ 02:12
thei0s can somebody tell me if this example is correct according to the newest specification? because I needed to modify it to get it working with pugs 6.2.13 (modification: all function calls with array as parameters should be: |@xs, I also replaced in all parameters *$ with just $ (I don't get it what is the point of having multiple variadic/slurpy arguments??)) 02:13
mncharity /me++ ? 02:15
pugs_svn r24124 | putter++ | STD_blue now parses and dumps
r24124 | putter++ | [STD_blue] sym bugfix.
r24124 | putter++ | [STD_green] Simplify parse caching.
mncharity for being daunted? I'm daunted by things all the time... ;)
masak mncharity: for doing what you're doing with Elf.
mncharity :)
sigh 02:16
02:16 ChrisDavaz joined
mncharity thei0s: sorry, for myself, I'm way behind on what's valid and not. 02:16
masak thei0s: I'm stumped too. looks right, though. 02:17
mncharity thei0s: actually, there's a bug in the question,
"correct according to the newest specification" and "get it working with pugs" are likely to be mutually exclusive. pugs stopped tracking the spec some years ago. 02:18
masak nod.
02:30 ChrisDavaz left 02:34 ChrisDavaz joined 02:43 kst````` left, kst`````` joined
mncharity ok, end of day. 02:45
02:46 apeiron left 02:47 apeiron joined 02:48 justatheory joined
pugs_svn r24125 | hinrik++ | [util/perl6.vim] highlight block labels and =<>, fix multiline <>, add more keywords, and plenty of other improvements 02:57
mncharity good night all & 03:00
pugs_svn r24126 | putter++ | [elf_h] Flesh out RegexDef node somewhat.
rakudo_svn r33396 | pmichaud++ | [rakudo]: !OUTER doesn't work for bare closures, so refactor implicit lexicals to avoid it.
03:00 mncharity left
literal perl6: say "asdf { 1 + \} 1 }" 03:05
p6eval elf 24126: OUTPUT[asdf { 1 + \} 1 }␤]
..pugs: OUTPUT[*** ␤ Unexpected "}"␤ at /tmp/TKj8vcO4eC line 1, column 18␤]
..rakudo 33395: OUTPUT[Statement not terminated properly at line 1, near "+ \\} 1 }\""␤␤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)␤]
literal perl6: say "asdf { 1 + 1 }"
p6eval pugs, rakudo 33395: OUTPUT[asdf 2␤] 03:06
..elf 24126: OUTPUT[asdf { 1 + 1 }␤]
literal perl6: sub hi { 'ho' }; say "asdf &hi" 03:07
p6eval elf 24126, pugs, rakudo 33395: OUTPUT[asdf &hi␤]
masak rakudo: say "{ "1 + } 1" }" 03:08
p6eval rakudo 33395: OUTPUT[1 + } 1␤]
masak rakudo: say "{ "{ "{ 1 }" }" }" 03:09
p6eval rakudo 33395: OUTPUT[1␤]
pugs_svn r24127 | putter++ | [STD_blue] 'token x { a }' -> IR. 03:19
03:21 Psyche^ joined 03:22 ChrisDavaz left 03:23 Patterner left, Psyche^ is now known as Patterner 03:37 justatheory left 03:41 [particle]1 joined
rakudo_svn r33397 | pmichaud++ | [rakudo]: Clean up handling of implicit lexicals a bit. 03:50
r33398 | pmichaud++ | [rakudo]: Add :g(lobal) flag to .subst( $regex, $repl )
03:54 [particle] left 03:57 alester left
pugs_svn r24128 | hinrik++ | [util/perl6.vim] highlight escaped delimiters in certain single-quoted strings 03:59
04:18 alester joined
rakudo_svn r33399 | pmichaud++ | [rakudo]: Add :g(lobal) flag to .subst($str, $repl) 04:20
04:22 stephens left 04:28 masak left 04:38 slavik`lap joined
rakudo_svn r33400 | pmichaud++ | [rakudo]: Oops! Fix :global on .subst( $regex, $str ) 04:40
04:57 kst`````` left 04:58 kst`````` joined 05:01 kst`````` left
slavik`lap rakudo: my @list = 1..inf; 05:45
p6eval rakudo 33408: OUTPUT[Could not find non-existent sub inf␤current instr.: '_block11' pc 22 (EVAL_14:17)␤]
slavik`lap rakudo: my @list = 1..inf; @list[5]=42; for 1..10 { say @list[$_]; } 05:46
p6eval rakudo 33408: OUTPUT[Could not find non-existent sub inf␤current instr.: '_block11' pc 22 (EVAL_15:17)␤]
slavik`lap no lazy list?
pugs: my @list = 1..inf; @list[5]=42; for 1..10 { say @list[$_]; } 05:48
p6eval pugs: OUTPUT[*** No such subroutine: "&inf"␤ at /tmp/K7SYFT2uCI line 1, column 12-18␤]
thei0s shouldn't inf be written as Inf ?
slavik`lap rakudo: my @list = 1..Inf; @list[5]=42; for 1..10 { say @list[$_]; }
p6eval rakudo 33408: OUTPUT[Use of uninitialized value␤Use of uninitialized value␤␤Use of uninitialized value␤␤Use of uninitialized value␤␤Use of uninitialized value␤␤42␤Use of uninitialized value␤␤Use of uninitialized value␤␤Use of uninitialized value␤␤Use of uninitialized value␤␤Use of uninitialized
05:48 ChrisDavaz joined
slavik`lap heh 05:48
rakudo: my @list = 1..Inf; @list[2]=42; for 0..4 { say @list[$_]; } 05:50
p6eval rakudo 33408: OUTPUT[Use of uninitialized value␤Use of uninitialized value␤␤Use of uninitialized value␤␤42␤Use of uninitialized value␤␤Use of uninitialized value␤␤]
slavik`lap pugs: my @list = 1..Inf; @list[2]=42; for 0..4 { say @list[$_]; }
hmm 05:51
pugs: say "hello"
p6eval pugs: No output (you need to produce output to STDOUT)
pugs: OUTPUT[hello␤]
slavik`lap pugs: my @list = 1..Inf; @list[2]=42; for 0..4 -> $a { say @list[$a]; }
rakudo: my @list = 1..Inf; @list[2]=42; for 0..4 -> $a { say @list[$a]; } 05:52
p6eval pugs: No output (you need to produce output to STDOUT)
rakudo 33408: OUTPUT[Use of uninitialized value␤Use of uninitialized value␤␤Use of uninitialized value␤␤42␤Use of uninitialized value␤␤Use of uninitialized value␤␤]
slavik`lap interesting
05:53 iblechbot joined 06:03 kane_ joined 06:14 iblechbot left 06:32 masak joined 06:35 ashizawa joined 06:49 slavik`lap left 06:55 alester left 07:01 sri_kraih_ left 07:09 DemoFreak joined 07:19 IRSeekBot joined 07:26 elmex joined 07:31 adc_penner joined 07:36 jferrero joined 07:51 justatheory joined 07:58 apeiron_ joined 08:01 apeiron left 08:02 apeiron_ is now known as apeiron 08:11 pbuetow joined 08:14 justatheory left 08:21 adc_penner2 joined 08:24 adc_penner left 08:25 iblechbot joined 08:36 adc_penner2 left 08:37 jjore left, pbuetow left 08:42 mtrimpe left 08:43 mtrimpe joined 08:44 smg left
thei0s I was wondering if something like "my $file = open 'largefile.txt', :r; for =$file -> $line { say $line; }" would use more and more memory as the file gets read or will it discard previously read lines from memory? (imagine largefile.txt with size >1GB) (if yes, would it then be better to use sth like: while(!$file.eof) { $_= =$file; ... } ?) 09:00
masak thei0s: assuming you don't store away old lines, they should go out of scope and be garbage collected. 09:02
(regardless of the actual looping construct) 09:03
thei0s ql 09:08
is it possible to have classes in classes? or classes in blocks?
(just curious)
masak thei0s: possible, but right not more useful than having them outside.
thei0s nice 09:09
masak one of those less specced things.
s/right not/right now no/
09:10 yahooooo left 09:12 justatheory joined 09:31 ejs joined 09:35 salmonix joined
salmonix Hi there, curious about Perl6 what should I try? Pugs or Rakudo/Parrot? 09:35
09:36 jjore joined
masak salmonix: I'd say Rakudo, since Pugs development has been stalled for a year or so. 09:36
whereas Rakudo is progressing by leaps and bounds.
salmonix masak: Yes, it was behind my question. Ok., I go for it. One more thing: 09:39
Do I have to build Parrot AND then build perl6 or perl6 in Languages is enough? 09:40
masak Parrot and then Rakudo.
cd parrot; perl Makefile.PL; make; cd languages/perl6; make perl6 09:41
salmonix masak: Ok. I'm on it. 09:43
masak best of luck.
salmonix salmonix: (keeping them Xed.) Thanx. 09:44
thei0s am, I don't know if Rakudo is already the right answer for this, because many things don't work (I tried 5 examples from pugs and nothing worked) 09:50
moritz_ rakudo doesn't implement as many features yet as pugs does. 09:51
masak though in some cases it's actually more feature-complete.
moritz_: good morning.
I'd prefer Rakudo over Pugs as a development platform today, because the things Rakudo does implement, it implements closer to the spec of today, and it's being actively developed, so one can talk to the developers about the time frame for upcoming features 09:55
audreyt did a fantastic job with Pugs a few years ago, and she has hinted that she'll be coming back to Pugs development. but that hasn't happened yet. 10:00
10:08 kane__ joined, kane_ left 10:14 smg joined 10:26 justatheory left 10:28 riffraff joined
riffraff hi 10:31
moritz_ hi riffraff 10:32
10:39 ruoso left, yahooooo joined 10:54 ChrisDavaz left 10:55 masak left 11:16 kane_ joined 11:17 kane__ left 11:23 smg left 11:26 alc left 11:41 salmonix left 11:43 vixey joined 12:01 Lorn joined 12:02 DemoFreak left 12:19 pnu left 12:31 rff joined 12:46 riffraff left 12:49 ashizawa left
thei0s hm, there is just one thing left that I am wondering about from the beginning a couple of days ago when I started learning perl6: why does perl6 use so many new words/keywords/way things are called (some pretty unusual, so it looks there will be need for a dictionary soon) for things that already exist with an established name in other languages or that could be called different so that they would be easily memorizable (eg. command 't 12:51
(or also in the language itself 'rule' is just 'token' with whitespaces, so why not just 'tokenws' or sth that is easy to remember (also rules from language theory have nothing to do with whitespaces), why classes introduce new keywords like 'has' and 'method' if they are quite similar to 'my'/'our'(with addition to having accessors) and 'sub', I also think that the keyword 'multi' is not needed (the compiler can be smart enough to fi
for me all this looks just like a way to confuse people who want to learn perl6 and to make it harder for those who already know perl6 to use something else! in addition these different hard to remember names serve the sustaining of imho bad situation that Larry described somewhere: "When I look at the present situation, what I see is the various scripting communities behaving a lot like neighboring tribes in the jungle, sometimes tra
12:53 smg joined
rff thei0s, maybe because the thing in perl6 that resembles things in other languages are not exactly like those.. and so having them called the same way would introduce more subtle problems? 12:53
moritz_ thei0s: usually all Perl keywords are also English words. 'tokenws' isn't, 'rule' is
likewise 'say' is much shorter and better to read than 'println' 12:54
thei0s tokenws -- tokenwhitespace
moritz_ that violates the principle of huffman coding
thei0s say in good, not criticizing it :)
moritz_ thei0s: btw some of your lines are truncated, see for what we see 12:55
thei0s but the features are almost same as elsewhere, so why shouldn't they be called similar?
lambdabot Title: IRC log for #perl6, 2008-12-01
thei0s (at least similar if not same)
moritz_ if you look at you'll see that the use cases for rule ws. token are not that similar, and it makes sense to distinguish these two (IMHO) 12:56
thei0s all lines are truncated, ahh.. I tought freenode had longer lines allowed.. so here is the continuation of the "first line": 12:57
(eg. command 'taken' is called 'yield' in python (why the new name?), 'role' is in java just an interface with some implemented methods, @array.elems is usually retrieved with a length method (even in perl5 it is called length(@array)), slurpy arguments are usually called variadic, 12:58
'given'/'when' are really a little more than 'switch'/'case' from elsewhere, but imho there is not such a change that would satisfy to force everyone in learning new words, signatures in subroutines are usually called just parameter lists...)
(or also in the language itself 'rule' is just 'token' with whitespaces, so why not just 'tokenws' or sth that is easy to remember (also rules from language theory have nothing to do with whitespaces), why classes introduce new keywords like 'has' and 'method' if
they are quite similar to 'my'/'our'(with addition to having accessors) and 'sub', I also think that the keyword 'multi' is not needed (the compiler can be smart enough to figure it out by itself), and many many more... (also a couple of artifact words/ways of calling things from perl5))...
for me all this looks just like a way to confuse people who want to learn perl6 and to make it harder for those who already know perl6 to use something else! in addition these different hard to remember names serve the sustaining of imho bad situation that Larry described somewhere:
"When I look at the present situation, what I see is the various scripting communities behaving a lot like neighboring tribes in the jungle, sometimes trading, sometimes warring, but by and large just keeping out of each other's way in complacent isolation."
moritz_ thei0s: gather/take is quite different from yield...
thei0s: for one gather/take is dynamically scoped, which yield isn't... 12:59
thei0s: and gather/take's workflow is determined by the laziness level of the list, whereas yield is strictly lazy
the thing with given/when is that, unlike switch/case in other languages, they are not tied together, you can used them separately (where 'switch/case' doesn't make sense, from a linguistic point of view) 13:00
thei0s but does does this really affect the programmer? if he wants to know the details he could check them and see that all "perl-yields" are such and such... but a novince would not distinguish them 13:01
moritz_ it does affect the programmer 13:02
just like 'die' and 'return' are different
thei0s why not.. you could have case ... just in the middle of the code and know that this is doing ~~ $_ ..
moritz_ (return() unwinds one call stack, die() as many as needed before a try block is found)
anyway, I think that it's more confusing if you have multiple concepts of the same name (even if they are similar) than having a separate name of separate things 13:06
but that's up for personal taste, of course 13:07
thei0s yeah, but this are the toughts that came to my mind when I started learning perl6... new words for similar concepts mean more time to remember them 13:09
moritz_ when reading the code? or writing? 13:10
thei0s when reading tutorials, documentation and code 13:11
moritz_ I do see the downsides of a rich syntax, which is why I started working on a tool that explains syntax that you feed into it
13:26 Lorn_ joined
rakudo_svn r33419 | pmichaud++ | [rakudo]: spectest-progress.csv update: 227 files, 4689 passing, 10 failing 13:30
r33419 | pmichaud++ | * 10 failures in S12-methods/multi.t
13:31 Lorn__ joined
moritz_ pugs: say "test" 13:33
p6eval pugs: OUTPUT[test␤]
moritz_ I don't know who unbroke pugs on evalbot, but I praise him/her/it
13:38 Lorn left
pmichaud thei0s: in each of the cases you cite, there's actually a distinction that is being made that means we can't use the old keyword 13:39
thei0s: for example, 'has' isn't at all the same as 'my/our'.
thei0s: given/when isn't the same as switch/case (because 'when' can be used inside of any block, not just 'given/switch', and has different semantics from 'case') 13:40
thei0s yes, but it is similar... a user would know in which context he is and therefore know how it is going to behave
pmichaud ...which is similar? 13:41
thei0s has and my/our :)
pmichaud no, they're different. has is a per-instance variable, my/our are for the class.
'has' means "every instance has its own attribute like this", 'my/our' are just lexically scoped to the class/package. 13:42
13:44 apeiron left
thei0s so you yre telling me it is possible to do: class A { my $shared; method x($s) { $shared =$s; } method y { return $s } } and then use: my $aa; my $; $aa.x(10); say $bb.y; -- would print 10? (like a class variable, shared among all instances of this class?) 13:44
moritz_ yes, that would work.
pmichaud I think you meant "return $shared" in method y, but yes -- 'my' declares a class variable. 13:45
thei0s ok, good then
i tought my/our can not be used, therefore having a 'has' is just adding complexity
pmichaud for 'rule' versus 'tokenws' -- this actually goes against what you're advocating; people writing grammars have long been used to the term "rule", while "tokenws" would be introducing an unfamiliar new word into the lexicon. 13:46
my/our in a class definition are really just package variables -- i.e., shared among all methods of the package.
they just define a couple of helpful accessor methods as well.
thei0s what if token would be replaced by something that contains word rule :) 13:47
pmichaud 'token' is also the standard rule that grammar authors are used to.
moritz_ then it would probably be longer
pmichaud sorry, standard term
people who write grammars, parsers, and lexers have often used the term 'token' and 'rule' -- these are naturally familiar to them (and so they get used).
13:48 Lorn_ left
thei0s ok, afaik those who just theoretically write grammars don't distinguish any whitespace sensitive or not sensitive variants of rules.. 13:49
moritz_ usually a token is a minimal subrule in a lexer, and what it matches is handed to the parser 13:51
13:51 alester joined, iblechbot left
pmichaud I think one of the things we discovered while creating Perl 6 was that the distinguishing characteristic between what we call "token" and "rule" is their handling of inter-token whitespace. 13:52
13:52 alester left
pmichaud and I mean that in a grammar-author sense, not just a Perl 6 sense 13:52
if you ask a (non-Perl 6) grammar author "What is the difference between a 'token' and a 'rule'", the answer would tend to come down to the notion that a 'token' is taken as a unit and we look carefully at each token, while a rule is a sequence of tokens where we expect to allow whitespace 13:54
it turns out to be _very_ natural in practice
thei0s :) 13:59
14:04 meppl joined 14:18 justatheory joined 14:47 rindolf joined, PZt joined 14:51 ruoso joined 14:53 masak joined 15:00 rff left, ruoso left 15:05 justatheory left 15:07 apeiron joined 15:10 iblechbot joined 15:11 justatheory joined 15:13 eternaleye left 15:20 slavik joined, pnu joined 15:30 dmq joined, riffraff joined
riffraff hi everyone 15:31
moritz_ @seen everyone
lambdabot I haven't seen everyone.
riffraff eh 15:32
I was wondering what is the best way to define a type with partial order
moritz_ what's "partial order"?
just that there's a < defined somehow?
riffraff yes 15:33
consider the problem of defining a new Color class
with only three possiblt instances red, green, blue
moritz_ there's always a "but" :-) 15:34
riffraff shall I define the <=> relation 9 times ?
slavik riffraff: had that nickname for long?
riffraff slavik, coupld of years, yes
do I remember you someone else? :) 15:35
slavik riffraff: do you work in the IT sector by chance? perhaps in an IT support position?
riffraff: probably not
moritz_ riffraff: well, in the general case yes. In other cases you can re-used other ops, or exploit symmetries
riffraff IT support? no, sorry. I am a free lance developer so I think I qualify in the IT sector, though 15:36
moritz_ riffraff: with an enum Color <Red Green Blue>; you inherit infix:<< <=> >>(Int, Int)
riffraff moritz_, I see thanks
slavik hmm, nvm then :(
riffraff ah, I didn't know about this cool enum :) 15:37
moritz_ it's buried deep down in S12 I think
riffraff I will check, thanks 15:38
15:38 sri_kraih joined 15:42 ruoso joined 15:48 REPLeffect joined 16:02 Lorn__ is now known as Lorn 16:05 smg left 16:12 spx2 left 16:13 spx2 joined 16:15 jhorwitz joined 16:21 stephens joined 16:27 riffraff left 16:33 sri_kraih_ joined 16:37 Coleoid left 16:40 rindolf left 16:42 rdice joined 16:46 ejs1 joined 16:48 sri_kraih left 16:49 ejs1 left 16:56 ejs left 17:04 alester joined 17:05 ruoso left 17:16 hercynium joined, Exodist joined 17:19 masak left 17:23 Exodist left 17:29 Exodist joined 17:36 smg joined 17:37 xinming joined 17:39 jferrero left 18:04 alech left, Lorn_ joined 18:05 ejs joined 18:22 Lorn left 18:25 kane__ joined, kane_ left 18:28 kane__ left 18:32 Lorn_ is now known as Lorn 18:37 lizsac left 18:38 pbuetow joined 18:39 adc_penner joined 18:40 cognominal left 18:41 lizsac joined 18:56 cognominal joined
rakudo_svn r33426 | particle++ | [rakudo] convert some PAST::Val(...) calls to constants 19:00
19:00 gbacon joined 19:03 alech joined 19:09 Ehtyar joined
rakudo_svn r33427 | infinoid++ | [CAGE] Remove trailing whitespace. 19:10
19:26 pbuetow left 19:27 exodist_ joined, Exodist left 19:30 Gothmog_ joined 19:34 DemoFreak joined 19:36 FurnaceBoy joined 19:39 pbuetow joined 19:43 OuLouFu joined 19:44 smg left 19:45 smg joined 19:46 araujo left 20:04 alech left 20:08 araujo joined 20:27 justatheory left 20:31 dmq left 20:36 FurnaceBoy left 20:38 lizsac_ joined, lizsac left 20:39 Gothmog__ joined, Gothmog_ left
rakudo_svn r33429 | particle++ | [rakudo] take advantage of parrot's config to make rebase tool more portable 20:50
21:01 rdice left 21:05 riffraff joined
riffraff I think I found a bug in rakudo and I may have a mini patch 21:07
wrt subset declarations
yet, the tests pass, mone pass too, but if I run spectests some of them seem to fail 21:08
or maybe not, I cannot understand the output :)
[particle]1 there are some expected failures in spectest for rakudo atm
21:08 [particle]1 is now known as [particle]
riffraff I see 21:09
[particle] i'm not sure the failures are the same on every platform, though, so i can't tell you precisely which are expected 21:10
riffraff I'm just rerunning the test suite without my patches and I'll compare the outputs 21:12
at first I did not notice that spectes was a separate target
[particle] 'make test' runs sanity tests in parrot repo 21:13
'make spectest' runs the official test suite from pugs repo
only spectest has expected failures
riffraff yep, I found out now thanks 21:14
slavik failure is not an option!!!
21:14 Lorn left
riffraff by the way, how do I handle this? the bug appears when using as a subset guard clause a regex literal 21:16
apparently rakudo treats it as a block but then the internal machinery fails because a regex is.. mh.. not a block enough
now, I haveth fix and my tests, but shall they go in the rakudo tests or in the pugs codebase? 21:17
the official spec miss these because they just check for non-regex literals in that position
but the failure is most probably impèlementation specific
riffraff feels extremely incompetent 21:18
[particle] submit patch and tests in a message to [email@hidden.address]
we'll help you sort it out from there 21:19
riffraff with [PATCH] header? 21:21
21:24 alech joined, Gothmog__ is now known as Gothmog_
[particle] yes, please 21:25
21:44 smg left
pugs_svn r24129 | hinrik++ | [util/perl6.vim] more comments 21:46
21:47 ejs left
riffraff done 21:52
moritz_ rakudo: sub evil(@a is copy) { @a[0] = 8 }; my @b = (1, 2); evil(@b); say @b[0]
p6eval rakudo 33429: OUTPUT[8␤]
moritz_ bug, or feature?
avar Bug? the @a param obviously isn't being copied 21:57
moritz_ I don't know how deep the copy should go 21:58
pmichaud I don't think is copy is implemented
I know that we still have issues with array parameters.
moritz_ rakudo: sub a($b is copy) { $b = 4 }; my $x = 5; a($x); say $x
p6eval rakudo 33429: OUTPUT[5␤]
moritz_ it is, for scalars ;-)
pmichaud well, there ya go. It's the array parameter problem. 21:59
I'm working on arrays now, actually. :-)
[particle] hrmm. i've got a grammar problem
moritz_ and I'm turning the test in RT #60976 into a spectest
[particle] i need to parse '--' as an option terminator for arguments 22:00
rule arguments { <options>* [ '--' <?before ws> ]? <resources>* }
pmichaud note that <?before ws> is the same as <?before 'ws'>
[particle] that's not working as i expect, it doesn't recognize "-- foo" properly
ah, i need <?before <ws>> then 22:01
pmichaud ....and it won't find it, because the "rule" will have already eaten any ws.
but why need the <?before at all? 22:02
[particle] --h # invalid option
pmichaud rule arguments { <options>* '--'? <resources>* }
[particle] -- h # end of options, 'h' is a resource
pmichaud here I'm assuming that '--' doesn't parse as a valid option.
[particle] correct
pmichaud rule arguments { <options>* '--'? <resources>* } # should work. 22:03
[particle] the only valid options for now are: '-' [ 'h' || '-help' ]
--h parses 'h' as a valid resource 22:04
pmichaud the <options>* doesn't report that as an invalid option?
[particle] no
pmichaud ...why not?
[particle] 22:05
pugs_svn r24130 | moritz++ | [t/spec] test for subset type with `where /regex/', RT #60976 22:06
22:06 donaldh joined
pmichaud shouldn't anything beginning with hyphen be considered an option (if it occurs before any '--')? 22:06
22:08 apeiron left, apeiron joined
moritz_ do you need predictive parsing for the command line options? 22:09
pmichaud there are a couple of issues to be considered 22:10
[particle] i need to differentiate invalid options from valid options
moritz_ you could do that more easily in a second pass
pmichaud thinking of "command line arguments" as being analogous to "perl 6 arguments", is it possible for positional arguments to be intermixed with named (option) arguments? 22:11 a b c --option=foo # valid ?
[particle] options can take arguments
pmichaud or do we say that options _always_ have to precede the non-option arguments?
moritz_ pmichaud: that works for the MAIN sub, I think 22:12
[particle] options always precede non-options in my view
pmichaud oddly, that's backwards from the way Perl 6 does it. :-)
where non-options tend to precede options.
moritz_ pmichaud: for 'perl6 --opt1 script --opt2' you'd expect --opt2 to be an optioin to the script, not to the compiler
[particle] we need to make sure the zones are well defined... what moritz said 22:13
pmichaud moritz_: ...and I don't have an issue with that. But I'm not sure I agree with the idea that options always precede non-options.
That's certainly not the case for many existing unix commands.
[particle] sure, ack included
it is the case for perl 5
and python, java, etc 22:14
moritz_ pmichaud: right, it's not enforced unless there's a good reason for it
pmichaud so I'm not sure that Perl 6 option syntax should enforce it :-)
moritz_ am I too impatient, or is 'make spectest' really slow again?
344 wallclock secs - I'm impatient ;)
pmichaud moritz_: yes, it's slow. I'm looking for ways to speed it up again.
I'm looking for "quick to do" ways to speed it up again. 22:15
[particle] my working assumption is: rule arguments { <options>* '--'? <resources>* <rest> }
pmichaud I'm thinking that --h should fail to parse because it's an invalid option, not because it's an invalid resource. 22:16
[particle] where <rest> is handed off to the resources to deal with
pmichaud the '--' is just a marker to say "whatever comes after this isn't an option, even if it looks like one".
[particle] did you see the error?
it matches '--'
then matches 'h', without a preceding space
pmichaud you missed my point. 22:17
inside of 'options' it should detect that we have something that begins with '-' but isn't '--' nor a valid option.
or, the other way to do this is to have options parse everything beginning with hyphens, but stop when it gets '--' \s
i.e., it's the <options> rule that should detect that we have an invalid option, not the <resources> rule. 22:18
because we say that "--h" is an invalid option, not that it's an invalid resource.
just a sec 22:19
[particle] ok, so that means i need to move '--' parsing inside of options 22:20
moritz_ I think you need an assertion somewhere, so that parsing of an invalid option is an error 22:21
otherwise --foo will allways be parsed as <--><foo> 22:22
another way of looking at it: 22:23
and here we use the {*} to decide if the option we just received is a valid one or not (and panic if it isn't)
that way the options aren't build directly into the grammar
[particle] pmichaud: agreed, i'll use actions to determine validity 22:25
i'll extend your examples to include --name options 22:26
should i be using | rather than || ?
pmichaud more (incomplete) ideas and thoughts: 22:27
|| implies ordering, | implies any order will do.
for this it shouldn't really matter.
However, I'm a wee bit interested to see how this would work in a unix environment, where the arguments are already broken up into parts already. 22:28
[particle] i'm working on the grammar for documentation's sake, not to use in the real world
pmichaud ah.
[particle] the way i see it, perl 6 will offer 'services' or 'modes' (more) 22:29
like, -h, --help, -v --version, will call the 'usage' service/mode
these services can be overridden 22:30
but perl 6 offers a reasonable default
so, they'll live in a particular namespace, and have well-defined signatures
pmichaud will this work with the notion of Perl 6's handling of usage already documented in S06 22:31
[particle] it should, indeed 22:32
pmichaud okay, was just curious.
[particle] i may not call it 'usage', as not to get it confused with 'USAGE'
22:35 ruoso joined
[particle] so, i wanted to key off the service name in the grammar 22:35
-h {*} #= usage 22:36
but, i won't do that.
pmichaud well, if it's primarily for documentation purposes, it might be okay to put the options into the grammar directly. From an implementation perspective I suspect it'll have to be treated a little differently. 22:37
[particle] i do want this document to compile, so i can test it
i'll push the semantic analysis down to 22:38
ruoso Hello!
[particle] hi ruoso
ruoso [particle], have you seen the proposed S07 22:39
22:40 donaldh left
[particle] ruoso: no, i haven't 22:40
you do mean formats, right? 22:41
ruoso [particle], please consider taking a look... I still haven't started implementing it (besides the concept Perl 6 code I posted to p6-language)
[particle], no... S07 has been reassigned to "Iterators and Laziness"
22:41 mncharity joined
[particle] ah, needs a major update 22:41
i bet needs to be updated as well 22:42
22:42 riffraff left
[particle] maybe even some cron job(s) 22:42
ruoso yeah... it seems to be completely outdated
[particle] come to think of it, i haven't updated my pugs wc in a while either... 22:43
mncharity says it was generated today from r24129... 22:44
lambdabot Title: S05