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: code.dlang.org downtime
On Wednesday, 18 December 2019 at 10:18:03 UTC, Sebastiaan Koppe wrote: On Wednesday, 18 December 2019 at 09:29:50 UTC, John Colvin wrote: This is still down for me, regardless of using the IP or address. I don't think it's just me either: https://stats.uptimerobot.com/6mQX4Crw2L/783838659 Anytime you see the metadata working you can add `--registry=https://dub.bytecraft.nl` to dub. I am really tempted to cache the metadata as well. Although that brings up the question of how to purge it when new versions are released. (I could setup a job to import the dump every now and then, hmm). This stuff just begs to be fixed. can't get metadata, so no good right now.
Re: code.dlang.org downtime
On Wednesday, 18 December 2019 at 09:29:50 UTC, John Colvin wrote: This is still down for me, regardless of using the IP or address. I don't think it's just me either: https://stats.uptimerobot.com/6mQX4Crw2L/783838659 https://downforeveryoneorjustme.com/code.dlang.org Connection timeout here.
Re: code.dlang.org downtime
On Wednesday, 18 December 2019 at 11:03:04 UTC, Andrea Fontana wrote: On Wednesday, 18 December 2019 at 09:29:50 UTC, John Colvin wrote: This is still down for me, regardless of using the IP or address. I don't think it's just me either: https://stats.uptimerobot.com/6mQX4Crw2L/783838659 https://downforeveryoneorjustme.com/code.dlang.org Connection timeout here. Just said. Up now.
Re: code.dlang.org downtime
On Wednesday, 18 December 2019 at 09:29:50 UTC, John Colvin wrote: This is still down for me, regardless of using the IP or address. I don't think it's just me either: https://stats.uptimerobot.com/6mQX4Crw2L/783838659 Anytime you see the metadata working you can add `--registry=https://dub.bytecraft.nl` to dub. I am really tempted to cache the metadata as well. Although that brings up the question of how to purge it when new versions are released. (I could setup a job to import the dump every now and then, hmm). This stuff just begs to be fixed.
Re: code.dlang.org downtime
On 12/18/19 12:29 PM, John Colvin wrote: This is still down for me, regardless of using the IP or address. I don't think it's just me either: https://stats.uptimerobot.com/6mQX4Crw2L/783838659 The same with me. I can't visit code.dlang.org from home pc, but able to do it from work one. (I did it in different times though)
Re: code.dlang.org downtime
On Monday, 16 December 2019 at 11:04:38 UTC, Sönke Ludwig wrote: As you may have already noticed, the main registry server, code.dlang.org got unreachable yesterday. This was caused by an old VPS of mine getting terminated. The registry had already moved to a different server years ago, but, without me realizing it, the DNS entry still pointed to the old one, with a "temporary" HTTP proxy forwarding to the new server being set up. By now the DNS entry has been corrected, an up-to-date TLS certificate is in place, and the registry is running stable. There are still reports of people not being able to access code.dlang.org, which is apparently caused by intermediate DNS servers still reporting the old IP address and should start working during the next few hours. A temporary workaround is to specify --registry=http://31.15.67.41/ on the dub command line. Unfortunately both fallback servers have been down for a while now, so that this resulted in a total blackout. I plan to move the main registry to a powerful dedicated server in January, which will fix all memory resource related issues that sometimes show up, and could then keep the current VPS as a relatively reliable fallback server. Both together should guarantee virtually 100% uptime, although more fallback servers are of course highly desirable. In addition to that, I plan to separate the repository polling process form the web and REST frontend, as the former appears to be the main cause for failures (a GC memory leak of some kind and a possibly codegen related crash when being compiled with DMD being the two known issues, which both need further investigation). This is still down for me, regardless of using the IP or address. I don't think it's just me either: https://stats.uptimerobot.com/6mQX4Crw2L/783838659
