water at tunes.org
Sun Oct 29 12:14:19 PST 2006
After some server maintenance and subsequent hiccups, the site is
On Oct 28, 2006, at 8:30 AM, Tom Novelli wrote:
> On 10/25/06, Brian Rice <water at tunes.org> wrote:
>> > I'll volunteer to -- do it *this month*, as soon as I get enough
>> > on the wording.
>> Sorry, maybe this was intended as a specific request for input on the
>> wording... I suggest you just start trying to do it, and
>> incrementally get feedback. The worst that happens is that the good
>> PR we get for trying to do the site is tarnished just slightly by
>> exposing some of our editing process.
> Ok, I've gone and changed the front page... the month is over and
> nobody has complained. I backed up /serv/tunes/tunes/ this morning,
> in preparation for some major clean-up... I'll just start chopping...
> if I get carried away, just let me know and I'll fix it!
It looks like a good start.
> At the last minute I remembered the website is maintained by CVS, and
> rebuilt every midnight.... It's an arcane system but it works, and
> it's not so bad for me now that I finally have broadband internet. I
> suppose we should keep it until we have a replacement ready...?
Yeah, I suppose, but these days it's pretty easy to move from CVS
into Subversion which supports scripting hooks so that site updates
can merely be driven from commits to a particular release branch. I
can explain this in detail on request but I learned it just from
online SVN documentation... it's not too hard. I personally like
Darcs, but it's overkill in this case, I'd wager.
And we don't need the CVS meta-data line in our web-pages any more...
it doesn't do us any good and looks ugly. Actually, these days the
trendy/more-appropriate thing to do is use <LINK REL=History
href=...> tags in the header to deal with meta-data like version
history, and just have the page itself contain text copy.
> Here's the plan:
> - Pinch some Wiki formatting code from Cliki and a JS wiki; adapt to
> make them match; rewrite later.
Cliki doesn't contain much formatting code - it'll be pretty simple.
These days there's also CL-PPCRE for advanced regexp-y goodness, not
to mention some other equally valid CL text packages: http://
Here's an example of a particular wiki-ish syntax being re-done in CL:
(syntax described at http://daringfireball.net/projects/markdown/
> - Set up a simple web-based editing system... (Enter a password, edit
> pages like a wiki, stored as text files... Convert to HTML upon
> saving.) Write new material in this "wiki" format... adapt the format
> as needed.
At a recent local Lisp/functional meeting, someone mentioned http://
www.wikimatrix.org for wiki software feature comparisons. You should
check that out just to see what's well-known and available. There are
quite an interesting number and degree of alternatives.
> - Design a database to *organize* the content in a fairly fine-grained
> way, with robust security, versioning, cross-referencing, etc.
Sure, and there are probably some available CMS database schema that
could be used as a template (although I haven't looked for that in
> I have CMUCL, SBCL, UCW, MySQL, CLSQL and CL-AJAX sitting here;
> hopefully I'll get into the web/db stuff this weekend. I think I've
> learned enough Lisp by now.
> My initial impression of Common Lisp is that it's over-complicated and
> it doesn't have as nice a codebase as Python because it's not as
> popular (although guys like Fare are working hard to change that).
Common Lisp is certainly big and reflects a huge amount of (awkward)
political compromise, and yes it helps to have a big community that
all weigh in and contribute to each other's work to refine the
libraries that people initially start.
That said, CL does allow you to start in a blank package and, say,
create an entirely CLOS-oriented dialect within it. Up to a point,
anyway, after which you need to look into writing a compiler or
> Still, Lisp seems like the Right Thing (tm) in the long run. Ideally,
> I think, we'd design a cleaner dialect of Lisp for use as an
> all-purpose intermediate language, and implement CL, Slate, Python,
> ECMAscript, etc. on top of that. I prefer Python's syntax. The nice
> thing about CL is, it's mature. Does all this make sense?
Python's syntax has been done as a "skin" on lisp in various packages
and I can imagine a future where code is not textual but is
interacted with in a "MVC" style fashion (higher-order tree-
transformation with massively-customizable editing framework, blah
blah blah). So I'd basically say that whatever syntax trees were
edited would be most directly renderable as Lisp, rather than being
Lisp itself. I'm assuming here that you're proposing this text for
website introductory copy, because doing all of this is a Lot Of Work.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/tunes/attachments/20061029/5e1e5572/PGP.pgp
More information about the TUNES