Hi folks!
I'm trying to understand, how can I (in most painless way) deliver my
lisp application to end user, run it on their server and still be able
to maintain it (remotely or localy).
When I finish my work, I transfer lisp source to customer's server,
start lisp, load compiled sources into toplevel and run application by
hand.
Here I've got few questions:
- How can I later re-connect to this running toplevel and see what's
going on with application?
- Is there a way to do this remotely (within localy running emacs,
maybe?)?
I'm using emacs, slime and clisp on Freebsd and Linux. I'm new in lisp
world and don't know if this setup is most suited for beginner. Any
advice is very welcome.
Regards,
Damir Horvat
From: Sam Steingold
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <u651ar8er.fsf@gnu.org>
> * Damir Horvat <·····@k-fv.bet> [2005-02-02 12:19:14 -0800]:
>
> - How can I later re-connect to this running toplevel and see what's
> going on with application?
> - Is there a way to do this remotely (within localy running emacs,
> maybe?)?
you can have you application have an open socket server and check on it
every now and then:
(let ((server (socket-server 1234)))
(loop (do-some-stuff)
(when (socket-wait server 0) ; 0 timeout == poll
(with-open-stream (socket (socket-accept server))
(format socket "status: ~s" (current-application-status))
(loop (case (read socket)
(status (print-status))
(eval (print (eval (read socket)))) ; security hole!
((quit bye exit) (return)))))))) ; finish remote interaction
<http://clisp.cons.org/impnotes/socket.html>
<http://clisp.cons.org/impnotes/quickstart.html>
<http://clisp.cons.org/impnotes/app-dev.html>
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Save your burned out bulbs for me, I'm building my own dark room.
From: Edi Weitz
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <usm4e3cve.fsf@agharta.de>
On 2 Feb 2005 12:19:14 -0800, ·····@x-si.org (Damir Horvat) wrote:
> I'm trying to understand, how can I (in most painless way) deliver
> my lisp application to end user, run it on their server and still be
> able to maintain it (remotely or localy).
>
> When I finish my work, I transfer lisp source to customer's server,
> start lisp, load compiled sources into toplevel and run application
> by hand.
> Here I've got few questions:
>
> - How can I later re-connect to this running toplevel and see what's
> going on with application?
You use something like detachtty:
<http://www.cliki.net/detachtty>
Or you can build a simple REPL into your Lisp application that accepts
TCP connections.
> - Is there a way to do this remotely (within localy running emacs,
> maybe?)?
With detachtty you can of course do this remotely (via ssh), you can
also use ssh directly or to forward ports securely. With Emacs? Hmm,
not sure, maybe with tramp.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Wed, 02 Feb 2005 21:50:29 +0100, <········@agharta.de> wrote:
> On 2 Feb 2005 12:19:14 -0800, ·····@x-si.org (Damir Horvat) wrote:
>>
>> - How can I later re-connect to this running toplevel and see what's
>> going on with application?
>
> You use something like detachtty:
>
> Or you can build a simple REPL into your Lisp application that accepts
> TCP connections.
Now that is such a nifty and handy idea, I would tend to expect
someone to have put together a small tool for such a purpose. Am I
right?
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
From: Edi Weitz
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <u8y604bah.fsf@agharta.de>
On Mon, 07 Feb 2005 15:40:19 GMT, GP lisper <········@CloudDancer.com> wrote:
> Now that is such a nifty and handy idea, I would tend to expect
> someone to have put together a small tool for such a purpose. Am I
> right?
Search for START-LISP-CONNECTION-LISTENER in the CMUCL sources. The
Eclipse[1] sources also contain something like that - maybe it's based
on the same facility.
Cheers,
Edi.
[1] Eclipse the X window manager written in CL, not Eclipse the Java
thingamabob.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
GP lisper <········@CloudDancer.com> writes:
> On Wed, 02 Feb 2005 21:50:29 +0100, <········@agharta.de> wrote:
[...]
>> Or you can build a simple REPL into your Lisp application that accepts
>> TCP connections.
>
> Now that is such a nifty and handy idea, I would tend to expect
> someone to have put together a small tool for such a purpose. Am I
> right?
See:
Serve Lisp requests
http://www.cons.org/cmucl/doc/lispserver.html
Paolo
--
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
On Mon, 07 Feb 2005 17:39:35 +0100, <·······@mclink.it> wrote:
> GP lisper <········@CloudDancer.com> writes:
>
>> On Wed, 02 Feb 2005 21:50:29 +0100, <········@agharta.de> wrote:
> [...]
>>> Or you can build a simple REPL into your Lisp application that accepts
>>> TCP connections.
>>
>> Now that is such a nifty and handy idea, I would tend to expect
>> someone to have put together a small tool for such a purpose. Am I
>> right?
>
> See:
>
> Serve Lisp requests
> http://www.cons.org/cmucl/doc/lispserver.html
Thanks for the link, however I couldn't get it to work in 19a.
···@phoenix:~ }lisp
CMU Common Lisp 19a, running on phoenix
With core: /usr/local/lib/cmucl-19a/lib/lisp.core
Dumped on: Tue, 2004-11-09 00:49:10-08:00 on phoenix
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2004/04/14 03:32:47
Simple Streams
Gray Streams Protocol Support
CLX X Library MIT R5.02
CL-USER> (setf mp::*idle-process* mp::*initial-process*)
#<Process Initial {58003F75}>
CL-USER> (mp::start-lisp-connection-listener :port 6789 :password "fred")
#<Process Anonymous {58032A25}>
CL-USER>
;;; Started lisp connection listener on port 6789 with password fred
==============================
···@phoenix:~ }telnet localhost 6789
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Enter password: fred
Connection closed by foreign host.
=============================
That is from a cmucl binary release, not locally built.
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
From: Edi Weitz
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <uhdkl7q27.fsf@agharta.de>
On Wed, 09 Feb 2005 14:22:03 GMT, GP lisper <········@CloudDancer.com> wrote:
> ==============================
>
> ···@phoenix:~ }telnet localhost 6789
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> Enter password: fred
> Connection closed by foreign host.
>
> =============================
Try
"fred"
instead of
fred
because the function uses READ to read the password. I submitted a
patch to cmucl-devel a while ago because I think this behaviour isn't
very intuitive but it somehow fell through.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: John Thingstad
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <opslxu410rpqzri1@mjolner.upc.no>
On Wed, 09 Feb 2005 15:42:24 +0100, Edi Weitz <········@agharta.de> wrote:
> On Wed, 09 Feb 2005 14:22:03 GMT, GP lisper <········@CloudDancer.com>
> wrote:
>
>> ==============================
>>
>> ···@phoenix:~ }telnet localhost 6789
>> Trying 127.0.0.1...
>> Connected to localhost.
>> Escape character is '^]'.
>> Enter password: fred
>> Connection closed by foreign host.
>>
>> =============================
>
> Try
>
> "fred"
>
> instead of
>
> fred
>
> because the function uses READ to read the password. I submitted a
> patch to cmucl-devel a while ago because I think this behaviour isn't
> very intuitive but it somehow fell through.
>
> Cheers,
> Edi.
>
Isn't using read on fields bad form..
Seems like a exploit waiting to happen!
What is stopping you from entering a program at the prompt?
This seems almost as bad as the buffer overflow exploits of C.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: John Thingstad
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <opslxvxqt8pqzri1@mjolner.upc.no>
On Wed, 09 Feb 2005 17:37:39 +0100, John Thingstad
<··············@chello.no> wrote:
> On Wed, 09 Feb 2005 15:42:24 +0100, Edi Weitz <········@agharta.de>
> wrote:
>
>> On Wed, 09 Feb 2005 14:22:03 GMT, GP lisper <········@CloudDancer.com>
>> wrote:
>>
>>> ==============================
>>>
>>> ···@phoenix:~ }telnet localhost 6789
>>> Trying 127.0.0.1...
>>> Connected to localhost.
>>> Escape character is '^]'.
>>> Enter password: fred
>>> Connection closed by foreign host.
>>>
>>> =============================
>>
>> Try
>>
>> "fred"
>>
>> instead of
>>
>> fred
>>
>> because the function uses READ to read the password. I submitted a
>> patch to cmucl-devel a while ago because I think this behaviour isn't
>> very intuitive but it somehow fell through.
>>
>> Cheers,
>> Edi.
>>
>
> Isn't using read on fields bad form..
> Seems like a exploit waiting to happen!
> What is stopping you from entering a program at the prompt?
> This seems almost as bad as the buffer overflow exploits of C.
>
If you don't believe me check out this link
http://free.freespeech.org/xaa/xaa0005.txt
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> On Wed, 09 Feb 2005 17:37:39 +0100, John Thingstad
> <··············@chello.no> wrote:
>
> > On Wed, 09 Feb 2005 15:42:24 +0100, Edi Weitz <········@agharta.de>
> > wrote:
> >
> >> On Wed, 09 Feb 2005 14:22:03 GMT, GP lisper
> >> <········@CloudDancer.com> wrote:
> >>
> >>> ==============================
> >>>
> >>> ···@phoenix:~ }telnet localhost 6789
> >>> Trying 127.0.0.1...
> >>> Connected to localhost.
> >>> Escape character is '^]'.
> >>> Enter password: fred
> >>> Connection closed by foreign host.
> >>>
> >>> =============================
> >>
> >> Try
> >>
> >> "fred"
> >>
> >> instead of
> >>
> >> fred
> >>
> >> because the function uses READ to read the password. I submitted a
> >> patch to cmucl-devel a while ago because I think this behaviour isn't
> >> very intuitive but it somehow fell through.
> >>
> >> Cheers,
> >> Edi.
> >>
> >
> > Isn't using read on fields bad form..
> > Seems like a exploit waiting to happen!
> > What is stopping you from entering a program at the prompt?
> > This seems almost as bad as the buffer overflow exploits of C.
> >
>
> If you don't believe me check out this link
> http://free.freespeech.org/xaa/xaa0005.txt
Either I don't have the eyes in front of the holes or you meant another link...
In the mean time, you may try:
#.(loop (print (eval (read))))
as password, if *READ-EVAL* is not set to NIL.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot. don't bother saving your artefacts.
From: John Thingstad
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <opslxxbuttpqzri1@mjolner.upc.no>
On 09 Feb 2005 18:10:35 +0100, Pascal Bourguignon <····@mouse-potato.com>
wrote:
> Either I don't have the eyes in front of the holes or you meant another
> link...
>
> In the mean time, you may try:
>
> #.(loop (print (eval (read))))
>
> as password, if *READ-EVAL* is not set to NIL.
>
Nearsighted as I am, (peephole optimation), I see your point.
But my point was that we should have a library along the line of
parse_float, parse_integer (exists) and so on.
This prevents nasty surprises.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
On Wed, 09 Feb 2005 15:42:24 +0100, <········@agharta.de> wrote:
> On Wed, 09 Feb 2005 14:22:03 GMT, GP lisper <········@CloudDancer.com> wrote:
>
>> ==============================
>>
>> ···@phoenix:~ }telnet localhost 6789
>> Trying 127.0.0.1...
>> Connected to localhost.
>> Escape character is '^]'.
>> Enter password: fred
>> Connection closed by foreign host.
>>
>> =============================
>
> Try
>
> "fred"
>
> instead of
>
> fred
>
> because the function uses READ to read the password. I submitted a
> patch to cmucl-devel a while ago because I think this behaviour isn't
> very intuitive but it somehow fell through.
Well, the current allows:
(mp::start-lisp-connection-listener :port 6789 :password "take a long walk")
and
...
Enter password: "take a long walk"
CMU Common Lisp 19a, running on phoenix
Thanks!
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
From: Marco Baringer
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <m2is542p3w.fsf@soma.local>
GP lisper <········@CloudDancer.com> writes:
> On Wed, 02 Feb 2005 21:50:29 +0100, <········@agharta.de> wrote:
>> Or you can build a simple REPL into your Lisp application that accepts
>> TCP connections.
>
> Now that is such a nifty and handy idea, I would tend to expect
> someone to have put together a small tool for such a purpose. Am I
> right?
it's called SLIME :)
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
"Marco Baringer" <··@bese.it> writes:
> >> Or you can build a simple REPL into your Lisp application that accepts
> >> TCP connections.
> >
> > Now that is such a nifty and handy idea, I would tend to expect
> > someone to have put together a small tool for such a purpose. Am I
> > right?
>
> it's called SLIME :)
I was using SLIME for my recent victory:
http://www.david-steuber.com/~david/Lisp/OSX/Carbon/OpenGL/hello-opengl.png
SLIME was attached to a running Carbon application that I am hacking
on with OpenMCL. One small step for me. The next is to see about
UFFIifying my OpenGL code so that I can build portable code on top of
it.
This setup is pretty good, but getting thrown into the debugger by the
GUI thread is death.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
"Marco Baringer" <··@bese.it> writes:
> GP lisper <········@CloudDancer.com> writes:
>
> > On Wed, 02 Feb 2005 21:50:29 +0100, <········@agharta.de> wrote:
>
> >> Or you can build a simple REPL into your Lisp application that accepts
> >> TCP connections.
> >
> > Now that is such a nifty and handy idea, I would tend to expect
> > someone to have put together a small tool for such a purpose. Am I
> > right?
>
> it's called SLIME :)
I'm using SLIME to connect to a Lisp running in a screen session.
Works great! But, is there a way to make create-swank-server to listen
on a specific interface?
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Damir Horvat wrote:
> Hi folks!
>
> I'm trying to understand, how can I (in most painless way) deliver my
> lisp application to end user, run it on their server and still be able
> to maintain it (remotely or localy).
>
> When I finish my work, I transfer lisp source to customer's server,
> start lisp, load compiled sources into toplevel and run application by
> hand.
> Here I've got few questions:
>
> - How can I later re-connect to this running toplevel and see what's
> going on with application?
> - Is there a way to do this remotely (within localy running emacs,
> maybe?)?
Just do a (swank:create-swank-server) from within the image (at the repl
or simply do it at startup) and you just M-x slime-connect to the
running image. Works great :) I usually tunnel the swank connecton
through ssh.
> I'm using emacs, slime and clisp on Freebsd and Linux. I'm new in lisp
> world and don't know if this setup is most suited for beginner. Any
> advice is very welcome.
I might suggest using a native compiler like CMUCL or SBCL. They have a
lot to offer over clisp. To deliver an SBCL application, i create an
image that contains all my complied code, and do 'sbcl --core my-core
--load my-init.lisp'. Having everthing compiled into the image saves on
startup time. then i have scripts to start the lisp server from my
/etc/init.d. All very simple, although my SBCL images are huge (50 mb).
drewc
>
> Regards,
> Damir Horvat
From: Sam Steingold
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <usm4epmgi.fsf@gnu.org>
> * drewc <·····@evsg.pbz> [2005-02-02 22:48:08 +0000]:
>
> I might suggest using a native compiler like CMUCL or SBCL.
Indeed - especially if floating point is important.
I used CLISP to process gigabytes of data in memory (on amd64)
quite successfully.
> They have a lot to offer over clisp.
CLISP also has a lot to offer over CMUCL and SBCL. YMMV.
> To deliver an SBCL application, i create an image that contains all my
> complied code, and do 'sbcl --core my-core --load my-init.lisp'.
CLISP can do that too.
<http://clisp.cons.org/impnotes/image.html>
> Having everthing compiled into the image saves on startup time.
indeed.
> then i have scripts to start the lisp server from my /etc/init.d.
CLISP can do that too.
<http://clisp.cons.org/impnotes/quickstart.html>
> All very simple, although my SBCL images are huge (50 mb).
CLISP images are 10% of that (not that it matters these days).
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Do not tell me what to do and I will not tell you where to go.
Sam Steingold <···@gnu.org> writes:
> > * drewc <·····@evsg.pbz> [2005-02-02 22:48:08 +0000]:
> >
> > I might suggest using a native compiler like CMUCL or SBCL.
>
> Indeed - especially if floating point is important.
> I used CLISP to process gigabytes of data in memory (on amd64)
> quite successfully.
>
> > They have a lot to offer over clisp.
>
> CLISP also has a lot to offer over CMUCL and SBCL. YMMV.
Yes, memory useage is worth taking into account when developing
server-side apps. However, is multithreading as efficent in clisp
as in the cmucl implementation?
> > All very simple, although my SBCL images are huge (50 mb).
>
> CLISP images are 10% of that (not that it matters these days).
I think it matters (if that matters :). Even on server-side
software.
--
Oyvin
Oyvin Halfdan Thuv <·····@remove.spam.oyvins.net> writes:
> > CLISP also has a lot to offer over CMUCL and SBCL. YMMV.
>
> Yes, memory useage is worth taking into account when developing
> server-side apps. However, is multithreading as efficent in clisp
> as in the cmucl implementation?
Is something inexistant as efficient as something existant?
Yes. Anything can be said of something inexistant.
That's the only drawback of clisp: no multithreading.
--
__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.
Pascal Bourguignon <····@mouse-potato.com> writes:
> Oyvin Halfdan Thuv <·····@remove.spam.oyvins.net> writes:
> > > CLISP also has a lot to offer over CMUCL and SBCL. YMMV.
> >
> > Yes, memory useage is worth taking into account when developing
> > server-side apps. However, is multithreading as efficent in clisp
> > as in the cmucl implementation?
>
> Is something inexistant as efficient as something existant?
> Yes. Anything can be said of something inexistant.
>
> That's the only drawback of clisp: no multithreading.
Oh, thats not good. I was hoping that multithreading was "optional",
and not inexistent :(
--
Oyvin
From: Wade Humeniuk
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <2zrMd.98794$Ob.64510@edtnps84>
Oyvin Halfdan Thuv wrote:
>
>
> Oh, thats not good. I was hoping that multithreading was "optional",
> and not inexistent :(
>
It seems that some people have forgot how to use fork.
Wade
From: John Thingstad
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <opslmoiwwvpqzri1@mjolner.upc.no>
On Thu, 03 Feb 2005 15:37:34 GMT, Wade Humeniuk
<··················@telus.net> wrote:
> Oyvin Halfdan Thuv wrote:
>
>> Oh, thats not good. I was hoping that multithreading was "optional",
>> and not inexistent :(
>>
>
> It seems that some people have forgot how to use fork.
>
> Wade
It seems some peaple forget how expensive spawning new proceses is
compared to
lightweight threading. (share process and memory.)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: Wade Humeniuk
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <lIrMd.98826$Ob.54330@edtnps84>
John Thingstad wrote:
>
> It seems some peaple forget how expensive spawning new proceses is
> compared to
> lightweight threading. (share process and memory.)
>
How many microseconds does it take? But seriously I am tainted
by past memories of the first releases of Solaris where we found
forking processes was much faster than threads. I am
also pretty sure that in some OS models there are things called
light-weight processes that are used to implement processes and
threads. My memory is very fuzzy though, and who cares these
days? throw another Gig of memory in the sucker and add 4 more
processors.
Wade
From: John Thingstad
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <opslmwtv1npqzri1@mjolner.upc.no>
On Thu, 03 Feb 2005 15:47:29 GMT, Wade Humeniuk
<··················@telus.net> wrote:
> John Thingstad wrote:
>
>> It seems some peaple forget how expensive spawning new proceses is
>> compared to
>> lightweight threading. (share process and memory.)
>>
>
> How many microseconds does it take? But seriously I am tainted
> by past memories of the first releases of Solaris where we found
> forking processes was much faster than threads. I am
> also pretty sure that in some OS models there are things called
> light-weight processes that are used to implement processes and
> threads. My memory is very fuzzy though, and who cares these
> days? throw another Gig of memory in the sucker and add 4 more
> processors.
>
> Wade
Depends on your system. Unixes have a relatively quick context switch.
Still sharing data is much more difficult. And remember fork actually
copies the process before exec overwrites it. So starting the
multi-processing is much slower. (I think there is a kludge that get's
around this but I forget the details.) This matters if you are forking
a new process for each web request.
Under windows process overhead is much higher so if you want to
port the code to Windows you are in for a nasty surprise.
(However there is OS thread support which is rather fast.)
The first version of Apache for windows tried spawning (a windows term)
a new process for each request. This works well under Unix but
the performance under Windows was unacceptable.
The newer Apache 2 uses a threading pool and is much faster.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: Wade Humeniuk
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <syvMd.1241$Ox3.1013@clgrps13>
John Thingstad wrote:
>
>
> Depends on your system. Unixes have a relatively quick context switch.
> Still sharing data is much more difficult. And remember fork actually
> copies the process before exec overwrites it.
Though my recollection is that "data" copying does not acually happen
until system pages are actually accessed and that "code" pages are
shared. Files descriptors, pipes, etc. are cloned in some fashion, and
besides that I am not sure.
Wade
From: Wade Humeniuk
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <kGvMd.99268$Ob.41901@edtnps84>
Wade Humeniuk wrote:
> John Thingstad wrote:
>
>>
>>
>> Depends on your system. Unixes have a relatively quick context switch.
>> Still sharing data is much more difficult. And remember fork actually
>> copies the process before exec overwrites it.
>
>
> Though my recollection is that "data" copying does not acually happen
> until system pages are actually accessed and that "code" pages are
> shared. Files descriptors, pipes, etc. are cloned in some fashion, and
> besides that I am not sure.
>
It actually seems more complex than that. If you peruse
fork
vfork
rfork
in the FreeBSD man pages
http://www.freebsd.org/cgi/man.cgi
Hmmm...
Wade
From: John Thingstad
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <opslm3hlylpqzri1@mjolner.upc.no>
On Thu, 03 Feb 2005 20:18:24 GMT, Wade Humeniuk
<··················@telus.net> wrote:
> Wade Humeniuk wrote:
>> John Thingstad wrote:
>>
>>>
>>>
>>> Depends on your system. Unixes have a relatively quick context switch.
>>> Still sharing data is much more difficult. And remember fork actually
>>> copies the process before exec overwrites it.
>> Though my recollection is that "data" copying does not acually happen
>> until system pages are actually accessed and that "code" pages are
>> shared. Files descriptors, pipes, etc. are cloned in some fashion, and
>> besides that I am not sure.
>>
>
> It actually seems more complex than that. If you peruse
>
> fork
> vfork
> rfork
>
> in the FreeBSD man pages
>
> http://www.freebsd.org/cgi/man.cgi
>
>
> Hmmm...
>
> Wade
yes.. I metioned there was some cluge..
Is it just me or is the Unix process model very strange...
(seems what you wanna do is a vfork though)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: Cameron MacKinnon
Subject: UNIX garbage collection (was Details on delivering and managing application)
Date:
Message-ID: <s5CdnVl3iMOJL5_fRVn-iQ@golden.net>
John Thingstad wrote:
> Is it just me or is the Unix process model very strange...
It's just you. Here's how modern UNIX garbage collectors work:
Processes create new memory pools (and new processes) by forking copies
of themselves. A fork actually creates a new set of page tables
(physical/virtual address maps with protection information) for the
child process, but pointing to the same physical memory as the parent
process. Both processes' page tables are modified so that if either
process attempts to write to read/write areas of memory, an operating
system trap will first copy that page, so each process now owns a
distinct version of it.
The above is a very memory efficient way of running multiple copies of a
program, sharing all of the code megabytes and, often, a large
percentage of the data megabytes. Still, copying all of the page tables
for your 30MB Lisp image is a bit inefficient if the child process will
immediately morph into a shell to run an external command. So there is a
special variants of the fork syscall which tells the OS not to bother
setting up a complete copy of the address space, as the plan is to
exec() and not need the work done.
A traditional UNIX daemon process reads a bunch of configuration
information upon startup, then waits for requests. For each incoming
request, it forks, so all of the code and configuration data is shared
between the daemon and its children, but each child's subsequent
modifications of memory (for purposes unique to the request it is
processing) are isolated. When the request is completed, the child
exits, and the operating system reaps all of the modified pages. It's
pool based, free-the-whole-pool-at-the-end garbage collection.
Up spake Wade Humeniuk:
> I am also pretty sure that in some OS models there are things called
> light-weight processes that are used to implement processes and
> threads.
ISTR that in _Modern Operating Systems_ Andy Tanenbaum asserts that
"lightweight process" and "thread" are synonymous. I got the impression
that different research groups coined different terms. Unfortunately
I'm at work and my bookshelf is at home.
--
-trent
"Shut up," she explained.
Trent Buck <·········@tznvy.pbz> writes:
> Up spake Wade Humeniuk:
> > I am also pretty sure that in some OS models there are things called
> > light-weight processes that are used to implement processes and
> > threads.
>
> ISTR that in _Modern Operating Systems_ Andy Tanenbaum asserts that
> "lightweight process" and "thread" are synonymous. I got the impression
> that different research groups coined different terms. Unfortunately
> I'm at work and my bookshelf is at home.
They are, but sometimes the implementations are really different. For
example, either the process does its own threading (using a run-time
library or no), or the OS provides the processes with threading, doing
itself the scheduling, possibly identifying each thread with a
different PID even (eg. not far from mere processes sharing all their
memory).
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
On 2005-02-03 16:37:34, Wade Humeniuk wrote:
> Oyvin Halfdan Thuv wrote:
>> Oh, thats not good. I was hoping that multithreading was "optional",
>> and not inexistent :(
>
> It seems that some people have forgot how to use fork.
I only use fork when there is no spoon. ;-)
(Sorry, could not resist)
On 2005-02-03 00:32:29, Sam Steingold wrote:
>> * drewc <·····@evsg.pbz> [2005-02-02 22:48:08 +0000]:
>> They have a lot to offer over clisp.
>
> CLISP also has a lot to offer over CMUCL and SBCL. YMMV.
You can add that Paul Graham used CLISP for ViaWeb and that CLISP
outperforms Perl, Ruby, PHP, and Java(?), which are other candidates
for web programming.
"Stefan Scholl" <······@no-spoon.de> schrieb im Newsbeitrag
······················@parsec.no-spoon.de...
> On 2005-02-03 00:32:29, Sam Steingold wrote:
> >> * drewc <·····@evsg.pbz> [2005-02-02 22:48:08 +0000]:
> >> They have a lot to offer over clisp.
> >
> > CLISP also has a lot to offer over CMUCL and SBCL. YMMV.
>
> You can add that Paul Graham used CLISP for ViaWeb and that CLISP
> outperforms Perl, Ruby, PHP, and Java(?), which are other candidates
> for web programming.
Ooops. I didn't expect this. I decided not to use CLISP for my web
programming because it lacks multiprocessing. I wondered how people change a
running web application without at least one (background) process. I'm sure
Paul Graham did this. How do you solve this? Write an own REPL? Serving 2
socket connections?
I had a short look on portable allegroserve as well as areneida. In CLISP
they 'lock' the REPL. Starting a function starts the server. This function
won't return unless the server is shut down.
Currently I use LispWorks + mod_lisp + Apache.
Any hint is appreciated :)
Andreas
On 2005-02-04 00:07:25, Andreas Thiele wrote:
> "Stefan Scholl" <······@no-spoon.de> schrieb im Newsbeitrag
>> You can add that Paul Graham used CLISP for ViaWeb and that CLISP
>> outperforms Perl, Ruby, PHP, and Java(?), which are other candidates
>> for web programming.
>
> Ooops. I didn't expect this. I decided not to use CLISP for my web
> programming because it lacks multiprocessing. I wondered how people change a
> running web application without at least one (background) process. I'm sure
> Paul Graham did this. How do you solve this? Write an own REPL? Serving 2
> socket connections?
There's some information on <http://www.paulgraham.com/vwfaq.html>.
But not enough to answer your question.
> Currently I use LispWorks + mod_lisp + Apache.
I use SBCL + mod_lisp + TBNL + Apache.
"Stefan Scholl" <······@no-spoon.de> schrieb im Newsbeitrag
·····················@parsec.no-spoon.de...
...
>
> There's some information on <http://www.paulgraham.com/vwfaq.html>.
> But not enough to answer your question.
>
...
Thanks, an interesting link.
Andreas
drewc wrote:
> /etc/init.d. All very simple, although my SBCL images are huge (50 mb).
Hey, do not post HTML to a newsgroup, your 5mb came out as "50 mb".
kt
ps. plz tell me SBCL images are not really 50mb. :)
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
>
>
> drewc wrote:
>
>> /etc/init.d. All very simple, although my SBCL images are huge (50 mb).
>
>
> Hey, do not post HTML to a newsgroup, your 5mb came out as "50 mb".
>
> kt
>
> ps. plz tell me SBCL images are not really 50mb. :)
>
lol :). One of my applications actually has a 55mb image, but there is a
lot in there. Usually my SBCL images run about 30mb. You can apparently
strip a lot out from that, but 50mb is not really all that big to me,
when compared with java and whatnot.
The image that runs lisp.tech.coop was using 25mb resident this morning
when i checked it. that machine also runs apache, postgres, postfix,
courier-imapd and a reverse proxy, all in 128mb ram (in total the
machine has about 20mb free memory and has not touched the swap.)
CPU time is not so cheap on the server-side, and i like my apps to run
FAST (part of the reason for choosing lisp in the first place). SBCL can
compile some fast code. (clisp, not so fast), so i don't mind the
resident memory usage at all. Most of it gets swapped out anyway, so
it's really just disk space.
drewc wrote:
> lol :). One of my applications actually has a 55mb image, but there is a
> lot in there. Usually my SBCL images run about 30mb. You can apparently
> strip a lot out from that, but 50mb is not really all that big to me,
> when compared with java and whatnot.
OK, so Moore's Law benefits us developers, not the users? Awesome!!
> i like my apps to run
> FAST (part of the reason for choosing lisp in the first place).
I do believe we have a milestone.
:)
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
From: Rahul Jain
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <87sm4bof92.fsf@nyct.net>
drewc <·····@rift.com> writes:
> Most of it gets swapped out anyway, so it's really just disk space.
Actually, the core is mmap()ed, so it's not even swapped out. The pages
of it just gets purged if the VMM wants space for other stuff and read
back in when accessed. Also, multiple invocations using the same core
share the core's loaded pages.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> Actually, the core is mmap()ed, so it's not even swapped out. The pages
> of it just gets purged if the VMM wants space for other stuff and read
> back in when accessed. Also, multiple invocations using the same core
> share the core's loaded pages.
That i didn't know, thanks for the info! I can stop trying to cram
everything into a single process now :)
drewc
>
From: John Thingstad
Subject: Re: Details on delivering and managing application
Date:
Message-ID: <opsllef9kppqzri1@mjolner.upc.no>
On Wed, 02 Feb 2005 22:48:08 GMT, drewc <·····@rift.com> wrote:
> /etc/init.d. All very simple, although my SBCL images are huge (50 mb).
>
> drewc
>
In these Java days 50 Mb is small.
Consider that Java needs 48 mb's to even run...
You are delivering a application that starts fast and
consumes half the memory of a Tomcat application.
So from a certain point a viev those are great figures.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad wrote:
> On Wed, 02 Feb 2005 22:48:08 GMT, drewc <·····@rift.com> wrote:
>
>> /etc/init.d. All very simple, although my SBCL images are huge (50 mb).
>>
>> drewc
>>
>
> In these Java days 50 Mb is small.
> Consider that Java needs 48 mb's to even run...
> You are delivering a application that starts fast and
> consumes half the memory of a Tomcat application.
> So from a certain point a view
I am thinking "Beluga whale"...
> those are great figures.
Should we submit a paper to the next lightweight languages conference?
<sob>
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
drewc wrote:
> Just do a (swank:create-swank-server) from within the image (at the
repl
> or simply do it at startup) and you just M-x slime-connect to the
> running image. Works great :) I usually tunnel the swank connecton
> through ssh.
Ok, you're a bit to fast for me...
I successfully started emacs, done M-x slime, opened another buffer
(C-x 2) and connected to this REPL running on 127.0.0.1:4005 with M-x
slime-connect. Is this it?
Can I just start clisp and start swank in it (not from emacs)?
Thanks,
Damir
·····@x-si.org wrote:
> I successfully started emacs, done M-x slime, opened another buffer
> (C-x 2) and connected to this REPL running on 127.0.0.1:4005 with M-x
> slime-connect. Is this it?
>
> Can I just start clisp and start swank in it (not from emacs)?
Yup. You just start your lisp (using detachtty is a good idea), load the
swank package, and then you can start a swank server on any port you
want. you then connect using M-x slime-connect.
the incantation is as follows :
;;load up swank
* (asdf:operate 'asdf:load-op 'swank)
; loading system definition from
#P"/usr/share/common-lisp/systems/swank.asd"
; into #<PACKAGE "ASDF4031">
; registering #<SYSTEM :SWANK {91AE6A1}> as SWANK
[snip]
;;start up the server
* (swank:create-swank-server 4006)
;; Swank started at port: 4006.
4006
*
When i do ths remotely i tunnel swank through ssh.
drewc
> Thanks,
> Damir
>
drewc <·····@rift.com> writes:
> Damir Horvat wrote:
> > going on with application?
> > - Is there a way to do this remotely (within localy running emacs,
> > maybe?)?
>
> Just do a (swank:create-swank-server) from within the image (at the
> repl or simply do it at startup) and you just M-x slime-connect to the
> running image. Works great :) I usually tunnel the swank connecton
> through ssh.
Yes, Damir, do tunnel, or ssh to the server and start a "emacs -nw"
and attach to the repl locally. Use of screen may interest you as well.
Remember to disallow access to the swak-listener (in the firewall) from
anything but localhost too. Exposing the repl to the public is a very,
very bad idea.
--
Oyvin
On 2005-02-03 11:18:26, Oyvin Halfdan Thuv wrote:
> Exposing the repl to the public is a very,
> very bad idea.
Although this could be some kind of "security through obscurity" for
some script kids. :-)