Gibbs --
> I tested the patch on CygWin, Solaris SunOS 5.8, and Tru64. It passed on
> all three systems.
Thanks!
Here's the platform status of this work:
CORE PASSED:
* Linux (x86)
* CygWin
* True64
* Solaris (Sparc)
CORE NOT TESTED:
* Win32
* OpenVMS (Alpha)
* FreeBSD (x86)
On Sunday 30 September 2001 11:14 am, Gregor N. Purdy wrote:
> The stuff I'm about to check in that allows NVs to move to the constant
> table is set up to also allow IVs to live there, too. I haven't made
> the assembler and the ops do that yet, but it is possible. I thought we
> were going to ha
Simon --
> Sorry. It's still throwing tests on Sparc. Tracking it down now.
Gibbs had a Solaris success (I assumed Sparc). If you've got a
different setup, I'd suggest looking at packfile.c in function
PackFile_Constant_unpack_number(). Maybe we need to use memcopy
instead of an assign (see the
This fix is independent of the rest of size issues.
Index: interpreter.c
===
RCS file: /home/perlcvs/parrot/interpreter.c,v
retrieving revision 1.20
diff -c -r1.20 interpreter.c
*** interpreter.c 2001/09/26 18:13:50 1.20
Bryan --
> > The stuff I'm about to check in that allows NVs to move to the constant
> > table is set up to also allow IVs to live there, too. I haven't made
> > the assembler and the ops do that yet, but it is possible. I thought we
> > were going to have sizeof(IV) == sizeof(OP), and handle lar
I've been testing situations where sizeof(opcode_t) != sizeof(IV) !=
sizeof(IV).
I got most of the casting and arithmetic problems patched [1], but am running
into alignment problems with the bytecode because it currently expects
sizeof(opcode_t) == sizeof(IV). (Or something, I can't tell qui
I tested the patch on CygWin, Solaris SunOS 5.8, and Tru64. It passed on
all three systems.
Tanton
Bryan --
> I got most of the casting and arithmetic problems patched [1], but am running
> into alignment problems with the bytecode because it currently expects
> sizeof(opcode_t) == sizeof(IV). (Or something, I can't tell quite yet
> whether the problems in the assembler or the _unpack funct
Sorry. It's still throwing tests on Sparc. Tracking it down now.
--
So what if I have a fertile brain? Fertilizer happens.
-- Larry Wall in <[EMAIL PROTECTED]>
> Dan Sugalski wrote:
>
> > >How does python handle MT?
> >
> > Honestly? Really, really badly, at least from a performance point of view.
> > There's a single global lock and anything that might affect shared state
> > anywhere grabs it.
>
> i.e. not so much 'threaded' as 'stitched up'.
Well, py
> >How does python handle MT?
>
> Honestly? Really, really badly, at least from a performance point of view.
> There's a single global lock and anything that might affect shared state
> anywhere grabs it.
Python uses global lock for multi-threading. It is reasonable for io thread,
which blocks mo
Tru64 cc is worried:
cc: Warning: packfile.c, line 1226: The scalar variable "encoding" is fetched but not
initialized. (uninit1)
new_string = string_make(data, size, encoding, flags, type);
-^
cc: Warning: packfile.c, line 1226: The scalar variable "t
I would assume that you would want to embed IV constants if at all possible
because of a locality of reference cache bonus. Even if the opcode_t is 32
bit and IV is 64 bit, it should still be possible to embed the constants
into the stream. As for having smaller opcode_t values, I think the argum
--- Alan Burlison <[EMAIL PROTECTED]> wrote:
> Benjamin Stuhl wrote:
>
> > Let me be more specific: if you're holding a mutex over
> a
> > call back into parrot, it's your own fault. Parrot
> itself
> > knows which functions may croak() and which won't, so
> it
> > can use utility funtions that r
I mentioned this idea before, and I've managed to implement a bit of it.
This is a compiler implementing a (very small) subset of Perl 6; it puts
the assembler code on STDOUT. Control flow and loops aren't implemented
yet. It uses Parse::RecDescent for parsing, and has a lot of 5.6-isms
in it.
> This was failing here until I made the following change:
>
> PackFile_Constant_unpack_number(struct PackFile_Constant *
> self, char * packed, IV packed_size) {
> char * cursor;
> NV value;
> NV * aligned = mem_sys_allocate(sizeof(IV));
Are you sure this is correct? Or this
On Sun, Sep 30, 2001 at 01:37:44PM -0700, Hong Zhang wrote:
> The memcpy() can handle alignment nicely.
Not always. I tried. :(
--
"How should I know if it works? That's what beta testers are for. I only
coded it."
(Attributed to Linus Torvalds, somewhere in a posting)
> > The memcpy() can handle alignment nicely.
>
> Not always. I tried. :(
How that could be possible? The memcpy() just does byte-by-byte
copy. It does not care anything about the alignment of source
or dest. How can it fail?
Hong
A couple hours ago (3:34PM PDT), someone commited a new version of the
MANIFEST file to the Parrot CVS. This file contains a file name that is
missing, Parrot/String.pm, on line 11. Running "perl Configure.pl"
fails as a result saying that it's missing that file. Simply deleting
line 11 does n
On Sun, Sep 30, 2001 at 11:31:21AM -0400, Gregor N. Purdy wrote:
> Gibbs had a Solaris success (I assumed Sparc). If you've got a
> different setup, I'd suggest looking at packfile.c in function
> PackFile_Constant_unpack_number(). Maybe we need to use memcopy
> instead of an assign (see the TODO
On Sun, 30 Sep 2001, Nick Ing-Simmons wrote:
> The main problem with perl5 and threads is that threads are an afterthought.
Which, of course, also goes for "UNIX and threads" and "C and threads".
It's good for us to be thinking about as early as possible but it's no
garauntee that there won't be
On Sun, Sep 30, 2001 at 11:25:04AM -0400, Gregor N. Purdy wrote:
> * Solaris (Sparc)
This was failing here until I made the following change:
PackFile_Constant_unpack_number(struct PackFile_Constant * self, char * packed, IV
packed_size) {
char * cursor;
NV value;
NV * align
On Sun, Sep 30, 2001 at 12:57:53PM -0700, Brent Dax wrote:
> I mentioned this idea before, and I've managed to implement a bit of it.
VERY GOOD WORK!
> That isn't quite valid Parrot bytecode, because of the concat. Concat
> is currently documented to take only two arguments.
This is because co
On Sunday 30 September 2001 08:46 pm, Simon Cozens wrote:
> It's to do with me being confused between the size of the NV pointer
> (which is an IV)
Not necessarily.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Casting to IV is not the way to do this.
Index: strnative.c
===
RCS file: /home/perlcvs/parrot/strnative.c,v
retrieving revision 1.12
diff -c -r1.12 strnative.c
*** strnative.c 2001/09/18 13:42:41 1.12
--- strnative.c 2001/10/01
On Sun, Sep 30, 2001 at 11:31:21AM -0400, Gregor N. Purdy wrote:
> And, BTW, the current PackFile_Constant type isn't using a union.
> It has separate members for each type of constant. This could be
> changed once things are working. There's probably a few other
> things that could use some cle
On Sunday 30 September 2001 04:30 pm, Simon Cozens wrote:
> On Sun, Sep 30, 2001 at 12:57:53PM -0700, Brent Dax wrote:
> > I mentioned this idea before, and I've managed to implement a bit of it.
>
> VERY GOOD WORK!
>
> > That isn't quite valid Parrot bytecode, because of the concat. Concat
> > i
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Ask has found us a spot for the paper Alan was speaking of.
DS> http://dev.perl.org/perl6/talks/
very impressive paper. my recent proposal for a multi-queue malloc
system has some of the ideas of this but nowhere nearly as fully
On Sun, Sep 30, 2001 at 03:36:53PM -0700, Nicholas Knight wrote:
> A couple hours ago (3:34PM PDT), someone commited a new version of the
> MANIFEST file to the Parrot CVS. This file contains a file name that is
> missing, Parrot/String.pm, on line 11. Running "perl Configure.pl"
> fails as a r
Simon,
I'm completely confused by this,
1.) Why are you allocating sizeof(IV) instead of sizeof(NV)?
2.) What is the difference between
mem_sys_memcopy( &value, cursor, sizeof(NV) )
and allocating a new pointer and copying into it? They are both just
copying data into a pointer...does th
BTW, Cygwin works fine (although -Wall issues a number of warnings related
to the printf flags).
-Original Message-
From: Simon Cozens
To: Gregor N. Purdy
Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
Sent: 9/30/2001 3:21 PM
Subject: Re: NV Constants
On Sun, Sep 30, 2001 at 11:25:04AM -0400
On Sun, Sep 30, 2001 at 07:07:34PM -0500, Gibbs Tanton - tgibbs wrote:
> mem_sys_memcopy( &value, cursor, sizeof(NV) )
I'm being stupid. Of course that ought to work.
(And it does, everywhere it matters.)
> does the sizeof(IV) have something to do with it?
It's to do with me being confused
1) As a wonderful example of Warnock's Dilemma, I asked for some temporary
volunteers to do the Perl 6 summaries while I was otherwise occupied. Your
patience is commendable - no one offered. So I'll resume with next week's
summary, but I'm afraid I won't be backfilling.
2) Apocalypse and Ex
33 matches
Mail list logo
