On 2013-11-15 13:41, Michel Fortin wrote:

> That was my idea too initially: put it in the reference implementation
> and other implementations will follow, and it'll become part of the
> language. That'd be great. But it's hard when you have to fix the
> backend to emit what you need. I have some fears about that for the
> exception handling stuff in the modern runtime, perhaps they're
> unjustified.

Yeah, that's the biggest advantage of doing it in LDC. They already have the correct back end parts in place.

> I wonder if Walter will approve the merge, despite his stated intention
> to do so eventually. The surface area of that patch is huge, it'll take
> him many hours for an initial review, and probably several iterations of
> that review process will be required to get it to pass. I remember my
> smaller-scale pull request #3 that never got reviewed... but maybe
> (hopefully?) things have changed since then.

Hopefully things are better now. There seems to be more people now that have a greater knowledge of DMD.

> Haha. No. I skim by topic of interest. But I generally play the passive
> observer. Replying generally brings other replies, begging for more
> followup. I have a couple of replies that were written but which I never
> posted because I anticipated writing the eventual followups wouldn't be
> worth my time. It doesn't help that I tend to spend too much time
> carefully writing anything too, proofreading and weighing every word.

Understandable. Like my post about AST macros. It's always a hot topic.

> But if you're talking about one of my projects there's more chance I'll
> pop in the conversation.

-- 
/Jacob Carlborg

On 2013-11-15 12:53:18 +0000, Jacob Carlborg <doob@me.com> said:

> On 2013-11-15 13:42, Michel Fortin wrote:
> 
>> Honestly, what I'd do is implement ARC for Objective-C types in the
>> compiler without waiting for Walter to decide on anything. There's
>> almost nothing to decide when it comes to how D/Objective-C does it: you
>> have to do it the same way as clang. And you can't reuse anything Walter
>> will come with without much tinkering because Objective-C ARC has to
>> manage autoreleased objects. On the other hand once you have implemented
>> Objective-C ARC it should be easy to retrofit the mechanics of it to
>> other parts of D.
> 
> The question is if this is something that Walter would accept to be included.

You mean if Walter would accept D/Objective-C without ARC? No idea. Ask him, or submit a pull request just to gauge the reaction.

People have been manually managing memory with retain/release/autorelease for more than a decade and it worked pretty well, much better than any other manual reference counting scheme out there. One problem with introducing ARC later is that you'll need a compiler flag to disable or enable ARC to support both legacy and new code.

Personally, I'd be more bothered by the lack of 64-bit than the lack of ARC, but that might be just because I'm good with retain/release/autorelease.

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

On 2013-11-15 14:38, Michel Fortin wrote:

> You mean if Walter would accept D/Objective-C without ARC? No idea. Ask
> him, or submit a pull request just to gauge the reaction.

No, I was referring to just implementing ARC like it's done in Objective-C.

> People have been manually managing memory with
> retain/release/autorelease for more than a decade and it worked pretty
> well, much better than any other manual reference counting scheme out
> there. One problem with introducing ARC later is that you'll need a
> compiler flag to disable or enable ARC to support both legacy and new code.

That's true.

> Personally, I'd be more bothered by the lack of 64-bit than the lack of
> ARC, but that might be just because I'm good with
> retain/release/autorelease.

Both are important. Although, I personally don't have a need for 64bit, but it's nice to have the modern runtime.

-- 
/Jacob Carlborg

On 2013-11-15 14:02:20 +0000, Jacob Carlborg <doob@me.com> said:

> On 2013-11-15 14:38, Michel Fortin wrote:
> 
>> You mean if Walter would accept D/Objective-C without ARC? No idea. Ask
>> him, or submit a pull request just to gauge the reaction.
> 
> No, I was referring to just implementing ARC like it's done in Objective-C.

I honestly don't think it can work much differently. You call retain and release at the right places. Extending it to other D types is just a matter of calling a different functions depending on the type. Objective-C has a couple of special cases for pointers to autoreleased objects, but that's just a couple more rules to add, and those should be kept specific to Objective-C types.

Weak pointers are a more difficult topic, but a separate one I'd say.

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

On Friday, 15 November 2013 at 12:07:19 UTC, Martin Nowak wrote:
> On Friday, 15 November 2013 at 09:20:18 UTC, Joakim wrote:
>> For one, dmd not having an ARM backend doesn't impact me since I'm targeting Android/x86 for now, :) as stated earlier.
>
> Interesting, then you'll mostly focus on druntime and glibc vs. bionic issues.
> The linux/ELF support of dmd should mostly work.

Yes, I thought that would be easier, to split the effort into two parts.  First, get D working on Android/x86, then, linux/ARM.  Some fine day, we combine the two into Android/ARM. :)

On Friday, 15 November 2013 at 12:18:20 UTC, Kai Nacke wrote:
> Hi Joakim!
>
> Yes, there is a some support, but not too much. The existence of the TARGET_* macros means that you can't have one compiler with 2 or more platform targets.

I think what I'll try initially is to hack the linux target on dmd to produce an Android/ELF/x86 executable, by tying into the Android NDK and linker.  That might be the shortest path to something that works.

> But there should be no real problem to create a dmd executable on Linux/ARM producing object files for Windows/x86. (Well - no problem except for the real data type. :-) ) But who needs that kind of cross-compiling?

Maybe not linux/ARM, but if D ever takes off, I could see it being convenient someday to cross-compile Windows/x64 executables on linux/x64 servers, perhaps by tying into Wine. I have compiled a small Windows utility using dmd under Wine on a FreeBSD host before: it worked. :) You wouldn't need to license Windows for a bunch of build servers and could cut costs that way.  Obviously not a concern today, but we should get cross-compiling working as much as possible and cross-compiling to Android might be a good first step.  Hell, by then, linux/ARM might be prevalent in the data center. ;)

> To be useful for producing ARM binaries, you need an ARM backend. This is already available for LDC and GDC. IMHO it is easier to pick one of those compilers and think about and create a cross-compiling environment instead of starting by zero. (For LDC, this is issue #490: https://github.com/ldc-developers/ldc/issues/490)

I'm only focusing on Android/x86 for now: why does everyone keep bringing up ARM?  It's almost as though Android/x86 gets translated into Android/ARM in their head. ;) Perhaps it is easier to cross-compile with ldc/gdc, or perhaps the overall port will be harder because I have to then dive into those larger llvm/gcc codebases, whereas the dmd backend looks simpler to me, at least so far.  I'll give it a whirl with dmd first and then move to ldc if I get stuck.

Thanks for the advice, I may end up following it.

On 15 November 2013 18:40, Joakim <joakim@airpost.net> wrote:

> On Friday, 15 November 2013 at 12:07:19 UTC, Martin Nowak wrote:
>
>> On Friday, 15 November 2013 at 09:20:18 UTC, Joakim wrote:
>>
>>> For one, dmd not having an ARM backend doesn't impact me since I'm targeting Android/x86 for now, :) as stated earlier.
>>>
>>
>> Interesting, then you'll mostly focus on druntime and glibc vs. bionic
>> issues.
>> The linux/ELF support of dmd should mostly work.
>>
>
> Yes, I thought that would be easier, to split the effort into two parts.
>  First, get D working on Android/x86, then, linux/ARM.  Some fine day, we
> combine the two into Android/ARM. :)
>
>
GNU/Linux on ARM will come first... it's now only a matter of time. ;)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Am Fri, 15 Nov 2013 09:24:53 +0100
schrieb "Joakim" <joakim@airpost.net>:

> On Friday, 15 November 2013 at 07:22:07 UTC, Paulo Pinto wrote:
> > On Friday, 15 November 2013 at 06:18:00 UTC, Joakim wrote:
> >> As Kai says, has anyone worked on getting D running on Android before?  I've been thinking about attempting an Android port for years.  I thought I'd spin up some x86 VMs this weekend and take a crack at getting D working on Android/x86 (http://www.android-x86.org/) as a first step.  If anyone has started on this already, I could chip in on their branch.
> >
> > Yes, have a look at an initial port of GDC to Android
> >
> > https://bitbucket.org/goshawk/gdc/wiki/GDC%20on%20Android
> 
> Thanks for the link.  It looks like Johannes Pfau took a stab at getting some minimal Android support into gdc a couple years back, with the handful of small patches listed here:
> 
> https://bitbucket.org/jpf/gdc/branch/android
> 
> Anyone get any farther than that?
> 
> Would it make sense to use dmd for linux/x86 to cross-compile to Android/x86 or is this a job for ldc/gdc only?

There are 3 main points which need to be addressed for a solid Android port:

* Druntime must be ported to bionic. Not difficult, but annoying as
  bionic is a mixture between bsd and posix code, so you'll have to
  edit many version statements. All compilers will benefit from that.
* You need to implement TLS support. Last time I checked there bionic
  didn't support native TLS and gcc's emulated TLS   doesn't work with
  the D GC.
* The main program in Android should always be java code, native code
  loaded as shared libraries. This is implemented in DMD now, but not
  in GDC. (And IIRC not in LDC either?)

On Friday, 15 November 2013 at 18:44:20 UTC, Iain Buclaw wrote:
> On 15 November 2013 18:40, Joakim <joakim@airpost.net> wrote:
>> Yes, I thought that would be easier, to split the effort into two parts.
>>  First, get D working on Android/x86, then, linux/ARM.  Some fine day, we
>> combine the two into Android/ARM. :)
>>
> GNU/Linux on ARM will come first... it's now only a matter of time. ;)

