Pascal Bourguignon writes:
> Well, really, everything should be put in a file and either load it or
> run it as a #! script; then you have full control.
Running from #! does not give you keyboard interaction.
Load does not let you change the package outside of the load.
That means that if you interrupt and abort the load then you're
not in the package you want.

Don Cohen writes:
> Pascal Bourguignon writes:
> >
> > Well the order of -i and -p indeed fixed, but you could use -x instead:
> >
> > clisp -q -norc \
> > -x '(in-package "KEYWORD")' \
> > -x '(cl:load "print-package.lisp")' \
> > -x '(ext:quit)'
> >
> > [1]>
> > #<PACKAGE KEYWORD>
> > KEYWORD[2]>
> > #<PACKAGE KEYWORD>
> > COMMON-LISP:T
> > KEYWORD[3]>
>
> One problem with that is that -x means to exit after the forms.
> In your case the quit is unnecessary. I can fix that with -repl
> but the next problem is that -x doesn't allow reading from the
> keyboard. That is, my interactive loop will simply exit due to eof.
Well, really, everything should be put in a file and either load it or
run it as a #! script; then you have full control.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.

Don Cohen writes:
>
> Here's a long standing problem that I only now begin to think of as a
> clisp bug. Let's see what the rest of you think.
> Consider a batch file with a command like
> clisp -i start.lsp -p MYPKG
> The behavior I see suggests that this is interpreted as something like
> (progn (load "start.lsp")(in-package "MYPKG"))
>
> The problem is that if the load breaks and the user aborts then he
> doesn't end up in MYPKG. One common case is that the load actually
> goes into a user interaction loop in which the code expects to be in
> MYPKG. In the case where the user is not actually a programmer one
> usually tries to catch errors, but it's sometimes useful (esp. for
> debugging) to break. At that point you might want to abort and
> restart, or the user might abort accidentally and want to restart.
> In that situation it would be nice to be in MYPKG after the abort.
>
> I think I'd prefer to do the in-package first. That's actually what
> I would have expected. The only problem I see is that such a change
> could break some existing working code.
> How about unwind-protect instead of progn?
Well the order of -i and -p indeed fixed, but you could use -x instead:
clisp -q -norc \
-x '(in-package "KEYWORD")' \
-x '(cl:load "print-package.lisp")' \
-x '(ext:quit)'
[1]>
#<PACKAGE KEYWORD>
KEYWORD[2]>
#<PACKAGE KEYWORD>
COMMON-LISP:T
KEYWORD[3]>
--
__Pascal Bourguignon__ http://www.informatimago.com/
This universe shipped by weight, not volume. Some expansion may have
occurred during shipment.

Sure. I'll pack up a tar ball, give it a shake or two, and email it to you.
Give me some time to put it together because a code review is in process!
I'll assume you aren't a complete newbie and know the basics on setting
up asdf packages manually; that will make my end simpler. I'll also assume
you have a working mysql installation and the "libmysql.dll" that is normally
installed in the "MySQL Server X.X/lib/opt/" directory.
-lv
Devon Sean McCullough wrote:
> From: Lou Vanek <vanek@...>
> Date: Sun, 21 May 2006 08:00:33 +0000
>
> Clsql relies on uffi. Cffi's uffi compatibility module has some
> problems. I submitted a patch to Luís Oliveira and he seems
> favorable to incorporating it.
>
> Gee, would you send me all the non-CLISP sources, patched or original,
> that went into your working CLSQL package? If I get it to work here
> I'll send back the fixes.
>
> I agree that the state of Lisp's (free) libraries need more
> attention. That's why I think the Python, Perl, PHP, and Ruby
> communities are so vibrant -- their libraries are mature,
> maintained, and continue to grow. Can't say the same for Lisp,
> sadly.
>
> Amen! Back to Python.
>
> Peace
> --Devon

Here's a long standing problem that I only now begin to think of as a
clisp bug. Let's see what the rest of you think.
Consider a batch file with a command like
clisp -i start.lsp -p MYPKG
The behavior I see suggests that this is interpreted as something like
(progn (load "start.lsp")(in-package "MYPKG"))
The problem is that if the load breaks and the user aborts then he
doesn't end up in MYPKG. One common case is that the load actually
goes into a user interaction loop in which the code expects to be in
MYPKG. In the case where the user is not actually a programmer one
usually tries to catch errors, but it's sometimes useful (esp. for
debugging) to break. At that point you might want to abort and
restart, or the user might abort accidentally and want to restart.
In that situation it would be nice to be in MYPKG after the abort.
I think I'd prefer to do the in-package first. That's actually what
I would have expected. The only problem I see is that such a change
could break some existing working code.
How about unwind-protect instead of progn?

