or our runloops are wrong
or deep core stuff
All run loops get a pointer to the parrot byte code for execution.
This has several impacts on the runloop itself and on branching and
jumping between instructions.
As parrot PASM jumps are expressed by means of opcodes (absolute or
relative) all ru
Nicholas Clark wrote:
On Wed, Jan 29, 2003 at 02:12:01PM +0100, Leopold Toetsch wrote:
The variable layout of interpreter->code (actually the packfile) doesn't
fit very good for multiple code segments. There is only one ->byte_code
pointer, the byte_code_size is in bytes and converted zig tim
Jonathan Scott Duff wrote:
The solution I advocate is to allow even "primitive" types to hold
undef.
Why do you then use a primitive type in the first place?
IMHO:
1) primitive types are what they are - no undef, no attributes, just
e.g. plain integers (or shorts or bits ...)
2) if you w
On 29 Jan 2003 14:29:52 -0500, Aaron Sherman wrote (in part):
ajs> As for the argument that testing for true non-existentness is a
ajs> burden, check out the way Perl5 does this. Hint: there's a central
ajs> sv_undef, and that's not what array buckets are initialized to
Either you're dead wr
AAron --
I think the point is that C<$x{$foo}> says "Hey C<$x>, y'know that
unordered
mess of stuff you've been keeping track of? Get me the one tagged $foo,
woudja?" while C<$x[$n]> says "yo C<$x>! Grab me the C<$n>-th thingee
in line over there, hey!". And, nothing prevents you wanting to use a
This is just to let everybody know that I will be unsubscribing from
p6-lang for the foreseeable future, effective immediately.
I deeply regret that I simply no longer have the time to cope with the
volume of messages being generated here. Unfortunately, the exigencies of
finding paying work in t
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> Right, we just can't do the 'undef' thing. OK, so let me see if this
> is right yet:
>
> my Int @a is default(2);
> @a[5] = 5;
>
> @a[4]; # 2 (autofilled)
> @a[5]; # 5
> @a[6]; # 2 (out-of-bounds)
>
>
On Thu, 2003-01-30 at 15:38, Damian Conway wrote:
> This is just to let everybody know that I will be unsubscribing from
> p6-lang for the foreseeable future, effective immediately.
I too will be leaving this list, as I'm concerned that my recent
enthusiasm has at least contributed to Damian's wit
On Thursday, January 30, 2003, at 12:49 PM, Austin Hastings wrote:
undef @a[5]; # undefining the element sets it to the default
@a[5]; # 2
@a[5] = undef; # same as above
@a[5]; # 2
undef!!
@a is an array of Int (not int) and can store undef, so no error occurs
Damian Conway:
# This is just to let everybody know that I will be
# unsubscribing from p6-lang for the foreseeable future,
# effective immediately.
I, and I'm sure the rest of the list, am sorry to see you go. Best of
luck with the job hunt and the serious design work.
(I swear, this is the l
(Sorry, deleted Michael's original message, hence this messy quoting
interaction)
On Thu, Jan 30, 2003 at 03:11:34PM -0500, [EMAIL PROTECTED] wrote:
> Shouldn't access to 'is computed' arrays be read-only?
>
> If you want to be able to consume the elements by shifting,
> you can always create a t
On Thu, Jan 30, 2003 at 11:41:04AM -0500, Aaron Sherman wrote:
> On Wed, 2003-01-29 at 16:41, Nicholas Clark wrote:
>
> > And the demonstration was as expected?
>
> Yes, of course. If you modify a hash, or look at another hash, you
> should not expect the same results. Why would you? More importa
On Wed, 2003-01-29 at 16:41, Nicholas Clark wrote:
> And the demonstration was as expected?
Yes, of course. If you modify a hash, or look at another hash, you
should not expect the same results. Why would you? More importantly, why
would the conversation threat up until now lead to such an exampl
On Wed, 2003-01-29 at 17:12, Dan Sugalski wrote:
> At 12:40 PM -0500 1/29/03, Aaron Sherman wrote:
> >Elements of a has ARE ordered, just not the way you may expect.
>
> Just to nip this one in the bud...
The bud was back that-a-way about 3 days
> If people start assuming that there's *any*
On Wed, 2003-01-29 at 17:50, Spider Boardman wrote:
> On 29 Jan 2003 14:29:52 -0500, Aaron Sherman wrote (in part):
>
> ajs> As for the argument that testing for true non-existentness is a
> ajs> burden, check out the way Perl5 does this. Hint: there's a central
> ajs> sv_undef, and that's not wh
Joseph F. Ryan wrote:
> Stéphane Payrard wrote:
> >
> >I think that arrays and associative tables are very
> >different entities for two reasons:
> > -type of keys. array keys are integers
> > -cost of insertion and deletion operations: O(n) and
> > lower for associative table ( O(1) if you do
At 11:41 AM -0500 1/30/03, Aaron Sherman wrote:
On Wed, 2003-01-29 at 17:12, Dan Sugalski wrote:
At 12:40 PM -0500 1/29/03, Aaron Sherman wrote:
>Elements of a has ARE ordered, just not the way you may expect.
Just to nip this one in the bud...
The bud was back that-a-way about 3 days
What was the reason again which Larry rejected unifying the syntax for array
and hash indexing?
Because some things have both, and do different things with each.
And because some built-in redundancy is useful for error checking,
especially on complex nested data structures.
As Piers said, we k
Garrett Goebel <[EMAIL PROTECTED]> writes:
> Joseph F. Ryan wrote:
>> Stéphane Payrard wrote:
>> >
>> >I think that arrays and associative tables are very
>> >different entities for two reasons:
>> > -type of keys. array keys are integers
>> > -cost of insertion and deletion operations: O(n) an
On Thursday, January 30, 2003, at 12:03 AM, Leopold Toetsch wrote:
Why do you then use a primitive type in the first place?
IMHO:
1) primitive types are what they are - no undef, no attributes, just
e.g. plain integers (or shorts or bits ...)
2) if you want to store additional information us
At 9:53 AM -0800 1/30/03, Michael Lazzaro wrote:
This is leading me to the conclusion that primitive-typed arrays
should not be allowed to have defaults, period, and that attempting
to place one should be a compile-time error. If you want a default,
use C instead of an C, and it will work fine
Apologies in advance for beating this dead horse...
Damian Conway wrote:
> Garrett Goebel wrote:
>
> > What was the reason again which Larry rejected unifying the
> > syntax for array
> > and hash indexing?
>
> Because some things have both, and do different things with each.
Ok $0 is special.
Piers Cawley wrote:
> Garrett Goebel <[EMAIL PROTECTED]> writes:
> >
> > What was the reason again which Larry rejected unifying the
> > syntax for array and hash indexing? As Piers said, we know
> > whether $a is an array or hash reference when we do:
> >
> > print $a->{foo};
>
> But as someone
Garrett Goebel <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>> Garrett Goebel <[EMAIL PROTECTED]> writes:
>> >
>> > What was the reason again which Larry rejected unifying the
>> > syntax for array and hash indexing? As Piers said, we know
>> > whether $a is an array or hash reference when w
On Thursday, January 30, 2003, at 09:55 AM, Dan Sugalski wrote:
At 9:53 AM -0800 1/30/03, Michael Lazzaro wrote:
This is leading me to the conclusion that primitive-typed arrays
should not be allowed to have defaults, period, and that attempting
to place one should be a compile-time error.
From: Piers Cawley [mailto:[EMAIL PROTECTED]]
> Garrett Goebel <[EMAIL PROTECTED]> writes:
> >
> > And what's to prevent that collection object from handling:
> >
> > my $queue = SomeQueue.new;
> >
> > $queue.push('foo');
> > $queue.push('bar');
> > $queue.push('baz');
> >
> >
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> On Thursday, January 30, 2003, at 12:03 AM, Leopold Toetsch wrote:
> > Why do you then use a primitive type in the first place?
> >
> > IMHO:
> >
> > 1) primitive types are what they are - no undef, no attributes,
> just
> > e.g. plain integers
Austin Hastings wrote:
There is no reason why primitive-typed arrays can't have a default. It
is the confusion of "default" with "undef" that is causing this
problem.
If I have:
my int @a;
print @a[4];
What comes out?
Notice, there's no "is default(woo-woo)" in there. Just a plain old
primit
On Thursday, January 30, 2003, at 10:56 AM, Austin Hastings wrote:
There is no reason why primitive-typed arrays can't have a default. It
is the confusion of "default" with "undef" that is causing this
problem.
Yes, I misspoke. You can have a default, which it will use for
autofill & out-of-
At 10:54 AM -0800 1/30/03, Mark Biggar wrote:
and if we define a prop "is no_default" then you get what ever
junk happens to be in memory. (this for even more speed)
That's not going to happen. It's too unsafe, and too open to
corruption attacks.
--
Dan
Garrett Goebel wrote:
Ok $0 is special. But isn't it _the_ special case?
Nope. Pretty much any built-in that returns more than a single
piece of information (e.g. C, C, C, etc.)
will do the same kind of thing.
And strictly
speaking, its an ordered associative array right? It doesn't really n
For C arrays, things get more complicated. Since there
are no true 'holes' in a primitive-typed array, the correct behavior
there would seem to be to autofill the array using the computed values.
For example, an empty array:
my int @a is computed { $^index ** 2 }
@a[2]; # 4 (doesn
On Thu, Jan 30, 2003 at 09:11:10AM -0800, Damian Conway wrote:
> >What was the reason again which Larry rejected unifying the syntax for
> >array
> >and hash indexing?
>
> Because some things have both, and do different things with each.
> And because some built-in redundancy is useful for error
On Thu, 2003-01-30 at 13:13, Garrett Goebel wrote:
> Hmm... $0[$!]
>
> However isn't that something the collection object should have to deal with?
> It seems like such nice thing to unify collection syntax.
Actually, that's a great example, and there are certainly others.
According to Larry, t
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> > What was the reason again which Larry rejected unifying the syntax
> for array
> > and hash indexing?
>
> Because some things have both, and do different things with each.
> And because some built-in redundancy is useful for error checking,
> espec
> X-Original-To: [EMAIL PROTECTED]
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> From: Garrett Goebel <[EMAIL PROTECTED]>
> Date: Thu, 30 Jan 2003 12:13:22 -0600
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
> --_=_NextPart_001_01C2C88B.468ED3D0
> Content-Type: tex
A little blue-sky, here...
> > And strictly
> > speaking, its an ordered associative array right? It doesn't really
need
> > the full range of expression offered by $0{...} and $0[...]. All it
> > needs is $0[1] for ordered lookups and $0["1"] for named lookups.
>
> Nope. The array aspect retu
On Thu, 2003-01-30 at 14:21, Damian Conway wrote:
> People, the whole argument that $a[key] should be a homonym for both
> array-like and hash-like look-ups is
... a really bad argument to have, and I would not presume. When Perl
has tried to unify syntax in that way, it has ultimately failed (a
Shouldn't access to 'is computed' arrays be read-only?
If you want to be able to consume the elements by shifting,
you can always create a tied object that kees a cursor and
a reference to the underlying array and gives you that
access (and it could die for splicing, etc.)...
Regards,
-- Gregor
On Wednesday 29 January 2003 09:52 pm, Rick Delaney wrote:
> On Wed, Jan 29, 2003 at 01:54:10PM -0800, Michael Lazzaro wrote:
> > On Wednesday, January 29, 2003, at 12:38 PM, Smylers wrote:
> > > That would make the rule very simple indeed:
> > >
> > > Assigning C to an array element causes that
On Thursday 30 January 2003 06:49 pm, Andrew Rodland wrote:
> On Wednesday 29 January 2003 09:52 pm, Rick Delaney wrote:
> > On Wed, Jan 29, 2003 at 01:54:10PM -0800, Michael Lazzaro wrote:
> > > On Wednesday, January 29, 2003, at 12:38 PM, Smylers wrote:
> > I'd also like to point out that ruby h
[EMAIL PROTECTED] wrote:
Shouldn't access to 'is computed' arrays be read-only?
In general, I would hope that 90% of them would be, but it's been
stated that it won't be a requirement. But hey -- note that, for
starters, this would mean that you could easily use an array for
caching things
Garrett Goebel <[EMAIL PROTECTED]> writes:
> From: Piers Cawley [mailto:[EMAIL PROTECTED]]
>> Garrett Goebel <[EMAIL PROTECTED]> writes:
>> >
>> > And what's to prevent that collection object from handling:
>> >
>> > my $queue = SomeQueue.new;
>> >
>> > $queue.push('foo');
>> > $que
Michael Lazzaro wrote:
[EMAIL PROTECTED] wrote:
Shouldn't access to 'is computed' arrays be read-only?
In general, I would hope that 90% of them would be, but it's been stated
that it won't be a requirement.
If you want such 'is computed' thingy, then tie it or wrap it in your
own -
Leopold Toetsch wrote:
static void cvt_num12_num8(unsigned char *dest, unsigned char *src)
[...]
I have committed the changes to packfile.c. As the tinderboxen seem to
be the ultimate testers, they'll tell if it works :)
And please: read the comment in t/native_pbc/number.t
TIA
leo
45 matches
Mail list logo
