Plans

[Tom Novelli]

Greetings...

I met up with Fare for another informal planning session 2 weeks ago.
(I apologize for the delay; I've spent those 2 weeks trying to make the
Commonwealth of Massachusetts live up to its promise of affordable
health insurance. But that's another story!) Anyway, without further
ado, here is a summary of our discussion:


WEB SITE

1. I will upgrade the CMS any day now (and rename it according to RMS's
terminology - Website Revision System - which makes more sense to me!)
Major changes include WSGI support, simplifications, and integration
with the Member List, so any member/lurker can easily edit the website
once granted permission.

2. Set up a GIT repository for code projects. (forget DARCS, SVN, Monotone)

3. Fare has volunteered to set up UML - UserMode Linux. Hopefully, this
will give us a lot more flexibility while making life easier for Tril.


CODE PROJECTS

(What's needed is for a few core members to start something to show
we're not all talk)

4. Let's declare Common Lisp our "platform of choice" for current
development. We recognize that it's far from ideal, and intend to
replace it with The Right Thing eventually. Meanwhile, at least we can
use try out Tunes ideas as we write *useful* programs that run on
*existing* systems.

(a) Write a short guide on getting started with CL quickly and
painlessly (short short version: install Debian/Ubuntu; install sbcl,
emacs21, slime, cua.el) I'll do this since I'm new to CL.

(b) Add PLT-style embedding of different syntaxes, to make CL
attractive to people like me who hate its syntax [see DrScheme, DrPython]

(c) Add a "compembler" [see Movitz]

(d) Add Erlang-style concurrency, Software Transactional Memory
(essentially a language-independent version of SQL transactions),
Algebraic Data Types, and so on... (see item #6 below)

5. Take a thorough look at the following projects to see what we can
learn/borrow from them, or add to them:

- Movitz (a Lisp OS)
- POP-11 (an old multi-paradigm language system)
- McCLIM (a Lisp user interface system *similar* to Tunes UI ideas)
- PLT Scheme (with its innovative IDE) and related work

6. Begin preparations for Google SoC 2008. For starters, see Fare's
term project proposals
[http://fare.tunes.org/computing/term-project-proposal.html]


RESEARCH / BRAINSTORMING

7. Imagine a future Internet with standardized content-addressable
storage, decentralized name lookup, a meaningful concept of identity,
peer-to-peer wireless mesh networks, or whatever innovations you can
think of. In that context, address the "Tunes Distributed Publishing"
problem...


Anyway, that's my take. Fare may have something to add. Comments most
welcome.

- Tom

[M. Edward (Ed) Borasky]

Post by Tom Novelli
Greetings...
I met up with Fare for another informal planning session 2 weeks ago.
(I apologize for the delay; I've spent those 2 weeks trying to make the
Commonwealth of Massachusetts live up to its promise of affordable
health insurance. But that's another story!) Anyway, without further
WEB SITE
1. I will upgrade the CMS any day now (and rename it according to RMS's
terminology - Website Revision System - which makes more sense to me!)
Major changes include WSGI support, simplifications, and integration
with the Member List, so any member/lurker can easily edit the website
once granted permission.
2. Set up a GIT repository for code projects. (forget DARCS, SVN, Monotone)
3. Fare has volunteered to set up UML - UserMode Linux. Hopefully, this
will give us a lot more flexibility while making life easier for Tril.
CODE PROJECTS
(What's needed is for a few core members to start something to show
we're not all talk)
4. Let's declare Common Lisp our "platform of choice" for current
development. We recognize that it's far from ideal, and intend to
replace it with The Right Thing eventually. Meanwhile, at least we can
use try out Tunes ideas as we write *useful* programs that run on
*existing* systems.
(a) Write a short guide on getting started with CL quickly and
painlessly (short short version: install Debian/Ubuntu; install sbcl,
emacs21, slime, cua.el) I'll do this since I'm new to CL.
(b) Add PLT-style embedding of different syntaxes, to make CL attractive
to people like me who hate its syntax [see DrScheme, DrPython]
(c) Add a "compembler" [see Movitz]
(d) Add Erlang-style concurrency, Software Transactional Memory
(essentially a language-independent version of SQL transactions),
Algebraic Data Types, and so on... (see item #6 below)
5. Take a thorough look at the following projects to see what we can
- Movitz (a Lisp OS)
- POP-11 (an old multi-paradigm language system)
- McCLIM (a Lisp user interface system *similar* to Tunes UI ideas)
- PLT Scheme (with its innovative IDE) and related work
6. Begin preparations for Google SoC 2008. For starters, see Fare's
term project proposals
[http://fare.tunes.org/computing/term-project-proposal.html]
RESEARCH / BRAINSTORMING
7. Imagine a future Internet with standardized content-addressable
storage, decentralized name lookup, a meaningful concept of identity,
peer-to-peer wireless mesh networks, or whatever innovations you can
think of. In that context, address the "Tunes Distributed Publishing"
problem...
Anyway, that's my take. Fare may have something to add. Comments most
welcome.

About the platform -- Common Lisp? Why not Gambit Scheme? You get:

1. Scheme, of course, both compiled and interpreted
2. Termite -- Erlang-style concurrency embedded in Scheme.

I don't know how efficient Gambit is relative to the other C-based
Scheme implementations, although I think it's slightly slower than
Chicken on average. It's probably more efficient than SBCL, though --
doesn't SBCL compile to bytecode rather than real code or C?

Or -- since you're "borrowing" from PLT Scheme, why not just use PLT Scheme?

But then, if it must be Common Lisp for some reason, SBCL is clearly the
one to use.

On the OS -- Debian is OK for me, although I prefer Gentoo. I don't like
Ubuntu -- never have and never will. I'd even pick Fedora over Ubuntu.

By the way, since you haven't asked, what am *I* currently working on? :)

1. I've got a dual-core 4 GB Athlon64 X2 and I'm using AMD's
"CodeAnalyst" to tune the Ruby interpreter on it. It's no great
difficulty to install Gambit, Dr Scheme and SBCL (they're all in Gentoo
and up to date) and profile them as well.

2. When that's done, I'm going to build a Markov chain analyzer in pure
Ruby. Speaking of Summer of Code, one of the Ruby projects this year was
some more matrix routines, and that's exactly what I needed to build this.

Post by Tom Novelli
- Tom

[Tom Novelli]

Post by M. Edward (Ed) Borasky
1. Scheme, of course, both compiled and interpreted
2. Termite -- Erlang-style concurrency embedded in Scheme.
I don't know how efficient Gambit is relative to the other C-based
Scheme implementations, although I think it's slightly slower than
Chicken on average. It's probably more efficient than SBCL, though --
doesn't SBCL compile to bytecode rather than real code or C?
Or -- since you're "borrowing" from PLT Scheme, why not just use PLT Scheme?
But then, if it must be Common Lisp for some reason, SBCL is clearly
the one to use.

If CL is the first choice, Scheme is a close second. Fare used to favor
Scheme, but he favors CL now... he's written a lot about the merits of
each over the years, on the list, his blog, and elsewhere. He uses CL
at ITA. Tril's "Max" reflection project is in CL... Slate was
bootstrapped in CL... and there are other Tunes members who prefer CL.
It seems like this is one thing we can agree on.

I don't want to drive away talented people who happen to hate CL,
however. (I'm a reformed Lisp-hater myself.) We're trying out ideas,
and anything that works in another language ought to work in CL; and if
not, that's a shortcoming we'll eventually need to address in our HLL.

I like PLT Scheme. It's friendly, complete, and runs on all the major
operating systems (unlike the *free* Common Lisps). While friendly, the
IDE is a little clunky... I'd get frustrated using it for serious
programming, but it's a good starting point.

Scheme is too minimal and perfectionist, with very different
implementations -- like Forth. We could easily get bogged down in
compatibility issues if we base our work on Scheme. That said, the
Scheme community has a lot of good ideas, here and there, that should
eventually find their way into Tunes.

SBCL, like CMUCL, compiles to native code. Not that it matters, as it's
a complex monolithic system, and Fare assures me that we can't use the
"compembler method" to extend it at the machine code level -- or rather,
it would be even more work than building a clean *reflective
environment* (TUNES itself) from scratch.

Maybe we could write a "Tunes compatibility layer" for CL and a few
Schemes....

Post by M. Edward (Ed) Borasky
On the OS -- Debian is OK for me, although I prefer Gentoo. I don't
like Ubuntu -- never have and never will. I'd even pick Fedora over
Ubuntu.

I ran Gentoo until 6 months ago... I was spending too much time
re-compiling & configuring programs... I wanted something that *just
works*, so I tried Ubuntu and I'm happy with it. In particular, Lisp
and Emacs work great with little configuration; under Gentoo this was a
pain in the butt. Gentoo scared me away from Lisp/Emacs. Debian is OK,
but it does lag behind... the "stable" release is *obsolete*, "testing"
still lags, and if you need something in "unstable" you might as well
use Ubuntu.

I'd recommend Ubuntu or Debian for a new Tunes hacker who doesn't want
to be bothered with the gory details of Unix... or an old Unix hacker
who's sick of it!

Post by M. Edward (Ed) Borasky
By the way, since you haven't asked, what am *I* currently working on? :)
1. I've got a dual-core 4 GB Athlon64 X2 and I'm using AMD's
"CodeAnalyst" to tune the Ruby interpreter on it. It's no great
difficulty to install Gambit, Dr Scheme and SBCL (they're all in
Gentoo and up to date) and profile them as well.

I've got the same thing, just because it was cheap... I'm not exactly
pushing its limits. Anyway, I guess you'll just let us know which
implementation takes advantage of the dual-core best?

Post by M. Edward (Ed) Borasky
2. When that's done, I'm going to build a Markov chain analyzer in
pure Ruby. Speaking of Summer of Code, one of the Ruby projects this
year was some more matrix routines, and that's exactly what I needed
to build this.

Cool.. let us know how it turns out.

- Tom

[M. Edward (Ed) Borasky]

Post by Tom Novelli
If CL is the first choice, Scheme is a close second. Fare used to favor
Scheme, but he favors CL now... he's written a lot about the merits of
each over the years, on the list, his blog, and elsewhere. He uses CL
at ITA. Tril's "Max" reflection project is in CL... Slate was
bootstrapped in CL... and there are other Tunes members who prefer CL.
It seems like this is one thing we can agree on.
I don't want to drive away talented people who happen to hate CL,
however. (I'm a reformed Lisp-hater myself.) We're trying out ideas,
and anything that works in another language ought to work in CL; and if
not, that's a shortcoming we'll eventually need to address in our HLL.

I don't hate CL ... as long as Termite can be ported to SBCL, I don't
see any reason not to go with SBCL.

Post by Tom Novelli
I like PLT Scheme. It's friendly, complete, and runs on all the major
operating systems (unlike the *free* Common Lisps). While friendly, the
IDE is a little clunky... I'd get frustrated using it for serious
programming, but it's a good starting point.

If SBCL doesn't run in Windows, it's pretty close. I assume you are
referring to *native* operation on Windows, not "MinGW/MSYS" or Cygwin
operation! The other "major operating systems" (Mac OSX, Solaris, Linux
and *BSD) shouldn't be a problem for any open source package.

Post by Tom Novelli
SBCL, like CMUCL, compiles to native code. Not that it matters, as it's
a complex monolithic system, and Fare assures me that we can't use the
"compembler method" to extend it at the machine code level -- or rather,
it would be even more work than building a clean *reflective
environment* (TUNES itself) from scratch.
Maybe we could write a "Tunes compatibility layer" for CL and a few
Schemes....

You should only have to write two compatibility layers -- one for ANS
Common Lisp and another for the "prevailing" Scheme standard. The Gambit
people voted against the latest Scheme standard, so it's probably "N - 1".

Post by Tom Novelli
I ran Gentoo until 6 months ago... I was spending too much time
re-compiling & configuring programs... I wanted something that *just
works*, so I tried Ubuntu and I'm happy with it. In particular, Lisp
and Emacs work great with little configuration; under Gentoo this was a
pain in the butt. Gentoo scared me away from Lisp/Emacs.

The Gentoo Lisp/Emacs setup was derived from Debian's. However, the main
Gentoo Lisp developer "retired" and I'm not sure who's watching the
store now.

Post by Tom Novelli

Post by M. Edward (Ed) Borasky
By the way, since you haven't asked, what am *I* currently working on? :)
1. I've got a dual-core 4 GB Athlon64 X2 and I'm using AMD's
"CodeAnalyst" to tune the Ruby interpreter on it. It's no great
difficulty to install Gambit, Dr Scheme and SBCL (they're all in
Gentoo and up to date) and profile them as well.

I've got the same thing, just because it was cheap... I'm not exactly
pushing its limits. Anyway, I guess you'll just let us know which
implementation takes advantage of the dual-core best?

When I first got the machine, I tried them all -- Etch, Ubuntu (Feisty,
IIRC), CentOS 5, Fedora 7, and Gentoo 2007.0. They all pretty much were
new releases concurrently with my getting the hardware. I was prepared
to hate Fedora, but I was pleasantly surprised. Fedora (Core) < 7 is
useless. Etch and CentOS were both rock-solid, stable, boring, etc.
Either one would make a fine production machine, although I'd give the
edge to CentOS for that because there are more Red Hat trained sysadmins
than there are Debian trained ones.

But for a scientific workstation, the choice is really between Fedora,
Gentoo, or Ubuntu/Lenny/Sid. Normally my ranking would be Gentoo,
Ubuntu/Lenny/Sid, Fedora. But I just couldn't work with Ubuntu. I don't
remember all the gory details, but it ended up being a dead tie between
Fedora and Gentoo. I didn't want to switch my brain from Gentoo to
Fedora, so I went with (stayed with) Gentoo.

[Faré]

Post by M. Edward (Ed) Borasky
I don't hate CL ... as long as Termite can be ported to SBCL, I don't
see any reason not to go with SBCL.

I don't think termite itself can be ported to CL, and I don't think it
sports the important aspect of Erlang that you can send asynchronous
signals (i.e. kill threads at any moment).

Instead, I intend to implement a system that allows Erlang-style
thread-killing on top of CL, using a combination of fork and green
threads for selectable grain in thread-dependencies. I have started
working on it (have built green threads on top of arnesi:with-call/cc,
and some preliminary work on forking), but haven't invested enough
energy in it yet to complete the task.

Eventually, I would like a system that has user-declared hierarchies
of safe-points, as in my thesis, but that requires control over
code-generation for decent performance, and thus compiler support -
i.e. writing my own compiler or deeply subverting an existing one. I
still haven't really started on this one, and don't know which
compiler to subvert. Maybe the one from Movitz? or the code by Ian
Piumarta? PLT internals are some unworkable one-man thing, and SBCL
seems somewhat hard to subvert in such directions.

Post by M. Edward (Ed) Borasky
But for a scientific workstation, the choice is really between Fedora,
Gentoo, or Ubuntu/Lenny/Sid.

It shouldn't matter much, as we should write our code in standard
enough CL (or PLT Scheme, or Slate) to be bootstrappable from
semi-standard packages.

Bespin uses debian (soon to be Etch). I use debian lenny at home.
tarballs for whatever we bootstrap from should available on any
platform.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Tomorrow will be different from today and from anything that existed in the
past. Tomorrow is a utopia. The only question is to determine which.