LeaukiProg

All the Cocoa bindings for Mono in the world...

2010-04-22T04:15:00.000-07:00

Over the last few years I found it increasingly confusing when yet another Cocoa binding was added to or offered for Mono.

Cocoa bindings allow .NET/Mono programs to call native Mac OS X APIs. This is usually needed to create a native-looking (and native-being) GUI.

Just a few days ago Novell announced MonoMac, the newest addition to the team:

http://tirania.org/blog/archive/2010/Apr-19.html

I myself use Monobjc. The first library to do this job was CocoaSharp.

These are the Cocoa binding libraries for Mono that I have heard of:

CocoaSharp (deprecated, part of Mono)

Cocoa# (CocoaSharp) is an effort to bring Mono and the Mac OS X Cocoa toolkits together in a two way bridge, allowing Mac developers that leverage the Mono runtime libraries, while retaining a native Mac look and feel. This bridge also allows Mono based applications to have access to the Cocoa libraries directly.

http://www.mono-project.com/CocoaSharp

CocoaSharp is still part of Mono but hasn't been in active development for years.

Monobjc (active, not part of Mono)

The Monobjc bridge provides the necessary tools to develop and run .NET applications (written in C#, VB.NET, etc.) that interact with Objective-C frameworks and libraries under Mac OS X. Existing Objective-C classes can be used in .NET code in an almost transparent manner.

Since Monobjc is not part of Mono any program that uses Monobjc will have to be distributed with the Monobjc dlls.

http://www.monobjc.net/

mobjc (active, not part of Mono)

mobjc is a Mono library which allows .NET code to interoperate with Apple frameworks such as foundation and appkit. It makes it possible for managed code to call native Objective-C methods, native methods to call managed code, and new Objective-C classes to be defined in managed code. Exceptions are properly marshaled in both directions.

http://code.google.com/p/mobjc/

mcocoa (active, based on mobjc, not part of Mono)

mcocoa provides a set of wrapper classes which allow Apple's Cocoa frameworks to be used from Mono. The wrappers are generated using the make file and rely on the mobjc library to handle the bridging between Objective-C and Mono.

http://code.google.com/p/mcocoa/

MonoTouch (for iPhone OS)

MonoTouch allows developers to create C# and .NET based applications that run on Apple's iPhone and Apple's iPod Touch devices, while taking advantage of the iPhone APIs and reusing both code and libraries that have been built for .NET, as well as existing skills.

http://monotouch.net/

MonoMac (announced for Mono 2.8)

I could find a catchphrase paragraph for MonoMac. But a blog post explaining what MonoMac is can be found here:

http://tirania.org/blog/archive/2010/Apr-19.html

Mono Tools for Visual Studio 1.1 has been released!

2010-04-02T05:06:00.000-07:00

Mono Tools for Visual Studio 1.1 has been released!

http://www.mono-project.com/news/archive/2010/Mar-31.html

I think I will get this.

.NET Old News March 23rd 2010

2010-03-23T04:15:00.000-07:00

Novell are developing a version of Mono for Google Android. Monodroid will allow developers to write .NET applications for Android phones:

MonoDroid will give Android developers tools for binding the Java APIs, while making them accessible through the JIT-compiled, 335-powered runtime engine. This will hopefully allow allow developers to reuse their engine and business logic code across all mobile platforms and swapping out the user interface code for a platform-specific API.

http://androidcommunity.com/novel-monoc-is-developing-monodroid-20100217/

This appears to be similar to MonoTouch, a way to develop .NET applications for the iPhone.

http://monotouch.net/

I hear Microsoft have released downloadable previews of developer tools for Windows Mobile 7. Apparently the new GUI is based on Silverlight.

http://developer.windowsphone.com/windows-phone-7-series/

.NET News March 22nd 2010

2010-03-22T04:58:00.000-07:00

A new version of Mono has been released, version 2.6.3. I assume this will fix the bug with Messagebox.Show(). It's in the list.

According to the Podcast at Delphi.org a new version of Delphi Prism will be released in late April (instead of February as would be the usual rhythm) to match the release of Microsoft Visual Studio 2010 on which it will be based. This new release will most likely come with an updated version of Mono.

Hebrew Conjugator Current State

2010-01-24T07:30:00.000-08:00

Hebrew Conjugator is a program that conjugates Hebrew verbs, or at least attempts to. Running on Windows Vista it looks like this:

(Click on image for larger version.)

The application currently consists of two files, HebrewConjugator.exe and HebrewConjugation.dll.

HebrewConjugator.exe is a .NET program for Windows that calls methods in HebrewConjugation.dll to conjugate Hebrew verbs. The program runs under Mac OS X but right-to-left language support is broken in Mono and all words are written the wrong way around.

HebrewConjugation.dll is a pure .NET library (actually it currently imports System.Windows.Forms for debug reasons) used by HebrewConjugator. It expects the program to set the wanted binyan like this:

// set binyan

if radioPa3al.Checked then binyan := 1;

if radioPa3ul.Checked then binyan := 2;

if radioNif3al.Checked then binyan := 3;

if radioPi3el.Checked then binyan := 4;

if radioHitpa3el.Checked then binyan := 6;

if radioHif3il.Checked then binyan := 7;

and create a HebrewWord from one of the classes provided by the library.

HebrewConjugation.dll is based on code that should be easy to adapt for other Semitic languages like Arabic and Akkadian, which I hope I will find the time to look at when Hebrew is done. It should also work on Mac OS X and Linux with native front ends or the Web with a Web application using the library. I will also add database support to save corrected verb forms.

The HebrewWord class deals with the binyan defined and adapts for exceptions:

constructor HebrewWord(setRoot: String; setBinyan: Int32);

begin

// configure word

root := setRoot;

binyan := setBinyan;

// create a general conjugation object to help with binyan

conjugation := new HebrewConjugation;

// specifiy complete binyan

if not (root.Length = 3) then binyan := 0;

if conjugation.IsHollow(root) then binyan := binyan + 10;

if conjugation.HasFinalHe(root) then binyan := binyan + 20;

if conjugation.StartsWithAlef(root) then binyan := binyan + 40;

if (conjugation.StartsWithWeakLetter(root) and not conjugation.WeakPeSurvives(root)) then binyan := binyan + 80;

end;

Other exceptions are caught (perhaps) by the Conjugation objects themselves. Conjugation objects are created based on the binyan number (including exception sums):

// create a general conjugation object

conjugation := new HebrewConjugation;

// create a Conjugation object for the right binyan

case binyan of

1: conjugation := new ConjugationPa3al;

2: conjugation := new ConjugationPa3ul;

3: conjugation := new ConjugationNif3al;

4: conjugation := new ConjugationPi3el;

6: conjugation := new ConjugationHitpa3el;

7: conjugation := new ConjugationHif3il;

11: conjugation := new ConjugationPa3alHollow;

12: conjugation := new ConjugationPa3ulHollow;

14: conjugation := new ConjugationPi3elHollow;

17: conjugation := new ConjugationHif3ilHollow;

There is/should be one Conjugation class defined for each binyan and for each exception in each binyan. Hence every Conjugation class only has to implement methods required for its particular type of root and daughter classes only have to implement what is missing in the class handling the binyan with no exceptions.

The HebrewConjugation base class also handles adding prefixed and suffixes as well as pronouns. Daughter classes refer to those methods to create finite verb forms.

For example, binyan Nif3al (G-Stem Reflexive) is implemented like this:

function ConjugationNif3al.GetInfinitive(root: String): String;

var

r: String;

begin

r := Lamed + He + root;

result := r;

end;

function ConjugationNif3al.GetPresentTense(root: String; person: Int32; male: Boolean): String;

var

r: String;

begin

// prepare root

root := Nun + root;

// get finite form

r := AddAffixesPresentTense(root, person, male, Taw);

r := AddPronoun(r, person, male);

result := r;

end;

function ConjugationNif3al.GetPerfectTense(root: String; person: Int32; male: Boolean): String;

var

r: String;

begin

// prepare root

root := Nun + root;

// get finite form

r := AddAffixesPerfectTense(root, person, male);

r := AddPronoun(r, person, male);

result := r;

end;

function ConjugationNif3al.GetImperfectTense(root: String; person: Int32; male: Boolean): String;

var

r: String;

begin

// prepare root

root := Yud + root;

// get finite form

r := AddAffixesImperfectTense(root, person, male);

r := ReplaceLetters(r, true, Alef + Yud, Alef);

r := AddPronoun(r, person, male);

result := r;

end;

This is the entire implementation part of the ConjugationNif3al class. It deals with no-nonsense non-exceptional roots like "kathav" ("he wrote"). Nif3al exceptions are not yet implemented. (However the active binyanim are completely implemented.)

Note that the entire program is specifically written in a very primitive way so that I can keep understanding it without getting confused.

You can download the current development version here:

http://www.netneurotic.net/bin/HebrewConjugator.zip

Just unpack both files into the same directory and run the program. This might or might not work and the program might or might not currently work. (The zip file is continuously updated with a more current version. Some new versions break what already worked in another branch.)

Refactoring Immediately

2009-09-02T02:33:00.000-07:00

I had to make lots of changes almost immediately in my project.

(See my original article on the Hebrew Conjugator project.)

Whenever I had formulated a way to output the correct finite verb form for a given tense/person/gender combination and after implementing exceptions, I found that the formula could be simplified again. So I had to do that in order to avoid that newly discovered exceptions during testing would not make the code ridiculous complicated.

I also noticed that object-orientation is ideal for this, so I implemented another set of subclasses for conjugations of a certain type and for certain exceptions.

The program now has a class "Conjugation" which implements a few helper methods and four conjugation methods:

function GetInfinitive(root: String): String;
function GetPresentTense(root: String; person: Int32; male: Boolean): String;
function GetPastTense(root: String; person: Int32; male: Boolean): String;
function GetFutureTense(root: String; person: Int32; male: Boolean): String;

Each method simply returns an empty string for all input values. This ensures two things. First, any unsupported conjugation can still be called (see note 1) and will not crash the program or return false results. Second, any non-implemented features in a supported conjugation will not return false results either (see note 2).

Note 1: If a subclass of Conjugation does not implement an override for a method, the original method will be called and, in this case, return an empty string.

Note 2: Subclasses of specific conjugations that do not implement an override for a method, will call the specific conjugation's method and return a false result. Hence all subclasses of subclasses of Conjugation will have to implement override methods if the original override method would return false results.

The program then defines subclasses of Conjugation representing specific conjugations (Hebrew: binyanim = buildings), for example ConjugationPa3al.

The subclasses define their own override versions of the four methods.

Orginially, the subclasses also defined new methods for exceptions (like GetPresentTenseHollow for hollow roots), but I found that the code is easier to read if each method follows the same structure in name and content. Hence were born subclasses of the subclasses, including ConjugationPa3alHollow (for hollow roots, like "gar" = "he dwelled" or "ba" = "he came"; "pa3al" is one of the conjugations in Hebrew)and ConjugationPa3alHe (for roots ending on He, like "qanah" = "he bought" and "panah" = "he turned").

Exceptions that only affect the infinitive are handled by the original subclass.

For the infinitive of root ending on He, I found a particularly clever (in my opinion) solution. ConjugationPi3el actually returns the correct infinitive for both roots ending on He ("qanah" -> "liqnoth") and normal roots ("katav" -> "likhtov") and ConjugationPi3elHe does not implement an override for the GetInfinitive() method. This constitutes a combination of not rewriting existing code but still keeping different things in different modules, logically.

Current class tree:

- Conjugator (GUI program uses Conjugation.dll)

- HebrewWord (used by Conjugator)

- Conjugation (all used by HebrewWord)
-- ConjationPa3al
--- ConjugationPa3alHollow
-- ConjugationPi3el
--- ConjugationPi3elHe

Other classes are not implemented yet.

Each subclass of Conjugation and their descendants contain implementations of GetInfinitive(), GetPresentTense(), GetPastTense(), and GetFutureTense(), if needed and nothing else.

Hebrew Conjugator - a Delphi Prism Project

2009-08-31T14:02:00.000-07:00

For the past few weeks, I have been working on a Delphi Prism project, a Hebrew verb conjugation program. It is meant to handle regular as well as irregular verbs.

The program consists of two parts, a conjugation library HebrewConjugation.dll and a front end HebrewConjugator.exe. The library defines a class HebrewWord as well as a class Conjugation, a base class from which the several conjugations (in Hebrew: binyanim = buildings) are derived. So far I have implemented parts of two conjugation classes, ConjugationPa3al and ConjugationPi3el.

The base class also defines as constants all letters of the Alefbet (Hebrew alphabet), helper methods to access the characters (for example to modify final letters when appropriate), and empty conjugation methods that simply return empty strings.

public

function Alefbet(i: Int32): String;

function Sofit(s: String): String;

function GetInfinitive(root: String): String; virtual;

function GetPresentTense(root: String; person: Integer; male: Boolean): String; virtual;

function GetPastTense(root: String; person: Integer; male: Boolean): String; virtual;

function GetFutureTense(root: String; person: Integer; male: Boolean): String; virtual;

An object of the type HebrewWord creates an object named conjugation first of the type Conjugation (i.e. the base class) and then of the correct type (e.g. ConjugationPa3al) if such a class already exists. (This means that all conjugations will technically work and not throw exceptions. If a conjugation is not implemented yet, it will return empty strings for any finite verb form requested.)

Catching irregular verbs is done step-by-step, like here:

function ConjugationPa3al.GetPastTense(root: String; person: Int32; male: Boolean): String;

var

r: String;

begin

if (root.Length = 2) then begin // two-letter root

r := GetPresentTenseHollow(root, person, male);

result := r;

exit;

end else begin // three-letter root

The Windows.Forms front end doesn't work on Mac OS X because of, I think, a bug in how Mono handles right-to-left scripts. (Input also doesn't work. I reported the bug to Novell.) So the current version runs on Windows (and perhaps Linux, I haven't tried).

I was planning to build separate front ends for Mac OS X (Monobjc) and Linux (GTK#) anyway, also for WPF and Silverlight (if I find the time).

Plus I plan to add an option to save a root and all finite forms in a (Blackfish SQL) database so that a conjugation once corrected and confirmed can be remembered by the program and accessed when the same root is asked again.

Currently the following items work:

Pa3al: infinitive, present tense (i.e. nouns), past tense (i.e. perfect tense)

Pi3el: infinitive, present tense

Hif3il: nothing

Hitpa3el: nothing

passive conjugations: not supported at all for the moment

Wish me luck!

Delphi Prism - First Experiment

2009-07-12T14:54:00.001-07:00

After writing a simple Winforms application I figured I should try out Delphi Prism and Monobjc to write a program for Mac OS X.

My first attempt was a disaster and I ran into three bugs in the IDE (now reported to Embarcadero), and two problems that I caused myself while trying to figure out how to deal with everything else that went wrong.

But at the end somebody in the Embarcadero newsgroups managed to explain everything so clearly that even I could understand it.

First, I spent a Saturday afternoon at Powerscourt Gardens in Wicklow, which I now realise is an excellent way to start a project.

It rained, which meant that most visitors were spending their valuable free time in the main building. We pretty much had the entire park for ourselves. It wasn't raining hard.

Powerscourt Gardens has an English garden, a Japanese garden, and a Robin-Hood style valley with cannon tower.

But be that as it may, Saturday evening and Sunday was spent learning Delphi Prism and playing StarCraft.

Delphi Prism supports Cocoa via Cocoa# and via Monobjc. Monojbc is now the preferred method. Most Cocoa classes, including GUI and other classes are exposed to .NET via wrappers provided by Monobjc. It is possible to create an NSMutableString in Prism and I assume it can be cast into a System.String but I haven't tried.

But what is perhaps most important is that Monobjc allows Prism (and any other .NET language) to use Cocoa NIB files. NIB files contain, as I understand it, archived (or "serialised") Cocoa objects like windows, buttons, text fields etc.. which can be unarchived and connected to delegates at runtime. Via Monobjc a .NET class can act as the delegate for these Cocoa objects.

Delphi Prism provides tools to read NIB files into Visual Studio and Prism and allows for somewhat easy interaction between the Windows and Mac worlds. Prism also creates a bundle out of the compiled .NET assemblies and adds all required DLLs the usual way.

After building the application in Visual Studio, the result is a bundle with a Macintosh icon (in this case the default icon for Monobjc projects in Delphi Prism):

The application uses native Cocoa windows fresh out of a NIB file. Here the text in the text box is not part of the window definition from the NIB but was added by a delegate method awakeFromNib: which is implemented in Pascal.

The text field ("textMessage") is mapped to the NIB in designable.pas, a Pascal file in the NIB folder.

The code for the actual method looks like this:

method ApplicationController.AwakeFromNib;

begin

textInfo.StringValue := 'Hello Prism Cocoa 2 Judgement Day';

end;

AwakeFromNib() is mapped to the Objective-C method awakeFromNib: automatically. I think Prism's NIB reader tool does that. Not all delegate methods are automatic like that. More about that later.

Here we have an alert box (NSRunAlertPanel) displayed when the OK button in the main window is clicked.

The method for the button event has to be added as an action in the NIB file and will then show up in designable.pas in the NIB folder. Somehow that maps the Pascal method to the action in the NIB file as Cocoa expects it.

Embarcadero say that this is a well-designed feature but I think it is magic.

Code:

[ObjectiveCMessage('PushOK:')]

method PushOK(aSender: NSObject); partial; empty;

(This is the generated code in designable.pas that maps the method to the action in the NIB file.)

method ApplicationController.PushOK(aSender: NSObject);

var

msgbox: Integer := AppKitFramework.NSRunAlertPanel('Hello Prism Cocoa 2 Judgement Day', 'Somebody pressed the OK button!', 'Really?', nil, nil, nil);

begin

if msgbox = NSPanel.NSAlertDefaultReturn then textInfo.StringValue := 'Somebody pressed the OK button just then.';

end;

(This is the code I wrote to make the alert box appear and change the text in the text field.)

The text field's contents has been changed by the method called by the button pressed.

Everything in the text field is selected. I didn't care because I was only experimenting. But I guess I have to play with a few attributes a bit more.

One common problem with Cocoa (it's by design for good reason) is that closing the last window does not quit the program. This is very useful in a Web browser or word processor but annoying when the program only has one window and is useless without that one window.

So I figured this would be a good way to test surprising delegate methods (i.e. those that are not awakeFromNib:).

I display an alert box when the red button to close the window is clicked on.

This requires two things.

First, the event has to be caught, which turns out is easy because the event has its own delegate method which I can implement somewhere. If I can manage to map my Pascal method to the delegate method the NIB expects, it should work.

Then, the event has to be cancelled in case the user decides "No" and doesn't want to quit.

This definition in the public type section of the ApplicationController.pas class file maps the Pascal function to the delegate method:

[ObjectiveCMessage('windowShouldClose:')]

function WindowShouldClose(window: NSWindow): Boolean; partial;

And this code, further down, implements the function:

function ApplicationController.WindowShouldClose(window: NSWindow): Boolean;

var

msgbox: Integer := AppKitFramework.NSRunAlertPanel('Hello Prism Cocoa 2 Judgement Day', 'Really Quit?', 'Yes', 'No', nil, nil);

begin

if msgbox = NSPanel.NSAlertDefaultReturn then Environment.Exit(0) else Result := false;

end;

It works beautifully.

Of course, this program only works on Mac OS X. But I now have a Mac program that can use .NET DLLs at will. This allows for some great portability, as code written for a Windows (.NET) program can also be used for a Mac program. Only the GUI parts and those parts that use other native classes (from Cocoa or Windows COM+) have to be written per platform.

Potential issues:

I assume that when I use other Cocoa classes that are not available in the form of existing objects from a NIB file, I will have to keep track of them and release them when I am done with them to avoid memory leaks.

Plus, all programs will have to be written in a way that allows for replacing everything GUI-related without breaking the business logic.

(I am hearing that Delphi for Win32 will be cross-platform soon. This will add another choice to a field dominated still by Java and REALbasic.)

iPhone debug zombies and finally VMware

2009-07-06T09:24:00.000-07:00

A few weeks ago I had an iPhone app running in the simulator that wouldn't quit. I also could not kill it, not using Activity Monitor nor kill or kill -9 or killall.

cyrus:~ ajbrehm$ ps auxc|grep Vocky
ajbrehm  76450   0.0  0.1   153116   5212   ??  UE   12:59pm   0:00.05 Vocky
ajbrehm  76437   0.0  0.1   153116   5212   ??  UE   12:58pm   0:00.05 Vocky
ajbrehm  76350   0.0  0.1   153116   5212   ??  UE   12:57pm   0:00.05 Vocky
ajbrehm  76336   0.0  0.1   153116   5212   ??  UE   12:56pm   0:00.05 Vocky
ajbrehm  76329   0.0  0.1   153116   5212   ??  UE   12:56pm   0:00.05 Vocky
ajbrehm  76276   0.0  0.1   153116   5212   ??  UE   12:56pm   0:00.05 Vocky
ajbrehm  76245   0.0  0.1   153116   5212   ??  UE   12:55pm   0:00.05 Vocky
ajbrehm  76176   0.0  0.1   153116   5212   ??  UE   12:55pm   0:00.05 Vocky
ajbrehm  76159   0.0  0.1   153116   5212   ??  UE   12:54pm   0:00.05 Vocky
ajbrehm  76150   0.0  0.1   155136   9264   ??  UE   12:54pm   0:00.10 Vocky

This happened whenever I ran the application in the simulator. Sometimes Xcode's debugger picked up on it and the simulator wouldn't run the application any more because, as the console sayd, it was already running.

It took me a while to figure out what was going on. But then misfortune struck and taught me the solution.

After a while VMware also started behaving oddly and left "vmware" zombies behind in Activity Monitor. One of the VMware instances then blocked the GUI. (It also kept changing the mouse pointer tracking speed for some reason. I have no idea why VMware is allowed to change system preferences and block the GUI.)

Ultimately I had to bring down the GUI (I killed loginwindow and windowserver) and solve the problem.

A few days earlier I had tried switching off Spotlight search because it had started indexing 600 GB of incoming data during a copy process (which took nearly 6 hours because of that, from a Firewire 800 disk). For some reason the only way to stop Spotlight from restarting itself during that copy process was to rename ReportCrash to something else ("ReportCrash2") so that it couldn't be found. That made sense at the time.

The problem was that I had forgotten that I had done that.

Once ReportCrash was usable again, each of the zombies reported its crash and went away, both the iPhone program and the many instances of the VMware interface. This took about 5 minutes. (In the process I learned that the 24" Apple Cinema Display is an EXCELLENT monitor for a text interface! Finally I could see each line without linebreaks.)

After that was done, I restarted windowserver and loginwindow and could log back into the GUI. My VMware VMs had also survived (since I didn't reboot) and VMware worked again and I could connect to all the Windows VMs and the zombie processes had gone.

Turned out it was a ten minute issue once it was clear that it had nothing to do with Xcode or gdb.

I hate ReportCrash.