www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - My Android project nearing beta

reply Adam D. Ruppe <destructionator gmail.com> writes:
I'm gonna drop the link here without further comment:

https://github.com/adamdruppe/d_android

hopefully I've written enough in the repo so anyone who wants to 
play with it can... and if not, I need to fix the docs :)

let me know if you find any success or failure playing with it.
Dec 16 2019
next sibling parent GreatSam4sure <greatsam4sure gmail.com> writes:
On Monday, 16 December 2019 at 21:37:51 UTC, Adam D. Ruppe wrote:

 I'm gonna drop the link here without further comment:

 https://github.com/adamdruppe/d_android

 hopefully I've written enough in the repo so anyone who wants 
 to play with it can... and if not, I need to fix the docs :)

 let me know if you find any success or failure playing with it.


Thanks, a lot really happy with this project.

Pls can we start you android studio to set up things like java, 
kotlin, and C++

In that, we can register the presence of D on Android strongly.

Once again thanks
Dec 16 2019
prev sibling next sibling parent GreatSam4sure <greatsam4sure gmail.com> writes:
On Monday, 16 December 2019 at 21:37:51 UTC, Adam D. Ruppe wrote:

 I'm gonna drop the link here without further comment:

 https://github.com/adamdruppe/d_android

 hopefully I've written enough in the repo so anyone who wants 
 to play with it can... and if not, I need to fix the docs :)

 let me know if you find any success or failure playing with it.


Thanks, a lot, I am really happy with this project.

Pls can we start using android studio to set up things just like 
java, kotlin, and C++

In that way, we can register strongly the presence of D on 
Android.

Once again thanks
Dec 16 2019
prev sibling next sibling parent reply GreatSam4sure <greatsam4sure gmail.com> writes:
On Monday, 16 December 2019 at 21:37:51 UTC, Adam D. Ruppe wrote:

 I'm gonna drop the link here without further comment:

 https://github.com/adamdruppe/d_android

 hopefully I've written enough in the repo so anyone who wants 
 to play with it can... and if not, I need to fix the docs :)

 let me know if you find any success or failure playing with it.


I will appreciate a step by step tutorial on how to get things 
setup and running dlang android app
Dec 16 2019
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 16 December 2019 at 23:23:08 UTC, GreatSam4sure wrote:

 I will appreciate a step by step tutorial on how to get things 
 setup and running dlang android app


Did the website there help you at all?
Dec 16 2019
parent GreatSam4sure <greatsam4sure gmail.com> writes:
On Tuesday, 17 December 2019 at 00:41:01 UTC, Adam D. Ruppe wrote:

 On Monday, 16 December 2019 at 23:23:08 UTC, GreatSam4sure 
 wrote:

 I will appreciate a step by step tutorial on how to get things 
 setup and running dlang android app


 Did the website there help you at all?


No sir, that is the reason for the request for a tutorial.
Dec 17 2019
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Dec 16, 2019 at 09:37:51PM +0000, Adam D. Ruppe via
Digitalmars-d-announce wrote:

 I'm gonna drop the link here without further comment:
 
 https://github.com/adamdruppe/d_android
 
 hopefully I've written enough in the repo so anyone who wants to play
 with it can... and if not, I need to fix the docs :)
 
 let me know if you find any success or failure playing with it.


I haven't gotten around to trying this yet (my Android project already
has its own working code; I'm thinking to eventually migrate to Adam's
stuff but no time to do that yet atm); but I highly recommend everyone
interested in Android to go check it out.

Especially check out arsd/jni.d, that can be used to almost-seamlessly
interoperate D with Java.  It's not 100% there yet, but it's pretty
danged awesome. I've never imagined D/Java interop would be so nice to
use!  And this is thanks to D's awesome metaprogramming capabilities.
Compile-time introspection + static foreach, pragma(mangle), and mixin
templates = win.


T

-- 
INTEL = Only half of "intelligence".
Dec 17 2019
parent reply bachmeier <no spam.net> writes:
On Tuesday, 17 December 2019 at 17:24:58 UTC, H. S. Teoh wrote:


 Especially check out arsd/jni.d, that can be used to 
 almost-seamlessly interoperate D with Java.  It's not 100% 
 there yet, but it's pretty danged awesome. I've never imagined 
 D/Java interop would be so nice to use!  And this is thanks to 
 D's awesome metaprogramming capabilities. Compile-time 
 introspection + static foreach, pragma(mangle), and mixin 
 templates = win.


I had no idea that existed. That should really be promoted. There 
might be a lot of interest.
Dec 17 2019
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 17 December 2019 at 17:41:46 UTC, bachmeier wrote:

 [snip]

 I had no idea that existed. That should really be promoted. 
 There might be a lot of interest.


First commit was only 8 days ago [1]. I'm sure there will be a 
bigger announcement when it's ready.

[1] 
https://github.com/adamdruppe/arsd/commit/708307d88526c07cb6bcd913532071e53a7a98a9
Dec 17 2019
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 17, 2019 at 06:08:07PM +0000, jmh530 via Digitalmars-d-announce
wrote:

 On Tuesday, 17 December 2019 at 17:41:46 UTC, bachmeier wrote:

 [snip]
 
 I had no idea that existed. That should really be promoted. There
 might be a lot of interest.


 
 First commit was only 8 days ago [1]. I'm sure there will be a bigger
 announcement when it's ready.
 
 [1] https://github.com/adamdruppe/arsd/commit/708307d88526c07cb6bcd913532071e53a7a98a9


It was already announced, kindof:

	http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_09.html


T

-- 
Life begins when you can spend your spare time programming instead of watching
television. -- Cal Keegan
Dec 17 2019
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 17, 2019 at 10:25:26AM -0800, H. S. Teoh wrote:
[...]

 	http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_09.html


[...]

And I might add, that since that blog was posted there has been
significant progress. Runtime initialization is now working, and you can
create a Java VM and use that too (though in Android's case this is not
necessary or desirable, since JNI docs say that currently only one JVM
per process is supported).

Remaining issues (that I'm aware of) are:
- Support non-final classes on D side;
- Method overloading;
- Using `scope` to handle lifetime issues (maybe?).

Other than that, it's seriously awesome stuff that anyone who has an
interest in Java/D interop should check out.


T

-- 
Nobody is perfect.  I am Nobody. -- pepoluan, GKC forum
Dec 17 2019
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 17 December 2019 at 18:29:32 UTC, H. S. Teoh wrote:

 Remaining issues (that I'm aware of) are:


I also haven't finished supporting all the various Java 
arguments. Notably arrays are unimplemented right now as well as 
handling interfaces (if a D function takes a CharSequence but the 
Java user passes a String, that should work, but doesn't yet. 
Probably a case of calling IsInstanceOf a few times, and I also 
haven't determined how to determine an object that implements 
multiple interfaces right now - the D thing right now makes a 
magic base class so can't do that twice. Will probably look like 
class Foo : JavaObject!("package.name", Foo, IWhatever, 
BaseClass).)

And my stretch goal of extending a Java class in D :P

I also haven't yet implemented thread support. A static ctor can 
do it but I'm actually concerned that is a bit too magical. I 
need to experiment more before just diving in.
Dec 17 2019
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 17 December 2019 at 18:29:32 UTC, H. S. Teoh wrote:

 Runtime initialization is now working, and you can create a 
 Java VM


I now have this tested and working on Windows and Linux.


 - Method overloading;


This is fixed in the newest commit too.


```D
import arsd.jni;

final class Test : JavaClass!("wtf", Test) {
          Import this();
	 Import void cool();
}

void main() {
	auto jvm = createJvm();

	auto h = new Test();
	h.cool();
}
```

```Java

package wtf;

public class Test {
         public native void test_();
         void test() { test_(); }

         void cool() {
                 System.out.println("********* super cool 
*******");
         }
}
```


As you can see there, the D code uses the java class almost as if 
it was native D. Overloads work now too as well as many types in 
many places, but not all in all cases. Still a good chunk of work 
to do but already super cool.


I've gotta shift my attention to COM and .net for a little while 
now though...
Dec 18 2019
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 18 December 2019 at 19:57:43 UTC, Adam D. Ruppe 
wrote:

 On Tuesday, 17 December 2019 at 18:29:32 UTC, H. S. Teoh wrote:

 Runtime initialization is now working, and you can create a 
 Java VM


 I now have this tested and working on Windows and Linux.


 - Method overloading;


 This is fixed in the newest commit too.


 ```D
 import arsd.jni;

 final class Test : JavaClass!("wtf", Test) {
          Import this();
 	 Import void cool();
 }

 void main() {
 	auto jvm = createJvm();

 	auto h = new Test();
 	h.cool();
 }
 ```

 ```Java

 package wtf;

 public class Test {
         public native void test_();
         void test() { test_(); }

         void cool() {
                 System.out.println("********* super cool 
 *******");
         }
 }
 ```


 As you can see there, the D code uses the java class almost as 
 if it was native D. Overloads work now too as well as many 
 types in many places, but not all in all cases. Still a good 
 chunk of work to do but already super cool.


 I've gotta shift my attention to COM and .net for a little 
 while now though...



Thanks a lot for this fantastic work. I want to do s.th. similar
for Delphi (For developing windows, android and ios applications)
and your work gives me some good inspiration.

I wonder whether D could be enhanced in future to make the CRTP
idiom a little bit nicer:

   class JavaClass(string javaPackage, CRTP) : IJavaObject {}

   final class Hello : JavaClass!("", Hello) {}


It would be nice, if I could specify s.th. like that:

   class JavaClass(string javaPackage = "", CRTP =  child) : 
IJavaObject {}

then I could just say:

   final class Hello : JavaClass

Kind regards
André
Dec 19 2019
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 19 December 2019 at 11:48:21 UTC, Andre Pany wrote:

 I wonder whether D could be enhanced in future to make the CRTP
 idiom a little bit nicer:


It is also possible to do a mixin for most the same result.

But yeah if the language were to change there's some fun things. 
The two I have considered is something similar to what you wrote 
and also putting an automatic child mixin in the parent 
class/interface.

Just I work with what we have, not what might happen at some 
point in the future :)
Dec 19 2019
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 17 December 2019 at 18:08:07 UTC, jmh530 wrote:

 On Tuesday, 17 December 2019 at 17:41:46 UTC, bachmeier wrote:

 I had no idea that existed. That should really be promoted. 
 There might be a lot of interest.


 First commit was only 8 days ago [1]. I'm sure there will be a 
 bigger announcement when it's ready.


If I announce lol

but yeah, I just started this a couple weeks ago. The thing that 
delayed me on the android project was the android build system 
and IDE, it took me FOREVER to figure out just how to get my code 
actually running there. (That's why I'm trying to simplify it to 
just running `android-dub-build path/to/android/studio/project` 
for the future).

Then I got to actually look at the interop and my original goal 
was simply to forward the JNI stuff to a regular D function more 
easily.... then I realized jni lets you do so so so much more and 
I went a little nuts.

What you see in there already is kinda incredible: you can `auto 
a = new SomeObjectFromJava();` and it... works. When I started, 
not in my wildest dreams did I expect to actually have a natural 
constructor for the foreign language object but here we have it.

So pretty cool stuff. Though I can't make any promises about 
performance and debugability. I'm gonna try to do load-time 
checks of signatures and I expect that will help, and speed 
relies on how JNI does it and idk how much that is (though things 
like using `wstrings` slicing the chars should help, it is still 
possibly an arbitrary translation layer) but it is still probably 
not going to be amazing; the IDE will just see it as an opaque 
blob I think.

but my jni experiments have so far pleasantly surprised me, so 
maybe it will again.
Dec 17 2019
prev sibling next sibling parent Murilo <murilomiranda92 hotmail.com> writes:
On Monday, 16 December 2019 at 21:37:51 UTC, Adam D. Ruppe wrote:

 I'm gonna drop the link here without further comment:

 https://github.com/adamdruppe/d_android

 hopefully I've written enough in the repo so anyone who wants 
 to play with it can... and if not, I need to fix the docs :)

 let me know if you find any success or failure playing with it.


Nice work!
Dec 17 2019
prev sibling next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 16 December 2019 at 21:37:51 UTC, Adam D. Ruppe wrote:

 I'm gonna drop the link here without further comment:

 https://github.com/adamdruppe/d_android

 hopefully I've written enough in the repo so anyone who wants 
 to play with it can... and if not, I need to fix the docs :)

 let me know if you find any success or failure playing with it.


👇️


 Download the Android NDK. I have version 20 here, I believe it 
 will work with >anything past version 18. Set the environment 
 variable NDK to its path.



 Download LDC, at least version 1.19. Make sure ldc2 is in your 
 PATH.
If you use dub, make sure you have at least version 1.18
Build the runtime with ldc-build-runtime for each supported 
platform. See the android-setup.d for my notes. You can't run 
that program yet but you can easily follow along with the short, 
simple comments. It expects these results will be found in this 
same directory.



Build your program for each supported platform. My 
android-dub-build can help with this.



Copy the generated libs into your existing Android project's 
jniLibs folder. >My android-dub-build will do this for you too 
if you pass it the directory.



This part is unclear to follow
Dec 17 2019
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 17 December 2019 at 20:26:39 UTC, aberba wrote:

 This part is unclear to follow


OK, I'll rewrite it with more examples later in the week. It is 
still a little bit of a pain to set up too so if I can fix that, 
the instructions will be simplified as well.
Dec 17 2019
parent reply bachmeier <no spam.net> writes:
On Tuesday, 17 December 2019 at 20:47:24 UTC, Adam D. Ruppe wrote:

 On Tuesday, 17 December 2019 at 20:26:39 UTC, aberba wrote:

 This part is unclear to follow


 OK, I'll rewrite it with more examples later in the week. It is 
 still a little bit of a pain to set up too so if I can fix 
 that, the instructions will be simplified as well.


Maybe Docker can help ease the burden for others to test it.
Dec 17 2019
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 17 December 2019 at 20:57:54 UTC, bachmeier wrote:

 Maybe Docker can help ease the burden for others to test it.


oh it isn't that hard... as of now the trickiest thing is the 
druntime build and ldc comes with a script to help with that. The 
script just worked on my box for x86, arm64, and x86_64. You also 
need the android stuff from Google but that's I think to be 
expected for the domain... and in theory we could skip that but 
in practice the goal of this is to interop with existing company 
workflows so I expect they will already be using it anyway.

The other arm runtime did NOT work with the script, but 
conveniently, ldc offers a binary download of that on their 
releases page! So just download it, rename the directory and put 
it in the right place, and you're good to go.

But aside from that downloading, otherwise you basically just run 
the program.
Dec 17 2019
parent reply kinke <noone nowhere.com> writes:
On Tuesday, 17 December 2019 at 21:08:07 UTC, Adam D. Ruppe wrote:

 On Tuesday, 17 December 2019 at 20:57:54 UTC, bachmeier wrote:

 Maybe Docker can help ease the burden for others to test it.


 oh it isn't that hard... as of now the trickiest thing is the 
 druntime build and ldc comes with a script to help with that. 
 The script just worked on my box for x86, arm64, and x86_64. 
 [...]
 The other arm runtime did NOT work with the script, but 
 conveniently, ldc offers a binary download of that on their 
 releases page! So just download it, rename the directory and 
 put it in the right place, and you're good to go.


LDC 1.19 final will probably come with a native Android/AArch64 
package. It's going to contain prebuilt Android/x86_64 
druntime/Phobos too, and the armv7a package will contain the i686 
libs; i.e., there'll be prebuilt libs for all 4 Android 
platforms. See https://github.com/ldc-developers/ldc/pull/3244; 
I'm just waiting for LLVM 9.0.1 final to be released (planned for 
Dec 19th).

Instead of wrappers around ldc2 and dub, I'd prefer a little 
generic tool, something like ldc-build-runtime, which automates

1) downloading a prebuilt LDC package for a specified 
cross-compilation target,
2) extracting & renaming the libs,
3) extending ldc2.conf by an appropriate section

Step 3 includes selecting a C cross-linker for most targets and 
could be simplified to just specifying the NDK path for Android 
targets.

Usage would be something like:

$ ldc-add-target android-aarch64
Enter path to Android NDK: /path/to/android-ndk-r20b
$ ldc2 -mtriple=aarch64-linux-android ...
...
$ ldc-add-target windows-x64
$ dub --arch=x86_64-windows-msvc ...

The tool could also create little forwarding scripts 
(aarch64-linux-android-ldc2).
Dec 17 2019
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 17, 2019 at 10:28:32PM +0000, kinke via Digitalmars-d-announce
wrote:
[...]

 LDC 1.19 final will probably come with a native Android/AArch64
 package.  It's going to contain prebuilt Android/x86_64
 druntime/Phobos too, and the armv7a package will contain the i686
 libs; i.e., there'll be prebuilt libs for all 4 Android platforms. See
 https://github.com/ldc-developers/ldc/pull/3244; I'm just waiting for
 LLVM 9.0.1 final to be released (planned for Dec 19th).


Awesome!!



 Instead of wrappers around ldc2 and dub, I'd prefer a little generic
 tool, something like ldc-build-runtime, which automates
 
 1) downloading a prebuilt LDC package for a specified
 cross-compilation target,
 2) extracting & renaming the libs,
 3) extending ldc2.conf by an appropriate section


Yeah, this would be very helpful.  I struggled a bit to get Windows
build working, for example, because I didn't know the exact pattern to
put in ldc2.conf at first. I tried various combinations that didn't work
until I accidentally landed upon "x86_64-.*-windows.msvc" (the Wiki page
was confusing; it's either outdated or incomplete, as I was trying
"i686-.*-windows.*" to no avail).

Having this automated would be Very Nice indeed.



 Step 3 includes selecting a C cross-linker for most targets and could
 be simplified to just specifying the NDK path for Android targets.
 
 Usage would be something like:
 
 $ ldc-add-target android-aarch64
 Enter path to Android NDK: /path/to/android-ndk-r20b
 $ ldc2 -mtriple=aarch64-linux-android ...
 ...
 $ ldc-add-target windows-x64
 $ dub --arch=x86_64-windows-msvc ...


[...]

This is awesome stuff.  My current Android still uses Joakim's old guide
that involves manually specifying a lot of stuff like explicit linker
options, library and SDK paths, etc., on the command line. True, I only
had to do it once and thereafter just put it in the build script, but
having a standard automated scheme to abstract away such details would
make it a lot more pleasant to use.

LDC is quickly becoming my go-to D compiler esp. because of this ease of
targeting other platforms. With superior codegen and ability to
cross-compile to Windows, Android, etc., without needing VMs, dual-boot,
separate cross-compiler installation, or any of that hassle, I'm quickly
running out of reasons to use dmd anymore.  LDC is awesome (and so is
the LDC team).


T

-- 
Two wrongs don't make a right; but three rights do make a left...
Dec 17 2019
parent kinke <kinke gmx.net> writes:
On Tuesday, 17 December 2019 at 23:18:33 UTC, H. S. Teoh wrote:

 I struggled a bit to get Windows build working, for example, 
 because I didn't know the exact pattern to put in ldc2.conf at 
 first. I tried various combinations that didn't work until I 
 accidentally landed upon "x86_64-.*-windows.msvc" (the Wiki 
 page was confusing; it's either outdated or incomplete, as I 
 was trying "i686-.*-windows.*" to no avail).


The Wiki page specifies `x86_64-.*-windows-msvc`, all good.


 This is awesome stuff.  My current Android still uses Joakim's 
 old guide that involves manually specifying a lot of stuff like 
 explicit linker options, library and SDK paths, etc., on the 
 command line. True, I only had to do it once and thereafter 
 just put it in the build script, but having a standard 
 automated scheme to abstract away such details would make it a 
 lot more pleasant to use.


Yeah, that Wiki page needs to be updated, and the outlined tool 
would have to be implemented. ;) - Luckily, it should be rather 
simple to implement and doesn't require knowledge about LDC's 
inner workings (=> I'd rather spend my time elsewhere, don't 
count on me/the LDC team).

And wrt. Android, we're still not running any CI tests 
whatsoever, the only thing that is checked is compilability (and 
linkability of the native LDC Android builds), so that's also 
something that needs to be added before we can claim to have 
Android support. Reworking the TLS initialization and enabling 
full support for shared druntime/Android, as mentioned by Joakim 
in the Wiki page, is also still on the table.
Dec 18 2019
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 17 December 2019 at 22:28:32 UTC, kinke wrote:

 Instead of wrappers around ldc2 and dub, I'd prefer a little 
 generic tool


My implementation is pretty generic - look at the source. All it 
really does is

foreach(target; [x86, x86_64, armv7, aarch64])
    dub build -a target;

and the android-ldc wrapper simply forwards to ldc2 to compile 
while calling a separate linker.

Both programs combined are < 100 lines. (I almost just did a 
shell script but figured easier to just do it in D for cross 
platform compatibility).
Dec 17 2019
parent reply kinke <kinke gmx.net> writes:
On Wednesday, 18 December 2019 at 00:33:38 UTC, Adam D. Ruppe 
wrote:

 On Tuesday, 17 December 2019 at 22:28:32 UTC, kinke wrote:

 Instead of wrappers around ldc2 and dub, I'd prefer a little 
 generic tool


 My implementation is pretty generic


I'm talking about genericity wrt. *all* targets, not just the 4 
Android ones.


 and the android-ldc wrapper simply forwards to ldc2 to compile 
 while calling a separate linker.

 Both programs combined are < 100 lines.


The android-ldc wrapper is already ~160 lines, and AFAICT, it's a 
rather cumbersome alternative to simply setting up ldc2.conf 
appropriately.
Dec 18 2019
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 18 December 2019 at 12:29:17 UTC, kinke wrote:

 The android-ldc wrapper is already ~160 lines, and AFAICT, it's 
 a rather cumbersome alternative to simply setting up ldc2.conf 
 appropriately.


tbh I didn't even know there was a such thing as ldc2.conf.

This indeed might be better and can prolly be upstreamed too. 
Maybe I can just set --linker=whatever... I'll play with it, 
thanks for the tip!
Dec 18 2019
parent reply kinke <kinke gmx.net> writes:
On Wednesday, 18 December 2019 at 15:04:14 UTC, Adam D. Ruppe 
wrote:

 tbh I didn't even know there was a such thing as ldc2.conf.


Heh, it looks like the Wiki page 
(https://wiki.dlang.org/Cross-compiling_with_LDC - I've added an 
exemplary Android section there as well, using `-gcc` to specify 
the NDK's preconfigured clang) needs some overhaul then if not 
even you guys seem to find the relevant information.
Dec 18 2019
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 18 December 2019 at 15:53:14 UTC, kinke wrote:

 Heh, it looks like the Wiki page


Yeah, I found the wiki pages just generally didn't actually work 
when I tried them; prolly outdated.

But your example there is simpler than I thought it would be. I'm 
gonna try using this.... probably next week as I'm out of town 
this week and my laptop can't do android stuff... but still this 
is looking good.

meanwhile i am working on jni from the laptop and that is going 
swimmingly.
Dec 18 2019
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 18 December 2019 at 15:53:14 UTC, kinke wrote:

 Heh, it looks like the Wiki page 
 (https://wiki.dlang.org/Cross-compiling_with_LDC - I've added 
 an exemplary Android section there as well, using `-gcc` to 
 specify the NDK's preconfigured clang) needs some overhaul then 
 if not even you guys seem to find the relevant information.



Well, I worked this into my setup program. It changes ldc2.conf 
so then you can just

         dub build --compiler=ldc2 -a i386-none-linux-android
          mv libdubtest.so BasicActivity/app/src/main/jniLibs/x86 
|| true

         dub build --compiler=ldc2 -a armv7a-none-linux-android
          mv libdubtest.so 
BasicActivity/app/src/main/jniLibs/armeabi-v7a || true

         dub build --compiler=ldc2 -a x86_64-none-linux-android
          mv libdubtest.so 
BasicActivity/app/src/main/jniLibs/x86_64 || true

         dub build --compiler=ldc2 -a aarch64-none-linux-android
          mv libdubtest.so 
BasicActivity/app/src/main/jniLibs/arm64-v8a || true

I really wish dub had a way to specify the output directory on 
its command line which would eliminate the need for those ugly mv 
commands :(

but meh now it works without the helper programs - just a setup 
step.



Meanwhile, I wrote a class/jar -> D interface converter and it 
works beautifully. Alas, dmd is giving me "forward reference" 
errors in there :(

so the crtp trick is triggering a bunch of internal compiler bugs.

ugh.
Dec 30 2019
parent Andre Pany <andre s-e-a-p.de> writes:
On Tuesday, 31 December 2019 at 03:59:58 UTC, Adam D. Ruppe wrote:

 On Wednesday, 18 December 2019 at 15:53:14 UTC, kinke wrote:

 Heh, it looks like the Wiki page 
 (https://wiki.dlang.org/Cross-compiling_with_LDC - I've added 
 an exemplary Android section there as well, using `-gcc` to 
 specify the NDK's preconfigured clang) needs some overhaul 
 then if not even you guys seem to find the relevant 
 information.



 Well, I worked this into my setup program. It changes ldc2.conf 
 so then you can just

         dub build --compiler=ldc2 -a i386-none-linux-android
          mv libdubtest.so 
 BasicActivity/app/src/main/jniLibs/x86 || true

         dub build --compiler=ldc2 -a armv7a-none-linux-android
          mv libdubtest.so 
 BasicActivity/app/src/main/jniLibs/armeabi-v7a || true

         dub build --compiler=ldc2 -a x86_64-none-linux-android
          mv libdubtest.so 
 BasicActivity/app/src/main/jniLibs/x86_64 || true

         dub build --compiler=ldc2 -a aarch64-none-linux-android
          mv libdubtest.so 
 BasicActivity/app/src/main/jniLibs/arm64-v8a || true

 I really wish dub had a way to specify the output directory on 
 its command line which would eliminate the need for those ugly 
 mv commands :(

 but meh now it works without the helper programs - just a setup 
 step.



 Meanwhile, I wrote a class/jar -> D interface converter and it 
 works beautifully. Alas, dmd is giving me "forward reference" 
 errors in there :(

 so the crtp trick is triggering a bunch of internal compiler 
 bugs.

 ugh.


I have to check in detail if I can find some free time, but maybe 
in dub.json of d_android a postGenerateCommands line could be 
defined which calls a dub single package responsible for copying 
the binary to the right place depending on the actual 
architecture.

"preGenerateCommands": ["$DUB copy.d"]

Inside of the coding of copy.d all needed information can be 
retrieved from environment variables (see list of environment 
variables here 
https://dub.pm/package-format-json.html#environment-variables).

Kind regards
Andre
Dec 31 2019
prev sibling next sibling parent reply visitor <visitor gmail.com> writes:
On Monday, 16 December 2019 at 21:37:51 UTC, Adam D. Ruppe wrote:

 I'm gonna drop the link here without further comment:

 https://github.com/adamdruppe/d_android

 hopefully I've written enough in the repo so anyone who wants 
 to play with it can... and if not, I need to fix the docs :)

 let me know if you find any success or failure playing with it.



Thank you very much, Sir
i managed to run the test app on my phone via Android Studio :))

https://framapic.org/JHDQ9v9AnsXj/XOscSF4YieDR.png
Jan 01 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 January 2020 at 12:44:30 UTC, visitor wrote:

 i managed to run the test app on my phone via Android Studio :))


Nice! I just realized that I forgot to commit some of the files 
so cool that you got it working despite me :)
Jan 01 2020
parent reply visitor <visitor gmail.com> writes:
On Wednesday, 1 January 2020 at 16:48:07 UTC, Adam D. Ruppe wrote:

 On Wednesday, 1 January 2020 at 12:44:30 UTC, visitor wrote:

 i managed to run the test app on my phone via Android Studio 
 :))


 Nice! I just realized that I forgot to commit some of the files 
 so cool that you got it working despite me :)


indeed :))
so to reply : i fortunately had a bit of (very recent) 
understanding about D/Android setup and stumbling upon the link 
crash without main() i figured that the main() hack was part of 
the missing files ... i went, like that, by guess and trial 
filling the holes :))

As for the second hack which caused me problems too, obviously, i 
found that if i put the D classes inheriting from your JavaClass 
each in their own files the problem disappears ...
everything compiles and run !
(i have a bunch of "R_ARM_TLS_LDO32 used with non-TLS symbol" 
warnings, though, at link time ... - i compile for armv7a only - )

Btw, with your work i can launch and work from D with libreoffice 
documents !
The exercice is silly because i use D to manipulate java to drive 
uno code (and probably C++)  but it works ! :))  (i will try to 
use your createJVM setup when i have time)
Jan 01 2020
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 January 2020 at 17:16:19 UTC, visitor wrote:

 so to reply : i fortunately had a bit of (very recent) 
 understanding about D/Android setup and stumbling upon the link 
 crash without main() i figured that the main() hack was part of 
 the missing files ... i went, like that, by guess and trial 
 filling the holes :))


nice!

That's a big reason why I am trying to explain the principles 
behind each step too, exactly so other people can fill in when I 
screw it up. And I might not maintain everything into all future 
versions too (I don't really use mobile myself and the hardware I 
own is already 5ish years old so I'm not likely to follow 
bleeding edge SDKs anyway) but as long as the principles still 
apply it will be easy for someone else to pick it up and keep it 
going.


 (i have a bunch of "R_ARM_TLS_LDO32 used with non-TLS symbol" 
 warnings, though, at link time ... - i compile for armv7a only 
 - )


Yeah, I see those too, it seems to come out of the upstream ldc 
builds... but also don't appear to matter. Doesn't happen on the 
other targets btw.


 Btw, with your work i can launch and work from D with 
 libreoffice documents !
 The exercice is silly because i use D to manipulate java to 
 drive uno code (and probably C++)  but it works ! :))  (i will 
 try to use your createJVM setup when i have time)


oh interesting, I didn't even realize that could be an 
application at all!

But Java is a pretty big world and D works pretty nicely with it 
so there is sure to be many things I didn't even think of.

i just need to write up the rest of the documentation so people 
can use it without having to follow my crazy thoughts as they 
jump around. but today my wrist is sore so taking it easy the 
rest of the day prolly. that blog took a lot of write up.
Jan 01 2020
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Another big update here in my blog this week:

http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_30.html
Jan 01 2020
next sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 1 January 2020 at 16:48:40 UTC, Adam D. Ruppe wrote:

 Another big update here in my blog this week:

 http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_30.html


A question that comes to mind with respect to your JNI work: Is 
this specific to Android, or could we use it, for instance, as a 
way to call Java functions from R, where we use D as a bridge to 
simplify things? If so, this could potentially lead to 
significant use of D, as there are a fair number of R packages 
that call into Java. It was a nightmare when I looked into it 
years ago. Making this even more appealing is GDC's inclusion in 
GCC.
Jan 01 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 January 2020 at 17:12:01 UTC, bachmeier wrote:

 A question that comes to mind with respect to your JNI work: Is 
 this specific to Android, or could we use it, for instance, as 
 a way to call Java functions from R, where we use D as a bridge 
 to simplify things?


That should be possible. And the bindings generator and packing 
techniques should work on other things too. All I did here was 
run it on android.jar, but I see no reason why it wouldn't work 
on other jars too, perhaps with adjustments for like java.lang.X 
so it pulls them from another source if necessary.

The jni thing is not specific to Android at all (which is also 
why I put it in my arsd repo instead of the d_android one). In 
fact, most my testing of it has been done outside android since 
it is so much more convenient. I have tested on 64 bit Windows 
and 64 bit Linux as well, it should work anywhere else D and the 
jvm both run.
Jan 01 2020
next sibling parent bachmeier <no spam.net> writes:
On Wednesday, 1 January 2020 at 17:35:28 UTC, Adam D. Ruppe wrote:

 On Wednesday, 1 January 2020 at 17:12:01 UTC, bachmeier wrote:

 A question that comes to mind with respect to your JNI work: 
 Is this specific to Android, or could we use it, for instance, 
 as a way to call Java functions from R, where we use D as a 
 bridge to simplify things?


 That should be possible. And the bindings generator and packing 
 techniques should work on other things too. All I did here was 
 run it on android.jar, but I see no reason why it wouldn't work 
 on other jars too, perhaps with adjustments for like 
 java.lang.X so it pulls them from another source if necessary.

 The jni thing is not specific to Android at all (which is also 
 why I put it in my arsd repo instead of the d_android one). In 
 fact, most my testing of it has been done outside android since 
 it is so much more convenient. I have tested on 64 bit Windows 
 and 64 bit Linux as well, it should work anywhere else D and 
 the jvm both run.


Excellent. I'll definitely be digging into this when I have time. 
R is very heavily used. Once users have D installed to facilitate 
calling into Java, there's no longer a good reason to not work 
with D itself.
Jan 01 2020
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 1 January 2020 at 17:35:28 UTC, Adam D. Ruppe wrote:

 bindings generator


oh one thing I forgot to mention on this is that right now it 
generates interfaces, but doesn't list them; each class is just

class Foo : IJavaObject {}

instead of

class foo : ActualParent, IWhateverElse {}


All that is possible, of course, and would probably be pretty 
useful. But I didn't do it for the same reason everything is 
listed `final` right now - doing so would mean the vtable needs 
to be populated... which means the linker is going to go looking 
for those implementations. 4000 classes of implementations (and 
ungodly build time) forced on you when you probably only want a 
handful.

so.... well, this is my solution until it is dead or I find 
something better.

I do think interfaces are important long term, and since JNI 
actually dynamically binds by name there's a few options 
available to me to make it work, even with the lazy linking.

But for now if you look in the source, there's this stuff and a 
bunch of reinterpret cast FIXME comments in places where 
something needs to change for full support. just even without all 
that this is still pretty useful!
Jan 01 2020
parent reply visitor <visitor gmail.com> writes:
On Wednesday, 1 January 2020 at 18:15:32 UTC, Adam D. Ruppe wrote:

i see you updated everything ! wow !! :))

just a note : i had to add a sourceSets instruction
```
android {
     ...
     defaultConfig {
     ...
     }
     sourceSets {
         main {
             // let gradle pack the shared library into apk
             jniLibs.srcDirs = ['./src/main/jniLibs']
         }
     }
     ...
}
```
in the build.gradle file (the one in app directory) of the test 
application

it didn't pack the library in the apk otherwise, in my setup 
(which is plain basic, probably not relevant anyway)
Jan 02 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 2 January 2020 at 20:26:05 UTC, visitor wrote:

 i see you updated everything ! wow !! :))


yea, the setup program should now download the runtime binaries 
for you and set up ldc2.conf fairly automatically (I haven't 
tested on Windows yet though and of course it will static assert 
on Mac but should be easy fix when I get to it).

Getting there. I think I have a plan for making new Java classes 
from D too that I'll play with when I get more time...


 just a note : i had to add a sourceSets instruction


hmm, ok, I didn't have to do that on mine but I can add a note to 
the docs for others.

tbh I don't really understand very much about android and the 
ide. I've never actually made an android app myself and never 
actually even heard of gradle before I started playing with 
this....
Jan 02 2020
parent reply visitor <visitor gmail.com> writes:
On Thursday, 2 January 2020 at 20:36:46 UTC, Adam D. Ruppe wrote:

 Getting there. I think I have a plan for making new Java 
 classes from D too that I'll play with when I get more time...


!!!   You tried very hard to blow up the whole thing !
Sorry, nope ! still running fine :)

i didn't try the new automated setup, though, but your jni.d 
works fine, both on the test android app and my little experiment 
with "normal" java (using regular dmd - 2.089.1 - there, btw)
Thanks :)
Jan 04 2020
parent reply visitor <visitor gmail.com> writes:
On Saturday, 4 January 2020 at 16:59:13 UTC, visitor wrote:

 On Thursday, 2 January 2020 at 20:36:46 UTC, Adam D. Ruppe 
 wrote:

 Getting there. I think I have a plan for making new Java 
 classes from D too that I'll play with when I get more time...




Your createJVM() setup works fine on my little experiment !
Not a single line of java! wow ! very Nice :))
Jan 04 2020
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 05, 2020 at 03:56:37AM +0000, visitor via Digitalmars-d-announce
wrote:

 On Saturday, 4 January 2020 at 16:59:13 UTC, visitor wrote:

 On Thursday, 2 January 2020 at 20:36:46 UTC, Adam D. Ruppe wrote:

 
 Getting there. I think I have a plan for making new Java classes
 from D too that I'll play with when I get more time...




 
 Your createJVM() setup works fine on my little experiment !
 Not a single line of java! wow ! very Nice :))


[...]

I've been saying, Adam's jni.d is epic stuff.  It's a perfect showcase
of how D's metaprogramming capabilities are a big enabler of this sort
of inter-language interfacing.  If we play it right, D could become a
powerful player as a glue language for pulling different languages
together in an integrated, hassle-free way.


T

-- 
Real men don't take backups. They put their source on a public FTP-server and
let the world mirror it. -- Linus Torvalds
Jan 04 2020
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 5 January 2020 at 03:56:37 UTC, visitor wrote:

 Not a single line of java!


so i got kinda excited for creating a class 100% in D as well, 
but.....

https://developer.android.com/training/articles/perf-jni.html

"DefineClass is not implemented. Android does not use Java 
bytecodes or class files, so passing in binary class data doesn't 
work."

gah, there goes that idea. So I guess that means the lambda 
callbacks for ui classes must be implemented in Java too. alas.

but still most things work anyway so still fun.

I need to make one of those NativeActivity ndk programs as a 
sample though, to show people how to do all that stuff.
Jan 06 2020
next sibling parent reply visitor <visitor gmail.com> writes:
On Monday, 6 January 2020 at 14:37:54 UTC, Adam D. Ruppe wrote:


 gah, there goes that idea. So I guess that means the lambda 
 callbacks for ui classes must be implemented in Java too. alas.

 but still most things work anyway so still fun.


hum ... indeed most of the native samples in android are using 
java helper classes

do you still plan to add the ability to create java classes in D 
for non-android projects ?
(ui callbacks, that's where i paused in my non-Android test, also 
in this project i made "GlobalRef"s to reuse java objects / 
classes - thanks for warmly warning about the possible wreckage)

(btw, though good to know the trick, in fact i don't need the 
sourceSets instruction for the jniLibs, i forgot to put the 
library in the right subfolder ... "x86" or "armeabi-v7a", etc...)
Jan 06 2020
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 6 January 2020 at 17:18:46 UTC, visitor wrote:

 hum ... indeed most of the native samples in android are using 
 java helper classes


Yeah, the NativeActivity is I think the only one that doesn't 
(and that's just because Google provides a pre-built helper java 
class).

But I'm personally OK with that; reusing the platform as much as 
we can is a strength of D, it doesn't have to be all one thing. A 
little bit of Java gives you hooks into the IDE and stuff and 
isn't that much work; you can still reuse the majority of a D 
core.


 do you still plan to add the ability to create java classes in 
 D for non-android projects ?


yes. I might not get around to it for a little while and it will 
very possibly be opt-in with a -version thing (right now I call 
it WithClassLoadSupport - creating a class would use the same 
code to work with the binary format). But I do want to do it.

Another challenge would be syntax. D does lambdas and anonymous 
inner classes... but they probably won't get the magic on them.

It may end up being a helper template, so you'd be like

JavaLambda!InterfaceName( a => whatever );

or something like that. I still need to think more about it.


 also in this project i made "GlobalRef"s to reuse java objects 
 / classes - thanks for warmly warning about the possible


I plan to address this later too. Probably all return values will 
conservatively get the global ref unless you declare it as like 
`Manual!T` instead, which then wraps it for you and uses the type 
system to determine what needs to be it.

(if you look at the comments of jni.d you can see a lot of my 
notes to self about problems and possible future directions. Not 
all of them actually work out, but it gives you some view into 
what's in my brain.)


 (btw, though good to know the trick, in fact i don't need the 
 sourceSets instruction for the jniLibs, i forgot to put the 
 library in the right subfolder ... "x86" or "armeabi-v7a", 
 etc...)


excellent.
Jan 06 2020
prev sibling parent reply Laeeth Isharc <laeeth kaleidic.io> writes:
On Monday, 6 January 2020 at 14:37:54 UTC, Adam D. Ruppe wrote:

 On Sunday, 5 January 2020 at 03:56:37 UTC, visitor wrote:

 Not a single line of java!


 so i got kinda excited for creating a class 100% in D as well, 
 but.....

 https://developer.android.com/training/articles/perf-jni.html

 "DefineClass is not implemented. Android does not use Java 
 bytecodes or class files, so passing in binary class data 
 doesn't work."


I haven't tried, but:

https://github.com/linkedin/dexmaker
Jan 06 2020
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 6 January 2020 at 17:40:47 UTC, Laeeth Isharc wrote:

 I haven't tried, but:
 https://github.com/linkedin/dexmaker


Yes, indeed, that is a possibility. I might work on this... 
honestly probably after several months given the length of my to 
do list right now.
Jan 06 2020
prev sibling parent suncarpet <suncarpet firemail.cc> writes:
On Wednesday, 1 January 2020 at 16:48:40 UTC, Adam D. Ruppe wrote:

 Another big update here in my blog this week:

 http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_30.html


I have to wonder if you sleep. Thank you for your work.
Jan 01 2020
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Monday, 16 December 2019 at 21:37:51 UTC, Adam D. Ruppe wrote:

 I'm gonna drop the link here without further comment:

 https://github.com/adamdruppe/d_android

 hopefully I've written enough in the repo so anyone who wants 
 to play with it can... and if not, I need to fix the docs :)

 let me know if you find any success or failure playing with it.


