On Sun, 2008-07-06 at 20:35 -0700, Vsevolod wrote:
> I have noted, that people use to say, that Common Lisp environment
> lacks good library support. For me that doesn't seem obvious, as in my
> 3 years' experience with the language I've never encountered such
> situation.
>
> So I'd like to propose a challenge for those, who hold to this
> viewpoint, to bring up specific examples of situations, when a decent
> library for some common task couldn't be found for Common Lisp. I
> think the answers could serve as a road-map for the potential library
> developers for Lisp (and not just for my and, possibly, other people
> enlightenment :)
..I'll just write down some related thoughts..
First I'd like for something outside of Lisp to be fixed. I'd like for
GObject used by GTK+ and many other libraries to be fixed and complete,
and I'd like for GTK+ to take full use of GObject everywhere. That way
Lisp, and all other languages, will always have 100% up-to-date and
in-sync bindings to whatever GTK+ library is installed at the current
location. I do not want people to be working on Lisp bindings to
something (directly to GTK+ itself) that is "wrong" in the first place.
So fix the C libraries first, please. :)
I'd like to have "green threads" (or whatever they are called) in SBCL
so I can spawn 30 000 threads without having to think much about it. I
don't _need_ any fancy Erlang features yet; this can come later. I just
need many, many threads first.
I'd like for there to be more widgets for SymbolicWeb
( http://groups.google.com/group/symbolicweb ). This is a bit weird to
say seeing as I'm the author, but still; there is just too much work
there for one person. I'd like to pay someone a bit for this by the way,
and I do have someone working on a slider widget (think; volume control)
at the moment.
I'd like for Hunchentoot to scale better in a Comet scenario, ref.
SymbolicWeb above. I know Hans is working on a new branch of Hunchentoot
and I will attempt to do something here myself later when he is done
with the biggest re-factoring stuff. They are aiming to make changes or
"plugins" for Hunchentoot possible. Great.
I'm not so sure how I am to express this, but we need somewhat of an
SBCL daemon, or something. Something that runs all the time. Wait; maybe
we need SBCL to be a .so library, and for it to produce .so files when
compiling stuff. This is needed for things to have "0" startup time.
Maybe SBCL needs to not only have threads, but also processes. We'll be
having many processes depending on the same cl-ppcre .so library and
having only 1 shared copy of that library loaded in memory.
Maybe SBCL needs to run besides Linux and work as a scheduler or
something. SB-PROCESS:MAKE-PROCESS. I suppose we have
SB-EXT:RUN-PROGRAM, but we need shared libraries and code again. Maybe
we, well I, need SBCL-OS:
http://www.lisphacker.com/projects/sbcl-os/project-map/sbcl-os.html
http://www.lisphacker.com/projects/sbcl-os/project-map/
..but I think we need Linux (too) actually. To take care of drivers and
all. Linux has good driver support now, I'd hate to lose this.
Besides this; Lisp is just fine. There is a ton of work that needs to be
done outside Lisp though:
* Browsers need to implement JIT compilation and caching of the
resulting binaries for JavaScript. We need fast JS now.
* Which probably means we need to get MS and IE out of the way.
* ..and to do this we need JIT comp... uh, what was mentioned in the
first point.
* Browsers need to drop their C++ crap (I really despise this language)
and write the low-level stuff in C then use the fast JIT compiled
JavaScript mentioned above to Do Things. Firefox has some seriously
silly bugs that are 8 years old now, and no one is able to or want to
fix them because the code is such a damn mess.
..OK, that's all I could think of right now.
--
Lars Rune Nøstdal
http://nostdal.org/
On Jul 7, 8:21 am, Lars Rune Nøstdal <···········@gmail.com> wrote:
> I'm not so sure how I am to express this, but we need somewhat of an
> SBCL daemon, or something. Something that runs all the time. Wait; maybe
> we need SBCL to be a .so library, and for it to produce .so files when
> compiling stuff. This is needed for things to have "0" startup time.
> Maybe SBCL needs to not only have threads, but also processes. We'll be
> having many processes depending on the same cl-ppcre .so library and
> having only 1 shared copy of that library loaded in memory.
But why not use ECLS and work on making CL-PPCRE "thread-safe"?
Cheers
--
Marco
Marco Antoniotti wrote:
> But why not use ECLS and work on making CL-PPCRE "thread-safe"?
>
Would you please share what you know about CL-PPCRE thread-safety or lack of it
I know 'thread safety' has many connotations, and I haven't looked at CL-PPCRE from a thread safety
point of view.
Thanks,
-Antony
On 2008-07-07, Lars Rune N�stdal <···········@gmail.com> wrote:
> I'm not so sure how I am to express this, but we need somewhat of an
> SBCL daemon, or something. Something that runs all the time. Wait; maybe
> we need SBCL to be a .so library, and for it to produce .so files when
These two requirements sound unrelated to me.
The former means being able to load SBCL as a library into a process
that is already running, similar to JNI's invocation API. Mostly a
question of getting the memory map right, which is tricky but not
impossible (I think).
Compilation into ELF binaries sounds more like something gcl or ecl
would do. I don't see the benefit within SBCL's architecture.
> compiling stuff. This is needed for things to have "0" startup time.
Oh, you just want to mmap() lisp code into memory, not use ELF in
particular?
In that case, steeldump implemented what you are asking for. I still
think that it was a nice idea, but I gave up on it, because it required
too much work to make each library (and each new version of that
library) work properly.
Besides, core files already give you "0" startup time, so we are only
talking about more modularity.
And core files are much closer to an actual 0 in their startup time than
a scheme like steeldump which maps individual libraries into memory:
Aside from mapping memory (and actually reading it from disk) it also
needs to install references between objects that have been loaded into
memory and the existing heap.
For example, it takes a significant amount of time to install new CLOS
classes and methods. (It still takes less time than fasl loading
though. Just not "0" time.)
> Maybe SBCL needs to not only have threads, but also processes. We'll be
> having many processes depending on the same cl-ppcre .so library and
> having only 1 shared copy of that library loaded in memory.
After, say, cl-ppcre.heap has been mapped, sb-heapdump would have to
install references from that memory to the existing heap and touch
nearly all parts of that memory, so that copy-on-write would do its part
and you won't actually share much.
I.e., sb-heapdump will actually share mapped memory in the case of
isolated graphs of objects that don't require such fixups (until a GC
touches them anyway), but that's not realistic for entirely libraries
like CL-PPCRE.
d.