[Openmcl-devel] NSStrings

[Paul D. Lathrop]

Gary,

	Thank you for the explanation - this seriously helped me track down 
what I was doing wrong. Incidentally, the problem wasn't in the way I 
was handing the string back and forth, it was in forgetting to suppress 
further processing of the key-event I was using to trigger the function 
I wrote. I felt dumb when I realized what I had done :-)

Thanks!
--Paul

On Mar 3, 2004, at 10:08 AM, Gary Byers wrote:

>
>
> On Wed, 3 Mar 2004, Paul D. Lathrop wrote:
>
>> I am doing some work with the cocoa/objc bridge (for the Clotho
>> project) and I've come across some confusion involving passing a 
>> string
>> from the lisp to the objc runtime. What I am working on currently is
>> implementing a function that will swap the case of the current
>> selection. I am able to get the selection and change it's case. I am
>> then allocating an nsstring using the following form:
>>
>> (ccl::%make-nsstring new-string)
>>
>> new-string is the lispy form of the string I'm trying to send. The
>> problem is, when the string reaches the cocoa component I'm sending it
>> to, it has one character's worth of garbage appended to it. The lisp
>> doesn't see this garbage at all - it registers the nsstring as:
>>
>> #<NS-CONSTANT-STRING "FOObarBAz" (#x155190)>
>
> That's what the applicable PRINT-OBJECT method returns for that 
> instance
> of the ObjC class NS:NS-CONSTANT-STRING (aka "NSConstantString").  The
> PRINT-OBJECT method sends the object a "description" message and prints
> the (lispified) string that that method returns.  Lisp has no other
> idea of what characters are in the string.
>
> (This is in contrast to #@"Foo", which sort of gets interned and
> canonicalized: the lisp string gets remembered along with the
> NS-CONSTANT-STRING in a little structure, so that the equivalent
> NS-CONSTANT-STRING can be recreated after SAVE-APPLICATION.)
>
> An NS-CONSTANT-STRING is something that can be statically created
> (it's what the ObjC compiler turns @"Foo" into): it can never be
> released, and it and the underlying bytes can be allocated in
> read-only storage.
>
> It might or might not be what you want.
>
>>
>> whereas, Cocoa gives me:
>>
>> "FOObarBAz¨"
>
> If you DESCRIBE the value returned by CCL::%MAKE-NSSTRING, you'll
> see its instance variables presented as CLOS slots.  They aren't
> incredibly interesting:
>
> ? (%make-nsstring "abcdefghij")
> #<NS-CONSTANT-STRING "abcdefghij" (#x138C10)>
> ? (describe *)
> #<NS-CONSTANT-STRING "abcdefghij" (#x138C10)>
> Class: #<OBJC:OBJC-CLASS NS:NS-CONSTANT-STRING (#xA6543EC4)>
> Wrapper: #<CLASS-WRAPPER NS:NS-CONSTANT-STRING #x5ACC146>
> Instance slots
> NS:ISA: #<OBJC:OBJC-CLASS NS:NS-CONSTANT-STRING (#xA6543EC4)>
> NS:BYTES: #<A Mac Pointer #x1F4160>
> NS:NUM-BYTES: 10
>
> i.e., it's basically just a pointer to some bytes and a count of
> those bytes.  It appears that between the time that the constant
> string is created and the time that you conclude that Cocoa's
> seeing something else something is stepping on the NUM-BYTES slot
> of your string.  That shouldn't be possible (via any sort of
> advertised means), so something somewhere is scribbling over
> memory.
>
>>
>> (note the extra char on the end). Am I missing a "proper" way of
>> accomplishing this? If not, what am I missing? The only clue I have
>> left is that the string I get *from* the objc runtime is:
>>
>> #<NS-CF-STRING "fooBARbaZ" (#x160B50)>
>>
>> Which is not what I am sending back. Could this be a problem? If it 
>> is,
>> how do I allocate the appropriate type of string? If I'm missing
>> something obvious, feel free to RTFM me.
>>
>
> NS-STRINGs come in several flavors.  Many of them are immutable (and
> an NS-CONSTANT-STRING is both immutable and "immortal" in that it's
> never deallocated by the runtime.)
>
> Given some kind of NS-STRING, a method like
> "stringBy[Appending|Deleting|Padding|...]..." will return a new string
> (of some class) that's just like the receiver except for some appending
> or deleting or padding ...
>
> There should probably be convenient ways to create other types of
> strings from a lisp string (besides CCL::%MAKE-NSSTRING).  It's
> not clear that using an NS-CONSTANT-STRING is an issue here, though.
>
>> Thanks,
>> Paul Lathrop
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>
>