[Openmcl-devel] [Clozure CL] #706: out-of-bounds errors with SLOT-VECTORs
R. Matthew Emerson
rme at clozure.com
Mon Aug 23 11:44:58 CDT 2010
On Aug 23, 2010, at 12:22 PM, Arthur Cater wrote:
> Thanks for that explanation. However, I don't think it addresses the issue of
> an image file for 'r14204' giving rise to an implementation-version of 'r14125M'.
> I checked out a wholly-new trunk, and still got r14125M
> Mine is a 32-bit ppc, if that matters.
When building a heap image, we note the current svn revision of the sources. In other words, the revision number of the source tree from which the checked-in heap image was built is r14125M. (Subversion revision numbers are the revision of the whole tree; they are not associated with individual files. See "Global Revision Numbers" at http://svnbook.red-bean.com/en/1.5/svn.basic.in-action.html)
For the trunk especially, the checked-in binaries are there primarily for bootstrapping: you need them to build the lisp from source code.
So, after you check out the sources, start up the lisp and run (rebuild-ccl :full t). When you start up from this new image, you'll be up-to-date (and the banner message that will be printed out when the lisp starts up will reflect this).
> On Aug 23, 2010, at 3:20 PM, Gary Byers wrote:
>> On Mon, 23 Aug 2010, Arthur Cater wrote:
>>> Odd. I've just svn updated, got file dppccl.r14204.image among others,
>>> and did
>> If you've made local modifications to text files and new versions of
>> those files are available in the repository, "svn update" will try to
>> merge the repository changes into your local copy. If the changes are
>> simple and independent (both textually and semantically), this usually
>> works pretty well; if "svn update" can't resolve the differences,
>> it'll note that a conflict exists, preserve copies of the repository
>> and local versions of the file, and generally clobber the working copy
>> (it'll contain embedded diff information.) If this ever happens, you
>> generally want to resolve the conflict in some way. Two ways of doing
>> this are:
>> 1) manually merge the repository changes and your local changes into
>> a new local version of the file, then use "svn resolved" to tell svn
>> that the file is no longer in conflict with the repository version.
>> 2) use "svn revert" to discard local changes and make the local copy
>> match the repository's version.
>> If binary files differ, "svn update" won't even try to merge the changes;
>> it'll simply note that a conflict exists and introduce the repository's
>> version of the file (as "file.revision") into the working directory.
>> (IIRC, starting around version 1.5, "svn update" will prompt for some
>> means of resolving the conflict in this case; "tf" ("theirs full") basically
>> removes the local copy of the conflicting file and installs the repository
>> This is described in more detail in:
>> It -is- certainly unintuitive and confusing, and it can be difficult to remember the issue.
>> One incentive to remembering was introduced several months ago: the first
>> person to forget and post a question about this on this list owes me $1US,
>> the next person $2, then $4, and so on. I'd hoped that this would both
>> help people to understand this issue and make me incredibly rich; unfortunately,
>> all that I've gotten out of it is a dollar.
>> (Well, $3 now.)
>>> Macintosh:ccl arthur$ ./dppccl -n -I dppccl.image.r14204
>>> Welcome to Clozure Common Lisp Version 1.6-dev-r14125M-trunk (DarwinPPC32)!
>>> ? (lisp-implementation-version)
>>> "Version 1.6-dev-r14125M-trunk (DarwinPPC32)"
>>> Is this really r14204? Am I doing something wrong?
>>> On Aug 23, 2010, at 12:10 PM, Clozure CL wrote:
>>>> #706: out-of-bounds errors with SLOT-VECTORs
>>>> Reporter: Arthur | Owner:
>>>> Type: defect | Status: new
>>>> Priority: normal | Milestone:
>>>> Component: IDE | Version: trunk
>>>> Keywords: |
>>>> Comment(by gb):
>>>> This may have been fixed in r14202/r14203.
>>>> An earlier attempt to fix this in r14198 introduced a number of other,
>>>> more severe problems.
>>>> If people who've experienced this problem (confusion about foreign
>>>> instances' slot-vectors) can upgrade to r14203 or later (in the trunk),
>>>> it'd be helpful to know whether that problem is still present.
>>>> Ticket URL: <http://trac.clozure.com/ccl/ticket/706#comment:4>
>>>> Clozure CL <http://trac.clozure.com/ccl>
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel