> Since we're never freeing any memory, it continually is allocating a block
> of size 56 (memory pool) + 1 (character) from the underlying system api.
Note that Parrot_alloc_new_block will allocate a minimum of DEFAULT_SIZE
(set in config.h; currently 32768),
so this situation is not quite as b
I've been thinking about this a bit, especially as I play catchup
with a few weeks of p6i mail. Here's my current thinking.
1) COW is useful and trivial in those cases where the original string
data is immobile. Constants, for example, or mmapped files.
$foo = "bar";
$foo _= "baz";
2)
Okay, we're finally hitting the DOD sweeps, and they're starting to
cause some trouble. As I see it there are a few ways we can keep
embryonic PMCs and Buffers from getting collected before they're
fully created and anchored:
1) Set the immortal flag on them until they're fully created
2) Set
At 11:12 AM +0100 1/2/70, James A Duncan wrote:
>Morning (BST) all,
>
>I've started work on B::Parrot, which is a Perl 5 to Parrot
>translation engine. Its very basic at the moment, but I've got it
>successfully translating things like:
>
>my $perliv = 10;
>my $perlpv = "\n";
>print $perliv;
>p
At 5:06 PM -0500 3/31/02, Michel J Lambert wrote:
>A second approach is to throw out this weird transmogrifying class stuff,
>and just construct a new PMC of the appropriate type to put into the
>destination register. Why would we *ever* care what's in the destination
>register, since it never get
At 6:07 PM -0500 4/4/02, Melvin Smith wrote:
>I also remember there was work already in progress, Simon Cozens mailed
>out a tokenizer and I recall Damian Conway saying he was going to deliver
>a parser (maybe I'm confused as I often am)? I assume this could be reused,
>else we end up with 2 archi
At 12:32 PM -0800 4/2/02, Steve Fink wrote:
>With the following comment:
>
> - Changes KEY to contain a KEY_PAIR* instead of a KEY_PAIR**
This patch is a cool thing, and I'm very glad it's in. Getting hashes
working should be pretty straightforward soon.
One thing for the next round of patches
At 10:25 AM -0500 4/2/02, Jason Gloudon wrote:
>On Tue, Apr 02, 2002 at 01:33:59AM -0500, Michel J Lambert wrote:
>
>> If instead, registers are aliased onto traditional memory variables, such
>> that a PMC pointed to by a register is *also* pointed to by a stash
>> somewhere, then it's a bit h
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 11:12 AM +0100 1/2/70, James A Duncan wrote:
>>Morning (BST) all,
>>
>> I've started work on B::Parrot, which is a Perl 5 to Parrot
>> translation engine. Its very basic at the moment, but I've got it
>> successfully translating things like:
>>
>>my
Dan Sugalski:
> At 6:07 PM -0500 4/4/02, Melvin Smith wrote:
> >I also remember there was work already in progress, Simon Cozens mailed
> >out a tokenizer and I recall Damian Conway saying he was going to deliver
> >a parser (maybe I'm confused as I often am)? I assume this could be reused,
> >els
> >destination register. Why would we *ever* care what's in the destination
> >register, since it never gets it's vtable methods called.
>
> That's not true. The destination needs its set method called.
> Otherwise tying/overloading won't work right.
Fair enough. I still have the problem brought
# Keep in mind there is the primitive STRING type which is the S* registers,
# and then there is the PMC (PerlString) which uses vtables.
I am refering to the parrots internal strings e.g. S*
the vtable I am refering to is the 'encoding' vtable of functions in
the string struct (*STRING).encodi
> But suppose you want all .foo to refer to self and not
> to the current topic.
What about
given (self) { }
Also, what about
use invocant;
resulting in all method bodies in scope getting an implied
surrounding given (self) { }.
And what about 'me' or 'i' instead of 'self'?
Me <[EMAIL PROTECTED]> writes:
>> But suppose you want all .foo to refer to self and not
>> to the current topic.
>
> What about
>
> given (self) { }
>
> Also, what about
>
> use invocant;
>
> resulting in all method bodies in scope getting an implied
> surrounding given (self) { ...
> So, I think #2 is the way to go. We'll add a new flag,
> (BUFFER|PMC)_stay_of_execution_FLAG or something, that gets added to
> allocated PMCs and Buffers. It'll be treated the same way as the
> constant/immortal flag is treated for DOD purposes, with one
> difference--there'll be an op which sp
I don't think we are in a position yet to prove much of anything as regards
real-world Perl programs, but just one data point as an example - using
examples/assembly/life.pasm (changed to 5000 generations)
[Pentium 166MHz; linux 2.2.18]
Clean CVS checkout (time averaged over 3 runs)
On Mon, 2002-04-08 at 20:39, Larry Wall wrote:
> Aaron Sherman writes:
> : If {} goes away in Perl6, then everything you've heard about Perl6 being
> : "not really all that different from Perl5" is either a lie or a damned
> : lie. People keep saying "it's just Perl5, but instead of syntax X, you
> If the new, spiffy features of Perl6 are out of my reach that 60-80% of
> the time, and I have to use "perl5compat -nle ...", then the usefulness
> of this new language will be largely lost on me.
I'm not sure I follow. What hypothetical features are you talking about
here? From what I've seen
EHLO again folks:
Hope all is well with you all. I believe I will take the old parrot out
of the cage today, so I need to see what you guys were wanting along the
lines of the format string processing. I was thinking of a similar
version to perl5's 'dummed down' format strings. what all must
if ($a = "\04") {
my only question with doing away with '{' and '}' are dealing with
issues of automagical stringification/number conversion with different
types of the same name. would this be an issue?
would $a be the 5th element of
$ambig[$a] or would it be the "\04" key to $ambig[$a]
PS I do
Aaron Sherman:
> perl -MNet::Ping -nle 'print "Ghost DHCP lease: $1"
> if /lease\s+(\d\S+)/ &&
> ! Net::Ping->new("icmp")->ping($1)' \
> /var/state/dhcp/dhcpd.leases
This becomes
perl -MNet::Ping -nle 'print "Ghost DHCP lease: $1"
if /lease\s+(\d\S+)/ &&
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> On Tue, Apr 09, 2002 at 04:17:38PM +0100, Simon Cozens wrote:
>> Aaron Sherman:
>> >nice du -a | sort -n | tail -300 | tac | perl -nle '
>> >die "Require non-zero disk size!\n" unless $ENV{DF};
>> >if ($. == 1) {
>> >
Simon Cozens <[EMAIL PROTECTED]> writes:
> Piers Cawley:
>> Well, no. Because Perl 6 is specified as behaving like perl 5 until
>> told different. Which means that the first translation you give would
>> be a syntax error.
>
> Ouch. Guess I need to go reread A1. Anyway, that makes it easier -
>
Me writes:
: > But suppose you want all .foo to refer to self and not
: > to the current topic.
:
: What about
:
: given (self) { }
That wouldn't have the same effect as what we're talking about--it'd be
overruled by any C within. We're talking about how to make .foo
mean self.foo reg
Ok now Im paranoid . . . . .
If I set BUFFER_immobile_FLAG during a string_make to allocate a
temporary string that must be manipulated through the body of a function
will the GC leave it alone? if not what must I do? where is this
immune/immortal/gc_cant_touch_me_yet flag?
Roman
On Tue, 9 Apr 2002, Roman Hunt wrote:
# Ok now Im paranoid . . . . .
# will the GC leave it alone? if not what must I do? where is this
# immune/immortal/gc_cant_touch_me_yet flag?
disregard my last message I now realize that gc wont stop at my STRING's
as I must maintain temporary INTVAL's and
Larry Wall <[EMAIL PROTECTED]> writes:
> Me writes:
> : > But suppose you want all .foo to refer to self and not
> : > to the current topic.
> :
> : What about
> :
> : given (self) { }
>
> That wouldn't have the same effect as what we're talking about--it'd be
> overruled by any C with
Melvin Smith wrote:
> At 10:30 PM 4/8/2002 -0700, Robert Spier wrote:
>>> Keep track of global (or interpreter local) scope with a macro
>>> upon entry.
>> I shudder every time someone says "macro" on p6i.
>> perl5 has several thousand macros defined. (grep for ^#define) (over
> Are you counting
Simon Cozens wrote:
>
> Piers Cawley:
> > Well, no. Because Perl 6 is specified as behaving like perl 5 until
> > told different. Which means that the first translation you give would
> > be a syntax error.
>
> Ouch. Guess I need to go reread A1. Anyway, that makes it easier -
> then there needs
29 matches
Mail list logo
