pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, smop: etc.) || We do Haskell, too | > reverse . show $ foldl1 (*) [1..4] | irclog: irc.pugscode.org/
Set by TimToady on 25 January 2008.
zamanfou is now away: In the rain my tears are forever lost. 02:50
pugs_svn r21422 | Auzon++ | [gsoc_spectest] added tests to return.t and fudged for rakudo. (added 6 tests) 04:48
Auzon pugs/t/spec/S04-statements/return.t is ready for spectest_regression
moritz_ re 09:07
Patterner hbock 09:21
rakudo_svn r29647 | moritz++ | [rakudo] add S04-statements/return.t to spectest_regression, Auzon++ 09:25
r29647 | moritz++ | +12 pass, +2 skip
masak moritz_: could you clarify to me what the advantage of fudge-skip is? 09:34
moritz_ masak: rakudo doesn't die if a test is skipped and it tests a not-yet-implemented feature ;) 09:35
masak and what happens once the feature is implemented?
moritz_ if it executes, and just yields the wrong results, a TODO is better
masak: we run autounfudge.pl ;-)
and hope it catches the skips 09:36
masak ah, that's new to me
masak checks out autounfudge.pl
cool! 09:37
now the picture is clearer to me
moritz_: thanks
moritz_ I just started it, and it found one passing todo test in S02-builtin_data_types/anon_block.t 09:38
masak autounfudge.pl++ 09:45
moritz_ thanks ;) 09:47
pugs_svn r21423 | moritz++ | [spec] unfudge a few tests for rakudo, autounfudge++ 10:13
masak moritz++ 10:15
rakudo_svn r29648 | moritz++ | [rakudo] add S04-statements/given.t to spectest_regression. Auzon++ 10:31
moritz_ perlbot: karma Auzon 10:32
perlbot Karma for Auzon: 137
zamanfou is now away: In the rain my tears are forever lost. 11:07
pmurias ruoso: hi 11:58
ruoso pmurias, hi 11:59
pmurias i'm still unsure if the object representation should store the metadata in a special way 12:00
ruoso: would a 'use v6' for switching from c to perl6 would be a good idea? 12:02
ruoso would it be easy to parse?
pmurias if we do it the pythonic way, easy
ruoso what do you mean? by using indentation? 12:03
pmurias ues
* yes
did a mockup even 12:04
ruoso seems fine to me 12:05
pmurias should the object representations be interchangable? 12:06
ruoso pmurias, yes... 12:10
pmurias, that's the entire point... you should be able to freely interchange WHAT/HOW/REPR
moritz_ @tell Auzon when you fudge files ready for inclusion into spectest_regression, just /msg or @tell me, I'll add them when I'm online again 12:12
lambdabot Consider it noted.
moritz_ @tell Auzon thinking a bit more, just adding a note in the commit log is also enough, since I read all your commit messages (big moritz is watching you ;-) 12:13
lambdabot Consider it noted.
ruoso pmurias, the REPR api is not implemented as a completely separated object because that requirement would be too much arbitrary... meaning... if you implement p5hash as a REPR you would have the methods and attributes being managed in a entirely different way... 12:18
pmurias, and having it as an explicit API makes it easier for non-p6opaque representations to be implemented.
pmurias under the current design (on the wiki) a metaclass instance needs to be available to interpret the metadata 12:23
ruoso yes... 12:25
the metaclass is REPR independent
because of the REPR API
pmurias what i would make sense would be to have the repr api seperated as a set of roles, the most basic providing only attribiute storage and .dispatch forwarding, others stuff as vtables
* what i think would
ruoso pmurias, oh sure... sure... nothingmuch had pointed me that direction before... 12:26
moritz_ pmurias: re v6.pm in evalbot: no. Would you benefit from it?
ruoso I think we lack the level of maturity to properly define this hierarchy
pmurias moritz_: not really 12:27
ruoso: we can just split it into basic and advanced for now ;) 12:28
ruoso pmurias, heh...
nothingmuch have some ideas about that...
pmurias what's the multi argument form of ``? 12:54
moritz_ in p5? 12:55
open()
pmurias in p5, it's unspeced in p6
moritz_ open $handle, '|-', @args or die $!; local $/; my $data = <$handle>; close $handle 12:56
or something along these lines 12:57
but I can never remember if it's |- or -|
pugs_svn r21424 | pmurias++ | [smop] sm0p.pl turns use v6;p6 code... into frame = q:sm0p {...} 13:04
pmurias moritz_: i just stuck it into a nearby open3 13:05
pugs_svn r21425 | moritz++ | [spec] fixed POD 13:14
r21426 | moritz++ | [spec] more pod fixes 13:16
moritz_ doesn't see a perlfix:sym<\> anywhere in STD.pm 13:18
is it simply missing? or is it handled as a separate term?
pmurias you can run STD on \1?
moritz_ how do I do that? 13:19
ruoso pmurias, btw... about repr-api-hierarchy... I think the most basic one is the support for private storage. That should be enough to implement a pure-prototype-oo... 13:21
moritz_ moritz@lara:~/pugs/src/perl6>echo '\1;' > test.t 13:22
moritz@lara:~/pugs/src/perl6>./tryfile test.t
Starting...
############# PARSE FAILED #############
----> <<<HERE>>>\1;
ruoso pmurias, I think we should create a directory inside smop to document all the roles then... 13:24
pugs_svn r21427 | pmurias++ | [smop] how a "a basic" p6opaque will look like 13:26
masak ok, so t/spec/S12-class/inheritance-class-methods.t passes in rakudo if I shuffle a few lines around in the class definitions. should I commit that? 13:27
moritz_ masak: that depends on wether the order of declarations is being tested for
ruoso pmurias, are you planning to store the methods and attribute definitions in the storage itself? 13:28
pmurias ruoso: yes creating such a directory would make sense
masak moritz_: not in this particular test, no
pmurias ruoso: in the most basic case yes
moritz_ masak: the canonical answer is "yes, but make sure the failing behaviour is tested somewhere"
masak moritz_: I submitted a bug report for it
but I guess I could write a test as well, if needed
moritz_ masak++
ruoso pmurias, how would you answer to "defined"?
moritz_ masak: another test is always good ;-) 13:29
pmurias a defined bit maybe ;)?
masak writes the test
ruoso pmurias, hmm...
pmurias or just see if the metadata is present like in the previous scheme
ruoso pmurias, you mean having it as a separated slot from the storage? 13:30
pmurias $objcje.^!private_storage('^METADATA').defined
* $object
ruoso pmurias, I think it might be ok to implement it that way in p6opaque for now... 13:31
pmurias, but that should not be exposed as the REPR API
masak hm, I use lives_ok when something is syntactically correct but likely to fail, right? 13:32
pmurias exposed meaning part of the REPR API?
ruoso yes
pmurias, and I'm not sure about having "defined" inside "metadata", because you will require every object to have a metadata, even if it's a plain instance of a single proto-object 13:33
in the previous schema, the object was "defined" when it had a private storage...
and usually the prototypes would only have a metadata storage 13:34
(considering the restriction to avoid Object.BUILDALL() making undef defined
pmurias, what do you think about the following... 13:35
has Hash $.metadata; has Hash of Hash $.private_storage
pugs_svn r21428 | masak++ | [declaration_order.t] new test file testing order-independent class declaration 13:40
r21429 | masak++ | [inheritance-class-methods.t] changed around the order of class declaration 13:41
r21429 | masak++ | due to a bug in rakudo, you must currently declare the base class first
r21429 | masak++ | the tests now run in rakudo
ruoso pmurias, then you'd have $obj.^!private_storage.{$package}{'$!a'} and $obj.^!metadata.{'methods'}
but we could then expose the API in more detailes...
like having a $obj.^!methods that would do the hash lookup directl
moritz_ masak: please use - to separate words in file names
masak oops
moritz_ masak: we're slowly moving to that conventioin (or at least try to)
masak moritz_: I remember the thread, but forgot the conclusion :/ 13:42
I just saw that all the other test files in that folder used _
moritz_ yes :(
ruoso pmurias, but I would still keep an "instanceof" to allow "diret delegation to a single prototype" which, afaics, is the most common case... 13:43
pugs_svn r21430 | masak++ | dashes, not underscores
masak moritz_++
ruoso pmurias, what do you think?
moritz_ maybe I should change the file names in one big rush in both the test suite and in rakudo's test files 13:44
but then again I should coordinate that with other people first ;-)
pmurias_ got sucked in some stupid blog posts from chromatics stupidity column 13:45
ruoso where where? 13:46
pmurias ruoso: where where refered to? 13:46
moritz_ suspects use.perl.org/~chromatic/journal/ 13:47
lambdabot Title: Journal of chromatic (983)
ruoso pmurias, the blog post? 13:48
pmurias, but... what do you think on what I've proposed? 13:49
pmurias from planet.perl.org
the difference is slight
actually it was the top one from planet.parrotcode.org 13:50
ruoso: i don't think we should add convenience methods to the representation object 13:52
ruoso what do you mean "conveinence"? 13:53
*convenience
pmurias, you mean .^!methods is convenience? 13:55
pmurias methods which don't add any functionality but make some thing more convenient
yes 13:56
ruoso pmurias, the convenience in this case is the REPR api
the thing is we don't need to force every object repr implementation to implement a full Hash of Hash to access each method... 13:57
pmurias a Hash of Hash is equivalent to a Hash
ruoso p6opaque is designed in a way that .^!methods looks like convenience, but that might not be the case for other implementations
p5blessedhash, for instance... 13:58
pmurias the .^methods as currently wikied wouldn't map to perl5 methods
ruoso pmurias, I should update .^!methods to be Hash of Array of Method 13:59
pmurias p5blessedhash would have to use AUTOLOAD (or lowlevel equivalent) and redispatch to .how.dispatch
ruoso pmurias, yes... but .how.dispatch would need to ask the p5blessedhash for the methods 14:00
considering you implement a protoobject in p5...
I think the point of confusion here is about class-based × prototype-based OO 14:01
pmurias but the p5blessedhash would store them as any other data 14:01
ruoso pmurias, not really... it would look at the 'ref' the hash has, and look the methods available for that package... 14:02
then you can have a mixed hierarchy of protoobjects of different representations... 14:03
pmurias p5blessedhash would be incompatible with a lot of metaclasses 14:04
ruoso why would it?
pmurias if the metaclass has a different dispatching order 14:05
ruoso I didn't get it 14:06
the "methods storage" is "used by" whatever metaclass
the REPR is not responsible by the dispatch 14:07
pmurias has to think 14:08
ruoso the repr delegates the dispatch to the how, the ho looks up the methods using the REPR api, and make the call
s/the ho /the how/
ruoso drawing a sequence diagram 14:10
pmurias can only find contrived examples of metaclasses not assuming a method list 14:17
pugs_svn r21431 | ruoso++ | [smop] sequence diagram on the invocation 14:19
r21432 | ruoso++ | [smop] ops, the last call was coming from the wrong object
ruoso pmurias, take a look at doc/InvocationSequence.png 14:20
ruoso pmurias, this example would be a pure-prototype-oo case 14:22
ruoso I also need to say that I'm in favour of making the default implementation for P6 prototype-based (by delegation...) 14:23
because class-based OO makes it very hard to adopt different dispatching mechanisms... Class::C3 × Single inheritance × whatever 14:24
if we make the protoobject the storage for the metadata, we can have a metaclass instance that is transversal to the entire hierarchy
and, more importantly, that can be easily replaced 14:25
pmurias, do you see what I mean? 14:28
pmurias yes
lunch& 14:29
ruoso TimToady, would it be ok for a Perl 6 implementation to make the built-in types Prototype-based-by-delegation instead of class-based? 14:32
TimToady, or is 'class-based OO' part of the spec for the builtin types? 14:33
pmurias TimToady is away for a couple of days for OSCON 14:36
moritz_ but I guess he'll have internet access there, from time to time ;-) 14:37
the last documented design minutes where 2008-06-11 - d'oh 14:38
ruoso pmurias, after all the reasoning, what do you think about p6opaque structure? 14:51
pmurias i would go for having .^!methods and .^!attributes (and perhaps .^!metadata) as separate roles with the default implemenation using .^!private_storage 14:53
ruoso and storing "isa", "does" etc as part of the private_storage? 14:55
pmurias unless the representation overides that 14:55
ruoso so you mean making .^!storage.{'^METADATA'}.how as *the* REPR API 14:57
ruoso renaming private_storage simply to "storage"...
pmurias dunno, ^!how might be better 14:58
ruoso and so for .^!storage.{'^METADATA'}.{'methods'}, doesn't it... 14:58
I mean... 14:59
you said Role, and I agree with you
if some representation doesn't support methods, it *doesn't support* them
it means that the how needs to fetch the methods elsewhere
ruoso and not that the how is going to traverse some hash to fetch it 15:00
ruoso or... 15:00
it might mean that you have a pure-prototype-oo
with no delegation
and that your methods are slots in the private_storage 15:01
and your metaclass is aware of that
ruoso and in that case, this metaclass would be incompatible with other metaclasses 15:02
which is the syntax to specify the type of the key in a Hash? 15:03
pmurias Hash of something 15:04
ruoso that's for the value
pmurias ah key
my Any %hash{Str}; 15:05
ruoso ahm...
that doesn't solve my problem...
pmurias that's the default hash
ruoso I have a
Hash{Package} of Hash
pmurias my Hash %hash{Package} 15:06
ruoso but how do I put that into a Signature?
(as the return value, I should say)
pmurias is just looking up stuff from s* not from memory 15:07
zamanfou is now away: In the rain my tears are forever lost.
ruoso hate public away notices... 15:08
pmurias zamanfou seems to live in a rainy climate
ruoso: what's the benefit of not supporting methods if the can be supported (emulated) by storing stuff in private_storage 15:09
moritz_ and in a very verbose climate, if (s)he minds telling us all status changes 15:10
ruoso pmurias, because that would make your metaclass incompatible with representations that do have a way to support methods
ruoso lunch &
ruoso brb & 15:11
pmurias what i meant is that the emulation happens at the repr level, the metaclass just calls .^!methods
rakudo_svn r29654 | moritz++ | [rakudo] fiddled with spectest_regression: 15:16
r29654 | moritz++ | - added S12-class/inheritance-class-methods.t, masak++
r29654 | moritz++ | - fixed typo in name of S12-class/anonymous.t, jonathan++ for implementing
rakudo_svn r29655 | moritz++ | [rakudo] whitespace fixes in spectest_regression.data 15:23
pmurias fixing my mountain bike& 15:35
Auzon thanks moritz_ :) 17:49
lambdabot Auzon: You have 2 new messages. '/msg lambdabot @messages' to read them.
Auzon moritz_: for some reason, the progress graph isn't updating on rakudo.de (or anywhere else that I've seen) 17:51
pugs_svn r21433 | fglock++ | [v6.pm] requires perl 5.8.6 18:00
pmurias ruoso: do you agree with what i'm proposing? 18:33
pmurias ruoso: i'm not sure myself, so i'll implement it and will see if it's a good scheme 18:59
does anyone have examples of usefull custom metaclasses?
pmurias j 19:17
moritz_ Auzon: yes, pmichaud didn't update spectest-progress.csvn for a while 19:59
Auzon I didn't know if it was that or the cronjob not working 20:00
moritz_ svn info languages/perl6/docs/spectest-progress.csv |grep Date
Last Changed Date: 2008-07-15 16:01:39 +0200 (Tue, 15 Jul 2008)
pmurias is tempted by a elf rewrite 20:08
Auzon Why/ 20:08
pmurias beind constantly hindered by little bugs and misdesignes 20:10
* misdesigns
pugs_svn r21434 | Auzon++ | [gsoc_spectest] moved leave.t into spec, changed $?BLOCK to &?BLOCK, other cleanup 21:25
Auzon I could've sworn that Rakudo had a basic implementation of leave. 21:26
moritz_ control exceptions are still on the ROADMAP
return() being the notable exception
Auzon on a side note, leave() is really cool, especially with being able to travel up multiple levels. 21:27
Auzon It's a good way to tangle up code if you're not careful, but most powerful constructs are like that. 21:28
moritz_ and &?BLOCK is cool for recursion into anonymous blocks ;-) 21:29
Auzon and @?BLOCK for recursion into the parent block.
moritz_
.oO( @?BLOCK[(^@?BLOCK).pick].() )
 21:31
