Folks,
I have done completed a CL application -- and it runs well :).
It is a web based Cable ISP solution.
I am using CMUCL on GNU/Linux (debian). Using detachtty I can
run the lisp in the background, but somehow it is refusing to run
through the init scripts (rc2.d) at boot time. This is vital as the
system has to restart itself on reboot. detachtty logs sey that the
application started successfully but then termintated.
Any pointers?
thanks
--
quasi
http://abhijit-rao.tripod.com/
q u a s i <·········@yahoo.com> writes:
> I am using CMUCL on GNU/Linux (debian). Using detachtty I can
> run the lisp in the background, but somehow it is refusing to run
> through the init scripts (rc2.d) at boot time. This is vital as the
> system has to restart itself on reboot. detachtty logs sey that the
> application started successfully but then termintated.
> Any pointers?
Hard to say, but maybe you simply start it too early? (e.g. before
the network is up)
--
(espen)
On Wed, 14 Jan 2004 10:03:35 +0100, Espen Vestre
<·····@*do-not-spam-me*.vestre.net> wrote:
>q u a s i <·········@yahoo.com> writes:
>
>> I am using CMUCL on GNU/Linux (debian). Using detachtty I can
>> run the lisp in the background, but somehow it is refusing to run
>> through the init scripts (rc2.d) at boot time. This is vital as the
>> system has to restart itself on reboot. detachtty logs sey that the
>> application started successfully but then termintated.
>> Any pointers?
>
>Hard to say, but maybe you simply start it too early? (e.g. before
>the network is up)
I think not .. S99 should be late 'nuff I guess... umm... Is there
any other way to start a lisp application on Unix at startup other
than using detachtty ?
--
quasi
http://abhijit-rao.tripod.com/
q u a s i <·········@yahoo.com> writes:
> On Wed, 14 Jan 2004 10:03:35 +0100, Espen Vestre
> <·····@*do-not-spam-me*.vestre.net> wrote:
>
> >q u a s i <·········@yahoo.com> writes:
> >
> >> I am using CMUCL on GNU/Linux (debian). Using detachtty I can
> >> run the lisp in the background, but somehow it is refusing to run
> >> through the init scripts (rc2.d) at boot time. This is vital as the
> >> system has to restart itself on reboot. detachtty logs sey that the
> >> application started successfully but then termintated.
> >> Any pointers?
> >
> >Hard to say, but maybe you simply start it too early? (e.g. before
> >the network is up)
>
> I think not .. S99 should be late 'nuff I guess... umm... Is there
> any other way to start a lisp application on Unix at startup other
> than using detachtty ?
You culd run it as a free standing binary (where possible), or clisp
in a shebang script ("#!/usr/bin/env clisp"). But then you wouldn't be
able to reattach to the running program.
Bj�rn
According to q u a s i <·········@yahoo.com>:
> I think not .. S99 should be late 'nuff I guess... umm... Is there
> any other way to start a lisp application on Unix at startup other
> than using detachtty ?
On FreeBSD, I use daemontools to start detachtty to start CMUCL, in a
FreeBSD jail.
Here's the daemontools run script:
#!/bin/sh
exec 2>&1
exec /usr/local/bin/setuidgid lispapp \
/usr/local/bin/detachtty \
--no-detach \
--dribble-file /pkg/lispapp/data/dribble \
/pkg/lispapp/data/tlsock \
/usr/local/bin/lisp \
-init /pkg/lispapp/cmucl-init.lisp
Daemontools itself is started by the rc system. Indeed, it is the only
extra rc thing that I start in this particular jail.
--
Ng Pheng Siong <····@netmemetic.com>
http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL
q u a s i <·········@yahoo.com> writes:
> Folks,
> I have done completed a CL application -- and it runs well :).
> It is a web based Cable ISP solution.
> I am using CMUCL on GNU/Linux (debian). Using detachtty I can
> run the lisp in the background, but somehow it is refusing to run
> through the init scripts (rc2.d) at boot time. This is vital as the
> system has to restart itself on reboot. detachtty logs sey that the
> application started successfully but then termintated.
> Any pointers?
As far as I know, there are two common methods to have a detatched
CMUCL: using detachtty, and using screen. With detatchtty, you
detatch just the CMUCL instance itself, and when you want to do
development work, you can attach a running Emacs to it, and detatchtty
won't interfere with the Emacs<->CMUCL communication. Personally, I
use screen, mostly because I've been using it since before detatchtty
was around. With screen, you detatch the entire CMUCL+Editor session.
So, for example, if you use ILISP, you'd start Emacs and ILISP and
CMUCL and your application, then finally detatch the whole thing.
With Hemlock, you just run CMUCL and your app, then detatch, and you
can later attach to it with Hemlock.
To do what you want with screen, you'd use the -m -d options.
( If you do run Emacs under screen, be sure to set a less crazy escape
key -- I use ^\ )
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On 14 Jan 2004 12:05:43 -0800, ···@famine.OCF.Berkeley.EDU (Thomas F.
Burdick) wrote:
>q u a s i <·········@yahoo.com> writes:
>
>> Folks,
>> I have done completed a CL application -- and it runs well :).
>> It is a web based Cable ISP solution.
>> I am using CMUCL on GNU/Linux (debian). Using detachtty I can
>> run the lisp in the background, but somehow it is refusing to run
>> through the init scripts (rc2.d) at boot time. This is vital as the
>> system has to restart itself on reboot. detachtty logs sey that the
>> application started successfully but then termintated.
>> Any pointers?
>
>As far as I know, there are two common methods to have a detatched
>CMUCL: using detachtty, and using screen.
Thanks. I will look up screen. Have you run a lisp application at
system *startup* using screen? Because detachtty works if run from a
tty -- I need to start a production server at startup. The machine is
remote and needs to recover from reboots.
> With detatchtty, you
>detatch just the CMUCL instance itself, and when you want to do
>development work, you can attach a running Emacs to it, and detatchtty
>won't interfere with the Emacs<->CMUCL communication. Personally, I
>use screen, mostly because I've been using it since before detatchtty
>was around. With screen, you detatch the entire CMUCL+Editor session.
>So, for example, if you use ILISP, you'd start Emacs and ILISP and
>CMUCL and your application, then finally detatch the whole thing.
>With Hemlock, you just run CMUCL and your app, then detatch, and you
>can later attach to it with Hemlock.
>
>To do what you want with screen, you'd use the -m -d options.
>
>( If you do run Emacs under screen, be sure to set a less crazy escape
> key -- I use ^\ )
--
quasi
http://abhijit-rao.tripod.com/
q u a s i <·········@yahoo.com> writes:
> On 14 Jan 2004 12:05:43 -0800, ···@famine.OCF.Berkeley.EDU (Thomas F.
> Burdick) wrote:
>
> >q u a s i <·········@yahoo.com> writes:
> >
> >> Folks,
> >> I have done completed a CL application -- and it runs well :).
> >> It is a web based Cable ISP solution.
> >> I am using CMUCL on GNU/Linux (debian). Using detachtty I can
> >> run the lisp in the background, but somehow it is refusing to run
> >> through the init scripts (rc2.d) at boot time. This is vital as the
> >> system has to restart itself on reboot. detachtty logs sey that the
> >> application started successfully but then termintated.
> >> Any pointers?
> >
> >As far as I know, there are two common methods to have a detatched
> >CMUCL: using detachtty, and using screen.
>
> Thanks. I will look up screen. Have you run a lisp application at
> system *startup* using screen?
Yes, like I said, the -m -d option to screen does what you want.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
q u a s i <·········@yahoo.com> writes:
> Thanks. I will look up screen. Have you run a lisp application at
> system *startup* using screen? Because detachtty works if run from a
> tty -- I need to start a production server at startup. The machine is
> remote and needs to recover from reboots.
(Wading in late, haven't seen the start of the thread)
If it's running from an rc script, it probably has /dev/console
available to it (or possibly even already open) and you could do
redirection judo to get this somewhere that detachtty expects it.
I had the same kind of pain you describe getting things to start on
boot when I was using screen (before I wrote detachtty) as you're
describing with detachtty. If you do find an answer or workaround,
please update the detachtty page at cliki and I'll add it to the
documentation next time I release a new version.
-dan
--
http://web.metacircles.com/ - Open Source software development and support
In article <··································@4ax.com>, q u a s i wrote:
> On 14 Jan 2004 12:05:43 -0800, ···@famine.OCF.Berkeley.EDU (Thomas F.
> Burdick) wrote:
>
>>q u a s i <·········@yahoo.com> writes:
>>
>>> Folks,
>>> I have done completed a CL application -- and it runs well :).
>>> It is a web based Cable ISP solution.
>>> I am using CMUCL on GNU/Linux (debian). Using detachtty I can
>>> run the lisp in the background, but somehow it is refusing to run
>>> through the init scripts (rc2.d) at boot time. This is vital as the
>>> system has to restart itself on reboot. detachtty logs sey that the
>>> application started successfully but then termintated.
>>> Any pointers?
>>
>>As far as I know, there are two common methods to have a detatched
>>CMUCL: using detachtty, and using screen.
>
> Thanks. I will look up screen. Have you run a lisp application at
> system *startup* using screen? Because detachtty works if run from a
> tty -- I need to start a production server at startup. The machine is
> remote and needs to recover from reboots.
I have done exactly this for some time now, and it works well. I only
use the machine remotly, and I have not had any problems with it.
I use Solaris/CMUCL, but I don't think there will be a difference on Linux.
--
Gisle S�lensminde
Computational biology unit, University of Bergen, Norway
Email: ·····@cbu.uib.no
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> As far as I know, there are two common methods to have a detatched
> CMUCL: using detachtty, and using screen.
You mean there's no way to write a totally non-interactive cmucl
application? Does cmucl always insist on having a terminal to talk
to? It's a tribute to the power of unix that there's a workaround,
but really, it shouldn't be necessary.
Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > As far as I know, there are two common methods to have a detatched
> > CMUCL: using detachtty, and using screen.
>
> You mean there's no way to write a totally non-interactive cmucl
> application? Does cmucl always insist on having a terminal to talk
> to? It's a tribute to the power of unix that there's a workaround,
> but really, it shouldn't be necessary.
I said "common", not possible. CMUCL itself doesn't expect a
terminal, so you can just send its stdin/stdout/stderr to /dev/null or
wherever you want. Most Lispers want to be able to get to the Lisp
prompt for their app, and using a detatched terminal is the best way
to do it.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On Sat, Jan 17, 2004 at 03:09:31PM -0500, Scott Schwartz wrote:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > As far as I know, there are two common methods to have a detatched
> > CMUCL: using detachtty, and using screen.
>
> You mean there's no way to write a totally non-interactive cmucl
> application? Does cmucl always insist on having a terminal to talk
> to? It's a tribute to the power of unix that there's a workaround,
> but really, it shouldn't be necessary.
There are ways, but you are missing the point that the OP wanted it
running interactively. Unlike the typical Unix script/app, there are
distinct advantages to having access to an interactive session with
lisp, even if you keep it running detached most of the time.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> There are ways, but you are missing the point that the OP wanted it
> running interactively.
Are you sure? He said "It is a web based Cable ISP solution", and
that he used detachtty to get it to run "in the background". That
sounds like a non-interactive daemon to me.
From: Christopher C. Stacy
Subject: Re: problem running CL application at boot time
Date:
Message-ID: <uisj9n4wc.fsf@news.dtpq.com>
>>>>> On 17 Jan 2004 23:48:45 -0500, Scott Schwartz ("Scott") writes:
Scott> Matthew Danish <·······@andrew.cmu.edu> writes:
>> There are ways, but you are missing the point that the OP wanted it
>> running interactively.
Scott> Are you sure? He said "It is a web based Cable ISP solution", and
Scott> that he used detachtty to get it to run "in the background". That
Scott> sounds like a non-interactive daemon to me.
It sounds like a "server application" to me, and most such applications
include some administrative functions. Thos are usually made available
on additional restricted ports or web pages, or from seperate command-line
programs which are seperate from the running server image.
Wouldn't it be nice not to necessarily have to implement the extra command
and control and communication system that most such servers require?
Having an "interactive" connection to the running image through a Lisp listener
is just another way of communicating with the server, like a special control port
or IPC or whatever. Exccept that the Lisp one is (by default) infinitely flexible,
and you get the "command reader" and oher goodies for free with all Lisp programs.
And when something goes wrong in the server application, isn't it nice to be able
to communicate directly with the running image, explore the live backtrace of the
thread that blew up, and possibly even fix up and proceed from the error?
Especially when you're still developing the application?
q u a s i <·········@yahoo.com> writes:
> Folks,
> I have done completed a CL application -- and it runs well :).
> It is a web based Cable ISP solution.
> I am using CMUCL on GNU/Linux (debian). Using detachtty I can
> run the lisp in the background, but somehow it is refusing to run
> through the init scripts (rc2.d) at boot time. This is vital as the
> system has to restart itself on reboot. detachtty logs sey that the
> application started successfully but then termintated.
> Any pointers?
Look at the C source of detachtty. Notice that it wants to grab the
parameters from the controlling terminal on startup. This info is used
in setting up the parameters for the pty used by the server. Your
startup script tries to start detachtty without a controlling terminal.
Two solutions spring to mind.
1) redirect stdin,stdout,stderr to some virtual terminal (e.g.
/dev/tty9). To do this you must make sure that the user that
detachtty runs under has read-write access to the tty.
2) Grab the tty parameters you want once, and hardcode them into
detachtty. I am actually using this, but it feels kind of
silly.
Here is my diff for detachtty:
--
diff -u detachtty-6/detachtty.c detachtty-6-changed/detachtty.c
--- detachtty-6/detachtty.c 2002-09-18 00:41:36.000000000 +0200
+++ detachtty-6-changed/detachtty.c 2004-01-14 13:03:14.000000000 +0100
@@ -115,11 +115,173 @@
}
- /* this assumes we're started from a shell. would be smart to
- default 80x24 or something if we can't do this */
- tcgetattr(0,&my_termios);
- ioctl(0,TIOCGWINSZ,&my_winsize);
-
+ /* Hacked with some hardcoded values for the failing
+ case. Added debug output for when we start under
+ a good terminal*/
+ if(tcgetattr(0,&my_termios) == -1){
+ fprintf(stderr,"Error getting tc attrs\n");
+
+/* A gadzillion of values to choose from. Uncomment one
+ set or cook your own */
+/* from rxvt and then some: */
+ my_termios.c_iflag=BRKINT|IGNPAR|ICRNL|IXON|IMAXBEL;
+/* don't know where these came from */
+/* my_termios.c_oflag=OPOST|ONLCR; */
+/* from emacs comint: */
+/* my_termios.c_iflag=BRKINT|IGNPAR|IXON; */
+/* my_termios.c_oflag=OPOST; */
+ my_termios.c_oflag=OPOST;
+
+my_termios.c_cc[0]=0X3;
+my_termios.c_cc[1]=0X1C;
+my_termios.c_cc[2]=0X7F;
+my_termios.c_cc[3]=0X15;
+my_termios.c_cc[4]=0X4;
+my_termios.c_cc[5]=0;
+my_termios.c_cc[6]=0X1;
+my_termios.c_cc[7]=0;
+my_termios.c_cc[8]=0X11;
+my_termios.c_cc[9]=0X13;
+my_termios.c_cc[10]=0X1A;
+my_termios.c_cc[11]=0;
+my_termios.c_cc[12]=0X12;
+my_termios.c_cc[13]=0XF;
+my_termios.c_cc[14]=0X17;
+my_termios.c_cc[15]=0X16;
+my_termios.c_cc[16]=0;
+my_termios.c_cc[17]=0X13;
+my_termios.c_cc[18]=0X40;
+my_termios.c_cc[19]=0;
+my_termios.c_cc[20]=0;
+my_termios.c_cc[21]=0;
+my_termios.c_cc[22]=0;
+my_termios.c_cc[23]=0;
+my_termios.c_cc[24]=0;
+my_termios.c_cc[25]=0;
+my_termios.c_cc[26]=0;
+my_termios.c_cc[27]=0;
+my_termios.c_cc[28]=0;
+my_termios.c_cc[29]=0;
+my_termios.c_cc[30]=0;
+my_termios.c_cc[31]=0;
+
+
+ }else{
+/*iflag*/
+ int first=1;
+ int i=0;
+ fprintf(stderr,"my_termios.c_iflag=");
+ if(my_termios.c_iflag&IGNBRK ){
+ fprintf(stderr,"%sIGNBRK", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_iflag&BRKINT ){
+ fprintf(stderr,"%sBRKINT", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_iflag&IGNPAR ){
+ fprintf(stderr,"%sIGNPAR", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_iflag&PARMRK ){
+ fprintf(stderr,"%sPARMRK", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_iflag&INPCK ){
+ fprintf(stderr,"%sINPCK", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_iflag&ISTRIP ){
+ fprintf(stderr,"%sISTRIP", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_iflag&INLCR ){
+ fprintf(stderr,"%sINLCR", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_iflag&IGNCR ){
+ fprintf(stderr,"%sIGNCR", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_iflag&ICRNL ){
+ fprintf(stderr,"%sICRNL", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_iflag&IUCLC ){
+ fprintf(stderr,"%sIUCLC", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_iflag&IXON ){
+ fprintf(stderr,"%sIXON", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_iflag&IXANY ){
+ fprintf(stderr,"%sIXANY", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_iflag&IXOFF ){
+ fprintf(stderr,"%sIXOFF", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_iflag&IMAXBEL){
+ fprintf(stderr,"%sIMAXBEL",first? "":"|");
+ }
+ fprintf(stderr,"\n");
+/*oflags*/
+ first=1;
+fprintf(stderr,"my_termios.c_oflag=");
+ if(my_termios.c_oflag&OPOST){
+ fprintf(stderr,"%sOPOST", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_oflag&OLCUC){
+ fprintf(stderr,"%sOLCUC", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_oflag&ONLCR){
+ fprintf(stderr,"%sONLCR", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_oflag&OCRNL){
+ fprintf(stderr,"%sOCRNL", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_oflag&ONOCR){
+ fprintf(stderr,"%sONOCR", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_oflag&ONLRET){
+ fprintf(stderr,"%sONLRET", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_oflag&OFILL){
+ fprintf(stderr,"%sOFILL", first? "":"|");
+ first=0;
+ }
+ if(my_termios.c_oflag&OFDEL){
+ fprintf(stderr,"%sOFDEL", first? "":"|");
+ first=0;
+ }
+ fprintf(stderr,"\n");
+ fprintf(stderr,"NCCS=%d, cc:\n",NCCS);
+ for (i=0;i<NCCS;i++){
+ fprintf(stderr,"my_termios.c_cc[%d]=%#X;\n",i,my_termios.c_cc[i]);
+ }
+ }
+ if(ioctl(0,TIOCGWINSZ,&my_winsize) == -1){
+/* Always print this to remind us that we are using a fishy trick */
+ fprintf(stderr,"Error getting winsize\n");
+ my_winsize.ws_row=24;
+ my_winsize.ws_col=80;
+ my_winsize.ws_xpixel=0;
+ my_winsize.ws_ypixel=0;
+ }else {
+ fprintf(stderr,"Winsize r%hd c%hd xpixel%hd ypixel%hd\n"
+ ,my_winsize.ws_row
+ ,my_winsize.ws_col
+ ,my_winsize.ws_xpixel
+ ,my_winsize.ws_ypixel);
+ }
s_a.sun_family=AF_UNIX;
strncpy(s_a.sun_path,socket_path,UNIX_PATH_MAX);
s_a.sun_path[UNIX_PATH_MAX-1]='\0';
@@ -230,7 +392,7 @@
stermios.c_lflag &= ~(ECHO | ECHOE | ECHOK | ECHONL);
stermios.c_lflag|=ICANON;
- /* stermios.c_oflag &= ~(ONLCR); */
+ stermios.c_oflag &= ~(ONLCR);
/* would also turn off NL to CR/NL mapping on output */
stermios.c_cc[VERASE]=0177;
if (tcsetattr(fd, TCSANOW, &stermios) < 0)
--
H�kon Alstadheim, hjemmepappa.
q u a s i <·········@yahoo.com> writes:
> Folks,
> I have done completed a CL application -- and it runs well :).
> It is a web based Cable ISP solution.
> I am using CMUCL on GNU/Linux (debian). Using detachtty I can
> run the lisp in the background, but somehow it is refusing to run
> through the init scripts (rc2.d) at boot time. This is vital as the
> system has to restart itself on reboot. detachtty logs sey that the
> application started successfully but then termintated.
> Any pointers?
try moving it to rc3.d, at rc2.d (run level 2) the network may not be
up, if I remember correctly it should not be up. Also look at the
scripts in rc3.d and have your server start *after* all the other
things it needs to run are started.
marc
>
> thanks
>
> --
> quasi
> http://abhijit-rao.tripod.com/
On Wed, 14 Jan 2004 22:51:43 GMT, Marc Spitzer
<········@optonline.net> wrote:
>q u a s i <·········@yahoo.com> writes:
>
>> Folks,
>> I have done completed a CL application -- and it runs well :).
>> It is a web based Cable ISP solution.
>> I am using CMUCL on GNU/Linux (debian). Using detachtty I can
>> run the lisp in the background, but somehow it is refusing to run
>> through the init scripts (rc2.d) at boot time. This is vital as the
>> system has to restart itself on reboot. detachtty logs sey that the
>> application started successfully but then termintated.
>> Any pointers?
>
>try moving it to rc3.d, at rc2.d (run level 2) the network may not be
>up, if I remember correctly it should not be up. Also look at the
>scripts in rc3.d and have your server start *after* all the other
>things it needs to run are started.
The default runlevel for debian is 2 I think... and the networks are
up by the time I run my script at S99. I think it must be what H�kon
Alstadheim says, that there is no tty for detachtty to detach from ..
hehe '-) .. Beats me how people run lisp applications at startup
then. My partner must have cribbed a million times that I should have
stuck with something less esoteric than CL... ;)
--
quasi
http://abhijit-rao.tripod.com/
Hello!
q u a s i <·········@yahoo.com> wrote:
>[...]
>The default runlevel for debian is 2 I think... and the networks are
>up by the time I run my script at S99. I think it must be what H�kon
>Alstadheim says, that there is no tty for detachtty to detach from ..
>hehe '-) .. Beats me how people run lisp applications at startup
>then. My partner must have cribbed a million times that I should have
>stuck with something less esoteric than CL... ;)
Perhaps no tty at all.
.../lisp -core ... </dev/null 2>&1 | logger ...
For remote control, hack up a REPL accessible via a UNIX domain
or TCP socket.
Just an idea, haven't tried it out.
Kind regards,
Hannah.
q u a s i wrote:
> then. My partner must have cribbed a million times that I should have
> stuck with something less esoteric than CL... ;)
well, aside from this irritant, how did CL perform relative to the
alternative your partner has in mind?
Because Cl is esoteric we using Lisp for Big Things often end up
spending an unpleasant week getting over some very specific problem
(such as mastering the FFI so we can talk to some necessary C library,
or in your case working out how to run the app at boot time). But
hopefully those chores pale in comparison to the overall project.
It's like taking a 747 to cross the continent instead of driving
(without a map, since we are talking about programming). Sure, it's
easier to just hop in the car and start driving, but the hassle of
getting to/from and thru the airports on both ends is well-rewarded.
Gratuitous Aside: by the same token I wonder when the lightbulb will go
on in all those people burning hour after hour on "free" CL
implementations and they'll break down and just buy a damn copy from
someone. God forbid those evil Lisp vendors get any business!
[Damn, just when the religious flames were almost out.]
:)
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
On Fri, 16 Jan 2004 00:34:40 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>q u a s i wrote:
>
>> then. My partner must have cribbed a million times that I should have
>> stuck with something less esoteric than CL... ;)
>
>well, aside from this irritant, how did CL perform relative to the
>alternative your partner has in mind?
I had done the earlier version using C cgi. :-) CL is more fun and I
wanted to do something other than mere winston and horn examples. But
personal idiosyncrasies aside, for simple webbased application which
involve nothing more than database access and a few minor logical
decisions I put an axe on me foot fer sure. But it was fun. And who
can boast of an app in /Lisp/ in the whole of India ? :-D
>Because Cl is esoteric we using Lisp for Big Things often end up
>spending an unpleasant week getting over some very specific problem
>(such as mastering the FFI so we can talk to some necessary C library,
>or in your case working out how to run the app at boot time). But
>hopefully those chores pale in comparison to the overall project.
fer me. :-D But fer the pard, hez going nuts.
>Gratuitous Aside: by the same token I wonder when the lightbulb will go
>on in all those people burning hour after hour on "free" CL
>implementations and they'll break down and just buy a damn copy from
>someone. God forbid those evil Lisp vendors get any business!
Well when you are paid Rs.10000 (~USD 220) and you gotta pay bills
worth Rs.9000 you thank the Lord (and the developers of) for these
same free CL implementations.
:)
--
quasi
http://abhijit-rao.tripod.com/
q u a s i wrote:
> On Fri, 16 Jan 2004 00:34:40 GMT, Kenny Tilton <·······@nyc.rr.com>
> wrote:
>
>
>>q u a s i wrote:
>>
>>
>>>then. My partner must have cribbed a million times that I should have
>>>stuck with something less esoteric than CL... ;)
>>
>>well, aside from this irritant, how did CL perform relative to the
>>alternative your partner has in mind?
>
>
> I had done the earlier version using C cgi. :-) CL is more fun and I
> wanted to do something other than mere winston and horn examples. But
> personal idiosyncrasies aside, for simple webbased application which
> involve nothing more than database access and a few minor logical
> decisions I put an axe on me foot fer sure. But it was fun. And who
> can boast of an app in /Lisp/ in the whole of India ? :-D
Ah, just what Lisp needs, new territory where attitudes have not been
set in concrete.
> Well when you are paid Rs.10000 (~USD 220) and you gotta pay bills
> worth Rs.9000 you thank the Lord (and the developers of) for these
> same free CL implementations.
Good point.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
q u a s i <·········@yahoo.com> writes:
> But it was fun. And who can boast of an app in /Lisp/ in the whole
> of India ? :-D
Probably the members of the Mumbai and Bangalore user groups. See
http://alu.cliki.net/Local and share the fun!
On 16 Jan 2004 14:42:30 +0100, Henrik Motakef
<············@henrik-motakef.de> wrote:
>q u a s i <·········@yahoo.com> writes:
>
>> But it was fun. And who can boast of an app in /Lisp/ in the whole
>> of India ? :-D
>
>Probably the members of the Mumbai and Bangalore user groups. See
>http://alu.cliki.net/Local and share the fun!
The Mumbai user group (lispbom) is whole of me :)
hehehe
Lisp Is Super Power
--
quasi
http://abhijit-rao.tripod.com/
q u a s i <·········@yahoo.com> writes:
> Beats me how people run lisp applications at startup
> then.
One obvious way is to replace the login prompt on one of your VTs with
your lisp service. Just stick it in /etc/inittab. To get your
favourite environment on that terminal just run it as some other user
that you create for that service, like the SQL databases do. Then put
in that users .emacs the commands to launch your service from within
ilisp or slime.
screen or detachtty are elaborations on the inittab way of working,
not on rc scripts.
> My partner must have cribbed a million times that I should have
> stuck with something less esoteric than CL... ;)
Interactive development, debugging and redefining a running system are
highly desirable traits of CL. To get that you _need_ a way to
interact. Stop thinking that rc scripts are the way god intended
services to be run. Don't be ashamed of CL. Even if you manage to
persuade CL to start with its IO redirected to /dev/null, it does not
buy you anything because that would kill/diminish some of the major
reasons for using CL. CL needs to be able to drop into a debugger
_anytime_, or at least the non-debugged parts of your system needs
that.
"Finished" parts can be started in separate threads with
appropriate condition handlers. You can run a REPL listener on a
socket, but for handling errors you need some surefire way for CL to
contact a user.
--
H�kon Alstadheim, hjemmepappa.
Hi q u a s i,
> Folks,
> I have done completed a CL application -- and it runs well :).
> It is a web based Cable ISP solution.
> I am using CMUCL on GNU/Linux (debian). Using detachtty I can
> run the lisp in the background, but somehow it is refusing to run
> through the init scripts (rc2.d) at boot time. This is vital as the
> system has to restart itself on reboot. detachtty logs sey that the
> application started successfully but then termintated.
A small aside: You may be creating the runlevel scripts manually. A
program can do the tedious stuff for you and it's called `update-rc.d'
(refer man update-rc.d). Place any script in /etc/init.d/ and then use
update-rc.d to set the rest up. The simplest invocation is: update-rc.d
name defaults
When you want to try a different runlevel or other defaults just type
this before trying other settings: update-rc.d name -f remove
Regards,
Adam
From: A. Rogowski
Subject: Re: problem running CL application at boot time
Date:
Message-ID: <bu730c$ai7$1@mamut.aster.pl>
Adam Warner wrote:
> A small aside: You may be creating the runlevel scripts manually. A
> program can do the tedious stuff for you and it's called `update-rc.d'
> (refer man update-rc.d). Place any script in /etc/init.d/ and then use
> update-rc.d to set the rest up. The simplest invocation is: update-rc.d
> name defaults
>
> When you want to try a different runlevel or other defaults just type
> this before trying other settings: update-rc.d name -f remove
AFAIK it's Debian specific. In RedHat a tool for configuring runlevel
services is called ntsysv.
ajr.
--
A. Rogowski http://ajr.gik.pw.edu.pl
Q. Where did the names "C" and "C++" come from?
A. They were grades.
-Jerry Leichter
From: Eduardo Muñoz
Subject: Re: problem running CL application at boot time
Date:
Message-ID: <87u12ug1f1.fsf@terra.es>
* q u a s i <·········@yahoo.com>
| Folks,
| I have done completed a CL application -- and it runs well :).
| It is a web based Cable ISP solution.
| I am using CMUCL on GNU/Linux (debian). Using detachtty I can
| run the lisp in the background, but somehow it is refusing to run
| through the init scripts (rc2.d) at boot time. This is vital as the
| system has to restart itself on reboot. detachtty logs sey that the
| application started successfully but then termintated.
| Any pointers?
This is my setup. The server has survived some "accidental"
reboots :)
···@skar:~
$ cat /etc/rc2.d/S94weblisp
#!/bin/sh
su - emf -c /home/emf/bin/weblisp
···@skar:~
$ cat bin/weblisp
#!/bin/sh
dtty=/home/emf/dtty
# detachtty needs absolute paths
detachtty --dribble-file $dtty/cmulisp.dribble \
--log-file $dtty/cmulisp.log \
$dtty/cmulisp.socket \
/usr/bin/lisp -noinit \
-load "/home/emf/weblisp/weblisp" \
-eval "(weblisp:start-web)"
···@skar:~
$
Hope this helps
--
Eduardo Mu�oz | (prog () 10 (print "Hello world!")
http://213.97.131.125/ | 20 (go 10))
On 17 Jan 2004 14:17:06 +0100, Eduardo Mu�oz <······@terra.es> wrote:
>
>* q u a s i <·········@yahoo.com>
>| Folks,
>| I have done completed a CL application -- and it runs well :).
[snip]
>| application started successfully but then termintated.
>| Any pointers?
>
>
>This is my setup. The server has survived some "accidental"
>reboots :)
Worked !!!!
You are a life saver, Sir!
--
quasi
http://abhijit-rao.tripod.com/
Thanks all. The wisdom gained by me in this whole endeavour will but
put up on me website in the form of "Deploying CL applications for
Dummies", heralding an irruption of dummies into the CL fold.
'-)
On Wed, 14 Jan 2004 12:51:10 +0530, q u a s i <·········@yahoo.com>
wrote:
>Folks,
> I have done completed a CL application -- and it runs well :).
>It is a web based Cable ISP solution.
> I am using CMUCL on GNU/Linux (debian). Using detachtty I can
>run the lisp in the background, but somehow it is refusing to run
>through the init scripts (rc2.d) at boot time. This is vital as the
>system has to restart itself on reboot. detachtty logs sey that the
>application started successfully but then termintated.
> Any pointers?
>
>thanks
--
quasi
http://abhijit-rao.tripod.com/
q u a s i wrote:
> Thanks all. The wisdom gained by me in this whole endeavour will but
> put up on me website in the form of "Deploying CL applications for
> Dummies", heralding an irruption of dummies into the CL fold.
Speaking of which, the pace seems to be quickening. This n.g. has turned
into a veritable newbie Help Desk (and that is a Good Thing) when not
being spammed by people swapping vegetable recipes.
But we see in reverse the power of marketing; I stop hawking:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
...and newbies stop responding. Well, I for one am still curious about
the question of how these newbies find their way to Lisp. The 100+
responses give us a good idea, but now I am interested in seeing how the
pattern changes, such as if word of mouth starts to become the #1 Road.
Unfortunately, the cross-indexing on the sight looks broken and I have
failed to get a response on bug reports, but the Survey itself still
works, so...
Calling all Lisp family newbies! If you have not responded to the above
survey, please give doing so some thought.
kenny
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>
>
> q u a s i wrote:
>
>> Thanks all. The wisdom gained by me in this whole endeavour will but
>> put up on me website in the form of "Deploying CL applications for
>> Dummies", heralding an irruption of dummies into the CL fold.
>
>
> Speaking of which, the pace seems to be quickening. This n.g. has turned
> into a veritable newbie Help Desk (and that is a Good Thing) when not
> being spammed by people swapping vegetable recipes.
>
> But we see in reverse the power of marketing; I stop hawking:
>
> http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
>
> ...and newbies stop responding. Well, I for one am still curious about
> the question of how these newbies find their way to Lisp. The 100+
> responses give us a good idea, but now I am interested in seeing how the
> pattern changes, such as if word of mouth starts to become the #1 Road.
>
> Unfortunately, the cross-indexing on the sight looks broken and I have
> failed to get a response on bug reports, but the Survey itself still
> works, so...
>
> Calling all Lisp family newbies! If you have not responded to the above
> survey, please give doing so some thought.
>
Kenny,
Have you (or anyone) made any progress on fixing the indexing (on RTL)?
--ag
--
Artie Gold -- Austin, Texas