Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

> 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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

> 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

Re: Carbon -> Cocoa

> 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

Re: Carbon -> Cocoa

> 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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

> 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

Re: Carbon -> Cocoa

"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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

> 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

Re: Carbon -> Cocoa

> 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

Re: Carbon -> Cocoa

> 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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

> 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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

> 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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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

Re: Carbon -> Cocoa

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