Re: Carbon -> Cocoa

[Tor Arne Vestbø]

On 24 Aug 2018, at 21:16, Alastair Houghton  
wrote:
> 
> On 24 Aug 2018, at 20:01, Tor Arne Vestbø  wrote:
>> 
>> On 23 Aug 2018, at 12:06, Alastair Houghton  
>> wrote:
>>> 
>>> Run loops are based on dispatch queues too, these days.
>> 
>> Are they? We use CFRunLoop in the Qt event dispatchers on macOS and iOS, and 
>> I these behave as normal sources without any sign of dispatch queues as far 
>> as I can tell?
>> 
>> I did experiment with using dispatch sources instead, but these can not be 
>> recursed, which was a showstopper unfortunately. I would have loved to use 
>> the queue debugging feature (backtrace recording) to tie posted Qt events 
>> back to their origin.
> 
> You can see the code here
> 
> https://opensource.apple.com/source/CF/CF-1153.18/CFRunLoop.c.auto.html
> 
> Perhaps “based on dispatch queues” is an exaggeration; it’s more that they’re 
> very tightly integrated… CFRunLoop appears to be using dispatch queues for 
> timers, and there’s clearly integration such that dispatched calls will run 
> within the run loop.
> 
> It does still have its own separate run loop sources, observers and so on, I 
> believe; they all talk to the run loop itself via a set of Mach ports.

Right, that matches my understanding. In a sense dispatch queues are based on 
runloops as well, so your description of “tightly integrated” is accurate  

Cheers,
Tor Arne 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Alastair Houghton]

On 24 Aug 2018, at 20:01, Tor Arne Vestbø  wrote:
> 
> On 23 Aug 2018, at 12:06, Alastair Houghton  
> wrote:
>> 
>> Run loops are based on dispatch queues too, these days.
> 
> Are they? We use CFRunLoop in the Qt event dispatchers on macOS and iOS, and 
> I these behave as normal sources without any sign of dispatch queues as far 
> as I can tell?
> 
> I did experiment with using dispatch sources instead, but these can not be 
> recursed, which was a showstopper unfortunately. I would have loved to use 
> the queue debugging feature (backtrace recording) to tie posted Qt events 
> back to their origin.

You can see the code here

https://opensource.apple.com/source/CF/CF-1153.18/CFRunLoop.c.auto.html 


Perhaps “based on dispatch queues” is an exaggeration; it’s more that they’re 
very tightly integrated… CFRunLoop appears to be using dispatch queues for 
timers, and there’s clearly integration such that dispatched calls will run 
within the run loop.

It does still have its own separate run loop sources, observers and so on, I 
believe; they all talk to the run loop itself via a set of Mach ports.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Tor Arne Vestbø]

On 23 Aug 2018, at 12:06, Alastair Houghton  
wrote:
> 
> Run loops are based on dispatch queues too, these days.

Are they? We use CFRunLoop in the Qt event dispatchers on macOS and iOS, and I 
these behave as normal sources without any sign of dispatch queues as far as I 
can tell?

I did experiment with using dispatch sources instead, but these can not be 
recursed, which was a showstopper unfortunately. I would have loved to use the 
queue debugging feature (backtrace recording) to tie posted Qt events back to 
their origin.

Cheers,
Tor Arne 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Alastair Houghton]

On 22 Aug 2018, at 21:42, Saagar Jha  wrote:
> 
>> Are they? kqueue() supports monitoring of fds, Mach ports and timers, so 
>> there’s really no reason that CFRunLoop would have to spawn a background 
>> thread just to monitor some file descriptors. As far as I can tell, the 
>> current CFRunLoop implementation is built on top of GCD, which sadly we 
>> don’t have the source code for
> 
> libdispatch is open source: 
> https://github.com/apple/swift-corelibs-libdispatch 
> 

On 23 Aug 2018, at 04:30, Uli Kusterer  wrote:
> 
> 
> I recall hearing from someone at Apple that they basically ported GCD to 
> Linux for the Swift Linux release ... have you looked whether that code might 
> give any clues about what may be happening on macOS?


Interesting. That isn’t quite the same libdispatch that’s used on the macOS by 
the look of things, but it does appear to have things merged across from the 
macOS version. It looks, from a cursory examination, as if the macOS 
functionality is built on top of a kernel “work queue” implementation that 
lives inside the non-open-source pthread.kext. (I’m sure I’m not the only one 
to have noticed that quite a bit of functionality has been moved from open 
source parts of the macOS to closed-source libraries and KEXTs; personally I 
find this a disappointing development, as it makes debugging and developing 
software harder if it’s impossible to inspect the source code.)

Anyway, from what I can see it seems highly unlikely that there will be any 
background threads to monitor file descriptors, at least on the macOS.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Alastair Houghton]

On 22 Aug 2018, at 19:32, Jens Alfke  wrote:
> 
>> On Aug 22, 2018, at 10:40 AM, Alastair Houghton 
>> mailto:alast...@alastairs-place.net>> wrote:
>> 
>> Well, yes and no. If the network library works that way, it’ll fire its 
>> callbacks on the background thread, which makes life awkward if you’re 
>> interacting with the UI
> 
> Then you write glue around the callbacks that dispatches them on a selectable 
> dispatch queue. (Which you'll want to do anyway, because who wants to work 
> with C callbacks?)

You’ll take a performance hit doing that; not sure how large, but some, for 
sure. Not necessarily a big issue for most apps, but worth bearing in mind.

