Re: Bit rotation question/challenge
On Saturday, 30 January 2021 at 14:41:59 UTC, Afgdr wrote: On Saturday, 30 January 2021 at 14:40:49 UTC, Afgdr wrote: On Saturday, 30 January 2021 at 13:30:49 UTC, burt wrote: [...] cast as uint and shift. cast the result as ubyte[4]. obiously, that works for n=4 with uint and n=8 for ulong, only. Yes I used to do this, but then I needed it for n > 8.
Re: Bit rotation question/challenge
On Saturday, 30 January 2021 at 14:17:06 UTC, Paul Backus wrote:
On Saturday, 30 January 2021 at 13:30:49 UTC, burt wrote:
[...]
Now I want to bit-rotate the array as if it is one big integer.
You may find `std.bitmanip.BitArray` useful for this:
http://phobos.dpldocs.info/std.bitmanip.BitArray.html
Thank you, this is indeed what I am looking for!
For future reference, this is how I implemented it:
```d
ubyte[n] rotateRight(size_t n)(ubyte[n] x, uint rotation)
{
import std.bitmanip : BitArray;
ubyte[n] x2;
foreach (i, value; x) // have to swap because of endianness
x2[n - 1 - i] = value;
auto copy = x2;
auto bitArray1 = BitArray(cast(void[]) x2[], n * 8);
auto bitArray2 = BitArray(cast(void[]) copy[], n * 8);
bitArray1 >>= rotation;
bitArray2 <<= n * 8 - rotation;
bitArray1 |= bitArray2;
foreach (i, value; x2) // swap back
x[n - 1 - i] = value;
return x;
}
ubyte[4] x = [
0b00011000,
0b0011,
0b00010101,
0b0010,
];
writefln!"%(%8b,\n%)"(x.rotateRight(4));
```
Bit rotation question/challenge
I have a static array of `ubyte`s of arbitrary size:
```d
ubyte[4] x = [ // in reality, ubyte[64]
0b1000,
0b0001,
0b00010101,
0b0010,
];
```
Now I want to bit-rotate the array as if it is one big integer.
So:
```d
ubyte[n] rotateRight(size_t n)(ref const ubyte[n] array, uint
rotation)
{
// ?
}
// same for rotateLeft
ubyte[4] y = [
0b1001,
0b0100,
0b,
0b10001010,
];
assert(x.rotateRight(9) == y);
assert(y.rotateLeft(9) == x);
```
Any ideas how this could be achieved? I.e. what should go at the
"?" for rotateRight and rotateLeft?
Re: Trouble with Android and arsd.jni
On Thursday, 10 September 2020 at 11:58:51 UTC, kinke wrote: On Thursday, 10 September 2020 at 11:16:55 UTC, burt wrote: However, I am getting linker errors, telling me that _tlsend, _tlsstart and __bss_end__ are missing. Perhaps you happen to use some stale artifacts? These magic symbols aren't used anymore in druntime since LDC v1.21, and not defined by the compiler anymore. You also don't need the dummy main() anymore. The object file containing the undefined references should shed some light on what's still referencing them. I'm not sure if this was the cause, but I believe I was using old libdruntime-ldc.a and libphobos2-ldc.a files which where downloaded from before v1.21. So that issue is fixed. However, the app is still crashing when I load it, and there appears to be an issue in Runtime.initialize(), which is called from JNI_OnLoad(), which is defined in arsd.jni. The debugger tells me that it was calling `getStaticTLSRange`, which calls `safeAssert` in the `__foreachbody`, which fails and eventually aborts.
Trouble with Android and arsd.jni
Hello,
I'm trying to upgrade and improve an Android project I was
working on a while ago. For this reason, I decided to upgrade my
compiler to the newest LDC (v1.23.0).
I am using the arsd.jni library for the JNI headers and for
initializing the runtime. However, I am getting linker errors,
telling me that _tlsend, _tlsstart and __bss_end__ are missing.
So I tried to fix these by adding empty declarations for them
myself (as I saw in another post):
```d
extern(C) __gshared
{
@section(".tdata")
int _tlsstart = 0;
@section(".tcommon")
int _tlsend = 0;
}
```
However, when doing this, it causes my app to crash, specifically
on jni.d:1033 when calling `Runtime.initialize()`. The stack
trace shows there is an assertion error in rt.sections_android in
the foreach body of `getStaticTLSRange`.
I also tried adding an empty `void main() {}` instead, with the
same result.
PR #2991 in dlang/druntime seems to have changed the way the TLS
is emulated on Android or something. I have no clue what is going
on and how to fix these errors, so if someone could help that
would be much appreciated.
Thank you.
Re: D on android and d_android
On Tuesday, 7 April 2020 at 12:29:57 UTC, Adam D. Ruppe wrote: On Tuesday, 7 April 2020 at 11:45:24 UTC, burt wrote: I managed to get it to compile. I had to add __bss_end__ symbol myself and set the value to the value of the `_end` symbol or it wouldn't work. A PR to the LDC druntime is wat caused the __bss_end__ symbol to be missing [0]. Blargh it was supposed to just work without main() on the new ldc but I only actually ran stuff with 1.19 on actual android. However, when I added a MainActivity class in D using arsd.jni, the app crashes whenever one of the @Exported methods is called. What does the android studio debugger say about it? Missing method or another link problem? And a callback method for a button in Java called dFunction with the appropriate parameters. I noticed that the generated .so file didn't contain a `Java_com_mypackage_myapplication_MainActivity_dFunction` symbol. Any help on this would be appreciated. Yeah, it uses a private name and registers that in a static module constructor (this allows it to support overloads more easily), so that specific name not being there isn't wrong, but it could be the registration function never got called again. Error is as follows according to the logs: java.lang.IllegalStateException: Could not execute method for android:onClick at [etc.] Caused by: java.lang.reflect.InvocationTargetException at [etc.] Caused by: java.lang.UnsatisfiedLinkError: No implementation found for void com.mypackage.myapplication.MainActivity.dFunction(android.widget.TextView, android.widget.TextView, android.widget.TextView) (tried Java_com_mypackage_myapplication_MainActivity_dFunction and Java_com_mypackage_myapplication_MainActivity_dFunction__Landroid_widget_TextView_2Landroid_widget_TextView_2Landroid_widget_TextView_2) at [etc.] So yes, it cannot find the function. How can I check if the module constructor is actually run?
Re: D on android and d_android
On Thursday, 2 April 2020 at 12:13:27 UTC, Adam D. Ruppe wrote:
On Thursday, 2 April 2020 at 11:29:24 UTC, burt wrote:
Anyway, I don't think this fails to work because of an error
in the d_android library. If you find anything else that may
cause it, I am glad to know, but thank you for your help.
Well, it is supposed to be a "just works" setup helper, so
anything in it is a problem! There was an off-by-one bug in the
downloader, maybe that missing byte made ldc ignore the
corrupted library file.
I managed to get it to compile. I had to add __bss_end__ symbol
myself and set the value to the value of the `_end` symbol or it
wouldn't work. A PR to the LDC druntime is wat caused the
__bss_end__ symbol to be missing [0]. However, when I added a
MainActivity class in D using arsd.jni, the app crashes whenever
one of the @Exported methods is called. My code looked like this:
```
import arsd.jni;
final class TextView : IJavaObject
{
mixin IJavaObjectImplementation!(false);
mixin JavaPackageId!("android.widget", "TextView");
}
mixin ImportExportImpl!TextView;
final class MainActivity : IJavaObject
{
@Export void dFunction(TextView input, TextView output,
TextView historyItem)
{
// ...
}
mixin IJavaObjectImplementation!(false);
mixin JavaPackageId!("com.mypackage.myapplication",
"MainActivity");
}
mixin ImportExportImpl!MainActivity;
```
And a callback method for a button in Java called dFunction with
the appropriate parameters. I noticed that the generated .so file
didn't contain a
`Java_com_mypackage_myapplication_MainActivity_dFunction` symbol.
Any help on this would be appreciated.
Thanks.
[0] https://github.com/ldc-developers/druntime/pull/178
Re: D on android and d_android
On Thursday, 2 April 2020 at 17:16:56 UTC, burt wrote:
On Thursday, 2 April 2020 at 12:13:27 UTC, Adam D. Ruppe wrote:
On Thursday, 2 April 2020 at 11:29:24 UTC, burt wrote:
Anyway, I don't think this fails to work because of an error
in the d_android library. If you find anything else that may
cause it, I am glad to know, but thank you for your help.
Well, it is supposed to be a "just works" setup helper, so
anything in it is a problem! There was an off-by-one bug in
the downloader, maybe that missing byte made ldc ignore the
corrupted library file.
I think I managed to get phobos2 and druntime to link. However,
I still get linker errors saying that the following symbols are
undefined: statvfs, fmodl, modfl, getdelim, _tlsend,
__bss_end__, _tlsstart, __libc_current_sigrtmin,
__libc_current_sigrtmax, strtold. I'm not sure what to do about
that; did I forget to link something or are these symbols not
in the Android runtime?
I managed to narrow it down to just one error. The missing
`_tlsstart` and `_tlsend` symbols were because of the missing
`void main() {}`, that used to be added automatically in
d_android v0.0.5 but not in v0.1.0. It worked when I added an
empty main function.
Most of the other errors were because of the API level of
Android; for whatever reason, Android Studio chose API level 16
instead of at least 21, so changing minSdkVersion to 21 in
build.gradle made those errors go away.
However, I still get one undefined reference to __bss_end__, and
I don't know how to fix this. Is this also a problem with TLS or
the API level?
Thanks.
Re: D on android and d_android
On Thursday, 2 April 2020 at 12:13:27 UTC, Adam D. Ruppe wrote: On Thursday, 2 April 2020 at 11:29:24 UTC, burt wrote: Anyway, I don't think this fails to work because of an error in the d_android library. If you find anything else that may cause it, I am glad to know, but thank you for your help. Well, it is supposed to be a "just works" setup helper, so anything in it is a problem! There was an off-by-one bug in the downloader, maybe that missing byte made ldc ignore the corrupted library file. I think I managed to get phobos2 and druntime to link. However, I still get linker errors saying that the following symbols are undefined: statvfs, fmodl, modfl, getdelim, _tlsend, __bss_end__, _tlsstart, __libc_current_sigrtmin, __libc_current_sigrtmax, strtold. I'm not sure what to do about that; did I forget to link something or are these symbols not in the Android runtime?
Re: D on android and d_android
On Thursday, 2 April 2020 at 01:53:30 UTC, Adam D. Ruppe wrote: On Wednesday, 1 April 2020 at 15:04:02 UTC, burt wrote: Well I'm European, so with 10.010 kB I mean 10010 kB = 10.010 MB in American/British. ah, of course. Well, I won't be able to finish it today anyway, so take your time. I rewrote the downloader so it goes straight from ldc releases instead of depending on me, so this should give a lot more compatibility. Also made `dub run d_android:setup` a thing (though dub sometimes will try to run what it already has and it needs the new version for this, so you might need to fetch new version first). And fixed a bit in readme and other bugs... I only did rudimentary testing though... compiled my test on linux with no error so I think it is good. I'll be on my Windows computer tomorrow and be able to run more tests there. But if you get to it before me, it *might* work now. You may have to edit your ldc2.conf file and delete the old generated addons to give it a cleaner slate too. otherwise, I'll email again once I get a chance to test it more in the morning. (I'm in US Eastern so you are several hours ahead of me in Europe!) I did some more testing and investigated druntime-ldc and phobos2-ldc. They contained the symbols that were undefined according to the error messages, so clearly they are not being linked at all, even though when using -v flag it reported passing -lphobos2-ldc and -ldruntime-ldc flags and -LC:/Users/<...>/armeabi-v7a to the linker, which is the path to the directory that contained `libdruntime-ldc.a` and `libphobos2-ldc.a`, so it should have found those and linked them... Anyway, I don't think this fails to work because of an error in the d_android library. If you find anything else that may cause it, I am glad to know, but thank you for your help.
Re: D on android and d_android
On Wednesday, 1 April 2020 at 15:01:02 UTC, Adam D. Ruppe wrote: On Wednesday, 1 April 2020 at 14:54:35 UTC, burt wrote: libphobos2-ldc.a and libphobos2-ldc-debug.a. Sizes are 2511 kB, 4792 kB, 10.010 kB and 17.378 kB respectively. Those latter two should be megabytes not kilobytes the download must have failed. Well I'm European, so with 10.010 kB I mean 10010 kB = 10.010 MB in American/British. can i come back to it in a few hours? I'll see about rewriting that thing and testing from scratch again... Well, I won't be able to finish it today anyway, so take your time.
Re: D on android and d_android
On Wednesday, 1 April 2020 at 14:31:45 UTC, Adam D. Ruppe wrote:
On Wednesday, 1 April 2020 at 14:20:25 UTC, burt wrote:
Some examples of errors are:
Those mean it isn't linking in the libs at all... ugh.
do
ldc2 -v
and it will tell you where the config file is.
open that up and see if it has teh correct paths under a
section that looks kinda like
"armv7a-.*-linux-android":
{
switches = [
"-defaultlib=phobos2-ldc,druntime-ldc",
"-link-defaultlib-shared=false",
"-gcc=$NDK/toolchains/llvm/prebuilt/$OS/bin/armv7a-linux-androideabi21-clang$EXT",
"-linker=bfd",
"-mcpu=cortex-a8",
];
lib-dirs = [
"$D_ANDROID/runtime_droid_armeabi-v7a",
];
That lib-dirs one in particular is what I'm interested in.
It gives me lib-dirs = [
"C:/Users//Programs/runtime_droid_armeabi-v7a", ];
At that location this folder is located and the contents are
libdruntime-ldc.a, libdruntime-ldc-debug.a, libphobos2-ldc.a and
libphobos2-ldc-debug.a. Sizes are 2511 kB, 4792 kB, 10.010 kB and
17.378 kB respectively.
During another attempt I copied those folder to my dub project
and included the path to those folders in my dub.json as
"lflags": ["--library-path=./runtime_droid_armeabi-v7a"]. This
gave me exactly the same errors.
Other ldc2.conf contents for that section was as follows:
switches = [
"-defaultlib=phobos2-ldc,druntime-ldc",
"-link-defaultlib-shared=false",
"-gcc=C:/Users//AppData/Local/Android/Sdk/ndk/21.0.6113669/toolchains/llvm/prebuilt/windows-x86_64/bin/armv7a-linux-androideabi21-clang.cmd",
"-linker=bfd",
"-mcpu=cortex-a8",
];
Re: D on android and d_android
On Wednesday, 1 April 2020 at 14:16:28 UTC, Adam D. Ruppe wrote: On Wednesday, 1 April 2020 at 14:13:32 UTC, burt wrote: I also wonder if there's a difference between the libphobos2-ldc and libphobos2-ldc-debug.a libraries? Do those mangle differently and could that cause the linker errors? maybe. what are the errors? Some examples of errors are: ...\ldc2-1.19.0-windows-x64\bin\..\import\std/utf.d:0: error: undefined reference to '_D3std3utf12UTFException7__ClassZ' ...\dub\packages\arsd-official-7.0.0\arsd-official/jni.d:0: error: undefined reference to '_D9Exception6__initZ' ...\ldc2-1.19.0-windows-x64\bin\..\import/object.d:3109: error: undefined reference to '_d_arraysetcapacity' .../parser.d:697: error: undefined reference to '_d_newarrayU' Strange is that even symbols that are not mangled (such as _d_arraysetcapacity) cannot be found, even though these should always mangle the same.
Re: D on android and d_android
On Wednesday, 1 April 2020 at 14:00:39 UTC, Adam D. Ruppe wrote: On Wednesday, 1 April 2020 at 13:36:29 UTC, burt wrote: Sorry, I must have misread this. My LDC version was 1.20.1, not 1.19. did that fix the linker error? The runtimes it downloads are specifically built against 1.19. But libs for the other versions are available too, you just need to download the Android versions of ldc and copy them out to the appropriate place. My downloader just isn't smart enough to do it... yet. It is on my todo list though, just so are a million other things. Unfortunately downgrading my LDC to 1.19 did not fix the linker errors. I used `android-setup.d` for this version again and recompiled my project using LDC 1.19, however the errors still occur. I also wonder if there's a difference between the libphobos2-ldc and libphobos2-ldc-debug.a libraries? Do those mangle differently and could that cause the linker errors?
Re: D on android and d_android
So the correct steps now: 1) get ldc 1.19 specifically and the android NDK 2) do `android-setup /path/to/your/android/ndk` 3) do normal `dub build` Sorry, I must have misread this. My LDC version was 1.20.1, not 1.19. Thanks
Re: D on android and d_android
On Wednesday, 1 April 2020 at 11:57:58 UTC, Adam D. Ruppe wrote: On Wednesday, 1 April 2020 at 08:50:01 UTC, burt wrote: I found a README [0] that mentions an "android-dub-build.d" script, which should be a wrapper around `dub build` Ah, I forgot to update that file. There is no android-dub-build anymore, instead the android-setup changes the main configuration file so plain `dub build` just works. So the correct steps now: 1) get ldc 1.19 specifically and the android NDK 2) do `android-setup /path/to/your/android/ndk` 3) do normal `dub build` Thank you for your response, I managed to get a simple no-druntime-no-phobos app running with a function written in D. Now I am trying to create a wrapper around a library that uses the runtime and phobos extensively, and even though the `libphobos2-ldc.a` and `libdruntime-ldc.a` files (created by `android-setup.d`) have been linked into the .a file that resulted from using dub build --compiler=ldc2 --arch=armv7a-none-linux-android on my library, I still get linker errors telling me that symbols from phobos and druntime are undefined. (At least, I think I linked them in properly, because the size is approximately equal to the sizes of `libphobos2-ldc.a` and `libdruntime-ldc.a` added up.) Do you have any idea what could be wrong with my setup? I am on windows and am using Android Studio v3.6.1, NDK 21.0.6113669 and the newest version of LDC2. Thanks in advance.
D on android and d_android
Hi, I'm trying to compile a simple app with D code to Android and trying to use the d_android library for this. While trying to compile a basic sample, I found a README [0] that mentions an "android-dub-build.d" script, which should be a wrapper around `dub build`, but I cannot find this file after downloading the dub package and also not on github; is this a mistake, or should I find it somewhere else? Thank you in advance. [0] https://github.com/adamdruppe/d_android/tree/master/android-dub-test
Re: How can I use heapify in @safe code?
On Saturday, 1 October 2016 at 18:36:54 UTC, klmp wrote:
On Saturday, 1 October 2016 at 16:59:18 UTC, Burt wrote:
[...]
It tries too but "heapify" uses the struct "BinaryHeap" that is
not safe at all.
(either not annotated or @safe not applicable because of what
it uses in intern: @system stuff)
[...]
No easy "good" way:
1. BinaryHeap is an old container
2. It would require to patch the standard library. So virtually
not available before weeks (but after a quick look it doesn't
seem possible)
There's an easy "bad" way:
import std.container.binaryheap;
@safe // This makes things fail.
unittest
{
void foo() @trusted
{
import std.algorithm.comparison : equal;
int[] a = [4, 1, 3, 2, 16, 9, 10, 14, 8, 7];
auto h = heapify(a);
assert(h.equal([16, 14, 10, 9, 8, 7, 4, 3, 2, 1]));
}
}
but "bad", don't forget ;)
It's a complete cheat to trust here.
Thanks for your quick answer! In this case I'll try to rewrite
BinaryHeap. The bad way came to my mind too :). But I don't like
it as does not really make things @safer.
How can I use heapify in @safe code?
Hi,
I'd like to use a binary heap from @safe code. I thought @safe is
transitive but the following example does not compile:
import std.container.binaryheap;
@safe // This makes things fail.
unittest
{
// Test range interface.
import std.algorithm.comparison : equal;
int[] a = [4, 1, 3, 2, 16, 9, 10, 14, 8, 7];
auto h = heapify(a);
assert(h.equal([16, 14, 10, 9, 8, 7, 4, 3, 2, 1]));
}
Is there a way to @safely call heapify? How?
Thanks in advance!
