On Mon, May 27, 2002 at 08:41:59AM -0700, Sean O'Rourke wrote:
But there are two kinds of available here: available without asking the
operating system for more; and available period. If we're in the first
situation, it seems reasonable to just ask the OS for a new block and keep
going,
Okay. I have yet another idea for solving our infant mortality problem,
which I think Dan might like. :)
The neonate idea originally was intended to be set on *all* headers
returned by the memory system, and they'd be reset by a clear_neonate op.
At least, that's how I understood it. A
On Mon, May 27, 2002 at 04:33:07PM -, Peter Gibbs wrote:
These changes do cause a slight performance degradation, but I believe it is
worth it for the overall simplification of transparent protection of the
newborn.
Performance can only be a secondary goal, after correct behaviour.
What
On Tue, May 28, 2002 at 04:45:06AM -0400, Mike Lambert wrote:
When you call new_*_header, the neonate
flag is automatically turned on for you. As a programmer writing a
function, you explicitly turn off the neonate flag when you attach it to
the root set, or let it die on the stack. If you
I propose the following alternate guidelines.
First, the code would look something like this:
STRING * concat (STRING* a, STRING* b, STRING* c) {
PARROT_start();
PARROT_str_params_3(a, b, c);
PARROT_str_local_2(d, e);
d = string_concat(a, b);
e = string_concat(d, c);
Jerome Vouillon:
# I propose the following alternate guidelines.
#
# First, the code would look something like this:
#
# STRING * concat (STRING* a, STRING* b, STRING* c) {
# PARROT_start();
# PARROT_str_params_3(a, b, c);
# PARROT_str_local_2(d, e);
#
# d = string_concat(a,
STRING * concat (STRING* a, STRING* b, STRING* c) {
PARROT_start();
PARROT_str_params_3(a, b, c);
PARROT_str_local_2(d, e);
d = string_concat(a, b);
e = string_concat(d, c);
PARROT_return(e);
}
Yet more ideas. Woohoo! :)
I considered this kind of approach myself,
On Tue, May 28, 2002 at 04:57:01AM -0700, Brent Dax wrote:
I assume the lack of mentions of Buffers are an oversight.
Right. It would be great if there was only one kind of parrot objects...
# (5) do not nest function calls
#(for instance, e = string_concat (string_concat(a, b),
On Tue, May 28, 2002 at 08:30:52AM -0400, Mike Lambert wrote:
Can you provide an implementation of the macros you described above? I
have a few concerns which I'm not sure if they are addressed. For example:
#define PARROT_start() \
frame * saved_top = stack_top;
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
#define PARROT_str_local(d)\
STRING * d = NULL; \
frame frame_##d;\
int dummy_##d = ( \
(frame_##d.ptr = d), \
(frame_##d.next = stack_top), \
(stack_top = frame_##d), \
On Tue, 28 May 2002 12:50:06 +0200 Jerome Vouillon [EMAIL PROTECTED] wrote:
I propose the following alternate guidelines.
STRING * concat (STRING* a, STRING* b, STRING* c) {
PARROT_start();
PARROT_str_params_3(a, b, c);
PARROT_str_local_2(d, e);
d = string_concat(a, b);
On Tue, May 28, 2002 at 03:45:58PM +0200, Jerome Vouillon wrote:
On Tue, May 28, 2002 at 08:30:52AM -0400, Mike Lambert wrote:
PARROT_str_params_3(a, b, c);
What's the point of this? With rule 5 that prevents function call nesting,
you're guaranteed of all your arguments being rooted. I
On Tue, May 28, 2002 at 07:54:49AM -0700, Robert Spier wrote:
#define PARROT_str_local(d)\
STRING * d = NULL; \
frame frame_##d;\
int dummy_##d = ( \
(frame_##d.ptr = d), \
On Mon, May 27, 2002 at 08:41:59AM -0700, Sean O'Rourke wrote:
Since our memory-allocating routines return NULL quite a ways back up the
call chain (all the way through e.g. string_grow()), here's another way to
do this -- if allocation returns NULL all the way to an op function, it
can make
I believe that the idea is to make things flexible enough that FURTHER
changes to Perl, beyond Perl 6, will be easier too.
On Sun, 2002-05-26 at 06:10, Ask Bjoern Hansen wrote:
[EMAIL PROTECTED] (Sebastian Bergmann) writes:
Leon Brocard wrote:
Oh, this happens to be a FAQ. The main
What are the debugging issues you mention? Note that this macro will
never fail: there is no pointer deferencing, no memory allocation, ...
Never is a bad word to use for anything more complicated than x=1+2.
(Which will hopefully get constant folded and optimized away anyway.)
It is
On Tue, 28 May 2002, Jerome Vouillon wrote:
That's an interesting point, actually. What is the right thing to do
when we run out of memory?
- Abort immediately.
This is not very user-friendly.
- Return a special value.
But then we need to check the return value of almost all functions
Hello all,
Hopefully I won't get too burned by flames by jumping into the middle of
the conversation like this.
I recently stumbled across your list talking about ICU and Unicode. I am
not advocating that you should or shouldn't use ICU. Each group has their
own requirements. As a person that
Okay, i've thought things over a bit. Here's what we're going to do
to deal with infant mortality, exceptions, and suchlike things.
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
Sean O'Rourke:
# On Tue, 28 May 2002, Jerome Vouillon wrote:
# That's an interesting point, actually. What is the right
# thing to do
# when we run out of memory?
# - Abort immediately.
#This is not very user-friendly.
# - Return a special value.
#But then we need to check the
I know the technical reason for a new VM, but this could've been a
new
VM for Perl 6 only. What I'd like to know is the motivation to open
up
the architecture and allow for plugable parser, compilers, bytecode
generators / optimizers, ...
snip
I believe that the idea is
Larry Wall wrote:
If we're going to make it a method, however, it's possible that curry
is the wrong popular name, despite its being the correct technical name.
There's really nothing about the word curry that suggest partial
binding to the casual reader. Perhaps we really want something
On Tue, 28 May 2002, Glenn Linderman wrote:
with reads very nicely, but we already have a perl6 precedent,
perhaps... how about reusing when as the method name for currying?
This may not curry favor with Damian, but I suggest
my half = div.when(y = 2);
would declare the subroutine
Luke Palmer:
# Wait, does this have any meaning?:
#
# my half = \div(y = 2)
Call div() with the named parameter 'y' equal to 2, take a reference to
its return value, and store that in half.
# Is backslash even a valid operator for reference anymore? If so, this
# makes sense to me.
I'm
[EMAIL PROTECTED] wrote:
On Tue, 28 May 2002 01:19:25 -0400 Jeff [EMAIL PROTECTED] wrote:
newasm now handles constants, macros, and local labels within. Here's a
Great work!
Thanks.
expansion. Also, they don't expand recursively. '.constant FOO
blahn.constant BAR Hey, .FOO' won't do
Okay, i've thought things over a bit. Here's what we're going to do
to deal with infant mortality, exceptions, and suchlike things.
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
At 5:47 PM -0700 5/28/02, Hong Zhang wrote:
Okay, i've thought things over a bit. Here's what we're going to do
to deal with infant mortality, exceptions, and suchlike things.
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point,
# New Ticket Created by Rocco Caputo
# Please include the string: [netlabs #632]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=632
21:37 Dan We'll need to interface with signals somehow. Getting them
The thread-package-compatible setjmp/longjmp can be easily implemented
using assembly code. It does not require access to any private data
structures. Note that Microsoft Windows Structured Exception Handler
works well under thread and signal. The assembly code of __try will
show you how to
Brent Dax wrote:
Jeff:
# I haven't been tracking assembly speed at all. Keep in mind
# that a perl assembler is only a temporary measure, and it'll
# be rewritten in C eventually. It's only written in Perl so
C or PASM (or Perl 6)? The latter might be better.
PASM is tempting, if only
At 02:42 PM 5/28/2002 -0700, George Rhoten wrote:
Hello all,
Hopefully I won't get too burned by flames by jumping into the middle of
the conversation like this.
Fortunately this list is very low on flammable material. :)
Thanks for the helpful info. One of the concerns with using
an external
We've pretty much settled on div.prebind(y = 2) as the most informative and
least conflictive.
Larry
Hey all,
After finding out that life.pasm only does maybe 1KB per collection, and
Sean reminding me that there's more to GC than life, I decided to create
some pasm files testing specific behaviors.
Attached is what I've been using to test and compare running times for
different GC systems.
34 matches
Mail list logo
