87fy8de4i7.fsf_-_@lalune.planetill.net 5868D729-CDBB-4C33-9C47-CC5D014AAF83@iro.umontreal.ca From: Alexander Sepp alexander.sepp@student.uni-augsburg.de Date: 19 Mar 2007 17:47:02 +0100 In-Reply-To: 5868D729-CDBB-4C33-9C47-CC5D014AAF83@iro.umontreal.ca Message-ID: 87y7lti3jt.fsf_-_@lalune.planetill.net Lines: 58 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii
Marc Feeley feeley@iro.umontreal.ca writes:
hi,
- Signature handling
afaics, every file in a snowball archive has it's own signature. why is this the case? wouldn't it be cleaner (and simpler) to provide the signature over the complete snowball archive itself? the problem is, that if i can not verify the origin of a tarball, i do not even want to untar it.
The snowball structure is designed so that a package's parts can be contributed, and signed, by different people. For example someone may be working on the Bigloo port while someone else is working on a Gambit port. The maintainer can then collect these (separately signed) parts and just drop them into the package directory, then upload the package.
Shouldn't this be handled by a source code management tool?
I do not want a cert for each developer contributing to snow. Imagine you would have a cert from each developer contributed once to the linux kernel...
It should be enough to trust the maintainer. If the maintainer is not trustworthy then the snowball is useless anyway.
While at it: Is there a repository one can track changes made to the core framework?
i did some quick tests with the digest package. i noticed a performance drop of 2/3 using gambit compared to the version in ~~lib/digest.scm (delivered with the gambit system). how do i get the performance back, still using the snowball?
That is odd. There is no reason why Snow packages should run slower. I will investigate.
Where you able to reproduce my observations?
The "snow-XXX" name is used when there is a possible name conflict with an XXX operation on some Scheme system. Often snow-XXX and XXX are related operations, but they may have slightly different semantics (accepted number of arguments, result in special cases, signaling of errors, etc).
I don't particularly like the "snow-" prefix and I hope that with time the Snow packages can deprecate those names when the various Scheme systems adopt a consistent semantics. A good example is fx+, fx*, etc which should be standardized by R6RS.
Yes, cluttering the core language is not a good idea at all.
Maybe it would be better to not support _all_ scheme systems out there. i would prefer quality over quantity.
alex
Afficher les réponses par date
snow-users-list@iro.umontreal.ca