Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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?
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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...)
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
On Sun, Jan 05, 2020 at 03:56:37AM +, 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
Re: My Android project nearing beta
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 :))
Re: My Android project nearing beta
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 :)
Re: My Android project nearing beta
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
Re: My Android project nearing beta
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)
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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!
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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)
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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 :)
Re: My Android project nearing beta
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
Re: My Android project nearing beta
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
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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 :)
Re: My Android project nearing beta
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é
Re: My Android project nearing beta
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...
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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!
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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).
Re: My Android project nearing beta
On Tue, Dec 17, 2019 at 10:28:32PM +, 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...
Re: My Android project nearing beta
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).
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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
Re: My Android project nearing beta
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!
Re: My Android project nearing beta
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
Re: My Android project nearing beta
On Tue, Dec 17, 2019 at 06:08:07PM +, 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
Re: My Android project nearing beta
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
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
On Mon, Dec 16, 2019 at 09:37:51PM +, 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".
Re: My Android project nearing beta
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.
Re: My Android project nearing beta
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?
Re: My Android project nearing beta
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
Re: My Android project nearing beta
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
Re: My Android project nearing beta
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
My Android project nearing beta
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.
