MethodMaker techniques in Perl 6
Based on the default accessors and encapsulation thread, it seems like a
Perl 6 equivalent of Class::MethodMaker will be still be useful in our (or
at least my) Brave New World. I've been pondering the best way to create
such a beast in Perl 6.
The most common two Perl 5 techniques are:
1. Use a string eval: build up a big string that looks the code for the
method that I would have typed myself if I wasn't so lazy, then eval the
string and assign the resulting code ref to the appropriate typeglob.
Example:
$attr = 'baz';
*{Foo::$attr} = eval qq(sub { \$_[0]-{'$attr'} });
This technique seems to have the best runtime performance in Perl 5 (by a
small margin), but it's also much more expensive (not to mention tedious and
persnickety) to create the method in the first place. For whatever reason,
it's always just struck me as wrong (sort of like source filtering where
code is just seen as a giant string--something that Perl 6 blessedly saves
us from :)
2. Use a closure: build a method by assigning what would normally be
constant values to a set of variables, then capturing their state in a
closure. Example:
$attr = 'baz';
*{Foo::$attr} = sub { $_[0]-{$attr} };
Making the method this way has always seemed cleaner to me, but it bothers
me that $attr a full blown variable that has to be read from every time the
method is run. Really, it should be a constant, which is probably why the
string eval version has a speed edge at runtime.
Obviously, simple get methods like the above wouldn't have to be written
at all in Perl 6. Instead, I'd just use a public, read-only attribute (has
$.baz) and be done with it. (As far as I can tell, the user of my class
wouldn't be able to determine (or care) how $o.baz is implemented--whether
as method baz() { ... } or as has $.baz. Correct me if I'm wrong :)
Set methods, OTOH, will still have to be either written manually or
auto-generated if, like me, you are not inclined to accept the contract
implied by has $.foo is rw Perl 6 attributes.
But beyond simple get/set methods, there's a whole world of increasingly
more complex kinds of generic methods to be made. Just look at Perl 5's
Class::MakeMethods::* for some examples. So finally, getting back to my
original point, I'm wondering how best to create a good MethodMaker in Perl
6.
The two Perl 5 techniques still seem like they will work (albeit with
different syntax), but I'm sure there are better ways...perhaps something
involving macros? The ideal solution has the strengths of both Perl 5
techniques, but none of their weaknesses. Creation should be fast and
clean, and there should be no wasted overhead when calling the generated
methods. It should be just as if I wrote the methods myself.
I haven't retained enough Perl 6 syntax to have any idea what this would
look like, so I'm looking for suggestions. Which Perl 6 features are best
suited to creating a good Perl 6 MethodMaker? Anyone want to post some
simple examples?
-John
RE: A12: subtypes that lack methods or roles
It's a valid question in general, but since you're designing this
functionality from the ground up (and not retro-fitting it in to existing
code), wouldn't the better approach be to create a non-GUI HList class, and
a GUI subclass that adds the indicator methods? Or even better, less tightly
coupled and in line with the MVC pattern, an HListModel class and a
HListWidget class that composes an HListModel within it.
-Dov Wasserman
-Original Message-
From: Jonathan Lang [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 24, 2004 12:44 AM
To: [EMAIL PROTECTED]
Subject: Re: A12: subtypes that lack methods or roles
Larry Wall wrote:
Jonathan Lang wrote:
: How would I declare a subtype of a class which messes with the
: dispatching mechanism to exclude certain methods and/or roles from
: it?
Er, uh...tell you what. Why don't you provide some sample code to
go with your question, and we'll just tell Dan to make it work. :-)
This goes along with my other thread about nested roles. In Perl/Tk -
specifically HList, there's a bunch of methods, including:
add, addchild, delete, headerCreate, headerConfigure, headerCGet,
headerDelete, headerExists, headerSize, indicatorCreate,
indicatorConfigure, indicatorCGet, indicatorDelete, indicatorExists,
indicatorSize, itemCreate, itemConfigure, itemCGet, itemDelete,
itemExists, ...
In perl 6, I'd be tempted to handle it something like this:
class HList {
method add {...};
method addchild {...};
method delete {...};
# things relating to multicolumn lists
does role header {
has Int $.columns;
method headerCreate {...};
method headerConfigure {...};
method headerCGet {...};
method headerDelete {...};
method headerExists {...};
method headerSize {...};
};
# things relating to the icon next to each tree entry
does role indicator {
has Flag $.indicator;
method indicatorCreate {...};
method indicatorConfigure {...};
method indicatorCGet {...};
method indicatorDelete {...};
method indicatorExists {...};
method indicatorSize {...};
};
# things relating to individual cells in the list
does role item {
method itemCreate {...};
method itemConfigure {...};
method itemCGet {...};
method itemDelete {...};
method itemExists {...};
};
...
};
OK: I'm planning on creating a widget which must not make use of any of
the indicator functionality of the HList; I don't just want to not use the
functionality - I want to have its use forbidden (letting the optimizer go
ahead and toss out the indicator role). So I'd like to create a subtype
of HList which exceises that functionality. It's a subtype of HList in
the sense that we're removing functionality in order to get there;
however, we're removing functionality by saying that, in effect, this
subtype does _not_ do the indicator role.
So when the resulting thing attempts to call the indicatorCreate method,
it first looks at the class methods, and doesn't find anything; it then
looks at each of the roles, _except for the indicator role_. It doesn't
find anything. It then looks at any inherited methods, etc., and
ultimately doesn't find the method. It then throws an exception to alert
the programmer that he's trying to use a routine that he's not supposed to
use.
So how to tell the subtype(?) to disregard the indicator role? While
we're at it, I'd also like to remove the addchild method, since I don't
want this thing to be used to create hierarchal structures - I'm looking
for the tabular data capabilities in this case.
=
Jonathan Dataweaver Lang
Re: A12: subtypes that lack methods or roles
On Fri, 2004-04-23 at 21:44, Jonathan Lang wrote: OK: I'm planning on creating a widget which must not make use of any of the indicator functionality of the HList; I don't just want to not use the functionality - I want to have its use forbidden (letting the optimizer go ahead and toss out the indicator role). So I'd like to create a subtype of HList which exceises that functionality. I think you're thinking of this backwards. Don't subclass HList. Create a new class that doesn't subclass anything and compose the appropriate roles into it. Provided the library designers have done their job and *ask for the proper role in function and method signatures, not a specific class*, you're groovy. Now I could be wrong about your intent, but the question How do I subclass a class to *remove* functionality? is the kind of Yeah, it hurts when you do that situation role-based composition try to avoid. If you have all of the pieces, put them together in a way you find most pleasing. -- c
Re: A12: Exporation
On Fri, 2004-04-23 at 20:51, Larry Wall wrote:
On Sat, Apr 24, 2004 at 09:52:12AM +1000, Damian Conway wrote:
: My proposal for that issue is just:
:
: module Bar;
:
: use Foo «foo»;
:
: sub foo is export {...}
That's on the right track, but has some difficulties, insofar as it's
not clear that the intent is to redefine foo retroactively rather
than actively. And it doesn't necessarily work for variables
Hmmm... it seems to me that:
use Foo;
our $bar is export := $Foo::bar;
should solve that, no? Now I just want a tied array called @EXPORT that
acts as a macro, adding is export to the symbols I put into it ;-)
Seriously, I did kind of like the code-as-documentation pseudo-feature
of seeing all of the exported symbols listed up-front in a module. It's
too bad Perl 6 will lack that.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
signature.asc
Description: This is a digitally signed message part
Math -- another stab
A LONG time ago, after an Apocalypse far, far away, I tried to define
many built-in operators in Perl 6 to see if I got it. After A12 I
think I get it enough to try at least the math ops again.
Everything in this file about modules and emitting IMCC is total
arm-waving, and there's no exporting going on at all... this is just a
mock-up, but I'm interested in hearing if any of this is wrong in terms
of:
* Type handling
* Operator naming (e.g. ~^, etc)
* multiness
For right now, I have only added three functions that do not exist in an
apocalypse or Perl 5, but they're defined in perlfun in terms of Perl
and in the Parrot opcode set, so I think it's fair (acos, asin, tan).
Enjoy!
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
#
# Math operations
#
# Written by Aaron Sherman [EMAIL PROTECTED] (c) 2004
# Distributed under the same terms as Perl itslef.
# For efficiency we declare as multi both object and basic type versions of any
# functions that will modify their arguments.
# There's a valid argument that:
#
# my Dog $x = 1;
# my $y = !$x;
#
# Should not strip the objectness of $x, and that $y should also
# be a Dog... this COULD be done, but has not been. I'm still thinking
# about it, as the other argument is that if Dog wanted that, it would
# define its own prefix:! with appropriate semantics, after all we don't
# know what a not-Dog is... perhaps it's a Cat and perhaps it's a Vet.
# Same goes for most math ops that don't modify their arguments. -ajs
module Math {
# Arm-waving about code generation begins
use IMCC::Emit; # Provides the macro, emit
# Some generic setup that should be moved to IMCC::Emit
sub as_imcc(str $op, $target is rw, [EMAIL PROTECTED]) is inline {
emit($op,$target,[EMAIL PROTECTED]);
return $target;
}
sub as_imcc_tmp(str $op, [EMAIL PROTECTED]) is inline { my $ret; return
as_imcc($op,$ret,@_) }
sub as_imcc_save(str $op, $target is rw, [EMAIL PROTECTED]) is inline {
my $tmp = $target;
as_imcc($op,$target,@_);
return $tmp;
}
# Arm-waving about code-generation ends.
# Define both num and int versions to take advantage of the
# different Parrot-level ops. IMCC lets us call these by the
# same name, and dispatches based on type.
# Simple math
multi sub abs (num $n) returns(num) { as_imcc(abs,$n) }
multi sub abs (int $n) returns(int) { as_imcc(abs,$n) }
multi sub exp (num $n) returns(num) { as_imcc(exp,$n) }
multi sub exp (int $n) returns(int) { as_imcc(exp,$n) }
sub log (num $n) returns(num) { as_imcc(log,$n) }
sub rand(num $max=1) returns(num) { as_imcc(rand,$max) }
sub sqrt(num $n) returns(num) { as_imcc(sqrt,$n) }
sub srand(int $seed) { as_imcc(srand,$seed) }
sub int (num $n) returns(int) { $n }
# Operators
multi sub prefix:+ (Num $val) returns(Num) { $val }
multi sub infix:+ (num $n, num $m) returns(num) { as_imcc(add,$n,$m) }
multi sub infix:- (num $n, num $m) returns(num) { as_imcc(sub,$n,$m) }
multi sub infix:+ (int $n, int $m) returns(int) { as_imcc(add,$n,$m) }
multi sub infix:- (int $n, int $m) returns(int) { as_imcc(sub,$n,$m) }
multi sub infix:* (num $n, num $m) returns(num) { as_imcc(mul,$n,$m) }
multi sub infix:/ (num $n, num $m) returns(num) { as_imcc(div,$n,$m) }
multi sub infix:* (int $n, int $m) returns(int) { as_imcc(mul,$n,$m) }
multi sub infix:/ (int $n, int $m) returns(int) { as_imcc(div,$n,$m) }
multi sub infix:** (int $n, int $m) returns(int) { as_imcc(pow,$n,$m) }
multi sub infix:** (num $n, num $m) returns(num) { as_imcc(pow,$n,$m) }
multi sub infix:% (num $n, num $m) returns(num) { as_imcc(mod,$n,$m) }
multi sub infix:% (int $n, int $m) returns(int) { as_imcc(mod,$n,$m) }
multi sub infix:+ (int $n, int $bits) returns(int) { as_imcc(shl,$n,$bits) }
multi sub infix:+ (int $n, int $bits) returns(int) { as_imcc(shr,$n,$bits) }
multi sub infix: (num $n, num $m) returns(num) { as_imcc(lt,$n,$m) }
multi sub infix: (int $n, int $m) returns(int) { as_imcc(lt,$n,$m) }
multi sub infix: (num $n, num $m) returns(num) { as_imcc(gt,$n,$m) }
multi sub infix: (int $n, int $m) returns(int) { as_imcc(gt,$n,$m) }
multi sub infix:= (num $n, num $m) returns(num) { as_imcc(le,$n,$m) }
multi sub infix:= (int $n, int $m) returns(int) { as_imcc(le,$n,$m) }
multi sub infix:= (num $n, num $m) returns(num) { as_imcc(ge,$n,$m) }
multi sub infix:= (int $n, int $m) returns(int) { as_imcc(ge,$n,$m) }
multi sub infix:== (num $n, num $m) returns(num) { as_imcc(eq,$n,$m) }
multi sub infix:== (int
Re: Win32 build fails on src\interpreter.str
Jonathan Worthington [EMAIL PROTECTED] wrote: Hi, I'm kinda tied up with stuff, but just to flag up a Win32 build issue... src\global_setup.c global_setup.c NMAKE : fatal error U1073: don't know how to make 'src\interpreter.str' Stop. Could be this line: %.str : %.c ... now changed to: .c.str : ... leo
Re: hyper op - proof of concept
On Fri, 2004-04-23 at 15:34, Dan Sugalski wrote: At 3:25 PM -0400 4/23/04, Aaron Sherman wrote: That I did not know about, but noticed Dan pointing it out too. I'm still learning a lot here, It might be best, for everyone's peace of mind, blood pressure, and general edification, to take a(nother) run through the documentation. The stuff in docs/pdds isn't too out of date (mostly) and all the opcodes have POD, so you can do something like: Yeah, I've been plowing through it a piece at a time. I'm currently still mowing down the DOD docs which (given that I've been in application space for the last 8 years, and the world of GC has changed radically in that time) is a hard read. There are 14,304 lines of POD in the docs subdir and its immediate subdirs. That's a fair amount of reading, especially for something as dense as technical documentation. While diving in feet-first does get you going, looking for the rocks and deep water first is never ill-advised... :) Is that really what I'm doing? It's also the case that there's a HUGE amount of documentation and source code, and I doubt that ANYONE coming to this list and asking questions will understand all of it. I would be so egotistical as to even suggest that I've read more of the source and docs than most who will be asking questions in the next few years. Given that, getting the stupid stuff out of the way now, and putting it in a highly indexed form (e.g. a mailing list FAQ) that people on the list can be pointed at, might save EVEN MORE blood pressure. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback signature.asc Description: This is a digitally signed message part
Re: Win32 build fails on src\interpreter.str
src\global_setup.c global_setup.c NMAKE : fatal error U1073: don't know how to make 'src\interpreter.str' Stop. I spent most of today trying to get parrot build on winxp with MS VC 7.1, with little success. Issues range from ICU build, CONST_STRING __LINE__ expansion madness to nmake-Makefile problems. Your problem seems to be related to the %.str: %.c inference rule, which nmake doesn't understand. For nmake, this should read .c.str: $(PERL) build_tools\c2str.pl $ $@ I am currently stuck with some CONST_STRING issues, for which VC 7.1 complains with: src\interpreter.c(1309) : warning C4013: '_CONST_STRING_' undefined; assuming extern returning int Anyone managed to get around this? Ron
Data::Dumper
I'm adding an object or two, and wanted to write my own __dump() method so I can be dumped out by Data::Dumper. Right now, there doesn't seem to be a way to integrate nicely with the indent level of the data structure I'm embedded in, so I see things like: PerlArray (size:2) [ PMC 'TclWord' (size:1) [ chunk:puts ], PMC 'TclWord' (size:1) [ chunk:$b(a) ] ] I see a few options: (1) Tell me the indent level, so I can handle it manually. (2) Have me return a DS instead of printing directly. (3) Pass me an object as one of the parameters, with handy utility methods for dumping strings and other predefined types. -- Will Coke Coledawill at coleda dot com
Re: Korean character set info
On Thu, 2004-04-22 at 12:18, Jeff Clites wrote: Unicode is an actively evolving standard. It's far from legacy. On Thu, 2004-04-22 at 15:07, George R wrote: I don't agree with the Unicode legacy comment... :-( Creating tomorrow's legacy today. :-) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Data::Dumper
Hi!
On Sunday 25 April 2004 17:01, Will Coleda wrote:
I'm adding an object or two, and wanted to write my own __dump() method
so I can be dumped out by Data::Dumper.
Right now, there doesn't seem to be a way to integrate nicely with the
indent level of the data structure I'm embedded in, so I see things
like:
PerlArray (size:2) [
PMC 'TclWord' (size:1) [
chunk:puts
],
PMC 'TclWord' (size:1) [
chunk:$b(a)
]
]
I see a few options:
(1) Tell me the indent level, so I can handle it manually.
Oh, this is not documented yet :-(
from t/pmc/dumper.t:
.sub __dump method
.param pmc dumper
.param string name
.local string subindent
.local string indent
.local string name
(subindent, indent) = dumper.newIndent()
print {\n
print subindent
print this is\n
print subindent
print _
classname name, self
print name
print ::__dump\n
print indent
print }
dumper.deleteIndent()
.pcc_begin_return
.pcc_end_return
.end
(2) Have me return a DS instead of printing directly.
You can create a data structure and dump it, returning another DS is
not possible.
(3) Pass me an object as one of the parameters, with handy utility
methods for dumping strings and other predefined types.
.sub __dump method
.param pmc dumper
.param string name
.local pmc hash
hash = ...
dumper.dumpHash( name, hash )
.pcc_begin_return
.pcc_end_return
.end
--
Will Coke Coledawill at coleda
dot com
jens
Re: MethodMaker techniques in Perl 6
On Sat, 24 Apr 2004, John Siracusa wrote:
Based on the default accessors and encapsulation thread, it seems like a
Perl 6 equivalent of Class::MethodMaker will be still be useful in our (or
at least my) Brave New World. I've been pondering the best way to create
such a beast in Perl 6.
Yes, I agree. As you point out below, Class::Makemethods does lots of
crazy stuff. Much of that (like pre- and post-hooks) will be easier to
write in P6, but there is still lots of stuff that won't be in the core.
The most common two Perl 5 techniques are:
1. Use a string eval: build up a big string that looks the code for the
method that I would have typed myself if I wasn't so lazy, then eval the
string and assign the resulting code ref to the appropriate typeglob.
Example:
$attr = 'baz';
*{Foo::$attr} = eval qq(sub { \$_[0]-{'$attr'} });
This technique seems to have the best runtime performance in Perl 5 (by a
small margin), but it's also much more expensive (not to mention tedious and
persnickety) to create the method in the first place. For whatever reason,
it's always just struck me as wrong (sort of like source filtering where
code is just seen as a giant string--something that Perl 6 blessedly saves
us from :)
2. Use a closure: build a method by assigning what would normally be
constant values to a set of variables, then capturing their state in a
closure. Example:
$attr = 'baz';
*{Foo::$attr} = sub { $_[0]-{$attr} };
Symbol tables and typeglobs and such belong to A10... and the * has been
stolen... so I'll just speculate in pseudocode.
Blocks-are-subroutines makes life easier, and in pseudocode that can be
just:
*{Foo::name1} = - $a { $a-{name1} };
OR:
for @names - $name {
my $private_scalar = $name;
*{Foo::$name} = - $a {$a-{$private_scalar}};
}
Making the method this way has always seemed cleaner to me, but it bothers
me that $attr a full blown variable that has to be read from every time the
method is run.
Really, it should be a constant, which is probably why the
string eval version has a speed edge at runtime.
That is something the compiler may be able to deal with. I don't know much
about compilers, but here is something from the camel book, 3rd ed, page
229 about inlining functions:
BEGIN {
my $prod = 1;
for (1..10) { $prod *= $_; }
sub NFACT () { $prod }
}
Here, NFACT is inlined because the compiler sees that $prod can never
change. So maybe the $private_scalar above can also be inlined. (There is
a new $private_scalar each time through the loop because of the my, and
$name is also implicitly my). For that code I did not need to introduce
$private_scalar, but I put it there to stand for more complex calculations
if you need there.
Maybe there should be a way to give hints to the compiler that inlining
maybe possible.
The two Perl 5 techniques still seem like they will work (albeit with
different syntax), but I'm sure there are better ways...perhaps something
involving macros? The ideal solution has the strengths of both Perl 5
techniques, but none of their weaknesses. Creation should be fast and
clean, and there should be no wasted overhead when calling the generated
methods. It should be just as if I wrote the methods myself.
I haven't retained enough Perl 6 syntax to have any idea what this would
look like, so I'm looking for suggestions. Which Perl 6 features are best
suited to creating a good Perl 6 MethodMaker? Anyone want to post some
simple examples?
Wicked Traits come to mind. They seem to be all about warping class
behaviors...
role methodmaker{
method trait_auxillary:install( : Class $container, $method_semantics,
[EMAIL PROTECTED]){
given $method_semantics {
when semantics1 {
for @names - $name {
...
my $method = - $arg {...};
$container.install($name, $method);
}
for @names - $name {
my $method = $container.get_method($name);
$method.i_wont_change___inline_variables_if_possible;
}
}
}
}
}
# And in our class:
class Dog{
install some_semantics, bark howl whine;
}
Or perhaps you want to put the install in a BEGIN{} if you want to have
the body of the class see these (especially their signatures).
class Dog{
BEGIN{ install some_semantics, bark howl whine }
}
-John
--abhijit
Re: Win32 build fails on src\interpreter.str
Ron Blaschke [EMAIL PROTECTED] wrote: Your problem seems to be related to the %.str: %.c inference rule, which nmake doesn't understand. For nmake, this should read .c.str: $(PERL) build_tools\c2str.pl $ $@ That's already in CVS ;) I am currently stuck with some CONST_STRING issues, for which VC 7.1 complains with: src\interpreter.c(1309) : warning C4013: '_CONST_STRING_' undefined; assuming extern returning int Is that already with your proposed change to the Makefile rule above or before? Ron leo
Re: MethodMaker techniques in Perl 6
Abhijit A. Mahabal [EMAIL PROTECTED] wrote:
Symbol tables and typeglobs and such belong to A10... and the * has been
stolen... so I'll just speculate in pseudocode.
Blocks-are-subroutines makes life easier, and in pseudocode that can be
just:
*{Foo::name1} = - $a { $a-{name1} };
If I read A12 correctly, this could be written as:
Foo::$name1 := - $a {$a.name1};
Dave.
RE: A12: subtypes that lack methods or roles
Dov Wasserman wrote: It's a valid question in general, but since you're designing this functionality from the ground up (and not retro-fitting it in to existing code), wouldn't the better approach be to create a non-GUI HList class, and a GUI subclass that adds the indicator methods? Or even better, less tightly coupled and in line with the MVC pattern, an HListModel class and a HListWidget class that composes an HListModel within it. Well, yes. But I wasn't mentioning this as the best way to handle this particular case; rather, I was using this particular case to illustrate the more general question. How do I remove functionality from a class or role that someone else put together? = Jonathan Dataweaver Lang __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash
Re: MethodMaker techniques in Perl 6
On Sun, 25 Apr 2004, Dave Whipp wrote:
Abhijit A. Mahabal [EMAIL PROTECTED] wrote:
Symbol tables and typeglobs and such belong to A10... and the * has been
stolen... so I'll just speculate in pseudocode.
Blocks-are-subroutines makes life easier, and in pseudocode that can be
just:
*{Foo::name1} = - $a { $a-{name1} };
If I read A12 correctly, this could be written as:
Foo::$name1 := - $a {$a.name1};
Could be; that sounds somewhat right, but could you point out where in A12
because a search for := revelaed nothing relevant to me.
In any case, I should have written that as:
*{Foo::name1} = - $a { $a.name1 };
Oscillating between using P5 and P6 is occasionally frustrating, though
working at a stretch in either is a pleasure...
The issue for P6 is more complicated than in P5 because you cannot just
assign to the typeglob: you will somehow have to take signatures in
consideration while populating the symbol table.
Dave.
--abhijit
Re: MethodMaker techniques in Perl 6
Abhijit A. Mahabal wrote:
*{Foo::name1} = - $a { $a-{name1} };
If I read A12 correctly, this could be written as:
Foo::$name1 := - $a {$a.name1};
Could be; that sounds somewhat right, but could you point out where in A12
because a search for := revelaed nothing relevant to me.
Sorry, the assignment part came from A6 (and, rechecking, it seems to
use ::= when assigning to a sub). The ability to say pkg::$name came
from A12.
Re: [CVS ci] cpu specfic config
On Apr-24, Leopold Toetsch wrote: I've extended the config system by CPU specific functionality: - new config step config/gen/cpu.pl is run after jit.pl - this step probes for config/gen/cpu/$cpu/auto.pl and runs it if present For i386 we have: - a new tool as2c.pl, which creates hopefully platform independent C code from a gcc source file - memcpy_mmx*.c - and i386/auto.pl which runs this file as a test and sets config vars Next step will be to incorporated these files in platform code. And then we will have a natural choice for the next code name. Parrot will be the fastest bird in existence, but still won't quite fly, so let's call it a Cheeto (cheetah + dodo).
Re: Q: status of IntList
On Apr-21, Leopold Toetsch wrote: Is IntList used outside of some tests? Can we rename it to IntvalArray? Yes, it is used in the languages/regex compiler (at least when embedded in Perl6, but IIRC in all cases.) But yes, go ahead and rename it.
Re: Data::Dumper
On Sunday, April 25, 2004, at 03:34 PM, Jens Rieks wrote: (1) Tell me the indent level, so I can handle it manually. Oh, this is not documented yet :-( Perfect, thank you. -- Will Coke Coledawill at coleda dot com
One change to the strings document
Just a heads up, there are two things that have been pointed out. First, the transset op is transcharset. The abbreviation was a bit sloppy. Second, in spots where character is used, substitute grapheme, as I'm going to. Noting, of course, that a grapheme is *not* a glyph. Glyphs are display things that we're staying very very (very!) far away from. The change'll go into the op names--getglyph instead of getcharacter and suchlike things. Hopefully using a different word'll help people remember that glyph!=codepoint, though we'll see how well that one works. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
