[elephant-devel] A thorny problem....

[Ian Eslick]

Klaus,

Glad to hear I'm not messing things up for you too much.  I share your
respect for Pascal's skills also. 

Would you be willing to bite off taking the lead on a Closer to MOP port
as part of fixing the MOP implementation for lispworks?  I was thinking
about doing it but won't be able to do it for awhile.  It's a hairy
project but I'd be happy to support you and if we could find a couple of
other testers we could slowly migrate one function at a time and test
it.  Pascal is looking for other metaobject protocol implementations to
test closer so I'm sure he'd be happy to help support. 

Pascal also works in Lispworks natively so might be motivated to make
elephant work under lispworks.

We shouldn't attempt this until after the current 0.6.0 is released
however as there's already too much going on in this release.  Hopefully
0.6.0 will come out next week or at least "very soon now".  :)

Cheers,
Ian

Klaus Harbo wrote:
>
> On 18/02/2006, at 19:29, Ian Eslick wrote:
>
>> Klaus,
>>
>> We should talk offline.  I'm in the middle of a large re-organization of
>> the codebase and am trying to simplify alot of the backend
>> functionality.  Merging your changes into mine will be non-trivial.
>>
>> If most of your changes are limited to berkeley-db and sleepycat then it
>> shouldn't be hard to make the changes there by hand.  The metaclass
>> protocol should get fixed by migrating to closer-to-mop in the near
>> future which deals with most of the mopish problems that are patched in
>> the current metaclasses.lisp file.
>>
>> Anyway, why don't you fill me in on what you're doing so we can
>> coordinate and keep the pain under control.  :)
>>
>> Ian
>
> Well, I think the best way to characterize what I've been doing is to
> 'hack' Elephant to make it work with LW, i.e. I wouldn't consider what
> I've done 'changes to Elephant'.  My main aim has been to understand
> the kinds of changes that would be required to make it work -- with
> that understanding I would then look at what would be the best way to
> fold it into Elephant.
>
> I'm encouraged that you're working on a reorganization; IMHO the code
> really needs it (I do not mean this as criticism -- considering the
> process Elephant has been through, lack organization is quite
> understandable).  If it is okay to venture an opinion, I think the
> code would benefit from stratifying both in terms of backends (which I
> believe is already happening judging from recent postings to the
> list), and in terms of CL implementations.  The latter could perhaps
> be approached like in Portable AllegroServe, where there's a clear
> interface to certain functionality, a separate files implement this
> interface for different implementations?
>
> As I mentioned, I don't have persistent classes working, and - frankly
> - my meta-programming skills are not very advanced; yet!  Poring over
> the code, I wondered if using Pascal Costanza's Closer framework might
> help Elephant become highly portable across implementations?  I know
> that, all things being equal, it is better to rely on fewer libraries
> rather than more, but I think there's considerable risk that we'll be
> reinventing the wheel... (I should perhaps add that I have not
> actually used Closer, but I have great respect for Pascal's abilities
> so I would expect it to be relatively usable.)
>
> -Klaus
>
> - The pencil is mightier than the pen -
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel