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