>> Much better to use a library that’s properly integrated with the native run 
>> loop and that therefore doesn’t end up calling your code on a background 
>> thread.
> 
> To be pedantic, both NSURLSession and Network.framework are based on dispatch 
> queues, not runloops. They call delegate code on the dispatch queue assigned 
> to the task.

Run loops are based on dispatch queues too, these days.

> Anyway, I agree with you that using a library integrated with OS facilities 
> is better than one that isn't. But developers using non-HTTP protocols, or 
> coding in C/C++, don't have that luxury … not until they can move up to iOS 
> 12 / macOS 10.14 as their deployment SDKs.  In my case that's probably about 
> three years away. :(

It’s worth checking whether any of the other libraries have dispatch queue or 
run loop integration. It wouldn’t surprise me if some of them do — it isn’t 
much of a stretch, once you have an async I/O library, to add the necessary 
support. That was sort of the point I was making, namely that it’s worth 
looking carefully at the available options to see which have the platform 
support you need to make them interoperate well with your platform specific 
code (without necessarily being platform specific themselves).

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Uli Kusterer]

On 22. Aug 2018, at 19:40, Alastair Houghton  
wrote:
> Are they? kqueue() supports monitoring of fds, Mach ports and timers, so 
> there’s really no reason that CFRunLoop would have to spawn a background 
> thread just to monitor some file descriptors. As far as I can tell, the 
> current CFRunLoop implementation is built on top of GCD, which sadly we don’t 
> have the source code for; I don’t have time to reverse engineer it right now 
> to see whether or not GCD does in fact spawn background thread(s) for this or 
> not, but I see no particular reason it should have to.

 I recall hearing from someone at Apple that they basically ported GCD to Linux 
for the Swift Linux release ... have you looked whether that code might give 
any clues about what may be happening on macOS?

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Uli Kusterer]

On 18. Aug 2018, at 20:19, Stephane Sudre  wrote:
> Regarding the complexity of porting from C++ Carbon to Cocoa, there's
> also the important question of what your minimum OS target is.
> 
> Maybe one of the reasons why you kept a Carbon version alive so long
> is that the application needs to keep working on older OS versions.
> 
> Porting to OS X 10.10 or later is not the same thing as porting to
> 10.6 or later for instance.

+1. I think we pretty much only supported whatever the current OS version was 
in our Cocoa ports. We had the Carbon versions in parallel that supported the 
older OSes, so it wasn't as if users would notice. There were significant 
improvements over macOS releases. Particularly 10.2 and 10.8, IIRC. I haven't 
had to Carbon-port much later than that.

... well, that's not true, I did a rough Carbon-to-Cocoa port for a friend 
about a year ago, but that was just getting the basics to work and solving the 
hard issues (like adding certain modifications he needed to standard views to 
Cocoa, in a Cocoa way), and hasn't shipped yet.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Uli Kusterer]

On 16. Aug 2018, at 13:54, Casey McDermott  wrote:
> I am curious, are there other developers on this list working on conversions
> from C++ Carbon to Cocoa?
> 
> If so, how is it going?

I've worked on a few in previous jobs, it was definitely a lot of work, but 
most of that was due to the lack of MVC separation in most existing C++ 
codebases, and due to (at the time) only limited support for co-habitation of 
Cocoa and Carbon code in the same app, so we had to branch and develop two apps 
(the shipping Carbon and the work-in-progress Cocoa app), because certain 
things (like mixing non-modal Cocoa and Carbon windows) were just too buggy.

Luckily most of these ports pre-dated 64 bit (well, pre-dated Apple being 
annoying about 32-bit apps), so we could port to Cocoa first, then to 64 bit 
from there.

Some of the apps shipped, some got sold to other companies and those companies 
haven't shipped their Cocoa versions yet ... so I can't claim a 100% success 
rate.

In retrospect, for most of them I'd say the best approach is to just tear off 
the view layer, wrap all the remaining code in some sort of API, then swap out 
the UI layers. We basically did that for Game Capture and that was our fastest 
port.

In the ones where we attempted to port parts over, there was usually a huge gap 
between the easy beginnings and later parts. Replacing file panels, standard 
alerts, cursors etc. with Cocoa calls, replacing all modal windows with Cocoa 
windows etc. was fairly straightforward. Actually moving over the menu bar 
required taking the main event loop along, and only *then* would non-modal 
Cocoa windows work properly.

You can mix modeless Cocoa and Carbon windows in a RAEL-based app or even 
WNE-based app, and they will sort of work, but it's only suitable for testing 
both versions of a window, nothing you would want to ship. Too many subtle 
focus and window-ordering bugs in daily use.

That said, NSSelectorFromString() let us make a pretty neat translation scheme 
between ObjC menu item selectors and HICommands, and many older C++ frameworks 
actually behave more like ObjC's -validateMenuItem: than modern Carbon did, so 
in one case I was very happy an app's codebase hadn't been brought up to speed 
with Carbon best practices, because I could just hollow out TCL classes and 
back them with ObjC objects and all was fine.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Saagar Jha]

Sent from my iPhone

