When I start up clisp I get the error: '*** - invalid byte #xFC in
CHARSET:ASCII conversion'. Using 'clisp -norc' yields no error. There is
neither .clisprc.lisp nor .clisprc.fas in my home directory so what is going
wrong?

I've come up with a little build hack that allows you to write
your own main() function when generating a custom lisp.run image.
It's a bit platform-specific in that the objcopy tool is required.
Your main() can process and filter the argument list, or perform your
own custom initialization stuff before calling the CLISP one.
You take your linkkit's link.sh file and change it according to this
diff:
--- code/unix-bindings/link.sh 16 Jan 2003 05:07:21 -0000 1.3
+++ code/unix-bindings/link.sh 14 Dec 2004 06:02:50 -0000
@@ -5,3 +5,8 @@
NEW_MODULES="$mod_list"
TO_LOAD='unix'
+
+# hack to get our own main()
+
+FILES="$(echo $FILES | sed -e 's/lisp.a //')"
+objcopy --redefine-sym main=clisp_main "$absolute_sourcedir"/lisp.a "$absolute_destinationdir"/lisp.a
What we are doing here is taking the lisp.a image out of the FILES
list, to prevent the main script from generating the symbolic link from
the linking set directory to the original lisp.a. This allows our
script to take on the responsibility of handling how the lisp.a
component is brought over from the original linking set to our new one.
Of course, we do that not by by symlinking it, but by making an edited
copy using the GNU objcopy tool to rename main() to clisp_main().
Then of course in your custom C module that you are linking, you have to
write a main function so everything links:
/*
* Main function. We arrange this by a hack; when we build the
* Lisp image, we rename the main function in the lisp.a archive
* to clisp_main using the objcopy utility. Then we can have our
* own main. See lisp.sh file.
*/
int main(int argc, char **argv)
{
extern int clisp_main(int argc, char **argv);
/* Code :before/:around CLISP */
retcode = clisp_main(new_argc, new_argv);
/* Code :after CLISP */
return retcode;
}
Do I get brownie points for participating in aspect-oriented
programming? Hahaha.
Why is this useful? Well, for one thing, you can eliminate the use of a
#! script to launch your CLISP application. So you are one-step closer
to a ``true'' executable. Just write your main() so it adds whatever
extra arguments it needs that would otherwise be in the #! script.
Moreover, you can add arbitrary arguments; you don't run into strange
#! limitations (which is why I experimented with this approach in the
first place!)
Here is an example main() that copies the argument list and adds
an extra two arguments at the front, in between argument 0 and 1.
Careful: the altered argument vector is locally allocated in main(), so
you can't refer to it from code that runs after main() returns, like
C++ destructors or atexit() handlers.
#include <stdlib.h> /* for malloc and free */
/*...*/
int main(int argc, char **argv)
{
extern int clisp_main(int argc, char **argv);
int new_argc = argc + 2;
char **new_argv = malloc(sizeof *new_argv * (new_argc + 1));
int i;
char E_option[] = "-M";
char E_arg[] = "/path/to/my/image.mem";
int retcode;
if (argv == 0) {
fprintf(stderr, "%s: out of memory\n", argv[0]);
return EXIT_FAILURE;
}
new_argv[0] = argv[0];
new_argv[1] = E_option;
new_argv[2] = E_arg;
memcpy(&new_argv[3], &argv[1], sizeof argv[1] * (argc - 1));
new_argv[new_argc] = 0;
retcode = clisp_main(new_argc, new_argv);
free(new_argv);
return retcode;
}
--
Meta-CVS: the working replacement for CVS that has been stable since
2002. It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs

Hello,
I also had that problem, but in recent cvs builds it works for me. I think
#windows and #unix were defined at the same time.
salud2
Karsten
"Jonathan" <funkyj@...> wrote in message
news:b2562c8e05012619333751f9bd@...
I've successfully built and run clisp under cygwin but when I tried to
build clisp with libsigsegv on cygwin I got the following compiler error:
In file included from spvw.d:24:
......
Is anyone else using clisp under cygwin? If yes, are you also using
libsigsegv?
Regards,
--Jonathan
--
But I don't have to know an answer. I don't feel frightened by not
knowing things, by being lost in the mysterious universe without
having any purpose-which is the way it really is, as far as I can
tell, possibly. It doesn't frighten me.
--Feynman
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

I've successfully built and run clisp under cygwin but when I tried to
build clisp with libsigsegv on cygwin I got the following compiler error:
In file included from spvw.d:24:
constobj.d:89: duplicate member `charname_8bis'
constobj.d:91: duplicate member `charname_10bis'
constobj.d:99: duplicate member `charname_0'
constobj.d:106: duplicate member `charname_7'
constobj.d:107: duplicate member `charname_8'
constobj.d:108: duplicate member `charname_9'
constobj.d:109: duplicate member `charname_10'
constobj.d:110: duplicate member `charname_11'
constobj.d:111: duplicate member `charname_12'
constobj.d:112: duplicate member `charname_13'
constobj.d:125: duplicate member `charname_26'
constobj.d:126: duplicate member `charname_27'
constobj.d:131: duplicate member `charname_32'
constobj.d:437: duplicate member `backupextend_string'
lispbibl.d:12521:1: warning: "INVALID_HANDLE_VALUE" redefined
In file included from /usr/include/w32api/windows.h:50,
from /usr/local/include/sigsegv.h:21,
from lispbibl.d:1727,
from spvw.d:24:
/usr/include/w32api/winbase.h:232:1: warning: this is the location of
the previous definition
make: *** [spvw.o] Error 1
Is anyone else using clisp under cygwin? If yes, are you also using
libsigsegv?
Regards,
--Jonathan
--=20
But I don't have to know an answer. I don't feel frightened by not
knowing things, by being lost in the mysterious universe without
having any purpose=E2=80=94which is the way it really is, as far as I can
tell, possibly. It doesn't frighten me.
--Feynman

Joerg-Cyril Hoehle wrote:
> IMHO, it's not yet consistent, since the following source-level
> transformation does not work for (setf values-list) as a function-name:
> (<f> <args>...)
> == (funcall (function <f>) <args>...)
For all cases where (funcall (function <f>) <args>...) is valid,
in clisp (<f> <args>...) is valid as well and equivalent. That's
why I call this consistent.
> #'(setf values-list)
The function (setf values-list) does not exist, therefore both
((setf values-list) ...)
and
(funcall (function (setf values-list)) ...)
are invalid. It is consistent.
The fact that (setf (values-list ...) ...) expanded to something invalid
was a bug and has now been fixed.
Bruno

