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?" ;
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 p
On 2014-12-29 20:01, Christian Schneider wrote:
previously it was possible to have a few D methods "point" to the same
Objective-C method like this:
NSView initWithFrame(NSRect frameRect) @selector("initWithFrame:") ;
this(NSRect frameRect) @selector("initWithFrame:") ;
Now with th
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 quite
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 (conta
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.. 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 have
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.
awesome, thank you very much!
On 2014-12-18 23:31, Christian Schneider wrote:
Regex is one of my weaknesses. If you don't mind sharing yours (and if
you have them still lying around) please send to schneider at
gerzonic.net, this would be greatly appreciated, and would make my life
a bit easier.
These are two simple regula
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
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 thoug
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 doubleClickAction(ObjcObject
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 repor
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 wo
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 wo
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,
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 t
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. Bu
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 t
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 N
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 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
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 stil
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) {
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 cou
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 obj
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
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].
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 works
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 st
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 tr
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, ca
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
declar
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 NSIntersection
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 range
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 p
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 goo
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 remai
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-01 10:47:54 +, Jacob Carlborg 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" could perha
On 2014-11-04 09:07:08 +, "Christian Schneider"
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 the implementation o
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 wo
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") ;
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 yo
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 ;
demoTab
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 thi
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 sy
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-10-30 09:16:34 +, "Martin Nowak" 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 could reuse p
On 2014-10-30 07:13:08 +, Jacob Carlborg 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 Objective-C objects
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")
voi
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 framew
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* gua
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 NSMutableArra
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 spen
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 NSComboBox
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 o
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
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 other
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-27 19:03, Christian Schneider wrote:
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 t
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 al
On 2014-03-13 18:13:44 +, Jacob Carlborg 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 to see how co
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 f
Am Thu, 13 Mar 2014 14:20:54 +
schrieb "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 devel
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 a
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
"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
"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
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 supp
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 12 March 2014 19:34, Michel Fortin wrote:
> On 2014-03-12 17:53:35 +, Andrei Alexandrescu
> 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? W
On 12 March 2014 19:36, Michel Fortin wrote:
> On 2014-03-12 19:02:10 +, Iain Buclaw 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 - eve
On 2014-03-12 19:02:10 +, Iain Buclaw 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 Clang ObjC. But then, I'd
On 12 March 2014 19:29, Jacob Carlborg 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 runtime
On 2014-03-12 17:53:35 +, Andrei Alexandrescu
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 this as part of the official D co
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 proper
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 :
> 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
On 12 March 2014 12:14, Michel Fortin wrote:
> On 2014-03-12 09:26:56 +, Iain Buclaw said:
>
>> On 12 March 2014 07:10, Jacob Carlborg wrote:
>>>
>>> Yeah, since Objective-C uses the C calling convention it's mostly about
>>> outputting symbols and data to the object files.
>>
>>
>> In what
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. I
"Szymon Gatner" 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 already had A
"w0rp" 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. Using CTFE
On Wednesday, 12 March 2014 at 12:14:23 UTC, Michel Fortin wrote:
On 2014-03-12 09:26:56 +, Iain Buclaw
said:
On 12 March 2014 07:10, Jacob Carlborg wrote:
Yeah, since Objective-C uses the C calling convention it's
mostly about
outputting symbols and data to the object files.
In what
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 runtime
On 2014-03-12 09:26:56 +, Iain Buclaw said:
On 12 March 2014 07:10, Jacob Carlborg 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:
- Traditional (32bit) ABI without
On 2014-03-12 08:06:47 +, "w0rp" 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 lacks templates an
On 12 March 2014 07:10, Jacob Carlborg 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 conventio
On 3/11/14, Jacob Carlborg 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 functions or pro
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 b
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 dr
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 ob
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 languag
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 Carl
1 - 100 of 111 matches
Mail list logo