> On Aug 22, 2018, at 10:40, Alastair Houghton  
> wrote:
> 
>> On 22 Aug 2018, at 17:53, Jens Alfke  wrote:
>> 
>>> On Aug 21, 2018, at 8:33 AM, Alastair Houghton 
>>> mailto:alast...@alastairs-place.net>> wrote:
>>> 
>>> So, for instance, it’s not so good on macOS or iOS if its event dispatcher 
>>> is based on select(), (e)poll() or kqueue() because what you really want on 
>>> macOS/iOS is for the event dispatch to go via CFRunLoop; if it doesn’t, 
>>> you’ll end up having to use threading to run the network library’s event 
>>> loops on background threads, which for an async networking library kind of 
>>> defeats the point IMO.
>> 
>> It does mean you have to spin up one background thread to sit and wait for 
>> events; but that's not a big hardship. You still get the scalability 
>> benefits of event-driven I/O, vs. having to use one thread per socket the 
>> old-fashioned way.
> 
> Well, yes and no. If the network library works that way, it’ll fire its 
> callbacks on the background thread, which makes life awkward if you’re 
> interacting with the UI as you’ll need to forward to the main thread and it 
> may in some cases for you to use synchronisation when you wouldn’t have 
> needed to. Much better to use a library that’s properly integrated with the 
> native run loop and that therefore doesn’t end up calling your code on a 
> background thread.
> 
>> (NSURLSession and Network.framework are doing the same thing under the hood, 
>> after all.)
> 
> Are they? kqueue() supports monitoring of fds, Mach ports and timers, so 
> there’s really no reason that CFRunLoop would have to spawn a background 
> thread just to monitor some file descriptors. As far as I can tell, the 
> current CFRunLoop implementation is built on top of GCD, which sadly we don’t 
> have the source code for

libdispatch is open source: https://github.com/apple/swift-corelibs-libdispatch

> ; I don’t have time to reverse engineer it right now to see whether or not 
> GCD does in fact spawn background thread(s) for this or not, but I see no 
> particular reason it should have to.
> 
> Kind regards,
> 
> Alastair.
> 
> --
> http://alastairs-place.net
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com
> 
> This email sent to saa...@saagarjha.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Jens Alfke]

> On Aug 22, 2018, at 10:40 AM, Alastair Houghton 
>  wrote:
> 
> Well, yes and no. If the network library works that way, it’ll fire its 
> callbacks on the background thread, which makes life awkward if you’re 
> interacting with the UI

Then you write glue around the callbacks that dispatches them on a selectable 
dispatch queue. (Which you'll want to do anyway, because who wants to work with 
C callbacks?)

> Much better to use a library that’s properly integrated with the native run 
> loop and that therefore doesn’t end up calling your code on a background 
> thread.

To be pedantic, both NSURLSession and Network.framework are based on dispatch 
queues, not runloops. They call delegate code on the dispatch queue assigned to 
the task.

Anyway, I agree with you that using a library integrated with OS facilities is 
better than one that isn't. But developers using non-HTTP protocols, or coding 
in C/C++, don't have that luxury … not until they can move up to iOS 12 / macOS 
10.14 as their deployment SDKs.  In my case that's probably about three years 
away. :(

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Alastair Houghton]

On 22 Aug 2018, at 17:53, Jens Alfke  wrote:
> 
>> On Aug 21, 2018, at 8:33 AM, Alastair Houghton > > wrote:
>> 
>> So, for instance, it’s not so good on macOS or iOS if its event dispatcher 
>> is based on select(), (e)poll() or kqueue() because what you really want on 
>> macOS/iOS is for the event dispatch to go via CFRunLoop; if it doesn’t, 
>> you’ll end up having to use threading to run the network library’s event 
>> loops on background threads, which for an async networking library kind of 
>> defeats the point IMO.
> 
> It does mean you have to spin up one background thread to sit and wait for 
> events; but that's not a big hardship. You still get the scalability benefits 
> of event-driven I/O, vs. having to use one thread per socket the 
> old-fashioned way.

Well, yes and no. If the network library works that way, it’ll fire its 
callbacks on the background thread, which makes life awkward if you’re 
interacting with the UI as you’ll need to forward to the main thread and it may 
in some cases for you to use synchronisation when you wouldn’t have needed to. 
Much better to use a library that’s properly integrated with the native run 
loop and that therefore doesn’t end up calling your code on a background thread.

> (NSURLSession and Network.framework are doing the same thing under the hood, 
> after all.)

Are they? kqueue() supports monitoring of fds, Mach ports and timers, so 
there’s really no reason that CFRunLoop would have to spawn a background thread 
just to monitor some file descriptors. As far as I can tell, the current 
CFRunLoop implementation is built on top of GCD, which sadly we don’t have the 
source code for; I don’t have time to reverse engineer it right now to see 
whether or not GCD does in fact spawn background thread(s) for this or not, but 
I see no particular reason it should have to.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Jens Alfke]

> On Aug 21, 2018, at 8:33 AM, Alastair Houghton  
> wrote:
> 
> So, for instance, it’s not so good on macOS or iOS if its event dispatcher is 
> based on select(), (e)poll() or kqueue() because what you really want on 
> macOS/iOS is for the event dispatch to go via CFRunLoop; if it doesn’t, 
> you’ll end up having to use threading to run the network library’s event 
> loops on background threads, which for an async networking library kind of 
> defeats the point IMO.

It does mean you have to spin up one background thread to sit and wait for 
events; but that's not a big hardship. You still get the scalability benefits 
of event-driven I/O, vs. having to use one thread per socket the old-fashioned 
way.

(NSURLSession and Network.framework are doing the same thing under the hood, 
after all.)

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Alastair Houghton]

