Re: synchronized/shared associative array .require error
On Saturday, 3 September 2022 at 14:37:16 UTC, Steven
Schveighoffer wrote:
On 9/2/22 3:15 PM, cc wrote:
Tried casting away shared as a workaround but I assume that
will cause some kind of TLS catastrophe.
I think it will be fine, but you may have an issue. You are
returning a non-shared `VAL`, but your class is `shared`, which
means `table`, and all the `VAL` and `KEY` inside must also be
`shared`.
If you cast away `shared` you have to put it back upon return.
TLS should not be involved here at all, so there is no problem
there.
-Steve
Alright, so this is safe then?
```d
alias VAL[KEY] T;
auto require(KEY key) {
auto unsharedT = cast(T) table;
auto r = unsharedT.require(key);
table = cast(shared) unsharedT;
return cast(shared) r;
}
```
Was a bit surprised to see mutating `unsharedT` left `table`
unchanged and needed reassigning.
A basic bitshifting tutorial thing
I wrote out this tutorial for bitshifting in D and it's probably not the best but it gets the general idea across for new users on how to have multiple values reside in one memory address. Here is the link to the tutorial https://github.com/jordan4ibanez/bitshifting_practice/blob/main/source/app.d
Re: How to link a msvcr120.dll in an inverse recursive way after a Windows .exe binary deployment
On Sunday, 4 September 2022 at 15:16:47 UTC, BoQsc wrote: **Folder structure** .\msvcr120.dll .\folder1\HelloWorld.exe .\folder2\HelloWorld.exe You don't need to do this. msvcr120.dll is already shipped with the DMD compiler at [DMD-install-folder]\windows\bin64\msvcr120.dll. (It is also in [DMD-install-folder]\windows\bin). You can access it directly from there. When you run your EXE... the OS looks for the DLL in the same folder of the EXE- if it cannot find it it looks in the folders specified in your PATH. You can test if this is the case by executing 'where msvcr120.dll' at a DOS console command prompt. If the DLL is reachable in any folder in your PATH environment variable these specific path(s) will be displayed. In this case you don't need to do anything - the EXE should be able to run and load the DLL. The fact that you get this error indicate this is not the case. You can do 1 of the following 2 things: - add your DMD bin64 (or bin) path to the PATH environment variable. --or-- - Copy the DLL to C:\Windows\System32\ - that will for sure already be in your PATH so you don't need to modify your PATH environment variable.
Re: Tracing out error that causes compiler crash
I tried to compile on the Raspberry Pi 400, now I'm getting segmentation fault during compilation with LDC. Still no idea what causes it, nor how to reduce it. Moved the codebase to a new repository, gave it a proper DOMString implementation instead of using it as a template name, and I'm still getting no luck compiling it. Current link: https://github.com/ZILtoid1991/newxml I might try to comment out the bodies of the functions and force them to return an initial value, to see if there's something wrong with the insides of the functions.
Re: Tracing out error that causes compiler crash
On Sunday, 4 September 2022 at 08:17:13 UTC, Nick Treleaven wrote: You may be able to use dustmite to automatically reduce the code to a minimal test case: https://dlang.org/blog/2020/04/13/dustmite-the-general-purpose-data-reduction-tool/ Send my regards to the planet smasher. What do I pass as the tester?
Re: BetterC stack traces?
On Sunday, 4 September 2022 at 17:43:01 UTC, IchorDev wrote: I'm trying to implement a custom exception system in BetterC. Does anyone know how I'd go about getting a stack trace so that I can print it to stdout? :) I was thinking of utilising UDAs & `__LINE__` but it turns out that UDAs don't let you inject code, which is a shame! You can use `libunwind` for this: https://www.nongnu.org/libunwind/ It's a C library, but it should work for D too.
BetterC stack traces?
I'm trying to implement a custom exception system in BetterC. Does anyone know how I'd go about getting a stack trace so that I can print it to stdout? :) I was thinking of utilising UDAs & `__LINE__` but it turns out that UDAs don't let you inject code, which is a shame!
Re: Why do failed contracts don't dump stack backtrace in unittests?
On 9/4/22 09:35, Paul Backus wrote: // TODO: omit stack trace only if assert was thrown // directly by the unittest. Thank you but I mean... :) I can understand removing a backtrace from the eyes of an end user but the consumer of a unittest output is a developer, no? Ali
Re: Why do failed contracts don't dump stack backtrace in unittests?
On Sunday, 4 September 2022 at 14:14:55 UTC, Ali Çehreli wrote: The program output is different whether an Error is thrown from main or from the unittest block: Because the default test runner catches the Error, and doesn't print the stack trace: https://github.com/dlang/dmd/blob/25799d3841ea87246c56532f6f91d9a1e34d8d8f/druntime/src/core/runtime.d#L599-L620 There's even a comment about it: // TODO: omit stack trace only if assert was thrown // directly by the unittest.
Re: How to link a msvcr120.dll in an inverse recursive way after a Windows .exe binary deployment
I've been reading up fairly recently on RPATH for *nix which does what you want. Unfortunately as far as I've found there is no way to do this on Windows without an extra executable.
How to link a msvcr120.dll in an inverse recursive way after a Windows .exe binary deployment
 **Folder structure** .\msvcr120.dll .\folder1\HelloWorld.exe .\folder2\HelloWorld.exe Basic binaries produced by DMD.exe compiler require Microsoft Compiler Runtime DLL As you might know that a basic D Language example `HelloWorld.exe` requires `msvcr120.dll` to work. Linking inverse recursively? **To not include** `msvcr120.dll` into every `.exe` executable's `.\folder\` **and to not marginally increase the overall size of the project**: I'd like to link every `.\folder\.exe` binary to the `.\msvcr120.dll` dynamic library. **Notice** Launching the `.exe` binary with external script to change the `path` variable is not a solution. I'd like the `.exe` binary to "know" and try to search for `.\msvcr120.dll` by itself after clicking it to launch.
