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

[Arthur Cater]

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.

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