review/merge request: wip-array-refactor
Hi all,
I've finished up my refactor of Guile's arrays. To my eye it's much
nicer now.
The only bits I could anticipate being controversial would be the last
two or three patches, in which bytevectors are given an "element type"
field. This is so that I can make the srfi-4 uniform vector code use
bytevectors as their representation -- it's one less orthogonal type
that the VM would have to deal with.
Those patches also allow uniform vectors of one type to be accessed
using accessors for other types:
(u8vector-ref #u32(#x) 0) => 255
Although:
(u8vector? #u32(#x)) => #f
But:
(bytevector? #u32(#x)) => #t
Anyway, logs are here, in chronological order. Let me know what you
think. Make check should pass at each of these patches. This is on the
"wip-array-refactor" branch, which I had been rebasing, but I don't plan
to rebase it again.
Andy
commit 86d88a223c64276e7cd9b4503e7e2ecca5aae320
Author: Andy Wingo
Date: Thu Jul 16 21:51:47 2009 +0200
remove deprecated functions from unif.c
* libguile/unif.h:
* libguile/unif.c: Remove deprecated functions.
* module/ice-9/deprecated.scm: Remove array-related deprecated
functions.
* NEWS: Update.
commit 4b126598445c4f12c0aebca2adfaa45f3edd86ab
Author: Andy Wingo
Date: Thu Jul 16 22:02:25 2009 +0200
remove convert.{c,i.c,h}
* libguile/convert.c:
* libguile/convert.h:
* libguile/convert.i.c: Remove these functions, which were undocumented,
not in the libguile/ header, and thus unlikely to have been used.
commit a4a0d399c877cb802cdaf2c48713d3377a412c4f
Author: Andy Wingo
Date: Thu Jul 16 22:15:04 2009 +0200
clean up libguile/Makefile.am
* libguile/Makefile.am: Clean up some of the file lists, should make
future diffs easier to parse.
commit b6149d8d9f35c8091a31b12fb3aeecee0e3a470c
Author: Andy Wingo
Date: Fri Jul 17 00:16:43 2009 +0200
rename scm_i_make_ra to scm_i_make_array
* libguile/unif.c (scm_i_make_array): Rename from scm_i_make_ra. All
callers changed.
commit 5d1b3b2db9349b615baac313ae5a111fa68573ac
Author: Andy Wingo
Date: Fri Jul 17 00:25:49 2009 +0200
rename ramap.[ch] to array-map.[ch]
* libguile/array-map.c:
* libguile/array-map.h: Rename from ramap.c and ramap.h.
* libguile.h:
* libguile/Makefile.am:
* libguile/eq.c:
* libguile/init.c:
* libguile/sort.c:
* libguile/unif.c:
* libguile/vectors.c: All referrers changed.
commit c53c0893a3bad3312230003707f71c2f441460d4
Author: Andy Wingo
Date: Fri Jul 17 00:47:31 2009 +0200
parts of unif.[ch] to array-handle.[ch]
* libguile/array-handle.c:
* libguile/array-handle.h: Move some parts of unif.c and unif.h to these
new files.
* libguile/unif.c:
* libguile/unif.h: Update includers. Since unif.h depends on the array
handle type, we include array-handle.h, which also means that there
will be no difference for our callers.
* libguile/init.c: Call scm_init_array_handle, though it does nothing as
of yet.
* libguile/Makefile.am: Adapt for new files.
commit cf396142405d9076cc20eca9bf53376e80359a56
Author: Andy Wingo
Date: Fri Jul 17 00:58:32 2009 +0200
bitvector exodus from unif.[ch]
* libguile/Makefile.am:
* libguile/unif.c:
* libguile/unif.h:
* libguile/bitvectors.c:
* libguile/bitvectors.h: Move bitvector functionality out of unif.[ch].
* libguile/array-handle.c:
* libguile/array-map.c:
* libguile/init.c:
* libguile/read.c:
* libguile/srfi-4.c:
* libguile/vectors.c: Oh, what a tangled web we weave...
commit 2fa901a51f62da8a01112aefbf687530f4bff160
Author: Andy Wingo
Date: Fri Jul 17 01:08:35 2009 +0200
rename unif.[ch] to arrays.[ch]
* libguile/Makefile.am:
* libguile/unif.c:
* libguile/unif.h:
* libguile/arrays.c:
* libguile/arrays.h: Rename unif.[ch] to arrays.[ch].
* libguile.h:
* libguile/array-handle.c:
* libguile/array-map.c:
* libguile/bitvectors.c:
* libguile/bytevectors.c:
* libguile/eq.c:
* libguile/gc-card.c:
* libguile/gc-malloc.c:
* libguile/gc-mark.c:
* libguile/gc.c:
* libguile/init.c:
* libguile/inline.h:
* libguile/print.c:
* libguile/random.c:
* libguile/read.c:
* libguile/socket.c:
* libguile/sort.c:
* libguile/srfi-4.c:
* libguile/srfi-4.h:
* libguile/strports.c:
* libguile/vectors.c:
* libguile/vectors.h: Update includers.
commit 2a610be59412a9d633a373c6f6ec4d4794c40fd8
Author: Andy Wingo
Date: Sun Jul 19 15:04:40 2009 +0200
add generic array implementation facility
* libguile/array-handle.c (scm_i_register_array_implementation):
(scm_i_array_implementation_for_obj): Add generic array facility,
which will (in a few commits) detangle the array code.
(scm_array_get_handle): Use the generic arra
Re: string_abstraction2 review
On Thu, 2009-06-11 at 23:12 +0200, Andy Wingo wrote: > Howdy good sir! > I'm back on task. I'll go through your comments from the review of a month or so ago, and try to push the Unicode stuff next week. Things seem stable on my end, but, some optimization work remains to be done. With respect to srfi-14 and char-sets, I wrote a new, Unicode capable, one. It is a big change, though, which might make some uneasy. It is in C for now, but, it certainly could go pure scheme at some point. Using what I learned from writing the C version, I have a half-completed version of the same in scheme as well. The only necessary action item remaining on my srfi-14 is to hardcode the standard char sets instead of populating them at startup, which takes a non-trivial amount of time. Thanks, Mike
Re: %nil once again
Daniel Kraft writes: >>> scheme@(guile-user)> (null? %nil) >>> #f >>> scheme@(guile-user)> (equal? %nil (cdr (list 1))) >>> #f >> >> I believe those work in the interpreter, and so are VM bugs. Can you >> check that with ,o interp #t ? > > The first one is indeed #t with the interpreter, the second one > not. But unfortunatly I think that the elisp equivalent of > > (equal?/eqv?/eq? (cdr (list 1)) nil) > > (don't know which predicates take the place of eq?/eqv?/equal? in elisp yet) > should indeed yield true, as a perfectly valid way to check for (null? (cdr > (list 1))), right? So it seems that in this case even the Guile interpreter > does not handle empty lists as it should for elisp -- > or don't we need to ensure that test is true? Hm, interesting point. Is it a problem in practice though? If so, what is the practical context? i.e. is there a lot of existing code that uses (equal ... nil) to test for the end of a list, rather than (null ...) ? > So no need for ensuring myself that > all '()'s get replaced by %nil's? I would say not - because much of the existing Scheme/Elisp design is based on _not_ having to translate data as it passes between languages. Or, to put it another way, if we think that we _do_ have to accept translating data, I think we could remove lots of special Elisp support from the libguile core. Regards, Neil
Re: updated NEWS, release tomorrow
l...@gnu.org (Ludovic Courtès) writes: > Hey! > > Andy Wingo writes: > >> All summer? I'm in France frequently. Perhaps one day we should meet up! That would be great. I'm in the Pyrenees, near Lourdes, from now until 31st July, and from 11th August until 4th September. And in the missing period - since I believe you have Spanish connections, Andy - I'll be near Valencia. > I'm frequently there, too, so I'd be happy to join in! Of course! > Perhaps we should set up a GNU Guile Hackers Meeting (G²HM) by the time > 2.0 is released? If it works for everyone, why not? Neil
Re: %nil once again
Hi Neil, Neil Jerram wrote: Daniel Kraft writes: scheme@(guile-user)> (null? %nil) #f scheme@(guile-user)> (equal? %nil (cdr (list 1))) #f I believe those work in the interpreter, and so are VM bugs. Can you check that with ,o interp #t ? The first one is indeed #t with the interpreter, the second one not. But unfortunatly I think that the elisp equivalent of (equal?/eqv?/eq? (cdr (list 1)) nil) (don't know which predicates take the place of eq?/eqv?/equal? in elisp yet) should indeed yield true, as a perfectly valid way to check for (null? (cdr (list 1))), right? So it seems that in this case even the Guile interpreter does not handle empty lists as it should for elisp -- or don't we need to ensure that test is true? Hm, interesting point. Is it a problem in practice though? If so, what is the practical context? i.e. is there a lot of existing code that uses (equal ... nil) to test for the end of a list, rather than (null ...) ? honestly, I don't know (but think in practice null shoud be used). So no need for ensuring myself that all '()'s get replaced by %nil's? I would say not - because much of the existing Scheme/Elisp design is based on _not_ having to translate data as it passes between languages. Good, that sounds reasonable and is also what I suggest. If we are one day able to actually run existing elisp code through Guile, we'll find out if anything needs to be changed in order to get a usable implementation anyways. BTW, I implemented also the function bindings of symbols using this fluid-based dynamic scoping at the moment -- but on second thought, there's no scoping at all for function slots (all are global), is there? If this is true, we can get rid of this complication here and use the symbols in (language elisp runtime function-slot) directly without indirection via the fluids. Yours, Daniel PS: Current status update (should mainly be pushed already): Yesterday I implemented compiler handling of backquoting and a lot of new built-ins (mainly list stuff like cons, car/cdr or number-sequence). Currently I'm working on some "derived" control-structures (prog1, prog2, when, unless, dotimes, dolist), and then a lot of the basic stuff will already be in place. However, there isn't yet a real elisp-reader, so maybe this is the next big project (but I can try to make use of the existing patches). -- Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz To go: Hea-Kni-Mon-Pri
Re: array handles and non-local exits
l...@gnu.org (Ludovic Courtès) writes: > Hey, > > Andy Wingo writes: > > [...] > >> You can't just write functions that return values, you have to contort >> code to store temporaries and then release and then return. You have >> to write paired statements. If you call a user function, you really >> should set up a dynwind, which conses, and contorts your code even >> further. > > Right, that one has to set up a dynwind for nothing sucks. > >> Array_handle_release is a bad idea. > > Fair enough. FWIW, I agree (I think with both of you) that `we might need it in future' is not a good argument, but that API compatibility is. > The doc would need to be revised (again). > > (It would have helped in this discussion if we knew the rationale for > this API. I couldn't find any trace of discussions around it.) I'm pretty sure it was about allowing C code to efficiently access and modify uniform vector contents, but at the same time supporting operations which might require the underlying storage to be reallocated. The latter operations could include enlarging an existing vector, or copy-on-write. But AFAICT we never implemented either of those ideas, and the existing code never changes the underlying storage of a vector. Regards, Neil
Re: %nil once again
Daniel Kraft writes: > Good, that sounds reasonable and is also what I suggest. If we are > one day able to actually run existing elisp code through Guile, we'll > find out if anything needs to be changed in order to get a usable > implementation anyways. Agreed. > BTW, I implemented also the function bindings of symbols using this > fluid-based dynamic scoping at the moment -- but on second thought, > there's no scoping at all for function slots (all are global), is > there? No, I don't think there is. `let' can't operate on function slots. Regards, Neil
Re: %nil once again
On Jul 19, 2009, at 16:10, Neil Jerram wrote: BTW, I implemented also the function bindings of symbols using this fluid-based dynamic scoping at the moment -- but on second thought, there's no scoping at all for function slots (all are global), is there? No, I don't think there is. `let' can't operate on function slots. Not in the main emacs lisp implementation. However, cl-macs.el provides an "flet" macro that does work on function slots; it uses the "letf" macro which expands to include a use of unwind-protect to do its dirty work. Ken
