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

Powered by Cro and the Raku® Programming Language.

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

Thank you!