pugs.blogs.com | pugscode.org | pugs.kwiki.org | paste: sial.org/pbot/perl6 | <stevan> Moose... it's the new Camel ":P | .pmc == PPI source filters! Set by Alias_ on 16 March 2006. |
|||
spinclad | as eighter fly flies fly, fly flies fly eighternal | 00:17 | |
nm: that sounds like good sympathy -- share pain, not suffering | 00:26 | ||
01:03
mako132_ joined
01:06
azuroth joined
|
|||
azuroth | I need food! | 01:08 | |
szbalint | Food for the mind, you've came to the right place. | 01:10 | |
TimToady | wolverian: all object attributes are supposed to work like variables, so "temp undefine $*ARGS.irs" or some such ought to work. | 01:13 | |
wolverian | TimToady, yeah. what I really wanted, I guess, was a tempified copy of the object for the duration of the method call chain. | 01:44 | |
I'm not sure if that's very sane. | |||
01:53
Quell joined
02:03
frederico joined
02:08
neoesque joined
|
|||
spinclad | { temp $foo; $foo.leg.mangle } # was it all just a bad dream? was it all just copyOnWrite? what is the extent of temporization? | 02:14 | |
02:16
integral_ joined
|
|||
spinclad | # the spatial scope? | 02:16 | |
# as it were | |||
02:18
DesreveR joined
|
|||
spinclad | By S06, this seems to depend on $foo .TEMP method, and by default, preserves as much structure as $saved = $foo; ... $foo = $saved; , which again depends on $foo. | 02:36 | |
s[$foo][$foo's] | 02:37 | ||
Note: S03 refers to S04 for temporization ['Note thae C<temp> and C<let> ... See S04 for more details.'] AFAICS this should refer to S06 instead. | 02:43 | ||
s/thae/that/ | |||
02:53
integral joined
02:57
Khisanth joined
03:01
weinig is now known as weinig|sleep
03:06
macroron__ joined
03:14
FurnaceBoy_ joined
03:15
trym joined
|
|||
aufrank | ?eval rule plain_a { [a]* }; 'aaa' ~~ / <plain_a> /; | 03:19 | |
?eval rule assert_a { <[a]>* }; 'aaa' ~~ / <assert_a> /; | 03:20 | ||
?eval say "1" | |||
aufrank misses evalbot | |||
03:21
kanru joined
03:28
svnbot6 joined
03:29
integral_ joined,
evalbot_10232 joined
|
|||
audreyt | ?eval rule plain_a { [a]* }; 'aaa' ~~ / <plain_a> /; | 03:30 | |
evalbot_10232 | Match.new( ok => bool::true, from => 0, to => 3, str => "aaa", sub_pos => (), sub_named => { "plain_a" => Match.new( ok => bool::true, from => 0, to => 3, str => "aaa", sub_pos => (), sub_named => {} ) } ) | ||
audreyt | ?eval rule assert_a { <[a]>* }; 'aaa' ~~ / <assert_a> /; | ||
evalbot_10232 | Match.new( ok => bool::true, from => 0, to => 3, str => "aaa", sub_pos => (), sub_named => { "assert_a" => Match.new( ok => bool::true, from => 0, to => 3, str => "aaa", sub_pos => (), sub_named => {} ) } ) | ||
audreyt | ?eval say "1" | ||
evalbot_10232 | OUTPUT[1 ] bool::true | ||
obra | 'morning, audreyt | 03:31 | |
audreyt | greetings. | 03:32 | |
obra | How's things? | ||
audreyt | just woke up. thinking about lighttpd packaging and general deployment strategy | 03:33 | |
clkao . o O (runapp) | |||
there's a very noisy bird outside since 3am | 03:34 | ||
obra | audreyt: does this mean you're shaving the jifty packaging spec yak? | ||
audreyt | potentially. still want ot get the declarative-action yak done first today | 03:35 | |
obra | *nod* very cool | ||
audreyt | there is a deadline some 26 hours from now for all this to work on win32 :) | ||
so I'll... use whatever way most expedient. | |||
obra | Yow. understood. | ||
audreyt | (but the basic jifty was already ported a couple days ago in my checkin) | 03:36 | |
obra | Yep. we've only found one small bug | ||
File::Path chokes when you ask it to mkdir something existing | 03:37 | ||
audreyt | put a -e test before make_path? | 03:39 | |
obra | -e or -d? | 03:40 | |
I'd gone with -d. | |||
Oh. and actually, mason, deep inside somwhere does a ..unless (-e _) | |||
which breaks with our loc | |||
audreyt | oh. right. I custom-patch that by hand | 03:41 | |
obra | custom patch mason? | ||
aufrank | hi audreyt! hi evalbot_10232! | 03:42 | |
audreyt | no, rewrite HTML:::Mason::Compiler::ToObject::compile_to_file | ||
obra | oh. | ||
audreyt | *H::M::C::TO::ctf = sub { ... }; | ||
obra | "ew" | ||
audreyt | granted, not a good idea. | ||
obra ponders *H::M::C::TO::_ = sub { } | 03:43 | ||
audreyt notes that *ANY::_ is just *::_ | 03:44 | ||
i.e. the parser has a special rule | |||
obra | oh god. I didn't realize. | 03:45 | |
obra cries | |||
Perl6 will make this all better? right? ;) | |||
FurnaceBoy_ pats obra | 03:46 | ||
audreyt | right :) actually Perl5.10 already does | ||
via lexical _ | |||
aufrank | basic rules question (the one I was trying to figure out with evalbot): what's the difference between matching an asserted character class using an assertion and matching a raw character class using an assertion? | 03:49 | |
audreyt | [a] is just the char "a" | 03:52 | |
aufrank | I know | ||
audreyt | [a-z] is the string "a-z" | ||
<[a-z]> is a char between a and z | |||
aufrank | right | ||
oh | 03:53 | ||
audreyt | did I unask your question? :) | ||
aufrank | <[a..z]> === <[a-z]> ? | ||
audreyt | oh wait a minute | 03:54 | |
a-z now means 'a', or '-', or 'z' | |||
a..z is correct. sorry. | |||
I was confused by the :Perl5 example in S05. | |||
aufrank | rule plain_alpha { [alpha]* }; rule assert_alpha { <[alpha]>* }; 'abc' ~~ / <plain_alpha> / ; 'abc' ~~ / <asserted_alpha> / # what's the difference ? | 03:56 | |
I think it's something about what goes into $/, but I don't know what | 03:57 | ||
audreyt | the first one doesn't match. | 03:58 | |
or rather, it matches empty. | |||
?eval 'abc' ~~ /[alpha]/ | |||
evalbot_10232 | Match.new( ok => bool::false, from => 0, to => 0, str => "", sub_pos => (), sub_named => {} ) | ||
audreyt | ?eval 'abc' ~~ /[alpha]*/ | 03:59 | |
evalbot_10232 | Match.new( ok => bool::true, from => 0, to => 0, str => "", sub_pos => (), sub_named => {} ) | ||
audreyt | square brackets is not the perl5 (?:...) | ||
so it's like (?:alpha) | |||
s/not/now/ | |||
aufrank | oh | 04:00 | |
non capturing group | |||
got it | 04:01 | ||
04:01
kanru joined
|
|||
aufrank | so <[...]> is enumerated or named character class, period. | 04:01 | |
aufrank wishes things sank in faster =\ | |||
audreyt | just need more gravity | 04:02 | |
aufrank | I'd better start digging | ||
04:28
eccles joined
|
|||
eccles | hello | 04:33 | |
04:38
kanru joined
|
|||
aufrank | hello | 04:38 | |
audreyt: should the signature parser work like the Moose example in S06 line 1050, where it returns a new object of class Param based on the contents of the match? | 04:44 | ||
and then an object of class Signature based on the Param objects? | |||
audreyt | sec | 04:45 | |
aufrank | rule positional { / <sigil> <name> / { return Param.new( :sigil<$/<sigil>>, :name:<$/<name>>) } } # naive example | 04:47 | |
ok, that was wrong in a bunch of ways | |||
but hopefully the right parts got the point across | |||
audreyt | yo | 04:49 | |
aufrank | hi hi | ||
audreyt | I think just get the parse tree working is a good 1st step | ||
aufrank | ok | ||
audreyt | the "production" part is as simple as | ||
rule positional { <sigil> <name> : { return Param(*()) } } | 04:50 | ||
aufrank | ok, that makes sense | ||
audreyt | (which translates to Param.new(sigil=>$<sigil>, name=>$<name>) | ||
) | |||
aufrank | right | ||
audreyt | which is why we brought in *() notation :) | 04:51 | |
aufrank | so is it my job or the production job to know that postfix:<?> sets the optional bit to true? | ||
audreyt | the production job. and production will be part of rule | 04:52 | |
so you'll eventually need that too | |||
see ruleFormalParam | |||
line 380 src/Pugs/Parser.hs | |||
that's how it'd eventually look like | 04:53 | ||
(conceptually not syntactically) | |||
aufrank | this helps | 04:54 | |
thanks | |||
audreyt | np :) | ||
aufrank | do you want me to add fixes so that the requirement/optional markers are postfix? | ||
or will that cause too much breakage> | |||
? | |||
audreyt | they already are | 04:55 | |
see line 386 | |||
aufrank | -- $foo is required --> !$foo | ||
audreyt | it's after line 385 | ||
it's canonicalized internal representation | |||
not parser | |||
aufrank | ok | ||
audreyt | see line 391 | ||
it's just so we can apply a foldr on it | 04:56 | ||
aufrank | ok, I get that :) | ||
buu | Wow | 05:19 | |
Your names are impressively hard to differentiate | |||
aufrank | yeah, that has come up today | ||
05:19
aufrank is now known as aufrank_not_audr
|
|||
aufrank_not_audr | any better? | 05:19 | |
=P | 05:20 | ||
05:20
aufrank_not_audr is now known as aufrank
06:01
ghenry joined
|
|||
spinclad | <auDREYT> auFRANK: much | 06:15 | |
:] | 06:16 | ||
06:16
aufrank is now known as auFRANK
|
|||
auFRANK | fine by me | 06:16 | |
spinclad | if you like | 06:17 | |
auFRANK | what's a good rule for a valid key of a hash? | ||
spinclad | a string, unless the hash has another :shape | ||
is that what you mean? | 06:18 | ||
auFRANK | ok, now say that in rule-speak :P | ||
06:18
neoesque joined
|
|||
auFRANK | token key { [ <alpha> | \d | _ ]+ } is too restrictive | 06:18 | |
but is | 06:19 | ||
spinclad | depends who's parsing it, i imagine | ||
auFRANK | token key { <.>* } too pernissive> | ||
? | |||
06:19
cmarcelo joined
|
|||
spinclad | i think it just must not be confusible with whatever closes its parsing | 06:19 | |
auFRANK | good call | 06:20 | |
spinclad | :key %hash<key> %hash{'{'} | ||
the last form should allow any string | |||
auFRANK | I'm only dealing with :key right now | 06:21 | |
spinclad | there, i'm not sure you can make much wider than other var names | 06:22 | |
auFRANK | good news to me | ||
spinclad | :key(1) etc | 06:23 | |
:key, ... :key:key2 | |||
auFRANK | there's an exception, I think | ||
I'm pretty sure :1(2) is allowed | |||
but $1 is not allowed as a variable name, right? | |||
audreyt | :1(2) means something else | 06:24 | |
?eval :8(123) | 06:25 | ||
evalbot_10232 | 83 | ||
spinclad | :2(1) parses 1 in binary; i'm not sure how that falls out of, or away from, adverbs/pairs generally | ||
audreyt | the :name() and :digit() forms are separate forms | ||
spinclad | (like audreyt said) | ||
audreyt | you can't use the :digit form to passin named param | ||
auFRANK | good good | ||
can you put traits on unpacked parameters? | 06:26 | ||
( [ $foo, *@bar] is rw, $baz ) | |||
spinclad | ( $pair [ $head, *@tail ] is rw ) ... i imagine so | 06:28 | |
(if i got that syntax right) | |||
auFRANK | ok, here goes nothin' | ||
spinclad | but in $pair ... is rw, perhaps the $pair is what's rw | ||
but i think your form should work | 06:29 | ||
svnbot6 | r10233 | aufrank++ | initial attempt at rules for parsing signatures | 06:32 | |
r10233 | aufrank++ | only attempted single dispatch signatures so far | |||
r10233 | aufrank++ | no invocant support, limited type parameter support | |||
r10233 | aufrank++ | almost definitely need help with unpacked params | |||
audreyt | woot! auFRANK++ | 06:33 | |
auFRANK | it's very possible that I am hopelessly off the mark | ||
spinclad | auFRANK++ | ||
audreyt | (and I wouldn't mind if you re/nick back to lower-case :)) | ||
06:33
auFRANK is now known as aufrank
|
|||
aufrank | phew, that's more like it | 06:33 | |
audreyt: I don't think I quite grok the magic of <%hash> forms | 06:34 | ||
audreyt | actually that looks Just Right | ||
aufrank | so if they are useful, they're not in this version | ||
audreyt | oh, there's no need to grok them for sigs | ||
they are for e.g. <%infix> | |||
allowing user-defined infix operator | |||
aufrank | do you think that unpacked params take types and traits? | 06:35 | |
sub chase ( Dog [$fido, *@doggies] are vicious, $cat ) {...} | 06:36 | ||
spinclad | i seem to recall that the unpacking form is generally another signature, so yes, types, constraints, traits, pretty much everything i think | 06:38 | |
audreyt | yeah. | 06:39 | |
spinclad | (Dog @pack [ $fido is nice, *@others are bad ] ) | 06:40 | |
aufrank | spinclad: are you think that sub would be called as chase(@pack1, @pack2) ? | ||
my understanding was that unpacking happens in place, so you're describing two different array paremeters as opposed to unpacking the first one | 06:41 | ||
s/think/thinking/ | |||
spinclad | that would be (Dog @pack, Dog [ $fido is nice, *@others are bad ] ) | 06:42 | |
aufrank | oh | ||
wow, ok, need to think about that :) | |||
spinclad | i was intending one @pack, with aliases on its head and tail | ||
audreyt | (bbiab) | 06:43 | |
spinclad | sorry, must get up tomorrow ... to bed now & | 06:44 | |
aufrank | gnight | ||
thanks for the help | |||
spinclad | glad to see this getting real, though | 06:45 | |
glad to contribute | |||
svnbot6 | r10234 | aufrank++ | s/packed/unpacked/ | 06:56 | |
r10234 | aufrank++ | more notes about broken stuff | |||
r10234 | aufrank++ | attempted to handle observations from spinclad++ | |||
r10234 | aufrank++ | (@foo [$head, *@tail]) # unpacks by aliasing | |||
r10234 | aufrank++ | (@foo, [$head, *@tail]) # unpacks second param in place | |||
07:16
kattana_ joined
07:24
elmex joined
07:35
iblechbot joined
|
|||
svnbot6 | r10235 | aufrank++ | described access to the match object for some Signature object attributes | 07:41 | |
r10235 | aufrank++ | removed explicit whitespace in rules, they're supposed to DWIM with :w | |||
r10235 | aufrank++ | attempted to fix up type parameter handling, probably closer now | |||
r10235 | aufrank++ | described some more rough spots | |||
07:44
cmarcelo left
|
|||
aufrank | ok, that's it for me for the night | 07:54 | |
08:20
SvenDowideit2 joined
08:28
lisppaste3 joined
09:03
larsen joined
09:26
drbean_ is now known as drbean
09:51
neoesque joined
09:59
iblechbot joined
10:37
larsen_ joined
|
|||
meppl | guten morgen | 10:54 | |
azuroth | evening | 10:55 | |
meppl | hello azuroth | 10:57 | |
azuroth | hi meppl, what's up? | ||
meppl | its all fine | 10:58 | |
11:03
larsen joined
11:04
kanru joined
|
|||
gaal | how do I tell svn to remove a file from source control, without deleting my copy of it in the working directory? | 11:08 | |
I hope it isn't mv ; svn rm ; svn ci ; mv | |||
11:40
FurnaceBoy joined
|
|||
gaal | say, why are statement-ending blocks desireable? To make C<if> and friends consistent with everything else? | 11:42 | |
11:53
larsen_ joined
12:32
macroron joined
12:44
jsiracusa joined
12:48
larsen joined
12:52
Limbic_Region joined
13:16
xinming joined
13:17
larsen_ joined
13:19
weinig|sleep is now known as weinig
|
|||
TimToady | gaal: yes, though rather than saying they're more consistent, I look at it more like, "the user doesn't have to worry about whether this block belongs to a built-in or not." | 13:45 | |
13:50
justatheory joined
|
|||
theorbtwo | ...and thus you can write a grope function that really does look like grep. | 13:55 | |
14:02
Southen_ joined
|
|||
nothingmuch | gaal: ping | 14:02 | |
pasteling | "nothingmuch" at 84.108.53.74 pasted "YAPC iternary" (6 lines, 335B) at sial.org/pbot/17083 | 14:03 | |
aufrank | gaal: with svk there is a -K switch on rm that means "keep local copy" | 14:18 | |
I imagine there's something like that in svn | 14:19 | ||
FurnaceBoy | actually, I don't think there is | 14:22 | |
furthermore, even if you rm url:// remote and then 'svn up', it blows away the local file, rather than leaving it there unmanaged | 14:23 | ||
FurnaceBoy can't remember what would happen with local changes though | 14:24 | ||
FurnaceBoy should test it | |||
14:43
fishb0t joined
|
|||
fishb0t | 'lo all: If I have questions about parrot install - better to ask here, or #parrot on irc.perl? | 14:44 | |
aufrank | I've had luck with #parrot for that | 14:48 | |
fishb0t | thnx, I'll try that. | 14:53 | |
gaal | <nothingmuch aufrank FurnaceBoy> >>.ack | 14:54 | |
gaal writes a gripe function | 14:55 | ||
szbalint | :)) | 14:57 | |
aufrank | TimToady: I finally checked a first pass at Signature parsing, if you want to check it out | 15:09 | |
src/Pugs/Parser/Signature.pg | |||
svnbot6 | r10236 | aufrank++ | some fixes on accessing match objects | 15:35 | |
r10236 | aufrank++ | clarified my ideas about aliasing matches | |||
15:44
FurnaceBoy_ joined
16:21
Ymmv joined
16:26
jsiracusa joined
16:34
integral_ is now known as integral
17:00
justatheory joined
|
|||
gaal | { my $foo = 42 ; my $foo = 54 } # error? warning? | 17:10 | |
17:30
chris2 joined
17:32
elmex joined
17:33
m__ joined
|
|||
szbalint | why, gaal? | 17:41 | |
18:07
larsen joined
18:21
larsen_ joined
18:42
penk joined
18:43
penk joined
18:44
penk joined
18:50
Khisanth joined
18:55
marmic joined
18:56
ma|2duk joined
18:58
ilogger2 joined
19:26
DaGo joined
19:39
ruoso joined,
aufrank joined
19:51
aufrank left
19:56
penk joined
19:57
penk joined
20:11
aufrank joined
20:33
ludan joined
|
|||
ludan | hi | 20:33 | |
20:36
Quell joined
20:38
Quell joined
20:40
DaGo joined
|
|||
svnbot6 | r10237 | wolverian++ | typo fix | 20:52 | |
20:52
aufrank joined
21:29
kanru2 joined
|
|||
aufrank | should sub foo (@a [$b, @c [$d, *@e]], *@f) {...} be allowed? | 21:34 | |
can you unpack a parameter that is already being unpacked? | |||
azuroth | looks sane to me | 21:41 | |
21:44
Raftman joined
|
|||
wolverian | can I use stub declarations to declare the signature of a set of multis? | 21:51 | |
s,stub declarations,a stub declaration, | |||
azuroth | like `multi foo(Int $x, Int $y), (Str $x, Num $y), ($x, $y, $z);`? interesting | 21:53 | |
21:53
xerox joined
|
|||
xerox | audreyt: ping? | 21:54 | |
Or anybody. | 21:55 | ||
wolverian | azuroth, actually, I was thinking along the lines of 'multi foo (Foo, Bar --> Baz) {...} multi foo ([], $bar) { ... } multi foo (@foo, $bar) { ... }' | ||
xerox | Anybody knows how does CPAN work on the security side? | ||
szbalint | depends which side of security. | 21:57 | |
xerox | szbalint: mind to come to #haskell-overflow a second? | 21:58 | |
szbalint | sure, if I can help it will turn out in a sec. :) | 21:59 | |
xerox | Thank you | ||
azuroth | wolverian: that's a lot more normal. I don't know whether it's specced, but I'd also like it to be | ||
wolverian | good, someone agrees with me :) | 22:01 | |
btw, I also hope we have foldl, not just foldl1 (reduce).. | 22:04 | ||
azuroth | I would also kinda like a compile-time { ... }, if I were going to use it like that though | 22:05 | |
like... sub die_sub { die; die; die; }; macro infix:<...!> { $?ROUTINE := &die_sub # would this work? }; CHECK { for @subs -> $s { if $s == &die_sub && { die "this sub sucks" } } } | 22:10 | ||
or something... I wonder whether it's doable | |||
aufrank | audreyt told me the other day about tiebreaking sigs for multis | 22:11 | |
so you can do `sub foo (Int $x, Str $y : Str $z Set $q) {...}` | |||
s/sub/multi sub/ | |||
wolverian | is that missing a ,? | 22:12 | |
aufrank | that allows declaring more than set of invocants for the multi within the same signature | ||
yes, there should be a , between $z and Set | |||
and actually, I think it needs to be either a multi method or a multi submethod | 22:16 | ||
because plain sub doesn't have an invocant? | 22:17 | ||
azuroth | hmm, maybe they aren't really invocants, just look like them? | 22:21 | |
aufrank | I think they are actual invocants when they are split by colons like that | 22:23 | |
but I can't find this tiebreaking syntax anywhere in the syns | |||
the closest I see is from S06 | 22:24 | ||
Multimethod and multisub invocants are specified at the start of the | |||
parameter list, with a colon terminating the list of invocants: | |||
multi sub handle_event ($window, $event: $mode) {...} # two invocants | |||
multi method set_name ($self, $name: $nick) {...} # two invocants | |||
audreyt or TimToady: is the tiebreaking inv syntax for multi sigs documented somewhere in the syns? If so, where? | 22:27 | ||
ludan | audreyt: are you living in the netherlands? | 22:29 | |
azuroth is off to TAFE | |||
bye all! | |||
23:19
SamB joined
23:20
avar joined
23:23
justatheory joined
23:26
pdcawley_ joined
|
|||
meppl | gute nacht | 23:33 | |
23:37
putter joined
|
|||
putter | abs.t has constructs like is(ref abs($_), ref $_, "got") | 23:37 | |
is this valid? | 23:38 | ||
why does is it not parse like is(ref(...))? | |||
wolverian | ref has a signature that takes one scalar? | 23:39 | |
dvorak | what wolverian said | ||
putter | my impression is pugs considers arity, but a spec p6 parse doesn't. | ||
I'm wondering if i'm mistaken about the latter | 23:40 | ||
or whether abs.t is just non-spec | |||
wolverian | I hope p6 does. | ||
putter | non-trivial interaction with optional args. | 23:41 | |
wolverian | mm. | ||
audreyt | p6 does consider 0, 1, and Inf | 23:47 | |
where 1 may be optional | 23:48 | ||
and that's all it's allowed to care | |||
i.e. as far as parser is concerned, (), ($), ($?), (*@) | |||
are the only 4 variants | |||
TimToady: strangely, this is implied, never documented. should we document it somewhere? S02? | 23:50 | ||
putter | so the parser consults the scope to determine from proto signatures whether an ident should be considered term, prefix, or... greedy something? | 23:51 | |
audreyt | in PGE it's called "prelist" | 23:52 | |
for "prefix listop" | 23:53 | ||
in Pugs/Hs currently it's a toplevel "apply sub" rule | |||
outside normal precedence parsing | |||
putter | fine name. still sitting here contemplating the consequences for the parser | ||
nod | 23:54 | ||
audreyt | essentially that makes all listops the same prec level | 23:55 | |
otoh, not clear what "tighter" listops means. | |||
23:55
pdcawley_ joined
|
|||
aufrank | audreyt: do you know if tiebreakers are documented in a syn? | 23:58 | |
putter | so when I compile a file, its parse is dependent on the arity of subs defined in my ::* of the moment? | 23:59 |