Or may be that's me who's challenged to read CLHS, but:
- How can you truncate a file (or file stream) in Common-Lisp ?
(by the way, that's one thing easily done in C or C++:
truncate("file-name",length)
for the file version or for the stream version:
int fd=open("file-name",O_RDRW);
ftruncate(fd,length);
).
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
There is a fault in reality. Do not adjust your minds. -- Salman Rushdie
Pascal Bourguignon <···@informatimago.com> wrote in message news:<··············@thalassa.informatimago.com>...
> Or may be that's me who's challenged to read CLHS, but:
>
> - How can you truncate a file (or file stream) in Common-Lisp ?
>
>
> (by the way, that's one thing easily done in C or C++:
>
> truncate("file-name",length)
>
> for the file version or for the stream version:
>
> int fd=open("file-name",O_RDRW);
> ftruncate(fd,length);
Doh, these functions are POSIX features, not standard C or C++.
It just so happens that calling these ``foreign functions'' from C is
as easy as including a nonportable header, and linking to the right
library, because C is the preferred interface language of the POSIX
platform.
In a Lisp system running on a POSIX platform we do a slightly more
work to get to ftruncate() but not a whole lot more. Certainly the
extra effort is not worth it to switch to a low-level,
productivity-wasting language for the entire program.
···@ashi.footprints.net (Kaz Kylheku) writes:
> Pascal Bourguignon <···@informatimago.com> wrote in message news:<··············@thalassa.informatimago.com>...
> > Or may be that's me who's challenged to read CLHS, but:
> >
> > - How can you truncate a file (or file stream) in Common-Lisp ?
> >
> >
> > (by the way, that's one thing easily done in C or C++:
> >
> > truncate("file-name",length)
> >
> > for the file version or for the stream version:
> >
> > int fd=open("file-name",O_RDWR);
> > ftruncate(fd,length);
>
> Doh, these functions are POSIX features, not standard C or C++.
Doh there is no standard C function. (Ask MS-DOS programmers who're
used to con.h instead of stdio.h).
> It just so happens that calling these ``foreign functions'' from C is
> as easy as including a nonportable header, and linking to the right
> library, because C is the preferred interface language of the POSIX
> platform.
>
> In a Lisp system running on a POSIX platform we do a slightly more
> work to get to ftruncate() but not a whole lot more. Certainly the
> extra effort is not worth it to switch to a low-level,
> productivity-wasting language for the entire program.
You're all missing the point.
----------------------------------- ----------------------------------
Lisp C
----------------------------------- ----------------------------------
Provide a lot of runtime functions. Does not provide any runtime functions.
==> Users expect a comprenhesive set. ==> Users don't expect anything from
the language.
Does not provide a standard FFI. Provides a standard FFI. Actually,
IS the standard FFI.
==> It's impossible to provide a ==> Library or OS developers can
common POSIX or UNIX package. and do provide standard APIs.
----------------------------------- ----------------------------------
I've no problem with the "least common denominator" approach of
Common-Lisp and the fact that they under-specified.
But clearly we need some additionnal standard covering the missing
parts:
- A common FFI.
- A common POSIX package.
- A common UNIX package.
- etc.
One of the most telling hint about the problem is the rampant use of
#+ and #-. (Granted it's not better in C with their #ifdef/#ifndef,
but that's only because C programmers don't know how to define an
interface).
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
There is a fault in reality. Do not adjust your minds. -- Salman Rushdie
Pascal Bourguignon <···@informatimago.com> wrote in message news:<··············@thalassa.informatimago.com>...
> ···@ashi.footprints.net (Kaz Kylheku) writes:
>
> > Pascal Bourguignon <···@informatimago.com> wrote in message news:<··············@thalassa.informatimago.com>...
> > > Or may be that's me who's challenged to read CLHS, but:
> > >
> > > - How can you truncate a file (or file stream) in Common-Lisp ?
> > >
> > >
> > > (by the way, that's one thing easily done in C or C++:
> > >
> > > truncate("file-name",length)
> > >
> > > for the file version or for the stream version:
> > >
> > > int fd=open("file-name",O_RDWR);
> > > ftruncate(fd,length);
> >
> > Doh, these functions are POSIX features, not standard C or C++.
>
> Doh there is no standard C function. (Ask MS-DOS programmers who're
> used to con.h instead of stdio.h).
Consequently, there is no standard Lisp. Ask people who are using
dialects like Emacs Lisp.
If we are going to discuss C, we should treat it properly. It's an ISO
standard language in its second revision now. It has a library, and we
have to respect that.
The <conio.h> library on some MS-DOS compilers is not a replacement
for standard I/O; it's a console screen handling package.
(Incidentally, The Single Unix specification defines a standard
mechanism for this type of screen handling called curses. Curses is
not part of C, but you can find implementations of it for C compilers
that target MS-DOS).
> > In a Lisp system running on a POSIX platform we do a slightly more
> > work to get to ftruncate() but not a whole lot more. Certainly the
> > extra effort is not worth it to switch to a low-level,
> > productivity-wasting language for the entire program.
>
> You're all missing the point.
>
> ----------------------------------- ----------------------------------
> Lisp C
> ----------------------------------- ----------------------------------
> Provide a lot of runtime functions. Does not provide any runtime functions.
> ==> Users expect a comprenhesive set. ==> Users don't expect anything from
> the language.
That is incorrect, C has a standard library which is part of the
language. This provides like <stdlib.h>, functions like malloc and
printf, etc.
The C standard does define the concept of a freestanding
implementation, which provides no library, and a reduced set of
standard headers. (Even with no library, it's nice to have, for
instance, <limits.h> which tells you what INT_MAX is).
> Does not provide a standard FFI. Provides a standard FFI. Actually,
> IS the standard FFI.
This is true; because C has reached huge popularity as the language
for expressing system interfaces, it's easy to gain access to
proprietary system interfaces by writing in C, compared to the steps
required in some other languages.
But Lisp is not alone in that boat here, and in fact thanks to macros,
it's substantially better off. At least you can have a notation which
can express the subtleties of C-based foreign interfaces, and you can
use that notation right in your Lisp code.
> ==> It's impossible to provide a ==> Library or OS developers can
> common POSIX or UNIX package. and do provide standard APIs.
Yeah, right! As someone who has not long ago worked on C++ code that
simultaneously targetted POSIX, Win32, and PalmOS, I'm in an excellent
position to disagree with that ``standard APIs'' bit.
Even portability among Unixes has traditionally been a quagmire of
#ifdef's. This has improved in recent years, but hacks like autoconf
have not gone away.
* Kaz Kylheku wrote:
> This is true; because C has reached huge popularity as the language
> for expressing system interfaces, it's easy to gain access to
> proprietary system interfaces by writing in C, compared to the steps
> required in some other languages.
However, I don't believe C provides a standard FFI. A standard FFI is
really a standard function call convention as well as the definition
of the representation of some standard types. C may get half way
towards the latter, but it doesn't provide the former at all.
Instead, what has happened is that there has been a convergence in C
compilers such that, in general, all the compilers for a system have
the same calling conventions and data representations and thus can
inter-call each other. This probably started on Unix - if you wanted
to write a C compiler for a Unix machine, then it was insane not to
be able to use the standard libraries &c, so there was a very strong
incentive to use, or at least support, the calling conventions of
(typically) pcc. It may also have been driven by architecture-defined
calling conventions, but again this is not to do with C.
So, really, this is another class/instance confusion: *pcc* (or maybe
the architecture) defined the calling convention which we are happily
crediting to C-the-language.
And, incidentally, it's not really true either: gcc has a google of
options which control calling conventions, and I don't think its
default conventions are always compatible with the system compiler's.
Of course for Linux (and many other) boxes, gcc's conventions *are*
the system compiler's.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Kaz Kylheku wrote:
>
> > This is true; because C has reached huge popularity as the language
> > for expressing system interfaces, it's easy to gain access to
> > proprietary system interfaces by writing in C, compared to the steps
> > required in some other languages.
>
> However, I don't believe C provides a standard FFI. A standard FFI is
> really a standard function call convention as well as the definition
> of the representation of some standard types. C may get half way
> towards the latter, but it doesn't provide the former at all.
>
> Instead, what has happened is that there has been a convergence in C
> compilers such that, in general, all the compilers for a system have
> the same calling conventions and data representations and thus can
> inter-call each other. This probably started on Unix - if you wanted
> to write a C compiler for a Unix machine, then it was insane not to
> be able to use the standard libraries &c, so there was a very strong
> incentive to use, or at least support, the calling conventions of
> (typically) pcc. It may also have been driven by architecture-defined
> calling conventions, but again this is not to do with C.
And, as was recently mentioned on comp.compilers, calling conventions
aren't the full story. There's still the question of the runtime. C
hardly has much of a runtime, but you still need to deal with a few
things like setjmp/longjmp. If you do really simple things, the
extent to which a C calling convention is specified for a given
OS/architecture, is good enough -- but if you get fancy, or god help
you, you want to use a language that requires real runtime support
like C++, you run into problems really fast.
> So, really, this is another class/instance confusion: *pcc* (or maybe
> the architecture) defined the calling convention which we are happily
> crediting to C-the-language.
>
> And, incidentally, it's not really true either: gcc has a google of
> options which control calling conventions, and I don't think its
> default conventions are always compatible with the system compiler's.
> Of course for Linux (and many other) boxes, gcc's conventions *are*
> the system compiler's.
Which is oh-so-fun when gcc changes something.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
* Thomas F Burdick wrote:
> And, as was recently mentioned on comp.compilers, calling conventions
> aren't the full story. There's still the question of the runtime. C
> hardly has much of a runtime, but you still need to deal with a few
> things like setjmp/longjmp. If you do really simple things, the
> extent to which a C calling convention is specified for a given
> OS/architecture, is good enough -- but if you get fancy, or god help
> you, you want to use a language that requires real runtime support
> like C++, you run into problems really fast.
I recently had a bunch of excitement compiling gcc - you have to be
*really sure* you get the right options if you want exceptions to work
in multithreaded C++ code: the default options are not the right ones,
the problems occur only in weird cases and are very hard to debug...
--tim
Tim Bradshaw wrote:
> * Kaz Kylheku wrote:
>
>> This is true; because C has reached huge popularity as the language
>> for expressing system interfaces, it's easy to gain access to
>> proprietary system interfaces by writing in C, compared to the steps
>> required in some other languages.
>
> However, I don't believe C provides a standard FFI. A standard FFI is
> really a standard function call convention as well as the definition
> of the representation of some standard types. C may get half way
> towards the latter, but it doesn't provide the former at all.
>
> Instead, what has happened is that there has been a convergence in C
> compilers such that, in general, all the compilers for a system have
> the same calling conventions and data representations and thus can
> inter-call each other. This probably started on Unix - if you wanted
> to write a C compiler for a Unix machine, then it was insane not to
> be able to use the standard libraries &c, so there was a very strong
> incentive to use, or at least support, the calling conventions of
> (typically) pcc. It may also have been driven by architecture-defined
> calling conventions, but again this is not to do with C.
>
> So, really, this is another class/instance confusion: *pcc* (or maybe
> the architecture) defined the calling convention which we are happily
> crediting to C-the-language.
>
> And, incidentally, it's not really true either: gcc has a google of
> options which control calling conventions, and I don't think its
> default conventions are always compatible with the system compiler's.
> Of course for Linux (and many other) boxes, gcc's conventions *are*
> the system compiler's.
>
By reading this one might assume that the calling convention used by C
compilers is somewhat arbitrary. The fact is that there is almost always a
defined ABI (application binary interface) for unix which defines the
calling convention that should be used for system libraries. This calling
convention can be used by any language. The ABI is usually geared towards
four important languages: Fortran, C, C++, and Ada.
It is really a question of what is "foreign". C/C++/Fortran/Ada uses a
calling convention that is defined in a standard. A lisp implementation
typicall invents its own calling convention.
Also, gcc typically does _not_ have options that change the calling
convention used on platforms that have an ABI. The calling convention
defines what the stack layout looks like, what registers are callee-saved
vs. caller-saved, how results are returned etc.
On linux it is popular to use the -fomit-frame-pointer option for example.
This changes how gcc handles the stack, but it does not influence the
calling convention used. On Windows where the pascal calling convention is
used for system libraries (callee handles stack adjustments + arguments are
pushed the other way on the stack) there is support for letting a function
be called by this convention, but in this case there is only two calling
conventions used, the "C", and the "pascal" calling conventions.
Also, the reason why there are these two choices on windows is out of
necessity, not because compilers want to provide "choice" to users. A
compiler simply has to support something in addition to the system/pascal
calling convention in order to call functions with a variable number of
arguments since this is not supported by the pascal calling convention.
astor
* Alexander Kjeldaas wrote:
> By reading this one might assume that the calling convention used by C
> compilers is somewhat arbitrary. The fact is that there is almost always a
> defined ABI (application binary interface) for unix which defines the
> calling convention that should be used for system libraries. This calling
> convention can be used by any language. The ABI is usually geared towards
> four important languages: Fortran, C, C++, and Ada.
Well, yes. The ABI may even be defined by the architecture. The
issue is that the calling convention isn't a feature of
C-the-language, it's either a feature of a C implementation, or
something a C compiler can adhere to, the same way that any other
system, such as Lisp, can for its external calls. There's no reason,
for instance, why a C compiler shouldn't use some other, possibly more
efficient, convention for non-external calls, the same say a Lisp
system often does (someone here should insert the story about Franz
Lisp beating C on the Vax because its calling convention was more
efficient).
(Actually, I guess there are reasons why systems need to be aware of
various calling conventions even in internal calls: asynchronous
interrupts and signals.)
> It is really a question of what is "foreign". C/C++/Fortran/Ada uses a
> calling convention that is defined in a standard. A lisp implementation
> typicall invents its own calling convention.
> Also, gcc typically does _not_ have options that change the calling
> convention used on platforms that have an ABI. The calling convention
> defines what the stack layout looks like, what registers are callee-saved
> vs. caller-saved, how results are returned etc.
-fpcc-struct-return, for instance is a counterexample to this: to
quote the gcc manual:
`-fpcc-struct-return'
Return "short" `struct' and `union' values in memory like longer
ones, rather than in registers. This convention is less
efficient, but it has the advantage of allowing intercallability
between GCC-compiled files and files compiled with other compilers.
The precise convention for returning structures in memory depends
on the target configuration macros.
Short structures and unions are those whose size and alignment
match that of some integer type.
Now you might sayp `Oh, this doesn't change the calling convention'.
Well, it certainly makes it not possible to intercall between gcc and
(say) pcc, which is the only useful definition of changing the calling
convention that I can think of.
--tim
Pascal Bourguignon <···@informatimago.com> writes:
> You're all missing the point.
I understand your point, but I have a nit to pick:
> ----------------------------------- ----------------------------------
> Lisp C
> ----------------------------------- ----------------------------------
>
> Does not provide a standard FFI. Provides a standard FFI. Actually,
> IS the standard FFI.
Not true. _F_FI means _foreign_ function interface. In C's case, the
equivalent would be a calling mechanism to make calls to non-lisp
languages such as Lisp.
The idea would be that if I had an expert system application written
in CL and I wanted to call it from C without modifying the CL app to
accept foreign callbacks (or call-into's) then I wouldn't be able to
do this, because C has no FFI into CL. Two reasons why this occurs:
1. CL has no machine-level calling convention defined.
2. C is C-centric and doesn't recognize any other languages.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> Pascal Bourguignon <···@informatimago.com> writes:
>
> > You're all missing the point.
>
> I understand your point, but I have a nit to pick:
>
> > ----------------------------------- ----------------------------------
> > Lisp C
> > ----------------------------------- ----------------------------------
> >
> > Does not provide a standard FFI. Provides a standard FFI. Actually,
> > IS the standard FFI.
>
> Not true. _F_FI means _foreign_ function interface. In C's case, the
> equivalent would be a calling mechanism to make calls to non-lisp
================================================================^
> languages such as Lisp.
Sorry, I meant non-C here...
> The idea would be that if I had an expert system application written
> in CL and I wanted to call it from C without modifying the CL app to
> accept foreign callbacks (or call-into's) then I wouldn't be able to
> do this, because C has no FFI into CL. Two reasons why this occurs:
> 1. CL has no machine-level calling convention defined.
> 2. C is C-centric and doesn't recognize any other languages.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Pascal Bourguignon writes:
>
>
> >You're all missing the point.
>
>
> I understand your point, but I have a nit to pick:
>
>
> >----------------------------------- ----------------------------------
> >Lisp C
> >----------------------------------- ----------------------------------
> >
> >Does not provide a standard FFI. Provides a standard FFI.
> Actually,
> > IS the standard FFI.
>
>
> Not true. _F_FI means _foreign_ function interface. In C's case, the
> equivalent would be a calling mechanism to make calls to non-lisp
> languages such as Lisp.
I assume you meant "make calls to non-C languages such as Lisp" :)
Cheers
--
Marco Antoniotti
Pascal Bourguignon wrote:
> But clearly we need some additionnal standard covering the missing
> parts:
>
> - A common FFI.
> - A common POSIX package.
> - A common UNIX package.
> - etc.
Excellent observation! The most important missing part, of course, is the
common FFI: It is the common FFI that makes people port zillions of
libraries to Perl, Python, Ruby, Tcl (of course, that's easy with these
languages as each has essentially one implementation only). It is a waste
of effort to have to port to (almost) each Lisp-Implementation
individually. UFFI might be a start.
For many real-world problems having available a powerful language to express
abstractions is just as important as having available a large number of
high-quality libraries.
Matthias
>
> One of the most telling hint about the problem is the rampant use of
> #+ and #-. (Granted it's not better in C with their #ifdef/#ifndef,
> but that's only because C programmers don't know how to define an
> interface).
>
>
Matthias Heiler wrote:
> Pascal Bourguignon wrote:
>
>
>>But clearly we need some additionnal standard covering the missing
>>parts:
>>
>> - A common FFI.
>> - A common POSIX package.
>> - A common UNIX package.
>> - etc.
>
>
> Excellent observation! The most important missing part, of course, is the
> common FFI:
Yep
> It is the common FFI that makes people port zillions of
> libraries to Perl, Python, Ruby, Tcl (of course, that's easy with these
> languages as each has essentially one implementation only). It is a waste
> of effort to have to port to (almost) each Lisp-Implementation
> individually. UFFI might be a start.
Yep, but it needs a push.
Somehow I, who knows nothing about FFI and has zero familiarity with
Corman, ended up being the one tying to add Corman support to UFFI.
(after having to fix the LW support.) Not good.
Adding Corman is technically easy because Corman has great FFI support,
but for a dense task like this one really needs to be fluent in the IDE.
Day five, steady progress, but I just hit obstacle 42 and I am so fed up
I might just say fuck it. I'll take a nap first.
Why haven't cormaniks ported uffi? Because not much software has been
uffi-ized? Why wasn't Corman support added by UFFIniks? Corman too
small? Probably just a chicken-egg deal.
OK. Nap is done. Anyone want the work I have done on UFFI? New stuff in
there for LW and Corman. I'd ask on the UFFI and Corman mail lists, but
my original queries there re UFFI/Corman were met with silence so I
think I know the answer. :)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> writes:
> OK. Nap is done. Anyone want the work I have done on UFFI? New stuff
> in there for LW and Corman. I'd ask on the UFFI and Corman mail
> lists, but my original queries there re UFFI/Corman were met with
> silence so I think I know the answer. :)
The UFFI people do accept patches and fold them into the distribution.
The uffi list if low-volume, but it does pick up when something
interesting comes along.
-russ
Pascal Bourguignon <···@informatimago.com> writes:
> (by the way, that's one thing easily done in C or C++:
>
> truncate("file-name",length)
>
> for the file version or for the stream version:
>
> int fd=open("file-name",O_RDRW);
> ftruncate(fd,length);
Neither truncate() nor ftruncate() are part of the ISO C standard.
Florian Weimer <··@deneb.enyo.de> writes:
> Pascal Bourguignon <···@informatimago.com> writes:
>
> > (by the way, that's one thing easily done in C or C++:
> >
> > truncate("file-name",length)
> >
> > for the file version or for the stream version:
> >
> > int fd=open("file-name",O_RDRW);
> > ftruncate(fd,length);
>
> Neither truncate() nor ftruncate() are part of the ISO C standard.
If not ISO C, POSIX is good enough for me:
CONFORMING TO
4.4BSD, SVr4 (these function calls first appeared in BSD
4.2). SVr4 documents additional truncate error conditions
EINTR, EMFILE, EMULTIHP, ENAMETOOLONG, ENFILE, ENOLINK,
ENOTDIR. SVr4 documents for ftruncate additional EAGAIN
and EINTR error conditions. POSIX has ftruncate but not
truncate.
The POSIX standard does not define what happens if the
file has fewer bytes than length.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
There is a fault in reality. Do not adjust your minds. -- Salman Rushdie
Pascal Bourguignon <···@informatimago.com> writes:
> Florian Weimer <··@deneb.enyo.de> writes:
>
> > Neither truncate() nor ftruncate() are part of the ISO C standard.
>
> If not ISO C, POSIX is good enough for me:
>
> CONFORMING TO
> 4.4BSD, SVr4 (these function calls first appeared in BSD
> 4.2). SVr4 documents additional truncate error conditions
Well, if what you need is POSIX functionality, then maybe you
should consider a foreign-language binding to the POSIX calls you need?
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Pascal Bourguignon wrote:
> Florian Weimer writes:
>
>
> >Pascal Bourguignon writes:
> >
> >
> >>(by the way, that's one thing easily done in C or C++:
> >>
> >> truncate("file-name",length)
> >>
> >>for the file version or for the stream version:
> >>
> >> int fd=open("file-name",O_RDRW);
> >> ftruncate(fd,length);
> >
> >Neither truncate() nor ftruncate() are part of the ISO C standard.
>
>
> If not ISO C, POSIX is good enough for me:
>
> CONFORMING TO
> 4.4BSD, SVr4 (these function calls first appeared in BSD
> 4.2). SVr4 documents additional truncate error conditions
> EINTR, EMFILE, EMULTIHP, ENAMETOOLONG, ENFILE, ENOLINK,
> ENOTDIR. SVr4 documents for ftruncate additional EAGAIN
> and EINTR error conditions. POSIX has ftruncate but not
> truncate.
>
> The POSIX standard does not define what happens if the
> file has fewer bytes than length.
I am pretty sure that in CMUCL you can do (or easily set up your system
to do)
(ext:unix-truncate file length)
Your question is not a challenge for Common Lisp as a language. Is a
challenge for the community to come up with a portable (meaning: working
on all implementations/platforms)
(defpackage "POSIX" (:use "WHATEVER-IT-TAKES")
(:export "TRUNCATE" ....))
etc etc.
Any takers?
Cheers
--
Marco Antoniotti
Pascal Bourguignon wrote:
> Or may be that's me who's challenged to read CLHS, but:
>
> - How can you truncate a file (or file stream) in Common-Lisp ?
>
>
> (by the way, that's one thing easily done in C or C++:
>
> truncate("file-name",length)
>
> for the file version or for the stream version:
>
> int fd=open("file-name",O_RDRW);
> ftruncate(fd,length);
>
> ).
Common Lisp has TRUNCATE and FTRUNCATE. What could the problem
possibly be? :-)
Aside: What seems to be the obvious way to do this in CMU CL
doesn't work for me. Perhaps someone can tell me whether I'm
being dim; if not, I'll file a bug report. I have a file called
"test-file.txt" containing "This is a test.\nThis is a test".
The "\n" is a newline character. I call
(unix:unix-truncate "test-file.txt" 10)
and it returns NIL and 27 and doesn't truncate the file.
As I understand it, the second value is meant to be a Unix
error code. According to sys/errno.h on my system, error 27
is EFBIG ("File too large"), which isn't even among the
documented errno values for truncate(2).
This is with CMU CL version 18d, on a FreeBSD/x86 box.
--
Gareth McCaughan ················@pobox.com
.sig under construc
Gareth McCaughan wrote:
[TRUNCATE]
> Aside: What seems to be the obvious way to do this in CMU CL
> doesn't work for me. Perhaps someone can tell me whether I'm
> being dim; if not, I'll file a bug report.
you don't seem to be dim. i've followed your procedure to the letter, and
it works fine. return values are <T, 0> and the file is truncated.
this is on CMU CL 18d, linux/x86.
so a bug report might be in order... ;-)
--
Joost Kremers http://baserv.uci.kun.nl/~jkremers
mail me for a bon mot
Joost Kremers <············@yahoo.com> writes:
> Gareth McCaughan wrote:
> [TRUNCATE]
> > Aside: What seems to be the obvious way to do this in CMU CL
> > doesn't work for me. Perhaps someone can tell me whether I'm
> > being dim; if not, I'll file a bug report.
>
> you don't seem to be dim. i've followed your procedure to the letter, and
> it works fine. return values are <T, 0> and the file is truncated.
>
> this is on CMU CL 18d, linux/x86.
>
> so a bug report might be in order... ;-)
I've fixed this in CVS; reason was the 64-bit off_t on FreeBSD.
(in-package "UNIX")
(defun unix-truncate (name len)
"Unix-truncate truncates the named file to the length (in
bytes) specified by len. NIL and an error number is returned
if the call is unsuccessful."
(declare (type unix-pathname name)
(type (unsigned-byte 32) len))
#-(and bsd x86)
(void-syscall ("truncate" c-string int) name len)
#+(and bsd x86)
(void-syscall ("truncate" c-string unsigned-long unsigned-long) name len 0))
(defun unix-ftruncate (fd len)
"Unix-ftruncate is similar to unix-truncate except that the first
argument is a file descriptor rather than a file name."
(declare (type unix-fd fd)
(type (unsigned-byte 32) len))
#-(and bsd x86)
(void-syscall ("ftruncate" int int) fd len)
#+(and bsd x86)
(void-syscall ("ftruncate" int unsigned-long unsigned-long) fd len 0))
Gerd Moellmann wrote:
> Joost Kremers <············@yahoo.com> writes:
>
> > Gareth McCaughan wrote:
> > [TRUNCATE]
> > > Aside: What seems to be the obvious way to do this in CMU CL
> > > doesn't work for me. Perhaps someone can tell me whether I'm
> > > being dim; if not, I'll file a bug report.
> >
> > you don't seem to be dim. i've followed your procedure to the letter, and
> > it works fine. return values are <T, 0> and the file is truncated.
> >
> > this is on CMU CL 18d, linux/x86.
> >
> > so a bug report might be in order... ;-)
>
> I've fixed this in CVS; reason was the 64-bit off_t on FreeBSD.
[etc]
Thanks!
--
Gareth McCaughan ················@pobox.com
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> Common Lisp has TRUNCATE and FTRUNCATE. What could the problem
> possibly be? :-)
>
> Aside: What seems to be the obvious way to do this in CMU CL
> doesn't work for me. Perhaps someone can tell me whether I'm
> being dim; if not, I'll file a bug report. I have a file called
> "test-file.txt" containing "This is a test.\nThis is a test".
> The "\n" is a newline character. I call
> (unix:unix-truncate "test-file.txt" 10)
> and it returns NIL and 27 and doesn't truncate the file.
> As I understand it, the second value is meant to be a Unix
> error code. According to sys/errno.h on my system, error 27
> is EFBIG ("File too large"), which isn't even among the
> documented errno values for truncate(2).
>
> This is with CMU CL version 18d, on a FreeBSD/x86 box.
It *could* be a problem with the FFI binding for
unix-truncate. The offset argument is an off_t (ahem), which has been
a 64-bit value for some time under FreeBSD.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Pascal Bourguignon <···@informatimago.com> writes:
> Or may be that's me who's challenged to read CLHS, but:
>
> - How can you truncate a file (or file stream) in Common-Lisp ?
In Allegro CL 6.2 (with a fully patched lisp), you can use the `osi'
(operating system interface) module. It was designed for just this
type of thing.
(require :osi)
(excl.osi:os-truncate file length)
(excl.osi:os-ftruncate stream length)
See the docs here:
http://www.franz.com/rz/6.2/doc/os-interface.htm#os-truncate-op-bookmarkxx