On 2014-12-29 22:39, Christian Schneider wrote:
I just report another finding here. It's about properties and NSStrings.
So far, it was possible to set the strings of an alert like this (source
copied from the Chocolat example):
auto alert = new NSAlert ;
alert.messageText = Want Chocolate? ;
On Friday, 26 December 2014 at 17:47:29 UTC, Jacob Carlborg wrote:
On 2014-12-25 14:12, Christian Schneider wrote:
Just for my information: Why is it no longer possible to have
multiple d
methods (or overloaded constructors) to map to the same
Objective-C
implementation?
I though it was
It's the destructor in NSObject that causes the problem. I'll
take a look. Remove that and your example will work, after you
import the missing foundation.runtime in app.
Once again, thank you very much for your help! It works now with
the new @selector style, and I would had the biggest
On 2014-12-25 14:12, Christian Schneider wrote:
Just for my information: Why is it no longer possible to have multiple d
methods (or overloaded constructors) to map to the same Objective-C
implementation?
I though it was quite nice to have overloaded d constructors for the
various init..
On 2014-12-25 15:30, Christian Schneider wrote:
Was just upgrading everything to the latest Github, dmd, druntime (the
d-objc branch). It does not seem to be able to link into the AppKit and
Foundation anymore. dmd fails silently with error code -11
I uploaded a very stripped down project
Just for my information: Why is it no longer possible to have
multiple d methods (or overloaded constructors) to map to the
same Objective-C implementation?
I though it was quite nice to have overloaded d constructors for
the various init.. methods.
Was just upgrading everything to the latest Github, dmd, druntime
(the d-objc branch). It does not seem to be able to link into the
AppKit and Foundation anymore. dmd fails silently with error code
-11
I uploaded a very stripped down project (containing everything)
that you might want to
awesome, thank you very much!
On 2014-12-17 20:51, Christian Schneider wrote:
OMG, what did you do? all my beautiful appkit and foundation header
files are destroyed! do you plan any other such attacks?
Hopefully no :)
lol, i must admit, i was a bit shocked about this sudden surprise. what
is the main motivation? i
The reason for the change is that the old syntax, [foo:bar:],
required language changes wheres the new syntax,
@selector(foo:bar:), doesn't. When D/Objective-C was
initially created D didn't support UDA's, that's why a new
syntax was invented. If D had supported UDA's back then, that
would
This should be fixed now in my forks [1] [2]. Note, I've also
replaced the selector syntax, [foo], with a compiler recognized
UDA, @selector(foo).
[1] https://github.com/jacob-carlborg/dmd/tree/d-objc
[2] https://github.com/jacob-carlborg/druntime/tree/d-objc
OMG, what did you do? all my
On 2014-11-04 10:07, Christian Schneider wrote:
Ok, some more info:
I changed the mapping in tableview.d to:
void setDoubleAction(void __selector(ObjcObject))
[setDoubleAction:] ;
This should be the way to do it. Now in the implementation of the
action:
void
Why not use a constructor and let the compiler manage the
boilerplate?
this(NSRect frame) [initWithFrame:] {
//my stuff
super(frame);
}
This should emit the same code as the function above (but I
haven't tested). And then you can write:
On 2014-11-18 09:07:10 +, Christian Schneider said:
This is what I came up with so far:
override KeyboardView initWithFrame(NSRect frame) [initWithFrame:] {
//my stuff
return cast(KeyboardView) super.initWithFrame(frame) ;
}
Why not use a constructor and let the compiler manage
I forgot to ask, do you have a small test case showing this
problem? Without windows or any other fancy stuff.
Just setup a small temporary repository for this:
https://github.com/DiveFramework/FixingNSRect
Without an OSX application with windows et al, it won't show you
the send bug
Do you get a compile time error or runtime error?
Compiling using dmd...
source/document.d(79): Error: function
foundation.array.NSArray.arrayWithObjects (ObjcObject object,
...) is not callable using argument types (Class, Class,
typeof(null))
compile time.
hmm, a class object is of
I'm wondering how I should deal with overriding designated
initailizers. I really have no clue about the part self =
[super...]. KeyboardView is a subclass of NSView.
@implementation KeyboardView
- (id)initWithFrame:(NSRect)frame {
self = [super initWithFrame:frame];
if (self) {
Speaking of drawing, I have a very serious problem wit NSView. I
cannot call frame() nor bounds() on instances or subclasses and
get a valid NSRect. (same goes for NSWindow frame()).
I had similar problems when working with NSAttributedString and
NSRange, because NSRange from Chocolat was
On 2014-11-18 09:46, Christian Schneider wrote:
Compiling using dmd...
source/document.d(79): Error: function
foundation.array.NSArray.arrayWithObjects (ObjcObject object, ...) is
not callable using argument types (Class, Class, typeof(null))
compile time.
hmm, a class object is of course not
On 2014-11-18 10:07, Christian Schneider wrote:
I'm wondering how I should deal with overriding designated
initailizers. I really have no clue about the part self = [super...].
KeyboardView is a subclass of NSView.
@implementation KeyboardView
- (id)initWithFrame:(NSRect)frame {
self =
On 2014-11-18 13:47, Christian Schneider wrote:
Speaking of drawing, I have a very serious problem wit NSView. I cannot
call frame() nor bounds() on instances or subclasses and get a valid
NSRect. (same goes for NSWindow frame()).
I had similar problems when working with NSAttributedString and
Compiling using dmd...
source/document.d(79): Error: function
foundation.array.NSArray.arrayWithObjects (ObjcObject object,
...) is
not callable using argument types (Class, Class, typeof(null))
Hmm, I don't know. Can you use a cast to get around the
problem? Perhaps use a variadic template
Could it be this issue [1]? Can you please see if you can
reproduce it using just plain C.
https://issues.dlang.org/show_bug.cgi?id=5570
Uh, oh, that bug looks like a major annoyance in 64bit! I made a
few checks, all appkit methods returning a NSRect currently
produce a runtime segfault.
Can't you just call super in the beginning of the method and
then call return this at the end. Something like this:
override KeyboardView initWithFrame(NSRect frame)
[initWithFrame:] {
super.initWithFrame(frame);
// my stuff
return this;
}
Ups, sorry, my bad! I was trying this
On 2014-11-18 21:46, Christian Schneider wrote:
Yes, of course, and this is really not an issue! And this convenience
function can be rewritten in a few lines of code, if really necessary.
Good, I just want to make sure you can continue. Than we can figure out
the minor issues later. Anyway,
On 2014-11-18 21:54, Christian Schneider wrote:
Uh, oh, that bug looks like a major annoyance in 64bit! I made a few
checks, all appkit methods returning a NSRect currently produce a
runtime segfault. But this does not apply to NSSize, nor NSPoint,
functions returning either NSSize or NSPoint
On 2014-11-16 12:16, Christian Schneider wrote:
I am just stumbling over adding class objects to an array:
I get an error when trying to add class objects to an NSArray because
e.g. NSString.class does not conform to ObjcObject. There is some
functions in the API that require arrays of class
I am just stumbling over adding class objects to an array:
I get an error when trying to add class objects to an NSArray
because e.g. NSString.class does not conform to ObjcObject. There
is some functions in the API that require arrays of class
objects, e.g. in NSPasteboard:
NSPasteboard pb
I guess you have to live using NSObject for now, until I fixed
that. But in practice NSObject is the only root class. So far
I've seen one other class, NSProxy, that doesn't inherit from
NSObject.
Ok, I had a quick look at this issue. It is implemented but
it's not working. There is a test
Also when I tried to declare / use extern strings like from
NSApplication.h:
APPKIT_EXTERN NSString *NSApplicationDidHideNotification;
I found no way to get this working. Is this a limitation of
the current
64 bit port?
I think that should work. How did you declare it? It should be
On 2014-11-07 13:12, Christian Schneider wrote:
Jacob, thank you very much for your reply and explanations!
I get EXC_BAD_ACCESS (SIGSEGV) for both NSString and void * if I use the
declaration you suggested.
What exactly are you doing with the string when you get the
EXC_BAD_ACCESS? Also,
I get EXC_BAD_ACCESS (SIGSEGV) for both NSString and void * if
I use the
declaration you suggested.
What exactly are you doing with the string when you get the
EXC_BAD_ACCESS? Also, can you reproduce the issue in an program
just printing this variable with NSLog?
I get the SIGSEGV when i
On 2014-11-07 15:23, Christian Schneider wrote:
I get the SIGSEGV when i try to NSLog this string constant. I was not
looking any further, because if it fails to NSLog, i can't do anything
with it ;)
Now I know what the problem is. In D, module variables are by default in
TLS (thread local
Now I know what the problem is. In D, module variables are by
default in TLS (thread local storage). To make it refer to a
global C variable, use __gshared:
extern (C) extern __gshared NSString
NSApplicationDidHideNotification;
Sorry, I completely forgot about that.
Ha, awesome! It
On 2014-11-07 17:05, Christian Schneider wrote:
Ha, awesome! It works! I'll add this to a wiki page in the DiveFramework
github repos.
Thanks again!
No problem :). This isn't mention in the DIP since this has nothing to
do with Objective-C, it's rather plain C. This is documented here [1].
Oh, just found out, it seems that currently the extern C
declarations don't work. This comes from the original Chocolat
range.d
extern (C) {
nothrow:
NSRange NSUnionRange(NSRange range1, NSRange range2) ;
NSRange NSIntersectionRange(NSRange range1, NSRange
On 2014-11-06 17:06, Christian Schneider wrote:
Oh, just found out, it seems that currently the extern C declarations
don't work. This comes from the original Chocolat range.d
extern (C) {
nothrow:
NSRange NSUnionRange(NSRange range1, NSRange range2) ;
NSRange
What happens if you declare doubleClickAction like this:
void doubleClickAction(NSTableView sender) { ... }
That will probably require a cast when passing the selector to
setDoubleAction.
Hi Jacob
This just delegates the problem to another place. The
target/action paradigm in Cocoa
I would expect to be using an ObjcObject instead of an
NSObject here,
but this does not compile. The signature of the target action
seems to
be irrelevant, it may have no or more parameters. I guess this
is just
ok and the expected behavior.
Hmm, that sounds strange. What exact errors do
Ok, some more info:
I changed the mapping in tableview.d to:
void setDoubleAction(void __selector(ObjcObject))
[setDoubleAction:] ;
This should be the way to do it. Now in the implementation of the
action:
void doubleClickAction(ObjcObject sender) {
NSLog(double click action) ;
what is funky in this context (see above): even when using
ObjcObject in both the mapping and the action method, the test
if (sender is demoTableView) {
//
}
does not fail in the action, only a cast to a NSTableView object
fails. Of course, in this setting it's not really a problem, I
can
On 2014-11-04 09:07:08 +, Christian Schneider
schnei...@gerzonic.net said:
Ok, some more info:
I changed the mapping in tableview.d to:
void setDoubleAction(void __selector(ObjcObject))
[setDoubleAction:] ;
That's indeed the best way to do it.
This should be the way to do it. Now in
On 2014-11-01 10:47:54 +, Jacob Carlborg d...@me.com said:
On 2014-11-01 01:58, Michel Fortin wrote:
That said, there are other parts of D/Objective-C that could pose
difficulties to existing languages tools, some syntactic (__selector, or
this.class to get the metaclass)
this.class
On 2014-11-04 13:29, Christian Schneider wrote:
what is funky in this context (see above): even when using
ObjcObject in both the mapping and the action method, the test
if (sender is demoTableView) {
//
}
does not fail in the action
That will just compare the address of the objects.
On 2014-11-04 23:46, Michel Fortin wrote:
Once this is merged in DMD, __selector could be documented to be
syntactically identical to a delegate (although semantically different)
and it could be made syntactically valid for regular D code compiled
with no Objective-C support (although it'd
There is no test for interface-to-class casts in the
D/Objective-C test suite, which means you're likely the first
person to try that. It's probably just an oversight in the
compiler code.
Hey Michel, thanks very much for this explanation! That's
actually good news. It certainly will be
I have a question regarding selectors. I wanted to set a
double-click action in the tableview example. Currently i get the
selector like this:
objc.runtime.SEL doubleAction =
cast(objc.runtime.SEL)AppDelegate.doubleClickAction ;
demoTableView.setDoubleAction(doubleAction) ;
Is
On 2014-11-03 09:51, Christian Schneider wrote:
I have a question regarding selectors. I wanted to set a double-click
action in the tableview example. Currently i get the selector like this:
objc.runtime.SEL doubleAction =
cast(objc.runtime.SEL)AppDelegate.doubleClickAction ;
On 2014-11-01 01:54, Michel Fortin wrote:
I can't remember if this is an oversight or just something that I hadn't
got to yet. In my mind this was already done.
I did a grep for dealloc and couldn't find anything related.
Anyway, the answer is *yes*: the destructor should be mapped to the
On 2014-11-01 01:58, Michel Fortin wrote:
That said, there are other parts of D/Objective-C that could pose
difficulties to existing languages tools, some syntactic (__selector, or
this.class to get the metaclass)
this.class could perhaps be called this.classof, at least that's
valid syntax.
On 2014-10-30 07:13:08 +, Jacob Carlborg d...@me.com said:
I had a look at your fix. I see that you added a call to release in
the destructor. Just for the record, there's no guarantee that the
destructor of a GC allocated object gets run, at all.
D/Objective-C never allocates
On 2014-10-30 09:16:34 +, Martin Nowak c...@dawg.eu said:
On Tuesday, 11 March 2014 at 18:23:08 UTC, Jacob Carlborg wrote:
A DIP is available here [1] and the latest implementation is available
here [2].
[1] http://wiki.dlang.org/DIP43
Instead of adding the selector syntaxsyntax you
On 2014-10-29 22:51, Christian Schneider wrote:
Btw, fixed the example, thanks for giving me the right clues. Of course,
it was just the manual memory management à la Objective-C that was
missing! I am really lucky that I spent already days, maybe weeks
debugging retain / release / autorelease
On Tuesday, 11 March 2014 at 18:23:08 UTC, Jacob Carlborg wrote:
A DIP is available here [1] and the latest implementation is
available here [2].
[1] http://wiki.dlang.org/DIP43
Instead of adding the selector syntaxsyntax you could reuse
pragma mangle.
extern (Objective-C)
class
On Thursday, 30 October 2014 at 07:13:09 UTC, Jacob Carlborg
wrote:
On 2014-10-29 22:51, Christian Schneider wrote:
Btw, fixed the example, thanks for giving me the right clues.
Of course,
it was just the manual memory management à la Objective-C that
was
missing! I am really lucky that I
I had a look at your fix. I see that you added a call to
release in the destructor. Just for the record, there's no
guarantee that the destructor of a GC allocated object gets
run, at all.
Omg, how embarrassing ;) of course I need to put it in dealloc so
that it will work with NSMutableArray
On 2014-10-30 16:28, Christian Schneider wrote:
So far, I was not even considering a D library that would be used
through Objective-C code, but yeah, that's a good point as well.
Isn't that what's usually happens when using something like an app
delegate. It will be instantiated by the
On 2014-10-30 10:23, John Colvin wrote:
Slightly derailing the conversation, but I see this all the time...
Isn't the situation actually this:
GC allocated objects are not guaranteed to be de-allocated before
program termination.
If a GC allocated object is deallocated, its destructor *is*
On 2014-10-30 10:16, Martin Nowak wrote:
Instead of adding the selector syntaxsyntax you could reuse pragma mangle.
extern (Objective-C)
class NSComboBox : NSTextField
{
private void* _dataSource;
pragma(mangle, objcMangle!(NSComboBox, insertItemWithObjectValue,
atIndex)
void
I tried running your code and could observe the behavior.
Although I have not been able to figure you why it behaves like
this. In general there are a couple of things to think of and
watch out for when interfacing between D and Objective-C :
* The D compiler does not support any form of ARC,
On 2014-10-29 16:09, Christian Schneider wrote:
DStep was not very helpful when I tried it, it wanted to find all the
referenced includes, which of course can be quite complicated when
trying to get foundation and appkit headers processed.
How do you mean? That it can't find stdarg.h and
In the future I hope to make it possible to use pass a
framework to DStep and it will create bindings for the whole
framework.
That would be so cool!
Btw, fixed the example, thanks for giving me the right clues. Of
course, it was just the manual memory management à la Objective-C
that was
Can somebody with a greater d-objc knowledge have a look at this
example project and tell this naive D-noob what he is missing?
https://github.com/DiveFramework/DiveFramework/tree/master/Examples/Tableview
I am pretty sure that it has something to do with memory
management and ARC. First it
Michel Fortin wrote in message news:lfqcs6$2su5$1...@digitalmars.com...
If the compiler is going to be converted to the D language (how is that
progressing?), it'd probably be better to merge before that, otherwise
it'll be a lot of work to port all those changes.
The converter can convert
Jacob Carlborg wrote in message news:lfqf4t$2v1o$1...@digitalmars.com...
I think Daniel has said he as a working Linux compiler. He just need to
create pull requests (and get them merged) for all changes his tool
requires.
The changes to dmd's source are all done(!), it's now time to start
On Thursday, 13 March 2014 at 12:02:24 UTC, Daniel Murphy wrote:
The changes to dmd's source are all done(!), it's now time to
start putting the manually ported stuff into the main repo.
That's great :).
--
/Jacob Carlborg
On Wednesday, 12 March 2014 at 17:53:19 UTC, Andrei Alexandrescu
wrote:
I'll defer to domain experts on this one. Please advise.
Yeah, we need some comments from Walter, Daniel, Kenji and others
of the core DMD developers. Probably good to have comments from
David and Iain as well, to get
Am Thu, 13 Mar 2014 14:20:54 +
schrieb Jacob Carlborg d...@me.com:
On Wednesday, 12 March 2014 at 17:53:19 UTC, Andrei Alexandrescu
wrote:
I'll defer to domain experts on this one. Please advise.
Yeah, we need some comments from Walter, Daniel, Kenji and others
of the core DMD
On 2014-03-13 17:16, Johannes Pfau wrote:
Is it possible to split objc.c into two files, one for backend
interfacing functions (ObjcSymbols) and one for the generic frontend
stuff?
I would guess so. I would need to take a look to see how coupled the
code in objc.c is. Although, most code is
On 2014-03-13 18:13:44 +, Jacob Carlborg d...@me.com said:
On 2014-03-13 17:16, Johannes Pfau wrote:
Is it possible to split objc.c into two files, one for backend
interfacing functions (ObjcSymbols) and one for the generic frontend
stuff?
I would guess so. I would need to take a look
On 11 Mar 2014 23:25, Michel Fortin michel.for...@michelf.ca wrote:
On 2014-03-11 22:43:58 +, John Colvin
john.loughran.col...@gmail.com said:
To what extent will this be portable to ldc/gdc?
The codegen elements in objc.c will need to be changed to bind to the
LLVM/GCC backend.
On Tuesday, 11 March 2014 at 21:48:45 UTC, Asman01 wrote:
It's really awesome. Congratulations! If this DIP is actually
approved will dmd have native integration/support to
Objective-C language just like we can do with C? I'm not a
Obj-C programmer but I like the idea.
Yes.
--
/Jacob
On Tuesday, 11 March 2014 at 23:20:23 UTC, Michel Fortin wrote:
The codegen elements in objc.c will need to be changed to bind
to the LLVM/GCC backend. Shouldn't be too hard, I guess.
Yeah, since Objective-C uses the C calling convention it's mostly
about outputting symbols and data to the
On Wednesday, 12 March 2014 at 01:09:25 UTC, Walter Bright wrote:
I'm glad to see this is building on the great groundwork you've
already done.
Yes, absolutely. Michel has done most of the work, forgot to
mention that. I'm just polishing now.
--
/Jacob Carlborg
On Tuesday, 11 March 2014 at 22:13:07 UTC, Paolo Invernizzi wrote:
Thanks Jacob, great work!
If someone is trying it like me, I don't know the proper way
for doing that, but the compiler must be built with the
DMD_OBJC define turned on.
Yes, D_OBJC. You need the corresponding changes for
On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu
wrote:
Great. Jacob, what's your plan to take this forward? We're very
interested in merging this as part of the official D compiler.
In theory I could create a pull request tonight. It depends on
what state we need the
This is really awesome work. If you combined ARM support with
Objective C support, it would mean you could write iOS programs
in D without much frustration, and that would be a huge step
forward. Objective C has a good runtime, but lacks templates and
CTFE. Using CTFE for an iOS program could
On 3/11/14, Jacob Carlborg d...@me.com wrote:
I just wanted to let everyone know that I have implemented D/Objective-C
for 64bit.
Excellent! One thing that's hard to implement right now in D is drag
drop support on OSX, at least when I tried to do it. The problem is I
need to call ObjC
On 12 March 2014 07:10, Jacob Carlborg d...@me.com wrote:
On Tuesday, 11 March 2014 at 23:20:23 UTC, Michel Fortin wrote:
The codegen elements in objc.c will need to be changed to bind to the
LLVM/GCC backend. Shouldn't be too hard, I guess.
Yeah, since Objective-C uses the C calling
On 2014-03-12 08:06:47 +, w0rp devw...@gmail.com said:
This is really awesome work. If you combined ARM support with Objective
C support, it would mean you could write iOS programs in D without much
frustration, and that would be a huge step forward. Objective C has a
good runtime, but
On 2014-03-12 09:26:56 +, Iain Buclaw ibuc...@gdcproject.org said:
On 12 March 2014 07:10, Jacob Carlborg d...@me.com wrote:
Yeah, since Objective-C uses the C calling convention it's mostly about
outputting symbols and data to the object files.
In what ABI may I ask? Your choices are:
On Tuesday, 11 March 2014 at 18:23:08 UTC, Jacob Carlborg wrote:
I just wanted to let everyone know that I have implemented
D/Objective-C for 64bit. Everything that worked for 32bit
should work, except for exceptions, which are not implemented
yet.
Objective-C on 64bit uses the modern
On Wednesday, 12 March 2014 at 12:14:23 UTC, Michel Fortin wrote:
On 2014-03-12 09:26:56 +, Iain Buclaw
ibuc...@gdcproject.org said:
On 12 March 2014 07:10, Jacob Carlborg d...@me.com wrote:
Yeah, since Objective-C uses the C calling convention it's
mostly about
outputting symbols and
w0rp devw...@gmail.com writes:
This is really awesome work. If you combined ARM support with
Objective C support, it would mean you could write iOS programs
in D without much frustration, and that would be a huge step
forward. Objective C has a good runtime, but lacks templates and
CTFE.
Szymon Gatner noem...@gmail.com writes:
Wow, this is fantastic! This and recent progress on iOS/ARM/LDC
porting make me so happy :)
Yeah, it will be cool to combine this with the LDC iOS work. I haven't
posted progress lately. I got Fibers working on an iPhone 4. I found
that GDC's thread.d
On 3/12/14, 12:15 AM, Jacob Carlborg wrote:
On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote:
Great. Jacob, what's your plan to take this forward? We're very
interested in merging this as part of the official D compiler.
In theory I could create a pull request tonight.
On 12 March 2014 12:14, Michel Fortin michel.for...@michelf.ca wrote:
On 2014-03-12 09:26:56 +, Iain Buclaw ibuc...@gdcproject.org said:
On 12 March 2014 07:10, Jacob Carlborg d...@me.com wrote:
Yeah, since Objective-C uses the C calling convention it's mostly about
outputting symbols
On 2014-03-12 13:14, Michel Fortin wrote:
I made the 32-bit legacy runtime support, Jacob added the 64-bit modern
runtime support.
There's no support at this time for properties declarations in the ABI,
but it doesn't really have much impact. As far as I'm aware, Objective-C
2.0 additions only
Am Wed, 12 Mar 2014 10:53:35 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 3/12/14, 12:15 AM, Jacob Carlborg wrote:
On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu
wrote:
Great. Jacob, what's your plan to take this forward? We're very
interested
On 2014-03-12 20:02, Iain Buclaw wrote:
gobjc supports both, there's two ABI's for the NeXT - which I take to
mean the difference between the difference between 32bit and 64bit.
You previously listed three ABI's. It's the modern runtime for 64bit and
the traditional for 32bit with with
On 2014-03-12 17:53:35 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
On 3/12/14, 12:15 AM, Jacob Carlborg wrote:
On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote:
Great. Jacob, what's your plan to take this forward? We're very
interested in merging
On 12 March 2014 19:29, Jacob Carlborg d...@me.com wrote:
On 2014-03-12 20:02, Iain Buclaw wrote:
gobjc supports both, there's two ABI's for the NeXT - which I take to
mean the difference between the difference between 32bit and 64bit.
You previously listed three ABI's. It's the modern
On 2014-03-12 19:02:10 +, Iain Buclaw ibuc...@gdcproject.org said:
From my POV, I wouldn't want to support the ABI of a language that GCC
itself doesn't support. So code compiled by GNU ObjC should be
compatible with extern(ObjC) code generated by GDC - even if it isn't
compatible with
On 12 March 2014 19:36, Michel Fortin michel.for...@michelf.ca wrote:
On 2014-03-12 19:02:10 +, Iain Buclaw ibuc...@gdcproject.org said:
From my POV, I wouldn't want to support the ABI of a language that GCC
itself doesn't support. So code compiled by GNU ObjC should be
compatible with
On 12 March 2014 19:34, Michel Fortin michel.for...@michelf.ca wrote:
On 2014-03-12 17:53:35 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
On 3/12/14, 12:15 AM, Jacob Carlborg wrote:
On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote:
Great. Jacob,
On 2014-03-12 20:34, Michel Fortin wrote:
If the compiler is going to be converted to the D language (how is that
progressing?), it'd probably be better to merge before that, otherwise
it'll be a lot of work to port all those changes.
I think Daniel has said he as a working Linux compiler. He
On 2014-03-12 20:37, Iain Buclaw wrote:
Sorry, some context. The two 32bit ABIs are part of the same source,
I'd take them to be identical, with the exception that the second
option supports features that are on-by-default in the 64bit ABI.
I see.
As in, if I were to support NeXT. I'd
On 3/11/14, 11:23 AM, Jacob Carlborg wrote:
[1] http://wiki.dlang.org/DIP43
[2] https://github.com/jacob-carlborg/dmd/tree/d-objc
Wow, this is fantastic. Congratulations!
Upon a quick scan, the DIP seems tasteful and well put together. Let's
see how to merge this into dmd!
Andrei
On Tuesday, 11 March 2014 at 18:23:08 UTC, Jacob Carlborg wrote:
I just wanted to let everyone know that I have implemented
D/Objective-C for 64bit. Everything that worked for 32bit
should work, except for exceptions, which are not implemented
yet.
Objective-C on 64bit uses the modern
On Tuesday, 11 March 2014 at 18:23:08 UTC, Jacob Carlborg wrote:
I just wanted to let everyone know that I have implemented
D/Objective-C for 64bit. Everything that worked for 32bit
should work, except for exceptions, which are not implemented
yet.
snip
A DIP is available here [1] and
1 - 100 of 107 matches
Mail list logo
