Re: parrot -t
Will Coleda [EMAIL PROTECTED] wrote: Should parrot -t 2 /dev/null work the same as parrot 2 /dev/null ? (that is, are the results of the program the same except for the additional output printed to stderr?) It should work the same. But currently -t leaks memory like a sieve and is totally unusable for non trivial programs. When run as parrot -t tcl.pbc foo.tcl 2 /dev/null, it immediately exits, This shouldn't happen. I've saved a snapshot of my code repository if it's needed for archaeology. Please mail me a copy. I'll have a look at it. leo
Re: The Great Renaming
Dan Sugalski [EMAIL PROTECTED] wrote: Go ahead. When you're done we'll get the directory move stuff done. This would be a good time for anyone with pending patches to check things in, or we'll see lots of annoying conflicts... Nothing pneding yet ... Yep. I'm waiting for renaming and move. Then again CVS will get impact, a lot of ... leo
parrot/t/src/hash.t
Here are some unit tests for the hash.h interface which are PerlHash free. It could be argued that they're superfluous, but given that there may well be other hash PMCs that use this code eventually, it might be worth testing it independently. Mike hash.t Description: application/text
Re: [PATCH] Re: [perl #23752] [BUG] op 'index' fails with mixed character sets
Luke Palmer [EMAIL PROTECTED] wrote: Here's a fix. Thanks. applied. Luke leo
Re: [perl #23910] [PATCH] POD format fix in PDD 7
Michael Scott [EMAIL PROTECTED] wrote: The GNU Indent options list was not formatting correctly in PDD 7. Thanks, applied. leo
Re: parrot -t
Leopold Toetsch [EMAIL PROTECTED] wrote: Will Coleda [EMAIL PROTECTED] wrote: Should parrot -t 2 /dev/null work the same as parrot 2 /dev/null ? (that is, are the results of the program the same except for the additional output printed to stderr?) It should work the same. But currently -t leaks memory like a sieve and is totally unusable for non trivial programs. Actually it doesn't leak memory but it exhausts memory. I'm currently investigating the problem, which is caused by all the DOD/GC blocking mainly in Parrot_vsprintf ... leo
[CVS ci] GC handling code review
This patch fixed several problems WRT GC: - parrot -t examples/assembly/mandel.pasm 2 /dev/null took several 100 MByte to run because: - DOD/GC was disabled in Parrot_vsprintf and friends - removing unnecessary DOD/GC block statements revealed some bugs: - the method_table inside VTABLEs was not properly marked and - t/src/*.t have to set interpreter-lo_var_ptr now, because they never enter a run-loop, where the stack limit is set. - finally hash.c WRT GC is straightend and fixed leo
Re: nmake languages fails (Win32)
Jonathan Worthington [EMAIL PROTECTED] writes:
- Original Message -
From: Leopold Toetsch [EMAIL PROTECTED]
To: Jonathan Worthington [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, September 19, 2003 5:50 PM
Subject: Re: nmake languages fails (Win32)
Jonathan Worthington [EMAIL PROTECTED] wrote:
Hi,
nmake languages is failing because /'s rather than \'s are used in
paths.
Makefiles, e.g. like the befunge one, contain this:-
PARROT = ../../parrot
Did you try Juergen Boemmels proposal RFT / patch?
I actually went through all the makefiles and put ${slash} in place of all
the /'s in paths. Would Juergen's proposal be better? I noticed there was
already a ${slash}defined in the config.
This was one part of my patch. But Steve tought it would decrease
readability to much. ATM I'm experimenting with a makefile.pl based
hack.
With my changes it appears to work fine apart from the cola makefile uses
chomd, which doesn't work under Win32. So, I added chmod to the config
data, and under Win32 it uses rem instead of chmod - essentially commenting
it out. It's a bit of a hack, but it should work - it's attached in a
separate diff in case it's not liked. :-)
IMCC is build twice for this reason.
I say should work because cola has a makefile generated by the developer,
not by parrot's configure system. Thus even with my addition of the chmod
variable it doesn't work out. What's the best option from here?
- Make cola's makefile be generated with configure?
- Exclude cola from being made under Win32 for this release?
If you let me know which one I can have a go at it.
Make the makefile generated by Configure. But this couples the
languages very close to the core system. Maybe Makefile.in should be
resurrected in the languages/ directory.
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: parrot -t
Leopold Toetsch [EMAIL PROTECTED] wrote: Will Coleda [EMAIL PROTECTED] wrote: Should parrot -t 2 /dev/null work the same as parrot 2 /dev/null Actually it doesn't leak memory but it exhausts memory. I'm currently investigating the problem, which is caused by all the DOD/GC blocking mainly in Parrot_vsprintf ... Please cvs update and check again if the problem still persists. leo
Re: [RfC] Semantics of fdopen.
Nicholas Clark [EMAIL PROTECTED] writes: On Fri, Sep 05, 2003 at 05:24:48PM +0200, Juergen Boemmels wrote: * Add an layer-argument to PIO_open and PIO_fdopen, which walk the layerstack and search for the Open-implementation. The current implentation of PIO_open with the default layer should be renamed to PIO_open_default. What is the layer stack? That term doesn't seem to be defined anywhere. The documentation of ParrotIO is uhm... suboptimal. ParrotIO uses handles IO request via layers. Each request is handled either directly by the layer or the request is passed down to the next layer. The layer stack is something that is associated with an io-handle. (OK, I can make a guess based on what perl 5.8 is doing) I can see why one would have a layer stack on an open file handle, but doesn't open crate file handles? Or is the action of open something that happens after file handle construction (hence there can be a stack by open time)? Open and fdopen create an IO-handle. But currently this IO-handle has always the current default layer (stack) associated with it, which is an interpreter-variable. There should be a possiblity of opening a file on a different layer. Nicholas Clark bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: parrot -t
On Mon, 22 Sep 2003, Leopold Toetsch wrote: Leopold Toetsch [EMAIL PROTECTED] wrote: Will Coleda [EMAIL PROTECTED] wrote: Should parrot -t 2 /dev/null work the same as parrot 2 /dev/null Actually it doesn't leak memory but it exhausts memory. I'm currently investigating the problem, which is caused by all the DOD/GC blocking mainly in Parrot_vsprintf ... Please cvs update and check again if the problem still persists. Looks like they might've broken the JIT. (Or something else recently did) make testj fails on two of the string tests now. (91 and 92) Dan
Re: string_to_cstring()
Gregor N. Purdy [EMAIL PROTECTED] writes:
Nicholas --
I'd be happy with that...
[...]
Instead could we just ditch the C-style put? (and make the layer table
one pointer smaller)
Thats something I wanted to do, See [RfC] Cleanup of ParrotIOLayerAPI
I just wanted to let the release pass by.
Anyone who wants to put a \0 terminated string can do the strlen
themselves. (Or we could provide a helpful macro)
I don't want to remove the PIO_puts function; It will just be
changed to
INTVAL
PIO_puts(theINTERP, PMC *pmc, const char *s)
{
return PIO_write(interpreter, pmc, s, strlen(s));
}
Maybe a rename is also needed. Have we decided for a suffix for
functions taking a c-string yet?
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Problem building jako (perl version dependency?)
On Thu, 18 Sep 2003, Gregor N. Purdy wrote:
Andy --
I didn't see anything wrong in the code, but I added some parens.
Let me know if you still have trouble...
Yup, still the same problem. Here's the line in question:
Can't modify subroutine entry in scalar assignment at lib/Jako/Symbol.pm
line 83, near 'arg';
sub is_variable { my $self = shift; return ($self-kind eq 'var') or
($self-kind = 'arg'); }
It's the ($self-kind = 'arg') assignment that's illegal under 5.00503.
--
Andy Dougherty [EMAIL PROTECTED]
Re: parrot -t
Dan Sugalski wrote: Looks like they might've broken the JIT. (Or something else recently did) make testj fails on two of the string tests now. (91 and 92) Yep. Two missing end in the newly added tests WRT string index and encodings - fixed. Dan leo
Re: Pondering argument passing
On Sep-21, Leopold Toetsch wrote:
Steve Fink [EMAIL PROTECTED] wrote:
That would make it fun to track register usage.
And here is the problem with all these shortcuts.
But any one of these instructions could be treated by IMCC as
potentially reading from and writing to all PMC registers, except when
generated by IMCC itself for handling the calling conventions.
Anyway, we should first finalize return conventions (it was proposed
these to be symmetric to calling conventions).
It seems like there was widespread agreement to that proposal. Dan?
Then finish pcc.c.
What's needed?
Then we need code from HLL to see, how efficient (or not) parameter
passing does look like.
I've been trying to implement A6 for languages/perl6. My first cut was
to have all calls, prototyped or not, take three parameters: an array
of all the positional args, an array of all named parameters with
statically-known names, and a hash of all remaining named params. I
have that version working for basic stuff, but it is obviously not
what Dan intended. f($a,$b) does not pass $a in P5 and $b in P6;
instead, it passes Array($a,$b) in P5, Array() in P6, and Hash() in
P7. (And it disagrees with the Perl6 builtin functions, which means I
can't use the same prototypes for builtins and user functions, which
is a mess.)
So I have many Perl6 examples of function calls that I have been
working off of, but none of them are particularly non-obvious. If it
helps, here's a list off the top of my head, not including any named
arguments:
Calls:
f($a)
f($a,$b)
f([EMAIL PROTECTED])
f($a,[EMAIL PROTECTED])
f($a,[EMAIL PROTECTED],$c)
f([EMAIL PROTECTED],[EMAIL PROTECTED])
f([EMAIL PROTECTED],@b)
Prototypes:
sub f($a)
sub f(int $a)
sub f([EMAIL PROTECTED])
sub f($a,[EMAIL PROTECTED])
sub f($a,?$b)
sub f($a,?$b,[EMAIL PROTECTED])
Those calls should be considered in both prototyped and non-prototyped contexts.
Then we can think of some higher level ops to {de,}construct argument
arrays.
Well, I'd also like to know what the IMCC syntax will look like for
dynamically-sized lists of arguments and parameters, independent of
how they are implemented. (If I just had that, I could hack together
some horrible nasty implementation that would get thrown away, but in
the meantime would allow me to proceed with the A6 stuff.)
Re: jako causing MANIFEST failures
On Sep-21, Gregor N. Purdy wrote: Nick -- Looks like I'm the guilty party. I do tend to do this every now and again, even though I don't consider myself thoughtless or careless. I think sometimes I get focused on my local changes and as I'm testing and committing it just isn't natural to consider that a change in something that *depends on* the rest of Parrot will cause a build failure of Parrot. It may be that I'm the only one that feels that way, but perhaps not. A sure way to make the problem go away is to make the building of these other pieces of code fail when the problem exists. One way to accomplish that would be to have the various languages have their own MANIFEST files that are checked every time you do a 'make' there. That way, if I have a clean checkout of the entirety of Parrot, and it builds fine, and then I go off and make a change to Jako, I'll get the complaint right then and there instead of having to remember to go back and build/test Parrot again (which hasn't been changed after all). Given the number of times the same failure has been triggered by other people, I would say that you are definitely not the only one. I know I've done it a few times. I don't really like splitting up the MANIFEST, though -- that changes what it means and reduces its ability to be plugged into existing tools. I propose instead that we should make it easy to write local manifest checks. Then all non-root makefiles could add a local-manicheck target to their 'test' target that would check only the portions of the manifest that are within the relevant subdirectory. Except that parts of a local area may be outside that directory, eg config/gen/makefiles/jako.in is really part of the Jako project. But that's easy to fix -- just don't bother to filter out the rest of the system in your local-manicheck target. Since the MANIFEST should be up-to-date during checkin at all times, this should catch exactly the same set of errors, and the check is fast enough to not be a burden. So we just need to come up with a good canonical way of calling the root-level t/src/manifest.t from subdirectories. We probably ought to implement it as a parrot/lib/ module.
Re: Problem building jako (perl version dependency?)
Andy Dougherty writes:
On Thu, 18 Sep 2003, Gregor N. Purdy wrote:
Andy --
I didn't see anything wrong in the code, but I added some parens.
Let me know if you still have trouble...
Yup, still the same problem. Here's the line in question:
Can't modify subroutine entry in scalar assignment at lib/Jako/Symbol.pm
line 83, near 'arg';
sub is_variable { my $self = shift; return ($self-kind eq 'var') or
($self-kind = 'arg'); }
Uhh, that last statement is bad. Unless Creturn is somehow special,
you're effectively executing:
(return $self eq 'var') or ($self-kind = 'arg')
Which I imagine is not the intent, as return doesn't, well, return.
Luke
It's the ($self-kind = 'arg') assignment that's illegal under 5.00503.
--
Andy Dougherty[EMAIL PROTECTED]
missing ops/vtable: lsr, pow
We have vtables for shr/shl but not for lsr. Is there a specific
reason that these vtables are not in pdd02?
The same is with pow, though this could be treated like the
trigonometric ops, which we don't have for PMCs either.
BTW: What about trig ops for PMCs:
sin P1, P0 # no vtable, so ...
set N0, P0 # 2 more ops to convert
sin N1, N0
set P1, N1
or
op sin(in PMC, in PMC) {
double n0 = VTABLE_get_number(interp, $2);
double n1 = sin(n0);
VTABLE_set_number_native(interp, $1, n1);
}
or
trig P1, P0, sin # implemented as method in PerlScalar or ...
trig P1, P0, .PERL_SCALAR_SIN_METHOD
Ctrig would use Cfind_method. The latter with an
array-lookup/integer index (if find_method uses an OrderedHash as method
table).
leo
Re: missing ops/vtable: lsr, pow
On Mon, 22 Sep 2003, Leopold Toetsch wrote: We have vtables for shr/shl but not for lsr. Is there a specific reason that these vtables are not in pdd02? Mainly because languages generally only define a single left and right shift operator The same is with pow, though this could be treated like the trigonometric ops, which we don't have for PMCs either. I've considered adding a separate sub-vtable for trig ops, hanging off a pointer in the class' base vtable, so multiple classes can share a single trig vtable. I don't expect it to be overridden enough to be worth adding another 128 bytes (or more) to each vtable we use. Most of the trig functions can be return function(SELF-get_float) or something like that. Dan
Trig functions for vtables
Okay, since it seems reasonable to hang the trig functions off of PMCs, we'd best get a list of the functions we want. I can think of: pow logarithm square root (yes, I know, it's for speed) Normal and hyperbolic versions of: sine cosine tangent cotangent arcsine arccosine arctangent arccotangent There are, I'm sure, others. The base version of these, which all classes will share unless overridden, will just get the double value of the PMC in question and perform the operation on that, so we only have to do this once by default, but classes can override it if they really, really want to. Dan
Re: Pondering argument passing
Steve Fink [EMAIL PROTECTED] wrote:
On Sep-21, Leopold Toetsch wrote:
Anyway, we should first finalize return conventions (it was proposed
these to be symmetric to calling conventions).
It seems like there was widespread agreement to that proposal. Dan?
Yep.
Then finish pcc.c.
What's needed?
Return conventions. They work but don't handle prot/non-proto cases. And of
course spilling, register allocation and opimization.
Then we need code from HLL to see, how efficient (or not) parameter
passing does look like.
I've been trying to implement A6 for languages/perl6. My first cut was
to have all calls, prototyped or not, take three parameters:
suboptimal for sure
Then we can think of some higher level ops to {de,}construct argument
arrays.
Well, I'd also like to know what the IMCC syntax will look like for
dynamically-sized lists of arguments and parameters,
Just use a PerlArray:
.sym PerlArray params
params = new PerlArray
push params, arg1
push params, arg2
...
.arg params
.pcc_call ...
Then in the sub:
.pcc_sub _sub
.param params
.local var a1
.local var a2
shift a1, params
shift a2, params
...
leo
Re: cvs commit: parrot/lib/Parrot Vtable.pm
Dan Sugalski [EMAIL PROTECTED] wrote: +vtables$(O) : $(GENERAL_H_FILES) vtables.c This is missing as vtable.h leo
Re: cvs commit: parrot/lib/Parrot Vtable.pm
On Mon, 22 Sep 2003, Dan Sugalski wrote: On Mon, 22 Sep 2003, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: +vtables$(O) : $(GENERAL_H_FILES) vtables.c This is missing as vtable.h There are a bunch of .h files that aren't in the dependencies, which is why I left it out. (Not, mind, that it's a *good* reason, but...) Though I probably ought to check in vtables.h and update the manifest... Dan
RE: Trig functions for vtables
(Forgot to send this to the list. Again. *sighs*) Dan Sugalski: # Okay, since it seems reasonable to hang the trig functions off of PMCs, # we'd best get a list of the functions we want. I can think of: # # pow # logarithm # square root (yes, I know, it's for speed) # # Normal and hyperbolic versions of: # sine # cosine # tangent # cotangent # arcsine # arccosine # arctangent # arccotangent Okay, reality check. How often are we going to use acosh? Is it really worth the space in the vtable for that few calls? And why can't we just use find_method? Basically, where do you draw the line between a vtable method and a find_method method? Unless the line is methods that everything should support, I'd say it's been crossed when you add acosh to the vtable. And if that *is* where the line is, don't be surprised when vtables cross the megabyte line. I'm really starting to wonder: why do we have only one type of vtable? Why are Closures, Pointers, and Scratchpads forced to implement acosh, splice, pop, or even get_float? And why are PerlInts forced to implement invoke and can_keyed? Vtable.tbl already divides vtables into sections. I suggest we take this a step further and express these sections in the vtables itself. Sections that a particular object didn't need would be loaded with a default, in which all of the methods would throw an exception. The result would mean that something like: pmc-vtable-add Might become: pmc-vtable-math-add And: pmc-vtable-add_keyed Might become: pmc-vtable-keyed-math-add This would make it easier to implement non-keyed objects, and the extra dereference would be lost in the overhead of dealing with keys and aggregates anyway. Best of all, if a PMC class doesn't need math calls, it can simply put this in its vtable definition, in place of the curlies delimiting the set of math calls: Parrot_pmc_default_math_vtable --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna set myself on fire to prove it.
Re: Trig functions for vtables
Brent Dax writes: Dan Sugalski: # Okay, since it seems reasonable to hang the trig functions off of PMCs, # we'd best get a list of the functions we want. I can think of: # # pow # logarithm # square root (yes, I know, it's for speed) # # Normal and hyperbolic versions of: # sine # cosine # tangent # cotangent # arcsine # arccosine # arctangent # arccotangent Okay, reality check. How often are we going to use acosh? Is it really worth the space in the vtable for that few calls? And why can't we just use find_method? And let's not forget our handy trig identities. We definitely don't need all those vtable. Technically, all we need are sine and arccosine. I think putting in cosine, arcsine, and [arc]?tangent would be nice, too. Cotangent is easy, and is so infrequently used that it's kind of silly to include. And hyperbolics are very infrequently used, and can be implemented in terms of exp, which in turn can be implemented in terms of pow, but shouldn't. Basically, where do you draw the line between a vtable method and a find_method method? Unless the line is methods that everything should support, I'd say it's been crossed when you add acosh to the vtable. And if that *is* where the line is, don't be surprised when vtables cross the megabyte line. But that's not even the line. There are a lot of methods in there which a lot of classes don't support. Now that we have find_method, it might be a good idea to define our critera for vtable functions, and then prune the vtable accordingly. Maybe. I'm really starting to wonder: why do we have only one type of vtable? Why are Closures, Pointers, and Scratchpads forced to implement acosh, splice, pop, or even get_float? And why are PerlInts forced to implement invoke and can_keyed? Vtable.tbl already divides vtables into sections. I suggest we take this a step further and express these sections in the vtables itself. Sections that a particular object didn't need would be loaded with a default, in which all of the methods would throw an exception. The result would mean that something like: pmc-vtable-add Might become: pmc-vtable-math-add And: pmc-vtable-add_keyed Might become: pmc-vtable-keyed-math-add This would make it easier to implement non-keyed objects, and the extra dereference would be lost in the overhead of dealing with keys and aggregates anyway. Best of all, if a PMC class doesn't need math calls, it can simply put this in its vtable definition, in place of the curlies delimiting the set of math calls: Parrot_pmc_default_math_vtable Hmm. I think that's a pretty good idea. Of course, the indirections cost, but we have to give space part of the tradeoff somewhere. On another, related, but not too related, note... That is to say, rant When I went and tried to implement the Infinity pmc, I ran into a lot of problems. I just wanted a value that could be put into a perlscalar that could act like an infinitely large (or small) integer. I ended up copying tons of code from PerlInt, etc. just to get the polymorphism to work (for some reason putting it all up into perlscalar died big-time). As far as the var/value split, we need something to support that. 'fetch' and 'store' would be really nice, as sort-of unkeyed variants of get_pmc_keyed. If something like this already exists, some ops to actually manipulate it would be nice. Then one could implement Infinity (or even PerlNum) as a non-polymorphic object, and let PerlScalar handle the polymorphism. Which, as far as adding new typed, I think would be a Very Good Thing. /rant Luke --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna set myself on fire to prove it.
Re: parrot -t
Note to self: always read all emails from leo before composing a reply. Other note to self: don't send in bug reports when you've been up for 24 hours, it's probably your fault, anyway. Ok. got a cvs udpate, did a make distclean, rebuilt (btw, the manifest is broken. I'm pretty sure this, at least, is not my fault. =-)... Bother. In attempting to duplicate the problem, I see that my problem is... me. Well, and a stupid makefile rule. I used make exit to run the normal version and make exit-t to run the -t version... but I didn't strip off the -t on the file name, so instead of trying to process exit.tcl, it was trying to process exit-t.tcl. So the version that didn't generate any output was actually behaving nicely - there was no input file, so it stopped early. All the other versions suggested i ran by hand, avoiding my make stupidity. renStmpy, you ediot!/ren The cvs-latest makes this *much* clearer by throwing a bus error when I try to read the file with the wrong name. (but it does that with or without the -t option.) I apologize to all for the wild goose chase. Hopefully I'll have something to show for it shortly. On Monday, September 22, 2003, at 08:03 AM, Leopold Toetsch wrote: Leopold Toetsch [EMAIL PROTECTED] wrote: Will Coleda [EMAIL PROTECTED] wrote: Should parrot -t 2 /dev/null work the same as parrot 2 /dev/null Actually it doesn't leak memory but it exhausts memory. I'm currently investigating the problem, which is caused by all the DOD/GC blocking mainly in Parrot_vsprintf ... Please cvs update and check again if the problem still persists. leo -- Will Coke Coledawill at coleda dot com
Re: Parrot 0.0.11 Doubloon Released!
On Mon, Sep 22, 2003 at 09:20:50AM -0700, Steve Fink wrote: A parrot-0.0.11.2.tar.gz is now staggering drunkenly towards CPAN, using VERSION=0.0.11. I even tested it this time. If people want 0.0.12 instead, I can do that too. Only if it has objects and exceptions and moon-on-a-stick :-) Argh. Thanks for all your toils in getting a release out. Nicholas Clark
Re: Trig functions for vtables
On a related note, I wonder how all this fits in with
methods and multimethods?
If we consider the current trig.ops as being equivalent
to, e.g. (expressed with approximate Perl 6 isms):
multi sub sin(Num $arg) : returns Num;
multi sub cos(Num $arg) : returns Num;
ASIDE
And, at some level I do think some of the more primitive
Perl 6 builtins should be expressed in a Perl syntax that
indicates this is an op, go to it! (like I implemented
in Jako. For example, the file 'string.jako' has guts
that look like this:
module string
{
sub concat :op (str dest, str s);
sub int index :op (str input, str pattern, int start);
sub int length :op (str dest);
sub str substr :op (str s, int i, int l);
}
(if
the sub name != the op name, then you can use :op='foo')
This ends up corresponding nicely to related syntax for
NCI. For example, here is Curses.jako:
module Curses
:fnlib = libcurses.so
{
sub int initscr :fn ();
sub int endwin :fn ();
sub int curs_set :fn (int x);
sub int addstr :fn (str s);
sub int refresh :fn ();
sub int move :fn (int x, int y);
sub int getch:fn ();
sub int box :fn (int screen, int v, int h);
sub int hline:fn (int ch, int n);
}
(if
the func name != the sub name, then you can use :fn='bar')
/ASIDE
Now, along comes the Perl6Scalar PMC, which implements
multi sub sin(Perl6Scalar $arg) : returns Perl6Scalar;
multi sub cos(Perl6Scalar $arg) : returns Perl6Scalar;
In short, it would be nice if
PMC == Class with opaque implementation
(in our case its a C implementation, but I suppose as
soon as someone implements a class in Python and another
person uses it in Perl, its opaque in Perl). Hmm...
Opaque smells kind of like closed, although maybe not
exactly.
Now, along comes some new class that doesn't implement its
own sin(), etc. What should happen? Well, if it is known to
be convertible without loss of information to something that
does have sin(), etc. then things should just work. If they
don't work fast enough, then someone can go to the trouble
to implement the appropriat multi sub in C. As long as we
never implicitly apply a lossy conversion, things should work
fine.
The deeper into the internals we can carry off the similarity
while still being Fast as All Get Out (TM), the better.
Regards,
-- Gregor
On Mon, 2003-09-22 at 15:08, Luke Palmer wrote:
Brent Dax writes:
Dan Sugalski:
# Okay, since it seems reasonable to hang the trig functions off of
PMCs,
# we'd best get a list of the functions we want. I can think of:
#
# pow
# logarithm
# square root (yes, I know, it's for speed)
#
# Normal and hyperbolic versions of:
# sine
# cosine
# tangent
# cotangent
# arcsine
# arccosine
# arctangent
# arccotangent
Okay, reality check. How often are we going to use acosh? Is it really
worth the space in the vtable for that few calls? And why can't we just
use find_method?
And let's not forget our handy trig identities. We definitely don't
need all those vtable. Technically, all we need are sine and arccosine.
I think putting in cosine, arcsine, and [arc]?tangent would be nice,
too. Cotangent is easy, and is so infrequently used that it's kind of
silly to include. And hyperbolics are very infrequently used, and can
be implemented in terms of exp, which in turn can be implemented in
terms of pow, but shouldn't.
Basically, where do you draw the line between a vtable method and a
find_method method? Unless the line is methods that everything should
support, I'd say it's been crossed when you add acosh to the vtable.
And if that *is* where the line is, don't be surprised when vtables
cross the megabyte line.
But that's not even the line. There are a lot of methods in there which
a lot of classes don't support. Now that we have find_method, it might
be a good idea to define our critera for vtable functions, and then
prune the vtable accordingly. Maybe.
I'm really starting to wonder: why do we have only one type of vtable?
Why are Closures, Pointers, and Scratchpads forced to implement acosh,
splice, pop, or even get_float? And why are PerlInts forced to
implement invoke and can_keyed?
Vtable.tbl already divides vtables into sections. I suggest we take
this a step further and express these sections in the vtables itself.
Sections that a particular object didn't need would be loaded with a
default, in which all of the methods would throw an exception.
The result would mean that something like:
pmc-vtable-add
Might become:
pmc-vtable-math-add
And:
pmc-vtable-add_keyed
Might become:
Re: Parrot 0.0.11 Doubloon Released!
On Sep-21, Gerrit P. Haase wrote: Hallo again, http://cpan.perl.org/authors/id/S/SF/SFINK/parrot-0.0.11.1.tar.gz And all we need now is a 0.0.11.2, with patches to allow four-element version numbers... [...] Ouch, better take this: $ diff -urd parrot-0.0.11.1/VERSION~ parrot-0.0.11.1/VERSION --- parrot-0.0.11.1/VERSION~2003-09-21 13:17:42.490672000 +0200 +++ parrot-0.0.11.1/VERSION 2003-09-21 13:16:56.794964800 +0200 @@ -1 +1 @@ -0.0.11.1 +0.0.11 Heh. I just went down the same road, and came to the same conclusion. For the casual observers: The problem is that those patches to allow four-element version numbers are decidedly nontrivial. The immediate failure is lib/Parrot/BuildUtil, which aborts Configure.pl because it insists on seeing 3-part version numbers. The next failure is ops2c.pl, which uses Parrot::OpsFile to tell it the decomposed parts of the version string -- major, minor, patchlevel. And it appears that those three values are stored in the bytecode, and I'm guessing that the value 1.2 will not fit very comfortably into an integer field. So even if we wanted to allow 4-digit version strings, it's too much of a change to make while packaging up a release, so it's much easier to just say the version is 0.0.11 and be done with it. Or if you really want proper versioning, 0.0.12. If we got out of this silly version 0.0 hole, then we wouldn't need to be so hung up about the stupid patch level. A parrot-0.0.11.2.tar.gz is now staggering drunkenly towards CPAN, using VERSION=0.0.11. I even tested it this time. If people want 0.0.12 instead, I can do that too. Argh.
