pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, elf: etc.) (or perl6: for all) | irclog: irc.pugscode.org/
Set by Tene on 29 July 2008.
00:25 felipe left 00:35 meppl joined 00:43 hercynium left 00:47 nipotaway is now known as nipotan, larsen_ left 00:50 alester left 00:52 bacek joined
pugs_svn r21975 | lwall++ | [STD] rudimentary global symbol table to detect routine definitions 01:31
01:34 felipe joined
meppl good night 01:36
01:38 meppl left 01:40 eternaleye left 01:46 kanru left 01:54 cookys left, Guest16015 left, nipotan left, integral left, hcchien left, Tene left, r0bby left, Guest16015 joined, hcchien joined, integral joined 01:58 r0bby joined 01:59 r0bby left, r0bby joined, Tene joined 02:00 hercynium joined 02:22 Limbic_Region left 02:26 xinming_ joined 02:27 kanru joined 02:39 xinming left 02:49 rlb3 joined 02:52 alester joined 02:56 Schwern left 03:00 wknight8111 left 03:02 elmex_ joined 03:07 eternaleye joined 03:08 eternaleye left 03:09 eternaleye joined 03:11 rlb3 left 03:16 elmex left, elmex_ is now known as elmex 03:22 Schwern joined 03:24 hercynium left
s1n if i find a parsefail but i'm not sure if it's parrot crashing or rakudo causing it, where do i file it? 03:52
Auzon You can nopaste it to #parrot and ask them what they think. Alternately, just file it under Rakudo, and note your observation. (Unless someone else has a better idea?) 03:53
s1n well, i think it's a bug in rakudo that causes a segfault on parrot
Auzon hm. I'd say rakudobug then 03:54
04:01 bacek left
s1n heh 04:03
pmc_ext = 0xdeadbeef
04:23 bacek joined 05:16 justatheory left 05:17 xinming_ left 05:18 elmex left 05:23 alester left 05:24 xinming_ joined 05:33 Psyche^ joined 05:50 Patterner left, Psyche^ is now known as Patterner 05:58 sri_work_ left 06:04 ashizawa joined 06:05 thestarslookdown joined 06:12 drbean left 06:16 thestarslookdown left 06:28 pmurias joined
pmurias TimToady: what sort of trouble - explain please, only falling back on &postcircumfix:( ) comes to mind 06:31
i have always assumed foo(42) would translate to &foo.postcircumfix:<( )>(42) 06:33
re primitive construct you mean on the language layer or in the VM? 06:34
06:45 masak joined
TimToady how do you then define the () on the end of that call? you get &foo.postcircumfix:<( )>.postcircumfix:<( )>(42) 06:52
and then &foo.postcircumfix:<( )>.postcircumfix:<( )>.postcircumfix:<( )>(42)
masak senses postcircumfix:<( )> all the way down... 06:58
moritz_ perhaps we just have to make the () -> .postcircumfix:<( )> expansion just lazyly, thus avoiding looping... ;-) 06:59
pmurias TimToady: it's a primitive construct in that sense in SMOP the lowlevel Code object just does the invocation instead of calling .postcircumfix:<( )> on itself 07:06
TimToady: to rephrase the question, if I put a custom object into &foo, what does it have to define in order for foo() to work? 07:08
TimToady see S13:156 07:14
moritz_ TimToady: STD.pm doesn't seem to parse anonymous enums 07:15
t/spec/S02-builtin_data_types/enum.t says lives_ok { %hash = enum Ā«:Sun(1) Mon Tue Wed Thu Fri SatĀ»; }, 'french quotes work...', :todo<feature>; 07:16
and STD.pm
Unknown routines: enum called at 27 35 43 51 59 67 85
(that was line 27)
viklund will smart-match between a string and an array of regexes try to match the string against each of the regexes? 07:17
moritz_ I think you need $str ~~ any(@list) for that
viklund (it didn't in Perl 5.010, which supprised me)
moritz_: ahh, thx
moritz_ or $str ~~ all(@list)
or whatever your desired semantics are
TimToady array doesn't imply any() in p6 even where it does in p5
viklund ahh, ok 07:18
TimToady well, that's why I put in the undefined sub code, to find out where it wasn't parsing right :)
moritz_ ;) 07:19
and it doesn't seem to know the pair listop
TimToady does in my copy :) 07:21
and pretty much everything else from Functions.pod... 07:22
pugs_svn r21976 | moritz++ | [STD] updated list of test functions 07:23
moritz_ ohh, too late
if our changes conflict, feel free to disregard mine
is try{...} ok, or does it need disambiguating whitespaces? 07:24
pugs_svn r21977 | lwall++ | Lots of library function calls 07:25
TimToady must have whitespace, and it's got a special rule 07:26
pugs_svn r21978 | moritz++ | [t/spec] system() is called run() now.
TimToady there is no try function
be sure that you have the boolean test right on run
run returns true on success
pugs_svn r21979 | moritz++ | [t/spec] a few disambiguating whitespaces 07:27
moritz_ that test used system() in void context ;)
TimToady which means it should probably throw an exception on failure. :) 07:28
now to figure out why it's not seeing "my &foo" as defining a sub...
moritz_ In this case the test harness will find the failure, I hoope 07:29
pugs_svn r21980 | moritz++ | [t/spec] another s/system/run/
r21981 | moritz++ | [t/spec] some disambiguationg whitespaces 07:31
r21982 | lwall++ | [STD] helps to spell desiglname correctly... 07:33
07:33 thestarslookdown joined
pugs_svn r21983 | moritz++ | [t/spec] more disambiguation whitespaces (and parenthesis) 07:34
r21984 | moritz++ | [t/spec] cleanups in reduce-metaop.t 07:37
07:38 drbean joined
pugs_svn r21985 | lwall++ | [STD] rescue a few more names from gimme5's clutches 07:40
07:41 barney joined
pugs_svn r21986 | moritz++ | [STD] update list of Test.pm functions 07:42
07:43 araujo left
moritz_ "$stuff{a}" will call sub a, right? 07:52
07:53 drbean left
TimToady correct 07:53
moritz_ and it's parsed as a subscript, not as two separate interpolations?
and it's the same in regex? (ie m/$stuff{a}/ ) 07:54
t/spec/S05-metasyntax/litvar.t seems a bit b0rked 07:55
lines 38 to 47
07:56 drbean joined
TimToady yeah, either need to be .<a> or .{'a'} 07:57
or both...
pugs_svn r21987 | moritz++ | [t/spec] correct subscript in regex interpolation in litvar.t 08:00
masak moritz_++ # test suite pumpking 08:01
TimToady several places need to have min and max become [min] and [max] 08:02
looks like STD doesn't parse '=begin END' without a corresponding =end END 08:03
pugs_svn r21988 | moritz++ | [t/spec] brought a bit sanity to wrapping.t. Needs more.
moritz_ TimToady: sounds like it backtracks too much 08:04
TimToady it does less than it used to. :)
getting the scope of a failure just right is tricky 08:05
pugs_svn r21989 | moritz++ | [t] mentioned wrapping.t in TASKS 08:06
08:07 jferrero joined
TimToady still not sure if there should be a 'multi new (Any where not .defined)' to catch all the new Foo calls, or whether we should force everyone to say "new Foo:" 08:08
moritz_ I think 'new Foo' is cute, and many beginners (and Perl 5 programmers) will be disappointed if it doesn't work 08:10
TimToady in any case, the indirect form is currently parsed as a listop, so probably will give bogus undefined errors
yes, and then they'll be entirely confused when "new Foo()" doesn't do at all what they expect 08:11
moritz_ ;) 08:12
pmurias indirect object notation withough arguments is ugly 08:16
TimToady but it is not at all clear that translating "foo $bar" to $bar.foo is a good idea in general 08:21
moritz_ IMHO it's clear that translating 'foo $bar' to '$bar.foo' is in general a bad idea ;) 08:25
pugs_svn r21990 | moritz++ | [t/spec] s/break/last/ 08:35
08:35 pmurias left
TimToady moritz_: break is a valid verb inside a when 08:38
moritz_ d'oh
masak a no-op? 08:39
I mean, a no-op when it's last in a when?
pugs_svn r21991 | moritz++ | [t/spec] revert r21990, TimToady++ moritz-- 08:40
TimToady yes, there is an implicit break at the end of the when 08:42
not sure what to do about does and is
does can be a declarator like trusts, but is is going to conflict with Test
masak can I put a while loop inside a given? what does a break do inside a when then? 08:43
08:43 bacek left
TimToady see S04:710 08:44
08:45 larsen_ joined
pugs_svn r21992 | lwall++ | [STD] add does, break, continue 08:46
masak ok, so it doesn't necessarily break out of the given. 08:48
TimToady (oh, and eager/hyper too) 08:49
08:49 zamolxes left
TimToady hmm, looks like FOO.break() is equivalent to Foo.leave()... 08:50
*FOO rather 08:51
well, can't keep my eyelids propped open anymore, so night all 08:52
have the appropriate amount of fun & # thunk
moritz_ good night TimToady ;)
masak god natt, TimToady 08:54
08:54 thestarslookdown left 08:59 kanru left 09:12 kanru joined, charsba__ joined 09:15 zamolxes joined 09:31 charsbar_ left
pugs_svn r21993 | moritz++ | [t/spec] some more try { ... } rewrites in S12-attributes/delegation.t 09:38
09:43 aindilis` joined 09:48 iblechbot joined 09:52 charsbar joined 09:56 aindilis left 10:01 charsba__ left
moritz_ rakudo: say 4.WHAT.WHAT 10:06
p6eval rakudo 29834: OUTPUT[Intā¤]
moritz_ rakudo: if 4.WHAT eq "Int" { say "yes" }
p6eval rakudo 29834: OUTPUT[yesā¤]
pugs_svn r21994 | moritz++ | [t/spec] quote a type name 10:07
10:11 iblechbot_ joined 10:20 iblechbot left 10:29 iblechbot joined 10:35 wknight8111 joined 10:43 iblechbot_ left 10:53 elmex joined 11:33 meppl joined 11:45 BinGOs left
moritz_ I started with a bunch of blog posts for perl 5 programmers 11:58
11:58 BinGOs joined
moritz_ it's a mixture of "learn perl 6" and "show off cool perl 6 features" 11:58
perlgeek.de/blog-en/perl-5-to-6/
lambdabot Title: blog | Perlgeek.de Blog
moritz_ feedback is welcome ;)
masak first off, moritz_++ for the idea itself :) 11:59
second, I'll get back to you when I've actually read it
moritz_ ;)
masak in a week or so, due to my surfing habits
moritz_ I hope that in a week or so it'll actually 7 posts or so 12:00
masak moritz_: btw, some november is running on feather now
and it's 17 times faster than yesterday :)
moritz_ some are already written, and I plan to finish & publish one perl day
masak viklund++
moritz_ that's great news ;)
masak yes :)
moritz_ s/perl/per/
masak next step: a proper domain name 12:01
any suggestions?
moritz_ perl6-november.org
moritz_ is always bad with names
november-wiki.org
masak likes that
12:04 BinGOs left, BinGOs joined
viklund yes, november-wiki.org seems right 12:04
now all I need to fix is parsing the POST-strings correctly, and then we have a minimal working wiki :) 12:05
masak just like last week :) 12:10
moritz_ so how did you achieve these speedups? precompiling? 12:14
12:15 ruoso joined
viklund moritz_: yes 12:15
--target=pir 12:16
moritz_ then it's also pmichaud++ ;-)
viklund yep 12:17
ruoso TimToady: if postcircumfix:<( )> has (|$capture) as the signature, the invocant of that capture will always be the code itself... once that Method isa Code, this is going to be problematic... it would be better if the call to postcircumfix:<( )> had the actual capture as the first positional argument of that call... so we can have a capture that has an invocant of other type...
viklund pmichaud++ # An extra one 12:18
masak karma target 12:20
@karma target 12:21
lambdabot target has a karma of 0
ruoso TimToady: this is important to SMOP because it's bootstrapping its type system, and the invocant is actually used since a very low-level of the runtime, and it needs to be compatible with the higher-level runtime, so we can use low-level and high-level objects interchangeably
which is, IMHO, the most important feature of Perl 6
er... of the SMOP implementation of Perl 6 12:22
12:23 zamolxes_ joined
ruoso moritz++ the perl6-to-6 posts are awesome 12:28
moritz_ ruoso: thanks 12:29
12:35 Alias_ joined
moritz_ published the next one, on types 12:41
12:42 wknight8111 left 12:44 zamolxes left
moritz_ S03:1700 12:48
(just need the link, and the logs convert that for me ;)
masak (the logs)++
ruoso moritz_: ~~ when comparing with an undefined value always call .^does... which is not just the "recommended" way of checking types, but is actually the "only sane way" of doing it... The only other thing I could think of is $foo.WHAT === $bar.WHAT... but that might result in (1.WHAT === 123.WHAT) beingg false (considering the runtime might have a special type to represent the most common int values... 12:52
.WHAT returns the actual prototype for that value, which might be some lowlevel optimized version of that type
for instance... 1 might be a constant value that allows pointer identity tests (just like constant identifiers do in SMOP) 12:54
and this objects return a different WHAT
moritz_ ruoso: maybe I should emphasize that point more strongly...
ruoso: but otoh it's a tutorial for those who are *not* familiar with all that stuff already, and I don't want to confuse them with too many details 12:55
13:00 ashizawa left 13:01 Alias__ joined, Alias_ left 13:02 ruoso_ joined
ruoso_ hate unstable connections in free software events... 13:02
moritz_ ruoso: would you like to contribute a short article about meta OO programming to that blog? 13:03
ruoso: I don't feel qualified for that ;)
ruoso_ moritz_: anyway... I was trying to say (before my connection died)... that I would argue that .WHAT should not be mentioned as a way to check types... .WHAT is usefull to get a new object of the same type and other prototype things...
moritz_: I'm not sure that's something that should be part of an introdutory document... it will probably scare people away ;) 13:05
moritz_ ruoso_: it's not only introduction, it's also a feature show-off
ruoso_: and .WHAT is useful if you don't know the type names
rakudo: say 1.WHAT
p6eval rakudo 29834: OUTPUT[Intā¤]
moritz_ if you don't know if that thing is called Int or Integer, you call .WHAT on one 13:06
ruoso_ moritz_: but that could return SomeLowLevelTypeThatYouThinkIsAnInt
and that is not even registered in the global namespace
for instance... in SMOP... say 'new'.WHAT will return 'SMOP Constant Identifier' 13:07
moritz_ ruoso_: no. We had that discussion on p6l, and TimToady said that the canonical type should be returned
and if it's an optimization, you have to cheat 13:08
ruoso_ hm... I have to backlog p6l (I not keeping up with the list)...
moritz_ I think it was in the "Rakudo test miscallenae" thread 13:09
ruoso_ but I should warn that I might disagree with that ;)
moritz_ then how would you proceed to obtain the user-visible direct type of an object? 13:11
ruoso_ moritz_: .WHAT 13:12
but the question is why you want the "canonical" type 13:13
instead of checking with ~~
moritz_ introspection
for example writing a debugger
which has the 'dump' command 13:14
ruoso_ er... that's why you have .perl
moritz_ which gives you the .perl output, the reference address (don't know if that's a good idea) and the type
[1].perl won't tell you that it's an Array
you have to *know* that
13:15 cmarcelo joined
moritz_ and you can't assume that a newbie will, for stuff like Captures and Signatures and the like 13:15
ruoso_ but what's the problem of using whatever returned by WHAT?
I mean...
why does it need to be the "canonical" type?
moritz_ nothing, if that is always something that appears in the official type hierarchy
it's pretty useless if it's something implementation specific 13:16
implementation specific stuff should be hidden from the user
and since something that matches \d+ is defined to be an Int, it may not return ImplementationSpecificTinyInt 13:17
ruoso_ I could agree that SomeLowlevelInt should stringify to 'Int'
but the return of the .WHAT need to be the actual type being used by that value...
moritz_ and if SomeLowlevelInt is limited to one byte, can you do my $var_of_same_type = 3.WHAT.new(257) ? 13:18
if you can, I'm happy with that ;)
ruoso_ moritz_: if new($newvalue) is part of the Int API... yes, you can,...
moritz_ ok 13:19
then I have no objections whatsoever
ruoso_ does TimToady have? 13:20
13:22 ruoso left
moritz_ well, if the things returned from .WHAT *behaves* like the canonical thing, you don't see any difference, right? 13:22
ruoso_ btw.... (3.WHAT.new(257).WHAT === 3.WHAT) might return false
moritz_ as long as 3.WHAT.new(257).WHAT eqv 3.WHAT is true... 13:24
ruoso_ hmm...
that is not true...
ah.. wait
hmm...
13:26 wolv joined, wolv left, Alias__ left
ruoso_ moritz_: that's a very hard question... 13:26
because you have two different types that "does" the same canonical type 13:27
moritz_ I'll retract my question ;)
ruoso_ moritz_: do you mean that it doesn't matter?
moritz_ ruoso_: not for me at the moment 13:28
ruoso_ you still agree even if 3.WHAT.new(257).WHAT eqv 3.WHAT is false?
pugs: say Num ~~ Int
moritz_ if there's a sane way to compare the proto objects
p6eval pugs: OUTPUT[ā¤]
ruoso_ moritz_: you should compare the.m against the canonical types.. 13:29
and I think the 'eqv' is not the operator you want...
pugs: say Int ~~ Num 13:30
p6eval pugs: OUTPUT[1ā¤]
ruoso_ pugs: say Int eqv Num
p6eval pugs: OUTPUT[ā¤]
ruoso_ but one way or another... the limitations on the type instrospection of Perl 6 is a very important feature... 13:32
"Something is what it says it is" 13:33
and you check if that something is something by using .^does
moritz_ but what the user somtimes want to know is "do these two objects have the exact same interface?" 13:34
the OO system should be able to answer that question, IMHO
ruoso_ alright... in that case... eqv on the prototype should do it
but it will return false on more cases then expected...
since it's too easy to do mixins and other things... 13:35
moritz_ yes, if stuff are 'but Tainted' or so
ruoso_ and I don't really see the point of asking if they have the "exact same interface".... 13:36
the question is "does it have *that* interface"?
13:38 barney left
moritz_ the question is relevant when you want to know "if I can throw $x into that sub, can I also throw $y into it)? if the type declaration on $x isn't strict enough, comparing the interface/type might be the only way to answer that question 13:38
ruoso_ well... one could argue if the declaration isn't strict enough... you can't really do much inference... 13:40
but yes, eqv on the prototypes could compare the API 13:41
we could even have...
$x.WHAT > $y.WHAT, to see if $y has everything $x has... 13:42
13:42 jferrero left
ruoso_ (> implies int, I know... but you see what I mean, right?) 13:42
moritz_ runs away screaming
isn't that $y.WHAT ~~ $x.WHAT ? 13:43
ruoso_ no...
because ~~ will ask .^does
and if the type declaration isn't strict enough...
it won't
moritz_ so Type1 ~~ Type2 isn't generic "type conformance"? 13:44
ruoso_ yes, it is... but "type conformance" presumes "type declaration"
if the types are not declared... there isn't much you can do... 13:45
we could have a variant of .^can that receives a prototype and checks for the API instead of the type 13:46
ruoso_ just realises that there isn't a way to ask for a prototype in the signature... 13:48
moritz_ prototype in a signature? (/me is confused)
ruoso_ multi method can (Object $object, Undefined Object $prototype) { ... } 13:49
multi method can (Object $object, String $methodname) { ... }
multi method can (Object $object, Object $methodname) { (forces string context on the defined object) } 13:50
moritz_ if all else fails you can use subset types with where { ... }, which allows arbitrary comparisons
ruoso_ oh... 13:51
right
multi method can (Object $object, Object $methodname where { ! $methodname.defined } ) { ... }
multi method can (Object $object, Object $proto where { ! $proto.defined } ) { ... } 13:52
multi method can (Object $object, Object $methodname where { $methodname.defined } ) { ... }
the last two...
moritz_ or simply where !.defined
ruoso_ right... I think it's even an error to use the name inside, isn't it? 13:53
since that's a closure that receives the value on $_
moritz_ I think it's a closure with arity one
so you could say stuff like where -> $a { $a.defined } 13:54
or where { $^a.defined }
but I'm not sure
ruoso_ it makes sense
TimToady: what do you think about having a .^can variant that receives a protoobject and compares if the current object implements all methods present in that protoobject? 13:55
that way, we would simply have... if $y.^can($x.WHAT) 13:56
13:58 ruoso joined
ruoso back using irc over ssh... and closing the web irc client... 13:58
13:59 ruoso_ left
ruoso moritz_: are you happy with the $y.^can($x.WHAT) idea? 14:01
moritz_ dunno really, but no objects atm 14:02
masak++ viklund++ "Christmas never felt that close"
masak :)
that's the feeling you get when developing november
ruoso TimToady: is it ok for .WHAT to return something that stringifies to the canonical type but might be some other type? 14:03
ruoso being a very noisy guy today.. 14:04
14:07 kanru left
ruoso actually blocked by the postcircumfix:<( )> question... ;( 14:10
14:25 Lorn joined 14:32 ggoebel left 14:34 kanru joined 14:39 pmurias joined
ruoso pmurias: hi 14:40
pmurias ruoso: i seem to recall the invocant to methods is passed as the first positionals when methods are exposed as subroutines
ruoso: hi
ruoso: how was the hackathon?
ruoso i'm on it yet...
14:40 rdice joined
ruoso until saturday 14:40
viklund Juerd: I have now redirected wwww.november-wiki.org to 193.200.132.135, what's the next step?
moritz_ I guess you need a virtual host for that 14:41
pmurias you mean you're still on it? 14:42
ruoso pmurias: yes...
pmurias is anyone interested in SMOP? or is it an general Perl 6 one? 14:43
ruoso it's a general Perl 6 hackathon... but so far there isn't much qualified atendees, so it's basically me, myself, and the code ;) 14:44
masak best kind of hackathon, really :) 14:45
moritz_ not really :/
masak actually, it very much depends.
ruoso I'd be happy to introduce the code to new people... 14:46
pmurias: btw... aout the invocant... do you see what I mwan about the problems of having the capture to postcircumfix:<( )> as the actual capture to the code? 14:47
s/aout/about/
s/mwan/mean/
and why it would be important to have it as the first positional argument instadd? 14:48
pmurias i see, but i think postcircumfix:<( )> should stay the way it is methods may implement a call method or something 14:50
ruoso but Method isa Code 14:54
and in the end, it needs to get the correct capture
and it needs to call .() 14:55
unless method.call re-implements what's currently implemented in COde 14:56
and that would be a shame
although it will probably need to override it anyway to provide "self" closure... 14:57
pmurias i can't find it in the log but i think methods take the none-Method invocant as their first positional if used as subroutines 14:59
ruoso btw... I'm planning to implement self as a closure that returns the invocant and is declared in the scope of the method... 15:00
pmurias $method.($invocant,$pos1,$pos2,....)
ruoso pmurias: yes... but that's not the case here...
pmurias: actually... you're confusing... 15:01
it was the method dispatch fallback to subroutines that did that
when you were calling a subroutine as a method it would do it
[particle] which no longer happens
ruoso exacly
but anyway... the .() call needs to receive the method as the invocant... so we need to hide the actual capture as a positional argument of that capture 15:02
pmurias [particle]: S12:1039
ruoso so the invocant of the actual call can have a different type
pmurias: I think that's just something that wasn't updated yet... 15:03
[particle] yep, that should be updated. specbug
ruoso but the whole "moving things to Any" was supposed to get rid of the sub fallback
but anyway... 15:04
the thing is...
15:05 zamolxes_ left
ruoso the signature for .() should be ($code: $actualcapture) 15:05
instaed of (|$capture)
so the actualcapture can have another invocant defined
which , in method, will be the actual object
since the Metaclass will need to call .() on the method after it finds which method to call 15:06
pmurias &foo(42) would be really &foo.postcircumfix:<( )>(:(42))? 15:07
masak pmurias: how would that help you? 15:08
ruoso &foo.postcircumfix:<( )>(\(42)) actually
masak then you just have another pair of unexpanded parentheses
15:08 viklund left
ruoso and $foo.bar(42), in the end will mean &bar.postcircumfix:<( )>(\($foo: 42)) 15:09
pmurias masak: we need a way to pass an invocant to a method and ruoso proposes that postcircumfix:<( )> should take a capture as the only positional 15:10
ruoso pmurias: I think masak was referring to your use of : instead of \ to create the inner capture
masak pmurias: ok, so you actually don't run into infinite regress? 15:11
ruoso masak: no, because we have low-level objects that cut the loop
but they behave like highl-level objects
masak ruoso: no, I was referring to the fact that one pair of parentheses was expanded to a postcircumfix and another pair
ruoso: ah, ok
ruoso pmurias: in fact, I don't think it's actually possible to do it other way 15:13
pmurias ruoso: we can pass the real invocant (that is $foo in $foo.bar(42)) as a positional
ruoso but then we need to modify the capture... encapsulating it is easier... 15:14
we actually would need to modifiy the capture twice
15:14 sri_work joined
ruoso in SMOP, the capture is even readonly 15:16
lunch &
pmurias why are you oposed to having the capture as first positional variant as CALL? 15:17
ruoso well... because Method isa Code
it is supposed to use the same api 15:18
15:18 ggoebel joined
ruoso and even subroutines may declare a signature with an invocant 15:19
pmurias no they can't
15:20 Exodist joined
ruoso pugs: sub a ( $foo: $bar) { say $foo }; my $c = \("a", 1); a(|$c); 15:20
p6eval pugs: OUTPUT[*** Missing invocant parameters in '&a': 0 received, 1 missingā¤ at /tmp/xBCulDQXs5 line 1, column 54-60ā¤]
ruoso pugs: sub a ( $foo: $bar) { say $foo }; my $c = \("a": 1); a(|$c);
p6eval pugs: OUTPUT[*** No compatible multi variant found: "&a"ā¤ at /tmp/xT3i7d2JFt line 1, column 54-60ā¤]
ruoso really lunch & 15:21
15:21 jhorwitz joined 15:28 kolibrie left 15:30 hercynium joined 15:39 ruoso left 15:44 jan__ left 16:04 zamolxes joined 16:06 ruoso joined 16:08 jan__ joined
ruoso pmurias: re: invocant in subroutine signatures -- is it actually in the spec? or is it just reasonable thinking 16:11
16:11 sri_work_ joined 16:12 sri_work left
pmurias ruoso: it's (vague) irc recollection 16:13
16:17 eternaleye_ joined 16:22 eternaleye left
ruoso alright... I'll implement a method CALL on both Code and Method that receives the capture as the positional argument 16:36
then we decide if postcircumfix:<( )> is changed to be the same as this
16:39 eternaleye_ left 16:40 eternaleye_ joined
ruoso or maybe I should change postcircumfix as an exercise 16:41
of the concept
pmurias: is there support for the capture construct in m0ld already? 16:43
16:43 xinming joined 16:55 xinming_ left 17:10 zamolxes left
pmurias ruoso: sorry was afk 17:22
ruoso: you can call Capture.new
ruoso Capture.new returns an empty capyture 17:23
but I used the SMOP__S1P__Capturize... that returns the capture it receives
it can't be used with captures that have an invocant set 17:24
since the invocant is the Capturize RI
moritz_ an empty Capture is pretty useless, since Captures are immutable
so you always only get \() with that
ruoso \() is not that unusual 17:25
pmurias ruoso: we can have a different constructor Capture.other_constructor($invocant,...)
ruoso pmurias: I was talking about the current capture.new in smop
capture.new could be implemented... 17:26
17:26 masak left
ruoso just realised that his new connection has a transparent proxy that doesn't work wiht svn 17:27
pmurias i hesitate to extend m0ld with things that are not strictly nessesary
ruoso: any way to circumvent the proxy? 17:29
ruoso not that I'm aware of... 17:31
17:32 fridim_ joined
ruoso trying to get the event organizers to remove the proxy 17:34
17:36 pmurias left 17:41 justatheory joined 17:44 justatheory left, justatheory joined
pugs_svn r21995 | ruoso++ | [smop] experimenting the alternative signature for postcircumfix:<( )> 17:51
17:52 aindilis` left, aindilis` joined 17:55 sitaram joined
TimToady aims his eyeballs at the puddles of brane on the floor, but there's nothing left to think about the puddles with... 18:13
18:13 zamolxes joined 18:14 sitaram left 18:15 pmurias joined
pmurias TimToady: how do you think should the problem of passing the invocant to Methods be solved? 18:16
18:17 ruoso left
TimToady stares at puddles of brane 18:18
18:19 ruoso_ joined
TimToady the migraine doesn't help 18:19
ruoso_ gah... other connection issue... back to web chat
ruoso_ wonders if that means that it's not a good day to pester TimToady with boring questions... 18:22
18:23 [particle] left
TimToady is fine with boring questions, except to the extent that ruoso thinks brain pretzels are boring... 18:23
ruoso_ heh 18:24
18:27 ruoso_ left
pmurias TimToady: do we still have method to subroutine fallback? 18:28
TimToady no 18:29
we're trying to keep the two dispatchers very distinct these days
subject to pragmatic control, as always 18:30
but $foo.bar means something rather different from bar($foo)
if $foo contains a "foreign" object, it call .bar in foreign land 18:31
but bar() dispatches to bar in Perl land
this is why infix:<eq> is a multi, not a method 18:32
pugs_svn r21996 | moritz++ | [t] more s/system/run/
TimToady otherwise we can't rely on coercive semantics for eq, ==, etc
and to the extend we wish to use the same definition for both a method and a multi, we encourage use of "is export" 18:33
which basically just deletes the : from the signature
but that implies that methods know how to receive their invocant as the first parameter if invoked as a sub 18:34
unless we use some kind of wrapper, which would suck 18:35
so probably there's some way to construct a Capture where the invocant is really the first positional parameter 18:36
pugs_svn r21997 | moritz++ | [t] more rewrite of try { ... }; ok($!) to dies_ok
18:37 [particle] joined
TimToady but if smop demonstrates another way to think about it, I'll try to think about it 18:38
in any case, once you've got a ref to a Routine, there has to be a consistent way to call it, and that's probably the same way that the single-dispatcher calls individual methods as if they were subs 18:40
shower &
18:41 araujo joined
pugs_svn r21998 | moritz++ | [t/examples] some more fixes caught by STD.pm 18:42
r21999 | moritz++ | [t/examples] s/system/run/ 18:44
r22000 | moritz++ | [t] more try{...} fixes 18:47
18:47 luqui joined
pugs_svn r22001 | moritz++ | [t/oo] more s/system/run/ and try{...} fixes 18:51
18:51 StephenPollei left 19:09 apeiron joined 19:12 Claud joined 19:13 rdice left 19:14 Claud left 19:15 [particle] left, [particle] joined
pmurias TimToady: i think S12:1030 needs the fallback edited out then 19:28
pugs_svn r22002 | moritz++ | [STD] added builtins exists and delete 19:30
19:34 eternaleye joined
pugs_svn r22003 | moritz++ | [t/spec] remove usage of try as a function 19:39
r22004 | moritz++ | [t/spec] remove bogus tests 19:45
19:47 eternaleye_ left 19:57 lisppaste3 left 19:58 lisppaste3 joined
speckbot r14576 | larry++ | remove failover from methods to subs 19:58
20:03 larsen_ left
pmurias TimToady: is $a.infix:<*>($b) equivalent to $a * $b 20:12
moritz_ I don't think you can have infix operators as methods
pmurias S12:321 20:13
S12:327 actually
wolverian screams something about multimethods and breaks down
moritz_ that looks... hairy 20:14
pmurias is trying to clarify possible speckbugs before we implement them
20:15 luqui left 20:18 rindolf joined 20:19 wknight8111 joined 20:20 dolmen joined
TimToady it's possible that explicit use of syntactic categories forces use of the appropriate dispatcher 20:21
20:21 StephenPollei joined, tulcod joined
tulcod hey. when can i possibly expect perl 6 to be released? will it take a month, 6 months, a year, two years or four years? 20:21
[particle] tulcod: yes. 20:22
tulcod :)
moritz_ ;-)
my expectation is about 2 years
tulcod no but seriously. how far are the guys?
[particle] we're done with the first 80%, and well into the second 80%.
moritz_ [particle]: I wanted to quote that too
Auzon Is there a third 80%?
[particle] we hope not, auzon. 20:23
moritz_ [particle]: you're too fast ;)
tulcod okay then. and i guess the implementations will be ready by then too?
moritz_ I don't think it's realistic to expect the specs to be finished without an implementation
[particle] tulcod: there are several implementations that are useable for trivial things, and some that are useable for less trivial things
tulcod moritz_, [particle]: heh, okay :) 20:24
[particle] recently there has been a wiki written in rakudo (a perl 6 implementation running on parrot)
tulcod [particle]: yeah, i heard about rakudo. a wiki sounds crazy
proof of concept, "look guys, our perl interpreter really does work!" 20:25
?
moritz_ yes
tulcod overkill :P
moritz_ and "optimized for fun" ;)
[particle] just yesterday rakudo's test suite was sped up tremendously
moritz_ why overkill?
[particle] from 8m to 2m40s
tulcod moritz_: for me, hello world would have sufficed to show that their interpreter works... but i guess that's just my fault then ;) 20:26
moritz_ rakudo: say "hello, world"
p6eval rakudo 29834: OUTPUT[hello, worldā¤]
[particle] tulcod: rakudo passes 2200 tests from the official perl 6 test suite
pugs passes thousands more
moritz_ tulcod: hello world is too trivial to impress anybody
tulcod [particle]: ALL 2200 tests? or are there more?
moritz_ there are about 20k tests
tulcod haha 20:27
moritz_ and more to be written
[particle] there are currently ~20,000...this time moritz is too fast :)
tulcod well, still not bad, for a language which doesn't even have a real definition yet :P
Auzon tulcod: rakudo.de has a nice graph of the test passing progress
lambdabot Title: Rakudo - A Perl 6 Compiler
tulcod Auzon: cool, thx
hm. parrot is a well-defined and "standardized" language rgiht now? 20:28
TimToady the definition is most certainly real. It's just that it's also incomplete, and wrong. :)
moritz_ so far I haven't found a good other use for that domain ;)
tulcod: parrot is a virtual machine, not a language
[particle] tulcod: spec.pugscode.org/ has the perl 6 "definition", such as it is
lambdabot Title: Official Perl 6 Documentation
tulcod moritz_: a virtual machine based on a parrot language, right?
moritz_: like, it's not just an x86 vm 20:29
moritz_ tulcod: no, a platform independent vm
[particle] parrot's written in c89
tulcod moritz_: yes, but the stuff that runs ON it is written in, or at least compiled to, "parrot" language right?
[particle] the language is called pir 20:30
moritz_ tulcod: parrot runs a byte code, called PBC. There are also two assembler languages that parrot understands
tulcod exactly :)
moritz_ tulcod: so there's not "one" parrot language, but more of them
tulcod okay then
[particle] the other language is pasm, which is human-readable bytecode
tulcod spasm?
Auzon Parrot Assembler, correct? 20:31
moritz_ parrot assembler
tulcod so... do those languages have a complete definition now, then? 20:32
or are they still WIP too?
moritz_ they are work in progress, but still very usable
[particle] they are basically complete
parrot 0.7.0 was released tuesday
pmurias is the instruction set finalised? 20:36
moritz_ no
[particle] mainly finalized 20:37
all the design documents are done
but the implementation of some is still incomplete 20:38
implementation may drive design changes, of course
all the *funded* design documents, which includes the nine major subsystems 20:39
speckbot r14577 | larry++ | Clarification that categories change the choice of dispatcher on method names
moritz_ counts 10 design documents in docs/pdds/draft/
[particle] looks like only the nci document might impact the instruction set 20:41
TimToady tulcod: Google has demonstraed via its "eternal beta" approach that being a WIP and being useful are not mutually exclusive :)
tulcod TimToady: that was not what i was doubting, but thanks for your attention :)
[particle] already parts of perl 6 are written in perl 6 20:42
TimToady okay, but I just get the feeling that the definition of these things may never be "complete" in the sense that you're asking it...what do you mean by "complete"? 20:44
20:44 eternaleye left
TimToady a language designed to evolve can never in a sense be complete 20:45
it can only be "good enough for now"
and we freely admit that Perl 6 ain't good enough for now :) 20:46
(sorry for the rant--I'm just allergic to either/or thinking these days...:) 20:47
tulcod TimToady: as am i. but at some point, developers must be able to stabilize stuff
TimToady: and you can only make an app stable if you have a definition of what it should do. and if that definition changes daily.... 20:48
[particle] the definition of perl 6 changes infrequently as of late
however, it's in a state of continuous refinement
and this will never stop
TimToady most apps would never hit the corner cases where we're doing the simplifications these days 20:49
and most of the changes are driven by the desires of implementors
20:50 eternaleye joined
TimToady commuting & 20:53
pmurias tulcod: you have to implement an app to see what it does ;) 21:06
tulcod pmurias: ah, tricky ;)
where's the program which generates a program which behaves exactly as defined in a human-readable language definition? 21:07
metaprogramming level 2
Auzon I think some of them are connected to this room via IRC.
jhorwitz did he just describe PCT? ;-)
moritz_ an accurate human language description would be much longer than the implementation in any sany programming (unless for a few mathematical problems and the like) 21:08
[particle] sany := sane + zany
or in perl 6, sane|zany
tulcod hehe 21:09
moritz_ no, sane&zany
tulcod there is more than one way to do it ;)
21:22 eternaleye left 21:24 donaldh joined 21:35 tulcod left 21:39 pmurias left 21:51 Limbic_Region joined 21:52 hercynium left 22:33 jhorwitz left 22:42 BinGOs left 22:47 armagad joined, armagad left
japhb TimToady: ping 22:57
Or heck, I'll just ask the question: Has the license of Perl 5 ever changed since the first Perl 5 release? Are you currently planning to keep the Perl 5 license unchanged for the rest of its days? 22:58
23:03 donaldh left 23:09 cmarcelo left, eternaleye joined 23:11 Lorn left
Limbic_Region japhb - presumably you have read perlbuzz.com/2008/04/the-problem-wi...nsing.html which points to use.perl.org/~Shlomi+Fish/journal/36050 ? 23:20
lambdabot Title: The problem with "same terms as Perl" licensing - Perl Buzz, tinyurl.com/5hdojz
23:22 krunen left, Exodist left, kanru left, drbean left, Guest16015 left, kane_ left, idemal left, yves left, broquaint left, cls_bsd left, wknight8111 left, elmex left, r0bby left, felipe left, agentzh left, yath_ left, bloonix left, pengrate_ left, Gothmog_ left, Juerd left, frobnitz left, japhb left, perlbot left, jrockway left, ingy left, pochi left, funktio left, wknight8111 joined, Exodist joined, kanru joined, elmex joined, drbean joined, r0bby joined, Guest16015 joined, felipe joined, agentzh joined, krunen joined, ingy joined, broquaint joined, yves joined, funktio joined, pochi joined, idemal joined, cls_bsd joined, kane_ joined, Gothmog_ joined, frobnitz joined, jrockway joined, japhb joined, pengrate_ joined, perlbot joined, bloonix joined, Juerd joined, yath_ joined
Limbic_Region hrm - lost half the world 23:23
Limbic_Region will repeat himself just in case
japhb - presumably you have read perlbuzz.com/2008/04/the-problem-wi...nsing.html which points to use.perl.org/~Shlomi+Fish/journal/36050 ?
lambdabot Title: The problem with "same terms as Perl" licensing - Perl Buzz, tinyurl.com/5hdojz
23:23 aindilis` is now known as aindilis
japhb Limbic_Region: yes, some time ago. I don't entirely agree with his analysis, but in any case, I specifically wanted to know about Perl *5*'s past and future. 23:29
23:29 cotto_w0rk is now known as cotto_work
japhb When people complain about ambiguity, there's "real ambiguity" and then there's "theoretical ambiguity". 23:30
23:34 Exodist left 23:38 rindolf left 23:54 Jedai left 23:56 [particle]1 joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!