[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