January 07, 2020
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.



January 08, 2020
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
January 08, 2020
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.
January 08, 2020
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?


January 10, 2020
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.
1 2 3 4 5 6
Next ›   Last »