Re: [B2-devel] [PATCH] International text clipboard patch for Basilisk II and SheepShaver

[Alexei S. <ale...@gm...>]

Could you point me at a reference that explains why @autoreleasepool would
be more efficient than just managing one yourself?

Also, shouldn't the ifdef to use it be testing for the version of clang
that added it? Some Googling reveals that it's not supported by older clang
(e.g. the one shipped with Xcode 3.2).

-Alexei

On Thu, Jul 5, 2012 at 4:46 AM, Charles Srstka <
bas...@ch...> wrote:

> On Jul 5, 2012, at 1:38 AM, Alexei Svitkine wrote:
>
> On Thu, Jul 5, 2012 at 2:29 AM, Charles Srstka <
> bas...@ch...> wrote:
>
>> On Jul 5, 2012, at 12:39 AM, Alexei Svitkine wrote:
>>
>> if (floor(NSFoundationVersionNumber) > NSFoundationVersionNumber10_5)
>>> ... new API
>>> else
>>> ... old API
>>>
>>
>> Is your new implementation strictly better than the clip_macosx.cpp one?
>> Can you give a brief overview comparing them in terms of what works and
>> what doesn't? This will help make it clear whether it makes sense to always
>> prefer to use the new API code when running on 10.6 for 32-bit builds. (And
>> hence whether it makes sense to consolidate them now like this.)
>>
>>
>> Well, it’s definitely better than the clip_macosx.cpp in that the latter
>> doesn’t run on 64-bit systems. I’ve also added a couple of features to it:
>>
>> 1. copy/paste styled text into and out of the emulator
>>
>> 2. copy/paste international text using non-Roman scripts into and out of
>> the emulator
>>
>> As for the 10.6+ pasteboard API, that adds two features:
>>
>> 1. The ability to just say “lemme read/write an NSAttributedString off
>> the pasteboard!” and have the OS do the conversion for you to and from
>> whatever internal representation it’s using, instead of saying “Gimme some
>> data of kUTTypeRTF and I hope that’s what OS X still uses!”
>>
>> 2. The fact that the API is just more current and is a complete
>> replacement for the old one, and although the old API isn’t deprecated yet,
>> you know how Apple is (Exhibit A: the fact that the implementation in
>> clip_macosx.cpp no longer works). Basically, this is for future-proofing.
>>
>
> Okay, but clip_macosx.cpp would still be able to handle scrap types that
> exist both under Classic and Mac OS X transparently (at least, on PPC or if
> there is no byteswapping needed), correct? Ones that wouldn't get handled
> without explicit support in clip_macosx64.mm. That's the big difference,
> still, right?
>
>
> I believe that can be done in the ... old API section; the docs for
> NSPasteboard claim that the API marked "10.5 and earlier” are still capable
> of taking types that aren’t UTIs, although it warns that this will probably
> stop working in some future version of OS X (which is why I feel that we
> definitely don’t want code that does that running on modern OS X versions).
>
> One thing about that, though — as you point out, it’s only a safe thing to
> do on PPC — on Intel, it could lead to all sorts of byte-swapping issues.
> And forgive me if I’m missing an important use case, but if you’re on
> Tiger/PPC, why would you need SheepShaver? Machines in that configuration
> have access to the Classic environment, which in my experience is generally
> much better at running Classic Mac OS applications than SheepShaver is.
>
> I think there will also be problems compiling this combined file on 10.4,
> for example, since it wouldn't have headers for the new APIs. That can be
> worked around with additional ifdefs, but that gets hairy fast.
>
>
> With Objective-C, it can be done much more easily than that. The first
> thing to note is that Objective-C is a completely dynamic language, and all
> the “static typing” you get at the source code level is purely advisory;
> trying to send a message that isn’t defined in any header to an object only
> generates a warning at compile time, although if execution actually reaches
> that nonexistent call at runtime, it’ll throw an exception. So how much
> work this would be depends a lot on whether we care about warnings that
> only show up when compiling on ancient systems. There are a few exceptions,
> of course, one being that if we try to allocate a class that doesn’t exist
> in the 10.4 version of the frameworks, it won’t link. There are ways around
> that too, though, like for instance replacing this:
>
> SomeObjectThatsNotInTiger *myObject = [[SomeObjectThatsNotInTiger alloc]
> init];
>
> with this:
>
> SomeObjectThatsNotInTiger *myObject =
> [[NSClassFromString(@“SomeObjectThatsNotInTiger”) alloc] init];
>
> and that’ll work fine, as long as you keep the execution from getting to
> this line in Tiger.
>
> We’d definitely need to have a tester with Tiger and the dev tools to
> catch any surprises, though.
>
>  Let's leave merging these off for now, but we can revisit that later.
>
>
> I’m perfectly fine with that, and my original intent was to have this
> apply only to 10.6 and up; the only reason I brought it up was because you
> seemed to express some disappointment in it not being back-portable to
> 10.4, something that is certainly fixable in the future should the need
> arise.
>
>
>>  Still, if you do think the autorelease pools are really required, I
>>> suggest making a C++ scoped object that will alloc an autorelease pool in
>>> its ctor and release it in its dtor, which will eliminate the need for
>>> draining the pool at all the early return points.
>>>
>>>
>>> Yeah, that could work.
>>>
>>
>> Could you make that change? I think it would be much cleaner than all the
>> early-return cleanup in your current patch.
>>
>>
>> Sure thing. I think I’ll put the wrapper object in a header file so that
>> it can be used elsewhere if people want to. This’ll be an Objective-C++
>> header file and will only be includable by Objective-C++ code; do you have
>> any preference whether to put #ifdef guards around it or just use #import?
>>
>
> My preference would be to still have ifdef guards. Thanks.
>
>
> Here’s a new patch:
>
>
>
> Thanks,
> Charles
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>