Hello everybody,
Based on the constructive feedback we have got on the CDR process so
far, we have made some changes to CDR as follows.
+ First, due to the fact that the CDR process has been described as
CDR 0 which has already been finalized, strictly speaking we aren't
allowed to make changes to CDR anymore. We have solved this by
resubmitting the CDR process itself as CDR 4. You can find the new
version at http://cdr.eurolisp.org/document/4/ together with the
changes compared to CDR 0 (which are also described below).
Since we expect more suggestions for improvement in the near future,
we use an exceptionally long initial period for CDR 4 until November
1, 2007. This allows us to make changes as we go along. At the same
time, the CDR process in use will already be CDR 4. This means that
the CDR process for submitted CDRs until then will be somewhat
unstable, but we think that this gives us the advantage of being able
to experiment a little such that the final result will hopefully be a
better tested process.
Consider this equivalent to the bootstrapping of a metacircular
software architecture, or to the development of any new piece of
software for that matter, where you have to test and change things as
you go as well. ;)
+ We have added more details about submission of accompanying
material, especially with regard to licenses that give us the right
to publish it at the CDR website and related publications. We forgot
about this issue in CDR 0.
+ We have added a section where we ask authors and submitters to
provide rationales for changes they have made during the initial
period. From now on, we also intend to add archives of previous
versions of a CDR for better traceability of such changes.
+ We have added a mailing list cdr-discuss - see http://common-lisp.net/cgi-bin/mailman/listinfo/cdr-discuss for the mailing list
page. This mailing list is supposed to be used for discussions about
specific CDRs. This is especially useful when CDRs are in their
initial period, but may also be useful afterwards. The already
existing cdr-devel is purely for discussions about issues related to
CDR itself (that go beyond the scope of what is described in CDR 0
and CDR 4).
We hope that these changes address the suggestions we have got so far.
Best,
Pascal
--
Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium
_______________________________________________
cdr-announce mailing list
cdr-announce(a)common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cdr-announce
On Sat, 18 Nov 2006 08:47:55 +0100, "Marijn Haverbeke" <marijnh(a)gmail.com> wrote:
> Attached is the patch, I went with the name *handle-http-errors-p*
> instead.
Thanks a lot - it's in the latest release.
Cheers,
Edi.
_______________________________________________
tbnl-announce site list
tbnl-announce(a)common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-announce
On Tue, 14 Nov 2006 20:34:07 +0200, "Anton Vodonosov" <vodonosov(a)mail.ru> wrote:
> It sometimes necessary to recover from flexi-stream-encoding-error.
>
> For example, it's inconvenient now to use drakma for sites with
> broken utf encoding (like this livejournal page
> http://hzweiblum.livejournal.com/)
>
> I can see this page in my browser (with ? instead of badly encoded
> chars), but (http-request "http://hzweiblum.livejournal.com/") fails
> signaling flexi-stream-encoding-error.
Hmm, works for me.
> It will be good to have possibility to supply a character that will
> be used as a substitution for invalid byte sequence.
>
> use-value restart is added to the get-char-code function in the
> attached patch.
I've added your code to the new release. See also the new special
variable *SUBSTITUTION-CHAR*.
Thanks,
Edi.
_______________________________________________
flexi-streams-announce mailing list
flexi-streams-announce(a)common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/flexi-streams-announce
On Thu, 09 Nov 2006 14:55:58 -0700, "Robert J. Macomber" <tbnl(a)rojoma.com> wrote:
> There seems to be some small bugs involving header-out. The
> accessor is documented to take both keywords and strings, but
> neither works reliably because:
>
> [snip]
Yes, you're absolutely right. Thanks for spotting that. As I said,
there were obviously too many (untested) changes at once when I
switched from TBNL to Hunchentoot.
> Here's a patch which normalizes things so the keys of this alist are
> always strings and the lookup is always done with strings.
I've changed this a little bit because I prefer that the keys are
strings.
Thanks,
Edi.
_______________________________________________
tbnl-announce site list
tbnl-announce(a)common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-announce
Hi all,
I would like to announce the availability of cl-migrations, a port of
the migrations feature of Ruby on Rails to Common Lisp. cl-migrations is
a simple tool to manage your changes to a database as you develop your
web application or any database-backed application.
It works by generating a new file to put for each database change, which
contains the ddl required to enable and disable that change. So,
effectively you can version-control your database structure. You can
move to a particular version (whether back or forth) of your database
structure by simply doing:
(cl-migrations:migrate :version 42)
You can install this tool with asdf:
(asdf-install:install :cl-migrations)
This tool depends on clsql, so you can run migrations on any database
that is supported by clsql. Many thanks to Kevin Rosenberg for
maintaining such a useful library.
For more info, please go to this page:
http://common-lisp.net/project/cl-migrations/
Kindly raise any questions/feature requests/bug-reports here:
http://common-lisp.net/cgi-bin/mailman/listinfo/cl-migrations-devel
Regards,
Vamsee Kanakala.
_______________________________________________
cl-migrations-announce mailing list
cl-migrations-announce(a)common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cl-migrations-announce
Ingvar Mattsson has submitted a new version of CDR 2 which is now
available at http://cdr.eurolisp.org/document/2/
Cheers,
Pascal
--
Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium
_______________________________________________
cdr-announce mailing list
cdr-announce(a)common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cdr-announce
On Sun, 29 Oct 2006 03:07:26 +0100, Edi Weitz <edi(a)agharta.de> wrote:
> I just realized that Hunchentoot in its current form has problems
> with file uploads if it's used behind mod_lisp.
I think I've fixed this in 0.4.8 now. At least I found something in
START-OUTPUT which was obviously wrong and a result of my porting and
re-factoring Hunchentoot/TBNL too hastily.
Cheers,
Edi.
_______________________________________________
tbnl-announce site list
tbnl-announce(a)common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-announce
On Sun, 05 Nov 2006 14:18:50 -0700, "Robert J. Macomber" <tbnl(a)rojoma.com> wrote:
> Depends on whether you're interested in the user's (claimed) real
> address, or the address the user presents to the web server to which
> he thinks he's speaking. In my case, I'm interested in the latter
> (that is, I'm just interested in what REMOTE-ADDR would be if
> Hunchentoot weren't behind a server-side proxy). Having looked at
> the documentation for sessions in the past five minutes, I see that
> that machinery is interested in the former.
OK, I've implemented the version I described in my previous email.
The new release also fixes the bug in COOKIE-OUT you mentioned.
Thanks,
Edi.
_______________________________________________
tbnl-announce site list
tbnl-announce(a)common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-announce
On Sat, 4 Nov 2006 21:48:24 +0100, "Marijn Haverbeke" <marijnh(a)gmail.com> wrote:
> A good fix would be to just call *meta-dispatcher* for every call to
> dispatch-request, so that you've always got the most recent
> dispatch-table and the programmer can fiddle with that variable from
> the REPL and immediately see the result.
I've implemented that now in the new version. *META-DISPATCHER* came
in pretty late in the game, and it wasn't intended to behave like it
did until 0.4.5. Thanks for the report.
Cheers,
Edi.
_______________________________________________
tbnl-announce site list
tbnl-announce(a)common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-announce