At Tue, 9 Oct 2012 12:22:59 -0700, Dan Liebgold wrote:
On Tue, Oct 9, 2012 at 11:32 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Tue, 9 Oct 2012 18:00:14 + (UTC), Dan Liebgold wrote:
It still seems strange to me that we should implement our own
filesystem of some sort to get decent
On Wed, Oct 10, 2012 at 10:19 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
I guess we should try this, but I think we should keep it specific to
bytecode loading. That is, I don't think we should try to splice a
.zip-based filesystem into Racket's core filesystem operations.
I would think that
Just now, Matthew Flatt wrote:
I guess we should try this, but I think we should keep it specific
to bytecode loading. That is, I don't think we should try to splice
a .zip-based filesystem into Racket's core filesystem operations.
That's what I had in mind, though splicing a zip at the
I've just had a very brief round of e-mail with M. Fatih Köksal, who sends his
best to Matthias and the rest of the team.
Cheers,
John (Mehmet)
smime.p7s
Description: S/MIME cryptographic signature
_
Racket Developers list:
http://lists.racket-lang.org/dev
On Wed, Oct 10, 2012 at 7:19 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
People who know about network filesystems tell me that the difference
is in how the filesystems are tuned. They think a single file to hold
bytecode will likely help by trading meta-data operations on many files
for
FWIW, a zip file may not be a good format because the file index is
just a O(n) access list (no matter how many sub-directories the zip
file contains.) I didn't find any standard archive formats with O(log
n) or better performance, which is why DrDr uses a custom format:
6 matches
Mail list logo
