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 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:
> "John" == John Siracusa <[EMAIL PROTECTED]> writes:
John> 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
John> Someone will correct me if I'm wrong, but I don't think Darwin
John> even i
> 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
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
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
>
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
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
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...)
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
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
===
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
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
> 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/
> >
>
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
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
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
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 ?
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
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,
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
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
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
---
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 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 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
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
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
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
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
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, 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 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?
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
> "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
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,
36 matches
Mail list logo