From: Lou Vanek <vanek@...>
Date: Sun, 21 May 2006 08:00:33 +0000
Clsql relies on uffi. Cffi's uffi compatibility module has some
problems. I submitted a patch to Lu=EDs Oliveira and he seems
favorable to incorporating it.
Gee, would you send me all the non-CLISP sources, patched or original,
that went into your working CLSQL package? If I get it to work here
I'll send back the fixes.
I agree that the state of Lisp's (free) libraries need more
attention. That's why I think the Python, Perl, PHP, and Ruby
communities are so vibrant -- their libraries are mature,
maintained, and continue to grow. Can't say the same for Lisp,
sadly.
Amen! Back to Python.
Peace
--Devon
/~\
\ / Health Care
X not warfare
/ \
Dubya won the digital vote
Kerry won the popular vote

On 2006/05/21, at 17:00, Lou Vanek wrote:
> I agree that the state of Lisp's (free) libraries need more
> attention. That's why I think
> the Python, Perl, PHP, and Ruby communities are so vibrant -- their
> libraries are mature,
> maintained, and continue to grow. Can't say the same for Lisp, sadly.
Which is the reason why CL-Gardeners was born I gather.
JC Helary

Don Cohen wrote:
>
> > I am very saddened to have to report that I am forced to punt CLISP
> > in favor of Python. The SQL libraries actually work, what a relief
> > and those triple quotes are kinda cute. Although my code is not as
> > nice, working libraries take me a long way. [insert rant ad lib]
>
> Which libraries, what DB's, what platform are you trying to use?
> I did manage to get odbc-cl to work, and it's pretty straight forward
> to use something like the mysql command from clisp.
> Clsql seems not to work at the moment, though I don't know why.
> I bet it wouldn't be too hard to fix.
Clsql relies on uffi. Cffi's uffi compatibility module has some problems.
I submitted a patch to Luís Oliveira and he seems favorable to incorporating it.
Clsql itself has problems with it's library loader code (find-and-load-foreign-library)
if you are on windows or cygwin, but it's only one function that needs to be reworked.
If you're on windows you also have to make sure that all library C code is recompiled into
Dlls (not unix shared libraries). If you are using Cygwin you also may need to rename the
Dlls so that they have an .so extension. Also, Clsql's make files have to be tweaked unless
you are running on a major platform. Oh, and Clsql's loop macro doesn't work on Clisp (but
it's not needed). A bunch of silly little details, to be sure, but once you know what
needs a little lovin' it isn't that hard (except figuring out that cffi/uffi patch--that
was hard). I use Clsql to connect to Mysql 4.1 using Clsql's mysql package. And, as you've
probably guessed by now, I'm running on cygwin, which made it that much more interesting.
I agree that the state of Lisp's (free) libraries need more attention. That's why I think
the Python, Perl, PHP, and Ruby communities are so vibrant -- their libraries are mature,
maintained, and continue to grow. Can't say the same for Lisp, sadly.
Happy trails.

On May 20, 2006, at 10:58 PM, Don Cohen wrote:
> Clsql seems not to work at the moment, though I don't know why.
> I bet it wouldn't be too hard to fix.
Were you trying this with hacked UFFI, or CFFI's uffi-compat?
--
Stephen Compall
http://scompall.nocandysw.com/blog

From: don-sourceforge-xx@... (Don Cohen)
Date: Sat, 20 May 2006 20:58:57 -0700
Clsql seems not to work at the moment, though I don't know why.
I bet it wouldn't be too hard to fix.
I thought so too but was mistaken.
Peace
--Devon
/~\
\ / Health Care
X not warfare
/ \
Dubya won the digital vote
Kerry won the popular vote

> I am very saddened to have to report that I am forced to punt CLISP
> in favor of Python. The SQL libraries actually work, what a relief
> and those triple quotes are kinda cute. Although my code is not as
> nice, working libraries take me a long way. [insert rant ad lib]
Which libraries, what DB's, what platform are you trying to use?
I did manage to get odbc-cl to work, and it's pretty straight forward
to use something like the mysql command from clisp.
Clsql seems not to work at the moment, though I don't know why.
I bet it wouldn't be too hard to fix.

> I know there is a utility for wrapping regular function in AllegroCL. From a
> user perspective it works somewhat similar to :around method in a gen-function.
This is what trace does. See the options in impnotes 25.2.5
Not as fancy as advice was in interlisp, but normally adequate.
> It is a nice utility, when it is needed.
> Does anything like this wrapping utility exists for CLisp (or other CL's) ?
> http://www.cs.cmu.edu/~dst/Lisp/dtrace/dtrace.generic
Looks pretty much like trace.
> Could you possibly replace the function in the same way that
> trace-function does (by setf-ing (symbol-function <whatever>) with a
> lambda)?
This is the fall back position if you're not satisfied with what you
have - write your own.

< Hi,
< I know there is a utility for wrapping regular function in AllegroCL. From a
< user perspective it works somewhat similar to :around method in a gen-function.
< It is a nice utility, when it is needed.
< Does anything like this wrapping utility exists for CLisp (or other CL's) ?
I'm by no means that skilled in CL (for now ;-)), but I guess this might be useful:
http://www.cs.cmu.edu/~dst/Lisp/dtrace/dtrace.generic
Could you possibly replace the function in the same way that trace-function does (by setf-ing (symbol-function <whatever>) with a lambda)?
Jakub Hegenbart

Hi,
I know there is a utility for wrapping regular function in AllegroCL. From a
user perspective it works somewhat similar to :around method in a gen-function.
It is a nice utility, when it is needed.
Does anything like this wrapping utility exists for CLisp (or other CL's) ?

I am very saddened to have to report that I am forced to punt CLISP
in favor of Python. The SQL libraries actually work, what a relief
and those triple quotes are kinda cute. Although my code is not as
nice, working libraries take me a long way. [insert rant ad lib]
Peace
--Devon
/~\
\ / Health Care
X not warfare
/ \
Dubya won the digital vote
Kerry won the popular vote

Joerg-Cyril Hoehle writes:
> Don Cohen writes:
>>Now maybe I can try to build a current CVS clisp.
>>It would be useful to mark states that are thought to be relatively
>>stable and buildable.
> Do you mean "mark releases" or snapshots of CVS?
>
> As far as releases, 2.39 seems like a perfect candidate for "stable": When you look at the ChangeLog or NEWS, you see that there have been only bugfixes, except from the MS-windows I/O speed improvements and some SAVEINITMEM change.
> http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/src/NEWS
>
> Pro release:
> o MacOS non-blocking socket fix - enough reason on its own for a release?
> o sigsegv fixes
>
> However, time is not ripe for a release IMHO. YMMV:
> 1. There are several portabiliy bugs open.
>
> 2. I don't have access to a compile farm (firewall). The minimal thing
> to do prior to release is to test CVS whether it builds an passes tests
> on a lot more platforms than my MS-VC6 and Linux/i386 builds (and
> Yaroslav's mingw, and Dave's Fedora Core etc.).
>
> I'd really appreciate if users with access to some compile farm (either sourceforge or whatever is under the Sun) would build and test CLISP now and then on a lot of different architectures and report errors.
> Who volunteers?
>
If that can help, I can set up tests on GNU/Linux X86 and PPC,
Windows XP, MacOS X and NetBSD x86. In all case, I run mcclim with
clisp under GNU/Linux and MaxOSX with the current clisp stable
release.
> BTW, providing patches is even better than reporting errors :-)
>
Hum, don't know for this part, but if I can... :)
[...]
Thanks a lot for your great work!
best regards,
Philippe
--
Philippe Brochard <hocwp@...>
http://hocwp.free.frhttp://common-lisp.net/project/cl-wav-synth/
-=-= http://www.gnu.org/home.fr.html =-=-

> Don Cohen writes:
> >Now maybe I can try to build a current CVS clisp.
> >It would be useful to mark states that are thought to be relatively
> >stable and buildable.
> Do you mean "mark releases" or snapshots of CVS?
I meant CVS.
> As far as releases, 2.39 seems like a perfect candidate for "stable":
2.39? I've never heard of it before? It's not listed in
http://clisp.sourceforge.net/
If it has my two favorite bugs fixed from .38 (server not allowing
connections from all IP's and socket-status blocking when it
shouldn't) and not too many more introduced I'll use it.
BTW, are there entries in the test suite for those?
I know the only way to find out what other bugs (that affect ME) have
been introduced is to try it. That's another reason to try it.
If I thought longer strings might soon be working then I'd be tempted
to wait for that. (I'm happy that I have long strings on 64 bit though.)
> Pro release:
> o MacOS non-blocking socket fix - enough reason on its own for a release?
> o sigsegv fixes
>
> However, time is not ripe for a release IMHO. YMMV:
> 1. There are several portabiliy bugs open.
namely?
What other bugs? Are they all listed under
SourceForge Project Home
* bug reports
> 2. I don't have access to a compile farm (firewall). The minimal thing
> to do prior to release is to test CVS whether it builds an passes tests
> on a lot more platforms than my MS-VC6 and Linux/i386 builds (and
> Yaroslav's mingw, and Dave's Fedora Core etc.).
I only have a few different linux versions.
> Thanks for reporting the broken links, BTW. Although we could
> check links ourselves, there are so many things we could do
> ourselves (given a lot of time) that I really appreciate every
> little report and especially patches.
(After all, finding bugs is what users are for, right?)
The change in SF seems to have left broken links in many different
projects.

> Maybe it's bad design?
IMO, CL standard is limited in this regard - low level read functions
can only return unsigned-bytes or characters. READ can return
different objects but it's assumed, that READ construct it from
text characters. I don't think READ-CHAR returns special struct when
called to *keyboard-stream* is a big problem, either.
> behaviour may be good enough. But I fear portability bugs for
> software developed on UNIX, which errors out on MS-Windows when
> receiving individual shift or ctrl key events. Or from MS-Windows to
> UNIX, when the software says "press shift key to continue..." (which
> remembers me of a pinball/flipper game on C64 which IIRC used the
> shift keys -- which CLISP does not differentiate ;)
I wonder if there's just one unix or windows useful lisp program that
uses SCREEN. I once wrote one, I even reached to kinda window oriented
library and line-editing which worked in unix and windows, but haven't
finished.
Using API is powerful approach indeed, but it's too consuming.
Modify of program (remap shifts to something else on unix or just eat
shifts and controls silently on unix) is far more simple task, given
one have sources, which is true as we are talking about GNU programs.
--
Best regards,
Arseny

Hoehle, Joerg-Cyril wrote:
> Jack Unrue wrote:
>> On 5/19/06, Arseny Slobodyuk <ampy@...> wrote:
>>>> I don't think read-char-no-hang is intended to be stretched so
>>>> far as to return entities that are not considered characters, and
>>>> thus Shift/Ctrl would never appear in an input stream.
>>> It is not read-char-no-hang what's stretched, it's ok, the
>>> *keyboard-input* stream is such a special kind of stream.
>> OK. I misunderstood the issue, thanks for clarifying.
>
> IIRC Pascal Bourguignon filed a bug report that READ-CHAR (and thus READ-CHAR-NO-HANG etc.) may return something that's not a CHARACTER. This can happen when used with *KEYBOARD-INPUT*: INPUT-CHARACTER is not of type CHARACTER, as impnotes documents.
> So indeed, one can consider READ-CHAR to be stretched in CLISP.
> However, I find this point irrelevant. When using WITH-KEYBOARD, which is clearly non-portable, assumptions about portable code do not hold.
> Of course, this is debatable.
> I'm not worried by having READ-CHAR return a non-character on weird kinds of streams. Maybe it's bad design?
>
> From a historc perspective, it could be argued that CLISP's INPUT-CHARACTER is heritage from CLtL1 where character with BITs and FONT existed. This thing has been removed from ANSI-CL. So the question becomes: did CLtL1 consider the shift key as a character? But does CLtL1 matter these days?
>
> Back to the bug at hand, the current summary is:
> o portability is valuable
> o using platform specific features is equally valuable
>
> One way to reconcile both may be via Jack Unrue's argument that if you want platform specific behaviour, call platform specific API functions. Not functions from CLISP which try to be available (with variations) on all platforms.
> OTOH, documentation of the different behaviour may be good enough. But I fear portability bugs for software developed on UNIX, which errors out on MS-Windows when receiving individual shift or ctrl key events. Or from MS-Windows to UNIX, when the software says "press shift key to continue..." (which remembers me of a pinball/flipper game on C64 which IIRC used the shift keys -- which CLISP does not differentiate ;)
IMO, the WITH-KEYBOARD/*KEYBOARD-INPUT* design is a bit strange as an
interface. Things seem very overloaded with standard methods returning
non-standard data types when wrapped with WITH-KEYBOARD.
I'd rather have a method on *STANDARD-INPUT* or *TERMINAL-IO* called
RAW-MODE (perhaps a SETF-able boolean property) that puts the stream
into raw mode and simply allows raw access to characters, insuring that
any line discipline on the terminal is disabled. On UNIX, this would
turn off all buffering, and special terminal character processing (C-C,
C-Z, C-\, etc.). On Windows, this would basically just. I'd also like a
IS-A-TTY-P method to operate as expected on *STANDARD-INPUT/OUTPUT* and
*TERMINAL-IO*. I would have a WITH-RAW-TERMINAL macro that wraps that to
set/unset the raw mode. I like this better than just WITH-KEYBOARD
because WITH-KEYBOARD forces the terminal into raw mode for a whole
branch of the call-graph, where sometimes it's nice to be able to go
into/out-of raw mode at various places in the program.
Then, I'd like a layer above that which handles Termios processing.
Right now, that's on by default in WITH-KEYBOARD mode, which is nice
sometimes, but a bother at others. Perhaps the user creates a TERMIOS
object and gives it a stream to process, then pulls characters out the
TERMIOS object. The Termios object would then provide a bunch of methods
for handling cursor movement, clearing lines, etc., effectively removing
any need for the programmer to have to deal with the abstract terminal.
Then, for platforms like Windows where you can almost assume that the
keyboard is an attached hardware device, I'd have another very,
low-level, raw interface that allows you to detect specific keypresses,
including keys that don't have ASCII codes such as
shift/control/alt/etc. I'd make things like KEY events that represent
KEY strokes, but also low-level KEY-DOWN and KEY-UP events to detect
things at the raw button level. But, IMO, that's a separate interface,
specific to platforms that expose that level of functionality and
separate from the APIs that provide a terminal interface in the
traditional sense, since the two models are really quite different.
In short, separate out different concepts. The current API is usable but
it mixes a lot of functionality and even layers of the same
functionality together. Tease those things apart. Make the concepts
modular and allow them to be composed to do what the programmer wants.
Then it's a simple matter to develop convenience functions or macros
that implement high-level concepts.
Just my $0.02 (or maybe $0.04 given the amount I wrote ;-) ).
-- Dave

Jack Unrue wrote:
>On 5/19/06, Arseny Slobodyuk <ampy@...> wrote:
>> > I don't think read-char-no-hang is intended to be stretched so
>> > far as to return entities that are not considered characters, and
>> > thus Shift/Ctrl would never appear in an input stream.
>>
>> It is not read-char-no-hang what's stretched, it's ok, the
>> *keyboard-input* stream is such a special kind of stream.
>
>OK. I misunderstood the issue, thanks for clarifying.
IIRC Pascal Bourguignon filed a bug report that READ-CHAR (and thus =
READ-CHAR-NO-HANG etc.) may return something that's not a CHARACTER. =
This can happen when used with *KEYBOARD-INPUT*: INPUT-CHARACTER is not =
of type CHARACTER, as impnotes documents.
So indeed, one can consider READ-CHAR to be stretched in CLISP.
However, I find this point irrelevant. When using WITH-KEYBOARD, which =
is clearly non-portable, assumptions about portable code do not hold.
Of course, this is debatable.
I'm not worried by having READ-CHAR return a non-character on weird =
kinds of streams. Maybe it's bad design?
From a historc perspective, it could be argued that CLISP's =
INPUT-CHARACTER is heritage from CLtL1 where character with BITs and =
FONT existed. This thing has been removed from ANSI-CL. So the =
question becomes: did CLtL1 consider the shift key as a character? But =
does CLtL1 matter these days?
Back to the bug at hand, the current summary is:
o portability is valuable
o using platform specific features is equally valuable
One way to reconcile both may be via Jack Unrue's argument that if you =
want platform specific behaviour, call platform specific API functions. =
Not functions from CLISP which try to be available (with variations) =
on all platforms.
OTOH, documentation of the different behaviour may be good enough. But =
I fear portability bugs for software developed on UNIX, which errors =
out on MS-Windows when receiving individual shift or ctrl key events. =
Or from MS-Windows to UNIX, when the software says "press shift key to =
continue..." (which remembers me of a pinball/flipper game on C64 =
which IIRC used the shift keys -- which CLISP does not differentiate ;)
Regards,
J=F6rg H=F6hle.

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details