Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Saturday, 3 December 2022 at 22:46:31 UTC, DLearner wrote: I agree should not change existing meaning of ``` int[] A; ``` But why not allow a construct for value-type variable arrays like: ``` int[*] B; ``` There's no reason to add more complexity to the language for this when the same result can already be achieved using existing language features.
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Wednesday, 30 November 2022 at 02:29:03 UTC, Paul Backus wrote: [...] If you want a dynamic array with value semantics, you should use a library-defined container type (e.g., `struct DynamicArray`). I agree should not change existing meaning of ``` int[] A; ``` But why not allow a construct for value-type variable arrays like: ``` int[*] B; ``` Best regards
Re: How to compiler dlang code on Apple M1?
On 12/3/22 1:59 PM, zoujiaqing wrote: ``` dub build --compiler=ldc2 --arch=arm64-apple-macos Starting Performing "debug" build using ldc2 for aarch64, arm_hardfloat. Building taggedalgebraic 0.11.22: building configuration [library] Building eventcore 0.9.20+commit.4.g6744ae7: building configuration [cfrunloop] Building server ~master: building configuration [application] Linking server ld: warning: ignoring file ../../../.dub/packages/taggedalgebraic-0.11.22/taggedalgebraic/.dub/build/library-debug-posix.osx.darwin-aarch64.arm_hardfloat-ldc_v1.30.0-60F6D8BEA34F8F5E792A98EA27B02D2235262A4E0795062F91FA90871411535D/libtaggedalgebraic.a, building for macOS-x86_64 but attempting to link with file built for unknown-arm64 ld: warning: ignoring file /opt/homebrew/Cellar/ldc/1.30.0_1/lib/libdruntime-ldc.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file .dub/build/application-debug-posix.osx.darwin-aarch64.arm_hardfloat-ldc_v1.30.0-7AC1A4B8AFD7D9F59DB01E667A3DCF19DD437F41E741F5937BDCF58FAE6AA922/server.o, building for macOS-x86_64 but attempting to link with file built for unknown-arm64 ld: warning: ignoring file ../../eventcore/.dub/build/cfrunloop-debug-posix.osx.darwin-aarch64.arm_hardfloat-ldc_v1.30.0-ED6AFABD5E24BB6BCED6FD74F2DE88CF39B648360CE187983206459095D4677D/libeventcore.a, building for macOS-x86_64 but attempting to link with file built for unknown-arm64 ld: warning: ignoring file /opt/homebrew/Cellar/ldc/1.30.0_1/lib/libphobos2-ldc.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 Undefined symbols for architecture x86_64: "_main", referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Error: /usr/bin/cc failed with status: 1 Error ldc2 failed with exit code 1. ``` The issue is dub. Make sure you are using the dub built for ARM. What Apple does is if any program in the same process group is x86 specific, then all the executed programs that are universal (including the linker) will switch to that mode. The linker thinks you are building on x86, even though the compiler is doing ARM64. I ran into this early on too. Switching to the dub that ships with ldc built for ARM solved it! -Steve
How to compiler dlang code on Apple M1?
``` dub build --compiler=ldc2 --arch=arm64-apple-macos Starting Performing "debug" build using ldc2 for aarch64, arm_hardfloat. Building taggedalgebraic 0.11.22: building configuration [library] Building eventcore 0.9.20+commit.4.g6744ae7: building configuration [cfrunloop] Building server ~master: building configuration [application] Linking server ld: warning: ignoring file ../../../.dub/packages/taggedalgebraic-0.11.22/taggedalgebraic/.dub/build/library-debug-posix.osx.darwin-aarch64.arm_hardfloat-ldc_v1.30.0-60F6D8BEA34F8F5E792A98EA27B02D2235262A4E0795062F91FA90871411535D/libtaggedalgebraic.a, building for macOS-x86_64 but attempting to link with file built for unknown-arm64 ld: warning: ignoring file /opt/homebrew/Cellar/ldc/1.30.0_1/lib/libdruntime-ldc.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 ld: warning: ignoring file .dub/build/application-debug-posix.osx.darwin-aarch64.arm_hardfloat-ldc_v1.30.0-7AC1A4B8AFD7D9F59DB01E667A3DCF19DD437F41E741F5937BDCF58FAE6AA922/server.o, building for macOS-x86_64 but attempting to link with file built for unknown-arm64 ld: warning: ignoring file ../../eventcore/.dub/build/cfrunloop-debug-posix.osx.darwin-aarch64.arm_hardfloat-ldc_v1.30.0-ED6AFABD5E24BB6BCED6FD74F2DE88CF39B648360CE187983206459095D4677D/libeventcore.a, building for macOS-x86_64 but attempting to link with file built for unknown-arm64 ld: warning: ignoring file /opt/homebrew/Cellar/ldc/1.30.0_1/lib/libphobos2-ldc.a, building for macOS-x86_64 but attempting to link with file built for macOS-arm64 Undefined symbols for architecture x86_64: "_main", referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Error: /usr/bin/cc failed with status: 1 Error ldc2 failed with exit code 1. ```
Re: How do you print all Unicode characters in a range - I want the subscripts, can't google a range of Unicode.
On Saturday, 3 December 2022 at 14:43:15 UTC, Adam D Ruppe wrote:
The problem is just that writeln to the console is broken. You
can either write to a function instead and load it in a text
editor
aaargh not to a "function" i meant to a "file".
like
auto f = File("test.txt", "wt");
f.writeln(s);
then open test.txt and make sure it is opened in utf-8 mode.
Re: How do you print all Unicode characters in a range - I want the subscripts, can't google a range of Unicode.
On Friday, 2 December 2022 at 05:27:40 UTC, Daniel Donnelly, Jr.
wrote:
Doesn't work. The result I get is shit:
The problem is just that writeln to the console is broken. You
can either write to a function instead and load it in a text
editor, or use a non-broken writeln like my terminal.d's
```
void main() {
// using the same string...
dstring s = "";
for (dchar i='ₐ'; i < 'ₜ'; i++)
s ~= i;
// this will output correctly
import arsd.terminal;
auto terminal = Terminal(ConsoleOutputMode.linear);
terminal.writeln(s);
// this will not
import std.stdio;
writeln(s);
}
```
Screenshot output:
http://arsdnet.net/dcode/writelnsux.png
Now, while it outputs correctly, you'll still note a bunch of
empty boxes. That's because the *font* I'm using doesn't include
those characters. If you changed fonts there's a decent chance
you can see those too.
Re: How do you print all Unicode characters in a range - I want the subscripts, can't google a range of Unicode.
On Saturday, 3 December 2022 at 14:43:15 UTC, Adam D Ruppe wrote: import arsd.terminal; oh yeah my module: can download direct and compile with your program https://github.com/adamdruppe/arsd/blob/master/terminal.d or it is also on dub https://code.dlang.org/packages/arsd-official%3Aterminal
Re: Why can't D store all UTF-8 code units in char type? (not really understanding explanation)
On 02.12.22 22:39, thebluepandabear wrote: Hm, that specifically might not be. The thing is, I thought a UTF-8 code unit can store 1-4 bytes for each character, so how is it right to say that `char` is a utf-8 code unit, it seems like it's just an ASCII code unit. You're simply not using the term "code unit" correctly. A UTF-8 code unit is just one of those 1-4 bytes. Together they form a "sequence" which encodes a "code point". And all (true) ASCII code units are indeed also valid UTF-8 code units. Because UTF-8 is a superset of ASCII. If you save a file as ASCII and open it as UTF-8, that works. But it doesn't work the other way around.
Re: Easy sockets - don't exist yet?
On Monday, 10 October 2016 at 02:54:09 UTC, Jonathan M Davis wrote: Quite some time ago, it was decided that the *stream modules as they were were unacceptable and that they needed to be replaced with something range-based That's the key! Absolutely dilettantish solution of "profi", biased on ranges. Unfortunately even TECHNICALLY stream never was a "range"! It's more like "queue of bytes", where you can never be sure you even get these bytes. Moreover - "socket stream" is such a specific stream that you cannot assume even bytes data! Many protocols rely on STRINGS, so SocketStream have to have dual nature - byte-based and string-based. Even worse - if you read stupid HTTP standard, it allows for server to reply with strings (header), followed by RAW BYTES(!). Surprise! So in this light we cannot speak about ranges AT ALL. We need stream, which supports strings and at the same time bytes. And all of that in convenient way, not just "auto b = GimmeStupidHeapOfBytesWhichAreString". Anyway, it's quite unprofessional to remove SocketStream: it DOES NOT fit at all in "range" ideology (as well as, say, Window or Button) and lives own life. "Ranges" just PART of library, not a whole library! In other words not everything in a library should follow "ranges ideology". I ask to return standard SocketStream and keep it until that "smartie" (who remove it) will write fully functional replacement. Nobody will use D if maintainers will stupidly throw away classes by own wish. Keep functionality as big as possible, because D even now, after "stable language", still lie on road edge.
Re: Easy sockets - don't exist yet?
On Saturday, 8 October 2016 at 17:52:25 UTC, Karabuta wrote: This is how a usable socket in a standard library should be http://dsfml.com/docs/sockets.html. This is using DSFML (a D bindings to SFML). Pity, doesn't exist anymore.
Re: Easy sockets - don't exist yet?
On Monday, 10 October 2016 at 07:37:48 UTC, Bauss wrote: Wrote some pretty simple sockets that you could use (Based on vibe.d though.) That's the point! STANDARD library cannot/must not rely on bloatware like vibe.d; Only small, native, non-depended socket implementation.