On 21 Aug 2018, at 10:09, Mike Crawford  wrote:
> 
>> drag C developers away from the POSIX sockets API
> 
> Don't be dismayed if you're not happy with NIO:
> 
> There are numerous APIs that do such dragging, for example the
> ADAPTIVE Communications Environment (ACE):
> 
>   http://www.dre.vanderbilt.edu/~schmidt/ACE.html 
> 
> 
> Mozilla's NetScape Portable Runtime, The Electric Magic Company's
> ZooLib is C++ and MIT Licensed:
> 
>   http://www.em.net/portfolio/2000/12/zoolib.html 
> 
> 
> I expect there are many others.

One of the problems with many of those libraries is that they tend to insist 
that your software use their own event loop implementation(s). Admittedly it’s 
been a while since I looked at ACE (for example), but NIO is at least going to 
be using the same mechanisms that you’d use anyway in a macOS or iOS 
application.

Anyway, when looking at an async networking library, you want to check that it 
will integrate nicely with the set of platforms you care about, using the kind 
of event dispatch you require in your application. So, for instance, it’s not 
so good on macOS or iOS if its event dispatcher is based on select(), (e)poll() 
or kqueue() because what you really want on macOS/iOS is for the event dispatch 
to go via CFRunLoop; if it doesn’t, you’ll end up having to use threading to 
run the network library’s event loops on background threads, which for an async 
networking library kind of defeats the point IMO. (Of course, you may want to 
have event loops running in threads or thread pools for performance reasons, 
but one of the real benefits of async networking libraries is that you can use 
them from the main thread in your GUI code.)

Likewise, on Windows you’re going to want something that uses 
MsgWaitForMultipleObjectsEx() or similar, and on Linux you definitely want 
epoll() support.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Mike Crawford]

> drag C developers away from the POSIX sockets API

Don't be dismayed if you're not happy with NIO:

There are numerous APIs that do such dragging, for example the
ADAPTIVE Communications Environment (ACE):

   http://www.dre.vanderbilt.edu/~schmidt/ACE.html

Mozilla's NetScape Portable Runtime, The Electric Magic Company's
ZooLib is C++ and MIT Licensed:

   http://www.em.net/portfolio/2000/12/zoolib.html

I expect there are many others.

Mike Crawford
-- 
Mike Crawford mdcrawf...@gmail.com

  The Global Computer Industry Index: http://soggy.jobs/computer
   (It's getting more and more global every day now.)


On Tue, Aug 21, 2018 at 12:28 AM, Jean-Daniel  wrote:
>
>
>> Le 20 août 2018 à 18:51, Jens Alfke  a écrit :
>>
>>
>>
>>> On Aug 18, 2018, at 11:19 AM, Stephane Sudre  wrote:
>>>
>>> It might be the new Carbon once:
>>>
>>> - there is ABI stability in Swift. This could be not before late 2019.
>>>
>>> - the new APIs are only available in Swift. Is Swift NIO a hint this
>>> is coming sooner than expected?
>>
>> By “NIO” do you mean the new Network.framework? They did only demo the Swift 
>> API at WWDC, but it has a full C API too. (Which makes sense, since part of 
>> its goal is to drag C developers away from the POSIX sockets API.)
>>
>
> No, NIO is basically Netty in swift (and can use Network.framework under the 
> hood): https://github.com/apple/swift-nio 
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com
>
> This email sent to mdcrawf...@gmail.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Jean-Daniel]

> Le 20 août 2018 à 18:51, Jens Alfke  a écrit :
> 
> 
> 
>> On Aug 18, 2018, at 11:19 AM, Stephane Sudre  wrote:
>> 
>> It might be the new Carbon once:
>> 
>> - there is ABI stability in Swift. This could be not before late 2019.
>> 
>> - the new APIs are only available in Swift. Is Swift NIO a hint this
>> is coming sooner than expected? 
> 
> By “NIO” do you mean the new Network.framework? They did only demo the Swift 
> API at WWDC, but it has a full C API too. (Which makes sense, since part of 
> its goal is to drag C developers away from the POSIX sockets API.)
> 

No, NIO is basically Netty in swift (and can use Network.framework under the 
hood): https://github.com/apple/swift-nio 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Jens Alfke]

> On Aug 18, 2018, at 11:19 AM, Stephane Sudre  wrote:
> 
> It might be the new Carbon once:
> 
> - there is ABI stability in Swift. This could be not before late 2019.
> 
> - the new APIs are only available in Swift. Is Swift NIO a hint this
> is coming sooner than expected? 

By “NIO” do you mean the new Network.framework? They did only demo the Swift 
API at WWDC, but it has a full C API too. (Which makes sense, since part of its 
goal is to drag C developers away from the POSIX sockets API.)

> I don't know. I don't use networking frameworks.

You should consider adopting one at some point. There are several benefits they 
provide that aren’t available with POSIX APIs, like faster connection startup, 
and transparently switching between WiFi and cellular. (Stuart Cheshire’s 
various WWDC talks go into detail.)

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Jens Alfke]

> On Aug 20, 2018, at 12:43 AM, Alastair Houghton 
>  wrote:
> 
> I’d tentatively suggest that it’s likely that Swift will develop some means 
> of interfacing more directly with C++ code in the future, which should make 
> this easier rather than harder.

There are tools like SWIG for generating inter-language glue code; I don’t know 
if it supports C++ and Swift, though…

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Alastair Houghton]

