Re: debugging and serving web pages at the same time in lisp (specifically clisp)
"Yin-So Chen" <[email protected]> Fri, 6 Oct 2006 23:15:50 -0700
| Newsgroups | gmane.lisp.web |
|---|---|
| Message-ID | <[email protected]> |
--===============2203995626905175768== Content-Type: multipart/alternative; boundary="----=_Part_131469_5749869.1160201750771" ------=_Part_131469_5749869.1160201750771 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks to all for responding. I definitely have gotten some valuable pointers here and I will investigate more as I gain more experience developing in lisp. Thanks, yinso On 10/5/06, Richard Newman <[email protected]> wrote: > > > 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 > > ------=_Part_131469_5749869.1160201750771 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks to all for responding. I definitely have gotten some valuable pointers here and I will investigate more as I gain more experience developing in lisp.<br><br>Thanks,<br>yinso <br><br><div><span class="gmail_quote">On 10/5/06, <b class="gmail_sendername">Richard Newman</b> <<a href="mailto:[email protected]">[email protected]</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div style=""><br><div><span class="q"><div>On 5 Oct 2006, at 11:11 PM, Yin-So Chen wrote:</div><br><blockquote type="cite">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? <br></blockquote><div><br></div></span><div>Depends. If you're limited to clisp, perhaps.</div><span class="q"><br><blockquote type="cite">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? <br></blockquote><div><br></div></span><div>Generally, you make changes in the source, then evaluate your changes in the REPL. If you're lucky, things will work out :)</div><span class="q"><br><blockquote type="cite">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). <br></blockquote><div><br></div></span><div>Hmm. On SBCL serve-event does not block the REPL; I don't use clisp.</div><span class="q"><br><blockquote type="cite">BTW Ivan - I did find a blog article by BillClementson discussing the same topic at <a href="http://bc.tech.coop/blog/040224.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://bc.tech.coop/blog/040224.html</a>. <br><br>Based on all the descriptions so far, I am wondering if the development "methodology" is completely different with lisp. <br></blockquote><div><br></div></span><div>Yes, it is.</div><span class="q"><br><blockquote type="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. 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. <br></blockquote><div><br></div></span><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><span class="q"><br><blockquote type="cite"> Unless... there is a way to quickly verify and rollback changes easily in lisp? <br></blockquote><div><br></div></span><div>Do it locally.</div><span class="q"><br><blockquote type="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. I've started to write lisp code, but my limited experience does not allow me to grok this yet. <br></blockquote><div><br></div></span><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></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></div><div>-R</div></div><br></div> </blockquote></div><br> ------=_Part_131469_5749869.1160201750771-- --===============2203995626905175768== 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 --===============2203995626905175768==--