Everything is "only a matter of time." ;) The order is not important; it'd be great if linux/ARM is done first, though I hope gdc isn't the only one that does it.

On Friday, 15 November 2013 at 19:09:24 UTC, Johannes Pfau wrote:
> There are 3 main points which need to be addressed for a solid Android
> port:
>
> * Druntime must be ported to bionic. Not difficult, but annoying as
>   bionic is a mixture between bsd and posix code, so you'll have to
>   edit many version statements. All compilers will benefit from that.
Yep, this is the part I'm taking a stab at.

> * You need to implement TLS support. Last time I checked there bionic
>   didn't support native TLS and gcc's emulated TLS   doesn't work with
>   the D GC.
I think there's TLS support in bionic now, but not with the __thread keyword.  I'll look into it more as I go.

> * The main program in Android should always be java code, native code
>   loaded as shared libraries. This is implemented in DMD now, but not
>   in GDC. (And IIRC not in LDC either?)
I just want to get it working as a pure native compilation option for now.  Perhaps someone else will tie D into JNI and get it working with Dalvik, I'm not interested in that.

Thanks for the info.

On 15 November 2013 21:14, Joakim <joakim@airpost.net> wrote:

> On Friday, 15 November 2013 at 18:44:20 UTC, Iain Buclaw wrote:
>
>> On 15 November 2013 18:40, Joakim <joakim@airpost.net> wrote:
>>
>>> Yes, I thought that would be easier, to split the effort into two parts.
>>>  First, get D working on Android/x86, then, linux/ARM.  Some fine day, we
>>> combine the two into Android/ARM. :)
>>>
>>>  GNU/Linux on ARM will come first... it's now only a matter of time. ;)
>>
>
> Everything is "only a matter of time." ;) The order is not important; it'd be great if linux/ARM is done first, though I hope gdc isn't the only one that does it.
>
>
> On Friday, 15 November 2013 at 19:09:24 UTC, Johannes Pfau wrote:
>
>> There are 3 main points which need to be addressed for a solid Android port:
>>
>> * Druntime must be ported to bionic. Not difficult, but annoying as
>>   bionic is a mixture between bsd and posix code, so you'll have to
>>   edit many version statements. All compilers will benefit from that.
>>
> Yep, this is the part I'm taking a stab at.
>
>
>  * You need to implement TLS support. Last time I checked there bionic
>>   didn't support native TLS and gcc's emulated TLS   doesn't work with
>>   the D GC.
>>
> I think there's TLS support in bionic now, but not with the __thread keyword.  I'll look into it more as I go.
>
>
>  * The main program in Android should always be java code, native code
>>   loaded as shared libraries. This is implemented in DMD now, but not
>>   in GDC. (And IIRC not in LDC either?)
>>
> I just want to get it working as a pure native compilation option for now.
>  Perhaps someone else will tie D into JNI and get it working with Dalvik,
> I'm not interested in that.
>
>
C++ (as in g++) has compiler support with JNI.  I've been turning the idea in my head as going down this route with D (gdc) support in the same way through some sort of magic module which generates these special types (jint, jclass, etc) - not too different from eg: gcc.builtins module.  But for the time being at least this is a deferred long-term wish list goal.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

A few weeks ago I tried compiling gdc and ldc on my Debian arm system and they built Ok but the apps crashed when run. I think the error was something to do with fibres in Phobos and druntime.

I tried quickly hacking in missing architecture macros for Arm but I didn't know what I was doing so it didn't help.

I'd start with the runtime and Phobos before looking at obj-c support and I'll be delighted to test it once you have it working.

There are many more arm Linux systems as well as iOS and Android e.g. Raspberry pi's, other SBC's like cubieboard, arduino, chromebooks, chromecast, kindle etc. it's estimated that 25% of all laptops and 10% of servers will be arm based by the end of next year. D will be dead unless it supports arm.

I tried valiantly to get D working and even bought the book but alas I've had to abandon it for now.