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 straightfo
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.
Wh
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, b
> 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
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;
> PARROT_str_loca
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
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!
>expansion. Also, they don't expand >recursively. '.constant FOO
>"blah"n.constant BAR "Hey, .FOO"' won't do what >you want, sadly.
Thats ex
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
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 ma
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 impossib
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 funct
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 ac
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, ...
> >
> >
>
> I believe that
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 som
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 th
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 s
[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
> >"blah"n.constant BAR "Hey
> 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 w
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 thi
# New Ticket Created by Rocco Caputo
# Please include the string: [netlabs #632]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=632 >
21:37 We'll need to interface with signals somehow. Getting them
properly disp
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.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parr
> >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
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
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 extern
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. It's
Larry Wall wrote:
> We've pretty much settled on &div.prebind(y => 2) as the most informative and
> least conflictive.
and I'll demonstrate it in my next Conway Channel diary entry later today.
Damian
# New Ticket Created by Mike Lambert
# Please include the string: [netlabs #634]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=634 >
Peter recently submitted a patch to RT that uses a linked-list for free
headers. Here
38 matches
Mail list logo
