This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
mike@olan.com writes: > Jim Blandy <jimb@red-bean.com> writes: > > > Okay, so here's the $64k question: > > > > Do you want all of "the basic machine types" available for use in > > uniform arrays? > > > > Or do you want all of "the types corresponding to the C and FORTRAN > > types" available? > > > > That is, what do you want to specify in your Guile code --- 64-bit > > IEEE float, or "whatever a C `double' is on this machine"? > > Dunno about Clark, but I want the latter. > > > Is the purpose to mesh with libraries written in C or FORTRAN, or to > > have exact control over the bytes? > > I think that co-existing nicely with C is the purpose of Guile. So > having "more" control on bytes than C or FORTRAN on the same > architecture whould be pointless and, um, surprising. But you need it for some non-computational uses of uniform arrays, particularly if you want to use uniform-array-read! and uniform-array-write to generate binary files, but you want them in a format portable between architectures. I think the right answer is that you might want either a C `int' or exactly a 32-bit quantity. Actually, if you want to be portable you also care about endianness, so maybe uniform array operations are not the best basis for binary I/O. > > > I would also find it very useful if there were a way to get guile to > > > treat a region of memory as a uniform array (and not try to GC the > > > memory block). This would let me attach to large chunks of memory > > > allocated by other packages. > > > > Should Guile call a hook associated with the array to free its space? > > I can't think of exact reasons to shout "NO!", but that is what I want > to do. When things start to smell like C++, I get wary, > > I think Guile should have the concept of "indirect" uniform vectors. > These can appear in several situations: a pointer to something managed > by C, a sub-vector of an existing vector, or as a "handle" to a > vectored field of a record (heh, I had it all working here and then > broke it :-(). > > In all the above situations, Guile's GC should have no control over > the indirect vector. > Hmm, that solves the cases of "the array must free the momory" or "the array must not free the memory", but what about more complicated situations, where e.g. the array memory is part of some bigger data structure and this is the only reference to it, so you want to free it when the array gets GC'd? - Maciej