This is supposed to be informative, not a flame war. Please don't
assume you're being flamed; I just don't care that much about scsh.
There was some amount of effort to port the scsh api to mzscheme,
but I don't know where that stands; last I knew it was hung up on
getting FFI more standardized. I'm not aware of anybody having
volunteered to rewrite the C glue into yet another FFI du jour.
> And stat(). Just create a > 2GB file and try to get its size. Your
> scsh script aborts with an error. That's the "usual caveats". It keeps
> me from using scsh to delete files of size 0 in a directory containing
> other (big) files. Pretty limiting.
(delete-file "flob") where flob is in excess of 2 gigs works for
me, as does deleting a zero length file in directories containing
large files. At least on the system I'm on, rather than doing
something semi-rational like throwing a scheme level error,
file-info:size on a large file returns a number truncated into a
signed 32 bit quantity.
State code that doesn't work for you rather than making english
statements that are highly ambiguous. I can't figure out the precise
failure case you mean for what you are being prevented from deleting
zero size files for. If it was throwing a scheme error, this should
be catchable by the normal means -- thus, why such behavior is
considered dimly "reasonable" whereas truncation/aliasing like I'm
seeing is not. file:size on a file of length 8589934595 returns 3,
which is bad.
> I have to compile the libraries it needs as a 32 bit binary
> first. While theoretically possible, having a distribution packaging
> system that supports the multiple architectures supported by the
> hardware is not there yet. (And conflicts with LSB support and that
> kind of boring things.)
Thinly veiled flames are not conducive to getting people to
volunteer to help you.
If LSB says "thou shalt only provide 64 bit libraries to your
users" on a mixed 32/64 arch like amd64, you are doing your users a
disservice by specifying the standard as such and insisting that such
a standard has any basis on reality. Fix the standard. If your
packaging system can't deal with this mix, your packaging system is
broken and you should address this. 32 vs 64 bit backwards
compatability issues aren't new with amd64. Others have addressed
this in ways that allow you to move on to more interesting problems
and run what you need without a flag day; examine the prior art.
Insisting that a 64 bit flag day is a good idea doesn't seem to fly
for a lot of people.
My employer has a hell of a lot of code that doesn't port cleanly
to 64 bit systems (since we ran into the practical limitations of 32
bits a long time ago and got "clever"). We seem to be able to do
coexistance of 32 and 64 bit code in a straight forward enough fashion
without volunteering to compile a large body of code starting from the
C library on up ourselves (and even when we do have to compile it
ourselves, we can).
Choose where your priorities are, because as it stands right now your
requirements have mutual exclusivity problems. AFAICT, scheme48 still
doesn't run on the alpha, which bodes poorly for you getting
scsh/scheme48 functioning the way you want any time soon.
Addressing your problems with 64 bit off_t is probably much
simpler, but I'm not exactly volunteering myself at this rate.
|