pika-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

First try (was: Re: [Pika-dev] Re: willing to help)


From: Jose A . Ortega Ruiz
Subject: First try (was: Re: [Pika-dev] Re: willing to help)
Date: Mon, 22 Dec 2003 02:29:31 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

hi,

first of all, thanks Tom and Matthew for your advice, which finally
got me started with pika.

i've been reading docs and code (and learning tla,) and finally made a
first attempt at contributing some code, mainly to become familiar
with the project. more concretely, i've implemented hash_fn for
vectors and pairs. it's a very small contribution, hardly worth
noting, but, before going on, i would appreciate if any of you could
take a quick look at it to be sure that i'm on the right path. it is
available at:

Revision: scm--devo--0.1--patch-3
Archive: address@hidden

and it consists mainly on adding a new function (scm_values_hash_acc)
to reps/hash-values-imp.c, and use it in scm_vector_hash_fn and
scm_pair_hash_fn. i've also added tests in separate files
(unit-vector-hash.c and unit-pair-hash.c), rather than modifying the
existing unit-vector.c and unit-pairs.c: is this compliant with our
coding policies? i've observed that 'make test' does not run the new
tests, despite the fact that they're compiled: how do i fix it?

also, i was expecting a reps/vector-impl.[ch] module, but didn't find
it: shouldn't it be there? on a related note, i've observed that reps
uses now and then stuff from libscm, which prevents a clean layering
of both libraries: i was expecting libscm to depend on reps, but not
the other way round, so that we have a nice layered architecture. but
this does not seem to be the case (actually, i've also violated my
proposal when implementing scm_values_hash_acc, but i can easily fix
it): am i missing something?

i was also thinking of implementing the missing
scm_{pair,vector}_equal_fn functions, and actually wrote a first
attempt at scm_vector_equal_fn, but i don't understand the 'issues' in
the FIXME comment: circularity does not seem to be an issue, since
scm_values_equal already tests its arguments using scm_values_eq,
preventing in this way (if i'm not mistaken) infinite recursion when
comparing circular structures (i've in fact tested it for circular
vectors). thus, a very naive impl for vectors that firsts compares
their lengths and, if needed, checks in turn each of their components
using scm_values_equal seems to work--- but then, i don't know what
Tom meant in his comments with the 'interrupts and stack usage'
issues[1]: could you please elaborate on them so that i can try to
provide a robust implementation?

i could also try my hand on reading/writing circular structures. it
seems that the place to handle them is scm_write_value, storing
information about already printed objects in a new field within
scm_write_params (which could be, for instance, a hashmap
t_scm_word * -> index, where the keys are pointers to already printed
objects and the values are indexes for already referenced ones). but i
am probably missing a lot of relevant issues here, am i not?

well, i think that's all by now :) i know that i'm actually wasting
more of your time that my current contributions are worth, but please
bear with me: hopefully, the terms will be inverted as soon as i'm
familiar enough with pika :)

thanks a lot for your help.

cheers,
jao

Footnotes: 

[1]  The actual comment in vectors.c and pairs.c reads:
  /*
   * issues: circular structures, interrupts,
   * stack usage.
   */

-- 
Nature uses as little as possible of anything.
-Johannes Kepler, astronomer (1571-1630)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]