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.
TimToady I don't think you have to declare it. @_ is born env like $_ 00:00
audreyt sub f ($x, *@_) {} 00:01
so @_ is env by virtue of its name?
00:01 Khisanth joined
audreyt can I convey this env-hood to other things in the param list? 00:01
TimToady I think so. It's either that or by virtue of *, but I don't really like that.
sub foo (env $x) {...} 00:02
audreyt but that's a type
TimToady declarators are keywords
theorbtwo sub foo ($x is env) {...} ?
audreyt sub foo (env Int $x) {}
then
worksforme
TimToady sub foo (our Int $x) is just a semantic error, not a syntactic one.
audreyt actually it can be made to work easily 00:03
by really rebinding the our $x away
on each invocation
theorbtwo That doesn't sound very "our", but perhaps I'm just perl5thinking -- I don't recall the difference between my and our in perl6. 00:04
TimToady but we have the basic syntax "decl (decl $x, decl $y)" where the inside declarator overrides the outer.
audreyt my ($x, $y, our $z)
that just follows from allowing declarators in Sigs 00:05
TimToady yep
audreyt since my now takes a Sig
TimToady sub foo ($x, state $y = 0) might even make sense
but maybe not 00:06
audreyt so maybe the special syntax
sub moose ($.x)
is just sugar for
sub moose (has $x)
TimToady what I was thinking, under the redecl is the same rule
but that also kinda means you could put the *only* has into the BUILD args. 00:07
submethod BUILD ($.typo) 00:08
"how did I get a typo attribute?"
audreyt right. 00:09
svnbot6 r10376 | audreyt++ | * Signature.pg: Allow declarators to precede a param
r10376 | audreyt++ | (must occur before the optional type).
audreyt so maybe not a good idea after all
TimToady should "my ::T $foo" be working yet? 00:14
doesn't seem to parse. 00:15
audreyt it's parsed and not handled now
now, as in, r10373 00:16
TimToady I get unexpected ":" expecting comment, qualified identifier, variable name or "(" 00:17
svnbot6 r10377 | audreyt++ | * Parse for "my ::T $x"
TimToady will that handle "my ::('T') $x" as well? 00:18
(or not handle as well) 00:19
audreyt I don't think we should handle symbolics there... 00:21
maybe it can be made to work by forcing a parse-time evaluation
TimToady probably not necessary. Can always predeclare with class T {...}. 00:27
that's what I did in the test in question. 00:28
audreyt k. 00:29
so, why is
foo({...}.meth)
not kosher?
foo({...}.meth, 1, 2, 3)
would it be parsed as
foo({...} $_.meth)
two terms in a row?
I thought in a paren-call, it's okay to use {} that way 00:30
TimToady It's probably okay--I'm just not sure we should let people get in the habit of bare {}.meth
audreyt the dot-after-block is only "loose" on bare
bare {}.meth is always
(bare({})).meth
TimToady say {}.meth is currently (say {}).meth 00:31
audreyt yeah
but say({}.meth) should be fine
forcing people to write say(({}.meth)) doesn't quite make sense 00:32
TimToady other than arity, are there any .meth that are likely to be applied to a bare block?
audreyt .assuming?
TimToady and that's only in tests...
audreyt {$^x + $^y}.assuming(x=>3)
TimToady in real code it's almost always &block.arity
&block.assuming
audreyt {x => 3}.keys
?
TimToady why would you write that in non-test code? 00:33
audreyt {x => 5, y => 6}.pairs
?
{x => 5, y => 6}.{$x}
as a shorthand lookup 00:34
(I use that in p5)
$foo = {x => 5, y => 6}->{$current_key};
print {x => 5, y => 6}->{$current_key}; 00:35
TimToady which won't work in P6
(print {...}).{}
audreyt so we already said we force parens
print ({...}{})
but then, if this
print({...}{})
doesn't parse, that's quite strange
TimToady .() is always a bit weird. 00:36
audreyt what do we gain, though, by making that a parsefail?
TimToady possibly some mental consistency 00:37
audreyt ?eval true({}{})
TimToady bot's been down for a while
audreyt restarting 00:38
but I think the consistency is more to ()than to arglist
visually, if inside (), then . is no longer loose
meppl gute nacht 00:39
TimToady but then you're always scratching your head as to whether a {} is equiv to ;
audreyt schlaf gut
meppl ;)
audreyt you mean to {}; ?
00:40 hikozaemon joined
audreyt not sure where the headscratching comesfrom 00:40
TimToady sort {}.say
the {} terminates the list
audreyt but the rule is just
"blocks in bare arglists are self-terminating unless followed by a comma" 00:41
it already is magical when followed by newline
in the same position
so two magicks
but
say({}.{}) 00:42
wouldn't self-terminate and
say({}
TimToady the mental problem with that rule is that you have to run all the way to the beginning of the list to determine whether it's one of those
audreyt , 1)
does not introduce an implicit semicolon
the implicit statement-ending block already dpeend on the same "am I in a bracket" test
so I think mentally it's going to be in the same slot 00:43
TimToady could be
00:44 evalbot_10377 joined
TimToady but the statement think only happens at the top level, while this can happen at any level, and produce a rather obscure bug, as it did in the .arity tests. 00:45
and you can't just simply scan for parens: 1,2,3, mumble 4,5,6, {}.foo 00:47
audreyt why did the {}.meth become lose at the first place? 00:48
if it's just for .map:{x}.grep:{y}
then we can say that the ":" binds tightly to the {}
instead of saying any {x}.meth in list is loose
TimToady doesn't work for listops 00:49
audreyt which listops?
TimToady sort
audreyt sort {$^y <=> $^z}, 1, 2, 3;
sort {$^y <=> $^z}.moose, 1, 2, 3;
I don't think it's a big problem to let .moose parse as meth instead of parsefail
(or am I missing something?) 00:50
TimToady according to current rules that's (sort {}).moose
audreyt right
but why?
previously Pugs treats .map:{x} as ":-binding-block"
instead of any-block-not-folllowed-by-comma-is-selfterm 00:51
it seemed to work okay
(not 100% sure, just tossing around ideas)
TimToady I think adverbial :{} is brittler than the current rule even with the {}.foo problem. 00:52
00:52 tewk joined
TimToady .map: looks like a listop to me 00:52
00:53 Odin- joined
audreyt er, I think it's a listop too 00:53
it's just a listop that eats the first block.
TimToady but .map:{}, 1,2,3 00:54
except there's no : there to make it a list op if the {} eats it.
audreyt .map({}, 1, 2, 3)
mm.
say [].meth 00:55
say ().meth
say {}.meth
maybe I can train my eyes so they parse differently to my brain 00:56
takes some effort though.
TimToady say {};.meth
audreyt yes
TimToady I was kinda going that way yesterday 00:57
audreyt that's why I'm using my already-formed semiautomatic cortex
that is, the part of my brian that handles appending semicolons to blocks
to deal with this
TimToady but that kind of implies "sort 3,1,2;.say" 00:58
audreyt (which is why it's trying to reuse the "am I in a bracket" disambiguator)
oh, you mean a "literal" semicolon? I'm thinking of a "conceptual" breaker 00:59
just as the toplevel stmt introduces an unseen stmt breaker after {}
the bare list introduces an unseen expr breaker
but as you said, in expr level it's more subtle than stmt level
in Chinese there are two commas 01:06
one two separate expressions
s/two/to/
and one to separate arguments 01:07
theorbtwo Um, what do they look like. 01:08
s/\./?/; # I do that way too much.
TimToady , and 态presumably 01:09
or vice versa
audreyt yeah 01:10
the expression one is Ff0C FULLWIDTH COMMA
01:10 macroron joined
audreyt the list-arg one is 3001 IDEOGRAPHIC COMMA 01:10
each has "lower case" variants
FE50 and FE51, respectively
so it'd be naturaly to use 3001 to separate function arguments 01:11
but never mind :)
phone, brb 01:12
TimToady yay, now pass 11122 in smoke. 01:14
have to toddle of myself.
later &
audreyt TimToady++
svnbot6 r10378 | fglock++ | PCR - bugfixes; passes 38/40 tests; added a 'reverse' match option for implementing <after> 01:23
01:43 amnesiac joined
obra finds an amusing quote on wikipedia. 01:55
"The pearls are usually harvested three years after the planting, but it can take up to as long as six years before a pearl is produced." -- en.wikipedia.org/wiki/Pearl
audreyt rofl 01:57
stevan_ obra: that means we can expect Perl 6,... oh.... next christmas? 01:59
obra "The community brainstorming process finished August 1, 2000" 02:01
"Looks like it will be ready for OSCON" 02:02
02:05 sri_ joined
stevan_ obra: nice! 02:05
stevan_ prepares to port the $company_cash_cow to Perl 6 02:06
02:07 scw joined 02:16 SamB joined 02:24 neoesque joined 02:28 avar joined 02:48 FurnaceBoy joined 03:18 Quell joined 03:43 coumbes joined 04:04 Quell joined 04:08 Quell joined 04:24 arguile joined 04:54 Ymmv joined 04:59 Khisanth joined
aufrank anyone: ping 05:05
I guess audreyt in particular
audreyt pong 05:06
aufrank hi hi
audreyt hey
aufrank got a minute to talk through the rest of Capture.pg?
in particular, how should I match a positional?
it seems like it might just be <expression> 05:07
audreyt it is
<expression ,>
aufrank but I need to be able to say <expression> ~= <named>
!= 05:08
sorry, too much matlab
audreyt x <- namedArgOr parseExpWithTightOps
namedArgOr other = try namedArg <|> other
so basically use an alternation 05:09
[ <named> | <positional> ]
aufrank will the restriction that all required positionals need to precede optional positionals be reflected at the parsing level, or does that only come in once you're connecting the Capture to the Signature? 05:11
audreyt the latter.
the parsing level does not really know what the Signature will have
since you can bind a \(cap)
to multiple :(sig)
using :=
so when parsing Capture, assume no knowledge of the eventual sig 05:12
aufrank ok, makes sense :)
in a rule, where whitespace matters, how is extra whitespace in grouping or binding handled? 05:13
PerlJam plus captures may be used other places than just signatures
audreyt aufrank: elaborate wiht an example?
aufrank rule foo { [ $<bar> := <baz> ] <qux><quux> } 05:14
am I asserting anything about the whitespace matching between <baz> and <qux>
rule foo { [ <baz ]< 05:15
sorry
rule foo { [ <bar> ]<baz> } # same as
audreyt ah. 05:16
aufrank rule foo { [<bar>] <baz> }
audreyt in short, yes.
sorry, I mean, yes you are asserting
_any_ whitespace is translated to <?ws>
TimToady perhaps not whitespace around :=
audreyt but most certainly within []
TimToady yes 05:17
aufrank ok
audreyt the := is a token in itself
with two sides
so yeah, maybe not around :=.
TimToady but it does potentially seem useful before a quantifier. 05:18
<bar> * allowing whitespace between bars.
audreyt especially if bar itself is a token that doesn ot cae about ws
aufrank rule default { = $<default> := <expression( terminates => ',' )> }
PerlJam er, what?
TimToady otherwise you'd have to write [<bar> ]* 05:19
audreyt that is slightly different though
since it eats up trailing ws
05:19 elmex joined
PerlJam in keeping with historical terminology, the quantifiers act on the preceding atom. Making <bar> * work as you suggest breaks the "atom" idea 05:20
TimToady the whitespace isn't an atom
audreyt PerlJam: p5 allows that under /x
TimToady whitespace is always metasyntactic. Just sometimes it's metasyntactic for <?ws>, sometimes for <null> 05:21
aufrank ok, here's an example that I think is tricky 05:22
but maybe it's obvious
audreyt not mutually exclusive, obvious and tricky...
aufrank rule positional { [ <sigil><twigil>? $<internal> := <external>? ] } 05:23
TimToady trobvickious
aufrank do I have to run those together to avoid asserting whitespace?
audreyt broktvicious
aufrank <sigil><twigil>?$<internal> := <external> # better?
TimToady I'd say you probably want a token when youstart playuing with sigils.
audreyt I think so.
TimToady *playing 05:24
aufrank TimToady: ok, pretend I had a more rule-worthy example ;)
05:26 phpError joined
TimToady <ws> is only the default whitespace handler. I think there are probably explicit things a token can do the whitespace that might be around it, like undo the previous <ws>, or nullify a subsequent <ws>. 05:27
this is a generalization of the old :w thing of "unless there is already a whitespace matcher in that gap" 05:28
but what is a whitespace?
unless the tokens themselves have control of it?
basically, the whitespace is entirely managed by the tokens then, and rules only default to <ws> in the absence of guidance from the tokens. 05:29
05:29 penk left
PerlJam imagines parts of paintings negotiation who will be the foreground and who will be the background. 05:30
05:30 jabbot joined
PerlJam s/tion/ting/ 05:30
aufrank so if I'm defining a token that will always be bounded by whitespace on either side, but might contain optional whitespace somewhere within it, 05:31
05:31 jabbot joined
aufrank I use token foo { <bar> <ws>? <baz> } 05:31
rather than rule foo { <bar> <baz> }
?
TimToady most things should only worry about the internal whitespace.
05:32 jabbot joined
TimToady s/things/tokens/ 05:32
aufrank right, because they'll usually be put into rules which will handle whitespace around them on their behalf
TimToady or into another token that doesn't want the whitespace. 05:33
aufrank yeah
TimToady but I think some tokens (<block> maybe) want to be able to say "here's my whitespace policy, and it doesn't matter whether rules put whitespace after me. 05:34
05:34 penk joined
aufrank I see 05:34
TimToady or want to examine the whitespace before them to be sure they're in the right state.
aufrank token foo { <bar> }.assuming( <ws> = /.../ ) 05:35
or something
TimToady so all this implicit <ws> skipping is all kind of the default in the absence of more explicit direction for that particular "gap". 05:36
aufrank so a token could define policies for leading, internal, or trailing gaps
TimToady and that explicit direction can come from any level in the tree.
aufrank so there could be a grammar-wide whitespace-before-tokens policy, is an example of this? 05:38
TimToady so at a particular position, we schedule a sigspacey <?ws>, but we don't actually do it till we get down to the token in question, and if it doesn't care, we do a <?ws> before calling the token. On the other end, the token can somehow say
"I already handled the whitespace". 05:39
and nullify any implicit <?ws> going back up the rules.
might just be sufficient to let the token explicitly go back to before the leading whitespace. And of course it can chew up the following whitespace itself, if it isn't trying to change the definition of whitespace. 05:42
PerlJam So basically the default <?ws> is going to be smart enough to notice successive "calls" and delay execution until the appropriate time. Are these smarts encapsulated in such a way that users that redefine <?ws> don't have to recreate them?
05:43 coops joined, bjoern_ joined
TimToady a very good question. 05:43
that says to me that we do want to delay the call to <?ws> till the last moment. 05:44
and not try to just "undo" it.
but the question remains of how we know that the token is going to handle its own whitespace 05:46
05:47 baest joined
TimToady I suppose there could be a modifier that nullifies the parent implicit <ws> requests 05:48
05:48 pfenwick joined
TimToady the alternative seems to be to try to recognize things things like \s, and that doesn't allow for <weird> rules that recognize whitespace, nor does it make it easy to match \s**{0} whitespace. 05:49
aufrank the idea there is that if a token wants to manage its own whitespace, it should use something other than the special <ws> form to match it? 05:50
TimToady maybe token always means implicit <ws> around it where requested by parents, and if you want more control, you just have to write your own regex instead of a token. 05:51
and a regex ignores <ws> requests from parents.
aufrank TimToady: tokens always have whitespace around them in rules, or in other tokens? 05:53
token foo { <bar> <baz> } # whitespace around them?
05:53 mtve joined
TimToady whitespace is not significant in a token. 05:54
aufrank ok, that's what I thought 05:55
TimToady It's probably sufficient to just say that whitespace in a rule represents <?ws> and let the grammar rewrite <?ws> to get fancy with token cancellation policies.
aufrank works for me 05:56
at least as far as I've thought it out so far
TimToady if a token can find out where the previous <ws> started matching, that's probably good enough for now. 05:57
where previous means the ws that actually did something, since several rules might have attempted to skip ws, and only one will have succeeded. 05:58
so the current match object somehow has to keep track of "beginning of current whitespace" 05:59
svnbot6 r10379 | aufrank++ | cleaned up whitespace handling in tokens and rules
TimToady which could be quite a few lines and comments ago... 06:00
aufrank that was in Signature.pg
PerlJam Hmm. must only one have succeeded? 06:01
TimToady the second one will be after the <ws>
PerlJam Imagine that all of the consecutive <?ws> in execution order are all aliases for each other.
(i.e. they're really the same <?ws? 06:02
TimToady unless you write your <ws> as a kind of lookahead: "here's the whitespace I would have skipped if I'd skipped it"
PerlJam <?ws>)
TimToady yes, but then the question keeps coming up of how you know when to "really" match the ws.
but yes, effectively, they're the same <ws> 06:03
PerlJam How often would someone want to capture implicit whitespace? That seems like a strange thing to me. It seems that if whitespace were that important the user would have said so in the regex
TimToady and the token that wants to assert something about its preceding whitespace should not have to figure out which previous <ws> was the real one.
06:04 xern joined
TimToady yes, we may well be overengineering this for now. <ws> is idempotent unless someone wants to know which <ws> matched. 06:05
mostly a token will only want to know *whether* there was whitespace before it, if it's trying to do tricks like our statement-level block. 06:07
and even that can be handled by calling it carefully.
bjoern_ what's the type for "any object"? Any, Whatever, no type, ...?
PerlJam bjoern_: Any
06:07 xern joined
PerlJam bjoern_: or perhaps Object 06:08
bjoern_ is there a document that discusses these?
06:08 xern joined
TimToady it's sort of scatter about the synopses. 06:10
*scattered
basically Any will match any time, and box it up if it has to.
*type
Object is only "official" class-based objects 06:11
but there can also be prototype based objects that aren't really class based, just respond to .meta somehow.
bjoern_ right, that makes sense 06:12
so what about Whatever?
TimToady those are also Any but probably not Object.
Whatever is an Any type that doesn't match any type at all. It's intended to mean "just DWIM this somehow". 06:13
it's up to the particular operator to dwim it.
PerlJam so Whatever is a typeless type? :)
TimToady something like that. 06:14
bjoern_ heh
TimToady arguably it's at the bottom of the type hierarchy rather than the top.
for instance, range operator will interpret Whatever as some kind of infinity.
So 0..* is 0..Inf
but "a"..* is not expressible otherwise 06:15
since there's no "alphabetic infinity".
PerlJam TimToady: so what happens when I smartmatch against Whatever? Is the result always True or do we just disallow it?
TimToady in subscripts Whatever means "everything that makes sense in the dimension". 06:16
it depends on the operator, so in this case it depends on ~~.
I imagine ~~ should probably always match * meaning "don't care". 06:17
but * is intended to mean "don't care" in the permissive sense, not the nihilistic sense.
arguably though ~~ should never match * because nothing is actually of the Whatever type. 06:18
PerlJam $thing ~~ * seems like it would be asking if $thing is something rather than nothing. i.e. Whatever as long as it's something.
TimToady and you should really use Any if you mean Any,
it really comes down to what people will want "when *" to mean. 06:19
PerlJam I predict a lack of concensus :) 06:20
TimToady but a majority would probably want it to match anything. 06:21
PerlJam Though I guess it could be useful when the when in question happens to live in a CATCH block.
TimToady that is, "when *" would mean the same as "default"
PerlJam Hmm. right now I'm thinking of it more as "always" rather than "default" 06:22
svnbot6 r10380 | aufrank++ | changes to Capture.pg: 06:23
r10380 | aufrank++ | prefix:<*> goes to prefix:<[,]>
r10380 | aufrank++ | only bareword keys parse as opening named args
r10380 | aufrank++ | values are expressions terminated by ','
r10380 | aufrank++ | rule for captures
PerlJam It's clearly past my bedtime, so I'll spare you guys my babbling until tomorrow ;) 06:28
good night all.
PerlJam &
aufrank gnight :) 06:29
TimToady night sounds like a good plan to me. &
aufrank I guess I'm gone too, then :) 06:30
06:41 iblechbot joined
svnbot6 r10381 | aufrank++ | added named subrules for different bracketing characters in Signature.pg 06:51
r10381 | aufrank++ | marked some tasks as done in README.org and added some new ones
07:25 buu_ joined 07:45 reZo joined
svnbot6 r10382 | scw++ | Pugs::Compiler::Rule ratchet: alternation with repeat eval fail fixed 07:45
07:47 marmic joined 07:59 cdfh joined 08:00 reZo joined 08:22 andara joined 08:28 buu_ is now known as buu 08:31 coops joined
bjoern_ Is it possible to use "anything that does a specific role" as a type and if, how? 08:44
azuroth surely..? 08:45
I'd think that `sub foo(MyRole $a)` would just work? 08:46
bjoern_ that'd make sense, but I couldn't find that in S12 so far... 08:47
08:47 andara left 08:49 sri__ joined
bjoern_ ah, the bit after "Conjectural: " in S12 seems to use that 08:49
08:50 andara joined 09:05 iblechbot joined 09:43 lichtkind joined
lichtkind is the --> operator syntax still valid? 09:43
azuroth --> as in returns? 09:47
meppl guten morgen 09:49
lichtkind guten morgen :) 10:05
azuroth i mean in signaturs
10:07 andara left 10:29 andara joined 10:39 kane__ is now known as kane-xs 11:12 andara joined
bjoern_ hmm, HTTP::Server::Simple should use .bytes not .chars to determine the Content-Length, I think 11:16
theorbtwo Aye. 11:23
11:37 kanru joined 11:38 jsiracusa joined 11:51 rashakil joined 11:55 rashakil joined 12:19 iblechbot joined 12:21 mako132_ joined
aufrank good morning 12:33
12:33 orafu joined
audreyt morning 12:34
audreyt is just about to sleep
*wave* 12:37
aufrank bye!
audreyt: does pmichaud have a way of running tests on .pg files?
wolverian lichtkind, yes 12:41
12:43 Limbic_Region joined, particle_ joined 13:01 azuroth left 13:02 andara left 13:03 nothingmuch joined 13:31 justatheory joined 14:01 andara joined
lichtkind thanks wolverian 14:05
wolverian you're welcome 14:06
lichtkind wolverian what do you think are the 5 single best bits of perl6 14:09
wolverian single bits are not very information rich 14:10
Juerd lichtkind: 1, 1, 0, 1 and 0.
I forgot the offsets.
bjoern_ married bits aren't either...
lichtkind juerd very funny but you know what i want to do 14:11
juerd i write my tut because you dont have to give such talks like in bochum every time
wolverian i meant short pieces of perl6 syntax that enlightens you 14:12
Juerd lichtkind: I like doing it though :) 14:13
wolverian lichtkind, @foo[$i], @barĀ».baz, .meth_on_self, roles, mmd
I can't keep it solely to syntax :)
lichtkind with @barĀ».baz you mean hyper op 14:14
wolverian yes. 14:15
Juerd lichtkind: The best features, IMO, are: OO, grammars+rules, parallel execution (junctions and hyper ops), lexical everything (my class, my sub), Perl written in Perl
lichtkind wolverian yeah but my point is that part of my perl6 tut will by an apetizer, short chunks of perl5 code and equal perl6 to state is clear how perl6 evolved 14:16
into something very cooler
my bits i brought was
a simple junction, chained comparsion, as sub with siganture , a short class with an autogenerated accessor, and 2 for loops demonstrating ranges with steps(by) and multiple iterators 14:18
maybe i forgot something thatswhy i ask you
Grrrr [+] 1,2,3 14:20
wolverian signature unpacking
(i.e. pattern matching in haskell terms)
lichtkind whats that?
i mean signature unpacking 14:21
yes grrrr that its worth to mention
wolverian search for "Unpacking" in S06
although I think Larry did away with * so I don't know if the syntax there is right anymore.. 14:22
Juerd I don't like the recent * changes at all.
lichtkind you mean * dont stand vor slurpy arrays anmore? 14:23
and yadda is only necesary in sub but not blocks?
wolverian I think it doesn't flatten anymore. I'm not sure if it still means slurpy array in sigs
szbalint needs to catch up on changes... 14:25
theorbtwo I thought the recent changes mostly got rid of prefix * and **, replacing them with words or [,]. 14:27
Am I wrong?
14:27 scw joined
lichtkind but you guys think that i've got all the coolest quick to explain features? 14:27
theorbtwo "All the coolest quick"? 14:28
I'm not so sure about this double-at-sign stuff, but I also don't understand it. 14:29
lichtkind theorbtwo all the coolest*,* quick to explain 14:31
14:32 elmex joined, trym joined 14:35 xern joined 14:38 theorbtwo joined 14:41 justatheory joined, pfenwick joined, avar joined, obra joined, mako132 joined, domm joined, amv joined, drbean joined, jdv79 joined, clkao joined, svnbot6 joined, marcus_ joined, TreyHarris joined, Soga joined, tcliou joined, notsri joined, qwacky joined, rlp joined 14:52 hexmode joined 15:10 penk joined 15:20 hexmode joined 15:30 aufrank joined
pmichaud 12:37 <aufrank> audreyt: does pmichaud have a way of running tests on .pg files? 15:44
aufrank: not at the moment, no
I'm looking for a good way to do tests on tree results 15:45
15:46 andara_ joined 16:01 Aankhen`` joined 16:18 particle_ joined
wolverian what's wassercrat's nick here, again? 16:20
particle_ i think it's wolverian ;) # KingDillyDilly 16:22
wolverian thanks
:)
16:28 andara left 16:30 bpederse joined 16:36 ludan joined
ludan re 16:36
16:50 FurnaceBoy joined 16:53 bradleym joined 16:54 amnesiac joined 17:00 lisppaste3 joined 17:13 aufrank joined 17:43 cdfh joined
particle_ ?eval say '\x0123abg' 17:57
17:57 evalbot_10377 is now known as evalbot_10382
evalbot_10382 OUTPUT[\x0123abg ] Bool::True 17:57
particle_ ?eval say '0x0123abg'
evalbot_10382 OUTPUT[0x0123abg ] Bool::True
particle_ ?eval say "0x0123abg"
evalbot_10382 OUTPUT[0x0123abg ] Bool::True
particle_ ?eval say "\x0123abg"
evalbot_10382 OUTPUT[š’Ž«g ] Bool::True
particle_ hrmm 17:58
17:59 kolibrie joined
kolibrie OT: I installed inkscape a few hours ago, some other stuff got upgraded, now startx appears to do nothing except blank the display and kill the keyboard 18:02
anyone have any pointers or places I should look, or Xorg and/or debian foo?
bjoern_ I think there is a #inkscape channel nearby, and there is #svg 18:03
18:03 mtve joined
Juerd kolibrie: /var/log/Xorg* 18:03
particle_ juerd: how was your perl6-oo talk? 18:04
kolibrie examines /var/log/Xorg.0.log
18:07 ruoso joined
Juerd particle_: It went well 18:09
particle_: But unfortunately, I couldn't explain roles well. 18:10
particle_ i'm just glad you were able to stay awake through it
Juerd Well, I could explain the technical side well, but not when to use them instead of MI or mixins
My talk was the first
kolibrie Juerd: how far through the traits paper did you get?
particle_ they're so new, when to use them is still largely undefined
Juerd Because they scheduled two Perl 6 related talks (lt's Parrot talk, and my Perl 6 OO talk) at the same time, and the first speaker was late.
kolibrie: Somewhere around page 40 18:11
I understand why roles rock, now
That's no problem anymore.
18:11 pfenwick left
Juerd The problem's now that I don't see any reason to use inheritance anymore :) 18:11
kolibrie will have to read that paper some time
Juerd It's very technical, and even mathematical 18:12
It usos some equations to prove things. I have no idea how to read them.
uses
18:13 szbalint_ joined
kolibrie Juerd: so, I'll ask you if I have mathematical questions :) 18:14
Juerd No, don't :)
kolibrie :( 18:16
18:16 szbalint_ is now known as szbalint 18:17 FurnaceBoy is now known as ShitOnAStick 18:18 ShitOnAStick is now known as NiceNick 18:20 NiceNick is now known as FurnaceBoy 18:24 cdfh joined
ingy `_` 18:27
Juerd sh: _: command not found
particle_ man juerdsh
Juerd No manual entry for juerdsh 18:28
FurnaceBoy Juerd++
18:48 weinig joined 18:57 larsen joined 19:07 tatiane joined 19:08 tatiane left 19:27 cdfh joined 19:47 FurnaceBoy joined 19:49 larsen_ joined
aufrank Juerd: glad to hear the talk went well :) 19:49
19:53 Steve_p joined 19:55 coops joined 19:57 bernhard joined 20:14 weinig is now known as weinig|away 20:19 andara joined 20:22 FurnaceBoy_ joined
andara ?eval [+] 1,2,3 20:28
evalbot_10382 6
20:28 Ymmv joined
andara ?eval [*] 11,22,33 20:29
evalbot_10382 7986
20:30 larsen joined
andara ?eval $a=[11,22,33] and [+] $a 20:30
evalbot_10382 Error: Undeclared variable: "$a"
andara ?eval (@a=(11,22,33))&&([+] @a) 20:31
evalbot_10382 Error: Undeclared variable: "@a"
Gothmog_ try my
andara thanks. 20:32
Gothmog_ np
andara eval (my @a=(11,22,33))&&([+] @a)
Gothmog_ Question mark missing. :-)
andara :-| 20:33
Gothmog_ ?eval my @a = (11, 22, 33); [+] @a
evalbot_10382 66
andara yup
Gothmog_ Hm... 20:34
?eval 5 >>+<< (1, 2, [3, 4, [5, 6]]) 20:35
evalbot_10382 (6, 7, 8.0)
Gothmog_ Shouldn't this evaluate to (6, 7, [8, 9, [10, 11]])? 20:38
?eval my @a = (1, [2, 3]); my @b = 5 >>+<< @a; say @a; say @b; 20:39
evalbot_10382 OUTPUT[12 3 67 ] Bool::True
Gothmog_ ?eval my @a = (1, [2, 3]); my @b = 5 >>+<< @a; say @b[1];
evalbot_10382 OUTPUT[7 ] Bool::True
Gothmog_ This isn't according to the synopses, I think. 20:42
There isn't even a test for this, if I didn't overlook something...
gdickie ?eval 5 +<< (1, [2, 3]) 20:43
evalbot_10382 Error: unexpected end of input expecting block, "\\", "$/", "$!", ">>" or "<<"
Gothmog_ I think you have to put >> on the other side 'cause + is an infix op... 20:44
5 will be "upgraded" to an array automagically.
kolibrie & 20:59
21:07 froh-doh joined 21:16 FurnaceBoy joined 21:31 jsiracusa joined 21:45 lichtkind joined 21:47 pdcawley joined 22:01 pen1 joined 22:02 marcus_ joined, drbean_ joined, jdv79_ joined 22:03 clkao_ joined, TreyHarris joined 22:05 pen1 is now known as penk 22:06 domm joined 22:07 notsri joined, froh-doh joined, Steve_p joined, amnesiac joined, ludan joined, justatheory joined, avar joined, obra joined, mako132 joined, domm joined, amv joined, jdv79 joined, svnbot6 joined, Soga joined, tcliou joined, qwacky joined 22:10 mako132 joined 22:11 domm joined 22:16 Steve_p_ joined 22:20 kanru joined 22:21 froh-doh left 22:27 Hue-Bond joined 22:54 cybertrickle_ joined, Khisanth joined 22:55 obra_ joined, amv_ joined 22:57 justatheory joined 22:58 notsri_ joined 23:02 FurnaceBoy is now known as FB|zzz 23:04 Soga joined 23:07 tcliou joined 23:10 ludan joined, avar joined, svnbot6 joined, qwacky joined 23:20 Odin-LAP joined 23:40 Quell joined 23:44 weinig|away is now known as weinig 23:50 vytautas joined 23:56 dvorak joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!