Why do failed contracts don't dump stack backtrace in unittests?
The program output is different whether an Error is thrown from main or
from the unittest block:
void foo(string s)
in (s != "hello") {
}
unittest {
foo("hello"); // No stack backtrace
}
void main() {
foo("hello"); // Yes stack backtrace
}
Ali
Re: Best practice for dub registry package and module names
On Sunday, 4 September 2022 at 03:50:56 UTC, Ali Çehreli wrote: For example, there is fixedsizearray, which does not belong to any package: Yeah, this is bad design since two separate people might reuse the name and then end users - even if it comes through a couple layers of dependencies they didn't even know about - can see conflicts when they try to link the program. You really need globally unique D names. On the other hand, arsd-official:minigui does have a package. (And that answers a question: Dash character is acceptable in package and module names.) dub allows dash. D does not. The dub name and the D name do not have to match (I personally consider this yet another design flaw in dub, but it is what it is). The reason mine is called "arsd-official" on dub is because someone else registered "arsd" before me, but they didn't keep up with changes, so I had to do it myself but the name was already taken. But remember, the dub package name and the D package/module names are completely separate. D knows absolutely nothing about dub and dub knows very little about D. You should have them match when you can for user convenience, but it doesn't actually check it. How does that work? When the following dependency added to a user's project, "arsd-official:minigui": "~>10.9.1" does dub pull the entirety of arsd-official and then use minigui module from it? Yes, dub always pulls its top level thing in full. Then I had to specify a long list of subpackages in dub.json to let it understand the independent modules. Dub is unbelievably and embarrassingly bad. It really is a disappointment, but you can make it somewhat work if you repeat yourself enough times. Downloading a few extra kilobytes of D code is the least of its problems.
Re: Best practice for dub registry package and module names
On Sunday, 4 September 2022 at 01:52:11 UTC, Ali Çehreli wrote: Should the package be the author's name: acehreli.a, acehreli.b, and acehreli.c? This is what I'd suggest. You want something that nobody else is likely to step on throughout the entirety of the D ecosystem. It doesn't have to literally be your name, but it should be something unique and probably arbitrary at the top level. This way you can use it as much as you want without worrying about conflicting with someone else. Then you have the more descriptive name as the module. Your dub package name is then a combination of these to make that unique too. So you might have dub package `acehreli-a` which has the D module `acehreli.a`. What about module names? If the type is 'struct MyCache', should the module name be mycache, or my_cache, or my-cache? Module names must be valid D identifiers, so no dash there. Whether you use _ or squeeze the words together is up to you, I'd say pick whichever one is easier to read. I usually squeeze words together.
Re: Tracing out error that causes compiler crash
On Saturday, 3 September 2022 at 21:20:01 UTC, solidstate1991 wrote: During unittest in my own fork of std.experimental.xml (link: https://github.com/ZILtoid1991/experimental.xml ), potentially an error so severe is present, that it causes to crash the compiler (both DMD and LDC2, on Windows). I was able to separate the issue by commenting out all unittests, then re-enabling them one-by-one seeing when it crashes the compiler, but wasn't able to track down the issues. However, `domimpl.d` is a 2000+ line monster, with a huge templated class that nests multiple other classes. You may be able to use dustmite to automatically reduce the code to a minimal test case: https://dlang.org/blog/2020/04/13/dustmite-the-general-purpose-data-reduction-tool/ Send my regards to the planet smasher.
