perl6-projects.org/ | nopaste: sial.org/pbot/perl6 | evalbot: 'perl6: say 3;' | irclog: irc.pugscode.org/
Set by mncharity on 25 March 2009.
jnthn Yeah but then you need a way of saying what's in the ro interface. 00:00
TimToady so we can mix in the type officially and still override the method to be just value
in the case of True or 42
jnthn Mixing in the type officially still doesn't give us a method Num that does the right thing. 00:01
TimToady which takes me back to the notion that Bool is really two different roles...
jnthn Plus a "mix in my name without by stuff" feels horrible.
*my stuff
TimToady well, what's the general way to make an immutable value out of an mutable type? 00:02
jnthn Define how it responds to .WHICH.
pmichaud just as a side note, it feels to me that stringification, numification, boolification, listification, and hashification really want to be one step removed from .Str, .Num/.Int/.Rat, .Bool, .List, .Hash
jnthn pmichaud: That thought had occured to me too.
pmichaud then .list/.hash continue to "feel right"
TimToady maybe, but prefix:<~> isn't the answer 00:03
pmichaud agreed, prefix:<~> isn't the answer.
jnthn That prefix:<+> is kinda hand-wavey.
TimToady at bottom, the primitives have to be single dispatch on an object, since the object decides what it means, not the language 00:04
except maybe for really primitive functions that don't do MMD
but those are very rare
pmichaud it would be okay to me if "object stringification" delegated to .Str by default, but I'm not sure that it should *be* .Str 00:05
similar arguments for "numification" and .Int/.Num/.Rat and "boolification"
jnthn I guess it's the .list vs .List/.Array/.Range distinction.
TimToady oops, gotta run off 00:06
jnthn One is "give me something I can do list-y things with", the other is "give me exactly this type"
TimToady will backlog
pmichaud Yes, exactly.
TimToady bbl &
pmichaud I suspect conversation will close here for a while, as it's late where jnthn is, I have to fix a broken Rakudo build.
jnthn Aye.
pmichaud and we could all use time to ruminate on today's discussions
jnthn Sure.
I think "what do we tell people to override" plays into this as well. "Should I override .Num or .Int?" etc 00:07
pmichaud exactly.... I'm kinda thinking "neither"
I'm thinking there's some other numification interface
just like we currently override .list to get the list-version of an object. 00:08
even if that list-version isn't a List
jnthn There's already some other itemification, listification, and hashificiation interface.
Since we seem to have picked numification, stringification and boolificiation as our value-based "ifications", I guess following the same kind of approach as we do in container space might be the way to go. 00:09
But that sitll doesn't solve us the "what about $x but 42".
pmichaud I kinda think we can't really think about "$x but 42" until we decide what numification really means. 00:10
jnthn Yes.
pmichaud just like we can't really do "$x but True" until we decide what boolification really means.
jnthn *sigh* 00:11
Just when I thought we had an answer...
pmichaud Sorry.
jnthn No, they're all good counter-points. 00:12
pmichaud Well, I'm only half sorry. I figure pain today may avoid larger pain tomorrow. 00:12
and thinking of ~(Int.WHAT) as "CORE::Int" was a bit of an eye-openrer. 00:13
*opener
jnthn Doing anything by name is messy.
pmichaud *"CORE::Int()"
(sigh)
jnthn I was under the impression seen Foo($x) co-ercing to $x as becoming $x.Foo 00:14
And that's how a class said "here's how I become a Foo"
If that's the case, then we have a *much* wider problem of how to do co-ercion, than just what the "$x but 42" has exposed.
pmichaud oh, I think that may still be true; I'm just not sure that stringification is directly .Str, nor numification is directly .Num 00:15
jnthn I mean the namespacing problem.
What does Foo::Bar($x) call?
pmichaud depends on whether method Bar is export
jnthn Or CORE::Int($x)
pmichaud but yes, if it's a type...
jnthn I meant co-ercion.
pmichaud well, coercions are a bit syntactically special, yes. 00:16
but yes, it's not clear what method would define a coercion to a Foo::Bar
jnthn Right, which is the *real* problem we have here.
pmichaud that sounds very useful, yes.
(the identification of the problem, that is) 00:17
oh, switching tracks slightly
jnthn Or at least the same one that does underly the "what Int" in $x but $y where $y maybe is an Int or a My::Int.
pmichaud the other day we were talking about how PMC types keep their mros as string values... could they be type ints?
instead of strings? the type ints are somewhat guaranteed to be unique, yes?
although I guess that wouldn't work for dynpmcs 00:18
jnthn Yes apart from type IDs are meant to be going away.
dynpmcs get a type ID too.
pmichaud well, they still hang around internally
jnthn They don't know it up front.
pmichaud when type IDs disappear they'll just become pointers, I suspect.
jnthn I think there's some kinda idea that one day we'll be free of type IDs.
pmichaud I think we'll be free of "type ID as int"
I think we'll still have an ID, it'll just be an address.
jnthn When I re-wrote Parrot's object system initially, we were free of integer type IDs and everything was about pointers. 00:19
pmichaud I doubt it will be a string. At least I hope it won't be that :-)
unless we start to guarantee string uniqueness :-)
jnthn Then it was made to mesh into existing Parrot rather than existing Parrot made to mesh into it.
pmichaud Understood.
and I know the feeling. :->
okay, I _think_ I've fixed the build... testing now. 00:20
jnthn Heh, what was it?
Anyway, type IDs would be an improvement on strings. 00:23
pmichaud oh, I'm refactoring things to enable .HLL mapping
jnthn But we'd just have to get it past the "type IDs are dead" mentality.
pmichaud but apparently I forgot to add a file to the repo
jnthn (As in, they are alive and kicking internally for the foreseeable future) 00:24
pmichaud and "git status" didn't show my unadded file
jnthn Oh. Odd.
pmichaud (which I'm a little surprised about)
jnthn Yeah, same.
I found git add a weird beast.
pmichaud I think the death of type IDs has been exaggerated.
jnthn Aye, same. 00:25
I think anyone who really understands the issues knows they aren't going to disappear internally for quite a whioe.
*while
pmichaud right.
anyway, if mro could use type ids (even temporarily) instead of strings, that might be a huge win.
speed-wise, too.
jnthn Yes. 00:26
Wonder how hard it'd be...
Maybe let's suggest it at the next #parrotsketch?
pmichaud sure
it's an internals change, so wouldn't require deprecation.
jnthn Yeah, it's VTABLE structure, and I hope people aren't mucking in there too much. 00:27
pmichaud okay, I have to join family for dinner (belatedly, since rakudo appears fixed). see you tomorrow
jnthn Yeah, I sleep soon...enjoy dinner.
skids more fun with printf in Parrot: total has accesses by key type for rakudo '1.say' 04:10
skids reads: tot 380000 I 0 CS 12130 S 367852 PMC 18 ptr 0 04:11
writes: tot 92000 I 0 CS 904 S 91096 PMC 0 ptr 0
mankash how \Q works
skids in perl5?
mankash yes
skids \Qstuff\E, but go to channel #perl 04:12
mankash $rtr=\Q$snmpget .1.3.6.1.4.1.9.2.1.3.0\Q
here \Q not working for me
skids use \E at the end not \Q
mankash ok
thx
skids np
mankash giving compilation error 04:14
$snmpget is a command 04:15
skids inside quotes 04:16
'1.say' hash number of elements % operations (0 to 8, then 63+)
reads: 0.28 64.50 13.50 3.51 0.46 0.20 0.19 0.37, 12.72
writes: 14.23 9.03 6.18 4.40 3.58 2.96 2.39 2.18, 29.80
use quotes: $rtr="\Q$snmpget .1.3.6.1.4.1.9.2.1.3.0\Q" 04:17
use quotes: $rtr="\Q$snmpget .1.3.6.1.4.1.9.2.1.3.0\E"
even
mankash now it is not giving any compilation error but add \ all the places 04:19
mikehh rakudo (b83a0b0) builds on parrot r38415 - make test PASS / make spectest (pugs r26582) FAIL 08:51
t/spec/S09-subscript_slice/slice.rakudo - (Wstat: 11 Tests: 27 Failed: 0) 08:52
t/spec/S12-class/basic.rakudo - TODO passed: 30 08:53
./perl6 t/spec/S09-subscript_slice/slice.rakudo handles all the tests then has a Segmentation fault 08:54
mikehh thats on Kubunt Jaunty (9.04) AMD64 08:55
masak merry Friday, disruptive techies.
mberends good rakudoday, masak 08:58
masak \o/ 08:59
masak and, presto, Rakudo builds today. 09:03
pmichaud++
mberends @seen presto ;) 09:04
lambdabot I haven't seen presto.
pugs_svn r26593 | azawawi++ | [S:H:P6] updated to v0.49 which contains the latest STD. 09:20
jnthn H H 09:29
O AI
mberends O AI # did you drop something?
masak !IAH HO
mberends rakudo: "!IAH HO".flip.say 09:30
p6eval rakudo b83a0b: OUTPUT«OH HAI!␤»
masak rakudo: subset FooStr of Str where /^foo/; multi method trim(FooStr $self:) { return "OH HAI" }; say "foo".trim 09:31
p6eval rakudo b83a0b: OUTPUT«OH HAI␤»
masak that's just... so cool.
I can haz dispatch on subtyped invocant! \o/ 09:32
rakudo: subset FooStr of Str where /^foo/; multi method trim(FooStr $self:) { return "OH HAI" }; say "bar".trim
p6eval rakudo b83a0b: OUTPUT«No applicable candidates found to dispatch to for 'trim'␤current instr.: 'parrot;P6metaclass;dispatch' pc 243371 (src/gen_actions.pir:0)␤»
masak jnthn: how come that doesn't work, though?
jnthn masak: Because "bar" ~~ /^foo/ is false? 09:33
masak I know that.
my question is more along the lines of: why don't I get the ordinary .trim there? 09:34
jnthn oh hang on...
masak it seems an applicable candidate to me...
jnthn You're deifning methods outside of a class...
masak is that naughty?
basement cat told me to do it! 09:35
anyway, got to change locations again. please discuss appropriateness of defining methods outside of classes until I get back. :P 09:36
jnthn Well, not sure, but we do also have a ticket somewhere along the lines of "you can define methods outside of a class", I'm sure...
jnthn pulls latest Rakudo 09:39
jnthn I think this ticket can be closed? rt.perl.org/rt3/Public/Bug/Display.html?id=57444 09:43
Since :Trig tag is working...
masak jnthn: re RT ticket about declaring methods outside of classes: no, I find no such ticket. at least not one matching the string 'method' in the subject line. 10:04
jnthn Hmm, OK, I thought I'd seen one. 10:05
masak jnthn: anyway... why doesn't the "bar" version dispatch to Str.trim?
masak more importantly, is it something I should tell RT about? 10:07
jnthn masak: I'm not entirely sure how/why the first one works. 10:08
masak :)
it felt amazing that it did, to be sure.
jnthn rakudo: "foo".trim
p6eval rakudo b83a0b: ( no output )
jnthn OK, so there is something there
masak I mean, who needs monkeypatching when you can dispatch on subtyped invocants?
jnthn Well, you're essentially monkey-patching without the monkey.
masak *lol* 10:09
sounds like a good name for a blog post.
jnthn Does it work if you do monkey-patch the method in? 10:11
masak how do you mean?
rakudo: subset FooStr of Str where /^foo/; multi method trim(FooStr $self:) { return "OH HAI" }; class Str is also { multi method trim() { return "CHEEZBURGER" } }; say "foo".trim; say "bar".trim 10:12
p6eval rakudo b83a0b: OUTPUT«CHEEZBURGER␤CHEEZBURGER␤»
jnthn I meant put the FooStr one inside the is also too. 10:13
masak tries
jnthn omfg how many enums tickets do we have... 10:14
masak so, enums day today? :)
putting the subset decl inside the 'is also' decl brings back the "No applicable candidates" message.
jnthn Yeah, I think it might finally be time to bite the bullet and sort out enums. 10:17
masak tries to understand why a line in a November test uses .WHAT for type equivalence 10:18
ah, it was probably because smartmatching against the Match type object failed. 10:20
seems to work now. 10:21
rakudo: say ("foo" ~~ /foo/) ~~ Match
p6eval rakudo b83a0b: OUTPUT«1␤»
jnthn masak: On subset decl issue, already there is 64098[BUG] MMD on subset types fails for short name 10:28
masak oh, ok. 10:29
not the same issue, I'd say. 10:31
problem is, I don't really know what the issue should be with the monkey-sans-monkey-patching.
is it that the original method is hidden?
or that dispatching on subset types of the invocant shouldn't be allowed at all?
jnthn I don't know that writing a method outside a class like that is allowed (other than having heard various references to some Main class...) 10:33
(and either way, Main is not Any)
My guess is that you're ending up augmenting the exported trim 10:34
masak is there a place in the spec that mentions declaring methods outside of their class scope?
jnthn And we didn't clone the multi that the class exported, and thus why it looked like it affectd the class.
Anonlymous ones yes, named ones I can't recall one. 10:35
But there are I think references to a class Main.
masak jnthn: should I report it as a bug saying that the Str.trim should still work?
jnthn has a fix for both a masakbug and an ilyabug
There's *something* wrong that your example reveals.
I'm not completely sure what it is yet.
masak me neither. 10:36
jnthn I'm pretty sure that you should not have been able to affect the Str class though.
masak I didn't! :)
jnthn We might be missing some cloning in the exported.
*in the exporter
masak hesitantly submits a rakudobug
jnthn Well, I mean that a method with a Str invocant declared out of class Str or not monkey-patched into it should not affect instances of Str. 10:37
I think that might be the real wtf here.
masak jnthn: aye. 10:38
feels like monkey-patching from the outside.
jnthn moritz_: In rt.perl.org/rt3/Ticket/Display.html?id=65238 you mention a t/spec/integration/packages.t but I can't find it?
masak -> store 10:39
jnthn moritz_: oh, I fail it, I didn't svn up
jnthn moritz_: ping 10:49
pugs_svn r26594 | jnthn++ | [t/spec] eval should eval things into the namespace of its caller; correct a test that assumed otherwise, and fails under the corrected behavior. 11:11
masak jnthn++
pugs_svn r26595 | jnthn++ | [t/spec] Unfudge a test for eval/namespaces. 11:12
jnthn That's two tickets. 11:13
(both masak++ and ihrd++ had reported it)
masak guess it bugged us both. :) 11:23
LylePerl is still working on Camelia and should have something ready for evaluation later today 12:19
pugs_svn r26596 | ron++ | added implicit topic match tests RT #61662 13:06
PerlJam rakudo: role R { has $.x is rw; } ; role S does R { } ; class C does S does R {} ; 13:18
p6eval rakudo 44e1ca: OUTPUT«A conflict occurred during role composition due to method 'x'.␤current instr.: '!meta_compose' pc -94773 ((unknown file):-1)␤» 13:18
PerlJam bug?
jnthn Yes. 13:21
Parrot and Rakudo have different ideas about roles composed from other roles. 13:22
erm, Parrot and Perl 6.
PerlJam ah, there's already a ticket for it too 13:25
Matt-W Hello! 13:41
jnthn hi, Matt-W 13:42
jnthn > say True 14:07
0
> say False
1
.oO( There's more than one way to screw it up... )
fridim_ oO 14:08
Matt-W hah 14:12
that's the shell programmer's true :)
jnthn :-) 14:13
We make it through the sanity tests now, which is nice. :-)
(With the re-write of enums that I'm working on.) 14:14
also class Foo does MyEnum { } and MyEnum.pick work.
Matt-W yay
jnthn Still got a bunch of functionality left to add in though.
Matt-W what's the status of using enums defined in other modules?
jnthn Didn't look at that just yet. 14:15
Nor export.
Matt-W okay
because I'm sure that behaviour changed recently
jnthn In the spec, or in Rakudo?
Matt-W In Form I seem to be able to say EnumName::value and get an enum defined in a module I'm using 14:16
whereas before I had to redefine the enum
neither seems right
in Rakudo
jnthn I think there's at least one ticket on such things.
Matt-W okay 14:20
I'll worry about it if it's weird after your enum rewrite anyway
LylePerl Ok, we've worked really hard on the logo 14:26
I think we've come up with something everyone will be happy with:-
www.perlportal.com/logo/4.png
LylePerl Thoughts on it? :) 14:28
jnthn lol :-)
...are the wings big enough to actually get the camel off the ground?
Matt-W hmm does the O'Reilly trademark cover winged camels?
jnthn When is a camel not a camel. :-) 14:29
LylePerl jnthn: yeah, they flap really fast :)
Matt-W I assume the camel has internal modifications to make it lighter
LylePerl TimToady said about a Camel with wings, maybe I could sell this to O'Reilly? 14:30
But seriously, here are the ones we've done:-
www.perlportal.com/logo/camelia.html
Camelia has never looked so good :) Actually we got her looking better than we initially thought we'd be able to ;) 14:31
LylePerl watches tumble weed blow past... 14:39
Matt-W oooh shiny camelia 14:41
LylePerl The posts pmichaud pointed me to said about Tux, so we tried to style her a bit more that way 14:43
jnthn quite likes some of the ones towards the bottom 14:44
5, 7 and 8 are perhaps my favorites
LylePerl I guess it all depends on whether TimToady likes it... 14:45
jnthn ('cus they better capture the colorfulness of the original suggestion, but are a bit simplified/sylistic)
Matt-W It doesn't really seem right to me though
pmichaud fwiw, there is no more "Main" 14:46
(from scrollback)
Matt-W as in module Main? 14:47
pmichaud correct.
Matt-W interesting
what is ther einstead
pmichaud It's now GLOBAL
or, more precicely, CORE::GLOBAL
LylePerl Matt-W: Not right in what way? 14:48
jnthn pmichaud: Is there a class GLOBAL or just a module?
pmichaud module, I think. 14:49
jnthn pmichaud: OK, so non-anonymous methods outside of a class/role/grammar probably ought to be an error. 14:50
pmichaud my first thought is "yes", but I'm never certain of such things :-) 14:53
jnthn pmichaud: You'll be glad to know that enum_declarator in actions.pm has taken a serious gutting. 14:54
pmichaud You're correct, I'm very glad to know that. :-)
jnthn As has enum.pir.
Which probably as a tenth as much code.
*has
pmichaud that feels more correct. 14:55
pugs_svn r26597 | jnthn++ | [t/spec] Reviewed an enums test; don't see anywhere in the spec that says you can cheat on enum values other than with the special cheating-allowed syntax, so correct the test in line with that. 14:56
jnthn Of course, the infamous guts.pir gets longer. ;-)
I notice a bunch of stuff got broken out into src/parrot/ too.
pmichaud that's okay, I prefer guts (once) to output of actions.pm (many) 14:57
(src/parrot/) yes, in order to help with .HLL mapping I decided we should break out the parrot hll stuff into its own section
jnthn Makes sense.
Our additions to Parrot's role.pir may not stand. 14:58
pmichaud and in some sense, src/parrot/ may end up being "well, we really oughtn't to be doing this... but here's where we're doing things outside our sandbox."
jnthn (Might well subclass it to add what we need.)
pmichaud IM IN YR HLL NAMESPACE, MESSIN WITH YR CLASSES AND ROLEZ
anyway, it was an attempt to reduce the number of .HLL directives to two. 14:59
pmichaud (one at the beginning, one to switch back to 'parrot') 14:59
jnthn Sure. Also it is good to know where we're messing with Parrot.
Or doing stuff that will have effects wider than just Rakudo. 15:00
pmichaud ah, looks like one of my YAPC::EU talks was accepted! :-) 15:01
jnthn Yeah, looks like one of mine too. :-) 15:02
pmichaud now I just have to figure out how to get there. :-| 15:04
jnthn doesn't recommend swimming 15:05
Matt-W yay! 15:08
Hire a boat and sail there
jnthn Both Portugal and Texas are coastal. Sounds feasible. :-) 15:18
pmichaud well, I'm a pretty good distance from the coast at the moment
500 km 15:19
jnthn "My state is SO big that..." 15:21
rakudo: say True.WHAT; say True.perl; say True.name; 15:22
p6eval rakudo 44e1ca: OUTPUT«()␤.new()␤Could not locate a method 'name' to invoke on class ''.␤current instr.: 'die' pc 16588 (src/builtins/control.pir:225)␤»
jnthn ...well at least we get those right in my local Rakudo...
pmichaud yay. 15:31
jnthn oh, interesting 15:32
> my $x = 0 but True; say $x; say $x.Bool; say $x.true; say ?$x;
0
1
0
lambdabot <no location info>: parse error on input `='
jnthn So if .true and .Bool are 1, wtf is ? not?! 15:33
pmichaud because it's still using the get_bool vtable, probably.
jnthn might try fixing that up later
pmichaud right now we don't attempt to intercept get_bool for the built-in types
like Str, Int, Num, etc. 15:34
jnthn It seems that whatever comes of the proposal from last night, anyway, .Bool is the thing that Really Decides.
Or at least part of it.
pmichaud until we decide that boolification/stringification need to be a step removed from .Bool/.Str
jnthn Sure. 15:35
Anyway, but True under current Rakudo explodes IIRC
rakudo: say 0 but True; say "alive"
oh yeah, it inf-loops. :-) 15:36
p6eval rakudo 44e1ca: ( no output )
jnthn oops.
So, improvement.
pmichaud yes, I'm very happy with an implementation that gets us closer to truth, even if we don't know what that truth is yet.
jnthn OK, let's see what I make of the spec tests for enums now.
omg I pass all of basic.t that passed before like, straight off... 15:37
And anonymous.t and as-role.t...
ah, thorough.t is a disaster. 15:38
pmichaud surprisingly, the Texas Gulf Coast is only 25 mi closer to El Paso than the California Pacific Coast :-) 15:39
jnthn !!
jnthn my $texas_area = 696241; my $slovakia_area = 49035; say "There are { $texas_area / $slovakia_area} Slovakias in Texas." 15:42
rakudo: my $texas_area = 696241; my $slovakia_area = 49035; say "There are { $texas_area / $slovakia_area} Slovakias in Texas."
p6eval rakudo 44e1ca: OUTPUT«There are 14.198857958601 Slovakias in Texas.␤»
jnthn rakudo: my $texas_area = 696241; my $vatican_area = 0.44; say "There are { $texas_area / $vatican_area} Vaticans in Texas." 15:43
p6eval rakudo 44e1ca: OUTPUT«There are 1582365.90909091 Vaticans in Texas.␤»
jnthn rakudo: my $popes = 1; my $vatican_area = 0.44; say "There are { $popes / $vatican_area } popes per square kilometer in the Vatican."
p6eval rakudo 44e1ca: OUTPUT«There are 2.27272727272727 popes per square kilometer in the Vatican.␤»
PhatEddy There is already an RT for the example below - I would just like to verify that an empty string and uninitialized value warning would be OK behavior (sorry no foreigners here) 15:45
rakudo: sprintf "%s"
p6eval rakudo 44e1ca: OUTPUT«Null PMC access in get_string()␤current instr.: 'parrot;Str;sprintf' pc 5137 (src/classes/Str.pir:87)␤»
PhatEddy empty returned string and warning OK? 15:46
pmichaud I would think it would return a Failure
PhatEddy OK 15:47
pmichaud which then becomes a warning if used.
jnthn rakudo: enum A <B C>; say A.perl
p6eval rakudo 44e1ca: OUTPUT«Null PMC access in get_string()␤current instr.: 'parrot;Role;Str' pc 3962 (src/classes/Role.pir:394)␤»
jnthn huh 15:48
Oh!
We weren't even running thorough.t
jnthn does make spectest 15:50
Ugh. Fail a bunch of Bool.t
PhatEddy pmichaud: just one second thought - in perl5 my $x = sprintf("%d"); with no int gives a warning right away 15:51
jnthn We have these tests: 15:52
isa_ok(Bool::True, Bool);
isa_ok(Bool::False, Bool);
I think isa is the wrong thing to be checking here.
Since enum elements are not instances.
I think the test should be more like Bool::True ~~ Bool 15:53
pmichaud PhatEddy: this is a somewhat fundamental difference between p6 and p5
PhatEddy OK
pmichaud where p5 would "warn immediately", p6 tends to return Failure objects that warn on use.
jnthn hears no disagreement and changes the tests. 15:55
pmichaud sorry, was delayed
I'd be surprised if Bool::True.isa(Bool) didn't work.
jnthn I don't see how it can. 15:56
isa tests inheritance relationships.
pmichaud I thought it tested type membership.
(too)
rakudo: say 3.isa(Int); 15:57
p6eval rakudo 44e1ca: OUTPUT«1␤»
jnthn I saw it as more "is an instance of X or something inheriting from it" 15:59
pmichaud sure. But most people tend to think of True,False as being instances of Bool
that might not be the case in Perl 6, but people will be surprised by that. 16:00
jnthn Most people should probably get used to using infix:<~~> when they aren't sure what specific test they want.
pmichaud It's not just that... the methods on Bool differ from a normal enum.
at least, I _think_ they differ.
jnthn Yeah apart from when the spec says they aren't. 16:01
S12 clear says enum Bool <False True>
And I'm pretty sure TimToady referred to it as an enum last night too.
pmichaud I wonder if that's actually a fossil. 16:02
hmmm.
okay, yes, it was referenced as an enum last night. 16:03
jnthn Oh, hmm 16:04
The other special thing is that True++ is meant to just stay as True.
(e.g. it defines .succ as a no-op)
pmichaud yes, that's one of the places wehre the method is different.
We also had (from last night): irclog.perlgeek.de/perl6/2009-04-30#i_1107870 16:05
jnthn That makes True a subset type.
pmichaud True is Bool where { 1 }
right.
which wouldn't be an enum.
jnthn Which you then went on to say
True isn't a type.
pmichaud I was talking specifically with respect to smart matching there 16:06
jnthn You can't have it be a type and not a type.
pmichaud True.
pmichaud But the fact that it was mentioned as a subset type means I'm not sure how strongly it's tied to being an enum. 16:07
jnthn I'd kinda like it to be an enum. But we can easily just do something custom.
pmichaud The ability to correctly handle .succ and .pred comes to mind.
jnthn But the moment I make this not an enum type, is where but True won't work again.
Unless I implement last night's additions to S14, that is. 16:08
pmichaud so, is this a question of test regression, or one of getting a correct implementation of Bool? (more)
jnthn (It hasn't worked before now, so it's not a problem...)
pmichaud ah. 16:09
jnthn Well, I fail tests now.
pmichaud To me, "but True" and "but 42" ought to be using the same mechanism.
jnthn Because by getting enums more correct, they don't fit Bool as well as they did.
OK, how about we try: (more) 16:10
1) We make Bool not be an enum in Rakudo, so it can keep its special behavior.
pmichaud at this stage, I think that having "but True" working is relatively less important than being able to properly perlify/stringify enum types
and being able to properly report .WHAT and .isa membership on True/False values.
jnthn .WHAT is fine. 16:11
It's .isa that's an issue.
pmichaud anyway, I'm in agreement with your (1)
jnthn I was going to say then 2) implement what was dded to S14 so we can see how it actually works out. 16:12
pmichaud I'm fine with that too as a testing measure to see how it works. My gut says it's not going to survive in its current form. 16:13
pmichaud (what was added to S14, that is) 16:13
jnthn No, but if it's going to change then co-ercion and perhaps other stuff will have to change as well.
pmichaud There's that also. Being able to coerce to a nested-package-type is an interesting question. 16:14
jnthn Well, all the mechanism in S14 is really doing is saying "this is how I coerce to this type"
So AFAICT the solution for that just mirrors the solution for coercion. 16:15
pmichaud sure.
jnthn $foo."X::Y" is valid syntax to call a method literally named X::Y
pmichaud anyway, based on what I've seen in rt reports and on-channel, the priority would be 16:16
jnthn Thing is that method X::Y() { } is not valid for declaring a method of that name.
pmichaud (1) stringification of enums and correct reporting of enum types
(2) .succ/.pred on Bool values
(3) getting "0 but True" to work
(in that order)
jnthn stringification of enums themselves, or their values?
Their values stringify just to the value. 16:17
.name and .perl are what were missing that I think people were interested in (and .WHAT too)
All of which I've got right now.
pmichaud so, in
enum Foo < alpha beta gamma > 16:18
stringifying beta would give "1" ?
jnthn Yes. 16:18
and beta.name would give beta
pmichaud Hmm. That doesn't match something I read before.
okay, I see that in the spec now. 16:19
jnthn For any enum value of an object type, the object itself knows its own
type, so the C<.perl> method will return its long name, while C<.name>
returns its short name. Other than that, number valued enums act
just like numbers, while string valued enums act just like strings.
pmichaud okay, excellent.
jnthn So provided that bit of the spec is right... :-)
pmichaud so assuming that True/False are enums: say True; # "1" 16:20
jnthn Yes, but we can't assume that any more. :-)
pmichaud well, even if they aren't enums, having ~True return "1" would still seem valid for now (i.e., until we hear otherwise)
jnthn Meh. Bool has flip-flopped between "enum" and "not an enum" so many itmes...
pmichaud anyway, yes, I was thinking of stringifying enums along the lines of .name and .perl (i.e., what people were interested in) 16:21
jnthn OK, then hopefully I make some people happy. :-) 16:22
pmichaud Definitely me.
rakudo: say "pmichaud \c[SMILE]"; 16:23
p6eval rakudo cc1c74: OUTPUT«pmichaud ⌣␤»
jnthn OK, so now we're back to Rakudo's Bool just being whats in Bool.pir
Bemusignly, enum.pir and what's in there were intereacting in the strangest of ways... 16:24
pmichaud Heh.
jnthn Which just happened to sort of work.
OK, we pass bool.t again now 16:26
jnthn spectests
jnthn My wrod we're close to 11,000 tests passing... 16:34
pmichaud lunchtime here -- bbiaw 16:36
literal @tell mberends sial.org/pbot/36310 16:55
lambdabot Consider it noted.
jnthn pmichaud: You'll like this: 16:58
7 files changed, 224 insertions(+), 442 deletions(-)
pugs_svn r26598 | jnthn++ | [t/spec] Unfudge some enums tests that we now pass; add a test for .WHAT on an enum value. 17:00
LylePerl wonders when TimToady will see the Camelia designs 17:14
the suspense is kill me :/ 17:15
skids So is "but Failure" going to work soon then? 17:23
jnthn That needs Failure to become a role. 17:26
japhb Is github riding the fail whale right now, or is it just me unable to pull? 17:30
pugs_svn r26599 | jnthn++ | [t/spec] Tweak and mostly fudge S12-enums/thorough.t. 17:32
pugs_svn r26600 | jnthn++ | [t/spec] Add test for RT#63878. 17:34
jnthn japhb: I pushed just a moment ago... 17:38
japhb jnthn: And I just tried again, and it worked fine. Sixth time is the charm, I guess .... 17:39
pmichaud do we need "but Failure"? 17:40
I guess we do if we want to return more interesting values of things.
converting Failure to be a role in Rakudo would be a Good Thing. I wonder if we could even get it into the Setting. 17:41
jnthn pmichaud: I'm not sure we need but Failure, but it would just automatically work.
(Once Failure became a role.) 17:42
pmichaud I'm might look into that this weekend.
s/I'm/I/
jnthn Cool 17:43
japhb jnthn: Since we're both here ... did you get 'constant foo is export' working this week?
jnthn japhb: Not yet, but the week hasn't yet ended. ;-)
japhb True!
jnthn japhb: The more I think about it though, the more I realize it's not completely trivial. 17:44
japhb holds out hope. :-)
jnthn Since Rakudo needs to know about the constant at compile time when importing it.
japhb OK ... how about an eval adverb that doesn't introduce a new scope?
I'll fake what I need that way. :-)
jnthn Heh, that'd be harder than fixing up the importer. :-P 17:45
pmichaud eval doesn't have a way to modify an existing scope. Parrot doesn't even allow it (with its current lexical implementation)
japhb awww
pugs_svn r26601 | ron++ | add tests for missing argument and %C format: RT #62316 and RT #60672
japhb *sigh*
jnthn We get away with importing subs now since we don't need to know about them at parse time. 17:46
pmichaud in fact, that's the reason why the REPL loop doesn't/can't easily remember lexically declared variables.
japhb ... which brings me back to textual include 17:47
pmichaud what do you need from constant that couldn't be done with, say, a package variable? 17:48
japhb pmichaud: I've got several thousand constants ... I'd like to have them resolved away to ints at compile time. 17:49
And FWIW, it takes a LONG time for Rakudo to parse those constants.
pmichaud japhb: afaik, that's not even happening now with our 'constant' declarator.
(it will eventually, yes, but I'm not sure it's happening at the moment.) 17:50
japhb pmichaud: jnthn was discussing that as a possibility for near-term work. And if he is going to work on that, I didn't want to write all my code twice.
pmichaud fair enough.
I'm not sure that resolving them to ints will provide much of a performance improvement, fwiw. 17:51
not even in the near term. 17:52
japhb Normally I wouldn't expect so ... but if I compile my code down to a .pbc, then at load time, Parrot won't be dealing with creating/managing thousands of events.
s/events/variables/
pmichaud yes, it still will.
in fact, it'll have to create more PMCs.
japhb ???
japhb Why? 17:52
pmichaud let's consider: constant $x = 3;
and: my $y = 4 + $x; 17:53
with constant replacement, rakudo will produce code that looks like
$P0 = 'infix:+'(4, 3)
when that gets executed, Parrot will create Int PMCs for both the 4 and the 3
japhb wha? 17:54
pmichaud to be passed along to 'infix:+'
japhb oh. I see.
pmichaud without constant replacement, rakudo will produce
japhb So basically, resolve to int does nothing without constant folding.
pmichaud $P0 = find_lex '$x'
pmichaud $P1 = 'infix:+'(4, $P0) 17:54
japhb And the '4' does not get promoted? 17:55
pmichaud in this case, Parrot will create the constant 3 for $x only once, and re-use that same PMC every time it's used in an expression (instead of creating a new one each time)
japhb Then the performance difference if any just comes down to find_lex versus box opcodes, yes? 17:56
pmichaud yes
pmichaud but find_lex will likely be much easier on the system than box, because we create far fewer gc-able objects. 17:56
japhb nodnod
Those were exactly what I was trying to avoid.
pmichaud so, at least as things stand now, simply resolving constant values at compile time may produce a performance loss instead of a win. 17:57
japhb That ... bites.
pmichaud when we do a lot more advanced analysis, such as constant folding, or providing specialized versions of common methods that don't involve the autoboxing, we might get some improvements. 17:58
japhb nod
japhb For some reason I thought constant folding was already a done deal. 17:58
jnthn constant is not going to be any more efficient right now.
japhb And I didn't even think of the case that 3 + 4 would involve two box ops.
jnthn In the long run, I'd hope it won't.
japhb jnthn: nod. But at least the syntax and semantics are better. 17:59
jnthn (We'd fold it at compile time.)
constant is your way of saying to a future Rakudo, what it can optimize.
pmichaud (we fold at compile time if we can determine that there's not a custom infix:<+> that is in scope)
japhb pmichaud: 'we will' or 'we already do' 18:00
?
pmichaud we will.
japhb ah, gotcha.
pmichaud we don't do much in the way of optimization at the moment.
we're still just getting all of the mmd stuff in place.
(jnthn++ for that)
jnthn pmichaud: note that writing a my multi infix:<+>(Int, Int) is only going to get you a conflict.
erm, ambiguous dispatch
Since there already is one. 18:01
(We clone the outer/existing set of candidates and add our new ones)
pmichaud jnthn: but there could be a sub infix:<+>(Any, Any)
(non-multi)
jnthn Oh, yes, that's true.
my sub, but yes.
jnthn is happy with the number of enum related tickets he's being able to close, or to assign to moritz for spectests 18:04
pmichaud me too.
PhatEddy just saw the em about :Trig and noticed that t/spec/S32-trig/trig.t and t/spec/S32-num/exp.t 'use Num :Trig' 18:07
jnthn PhatEddy: In that case I think the ticket is well and truly closeable. 18:08
pmichaud PhatEddy++ # keeping up with RT
jnthn PhatEddy: Do you have privs to do it, or shall I?
PhatEddy I don't have such privs as of now. 18:09
jnthn resolved - thanks :-) 18:10
masak today truly is enum fixing day. 18:12
maybe after this, I'll start using enums in my programs.
jnthn Yeah, I realized just how many tickets we had relating to them.
masak rakudo: enum Rakudo <good cool awesome bad ugly weird>; say Rakudo.pick 18:14
p6eval rakudo f934db: OUTPUT«3␤»
masak rakudo: enum Rakudo <good cool awesome bad ugly weird>; say Rakudo.pick.perl
jnthn :-)
p6eval rakudo f934db: OUTPUT«[Rakudo::weird]␤»
masak :P
jnthn Well done Rakudo. :-)
masak still werid, Rakudo.
jnthn Normality is way overrated.
masak s/ri/ir/
aye, sooth.
rakudo: say <<:a(1)>>.perl 18:16
p6eval rakudo f934db: OUTPUT«":a(1)"␤»
masak reports rakudobug 18:17
jnthn I wondered how long that would take. :-)
masak it's a dirtly job, but somebody's gotta do it. 18:18
wohoo, ranges of enums! jnthn++
pugs_svn r26602 | jnthn++ | [t/spec] Tests for enum (i => 1, v => 5...) style stuff. 18:19
jnthn rakudo: rakudo: enum A <a b>; say (a < *).WHAT 18:20
p6eval rakudo f934db: OUTPUT«Statement not terminated properly at line 1, near ": enum A <"␤␤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)␤»
TimToady my multi is supposed to hide an outer multi of the same longname, not conflict
jnthn TimToady: ah, that's a pain.
TimToady it's specced 18:21
jnthn It's still a pain. :-P
rakudo: enum A <a b>; say (a < *).WHAT
p6eval rakudo f934db: OUTPUT«Block()␤»
jnthn rakudo: enum A <a b>; say (a < *).(-1) 18:22
p6eval rakudo f934db: OUTPUT«0␤»
jnthn rakudo: enum A <a b>; say (a < *).(2)
p6eval rakudo f934db: OUTPUT«1␤»
jnthn rakudo: 1 < *
p6eval rakudo f934db: ( no output )
jnthn rakudo: enum A <a b>; a < *
p6eval rakudo f934db: ( no output ) 18:23
jnthn OK, I think 63880 is ok
masak rakudo: say (*).perl
p6eval rakudo f934db: OUTPUT«!whatever_dispatch_helper␤»
masak !
how long did you expect to hide that one from me? :P
jnthn Damm! 18:24
masak now I really caught you out.
jnthn rakudo: enum A <a b>; say a < * # why you htink I didn't try this one ;-)
p6eval rakudo f934db: OUTPUT«!whatever_helper_right␤»
masak right. 18:25
whatever.
jnthn What should a block stringify to anyways?
masak its contents?
TimToady LylePerl: the 2nd camelia with rounded line is nice, though loses some of the woggliness that is bit charming. also, you lost the asymmetric smile, which is a no-no
jnthn masak: that's .perl 18:26
rakudo: sub foo { }; say &foo
p6eval rakudo f934db: OUTPUT«foo␤»
jnthn rakudo: my $x = { }; say $x;
masak jnthn: well, I did do (*).perl
p6eval rakudo f934db: OUTPUT«␤»
TimToady the rest of them seem to be devolution to the forms that camelia went through to get where she is; she used to have a face more like a smiley, and the bugout eyes and asymmetric smile were added to get away from ☻
jnthn masak: I'm not sure if *.perl and (*).perl are different... 18:27
TimToady and frankly, I think the latter ones would look scary to a kid
masak jnthn: I think they might be. 18:28
jnthn: the former is like *.uc, no?
jnthn Yeah, but we're currently treating the seoncd one like that too...
masak ok.
jnthn We're not doing it syntacticly.
pmichaud iirc, method dispatch on Whatever is what creates the closure.
jnthn Right.
masak jnthn: I see your point now. 18:29
pmichaud however, it does result in odd things with something like *.Str.perl
because that ends up meaning { $_.Str }.perl
which of course is different from $_.Str.perl 18:30
masak rakudo: say (*).WHAT.substr(0,-2).subst(/....$/,{"-{.uc}."})
p6eval rakudo f934db: OUTPUT«What-EVER.␤»
TimToady maybe there needs to be a type that is both Whatever and Closure
jnthn pmichaud: Part of me wonders if rather than *.perl => { $_.perl } we want *.perl => * but role { postcircumfix:<( )> { $_.perl } } or similar.
So then they just stack up around it. 18:31
TimToady yes, but we have to be able to distinguish bare Whatever from Whatever{block}
maybe it's a WHENCE :)
jnthn TimToady: Why?
TimToady @foo[*] vs @foo[*-1]
lambdabot Unknown command, try @list
jnthn Ah, true. 18:32
WhateverClosure
or whatever
:-)
The alternative (which I don't like much) is that *.foo.bar chains become a special syntactic form.
TimToady Blotever
don't like that either
jnthn Good. :-)
TimToady the particular problem with turning into Closure/Block is that not all methods are ignorant of that data type 18:33
like .perl, though it may barf
but expectation is that {...}.perl reproduces the block 18:34
and doubtless Code has other methods that it recognizes
{...}.arity .count etc
so what does *.foo.arity mean then? 18:35
even if we have Blockever, do we dispatch to Whatever or to Code?
or is it a Code that isa Whatever, so it just dwims mostly 18:36
jnthn Blockever is Whatever is Code 18:37
Perhaps
TimToady no, then *.foo.arity defaults to { $_.foo.arity }, which is probably not intended
probably meant {$_.foo}.arity in that case
so Blockever is Code is Whatever is what I was thinking 18:38
and it hits Whatever only if no .arity, .count, etc
I dunno, it's another DIHWIDT
maybe I should talk about doctors this year at oscon 18:39
"first of all do no harm", and all that :)
but I suppose I can argue it the other way too, and *.foo just adds in .() responder, as jnthn suggested 18:41
as long as it's also distinguishable by type
jnthn Defaulting to { $_.foo.arity } feels OK to me...
TimToady yes, avoids a non-linearity 18:41
TimToady maybe it's a Codever 18:42
jnthn if any(map *.hanldler.arity, @thingies) == $wanted { }
TimToady not to be confused with Codliver
or Cadaver
ZuLuuuuuu Hi folks, I wrote an article to an online Turkish magazine to introduce Perl 6 to Turkish programmers :) e-bergi.com/2009/Mayis/Gelisim-Sure...Yenilikler (This is part 1, part 2 will be published next month.) 18:44
masak ZuLuuuuuu: looks nice. 18:46
TimToady Perhaps this is not a time to confess that I know Greek better than Turkish :)
ZuLuuuuuu :)
thanks, we share a lot of words between Greek and Turkish actually :D
TimToady as for my picture, that's about as Turkish as I ever look. :) 18:47
I assume it has something about flying mugs, since Jon's picture is in there :)
ZuLuuuuuu yes actually your mustaches makes you look as a typical Turkish guy :)
TimToady though the shirt looks like I came out of a harem :) 18:48
ZuLuuuuuu Yes, the article starts with the story how the whole Perl 6 project started (includes the mug story too) then continues with the installation of Parrot and Rakudo and starts giving the differences of Perl 5 and Perl 6 18:49
ZuLuuuuuu Yes, the article starts with the story how the whole Perl 6 project started (includes the mug story too) then continues with the installation of Parrot and Rakudo and starts giving the differences of Perl 5 and Perl 6 18:50
part 1 mentiones about the arguably small differeces
TimToady looks pretty clean; I didn't notice any typos :)
ZuLuuuuuu part 2 will mention about smart matching rules grammers hyper operators 18:51
TimToady and it makes it look like the Unicode handling is natural 18:51
ZuLuuuuuu :D 18:52
ZuLuuuuuu :) yes, actually the examples including Turkish characters aren't displayed correctly on terminal :) 18:52
masak rakudo: say 'yılına'.uc
p6eval rakudo f934db: OUTPUT«Y 18:52
masak hm, partial output? 18:53
pmichaud I call p6eval bug. Or Parrot bug.
ZuLuuuuuu I got funny letters instead
masak pmichaud: nod.
pmichaud or even irc bug. :-)
masak investigates locally
pmichaud $ cat x 18:54
say 'yılına'.uc
$ ./perl6 x
YILINA
masak good.
ZuLuuuuuu wow it is correct
masak got 'no ICU lib loaded' locally
ZuLuuuuuu say 'ışığa'.uc
perl6: say 'ışığa'.uc
p6eval rakudo f934db: OUTPUT«I 18:55
..elf 26602, pugs: OUTPUT«IŞIĞA␤»
ZuLuuuuuu perl6: say 'ışığa'.uc;
pmichaud say 'ışığa'.uc
$ ./perl6 y
I^$
my font doesn't know what to do there.
p6eval rakudo f934db: OUTPUT«I
..elf 26602, pugs: OUTPUT«IŞIĞA␤»
ZuLuuuuuu ğugs gives correct result
pugs
pmichaud oh, ouch... rakudo on my system is outputting ucs2 for that one. 18:56
LylePerl TimToady: notes taken, we'll make adjustments and get back
pmichaud I wonder if rakudo should generally default its output to utf8. 18:57
I wonder if Parrot even lets me do that.
ZuLuuuuuu you would make us very happy utf-8 would be default everywhere possible :) 18:58
pmichaud experiments. 19:00
pmichaud Parrot's .uc changes string encoding: nopaste.snit.ch/16466 19:02
TimToady parrot has tended to fall into the ruby mindset that any character set is as good as any other :/ 19:04
apparently it feels that way about encodings too...
pmichaud well, I don't mind too much if Parrot changes the encoding to ucs2 here -- that's a bit faster at any rate -- but we do want it to be utf8 on output, I suspect. 19:05
TimToady we want I/O to be *well typed* 19:06
but for the western world, utf-8 is a pretty good default 19:07
far east may well prefer utf-16 for their default
TimToady but we can't have I/O handles just guessing 19:08
yari hi all, I'm a p6 beginner, looking at some of the emails on perl6-compiler about enums, with a beginner q- 19:10
given something like "enum Muses <Calliope Clio Erato Euterpe etc>"
TimToady waits... 19:11
yari can one ask the type of "Clio" - or another enum- and get back a string saying "Muses"
I don't know why I'd want to, just want to know if / how
pmichaud rakudo: enum Muses <Calliope Clio Erato Euterpe>; say Clio.WHAT
p6eval rakudo f934db: OUTPUT«Muses␤»
pmichaud wonders if that should have parens. 19:12
jnthn pmichaud: Yeah
pmichaud: It's not just enums, its any role.
pmichaud: On my todo list.
yari On my local build, that says "()" without the "Muses"
TimToady Clio is supposed to end up an immutable value of class/role Muses
jnthn TimToady: That *does* role Muses, no? 19:13
It's base type is Int in this case.
pmichaud yari: the changes to enums were just made a few hours ago -- have you recently updated? 19:13
jnthn Well, ish. :-) 19:14
pmichaud yari: you might also need to "make realclean; perl Configure.pl --gen-parrot" to get the correct version of parrot.
yari it was pretty recent (this morn) but I can try again, who knows who won that race!
TimToady Why shouldn't the type be Muses? it just num/strifies to 1
TimToady if the object is not well typed, how is $x.name supposed to work? 19:14
yari yup src/builtins/enums.pir was out of date here, rebuilding 19:15
jnthn TimToady: The spec says:
For any enum value of an object type, the object itself knows its own
type, so the C<.perl> method will return its long name, while C<.name>
returns its short name. Other than that, number valued enums act
just like numbers, while string valued enums act just like strings.
jnthn If they're going to act like numbers and strings, they'd best just be numbers/strings. 19:15
With enum-ness mixed in.
TimToady doesn't folow
*follow
jnthn I went down the other road with the previous implementation and it was a Bad Idea.
TimToady they act like numbers or strings only when *asked* to act like numbers or strings 19:16
they're still objects, albeit immutable
jnthn So are numbers and strings... 19:16
rakudo: enum Day <Mon Tue Wed>; multi x(Int $x) { say "ok" }; x(Mon) 19:17
p6eval rakudo f934db: OUTPUT«ok␤»
jnthn rakudo: enum Day <Mon Tue Wed>; multi x(Day $x) { say "ok" }; x(Mon)
p6eval rakudo f934db: OUTPUT«ok␤»
TimToady now put both
jnthn rakudo: enum Day <Mon Tue Wed>; multi x(Day $x) { say "ok 1" }; multi x(Int $x) { say "ok 2" }; x(Mon) 19:18
p6eval rakudo f934db: OUTPUT«ok 2␤»
TimToady is wrong
pmichaud rakudo: say Day ~~ Int
p6eval rakudo f934db: OUTPUT«Could not find non-existent sub Day␤current instr.: '_block14' pc 79 (EVAL_16:51)␤»
jnthn rakodu: say Day ~~ Int; say Int ~~ Day;
pmichaud rakudo: enum Day <Mon Tue Wed>; say Day ~~ Int
p6eval rakudo f934db: OUTPUT«0␤»
jnthn rakudo: enum Day <Mon Tue Wed>; say Int ~~ Day 19:19
p6eval rakudo f934db: OUTPUT«0␤»
jnthn wtf? Thsoe two candidates shoudl be tied then...
OH
It's becasue of a bug i'm still working on. 19:20
pmichaud naively I would expect Day.does(Int) ... is that correct?
TimToady I think we should make it correct
jnthn rakudo: enum Day <Mon Tue Wed>; say Mon ~~ Day
p6eval rakudo f934db: OUTPUT«1␤»
TimToady since everyone else will expect it too
pmichaud in that case, naively I would think that Day is Int :-)
jnthn That can be done, and yes, it would resolve teh ambiguity.
rakudo: enum Day <Mon Tue Wed>; say Mon ~~ Int 19:21
p6eval rakudo f934db: OUTPUT«1␤»
jnthn I'm still not getting why the dispatch wasn't ambig... :-S
pmichaud rakudo: say Day.ACCEPTS(Int);
p6eval rakudo f934db: OUTPUT«Could not find non-existent sub Day␤current instr.: '_block14' pc 53 (EVAL_16:43)␤»
pmichaud rakudo: enum Day <Mon Tue Wed> ;say Day.ACCEPTS(Int); 19:22
p6eval rakudo f934db: OUTPUT«1␤»
pmichaud rakudo: enum Day <Mon Tue Wed>; say Day.ACCEPTS(Int); say Day ~~ Int;
p6eval rakudo f934db: OUTPUT«1␤0␤»
pmichaud that's why.
TimToady those are backwards
pmichaud yes, just noticed that.
jnthn rakudo: enum Day <Mon Tue Wed>; say Int ~~ Day; 19:23
p6eval rakudo f934db: OUTPUT«0␤»
pmichaud rakudo: enum Day <Mon Tue Wed>; say Int.ACCEPTS(Day); say Day ~~ Int; 19:23
jnthn rakudo: enum Day <Mon Tue Wed>; say Day ~~ Int;
p6eval rakudo f934db: OUTPUT«0␤0␤»
rakudo f934db: OUTPUT«0␤»
pmichaud rakudo: enum Day <Mon Tue Wed>; say Day.ACCEPTS(Int); say Int ~~ Day;
p6eval rakudo f934db: OUTPUT«1␤0␤»
TimToady I think we've got some confusion here between manifest types and storage types, but I'll need to think on it over lunch 19:24
PerlJam Do Str-based enums work in rakudo?
jnthn pmichaud: Those two should certianly give the same answer...
pmichaud: Yes, should do.
TimToady A storage type cannot be a constrained type, but the known type of the object stored there might be more constrained than the storage type
PerlJam (and presumably they'll does(Str) instead of Int)
jnthn Yes. 19:25
pmichaud jnthn: I suspect that ~~ Day isn't dispatching as a protoobject/type check.
jnthn pmichaud: Something like that.
pmichaud rakudo: enum Day <Mon Tue Wed>; say Day.PARROT;
p6eval rakudo f934db: OUTPUT«␤»
pmichaud rakudo: enum Day <Mon Tue Wed>; say Day.WHAT;
p6eval rakudo f934db: OUTPUT«Day␤»
masak literal: the problem is in your script. you're trying to index a variable $*ARGV, which isn't defined.
TimToady that is, despite being a constrained type of Int, Day is also a valid object type, I think
masak literal: it's @*ARGS in Perl 6. 19:26
TimToady not sure what Liskov would say about it though... :)
masak TimToady: speaking of Liskov... 19:27
TimToady rakudo: enum Day <Mon Tue Wed>; say 42 ~~ Day
masak TimToady: how do you feel about monkeyless monkeypatching?
p6eval rakudo f934db: OUTPUT«0␤»
TimToady rakudo: enum Day <Mon Tue Wed>; say 2 ~~ Day
p6eval rakudo f934db: OUTPUT«0␤»
TimToady hmm
literal masak: oh, heh
TimToady rakudo: enum Day <Mon Tue Wed>; say Tue ~~ Day
jnthn TimToady: I figured that one is correct?
p6eval rakudo f934db: OUTPUT«1␤»
jnthn TimToady: Since S12 explicitly mentions a special form to use to "cheat". 19:28
masak TimToady: or maybe, this question first: can methods be declared outside of their class declaration?
named methods, that is.
TimToady well, but ~~ is about pattern match, and what does it mean for Day to accept an integer?
jnthn TimToady: I also have... 19:29
pmichaud rakudo: my Day $x; $x = 2;
p6eval rakudo f934db: OUTPUT«Malformed declaration at line 1, near "Day $x; $"␤␤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)␤»
pmichaud rakudo: enum Day <Mon Tue Wed>; my Day $x; $x = 2; say $x;
p6eval rakudo f934db: OUTPUT«Type mismatch in assignment; expected something matching type Day but got something of type Int()␤current instr.: 'die' pc 16609 (src/builtins/control.pir:225)␤»
jnthn rakudo: enum Day <Mon Tue Wed>; class Foo does Day { }; my $x = Foo.new; $x.Day = Wed; say "ok"; $x.Day = 2;
p6eval rakudo f934db: OUTPUT«ok␤Type mismatch in assignment; expected something matching type Day[] but got something of type Int()␤current instr.: 'die' pc 16609 (src/builtins/control.pir:225)␤»
TimToady masak: yes, but if they're not installed anywhere a dispatcher looks, they probably warrant a warning
jnthn That is, you can't just throw something that happens to be the thing an enum value numifies to and treat it as if it's the enum vlaue itself. 19:30
literal masak: heh, now I get an error about prefix:<=> being deprecated
masak TimToady: I'm thinking something like 'method foo(Subtype $self:) {...}'. does that constitute being installed somewhere a dispatcher looks?
literal oh well
masak literal: that might indeed be Pod::Parser. 19:31
literal yep
masak literal: I'll give it a try over here.
I can probably fix it for you.
pmichaud afk, gotta pick up kid from school.
masak literal: oh, and also, that'd be @*ARGS[0], I think. 19:32
TimToady rakudo: subset Pos of Int where * > 0; say 42 ~~ Pos
p6eval rakudo f934db: OUTPUT«1␤»
masak Rakudo++
TimToady the question is whether you mean Day as an object type or as a constraint when you say ~~ 19:33
if a constraint, 2 ~~ Day should match
but enums are in an uncomfy position
lunch & # thinking
jnthn S12 says "An enum is a low-level class that can function as a role or property.
"
Right off.
dalek kudo: e33c004 | jnthn++ | src/builtins/guts.pir:
Implement smart-matching on enum values.
19:34
jnthn yay dalek is back
I can haz karmaz.
Infinoid jnthn++
masak dalek: welcome back, bot. 19:35
Infinoid (problem was missing CPAN module on feather)
masak Infinoid++ 19:37
pugs_svn r26603 | jnthn++ | [t/spec] Unfudge tests for smart-match on enum values, and add explicit tests for given/when. 19:39
masak literal: try now. 19:42
pugs_svn r26604 | jnthn++ | [t/spec] Unfudge a couple more smart-match and enum tests.
jnthn -> diiner, back soon 19:44
literal masak: I get this now -> sial.org/pbot/36315 19:51
but I gotta go
masak ok.
literal ignore that S26... on the command line, of course...
masak literal: thing is, I tried it over here, and it worked. 19:52
literal: not sure I'll be able to reproduce your error.
literal ok
masak literal: are you running latest Rakudo and perl6-examples?
literal not the latest Rakudo, but from 2 days ago or so
I'll try again later with the latest
masak sounds good. 19:53
PhatEddy Hi - I'm looking at an open RT about someone's broken spectests one day with few details. Can I sort of say as policy that there is reason for an RT unless spectests are broken for 2-3 days? 20:04
s/is reason/is no reason/
masak PhatEddy: I think the overriding reason should be something like whether the ticket has an observable that can be fixed. 20:05
jnthn back from nom 20:08
pmichaud In general, if a spectest is broken on a platform (and only one person observes it), we should ask for more details about the reporter's configuration and setup (and ask them to verify again with an up-to-date build). 20:11
if no response after a few days, okay to close the ticket.
jnthn I'm going to leave a couple of the enums tickets for now...but most of them are now resolved. :-) 20:20
PerlJam jnthn++
PhatEddy Just to note that Bool.succ (RT #64366) has a ready and waiting patch ... 20:25
jnthn rakudo: my Bool $t; $t = Bool::True; print $t.succ 20:27
p6eval rakudo e33c00: OUTPUT«Null PMC access in isa()␤current instr.: 'parrot;List;!flatten' pc 6724 (src/classes/List.pir:215)␤»
pmichaud the patch in 64366 is backwards.
pmichaud it's defining pred/succ in terms of --/++, when it should be the other way around. 20:28
jnthn I don't quite get why it adds to succ and pred to the setting and has them in PIR too?
pmichaud I suspect they were trying to keep the vtable version as well.
jnthn ah
pmichaud at any rate, rejecting patch.
PhatEddy It takes them out of pir and moves them to setting
why backwards? 20:29
pmichaud yes, but it's not completely taking them out of pir -- it's keeping a version in PIR as well.
masak would like to upvote rt.perl.org/rt3/Ticket/Display.html?id=64388
PhatEddy PIR still needs increment and decrement
pmichaud it does? why? 20:30
jnthn masak: Ah yes, the whole BUILD fun...
PhatEddy because they are not the same as int
increment sets to 1 and decrement sets to 0
masak jnthn: it's not terribly urgent, it's just that it'd remove a lot of .init workarounds...
pmichaud PhatEddy: we don't use increment/decrement 20:31
PhatEddy rakudo: my Bool $t; $t = Bool::True; say ++$t
p6eval rakudo e33c00: OUTPUT«1␤»
PhatEddy rakudo: my Bool $t; $t = Bool::True; say --$t
p6eval rakudo e33c00: OUTPUT«0␤»
pmichaud okay, I misspoke.
Our current implementation of increment and decrement is wrong.
PhatEddy That may be ... 20:32
pmichaud at any rate, increment/decrement should be defined in terms of .succ and .pred 20:33
PhatEddy That is not true of Str and Int which base succ and pred on inc/dec the same way ... 20:34
pmichaud as I said, our current implementation of increment and decrement is wrong.
they're from before there was clarification / definition of .succ and .pred
in the spec 20:35
PhatEddy Sorry - did my best but based my implementation of bool on the other types ... 20:35
pmichaud sure, makes sense. 20:36
I would've done the same lacking knowledge of other things going on :-)
I'm not intending to criticize the patch effort at all (and I'm failing in that, so my apologies) 20:37
PhatEddy no prob - it finally needs to be implemented some right way ... 20:38
pmichaud yes, the current implementation of Bool.pir is definitely wrong also. 20:38
pmichaud I think I need to switch back to 32 bit linux... 64 bit seems so slow in several respects :-| 20:40
jnthn moves max to the setting so 58948 can be resolved at long last 20:51
pmichaud \o/ 20:52
jnthn Also got a patch to add () to end of roles when stringified. 20:53
pmichaud running spectest is taking waaaaay too long on my 64 bit box here. 20:54
so I think I definitely will move it back to 32 bit.
jnthn No no, stay there, it's an incentive to make Rakudo faster! ;-) 20:57
PerlJam It's the parsing that needs speed and that's not really rakudo's fault. 20:58
pmichaud I don't think it's just parsing anymore.
(that is slowing things down)
granted, the parser remains slow..
jnthn It's not, but it can dominate.
Consider assign.t 20:59
PerlJam I was showing someone something in rakudo earlier and the first line of execution printed "started". There was a noticably huge delay from when I hit enter to run the thing and when it output "started"
pmichaud PerlJam: that's not necessarily just parsing. There's also a _lot_ of initialization taking place now.
and every sub we add to the setting increases startup time. 21:00
PerlJam true.
pmichaud and every metaoperator we add increases the time needed to initialize the parser itself. 21:00
jnthn That should change once we parse them the STD.pm way though, no? 21:01
pmichaud the metaoperator cost? Perhaps.
but we still incur an extra cost in parsing that we don't have now, depending on how much LTM caching we can do.
jnthn The init will be a big area to try and optimize though.
I'm quite hopeful that I'm going to have method dispatch running a good bit faster next month. 21:02
erm,
this month
It's already May. 21:03
PerlJam jnthn: still doing rakudo day once a week? or will that change?
jnthn PerlJam: That and hopefully news.perlfoundation.org/2009/04/hag...t_tra.html 21:04
I've found myself with relativekly little work in May, which is a month I'd planned to not travel or have any conferences, but work.
So, filed a grant app that hopefully gets approved...
PerlJam Ah, D4 was something I was wondering about earlier today. 21:05
jnthn Anyway, in the process of doing D1 I'm planning a reasonbly big refactor. 21:06
I want to try and straighten out our story on custom meta-classes and alternative representations. 21:07
PerlJam you know how git gives you the + and - for a given file? It always makes me smile a little when the number of + is small while the number of - is large.
jnthn :-) 21:08
If actions.pm has a lot of -, blame me. :-)
PerlJam implementation trumps no implementation, so even if it's bloated and ugly, it's good. the more - than + in actions.pm is just a sign of refactoring and that's always good (because we still have stuff that works, only better :) 21:09
jnthn Sure. enums really needed an extensive refactor. 21:11
Even if the new implementation ain't perfect, it gets a lot of things right that we got wrong before.
And with well under 2/3 the number of lines of code. 21:12
jeremiah_ OHAI jnthn
How is everything?
Artemis says hi.
dalek kudo: e637cef | pmichaud++ | src/builtins/globals.pir:
Get $*IN, $*OUT, $*ERR to default to utf8 encodings.
jeremiah_ Or rather miao.
jnthn jeremiah_: OH HAI! 21:13
And hi to Artemis :-)
Things are pretty good here...how about up in Gothenburg? 21:14
jeremiah_ I am at our summer place where it is nice and warm. :) 21:18
How is life in Bratislava?
jnthn Nice, and warm also, but thankfully not too hot (yet). Was a national holiday here today...big fireworks show. 21:19
Could see it right from where I live. :-)
jeremiah_ Oh cool. 21:20
Yesterday was the Kings birthday here.
jeremiah_ No fireworks. 21:20
Swedes try and keep it on the 'lowdown'
as it were.
jnthn :-) 21:21
masak jeremiah_: most Swedes here were busy getting extremely drunk. no time for fireworks. 21:22
jnthn I was about to say. Just a few quiet bottles from the systemstore, but no fireworks. :-)
masak "a few"? :) 21:23
jnthn I didn't say they were bottles of beer. ;-)
jeremiah_ masak: Well, that is more Valborg then Kings birthday. :-) 21:25
s/then/than/
The System!
masak is no great fan of the current interpretation of Walpurgis night
jeremiah_ Systembologet.
masak: Yeah, when did it turn into a mass alcoholic reverie? 21:26
jnthn jeremiah_: That's the word I couldn't remember. :-)
masak the one day of the year when the words "get off my lawn!" are not a joke.
jeremiah_ heh 21:27
jeremiah_ But in Sweden, we have allemansratt 21:27
Of course it is spelled slightly differently.
But it is like Germany - you can walk wherever you chose, as long as you lock the gate after you. 21:28
masak ran spectests. two TODO passed in t/spec/S12-class/basic.rakudo -- do I unfudge them? 21:29
jnthn masak: I've been seeing two unexpected passes there too, I don't quite know what they are. 21:30
masak they are tests 30 and 31. :)
pugs_svn r26605 | jnthn++ | [t/spec] Roles now have () on the end of their stringification, as type objects do. 21:31
masak rakudo: class A { eval 'method x { say "OH HAI" }' }; say "alive" 21:32
p6eval rakudo e637ce: OUTPUT«alive␤»
masak closes [perl #61354] 21:33
jnthn w00t
masak: teste?
*tested?
masak jnthn: well, that was the TODO'd tests that passed here...
dalek kudo: 5035385 | jnthn++ | src/classes/Role.pir:
.WHAT on roles should stringify to something with () on the end.
kudo: 44c4879 | jnthn++ | src/ (2 files):
Move max to the setting.
jnthn masak: oh cool
masak jnthn: I'll unfudge them after I close the RT ticket.
jnthn that's fine 21:34
PhatEddy masak: I put in the tests for 61354 relatively recently ... they might be rewritten a bit now that they don't "crash"
masak PhatEddy: well, the RT ticket is clearly fixed, so no problem.
jnthn Woo, 58948 is closed. :-) 21:35
We're down to 319 tickets. 21:36
jnthn remembers the days when he could keep it down at 150.
PhatEddy fudged test for 58948 in t/spec/S06-multi/syntax.t 21:37
jnthn masak: On the BUILD/BUILDALL stuff, I plan to take care of it during my various other planned refactors on object stuff.
masak jnthn: ok. 21:38
masak likes that it's in the schedule somewhere
jnthn rakudo: say (1..10).min: { ($_-3) * ($_-5) }; 21:42
p6eval rakudo e637ce: OUTPUT«too many arguments passed (2) - at most 1 params expected␤current instr.: '_block23' pc 113 (EVAL_20:59)␤»
jnthn rakudo: say (1..10).min 21:43
p6eval rakudo e637ce: OUTPUT«1␤»
jnthn rakudo: say (1..10).list.min: { ($_-3) * ($_-5) };
pugs_svn r26606 | masak++ | [t/spec/S12-class/basic.t] unfudged two tests that now pass in Rakudo
p6eval rakudo e637ce: OUTPUT«too many arguments passed (2) - at most 1 params expected␤current instr.: '_block24' pc 125 (EVAL_20:60)␤»
jnthn rakudo: my @a = 1,2,3,4; my @a.min: { ($_-3) * ($_-5) }; 21:44
p6eval rakudo e637ce: OUTPUT«Redeclaration of variable @a␤Statement not terminated properly at line 1, near ".min: { ($"␤␤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:86)␤»
jnthn rakudo: my @a = 1,2,3,4; say @a.min: { ($_-3) * ($_-5) };
p6eval rakudo e637ce: OUTPUT«too many arguments passed (2) - at most 1 params expected␤current instr.: '_block27' pc 144 (EVAL_20:67)␤»
masak jnthn: that colon syntax doesn't work with arrays, unfortunately...
jnthn rakudo: my @a = 1,2,3,4; say @a.min({ ($_-3) * ($_-5) });
p6eval rakudo e637ce: OUTPUT«too many arguments passed (2) - at most 1 params expected␤current instr.: '_block27' pc 144 (EVAL_19:67)␤»
jnthn rakudo: my @a = 1,2,3,4; say @a.min(); 21:45
masak jnthn: there's an RT ticket about it.
p6eval rakudo e637ce: OUTPUT«1␤»
jnthn Yeah, I know 21:46
I'm looking at rt.perl.org/rt3/Ticket/Display.html?id=62742
Thing is, min and max are defined as taking such a code parameter...
multi method min( $values: Code $by = sub { $^a cmp $^b } ) { 21:47
Oh! 21:48
It's because that's an arity 1 block.
And it expects a comparator.
(e.g. arity 2) 21:50
masak aha.
pmichaud it should probably use the same logic that .sort is using.
masak aye, .min and .max being narrow special cases of .sort 21:53
jnthn pmichaud: aye 21:54
pmichaud: The ticket says as much, and claims S29 says so too.
ah well, it's an easy addition.
pugs_svn r26607 | ron++ | simplify/streamline testing for now fixed RT #61354 22:01
jnthn thinks we must be getting close to the 11,000 point. 22:19
PhatEddy If anyone is interested to ask, I think I know of about 5 tickets that may be closeable without coding ... 22:22
jnthn Nice 22:23
masak rakudo: sub foo(%bar) {}; foo( -> {} ) 22:24
p6eval rakudo 44c487: OUTPUT«Parameter type check failed; expected something matching but got something of type Block() for %bar in call to foo␤current instr.: 'die' pc 16538 (src/builtins/control.pir:225)␤»
masak submits rakudobug
jnthn wtf
masak jnthn: besides this small glitch, that new functionality is really neat, btw. 22:25
jnthn rakudo: sub foo(%bar) { }; say &foo.signature.pler
rakudo: sub foo(%bar) { }; say &foo.signature.perl
p6eval rakudo 44c487: OUTPUT«Could not locate a method 'pler' to invoke on class 'Signature'.␤current instr.: 'die' pc 16538 (src/builtins/control.pir:225)␤»
rakudo 44c487: OUTPUT«:( %bar)␤»
jnthn rakudo: say Associative.WHAT 22:26
p6eval rakudo 44c487: OUTPUT«Associative()␤»
jnthn rakudo: say Associative.perl
p6eval rakudo 44c487: OUTPUT«␤»
jnthn rakudo: say Positional.perl
p6eval rakudo 44c487: OUTPUT«␤»
jnthn rakudo: say Positional[Int].perl
p6eval rakudo 44c487: OUTPUT«␤»
PhatEddy easiest to close (I think) RT #63094 22:26
jnthn rakudo: sub foo(@a) { }; foo(1)
p6eval rakudo 44c487: OUTPUT«Parameter type check failed; expected something matching but got something of type Int() for @a in call to foo␤current instr.: 'die' pc 16538 (src/builtins/control.pir:225)␤»
jnthn rakudo: sub foo(Int @a) { }; foo(1) 22:27
masak ah, systemic fail.
p6eval rakudo 44c487: OUTPUT«Null PMC access in get_string()␤current instr.: 'parrot;Role;perl' pc 3906 (src/classes/Role.pir:358)␤»
jnthn gah. That worked like, veyr recently. How've I managed to hash that up...
say Positional[Int] 22:28
rakudo: say Positional[Int]
p6eval rakudo 44c487: OUTPUT«␤»
jnthn rakudo: say Positional
p6eval rakudo 44c487: OUTPUT«Positional()␤»
jnthn ah, that one works.
rakudo: say Positional.perl
p6eval rakudo 44c487: OUTPUT«␤»
jnthn looks confused 22:29
PhatEddy: That works for me here too on Win32. 22:30
And I'm on XP not Vista, and the other guy who said it worked said it worked on Vista. 22:31
PhatEddy: So yes, agree, close.
pugs_svn r26608 | masak++ | [t/spec/S06-multi/syntax.t] unfudged two tests 22:32
jnthn PhatEddy: closed 22:33
masak++ # that clears up all our unexpected success. 22:34
pmichaud: If you know how, or are able to, giving PhatEddy an RT bit could be a good idea.
masak recompiling Rakudo in one terminal window and trying to compile a Perl 6 project in another still throws me off sometimes. I should adopt a double buffering system. 22:36
...and then build it into proto.
PhatEddy Next relatively easy (I believe) is the merger of RT #61918 with RT #62002. 22:37
jnthn Does anybody see a failure in S11-modules/nested.t ?
masak jnthn: not here.
jnthn PhatEddy: I'm inclined to leave those separate. 22:38
PhatEddy: They are about the same thing, but one is explicitly tracking the lack of specification, the other the implemenation. 22:39
jnthn Having a [Spec] ticket is useful for tracking spec clarifications we're waiting on. 22:39
PhatEddy Should there be a dependency or something? 22:41
jnthn Yeah...probably. 22:42
PhatEddy If you are willing to try one more you look at RT #57336 last July 22:43
dalek kudo: ec69e24 | jnthn++ | src/setting/Any-list.pm:
Support arity-1 blocks being supplied to min and max.
pugs_svn r26609 | jnthn++ | [t/spec] Tests for .min and .max arity 1. 22:45
jnthn ...and that's another RT. :-) 22:47
PhatEddy: Looking.
Uff 22:48
It's a better error, but I think we can do even better than that.
jnthn OK, I think I might call it a day at that. 22:49
Fairly successful Rakudo day on the RT front. ;-)
PhatEddy OK - the other two are less probable so I am inclined to quit here ... sorry if I overestimated
jnthn no probs, we got one more closure out of it. :-) 22:50
PhatEddy I think after this I may be more inclined to ask about tickets here before posting to the list about them ... 22:51
masak jnthn: a successful day on the RT front here too. :) three new tickets in the pipe.
PhatEddy: that's generally a good idea, I think. 22:52
jnthn masak: Yeah, but today I closed more than you opened. :-P
Which makes a change.
masak jnthn++
jnthn: you keep that up, and you might actually bring the number of tickets under 300 again. :P
jnthn Of course, my crowning achievement today was getting my avatar on github set up. 22:53
masak cool.
jnthn There I was thinking it'd be just uploading an image BUT OH NO yet another acocunt on yet another site...
masak GRRavatar!
it's very late in the Eurozone. I'll be heading to bed now. 22:55
long bus journeys tomorrow and the day after, so I expect to be fairly productive in the weekend. 22:56
jnthn You're doing a lot of these long bus journeys. 22:57
masak aye. 22:58
jnthn Wait...Sweden...eurozone?
;-)
masak Sweden belongs to the Eurozone!
just because we're not smack in the middle of it... 22:59
jnthn I've probably been biased into aliasing Eurozone to "countries who use the Euro as their currency".
(Everyone here talked about Slovakia "entering the Eurozone")
masak jnthn: oh, you're right. 22:59
masak I'm using the term wrongly. 23:00
jnthn Well, I guess there's more than one way to define it. I've just seen eurozone meaning that an awful lot.
masak no, we don't belong to the Eurozone. we've voted about it twice so far, I think.
someday I will hold a Swedish Euro in my hand, I'm sure.
jnthn Out of the Scandinavian countries, Sweden feels to me like the only one that might join it any time soon. 23:01
masak aye, I believe that the sides are very even.
masak waves goodnight
jnthn I'd not be at all surprised if Sweden were to join it before the UK.
night, masak; safe journey tomorrow
masak dz. 23:02
jnthn use.perl.org/~JonathanWorthington/journal/38910 # rakudo day report 23:27
jnthn Google fail # y'know, taking the ariel map when it was dark/nighttime maybe wasn't such a good idea... 23:42
eternaleye LylePerl: (re Camelias) I like #7 23:46
LylePerl: for the later ones, the pink smile is too much 23:47