Thursday, April 22, 2010

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

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

Friday, April 2, 2010

Tuesday, March 23, 2010

.NET Old News March 23rd 2010

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/

Monday, March 22, 2010

.NET News March 22nd 2010

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.

Sunday, January 24, 2010

Hebrew Conjugator Current State


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