[elephant-devel] Some thoughts/Questions from testing

Glenn Tarcea gtarcea at umich.edu
Mon May 12 02:10:29 UTC 2008


Thanks Robert.

I'll look into it. I was thinking of something much simpler than you  
outlined. Rather than trying to support reading objects across  
versions, I was just looking to support two different versions of the  
elephant packages, and to tease out the load-op dependencies that  
refer to explicit names.

Something like (thinking out loud here):

(defconstant +elephant-system-name+ 'elephant)
(defconstant +elephant-system-bdb+ 'ele-bdb)

(defsystem #.+elephant-system-name+
    ....

And then in the code, rather than referring to :ele-bdb (for example)  
refer instead to +elephant-system-bdb+.

Then, to support the same package names, but different systems, we  
just need to change the constants. So, elephant unstable would set  
the constants to, eg 'elephant-unstable, 'ele-bdb-unstable, 'ele-xxx- 
unstable etc...

If we did something like this it would allow for both elephant and  
elephant-unstable on the system, and depending on which system the  
user loaded (require, or asdf:operation 'asdf:load-op) their code  
would either be referring to the released version, or the new  
"unstable" version. All package names would remain the same, so you  
couldn't easily switch without leaving and reentering lisp. As a  
first cut, though, this would be a low impact change with some  
immediate benefit.

Since I'm new to the code I'm hesitant to propose any change that  
isn't simple and straightforward. At least not until I get a better  
feel for the code.

I'll put some thought in to it and put out a proposal.

Thanks,

Glenn

On May 11, 2008, at 8:01 PM, Robert L. Read wrote:

> On Sun, 2008-05-11 at 19:50 -0400, Glenn Tarcea wrote:
>> What do you all think about allowing two different versions of
>> Elephant to be installed at the same time? I tried to have both my
>> original version of Elephant installed and also to install elephant-
>> unstable. Currently there are a lot of dependencies on the system
>> name sprinkled throughout the code that prevent this. My thought
>> would be to allow someone to do a (require 'elephant-unstable) (or
>> some other chosen system name) and have it load an alternative
>> version of Elephant. All the package names would stay the same, just
>> the systems would be different.
>
> I think this could be very nice for the reasons you mention.  I
> personally don't know how to do it.  I suspect any workable solution
> would have to be an asdf-based solution, not just using 'requre.
>
>>
>> The benefit to this is it would allow users to test out the new
>> functionality before deciding to switch, and for testers, it would
>> mean we could have both versions installed. It seems like this would
>> be helpful right now when the BerkeleyDB interfaces have stabilized,
>> but the postmodern interface hasn't. For me it would allow me to test
>> and observe behavior in the old environment and then easily switch
>> over to the new environment.
>>
>> If no one objects I can look into this further, at least drawing up a
>> plan of attack and posting it for comment.
>
> I think it is definitely worth trying to figure out how to do it.
> However, an added complication is that any objects created are created
> under a certain version, which may not be readable by another version.
> Ian has objectified this with his "schema numbering" for classes in
> elephant-unstable.
>
> The idea situation is that Elephant version N+K can read any Elephant
> object written by version N.  I think we are moving toward that
> capability.
>
> However, even if one version can't read another version, being able to
> have two distinct packages in one image could be useful---I encourage
> you to spend some time thinking through how it might work.
>
>>
>> Also, it looks like the testing framework is being migrated over to
>> 5am. I assume this means that I should write any new tests using 5am?
>
> Yes --- I believe we are already completely dependent on 5am for
> testing.
>
>>
>> Thanks,
>>
>> Glenn
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel
>
>




More information about the elephant-devel mailing list