Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6, 2009-05-17

Perl 6 | Reference Documentation | Rakudo

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:18 frew joined #perl6
00:41 CMA joined #perl6
00:53 wknight8111 joined #perl6
00:55 JDlugosz joined #perl6
00:59 JDlugosz Well, I just found The Periodic Table of Perl 6 Operators.  Thanks, Larry.  I'll print it out large and hang it at work, where I was just saying I need something other than bare wall.
01:00 literal Larry didn't make it :)
01:01 JDlugosz Back to iterator .get and .lines ⇰  Why two separate commands?  As opposed to one, that is.
01:01 TimToady different return type
01:01 JDlugosz Literal:  Yes, I know.  He pointed it out to me earlier today.  I see it is made by markl.
01:03 TimToady .lines always returns a list, .get always returns an item
01:03 TimToady so .get is equivalent to .lines(1)[0]
01:03 JDlugosz Sounds too traditional, like something you'd find in Java.  Why getting away from context?
01:03 meppl good night
01:04 TimToady when it makes sense, we return a capture, which does the right thing in context
01:04 TimToady but in this case, it seems better to split the concepts
01:04 TimToady however, for an example we decided the other way
01:05 TimToady there's .pick vs .pick(3)
01:05 JDlugosz Speaking of returning...
01:05 TimToady .pick returns a capture containing a single item, which behaves as an item in context and doesn't need .[0]
01:06 JDlugosz A while back I wrote <http://www.dlugosz.com/Perl6/web/return.html> which was apparently well-received.  ...
01:07 JDlugosz But, meanwhile, still wondered how to *declare* a function with strong typing that returned one thing or another based on context. ...
01:08 JDlugosz Now I wonder what is the point of returning a Capture to defer that decision.  You will populate it with the same stuff regardless of the context.  And $ operator on Context has been removed from S02.
01:11 JDlugosz Another quick one :  I see constants named True and False, initial capped, in S02 now.  Why cap?  Not a type name.
01:11 TimToady they're enums
01:12 TimToady and they're types insofar as any subtype is a type
01:12 TimToady enums and constants are just types of one value
01:12 TimToady (well, that's one view of it :)
01:12 TimToady anyway, named values parse as types
01:13 TimToady meaning they never look for a following arglist
01:13 TimToady they may or may not respond to an explicit .()
01:13 TimToady so all coercions are types responding to .(), as in Str()
01:13 cspencer joined #perl6
01:14 JDlugosz So, for similarities in the parser, any sigil-less named value other than subs are capitalized?
01:14 TimToady they don't have to be, it's just customary to reserved lowercase typenames for native types
01:15 JDlugosz I mean your current convention.
01:15 JDlugosz Built-in constants and standard library constants will be capitalized?
01:15 TimToady well, the common examples tend to be Sun,Mon,Tue, and such :)
01:15 TimToady not all of them
01:16 TimToady rakudo: say pi
01:16 p6eval rakudo ec55f1: OUTPUT«3.14159265358979␤»
01:16 TimToady rakudo: say e
01:16 p6eval rakudo ec55f1: OUTPUT«2.71828182845905␤»
01:16 TimToady std: say pi
01:16 p6eval std 26860: OUTPUT«ok 00:02 35m␤»
01:16 TimToady std: say pi()
01:16 p6eval std 26860: OUTPUT«Undeclared routine:␤   pi used at 1 ␤ok 00:02 35m␤»
01:16 bacek_ joined #perl6
01:16 TimToady note constants are not considered functions, unlike in p5
01:17 TimToady pi is more like Tue
01:17 JDlugosz Enums in particular?  You felt a deep connection with enumerations as single-value subtypes?  Or just your whim for True, or for consistancy with things like Tue?
01:18 JDlugosz Yes, I recall that constants are variables, but can be declared with a sigil for items.
01:18 TimToady basically any value can be used as a single-valued type in a signature
01:18 TimToady we can now leave the sigil off constants
01:18 TimToady std: constant answer = 42;
01:18 p6eval std 26860: OUTPUT«ok 00:02 35m␤»
01:18 JDlugosz in a signature .... ah, so by making them subtypes, you can directly use them for MMD constraints?
01:19 TimToady yes, and write the usual factorial with multi factorial (0) { 1 } etc
01:19 JDlugosz Yes, I know you can declare a constant with or without a sigil.  It's been that way as long as I can remember.
01:19 TimToady uh, specced, but STD didn't implement it till a month ago or so (hides head in shame)
01:19 TimToady s/implement/parse
01:20 JDlugosz The number 0, too?  That used to not be the case.  If you allow any single value in MMD, you don't need to make enums special.
01:20 TimToady it's just useful to classify named values with types for parsing purposes
01:20 JDlugosz I do like it.  I was afraid of having standard subtypes for things like Zero just to do that.
01:21 TimToady and we might get more mileage out of it as we go along
01:21 TimToady it just seems like a single value is a degenerate case of a subset type
01:21 JDlugosz If any constant or literal will do -- why not?  Define it as being an auto-generated subtype of one item.  Also have to make sure identically "declared" subtypes are the same type.
01:22 JDlugosz I like it.  It fixes a hole I've perceved before.
01:22 JDlugosz How about the Capture thing?
01:23 TimToady I don't see it as returning a Capture if it knows what type it's declared to return
01:23 TimToady it just returns that
01:24 JDlugosz You mentioned earlier about some things returning captures "which does the right thing in context", re scalar vs list.
01:24 JDlugosz It looks like, in S02, that the list (perl 5 [...] syntax) is now a capture.  So maybe you just meant that?  A list that becomes just its first item in item context?
01:24 TimToady yes, if you say return 1 you can use the return value as a scalar even though it's the first positional
01:25 TimToady Captures no longer distinguish an invocant separate from the first positional
01:26 JDlugosz That's the gist I got from the diff of S02.  Invokant is no longer special that way, and $ operator no longer works on Capture.
01:26 TimToady it no longer works in the way it did
01:27 TimToady it can still treat a single positional as an item, but other than that, a Capture in scalar context is just itself
01:27 JDlugosz But... my model of the 'return' formalism (see link) is that the return Capture is automatically dereferenced in context.  You removed $ operator on Capture from S02.
01:27 TimToady s/scalar/item/
01:28 TimToady I suspect ruoso can explain this better than I can, especially since I'm being called to dinner...
01:28 TimToady (if he's around)
01:29 JDlugosz Maybe he'll notice this in the log.
01:30 TimToady ruoso: ^^^
01:30 JDlugosz ruoso: ^^^
01:30 JDlugosz (echo in here)
01:30 TimToady well later, hope this helps
01:30 TimToady dinner &
01:30 JDlugosz Thanks.
01:45 justatheory joined #perl6
01:49 cspencer joined #perl6
01:49 JDlugosz Question on complex numbers and/or the "\" character ⇰ In S02 it says "The complex type defaults to NaN + NaN\i."  What is the use of i here, syntactically?
01:55 agentzh joined #perl6
01:58 ruoso JDlugosz, the idea is that Capture does both .[] and .{}, so if there is more than one item (positional or named) it will be available as if it was a hash or an array... but in the "return 1" case, the capture in item context will return that parameter for DWIM sake
02:01 ruoso so basically if you're doing "return 1,2,3" and use that value as a list, you'll be able to use @foo[0]
02:01 ruoso if you assign it to a scalar, you'll still be able to use $foo[0]
02:02 ruoso and as a hash, you (surprisingly) will still be able to use %foo[0]
02:02 ruoso std: sub foo { return 1,2,3 }; my %a = foo(); say %a[0];
02:02 p6eval std 26860: OUTPUT«ok 00:02 37m␤»
02:02 JDlugosz So, given sub foo { return 1 }
02:02 JDlugosz $x = foo;
02:02 JDlugosz What does the item $x contain?
02:02 ruoso this is the only exception... $x will be 1
02:03 JDlugosz exception???
02:03 ruoso in every other case, $x will contain the capture itself
02:03 JDlugosz What's wrong with saying that the returned Capture is automatically dereferenced in item context.
02:03 ruoso because the capture is not a reference
02:03 JDlugosz ?
02:03 ruoso the analogy with p5 is not precise
02:04 JDlugosz So you prevent it just so it doesn't look too much like a p5 ref?
02:04 ruoso I'm not sure what you mean...
02:05 JDlugosz I mean I know it's not the same as a ref.  Why did the scalar dereference go away?
02:05 ruoso when you do return 1,2,3 you don't have a "reference" to a "list" that gets "dereferenced" when you assign to a list
02:05 JDlugosz Whatever you call it.  I could argue that terminology, but whatever.
02:06 ruoso the scalar dereference gone away because in Perl 6 you have a clear distinction between the container and the value
02:06 ruoso which you didn't in p5
02:06 ruoso rakudo: my $a = 1; say VAR($a).WHAT;
02:06 p6eval rakudo ec55f1: OUTPUT«Int()␤»
02:06 JDlugosz Using the @ operator on a Capture will produce a list.
02:07 ruoso no... it will return the capture itself
02:07 ruoso which happens to implement the list api
02:07 JDlugosz OK.
02:07 ruoso btw... rakudo failed in the eval I just did
02:07 JDlugosz So it's now pointless to use @ or % operators on a Capture.  Even though they are mentioned in S-2.
02:07 ruoso pugs: my $a = 1; say VAR($a).WHAT
02:07 p6eval pugs: OUTPUT«Int␤»
02:07 ruoso gah... pugs also failed
02:08 eternaleye_ joined #perl6
02:08 ruoso JDlugosz, it's pretty much pointless, yes...
02:09 ruoso what you need to realize, otoh, is the difference between
02:09 ruoso my @a = foo();
02:09 ruoso my @a := foo()
02:09 ruoso my @a <== foo();
02:09 JDlugosz I would expect a variable defined as Int to be an item container that only holds Ints.
02:09 ruoso yeah... but the variable is not declared that way... the result was supposed to be "Scalar"
02:10 JDlugosz OK, the first defines an Array container that is populated with the return from foo.  OK, the Capture makes sense there.
02:10 JDlugosz The second binds a variable to the Capture as the container implementing the Positional role.
02:10 JDlugosz I'm not familiar with the 3rd.
02:10 cspencer joined #perl6
02:10 ruoso JDlugosz, it will, in a "mostly lazy" way, populate @a with the result from foo()
02:11 ruoso with implicit threading
02:11 ruoso the difference between that and the first is that the first is "mostly eager"
02:11 JDlugosz But given my $x = @a;  that will make the item container hold the container bound to @a.
02:12 JDlugosz Right?
02:12 JDlugosz I avoided the word "reference".
02:13 ruoso rakudo: my @a = 1,2,3; my $x = @a; $x[0] = 4; say @a;
02:13 p6eval rakudo ec55f1: OUTPUT«423␤»
02:13 JDlugosz and my Int $x = @a; would be an error, because an Array (or whatever) isn't an Int.
02:13 ruoso it's not really about the container itself
02:14 JDlugosz it ?
02:14 ruoso what happens in $x = @a is "take the thing you find by the name '@a' and call .item on it, then store on the scalar that you find by the name '$x'"
02:15 ruoso the rvalue here could be anything
02:15 ruoso it's not the language that is handling that, it's @a itself
02:15 ruoso so if your @a implements a different coercion to item
02:15 ruoso it will return something different
02:16 JDlugosz Is that relativily new?
02:16 ruoso not at all... that is the basic concept
02:17 JDlugosz The Synopses didn't say that last time I read in detail (about 8 months ago)
02:17 ruoso rakudo: class Foo { method postcircumfix:<[ ]> ($index) { return $index * 2 }; method item { return 'foo' } }; my @a := Foo.new; say @a[100]; my $x = @a; say $x;
02:17 p6eval rakudo ec55f1: OUTPUT«elements() not implemented in class 'Foo'␤»
02:17 ruoso pugs: class Foo { method postcircumfix:<[ ]> ($index) { return $index * 2 }; method item { return 'foo' } }; my @a := Foo.new; say @a[100]; my $x = @a; say $x;
02:17 p6eval pugs: OUTPUT«␤<obj:Foo>␤»
02:18 ruoso gah... they're both wrong
02:19 JDlugosz But lets elaborate on that.  $x = @a, not counting any knowledge of the built-in default meanings of default things, says to call .item on the container bound to @a, and STORE the result IN the container that's bound to $x.  Right?
02:20 ruoso yes
02:20 JDlugosz Meanwhile, how is .item() method different from using $ as a prefix operator?
02:20 ruoso it isn't
02:20 ruoso it's basically the same thing
02:21 JDlugosz Then why isn't it available on Capture anymore, especially given that's the key to what happens when you call $x=foo ?
02:21 ruoso rakudo: class Foo { method postcircumfix:<[ ]> ($index) { return $index * 2 }; method item { return 'foo' } }; my @a := Foo.new; say @a[100]; sub bla { @a }; my $x = bla(); say $x; #
02:21 p6eval rakudo ec55f1: OUTPUT«elements() not implemented in class 'Foo'␤»
02:21 ruoso JDlugosz, operators are not methods
02:21 ruoso operators are multi subs
02:21 ruoso I'm quite sure that the default implementation of prefix:<$> is to call .item
02:22 JDlugosz Agreed.
02:22 JDlugosz And what happens when you say $x=foo() ?  The .item() method is called on the Capture returned from foo?
02:22 ruoso exactly
02:23 ruoso (in smop that is still spelled FETCH
02:23 ruoso (i'm not very confortable with .item, very easy to clash with other things...)
02:23 JDlugosz So, why was prefix $ removed from something defined with Capture ?
02:23 ruoso it was removed from the spec as something that would have a special meaning
02:23 JDlugosz I agree, we need a different syntax for coersion operators.  But that's detail.  Lets get the concepts right.
02:24 ruoso std: sub foo { }; my $x = $(foo());
02:24 p6eval std 26860: OUTPUT«ok 00:02 36m␤»
02:24 JDlugosz So @ on a Capture is "special" in that it doesn't just apply the ARRAY operator?
02:25 ruoso it try to coerce to a list, yes
02:25 ruoso but in a capture, coercing to List means returning the capture itself
02:25 ruoso since the capture itself implements the list api already
02:25 JDlugosz I don't follow your last execution example.
02:25 ruoso the prefix $ is there
02:25 ruoso noone removed it
02:26 JDlugosz I did a diff, and the examples and explainations were systematically removed.
02:26 ruoso because it's no longer important in the concept of the Capture
02:26 ruoso specially because "my $x = $(foo())" is pointless
02:27 JDlugosz Look for "you can retrieve parts from a Capture object with a prefix sigil operator..."
02:27 ruoso since you're already implying the context by the assignment
02:28 JDlugosz $args = \( whatever );
02:28 JDlugosz $$args is removed from S02.
02:28 ruoso because $$args is probably going to get you the same as $args
02:28 JDlugosz Implying it no longer "retrieves parts".
02:28 ruoso exactly...
02:29 JDlugosz But then we are back to $x=foo not working.
02:29 ruoso there's *one* exception
02:29 ruoso (which is documented in the spec somewhere)
02:29 JDlugosz $x wants to contain the first (only) value in the Capture, not the Capture itself.
02:29 ruoso If the capture contains only one argument (positional or named), it will return that when used in item context
02:30 sri_kraih_ joined #perl6
02:30 ruoso so...
02:30 ruoso sub foo { return 1 }; my $x =  foo();
02:30 ruoso $x contains an Int
02:30 ruoso sub foo { return 1,2,3 }; my $x = foo();
02:30 ruoso $x contains a Capture
02:30 ruoso sub foo { return a => 1 }; my $x = foo();
02:30 ruoso $x contains a Pair
02:30 JDlugosz So, .item (or whatever it will be eventually called), aka prefix operator $, on a Capture will return the item if it contains exactly one positional item, or the Capture itself (identity) otherwise.
02:30 JDlugosz Is that it?
02:31 ruoso exactly
02:31 ruoso that's the DWIM exception
02:31 JDlugosz Could have just said so.
02:31 ruoso that's what I'm trying to say
02:31 ruoso ;)
02:31 JDlugosz Yea.  DWIM does not a formal specification make.
02:32 * ruoso recalls that being spec already...
02:32 JDlugosz So you never commented on my write-up in Perl 6 Language to say it was all wet, about a year ago.
02:32 JDlugosz Ah, but the wording in S02 etc. was changed since then.
02:32 JDlugosz When was this all hashed out?
02:33 JDlugosz I see a trend toward Captures being more and more central to the plot, as they are understood.
02:33 JDlugosz It used to be that the Scalar context was linked to the invocant.
02:34 JDlugosz I can see this way, getting rid of implied dereference in a particular case, it better.
02:35 ruoso the change in Capture is fairly recent
02:35 ruoso we're just finishing a huge refactroing in SMOP because of that change
02:36 JDlugosz OK.  So I'd better make sure I "get it".
02:36 JDlugosz And then I might fix the rough edits from S02 et al.
02:37 ruoso basically, Capture is no longer an unstable object
02:37 ruoso (since it was destructive too easily)
02:37 JDlugosz Well, maybe my write-ups were of some good after all.
02:37 JDlugosz Did I also read that [...] is no longer a List, but a Capture ?
02:38 ruoso oh... certainly... I had to pester TimToady a lot until he had the change...
02:38 ruoso about [...], where are you reading? (line if possible)
02:39 JDlugosz I can't find it...just my notes.
02:39 JDlugosz Was in S02, looking at the Unified Diff.
02:39 ruoso I think [...] is still an array constructor
02:39 JDlugosz Let me figure it out based on what's around it...
02:39 ruoso and (...) is a capture constructor
02:39 ruoso while the prefix \ means "enclose this capture in a scalar"
02:40 dduncan joined #perl6
02:40 dduncan left #perl6
02:40 ruoso but with the latest changes, you have fewer reasons to use prefix \
02:40 JDlugosz Nope, can't find it.
02:41 JDlugosz Can you give example?
02:41 ruoso my $x = (1,2,3) vs my $x = \(1,2,3)
02:41 ruoso the \ is useless there
02:41 ruoso but...
02:41 ruoso my $x = \foo()
02:42 ruoso makes sure your capture don't get destroyed by the DWIM case
02:42 JDlugosz Maybe that's what I saw, (), not [].  The () alone now does it.  The \ adds a wrapper so the single value doesn't pop out again (the special case).
02:42 ruoso yes
02:43 JDlugosz OK.  Time for another question?  I think this is a typo in S02.
02:43 ruoso shoot
02:43 JDlugosz “Therefore @array[^**] represents @array[{ map { ^* }, @_ }], that is to say, every element of the array, no matter how many dimensions.”
02:44 ruoso that's really two *
02:44 JDlugosz I don't like the ^**.  I think it should be [^]**.  Or, is ^ applied to a list automatically hypered?
02:44 JDlugosz I know ** is multi-dimensional Whatever.
02:45 * ruoso getting the context around the quote
02:45 JDlugosz The question is on applying ^ to a list.
02:48 ruoso JDlugosz, the closest you'd get would be ^(**)
02:48 ruoso std: my @a; @a[^(**) ];
02:48 p6eval std 26860: OUTPUT«ok 00:02 38m␤»
02:49 ruoso because the operator is ^, and the value is **
02:50 ruoso rakudo: my @a = [1,2,3],[4,5,6],[7,8,8
02:50 JDlugosz or ^\**, to separate the tokens with a degenerate unspace.
02:50 ruoso gah
02:50 p6eval rakudo ec55f1: OUTPUT«Statement not terminated properly at line 1, near "[7,8,8"␤in Main (src/gen_setting.pm:0)␤»
02:50 ruoso rakudo: my @a = [1,2,3],[4,5,6],[7,8,9]; say @a[^**];
02:50 p6eval rakudo ec55f1: OUTPUT«Statement not terminated properly at line 1, near "[^**];"␤in Main (src/gen_setting.pm:0)␤»
02:51 ruoso ok... rakudo doesn't support it already
02:51 ruoso std: my @a; @a[^\**];
02:51 p6eval std 26860: OUTPUT«ok 00:02 38m␤»
02:51 JDlugosz So, ^ DOES work on a list without needing to hyper-ize it?
02:51 JDlugosz But it's wrong in another way, tokens run together ?
02:52 ruoso the spec says it's translated to a map
02:52 ruoso so I guess it's not as an hyperoperator
02:52 ruoso so no concurrent execution
02:52 JDlugosz I think that's a quibble.
02:53 JDlugosz No reason it couldn't be concurrent.  Just no "other" and "Perl 5 familiar" way to write that.
02:53 ruoso maybe the expanded example is just an example...
02:54 ruoso but TimToady probably needs to clarify that..
02:54 ruoso anyway...
02:54 * ruoso needs to sleep
02:54 JDlugosz It appears that rakudo took it, when parens were added.
02:54 JDlugosz Is that BECAUSE of this example?
02:55 JDlugosz Why would ^ be different from other operators?  No need to auto-hyper it, why not all of them?
02:55 ruoso well.. I think noone considered yet to auto-hyperize normal operators...
02:56 ruoso but I'll leave that for TimToady
02:56 * ruoso night &
02:57 eternaleye joined #perl6
02:59 kate21de joined #perl6
03:10 eternaleye joined #perl6
03:20 donaldh joined #perl6
03:45 cspencer_ joined #perl6
03:45 cspencer_ left #perl6
03:45 cspencer_ joined #perl6
03:46 cspencer_ rakudo: say 1 before 2
03:46 p6eval rakudo ec55f1: OUTPUT«Statement not terminated properly at line 1, near "before 2"␤in Main (src/gen_setting.pm:0)␤»
03:49 orafu joined #perl6
03:56 ejs joined #perl6
04:06 agentzh joined #perl6
04:45 lambdabot joined #perl6
05:21 agentzh joined #perl6
05:41 meteorjay joined #perl6
06:13 orafu joined #perl6
06:31 c9s joined #perl6
07:05 iblechbot joined #perl6
07:21 donaldh joined #perl6
07:42 DemoFreak joined #perl6
07:53 eternaleye Well that's interesting. In exploring Unicode, I chanced across a symbol which the Arial font has switched with its neighbor
07:54 eternaleye rakudo: say "\c[CIRCLE WITH UPPER HALF BLACK]"
07:54 p6eval rakudo ec55f1: OUTPUT«◓␤»
07:54 eternaleye In Arial, the top it white and the lower half is black.
07:54 eternaleye *is
07:57 Patterner I have white letters on black background and the upper half of the circle is white. And I'm sure I don't use Ariel.
08:30 Eevee I'm pretty sure Unicode glyph names say "black" with the assumption that the font color is black
09:01 eternaleye All my fonts are black font on light background
09:01 eternaleye Except Konsole, but I use Quassel for IRC
09:13 literal "filled" would have worked better than "black"
09:13 bacek_ joined #perl6
09:45 eternaleye ... So I've started building this bikeshed... XD
09:46 meppl joined #perl6
09:47 agentzh joined #perl6
10:12 VX joined #perl6
10:25 pmurias joined #perl6
10:32 abra joined #perl6
10:34 payload joined #perl6
10:34 payload joined #perl6
10:38 eternaleye joined #perl6
10:42 pugs_svn r26861 | pmurias++ | [re-mildew] Capture.new handles named arguments
10:42 pugs_svn r26861 | pmurias++ | t/signature_named.t passes
10:43 Chillance joined #perl6
10:51 fridim_ joined #perl6
10:52 icwiener joined #perl6
11:16 eternaleye joined #perl6
11:20 donaldh joined #perl6
11:28 masak joined #perl6
11:28 masak whoz op, #perl6
11:29 masak the weather is actually too nice in Uppsala to stay indoors, but I just thought I'd pop by and see how you're doing. :)
11:31 masak rakudo: class A { method postcircumfix:<( )>() { 42 } }; my $a = A.new; say $a()
11:31 p6eval rakudo ec55f1: OUTPUT«invoke() not implemented in class 'A'␤»
11:31 masak will the above ever work?
11:33 mberends will you return to more constructive pursuits when it does?
11:33 masak :)
11:33 masak no promises.
11:33 masak the reason I'm asking is that I seem to recall that .() was special-cased in some way.
11:34 jnthn masak: That problem may disappear when pm does various list refactors.
11:34 * jnthn also doesn't intend to stay indoors this afternoon either.
11:34 masak mberends: oh, and good day, sir. is there anything in particular that you would prefer I focus on, in terms of constructive pursuits?
11:34 masak jnthn: OH HAI
11:35 eternaleye joined #perl6
11:35 masak jnthn: so, "yes, it will eventually work"?
11:35 jnthn masak:  H H
11:35 mberends declaring the spaceship operator is also fun, infix:�<=>�
11:35 jnthn masak: I think perhaps you may have to implement elems too.
11:35 masak jnthn: 噢你好 :)
11:35 jnthn masak: However, doing that at the moment doesn't help either.
11:36 mberends and a nice day to you's all
11:36 masak jnthn: we should have a list of the things you're expected to implement when making a class do Callable, Associative and Positional...
11:37 jnthn masak: Oh, I completely read your example as [ ], not ()
11:37 jnthn oop
11:37 jnthn s
11:37 jnthn You wouldn't need elems for that one.
11:37 jnthn And I'm not quite sure when we'll make that one work.
11:37 jnthn It depends on solving a nasty nasty Parrot issue.
11:37 masak jnthn: it's ok, I didn't reflect on the insanity of your reply. :P
11:37 mberends masak: no, leap year arithmetic was just making me crabby
11:38 masak mberends: you're a brave man, sir.
11:38 masak mberends: have you done leap seconds yet?
11:38 mberends aaaargghh!
11:39 masak mberends: it'd be fun to create an expert system that can answer the question "which was the longest year?"
11:39 mberends szabgab++ kicked my Padre installation into shape :)
11:39 masak yes, I backlogged as much.
11:40 mberends Padre support for Perl 6 is still young, needs more testers
11:42 payload1 joined #perl6
11:45 masak mberends: I had a mind to hack some on Druid yesterday, but got distracted by everything and nothing. maybe today I'll get a chance, if the nice weather doesn't completely overpower me.
11:45 bacek_ joined #perl6
11:45 masak I have two interesting leads to follow: the SVG thing, and the Web.pm thing.
11:45 masak they actually interact a bit, too.
11:46 mberends masak: I suggest try the Web.pm first for -Ofun
11:46 masak mberends: I already did, a few weeks ago.
11:47 masak but it needs a bit of polish.
11:47 masak bin/web-druid
11:49 masak (a type of script that we keep seeing more and more often nowadays -- HTTP::Daemon++)
11:49 mberends enjoy! I really want to move along my todo list as well.
11:49 * jnthn eyes his todo list fearfully
11:50 mberends that Daemon does get around, in new forms :)
11:50 jnthn OK, off to the castle, and the river(s) and the sun. bbl
11:50 masak mberends: in fact, it might be a good idea to provide the functionality being copy-pasted everywhere in HTTP::Daemon itself, making it work out-of-the-box with certified Web.pm apps.
11:50 mib_4qajcr joined #perl6
11:51 masak jnthn: enjoy!
11:51 jnthn masak: You too, whatever you choose to do in the sun. :-)
11:51 masak jnthn: read, probably. thanks. :)
11:51 mberends masak: that's a good idea for what to do with the core code.
11:52 mberends with help from Tene++ maybe SMTP will become a similar core.
11:52 masak mberends: I'm having a look at HTTP::Engine from CPAN, and seeing if we can learn something from that.
11:53 masak mberends: but I think a wrap-HTTP::Daemon-around-a-Web.pm-app script would be good for dependency reasons.
11:54 masak having Web.pm depend on HTTP::Daemon does not exactly square with it being engine-agnostic, as I've recently come to realise. :/
11:54 masak that said, we should definitely make it super-easy to hook the latter into the former.
11:55 mberends masak: for the wrapping, a CGI style API (not CGI.pm) would link them agnostically, and even resemble Apache and mod_perl interfaces. It mainly uses %*ENV.
11:56 masak mberends: as does Rack. sounds good.
11:56 mberends ok, Rack too. nice.
11:57 mberends masak: can do, need a break from Feb-29 and all that.
11:57 masak (Feb 29)--
11:58 masak mberends++
11:58 mberends masak: on another front, started writing my YAPC::EU talk this week :)
11:59 masak mberends: hint taken. :P
11:59 * masak still very much likes the second photo in http://howcaniexplainthis.blogspot.com/2009/04/group-photos.html
12:00 mberends a kind of rain dance?
12:00 masak I have no recollection of the specific situation that caused me to do that.
12:00 eternaleye joined #perl6
12:01 masak but it appears I'm enjoying myself.
12:02 mberends I'm planning to publish by talk WIP (10% done) soon - will you also?
12:02 mberends *my
12:02 masak depends -- what's a WIP?
12:02 mberends Work In Progress, sorry
12:02 masak oh, good idea. I could keep it in the Web.pm repo.
12:03 masak that'll also spur me to port my Amazing Slide Software (tentatively called 'Hubris') to Perl 6.
12:03 mberends :-) Hubris. I've already invoked Laziness in mine.
12:05 mberends my Slide Software is going to have to be a Pod6 emitter
12:09 masak joined #perl6
12:09 mberends masak: rehi. HTTP Engine at first sight appears to be cloneable
12:12 eternaleye joined #perl6
12:15 masak .oO( neighbour's wifi... )
12:22 DemoFreak joined #perl6
12:23 mberends @tell masak re: HTTP-Engine, see also http://search.cpan.org/~beppu/Squatting-0.60/lib/Squatting/Cookbook.pod
12:23 lambdabot Consider it noted.
12:28 c9s joined #perl6
12:40 bacek__ joined #perl6
12:46 eternaleye joined #perl6
13:04 eternaleye joined #perl6
13:06 payload1 joined #perl6
13:10 Whiteknight joined #perl6
13:14 lichtkind joined #perl6
13:21 lichtkind does anybody know the nickname of conrad schneiker?
13:25 abra joined #perl6
13:26 eternaleye joined #perl6
13:44 eternaleye joined #perl6
13:54 pmurias joined #perl6
14:02 jhorwitz joined #perl6
14:03 eternaleye joined #perl6
14:06 ruoso_ joined #perl6
14:06 ruoso_ pmurias++ # more tests passing...
14:07 ruoso_ pmurias, the segfault in the other test is being caused by refcounting bugs...
14:10 s1n do trait_auxilary apply to methods as well?
14:10 ruoso yes
14:10 ruoso method foo is export { }
14:11 s1n ruoso: thanks :)
14:11 obra_ joined #perl6
14:13 nihiliad joined #perl6
14:14 eternaleye joined #perl6
14:14 payload joined #perl6
14:24 cognominal joined #perl6
14:27 cspencer joined #perl6
14:31 pmurias ruoso: hi
14:32 eternaleye joined #perl6
14:36 ruoso joined #perl6
14:37 CMA joined #perl6
14:42 iblechbot joined #perl6
14:45 M_o_C joined #perl6
14:46 s1n Tene: i tried doing something similar to your LolDispatch, but i seem to be doing something wrong, i'm seeing "No method named 'trait_auxiliary:is' to remove in class 'TestDispatch'."
14:50 meppl joined #perl6
15:01 justatheory joined #perl6
15:07 eternaleye joined #perl6
15:15 eternaleye joined #perl6
15:20 donaldh joined #perl6
15:32 eternaleye joined #perl6
15:35 Tene s1n: that's a bug in rakudo when defining subs in classes.  Both jonathan and I have looked at it.  I might look into working around it today, but the proper fix depends on the work in the .HLL_map branch.
15:36 Tene s1n: you need to define it in a 'module', not a 'class' for now.
15:36 Tene s1n: the big problem I ran into when working on this is trying to get the invocant from the caller.
15:36 Tene Parrot doesn't actually expose that information in PIR, afaict.
15:37 Tene I patched Parrot to expose it, and ran into a segfault.
15:45 Psyche^ joined #perl6
16:14 mikehh joined #perl6
16:26 TimToady funny thing is that Class isa Module, on some level or other, so if it works in a module, it ought to work in a class
16:28 jnthn TimToady: Happily, we're exploding in some code that is a hack to work around something that (as of a few days ago), we won't need to work around.
16:29 jnthn TimToady: Basically it's making the un-good assumption that if something is in a class, it must also be a method.
16:29 jnthn I could fix that up too somehow, but I'd rather spend time just ripping out the code in question anyway. :-)
16:34 cspencer should Range eventually expose a .by method to get at the increment?
16:36 Tene oh... release is coming up soon.  If I'm going to get this inter-language library import stuff into this release, I'd better do it soon.
16:39 jnthn cspencer: Most likely yes.
16:39 cspencer jnthn: and for the to_exclusive/from_exclusive too, i imagine then?
16:39 cspencer jnthn: though those names are somewhat cumbersome
16:40 jnthn Yeah, .by will do well for a name, but those probably won't.
16:40 jnthn I don't do naming though. :-)
16:40 jnthn Most things I tried to name in Parrot, other people came along with a better name for. ;-)
16:41 cspencer jnthn: heh, okay, i'll add in a .by method and leave the others for later :)
16:51 Gothmog_ joined #perl6
17:04 eternaleye joined #perl6
17:06 pmurias jnthn: will we support merging ranges?
17:06 eternaleye joined #perl6
17:06 jnthn pmurias: Merging ranges?
17:07 jnthn pmurias: Gotta run to the shops quickly...need food...piwo ;-)
17:08 justatheory joined #perl6
17:08 pmurias :)
17:08 pmurias like having a range from 1..3 and 5..8
17:14 s1n Tene: i changed it to a module (which i thought was essentially just a package as well), but i now get null pmc access in invoke...
17:14 moritz_ re
17:18 ruoso joined #perl6
17:18 Tene s1n: what are you trying to invoke?  Can I see the code?  How are you extracting the invocant from the caller?
17:19 s1n Tene: yeah, lemme touch it up and gist it
17:19 Tene I wasn't able to get the invocant from the caller in any reasonable way.
17:19 Tene also, can there be a sub and a method of the same name in the same namespace?
17:20 Tene I think so, but I haven't verified.
17:20 ruoso as long as you don't use my or our in the method, you can
17:21 ruoso my method foo {} # declares &foo
17:21 ruoso our method foo {} # declares &foo and register in $?PACKAGE
17:21 ruoso method foo {} #  no lexical or package
17:22 pugs_svn r26862 | moritz++ | [t/deprecated-syntax.pod] remove some paragraphs that are either out of date or typically not a problem anymore
17:22 pugs_svn r26863 | moritz++ | [t] merge init-in-exported-sub.t into spec/S10-packages/basic.t
17:22 s1n bleh, i'm getting malformed routine now
17:22 s1n i'll just gist it and see if you can help
17:24 pmurias_ joined #perl6
17:24 s1n http://gist.github.com/113062
17:24 s1n oops, hmm, i think i misnamed the module
17:24 s1n how did i not notice that until just now
17:25 eternaleye joined #perl6
17:25 s1n well, i still get malformed routine def at line 21
17:26 masak joined #perl6
17:26 moritz_ s1n: that's because the multi trait_auxiliary:<is> isn't visible in the scope of line 21
17:26 masak @messages
17:26 lambdabot mberends said 5h 3m 43s ago: re: HTTP-Engine, see also http://search.cpan.org/~beppu/Squatting-0.60/lib/Squatting/Cookbook.pod
17:26 masak mberends: will read. thanks.
17:26 masak @clear
17:26 lambdabot Messages cleared.
17:27 s1n moritz_: okay, is it feasible to move it into FooDispatch?
17:28 s1n moritz_: because even when i move it into FooDispatch, i still get "Malformed routine definition at line 19, near "foo() is f""
17:28 moritz_ s1n: I don't know (yet) what the right solution is, sorry
17:28 jnthn pmurias: Ja mam piwo! ;-)
17:29 jnthn pmurias: I guess you could just make a list with the two ranges in and make sure you keep it in lazy contexts...
17:29 s1n moritz_: that's okay, i'm looking to see what i'm doing wrong. Tene's LolDispatch was so interesting, i wanted to play with it :)
17:30 moritz_ s1n: I have some backlogging to do, and if you haven't found your problem until I'm finished I'm glad to investigate more...
17:30 moritz_ s1n: that said, try to pars it with STD.pm, perhaps you just have a syntax error and STD.pm gives you a better error message
17:31 s1n moritz_: how do i pass that through STD.pm?
17:31 moritz_ cd src/perl6/ # in pugs
17:31 brrrrr joined #perl6
17:31 moritz_ ./tryfile $filename
17:31 moritz_ you need 'make' as step 1.5 ;-)
17:40 s1n moritz_: i had to do a 'perl tryfile $filename' (because my perl is elsewhere) and it complaining about STD.pm barewords...
17:40 moritz_ s1n: did you do a 'make' first?
17:40 s1n no, perl was always elsewhere, i'll have to change that to make it work
17:41 pugs_svn r26864 | moritz++ | [S02] remove a left-over $<?> (now $/.ast)
17:44 moritz_ s1n: 21 sub foo() is foo_command(/^foo) { # you need to close that regex
17:44 s1n moritz_: doh!
17:45 s1n bleh, the p5 syntax highlighter in vim usually clues me to that one
17:45 s1n now i'm getting the null pmc access in invoke again
17:45 moritz_ s1n: use the p6 syntax hilighter
17:46 s1n moritz_: check line 26 :)
17:46 alester joined #perl6
17:47 moritz_ ;-)
17:51 sri_kraih joined #perl6
17:53 Tene s1n: you're still having problems?
17:53 Tene sorry, stepped out for lunch.
17:55 JDlugosz I'm at my desk, working on Perl.
18:02 s1n Tene: yeah, moritz_ fixed the sub def error i was getting, still getting null pmc access
18:03 Tene s1n: update your gist and I'll check it out
18:05 s1n Tene: updated
18:06 s1n all i did was "perl6 -e 'use FooDispatch'"
18:06 masak moritz_: oh, you don't like the each() comprehension?
18:06 moritz_ masak: not as it is now
18:06 moritz_ masak: right now it works in one syntactic special case, which makes it rather obscure
18:07 masak moritz_: I found your comment about it in t/TODO, and then re-read the part about each(), and found it quite quirky and a bit amusing.
18:07 masak moritz_: but I must confess to never having needed it.
18:08 masak moritz_: fwiw, I think you're onto something in the email.
18:08 moritz_ masak: did you know about it before you read my comment?
18:08 masak moritz_: nope. :) but I must have skimmed over that part of the spec at some time.
18:08 moritz_ actually when I wrote it wanted to write something like "can we get rid of that bullshit?"
18:09 moritz_ but I then remembered some earlier Junction tests
18:09 moritz_ which assumed exactly the semantics that each() has, in this special case
18:09 masak moritz_: that's what you wrote in the TODO file, IIRC. :)
18:09 moritz_ so I thought maybe there's some merit after all
18:09 masak sorry, t/TASKS
18:10 masak yup, "container/each.t: wtf is each? do we still need it?"
18:10 masak :)
18:10 JDlugosz Can someone talk about "Subexpressions circumfixed by parentheses" as described in S03 ?
18:11 JDlugosz ruoso ^^^^^
18:11 JDlugosz TimToady ^^^^^
18:12 JDlugosz ruoso explained yesterday how () are now a Capture constructor, no \ needed.
18:12 moritz_ that surprises me a bit
18:12 JDlugosz But S03 reads, "Parentheses are parsed on the inside as a semicolon-separated list of statements, which (unlike the statements in a block) returns the results of all the statements concatenated together as a List of Capture."
18:12 moritz_ that's my state of knowledge too
18:13 ruoso note the "semicolon-separated"
18:13 ruoso (1,2,3) returns a capture
18:13 ruoso (1,2,3;4,5,6) returns two captures
18:13 JDlugosz Not a Capture, but a List OF Capture.  I was expecting a single Capture with the kind of non-flattening at the semi's that we've seen for subscripts.
18:14 masak JDlugosz: what ruoso just said.
18:14 frew|work what's the diff between a capture and a list?
18:14 moritz_ any idea what happened to t/spec/S04-statements/do.t?
18:14 JDlugosz It doesn't say that a circumscribed subexpression without semis does anything different.
18:14 ruoso but I think that part would look better "all the statements concatenated together as a Capture of Captures"
18:14 moritz_ rakudo now aborts after 16 tests or so
18:14 moritz_ is that deliberate?
18:15 ruoso frew|work, a capture is a context-less container
18:15 JDlugosz So the singular case is different?  No extra wrapping that somehow keeps out of the way?
18:15 s1n Tene: any idea what's wrong?
18:15 ruoso a list defines a container
18:15 masak frew|work: Captures participate in binding (of variables and function arguments)
18:15 ruoso *a context
18:16 pugs_svn r26865 | moritz++ | [t/spec] stop rakudo from prematurely aborting do.t
18:17 ruoso JDlugosz, it certainly depends on how you look at it... but I guess there isn't much difference between
18:17 ruoso (1,2,3;4,5,6) and ((1,2,3),(4,5,6))
18:17 ruoso but I'm not sure about that
18:17 JDlugosz OK, that makes sense and is a good way to explain it.
18:17 JDlugosz But, without semicolons, you don't get double-bagged, right?
18:18 ruoso it would be a shame if you did
18:18 ruoso since most of the time we deal with single-dimension captures
18:18 JDlugosz It's like the () is a capture constructor, as explained yesterday, and the semicolons also, indpendantly, is a capture constructor.
18:19 ruoso yeah... I'd think that as infix:<;> vs circumfix:<( )>
18:19 JDlugosz So in any kind of list, 1,2,3;4,5,6 gives two captures rather than 6 Ints.
18:19 JDlugosz Put the two together, it works out as you described.
18:20 JDlugosz So... what about the explaination I learned about ; in a list just marking the spots, with a separate non-flattening context being optional?
18:20 JDlugosz Is that gone totally, for subscripts and everything?
18:21 JDlugosz And instead, semi's produce nested lists in a fairly ordinary and very understandable way?
18:21 Tene s1n: it works perfectly when I move FooDispatch into a separate file.
18:21 ruoso JDlugosz, the flattening only happens later
18:22 ruoso if you assign to a list
18:22 ruoso for instance
18:22 Tene s1n: that is, when I put the foo_command'd sub in a different file from FooDispatch
18:22 moritz_ so it's really an exporting issue?
18:23 Tene s1n: it has to do with the timing of when things are put in the right places during compilation and when the trait_auxiliary stuff is called.
18:23 moritz_ you could try a FooDispatch.import() or FooDispatch.IMPORT() or however it's called
18:23 JDlugosz OK, I'll come back to that in a moment. But what I said is correct?  It (now) makes a list of Captures?
18:24 JDlugosz As for flattening:  I recall that a list where an item is expected in list context will flatten.  So the Capture allows that to happen too, just like the literal list.  Captures, in general, defer decisions.
18:24 Tene But when you put it in a different file, all of that happens as soon as rakudo sees the 'use' statement.
18:25 JDlugosz So,  given my Capture $c := (1,2,3);
18:26 JDlugosz Strike that, should be: my Capture @c := (1,2,3);
18:27 JDlugosz then my Capture @d := (10,@c,20);
18:28 JDlugosz @d holds a nested Capture, but
18:28 lambdabot Maybe you meant: devils dice dict dict-help djinn djinn-add djinn-clr djinn-del djinn-env djinn-names djinn-ver docs dummy . ? @ id v
18:28 JDlugosz my @A= @d;
18:28 JDlugosz will flatten, giving 10, 1,2,3, 20.
18:29 Tene s1n: what's your purpose in putting foo() in FooDispatch btw?
18:30 JDlugosz But @d still has a nested structure.  How do I view it as such, getting back the non-flattened top list?  That was previously described as using the @@ context.
18:31 JDlugosz I'm supposing that the Positional interface to Capture will present the flattened view.
18:32 JDlugosz Binding to variables through a Signature will see the non-flattened view.  That's parameter passing.
18:33 nihiliad joined #perl6
18:34 VX joined #perl6
18:38 s1n Tene: because moritz_ said trait_auxiliary:<is> wasn't visible
18:38 s1n Tene: should i put FooDispatch in one file, and the call to dispatch() in another file?
18:38 Tene s1n: that's because you weren't importing the class youd efined there.
18:39 Tene s1n: yes
18:39 Tene or, if you want to keep it like that, do something like FooDispatch.import() oslt
18:39 Tene i don't remember the details to do that.
18:39 s1n why would i have to import FooDispatch in the same file?
18:40 moritz_ because subroutines are scoped to the current module
18:40 moritz_ not to the file
18:40 Tene s1n: because symbols are lexically scoped.  Defining a class or module isn't the same as asking its symbols to be imported into the scope you deifned it in.
18:41 moritz_ it's like in perl 5: { package foo; sub bar { }}; bar() # book
18:41 moritz_ s/book/boom/
18:41 s1n okay, how do i import this properly then?
18:42 moritz_ that's a good question
18:42 Tene s1n: I strongly recommend you just put them in different files for now.
18:43 Tene i think there's a related bug here, but I'm not sure and don't have the time to track it down right now.
18:43 s1n Tene: i can do that, would i just use FooDispatch then?
18:43 Tene yes.
18:44 moritz_ rakudo: module A { sub f is export { 3 } }; A.import(:DEFAULT); say f()
18:44 p6eval rakudo ec55f1: OUTPUT«Null PMC access in getprop()␤»
18:44 s1n Tene: should i be able to do the call to dispatch from the command-line?
18:44 moritz_ rakudo: module A { sub f is export { 3 } }; A::import(:DEFAULT); say f()
18:44 p6eval rakudo ec55f1: OUTPUT«Null PMC access in invoke()␤»
18:44 s1n -e 'use FooDispatch; dispatch("foo")'
18:44 s1n moritz_: is that supposed to work?
18:44 Tene s1n: put the foo() definition on the command line, and yes.
18:45 s1n Tene: the handler has to be in a different file too??
18:45 masak I've asked this before, but gotten contradictory answers: if I'm in a script and import modules A and B, and A exports a bunch of subs which override Perl 6 core subs, will these still be overriddent in module B?
18:45 moritz_ masak: no.
18:46 Tene s1n: put the module in FooDispatch.pm.  Then, in a separate file, put: use FooDispatch; sup foo is foo-handler() { ... }; dispatch();
18:46 Tene s1n: like I said before.
18:46 moritz_ masak: B unly sees the overridden symbols if it uses `lift#
18:46 moritz_ *lift
18:46 masak moritz_: among the two possible answers, that's the one I like.
18:46 JDlugosz masak:  no.  In Perl 5, the override is lexical.  In Perl 6, it should be the same.
18:46 masak moritz_: I've actually been bitten by Rakudo implementing the other answer. :/
18:47 moritz_ masak: then do your job (and rt it) ;-)
18:47 masak moritz_: yes.
18:47 JDlugosz Then again, it depends on *how* it overrides the core subs.
18:47 masak moritz_: last time I tried, there was a bug earlier in the chain.
18:47 moritz_ JDlugosz: no.
18:47 masak moritz_: I'll give it a go again now.
18:47 JDlugosz If it wraps them, the change is global.  The same symbol is assigned a different meaning.
18:47 moritz_ JDlugosz: the setting is immutable once it's loaded
18:48 s1n Tene: i'll try that in a bit (errands), is that a bug and should i file?
18:48 moritz_ JDlugosz: so calling .wrap on core function either does its job lecxically, or fails
18:48 Tene s1n: yes, there's a bug there.
18:48 JDlugosz What "setting"?
18:48 Tene I'm not sure exactly what it is.
18:48 moritz_ JDlugosz: all the built-ins reside in a scope called "setting"
18:48 JDlugosz I don't recall wrap being descibed to work differently for things that reside in CORE.
18:49 JDlugosz setting: OK.
18:49 moritz_ JDlugosz: and to all modules and scripts it looks like an outer lexical scope
18:49 skids joined #perl6
18:49 moritz_ (it's rather newish, might be 3 months old or so)
18:49 abra_ joined #perl6
18:50 JDlugosz CORE <+ SETTING < UNIT < (your_block_here)
18:50 JDlugosz er, <=
18:50 JDlugosz For standard stuff, SETTING is the same as CORE.  startup options -n and -p put stuff in CORE to make a DSL.
18:51 JDlugosz So, I can see defining a sub in SETTING to lexically hide the rock-bottom-default from CORE.
18:51 moritz_ or maybe it's the other way round, and CORE is imutable
18:51 JDlugosz But that's not the same as calling .wrap.
18:51 moritz_ I haven't really grokked it
18:52 JDlugosz Perhaps (most) built-ins will complain if you try to wrap them, e.g. the Routine is readonly.
18:52 JDlugosz Error message suggests defining yours in SETTING to hide it, instead.
18:53 JDlugosz All the modules see the same SETTING for the program.  They have different UNIT scopes.
18:54 JDlugosz That has implications for pre-compiling modules.  Basically, the SETTING can affect the meaning of the module at "compile time" if compiles when loaded like P5.
18:56 JDlugosz But the hope is that stuff can be pre-compiled.  I can see making the loader treat subs in SETTING as bascially a formal way to override the CORE, but that doesn't help names that are defined of a different fundimental class, and change the meaning of the parsed text.
18:56 jferrero joined #perl6
18:57 moritz_ JDlugosz: but as I understand it the intention is that unless a module requests something else, it will always get the "normal" built-ins
18:57 JDlugosz That (fairly new) section in S02 needs work.
18:57 moritz_ JDlugosz: so that 'use B' can not mean somethiing else if there was a 'use A' before
18:57 moritz_ did I understand that correctly?
18:58 JDlugosz I agree with you, moritz_.  The meaning should be fixed unless explicitly using contextual symbols or generics.
18:58 moritz_ good.
18:59 JDlugosz So, given that the intent of SETTING is to provide a DSL, not to hot-wire the meanings of modules, a module should behave as if pre-compiled, and that means being independant of the main program.
18:59 JDlugosz Compiling a module (for later use) has its own SETTING layer, which is unrelated to that of the main program.
19:00 JDlugosz That's my thought.  I'll make notes to work over the S02 later.  Buzz me if anyone has more input on the matter.
19:00 moritz_ none but "I agree" ;-)
19:02 JDlugosz I think my working style will be to present a whitepaper or tutorial first, that's less formal and explains the rationale.  Then later update the Synopses if they are well-received, and the whitepaper can become a "rationale" unofficially.
19:07 iblechbot joined #perl6
19:09 moritz_ masak: did you submit your grant proposal?
19:09 masak moritz_: aye, on Friday. rdice already replied, saying "how's it going with the Web.pm grant?"
19:09 masak a very reasonable question.
19:09 masak I wrote a reply a few hours ago.
19:10 masak (I expect to finish my part of Web.pm by early June)
19:10 moritz_ ok
19:11 payload joined #perl6
19:20 donaldh joined #perl6
19:22 masak oh, and another thing: errors are written to $*OUT in Perl 6?
19:22 masak why?
19:22 masak erm, in Rakudo.
19:22 Tene that seems like a mistake.
19:22 masak it does indeed.
19:23 masak it's hard to demonstrate with p6eval.
19:24 masak rakudo: run('./perl6 "die q[OH NOES]" > /dev/null')
19:24 p6eval rakudo ec55f1: OUTPUT«Unable to open filehandle from path 'die q[OH NOES]'␤current instr.: 'perl6;PCT;HLLCompiler;evalfiles' pc 75371 ((unknown file):-1)␤»
19:24 masak rakudo: run('./perl6 -e "die q[OH NOES]" > /dev/null')
19:24 p6eval rakudo ec55f1:  ( no output )
19:24 masak see?
19:24 moritz_ rakudo: run('./perl6 -e "die q[OH NOES]" 2>/dev/null')
19:24 p6eval rakudo ec55f1: OUTPUT«OH NOES␤in Main (<unknown>:1)␤»
19:24 * masak submits rakudobug
19:31 mberends funny, warn() and die() write to 2>/tmp/whatever here
19:32 mberends p6eval might have a 2>&1 kind of trick
19:32 masak so, platform-dependence?
19:32 mberends yes
19:33 kate21de joined #perl6
19:33 mberends calling environment
19:35 jnthn yes, should be going to stdin
19:35 moritz_ *in*?
19:35 moritz_ ;-)
19:35 jnthn o jebat...
19:35 jnthn stderr
19:35 jnthn I fix this week.
19:35 jnthn Along with the sometimes-missing-backtrace issue.
19:35 masak yes, plz fix.
19:36 moritz_ jnthn: do you know how I can call import manually?
19:36 masak this is the closest to an outrageous bug that I've found for quite some time.
19:36 moritz_ rakudo: method A { sub f is export { 3 } }; A::import(:DEFAULT); say f()
19:36 p6eval rakudo ec55f1: OUTPUT«Null PMC access in invoke()␤»
19:37 moritz_ jnthn: is that how it's supposed to work?
19:37 Tene rakudo: module A { sub f is export { 3 } }; A::import(); say f();
19:37 Tene I think you mean.
19:37 p6eval rakudo ec55f1: OUTPUT«Null PMC access in invoke()␤»
19:37 moritz_ Tene: ah, yes
19:37 masak that's in RT, though.
19:37 moritz_ result is the same
19:38 moritz_ masak: ah, I didn't know that
19:38 Tene yes, but s/method/module/ is important :)
19:38 masak "calling sub in module" is, yes.
19:38 moritz_ rakudo: module A { sub f is export { 3 } }; A::import(:DEFAULT); say "alive";
19:38 p6eval rakudo ec55f1: OUTPUT«Null PMC access in invoke()␤»
19:38 Tene rakudo: module A { sub f is export { 3 } }; say A::f();
19:39 p6eval rakudo ec55f1: OUTPUT«3␤»
19:39 * moritz_ isn't sure if masak meant the same thing
19:39 masak http://rt.perl.org/rt3/Ticket/Display.html?id=64876
19:39 jnthn masak: Meh. Gotta let you have something to complain about now and then. :-P
19:40 moritz_ ;-)
19:40 jnthn moritz_: I think it's IMPORT too, but NYI.
19:40 masak jnthn: well, it's been a while since I had something really good to complaing about. :-P
19:40 mberends masak: pugs/misc/evalbot/evalbot.pl:96: cmd_line    => $input . '| ./perl6 %program >> %out 2>&1',
19:40 moritz_ jnthn: ok, thank you
19:40 moritz_ masak: it's not quite the same thing, not quite the same error message
19:40 jnthn moritz_: Importing is currently one of those things we cheat on a lot.
19:40 Fuad joined #perl6
19:40 masak mberends: yes, but note that the run(...) call doesn't follow those rules.
19:41 Fuad Hello folks
19:41 mberends hi Fuad
19:41 masak Fuad: hello!
19:41 Fuad :)
19:41 jnthn moritz_: Mostly because I just needed something good enough to let us import stuff from the setting, and wanted to handle tags at some level too.
19:41 masak Fuad: did you read the source I threw at you last time?
19:42 Fuad masak: yes i was working on it,dude
19:42 moritz_ jnthn: fine by me... I'm just thinking about the traits stuff...
19:42 masak Fuad: let me know how that goes.
19:42 moritz_ jnthn: should I move the roles defining the traits to an external module?
19:42 jnthn moritz_: Aye, traits are kinda blocking on input.
19:42 jnthn (From TimToady++)
19:43 keepguessing joined #perl6
19:43 jnthn moritz_: Are you looking at testing traits some more?
19:43 jnthn moritz_: If so, I'd advise you put it off a bit - I know TimToady is mulling them over and I've no real way of guessing how radical the changes are going to be.
19:44 aindilis joined #perl6
19:44 moritz_ jnthn: I'm just looking at testing what's implemented right now
19:46 jnthn moritz_: OK, feel free, but be aware that (a) the spec is one of the bits currently very liable to change and (b) I don't plan any more implementation until there's some progress on the spec.
19:46 moritz_ jnthn: ok
19:47 jnthn Just don't want to encourage you to spend a bunch of time on something that I know could change (possibly a lot) shortly.
19:53 moritz_ jnthn: thanks
19:53 moritz_ getting the current tests to pass on rakudo seems non-trivial
19:54 moritz_ so I abort for now
19:54 jnthn moritz_: I didn't get far into traits before I blocked on spec. :-)
19:54 ejs joined #perl6
19:55 justatheory joined #perl6
20:05 mberends masak: pushed minor change to proto
20:05 masak mberends: pulling.
20:06 dalek rakudo: 2949868 | jnthn++ | perl6.pir:
20:06 dalek rakudo: Make sure backtraces are printed to STDERR; printing them to STDOUT outrages masak++^W^Wis very wrong.
20:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/294986872304dc2b441c68e7615c0a04ceb076c3
20:07 masak jnthn: I'm suddenly much less outraged. :)
20:08 masak mberends: no twigil because I'm a very forgetful person. :/
20:09 mberends it works all the same :)
20:09 masak I'll add a twigil.
20:09 masak (and remove the TODO comment that you implemented, mberends++)
20:09 Tene pmichaud: ping?  going ot be around today?
20:10 masak mberends: oh, my 'if !' instead of 'unless ' is just a personal preference. I don't mind you changing it to the latter, but I'll probably keep writing the former.
20:10 mberends 50/50, ok
20:10 masak mberends: partly because of PBP, partly because I find it easier to reason about.
20:11 * moritz_ likes 'if !...' better too
20:11 masak I don't mind statement-modifying 'unless' at all, though. strange. :)
20:11 moritz_ ;-)
20:11 Tene I prefer 'unless'... make it more obvious I'm looking for a negative.  I tend to overlook !s.
20:12 moritz_ well, reading an 'unless ... { ... } else { ... }' is rather confusing (but forbidden in p6, iirc)
20:12 Tene rakudo: unless 1 { ... } else { say "hi" }
20:12 p6eval rakudo ec55f1: OUTPUT«unless does not take "else" in Perl 6; please rewrite using "if" at line 1, near "else { say"␤in Main (src/gen_setting.pm:0)␤»
20:12 Tene :(
20:12 Tene ;_;
20:12 Tene oh well, I'm over it now.
20:12 masak mberends: make_pir_modules is a nice addition, but I still think we should have a real Makefile :)
20:13 masak ...eventually.
20:13 mberends masak: the reason for the refactor was to try to get "Building proto" to happen at first execution, but that would assume that the default RAKUDO_DIR was already correct
20:13 masak mberends: also, the final Pod doc looks incomplete.
20:13 masak mberends: "Some possible changes, subject"
20:13 mberends it looks terribly out of date
20:15 mberends after your Ecosystem separation, the name Installer no longer describes what it does too well.
20:15 masak it doesn't?
20:15 masak I thought the name became more apt after the disfactor. :)
20:15 * masak skims Installer.pm
20:16 masak mberends: though I did briefly ponder naming them Proto::Installer and Proto::Ecosystem, respectively.
20:17 mberends update, test, and showdeps are not actually installing anything
20:17 mberends and from my soapbox, I think 'subcommand-dispatch' is overly pompous.
20:18 masak no, but couldn't 'installer' be a sort of catch-all term?
20:18 masak mberends: granted, subcommand-dispatch is pompous. :)
20:18 mberends I can only offer criticism right now, not constructive suggestions ;)
20:18 masak 哈哈
20:19 masak it would be fun if someone wanted to write a review of proto.
20:20 masak lurkers: ^^
20:21 mberends masak: Installer method new() looks very pretty :-)
20:22 ejs1 joined #perl6
20:22 masak mberends: you're referring to the assignment inside a hash value? :P
20:22 mberends yes, the $c
20:23 masak hm, variable declaration, even.
20:23 masak mberends: let's just say I'm glad Perl is as liberal as it is. :)
20:24 masak mberends: I pushed a little fix.
20:26 mberends :) Padre detected the pull and offered to reload :)
20:26 masak I just want to counter Tene's above sobbing (about unless/else being forbidden) by expressing my total contentment about the current state of affairs. :)
20:26 masak Padre++
20:27 Tene :P
20:29 masak rakudo: class A does Associative { method postcircumfix:<{ }>(*@ix) { return @ix } }; .say for A.new<foo bar>
20:29 p6eval rakudo 294986: OUTPUT«foo␤bar␤»
20:29 masak that's just so cool.
20:30 moritz_ masak: care to turn that into a small test case?
20:30 masak moritz_: well, since you ask so nicely... :)
20:30 masak mberends: for the record, I'll scrap contains-project and get-info-on after the next Rakudo release.
20:31 masak mberends: ...replacing it with the above kind of thing.
20:32 bacek joined #perl6
20:32 * mberends doesn't get it
20:33 masak mberends: essentially making Ecosystem do Associative.
20:33 moritz_ gah, S06-operator-overloading/method.t seems over-engineered
20:34 moritz_ and wrong.
20:35 moritz_ or, hm, maybe not
20:35 moritz_ rakudo: class A { method b { say "A::b" } }; my $x = A; $x.new().b
20:35 p6eval rakudo 294986: OUTPUT«A::b␤»
20:37 mberends masak: you're just adding sugar with Associative, right?
20:37 masak mberends: no, I'm also removing two methods.
20:37 masak "There should be only one obvious way to do it." :P
20:38 moritz_ welcome to python.
20:38 mberends yes
20:38 masak moritz_: aye. I'm just being an iconoclast.
20:39 moritz_ rakudo: class A { method prefix:<~> { "foo" } }; my $x = A.new(); say "$x";
20:39 masak moritz_: I found t/spec/S13-overloading/operators.t -- got a better suggestion for a suitable file to put the test in?
20:39 p6eval rakudo 294986: OUTPUT«A()<0xb62517e0>␤»
20:40 moritz_ masak: I'm currently reviewing t/spec/S06-operator-overloading/method.t if it might be more suitable
20:40 masak it might.
20:40 moritz_ hm
20:40 moritz_ but method.t seems to require quite some work
20:40 moritz_ I'd go with the S13 one for now
20:40 masak ok.
20:40 moritz_ (and add it to t/spectest.data)
20:41 masak (and fudge as needed)
20:41 moritz_ it currently passes all two tests ;-)
20:41 masak :)
20:41 jnthn masak: Happy I decreased your outragedness.
20:41 * jnthn is finding LiveMocha a HUGE distraction.
20:41 masak jnthn: consider yourself today's outragedness decreaser.
20:42 masak moritz_: should it really say 'ok eval', though? I thought we did things like lives_ok nowadays?
20:42 masak oh well.
20:42 * masak stops procrastinating actually writing the test
20:42 moritz_ eval_lives_ok
20:43 moritz_ (thouge we could change that to eval-lives-ok sometimes
20:44 masak <grammar-nazi>(no, 'sometimes' is used for recurring events.)</grammar-nazi>
20:44 moritz_ s/sometimes/eventually/
20:44 moritz_ better? ;-)
20:44 masak I'm not _un_happy :)
20:45 moritz_ bah, method.t is a mess
20:46 moritz_ it actually tests a rather obscure corner case which isn't specced probably
20:46 jnthn Eww.
20:46 jnthn moritz_: Which one?
20:47 moritz_ jnthn: prefix:<~> as methods and multi subs
20:47 * jnthn has managed to drag himself away from LiveMocha
20:47 jnthn moritz_: In S12-methods?
20:47 moritz_ jnthn: no, t/spec/S06-operator-overloading/method.t
20:47 jnthn moritz_: ah, ok
20:47 jnthn taking a peek
20:48 moritz_ it uses interpolation into double quoted strings to look for a prefix:<~>
20:48 jnthn moritz_: It looks very dubious.
20:49 pugs_svn r26866 | masak++ | [S13-overloading/operators.t] added test about postcircumfix:<{ }>
20:49 jnthn multi sub prefix:<~> (Bar $self) # well done, you just declared yourself an arity-2 prefix operator.
20:49 moritz_ rakudo: class A { method prefix:<`> { say "foo" } }; `A.new()
20:49 p6eval rakudo 294986: OUTPUT«Could not find non-existent sub prefix:`␤»
20:49 jnthn moritz_: It'd need exporting, I think.
20:49 masak bug?
20:49 moritz_ jnthn: why? it's not a method...
20:49 masak well, yes it is.
20:49 jnthn moritz_: oh, duh
20:50 jnthn moritz_:
20:50 jnthn it is a method
20:50 jnthn multi method prefix:<~> ($self)  { return $.bar }
20:50 moritz_ oh, that one
20:50 jnthn If there was a : after the $self, it'd be dine.
20:50 jnthn *fine
20:50 moritz_ jnthn: feel free to add it
20:50 jnthn moritz_: Well, it's deeper
20:50 jnthn multi method infix:<+>  ($a, $b) { return "$a $b" }
20:50 jnthn That'd need to be $a: $b
20:51 jnthn then it looks like it's missing some exporing too IIUC.
20:51 masak what happens if an infix sub or method is declared with too many parameters?
20:51 brrrrr joined #perl6
20:51 moritz_ masak: it will participate in ordinary dispatch, I think
20:52 moritz_ masak: and if it has assoc<list>, it might even get called
20:52 masak ah.
20:52 jnthn rakudo: sub infix:<epicfail>($a) { }; 1 epicfail 2
20:52 p6eval rakudo 294986: OUTPUT«too many arguments passed (2) - 1 params expected␤»
20:52 dalek rakudo: 1203649 | masak++ | t/spectest.data:
20:52 dalek rakudo: [spectest.data] added S13-overloading/operators.t
20:52 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1203649deb39b5bd6caea24106acd1c032146263
20:52 jnthn masak: That. :-)
20:52 masak dalek is much slower than pugs_svn...
20:52 masak jnthn: makes a lot of sense. :)
20:53 jnthn .oO( must find good use for epicfail operator )
20:53 moritz_ so only postcircumfix operators can be non-exported subs?
20:53 jnthn moritz_: Well, I guess you can always call
20:53 jnthn $foo.infix:<+>($b)
20:53 moritz_ well.
20:53 moritz_ yes
20:54 jnthn Oh, wait, do we still have multis being automatically exported though?
20:54 moritz_ dunno
20:54 moritz_ I hope not
20:54 jnthn I forget. I remember reading the spec not long back on that and doing what the spec said, but I forget what the spec actually said by now. ;-)
20:54 moritz_ because that would mean automatically importing new syntax
20:54 moritz_ which would come close to epicfail ;-)
20:55 * masak ponders going home for the evening
20:56 Tene jnthn: interested in reviewing the start of my sketch for inter-language library loading?
20:57 Tene I'm interested in getting additional eyes on this.
20:58 moritz_ jnthn: so when I define a new postcircumfix:«` `», do I have to export it to properly parse?
20:59 Tene moritz_: not in current rakudo, iirc, but that's the spec, again iirc
20:59 jnthn moritz_: Yeah, I expect not...
21:00 jnthn moritz_: That's a very good question...I think that in Rakudo as we have it today we just say the token is kosher from the point when we parse it onwards.
21:00 jnthn Tene: I'm a little tired, but I'll happily look.
21:01 moritz_ rakudo: class A { method postcircumfix:«` `»($a) { say "argh" } }; A.new().`3`
21:01 p6eval rakudo 120364: OUTPUT«Statement not terminated properly at line 1, near ".`3`"␤in Main (src/gen_setting.pm:0)␤»
21:01 moritz_ rakudo: class A { method postcircumfix:«` `»($a) { say "argh" } }; A.new()`3`
21:01 p6eval rakudo 120364: OUTPUT«Statement not terminated properly at line 1, near "`3`"␤in Main (src/gen_setting.pm:0)␤»
21:01 jnthn moritz_: Ah, but declaring new postcircumfixes I think will not work.
21:01 moritz_ ok
21:01 jnthn As in, add them to the parser.
21:01 jnthn I was quite surprised when Tene++ got circumfixes to work...
21:07 meppl joined #perl6
21:12 patmat seas meppl
21:15 skids pfah, so much for moore's law -- new laptop rakudo at best 2x as fast :-)
21:15 jnthn skids: How old was the previous laptop though? ;-)
21:16 Tene jnthn: you see link in #parrot?
21:16 skids several years, on the high end of several
21:17 jnthn Tene: Oh, no...
21:17 jnthn Tene: looking...
21:17 meppl seas patmat
21:17 moritz_ skids: well, having two cores can speed up 'make spectest' by another factor of 2
21:18 Tene http://nopaste.snit.ch/16580
21:18 jnthn Tene: re # other attributes?
21:18 jnthn For Perl 6 I think the set of attributes may be extensible.
21:18 jnthn There's :auth for example.
21:19 Tene jnthn: for example, Perl 6 is specced as defining a library based on name, author, version, authority, etc.
21:19 jnthn I think author and authority may be conflated, but yes.
21:19 Tene jnthn: but, ideally, only name is required.  all others are optional and may be ignored by the language you're requesting a library from.
21:19 jnthn Tene: I wonder though if we should just say "and you can pass a bunch of others and it's up to the library loader of that HLL to use them"
21:20 jnthn And if you give it something it can't handle sanely, I guess it can choose to explode in the appropriate way.
21:20 Tene jnthn: I'd prefer if the library loader just ignored them instead of exploding.
21:20 Whiteknight joined #perl6
21:21 jnthn Tene: Sure, if it's possible for it to do so, that'd be far nicer.
21:22 jnthn Tene: Is the list of strings meant to boil down to namespace parts?
21:22 jnthn e.g. for use Foo:Bar we'd pass ['Foo','Bar']
21:22 Tene Yes.
21:22 jnthn ok
21:22 Tene python has foo.bar.baz, perl has Foo::Bar::Baz, php has Foo\Bar\Baz, etc.
21:23 jnthn DEFAULT:
21:23 jnthn # a map of names to symbols
21:23 jnthn php srsly uses \ for ns sep? omfg.
21:23 Tene yes, it does.
21:23 jnthn For this, I guess maybe we should define what "a map" means.
21:23 jnthn I'd imagine ideally for Rakudo we'd just hand back the namespace
21:23 Tene hash.  string-keyed.
21:23 Tene right.
21:24 Tene anything that responds to a hash interface
21:24 * skids trauma seizure every time he sees the word PHP
21:24 jnthn and since it does a hash interface and you can iterate over it, it's good enough.
21:24 jnthn Is being able to get an iterator part of the hash interface?
21:24 jnthn If not, we should probably lay down that the thing you had back had really better be iterable.
21:24 Tene nodnod
21:25 jnthn One other thing that comes to mind.
21:25 jnthn Where is the responsibility for not re-loading something already loaded meant to go?
21:25 Tene that responsibility is up to the language who is asked to load a library
21:26 jnthn OK, I can go with that. But something to make clear.
21:26 Tene it would be entirely correct, if a bit unusual, for a language to make an HTTP request for the latest version of the module every time it was asked for.
21:26 Tene for example.
21:26 Tene it can do anything it wants, as long as it obeys the interface.
21:26 jnthn Oh, for sure, but just to make clear to people implementing the interface that it needs to handle the "you tried to load this again" case.
21:27 Tene nodnod
21:27 Tene I mean, I guess we could make HLLCompiler provide a cache...
21:27 jnthn I did ponder that but...
21:27 Tene the issue is whether any language ever wants to *avoid* caching.
21:27 jnthn Well, it also means HLLCompiler needs to have some clue about how to determine module identity too.
21:28 Tene nodnod
21:28 Tene case-sensitive, frex
21:28 Tene or version
21:28 jnthn nod
21:28 jnthn I think putting a layer of cache in HLLCompiler is probably being too clever and will just lead to hurt.
21:29 Tene yes, agreed
21:29 jnthn version: 'v1.0.1'                  # optional. a string is probably good?
21:29 jnthn I think Perl 6 it's fine to say things like v1.*
21:29 Tene the issue is how different languages represent versioning.
21:29 jnthn Do you see that just being something we stringify and the end receiving it should know what to do with it?
21:29 Tene Right.
21:30 jnthn OK. If it appears in the soruce code, it has gotta be able to appear as a string, so a string is probably good, I agree.
21:30 Tene maybe in one language it's an integer, in one language it's a float, or a string, etc.  is 1.2 greater or less than 1.10 ?
21:30 jnthn Ugly.
21:31 Tene put it in a string, let someone else take care of it.
21:31 jnthn I think "pass the string and let the language deal with it" may be the way.
21:31 jnthn And if you throw in a string that in that language's version handling is invalid, then it'll just whine.
21:31 Tene yes
21:31 jnthn I guess we want to make languages all play together rather than try to make all languages the same. :-)
21:32 jnthn author: "adent"
21:32 jnthn In Perl 6 I think that's just auth
21:32 jnthn But I think once again
21:32 Tene it was just an example.
21:32 jnthn We just say "and you can hand back whatever other details you want"
21:32 Tene "you can put more details in here if the language wants them"
21:32 Tene yes
21:32 jnthn filename: "/path/to/filename.ext"
21:32 jnthn version: "v1.0.1"
21:33 jnthn Did you see those as being optional or required?
21:33 Tene not required, but examples of what a language might provide.
21:33 jnthn Ok, then fine.
21:33 jnthn Again, good to make claer in the spec, but fine.
21:34 jnthn btw, you talk about get-library but then describe fetch-library.
21:34 Tene in the request, the only required key is 'name'.  In the response, the only required key is 'symbols', whose only required keys are 'ALL' and 'DEFAULT'.
21:34 jnthn Right, that sounds like a sane minimum.
21:34 Tene fixed :)
21:34 Tene (I haven't seen any other libraries that offer that functionality, but they might in the future, after seeing the Perl 6 example. :) )
21:35 Tene also to give a way for other languages to potentially use Perl 6 libraries better.
21:35 leroe joined #perl6
21:35 leroe left #perl6
21:35 jnthn *nod*
21:35 jnthn OK, I think that's all my comments. :-)
21:36 Tene Thanks for mentioning clarifications.  The degree of agreement is very promising. :)
21:36 Tene I'll start working on it today.
21:36 Tene Is it too soon before the release, do you think?
21:37 jnthn I suspect that since it adds functionality rather than modifies existing, at least at a Parrot level, it's probably fine.
21:37 Tene OK
21:37 fridim_ joined #perl6
21:37 masak here's a blog post I just wrote: http://use.perl.org/~masak/journal/38988
21:37 jnthn That said, it may be good to get slightly wider consensus since ocne it's in a release people can start using it and it's harder to change.
21:38 Tene Any ideas of who else I should consult with?
21:38 jnthn Tene: I'd run it through pmichaud.
21:38 Tene Yes, I wanted to, but he's not around today. :(
21:38 Tene i'll keep it in a branch for now.
21:38 jnthn Yeah, well, he's gotta rest at some point. ;-)
21:38 jnthn OK, sounds sane.
21:39 jnthn I expect pm will be about tomorrow.
21:40 jnthn masak: How are you feets?
21:40 masak jnthn: they ache slightly.
21:40 masak not too bad, considering.
21:41 masak I have a nice large blister on the right one, but I got that from jogging yesterday... which, I think, is what actually prompted me to do the whole barefoot thing.
21:41 masak rakudo: say +'I have a blister on my right foot'.words # trying to stay on topic :)
21:41 p6eval rakudo 120364: OUTPUT«8␤»
21:42 jnthn "Our humor is quirky and intellectual, full of a mix of quantum physics, lolcats"...thrown in with the occasional "how iz compiler formed" :-)
21:42 masak rakudo: say +'␤␤␤␤␤␤'.words # trying to stay on topic :)
21:42 p6eval rakudo 120364: OUTPUT«0␤»
21:43 masak jnthn: I like how #perl6 visits both the highs and the lows in humour. :)
21:43 masak rakudo: say +''.words
21:43 jnthn masak++ # nice post
21:43 p6eval rakudo 120364: OUTPUT«0␤»
21:43 masak jnthn: dz. :)
21:43 masak going to bed now. my work here is done.
21:44 jnthn night
21:44 masak good night.
21:49 eternaleye rakudo: say (~pi).words
21:49 p6eval rakudo 120364: OUTPUT«3.14159265358979␤»
21:49 eternaleye 0.o
21:50 moritz_ .
21:53 leroe joined #perl6
21:53 leroe hi
21:53 leroe is it just me or google is heavily backing up python than perl?
21:54 pugs_svn r26867 | moritz++ | [perl6-projects.org] introductory paragraph
21:54 moritz_ well, the use python for a lot of their web pages
21:55 leroe yeah but why google of all companies supports py to perl?
21:55 moritz_ s/the/they/
21:55 leroe i mean they're pretty smart enough to know where python stands
21:55 moritz_ they seem to think it's not too bad
21:55 leroe but in your opinion what are they missing, code wise
21:55 leroe i know they got py's creator
21:56 leroe so mayve thats why?
21:56 leroe our lecturer advised us too
21:56 leroe ive been gathering books on perl until today
21:56 leroe :P
21:56 leroe he suggested i go learn python
21:56 moritz_ honestly, I have no idea why the picked python
21:56 moritz_ but they are free to do whatever they want
21:57 leroe is there any advantage using py pver perl
21:57 leroe in any area
21:57 moritz_ sure; for example if you want to get hired by google
21:57 leroe no i mean technically
21:57 leroe syntax, code
21:57 leroe concept
21:57 moritz_ well, some people like indention for semantics
21:58 moritz_ and some people prefer one way to do it over many ways to do it
21:58 moritz_ it's a bit like with natural languages
21:58 moritz_ what are your advantages of learning French over German, or the other way round?
21:58 moritz_ it all depends on whom you want to talk to
21:58 leroe no but perl seems to be over the top on a lotof things
21:59 leroe im sure techn ically speaking its way past python
21:59 leroe that is where i want to know, where exactly
21:59 skids one of the python fans I know thinks the language's strength is in its docs.
21:59 moritz_ are you talking about Perl 5 or Perl 6?
21:59 leroe perl6
21:59 leroe perl in general
22:00 moritz_ well, the difference between Perl 6 and Perl 5 is quite large
22:00 moritz_ there is no "perl in general"
22:00 leroe well take perl6  to the new python
22:00 moritz_ well, then Perl 6 has grammars, for example
22:00 moritz_ with cleaned-up regex syntax, match trees, inheritance of subrules etc.
22:01 moritz_ very good Unicode support (grapheme-level support)
22:01 moritz_ versioned modules
22:01 jnthn multiple dispatch
22:01 leroe and what is python lacking in those areas
22:01 moritz_ I don't think python has any of the fancy regex stuff
22:02 moritz_ or meta operators, for that matter
22:02 leroe ah
22:02 moritz_ mutable grammar
22:02 moritz_ http://dev.perl.org/perl6/faq.html has a nice (albeit a bit outdated) list of cool Perl 6 features
22:02 leroe ok cool
22:04 leroe is it faster than py
22:05 leroe check this http://www.python.org/doc/humor/#python-vs-perl-according-to-yoda
22:05 moritz_ Perl 6 is a language specification, not a compiler
22:05 moritz_ so it can't be faster or slower
22:05 moritz_ maybe Perl 5 is faster
22:06 leroe ah
22:06 leroe theres much debate lying around py vs perl, didnt realise until today
22:07 s1n Tene: you're right, if i move foo() and the call to dispatch out to a different file, it seems to properly work
22:07 s1n Tene: i'm still not sure i understand why that is though
22:07 ruoso joined #perl6
22:08 leroe moritz_ does making a language compiled make it faster
22:08 leroe like objc
22:09 moritz_ leroe: sometimes.
22:09 Tene s1n: it's a a bug in rakudo
22:09 moritz_ leroe: for example, Java is compiled to bytecode, but some java VMs have such fast JIT compilers that many programs run faster in Java than in C
22:09 Tene it has to do with the timing
22:09 moritz_ leroe: ... usually at the expense of eating more memory
22:10 s1n Tene: is there one filed about it?
22:10 leroe moritz_: couldnt agree with you more
22:10 Tene no idea.
22:10 leroe moritz_ what language do you use when programming OO
22:10 moritz_ leroe: Perl (and C++ for heavy duty numerics)
22:11 s1n perl, duh!
22:11 leroe moritz_: although I don't see how that can be possible =p
22:11 leroe logically that is
22:11 leroe the comment about java
22:11 moritz_ why not? the VM has much more run time information than a compiler can ever have
22:11 moritz_ it knows exactly where the hotspots are
22:11 moritz_ and can optimize the heck out of them
22:12 moritz_ whereas if you try to optimize the heck out of every single piece of code in your program, you loose cache friendliness
22:13 leroe thinking
22:13 leroe you have a point
22:14 moritz_ anyway, in 99.5% of all apps that I write speed is not an issue
22:15 leroe i don;t doubt that:P
22:16 s1n moritz_: about 99.5% of the apps i write for my degree always have speed as a consideration (and usually ignored in favor of development time and a very long runtime) :)
22:18 moritz_ s1n: well, the program that I write for my degree makes up for the 0.5% ;-9
22:18 moritz_ s1n: and it uses SSE friendly matrix products, interfaces Fortran libraries etc, all that nasty stuff just to make it run fast enough :)
22:19 moritz_ thankfully most of that is done by a linear algebra library under the hood
22:19 lichtkind_ joined #perl6
22:20 s1n moritz_: what's your degree/focus?
22:20 leroe moritz_: c++ vs java seems a big debate on the web
22:20 leroe but yours makes more sense
22:21 moritz_ s1n: German "Diplomphysik"
22:21 moritz_ physics.
22:21 s1n moritz_: heh okay, i was just about to ask for the american version :/
22:22 s1n graduate or under?
22:22 moritz_ well, the degree is going to be superseeded by the Master of Science
22:22 moritz_ but IMHO it's a bit more than a Master
22:22 leroe sweet
22:22 leroe germans
22:22 leroe big brains
22:22 leroe :P
22:22 moritz_ (because I did a Master in Scotland, and it was not too tough for me9
22:22 leroe the most common name in germany
22:22 s1n interesting
22:22 leroe in german
22:22 leroe what is it?
22:22 moritz_ s/9/)/
22:23 s1n my degree can't really be helped by sse :)
22:23 s1n master/phd in cs, intelligent system / statistical nlp focus
22:23 s1n i just have to wait, sometimes for a week :/
22:24 moritz_ eek
22:25 s1n churning out a solution quickly with perl means i can spend more time waiting :)
22:35 orafu joined #perl6
22:44 skids joined #perl6
22:57 orafu joined #perl6
23:06 JDlugosz howdy
23:13 JDlugosz Reading S03, what happened to pair methods?
23:15 leroe doesnt randall come to perl6?
23:15 leroe just wondering..
23:19 orafu joined #perl6
23:19 ruoso masak++ # beautifull analogy
23:19 JDlugosz hello again, ruoso.
23:19 ruoso what's up
23:20 donaldh joined #perl6
23:20 jferrero left #perl6
23:20 JDlugosz We were discussing () and ; and had gotten to what is the current understanding of multidimensional array subscripts, compared to how they had been described originally?
23:26 ruoso ok... I think we need TimToady clarification on this... but my guess is that (1,2,3;4,5,6) is the same as ((1,2,3),(4,5,6))
23:29 JDlugosz Anything new concerning their use with subscripts?  Used to be a flat thing that just remembered the mark points, and was somehow the same as a list of streams too.  Got pretty thick.  The above looks like a fundimental enough change that this stuff needs to change too.  Hopefully for the better?
23:32 DemoFreak joined #perl6
23:32 frew joined #perl6
23:33 icwiener joined #perl6
23:34 ruoso JDlugosz, I think that doesn't change anything in the subscripts
23:35 JDlugosz it certainly changes the details.  You think a high-enough level explaination is still the same?
23:36 ruoso well... the major change is that a unflattened list is composed of captures...
23:36 ruoso but as capture implements the list api
23:36 ruoso that isn't much visible
23:37 ruoso and also (depending on how old is your reading of the spec)
23:37 JDlugosz the Positional API for a Capture will see the flattened list, right?  You have to use @@ to see it un-flattened.
23:38 ruoso oh right... you have a very old reading of the spec...
23:38 ruoso ;)
23:38 ruoso there was an earlier change
23:38 JDlugosz age of spec:  I'm comparing the current with March 2008 or so.
23:38 JDlugosz What earlier change?
23:38 ruoso that simplified that... a list is either flattened or unflattened
23:38 ruoso and the subscript will respect that
23:39 ruoso @a and @@a are now two different variables
23:39 lambdabot Maybe you meant: activity activity-full admin all-dicts arr ask . ? @ v
23:39 ruoso and @@a is probably going to be renamed to @%a
23:39 ruoso with the short form as ¢a
23:39 orafu joined #perl6
23:39 ruoso which is the capture sigil
23:40 JDlugosz S03 still describes @@ as a contextualizer.  Ah, but I see @@ is mentioned on sigiled variables.
23:40 ruoso yes... the change from @@a to @%a was not yet materialized
23:40 JDlugosz @% ? Are you joking?
23:40 lambdabot Maybe you meant: . ? @ v
23:41 ruoso no... actually I'm not
23:41 ruoso because @@a was a "slice"
23:41 ruoso but "slice" is too list specific
23:41 ruoso but a capture might contain named values as well
23:41 JDlugosz So if they are really different containers/contexts now, the Capture supports your choice of Positional and Slice as well as Associative.  Much simpler.
23:42 JDlugosz Why call it @% ? Sounds like hash-related.
23:42 ruoso hash or list, depend on how you see
23:43 JDlugosz How does a non-flattened list look like a hash?
23:43 ruoso because a non-flattened list is actually non-flattened capture
23:44 ruoso and capture might look like a hash
23:44 JDlugosz Now that you mention it, I see wording in S03 to the effect that @ are @@ are being separated.
23:44 ruoso yes... this is the earlier change I just mentioned
23:44 JDlugosz So is @% really going to be the context of a Capture?  Or the subset of Capture semantics that just provide both positional and named items ?
23:45 ruoso there's no such thing as "context of a capture"
23:45 ruoso because capture means precisely "no context"
23:46 ruoso so @%foo or ¢foo actually mean "do not enforce any context when dealing with this variable"
23:47 JDlugosz So the ¢ role/sigil/context just does Positional and does Associative, and the impelemtation of that interface on Capture returns non-flattened data.
23:47 ruoso exactly
23:48 JDlugosz exactly? No, your last line said otherwise.  that is, ¢foo has a deeper meaning, is Capture context, what you just said was wrong.
23:48 JDlugosz ¢foo[2] has to mean _something_.  It can't really be context free.
23:49 ruoso ¢foo[2] calls postcircumfix:<[ ]> on ¢foo without enforcing any context *on ¢foo*
23:50 ruoso my ¢foo = bar();
23:50 JDlugosz OK, so in comparison, @foo[2] would do what when calling postcircumfix:<[ ]> on @foo ?
23:50 ruoso the context is not enforced when you use the variable
23:50 ruoso it is enforced when you assign to it
23:50 ruoso my @foo = bar();
23:50 ruoso vx
23:50 ruoso vs
23:51 ruoso my ¢foo = bar();
23:51 icwiener_ joined #perl6
23:51 ruoso my @foo := bar()
23:51 ruoso will still hold unflattened
23:52 ruoso so...
23:53 ruoso sub foo { return (1,2,3),(4,5,6) };
23:53 JDlugosz I would think the ¢foo = bar(); the return capture from the call by STOREing it in the container bound to ¢foo, which is OK because Capture does the role associated with ¢, whatever that will end up being called.
23:53 ruoso my @a = foo(); say @a[3]; # 4
23:53 JDlugosz Likewise, @foo = bar(); as you explained before, doesn't convert or unpack anything either.  The Capture does Positional.
23:53 ruoso my ¢a = foo(); say @a[3]; # fails, since the first dimension only has two elements
23:54 JDlugosz Er, I'm mixing up Item containers and other variables.  Let me try again:
23:54 ruoso my @a := foo(); say @a[3]; # fails, since the first dimension only has two elements
23:55 skids wait, on that last one, wouldn't that make it difficult to bind to a list of lvalues?
23:55 JDlugosz The case I understand:  @x = bar();  will take the Capture returned by bar, and do list assignment between the Array (or whatever it was declared to be) on the left with the thing that does Positional on the right.
23:55 skids (that you want flattened?)
23:55 ruoso JDlugosz, thus generating a flattened list
23:55 JDlugosz That is, it will copy the elements between containers, or the lazy version therof.
23:55 payload joined #perl6
23:57 JDlugosz You said "will still hold unflattened" but the example @a[3]; implies that it is flattened.
23:57 ruoso JDlugosz, see the comment after it...
23:57 skids := vs =
23:58 ruoso skids, re: your earlier question: when you assign @a = @b, @a[0
23:58 ruoso gah
23:58 * skids tries to suss how one would bind a slice of array elements to a list of lvalues
23:58 ruoso skids, re: your earlier question: when you assign @a = @b, @a[0] === @b[0] will be true
23:59 JDlugosz Sorry, still confused.  are you saying the flattening takes place during the list assignment, not in the Positional interface itself?
23:59 ruoso JDlugosz, YES!
23:59 JDlugosz If so, how would list assignment know it's flattenable, and how does it drive it differently?
23:59 ruoso list assignment *always* flatten
23:59 skids ruoso: right, but what if your lvalues are not in Array but List?
23:59 JDlugosz Oh, because you need a new form of list assignment that takes a Capture on the right, not just a Positional.

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

Perl 6 | Reference Documentation | Rakudo