LispNYC will mentor this summer. Here is a starting point for a list
of project ideas:
-UFFI cleanup
-sockets
-productize Lisp on Lines (rails clone)-get it to the point where a
single asdf install pulls areneida, lol, etc., and you can get a small
site up and running in an hour or so.
-Lisp library for computational chemistry. (actually, any domain that
uses bad languages should be considered fair game.)
-Port Postore to CL (it's an object database)
-write a lisp plugin for firefox, so that lisp could be used in the
place of javascript (VERY hard, I think)
Project ideas, discussion, etc. are much appreciated. For example, I
don't know the extent to which infrastructure, libraries or
applications are the right place to put effort. Sockets seems a
no-brainer, but does it make sense to try to do something with lisp on
lines? Should we try to have applicants submit their own ideas, as
opposed to proposals for one of the ones we had?
Some really cool things came out of last year's efforts, and we hope to
do more this year.
matt
> -productize Lisp on Lines (rails clone)-get it to the point where a
> single asdf install pulls areneida, lol, etc., and you can get a small
> site up and running in an hour or so.
Hello.
Just now i started to writing wrapper around CL-SQL that will let to
define ORM models in ActiveRecords style but with static fields. f.e.
(defORM category ()
(tree)
(has_many :products)
(scheme
(text-field :name "name" :size 25)
(date)
(clsql
;; CL-SQL additional scheme
)))
will generate:
(clsql:def-view-class category (cl-true-orm:tree) ;; (tree)
(;;; STANDART
(id
:accessor id
:db-kind :key
:db-constraints (:not-null :auto-increment) ;; for mysql
:type integer
:initarg :id)
;; (tree)
(parent-id
:accessor parent-id
:type integer
:initarg :parent-id)
(parent
:accessor parent
:db-kind :join
:db-info (:join-class category
:home-key parent-id
:foreign-key id
:set nil))
(children
:accessor children
:db-kind :join
:db-info (:join-class category
:home-key id
:foreign-key parent-id
:set t))
;; (has_many :products)
(products
:accessor products
:db-kind :join
:db-info (:join-class products
:home-key id
:foreign-key category-id))
;;; Other fields
(name
:initform ""
:accessor name
:type (varchar 25)
:initarg :name)
))
It will be very interesting for me to take part in development of Lisp
On Lines, I can write this wrapper and itegrate with LoL and maybe
write some other stuff. I am student an i can to do this as SoC
project.
// sory for my english
--
Peter Rezikov
To say the truth, I don't like Active Record idea very much. Maybe
it's just because I didn't try to use it. But let's analyze the
situation. There can be following possibile scenaries of ORM usage:
1) You need to support existing DB schema.
2) You can design your own schema.
3) You have limited control of existing schema / ongoing schema design.
Active Record binds you tight to the DB schema, which in cases 1 and 3
may not be very OO-friendly, so you'll hardly be happy with Active
Record approach and may want to use a more advanced and less direct data
mapping. In case 2 it's not a big problem, but when you can design the
schema yourself, I think you're better off inferring it from the object
model (just like CREATE-VIEW-FROM-CLASS already does in CLSQL) and not
messing with SQL tables directly.
By the way, Rails' concept of Active Record seems to be somewhat
different (and IMO even worse) compared to original P of EAA Active
Record pattern (
http://www.martinfowler.com/eaaCatalog/activeRecord.html ), which is
basically the most obvious dumbest and simplest thing you do in C# or
Java to map your classes to DB.
Meanwhile, I do think that CLSQL does indeed rather weak job as ORM.
It does provide basic class <-> table and foreign key mapping, some lazy
loading support and so on, but lacks many other important O/R mapping
features that cannot be easily added without modifying library's
internals (see below). I do not think this counts as a flaw, most likely
it's intentional decision to keep things simple.
The following are some of important ORM features not supported by
CLSQL, using some P of EAA terminology. They are supported by well-known
Java / .NET ORMs such as (N)Hibernate.
1. Unit of Work. When working with CLSQL, you have to explicitly save
all changes to database. The alternative is binding *db-auto-sync* to
true, but this way you will have database calls every time you change
any slot, invoke make-instance for view class and so on. Not good. It
would be nice to have something like (with-session ...) macro which
would accumulate changes in an Unit of Work and flush them to database
at once in the end, optionally also committing DB transaction. Not easy
to add on top of existing CLSQL infrastructure as all objects loaded
from DB must be registered within UoW but lazy FK slots are loaded
without providing any hooks to monitor / intercept object loading.
2. Identity Map. When using CLSQL the same object can be loaded multiple
times, so you can't use EQ to compare your objects, the memory is wasted
and there are many other possible unpleasant consequences (made some
changes to copy 1, other changes to copy 2, saved copy1, than copy2,
lost changes to copy 1, and so on). Possible implementation of UoW
should probably use the same session object as UoW, i.e. (with-session
...) and should provide also a global identity map. Just like UoW, it's
impossible to add Identity Map on top of existing CLSQL functionality
for exactly same reason.
3. Lazy collections. While CLSQL does provide lazy FK slots, it cannot
load the collections themselves lazily. I.e. if you have lazy ORDERS
slot in CUSTOMER class, when you refer to a customer's ORDERS slots will
be loaded at once, even if there's million of them and you actually want
to display first ten orders. It would be nice to have something that
looks like Elephant's btrees / cursors and probably something like pipes
(i.e. lazy lists, see PAIP) plus of course nice API for them. Most
likely it's impossible to add lazy collections without altering CLSQL's
internal machinery.
4. Types. CLSQL does implement some CL types <-> SQL types mapping, but
it's just isn't enough - you have to resort to DB-vendor-specific types
too often. Something like (N)Hibernate's type mapping would be useful
(i.e. there should be additional optional DB-aware but
vendor-independent type specifiers for persistent slots). It's possible
to add vendor-independent types on top of CLSQL using some macrology
(AFAIK MOP machinery in CLSQL is not exported enough), but it would be
somewhat kludgy.
5. Inheritance Mapping. There seems to be no way in CLSQL to provide
adequate inheritance mapping. Probably (N)Hibernate mapping should be
used. It's impossible to add this without modifying CLSQL internals.
6. Locking and versioning. Didn't think much about this one yet.
Probably it's possible to add this stuff on top of CLSQL, but not sure.
... probably many other issues...
Overall, CLSQL doesn't do a good job at abstracting you away from that
kludgy "SQL-hacking". Some will argue that ORM is not the way to go,
that one should use OODB, but frankly I don't see much choice here.
Let's look what we have:
1. AllegroCache and its predecessor AllegroStore. Non-free and requires
you to buy expensive Allegro CL. AllegroCache is also pretty young AFAIK
and has some rough edges.
2. Elephant. Nice OODB, but has some unpleasant problems. Your choices
are limited to Berkeley DB and SQLite. In first case, what we have to
use is Oracle's product with license which does not seem to make clear
whether you can use it for your web site without releasing all sources.
In second case, I think performance must be suboptimal, as eager DB
updates are used upon every slot change, plus some extra serialization
is added to the mix.
3. PLOB! License problems. Don't know anything how good is this library
in API and performance sense. Maybe suggested SoC project concerning
writing POSTORE replacement in CL will help.
4. Various prevalence solutions. BKNR, CL-Prevalence, probably others.
I've also rolled my own trivial prevalence lib once in a state of slight
hangover using CL-STORE for snapshots and journal, but I'm reluctant to
release it because I'm too afraid to be ashamed :) Prevalence is nice
stuff really, but there's plenty of cases when all data cannot be loaded
into RAM. Also, there are issues with data <-> code dependence, i.e. you
can easily break your data if you don't take enough care when hacking a
running app.
5. Maybe I forgot something?
Overall it seems that good O/R mapper will be helpful as it's easier to
implement than the full OODB solution. It can serve as a good compromise
till some good free CL OODB is invented. So, I'd suggest something like
that for SoC. Possible ways to implement a "good" O/R mapper:
1. Add all this new stuff to CLSQL. This probably will not be approved
by Kevin Rosenberg as the library will become bloated. It's possible
though to add most new stuff transparently, i.e. without breaking
backward compatibility (e.g. if you don't use with-session, CLSQL will
work as always etc.)
2. Devise a minimum set of necessary hooks that must be added to CLSQL
to make it possible to add the new infrastructure on top of it. Maybe it
will be accepted into main CLSQL source tree, or it can be distributed
as simple patch.
3. Write completely separate ORM library.
Of course, I'd gladly do all this stuff myself, but unfortunatelly I
think I will not have enough spare time :(
Some corrections:
Ivan Shvedunov wrote:
> 3. Lazy collections. While CLSQL does provide lazy FK slots, it cannot
> load the collections themselves lazily. I.e. if you have lazy ORDERS
> slot in CUSTOMER class, when you refer to a customer's ORDERS slots will
> be loaded at once, even if there's million of them and you actually want
> to display first ten orders.
... when you refer to a customer's ORDERS slot all customer's orders
will be loaded at once ...
> 5. Inheritance Mapping. There seems to be no way in CLSQL to provide
> adequate inheritance mapping. Probably (N)Hibernate mapping should be
> used.
... Probably (N)Hibernate inheritance mapping scheme should be used,
maybe with some additions to account for multiple inheritance.
> Overall it seems that good O/R mapper will be helpful as it's easier to
> implement than the full OODB solution. It can serve as a good compromise
... easier to implement than a full OODB solution.
Thanks, very usefull and interesting post. I think the better way is to
add all this features with some macro like with-session and thouse
things that will hard or imposible to do with macro make as CL-SQL
patch...
On 2006-04-19, CrazyPit <··········@gmail.com> wrote:
> Thanks, very usefull and interesting post. I think the better way is to
> add all this features with some macro like with-session and thouse
> things that will hard or imposible to do with macro make as CL-SQL
> patch...
I would be happy to be a mentor to students who wish to work on my
open-source software projects.
--
Kevin Rosenberg
·····@hypershots.com
Personally I'd like to see:
- Further work on CFFI. I don't know how far from "complete" it is,
but it would be nice to see it finished (for some definition of
complete)
- Work on either Verranzo or Swig. I don't mind either way really,
though SWIG as a whole is not likely to dry up for lack of maintainers.
There is still plenty to do with wrapping technologies, make the
generated code nicer, make it easier to generate the Lispy side of the
interface.
Cheers
Brad
bradb wrote:
> Personally I'd like to see:
> - Further work on CFFI. I don't know how far from "complete" it is,
> but it would be nice to see it finished (for some definition of
> complete)
Agreed. CFFI is an extremely important project for Lisp as a language.
> - Work on either Verranzo or Swig. I don't mind either way really,
> though SWIG as a whole is not likely to dry up for lack of maintainers.
> There is still plenty to do with wrapping technologies, make the
> generated code nicer, make it easier to generate the Lispy side of the
> interface.
Definitely agree. I think I'd vote for Swig, at least for the short
term - the wxCL project seems to be using it with some success.
I think for other project ideas I'd really like to see the work that
has been done with interfaces to graphical libraries extended. There
was some extremely interesting work done with the QT toolkit a little
while back - if that could be extended to cover most of the features of
QT it would be a major plus for Lisp cross platform graphics. I still
haven't gotten QT4 on my machine so I haven't played with what has been
done, but clearly enough is already working to point the way for
subsequent efforts. That might tie in with CFFI and/or binding
generators. Also of interest would be robust Windows GDI bindings,
more work on the cl-carbon project, and extensions/improvements to CLX.
Cheers,
CY
Sorry to reply to myself - dug up the link for the QT stuff:
http://weitz.de/files/ECL-Qt/
A CFFI multi-lisp version of this, fleshed out, would be a big boon to
Lisp graphics, particularly with QT4 being available under GPL for
Windows, Linux and Mac.
"C Y" <···········@yahoo.com> writes:
> I think for other project ideas I'd really like to see the work that
> has been done with interfaces to graphical libraries extended. There
> was some extremely interesting work done with the QT toolkit a little
> while back - if that could be extended to cover most of the features of
> QT it would be a major plus for Lisp cross platform graphics. I still
> haven't gotten QT4 on my machine so I haven't played with what has been
> done, but clearly enough is already working to point the way for
> subsequent efforts. That might tie in with CFFI and/or binding
> generators. Also of interest would be robust Windows GDI bindings,
> more work on the cl-carbon project, and extensions/improvements to CLX.
What would be really neat would be a free Carbon/Cocoa CLIM. Somehow
I think, however, that this may be beyond the scope of a single
summer. ;)
Agreed. That's why I suggest either QT (already cross platform, so
saves work) or cl-gdi, cl-carbon, and CLX improvements (my actual
preference) - that work is a necessary precursor to McCLIM becoming
cross platform. cl-gdi and cl-carbon would allow a great deal of
flexibility with a minimum of layers below McCLIM, but QT covers all
three platforms and might also conceivably be used as a backend
platform for McCLIM. Practically speaking, what I would suggest for
the Summer of Code projects is:
1) (this year) Building off the ECL-QT work that has already begun,
convert it to CFFI as a backend and expand the percentage of the QT API
it covers. Expand it a lot - with any luck, once a student got the
hang of it they could get most of the API interfaced, although I don't
have any definite idea how big the QT API actually is. Document along
the way, from the lisp perspective. Maybe call this cl-qt.
2) (next year, if they go for it again) Building off of the cl-qt
bindings from 2006, create a QT backend for McCLIM. This will a) allow
McCLIM to become the first open, pure lisp, cross platform GUI toolkit
and b) make sense of what it takes to make an McCLIM backend.
You might be able to do 2 with wxWidgets bindings, but I don't know
quite how robust the wxWidgets bindings are right now. Of course QT
restricts GUI applications to the GPL unless you buy a commercial
license, which might be a slight drawback, but I doubt commercial
application development will be the first use for cl-qt anyway -
they've got Allegro and Lispworks for that ;-).
"C Y" <···········@yahoo.com> writes:
> cl-gdi and cl-carbon would allow a great deal of flexibility with a
> minimum of layers below McCLIM, but QT covers all three platforms
> and might also conceivably be used as a backend platform for McCLIM.
You might be interested to know that McCLIM already has partly-working
Cocoa, Cairo and Gtk+ backends, in various stages of development.
Both the Cairo and the Gtk+ backends in principle cover "all three"
platforms. In that light, a Qt backend might be interesting but
doesn't feel critically vital, at least to me. (Probably to others
any work at all on McCLIM doesn't feel critically vital, but I'm a
happy user and I'd like to see it improve: I have some ideas, and the
real developers probably have some more :-)
> 1) (this year) Building off the ECL-QT work that has already begun,
> 2) (next year, if they go for it again) Building off of the cl-qt
I think that planning two years ahead is potentially useful but should
be viewed with a pinch of salt, and above all the first year's project
needs to stand on its own. We are vulnerable not only to Google's
whims regarding running the event and funding in following years, but
also to the ability of the first year's student to fulfil his or her
part of the work (and quite possibly to defend it from bitrot for 11
months).
Christophe
Christophe Rhodes wrote:
> "C Y" <···········@yahoo.com> writes:
>
> > cl-gdi and cl-carbon would allow a great deal of flexibility with a
> > minimum of layers below McCLIM, but QT covers all three platforms
> > and might also conceivably be used as a backend platform for McCLIM.
>
> You might be interested to know that McCLIM already has partly-working
> Cocoa, Cairo and Gtk+ backends, in various stages of development.
I think the Cocoa backend (Beagle) ran into some rather fundamental
world view clashes between McCLIM and Cocoa - that's why I thought
cl-carbon might make a more logical target. The other option would be
to adapt McCLIM's behavior to Cocoa I suppose, but I don't know if the
spec allows that.
The Cairo backend looks interesting, but I don't know much about the
status of Cairo - is it activly developed and maintained? How does it
perform on various platforms?
The GTK+ backend is a new development IIRC, and an exciting one - but
GTK on Windows never feels "natural" to me, and I don't really care for
it too much. That's just a personal thing, and I grant you GTK support
in Lisp is much futher along (lamdagtk, clg) than QT. It might be the
best way to move forward, but I think it would wind up with McCLIM
feeling subtly "wrong" on Windows. Just a thought.
QT I suggest because a) Trolltech does all the hard, nasty work of
cross platform toolkit development and b) I'm hoping it will be
somewhat more "natural" under Windows than GTK. wxWidgets is another
way to achieve this but on Linux that would result in the software
stack being X->GTK->WxWidgets->McCLIM, which seems like a lot of
overhead. I'm not opposed to a wxCL based backend of course - indeed I
would eventually like to see a wide variety of backends for McCLIM -
but for a first target I think QT may have the most to offer. Again,
that's just my opinion.
> Both the Cairo and the Gtk+ backends in principle cover "all three"
> platforms. In that light, a Qt backend might be interesting but
> doesn't feel critically vital, at least to me. (Probably to others
> any work at all on McCLIM doesn't feel critically vital, but I'm a
> happy user and I'd like to see it improve: I have some ideas, and the
> real developers probably have some more :-)
I think graphical toolkits in Lisp is a vitally important area for
development - I suspect it's one of the areas holding Lisp back the
most for "common" usage.
> > 1) (this year) Building off the ECL-QT work that has already begun,
>
> > 2) (next year, if they go for it again) Building off of the cl-qt
>
> I think that planning two years ahead is potentially useful but should
> be viewed with a pinch of salt, and above all the first year's project
> needs to stand on its own. We are vulnerable not only to Google's
> whims regarding running the event and funding in following years, but
> also to the ability of the first year's student to fulfil his or her
> part of the work (and quite possibly to defend it from bitrot for 11
> months).
True. Hopefully the community would rally 'round a good development
effort, but there are no guarantees.
Cheers,
CY
Agreed. That's why I suggest either QT (already cross platform, so
saves work) or cl-gdi, cl-carbon, and CLX improvements (my actual
preference) - that work is a necessary precursor to McCLIM becoming
cross platform. cl-gdi and cl-carbon would allow a great deal of
flexibility with a minimum of layers below McCLIM, but QT covers all
three platforms and might also conceivably be used as a backend
platform for McCLIM. Practically speaking, what I would suggest for
the Summer of Code projects is:
1) (this year) Building off the ECL-QT work that has already begun,
convert it to CFFI as a backend and expand the percentage of the QT API
it covers. Expand it a lot - with any luck, once a student got the
hang of it they could get most of the API interfaced, although I don't
have any definite idea how big the QT API actually is. Document along
the way, from the lisp perspective. Maybe call this cl-qt.
2) (next year, if they go for it again) Building off of the cl-qt
bindings from 2006, create a QT backend for McCLIM. This will a) allow
McCLIM to become the first open, pure lisp, cross platform GUI toolkit
and b) make sense of what it takes to make an McCLIM backend.
You might be able to do 2 with wxWidgets bindings, but I don't know
quite how robust the wxWidgets bindings are right now. Of course QT
restricts GUI applications to the GPL unless you buy a commercial
license, which might be a slight drawback, but I doubt commercial
application development will be the first use for cl-qt anyway -
they've got Allegro and Lispworks for that ;-).
"C Y" <···········@yahoo.com> writes:
[...]
> 1) (this year) Building off the ECL-QT work that has already begun,
> convert it to CFFI as a backend and expand the percentage of the QT API
> it covers. Expand it a lot - with any luck, once a student got the
> hang of it they could get most of the API interfaced, although I don't
> have any definite idea how big the QT API actually is. Document along
> the way, from the lisp perspective. Maybe call this cl-qt.
[...]
Do you already know about Paul Ruetz' effort at
http://members.aon.at/lispolos/ ? It's CFFI based and
supposed to work at least on ECL, CLISP and SBCL.
Best regards,
Stephan
Opps! I think I had seen that, but it slipped my mind. Trying to
concentrate on too many things at once, with predictable results.
Thanks!
OK, so that effort is probably even better groundwork for expansion,
since the initial steps have already been taken to figure out how to
link CFFI + QT. I think is quite a reasonable project for a student to
expand the QT API support as much as possible. Arguably it's not as
much fun as the initial figuring out of HOW to do it, but it will have
quite some benefit for the open source lisp world. Plus, Lisp work in
KDE becomes more interesting ;-).
I don't know how either LispNYC or Google would feel about such a
project, but fingers crossed!
···········@gmail.com writes:
> -sockets
> Sockets seems a no-brainer
I don't understand, so maybe I don't have a brain. Could you explain
what you mean by "sockets" in the context of a summer of code project,
and why it would benefit the Lisp community?
Christophe
Last summer, there was an attempt to make a portable CL interface to
BSD sockets, with the aim of supporting most of the major CLs. It
didn't fly, for nontechnical reasons that I'll not get into here, but
having a portable sockets would seem to be important and useful.
I don't know enough about sockets (or CL, really) to judge the
difficulty of doing this, but people have said that it is doable in a
summer by a motivated and talented student.
···········@gmail.com writes:
> Last summer, there was an attempt to make a portable CL interface to
> BSD sockets, with the aim of supporting most of the major CLs. It
> didn't fly, for nontechnical reasons that I'll not get into here,
I'm sorry to hear there were nontechnical contributing factors, but
the technical output (the code) was also pretty poor.
> but having a portable sockets would seem to be important and useful.
http://www.scsh.net/docu/html/man-Z-H-5.html would be a pretty good
source of inspiration.
Zach
···········@gmail.com writes:
> scsh is mostly/entirely implemented in scheme48, right? would it be
> fairly straightforward to convert to CL/RnRS?
Please include some context when replying to messages.
Porting ideas can be more useful than porting code sometimes.
Zach
[following up to comp.lang.lisp only]
···········@gmail.com writes:
> I don't know enough about sockets (or CL, really) to judge the
> difficulty of doing this, but people have said that it is doable in a
See:
Socket API Analysis
http://www.findinglisp.com/blog/2005/12/socket-api-analysis.html
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Paolo Amoroso <·······@mclink.it> writes:
> Socket API Analysis
> http://www.findinglisp.com/blog/2005/12/socket-api-analysis.html
Regarding address representation, I wonder why implementations don't
just wrap the C BSD sockets interface. That is, an address is a pack
of bytes prefixed with an address family. You can always treat the
data as an opaque byte array, and additionally for particular known
address families the implementation provides customized field
accessors. The C interface was designed such that generic address
handling code doesn't have to know address formats. This solves
problems with supporting IPv6, UDP, system-specific protocols etc.
I did this for my language Kogut. An address appears to have fields
family (isomorphic to an integer) and data (a byte array). In addition
addresses appear to have fields which depend on the family. These
fields present data in more convenient formats; they can be used to
access parts of data of an address, or for construction of a new
address. Fields for particular address families include:
* InetFamily - port (integer) and addr (a list of 4 bytes)
* Inet6Family - port (integer), flowInfo (integer),
addr (a list of 16 bytes), scopeId (integer)
* UnixFamily - path (string)
Handlers of fields of particular address families are kept in central
dictionaries, and can be added externally.
The internal representation of an address wraps the C representation,
so it doesn't have to be marshalled when used with socket functions.
Unix provides getaddrinfo() and getnameinfo() for translation of
Internet addresses from/to strings, both in numeric formats and basing
on DNS. On systems which provide these functions, there is no need to
write custom printers and parsers for human-readable IPv4 and IPv6
addresses, and thus IPv6 just works if only the OS supports it.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
···········@gmail.com writes:
> Project ideas, discussion, etc. are much appreciated. For example,
> I don't know the extent to which infrastructure, libraries or
> applications are the right place to put effort. [...] Should we
> try to have applicants submit their own ideas, as opposed to
> proposals for one of the ones we had?
I think that it is valuable for potential volunteers to see the scope
and the complexity of things that the mentoring organization considers
worth funding, but that they should be positively encouraged to submit
proposals that they have come up with themselves if they have an idea
that they want to work on. In both cases, of course, it is important
that the mentoring organization checks that the project isn't a
duplicate or near-duplicate of something that already exists, and that
there's a mentor to guide the student as and when they need help.
My opinion is that the students' choice of projects will guide where
the effort is put; as long as there are interesting and challenging
things to do in whatever category label you want to put them there
will be a positive result. So I'd suggest doing much as you are doing
now: soliciting project suggestions from interested parties, seeing
what you get back, and establishing a dialogue among those parties to
improve or weed out suggestions that aren't up to scratch.
> Some really cool things came out of last year's efforts, and we hope to
> do more this year.
Is there a summary of what came out of last year's efforts? Other
communities (e.g. Gerv for Mozilla) have reported that, by and large,
the projects funded by Google have drifted into unmaintained status,
not been merged into their parent repositories, and have otherwise
died; I gather that the people at Google are aware of this, but it
would obviously be good for our community to try to avoid this
apparent problem, if indeed it did affect the Lisp projects, from
recurring.
I am aware of the success of CFFI, and the failure of last year's
socket project (whatever it was) and the slime stepper; beyond that, I
do not know what has happened to the work done. Is there any chance
of finding out?
Christophe
I'll get together a summary of where the various projects went and what
state they are in now, hopefully this evening sometime.
From: Ken Tilton
Subject: Re: Google summer of code
Date:
Message-ID: <NNN0g.7$f6.1@fe12.lga>
Christophe Rhodes wrote:
> ···········@gmail.com writes:
>
>
>>Project ideas, discussion, etc. are much appreciated. For example,
>>I don't know the extent to which infrastructure, libraries or
>>applications are the right place to put effort. [...] Should we
>>try to have applicants submit their own ideas, as opposed to
>>proposals for one of the ones we had?
>
> Is there a summary of what came out of last year's efforts? Other
> communities (e.g. Gerv for Mozilla) have reported that, by and large,
> the projects funded by Google have drifted into unmaintained status,
> not been merged into their parent repositories, and have otherwise
> died; I gather that the people at Google are aware of this, but it
> would obviously be good for our community to try to avoid this
> apparent problem, if indeed it did affect the Lisp projects, from
> recurring.
>
> I am aware of the success of CFFI, and the failure of last year's
> socket project (whatever it was) and the slime stepper; beyond that, I
> do not know what has happened to the work done. Is there any chance
> of finding out?
Good idea. Each year a "Where are they now?" on all projects, not just
the prior year's. The ones I mentored:
CFFI -- Is this now the standard, er, substandard of portable FFIs?
I would call that a ringing success, if so.
Fetter, renamed Verrazano, renamed Fetter <kidding> since the author
seemed fettered by it, abandoning it after technical success and not
respond to emails or list traffic. But, hey, it is open source so anyone
could pick it up and take it forward. The big question to me, and I
honestly do not know because I have not looked, is whether Swig makes
vzn redundant.
cl-sockets -- a standout: the only Google project for which the
student sought and was refused payment when both mentors flunked the effort.
I would say one technical and political success, one technical success,
and one mushroom cloud. I get a perverse pleasure out of having mentored
the full range of outcomes, btw. :)
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
···········@gmail.com wrote:
> LispNYC will mentor this summer. Here is a starting point for a list
> of project ideas:
>
> -UFFI cleanup
Nowadays CFFI rules the Lisp world :-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Ken Tilton
Subject: Re: Google summer of code
Date:
Message-ID: <czN0g.6$f6.2@fe12.lga>
Frank Buss wrote:
> ···········@gmail.com wrote:
>
>
>>LispNYC will mentor this summer. Here is a starting point for a list
>>of project ideas:
>>
>>-UFFI cleanup
Is KMR the mentor? Last I heard, he felt UFFI2 was needed and did not
want to accept changes to UFFI because that destabilizes it and he needs
it for production work to be reliable. And UFFI2 was not a cleanup, it
would be a break from the past.
>
>
> Nowadays CFFI rules the Lisp world :-)
>
That was my impression (and my second question in re an UFFI project),
but I do not get out much.
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton напиша:
> Frank Buss wrote:
> > ···········@gmail.com wrote:
> >
> >
> >>LispNYC will mentor this summer. Here is a starting point for a list
> >>of project ideas:
> >>
> >>-UFFI cleanup
>
Wait the minute I wanted to apply for a DirectX 9 interface through
CFFI.
Where this UFFI cleanup came out.
Oops I'm not student anymore .
bobi
fireblade wrote:
> Wait the minute I wanted to apply for a DirectX 9 interface through
> CFFI.
Good idea, but you have to enhance CFFI for supporting COM then.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Ken Tilton напиша:
> Frank Buss wrote:
> > ···········@gmail.com wrote:
> >
> >
> >>LispNYC will mentor this summer. Here is a starting point for a list
> >>of project ideas:
> >>
> >>-UFFI cleanup
>
Wait the minute I wanted to apply for a DirectX 9 interface through
CFFI.
Where this UFFI cleanup came out.
Oops I'm not student anymore .
bobi
Frank Buss <··@frank-buss.de> writes:
> ···········@gmail.com wrote:
>
>> LispNYC will mentor this summer. Here is a starting point for a list
>> of project ideas:
>>
>> -UFFI cleanup
>
> Nowadays CFFI rules the Lisp world :-)
I think adding optional run-time foreign pointer type checking to CFFI
would be a very interesting and useful project. Bonus points if it
could work through the compiler-macros that CFFI already uses and
sniff out the OPTIMIZE SAFETY value from the compiler as well...
James
···········@gmail.com writes:
> -write a lisp plugin for firefox, so that lisp could be used in the
> place of javascript (VERY hard, I think)
After spending some . . . quality time with JavaScript recently,
I strongly agree that this would be valuable. Scheme may have some
advantages in terms of size for this role.
Another widely used tool that could benefit from being rethought
and reimplemented in Lisp is Ant.
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
Patrick May <···@spe.com> writes:
> ···········@gmail.com writes:
>> -write a lisp plugin for firefox, so that lisp could be used in the
>> place of javascript (VERY hard, I think)
>
> After spending some . . . quality time with JavaScript
> recently, I strongly agree that this would be valuable. Scheme may
> have some advantages in terms of size for this role.
>
> Another widely used tool that could benefit from being
> rethought and reimplemented in Lisp is Ant.
>
> Regards,
>
> Patrick
>
> ------------------------------------------------------------------------
> S P Engineering, Inc. | The experts in large scale distributed OO
> | systems design and implementation.
> ···@spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
Not sure if this will meet your needs, but do you know about
Parenscript? It lets you write Javascript in a subset of Common Lisp
and will generate Javascript from it. It supports macros and
implements the entire ECMAscript standard. I am a fan.
http://www.bknr.net/parenscript
--
Bill
LispVan had a presentation in which, IIRC, the presentor used his own
combination of parenscript, ucw, CL-SQL, parsley, sage, rosemary and
time to put together a RoR-like thing in CL. I would love a proposal
that brought all of that together, fixed whatever problems rails has,
and ended up with a full-stack lisp web solution. Actually, looking
back on it, I am not at all sure that parenscript was included, and
that is an important omission. If we were to provide a single syntax
and semantics for HTML, CSS, SQL, javascript, and actual programming,
with some clever magic to determine what should go on the server and
what should go on the client, someone could write an app, and have the
backend figure out that it should be deployed to servers as HTML, to
databases as a schema, and to all the other languages as a challenge:
this is what a real language can do. sounds great to me.
I have used ant with java a bit, but how would it work with lisp? It
seems to mostly be good(ish) at handling the compile-phase, which is
somewhat less well-defined in lisp than in java.
···········@gmail.com writes:
> I have used ant with java a bit, but how would it work with lisp? It
> seems to mostly be good(ish) at handling the compile-phase, which is
> somewhat less well-defined in lisp than in java.
I agree. My suggestion was confusing -- I didn't mean that an
Ant replacement would be particularly useful for Lisp development.
I'd rather write build rules for C++ and Java in Scheme or Lisp than
in sh (Make) or XML (Ant).
My ulterior motive is to get C++ and Java programmers used to
Lisp in digestable chunks.
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
···········@gmail.com wrote:
> LispNYC will mentor this summer. Here is a starting point for a list
> of project ideas:
>
> Project ideas, discussion, etc. are much appreciated.
I'd like to see the Common-Lisp stepper for Slime resurrected.
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
Am 17.04.2006 5:36 Uhr schrieb ············@gmail.com" unter
<···········@gmail.com> in
························@v46g2000cwv.googlegroups.com:
> LispNYC will mentor this summer. Here is a starting point for a list
> of project ideas:
>
> -UFFI cleanup
> -sockets
> -productize Lisp on Lines (rails clone)-get it to the point where a
> single asdf install pulls areneida, lol, etc., and you can get a small
> site up and running in an hour or so.
> -Lisp library for computational chemistry. (actually, any domain that
> uses bad languages should be considered fair game.)
> -Port Postore to CL (it's an object database)
> -write a lisp plugin for firefox, so that lisp could be used in the
> place of javascript (VERY hard, I think)
>
> Project ideas, discussion, etc. are much appreciated. For example, I
> don't know the extent to which infrastructure, libraries or
> applications are the right place to put effort. Sockets seems a
> no-brainer, but does it make sense to try to do something with lisp on
> lines? Should we try to have applicants submit their own ideas, as
> opposed to proposals for one of the ones we had?
>
> Some really cool things came out of last year's efforts, and we hope to
> do more this year.
>
> matt
>
How about a Lisp interface to Subversion?
···········@gmail.com wrote:
> LispNYC will mentor this summer. Here is a starting point for a list
> of project ideas:
>
>[snip]
> -productize Lisp on Lines (rails clone)-get it to the point where a
> single asdf install pulls areneida, lol, etc., and you can get a small
> site up and running in an hour or so.
I think this is a great idea, and i'd really like to see it happen. LoL
is a very useful project, but i have not had time to polish it up for a
more general release.
I'm more than willing to mentor this, if we can find somebody
interested in doing the work :)
> Sockets seems a
> no-brainer, but does it make sense to try to do something with lisp on
> lines?
I think it might, though i'm biased :). People are always talking about
CL needing a 'killer app'. I think that LoL could serve that duty. I
was thinking of having the Tech Co-op join SoC just for this reason,
but i'd much rather be a part of the greater Lisp effort.
Cheers,
drewc
ps- Posting from Google Groups for the first time. so please excuse any
weirdness.
Supercool-I really should have asked you before I proposed the idea,
but I didn't. Sorry and thanks. I am particularly interested in
getting Parenscript in the mix-do you think that is doable? If so, we
would have the first _really_ full-stack web app thingie. (well,
sorta. rails has a syntax for javascript, but I do not think if it
supports the full ecma standard).
···········@gmail.com writes:
> Supercool-I really should have asked you before I proposed the idea,
> but I didn't. Sorry and thanks.
No worries.
> I am particularly interested in
> getting Parenscript in the mix-do you think that is doable? If so, we
> would have the first _really_ full-stack web app thingie. (well,
> sorta. rails has a syntax for javascript, but I do not think if it
> supports the full ecma standard).
LoL already uses Parenscript actually, and has built in support for
ajax via the Dojo toolkit. It also inherits <UCW:SCRIPT from
UncommonWeb, which is a YACLML tag for outputting arbitrary
parenscript code.
For example, here is a part of the LoL source for creating
drag-and-drop sortable lists via Dojo. The :CALLBACK argument to
WITH-AJAX defines some lisp code that will be run with the output of
some parenscript code, which is in this case triggered by
drag/dropping an item within an html list (<li></li>).
(<ucw:script
`(dojo.event.connect dojo "loaded"
(lambda ()
(setf make-sortable
(lambda (x)
(setf ulist (document.get-element-by-id x))
(setf drop (new (dojo.dnd.*html-drop-target ulist (array x))))
(setf list-items (ulist.get-elements-by-tag-name "li" ))
(dolist (li list-items)
(new (dojo.dnd.*html-drag-source li x)))))
(make-sortable ,(input-id self))))
(dojo.event.connect drop "onDrop"
(lambda ()
(dolist (li list-items)
(new (dojo.dnd.*html-drag-source li ,(input-id self))))
,(with-ajax (self)
(:action nil)
(:callback d (let ((list-order
(mapcar
#'(lambda (x)
(parse-integer
(subseq x
(length (input-id self)))))
(read-from-string d))))
(setf (mewa::instances self)
(reorder-list
(mewa::instances self)
list-order)))
`(list-to-sexp-of-ids list-items))
(:load `(lambda (x data)
(setf (slot-value
(document.get-element-by-id
,(input-id self))
inner-h-t-m-l)
data)
(make-sortable ,(input-id self)))))))
Cheers,
drewc
excellent-can you put a recent version up somewhere? We're going to
have candidates start coding as soon as we can get them started, and it
would be very slick for the lol project to be well underway when May 8
and the app deadline hit.
On Tue, 18 Apr 2006 03:45:36 +0000, drewc wrote:
> ···········@gmail.com writes:
>
[SKIP]
>
>> I am particularly interested in
>> getting Parenscript in the mix-do you think that is doable? If so, we
>> would have the first _really_ full-stack web app thingie. (well,
>> sorta. rails has a syntax for javascript, but I do not think if it
>> supports the full ecma standard).
>
> LoL already uses Parenscript actually, and has built in support for
> ajax via the Dojo toolkit. It also inherits <UCW:SCRIPT from
> UncommonWeb, which is a YACLML tag for outputting arbitrary
> parenscript code.
>
[SKIP]
just wanted to let you know, that we (our research project at Inria) are
currently working on something similar. Ours is called "Hop" (it was
originally a Proxy) and I've worked on a decent Scheme to Javascript
compiler recently. I submitted a paper to ICFP just one week ago, and we
are going to release the compiler in the near future (at least I hope so).
The compiler is still missing call/cc and correct tail-calls (although the
most obvious loops are compiled to while-loops), but it is otherwise
nearly R5RS complete.
I'm now trying to implement some long-due optimizations (more inlining,
and peep-hole patterns), and then integrate tail-calls and call/cc (at
least give it a try).
Here's a small example of HOP and the Scheme/JS integration (currently
Scheme symbols are mapped to JS strings):
(let ((el (<SPAN>)))
(<HTML>
(<BODY>
(<P> "some paragraph text.")
el
(<SCRIPT>
~(set! $el.innerHTML (string->symbol "some text"))))))
// florian loitsch
I looked pretty hard, and cannot find a downloadable version of lisp on
lines. There is a pretty old tarball available at
mattknox.com/lol.tar.gz-can you make a recent version available?
Hi. I've been teaching myself lisp this semester and working through
Peter Siebel's PCL, Paul Graham's ANSI Common Lisp and also trying some
stuff from Peter Norvig's Paradgims of AI Programming. I'm new at Lisp
and I've been looking for a project to do to get better at it. I've used
Ruby on Rails and I'd be more than happy to work on a Lisp version. I
don't know if I qualify for Google's summer of code since I'm graduating
in May, but if experienced Lispers don't mind mentoring I don't mind
working.
-Jeff
Drew Crampsie wrote:
> ···········@gmail.com wrote:
>
>>LispNYC will mentor this summer. Here is a starting point for a list
>>of project ideas:
>>
>>[snip]
>>-productize Lisp on Lines (rails clone)-get it to the point where a
>>single asdf install pulls areneida, lol, etc., and you can get a small
>>site up and running in an hour or so.
>
>
> I think this is a great idea, and i'd really like to see it happen. LoL
> is a very useful project, but i have not had time to polish it up for a
> more general release.
>
> I'm more than willing to mentor this, if we can find somebody
> interested in doing the work :)
>
>
>>Sockets seems a
>>no-brainer, but does it make sense to try to do something with lisp on
>>lines?
>
>
> I think it might, though i'm biased :). People are always talking about
> CL needing a 'killer app'. I think that LoL could serve that duty. I
> was thinking of having the Tech Co-op join SoC just for this reason,
> but i'd much rather be a part of the greater Lisp effort.
>
> Cheers,
> drewc
>
> ps- Posting from Google Groups for the first time. so please excuse any
> weirdness.
>
I think you're ok. This is the page to look at to see for sure:
http://code.google.com/soc/studentfaq.html (point 11)
There will be an announcement from Heow Eide-Goodman in the next day or
so. He's going to say (rather more eloquently) that having working
code at application time is a good idea, so I suggest you go download
lisp-on-lines (Drew Crampsie's site might have it, or you can get an
old version from mattknox.com), and start thinking about what it needs.
> I'm more than willing to mentor this, if we can find somebody
interested in doing the work :)
And what about ActiveRecord like stuff in LoL? It is very interesting
to me to make it. I have many ideas about pretty ORM fo CL and i think
with base of CL-SQL i can write wrapper, that would helps in rapid web
development. I want to realize such features as Acts, Associations,
Calculations, Migrations and other. I using RoR and i knew it is cool,
but i love Lisp and think, that with power of CL we can create much
more powerfull freamwork.
···········@gmail.com wrote:
> LispNYC will mentor this summer. Here is a starting point for a list
> of project ideas:
>
> -Lisp library for computational chemistry. (actually, any domain that
> uses bad languages should be considered fair game.)
I'm the author of CL-ODE (http://common-lisp.net/cl-ode), a CFFI
wrapper around the Open Dynamics Engine. (http://ode.org). I'd like
write a similar library in straight lisp.
Tom