Re: debugging and serving web pages at the same time in lisp (specifically clisp)
Richard Newman <[email protected]> Thu, 5 Oct 2006 23:58:16 +0100
| Newsgroups | gmane.lisp.web |
|---|---|
| Message-ID | <[email protected]> |
--===============0021802773843225334== Content-Type: multipart/alternative; boundary=Apple-Mail-4--754213421 --Apple-Mail-4--754213421 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 5 Oct 2006, at 11:11 PM, Yin-So Chen wrote: > Thanks Ivan, Richard, and Lawrence for responding - this is all > very intriguing. Sounds like CGI is the only sure way to go with > Clisp if I am looking to run multiple concurrent sessions? Depends. If you're limited to clisp, perhaps. > Also - Lawrence, I am assuming you have a way to capture your > changes in life system back into source code form easily? I've > heard the save-image capability, but would think you still need to > have source code so you can rebuild image again if you can, is this > correct? Generally, you make changes in the source, then evaluate your changes in the REPL. If you're lucky, things will work out :) > Richard - you meant you can (trace) h-r-r in SBCL, right? In > CLISP, once (host-serve-events) is called, it blocks REPL, so I > can't do trace just-in-time without killing off the lisp session (I > can't tell whether there is a way to accept a control-character > within araneida). Hmm. On SBCL serve-event does not block the REPL; I don't use clisp. > BTW Ivan - I did find a blog article by BillClementson discussing > the same topic at http://bc.tech.coop/blog/040224.html. > > Based on all the descriptions so far, I am wondering if the > development "methodology" is completely different with lisp. Yes, it is. > I so far lived in the compile-link-install-test world, where most > of syntactic bugs and some semantic bugs are caught during the > compile phase. And that leaves the bugs that are harder to find in > live systems. Of course, examining trace files is horrible > compared to live traces, but I've found that a good majority of the > bugs found in production requires non-trivial changes (even with > decent abstraction layers) and hence my experience is that without > going through another test cycle, changing is extremely risky. You verify things on a test server, if you can, or by local testing of some kind... then make the change in the running server without a restart. > Unless... there is a way to quickly verify and rollback changes > easily in lisp? Do it locally. > It would be great if someone with experiences in both worlds (I am > sure many of you do ;p) can share some light on whether lisp's > development cycle is completely different than c/c++/java/c# > world. I've started to write lisp code, but my limited experience > does not allow me to grok this yet. Yes, it is. You don't ever need to restart, unless you're testing startup code! I've had systems which I've maintained, running, for 6 months; I keep the source up to date on-disk, and they've shut down and restarted without any difficulties. You're also not limited to a compile-run-test-edit cycle to find out if you're right; you can work with live data in a REPL, so you're much more likely to be right, and you don't ever have the shutdown/ restart delay. -R --Apple-Mail-4--754213421 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 <HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = -khtml-line-break: after-white-space; "><BR><DIV><DIV>On=A0 5 Oct 2006, = at 11:11 PM, Yin-So Chen wrote:</DIV><BR = class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite">Thanks = Ivan, Richard, and Lawrence for responding - this is all very = intriguing.=A0 Sounds like CGI is the only sure way to go with Clisp if = I am looking to run multiple concurrent = sessions?=A0<BR></BLOCKQUOTE><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>Depends. If you're limited = to clisp, perhaps.</DIV><BR><BLOCKQUOTE type=3D"cite">Also - Lawrence, I = am assuming you have a way to capture your changes in life system back = into source code form easily?=A0 I've heard the save-image capability, = but would think you still need to have source code so you can rebuild = image again if you can, is this correct?=A0<BR></BLOCKQUOTE><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>Generally, you make changes = in the source, then evaluate your changes in the REPL. If you're lucky, = things will work out :)</DIV><BR><BLOCKQUOTE type=3D"cite">Richard - you = meant you can (trace) h-r-r in SBCL, right?=A0 In CLISP, once = (host-serve-events) is called, it blocks REPL, so I can't do trace = just-in-time without killing off the lisp session (I can't tell whether = there is a way to accept a control-character within = araneida).=A0<BR></BLOCKQUOTE><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>Hmm. On SBCL serve-event = does not block the REPL; I don't use clisp.</DIV><BR><BLOCKQUOTE = type=3D"cite">BTW Ivan - I did find a blog article by BillClementson = discussing the same topic at <A = href=3D"http://bc.tech.coop/blog/040224.html">http://bc.tech.coop/blog/040= 224.html</A>. <BR><BR>Based on all the descriptions so far, I am = wondering if the development "methodology" is completely different with = lisp.=A0 <BR></BLOCKQUOTE><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>Yes, it = is.</DIV><BR><BLOCKQUOTE type=3D"cite">I so far lived in the = compile-link-install-test world, where most of syntactic bugs and some = semantic bugs are caught during the compile phase. And that leaves the = bugs that are harder to find in live systems.=A0 Of course, examining = trace files is horrible compared to live traces, but I've found that a = good majority of the bugs found in production requires non-trivial = changes (even with decent abstraction layers) and hence my experience is = that without going through another test cycle, changing is extremely = risky.=A0<BR></BLOCKQUOTE><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>You verify things on a test = server, if you can, or by local testing of some kind... then make the = change in the running server without a restart.</DIV><BR><BLOCKQUOTE = type=3D"cite">Unless... there is a way to quickly verify and rollback = changes easily in lisp?=A0<BR></BLOCKQUOTE><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>Do it = locally.</DIV><BR><BLOCKQUOTE type=3D"cite">It would be great if someone = with experiences in both worlds (I am sure many of you do ;p) can share = some light on whether lisp's development cycle is completely different = than c/c++/java/c# world.=A0 I've started to write lisp code, but my = limited experience does not allow me to grok this = yet.=A0<BR></BLOCKQUOTE><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>Yes, it is. You don't ever = need to restart, unless you're testing startup code! I've had systems = which I've maintained, running, for 6 months; I keep the source up to = date on-disk, and they've shut down and restarted without any = difficulties.</DIV><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>You're also not limited to = a compile-run-test-edit cycle to find out if you're right; you can work = with live data in a REPL, so you're much more likely to be right, and = you don't ever have the shutdown/restart delay.</DIV><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>-R</DIV></DIV><BR></BODY></HT= ML>= --Apple-Mail-4--754213421-- --===============0021802773843225334== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lispweb mailing list [email protected] http://www.red-bean.com/mailman/listinfo/lispweb --===============0021802773843225334==--