Thanks! Applied.
-Original Message-
From: Tom Hughes
To: [EMAIL PROTECTED]
Sent: 10/8/2001 6:51 PM
Subject: RE: Transcoding patch
In message
<[EMAIL PROTECTED]>
Gibbs Tanton - tgibbs <[EMAIL PROTECTED]> wrote:
> This is good, unless someone has objections I'll commit this.
Ho
At 12:00 AM 10/9/2001 +0100, Simon Cozens wrote:
>On Mon, Oct 08, 2001 at 06:36:32PM -0400, Dan Sugalski wrote:
> > PACKAGE *package;
> > INTVAL base_type;
> > INTVAL int_type;
> > INTVAL float_type;
> > INTVAL num_type;
> > INTVAL string_type;
>
>Why are a
Ugh, that makes life annoying, it might be possible to hack the tinderbox
script to save to a file and then ftp up and down to get the file, etc, or
could we use the sourceforge Itanium box and ask them to allow outoging
email? Would we be able to get cvs through to sourceforge?
Zach
On 10/8/01
Zach Lipton:
# Can we get an itanium tinderbox to track this?
That may be a little difficult, as the Itanium in question is a
TestDrive box and thus can't open connections to the outside world. I
had to write extensive modifications to Parrot::Smoke and create an
active script on my computer jus
Can we get an itanium tinderbox to track this?
Zach
On 10/8/01 11:36 AM, "Brent Dax" <[EMAIL PROTECTED]> wrote:
> Moral of the story: long double breaks things for some reason. FYI,
> Itanium has 16-byte long doubles.
>
> Automated smoke report for patch Oct 8 07:00:01 2001 UTC
> v0.
This looks good.
Also, WRT the utf8_t, utf16_t, and utf32_t can we not just use utf32_t and
then mask off the lower 8 or 16 bits? We can still have utf8_t be defined
as char to allow sizeof to work right and we can do sizeof(utf8_t)*2 to get
the utf16_t's size.
-Original Message-
From:
In message <[EMAIL PROTECTED]>
Gibbs Tanton - tgibbs <[EMAIL PROTECTED]> wrote:
> This is good, unless someone has objections I'll commit this. However, we
> also need the ability to do unicode in the assembler (I'll do this later
> today if no one beats me to it), and we need some way
On Mon, Oct 08, 2001 at 06:36:32PM -0400, Dan Sugalski wrote:
> PACKAGE *package;
> INTVAL base_type;
> INTVAL int_type;
> INTVAL float_type;
> INTVAL num_type;
> INTVAL string_type;
Why are all these in the vtable? They seem like PMC-ish things
to me.
--
Okay, here's a quick rundown on PMCs and how we're handling opcodes called
on PMC registers. (This is mildly different than what's gone in the past, FWIW)
Every PMC has a set of static types, stored in the vtable. These types are
static, and stuck in the base vtable structure, which looks like:
Brent Dax wrote:
[...]
> The code could look like this:
>
> (pull in hints file)
> if(-e "Parrot/Config.pm") {
> eval "use Parrot::Config";
> %c=%pConfig;
> }
> (etcetera)
>
> except that "Parrot/Config.pm" isn't portable to VMS.
I
All --
> OK. Updated patch attached.
>
> Re: Portability, I suppose for now we could make a test for the
> presence of gettimeofday() and #define Parrot_gettimeofday() to
> it if it is there, else #define it to (FLOATVAL)time() to get
> the prior behavior. Smarter solutions could come later...
>
> Currently, instead of pushing the contents of fixed registers onto the
> stack, the registers themselves float on top of the stack. That doesn't
> preserve register contents on a push_x, as the registers are now in a new
> memory location. After toying with fixed registers per interpreter, I
I should have waited :)
-Original Message-
From: Dan Sugalski
To: Brent Dax; Gibbs Tanton - tgibbs; 'Perl 6 Internals '
Sent: 10/8/2001 2:11 PM
Subject: RE: Itanium still a little ill
At 12:11 PM 10/8/2001 -0700, Brent Dax wrote:
>Gibbs Tanton - tgibbs:
># Yeah, long double is going to
I think we can support it; whether we will or not is up to Dan and Simon.
Either way, it is not ready yet.
-Original Message-
From: Brent Dax
To: Gibbs Tanton - tgibbs; 'Perl 6 Internals '
Sent: 10/8/2001 2:11 PM
Subject: RE: Itanium still a little ill
Gibbs Tanton - tgibbs:
# Yeah, lon
At 12:11 PM 10/8/2001 -0700, Brent Dax wrote:
>Gibbs Tanton - tgibbs:
># Yeah, long double is going to break things because we are
># packing it into a
># double and then memcpying it out like it is a long double. The
># inconsistency is the problem.
>
>Does that mean we're not gonna support long
Yeah, long double is going to break things because we are packing it into a
double and then memcpying it out like it is a long double. The
inconsistency is the problem.
-Original Message-
From: Brent Dax
To: Perl 6 Internals
Sent: 10/8/2001 1:36 PM
Subject: Itanium still a little ill
M
Gibbs Tanton - tgibbs:
# Yeah, long double is going to break things because we are
# packing it into a
# double and then memcpying it out like it is a long double. The
# inconsistency is the problem.
Does that mean we're not gonna support long double, or just that it
isn't ready yet?
--Brent Da
Moral of the story: long double breaks things for some reason. FYI,
Itanium has 16-byte long doubles.
Automated smoke report for patch Oct 8 07:00:01 2001 UTC
v0.01 on linux using cc version 2.96-ia64-000717 snap
001117
O = OK
F = Failure(s), extended report at the bottom
? =
Brent Dax:
# Patch below my sig does three things:
# *makes sure that *all* the VMS-specific stuff is in the VMS
# hints file
# *makes test.c return a chunk of eval-able code
# *makes test.c return several more sizeof() results (for types like
# int, double...)
#
# I especially need the VMS
[EMAIL PROTECTED] (B Vlad) writes:
> ps. have to figure how to get the WinCVS thing work...
> can't seem to be able to access cvs.perl.org. I've used
> the following set up:
>
> CVSROOT = :pserver:[EMAIL PROTECTED]:/home/perlcvs
> Authentication = passwd file on the remote host.
>
> any suggest
Supercedes the previous one.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.33
diff -u -r1.33 basic_opcodes.ops
--- basic_opcodes.ops 20
On Monday 08 October 2001 11:43 am, Alex Gough wrote:
> On Mon, 8 Oct 2001, Bryan C. Warnock wrote:
> > Currently, instead of pushing the contents of fixed registers onto the
> > stack, the registers themselves float on top of the stack. That doesn't
> > preserve register contents on a push_x, as
INTVAL (>= 32 bits, signed)
We need an unsigned version: U_INTVAL, UINTVAL, UNTVAL? (NUTVAL? ;-)
Do we want some exactly sized integers? s/VAL/32/ perhaps?
(Although I probably shouldn't be, I've always been a little leery of
putting flags in a variably-width container.)
--
Bryan C. Warnock
On Mon, 8 Oct 2001, Bryan C. Warnock wrote:
> Currently, instead of pushing the contents of fixed registers onto the
> stack, the registers themselves float on top of the stack. That doesn't
> preserve register contents on a push_x, as the registers are now in a new
> memory location. After t
At 11:02 AM 10/8/2001 -0400, Bryan C. Warnock wrote:
>Currently, instead of pushing the contents of fixed registers onto the
>stack, the registers themselves float on top of the stack. That doesn't
>preserve register contents on a push_x, as the registers are now in a new
>memory location. After
Currently, instead of pushing the contents of fixed registers onto the
stack, the registers themselves float on top of the stack. That doesn't
preserve register contents on a push_x, as the registers are now in a new
memory location. After toying with fixed registers per interpreter, I
decid
All --
The mod_i, cmod_i, mod_n and cmod_n ops have comments with references.
This are begging to be POD. Suppose we converted them to POD and added
POD comments to the other ops so that we could generate op documentation
from the basic_opcodes.ops file?
Suppose also that we generated opcode_tab
All --
> Besides the Calendrical Calculations reference I originally sited,
Ummm s/sited/cited/
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL
Dan --
> >Fortunately, there is a perfectly rational definition of the mod(x,y)
> >function over the full domains of x and y, and even for x and y that
> >are not integral. This can be found in the book Concrete Mathematics,
> >Second Edition by Graham, Knuth and Patashnik (Section 3.4, pages
> >
All --
> As I understand it, computer languages differ in their implementation
> of the mod() function. I've heard some architectures differ, too, so
> that the same language (such as C or Perl) might behave differently on
> different machines (I'd be interested to know if this is really true).
In message <[EMAIL PROTECTED]>
Gibbs Tanton <[EMAIL PROTECTED]> wrote:
> > - The utf8_t, utf16_t and utf32_t types will need to be determined
> >by configure as they will currently break on some machines. Plus
> >machines without native 8, 16 and 32 bit types will be a problem.
>
> Absolutely. A few other issues that I remembered last night are:
>
> - The current code assumes that the string data will be two
>byte aligned for UTF-16 and four byte aligned for UTF-32 which
>is probably reasonable but maybe not.
Yeah, I think we can handle that in the constant secti
In message <[EMAIL PROTECTED]>
Gibbs Tanton <[EMAIL PROTECTED]> wrote:
> I've applied this patch.
I just did an update and noticed the new files had appeared about
two seconds before your mail arrived ;-)
> I realize that we have a ways to go before we can fully support unicode, but
> I
I've applied this patch.
I realize that we have a ways to go before we can fully support unicode, but
I felt that this patch was a big step in the right direction; with it
committed we can now start incrementally cleaning it up and making it work
correctly. Since it doesn't affect anything we ar
On Behalf Of Alex Gough:
# I've modified Configure.pl to take defaults from a previous build (if
# there was one). This should play nicely with hints, and '--defaults'
# by doing the Right Thing. I've added a '--nopolicy' option to disable
# this.
FYI, this is sitting around the top of my stack
35 matches
Mail list logo
