Complex numbers

2002-02-03 Thread Boris Tschirschwitz
Hi. During the vtable discussions lately, a complex type was used in examples a lot. I have a more or less complete implementation of a complex number PMC. After writing it, I started wondering, if this wouldn't just be unneccessary overhead at this point, so I let it sleep. But if there's intere

Parrot directory structure

2002-02-03 Thread davem
Parroteers, I've been thinking about the directory structure of Parrot. Currently, the top-level dir is a bit of mess, with zillions of files of various flavours. It is my contention that apart from a few expected files such as README, MANIFEST, Configure.pl etc, everything else should be in subd

Re: [PATCH] POST_MORTERM, running.pod [APPLIED]

2002-02-03 Thread Robert Spier
> >I could also replace some "perl foo" calls with "./foo" if someone > >wanted to set the executable flag in CVS on assemble.pl, optimize.pl, > >etc. Done. (For all the .pl files in the root directory.) You'll need to delete them and let CVS recreate them (cvs update) for the change to take e

Re: Parrot FAQ location

2002-02-03 Thread Robert Spier
On Fri, 2002-01-25 at 09:07, Melvin Smith wrote: > > >1.> There is no link to the FAQ on the Perl6 page (that I could find > anyway). > > (http://www.panix.com/~ziggy/parrot.html - I think this it) > > This really should be stored or linked in the Perl6 Parrot area. > The new location is h

Re: autogenerating some vtable-methods

2002-02-03 Thread Steve Fink
On Sun, Feb 03, 2002 at 09:29:27PM +0100, Juergen Boemmels wrote: > Hi there, > > I played again a little with the vtables. > I noticed that all *.pmc function implement the methods type and name > are implemented the same way. Then I was wondering if its possible to > autogenerate this functions

autogenerating some vtable-methods

2002-02-03 Thread Juergen Boemmels
Hi there, I played again a little with the vtables. I noticed that all *.pmc function implement the methods type and name are implemented the same way. Then I was wondering if its possible to autogenerate this functions in the pmc2c.pl This patch implements autogeneration of this functions, and

[PATCH] Win32 JIT ( + other misc fixes )

2002-02-03 Thread Mattia Barbon
This is for MinGW ( read below why not MSVC ) Changes: * Configure.pl correctly detect $cpuarch/$osname * jit2h.pl Accept a new osname parameter search jit/cpuarch/$file-$osname.jit, and if found add ops found there/override ops in $file.jit * Makefile.in add jitosname to the paramete

RE: [pythonesque] vtable ideas

2002-02-03 Thread Angel Faus
Simon said: > > I see. ?But what's the rational to have Bigints / Bigfloat be native types > > instead of PMCs? > > They're useful and predictable. And also, you may want to automatically > promote integers to bigints; you probably don't want to automatically > promote integers to complex types.

Re: [pythonesque] vtable ideas

2002-02-03 Thread Simon Cozens
begin quote from Angel Faus: > I see. ?But what's the rational to have Bigints / Bigfloat be native types > instead of PMCs? They're useful and predictable. And also, you may want to automatically promote integers to bigints; you probably don't want to automatically promote integers to complex ty

RE: [pythonesque] vtable ideas

2002-02-03 Thread Angel Faus
> > These methods are provided so that we can play with "native" types in our > bytecode then send them to our pmc, as otherwise every constant in our > code would have to be a PMC, which is a little excessive. > > Things like a complex number will be represented by either a PMC class > (very lik

Re: [PATCH] PMC -> string

2002-02-03 Thread Simon Glover
On Fri, 1 Feb 2002, Alex Gough wrote: > On Fri, 1 Feb 2002, Simon Glover wrote: > > > The enclosed patch implements the last of these, and adds tests for > > PerlUndefs and PerlStrings (and implicitly PerlInts and PerlNums - > > should we also add explicit tests for these?). I haven't adde