Will Coleda wrote:
>
> The README doesn't mention Configure.pl (minor doc patch follows), and
> Parrot::Opcode is requiring perl5.6, which makes my 5.5.3 quite unhappy.
>
> Are folks intentially using 5.6 constructs? I'll consider generating a
> patch to make things work with 5.5.3 if this was
Mattia Barbon:
# > PLEASE can someone rewrite the tests to actually *test* things
# > and print "ok 1\n" and so on?
# Here it is ( for the second time )
#
# > Quick, or I'll call Schwern in.
# Ah, I thought you missed my patches, then I was correct
# both attached
...
(in things.diff)
# -C_FLAGS =
The README doesn't mention Configure.pl (minor doc patch follows), and
Parrot::Opcode is requiring perl5.6, which makes my 5.5.3 quite unhappy.
Are folks intentially using 5.6 constructs? I'll consider generating a
patch to make things work with 5.5.3 if this was an act of convenience
rather th
Just a quick note (since I have no time for more commentary...):
for inspiration on the data storage you might want to look at how
Storable has chosen to do things.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. --
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 10:33 PM 9/13/2001 -0400, Uri Guttman wrote:
>> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>>
DS> Actually, I'm expecting almost nothing to be written in pasm after
DS> we get a working parser and compiler. We mi
Quoting Dan Sugalski <[EMAIL PROTECTED]>:
> Hmmm. I think we need a reorg of the source directories, then. I'll get
>
> with Simon and coordinate doing this. (It's going to make CVS *so*
> happy... :)
It's often easier to do this by moving the RCS files inside the CVS respository
directly - it's
> On Thu, Sep 13, 2001 at 11:07:00AM -0600, Nathan Torkington wrote:
> > Isn't the correct solution to this problem to say
> >#include
> >
> > That is, include the subdirectory prefix in all #includes. You -I the
> > directory containing parrot/, and that avoids randomly located
> > config.
This patch adds:
an hints directory ( files are named hints/lc($^O).pl )
therir contents are eval'd in Config.pl
it adds to Config.pl some flags
--debugging Enable debugging
adds -g or equivalento to compiler flags
--defaults Accept all default values
like -d option to
> OffsetLength Description
> 0 1 Magic Cookie (0x013155a1)
> 1 n Data
> n+1 m Directory Table
> m+n+1 1 Offset of beginning of directory table (i.e. n+1)
I think we need a version right after cookie for long term compatibility.
> The directory is after
Not to harp on this subject, but there is still no official place where a
casual developer like myself can find a current listing of PDDs aside from
the perl6-internals mail list archive. http://dev.perl.org/perl6 has not
been updated in a long time... and that's the place that I would expect
peo
> "BW" == Brian Wheeler <[EMAIL PROTECTED]> writes:
BW> On Fri, 2001-09-14 at 10:20, Dan Sugalski wrote:
>> Okay, we've had a number of people in favor of a good macro assembler for
>> Parrot. Given that, do we have anyone who'll volunteer to define, maintain,
>> and extend the thin
At 03:10 PM 09-14-2001 -0500, Brian Wheeler wrote:
>I've been thinking alot about the bytecode file format lately. Its
>going to get really gross really fast when we start adding other
>(optional) sections to the code.
>
>So, with that in mind, here's what I propose:
>What do you guys think?
The README really doesn't have to mention Configure.pl because when you do
make test_prog it will run Configure.pl for you (at least it is supposed to
:)
-Original Message-
From: Will Coleda
To: [EMAIL PROTECTED]
Sent: 9/15/2001 12:13 AM
Subject: Difficulties
The README doesn't mention
At 03:10 PM 9/14/2001 -0500, Brian Wheeler wrote:
>I've been thinking alot about the bytecode file format lately. Its
>going to get really gross really fast when we start adding other
>(optional) sections to the code.
>
>So, with that in mind, here's what I propose:
>
>* All data sizes are in lon
Paul Johnson:
# Call me an old fuddy duddy if you will, or Unix-centric if
# you must, but
# the .pl extension historically refers to Perl Libraries, and even now
# that is my first thought when I see it.
#
# Now I realise that many people working on this project have rarely, if
# ever, used Perl
All --
For your amusement, I've produced a very simple compiler that targets
Parrot assembly language. It implements a tiny language name 'Jako',
the name of an African parrot (also called the gray parrot).
Don't get too excited about the language, since it has only global
data, highly naiive re
At 04:44 PM 9/14/2001 -0400, Buddha Buck wrote:
>>What do you guys think?
>
>Have you taken a look at the old Amiga IFF format? It consisted mainly of
>"chunks" identified by a 32-bit type code and a chunk-length code. While
>most implementations were for specific multi-media applications (ch
> Have you taken a look at the old Amiga IFF format? It consisted mainly of
> "chunks" identified by a 32-bit type code and a chunk-length code. While
> most implementations were for specific multi-media applications (chunks
> defining sound formats, chunks defining image formats, etc), the
On Fri, 2001-09-14 at 15:44, Buddha Buck wrote:
> At 03:10 PM 09-14-2001 -0500, Brian Wheeler wrote:
> >I've been thinking alot about the bytecode file format lately. Its
> >going to get really gross really fast when we start adding other
> >(optional) sections to the code.
> >
> >So, with that i
Uri --
> well, pdp-11 assembler would be very cool to work in again if it weren't
> so painful to reinvent every wheel. c was a big step up and then perl
> even more so. no more (or almost no more) worries about memory
> management and boundary conditions. if a pasm macro assembler allows me
> so
> > I believe that Microsoft is using a derivative of that format for some of
> > its files, and I think that TIFF files are another instantiation.
>
> To avoid using Redmondian references :-) I think IFF was one
> of the strongest inspirations for the PNG .
...and here's a link that explains t
Brian --
> I've been thinking alot about the bytecode file format lately. Its
> going to get really gross really fast when we start adding other
> (optional) sections to the code.
>
> So, with that in mind, here's what I propose:
This may be too crazy, but if we take seriously the notion that
> 8-byte word:endianness (magic value 0x123456789abcdef0)
> byte: word size
> byte[7]:empty
> word: major version
> word: minor version
>
> Where all word values are as big as the word size says they are.
>
> The magic value can be something else, but it
> PLEASE can someone rewrite the tests to actually *test* things
> and print "ok 1\n" and so on?
Here it is ( for the second time )
> Quick, or I'll call Schwern in.
Ah, I thought you missed my patches, then I was correct
both attached
testsuite.diff:
-
Run with
perl
--- Brian Wheeler <[EMAIL PROTECTED]> wrote:
> I've been thinking alot about the bytecode file format
> lately. Its
> going to get really gross really fast when we start
> adding other
> (optional) sections to the code.
>
> So, with that in mind, here's what I propose:
>
> * All data sizes are
On Fri, 2001-09-14 at 15:42, Dan Sugalski wrote:
> At 03:10 PM 9/14/2001 -0500, Brian Wheeler wrote:
> >I've been thinking alot about the bytecode file format lately. Its
> >going to get really gross really fast when we start adding other
> >(optional) sections to the code.
> >
> >So, with that i
Simon Cozens writes:
> So maybe the best thing would be for people to send patches to the
> list and Cc [EMAIL PROTECTED]
I wonder if, when RT comes online, we could use that to manage the
patches. In other words, patches become open "to do" items, which are
cleared when the patches are definiti
At 01:56 PM 9/14/2001 -0700, Hong Zhang wrote:
> > 8-byte word:endianness (magic value 0x123456789abcdef0)
> > byte: word size
> > byte[7]:empty
> > word: major version
> > word: minor version
> >
> > Where all word values are as big as the word size says
> We can't do that. There are platforms on both ends that
> have _no_ native 32-bit data formats (Crays, some 16-bit
> CPUs?). They still need to be able to load and generate
> bytecode without ridiculuous CPU penalties (your Palm III
> is not running on a 700MHz Pentium III, after all!)
If the p
Call me an old fuddy duddy if you will, or Unix-centric if you must, but
the .pl extension historically refers to Perl Libraries, and even now
that is my first thought when I see it.
Now I realise that many people working on this project have rarely, if
ever, used Perl 4 or earlier versions, and
--- Brian Wheeler <[EMAIL PROTECTED]> wrote:
> Ok, what if we did IFF with these caveats:
> * all chunks must be padded to 4 bytes (instead of IFF's
> 2)
> * no nesting of FORMs
>
> Chunks we'd need are:
>
> Name: 'PINF' - Parrot Information
> Size: 28 bytes + size o
On Fri, Sep 14, 2001 at 02:26:37PM -0700, Hong Zhang wrote:
> > We can't do that. There are platforms on both ends that
> > have _no_ native 32-bit data formats (Crays, some 16-bit
> > CPUs?). They still need to be able to load and generate
> > bytecode without ridiculuous CPU penalties (your Palm
Benjamin Stuhl:
# --- Brian Wheeler <[EMAIL PROTECTED]> wrote:
# > I've been thinking alot about the bytecode file format
# > lately. Its
# > going to get really gross really fast when we start
# > adding other
# > (optional) sections to the code.
# >
# > So, with that in mind, here's what I prop
> There's a one-off conversion penalty at bytecode load time, and I don't
> consider that excessive. I want the bytecode to potentially be in platform
> native format (4/8 byte ints, big or little endian) with a simple and
> well-defined set of conversion semantics. That way the bytecode loader
> It will be hard to use one format for both native and portable.
Not one format, but a set of closely related formats with well-defined
transformations between them.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'.
(Sorry, already deleted message to which I was going to reply)
to eliminate the extra ".", .tar.gz -> .tgz
Regards.
I might try tonight doing *very* simple code to portably write and
read the bytecode header since I have access to 32/64 little/big
endian boxes and to the resident gremlin of a platform, UNICOS.
(Well, it's really UNICOS/mk, so it's LE, not BE, as real UNICOS,
but it still has the funky integer s
On Fri, Sep 14, 2001 at 04:42:21PM -0400, Dan Sugalski wrote:
> Where all word values are as big as the word size says they are.
What should the byteloader do when it encounters data in a word that
cannot fit in a native word?
Re: IFF. Being an old Amiga user, I find it appealing. Is the lack
On Fri, Sep 14, 2001 at 03:01:11PM -0700, Damien Neil wrote:
> On Fri, Sep 14, 2001 at 04:42:21PM -0400, Dan Sugalski wrote:
> > Where all word values are as big as the word size says they are.
>
> What should the byteloader do when it encounters data in a word that
> cannot fit in a native word?
At 10:16 AM 9/14/2001 -0400, Gregor N. Purdy wrote:
>All --
>
>For your amusement, I've produced a very simple compiler that targets
>Parrot assembly language. It implements a tiny language name 'Jako',
>the name of an African parrot (also called the gray parrot).
Keen! And I added a little_langu
On Sat, Sep 15, 2001 at 01:03:51AM +0300, Jarkko Hietaniemi wrote:
> > Re: IFF. Being an old Amiga user, I find it appealing. Is the lack
> > of a dictionary likely to be a significant problem?
>
> Please elaborate.
IFF stores a linear series of chunks. Each chunk has a header containing
the
At 03:01 PM 9/14/2001 -0700, Damien Neil wrote:
>On Fri, Sep 14, 2001 at 04:42:21PM -0400, Dan Sugalski wrote:
> > Where all word values are as big as the word size says they are.
>
>What should the byteloader do when it encounters data in a word that
>cannot fit in a native word?
That, generally
At 10:33 PM 9/13/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> Actually, I'm expecting almost nothing to be written in pasm after
> DS> we get a working parser and compiler. We might write template code
> DS> for the compiler in it, but that'
On Sat, Sep 15, 2001 at 12:39:39AM +0300, Jarkko Hietaniemi wrote:
> > It will be hard to use one format for both native and portable.
>
> Not one format, but a set of closely related formats with well-defined
> transformations between them.
After thinking about implementing this for a bit, I'm
At 03:18 PM 9/14/2001 -0700, Damien Neil wrote:
>On Sat, Sep 15, 2001 at 01:03:51AM +0300, Jarkko Hietaniemi wrote:
> > > Re: IFF. Being an old Amiga user, I find it appealing. Is the lack
> > > of a dictionary likely to be a significant problem?
> >
> > Please elaborate.
>
>IFF stores a linear
At 03:29 PM 9/14/2001 -0700, Damien Neil wrote:
>On Sat, Sep 15, 2001 at 12:39:39AM +0300, Jarkko Hietaniemi wrote:
> > > It will be hard to use one format for both native and portable.
> >
> > Not one format, but a set of closely related formats with well-defined
> > transformations between them.
On Fri, Sep 14, 2001 at 08:34:22AM -0600, Nathan Torkington wrote:
> I wonder if, when RT comes online, we could use that to manage the
> patches. In other words, patches become open "to do" items, which are
> cleared when the patches are definitively applied or rejected.
That would be nice; som
On Fri, Sep 14, 2001 at 10:20:00AM +0100, Simon Cozens wrote:
> On Thu, Sep 13, 2001 at 08:54:40PM -0700, Damien Neil wrote:
> > Here's an updated version of my original patch, to account for recent
> > changes in CVS. As before, this includes opcode-munging to let Parrot
> > run on FreeBSD.
...
Since we are so early in the game, I'm not sure if it really matters whether
we keep the version information or not. Does anyone have a problem with me
deleting the header files and readding them under include/parrot/. or is the
general concensus moving the RCS files?
Also, would anyone like to
On Fri, Sep 14, 2001 at 06:37:33PM -0400, Dan Sugalski wrote:
> At 03:29 PM 9/14/2001 -0700, Damien Neil wrote:
> >On Sat, Sep 15, 2001 at 12:39:39AM +0300, Jarkko Hietaniemi wrote:
> > > > It will be hard to use one format for both native and portable.
> > >
> > > Not one format, but a set of clo
On Fri, Sep 14, 2001 at 11:20:36AM -0400, Dan Sugalski wrote:
> Okay, we've had a number of people in favor of a good macro assembler for
> Parrot. Given that, do we have anyone who'll volunteer to define, maintain,
> and extend the thing? (Presuming we jump off of the current assembler,
> whic
The patch assumes that your source code directory is named parrot. This may
have been an invalid assumption, but it is going to be hard to do this patch
unless we agree on the name of the source directory.
-Original Message-
From: Gregor N. Purdy
To: [EMAIL PROTECTED]
Sent: 9/14/2001 11:
The attached assemble.diff has assemble.pl look in its parent
directory if the data files it needs aren't in the current one. This
lets me camp out in t/ and assemble stuff over and over.
The attached Makefile goes in the t/ directory. It lets me reassemble
files by invoking "make test.pbc".
-
Okay, we've had a number of people in favor of a good macro assembler for
Parrot. Given that, do we have anyone who'll volunteer to define, maintain,
and extend the thing? (Presuming we jump off of the current assembler,
which seems reasonable)
There probably isn't a huge amount to do with the
Ok, my previous patch to assemble.pl caused somethings to core dump...I
promise this one won't :) It fixes the problem with numeric values having
the wrong pack type. Also, config_h.in was changed to typedef ${iv} double
NV to typedef ${nv} NV
Index: assemble.pl
You actually don't want to add the Makefile.in patch. Brent Dax submitted a
patch that puts the correct -I./include in the Configure.pl file. If you
don't still have the patch I can forward it to you.
Tanton
-Original Message-
From: Gregor N. Purdy
To: Gibbs Tanton - tgibbs
Cc: 'Rober
At 11:31 AM 9/14/2001 -0500, Gibbs Tanton - tgibbs wrote:
>The patch assumes that your source code directory is named parrot. This may
>have been an invalid assumption, but it is going to be hard to do this patch
>unless we agree on the name of the source directory.
Hmmm. I think we need a reorg
Run with
perl -Mlib=lib t/harness
Tests live in t/*/*.t .
In case of failure the assembler, bytecode and output
are available as t/dir/testnnn.pasm/pbc/out
tested under Linux and Win32
Regards
Mattia
--patch--
diff -r -b -u -2 -N parrot.cvs/lib/Test/Parrot.pm
parrot/lib/Test/Parrot.pm
--- par
On Thu, Sep 13, 2001 at 05:59:13PM +0100, Tom Hughes wrote:
> Especially since all function names starting with str are strictly
> speaking reserved to ANSI/ISO for future expansion of the string.h
> facilities ;-)
Oh blow. If you're worried about namespace pollution, you're definitely
blaming th
On Thu, Sep 13, 2001 at 11:07:00AM -0600, Nathan Torkington wrote:
> Isn't the correct solution to this problem to say
>#include
>
> That is, include the subdirectory prefix in all #includes. You -I the
> directory containing parrot/, and that avoids randomly located
> config.h files from b
On Fri, Sep 14, 2001 at 06:00:38AM +0300, Jarkko Hietaniemi wrote:
> But in some places Perl 5 has to use a similar union trick, too.
> See struct xpvio in sv.h.
Thanks, that swings it; a union it shall be.
Simon
On Fri, Sep 14, 2001 at 12:33:37PM -0400, Rocco Caputo wrote:
> The attached assemble.diff has assemble.pl look in its parent
> directory if the data files it needs aren't in the current one. This
> lets me camp out in t/ and assemble stuff over and over.
>
> The attached Makefile goes in the t/
I have modified assemble.pl to do a slightly different form of
lookup...basically, it takes the op and gets all operations that have op as
a base (followed by (_([ins]c?)|p)+). Then, it goes through each candidate
and compares the arguments declared in opcode_table to the arguments
actually give
On Thu, Sep 13, 2001 at 06:35:39PM -0700, Brent Dax wrote:
> Ask Simon, he's the one who came up with 'config.h.in' in the first
> place.
Oops. Naughty me.
I always fancied doing things like "config.hh" for .h file templates,
but then C++ people might get confused.
On Thu, Sep 13, 2001 at 09:48:27PM -0400, Dan Sugalski wrote:
> Ah, I'm sure it was a slip 'o the keyboard. :) config.h_in (or config_h.in)
> are both OK, and unique enough on 8.3 systems.
Yeah, that was it! Brent, do you want to take care of that.
(config_h.in would be better, since it gets min
I should have that ready in a bit. ITMT, don't apply my other
patches--the next one will cover all of this.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
# -Original Message-
# From: Simon Cozens [mailto:[EMAIL PROTECTED]]
# Sent: Friday, September 14, 2001 01:41
On Thu, Sep 13, 2001 at 12:40:36PM -0500, Gibbs Tanton - tgibbs wrote:
> --- assemble.pl 2001/09/13 16:29:24 1.14
> +++ assemble.pl 2001/09/13 17:38:42
> @@ -31,7 +31,7 @@
> open GUTS, "interp_guts.h";
> my %opcodes;
> while () {
> -next unless /\tx\[(\d+)\] = ([a-z_]+);/;
>
Simon Cozens:
# Yeah, that was it! Brent, do you want to take care of that.
# (config_h.in would be better, since it gets mindshare from the
# current Perl 5 build process.)
Didn't take long--patch below sig. You'll also have to rename
config.h.in to config_h.in yourself.
--Brent Dax
[EMAIL PRO
On Thu, Sep 13, 2001 at 06:20:00PM -0400, Uri Guttman wrote:
> does it make sense for patches to be only sent to simon and then we can
> be notified by the cvs list? it is hard to track what people are doing
> when some patches are in and others are rejected, etc.
NO! Sorry, but I firstly want pe
On Thu, Sep 13, 2001 at 01:57:09PM -0500, Gibbs Tanton - tgibbs wrote:
> I'll keep looking for other coding standard changes.
Woohoo! Applied with much thanks!
Simon
On Thu, Sep 13, 2001 at 02:59:09PM -0500, Gibbs Tanton - tgibbs wrote:
> I think the substr in strnative.c is incorrectly growing the destination
> string.
Yes, it is. D'oh.
> patch for function names...so it needs to be applied after that patch.
Applied with some corrections; since your previo
Gibbs Tanton - tgibbs:
# Here is the parrot/config.h patch
#
# It fixes Makefile.in, but not in the correct way. Brent, if
# you could look
# at this and fix it the right way I would really appreciate it
# (note that I
# have no clue what the right way is :)
It's understandable that you couldn't
Dan Sugalski sent the following bits through the ether:
> Actually, I'm expecting almost nothing to be written in pasm after we get a
> working parser and compiler
I am, as you may have noticed already, clearly a frustrated assembler
programmer who's had to code high-level stuff for far too lon
On Thu, Sep 13, 2001 at 01:10:46PM -0400, Gregor N. Purdy wrote:
> I've attached a new patch that adds the necessary bits to bytecode.[hc],
> assemble.pl build_interp_starter.pl, disassemble.pl, and
> interpreter.c.
Thanks, applied. (assemble.pl chunk applied manually.)
Simon
On Thu, Sep 13, 2001 at 06:38:56PM -0400, Dan Sugalski wrote:
>
> I was thinking more that we'd have a type OP for opcodes, for example.
> #typedef'd to int, or long, or int32_t, but conceptually standalone so we
> could change it if need be. (The possibility still exists that we might
> shrin
Yes-
People just need to agree to send all patches to RT first so that
they can be tagged in their subject line, so discussion gets
tracked. For now, RT needs to be CC'ed on followups - soon it
will just "listen".
When Simon/Dan/$PATCHER applies/rejects a patch, they can t
[EMAIL PROTECTED] sent the following bits through the ether:
> Here is the fibonaci function
Here are slightly cleaner (could even be used for testing purposes)
fibonacci and factorial example files. I'd say bundle them in as
examples and prod me until I do the test suite
Leon
--
Leon Broc
On Thu, Sep 13, 2001 at 04:45:36PM -0500, Gibbs Tanton - tgibbs wrote:
> I have a patch that puts parrot/ in front of all the header files and adds
> -I.. to the makefile. However, I will wait until some of the other patches
> get applied because my version is extremely hacked up and I don't want
On Fri, Sep 14, 2001 at 11:36:04AM -0500, Gibbs Tanton - tgibbs wrote:
> Ok, my previous patch to assemble.pl caused somethings to core dump...I
> promise this one won't :) It fixes the problem with numeric values having
> the wrong pack type. Also, config_h.in was changed to typedef ${iv} doubl
the cvs box will be down for a little while again. Hopefully I'll
get it moved to the other box over the weekend where I can give
access to the few new people Dan and Simon have asked me to make
accounts for.
And it'll be more stable. And faster. Harder Better Faster Stronger.
:-)
- ask
--
I'm pleased to announce that Brian Wheeler and Gregor Purdy,
after providing a good number of high-quality patches, have
now been given committer access to the Parrot CVS tree. They
join myself and Dan, the other committers at the moment.
If you're feeling left out, don't! We'll be giving other p
All --
It seems to me that the full complement of set_* ops should be something
like this (minus PMC stuff):
set_i_ic # We have this
set_i_i # We have this, and call it set_i
set_i_nc # NOT NEEDED: Assembler does it
set_i_n # We have this, a
At 09:36 AM 9/14/2001 +0100, Leon Brocard wrote:
>Dan Sugalski sent the following bits through the ether:
>
> > Actually, I'm expecting almost nothing to be written in pasm after we
> get a
> > working parser and compiler
>
>I am, as you may have noticed already, clearly a frustrated assembler
>p
Gibbs --
> The patch assumes that your source code directory is named parrot.
> This may
> have been an invalid assumption, but it is going to be hard to do this patch
> unless we agree on the name of the source directory.
Ah. I try not to assume the source directory name, since folks might
rena
On Fri, 2001-09-14 at 10:20, Dan Sugalski wrote:
> Okay, we've had a number of people in favor of a good macro assembler for
> Parrot. Given that, do we have anyone who'll volunteer to define, maintain,
> and extend the thing? (Presuming we jump off of the current assembler,
> which seems reaso
All --
I'd like to suggest that the Parrot image we've seen associated with
Perl6 be given the name "Jake", especially if it turns out to be a
picture of an African gray parrot (a jako).
Regards,
-- Gregor
_
/ perl -e 's
Lvalue casts are evil, I know. Patches welcome.
cc: Warning: bytecode.c, line 89: In this statement, the result of the cast "(char
...)*program_code" is used as an lvalue.
(char*)*program_code += buflen;
^
cc: Warning: bytecode.c, line 97: In this statement, the result of the cas
All --
> Since we are so early in the game, I'm not sure if it really matters whether
> we keep the version information or not. Does anyone have a problem with me
> deleting the header files and readding them under include/parrot/. or is the
> general concensus moving the RCS files?
Rather th
All --
> Since we are so early in the game, I'm not sure if it really matters whether
> we keep the version information or not. Does anyone have a problem with me
> deleting the header files and readding them under include/parrot/. or is the
> general concensus moving the RCS files?
Rather th
On Fri, Sep 14, 2001 at 02:35:33PM -0700, Benjamin Stuhl wrote:
> > Chunks we'd need are:
> >
> > Name: 'PINF' - Parrot Information
> > Name: 'PBYT' - Parrot Bytecode
> > Name: 'PSTR' - Parrot String Table
> > Name: 'PFIX' - Parrot Fixup Ta
Below is memory.c changed to support all (I think) of the coding standards.
Please look it over and let me know. Once the powers that be give the ok, I
will try to change all the source files to the standard.
Thanks!
Tanton
/* Memory.c
* Copyright: (When this is determined...it will go here)
Sorry...forgot the tabs...this one should be right.
memory.c
Attached a simple bytecode header reader/writes that writes out the
natively correct output, and can read in recognize the output of "any"
(for small enough values of any) other platform. Tried on x86 (32LE),
sparc (32BE), alpha (64LE), mips (32BE/64BE, compiler-switchable), and
unicosmk (64BE, r
As promised, here's the patch that gets Parrot building out
of the box on Win32. I had to comment out the mmap(), I'll
start working on doing that portably after class.
-- BKS
__
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency
First, good news! Parrot now builds - and works - on FreeBSD.
However, the output from the tests now looks really silly
given that we've got no newlines on printing integer and
float registers.
PLEASE can someone rewrite the tests to actually *test* things
and print "ok 1\n" and so on?
Quick, o
95 matches
Mail list logo