Auzon I can't even imagine what use that would be. Maybe obfu :) 21:32
moritz_ none at all, probably 21:33
but it looks really nice ;-)
Auzon Why is it (^@?BLOCK) instead of just @?BLOCK ? 21:34
moritz_ because it's too late and I'm playing chess at the same time ;-) 21:34
@?BLOCKS.pick().()
[particle]1 try en.wikipedia.org/wiki/Chess_boxing 21:35
lambdabot Title: Chess boxing - Wikipedia, the free encyclopedia
Auzon @?BLOCKS.pick().() would be the same as &?BLOCK() for some types of recursion... 21:35
moritz_ for some ;-)
Auzon @?BLOCKS.unique.pick().() # ;) 21:37
(assuming that .unique does what I mean)
moritz_ I don't think there's a builtin .unique 21:38
Auzon Nope, I checked
moritz_ probably because it encourages usage of the "wrong" data structure
does @?BLOCKS contain the lexical or the dynamic calling blocks? 21:39
ah, lexical, otherwise the ? twigil would be wrong
so no need for unique at all
Auzon also, @?BLOCK[0] === &?BLOCK 21:40
moritz_ but that's the same for both lexical and dynamic scopes
Auzon Ok, makes sense. I guess. ;) 21:41
[particle] @?BLOCKS.pick.clone.() 21:42
ruoso going home & 21:44
[particle] who needs closures remembering state, anyway? 21:46
moritz_ continuations? ;-)
[particle] if i'm picking blocks at random, might as well make sure i get consistently inconsistent results 21:47
moritz_ when you call srand() first you might get a nice obfu from it

Powered by Cro and the Raku® Programming Language.

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

Thank you!