I'm announcing version 0.2 of the D/Objective-C bridge. Here are the major improvement:

*  Now compiles and work correctly on Macs with Intel processors.
*  Reduced the number of functions involved in the the function/method
  call bridge to reduce the noise when looking at the call stack
  from the debugger.
*  Dramatically reduced the size of the templates that need to be
  instanciated at import time. As a result, compiling a module that
  include the Cocoa class wrappers (including compiling the wrapper
  themselves) is much faster now.
*  Added wrappers for many classes from the Cocoa framework (many of
  them are still incomplete or subject to change).

If anyone wants to play with it, you can find it here:

<http://michelf.com/projects/d-objc-bridge/>


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Michel Fortin wrote:

> I'm announcing version 0.2 of the D/Objective-C bridge. 

Great work, as usual! For some reason, the file download
says "d-objc-0.1.zip" (?) even if it was downloaded from
http://michelf.com/docs/code/d-objc-0.2.zip
"301 Moved Permanently" (redirecting to d-objc-0.1.zip)

--anders

On 2008-01-11 09:26:18 -0500, Anders F Björklund <afb@algonet.se> said:

> Michel Fortin wrote:
> 
>> I'm announcing version 0.2 of the D/Objective-C bridge.
> 
> Great work, as usual! For some reason, the file download
> says "d-objc-0.1.zip" (?) even if it was downloaded from
> http://michelf.com/docs/code/d-objc-0.2.zip
> "301 Moved Permanently" (redirecting to d-objc-0.1.zip)
> 
> --anders

Right. Silly apache auto-guessing what the correct name is. Try this:
http://michelf.com/docs/code/d-objc-0.2.tgz

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Michel Fortin escribió:
> I'm announcing version 0.2 of the D/Objective-C bridge. Here are the major improvement:
> 
> *  Now compiles and work correctly on Macs with Intel processors.
> *  Reduced the number of functions involved in the the function/method
>   call bridge to reduce the noise when looking at the call stack
>   from the debugger.
> *  Dramatically reduced the size of the templates that need to be
>   instanciated at import time. As a result, compiling a module that
>   include the Cocoa class wrappers (including compiling the wrapper
>   themselves) is much faster now.
> *  Added wrappers for many classes from the Cocoa framework (many of
>   them are still incomplete or subject to change).
> 
> If anyone wants to play with it, you can find it here:
> 
> <http://michelf.com/projects/d-objc-bridge/>
> 
> 

Any chance of making this Tango compatible?

-- 
Carlos Santander Bernal

On 2008-01-14 12:41:48 -0500, Carlos Santander <csantander619@gmail.com> said:

> Any chance of making this Tango compatible?

I suppose it shouldn't be too hard as I'm only using a few things from Phobos, namely:

- std.string : mostly for toStringz
- std.c.args : for _argptr, to wrap NSLog which is variadic (but the wrapping isn't done so well)
- std.utf : to support the interesting concept of subclassing NSString to encapsulate a D string
- std.gc : for adding a root to the D class in the Objective-C capsule object's memory
- std.traits : to get the list of fields of an object (method definitions are mixed in as fields)
- std.metastring : for converting numbers to strings in some compile-time error messages
- std.c.stdlib : for malloc and free, used in the conversion of some obscure, unnecessary, runtime macros for the Objective-C runtime which could probably be removed
- std.typetuple : for the simplistic TypeTuple!() template

I don't expect any of this to be very hard to find an equivalent in Tango. If someone wants to give it a try, great! I suppose I could even help.

But I can't say I'm interested much in maintaining two parralel versions of the bridge right now. Aren't Phobos and Tango merging anyway?

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Michel Fortin wrote:

> I don't expect any of this to be very hard to find an equivalent in Tango. If someone wants to give it a try, great! I suppose I could even help.
> 
> But I can't say I'm interested much in maintaining two parralel versions of the bridge right now. Aren't Phobos and Tango merging anyway?

If it's only a handful of items, you can use conditional compilation like: "version (Tango) { ... } else /* Phobos */ { ... }" instead :

version (Tango)
import tango.io.Stdout;
else // Phobos
import std.stdio;

void main()
{
  version (Tango)
  Stdout ("Hello, World!").newline;
  else // Phobos
  writefln("Hello, World!");
}

Gets really painful, not to mention ugly, with larger diffs though.
wxD is somewhere in the borderline*, but still coping with both...

--anders

* especially "string" has been trouble with Phobos/Tango and 1.0/2.0
but it's starting to settle down to a single "toString()" method now

On 2008-01-15 04:17:13 -0500, Anders F Björklund <afb@algonet.se> said:

> If it's only a handful of items, you can use conditional compilation like: "version (Tango) { ... } else /* Phobos */ { ... }" instead :
> 
> version (Tango)
> import tango.io.Stdout;
> else // Phobos
> import std.stdio;
> 
> void main()
> {
>    version (Tango)
>    Stdout ("Hello, World!").newline;
>    else // Phobos
>    writefln("Hello, World!");
> }
> 
> Gets really painful, not to mention ugly, with larger diffs though.
> wxD is somewhere in the borderline*, but still coping with both...

Well, perhaps it won't be truly two paralel versions in the source code, but what I expect to be bothersome is testing. I'd need to compile everything twice to make sure it work. How do I switch fast between compiling against Tango and Phobos?

What I could do to improve the situation is remove most of the dependencies on the standard library. I could for instane remplace toStringz with (str~\0).ptr, FieldTypeTuple!(T) with typeof(T.tupleof) and so on. There's one thing I can't replace or remove: functions dealing with the garbage collector, those are tied to the D runtime. Everything else I could easily either "inline" manually or get rid of in some way.

But I'm wondering now: who is seriously interested in using the D/Objective-C bridge with Tango?


> * especially "string" has been trouble with Phobos/Tango and 1.0/2.0
> but it's starting to settle down to a single "toString()" method now

Yeah, that'd be another thing to bother about, although the version trick above could handle for that just like everything else.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Michel Fortin escribió:
> On 2008-01-15 04:17:13 -0500, Anders F Björklund <afb@algonet.se> said:
> 
>> If it's only a handful of items, you can use conditional compilation like: "version (Tango) { ... } else /* Phobos */ { ... }" instead :
>>
>> version (Tango)
>> import tango.io.Stdout;
>> else // Phobos
>> import std.stdio;
>>
>> void main()
>> {
>>    version (Tango)
>>    Stdout ("Hello, World!").newline;
>>    else // Phobos
>>    writefln("Hello, World!");
>> }
>>
>> Gets really painful, not to mention ugly, with larger diffs though.
>> wxD is somewhere in the borderline*, but still coping with both...
> 
> Well, perhaps it won't be truly two paralel versions in the source code, but what I expect to be bothersome is testing. I'd need to compile everything twice to make sure it work. How do I switch fast between compiling against Tango and Phobos?
> 

As I've said many times, I use Tango from the SVN repos. In trunk/lib, there's a script install-gdc.sh. Call it once to install Tango, call it again with --uninstall to restore Phobos. That fast, that easy.

> What I could do to improve the situation is remove most of the dependencies on the standard library. I could for instane remplace toStringz with (str~\0).ptr, FieldTypeTuple!(T) with typeof(T.tupleof) and so on. There's one thing I can't replace or remove: functions dealing with the garbage collector, those are tied to the D runtime. Everything else I could easily either "inline" manually or get rid of in some way.
> 

You could also take the Derelict route. It has a layer between the library and either Tango or Phobos, so the runtime dependency remains there.

Tango also provides access to the GC.

> But I'm wondering now: who is seriously interested in using the D/Objective-C bridge with Tango?
> 

Do you mean seriously as in doing a major project or similar? In that case, not me. However, I'm a Mac user, so I'm interested in this library, but I prefer Tango to Phobos.

> 
>> * especially "string" has been trouble with Phobos/Tango and 1.0/2.0
>> but it's starting to settle down to a single "toString()" method now
> 
> Yeah, that'd be another thing to bother about, although the version trick above could handle for that just like everything else.
> 


-- 
Carlos Santander Bernal

Michel Fortin wrote:
> Well, perhaps it won't be truly two paralel versions in the source code, but what I expect to be bothersome is testing. I'd need to compile everything twice to make sure it work. How do I switch fast between compiling against Tango and Phobos?

Probably with dsss, it has a switch called "dc", and you add a profile do the "dc" switch like this for example: "rebuild something dc=gdc-posix-tango" and "dc=gdc-posix". The profiles are files located in the dsss/etc/rebuild folder (at least on windows). I don't know how you do this under mac the best way but under windows you can have one lib folder for tango, one for phobos and one common for both and then have two sc.ini files that looks slightly different. I don't know if you can do anything similar under mac.

> But I'm wondering now: who is seriously interested in using the D/Objective-C bridge with Tango?

I would be interested in using the D/Objective-C bridge with Tango, not for the moment but definitely later.

Michel Fortin wrote:

> Well, perhaps it won't be truly two paralel versions in the source
> code, but what I expect to be bothersome is testing. I'd need to
> compile everything twice to make sure it work. How do I switch fast
> between compiling against Tango and Phobos?

Install two versions of GDC, one with Phobos and one with Tango...
I usually keep the first one in /usr and the second one in /opt/gdc
(where the /usr would be from gdcmac dmg, and the /opt from dgcc tbz)

More on http://dsource.org/projects/tango/wiki/PhobosTangoCooperation

But recent testing shows that they are inching closer to eachother,
so that eventually it will be possible to change with the flick of
a compiler version parameter (i.e. -fversion=Tango -fversion=Posix)

Not sure whether -nophoboslib will be needed or not, when complete ?

--anders