Of course, this fails to account for the fact that different compilers can order a struct differently in memory, but ucl-ffi deliberately attempts to provide only the lowest-level functionality. Eventually I hope to have time to write a high-level FFI which will generate accessor functions for structs, but that would obviously require a C compiler, plus install hooks and executable dependencies for the package system.

Also, Racket doesn’t allow you to get an R6RS REPL, as far as I know. What you’ll need to do is start the ordinary racket REPL and import it using the Racket ‘require’ statement as ‘(require (lib “ucl/install.sls”))’.

I hadn’t heard of the r6rsgambit package. I’ll give it a try and see if it’s complete enough to add a backend for that.

Also, the simple (import (ucl install)) expression works in ypsilion (SVN build) for me, but I couldn’t figure out how to get it to work through a REPL in racket. If someone could post an example that would be great.

My own scheme implementation of choice, gambit-c, doesn’t have excellent support for r6rs it seems. Have you tried getting the r6gambit package to work with UCL yet?

Thanks for the help. I really like your project.

Have you looked at Descot?

http://descot.sacrideo.us/about.xhtml

I had not heard of Descot before, and am now reading up on it. My initial impression is that it simply seems more complicated than it really needs to be.

I like the idea of having servers automatically update each other to mirror package info, but this seems to necessitate a long-running server process, which I don’t like because it makes it harder to run a repository on a shared web host.

I don’t entirely understand the use of RDF, as it pulls in pages and pages of specifications where I believe a simpler flat-file association-list data model is a lot easier to query and to reason about. Maybe I’m missing some portion of the documentation where the reasoning for this is explained.

Ultimately, I like the idea of making the repositories automatically distribute packages among themselves, but I am doubtful of whether this convenience would be as appreciated by the average user. It seems likely that most users would prefer to only upload to and download from a single favorite server anyway, so I don’t entirely see what we gain in convenience by decentralizing it.

Also, after reading through the technical documentation, I’m still left not actually knowing how one creates a package for Descot, which is excusable given the alpha status of the project, but does not entirely reassure me either.

why don’t you join forces with Marco Maggi ?
Have you talked to him ?
It’s a good idea because it’s really needed, but it makes no sense if people are doing things their separate ways

I had written the portability libraries before I knew about his project, and the install procedure for his code turned me off from trying to use that as a base for the package manager (I am not a fan of autotools). Once I knew about his work, I figured it would be better to finish up the code I was working on before trying to negotiate any joint efforts.

Also, the FFI interface functionality in Nausicaa is more or less a superset of UCL FFI, so it should be easy enough to port everything to that if and when we get the packaging worked out.

Anyway, I have emailed him about the possibility of repackaging some of the code for UCL, now I’m just waiting on a response.

Have you looked at Descot?

http://descot.sacrideo.us/about.xhtml