[Openmcl-devel] [Clozure CL] #706: out-of-bounds errors with SLOT-VECTORs

[R. Matthew Emerson]

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).



> Arthur
> 
> 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
>> version.)
>> 
>> 
>> This is described in more detail in:
>> 
>> <http://trac.clozure.com/ccl/wiki/UpdatingFromSource>
>> 
>> 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?
>>> 
>>> Arthur
>>> 
>>> 
>>> 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
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>> 
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel