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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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