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