Re: plans
Andreas Rottmann <[email protected]> Tue, 09 Mar 2004 19:30:47 +0100
| Newsgroups | gmane.lisp.scheme.pika.devel |
|---|---|
| Message-ID | <[email protected]> |
Tom Lord <lord-1tv/[email protected]> writes: > 1) basic data structures not having to do with EVAL > > 2) everything having to do with EVAL > > > I would like to focus the project on (1), for now. Jivera has been > experimenting with things for (2) and I encourage that to continue -- > but let's finish up the stuff in (1) before we "officially" move on to > that. > > The tasks in (1) are: > > ~ the missing list and and vector primitives > > Andreas is working for sure on some of these, possibly on others. > I'm sure any of us can take up any slack in this area. This > stuff is pretty straightforward and presents no new issues -- just > a handful of functions to write. > I've now implemented the missing list primitives, you may pick them up from my --integration branch at your convinience. I guess the few vector-related funcs don't warrant a opening a branch for them, if I were to implement them. So would just committing them to --integration be OK? > ~ strings > > We're in very good shape now for rounding out hackerlab's t_udstr > type to provide the basic functionality that we need. > > Basically, t_udstr just has to be wrapped (vtable-style) to make > Scheme strings but there is a catch: > > Strings present some interesting challenges for thread-safety and > async-code safety. I've written a design for how to handle those > issues (the "object-locks" file in ./src/scm/=PLAN). > So, we'd first implement object locks I guess. Most of the stuff would live in reps/, I think, except for the conviniency function. I could go ahead and put this in place (fairly trivial, as they're supposed to be noops ATM). This would result in: * reps/object-locks-imp.[hc]: scm_lock_for_object, scm_unref_object_lock, scm_ref_object_lock scm_acquire_object_locks, scm_release_object_locks * libscm/object-locks.[hc]: scm_lock_objects, scm_unlock_objects Does that look OK? Furthermore, to meet your suggestion about having invariants in place, I think it would be a good idea to already implement reference counting and the boolean locked? flag, even if we don't have asyncs ATM. Regards, Andy -- Andreas Rottmann | [email protected] | 118634484@ICQ | [email protected] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth