Comments on: Adventures in Cocotron

By: Iain

Iain — Sun, 27 Dec 2009 11:48:08 +0000

That’s Levar Burton, not Geordi LaForge. Cool project, anyway. I wonder how foreign a complex Cocoa application would feel on Windows.

By: James

James — Fri, 31 Oct 2008 22:51:31 +0000

The most glaring “looks ported” feel will be that Mac apps have OK to the right of Cancel, where Windows users expect OK on the left. Does NSAlert alertWithMessageText: put the default button on the left?

By: glen

glen — Thu, 30 Oct 2008 21:56:51 +0000

Hi Alexei: No, our changes are not in yet. You should see some of them start coming through the group this week. As for iconForFile:, I just took a look at your version, and let’s just say I don’t think mine will ever see the light of day, as it’s many more levels of nasty!

By: Alexei

Alexei — Thu, 30 Oct 2008 15:53:45 +0000

So you were adding/fixing things in Cocotron and sitting on your changes, rather than submitting patches to Cocotron as you progress? Why?

For instance, I implemented “[NSWorkspace iconForFile:]” for Win32 in the current Cocotron tree. But you say you’ve implemented this.

So either you’re taking credit for my work, or more likely you implemented this back when it wasn’t yet in Cocotron, and sat on your changes without submitting a patch. Then, since I didn’t know of your changes, I re-implemented this which was added to Cocotron. A duplication of effort!

Please submit fixes/features as patches when you have them ready, rather than sitting on them for months and causing others to duplicate the effort.

By: glen

glen — Wed, 29 Oct 2008 20:02:01 +0000

@David Leppik: There’s definitely a bit of “ported”-looking UI in the app! Since we don’t have have Windows background, we didn’t see it. But as soon as we showed the app to some Windows users, they immediately pointed out, for example, that the dialog boxes looked non-standard. Some of that can probably be fixed within the Cocotron framework. For more complicated apps, a separate nib file would probably be in order.

By: ken

ken — Wed, 29 Oct 2008 19:38:34 +0000

@Keith: Thanks for the info. Threading was not one of the areas that caused us any grief. However, from what you say it sounds like some race condition issues do exist.

By: Keith Bauer

Keith Bauer — Wed, 29 Oct 2008 19:05:30 +0000

I remembered reading it somewhere, so I took a look at the source. I don’t think I’m reading this wrong…

-retain and -release aren’t atomic, so if two threads retain/release the same object at once I see nothing preventing the retain count from getting out of synch.

The retain count is stored in a global hashtable which is mutated on -retain and -release, without locking; I see nothing that would suggest that this is in the least safe from corruption due to concurrent modification.

http://cocotron.googlecode.com/svn/trunk/Foundation/NSZone/NSZone.m

+initialize isn’t locked, so if the same class is used first from two different threads simultaneously, it could be called twice.

http://cocotron.googlecode.com/svn/trunk/Foundation/objc/ObjCClass.m

There may be more, but those were the things I thought to check.

By: ken

ken — Wed, 29 Oct 2008 16:15:03 +0000

@Keith: Yes, we do use threads. It seemed to work just fine. Why do you think it’s un-thread-safe?

@Mike: That’s really funny.

By: Keith Bauer

Keith Bauer — Wed, 29 Oct 2008 08:50:31 +0000

You explicitly mention threading, yet Cocotron is very un-thread-safe — how do you handle that, or does your app not have multiple threads?

By: Mike

Mike — Wed, 29 Oct 2008 05:20:27 +0000

Amazing! The only thing funny is the name Cocotron. I will explain. In Portuguese, coco, or better, cocô, is shit. So the name sounds like shitTron what in fact is perfect, as you are compiling for windows…haha