chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] CR #1142 and upcoming changes


From: Jörg F. Wittenberger
Subject: Re: [Chicken-hackers] CR #1142 and upcoming changes
Date: Wed, 20 Aug 2014 13:56:34 +0200
User-agent: Mozilla/5.0 (X11; Linux armv7l; rv:24.0) Gecko/20100101 Icedove/24.5.0

Am 18.08.2014 17:06, schrieb Peter Bex:

Yeah, we're pretty thinly spread right now.

I think calling this CHICKEN 5 may be a good idea.  I don't know for
sure though: adding backwards compatibility may actually be easier
in this situation.  Ripping out the SRFIs from core should be pretty
simple, but it does require updating all the eggs.  And of course
there's shitloads of eggs that are unmaintained, which will break
and never get fixed.  So all in all, starting over might be easiest.

I'd love to hear from some of the people using CHICKEN in their business
or for other Serious Projects (Kristian? Ivan? Andy?) how painful this
would be for them.

I rely on chicken every day. Web pages, file system (at least one directory) with content synchronization, calendar etc. Customers depend on it too.

Our code is fairly demanding (after all: p2p consensus is demanding) and moreover required to produce the same results (down to crypto hashs) using alternative implementations. (Which is not always easy, since things like print representations of number pose easily a problem. Another is that SQLite might change the memory layout it produces without notice - which is why we now include a reference to a specific version.)

Also: we often use "strange" hosts: no root, badly administrated (for whatever reasons).

This lead to the decision that we don't use anything eggs infrastructure at all. Instead we always test the static compiled build too.

I'll have to see how to deal with the planned changes. Currently I'm a bit busy writing a little application.

Best

/Jörg




reply via email to

[Prev in Thread] Current Thread [Next in Thread]