I've learned a lot from the responses on the "Edi for Dictator"
thread.
1. Be very careful about using the word "standard" in any discussion
of Common Lisp.
2. Make clear the distinction between "implementation" and
"distribution". From comparisons made to Linux and Unix, different
Common Lisp implementations (SBCL, CLisp, Allegro) might be better
compared to Linux, BSD, Solaris, etc. Lisp-in-a-Box would be a
distribution, like Ubuntu or Fedora. This will often be blurred as
Allegro Common Lisp is really a distribution, too, I think.
3. The dictator thing is a possible means to an end, not an end in and
of itself. The goal is a set of well chosen, broadly applicable, very
easy to install or included set of libraries available for the major
Common Lisp implementations.
4. The CDR repository will be a very good place to communicate this
goal in a non-ambiguous way.
5. There is a possible cost to forcing the Starter Library to be
included in every distribution. That is part of the brilliance of
Starter Pack, even though the libraries are not pre-installed, Starter
Pack makes getting them about as easy as could be possible.
6. Some Linux package managers already provide a good number of Common
Lisp libraries.
7. Edi seems to have politely declined the position :).
8. I really need to shut up and do something productive.
So, in response to 8., I downloaded the source to Starter Pack a
couple of nights ago and started thinking about how it might be made
to work in SBCL.
My first thought is that a Hunchentoot version could be interesting.
If coupled with a script that somehow started the Hunchentoot-Starter-
Pack application from an image, then opened a browser window pointing
to the appropriate port on localhost, you could have a fairly portable
version of Starter Pack.
Looking at the source files, I think it roughly follows a Model-View-
Controller pattern with libs.lisp defining the model, interface.lisp
with most of the view code, and main.lisp containing controller code.
interface.lisp is, of course, mostly LispWorks specific code and not
very useful for a portable version. Maybe main.lisp could be
abstracted a bit more to use either the code from interface.lisp or
from a hunchentoot or other UI strategy. The remaining files contain
a few scattered references to LispWorks (and CAPI) specific code that
shouldn't be too hard to factor out (things like capi:display-message
for reporting errors).
So I think the first step would be to get the model part of the code
working on SBCL. From there, I could start thinking about how to
refactor to use a hunchentoot web-app instead of the CAPI interface.
Thoughts? Is this a reasonable approach? Might it be useful for
combinations other than SBCL/OS X? Are there better approaches than
this?
-jimbo
On 13 Jul, 18:00, ········@gmail.com wrote:
> I've learned a lot from the responses on the "Edi for Dictator"
> thread.
> My first thought is that a Hunchentoot version could be interesting.
It's good that you're starting to work on this as it's the best way to
get people interested.
I think Hunchentoot for UI creates an interesting bootstrapping
problem although clearly you've already thought about this. I quite
like the neat desktop app / dialog box approach of the current starter
pack.
Maybe LTK would be one way to go? It's cross platform, can be started
with a simple (load ...) and is well capable of replicating the UI in
Edi's current implementation. That said, if you refactor it to pure
MVC then swapping UI should be trivial...
----
Phil
http://phil.nullable.eu/
On Jul 13, 1:21 pm, ···············@gmail.com wrote:
> Maybe LTK would be one way to go? It's cross platform, can be started
> with a simple (load ...) and is well capable of replicating the UI in
> Edi's current implementation. That said, if you refactor it to pure
> MVC then swapping UI should be trivial...
Hmm, glancing at LTK, it is of course much closer to the CAPI API, so
maybe that would require less refactoring.
-jimbo
On Jul 13, 7:00 pm, ········@gmail.com wrote:
> I've learned a lot from the responses on the "Edi for Dictator"
> thread.
>
> 1. Be very careful about using the word "standard" in any discussion
> of Common Lisp.
> 2. Make clear the distinction between "implementation" and
> "distribution". From comparisons made to Linux and Unix, different
> Common Lisp implementations (SBCL, CLisp, Allegro) might be better
> compared to Linux, BSD, Solaris, etc. Lisp-in-a-Box would be a
> distribution, like Ubuntu or Fedora. This will often be blurred as
> Allegro Common Lisp is really a distribution, too, I think.
> 3. The dictator thing is a possible means to an end, not an end in and
> of itself. The goal is a set of well chosen, broadly applicable, very
> easy to install or included set of libraries available for the major
> Common Lisp implementations.
> 4. The CDR repository will be a very good place to communicate this
> goal in a non-ambiguous way.
> 5. There is a possible cost to forcing the Starter Library to be
> included in every distribution. That is part of the brilliance of
> Starter Pack, even though the libraries are not pre-installed, Starter
> Pack makes getting them about as easy as could be possible.
> 6. Some Linux package managers already provide a good number of Common
> Lisp libraries.
> 7. Edi seems to have politely declined the position :).
> 8. I really need to shut up and do something productive.
>
> So, in response to 8., I downloaded the source to Starter Pack a
> couple of nights ago and started thinking about how it might be made
> to work in SBCL.
>
> My first thought is that a Hunchentoot version could be interesting.
> If coupled with a script that somehow started the Hunchentoot-Starter-
> Pack application from an image, then opened a browser window pointing
> to the appropriate port on localhost, you could have a fairly portable
> version of Starter Pack.
>
> Looking at the source files, I think it roughly follows a Model-View-
> Controller pattern with libs.lisp defining the model, interface.lisp
> with most of the view code, and main.lisp containing controller code.
> interface.lisp is, of course, mostly LispWorks specific code and not
> very useful for a portable version. Maybe main.lisp could be
> abstracted a bit more to use either the code from interface.lisp or
> from a hunchentoot or other UI strategy. The remaining files contain
> a few scattered references to LispWorks (and CAPI) specific code that
> shouldn't be too hard to factor out (things like capi:display-message
> for reporting errors).
>
> So I think the first step would be to get the model part of the code
> working on SBCL. From there, I could start thinking about how to
> refactor to use a hunchentoot web-app instead of the CAPI interface.
>
> Thoughts? Is this a reasonable approach? Might it be useful for
> combinations other than SBCL/OS X? Are there better approaches than
> this?
>
> -jimbo
Don't bother with gui, it's nice to have it but keep the make-up for
later, simple console with some questions would be usefull enough, and
including some more libs like Gary Kings would make it even nicer.
Actually you could even make it a simple click and forgeth, the code
will just download all libs included. Just my 2 cents