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
11 matches
Mail list logo
