headers
Marco Baringer | 2 Mar 2004 08:36
Picon

[ANN] UnCommon Web 0.2 - learning to walk

UnCommon Web version 0.2.0 - learning to walk

* Home Page

http://common-lisp.net/project/ucw/

* Download

ftp://ftp.common-lisp.net/pub/project/ucw/ucw_0.2.0.tar.gz

NB: This tar ball contains not only ucw but also every single library
UCW depends on and pristine trees for every arch controlled
project.

* New Features (since 0.1.0)

** UCW

- Well defined, extensable, request/action handling protocol

- Initial support support for i18n.

- Session expiration and session transactions.

- The CPS transformer is much more capable and faster.

** UCW Component Library

- New: Tabbed Pane.
(Continue reading)

Permalink | Reply | 2 comments |
headers
rm | 2 Mar 2004 13:55
Picon

Re: [Lispweb] [ANN] UnCommon Web 0.2 - learning to walk

On Tue, Mar 02, 2004 at 08:36:00AM +0100, Marco Baringer wrote:
> UnCommon Web version 0.2.0 - learning to walk
> ftp://ftp.common-lisp.net/pub/project/ucw/ucw_0.2.0.tar.gz
> 
> NB: This tar ball contains not only ucw but also every single library
> UCW depends on and pristine trees for every arch controlled
> project.

Hi Marco, is there a reason you include the whole arc tree in the 
tarball? People not using arch won't need it and those using
arch won't need the tarball ...

> 
> happy hacking,

Same to you, thanks

   RalfD
Permalink | Reply | 0 comments |
headers
Robert STRANDH | 4 Mar 2004 08:42
Picon

Flexichain library specification

Hello, 

Matthieu Villeneuve and myself have been working on a library for
storing sequences of objects such that objects can be efficiently
inserted in and deleted from the sequence.  

I am working mostly on the specification, whereas Matthieu is working
on the implementation, which is hard, because I keep changing the
specification.  Actually, he has not yet seen the latest version of
the specification, so I hope he will not faint. 

The library is called `flexichain' (thanks to Tim Moore for letting me
use the `flexi-' prefix).  Potential clients for this library are
Goatee (the text editor of McCLIM), Portable Hemlock, and Gsharp, the
interactive, extensible score editor.  The implementation is an
improved gap-buffer with circular storage to speed up worst-case
operations by a factor two and eliminate an annoying worst case (queue
operations).

We decided to write this library because something with this
functionality is often needed, as is evident from the numerous times
people (including myself) have come up with less efficient and less
general code for a subset of this functionality. 

At this time, we would like for you all to help us review and improve
the specification, so that we can freeze it and let Matthieu work in
peace.  Here it is:

   http://dept-info.labri.fr/~strandh/flexichain.ps
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nikodemus Siivola | 4 Mar 2004 11:08
Picon
Picon

Re: Flexichain library specification

On Thu, 4 Mar 2004, Robert STRANDH wrote:

Oooh, jummy. Good spec.

> Although we have thought pretty hard about naming, we are open to
> suggestions for improving names of operations, protocols, classes,
> etc.

I hesitate to call the following suggestions -- more like thoughts that
came to mind. In general I'd drop the the "flexi" prefix: call them chains
and cursors. Also, -error postfix in all error condition names might be
good.

flexichain initargs :fill-element

 I'm probably missing something obvious here: why is this argument
 required for non-standard type? Could it not eg. default to first
 element written unless it's explicitly provided?

nb-elements

 What about chain-length? The nb- prefix is... ugly.

flexi-position

 What about chain-out-of-bounds-error or chain-position-error?

delete*

 I'm not sure what to think about this. While I like the insert-op names,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luke Gorrie | 13 Mar 2004 21:49

Re: Flexichain library specification

Robert STRANDH <strandh <at> labri.fr> writes:

> Hello, 

Howdy!

> Matthieu Villeneuve and myself have been working on a library for
> storing sequences of objects such that objects can be efficiently
> inserted in and deleted from the sequence.  

[...]

> We decided to write this library because something with this
> functionality is often needed, as is evident from the numerous times
> people (including myself) have come up with less efficient and less
> general code for a subset of this functionality. 