On 20 Aug 2018, at 14:27, Casey McDermott  wrote:
> 
> Moving anything from Obj-C to C++ objects is easy, because the .mm file can 
> contain both.
> 
> Moving back is hard, because C++ can't reference Obj-C classes.

It can, but only if it’s either (a) in a .mm file, or (b) prepared to call the 
Objective-C runtime functions. You can include the Objective-C runtime from a 
C++ file, and you’ll get all the base types (so, not the Foundation or AppKit 
types, or any of your own, but you will get “id”, “Protocol”, “Class” and so 
on), and can make method calls using appropriate Objective-C runtime APIs. I’m 
not saying either of those would be better than what you’ve done, mind.

>>> I’d tentatively suggest that it’s likely that Swift will develop some means 
>>> of 
> interfacing more directly with C++ code in the future, which should make this 
> easier rather than harder.
> 
> This link says that C++ support is now marked "out of scope" in Swift 3.0:
> https://stackoverflow.com/questions/35229149/interacting-with-c-classes-from-swift
> I didn't find any mention of future support being planned.

Sure, that may well be the case. I can’t imagine anyone thinking it isn’t a 
desirable feature for Swift to have at some point, though, and Swift being Open 
Source, any of a very large pool of people and companies could work on this if 
they wanted. I think it’s inevitable that Swift will at some point develop 
better support for C++ objects.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Casey McDermott]

>> >> It's annoying but not dreadful to link C++ code into Cocoa via 
>> >> Objective-C.
>>  Pretty easy, I’d say; mostly you just rename your file from “.m” to “.mm” 
>> and then use C++ wherever you wish.

That part is easy, and at the beginning we were very optimistic.

The problem is, we already have an MVC architecture written in C++ / PowerPlant.
It has many business logic quirks.  We have to link the C++ controllers to 
Cocoa controllers, 
and each C++ view field to a Cocoa control (usually with subtly different 
behaviors).

Moving anything from Obj-C to C++ objects is easy, because the .mm file can 
contain both.

Moving back is hard, because C++ can't reference Obj-C classes. We use an 
intermediate C++ linker class with void pointers to Obj-C objects in the 
header.  
Then a .mm source file that talks with both.

What used to be controller -> field becomes Cocoa controller -> C++ controller 
->
C++ field -> linker -> Cocoa control.  The alternative is to rewrite all the 
business logic
in Cocoa, but that would require a year of testing to get it all right again.  
Then maintaining
two code bases from here on out.

>> I’d tentatively suggest that it’s likely that Swift will develop some means 
>> of 
interfacing more directly with C++ code in the future, which should make this 
easier rather than harder.

This link says that C++ support is now marked "out of scope" in Swift 3.0:
https://stackoverflow.com/questions/35229149/interacting-with-c-classes-from-swift
I didn't find any mention of future support being planned.

Casey McDermott
Turtle Creek Software 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Guillaume Laurent]

> On 17 Aug 2018, at 19:51, Jeremy Hughes  wrote:
> 
>> Of course, the C++ business logic doesn't need any changes.  The concern is,
>> how long will it last?  Seems like the future is an entirely Swift-based API
>> that replaces Objective-C Cocoa in 5 years, with no easy way to link to 
>> other languages.
> 
> Core parts of Webkit are written in C++, so I think you’re safe with that.
> 
> I haven’t tried to interface between Swift and C++, but I think it’s possible 
> and will probably get easier. You could ask in the Swift forums.

It’s not currently possible, from what I’ve tried, the best way to do this is 
to wrap a C++ class in an ObjC++ class.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Alastair Houghton]

On 18 Aug 2018, at 20:45, Mike Crawford  wrote:
> 
> "older OS versions", porting to 10.6 or later vs. 10.10 or later:
> 
> I at first intended all the drivers I write for my clients to work on
> Snow Leopard 10.6, but after actually attempting to do so I settled
> upon supporting El Capitan 10.11, sometimes just Sierra 12.6.

Slightly off topic, but drivers are definitely the worst case, as sometimes you 
need to use the old SDKs to build them, and the Xcode team is, in my view, 
somewhat overenthusiastic about dropping support for them… the Deployment 
Target setting isn’t always sufficient. I do wonder, actually, how much thought 
is given to those of us who have KEXTs to build when pondering whether or not 
to drop an SDK from Xcode. There have been some other pain points in recent 
macOS versions relating to KEXTs also (changes to driver signing, the recent 
blocking of third-party KEXTs until the user visits System Preferences to 
confirm their installation, etc.). One would almost think Apple didn’t want us 
writing low-level code…

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Alastair Houghton]

On 17 Aug 2018, at 17:45, Casey McDermott  wrote:
> 
>>> By now, Cocoa may be the new Carbon.   if your app is large, I'd wait to 
>>> see what happens with Marzipan.
> 
> This is true, and very scary.  Makes us wonder about sunk cost fallacy.

I don’t actually think it’s very likely that Marzipan will replace Cocoa 
(except possibly for things like calculator, to-do list and notes type apps). 
My impression is that it’s really a way to run iOS apps, which typically have a 
much simpler UI and far fewer features, on the macOS. That makes sense for some 
types of software, for sure, but I think larger packages are likely to want to 
stick with AppKit.

> It's annoying but not dreadful to link C++ code into Cocoa via Objective-C.

Pretty easy, I’d say; mostly you just rename your file from “.m” to “.mm” and 
then use C++ wherever you wish.

> Throw in Swift and future APIs that are Swift-dominated, and it becomes 
> harder.  How soon will it be impossible?

It’ll never be impossible, but you’re right at the moment you’ll need either an 
Objective-C or vanilla C API to wrap your C++. I’d tentatively suggest that 
it’s likely that Swift will develop some means of interfacing more directly 
with C++ code in the future, which should make this easier rather than harder.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Saagar Jha]

Saagar Jha

> On Aug 17, 2018, at 10:51, Jeremy Hughes  wrote:
> 
>> Of course, the C++ business logic doesn't need any changes.  The concern is,
>> how long will it last?  Seems like the future is an entirely Swift-based API
>> that replaces Objective-C Cocoa in 5 years, with no easy way to link to 
>> other languages.
> 
> Core parts of Webkit are written in C++, so I think you’re safe with that.
> 
> I haven’t tried to interface between Swift and C++, but I think it’s possible 
> and will probably get easier. You could ask in the Swift forums.

This isn’t currently possible, and would be a huge undertaking since bridging 
with C++ essentially requires adding the (complex) semantics of C++ to the 
bridging language. That being said, I think this is something that the Swift 
core team was interested in.

> 
> I think ObjC will be around for a while, at least the next ten years.
> 
> Jeremy
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com
> 
> This email sent to saa...@saagarjha.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Charles Srstka]

> On Aug 18, 2018, at 2:45 PM, Mike Crawford  wrote:
> 
> "older OS versions", porting to 10.6 or later vs. 10.10 or later:
> 
> I at first intended all the drivers I write for my clients to work on
> Snow Leopard 10.6, but after actually attempting to do so I settled
> upon supporting El Capitan 10.11, sometimes just Sierra 12.6.
> 
> There are some occasional but quite serious problems with new APIs
> appearing during a minor release so you can't just set your Deployment
> Target to a major release's first drop.  To get drivers to build - and
> I expect Cocoa code as well - one must take _great_ care to check
> Apple's doc for most if not all of your API calls to determine when
> they first appeared.
> 
> For one particular client's USB function driver we actually had three
> kernel extensions.  I at first planned to package this in just one
> kext bundle but because of time pressure shipped them as three
> separate ones.
> 
> Two of the drivers had Deployment Targets of 10.12, the third 10.11.
> I had some manner of good reason for doing it this way, but I've just
> been up all night nosediving deeply into Wikipedia and all manner of
> Epic Talk Page Flame Wars so just now I'm too thrashed to actually
> remember what it was.


Recent version of Xcode make this much easier to deal with, though, thanks to 
the @available attribute (#available in Swift). If you have your warnings set 
up correctly, this will result in a warning when you use an unavailable API 
outside of an @available block. In Swift, it’s a compiler error rather than a 
warning, so you’re basically forced to do this.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Mike Crawford]

"older OS versions", porting to 10.6 or later vs. 10.10 or later:

I at first intended all the drivers I write for my clients to work on
Snow Leopard 10.6, but after actually attempting to do so I settled
upon supporting El Capitan 10.11, sometimes just Sierra 12.6.

There are some occasional but quite serious problems with new APIs
appearing during a minor release so you can't just set your Deployment
Target to a major release's first drop.  To get drivers to build - and
I expect Cocoa code as well - one must take _great_ care to check
Apple's doc for most if not all of your API calls to determine when
they first appeared.

For one particular client's USB function driver we actually had three
kernel extensions.  I at first planned to package this in just one
kext bundle but because of time pressure shipped them as three
separate ones.

Two of the drivers had Deployment Targets of 10.12, the third 10.11.
I had some manner of good reason for doing it this way, but I've just
been up all night nosediving deeply into Wikipedia and all manner of
Epic Talk Page Flame Wars so just now I'm too thrashed to actually
remember what it was.

Mike Crawford
Portland Custom Software Development
http://soggywizards.com
m...@soggywizards.com

One Must Not Trifle With Wizards For It Makes Us Soggy And Hard To Light
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Stephane Sudre]

It might be the new Carbon once:

- there is ABI stability in Swift. This could be not before late 2019.

- the new APIs are only available in Swift. Is Swift NIO a hint this
is coming sooner than expected? I don't know. I don't use networking
frameworks.


Regarding the complexity of porting from C++ Carbon to Cocoa, there's
also the important question of what your minimum OS target is.

Maybe one of the reasons why you kept a Carbon version alive so long
is that the application needs to keep working on older OS versions.

Porting to OS X 10.10 or later is not the same thing as porting to
10.6 or later for instance.


On Thu, Aug 16, 2018 at 3:48 PM, Sean McBride  wrote:
> On Thu, 16 Aug 2018 11:54:59 +, Casey McDermott said:
>
>>I am curious, are there other developers on this list working on conversions
>>from C++ Carbon to Cocoa?
>
> By now, Cocoa may be the new Carbon.
>
> If you haven't switched to Cocoa after all these years, and if your app is 
> large, I'd wait to see what happens with Marzipan.
>
> Sean
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/dev.iceberg%40gmail.com
>
> This email sent to dev.iceb...@gmail.com



-- 
Packaging Resources - http://s.sudre.free.fr/Packaging.html
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Mike Crawford]

A while back I offered to port a PowerPlant Carbon app to Cocoa for
sometime who posted it on one of the contract programming sites -
ucode or some such.

We agreed on his total price but he absolutely _refused_ to agree on
pre-agreed milestones.  I always put such milestones in the contract,
as well as mailing back and forth with my clients as to what each
milestone should actually be, my pay for reaching each milestone as
well as what ACCEPTANCE TESTS my code must pass so as to trigger a
payment.

The reason this joker gave for being so obstinate was that he once
paid one of my Friendly Competitors for some networking code WITHOUT
EVEN LOOKING AT IT, that Friendly Competitor bailed, then his next
Friendly Competitor coudn't make sense of the first one's code.

I remain _dumbstruck_ that anyone at all would either propose, agree
to or actually pay for a milestone without both sides agreeing to the
acceptance tests which are SPECIFIED IN THE CONTRACT.

Don't even get me started.

Just Don't.
-- 
Mike Crawford mdcrawf...@gmail.com

  The Global Computer Employer Index: http://soggy.jobs/computer
   (It's actually starting to get global now.)

On Fri, Aug 17, 2018 at 5:53 PM Jerome Krinock  wrote:
>
>
>
> > On 2018 Aug 17, at 10:43, Andreas Falkenhahn  wrote:
> >
> > On 17.08.2018 at 19:37 Casey McDermott wrote:
> >
> >> Of course, the C++ business logic doesn't need any changes.  The concern 
> >> is,
> >> how long will it last?
> >
> > Well, I'd guess that C++ is pretty future-proof.
>
> Swift is itself written in C++  :)
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com
>
> This email sent to mdcrawf...@gmail.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Jerome Krinock]

> On 2018 Aug 17, at 10:43, Andreas Falkenhahn  wrote:
> 
> On 17.08.2018 at 19:37 Casey McDermott wrote:
> 
>> Of course, the C++ business logic doesn't need any changes.  The concern is,
>> how long will it last?
> 
> Well, I'd guess that C++ is pretty future-proof.

Swift is itself written in C++  :)


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Jens Alfke]

> On Aug 17, 2018, at 9:45 AM, Casey McDermott  wrote:
> 
> It's annoying but not dreadful to link C++ code into Cocoa via Objective-C.  
> Throw in Swift and future APIs
> that are Swift-dominated, and it becomes harder.  How soon will it be 
> impossible?

Never. I can't think of a single (nontrivial) language that doesn't have a 
foreign-function mechanism to call into C code. It's vital to have this, since 
much of a higher-level language's runtime support code and libraries are 
written in lower-level languages.

Also, even if 'Marzipan' is released with the goal of eventually replacing 
AppKit (which is speculative), it will be in a similar position to Cocoa in 
2001 — regardless of how good it is, the apps that _must_ be kept running on 
the Mac, like Office, PhotoShop, Final Cut, Ableton Live, still use the old 
language/framework and won't be rewritten any time soon. That means Apple must 
keep supporting the old framework for years and years and years. (17 years and 
counting, in the case of Carbon…)

—Jens  [who worked in the OS team at Apple during the OS 9 / OS X transition]
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Jeremy Hughes]

> Of course, the C++ business logic doesn't need any changes.  The concern is,
> how long will it last?  Seems like the future is an entirely Swift-based API
> that replaces Objective-C Cocoa in 5 years, with no easy way to link to other 
> languages.

Core parts of Webkit are written in C++, so I think you’re safe with that.

I haven’t tried to interface between Swift and C++, but I think it’s possible 
and will probably get easier. You could ask in the Swift forums.

I think ObjC will be around for a while, at least the next ten years.

Jeremy


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Andreas Falkenhahn]

On 17.08.2018 at 19:37 Casey McDermott wrote:

> We are slogging along with Cocoa.  The app has final appearance now, but
> there are many small details to complete.  We won't be done by Mojave release 
> but
> probably can finish before the next one.

> Of course, the C++ business logic doesn't need any changes.  The concern is,
> how long will it last?

Well, I'd guess that C++ is pretty future-proof. If you want to be even safer,
go back to plain C. Given the wide array of open-source libraries written in C
and used by Apple, I think it's pretty certain that they can never ever drop C
support. Even if the higher level stuff changes every once in a while now, 
there'll
always be a way to call into C code from it. At least that's what I'd predict.

-- 
Best regards,
 Andreas Falkenhahnmailto:andr...@falkenhahn.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Casey McDermott]

We are slogging along with Cocoa.  The app has final appearance now, but
there are many small details to complete.  We won't be done by Mojave release 
but
probably can finish before the next one.

Of course, the C++ business logic doesn't need any changes.  The concern is,
how long will it last?  Seems like the future is an entirely Swift-based API
that replaces Objective-C Cocoa in 5 years, with no easy way to link to other 
languages.
The payback isn't big enough to write software with only a 5 year lifetime.

Casey McDermott
Turtle Creek Software 


On Fri, 8/17/18, Jeremy Hughes  wrote:

 Subject: Re: Carbon -> Cocoa
 To: "Casey McDermott" 
 Cc: "Cocoa Dev" 
 Date: Friday, August 17, 2018, 1:10 PM
 
 > Our app has 6 or 8 programmer-years of
 C++ cross-platform business logic.  Accounting software is
 complicated. Rewriting that in another language would be
 hard work, and tons of testing. More than Mac sales would
 justify, so it would be time to go Windows-only or just
 fold.
 
 If you have a
 cross-platform business logic, it’s presumably separate
 from the UI and separate from Carbon - so you don’t need
 to rewrite it.
 
 Personally,
 I would rewrite the UI. You can try to Cocoa-fy it in a
 gradual process, but that didn’t work out for us, and it
 doesn’t seem like it’s working out for you.
 
 Jeremy
 
 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Jeremy Hughes]

> Our app has 6 or 8 programmer-years of C++ cross-platform business logic.  
> Accounting software is complicated. Rewriting that in another language would 
> be hard work, and tons of testing. More than Mac sales would justify, so it 
> would be time to go Windows-only or just fold.

If you have a cross-platform business logic, it’s presumably separate from the 
UI and separate from Carbon - so you don’t need to rewrite it.

Personally, I would rewrite the UI. You can try to Cocoa-fy it in a gradual 
process, but that didn’t work out for us, and it doesn’t seem like it’s working 
out for you.

Jeremy


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Casey McDermott]

>> By now, Cocoa may be the new Carbon.   if your app is large, I'd wait to see 
>> what happens with Marzipan.

This is true, and very scary.  Makes us wonder about sunk cost fallacy.

It's annoying but not dreadful to link C++ code into Cocoa via Objective-C.  
Throw in Swift and future APIs
that are Swift-dominated, and it becomes harder.  How soon will it be 
impossible?

Our app has 6 or 8 programmer-years of C++ cross-platform business logic.  
Accounting software is complicated.
Rewriting that in another language would be hard work, and tons of testing. 
More than Mac sales would justify, 
so it would be time to go Windows-only or just fold.

Casey McDermott
Turtle Creek Software 


On Thu, 8/16/18, Sean McBride  wrote:

 Subject: Re: Carbon -> Cocoa
 To: "Casey McDermott" , cocoa-dev@lists.apple.com
 Date: Thursday, August 16, 2018, 9:48 AM
 
 On Thu, 16 Aug 2018 11:54:59
 +, Casey McDermott said:
 
 >I am
 curious, are there other developers on this list working on
 conversions
 >from C++ Carbon to
 Cocoa?
 

 
 If
 you haven't switched to Cocoa after all these years, and

 
 Sean
 
 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Casey McDermott]

>>  The OP is as late as he could be (no offense meant). 

We started 4 years ago.  The previous update from OS 9 to OS X Carbon took about
3 months.  Moving from PPC to Intel was about a month (helped by the fact we 
already byte-swap for the Windows version).  So, we figured it would take a 
year or so.

The original plan was to subcontract the GUI work, since we assumed there would
be many experienced contractors who had already done Carbon to Cocoa ports.  
Meanwhile, we updated the back end in parallel: converting PowerPlant's LArray 
to std::vector, 
replacing the database, etc.

4 different contractors tried to Cocoa-ize, and got nowhere. Another used QT and
reached the first draw payment, then stopped.  We started asking people for 
prior conversion
samples. The few who had actually finished one all wanted $100K+ to do another.

So, we started the GUI work in-house 2 years ago.  Completion estimates keep 
receding.

Casey McDermott
Turtle Creek Software 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[James Walker]

On 8/16/18 4:54 AM, Casey McDermott wrote:

I am curious, are there other developers on this list working on conversions
from C++ Carbon to Cocoa?

If so, how is it going?


(Sorry about the empty post; the list server eats my messages if I try 
to post in HTML.)


I'm working on it.  I have converted all windows and menus to Cocoa. 
What remains is converting to NSApplicationMain, getting rid of Carbon 
Events being sent to window event targets, and other miscellaneous things.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[James Walker]

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Jeremy Hughes]

> By now, Cocoa may be the new Carbon.

The crucial difference is that Cocoa supports 64-bit applications, and Carbon 
doesn’t.

> If you haven't switched to Cocoa after all these years, and if your app is 
> large, I'd wait to see what happens with Marzipan


We don’t have time to wait for Marzipan - Apple are dropping support for 32-bit 
applications after Mojave.

Jeremy

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Sean McBride]

On Thu, 16 Aug 2018 11:54:59 +, Casey McDermott said:

>I am curious, are there other developers on this list working on conversions
>from C++ Carbon to Cocoa?

By now, Cocoa may be the new Carbon.

If you haven't switched to Cocoa after all these years, and if your app is 
large, I'd wait to see what happens with Marzipan.

Sean


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Steve Mills]

> On Aug 16, 2018, at 06:54:59, Casey McDermott  wrote:
> 
> I am curious, are there other developers on this list working on conversions
> from C++ Carbon to Cocoa?
> 
> If so, how is it going?

At my previous job, we started doing that soon after I started. This was an 
enormous app with, jeez, I forget, like 150 dialogs? There were 4 of us that 
could do Mac dev, plus still keep up with normal release cycles. 3 years later, 
all but 1 of those 4 were laid off because the new owner moved the company to 
Colorado to be with his other bought-up company. In those 3 years, we made a 
small dent in the Carbon->Cocoa, and that was only because 1 guy would work 
nights and weekends coming up with ways to automate parts of the process.

We'd continually run into weird problems when trying to have Carbon and Cocoa 
windows up at the same time. But that was quite a few major OS versions ago. 
I'll just say it's not a fun process, especially when it's this many years 
after the "Carbon is dead" announcement. My choice would be to do it as a 
rewrite.

--
Steve Mills
Drummer, Mac geek

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Carbon -> Cocoa

[Jeremy Hughes]

We found it very difficult. This was for a large C++ Carbon application.

We’re now rewriting in Swift + Cocoa, starting from scratch.

Jeremy

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com