On Mon, Oct 01, 2001 at 06:10:55PM -0400, Michael Fischer wrote:
> Its also at least 2 weeks old, and obsoleted/made incompatible
> by lots of other stuff during that time, including opcode switch()
> stuff I'd sent to other commiters (presumably unused).
The opcode switch stuff I can't use in it
from current CVS,
[ask@embla parrot]$ uname -a && perl t/harness
Darwin embla.int.develooper.com 1.4 Darwin Kernel Version 1.4: Sun Sep 9 15:39:59 PDT
2001; root:xnu/xnu-201.obj~1/RELEASE_PPC Power Macintosh powerpc
t/op/basic..ok, 1/5 skipped: label constants unimplemented in assemb
On Monday 01 October 2001 07:16 pm, Dan Sugalski wrote:
> >Well, we recently went to all the trouble to decouple opcodes from IVs -
> > I assume for a reason. Do we want to undo that, or move them into the
> > constant table?
>
> Nope.
To one, the other, or both?
>
> >If you re-couple the sizes
My normal email system isn't working, but I wanted to say that the changes
work on CygWin, Tru64, and Solaris SunOS 5.8.
Tanton Gibbs
[EMAIL PROTECTED]
"Why regret? Tommorow will soon be yesterday and today but a memory."
- Gibbs
"Remember, wherever you go, there you are!" - The Adventures of Buc
On Sun, 30 Sep 2001, Ask Bjoern Hansen wrote:
> > Is [EMAIL PROTECTED] working? The message below is the last one I have
> > received.
>
> I believe it is. I don't see anything to hitchhiker.org in the mail
> queue here.
well, it wasn't. =)
ValueClick had a power outage in the office where
[EMAIL PROTECTED] (Brent Dax) writes:
> Automated snapshots and e-mail notifications of CVS commits have
> both stopped. What's going on?
snapshots looks okay, but there's something #$@# with the mails. I'll
have a look. :-)
Generally [EMAIL PROTECTED] is better for that sort of thing.
- as
> Automated snapshots and e-mail notifications of CVS commits have both
> stopped. What's going on?
At some point, someone set the clock back on the machine that sends the mail
(I noticed because all of my new mails are coming in as older than ones that
I received earlier in the day). If this is
Automated snapshots and e-mail notifications of CVS commits have both
stopped. What's going on?
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
Debian Linux/PowerPC without 64 bit integers tests out 100% ok.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
"Let's face it," said bearded Rusty Simmons, opening a can after the
race. "Th
At 03:27 PM 10/1/2001 +0100, Simon Cozens wrote:
>On Mon, Oct 01, 2001 at 10:23:11AM -0400, Jason Gloudon wrote:
> > What about the current macros for NUM_REG etc ?
>
>I'd probably rip 'em out too. Stops people accidentally hand hacking the
>.c file
>instead of the .ops file and then losing all t
At 09:23 AM 10/1/2001 -0400, Michael Maraist wrote:
> > > Just because parrot knows what functions can croak, it
> > > doesn't mean that
> > > it can possibly know which locks have been taken out all
> > > the way back up
> > > the stack between the call to longjmp and the
> > > corresponding setj
At 04:15 PM 9/30/2001 -0400, Sam Tregar wrote:
>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 ea
At 10:45 AM 9/30/2001 -0700, Hong Zhang wrote:
>The same story may happen to Perl. If Perl make all operations on SV, AV,
>HV sync, the performance will be pathetic. Many SMP machines can only
>perform about 10M sync operations per second, because sync op requires
>system-wide bus lock or global m
Still getting a lot of smoke from Linux/PowerPC with 64 bit integers.
Failed TestStatus Wstat Total Fail Failed List of Failed
t/op/basic.t 2 512 52 40.00% 2, 4
t/op/bitwise.t 4 1024
At 11:28 AM 9/30/2001 -0400, Bryan C. Warnock wrote:
>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 t
At 09:30 PM 9/30/2001 +0100, Simon Cozens wrote:
>On Sun, Sep 30, 2001 at 12:57:53PM -0700, Brent Dax wrote:
> > That isn't quite valid Parrot bytecode, because of the concat. Concat
> > is currently documented to take only two arguments.
>
>This is because concat is broken. I think I need a ruli
FreeBSD/x86
OK/OK
Win32/x86
OK/NOK (report after my sig)
Linux/IA64
OK/NOK (smoke report after my sig)
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
Win32/x86:
Failed Test Stat Wstat Total Fail Failed List of Failed
--
Dan Sugalski:
# (I'll start
# stuffing 0xDEADBEEF in there if I have to... :)
Actually, I think 0xDECAF would bug late-night coders even more! :^)
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
At 10:52 AM 10/1/2001 -0400, Gregor N. Purdy wrote:
>Dan --
>
> > Here's a list of manifest constants I think Parrot should know about.
> > Anyone care to add to the list?
> >
> > '' (empty string)
> > 0
> > 1
> > undef
> > NaN
> > pi
> > e
> > epsil
At 10:32 AM 10/1/2001 -0400, Bryan C. Warnock wrote:
>On Monday 01 October 2001 10:29 am, Dan Sugalski wrote:
> > Here's a list of manifest constants I think Parrot should know about.
> > Anyone care to add to the list?
> >
> > '' (empty string)
> > 0
> > 1
> > undef
> >
At 03:35 PM 10/1/2001 -0700, Brent Dax wrote:
>Wizard:
># This was discussed to some extent on this list before (see RFC
># http://dev.perl.org/rfc/263.pod). If parrot is expected to be
># a JVM for
># countless other languages, then it MUST (IMHO) understand the
># concept of
># NULL. Either that
On Oct 01, Simon Cozens <[EMAIL PROTECTED]> took up a keyboard and banged out
> On Mon, Oct 01, 2001 at 04:22:30PM -0400, Jason Gloudon wrote:
> > It breaks manual ops like eq_i_ic since the generated code can return without
>returning a value.
> Yeah, I just noticed that myself. :) Retracting.
Wizard:
# This was discussed to some extent on this list before (see RFC
# http://dev.perl.org/rfc/263.pod). If parrot is expected to be
# a JVM for
# countless other languages, then it MUST (IMHO) understand the
# concept of
# NULL. Either that, or it must make allowances for the dynamic
# inc
Andy Dougherty:
# On Wed, 26 Sep 2001, Andy Dougherty wrote:
#
# > > I posted a patch last week to change the 'l' to a 'q',
# but more generally,
# > > the assumption that sizeof(opcode_t) == sizeof(IV) should
# probably be
# > > removed and each should be computed independently.
# Perhaps late to
Mattia Barbon:
# Makes Win32 use ExtUtils::Command::rm_f as a rm -f replacemnt.
Thanks, applied. This one's been hovering near the top of my stack for
a while, but I kept pushing new things on above it till now.
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for wh
On Mon, Oct 01, 2001 at 04:22:30PM -0400, Jason Gloudon wrote:
> It breaks manual ops like eq_i_ic since the generated code can return without
>returning a value.
Yeah, I just noticed that myself. :) Retracting.
--
Rule 3: If the character is comprised of a container without another radical,
On Mon, Oct 01, 2001 at 03:37:34PM +0100, Simon Cozens wrote:
> On Sun, Sep 16, 2001 at 01:44:12PM -0400, Michael Fischer wrote:
> > Small hack to keep process_opfunc.pl from generating
> > extra return() statements.
>
> Thanks, applied.
That patch is broken or incomplete.
It breaks manual ops
> On Sun, Sep 30, 2001 at 10:45:46AM -0700, Hong Zhang wrote:
> >Python uses global lock for multi-threading. It is reasonable for io
thread,
> >which blocks most of time. It will completely useless for CPU intensive
> >programs or large SMP machines.
>
> It might be useless in theory. In practi
> Now how do you go about performing an atomic operation in MT? I
> understand the desire for reentrance via the exclusive use of local
> variables, but I'm not quite sure how you can enforce this when many
> operations are on shared data (manipulating elements of the
> interpreter / global varia
On Wed, 26 Sep 2001, Andy Dougherty wrote:
> > I posted a patch last week to change the 'l' to a 'q', but more generally,
> > the assumption that sizeof(opcode_t) == sizeof(IV) should probably be
> > removed and each should be computed independently. Perhaps late today I'll
> > have a chance to d
This was discussed to some extent on this list before (see RFC
http://dev.perl.org/rfc/263.pod). If parrot is expected to be a JVM for
countless other languages, then it MUST (IMHO) understand the concept of
NULL. Either that, or it must make allowances for the dynamic inclusion of a
definition of
Dan --
> Here's a list of manifest constants I think Parrot should know about.
> Anyone care to add to the list?
>
> '' (empty string)
> 0
> 1
> undef
> NaN
> pi
> e
> epsilon (maybe)
That brings up an interesting issue. The Ix registers initiali
On Sun, Sep 16, 2001 at 01:44:12PM -0400, Michael Fischer wrote:
> Small hack to keep process_opfunc.pl from generating
> extra return() statements.
Thanks, applied.
--
Hanlon's Razor:
Never attribute to malice that which is adequately explained
by stupidity.
On Sat, Sep 29, 2001 at 12:08:20AM -0700, Josh Wilmes wrote:
> Here's a fixed version of that patch I sent a while back:
Thanks, applied.
--
A formal parsing algorithm should not always be used.
-- D. Gries
On Monday 01 October 2001 10:29 am, Dan Sugalski wrote:
> Here's a list of manifest constants I think Parrot should know about.
> Anyone care to add to the list?
>
> '' (empty string)
> 0
> 1
> undef
> NaN
> pi
> e
> epsilon (maybe)
>
(+- infinity)?
Here's a list of manifest constants I think Parrot should know about.
Anyone care to add to the list?
'' (empty string)
0
1
undef
NaN
pi
e
epsilon (maybe)
Dan
--
On Sun, Sep 30, 2001 at 10:45:46AM -0700, Hong Zhang wrote:
>Python uses global lock for multi-threading. It is reasonable for io thread,
>which blocks most of time. It will completely useless for CPU intensive
>programs or large SMP machines.
It might be useless in theory. In practice it isn't,
On Mon, Oct 01, 2001 at 10:23:11AM -0400, Jason Gloudon wrote:
> What about the current macros for NUM_REG etc ?
I'd probably rip 'em out too. Stops people accidentally hand hacking the .c file
instead of the .ops file and then losing all their changes on rebuild. Not
that I've ever done that tri
On Monday 01 October 2001 08:36 am, Simon Cozens wrote:
> On Mon, Oct 01, 2001 at 07:20:56AM -0500, Gibbs Tanton - tgibbs wrote:
> > Casting to IV doesn't actually hurt anything (unless there is an
> > alignment issue); however, casting to char* is the more idiomatic way of
> > doing it. I'll comm
On Monday 01 October 2001 08:20 am, Gibbs Tanton - tgibbs wrote:
> Casting to IV doesn't actually hurt anything (unless there is an alignment
> issue); however, casting to char* is the more idiomatic way of doing it.
> I'll commit this unless Simon says he is going to handle it in "The Great
> Ren
All --
Here's an updated version of my Parrot Bytecode --> C compiler. I've
updated it to work in the context of the latest commits.
NOTE: The only existing file that is modified by this patch is
MANIFEST (to add the two new files), so there's little impact on
your sandbox if you are testing oth
On Sun, 30 Sep 2001, Hong Zhang 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.
>
> One way to reduce sync overhead is to m
Yeah, I knew we were trying to stay away from char*; however, since this is
in the native string library, there's pretty much no getting around it :)
-Original Message-
From: Simon Cozens
To: '[EMAIL PROTECTED] '
Sent: 10/1/2001 7:36 AM
Subject: Re: [PATCH] Bad cast
On Mon, Oct 01, 2001
On Mon, Oct 01, 2001 at 07:20:56AM -0500, Gibbs Tanton - tgibbs wrote:
> Casting to IV doesn't actually hurt anything (unless there is an alignment
> issue); however, casting to char* is the more idiomatic way of doing it.
> I'll commit this unless Simon says he is going to handle it in "The Great
Casting to IV doesn't actually hurt anything (unless there is an alignment
issue); however, casting to char* is the more idiomatic way of doing it.
I'll commit this unless Simon says he is going to handle it in "The Great
Renaming".
Tanton
-Original Message-
From: Bryan C. Warnock
To: [
On Sun, Sep 30, 2001 at 11:37:37PM -0400, Jason Gloudon wrote:
> Here is a patch for macros for accessing constants from ops. This uses
> (INT|STR|NUM)_PCONST(i) for the relevant types. Best to avoid filling opcode
> definitions with manual structure dereferences.
Nice idea, but I'd *much* rathe
46 matches
Mail list logo