Great stuff. I doff my hat. You seem to be the right guy for this 
job, hands-on and all. A few questions / remarks:

1. How does it fare performance wise with JNI? In the Android 
docs they advise you not to use the JNI bridge very often as it 
very costly.

2. The new JVM default language for Android is Kotlin. How will 
you handle that? Kotlin and Java are a 100% compatible, so for 
now it is possible to have something like jni.d > Java > Kotlin, 
or even jni.d > Kotlin, as JNI for Kotlin is basically the same 
as for Java.  Further down the road it might make sense to cater 
for Kotlin more directly which leads me to my next point:

3. At KotlinConf 2019 they announced that they want Kotlin to 
become some sort of a default tool for programming tasks [1] (be 
it mobile, server or micro-controllers). Earlier in this thread, 
D's potential as a "glue language" was mentioned, and I think it 
makes sense. So maybe more efforts should go into this aspect of 
D, along the lines of what you have created here.

[1] https://www.youtube.com/watch?v=0xKTM0A8gdI
Jan 08 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 8 January 2020 at 12:10:15 UTC, Chris wrote:

 1. How does it fare performance wise with JNI? In the Android 
 docs they advise you not to use the JNI bridge very often as it 
 very costly.


I don't know. I don't even have a plan to actually test it at 
this point.

Worth remembering that I'm talking a lot about the jni thing 
because it is new, but I suspect the majority of use wouldn't hit 
it often, and possibly not at all. Just the extern(C) NDK and 
OpenGL functions are already a solved problem so much as much to 
say there in terms of new developments.

But I do use various techniques internally to minimize the calls: 
it slices strings rather than copying them (where possible), 
caches lookup results for classes and methods, avoids pinning 
references where possible (though this will have to partially 
change with the implementation expanding too!) and will do lazy 
loading of object arrays (right now it is simply not implemented).

Just there is indeed some cost on the jvm side we can't avoid. 
But using D code and the C functions for the majority should 
minimize the impact too; the jni might be limited to setup and 
some user interaction callback stuff where speed is adequate even 
if not great.


 2. The new JVM default language for Android is Kotlin. How will 
 you handle that?


Doesn't affect anything as far as I can tell, except possibly 
slightly awkward syntax when compared side by side with stuff 
like kotlin extension methods - even my bindings generator (which 
you don't have to use btw) doesn't look at the source, instead 
pulling the data right out of the compiled class files. Since 
kotlin compiles to the same thing as java, it should work the 
same way.

(the biggest problem I've had with the jni thing btw: default 
implementations in interfaces. yikes. but i think i have a plan. 
otherwise the other pains are just me trying to keep compile time 
and memory usage down, so some hacks to do that while still 
keeping all of java available on demand. But that isn't used in 
anything Android I've found so far.)

We should probably test it more to be sure though.
Jan 08 2020
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 8 January 2020 at 14:13:58 UTC, Adam D. Ruppe wrote:


 2. The new JVM default language for Android is Kotlin. How 
 will you handle that?


 Doesn't affect anything as far as I can tell, except possibly 
 slightly awkward syntax when compared side by side with stuff 
 like kotlin extension methods - even my bindings generator 
 (which you don't have to use btw) doesn't look at the source, 
 instead pulling the data right out of the compiled class files. 
 Since kotlin compiles to the same thing as java, it should work 
 the same way.


Cool that you can take the compiled classes directly. Btw, how 
will D for Android handle multi-threading / coroutines? Will the 
coroutines have to be on the Java / Kotlin side of things or is 
it possible to run them in D too?
Jan 08 2020
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 8 January 2020 at 14:23:49 UTC, Chris wrote:

 Btw, how will D for Android handle multi-threading / coroutines?


So again I haven't actually tested, but based on the 
implementation right now you can have D threads and Java threads, 
but they shouldn't mix. I think I can fix that later by offering 
attach/detach D to Java threads, and possibly do it automatically 
with static ctors.

But I'm just not there yet.


BTW I did finally call the code generator good enough yesterday. 
I was trying to mimic the Java inheritance tree in D but that hit 
various troubles (including two separate dmd bugs!), so instead, 
the code generator flattens everything into individual D final 
classes.

Then if you need to cast to a Java interface, you'll have to use 
a template function instead. Best compromise of usability I could 
get right now.

The Android TextView widget takes 30 seconds to compile since it 
pulls in virtually everything :( I also changed it so return 
values are automatically imported to avoid linker errors but that 
is a good chunk as to why it gets so slow.

I experimented with opaque return values you must instantiate but 
you'd then have to explicitly call it an every return, and the 
builder pattern was annoying:

Foo.builder.get.whatever.get.whatever.get

each of those .get things are the instantiate thing. Trying 
opDispatch and alias this both failed due to awful error messages 
leading to bad usability or dmd segfaults. So... idk I might go 
back to that idea since writing .get isn't too bad. But it is a 
matter of trading compile time for more natural looking code and 
idk what I like most yet.
Jan 10 2020