Use Hash instead of PerlHash for properties
* Parrot should only use core types
* prophash now returns PMCNULL, if there aren't any properties
this is necessary, because introspection (dump) would inject a
property hash into all dumped PMCs
* adjust dumper tests and Dumper.pir
leo
Jeff Clites wrote:
Okay, that makes sense then. So is the current implementation
incomplete? I ask because it looks like the mark functionality won't yet
quite deal with non-PObj values, etc.
The mark_key (and hash, compare) functions can be passed to the extended
new_hash_x() creation functio
On Nov 6, 2003, at 11:56 PM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
An alternative (which may or may not a good one) would be to say that
you can never actually store a NULL in a hash
Not good. The Hash (now) may take almost arbitrary key/value pairs.
Value can be plain int
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Attached patch implements this. Furthermore it implement hash_exists.
> It does not break more tests than previously.
> Is this ok to commit?
Yes for me. While touching these files, you could rename HASH{,BUCKET}
too to ucfirst lc $_.
Thanks,
leo
Leopold Toetsch <[EMAIL PROTECTED]> writes:
[...]
> > void * hash_get(Interp * interpreter, HASH *hash, void *key);
> > HASHBUCKET * hash_get_bucket(Interp * interpreter, HASH *hash, void *key);
>
> That's ok for me. For all of the "normal" Hash usage, we don't have NULL
> values, so there is no
Jeff Clites <[EMAIL PROTECTED]> wrote:
> An alternative (which may or may not a good one) would be to say that
> you can never actually store a NULL in a hash
Not good. The Hash (now) may take almost arbitrary key/value pairs.
Value can be plain ints ...
> JEff
leo
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Yes this is a problem. I did a little research how other libraries
> solve this problem. Oh man, there are many of them.
"little" :)
BTW, inside parrot:
$ find . -name '*.c' | xargs grep hash_get
and you'll see another hash implementation.
> void
On Nov 6, 2003, at 10:05 AM, Juergen Boemmels wrote:
But I still have one problem: hash_put and hash_get are not
symmetric. hash_put puts a void *value, but hash_get returns a
HASHBUCKET. This looks wrong to me.
When returning the value directly, we couldn't have NULL value's - or
better NULL valu
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> > Hi,
>
> > the latest changes of HASH in src/hash.c makes t/src/hash.t fail
> > badly.
>
> Oops, sorry (but at least it isn't the only broken test currently :)
I committed a partial fix. Now the tests a
Hi,
the latest changes of HASH in src/hash.c makes t/src/hash.t fail
badly. It did not even compile because of the prototype change in
hash_new. Ok that was easy to fix and I have already a fix in my tree,
which at least compiles cleanly.
But I still have one problem: hash_put and hash_get are no
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Hi,
> the latest changes of HASH in src/hash.c makes t/src/hash.t fail
> badly.
Oops, sorry (but at least it isn't the only broken test currently :)
> But I still have one problem: hash_put and hash_get are not
> symmetric. hash_put puts a void *valu
In message <[EMAIL PROTECTED]>
Nathan Torkington <[EMAIL PROTECTED]> wrote:
> Tom Hughes writes:
> > I must admit it had never occurred to me that somebody might
> > deliberately use keys or values to achieve that, but I guess
> > somebody might be relying on it without realising it.
>
In message <[EMAIL PROTECTED]>
Jerrad Pierce <[EMAIL PROTECTED]> wrote:
> >As far as I can tell reset %x currently tries to reset any
> >variables which start with either % or x even though no variable
> >can start with %...
>
> ~/perl
> ${"%percent"} = "Quoth the raven";
> print ${"%pe
>As far as I can tell reset %x currently tries to reset any
>variables which start with either % or x even though no variable
>can start with %...
~/perl
${"%percent"} = "Quoth the raven";
print ${"%percent"}, "\n";
reset("%");
print ${"%percent"}, "\n";
Quoth the raven
Sure looks like it starts
Tom Hughes writes:
> I must admit it had never occurred to me that somebody might
> deliberately use keys or values to achieve that, but I guess
> somebody might be relying on it without realising it.
while (($k,$v) = each %foo) {
last if ...;
}
keys %foo;# reset the iterator
w
In message <[EMAIL PROTECTED]>
Nathan Torkington <[EMAIL PROTECTED]> wrote:
> Resetting an each() should be done in some other way than calling
> keys() or values(). Perhaps reset(%hash)? I'm subfond of the current
> reset() semantics (symbol table crackheadery + single-match regexp
>
>Tom Christiansen writes:
>> But %hash->BUCKET_USE() should return what's currently there.
>Do you really use this information? Really? I have no objection
>to supplying a way to discover it, but this might even be in an
>external module rather than built into the language given how rarely
>it'
Tom Christiansen writes:
> But %hash->BUCKET_USE() should return what's currently there.
Do you really use this information? Really? I have no objection
to supplying a way to discover it, but this might even be in an
external module rather than built into the language given how rarely
it's used
>I was against the idea of hash context, but I'd love it if:
> foreach ($k,$v) (%hash) {
>...
> }
I'd like for Perl to emit a warning if people try
for (%hash)
or its aliases. That is, if a foreach loops sole content is
a %{...} at compile time, grinch.
--tom
>%hash in scalar context should return what scalar(keys(%hash))
>currently does.
But %hash->BUCKET_USE() should return what's currently there.
And a simple boolean (read: don't care) use shouldn't waste time
looking for keys, really, but should be internally optimized to do
the current reasonabl
(I'm going to RFC these if nobody presents any killer complaints about
them, it's just that writing RFCs is more work than I want to go through
for tiny little changes like these, especially if they turn out to be
dumb).
%hash in scalar context should return what scalar(keys(%hash))
currently doe
21 matches
Mail list logo
