Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6, 2008-01-10

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:05 __pao__ left #perl6
00:19 silug joined #perl6
00:46 thoughtpolice joined #perl6
01:10 cnhackTNT joined #perl6
01:13 meppuru good night
01:20 lyokato_ joined #perl6
01:24 dalek joined #perl6
01:24 Tene [particle]: looking at dopplr... interesting...
01:27 araujo joined #perl6
01:47 japhb doc/ops:  This is your brain over easy with a side of hashbrowns ...
02:03 mncharity it looks like perl5rx is a plugin for rx only, rather than being an alternative to the perl5 backend.
02:08 pbuetow joined #perl6
02:24 drbean_ joined #perl6
02:32 drbean joined #perl6
02:46 pugs_svn r19401 | rhr++ | [Unicode.pm] canonical composition
02:53 drbean_ joined #perl6
03:19 arxc joined #perl6
03:25 jjore joined #perl6
03:37 overdrive joined #perl6
03:39 buubot joined #perl6
03:42 buubot joined #perl6
03:49 alc joined #perl6
03:57 felipe joined #perl6
04:21 fridim_ joined #perl6
05:33 matisse_enzer joined #perl6
05:43 matisse_enzer Hi folks - I recently set up a buildbot  (see http://buildbot.eigenstate.net:8040/) to poll the perl6 SVN repo and build parrot when changes are committed, and I'm wondering if anyone here s a committer and could commit some trivial change to https://svn.perl.org/parrot/trunk and/or https://svn.perl.org/parrot/branches/pdd17pmc
05:54 TimToady most of the parrot committers hang out on #parrot at irc.perl.org
05:54 TimToady here are mostly pugs committers
05:58 Andy_ joined #perl6
05:58 matisse_enzer thanks - I will (and did) check #parrot - only two souls there :)
05:58 matisse_enzer I will try again another time.
05:59 meppuru joined #perl6
05:59 Auzon Try #parrot on irc.perl.org
06:00 Auzon That's where it's supposed to be
06:00 matisse_enzer ahh, I forgot - someone told me that and  forgot. Thanks.
06:00 Auzon No problem
06:01 matisse_enzer left #perl6
06:42 devogon joined #perl6
07:54 Aankhen`` joined #perl6
08:09 iblechbot joined #perl6
08:14 asprillia joined #perl6
08:31 jferrero joined #perl6
08:47 asprillia joined #perl6
09:36 jferrero joined #perl6
09:50 jferrero joined #perl6
10:00 jisom joined #perl6
10:02 arxc_ joined #perl6
10:02 njbartlett_ joined #perl6
10:13 ruoso @tell mncharity re why yap6 instead of per5v6: One of the more important performance killers in kp6 is the fact that it builds a heavy runtime in top of the perl5 runtime which is not lightweight also. YAP6 tries to implement a Perl 6 compatible runtime directly in C, so no overhead is needed. The idea is that yap6 can implement directly all the semantics of Perl 6
10:13 lambdabot Consider it noted.
10:14 ruoso TimToady, I've been thinking, and I realised that bare $obj.HOW(); returning a proxy object is not a good idea. Because sometimes you need to use the metaclass in its own context, considering its a generic one
10:15 ruoso and in the proxy case, I can never get the metaclass object as it really is
10:16 ruoso I mean, $obj.^can() puts $obj as the invocant,
10:16 ruoso it makes sense to be able to call my $a = $obj.HOW(); $a.foo(); where the invocant for foo is the generic metaclass
10:17 ruoso so perhaps it is a better idea to force the invocant declaration when using HOW instead of ^ to represent object-related metacalls
10:17 ruoso like
10:17 ruoso $obj.^methods(); should be the same as $obj.HOW.methods($obj: );
10:18 ruoso because, if the metaclass is an object by itself also, It may have other methods...
10:19 ruoso for instance, if the metaclas is also the responder interface (in nothingmuch's terms)
10:20 ruoso which is the case in YAP6
10:22 ebassi joined #perl6
10:22 drrho joined #perl6
10:29 masak joined #perl6
10:38 njbartlett_ joined #perl6
10:42 nothingmuch ruoso++ # i feel appreciated =)
10:44 ruoso nothingmuch, btw... did you take a look in yap6?
10:44 ruoso I would really appreciate your review in the design I'm implementing...
10:44 ruoso the NOTES_* files and the include/*.h files are already related to this latest revamp
10:46 nothingmuch i'll have a look when I finish my crazy work load
10:46 nothingmuch if I don't respond by like monday or something feel free to /msg or email or something and bitchslap me about it =)
10:46 ruoso nothingmuch, noprob... I'm still working in the .h files
10:46 ruoso and I'll probably not finish it until the weekend anyway
10:47 ruoso and I'll only get to the C code itself, when I finish the public .h files (the ones in include)
10:47 nothingmuch if you wanna braindump a short spiel on how it's not like $something_else_i_should_know_about that might take less time
10:47 ruoso Well, the braindump is the NOTES_BOOTSTRAP.txt file
10:47 ruoso it's a quite short note
10:48 ruoso http://svn.pugscode.org/pugs​/v6/yap6/NOTES_BOOTSTRAP.txt
10:48 ruoso in the case you don't have it checked out
10:48 nothingmuch ah, ok
10:49 nothingmuch i'll read that now
10:49 nothingmuch i have it checked out (pugs) but I haven't ran svk up -s in like... months. maybe years =P
10:49 ruoso heh
10:49 nothingmuch so this is like an OO VM in C?
10:49 ruoso btw, where you see dispatcher, you should read prototype
10:49 ruoso nothingmuch, yes
10:50 ruoso not quite VM
10:50 ruoso but runtime library
10:50 ruoso actually
10:50 ruoso after I started to play with the stack
10:50 ruoso I should call it vm anyway
10:50 nothingmuch read up on scheme -> C
10:50 nothingmuch there are many many interesting things those guys did
10:50 ruoso ok, I'll search for it
10:50 nothingmuch those lambda heads are smart cookies
10:50 ruoso any special url?
10:50 nothingmuch i'll find something specific for you in a sec
10:53 nothingmuch fwiw, metaclass should be polymorphic
10:53 nothingmuch and it should almost always be completely masked by a responder interface
10:54 nothingmuch which in turn can be a very simple vtable of c funcs and a pointer to some data
10:54 nothingmuch much like perl's mg structure, but without the linked list stuff
10:54 ruoso http://svn.pugscode.org/pugs​/v6/yap6/include/yap6_base.h
10:54 ruoso I kinda mixed the metaclass and the responder interface
10:55 ruoso the metaclass is the reponder interface in YAP6
10:55 nothingmuch how come?
10:55 ruoso when I get to the C level,
10:56 ruoso the MetaClass is a special kind of object
10:56 nothingmuch let me rephrase
10:56 ruoso that also have a struct member named MESSAGE
10:56 ruoso which handles the request
10:56 nothingmuch it's essentially an RI
10:56 nothingmuch MESSAGE == dispatch
10:57 ruoso yep, but it also plays the role of the metaclass
10:57 ruoso in the Perl 6 land
10:57 nothingmuch that's an abstract object of it's own though
10:57 nothingmuch with it's own responder interface
10:57 ruoso sure
10:57 ruoso which may be itself
10:57 ruoso I mean
10:58 ruoso some metaclass can be the responder interface for itself
10:58 nothingmuch well, i don't see the difference, except that you renamed RI to metaclass ;-)
10:58 ruoso heh
10:58 nothingmuch oh, of course
10:58 nothingmuch but the instance slot is different
10:58 ruoso in theory the metaclass is the RI and the Object Layout at the same time
10:58 nothingmuch how is that possible?
10:58 ruoso it knows how the objects it handles are laid out
10:59 ruoso in the C level
10:59 nothingmuch unless you are making prototype based derived metaclass instances
10:59 ruoso it's kinda recursive, yes
10:59 nothingmuch object layout should be encapsulated in a low level constructor method, there is no need for the VM opcode dispatcher guy to ever know anything about that
11:00 nothingmuch (void *)
11:00 ruoso nothingmuch, yes... that's why it's delegated to the metaclass
11:00 nothingmuch errm, again, all of this is defined as the responder interface stuff =)
11:00 nothingmuch the metaclass is simply what is boiled down to the responder interface
11:00 nothingmuch it's an object that knows how to make responder interface objects
11:01 nothingmuch there are a few core responder interface types
11:01 nothingmuch that can be used to implement other, more arbitrary responder interfaces
11:01 nothingmuch by telling your compiler what C code to generate for a specific RI you can, of course, extend these "core" types for performance
11:02 nothingmuch but a metaclass object should have nothing to do with runtime (except for reflection)
11:02 nothingmuch unless it just so happens to be conveinent, but that's on a case-by-case implementation detail
11:02 ruoso hmmm
11:02 nothingmuch i don't see the practical benefit of joining these two types
11:02 * ruoso trying to parse that
11:02 nothingmuch a little more exemplifying:
11:03 nothingmuch a core responder interface is the flat, by name method table
11:03 nothingmuch there are C functions for a hash or a trie or something
11:03 nothingmuch that maintain pointers to the code objects of the class this is implementing
11:03 ruoso ok...
11:03 nothingmuch the dispatch method (also written in C) will search by name, and then open a new stack frame and goto the code object
11:03 nothingmuch I'll use perl5 terms to illustrate for clarity
11:04 ruoso that's what I plan to do for the native types
11:04 ruoso for instance
11:04 nothingmuch so basically it's a table of CVs indexed by name
11:04 nothingmuch and the responder interface table has a pointer to the C function ri_named_method_table_dispatch ( SV* invocant, SV* invocation );
11:04 nothingmuch that returns the thunk object
11:05 nothingmuch which the interpreter can evaluate
11:05 ruoso yes, that's what I'm doing for the native and lowlevel types
11:05 nothingmuch anyway, in the event that you want to implement a custom responder interface
11:05 nothingmuch then that responder interface is an object
11:05 nothingmuch whose responder interface is this low level type
11:05 ruoso yes... ok... so my metaclass is the RI
11:05 nothingmuch (Fwiw there can be a number of low level RIs, like indexed vtables which don't use strings at all, or ones that use a more dynamic structure, for example)
11:06 nothingmuch the metaclass is a highlevel object
11:06 nothingmuch that is instantiated by the compiler
11:06 ruoso I mean, the metaclass in yap6_base.h
11:06 nothingmuch the syntax of the class is converted into method calls on this metaclass
11:06 nothingmuch and when it's time to dump everthing to disk the metaclass creates any number of responder interfaces, and saves them in the current compilation unit,
11:06 ruoso what I did was that the responder interface type is *also* a high-level object
11:07 nothingmuch the compiler will dumb down the known "core" responder interfaces
11:07 nothingmuch yes, of course it is =)
11:07 nothingmuch that is, if the metaclass created a MethodTable->new( methods => { %methods } ) responder interfaces
11:07 nothingmuch the compler will know how to take apart the abstract responder interface
11:07 nothingmuch and dumb it down into it's low level C counterpart
11:07 nothingmuch that's how the bootstrapping was designed to happen in MO
11:07 nothingmuch there is a registry of known responder interfaces
11:08 nothingmuch and routines to dumb them do
11:08 nothingmuch wn
11:08 nothingmuch that are intimately involved with the VM
11:08 ruoso well... in fact...
11:08 ruoso YAP6 metaclass *is* MO responder interface
11:08 nothingmuch but responder interface from perl 6's pov are impelmentation independant, they are jsut datatype conventions
11:08 nothingmuch OK, so that's what I thought =)
11:08 ruoso :)
11:08 ruoso ok... but now looking to the Perl 6 level
11:09 ruoso $obj.^methods() is a call to the responder interface, right?
11:09 nothingmuch right, so from the perl 6 level, the compiler also knows how to proxy methods back into perl space
11:09 nothingmuch the mapping from the abstract MethodTable object to the low level C object is bidi
11:09 nothingmuch (prolly the core types are readonly to simplify this, and the original object is just cached as well)
11:10 ruoso exactly... the Stack type for instance (yap6_stack.h) defines itself as closed and final
11:10 ruoso so it can have a custom RI that handles it in the C level
11:10 nothingmuch right
11:11 nothingmuch it appears to me like you have it nailed
11:11 ruoso :) good to hear that from you ;)
11:11 nothingmuch the whole poitn of MO was that language support entails implementing a very simple set of responder interfaces
11:11 nothingmuch please make this easily addable to perl5  too ;-)
11:11 ruoso well.. I know that adding perl5 to this is easy
11:11 ruoso the other way I'm not sure
11:12 nothingmuch with all the optree rewriting we've been doing in moose land, if i can make a custom method dispatch delegate to this rI object in perl 5 maybe we can get "real" OO
11:12 nothingmuch what do you mean by the other way?
11:12 ruoso I can get a SV YAP6 metaclass
11:12 ruoso but I'm not sure how I could get a YAP6 ri inside perl5
11:12 nothingmuch ah
11:13 nothingmuch as long as Object can encapsulate an SV *
11:13 nothingmuch then that should be enough
11:13 nothingmuch lemme dig something up
11:13 nothingmuch http://use.perl.org/~jjore/journal/34643
11:13 lambdabot Title: Journal of jjore (6662)
11:13 nothingmuch using josh's trickery you can replace the method call opcode's implementation for specific objects
11:13 ruoso cool
11:14 nothingmuch and make it delegate to an RI instead of use perl's builtin mechanism
11:14 nothingmuch granted, we only get one type of Invocation object (by name, with a list of args)
11:14 nothingmuch but that's still pretty cool
11:14 nothingmuch the opcode would call sdispatch
11:14 nothingmuch and the thunk type would be just a CV *
11:14 ruoso That is *REALLY* cool
11:14 nothingmuch since we can assume things about the invocation
11:14 nothingmuch which means native MO for perl 5
11:15 nothingmuch without having to use AUTOLOAD
11:15 nothingmuch for custom RIs
11:15 ruoso and transparent integration between libyap6 and libperl5
11:15 nothingmuch *nod*
11:15 ruoso in both ways
11:15 nothingmuch bidi is just a matter of wrapping SV's in the perl5-native responder interface
11:15 nothingmuch which delegates back to the original method call code in perl
11:16 * ruoso very happy to see the pieces getting together
11:16 nothingmuch =)
11:16 nothingmuch so one nit: for clarity consider renaming MetaClass to ResponderInterface ;-)
11:17 ruoso Ok...
11:17 nothingmuch oh
11:17 nothingmuch one more thing
11:18 nothingmuch in the core please make sure that you can cheat certain objects out of their box
11:18 nothingmuch that is, it should be trivial to autobox an INT type lazily
11:18 nothingmuch pointing to a global, shared responder interface
11:18 ruoso This is something I'm trying to figure out
11:18 ruoso in yap6_native.h
11:19 nothingmuch this requires static analysis
11:19 nothingmuch where you compile different variants
11:19 nothingmuch so that no type info has to be carried around anymore
11:19 ruoso I'm considering having a "native" method in the responder interface (a high-level method, I mean)
11:19 nothingmuch what do you mean?
11:19 ruoso well...
11:20 ruoso Perl 6 defines that native types are closed and final
11:20 ruoso and that their representation can't be changed
11:20 nothingmuch yeah
11:20 ruoso so, I can know that if it's a native int, I can use a low-level C structure that I defined for it
11:20 nothingmuch exactly
11:20 ruoso but the thing is,
11:21 nothingmuch this is much simpler than it sounds from what you have to do
11:21 ruoso but
11:21 nothingmuch it's the compiler writers problem
11:21 ruoso Int means anything that does Int
11:21 nothingmuch just make it easy to skip the Object type
11:21 nothingmuch you're forgetting that the compiler is allowed to cheat =)
11:21 nothingmuch when it knows that ref($x) eq Int, nto that $x->isa("Int"), then it can do that
11:21 ruoso that's why I'm planning a "native" method that must return the YAP6 native type
11:21 nothingmuch it has two RIs that pretend to be the same RI
11:22 ruoso yes... sure... but that's optimization
11:22 nothingmuch the compiler just has to make sure that instead of doing obj->responder_interface->dispatch( obj ) it does native_responder_interfaces[type]->dispatch(  obj );
11:22 nothingmuch err
11:22 ruoso I mean
11:22 nothingmuch instead of obj in the last one it should be low level int
11:23 ruoso yes yes..
11:23 ruoso if I can know, in the C level, that this object is handled by a known responder interface
11:23 ruoso I can cheat
11:24 ruoso but what I mean, is that the design must allow the responder interface to be something you don't know
11:24 ruoso that's why I'm saying it's optimization...
11:25 nothingmuch erm, no, it's simpler =)
11:25 nothingmuch just make sure the C typing is such that you can push around void *
11:25 nothingmuch again, it's the compiler writer's problem to codegen the right code
11:25 ruoso yes yes...
11:25 ruoso YAP6 design today is loosely typed
11:25 nothingmuch for example, imagine the function sum { $^x + $^y }
11:26 nothingmuch that would codegen to an optree
11:26 nothingmuch with an inlined method call optree
11:26 nothingmuch that points to a function with an alt type
11:26 nothingmuch there is an easy way to reason about this not needing to be complicated
11:26 Alias_ joined #perl6
11:26 nothingmuch like, for example, if your Int type is infinite
11:27 nothingmuch you can still codegen a naive, native int using version
11:27 nothingmuch do you know the psyco project?
11:27 ruoso psyco? I don't think so
11:27 nothingmuch the basic idea is that you have mmd based type specialization
11:28 nothingmuch for clarity i'll use hs type notation
11:28 nothingmuch factorial :: Int -> Int -> Int
11:28 nothingmuch Factorial int -> Int -> Int
11:28 nothingmuch factorial int -> int -> Int
11:28 nothingmuch factorial Int -> int -> Int
11:28 nothingmuch factorial int -> int -> int
11:28 nothingmuch ad nauseum
11:28 nothingmuch the "root" factorial is a multimethod that jumps to these variations
11:28 nothingmuch which are compiled lazily based on the arguments
11:28 ruoso ah yeah... sure...
11:28 nothingmuch if the types in the call site are statically known at the time of the call
11:29 nothingmuch then the specialized version can be used instead
11:29 nothingmuch so Int -> Int -> Int is a slow, OO based version
11:29 nothingmuch wheras int -> int -> int is just the native C impl f a factoriaal function with the native int type
11:29 nothingmuch it will be used when the return value type cannot handle the overflow anyway
11:30 ruoso considering every Perl 6 op is mmd
11:30 ruoso this is a mandatory design requirement
11:30 nothingmuch any factorial function that returns an Int must check for overflows, too
11:30 ruoso I'm already with my eye on it...
11:30 nothingmuch and might eventually point to Int -> Int -> Int
11:30 ruoso I still didn't actually plan how the mmd will work...
11:30 ruoso but I think it fits in the RI
11:30 nothingmuch anyway, it hink this is the best optimization approach for inlining/etc
11:30 nothingmuch that's TBD
11:31 nothingmuch the core RIs don't even need to support RI in yap6
11:31 ruoso TBD?
11:31 nothingmuch to be decided
11:31 ruoso ah
11:31 nothingmuch MO's core inspiration was that new cool stuff was invented every week
11:31 nothingmuch if we design semantics for MMD
11:31 nothingmuch and in 5 years they turn out to be problematic
11:31 nothingmuch it's trivial to natively support a new type very cleanly
11:31 nothingmuch and 'use 6.1' will enable that by default, lexically
11:32 nothingmuch the Invocation and the ResponderInterface just have to agree amongst themselves
11:32 nothingmuch ditto for what I dubbed "concepts" in MO -- roles, class features, etc
11:33 nothingmuch did you look at how AGs were done?
11:33 nothingmuch there's no hack level at all, except for optimization's sake
11:33 ruoso for now, every responsability is let to the RI in YAP6
11:33 ruoso I think MMD will be also RI responsability
11:34 nothingmuch exactly =)
11:34 ruoso AG?
11:34 nothingmuch since the method call is a higher order object (or at least there's the possibility of that), you can extend
11:34 nothingmuch attribute grammars
11:34 ruoso ah...
11:34 nothingmuch http://nothingmuch.woobling.org/bro​wse_code?r=MO;a=headblob;f=/t/ag.t
11:34 lambdabot Title: darcs - MO, http://tinyurl.com/225b69
11:35 nothingmuch this doesn't have to know anything about the runtime to Just Work, it's the other benefit of the two staged approach
11:35 nothingmuch the same AttributeGrammar metaclass (or meta role or whatever) can be mixed in to your metaclasses
11:35 nothingmuch the same implementation that is
11:35 nothingmuch and it'll work regardless of the VM
11:36 nothingmuch if you're dilligent enough to support AGs natively in the VM it can be faster
11:36 nothingmuch but that is totally optional
11:37 * ruoso parsing...
11:38 nothingmuch bottom line: the less you define in the VM core (eg. libyap6) the more extensible it is
11:38 nothingmuch that was the point i was trying to illustrate
11:38 ruoso well..
11:38 nothingmuch MO::Run is all about finding the minimum usable prototype meta OO system thingy that is:
11:38 ruoso besides the native types
11:38 nothingmuch a. extensible
11:38 nothingmuch b. possibly fast
11:39 ruoso everything is design by contract
11:39 ruoso and I don't even have declared C types for that
11:39 ruoso that will be implementation specific
11:39 ruoso and that's why I'm focusing in the public/*.h files
11:40 nothingmuch *nod*
11:40 nothingmuch i think you have it in the right direction
11:40 ruoso if you take a look in includes/yap6_stack.h
11:40 nothingmuch just note that $responder_interface->dispatch doesn't actually dispatch
11:40 nothingmuch it returns a thunk object
11:40 nothingmuch that can be evaluated or not
11:40 nothingmuch this is important because it makes a generic ->can much easier to implement
11:41 nothingmuch in retrospect I should have made the thunk not close over the invocation, but instead get it as an argument
11:41 nothingmuch that would make it easier to do in C too
11:41 nothingmuch but it's a minor change
11:41 ruoso I was thinking about that in the way to here today...
11:41 nothingmuch one sec
11:41 nothingmuch let me svk up
11:41 ruoso if there will be a $ri->call or a $ri->resolve->call
11:42 nothingmuch $ri->dispatch($object, $invocation)->($object, $invocation) # conceptually
11:42 nothingmuch it doesn't really matter how
11:42 nothingmuch ->call or whatever
11:43 nothingmuch in perl 5 terms, the method call operator will be kinda like $obj->can($method)->( $obj, @args) every single time
11:43 nothingmuch if the thunk type is low level and known (e.g. it's a simple pointer to a CV) then the runtime can easily do interesting things with it
11:43 nothingmuch without breaking responder interface encapsulation
11:44 ruoso yehah..
11:44 ruoso I think everything fits...
11:44 nothingmuch if ( $thunk->is_static && $responder_interface->metaclass->is_cl​opsed_and_final_and_everything_is_fine ) { $self->inline_into_current_optree($thunk) }
11:44 ruoso but please take a look at the include/*.h files
11:44 nothingmuch svk up still running =)
11:44 pbuetow joined #perl6
11:44 ruoso :)
11:45 nothingmuch i think that yap6 is a too perl 6 specific named for this, fwiw
11:45 nothingmuch this is really much more general then that
11:45 ruoso nothingmuch, well.. there's the stack thing
11:46 nothingmuch reading right now
11:46 ruoso that makes it more perl 6 specifc
11:46 nothingmuch hmm
11:46 nothingmuch that's not mandatory though
11:46 nothingmuch it's just "a" stack, not "the" stack, right?
11:47 nothingmuch this is a library for building OO virtual machines more than anything IMHO
11:47 ruoso yes, although the Stack prototype is closed and final
11:47 ruoso even if you can have several stacks
11:47 ruoso they all must be of the same type
11:48 nothingmuch huhmm
11:48 nothingmuch interesting
11:48 ruoso hmmm
11:48 ruoso wait
11:48 nothingmuch well, you don't have to use this particular stack at all, if it doesn't work for you
11:48 ruoso in fact, no, they don't
11:48 nothingmuch that's all I'm saying ;-)
11:48 ruoso The stack is already a high-level type
11:48 ruoso and as it's design by contract
11:48 nothingmuch i like stack_eval's polymorphism
11:49 nothingmuch it's in effect a polymorphic run loop
11:49 nothingmuch you can plug in several virtual machines as long as they can eventually give back control at some point
11:49 nothingmuch and you can proxy values back and forth as long as the vms' respective object boxes are useful enough
11:49 ruoso hmm... I didn't think about interfacing the perl 5 stack directly
11:50 ruoso but it is possible
11:50 nothingmuch (like, for instance, if they use yap6 ;-)
11:50 nothingmuch no, nto that far
11:50 nothingmuch i meant something less ambitious
11:50 nothingmuch just have a stack nodes with heteroegenous opcodes
11:51 nothingmuch though you could theoretically make the stack object a proxy that merges several other stacks or something
11:51 nothingmuch too many details involved in this though
11:51 nothingmuch to really know in advance
11:51 ruoso it obviously depends on the embedding hability of the other vm
11:51 nothingmuch yeah
11:52 ruoso but it's possible by yap6 side
11:52 pbuetow joined #perl6
11:52 * ruoso needs a coffee, in despair
11:54 * nothingmuch is on the phone to
11:58 pmurias joined #perl6
11:58 pmurias ruoso: what do you mean by a generic metaclass?
11:58 lambdabot pmurias: You have 1 new message. '/msg lambdabot @messages' to read it.
12:00 njbartlett_ joined #perl6
12:01 jferrero joined #perl6
12:05 nothingmuch ruoso: i have to work some
12:05 nothingmuch it looks like a very good general direction
12:05 nothingmuch just recite a minimalism mantra in your head whenever you seem confused =)
12:05 pmurias joined #perl6
12:06 pmurias joined #perl6
12:10 pmurias @tell mncharity it should pararelise ok, you have to get used to mp6 (i.e. not make syntax errors as it's a slow compiler) and you can only bootstrap once you finish the backend
12:10 lambdabot Consider it noted.
12:12 IllvilJa joined #perl6
12:15 riffraff joined #perl6
12:19 ruoso nothingmuch, I need to compose a mantra then... I'm getting confused too often
12:19 ruoso :)
12:20 nothingmuch "less is more" =)
12:20 ruoso heh
12:20 nothingmuch in OO especially
12:20 nothingmuch the less you define the more polymorphism you get
12:20 nothingmuch of course, you might eventually end up with nothing if you go too far ;-)
12:20 ruoso hehe
12:21 moritz_ .oO( my OO system is undef )
12:21 ruoso hehehehe
12:21 masak joined #perl6
12:21 ruoso pmurias, re generic metaclass: if a metaclass handles more than one class
12:22 pmurias i thought $foo.HOW() is distinct for each class
12:22 ruoso well, it is in the spec, but what I was saying is that it is not a good idea
12:23 ruoso although in the call you enforce the proper context
12:23 ruoso that's what $dog.^methods does
12:23 ruoso it calls methods in the metaclass, but enforces $dog as the invocant
12:23 ruoso as I was saying
12:23 ruoso $dog.^methods should be the same as $dog.HOW.methods($dog: )
12:23 ruoso and not juts $dog.HOW.methods()
12:24 nothingmuch .HOW can appear to be distinct even if it really isn't using a simple ref
12:24 nothingmuch i'm pretty sure that's the original intent
12:24 ruoso yeah... but the problem
12:24 nothingmuch "can be" != "always is"
12:24 ruoso what can I do when I want to use the metaclass in its own context
12:24 nothingmuch sometimes "always is" is really just "can be" with a little masquerading
12:24 ruoso instead of some object class context
12:25 nothingmuch expl?
12:25 meppuru joined #perl6
12:25 nothingmuch wait, no
12:25 nothingmuch don't explain
12:25 ruoso for instance...
12:25 nothingmuch i have to work ;-)
12:25 ruoso ok
12:25 ruoso you can backlog later
12:25 nothingmuch explain to pmurias ^_^
12:25 ruoso I'll post it here
12:25 * nothingmuch has a very very busy next few days ahead of him
12:25 nothingmuch i doubt I will get to it
12:25 nothingmuch but I can check on the results
12:25 nothingmuch or /msg me if you have some conclusive link or reference
12:26 ruoso everything is design by contract... so your metaclass may be something you know to do something more than the standard meta api
12:26 ruoso if the metaclass is an object in itself...
12:26 ruoso how do you call a method in the context of that object
12:26 ruoso ?
12:26 ruoso if $dog.HOW returns a proxy that keeps the reference to $dog, as to pass it as the invocant
12:26 pmurias ruoso: in the context means?
12:27 pmurias ruoso: i don't suggest $dog.HOW returns a proxy
12:27 ruoso suppose $dog.HOW retuns an object that I know to have another method
12:27 pmurias $dog.HOW.another_method
12:28 py77 joined #perl6
12:28 ruoso ok, now... consider the metaclass can be generic
12:28 ruoso how can you do my $a = $dog.HOW;  $a.methods
12:29 ruoso if $a don't have a reference to $dog
12:29 ruoso $a.methods should be $a.methods($dog: )
12:29 ruoso explicitly
12:29 ruoso to implement it in the way it is in the spec,
12:29 pmurias ruoso: only if you have per object methods
12:29 ruoso pmurias, per-prototype
12:30 ruoso remember that $dog can be a prototype
12:30 pmurias prototypes are undefined objects
12:30 ruoso or class, if you name it that way
12:30 ruoso no... a class is a prototype object
12:30 pmurias ruoso: i view it diffrently
12:30 * ruoso getting the piece of spec that states it
12:33 ruoso take the beggining of the "class" section in s12
12:34 pmurias ruoso: use line numbers please
12:34 ruoso it's the first section
12:34 ruoso I'm seeing it in the browser
12:34 ruoso no line numbers (at least in my browser)
12:34 ruoso the thing is,
12:35 ruoso even if some mop uses a metaclass per class
12:35 ruoso this doesn't means that every mop should do it
12:35 pmurias the standard one uses a metaobject per class
12:36 ruoso 'A "class" object is just considered an "empty" instance in Perl 6, more properly called a "prototype" object, or just "protoobject"."'
12:36 pmurias The actual class object is the metaclass object pointed to by the
12:36 pmurias C<HOW> syntax.
12:37 pmurias ;)
12:37 ruoso in a class-based mop
12:37 ruoso but prototype-based mop is also supported
12:38 pmurias than there is a diffrent HOW per object
12:38 pmurias * different
12:39 * pmurias always spell diffrent differently ;)
12:47 ruoso pmurias, "(For a prototype system (a non-class-based object system), all objects are merely managed by the same meta object.)" in s02
12:47 ruoso in the definition of the HOW function
12:49 cmarcelo joined #perl6
12:53 pmurias ruoso: the metaclass should take object as a parameter than
12:53 pmurias * metaobject
12:56 pmurias why do you call the metaobject the metaclass
12:56 pmurias ?
12:56 ruoso I don't know... bad habits ;)
12:57 ruoso I argue that the object (or prototype) is the invocant for the metacalls
12:57 ruoso as $dog.^methods() is the same as $dog.HOW.methods($dog: )
12:57 thoughtpolice joined #perl6
12:57 pmurias you need to invocants then
12:58 pmurias s/to/2/
12:58 ruoso pmurias, not exactly
12:58 ruoso what I have is a two phase dispatch
12:58 ruoso I get the method from the $dog.HOW object,
12:58 ruoso and execute it passing $dog as the invocant
12:59 pmurias it's curring
12:59 ruoso the thing is that all methods are already dispatched by the metaclass
12:59 ruoso the metaclass doesn't need to be in the arguments
12:59 pmurias * metaobject
13:00 ruoso heh... yeah... metaobjecgt
13:01 ruoso $dog.HOW.methods is really $dog.HOW.can("methods").call($dog: )
13:01 ruoso while $dog.^methods is simpler...
13:01 ruoso if I keep it that way, I can call things in the metaobject without the object's context
13:01 ruoso like...
13:02 ruoso my $a = $dog.HOW(); $a.foo; places $a as the invocant to foo
13:03 ruoso and $a.methods() would probably return the same as $a.^methods()
13:04 pmurias there are also bootstraped metaobjects
13:04 pmurias got to work&
13:04 ruoso lunch&
13:06 polettix joined #perl6
13:25 ispy_ joined #perl6
13:33 Psyche^ joined #perl6
13:53 drrho joined #perl6
14:15 iblechbot joined #perl6
14:18 braceta joined #perl6
14:19 braceta joined #perl6
14:20 pbuetow joined #perl6
14:30 jhorwitz joined #perl6
14:35 masak joined #perl6
14:44 alc joined #perl6
15:06 ircuser joined #perl6
15:07 ircuser Hi all, is there some perl6 book available?
15:08 Alias_ A couple, they might be out of date a bit though
15:08 moritz_ Perl6 and Parrot Essentials was open-sourced the other day
15:08 ircuser Because the syntax change too much?
15:08 moritz_ not only syntax ;)
15:09 moritz_ well, depends on what you call "syntax", actually
15:09 moritz_ ircuser: what do you want that book for? Perl 6 design philosphy? or learning Perl 6?
15:09 lorn joined #perl6
15:09 ircuser moritz_ good question the 2th
15:10 njbartlett_ joined #perl6
15:10 ircuser but if perl6 need to be changed a lot i will wait for a "final book"
15:10 ruoso HAH! Now I had an important breakthrough
15:10 ruoso the problem I facing is that what I've been calling metaclass (which is actually the responder interface),
15:11 ruoso is not the metaobject and not the prototype
15:11 ruoso there's one of that methods missing, we need a WHO
15:11 ruoso which returns the responder interface
15:11 moritz_ ircuser: even p5 doesn't have a "final book"
15:12 ruoso and the responder interface is an object that is a C structure that is always binary compatible with a fundamental type
15:13 ruoso That way I don't even need to have a prototype lowlovel structure
15:14 ruoso the lowlevel C structure always have HOW member in the top of the struct
15:15 ircuser moritz_ anyway i think we can use perl5 with the perl6 interpreter
15:16 moritz_ it's in the specs, yes
15:17 chris2 joined #perl6
15:22 ruoso I think I agree with nothingmuch that yap6 is not a Perl 6 runtime, but a generic OO runtime.
15:22 ruoso I think I'll rename it
15:22 ruoso I thought on the name OZOO
15:22 nothingmuch VROOM!!!!!!!!
15:22 ruoso which stands for Object Zoo, or Oz Object Orientation
15:22 nothingmuch ViRtual Object Oriented Machine
15:22 nothingmuch ;-)
15:23 ruoso heh
15:23 ruoso btw... take a look in what I've just said before
15:23 nothingmuch not right now... in an hour or so i might have some time
15:23 ruoso ok
15:24 ruoso VROOM++
15:25 pugs_svn r19402 | ruoso++ | [yap6] last commit before rename
15:25 rdice joined #perl6
15:27 TJCRI joined #perl6
15:27 pugs_svn r19403 | ruoso++ | [vroom] VROOM is the new name of YAP6 after realizing that it is not Perl 6 specific
15:29 moritz_ should I rename some constructs from yap6 to vroom?
15:30 ruoso moritz_, I'm starting doing that,
15:30 ruoso if you want to take some files to hepl
15:30 ruoso please...
15:30 ruoso but wait
15:30 * moritz_ pokes const.c
15:31 ruoso moritz_, they are already not working
15:31 ruoso so they are not that important
15:31 ruoso because the structures were already different on them
15:31 ruoso but you can express it in terms of VROOM__Object* already
15:31 ruoso instead of YAP6__CORE__Value*
15:32 pugs_svn r19404 | ruoso++ | [vroom] renamed include/*.h files
15:33 * ruoso changing vroom_base.h
15:34 pugs_svn r19405 | moritz++ | [vroom] src/: changed some file names, s/yap6/vroom/g
15:42 TJCRI joined #perl6
15:48 pugs_svn r19406 | ruoso++ | [vroom] include/vroom_base.h rewritten
15:48 * ruoso taking vroom_stack.h
15:51 moritz_ In file included from const.c:3:
15:51 moritz_ ../include/vroom.h:4:24: error: vroom_base.h: No such file or directory
15:51 moritz_ but there is a ./include/vroom_base.h
15:51 moritz_ wtf?
15:54 ruoso moritz_, at this point, I don't expect anything to work...
15:55 ruoso the C code is now based on yap6 before this revamping I'm doing
15:55 moritz_ ruoso: neither do I, but I just don't understand why the include file isn't found
15:58 pugs_svn r19407 | ruoso++ | [vroom] include/vroom_stack.h rewritten
15:58 * ruoso taking vroom_native.h
15:58 * moritz_ yawns
15:58 moritz_ ETOLITTLEO2
16:02 pugs_svn r19408 | ruoso++ | [vroom] include/vroom_native.h rewritten
16:02 * ruoso taking vroom_builtin.h
16:03 pugs_svn r19409 | ruoso++ | [vroom] include/vroom_builtin.h rewritten
16:05 dmas1 joined #perl6
16:07 lichtkind joined #perl6
16:10 pugs_svn r19410 | ruoso++ | [vroom] some other renamings...
16:14 pugs_svn r19411 | ruoso++ | [yap6] cleaning up yap6 dir, leaving a goodbye note.
16:16 pugs_svn r19412 | ruoso++ | [vroom] VROOM_DISPATCH must receive a responder interface
16:17 cognominal_ joined #perl6
16:17 arxc joined #perl6
16:19 drrho joined #perl6
16:26 Psyche^ joined #perl6
16:43 moritz_ ruoso: should vroom compile again?
16:50 pmurias joined #perl6
16:52 pmurias ruoso: WHO is already taken, not all implementations will use a responder interface (i suppose perl5v6 will use a perl5 class serving as a method cache)
16:55 jhorwitz_ joined #perl6
17:04 manfred joined #perl6
17:06 rdice joined #perl6
17:17 barney joined #perl6
17:21 aindilis joined #perl6
17:28 ruoso pmurias, ops... I overlooked that...
17:28 ruoso i need another name
17:31 ruoso moritz_, not yet... I need to port the code from YAP6__CORE__Value to VROOM__Object
17:31 ruoso but it should be very simple
17:33 ruoso moritz_, porting that is, actually, the first item in the ROADMAP
17:33 pugs_svn r19413 | ruoso++ | [vroom] WHO was already taken, my bad overlooking that, pmurias++ for noticing. The Responder Interface is get with YAP6_RI instead, and the member is called RI
17:34 ruoso oops...
17:34 ruoso s/YAP6_RI/VROOM_RI/
17:36 pugs_svn r19414 | ruoso++ | [vroom] one other s/yap6/vroom/
17:42 ruoso named arguments are optional by default, right?
17:43 moritz_ I don't think so
17:43 moritz_ only when they have a default value
17:43 [particle] named are optional by default in perl 6
17:44 [particle] unnamed are required by default
17:44 ruoso yep, i found it.... needs a sufix ! to make them required...
17:44 [particle] yep
17:44 * moritz_ rereads the spec
17:44 [particle] ruoso: wanna see arg processing in nqp?
17:45 [particle] ...or perl6 for that matter? it's a short routine to determine optional/named/slurpy/required
17:45 ruoso is it implemented already?
17:46 * ruoso wondre
17:46 * ruoso wonders if that looks like a Signature ~~ Capture
17:48 TimToady http://www.vroomsite.com/
17:48 lambdabot Title: Vroom&reg; -The Web System for Business&trade; - Home
17:49 ruoso TimToady, vroomcode.org seems free ;)
17:51 TimToady I'm more worried about a trademark suit.
17:53 ruoso well, we may argue that it's an reference to http://www.perlmonks.org/?node=vroom
17:53 lambdabot Title: vroom
17:53 ruoso ;)
17:58 ruoso TimToady, btw... in the end I found my way out of the HOW/WHAT confusion... nothingmuch made me realise that what I was calling metaclass was really the responder interface... and not the prototype or metaobject...
17:58 ruoso so HOW and WHAT can do whatever decided in the RI implementation
17:59 nothingmuch it's supposed to be VROOM!!!!!!! not Vroom
17:59 ruoso re suit: and I can always blame nothingmuch ;)
17:59 nothingmuch aah no i have enough bureaucracy to deal with as it is, thank you very much
18:00 TimToady if gaal were here he'd suggest ESOOM
18:00 ruoso I thought about OZOO
18:00 ruoso Object ZOO
18:01 ruoso or Oz Object Orientation
18:01 ruoso heh
18:01 TimToady ZOOF sound like something going by fast
18:01 nothingmuch libozoo has no hits on google
18:01 nothingmuch neither does libzoof
18:01 allbery_b zoof sounds to me lik someone got punched in the stomach
18:01 ruoso hehe
18:01 [particle] OZONE - developed by free software radicals
18:01 moritz_ rofl
18:01 moritz_ [particle]++
18:02 TimToady You are entering... the O Zone...
18:02 ruoso hehe
18:02 ruoso OZONE++
18:02 ruoso [particle], ++
18:02 TimToady WHOOPS
18:02 ruoso oops... bad completion
18:03 TimToady SHROOM
18:03 TimToady CROON
18:03 TimToady SPOON
18:03 [particle] swoon?
18:03 allbery_b gubru?  "zooooon..."
18:04 TimToady JOOS pronounced "juice"
18:04 ruoso SOOM -> Stacked OO machine
18:05 ruoso YAA -> Yet Another Animal
18:05 TimToady barsoom
18:05 [particle] gezundheit
18:05 Auzon joined #perl6
18:05 moritz_ ;)
18:06 moritz_ s/z/s/ though
18:06 TimToady barzoom
18:06 [particle] we americans put 'z' everywhere you don't expect it :)
18:06 moritz_ I noticed, yes
18:07 allbery_b zomg!
18:07 TimToady TROO STROO THROO etc
18:07 [particle] I HAD A OO BUT I EATED IT
18:07 TimToady name it LOL and confuse #parrot
18:08 ruoso hehe
18:08 [particle] SHOOHORN
18:08 moritz_ but lolcode.org is already taken
18:08 ruoso EOO
18:08 ruoso Empty Object Orientation
18:09 [particle] COOL
18:09 ruoso Cool Object Orientation Library ?
18:09 [particle] self-naming
18:09 moritz_ VOOT (Virtual OO Transmogrifier)
18:10 TimToady KOOL is a possibility, if you don't mind the tobacco association
18:10 TimToady doesn't seem to be any computery interference
18:11 TimToady at least, not on wikipedia
18:11 [particle] DROOL # plays well with Moose
18:11 TimToady MOOSTANG
18:11 Auzon TROOL
18:11 pbuetow for what are you looking a name for?
18:11 ruoso TROOL++
18:11 Auzon Apparently with "OO"
18:12 TimToady yap6
18:12 moritz_ for VROOM, formerly yap6
18:12 TimToady KROOD
18:12 pbuetow hm ok
18:12 Auzon TRue Object Orientated Language?
18:12 TimToady DOODZ
18:12 Auzon Or maybe TOOL
18:13 TimToady TOOTSY
18:13 ruoso DOS -> Damaged Object System
18:13 TimToady got ROOT?
18:14 ruoso root would be cool
18:14 moritz_ but that's too hard to search for
18:14 moritz_ Results 1 - 10 of about 166,000,000 for root
18:15 TimToady skoot
18:15 Auzon I like skoot
18:15 pstuifzand joined #perl6
18:16 ruoso PMOS -> Post-Modern Object System
18:16 moritz_ PMOS++
18:16 allbery_b that sounds like something the folks downstairs from me (chip designers) would be playing with
18:17 ruoso PMORE -> PostModern Object Runtime Environment
18:17 Auzon left #perl6
18:17 Auzon joined #perl6
18:17 Auzon oops. wrong window.
18:18 [particle] MIPE: Modularity, Inheritance, Polymorphism, Encapsulation
18:18 TimToady pmoose
18:19 [particle] poogs
18:19 ruoso poogs++
18:19 ruoso hehehe
18:19 Auzon Muskox
18:19 lichtkind TimToady: thanks for the answer
18:19 lichtkind TimToady++
18:19 ruoso postmodern moose?
18:20 lichtkind TimToady: max is also list infix ?
18:23 ruoso from all the options, I like most: OZONE, COOL, KOOL, and SPOON
18:24 Auzon All common words, but not in combination with Perl. That's good.
18:24 ruoso ozone is already taken
18:25 ruoso spoon also, by a cpan module
18:26 ruoso cool don't identify much
18:26 ruoso kool is a cigarret brand
18:34 ruoso LisMOS <- "Less is More" Object System
18:34 moritz_ not bad
18:43 DarkWolf84 joined #perl6
18:45 ruoso MEEOW - MEta Object Orientation System
18:45 moritz_ where's the W?
18:45 ruoso the cat ate
18:46 Auzon Where's the second E?
18:46 [particle] it doesn't *have* to be an acronym
18:46 Auzon :P
18:47 ruoso ok... let's find an acronym for MEEOW
18:47 ruoso (having two E's make it easier to search for
18:47 [particle] ooh! WOOF
18:49 [particle] work-in-progress oo frobulator
18:51 [particle] ROOBY
18:51 Auzon hahah
18:51 Auzon I dunno, some people may not like that
18:51 [particle] NOOBIE
18:52 TimToady lichtkind: max is just scalar infix
18:53 TimToady btw, I don't the the multiple dispatch RI belongs in any of the argument objects
18:53 TimToady it probably goes in the proto sub
18:53 TechSkilled joined #perl6
18:53 TimToady pugs went as far as to generate one if you didn't supply one
18:54 ruoso NOOL
18:54 TimToady s/the the/think the/
18:54 lichtkind TimToady: so you write @array.max instead of [max] @array?
18:54 TimToady whether there's a method on @array is independent of whether there's an operator
18:55 TimToady but using infix we can say $biggest max= $current
18:55 TimToady admittedly that's side effectful
18:56 TimToady but we also get [max] @array
18:56 TimToady I don't see any problem with also having @array.max
18:56 TimToady so you could even write "max @array:"
18:57 TimToady tmtowtdi
18:58 lichtkind thanks
18:58 Auzon ++
19:00 TimToady smop
19:00 TimToady though that's also been suggested as a name for parrot's perl6 impl
19:01 [particle] LOON
19:01 moritz_ what happened to the name "Onion"?
19:01 ruoso SMOP++
19:01 ruoso http://en.wikipedia.org/wiki​/Small_matter_of_programming
19:01 ruoso the description fits perfectly
19:01 Auzon Indeed. SMOP++
19:01 Auzon @karma SMOP
19:01 lambdabot SMOP has a karma of 2
19:01 Auzon Heheh
19:02 [particle] karma SMOP++
19:02 [particle] @karma SMOP++
19:02 lambdabot SMOP++ has a karma of 0
19:02 Auzon :O
19:02 [particle] heh
19:02 Auzon Oh
19:02 Auzon I getit
19:03 TimToady Simple Meta Object Programming
19:03 ruoso Simplistic ...
19:04 TimToady Super ...
19:04 ruoso but Small Matter Of Programming is also just fine
19:04 moritz_ small...
19:04 TimToady is there an S word for extenSible?
19:04 araujo Sensible
19:04 araujo :-P
19:04 TimToady Smart
19:04 Auzon Supported?
19:04 ruoso inSane
19:04 Auzon Sufficient?
19:04 moritz_ superior!
19:04 araujo Sensible Meta Object Programming
19:05 drrho joined #perl6
19:05 araujo :-P
19:06 TimToady SMOP Meta Object Programming
19:06 araujo :-D
19:07 ruoso Ok... no more arguments... SMOP Rules
19:08 pugs_svn r19415 | ruoso++ | [vroom] documenting the node methods... btw... this is the last commit as vroom
19:09 pugs_svn r19416 | ruoso++ | [smop] hey... vroom is now smop
19:09 pugs_svn r19417 | ruoso++ | [yap6] updating yap6 goodbye note.
19:09 TimToady there's a smop.org, but it doesn't appear to be the name of computer code
19:10 ruoso yeah.. seems like an outdated blog
19:11 ruoso one thing I miss in regex is a feature of emacs search and replace...
19:12 ruoso s/vroom/smop/g
19:12 ruoso but keep the original case
19:14 pugs_svn r19418 | ruoso++ | [smop] renaming include/* files.
19:16 avar ruoso: miss in what?
19:16 pugs_svn r19419 | ruoso++ | [smop] s/vroom/smop/g(emacs ignore-but-keep-case-feature)
19:17 ruoso consider you have "SMOP Smop smop" and you want to substitute by "BLOP Blop blop"
19:17 ruoso if you just do s/smop/blop/gi
19:17 ruoso you'll end with "blop blop blop"
19:17 ruoso emacs search and replace is smart enough to keep the original case
19:17 moritz_ cool
19:19 Southen joined #perl6
19:20 pugs_svn r19420 | ruoso++ | perl -pi -e '[smop/src] s/VROOM/SMOP/g' *.c *.h ; perl -pi -e 's/vroom/smop/g' *.c *.h;
19:24 avar FOO Foo FoO foo will also be BAR Bar Bar bar
19:24 avar emacs++
19:25 ruoso TimToady, do we still have a slot for a regex modifier?
19:25 ruoso :)
19:25 moritz_ in p5 or p6?
19:25 ruoso in p6...
19:26 moritz_ :smartcase
19:26 pasteling "avar" at 208.78.101.240 pasted "emacss replace-match" (454 lines, 12.4K) at http://sial.org/pbot/29749
19:27 avar it's called fixedcase in emacs
19:28 ruoso :fixedcase makes sense
19:29 avar (also C-h f replace-match RET
19:32 TimToady might want to be something more like {lc ...}
19:33 TimToady s:i/foo/{.samecase bar}/
19:33 TimToady but if you have to have :i anyway...
19:33 ruoso sure
19:34 TimToady maybe s:same/foo/bar/ is just shorthand for that
19:34 TimToady or whatever the switch turns out to be
19:34 [particle] :sc # samecase
19:35 TimToady unfortunately :s is taken
19:35 Auzon :c ?
19:35 moritz_ is taken as well
19:35 TimToady also taken
19:35 ruoso :f?
19:36 Auzon What would that stand for?
19:36 ruoso fixed case
19:36 ruoso as emacs calls
19:36 Auzon ah..., fixed
19:36 TechSkilled left #perl6
19:37 TimToady or maybe :ii
19:37 moritz_ like :uglii
19:37 ruoso hehehe
19:38 TimToady :i2
19:38 ruoso ii is funny because it looks like ignore the case in the both sides
19:39 TimToady which, in a sense, it does
19:39 ruoso yeah...
19:39 TimToady I'll go with :ii for now
19:39 jisom joined #perl6
19:39 [particle] aye aye
19:40 TimToady I wonder if there's something equivalent for :bb (basechar)
19:40 Auzon @karma lambdabot
19:40 lambdabot lambdabot has a karma of 53
19:40 ruoso hmmm
19:40 ruoso maybe
19:41 TimToady s:bb/a/o/ changes ä to ö
19:41 ruoso s:bb/a/e/ would turn "á" into "é"
19:42 TimToady it's a little dicier if the two strings are of unequal length
19:42 wolverian I hope that only happens in locales where it makes sense :)
19:42 ruoso well, the longest dictates the case
19:43 ruoso unicode isn't locale dependant, is it?
19:43 TimToady probably just limit it to same character position
19:43 TimToady not unless you say "use Locale" or some such
19:43 TimToady otherwise graphemes are considered language indepenent
19:43 Auzon Is everything Unicode in Perl 6?
19:43 ruoso Auzon, yep
19:43 wolverian TimToady, ah, thanks.
19:44 Auzon great :)
19:44 TimToady well, you can have other types if you like
19:44 TimToady but string types are distinguished from buffer types, and the string types are all unicode
19:44 wolverian I'm having a hard time imagining where s:bb/a/o/ would make sense in an locale-independent way, _or_ locale-dependent!
19:44 TimToady the standard string types, that is
19:44 TimToady well, it's just an interesting thought, doesn't have a huge use case
19:45 TimToady no pun intended
19:45 wolverian heh. true enough
19:45 TimToady just noticed :basechar right under :ignorecase is all
19:45 TimToady and realized they were similar
19:45 wolverian I wouldn't have noticed it
19:45 wolverian so, please keep noticing and ignore me
19:46 pugs_svn r19421 | ruoso++ | [smop] A small note on a important stack design issue: The node pushed is never evaluated by the interpreter loop, it should be used to pass information to the new frame.
19:52 avar 1/w 26
19:58 arxc joined #perl6
19:59 pugs_svn r19422 | pmurias++ | points to the right directory
20:00 moritz_ TimToady++ # r14484
20:01 TimToady ruoso++
20:01 moritz_ TimToady: what happens if a titlecase letter is substituted by a letter that doesn't have a titlecase equivalent?
20:01 moritz_ is it mapped to upper case?
20:01 TimToady good Q
20:01 TimToady hang on
20:03 TimToady I guess the question I have is whether you want to substitute titlecase into the middle of a camelcase identifier
20:03 moritz_ that's not my question
20:04 moritz_ I think the greek letter sigma has three cases: upper case, lower case and title case
20:04 TimToady I'm assuming that if there is a direct mapping, it works
20:04 TimToady uh, no, you're confusing the ending sigma, which is different
20:04 moritz_ ok
20:05 TimToady I think if there is a titlecase to titlecase mapping, or upper to upper, that is automatically used.
20:05 TimToady there are no titlecase without a corresponding upper
20:05 TimToady (I don't think)
20:06 TimToady so all that remains is if there is no corresponding titlecase, it goes to upper
20:07 TimToady on the other hand, arguably it should choose titlecase or uppercase depending on whether there's a letter to the left of it in the result
20:07 TimToady but camelcase might be wrong then
20:07 TimToady if you're substituting in the middle of a longer identifier
20:08 TimToady I don't think there's a right answer
20:08 moritz_ my $s = "ABc" ~~ s:bb/.../ßbc/; # is that SSBc? or SSbc?
20:08 TimToady or rather, the right answer changes depending on whether you're doing computer programming or natural language processing
20:08 moritz_ I think it should be SSBc
20:09 moritz_ I don't think the problem shows up unless you process natural language
20:09 TimToady my brane hurtz
20:10 TimToady if you're doing NLP then you've probably said "use Deutsch"
20:10 moritz_ ;)
20:10 TimToady on the other hand, I don't think many other languages *care* what happens to ß :)
20:11 moritz_ aye
20:11 TimToady so it's language independent in that sense
20:11 moritz_ are there other chars that produce multiple graphemes when lc'ing or uc'ing?
20:12 TimToady dunno, could be
20:12 lichtkind TimToady: does $a=(1,2,(a,b)); and  @a=(1,2,(a,b)); the same? (array ref to an flat array?)
20:13 lichtkind use Deutsch;++
20:13 DarkWolf84 r there refs in p6
20:13 DarkWolf84 ?
20:13 moritz_ perhaps use lang::Deutsch;
20:13 lichtkind of course
20:13 moritz_ DarkWolf84: there are captures
20:14 lichtkind they are spelled captures
20:14 DarkWolf84 lake in grammar?
20:14 lichtkind like a signature
20:14 TimToady the @a= case puts the right side into list context, and parens are ignored in list context, so you get @a=1,2,a,b
20:15 TimToady the $a= puts the right side into scalar context, but the commas make their own list context (I suspect), so you end up with $a = [1,2,a,b]
20:16 TimToady note that $a=\(1,2,(a,b)) is a different matter, since those commas are in capture context
20:17 TimToady are are the commas in foo(1,2,(a,b))
20:17 TimToady in capture context the list/scalar distinction is lazy until binding time
20:18 lichtkind makes sense
20:19 lichtkind thank you vary much
20:19 lichtkind very :)
20:23 buubot joined #perl6
20:26 spinclad in finnish, 'ö' ~~ s:bb/o/u/ should arguably give 'y', since 'y' is their 'ü'
20:26 moritz_ outch
20:27 moritz_ all those language dependent cases are going to hurt
20:28 spinclad but even in finnish, unicode has a 'ü'...
20:29 spinclad er...
20:31 silug joined #perl6
20:31 thoughtpolice joined #perl6
20:37 spinclad all right, now i want an umlautable metalinguistic 'V', so i could say  'ieaou' ~~ s:g:bb/V/V\"/ => 'ieäöu'
20:38 moritz_ so \" is COMBINING DIARESIS?
20:38 stephang joined #perl6
20:38 spinclad *'ieäöy', dammit!
20:39 spinclad moritz_: that's what i mean, even if i can't say it.
20:39 spinclad \"V, even, TeXwise.
20:42 lichtkind ju ich hab 20%
20:45 TJCRI joined #perl6
20:48 moritz_ lichtkind: wrong channel ;)
20:50 lichtkind moritz_: stimmt
21:07 TimToady why not just <V>
21:08 spinclad sure.  how do i do \"<V> on the rhs?
21:09 spinclad s/<V>/\"($<V>)/
21:10 TimToady $<V>\x[0308]/ presumably
21:10 spinclad overfix:<">
21:11 spinclad superfix, rather
21:12 spinclad +front($<V>)
21:12 TimToady or s/<V>/$<V>\c[COMBINING DIAERESIS]/
21:13 TimToady assuming the right side is smart about recombining graphemes when it needs to
21:13 TimToady otherwise might need a codepoint declaration around it
21:16 spinclad i guess if i used the actual character in /$<V>\c[...]/, it would try to the '>', which would be Bad.
21:16 TimToady indeed
21:17 spinclad *try to apply to
21:17 TimToady metacharacters have to good for something... :)
21:17 TimToady s/to/to be/
21:18 zamolxes joined #perl6
21:22 spinclad (otoh, that would give 'ïëäöü', which is completely unfinnish, but then i shouldn't be trying to solve that at a unicode level.)
21:45 jferrero joined #perl6
21:54 meltingwax joined #perl6
21:54 meltingwax i'm getting this error when i try to compile:     Could not find module `Data.Array':
21:54 meltingwax it is a member of package array-0.1.0.0, which is hidden
21:54 moritz_ meltingwax: which version of ghc are you using?
21:55 moritz_ if you have >= 6.8, apply the patch pugs-ghc681.diff
21:55 meltingwax 6.8.2
21:55 meltingwax ok
21:56 meltingwax how do i do that :x
21:57 moritz_ I guess 'patch < pus-ghc681.diff'
21:59 luqui joined #perl6
22:13 meltingwax moritz_: thanks
22:13 moritz_ meltingwax: so it works?
22:14 meltingwax the patch did (when i added -p0)
22:14 meltingwax its compiling now
22:14 meltingwax Setup: error reading dist/setup-config; run "setup configure" command?
22:15 meltingwax Build failed for '/usr/src/pugs/dist/build/libHSPugs-6.2.13.a': 256 at util/build_pugs.pl line 372.
22:15 meltingwax make: *** [pugs] Error 2
22:17 * moritz_ never saw that error
22:17 moritz_ did you run Makefile.PL after applying the patch?
22:24 meltingwax yes
22:28 * moritz_ has no idea what's wron
22:28 moritz_ g
22:30 moritz_ TimToady: if I query Str.bytes, which encoding is used to determine the byte size?
22:31 jjore-w joined #perl6
22:41 jferrero joined #perl6
23:05 polettix joined #perl6
23:15 charsbar_ joined #perl6

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

Perl 6 | Reference Documentation | Rakudo