I am surprised to hear that darcs didn't work on windows. It must work
for some people though, there is even a GUI browser for darcs on
windows: http://tortoisedarcs.sourceforge.net/
I think someone (possibly PG) wrote he had never heard of anyone knowing
Common Lisp well switching to Java unless
Scribit Robert L. Read dies 25/03/2007 hora 13:27:
> Obviously, if darcs doesn't work well with Windows, that is not a
> point in its favor.
As I said, if eventually you don't decide to use darcs, but wish to use
a DCVS, I strongly recommend Mercurial. It seems to work nicely on
Windows, has a cle
On Sun, 25 Mar 2007 13:25:13 -0500, "Robert L. Read" <[EMAIL PROTECTED]> wrote:
> This is surprising to me; I don't think we have two connections
> open.
Not any more, I think Ian changed something after I reported this.
I'm pretty sure that at that time I had traced CLSQL:CONNECT and I saw
two c
On Sun, 25 Mar 2007 13:27:23 -0500, "Robert L. Read" <[EMAIL PROTECTED]> wrote:
> I am willing to consider using either subversion or darcs; I'll let
> Ian decide. Obviously, if darcs doesn't work well with Windows,
> that is not a point in its favor.
I'm not sure if I sent this to Ian or to the
On Sat, 2007-03-24 at 17:03 +0100, Edi Weitz wrote:
> I won't be able to work with the Darcs repository, though. I've spent
> some quality time a few months ago to get it to work with Windows and
> didn't succeed and I won't do it again. I have better things to do in
> my spare time. If you're
On Fri, 2007-03-23 at 14:09 +0100, Edi Weitz wrote:
> On Fri, 23 Mar 2007 07:30:38 -0400, Ian Eslick <[EMAIL PROTECTED]> wrote:
>
> > The SQLite problem is a known one. There is some initialization
> > problem that causes this error - however it is only when creating
> > the DB. Once you've cre
On Sat, 2007-03-24 at 16:27 +0100, Edi Weitz wrote:
> In the long run you should try to get rid of absolute pathnames at all
> (or use them only for building) and trust the OS to find external
> programs and shared libraries from the filename sans directories.
> Otherwise it will be very hard or a
With latest HEAD, both BDB and SQLite3 passed the whole test suite
including migration on both i386 and amd64 under Debian GNU/Linux, with
SBCL 1.0.0.0.
Which is great news, because this release will come just as I need
Elephant in a project with similar constraint as the previous one, where
I had
On Sat, 24 Mar 2007 11:47:55 -0400, Ian Eslick <[EMAIL PROTECTED]> wrote:
> I think the solution for Joe Average is as Edi suggested earlier,
> we'll bundle Win32 DLLs with each release and people who want to
> track the development tree or use 64-bit Windows will, for now, have
> to solve the iss
Frank/Edi,
I think the solution for Joe Average is as Edi suggested earlier,
we'll bundle Win32 DLLs with each release and people who want to
track the development tree or use 64-bit Windows will, for now, have
to solve the issues related to building images.
As soon as we're done with 0.6
On Fri, 23 Mar 2007 17:02:40 +0100, Frank Schorr <[EMAIL PROTECTED]> wrote:
> ((:berkeley-db-include-dir . "C:/Programme/Oracle/Berkeley DB
> 4.5.20/include/")
> (:berkeley-db-lib-dir . "C:/Programme/Oracle/Berkeley DB 4.5.20/bin/")
> (:berkeley-db-lib . "C:/Programme/Oracle/Berkeley DB 4.5.20/
On Fri, 23 Mar 2007 12:14:33 -0400, Ian Eslick <[EMAIL PROTECTED]> wrote:
> config.sexp is only a reference file. You copy this to my-
> config.sexp and then edit the paths to be the appropriate ones for
> your system.
In the long run you should try to get rid of absolute pathnames at all
(or us
My bad - I just promoted a change that led to this. Will be fixed
shortly.
Ian
On Mar 24, 2007, at 12:59 AM, Pierre THIERRY wrote:
Scribit Pierre THIERRY dies 24/03/2007 hora 05:52:
BDB still gets stuck at:
Migrating class indexes for: IDX-UNBOUND-DEL
I tried again, after running delscr
Scribit Pierre THIERRY dies 24/03/2007 hora 05:52:
> BDB still gets stuck at:
>
> Migrating class indexes for: IDX-UNBOUND-DEL
I tried again, after running delscript.sh and setting rt::*catch-errors*
to nil, and got in the debugger with that:
-
Scribit Ian Eslick dies 23/03/2007 hora 12:33:
> I think I've fixed this.
I tested again with latest HEAD, and end up with this for SQLite:
2 out of 122 total tests failed: MIGRATE-BASIC, MIGRATE-IPCLASS.
WARNING:
Unable to clear class index caches Object's store controller was lost
BDB still
I think I've fixed this. There was some legacy code with some
hardcoded paths in ele-clsql that never effected me but appears to
serve no purpose. I commented it out, but if it causes some other
system to fail then we'll have to look at it more closely.
Ian
On Mar 23, 2007, at 2:45 AM, P
ndet: 23.03.07 15:23:10
An: Elephant bugs and development
Betreff: Re: [elephant-devel] Start of 0.6.1 Beta Cycle
On Fri, 23 Mar 2007 10:11:58 -0400, Ian Eslick
<[EMAIL PROTECTED]> wrote:
I think the cygwin version is slow to update their versions and for
various reasons we tend to depend
I've checked in a fix for this that I verified under Allegro / Mac.
Ian
On Mar 23, 2007, at 9:09 AM, Edi Weitz wrote:
On Fri, 23 Mar 2007 07:30:38 -0400, Ian Eslick
<[EMAIL PROTECTED]> wrote:
The SQLite problem is a known one. There is some initialization
problem that causes this error -
bugs and development
> Gesendet: 23.03.07 15:23:10
> An: Elephant bugs and development
> Betreff: Re: [elephant-devel] Start of 0.6.1 Beta Cycle
> On Fri, 23 Mar 2007 10:11:58 -0400, Ian Eslick <[EMAIL PROTECTED]> wrote:
>
> > I think the cygwin version is slow to u
On Fri, 23 Mar 2007 10:11:58 -0400, Ian Eslick <[EMAIL PROTECTED]> wrote:
> I think the cygwin version is slow to update their versions and for
> various reasons we tend to depend on the latest release (4.5 in this
> case).
Really? I thought that BerkeleyDB was always distributed as a whole
with
I think the cygwin version is slow to update their versions and for
various reasons we tend to depend on the latest release (4.5 in this
case).
Your point on windows builds is well taken. Here is a possible
approach:
By default, we distribute DLLs with major releases and major
developm
On Fri, 23 Mar 2007 09:19:49 -0400, Ian Eslick <[EMAIL PROTECTED]> wrote:
> Any ideas for a better solution on your end? I have to admit to an
> extreme dislike of cygwin after a nasty summer in it's company some
> years back.
I think you can't really blame Cygwin in this case because Elephant
u
On Fri, 23 Mar 2007 08:32:23 -0500, "Robert L. Read" <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-03-23 at 10:28 +0100, Edi Weitz wrote:
>
>> (DO-BACKEND-TESTS (QUOTE (:CLSQL (:POSTGRESQL NIL "elephant" NIL NIL
>
> This doesn't look like a good connect string to me.
It's a connection spec accept
On Fri, 2007-03-23 at 10:28 +0100, Edi Weitz wrote:
> (DO-BACKEND-TESTS (QUOTE (:CLSQL (:POSTGRESQL NIL "elephant" NIL
> NIL
>
This doesn't look like a good connect string to me.
This may be an example where better documentation would help us.
The best documentation on this right now is Ia
Ah yes, there's a problem with db.h and mingw that we need to
document in the INSTALL instructions. I'm not sure if there is a
tasteful way around this, but sys/types.h defines ssize_t differently
than db.h, so they appear to be incompatible.
Frank Schorr had this solution, but it isn't id
On Fri, 23 Mar 2007 07:30:38 -0400, Ian Eslick <[EMAIL PROTECTED]> wrote:
> The SQLite problem is a known one. There is some initialization
> problem that causes this error - however it is only when creating
> the DB. Once you've created it, and restart the tests, it should
> work. I haven't ha
On Fri, 23 Mar 2007 07:30:38 -0400, Ian Eslick <[EMAIL PROTECTED]> wrote:
> I believe you can download a pre-built BDB Windows DLL distribution
> from Oracle.
Yeah, I had that installed, but I wasn't aware that I could expect an
automatic build because I originally saw lots of errors flying by.
Thank you for the work!
The SQLite problem is a known one. There is some initialization
problem that causes this error - however it is only when creating the
DB. Once you've created it, and restart the tests, it should work.
I haven't had the time to track this down and Robert has been b
FWIW, I tried to build Elephant (current CVS) with LWW 5.0.1. I
understand that Windows is currently not supported, but maybe you're
interested anyway. Here's a summary:
I have Cygwin installed. I had to make a few changes to make the
build succeed for which a patch is attached. This includes
With:
- Debian GNU/Linux 2.6.18 amd64
- SBCL 1.0.0.0
- BDB backend
Compilation failed with:
Berkeley DB error: Invalid argument
Here is the compiler output for the relevant compilation unit:
; file: /home/pierre/Lisp/Elephant/elephant-CVS/src/db-bdb/bdb-transactions.lisp
; in: DEFMETHOD
Scribit Ian Eslick dies 21/03/2007 hora 11:42:
> We have tagged CVS with the tag ELEPHANT-0-6-1-BETA.
With:
- Debian GNU/Linux 2.6.18 amd64
- SBCL 1.0.0.0
- SQLite3 backend
3 of 122 tests failed:
- MIGRATE-BASIC
- MIGRATE-IDX-BTREE
- MIGRATE-IPCLASS
I still have difficulties loading CL-SQL, exce
Henrik,
I think there's a confusion here because we have not properly
communicated the semantics we are intending for map-index. You have
properly identified a problem in mine (inability to traverse null
values) which I introduced to solve a problem I anticipated that
shows up under your
Great work.
It seems that one of my changes yesterday introduced a bug, so Ian fixed
that bug and my change disappeared in the process. It suits me right,
because I really should have made a testcase showing the bug before
fixing it. Better later than never though.
I modify the test indexing-basic
We have tagged CVS with the tag ELEPHANT-0-6-1-BETA. OpenMCL still
needs verification, but has been verified in the past so I don't
think it's much work and the current tree seems very stable and
addresses all the outstanding issues we documented and discovered for
0.6.1.
This would be a
34 matches
Mail list logo
