On Tuesday, 3 December 2013 at 15:13:36 UTC, Johannes Pfau wrote:
> Am Tue, 03 Dec 2013 12:26:57 +0100
> schrieb "Joakim" <joakim@airpost.net>:
>
>> Seems like you got pretty far with your Android port: are you planning on submitting any of these patches back upstream?
>
> At some point, probably yes. However, I want to get the 'easy' stuff
> working first. This means a stable and well-tested ARM/Linux/glibc
> build should be available first. (It makes more sense this way as we
> still have/had some ARM codegen bugs in the compiler.)

OK, anything against putting your incomplete Android port online someplace, say on github?  I'm working on an Android/x86 port now, that way we could work together and submit our patches together.  This would especially allay Iain's concerns about future conflicts between Android/x86 and Android/ARM patches.  My work is publicly available here:

https://github.com/joakim-noah/druntime/tree/android

On 3 December 2013 15:30, Joakim <joakim@airpost.net> wrote:
> On Tuesday, 3 December 2013 at 15:13:36 UTC, Johannes Pfau wrote:
>>
>> Am Tue, 03 Dec 2013 12:26:57 +0100
>> schrieb "Joakim" <joakim@airpost.net>:
>>
>>> Seems like you got pretty far with your Android port: are you planning on submitting any of these patches back upstream?
>>
>>
>> At some point, probably yes. However, I want to get the 'easy' stuff working first. This means a stable and well-tested ARM/Linux/glibc build should be available first. (It makes more sense this way as we still have/had some ARM codegen bugs in the compiler.)
>
>
> OK, anything against putting your incomplete Android port online someplace, say on github?  I'm working on an Android/x86 port now, that way we could work together and submit our patches together.  This would especially allay Iain's concerns about future conflicts between Android/x86 and Android/ARM patches.  My work is publicly available here:
>
> https://github.com/joakim-noah/druntime/tree/android

They are also the concerns of Walter, David and Kai.  But yes I'm a bit more vocal about it than some. :~)

On 2013-12-03 10:43 AM, Iain Buclaw wrote:
> On 3 December 2013 15:30, Joakim <joakim@airpost.net> wrote:
>> On Tuesday, 3 December 2013 at 15:13:36 UTC, Johannes Pfau wrote:
>>>
>>> Am Tue, 03 Dec 2013 12:26:57 +0100
>>> schrieb "Joakim" <joakim@airpost.net>:
>>>
>>>> Seems like you got pretty far with your Android port: are you planning on
>>>> submitting any of these patches back upstream?
>>>
>>>
>>> At some point, probably yes. However, I want to get the 'easy' stuff
>>> working first. This means a stable and well-tested ARM/Linux/glibc
>>> build should be available first. (It makes more sense this way as we
>>> still have/had some ARM codegen bugs in the compiler.)
>>
>>
>> OK, anything against putting your incomplete Android port online someplace,
>> say on github?  I'm working on an Android/x86 port now, that way we could
>> work together and submit our patches together.  This would especially allay
>> Iain's concerns about future conflicts between Android/x86 and Android/ARM
>> patches.  My work is publicly available here:
>>
>> https://github.com/joakim-noah/druntime/tree/android
>
> They are also the concerns of Walter, David and Kai.  But yes I'm a
> bit more vocal about it than some. :~)
>

I'm very interested in this, more specifically when ARM support is such that porting the vibe.d library to Android/ARM or Linux/ARM in general would allow lightweight micro serial-port servers like the BeagleBone to be operated on with WebSockets. This would definitely make robotics more simple. I know it would be interesting for me, I'd use it to build a simple, mini RC airplane equipped with a GoPro! camera that works over LTE. Oh the fun I'd have :) Keep it up

Am Tue, 3 Dec 2013 15:23:54 +0000
schrieb Iain Buclaw <ibuclaw@gdcproject.org>:

> On 3 December 2013 16:13, Johannes Pfau <nospam@example.com> wrote:
> > Am Tue, 03 Dec 2013 12:26:57 +0100
> > schrieb "Joakim" <joakim@airpost.net>:
> >
> >> Seems like you got pretty far with your Android port: are you planning on submitting any of these patches back upstream?
> >
> > At some point, probably yes. However, I want to get the 'easy' stuff working first. This means a stable and well-tested ARM/Linux/glibc build should be available first. (It makes more sense this way as we still have/had some ARM codegen bugs in the compiler.)
> 
> That need testing / approval. ;-)

I know ;-) I found yet another codegen issue when testing dub, currently reducing that issue.

Am Tue, 03 Dec 2013 16:30:10 +0100
schrieb "Joakim" <joakim@airpost.net>:

> On Tuesday, 3 December 2013 at 15:13:36 UTC, Johannes Pfau wrote:
> > Am Tue, 03 Dec 2013 12:26:57 +0100
> > schrieb "Joakim" <joakim@airpost.net>:
> >
> >> Seems like you got pretty far with your Android port: are you planning on submitting any of these patches back upstream?
> >
> > At some point, probably yes. However, I want to get the 'easy'
> > stuff
> > working first. This means a stable and well-tested
> > ARM/Linux/glibc
> > build should be available first. (It makes more sense this way
> > as we
> > still have/had some ARM codegen bugs in the compiler.)
> 
> OK, anything against putting your incomplete Android port online someplace, say on github?  I'm working on an Android/x86 port now, that way we could work together and submit our patches together.  This would especially allay Iain's concerns about future conflicts between Android/x86 and Android/ARM patches.  My work is publicly available here:
> 
> https://github.com/joakim-noah/druntime/tree/android

Sure, here's the code:

Android stuff, but I guess 99% of it is obsolete now https://github.com/jpf91/GDC/commits/android

NDK buildscripts integration: https://github.com/jpf91/ndk-build/commits/master

But that stuff is really old and probably not very interesting. Here's
the current ARM/GlibC work:
https://github.com/jpf91/GDC/commits/arm

On Tuesday, 3 December 2013 at 09:28:11 UTC, Iain Buclaw wrote:
> On 3 December 2013 02:43, Mike <none@none.com> wrote:
>>> Personally I feel that people porting to specific architectures should
>>> maintain their differences in separate files under a /ports directory
>>> structure - lets say core.stdc.stdio as a cod example. The version for
>>> bionic would be under /ports/bionic/core/stdc/stdio.d, and that is the
>>> module that gets compiled into the library when building for bionic.
>>> When installing, the build process generates a header file of the
>>> bionic version of core.stdc.stdio and puts the file in the correct
>>> /include/core/stdc/stdio.di location.
>>>
>>> Though it is fine to say using version {} else version {} else static
>>> assert(false); when dealing with a small set of architectures.  I feel
>>> strongly this is not practical when considering there are 23+
>>> architectures and 12+ platforms that could be in mixed combination.
>>> The result would either be lots of code duplications everywhere, or
>>> just a wiry long block of spaghetti code.  Every port in one file
>>> would (eventually) make it difficult for maintainers IMO.
>>
>>
>> I agree.  Submitted an enhancement here:
>> https://d.puremagic.com/issues/show_bug.cgi?id=11666
>
> Thanks.
>
> My name is Iain.

Iain (sorry for the misspelling),

I'm wondering if you could please elaborate on the following statement:

"When installing, the build process generates a header file of the bionic version of core.stdc.stdio and puts the file in the correct /include/core/stdc/stdio.di location."

Being new to D and the D Runtime build process, while I understand the general principle, I'm not seeing exactly how this can be implemented.

* How are header files generated in the build process?
* Once all the necessary files are generated, what need to be done to tell the compiler to "use this one"?

Also, D has "header files"? Tell me it isn't so.  Did you mean a .di file?  Are these called "header files"?

On Tuesday, 3 December 2013 at 21:39:20 UTC, Johannes Pfau wrote:
> Am Tue, 03 Dec 2013 16:30:10 +0100
> schrieb "Joakim" <joakim@airpost.net>:
>
>> On Tuesday, 3 December 2013 at 15:13:36 UTC, Johannes Pfau wrote:
>> > Am Tue, 03 Dec 2013 12:26:57 +0100
>> > schrieb "Joakim" <joakim@airpost.net>:
>> >
>> >> Seems like you got pretty far with your Android port: are you planning on submitting any of these patches back upstream?
>> >
>> > At some point, probably yes. However, I want to get the 'easy' stuff
>> > working first. This means a stable and well-tested ARM/Linux/glibc
>> > build should be available first. (It makes more sense this way as we
>> > still have/had some ARM codegen bugs in the compiler.)
>> 
>> OK, anything against putting your incomplete Android port online someplace, say on github?  I'm working on an Android/x86 port now, that way we could work together and submit our patches together.  This would especially allay Iain's concerns about future conflicts between Android/x86 and Android/ARM patches.  My work is publicly available here:
>> 
>> https://github.com/joakim-noah/druntime/tree/android
>
> Sure, here's the code:
>
> Android stuff, but I guess 99% of it is obsolete now
> https://github.com/jpf91/GDC/commits/android
Are these all your patches to druntime?  For example, you
mentioned earlier that you "had to rewrite the complete core.stdc
bindings," but there are only three small patches to core.stdc in
the above branch:

https://github.com/jpf91/GDC/commit/d807f9d8a1cc51efe8b14a48d6a294174dc92168

You also mentioned porting the GC, but there are no patches for
that.  I thought you'd gotten further along on an Android port
based on your earlier comments.  It appears that we hit the same
stderr issues though. :)

On 4 December 2013 01:38, Mike <none@none.com> wrote:
> On Tuesday, 3 December 2013 at 09:28:11 UTC, Iain Buclaw wrote:
>>
>> On 3 December 2013 02:43, Mike <none@none.com> wrote:
>>>>
>>>> Personally I feel that people porting to specific architectures should maintain their differences in separate files under a /ports directory structure - lets say core.stdc.stdio as a cod example. The version for bionic would be under /ports/bionic/core/stdc/stdio.d, and that is the module that gets compiled into the library when building for bionic. When installing, the build process generates a header file of the bionic version of core.stdc.stdio and puts the file in the correct /include/core/stdc/stdio.di location.
>>>>
>>>> Though it is fine to say using version {} else version {} else static assert(false); when dealing with a small set of architectures.  I feel strongly this is not practical when considering there are 23+ architectures and 12+ platforms that could be in mixed combination. The result would either be lots of code duplications everywhere, or just a wiry long block of spaghetti code.  Every port in one file would (eventually) make it difficult for maintainers IMO.
>>>
>>>
>>>
>>> I agree.  Submitted an enhancement here: https://d.puremagic.com/issues/show_bug.cgi?id=11666
>>
>>
>> Thanks.
>>
>> My name is Iain.
>
>
> Iain (sorry for the misspelling),
>
> I'm wondering if you could please elaborate on the following statement:
>
>
> "When installing, the build process generates a header file of the bionic version of core.stdc.stdio and puts the file in the correct /include/core/stdc/stdio.di location."
>
> Being new to D and the D Runtime build process, while I understand the general principle, I'm not seeing exactly how this can be implemented.
>
> * How are header files generated in the build process?
> * Once all the necessary files are generated, what need to be done to tell
> the compiler to "use this one"?
>
> Also, D has "header files"? Tell me it isn't so.  Did you mean a .di file? Are these called "header files"?

1. There are interface files installed in header locations on your
filesystem. ;-)
They used to be generated in the build process (ie: gdc -fsyntax-only
-fintfc) but now they are just installed from *.d -> *.di

2. You don't need to tell the compiler to *use this one* because ~only one is installed~.  Which one to install depends on whatever some configure script/make rules decides based on your target system when you build/install the library.

Am Wed, 04 Dec 2013 08:29:11 +0100
schrieb "Joakim" <joakim@airpost.net>:

> On Tuesday, 3 December 2013 at 21:39:20 UTC, Johannes Pfau wrote:
> > Am Tue, 03 Dec 2013 16:30:10 +0100
> > schrieb "Joakim" <joakim@airpost.net>:
> >
> >> On Tuesday, 3 December 2013 at 15:13:36 UTC, Johannes Pfau wrote:
> >> > Am Tue, 03 Dec 2013 12:26:57 +0100
> >> > schrieb "Joakim" <joakim@airpost.net>:
> >> >
> >> >> Seems like you got pretty far with your Android port: are you planning on submitting any of these patches back upstream?
> >> >
> >> > At some point, probably yes. However, I want to get the
> >> > 'easy' stuff
> >> > working first. This means a stable and well-tested
> >> > ARM/Linux/glibc
> >> > build should be available first. (It makes more sense this
> >> > way as we
> >> > still have/had some ARM codegen bugs in the compiler.)
> >> 
> >> OK, anything against putting your incomplete Android port online someplace, say on github?  I'm working on an Android/x86 port now, that way we could work together and submit our patches together.  This would especially allay Iain's concerns about future conflicts between Android/x86 and Android/ARM patches.  My work is publicly available here:
> >> 
> >> https://github.com/joakim-noah/druntime/tree/android
> >
> > Sure, here's the code:
> >
> > Android stuff, but I guess 99% of it is obsolete now https://github.com/jpf91/GDC/commits/android
> Are these all your patches to druntime?  For example, you mentioned earlier that you "had to rewrite the complete core.stdc bindings," but there are only three small patches to core.stdc in the above branch:
> 
> https://github.com/jpf91/GDC/commit/d807f9d8a1cc51efe8b14a48d6a294174dc92168

Hmm, it's possible that I didn't push those changes to github. I might have some backups of that stuff, but I'm not sure. (IIRC I had another git project for that where I experimented with the 'ports' idea)

> 
> You also mentioned porting the GC, but there are no patches for that.  I thought you'd gotten further along on an Android port based on your earlier comments.  It appears that we hit the same stderr issues though. :)

'porting' is an overstatement. The GC is already quite portable, all I did was adding functions to get the stack top / bottom on Android. (Stack top is actually handled in a generic way in gdc).

See https://github.com/jpf91/GDC/blob/428a7573896962acfdd8132465b1f4af0ff3aea8/d/druntime/rt/memory.d#L119

and search for Android. (Of course no real testing was done and the GC could still be broken in other ways. But stack-scanning should work, TLS scanning is portable anyway and heap scanning should work as well)

On Tuesday, 3 December 2013 at 02:43:34 UTC, Mike wrote:
> I agree.  Submitted an enhancement here:  https://d.puremagic.com/issues/show_bug.cgi?id=11666

What new platform are you porting druntime to?  I'm guessing linux/ARM Cortex-M based on your previous posts.  Hopefully, I can reuse some of your work when I try ARM out.