Re: CLISP GSoC project ideas
Sam Steingold <[email protected]> Thu, 08 Mar 2018 12:47:07 -0500
| Newsgroups | gmane.lisp.clisp.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Bruno, > * Bruno Haible <[email protected]> [2018-02-20 01:06:47 +0100]: > > Before we offer a GSoC project to a specific volunteer, I think we > should collect ideas and see how promising they are. > > What are criteria for promising ideas? > - Don't require too much learning about clisp internals. > - Be feasible. > - Require 2-4 months of work. I disagree. The idea of SoC is not to give us free labor for 2-4 months. The idea is to get a long-term contributor. Thus learning is fine. The only requirement is that there should be a "deliverable" that can be done in 2-4 months, but the expectation is that the student will stay with us longer term and, hopefully, do another SoC next year. The bottom line: SoC should be fostering LTR, not one-night-stands ;-) > * Remaining work on multithreading: too much learning, too big (2 > man-years) Any progress on this path would be welcome. E.g., making the C core thread-safe could be already useful. > * Multithreaded hash tables: IMO pointless, locking is the way to go Locking can be prohibitively expensive. > * Octave binding: learning and sizing probably ok, but is it > appealing? Octave is just an example. Bindings to any useful library would be useful. > * IEEE NaNs and infinities: too small (2 man-weeks) > * SSL bindings: too small (2-4 man-weeks) For someone just learning the stuff - not necessarily. There is plenty of opportunities to get bogged down in GC-safety ;-) > * Embed clisp: too big (1 man-year) I thought this is actually a pretty small task for someone who understands this shared library mess. I don't so I might be wildly wrong here. What does it involve beyond turning lisp.a into lisp.so? > * Compilation to JVM: already done by Clojure, pointless for clisp Clojure is not ANSI CL. > * Source-level debugging with breakpoints in SLIME > (or is this already done? I don't know) This is a good idea. > * Enhance the compiler to do inlining of local functions > - IMO infeasible without rewriting the compiler frontend to include data > flow analysis. How come this has been in the man page todo list since times immemorial? > * Integrate Robert Strandh's SICL compiler frontend with clisp's > bytecode backend ... or port any other major CL project to CLISP. Thanks. -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561 http://steingoldpsychology.com http://www.childpsy.net http://www.memritv.org http://thereligionofpeace.com http://think-israel.org Be sure brain is in gear before engaging mouth. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ clisp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/clisp-devel