I don't think it's always a subset though. Your interface looks
similar to Emacs (one linear chunk of text with markers/cursors), but
different to Hemlock and Goatee (doubly-linked list of 'line' objects
each containing some text). Other possibilities exist too --
e.g. immutable (copy on change) versions which can give you 'undo' for
"free" (check out Boehm's 'cord' structure [1]). Each design makes
some things easier, some harder, and some just different.

I reckon that experimenting to find the best interface to build the
rest of the editor around is the worthwhile part of editor hacking --
it would be a shame to standardise it away. (I also prefer the Hemlock
interface to the Emacs one, and hear tell that the Dylan editor has
improved things further, so I'm not sure that Emacs would make the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert STRANDH | 14 Mar 2004 07:47
Picon

Re: Flexichain library specification

Hello, 

Luke Gorrie writes:
 > > We decided to write this library because something with this
 > > functionality is often needed, as is evident from the numerous times
 > > people (including myself) have come up with less efficient and less
 > > general code for a subset of this functionality. 
 > 
 > I don't think it's always a subset though. Your interface looks
 > similar to Emacs (one linear chunk of text with markers/cursors), but
 > different to Hemlock and Goatee (doubly-linked list of 'line' objects
 > each containing some text). 

Well, as it turns out, a flexichain can be used instead of the
doubly-linked list; in fact it was designed that way.  Goatee and
Hemlock would typically use a flexichain containing line objects, each
line object being essentially another flexichain.  

 > Other possibilities exist too --
 > e.g. immutable (copy on change) versions which can give you 'undo' for
 > "free" (check out Boehm's 'cord' structure [1]). Each design makes
 > some things easier, some harder, and some just different.

Right.  I was not trying to imply that flexichain would be for
everyone. 

 > I reckon that experimenting to find the best interface to build the
 > rest of the editor around is the worthwhile part of editor hacking --
 > it would be a shame to standardise it away.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nikodemus Siivola | 18 Mar 2004 11:38
Picon
Picon

asdf-build-package

Preliminary versions of release-op and lint-op for ASDF are at:

 http://random-state.net/tmp/asdf-build-package-latest.tar.gz
 http://random-state.net/tmp/asdf-build-package-latest.tar.gz.asc

Release-op makes a release tarball based on an asdf system-definition,
signs it, and makes the appropriate *-latest.* symlinks.

 (oos 'release-op :some-system :directory "/my/tarball/dir/")

Lint-op walks the system -- well more like tiptoes -- and looks for
bad names, "unstylish" forms, etc.

 (oos 'lint-op :some-system)

Both contain some cheeky hacks, and may yet break on systems that
invoke asdf-features I don't usually use. A better name for the bundle
might be asdf-packaging-tools.

I'm proposing to add these as #.(pick-a-name) to cclan CVS & repository.

Duck and cover,

 -- Nikodemus
Permalink | Reply | 0 comments |
headers
Robert STRANDH | 29 Mar 2004 18:13
Picon

Request for comments: project proposal

Hello all, 

Sorry if you get multiple copies of this message. 

Today, I was thinking of a new project.  Not that I have time to
contribute to another one, but I could probably write some
specifications for some summer interns, I guess. 

The purpose of the project (let's call it "Mel") is to write an
end-user email client using Common Lisp + CLIM (McCLIM).  

For a long time, I have been unhappy with "vm" (an extension for
Emacs), and the GNUS documentation recommends "vm" for email.  I do
like having many of my usual Emacs features around, such as abbrevs,
interface to aspell, etc when I read and write email, but there are
some other aspects of "vm" that get on my nerves:

  * loading and saving files.  Mel would use a file format in the form
    of a Lisp image that could be mmaped as opposed to an octet-stream
    representation of mail messages.  Code would have to be written to
    parse MIME into Lisp data structures.

  * duplication.  When a message is saved to a mailbox, it gets
    duplicated.  Mel would just save a pointer.

  * grep is hard.  I can no longer use grep or equivalent on my
    mailboxes, since they are stored in various formats.  Mel could
    use generic function dispatch to make a putative grep method work
    for all kinds of formats.
(Continue reading)

Permalink | Reply | 21 comments |
headers
Ng Pheng Siong | 29 Mar 2004 18:51
Favicon

Re: Request for comments: project proposal

On Mon, Mar 29, 2004 at 06:13:09PM +0200, Robert STRANDH wrote:
> The purpose of the project (let's call it "Mel") is to write an
> end-user email client using Common Lisp + CLIM (McCLIM).  
> [...] 
>   * It is VERY USEFUL and could become a "killer app" for Common Lisp
>     and McCLIM. 

IMHO, a mail client will not match the expectation/standard for a "killer
app" these days.

People are building such things:

  http://www.divmod.org/Home/Projects/Quotient/

  http://www.osafoundation.org/OSAF_Our_Vision.htm

The keyword is 'platform', the construction of which, (perceived) lack of
libraries notwithstanding, CL is very good at.

--

-- 
Ng Pheng Siong <ngps <at> netmemetic.com> 

http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL
Permalink | Reply | 6 comments |
headers
Robert STRANDH | 29 Mar 2004 20:30
Picon

Re: Request for comments: project proposal

Ng Pheng Siong writes:
 > IMHO, a mail client will not match the expectation/standard for a "killer
 > app" these days.
 > 
 > People are building such things:
 > 
 >   http://www.divmod.org/Home/Projects/Quotient/
 > 
 >   http://www.osafoundation.org/OSAF_Our_Vision.htm

Oh, dear.  I must be more out of the loop than I thought (I could
access the first URL but not the second).  Or I guess we could argue
about the definition of "killer app".  

 > The keyword is 'platform', the construction of which, (perceived) lack of
 > libraries notwithstanding, CL is very good at.

I am not sure how to interpret this, but it looks to me like my
suggested project would be a good basis for such a platform.  No? 

--

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
Permalink | Reply | 2 comments |

Gmane