Re: Does anyone build for Android? Tons of link errors..
On Thursday, 17 February 2022 at 01:17:51 UTC, kinke wrote: On Wednesday, 16 February 2022 at 20:40:02 UTC, Fry wrote: A lot of unresolved references to just CPU_COUNT. The confusing part is that it has undefined referenced to parts of in `core`, which I am linking the druntime as well. If you're linking manually, make sure that `-ldruntime-ldc` comes *after* `-lphobos2-ldc`, and that your druntime lib has been compiled for the appropriate arch. CPU_COUNT is a druntime symbol too. Yes I tried changing the order, it seems like I am getting all unresolved symbols for D. Including _d_assert, but only when I use the --no-undefined flag. I have no idea why it is spitting out so many unresolved references.
Re: Does anyone build for Android? Tons of link errors..
On Wednesday, 16 February 2022 at 20:40:02 UTC, Fry wrote: A lot of unresolved references to just CPU_COUNT. The confusing part is that it has undefined referenced to parts of in `core`, which I am linking the druntime as well. If you're linking manually, make sure that `-ldruntime-ldc` comes *after* `-lphobos2-ldc`, and that your druntime lib has been compiled for the appropriate arch. CPU_COUNT is a druntime symbol too.
Re: Does anyone build for Android? Tons of link errors..
On Wednesday, 16 February 2022 at 22:50:09 UTC, H. S. Teoh wrote: On Wed, Feb 16, 2022 at 08:40:02PM +, Fry via Digitalmars-d-learn wrote: I'm getting a ton of linker errors when building with LDC with the aarch64 release from here: [...] Is anyone able to build for android? I adapted the instructions from: https://wiki.dlang.org/Build_D_for_Android Works fine for me. Note that you will need a working installation of the Android NDK, and will need to build druntime/phobos specifically for cross-compilation, as detailed on that page. If you're planning to build APKs, you will need to install various Android utilities as well (dalvik-exchange, zipalign, apksigner, etc.). T I got that demo compiling, it seems this flag is causing it to not compile "-Wl,--no-undefined". But if it is undefined it shouldn't compile normally. There should be linker errors I'm expecting but if I take out that flag then I don't get any...
Re: Does anyone build for Android? Tons of link errors..
On Wed, Feb 16, 2022 at 08:40:02PM +, Fry via Digitalmars-d-learn wrote: > I'm getting a ton of linker errors when building with LDC with the > aarch64 release from here: [...] > Is anyone able to build for android? I adapted the instructions from: https://wiki.dlang.org/Build_D_for_Android Works fine for me. Note that you will need a working installation of the Android NDK, and will need to build druntime/phobos specifically for cross-compilation, as detailed on that page. If you're planning to build APKs, you will need to install various Android utilities as well (dalvik-exchange, zipalign, apksigner, etc.). T -- All men are mortal. Socrates is mortal. Therefore all men are Socrates.
Does anyone build for Android? Tons of link errors..
I'm getting a ton of linker errors when building with LDC with the aarch64 release from here: https://github.com/ldc-developers/ldc/releases ``` Lib/Android/arm64-v8a/libphobos2-ldc.a(concurrency.o):(.data._D3std11concurrency12__ModuleInfoZ+0x20): undefined reference to `_D4core4sync9condition12__ModuleInfoZ' Lib/Android/arm64-v8a/libphobos2-ldc.a(parallelism.o): In function `_D3std11parallelism13totalCPUsImplFNbNiNeZk': parallelism.d:(.text._D3std11parallelism13totalCPUsImplFNbNiNeZk+0x20): undefined reference to `CPU_COUNT' Lib/Android/arm64-v8a/libphobos2-ldc.a(parallelism.o): In function `_D3std11parallelism8TaskPool6__ctorMFNeZCQBnQBmQBc': parallelism.d:(.text._D3std11parallelism8TaskPool6__ctorMFNeZCQBnQBmQBc+0x64): undefined reference to `CPU_COUNT' Lib/Android/arm64-v8a/libphobos2-ldc.a(parallelism.o): In function `_D3std11parallelism8TaskPool6__ctorMFNemZCQBoQBnQBd': parallelism.d:(.text._D3std11parallelism8TaskPool6__ctorMFNemZCQBoQBnQBd+0xc0): undefined reference to `_D4core4sync9condition9Condition7__ClassZ' parallelism.d:(.text._D3std11parallelism8TaskPool6__ctorMFNemZCQBoQBnQBd+0xc4): undefined reference to `_D4core4sync9condition9Condition7__ClassZ' parallelism.d:(.text._D3std11parallelism8TaskPool6__ctorMFNemZCQBoQBnQBd+0xd0): undefined reference to `_D4core4sync9condition9Condition6__vtblZ' parallelism.d:(.text._D3std11parallelism8TaskPool6__ctorMFNemZCQBoQBnQBd+0xd4): undefined reference to `_D4core4sync9condition9Condition6__initZ' parallelism.d:(.text._D3std11parallelism8TaskPool6__ctorMFNemZCQBoQBnQBd+0xd8): undefined reference to `_D4core4sync9condition9Condition6__vtblZ' parallelism.d:(.text._D3std11parallelism8TaskPool6__ctorMFNemZCQBoQBnQBd+0xdc): undefined reference to `_D4core4sync9condition9Condition6__initZ' parallelism.d:(.text._D3std11parallelism8TaskPool6__ctorMFNemZCQBoQBnQBd+0x108): undefined reference to `_D4core4sync9condition9Condition6__ctorMFNbNfCQBsQBq5mutex5MutexZCQCmQCkQCiQCb' parallelism.d:(.text._D3std11parallelism8TaskPool6__ctorMFNemZCQBoQBnQBd+0x134): undefined reference to `_D4core4sync9condition9Condition6__ctorMFNbNfCQBsQBq5mutex5MutexZCQCmQCkQCiQCb' Lib/Android/arm64-v8a/libphobos2-ldc.a(parallelism.o): In function `_D3std11parallelism__T27__lazilyInitializedConstantTykVki4294967295S_DQCqQCp13totalCPUsImplFNbNiNeZkZQDbFNaNbNdNiNfZyk': parallelism.d:(.text._D3std11parallelism__T27__lazilyInitializedConstantTykVki4294967295S_DQCqQCp13totalCPUsImplFNbNiNeZkZQDbFNaNbNdNiNfZyk+0x60): undefined reference to `CPU_COUNT' Lib/Android/arm64-v8a/libphobos2-ldc.a(parallelism.o): In function `_D3std11parallelism8taskPoolFNdNeZ9__lambda2FNfZCQBvQBu8TaskPool': parallelism.d:(.text._D3std11parallelism8taskPoolFNdNeZ9__lambda2FNfZCQBvQBu8TaskPool+0xc0): undefined reference to `CPU_COUNT' Lib/Android/arm64-v8a/libphobos2-ldc.a(parallelism.o): In function `_D3std11parallelism18defaultPoolThreadsFNdNeZk': parallelism.d:(.text._D3std11parallelism18defaultPoolThreadsFNdNeZk+0x84): undefined reference to `CPU_COUNT' ``` A lot of unresolved references to just CPU_COUNT. The confusing part is that it has undefined referenced to parts of in `core`, which I am linking the druntime as well. Is anyone able to build for android?
Re: Strange behavior of iota
On Wednesday, 16 February 2022 at 19:35:00 UTC, jmh530 wrote: [snip] Step 1: In the integral overloads, use allSatisfy!(isSigned, B, E) || allSatisfy!(isUnsigned, T, U) for the current behavior Step 2: When !(allSatisfy!(isSigned, B, E) || allSatisfy!(isUnsigned, T, U)), then convert to narrowest common type as I mentioned (long in your case). This would preserve the current size when the types are both either signed or unsigned and then would expand it only when there are different signed-ness. This also makes the behavior change at compile-time instead of throwing at runtime. T/U should be B/E
Re: GtkD on macOS Monterey
On Wednesday, 16 February 2022 at 15:54:26 UTC, Ron Tarrant wrote: On Monday, 14 February 2022 at 00:39:30 UTC, Joel wrote: My GtkD programs compile and run (on Monterey - works on earlier versions), but not GUI displayed?! I asked on the GtkD forum, but they said about not having a mac or something. Check this out: https://gitlab.gnome.org/GNOME/gtk/-/issues/4342 It may shed some light for you. Thanks for your reply, but it's not the same issue though. I don't have an M1 computer, (I've tried M1 though, and could do even less on it, just terminal programs, not the multimedia stuff I use).
Re: Offline D documentation/tutorial
On 2022-02-13 01:16, LorenDB wrote: Is there a way to download tour.dlang.org, the D spec, and/or the Phobos spec as an offline HTML site? I like the ability of cppreference.com to be saved as an offline HTML archive and I'd like to have that for D as well. In addition to the already mentioned solutions there are at least two more: 1. I was pointed by Seb to https://devdocs.io/d/ which offers an offline mode via html5. 2. Another nice thing for dlang would be to support dash docsets (https://kapeli.com/dash). There is a free opensource reader for those as well (https://zealdocs.org/). https://github.com/trishume/d-phobos-docset tried to create such docsets with a small script, but thats not up2date. All in all I think there are almost to many half baked solutions to the offline documentation problem in dlang. Perhaps this could be something for the steering committee. Kind regards, Christian
Re: Strange behavior of iota
On Wednesday, 16 February 2022 at 15:55:55 UTC, bachmeier wrote: On Wednesday, 16 February 2022 at 15:21:11 UTC, jmh530 wrote: On Tuesday, 15 February 2022 at 22:24:53 UTC, bachmeier wrote: [snip] After looking at the documentation and seeing CommonType!(int, uint) is uint, I have to say that iota's behavior doesn't make much sense. What do you propose as an alternative? What about the narrowest type that fits both int and uint? That would be a long. My preference (in order) 1. Change everything to long. That way it works as anyone other than the author of std.range.iota would expect. 2. Throw an error when casting from signed to unsigned. That would at least prevent wrong output. The current behavior delivers incorrect output 100% of the time, excluding the trivial case where the correct output has zero elements. 3. Require the step to be positive. 4. Remove iota from Phobos because it silently changes correct code to incorrect code that compiles and runs. I've got an idea for combining 1 and 2. Step 1: In the integral overloads, use allSatisfy!(isSigned, B, E) || allSatisfy!(isUnsigned, T, U) for the current behavior Step 2: When !(allSatisfy!(isSigned, B, E) || allSatisfy!(isUnsigned, T, U)), then convert to narrowest common type as I mentioned (long in your case). This would preserve the current size when the types are both either signed or unsigned and then would expand it only when there are different signed-ness. This also makes the behavior change at compile-time instead of throwing at runtime.
Re: split Error - no overload matches
On Tue, Feb 15, 2022 at 06:37:44PM +, meta via Digitalmars-d-learn wrote:
> A trick i use often:
>
> ```D
> import std;
>
> void main()
> {
> import uni = std.uni;
> writeln("Learning D is fun".split!(uni.isWhite));
> }
>
> ```
>
> Under-rated way of importing things, you don't bloat your scope
> anymore
+1, noice! I should use this more often.
T
--
Truth, Sir, is a cow which will give [skeptics] no more milk, and so they are
gone to milk the bull. -- Sam. Johnson
Re: Strange behavior of iota
On Wednesday, 16 February 2022 at 15:21:11 UTC, jmh530 wrote: On Tuesday, 15 February 2022 at 22:24:53 UTC, bachmeier wrote: [snip] After looking at the documentation and seeing CommonType!(int, uint) is uint, I have to say that iota's behavior doesn't make much sense. What do you propose as an alternative? What about the narrowest type that fits both int and uint? That would be a long. My preference (in order) 1. Change everything to long. That way it works as anyone other than the author of std.range.iota would expect. 2. Throw an error when casting from signed to unsigned. That would at least prevent wrong output. The current behavior delivers incorrect output 100% of the time, excluding the trivial case where the correct output has zero elements. 3. Require the step to be positive. 4. Remove iota from Phobos because it silently changes correct code to incorrect code that compiles and runs.
Re: GtkD on macOS Monterey
On Monday, 14 February 2022 at 00:39:30 UTC, Joel wrote: My GtkD programs compile and run (on Monterey - works on earlier versions), but not GUI displayed?! I asked on the GtkD forum, but they said about not having a mac or something. Check this out: https://gitlab.gnome.org/GNOME/gtk/-/issues/4342 It may shed some light for you.
Re: Strange behavior of iota
On Tuesday, 15 February 2022 at 22:24:53 UTC, bachmeier wrote: [snip] After looking at the documentation and seeing CommonType!(int, uint) is uint, I have to say that iota's behavior doesn't make much sense. What do you propose as an alternative? What about the narrowest type that fits both int and uint? That would be a long.
Re: Strange behavior of iota
On Wednesday, 16 February 2022 at 02:51:32 UTC, Era Scarecrow
wrote:
On Tuesday, 15 February 2022 at 22:24:53 UTC, bachmeier wrote:
On Tuesday, 15 February 2022 at 22:02:13 UTC, Adam D Ruppe
wrote:
for(a = v.length; a > cast(size_t) -1, a += -1)
After looking at the documentation and seeing CommonType!(int,
uint) is uint, I have to say that iota's behavior doesn't make
much sense.
Unless it's almost always intended to go up and stay positive?
That may have been the intended use case, but it's poor design to
not enforce it. I was using it to iterate through the indexes on
an array backwards. You have to set the second argument to -1 to
get the last index to be 0.
On a larger scale, it's D's principle that it's okay to throw
unsigned types around and leave it to the programmer to hang
themself. It's hard to see how anyone could think it makes sense
to silently convert -1 to 18446744073709551615 without even a
warning.
This compiles:
```
void main() {
void foo(int x) {}
void bar(uint x) {}
bar(-1.to!uint);
}
```
This doesn't:
```
void main() {
void foo(int x) {}
void bar(uint x) {}
foo(-1.to!long);
}
```
Re: How to work with hashmap from memutils properly?
On Wednesday, 16 February 2022 at 10:31:38 UTC, Siarhei Siamashka wrote: On Friday, 11 February 2022 at 19:04:41 UTC, Sergey wrote: Is this an attempt to implement a high performance solution for the Benchmarks Game's LRU problem in D language? Yes. There is no D version there. And I'm just curious how fast is D in those problems. Sorry for late question - I can't find page with benchmark results, can you please share url? Thanks
Re: How to work with hashmap from memutils properly?
On Friday, 11 February 2022 at 19:04:41 UTC, Sergey wrote: Is this an attempt to implement a high performance solution for the Benchmarks Game's LRU problem in D language? Yes. There is no D version there. And I'm just curious how fast is D in those problems. Dlang (LDC), Crystal, Rust and C++ (Clang) all can generate equally fast code. That's because they are using the same LLVM backend for generating code. If you encounter a significant performance difference, then there has to be a good reason for that. And figuring out what exactly causes this difference allows to fix the under-performing code in most cases. A better question is how much effort is required to reach _peak_ performance using each of these programming languages? Or how much effort is required to reach _good enough_ performance? Let's look at the benchmark results from that site: * https://programming-language-benchmarks.vercel.app/d-vs-rust * https://programming-language-benchmarks.vercel.app/crystal-vs-rust * https://programming-language-benchmarks.vercel.app/d-vs-crystal It may seem like Rust is kinda winning there. But is it a faster language? Or did some people just invest a lot of their time into creating better Rust code for these benchmarks? This time is not tracked and not compared for different languages, while it's probably the most important metric. My personal opinion is that both Dlang and Crystal primarily focus on developer convenience and rapid development. Rust focuses on extreme safety at the expense of developer convenience. C++ is neither safe nor convenient, but at least it's fast and has excellent backward compatibility with the old code. Does it make sense to spend time on improving D code on that benchmark site and reach performance parity with the other languages? I don't know. It is interesting finding about the size of the LRU. Already seen your comment in the benchmark github. Yes, I took a look and their initial implementation of the LRU benchmark for Crystal was initially written by somebody, who is apparently not very fluent with the language. This was difficult for me to ignore, so I had an impulse to fix it and this escalated into a kind of Rust vs. Crystal performance duel. Now the size of the LRU cache has been changed to something more reasonable in that benchmark and hash tables are back in the game :-) You can try to contribute your D code to this benchmark site and then work on making it faster. Though version with memutils still not working :) Do you suspect that it's a bug in https://github.com/etcimon/memutils ? I never heard about this library before. But associative arrays are important enough and it's reasonable to expect a decent implementation in the standard library without having to use some third-party magic sauce for that.