Bruno Haible wrote:
>CLISP supports the consistent way of using function names, in DEFUN,
>in DECLARE INLINE, in DEFGENERIC, in DEFCLASS slot options, in =
FBOUNDP,
>in FUNCTION, _and_ also in the function call syntax.
IMHO, it's not yet consistent, since the following source-level =
transformation does not work for (setf values-list) as a function-name:
(<f> <args>...)
=3D=3D (funcall (function <f>) <args>...)
(same for apply), since I already pointed out that #'(setf values-list) =
yield an error.
Some macros are likely to do such transformations. It works for names =
as symbols and for (lambda ...) expressions.
>Cool! You already found the paragraph that supports the extension!
I'd like to find a similar paragraph in impnotes.
I can live with #+clisp-specific ((setf foo) v bar) syntax.
>do yourself a favour and replace [...] with
> (typep x '(or symbol (cons (eql setf) (cons symbol null))))
>at the appropriate place. It's a one-line change.
It's not a one line change, since it endangers other places in the code =
(a typical static vs. dynamic typing argument).
For example, calls to (macro-function x), special-operator-p or type =
declarations because CLHS states:
macro-function symbol &optional environment =3D> function
symbol---a symbol.
But I fully agree that the amount of changes is limited.
Concretely, if I were to apply the proposed change in Iterate, which =
(not surprisingly) has such a SYMBOLP test, it would break because:
(special-operator-p '(setf values-list))
*** - SPECIAL-OPERATOR-P: (SETF VALUES-LIST) is not a symbol
But I have a 2-line patch (4 with comments) that seems to work.
>There is no such thing as a portable code walker.
Agreed, yet every walker will need #+clisp-specific code.
Not so nice.
For instance, Marco Baringer came across this setf issue when trying to =
port his UCW to clisp (ucw includes a CPS transformer, which means code =
transformation).
Regards,
J=C3=B6rg H=C3=B6hle.

Joerg-Cyril Hoehle wrote:
> I consider it impossible to add such an extension. The standard clearly
> says: ?3.1.2.1.2
> A cons that is used as a form is called a compound form.
> If the car of the compound form is not a symbol, then that car must be a
> lambda expression, in which case the compound form is a lambda form.
The ANSI CL committee, when they voted down item 7 of issue
<FUNCTION-NAME:LARGE>, voted for inconsistency.
CLISP supports the consistent way of using function names, in DEFUN,
in DECLARE INLINE, in DEFGENERIC, in DEFCLASS slot options, in FBOUNDP,
in FUNCTION, _and_ also in the function call syntax.
> glossary, so YMMV:
>
> "function form n. a form that is a list and that has a first element which
> is the name of a function to be called on arguments [...]"
Cool! You already found the paragraph that supports the extension!
> Therefore, I believe CLISP must not use such special syntax, or it will
> cause trouble to any portable code walker.
Come on, get real:
1) There is no such thing as a portable code walker.
You cannot expand
(macrolet ((foo (a &environment env) ...))
(symbol-macrolet (x 5)
(macrolet ((bar () (foo x)))
(bar))))
in a portable way, because in order to do so, you would need to construct
a macroexpansion environment 'env' that contains the symbol-macro binding
for 'x' in the format that the implementation uses. You don't have the
portable primitives for doing so.
2) If you are working on a semi-portable code walker, that anyway
requires some adjustments for every Lisp implementation, then please
do yourself a favour and replace
(symbolp x)
with
(typep x '(or symbol (cons (eql setf) (cons symbol null))))
at the appropriate place. It's a one-line change.
Bruno

Hi,
while we are at CLISP custom syntax uses, here's something Marco Baringer just reported as causing problems with Iterate (and code walkers, generally):
((setf foo) value other-args)
CLISP does not document this syntax extension (probably nobody uses it directly). Yet it appears as a result of macroexpansion:
[9]> (macroexpand-1'(setf (values-list (list a b c)) (foo)))
(LET* ((#:G6359 (LIST A B C))) ((SETF VALUES-LIST) (FOO) #:G6359)) ;
T
I consider it impossible to add such an extension. The standard clearly says:
?3.1.2.1.2
A cons that is used as a form is called a compound form.
If the car of the compound form is not a symbol, then that car must be a lambda expression, in which case the compound form is a lambda form.
With ((setf ...) ...), the car is not a symbol, nor a lambda expression. It's not legal CL (and it's not a function form).
Therefore, I believe CLISP must not use such special syntax, or it will cause trouble to any portable code walker.
IMHO ((setf ...) ...) cannot be considered a function form, since the standard uses a discrimination tree to distinguish among the three categories: function, special and lambda forms. Nowhere does it say "a function form is a list starting with a function name or designator, and (setf ...) is a function designator" -- except in the glossary, so YMMV:
"function form n. a form that is a list and that has a first element which is the name of a function to be called on arguments [...]"
One may argue that the above example with (setf value-list) is specific to CLISP (impnotes ?5.1.5) and thus non-portable already. Well, it's just the first example I came up with after Marco Baringer reported the bug to the iterate-devel mailing list. I guess there are other such uses of illegal syntax in macroexpansions from CLISP for plain porable code.
Suggestions are welcome!
BTW, #'(setf values-list)
*** - FUNCTION: undefined function (SETF VALUES-LIST)
Same for #'(setf car), but I guess CL says nowhere that (setf car) is the name of a defined function. I presume it only applies to self-defined functions.
Regards,
Jorg Hohle.

> I've been hearing a lot about Lisp lately, and I'd like to give it a
> try.
>
> Almost every day I'm faced with moving data from let's say ldap to sql
> or vice versa, parsing few files and generating some meaningful output.
LDAP <-> "SQL" is a good example, as CLISP does have built-in modules
(which in turn access 3rd party libraries) for those two things
specifically.
By "SQL" I assume you mean a relation DBMS of some ttype. CLISP has
easy access to Postgres and Oracle. I have written substantial Oracle
apps w/ it.
For parsing files CLISP has yet another library "pcre" (perl
compatible regex's) which should be on par w/ perl.
> Few other, bigger things are billing software (all writtn in perl),
> threaded tcp servers, XMLRPC, ...
This sounds like a lot to re-write at once. I'd suggest picking a small
project and seeing it through from start to finish!
> I'd like to try writing this thingies in Clisp. Is this even sane
> to do?
definitely. One thing that is way easier w/ Lisp is debugging.
---
John Hinsdale, Alma Mater Software, Inc., Tarrytown, NY 10591-3710 USA
hin@... | http://www.alma.com/staff/hin | +1 914 631 4690

Hi!
I'm a sysadmin using mostly perl for my day-to-day tasks. Zilions of
modules and lazy type of writing is very suited for me ... Mostly moving
data from one place to another.
I've been hearing a lot about Lisp lately, and I'd like to give it a
try.
But it's difficult to do something similiar to my perl throwaway scripts
in Clisp. There seems to be very few(non-free) on no supporting libraries
(sql, ldap, parsing files, ...). Yes, I am lazy... to some degree.
Almost every day I'm faced with moving data from let's say ldap to sql
or vice versa, parsing few files and generating some meaningful output.
Few other, bigger things are billing software (all writtn in perl),
threaded tcp servers, XMLRPC, ...
I'd like to try writing this thingies in Clisp. Is this even sane to do?
Damir

Yaroslav Kavenchuk schrieb:
> I have copied files postgresq from include\* and lib\* in c:\cygwin\...
> It can be made more nice?
wrong:
/usr/include/postgres_ext.h is ok
/usr/include/libpq-fe.h is ok
just some internal includes are in /usr/include/postgresql/server
(not needed)
The libs are in /lib, just some libexec dll's are in /lib/postgresql
> After build clisp with postgresql module
>
> $ ./configure --silent --with-module=syscalls --with-module=regexp
> --with-module=dirkey --with-mingw \
> --with-module=postgresql --build build-win32-pg
>
> and remove cygwin\bin from PATH I get:
> ...library DLL cygcrypt-0.dll not found...
So you shouldn't remove cygwin\bin from your PATH.
How you do you want to run a cygwin app without a PATH?
and you need the openssl package.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

hello,
i m vishal G. Ghadge, I am doing MCA under PUNE Univ,
i want do project in clisp,
can anybody forward me good project idea.
NOTE: project should be big enough to submit for 500
marks.
thanks
vishal
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com