[elephant-devel] Some thoughts/Questions from testing

[Ian Eslick]

Hmmmm...

I think having to name all the systems differently in each branch is a  
poor methodology and likely to lead to confusion over time.   Instead,  
I wrote a simple shell script to change .asd symbolic links in my  
system directory.

We might bundle a shell script and batch file that one can run to  
manage multiple .asd files or source trees so that the right thing  
happens as a convenience for our users.  It might be possible to  
integrate this into a special .asd file that manipulates links  
appropriately - but allowing users to adapt shell scripts is probably,  
ultimately, simpler.

Ian

PS - It might also be useful to have a clear message during the  
loading process about what version is actually being loaded into the  
image.  At least that way you aren't confused about which version you  
are currently running!  Perhaps something that prints a message when  
you open a store; or a big banner that makes it hard to miss what  
version is loading?

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;; Loading ELEPHANT 0.9.2
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


On May 11, 2008, at 10:10 PM, Glenn Tarcea wrote:

> 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
>>
>>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel