On Wed, 14 Aug 2002, David M. Lloyd wrote:
The problem was that the math vtable methods were giving up if the
other side of the operator wasn't an int or a num. So the current
version of PerlArray would make $x undef. I'm not sure getting the
other thing's int value (as opposed to its
I can comment on a bit of this at least :)
On Wed, 24 Jul 2002, Melvin Smith wrote:
It is not clear to me yet that there needs to be a 1-to-1 correlation
from PMC's to upper level classes.
There won't be. In general, there well be far fewer PMC classes than
upper-level classes.
Also, as
On Mon, 22 Jul 2002, Dan Sugalski wrote:
At 5:52 PM +0100 7/22/02, Alberto Manuel Brandão Simões wrote:
Dan, can we create this new vtable method? returning an integer (long
integer)... with name hashValue, or asHash.. or something else.
Yep. Call it id and have it return an INTVAL.
Do we
On Sat, 13 Jul 2002, Tom Hughes wrote:
Of course... The attached patch should handle that I think...
This patch is breaking several Solaris 32-bit tests. The following
assembly (from t/pmc/perlarray1.pbc):
new P0,.PerlArray
set P0,0
set I0,P0
print I0
On Mon, 15 Jul 2002, John Porter wrote:
David M. Lloyd wrote:
Do we really want *two* inheritance trees per object
in Perl 6? One language-level and one PMC-level?
Well, parrot != perl6, so I don't see a problem.
Ugh.
The MM dispatch problem is pretty much solidly in
the realm of pmc
On Tue, 16 Jul 2002, John Porter wrote:
David M. Lloyd wrote:
John Porter wrote:
The MM dispatch problem is pretty much solidly in
the realm of pmc inheritance,
There _is_ no pmc inheritance right now.
There's just a set of default functions.
Call it what you want. The point
On Fri, 12 Jul 2002, John Porter wrote:
Which IRC network, which channel?
I use irc.pobox.com, you can also try irc.rhizomatic.net
Channel is #parrot
Problem I have with irc (besides the fact that I don't, can't and won't
use it) is that all the good stuff that flows by isn't getting
On Mon, 15 Jul 2002, Ashley Winters wrote:
PDD02: Common vtable format for all variables
Nice.
I should be able to answer some of these.
Question: Why is the key param for keyed_int vtable functions a pointer?
Considering I have to implement all those functions to add a PMC...
seems odd
On Wed, 10 Jul 2002, Dan Sugalski wrote:
What bothers me is this: the programmer needs to be able to predict
what the machine is going to do with the code she gives it.
And predicting how the machine is going to resolve the multimethod
call could be, in any but trivial cases, far too
On Fri, 5 Jul 2002, Josh Wilmes wrote:
At 8:55 on 07/05/2002 CDT, David M. Lloyd [EMAIL PROTECTED] wrote:
It got removed because it wasn't in the spec... Dan directed that we
replace it with a version of init that accepts a PMC argument
(init_pmc_method_t) that can be used to send
Well, there's now a _keyed_int form for every _keyed vtable method.
PDD02 has a summary of how these new methods work.
Also, I've added push/pop/shift/unshift vtable methods. There are no ops
that use these yet.
So if anyone wants to a make a (first?) contribution, the following needs
to be
On Mon, 10 Jun 2002, Jeff wrote:
Tests are now failing because of the removal of the 'inc_n_ic' opcode. I
find this interesting for several reasons. One, the tests probably
should have been removed. Two, once the 'inc' operator has two
parameters, it is no longer 'increment' in my mind. I
On Fri, 7 Jun 2002, Brent Dax wrote:
Er, what patch?
It was attached because it is 214K. I could resend with it inline if
nobody minds the large message body.
- D
[EMAIL PROTECTED]
On Fri, 7 Jun 2002, Brent Dax wrote:
David M. Lloyd:
# On Fri, 7 Jun 2002, Brent Dax wrote:
#
# Er, what patch?
#
# It was attached because it is 214K. I could resend with it
# inline if nobody minds the large message body.
I don't think anybody minds an attached patch, but I didn't
On Fri, 31 May 2002, Melvin Smith wrote:
The common way is to define our own INLINE definition and have Configure
check for it, define it null if needed, and conditionally include it
into a file as extern if so.
Sounds like a job for. BrentDax++!
Also some compilers (like SUN
Nearly two years ago, a great debate was begun on this mailing list about
when to inline code and when not to, as well as the actual merits of
inlining in the first place. I will attempt to summarize here, becuase
this debate was never concluded and we now are at a point where some
things are
On Tue, 28 May 2002, Hong Zhang wrote:
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point, having considered the
alternatives, I wish it were otherwise but it's not. Too bad for us.
I think this statement is not very accurate.
On Wed, 29 May 2002, Jerome Vouillon wrote:
On Wed, May 29, 2002 at 11:45:45AM -0500, David M. Lloyd wrote:
Dan may have been referring to the fact that on some key platforms
(Solaris included) (sig)setjmp/longjmp are officially marked as unsafe for
use inside of threads.
Is it really
On Wed, 29 May 2002, Hong Zhang wrote:
Actually I'd been given dire warnings from some of the Solaris folks.
Don't use setjmp with threads!
I've since gotten details, and it's Don't use setjmp with threads
and do Stupid Things.
I used to be at Sun. I knew those warnings too. If we
On Wed, 29 May 2002, Hong Zhang wrote:
I used to be at Sun. I knew those warnings too. If we use longjmp
carefully, we can make it. In the worst case, write our own version.
..Or we could use setcontext/getcontext, could we not?
The setcontext/getcontext will be much worse than
On Sun, 26 May 2002, Steve Fink wrote:
I implemented it that way once in my private tree. But I ended up
replacing it with a couple of PerlArrays.
I am now of the opinion that there's currently nothing for a regex PMC
to do. At compile-time, you know what sort of beast you're matching
May I be the first to say that the new Configure system *rocks*?
No more digging through the source code to find that config option...
- D
[EMAIL PROTECTED]
On Wed, 22 May 2002, Steve Fink wrote:
Which brings me to my question: is there some way of getting
machine-readable output from tinderbox? I'd really like to alias my cvs
commit to something that automatically monitors the tinderbox for the
next hour and a half so it screams at me when I
Are the REGEX structure and the match vtable methods officially dead? The
POD inside of rx.ops does not mention them at all, and right now REGEX is
typedef'd to void and no-one uses the 'match' method for anything.
Since regular expressions will most likely be implemented as Parrot
bytecode,
Has anyone given any thought to this problem yet?
Will we be able to do this or do we need a special vtable whose entries
automatically do a callback to Parrot?
- D
[EMAIL PROTECTED]
On Mon, 20 May 2002, David M. Lloyd wrote:
Has anyone given any thought to this problem yet?
Will we be able to do this or do we need a special vtable whose entries
automatically do a callback to Parrot?
For that matter, what about calling C functions from Parrot? Loading PMCs
dynamically
On Mon, 20 May 2002, Daniel Grunblatt wrote:
On Mon, 20 May 2002, David M. Lloyd wrote:
What about subroutines? Are bsr jsr the way it's gonna be or is there
a rework in the works?
docs/pdds/pdd03_calling_conventions.pod :)
OK, I've looked it over but it doesn't say Subroutines
Is CVS access for Parrot still invitation-only? If not, I would like to
request CVS access. I have posted mildly useful patches (mostly warning
fixes really) in the past; I don't think any have ever been rejected.
The CVS page at dev.perl.org/cvs implies that a maintainer (probably Dan I
On Thu, 21 Mar 2002, Melvin Smith wrote:
Ahhh, those simpler days
Hmm you have just given me an evil idea...
I must have had the same idea in the same instant. :-)
- D
[EMAIL PROTECTED]
I forgot to mention there's a patch enclosed. If it doesn't survive
formatting, take it out of my previous message.
On Tue, 19 Mar 2002, David M. Lloyd wrote:
My Tinderbox client for 32-bit Solaris + 64-bit ints is entering an
infinite loop with this message:
Determining C data type sizes
This fixes a compile error under Solaris: a cast does not yield an
lvalue. I think this is something that GCC allows that others don't.
It's not entirely clear to me why 'rflags' was a UINTVAL to begin with.
It doesn't look like this code is really in use anyway. But in any case,
casting an
On Fri, 15 Mar 2002, Nicholas Clark wrote:
On Fri, Mar 15, 2002 at 03:42:50PM -0500, Dan Sugalski wrote:
On Fri, 15 Mar 2002, Tim Bunce wrote:
Might be good to also provide higher level controls that just
provide hints to the GC. Somewhat like the use less qw(memory);
pragma
I have a design question here. Why did we take the approach of having a
match method on every single vtable, instead of having a vtable for
regular expressions, and have regex be an object (like Perl 5)?
From a Perl (6) perspective, it makes more sense to me:
# This:
$a =~ /$regex/;
#
Subject says it all...
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.77
diff -a -u -r1.77 Configure.pl
--- Configure.pl9 Jan 2002 17:24:11 - 1.77
+++ Configure.pl
On Sat, 12 Jan 2002, Dan Sugalski wrote:
At 10:23 AM 1/12/2002 -0600, David M. Lloyd wrote:
On Sat, 12 Jan 2002, Dan Sugalski wrote:
At 09:05 PM 1/11/2002 -0600, David M. Lloyd wrote:
I have a design question here. Why did we take the approach of having a
match method on every
On Sat, 12 Jan 2002, Dan Sugalski wrote:
At 09:05 PM 1/11/2002 -0600, David M. Lloyd wrote:
I have a design question here. Why did we take the approach of having a
match method on every single vtable, instead of having a vtable for
regular expressions, and have regex be an object (like Perl
Try #2, my first was lost in the mail or something.
Index: rx.ops
===
RCS file: /home/perlcvs/parrot/rx.ops,v
retrieving revision 1.4
diff -a -u -r1.4 rx.ops
--- rx.ops 11 Jan 2002 05:34:00 - 1.4
+++ rx.ops 11 Jan
Just out of curiosity, is the regex compiler going to be written in Parrot
or C?
- D
[EMAIL PROTECTED]
This patch fixes a warning and also changes an 'int' to an 'INTVAL'. All
tests should pass on Solaris.
Index: rx.ops
===
RCS file: /home/perlcvs/parrot/rx.ops,v
retrieving revision 1.4
diff -a -u -r1.4 rx.ops
--- rx.ops 11 Jan
This patch fixes parrotpointer.pmc, which tries to return 0 from a void
function.
Index: classes/parrotpointer.pmc
===
RCS file: /home/perlcvs/parrot/classes/parrotpointer.pmc,v
retrieving revision 1.1
diff -u -r1.1
On Thu, 10 Jan 2002, Steve Fink wrote:
The naming of things is getting a bit messy. I'd like to propose a
convention that I use in my work. It's compatible with the last draft
of PDD 7 that I could find:
http://www.mail-archive.com/perl6-internals%40perl.org/msg03422.html
I agree, we should
Just as the subject says.
Index: core.ops
===
RCS file: /home/perlcvs/parrot/core.ops,v
retrieving revision 1.72
diff -u -r1.72 core.ops
--- core.ops9 Jan 2002 17:24:11 - 1.72
+++ core.ops10 Jan 2002 21:47:29 -
This patch will clash with Steve Fink's stacks patch, but you get the
idea.
Also, there's gonna be a small speed hit that I don't know how to get
around. The problem is that when you save an int constant on the stack in
a mixed 32/64-bit system, the int type is 8 bytes but the pointer points
to
I'm removing this more common configuration because of the increased time
it takes to build Parrot these days. If someone else wants to pick it up,
cool, but until then I'm figuring that if the other two (mixed 32/64-bit
and pure 64-bit) work, 32-bit probably does too.
- D
[EMAIL PROTECTED]
On Thu, 10 Jan 2002, David M. Lloyd wrote:
The problem is that when you save an int constant on the stack in a
mixed 32/64-bit system, the int type is 8 bytes but the pointer points
to four bytes of int constant and four bytes of... something else. So
it has to be copied out into a temp
Revision 1.89 of MANIFEST introduced io/io_unix.c, but configure dies
becuase the file isn't there...
- D
[EMAIL PROTECTED]
On Wed, 9 Jan 2002, Dan Sugalski wrote:
At 02:39 PM 1/9/2002 -0500, Melvin Smith wrote:
Must be Dan's magic fingers again. I renamed io_os.c to io_unix.c but
probably
it got lost in the shuffle.
Weird. It's in my local MANIFEST from the patch, and CVS is convinced
that it's up to date.
On Fri, 4 Jan 2002, Jason Diamond wrote:
Okay, the problem is in the compiletestc in Configure.pl. Unfortunately
I'm
not sure what's proper for this. If you could, take a look at hints/vms.pl
for how to override the default compiletestc sub and add an override to
hints/mswin32.pl? Or
I'm getting warnings on this bit of core.ops when compiling with 64-bit
ints:
op write(i|ic, i|ic) {
INTVAL * i = ($2); /* */
write($1, i, sizeof(INTVAL));
goto NEXT();
}
I'm getting a warning that stems from the fact that sizeof(INTVAL) = 8 and
sizeof(opcode_t) = 4, so the pointer
On Fri, 4 Jan 2002, Bryan C. Warnock wrote:
On Friday 04 January 2002 10:43 pm, David M. Lloyd wrote:
So that you can use constants that are up to sizeof(opcode_t) bytes, but
after that you're on your own. That raises a question, though: Do we
want to move integer constants
Parrot Version 0.0.3 Configure
Copyright (C) 2001-2002 Yet Another Society
Since you're running this script, you obviously have
Perl 5--I'll be pulling some defaults from its configuration.
Checking the MANIFEST to make sure you have a complete Parrot kit...
No such file: classes/perlhash.pmc
On Thu, 3 Jan 2002, Bryan C. Warnock wrote:
On Thursday 03 January 2002 12:33 am, Bryan C. Warnock wrote:
Looks like the chunk_base logic doesn't work on 64-bit Solaris. Every
test failure I checked was centered around an inaccesable address coming
out of STACK_CHUNK_BASE(*top) [line 85]
On Thu, 3 Jan 2002, Jarkko Hietaniemi wrote:
Please find attached a typescript log from a freshly rsynced parrot in
tru64.
Failed Test Status Wstat Total Fail Failed List of Failed
-
t/op/basic.t
On Thu, 3 Jan 2002, Nicholas Clark wrote:
On Thu, Jan 03, 2002 at 08:46:31AM -0600, David M. Lloyd wrote:
Maybe we should be using the Configure output to determine what postfix to
use, based on the size of ints, longs, long longs, etc., and pointers,
rather than almost always being
On Thu, 3 Jan 2002, Nicholas Clark wrote:
On Thu, Jan 03, 2002 at 08:46:31AM -0600, David M. Lloyd wrote:
Maybe we should be using the Configure output to determine what postfix to
use, based on the size of ints, longs, long longs, etc., and pointers,
rather than almost always being
Also, the UL[L] should probably be on the inside of the ():
stacklow = '(~0xfffULL)',
I still don't see this one is safer than my proposal.
~((uintptr_t) 0xfff);
Well, if you ever want to specify a constant longer than 0x7fff, you'd
better put a 'u', 'ul' or 'ull' after
Is it 'incorrect' to build Parrot with ints that are bigger than opcodes?
My 'some 64-bitness' build is generating warnings and failing tests
because of the pointer mismatch (long * vs long long *) between INTVAL and
opcode_t.
Also, just out of curiosity, why is it INTVAL and opcode_t, rather
The incorrect assumption here is that you are building Parrot with the
same compiler and architecture (read: integer and pointer sizes) that Perl
was built with. Specifically, it allows my perl (64-bit ints but
otherwise 32-bit) to build a full 64-bit Parrot under Solaris. Maybe it
helps other
This patch fixes a pointer deref problem if sizeof(INTVAL)
sizeof(opcode_t).
Index: core.ops
===
RCS file: /home/perlcvs/parrot/core.ops,v
retrieving revision 1.67
diff -u -r1.67 core.ops
--- core.ops2 Jan 2002 00:55:03 -
Silence this warning.
Index: io/io_os.c
===
RCS file: /home/perlcvs/parrot/io/io_os.c,v
retrieving revision 1.2
diff -u -r1.2 io_os.c
--- io/io_os.c 2 Jan 2002 04:10:50 - 1.2
+++ io/io_os.c 2 Jan 2002 16:30:52 -
@@
Silences this warning.
Index: chartypes/unicode.c
===
RCS file: /home/perlcvs/parrot/chartypes/unicode.c,v
retrieving revision 1.4
diff -u -r1.4 unicode.c
--- chartypes/unicode.c 31 Dec 2001 20:00:37 - 1.4
+++
Here's how things build on Solaris now:
32-bit: Perfect, beautiful, couldn't be better.
32-bit with 64-bit ints: OK, but many PMC tests fail, don't know why yet.
64-bit: Horrid. About 25% of tests are crashing, don't know why yet.
The 32-bit with 64-bit ints problems should be duplicatable on
Dan posted to p5p, which I noticed just after I sent this... whoops. :-)
- D
[EMAIL PROTECTED]
-- Forwarded message --
Date: Mon, 31 Dec 2001 16:41:43 -0600 (CST)
From: David M. Lloyd [EMAIL PROTECTED]
To: Dan Sugalski [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject
On Mon, 31 Dec 2001, Dan Sugalski wrote:
At 04:43 PM 12/31/2001 -0600, David M. Lloyd wrote:
Dan posted to p5p, which I noticed just after I sent this... whoops. :-)
Heh, yep, I was fishing for p5p folks that might have machines they
could enlist if it didn't take any effort on their part
On Mon, 31 Dec 2001, Dan Sugalski wrote:
Could you throw the system into tinderbox? It'll give us logs of the
zillions of errors or so...
I am working on it right now. I will set up two: one that uses sparcv9
(fully 64-bit) and one that is 32-bit with 64-bit ints.
Cool, thanks. We
When I look at the tinderbox screen, there's green, orange, yellow, and
red. What to the colors mean? There's no key.
You know, it's kind of fun to watch. There should be like an auto-refresh
every 5 minutes or something. :-)
- D
[EMAIL PROTECTED]
On Thu, 13 Dec 2001, Dan Sugalski wrote:
I'm not sure we'll ultimately go this way, but I've added the following ops
to the core:
setline
setpackage
setfile
getline
getpackage
getfile
so compiler output can note the file, package, and line that code is in.
Will there be a way to 'freeze' an interpreter so that its state can be
serialized to storage? If so, how would this work with PMCs? Some
special vtable method?
This was discussed several months ago when high-level language compilation
was being discussed, but nothing definite ever came of it.
On Wed, 5 Dec 2001, Dan Sugalski wrote:
The Zork interpreter might be stack based, thinking about it, but it was
hardly geared for speed, so I don't know that it'd count if it was.
FWIW, there are many MUDs and MUCKs out there (multiplayer text-based
role-playing gmaes for those not in the
On Mon, 3 Dec 2001, Dan Sugalski wrote:
I'm getting tempted to have some sort of multi-level ENV thing that, for
most single-interpreter cases, collapses down to a plain getenv/putenv.
On a related topic, I have a friend/coworker who's an avid developer of
PHP, and we routinely get into,
On Sat, 24 Nov 2001, Bryan C.Warnock wrote:
On a side note, do we want to be positive-oriented or
negative-oriented? (Do we want to succeed as fast as possible, or fail
as fast as possible? I'm thinking fail, since you're probably more
likely to do that.) If you weight each kind of regex
On Tue, 16 Oct 2001, Dan Sugalski wrote:
Parrot's going with the one thread per interpreter model of
threading.
Yay!
PMCs will be shareable, but only when explicitly marked as shared. Passing
an unshared PMC to another interpreter's a fatal error. PMCs *can* be
cloned when an interpreter
On Fri, 28 Sep 2001, Alan Burlison wrote:
Arthur Bergman wrote:
longjmp in a controlled fashion isn't thread-safe? Or longjmping while
holding mutexs and out from asynchronous handlers is not thread-safe?
Arthur It *may* be possible to use longjmp in threaded programs in a
restricted
I'm just curious, is there a plan for how closures will work in Parrot? I
think that closures are one of the coolest Perl 5 features around (despite
their memory leak issues :-), and I'd hate to see them go away.
- D
[EMAIL PROTECTED]
On Mon, 24 Sep 2001, Uri Guttman wrote:
then what about a win/win? we could make the event checking style a
compile time option.
DS Odds are you'll get per-op event checking if you enable debugging,
DS since the debugging oploop will really be a generic check event
DS every op
On Sat, 22 Sep 2001, Ken Fox wrote:
I've been thinking about the possibility of building a higher-level
VM. The current VM is very close to a traditional CPU. What if we did
something non-traditional that made implementing higher-level
lexically scoped languages easier?
snip
I'm proposing:
Not to harp on this subject, but there is still no official place where a
casual developer like myself can find a current listing of PDDs aside from
the perl6-internals mail list archive. http://dev.perl.org/perl6 has not
been updated in a long time... and that's the place that I would expect
On Mon, 10 Sep 2001, Simon Cozens wrote:
On Sat, Sep 08, 2001 at 12:00:24PM -0400, Dan Sugalski wrote:
Okay, I'm whipping together the fancy math section of the interpreter
assembly language. I've got:
sin, cos, tan : Plain ones
asin, acos, atan: arc-whatevers
On Fri, 6 Jul 2001, Dan Sugalski wrote:
At 01:26 PM 7/5/2001 -0500, David M. Lloyd wrote:
It would be nice to be able to tell the interpreter to call a user-defined
C function between opcodes. This could make it easier to implement
debuggers, profilers, etc. as well as providing a method
On Fri, 6 Jul 2001, Dan Sugalski wrote:
You've pretty much got it. The flag-checking will be hardwired, but
there's no reason that the function called can't be user-defined.
Being able to install an arbitrary number of user-defined inter-opcode
(and inter-statement) functions seems
Here's a feature suggestion for Perl 6.
It would be nice to be able to tell the interpreter to call a user-defined
C function between opcodes. This could make it easier to implement
debuggers, profilers, etc. as well as providing a method of safely using
asynchronous callbacks that certain C
81 matches
Mail list logo
