After your e-mail I installed elephant in the my Atlhon64 linux box,
using the latest CVS version of SBCL. The memutil compiled
automaticaly, but I get a diferent error when trying to open-store:
Unhandled memory fault at #x4020002.
[Condition of type SB-SYS:MEMORY-FAULT-ERROR]
Restarts:
0:
"Robert L. Read" <[EMAIL PROTECTED]> writes:
> The contract is that make-instance should only be called once for a
> given object?
FWIW, I wrote a CLOS->SQL layer a few years ago, and I do agreed
with this assessment (that MAKE-INSTANCE should only get called once),
so my protocol ended up with t
Thank you. I have committed this patch to the repository.
However, under sbcl on a x86_64 architecture, I have to build libmemutil
by hand, because of the errors below. I have no way to explain these.
After executing gcc by hand, it is not a problem.
This is the REPL error:
Implicitly c
Thank you, Anton.
I'm sorry it has taken so long to get to this (the holidays clog things
up.)
I applied this patch and was green under SBCL on postmodern and
postgres. I can't test under BDB, but I assumed this was enough
evidence to commit it to the repository, so I have done so.
If anybody
SR> All the methods defined are defined on persistent-object and it
SR> appears that persistent-object
SR> is not on pm-indexed-btree's class-precedence-list which could cause
SR> various amounts of havoc.
doesn't this function do so:
(defmethod shared-initialize :around ((class persistent-me
On Jan 8, 2008 8:35 PM, Sean Ross <[EMAIL PROTECTED]> wrote:
> On a different note, It may be worth requiring that
> perstistent-metaclasses have persistent-object on their class-precedence-list
> although that is bound to have implications that I haven't thought of.
Sorry all, please ignore tha
On Jan 8, 2008 7:38 PM, Robert L. Read <[EMAIL PROTECTED]> wrote:
> Thank you very much, Sean. I suggest you work with Henrik and Alex and
> I on this as well (possibly off-line, outside of this forum.)
Thanks, I'll try and put together an initial proposal for Henrik, Alex
and I to start with.
>
persistent is simply a base class that maintains an OID which is
initialized using the :from-oid (so it picks up the oid during
deserialization by default)
persistent-object is the superclass for all objects for which we are
allowing the persistent slot access protocol
persistent-collecti
Thank you very much, Sean. I suggest you work with Henrik and Alex and
I on this as well (possibly off-line, outside of this forum.)
In case it helps, here is what I tried to do, and what I think I
discovered. Please forgive me if I am inconsistent; I clearly have been
confused on some of these
SR> I'm sorry to hear that my patch caused so many issues with postmodern
SR> and I'm quite keen to investigate the cause of this. I'll be
SR> installing setting up the postmodern backend and seeing if I can track
SR> down the causes of these problems.
looks like it's related to some deep weird
SR> I'm sorry to hear that my patch caused so many issues with postmodern
SR> and I'm quite keen to investigate the cause of this. I'll be
SR> installing setting up the postmodern backend and seeing if I can track
SR> down the causes of these problems.
looks like it's related to some deep weir
On Jan 8, 2008 3:31 PM, Ian Eslick <[EMAIL PROTECTED]> wrote:
> Actually I think we definitely need to fix this. Quite a few people
> have run into the problem that we're violating the CLOS contract on
> make-instance and that we should not use the same CLOS calling path
> for re-initialization th
Hi all,
I'm sorry to hear that my patch caused so many issues with postmodern
and I'm quite keen to investigate the cause of this. I'll be
installing setting up the postmodern backend and seeing if I can track
down the causes of these problems.
As to where to go from here I do agree with robert o
i thought people might be doing all sorts of funny stuff in their
initialize-instances -- additional initialization unrelated to
instance
slots, validation, writing to logs etc.
and they can be surprised that once they make class elephant-
persistent and
it's loaded from DB, their stuff is n
IE>>> our learning. My guess is that getting all this right can best be
IE>>> accomplished by rationally designing all the functionality from
IE>>> scratch, and rewrite the persistence protocol as necessary to
IE>>> accommodate the new design.
??>>
??>> the way it was working before "the pat
On Jan 8, 2008, at 11:08 AM, Alex Mizrahi wrote:
IE> our learning. My guess is that getting all this right can best be
IE> accomplished by rationally designing all the functionality from
IE> scratch, and rewrite the persistence protocol as necessary to
IE> accommodate the new design.
the way
On Tue, 2008-01-08 at 10:31 -0500, Ian Eslick wrote:
> Actually I think we definitely need to fix this. Quite a few people
> have run into the problem that we're violating the CLOS contract on
> make-instance and that we should not use the same CLOS calling path
> for re-initialization that
IE> our learning. My guess is that getting all this right can best be
IE> accomplished by rationally designing all the functionality from
IE> scratch, and rewrite the persistence protocol as necessary to
IE> accommodate the new design.
the way it was working before "the patches" seemed to be
Actually I think we definitely need to fix this. Quite a few people
have run into the problem that we're violating the CLOS contract on
make-instance and that we should not use the same CLOS calling path
for re-initialization that we use for initial creation. I think we
should require new
Until we can resolve the issues Ian described, or at least make it work
with ele-postmodern.
___
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
I agree completely with Ian.
In fact I have now spent a very embarrassing 5 days trying to modify the
ele-postmodern interface to use "recreate-instance" based on Sean's
patches, and have failed miserably. This is the first time in my career
this has ever happened to me.
I wasted this time in pa
Hi Alex,
I don't think any of the current developers have sat down and really
thought through how the entire MOP interface _should_ work in light of
our learning. My guess is that getting all this right can best be
accomplished by rationally designing all the functionality from
scratch,
helo
there was a patch that alters the way how objects that are deserialized are
created: it uses allocate-instance and bypasses normal initialization
sequence of make-instance.
however, there was no documentation given how this is supposed to work, so i
thought this shouldn't affect applicati
"Alex Mizrahi" <[EMAIL PROTECTED]> writes:
> IE> We'll need alot more information to help.
>
> my telepathy says it's stuff in memutil.lisp
>
> it seems #+#. trick got somehow broken with new version of SBCL with
> optimization settings.
>
Hmm.. I've got this problem when compiling under slime w
24 matches
Mail list logo
