On Wed, Sep 19, 2001 at 02:49:58PM +0100, Leon Brocard wrote:
> Attached is a cute prime number printer.
>
> It strikes me that we need a central place to put these things - it'd
> really help people get stuck into the lowlevel stuff.
It wouldn't hurt to throw it in as a test. Probably the most
First, code->i doesn't exist anymore...it is back to being *code (much more
readable that way :)
Second, we are going to remove those safety checks on that version of runops
if I'm not mistaken, I just don't think anyone's gotten around to it yet.
-Original Message-
From: Simon Cozens
On Wed, Sep 19, 2001 at 10:47:44PM -0700, Dave Storrs wrote:
> Well, I'm in the process of fiddling with this stuff anyway...what do you
> want me to make it do?
Oh, sorry, I see what happens. The last test (code->i) is what I would think
of as *code: it tests whether we're sitting on an end op,
Well, I'm in the process of fiddling with this stuff anyway...what do you
want me to make it do?
Dave
On Thu, 20 Sep 2001, Simon Cozens wrote:
> On Wed, Sep 19, 2001 at 10:32:18PM -0700, Dave Storrs wrote:
> > Ok, that was pretty much what I thought. But then what is the 'end'
> > opcode for?
On Wed, Sep 19, 2001 at 10:32:18PM -0700, Dave Storrs wrote:
> Ok, that was pretty much what I thought. But then what is the 'end'
> opcode for? It does a 'RETURN 0', which would increment the PC by 0
> opcodes...which either counts as an infinite loop or a no-op, and we've
> already got a no-op
On Wed, Sep 19, 2001 at 11:29:08PM -0500, Brian Wheeler wrote:
> The only incompatibility I've introduced is now assemble.pl won't read
> from stdin...you have to give it a filename. Patches welcome!
And, of course, these beautiful new features don't appear in the
assembler documentation. This
end never actually gets called. It can do whatever it wants. When the
interpreter sees an opcode with a value of 0 (which end is currently the
only one with that opcode), it will immediately stop execution (without
executing the end function).
-Original Message-
From: Dave Storrs
To: G
Ok, that was pretty much what I thought. But then what is the 'end'
opcode for? It does a 'RETURN 0', which would increment the PC by 0
opcodes...which either counts as an infinite loop or a no-op, and we've
already got a no-op op.
Dave
On Thu, 20 Sep 2001, Gibbs Tanton - tgibbs wrote:
> RE
RETURN causes the program counter to be incremented by that many opcodes.
So RETURN 4 would move forward 4 opcodes and RETURN -2 would move backward 2
opcodes. Basically, it returns a relative offset from the current position.
-Original Message-
From: Dave Storrs
To: The Perl 6 Internals
I'm working on documenting the opcodes, and I want to make sure that I
understand the 'RETURN' code properly. I've poked around a little bit to
see if I coudl figure it out, but I don't want to divert too much. Would
someone please explain to me what each of the following does?
RETURN 4
RETURN
Please test this out to make sure I haven't done anything stupid!
The syntax for including another file is:
include 'filename'
or
include "filename"
The file will be included as-is at that spot. The listing will reflect
that a series of lines was included by printing
# Star
please see attached process_switch.pl
notes inside.
Very rough draft, but I think it does write a correct
define ( but I might be clueless ).
On the note of the enum for the case foo:
Made it work, Gibbs has seen patch, but we wanted to
defer to Dan/Simon because op.h has the knack of
redefini
On Wed, 19 Sep 2001, Dan Sugalski wrote:
> Basically we're getting a free load on most architectures, so we ought to
> use it where we can. (And it doesn't hurt us on those architectures where
> we don't have it)
1) Does that make us freeloaders?
2) I guess the architecture designers are
At 09:16 PM 9/19/2001 -0400, Gregor N. Purdy wrote:
> > > -print INTERP "\tx[$opcodes{$name}{CODE}] = (void*)$name; \\\n";
> > > -}
> > > -print INTERP "} while (0);\n";
> > > +printf INTERP "{ (void *)%-12s, %-14s, %d, { ",
> > > + $name, "\"$name\"", $opcodes{$name}{ARGS};
> >
>
At 09:23 PM 9/19/2001 -0400, Gregor N. Purdy wrote:
> > >Dan? Does this fly in the face of your overall design, or is this
> > >a good thing?
> >
> > Cool, but not a good thing. The problem with it is there's a lot of
> > extraneous stuff scattered in the function table structure. That's
> going
> >Dan? Does this fly in the face of your overall design, or is this
> >a good thing?
>
> Cool, but not a good thing. The problem with it is there's a lot of
> extraneous stuff scattered in the function table structure. That's going to
> reduce the L1 cache hit rate, and I'd rather not do that
> > -print INTERP "\tx[$opcodes{$name}{CODE}] = (void*)$name; \\\n";
> > -}
> > -print INTERP "} while (0);\n";
> > +printf INTERP "{ (void *)%-12s, %-14s, %d, { ",
> > + $name, "\"$name\"", $opcodes{$name}{ARGS};
>
> This is so much more confusing. :(
It may be a little less cle
I only had one real problem with Parrot on Darwin, which really has
nothing to do with Darwin at all. The first time I tried to "make test"
I got a slew of errors about Test::More, so I diligently went to CPAN
and downloaded the latest version. It claimed dependency on Test::Simple,
which claimed
I've updated number.t and integer.t to use the new comparison operators. I
also made a minor patch to opcode_table because the if ops had the wrong
number of args. Finally, I made a change to assemble.pl to grok operators
better. It should now handle an operator no matter how you name it as lon
On Wed, 19 Sep 2001, Mattia Barbon wrote:
> > > Any chance on rsync? If so, I might set up another smoke suite to bother you
> > > with reports :)
> >
> > rsync -av cvs.perl.org::parrot-HEAD parrot
> For smoking it'll be nice to hace some file with a timestamp of the
> checkout, i.e. in the scri
At 06:23 PM 9/19/2001 -0400, Gregor N. Purdy wrote:
>All --
>
>I wanted to have a unified op func, name, argc and argtype[] member
>in the interpreter struct, and that led me to make all the changes
>in this patch.
>
>I don't know if I've gone too far, but DO_OP is simpler now, and
>things still s
On Wed, Sep 19, 2001 at 06:23:41PM -0400, Gregor N. Purdy wrote:
> -print INTERP "\tx[$opcodes{$name}{CODE}] = (void*)$name; \\\n";
> -}
> -print INTERP "} while (0);\n";
> +printf INTERP "{ (void *)%-12s, %-14s, %d, { ",
> + $name, "\"$name\"", $opcodes{$name}{ARGS};
This is so m
All --
I wanted to have a unified op func, name, argc and argtype[] member
in the interpreter struct, and that led me to make all the changes
in this patch.
I don't know if I've gone too far, but DO_OP is simpler now, and
things still seem to run for me.
Anyone else interested in trying this ou
At 05:28 PM 9/19/2001 -0400, Dan Sugalski wrote:
>The assembler's failing with 0a->0D0A conversions in spots. Could someone
>familiar with it go binmode all the output files that we spit bytecode to?
Never mind, I took care of it.
Dan
---
The assembler's failing with 0a->0D0A conversions in spots. Could someone
familiar with it go binmode all the output files that we spit bytecode to?
Dan
--"it's like this"---
Dan Sugalski
here it is.
I'll release Parrot::Smoke 0.01 tomorrow,
promise.
*PLEASE* - change _read to read in test_main.c
- correct integer.t, test 1
not to test 0x == -1
( that's why we have got all F... )
Regards
Mattia
Automated smoke report for patch ?
Andy Dougherty:
...
# +prompt("And what is sizeof(iv)?", 'ivsize');
# prompt("And your floats?", 'nv');
# +prompt("And what is sizeof(nv)?", 'nvsize');
...
Somehow, this seems like something we ought to be able to do
programmatically. Can't we just compile a quick little C program with
somethin
Andy Dougherty:
# On Wed, 19 Sep 2001, Brent Dax wrote:
#
# > Andy Dougherty:
# > ...
# > # +prompt("And what is sizeof(iv)?", 'ivsize');
# > # prompt("And your floats?", 'nv');
# > # +prompt("And what is sizeof(nv)?", 'nvsize');
# > ...
# >
# > Somehow, this seems like something we ought to be a
> On Tue, 18 Sep 2001, H.Merijn Brand wrote:
>
> > On Mon 17 Sep 2001 23:08, Ask Bjoern Hansen <[EMAIL PROTECTED]> wrote:
> > >
> > > oops, I forgot to tell anyone. I made CVS export and tar up a
> > > snapshot every 6 hours. It is available at
> > > http://cvs.perl.org/snapshots/parrot/
> >
>
On Wed, 19 Sep 2001, Brent Dax wrote:
> Andy Dougherty:
> ...
> # +prompt("And what is sizeof(iv)?", 'ivsize');
> # prompt("And your floats?", 'nv');
> # +prompt("And what is sizeof(nv)?", 'nvsize');
> ...
>
> Somehow, this seems like something we ought to be able to do
> programmatically. Can
Thanks. Applied.
-Original Message-
From: Josh Wilmes
To: [EMAIL PROTECTED]
Sent: 9/19/2001 3:04 PM
Subject: [PATCH] mem_allocate_aligned explanation
This patch adds Dan Sugalski's explanation to the code.
Index: memory.c
===
This has been applied. Please rerun Configure.pl after updating.
Thanks!
Tanton
-Original Message-
From: Gibbs Tanton - tgibbs
To: '[EMAIL PROTECTED] '
Sent: 9/19/2001 1:15 PM
Subject: [REPATCH] changing IV to opcode_t
Ok, this patch changes from the union to a simple type. The type
This patch adds Dan Sugalski's explanation to the code.
Index: memory.c
===
RCS file: /home/perlcvs/parrot/memory.c,v
retrieving revision 1.9
diff -u -r1.9 memory.c
--- memory.c2001/09/16 01:45:51 1.9
+++ memory.c2001/09
To make Parrot pass (almost) all of the tests, also change the n => 2 line
in process_opfunc.pl to a 1. On my Tru64 box, it passed all tests but the
overflow ones.
-Original Message-
From: Gibbs Tanton - tgibbs
To: '[EMAIL PROTECTED]'
Sent: 9/19/2001 2:05 PM
Subject: 64 bit Assembler
I
Nope, I think you've messed up your math there :)
The current version multiplies the number of numeric types seen by two
(because (unportably) most numbers are twice the size of integers). Yours
does not take that into account.
-Original Message-
From: Pat Eyler
To: [EMAIL PROTECTED]
S
I found one more bit that looks odd to me (again in _load), near the end
of the while loop is this code:
my $num_i = () = grep {/i/} @params;
my $num_n = () = grep {/n/} @params;
$opcode{$name}{RETURN_OFFSET} = 1 + $num_i + $num_n * 2;
which could be reduced to:
At 02:51 PM 9/19/2001 -0400, Andy Dougherty wrote:
>On Wed, 19 Sep 2001, Dan Sugalski wrote:
>
> > At 01:37 PM 9/19/2001 -0400, Andy Dougherty wrote:
>
> > >Of course it doesn't help that perl doesn't have a pack() flag for IV :-).
> >
> > Definitely a pain. :) We need to figure out the size and u
I have updated the Assembler to work better with 64 bit platforms. Now, to
run under a 64 bit platform, just change the 'l' to a 'q' in the pack_type
hash. I think Andy's patch will come closer to automatically choosing the
right type, but that's not my area :)
On Wed, 19 Sep 2001, Dan Sugalski wrote:
> At 01:37 PM 9/19/2001 -0400, Andy Dougherty wrote:
> >Of course it doesn't help that perl doesn't have a pack() flag for IV :-).
>
> Definitely a pain. :) We need to figure out the size and use the
> appropriate thingie. That should be a mild amount o
parrot hackers,
I'm not going to pretend to be a wizened hacker, but I've got a couple
of questions about Parrot::Opcode that I hope you could answer.
1) _load looks like:
sub _load {
#
#
#
my $count = 1;
while (<$fh>) {
#
#
#
if (@params && $pa
Ok, this patch changes from the union to a simple type. The type is queried
for at configure time. Brent, if you'll ok the configure stuff I'll go
ahead and apply it.
Thanks!
Tanton
patch.dat
Thanks. Applied.
-Original Message-
From: Andy Dougherty
To: [EMAIL PROTECTED]
Sent: 9/19/2001 12:22 PM
Subject: [PATCH] Remove C++ style comment
I'm not sure why this is commented out in the first place, but if we
want to keep it, we need to use C-style comments.
diff -r -u parrot/co
On Wed 19 Sep 2001 18:53, Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 19, 2001 at 06:37:22PM +0200, H. Merijn Brand wrote:
> > HP-UX 11.00, HPc B.11.11.23709.GP, perl-5.7.2@12053
> > DEBUGGING USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES
>
> Wow, that one sucked. Betcha it's a prob
> One of the things that might be coring solaris is the potential for
> embedded floats in the bytecode stream. (The more I think about that the
> more I regret it...) The ops do a quick and ugly cast to treat some of the
> opcode stream as an NV which may trip across alignment rules and size
> Nope. There's *always* an integer type that works right. We won't be
> running on a platform that doesn't have 32-bit integers. (Well, not
without
> someone hacking the heck out of the core)
We should not rule out 16-bit system completely. It should be possible an
16-bit runtime can easily c
At 01:37 PM 9/19/2001 -0400, Andy Dougherty wrote:
>On Wed, 19 Sep 2001, Dan Sugalski wrote:
>
> > At 05:27 PM 9/19/2001 +0100, Simon Cozens wrote:
>
> > >I think it's more urgent that we think about having the bytecode
> written in
> > >native IVs rather than 32 bits; that'll help Tru64 and all
On Wed, 19 Sep 2001, Dan Sugalski wrote:
> At 05:27 PM 9/19/2001 +0100, Simon Cozens wrote:
> >I think it's more urgent that we think about having the bytecode written in
> >native IVs rather than 32 bits; that'll help Tru64 and all the other things
> >with alignment problems.
> Sure. That's a
I'm not sure why this is commented out in the first place, but if we
want to keep it, we need to use C-style comments.
diff -r -u parrot/config_h.in parrot-andy/config_h.in
--- parrot/config_h.in Wed Sep 19 11:57:11 2001
+++ parrot-andy/config_h.in Wed Sep 19 12:08:27 2001
@@ -18,7 +18,7 @@
On Wed, 19 Sep 2001, Simon Cozens wrote:
> On Wed, Sep 19, 2001 at 06:37:22PM +0200, H. Merijn Brand wrote:
> > HP-UX 11.00, HPc B.11.11.23709.GP, perl-5.7.2@12053
> > DEBUGGING USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES
>
> Wow, that one sucked. Betcha it's a problem with pack() and
> I
On Wed, Sep 19, 2001 at 06:37:22PM +0200, H. Merijn Brand wrote:
> HP-UX 11.00, HPc B.11.11.23709.GP, perl-5.7.2@12053
> DEBUGGING USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES
Wow, that one sucked. Betcha it's a problem with pack() and
IV size.
--
If God had a beard, he'd be a UNIX pro
HP-UX 11.00, HPc B.11.11.23709.GP, perl-5.7.2@12053
DEBUGGING USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES
--
H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 & 629 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.1
I'm about to hack things up so that all the conditional branch opcodes have
only one destination, the one they take if the condition's matched.
(Otherwise they fall through) This should speed things up a bit, as we'll
have less memory that we need to chew through when running, and density's
ge
At 05:27 PM 9/19/2001 +0100, Simon Cozens wrote:
>On Wed, Sep 19, 2001 at 12:25:32PM -0400, Dan Sugalski wrote:
> > Cool. If I get a chance (or someone else does) I'll see about hacking the
> > byteloader to translate to native format if handed a non-native but still
> > known set of bytecode.
>
>
On Wed 19 Sep 2001 16:43, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:15 AM 9/19/2001 +0200, H.Merijn Brand wrote:
> >If the nightly builds start OK, I could add a daily report for
> >
> > HP-UX 11.00 HPc/gcc 32/64 threading/non-threading
> > HP-UX 10.20 HPc 32threading
On Wed, Sep 19, 2001 at 12:25:32PM -0400, Dan Sugalski wrote:
> Cool. If I get a chance (or someone else does) I'll see about hacking the
> byteloader to translate to native format if handed a non-native but still
> known set of bytecode.
I think it's more urgent that we think about having the
At 11:19 AM 9/19/2001 -0500, Gibbs Tanton - tgibbs wrote:
>Ok, after class I will fix and repatch. Making opcode_t a simple type that
>is configurable.
Cool. If I get a chance (or someone else does) I'll see about hacking the
byteloader to translate to native format if handed a non-native but st
Ok, after class I will fix and repatch. Making opcode_t a simple type that
is configurable.
Thanks!
Tanton
-Original Message-
From: Dan Sugalski
To: Simon Cozens; ''[EMAIL PROTECTED]' '
Sent: 9/19/2001 10:14 AM
Subject: Re: [PATCH] changing IV to opcode_t!!
At 03:58 PM 9/19/2001 +0100,
At 12:08 PM 9/19/2001 -0400, John Siracusa wrote:
>On 9/19/01 11:51 AM, Randal L. Schwartz wrote:
> > John> (HFS and HFS+ are indeed case-insensitive though)
> >
> > Which they *could* have fixed from the Unix side in the same way that
> > MachTen did it..., and I wish they would. In MachTen, eac
At 04:49 PM 9/19/2001 +0100, Robin Houston wrote:
>Dan Sugalski wrote:
> > I'd love to have Darwin there, [...]
> >
> > If someone is willing to pitch in the time and effort, I'd be thrilled
> > to add it to the list.
>
>I'm willing.
Keen. I don't suppose you can do Classic Mac too, perchance?
On 9/19/01 11:51 AM, Randal L. Schwartz wrote:
> John> (HFS and HFS+ are indeed case-insensitive though)
>
> Which they *could* have fixed from the Unix side in the same way that
> MachTen did it..., and I wish they would. In MachTen, each
> case-folded collision on the HFS+ side is handled by a
Dan Sugalski wrote:
> I'd love to have Darwin there, [...]
>
> If someone is willing to pitch in the time and effort, I'd be thrilled
> to add it to the list.
I'm willing.
.robin.
--
"Sometimes I sit in front of my washing machine and contemplate the
worthlessness of life. My washing machin
> "John" == John Siracusa <[EMAIL PROTECTED]> writes:
John> HFS+ supports 255 character file names. Yes, the (classic Mac OS) Finder is
John> hiding something from you, as are the rest of the classic Mac OS file access
John> APIs, which are limited to 32 characters and weren't updated when H
On Wed, 19 Sep 2001, Dan Sugalski wrote:
> One of the things that might be coring solaris is the potential for
> embedded floats in the bytecode stream. (The more I think about that the
> more I regret it...) The ops do a quick and ugly cast to treat some of the
> opcode stream as an NV which
At 03:58 PM 9/19/2001 +0100, Simon Cozens wrote:
>On Wed, Sep 19, 2001 at 10:59:45AM -0400, Dan Sugalski wrote:
> > Nope. opcode_t should be the native opcode type for the platform we're
> > compiling on. No need for fancy unions--configure should find out the
> > integer type that works out right
One of the things that might be coring solaris is the potential for
embedded floats in the bytecode stream. (The more I think about that the
more I regret it...) The ops do a quick and ugly cast to treat some of the
opcode stream as an NV which may trip across alignment rules and size
issues.
At 06:44 PM 9/18/2001 -0700, Hong Zhang wrote:
> > Proposed: Parrot should never crash due to malformed bytecode. When
> > choosing between execution speed and bytecode safety, safety should
> > always win. Careful op design and possibly a validation pass before
> > execution will hopefully keep
At 03:56 PM 9/18/2001 -0700, Damien Neil wrote:
>On Wed, Sep 19, 2001 at 12:51:43AM +0200, Mattia Barbon wrote:
> > I think that especting 4294967295 == -1 because they have the same
> > bit pattern ( on two's complement 32 bit machines ) is wrong
>
>I was wondering how long it would take for some
On Wed, Sep 19, 2001 at 10:59:45AM -0400, Dan Sugalski wrote:
> Nope. opcode_t should be the native opcode type for the platform we're
> compiling on. No need for fancy unions--configure should find out the
> integer type that works out right for the platform and the bytecode and use
> that.
I
At 09:41 PM 9/18/2001 -0500, Gibbs Tanton - tgibbs wrote:
>Ok...let me try to get this straight and I'll repatch...
>
>opcode_t should be something that will represent the native opcode type. In
>most cases it should just be long; however, there might be special systems
>where it is somehting dif
On Wed, Sep 19, 2001 at 08:44:34AM -0600, Nathan Torkington wrote:
> > Don't use parrot-nightly; use the snapshots from cvs.perl.org
>
> So parrot-nightly will only be useful when we have many more features
> implemented, and there's a high probability that most features in a
> snapshot will actu
On Wed, Sep 19, 2001 at 02:49:58PM +0100, Leon Brocard wrote:
> How about an examples/ directory in the CVS tree?
I'd rather we didn't do this; I don't want to clutter up Parrot
with auxilliary stuff.
> Alternatively, I
> could set up a "learning parrot assembler" website of some sort,
This wou
Simon Cozens writes:
> On Wed, Sep 19, 2001 at 01:22:04PM +0200, H. Merijn Brand wrote:
> > Can't open perl script "t/harness": No such file or directory
> > MANIFEST? (using most recent parrot-nightly)
>
> Don't use parrot-nightly; use the snapshots from cvs.perl.org
So parrot-nightly will only
On 9/19/01 10:35 AM, Randal L. Schwartz wrote:
> John> Someone will correct me if I'm wrong, but I don't think Darwin
> John> even installs on file systems that support anything less than
> John> 255 character file names (e.g. HFS).
>
> My HFS+ drive held Darwin for at least a little while, and t
At 01:10 PM 9/19/2001 +0200, H.Merijn Brand wrote:
>(cast)foo = bar; syntax is *not* supported in most non-GNU C compilers:
My sloppiness, I'll fix anything remaining. (It wasn't done out of any
gcc-centrism--I don't even use gcc much. Just never occurred to me that it
wouldn't work...)
At 11:15 AM 9/19/2001 +0200, H.Merijn Brand wrote:
>If the nightly builds start OK, I could add a daily report for
>
> HP-UX 11.00 HPc/gcc 32/64 threading/non-threading
> HP-UX 10.20 HPc 32threading/non-threading
> AIX 4.3.3 vac/gcc 32/64 threading/non-threading
>
On Wed, Sep 19, 2001 at 08:57:53AM -0500, Gibbs Tanton - tgibbs wrote:
> Both of these things were fixed when I converted from IV to opcode_t. (not
> that I didn't break other things...)
> Since that change was made, how many of the core platforms pass?
Tru64 builds beautifully, but also segfault
Both of these things were fixed when I converted from IV to opcode_t. (not
that I didn't break other things...)
Since that change was made, how many of the core platforms pass? If we lose
one, I need to revert.
Thanks!
Tanton
-Original Message-
From: H.Merijn Brand
To: Simon Cozens
Cc:
On 9/18/01 7:26 PM, Randal L. Schwartz wrote:
> I'd suggest you "Darwin" there to be sure you're thinking about
> case-insensitive-32-char filenames
Someone will correct me if I'm wrong, but I don't think Darwin even installs
on file systems that support anything less than 255 character file name
Attached is a cute prime number printer.
It strikes me that we need a central place to put these things - it'd
really help people get stuck into the lowlevel stuff.
How about an examples/ directory in the CVS tree? Alternatively, I
could set up a "learning parrot assembler" website of some sort,
> And, maybe even more important, not all the world has gcc!
Hear, hear.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
On Wed, Sep 19, 2001 at 01:22:04PM +0200, H. Merijn Brand wrote:
> Can't open perl script "t/harness": No such file or directory
> MANIFEST? (using most recent parrot-nightly)
Don't use parrot-nightly; use the snapshots from cvs.perl.org
--
"I don't think so," said Rene Descartes. Just then, h
On Wed 19 Sep 2001 13:10, "H.Merijn Brand" <[EMAIL PROTECTED]> wrote:
> And, maybe even more important, not all the world has gcc!
and bytecode.c
l1:/pro/3gl/CPAN/parrot 136 > make test_prog
cc -DDEBUGGING -Ae -D_HPUX_SOURCE -I/pro/local/include -D_LARGEFILE_SOURCE -D_FI
LE_OFFSET_BITS=64 -I..
On Wed 19 Sep 2001 11:15, "H.Merijn Brand" <[EMAIL PROTECTED]> wrote:
> On Tue 18 Sep 2001 20:43, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > Okay, folks, the following platforms are considered core for the parrot
> > interpreter. That means we need to run on all of them for any release of
> > t
On Tue 18 Sep 2001 20:43, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, folks, the following platforms are considered core for the parrot
> interpreter. That means we need to run on all of them for any release of
> the interpreter to be considerd OK. They are:
>
> Linux (x86)
> CygWin
84 matches
Mail list logo
