Re: importC Error: undefined identifier `__atomic_thread_fence`
On Friday, June 21, 2024 12:39:44 PM MDT mw via Digitalmars-d-learn wrote: > Looks like `__atomic_thread_fence` is a GCC built-in function, so > how to make importC recognize it? dmd cannot handle it. gcc or ldc might, but dmd generally needs standard C code. Stuff like gcc built-ins basically has to be removed from the file (either literally or via a #define). Unfortunately, since I haven't really done anything with importC, I can't give good info on how to do that properly (outside of simply removing it from the file). Looking over https://dlang.org/spec/importc.html this section might be useful: https://dlang.org/spec/importc.html#_builtins So, you can probably edit that file to make it work, though what you should probably do is open a bug report for it - https://issues.dlang.org/ - and if the correct solution is indeed to edit that file, then that will hopefully lead to the file being updated (and if you're feeling particularly motivated, you can always open a pull request - https://github.com/dlang/dmd/). - Jonathan M Davis
Re: ImportC "no include path set"
On Saturday, 22 June 2024 at 10:47:42 UTC, bachmeier wrote: I don't normally use Dub for this reason (it takes longer for me to figure out how to create the dub.json than it's worth). I'd expect "dflags" to work, but I haven't tried, and I'm not sure how much of ImportC even works with GDC. It doesn't seem to be documented, but there is a `cImportPaths` argument, which presumably does what you want: https://github.com/dlang/dub/blob/a8da51eb8a5485956622282f2339ec5a39c8c761/source/dub/recipe/json.d#L233
[Issue 24624] New: Struct with both bitfields and a slice or class instance ref doesn't compile.
https://issues.dlang.org/show_bug.cgi?id=24624
Issue ID: 24624
Summary: Struct with both bitfields and a slice or class
instance ref doesn't compile.
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: jonas.mee...@gmail.com
Compiling the following code with -preview=bitfields:
---
struct S
{
char[] slice;
bool flag:1;
}
---
Produces: "Error: cannot take address of bit-field `flag`".
After experimenting it seems that:
- A struct with bitfields cannot contain:
- Slices of any type.
- Class instance references.
- Structs, enums or references to classes containing any of the above.
- Bitfields in classes or named unions are not affected.
- When wrapping the bitfields in a named struct, the issue doesn't happen.
- With -betterC or ldcs --fno-rtti, the issue doesn't happen.
The issue might involve TypeInfo_Struct?
More failing examples:
---
struct S1
{
bool flag:1;
Object o;
}
struct Wrapper2
{
void[] wrapped;
}
struct S2
{
bool flag:1;
Wrapper2 wrapper;
}
struct Wrapper3
{
Object wrapped;
}
struct S3
{
bool flag:1;
Wrapper3 wrapper;
}
enum Wrapper4 : string
{
empty = ""
}
struct S4
{
bool flag:1;
Wrapper4 wrapper;
}
---
--
[Issue 24623] Rename version CppRuntime_Clang/Gcc to CppRuntime_libcxx/libstdcxx.
https://issues.dlang.org/show_bug.cgi?id=24623 --- Comment #3 from johanenge...@weka.io --- libcpp is the GCC C PreProcessing library). libstdc++v3 refers to itself as (lib)stdcxx in code. libc++ similarly. Changed title of bug report: cpp --> cxx --
[Issue 24623] Rename version CppRuntime_Clang/Gcc to CppRuntime_libcxx/libstdcxx.
https://issues.dlang.org/show_bug.cgi?id=24623 johanenge...@weka.io changed: What|Removed |Added Summary|Rename version |Rename version |CppRuntime_Clang/Gcc to |CppRuntime_Clang/Gcc to |CppRuntime_libcpp/libstdcpp |CppRuntime_libcxx/libstdcxx |. |. --
Re: Phobos 3 Development is Open!
On Wednesday, 28 February 2024 at 10:51:52 UTC, Adam Wilson wrote: The first PR for Phobos 3 has been merged into the Phobos repo! Oh, I remembered one wish: Please, make Phobos modules disableable! Something like: [...] enum isFileIOisAvailable = __traits(compiles, /* some druntime filesIO-related code */); static if (isFileIOisAvailable): [...] That is, for example, if the code using core.stdc.stdio.fopen is not compiles that means files or stream subsystem isn't available and, thus, it is not need to provide std.file module and so on related to the files/std streams subsystem. The same is for any other Phobos modules relying on support of any hardware features.
[Issue 24594] ImportC: Packed struct has wrong layout
https://issues.dlang.org/show_bug.cgi?id=24594 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16611 "Fix bugzilla 24594 - ImportC: Packed struct has wrong layout" was merged into master: - d02e12b8ddcf66d435265d443af34f8d3f25faaf by Tim Schendekehl: Fix bugzilla 24594 - ImportC: Packed struct has wrong layout Packed structs were already implemented with the Microsoft syntax (e.g. `#pragma pack(push, 1)`), but the GCC syntax was ignored. https://github.com/dlang/dmd/pull/16611 --
[Issue 24623] Rename version CppRuntime_Clang/Gcc to CppRuntime_libcpp/libstdcpp.
https://issues.dlang.org/show_bug.cgi?id=24623 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16610 "Rename CppRuntime_Clang/Gcc to CppRuntime_libcpp/libstdcpp." was merged into master: - 349b493810d9fe6f1997df93d23194589f170584 by Johan Engelen: Fix bugzilla issue 24623: Rename CppRuntime_Clang/Gcc to CppRuntime_libcpp/libstdcpp. Add libcpp and libstdcpp -target= option recognition. https://github.com/dlang/dmd/pull/16610 --
[Issue 24594] ImportC: Packed struct has wrong layout
https://issues.dlang.org/show_bug.cgi?id=24594 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @tim-dlang created dlang/dmd pull request #16611 "Fix bugzilla 24594 - ImportC: Packed struct has wrong layout" fixing this issue: - Fix bugzilla 24594 - ImportC: Packed struct has wrong layout Packed structs were already implemented with the Microsoft syntax (e.g. `#pragma pack(push, 1)`), but the GCC syntax was ignored. https://github.com/dlang/dmd/pull/16611 --
Re: ImportC "no include path set"
On Friday, 21 June 2024 at 17:40:39 UTC, mw wrote: On Monday, 6 February 2023 at 14:35:53 UTC, bachmeier wrote: On Monday, 6 February 2023 at 06:55:02 UTC, Elfstone wrote: So how am I supposed to set the include path? https://dlang.org/spec/importc.html#preprocessor The -Ppreprocessorflag switch passes preprocessorflag to the preprocessor. So if you normally use `-I/foo`, you'd add `-P-I/foo`. How to do this in the dub.json file? and work across DMD/LDC/GDC? Thanks. I don't normally use Dub for this reason (it takes longer for me to figure out how to create the dub.json than it's worth). I'd expect "dflags" to work, but I haven't tried, and I'm not sure how much of ImportC even works with GDC.
[Issue 24623] Rename version CppRuntime_Clang/Gcc to CppRuntime_libcpp/libstdcpp.
https://issues.dlang.org/show_bug.cgi?id=24623 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @JohanEngelen updated dlang/dmd pull request #16610 "Rename CppRuntime_Clang/Gcc to CppRuntime_libcpp/libstdcpp https://issues.dlang.org/show_bug.cgi?id=24546 ." fixing this issue: - Rename CppRuntime_Clang/Gcc to CppRuntime_libcpp/libstdcpp. Add libcpp and libstdcpp -target= option recognition. Fix bugzilla 24623 https://issues.dlang.org/show_bug.cgi?id=24623 https://github.com/dlang/dmd/pull/16610 --
[Issue 24623] New: Rename version CppRuntime_Clang/Gcc to CppRuntime_libcpp/libstdcpp.
https://issues.dlang.org/show_bug.cgi?id=24623 Issue ID: 24623 Summary: Rename version CppRuntime_Clang/Gcc to CppRuntime_libcpp/libstdcpp. Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: johanenge...@weka.io There is unfortunately an error in druntime CppRuntime version naming. I think this arises from the wrong assumption that libstdc++ is bound to GCC and libc++ to clang. This is not the case. For those in the know, it is actually very confusing to read CppRuntime_Clang in the code. "What is that?!" Clang works with both libstdc++ and libc++ and it very much depends on the OS/installation/user which library is actually used. I had to find this bit in d_do_test.d to learn what it stands for: version (CppRuntime_Gcc) envData.cxxCompatFlags = " -L-lstdc++ -L--no-demangle"; else version (CppRuntime_Clang) envData.cxxCompatFlags = " -L-lc++ -L--no-demangle"; Ah, ok, so CppRuntime_Clang stands for libc++. Please, please rename CppRuntime_Gcc => CppRuntime_libstdcpp CppRuntime_Clang => CppRuntime_libcpp The -target option should be fixed similarly. --
Re: ImportC in a Dub project
On Friday, 28 October 2022 at 19:08:47 UTC, Steven Schveighoffer wrote: On 10/28/22 2:43 PM, Carsten Schlote wrote: On Friday, 28 October 2022 at 18:31:25 UTC, Steven Schveighoffer wrote: Are you passing the c file to the compiler? Also, you must be ... By default dub does not build C files (as evidenced by your command line). It may not even let you I don't know, but try: ```json "sourceFiles" : ["source/zstdc_binding.c"] ``` What if the dub.json target is a staticLibrary? Right now I have this error: ``` gdc: fatal error: cannot specify ‘-o’ with ‘-c’, ‘-S’ or ‘-E’ with multiple files ``` Since both (a single) .d file and the single line .c (include ".h") file is on the command line: e.g. ``` gdc -dip25 -Wno-error=builtin-declaration-mismatch -fall-instantiations -c -o /.dub/cache/liblfdsd/0.3.4/build/library-unittest-swOTDhNpx8l9YtK1BPSAow/liblfdsd.a -fdebug -g -Werror -Wall -Wno-deprecated /.dub/packages/liblfdsd/0.3.4/liblfdsd/source/liblfdsd.d /.dub/packages/liblfdsd/0.3.4/liblfdsd/source/liblfdsd_ImportC.c -Xlinker -Xlinker -llfdsd -Xlinker -llfdsdc -Xlinker -llfds711 ``` Thanks.
importC Error: undefined identifier `__atomic_thread_fence`
Looks like `__atomic_thread_fence` is a GCC built-in function, so how to make importC recognize it? Thanks.
Re: ImportC "no include path set"
On Monday, 6 February 2023 at 14:35:53 UTC, bachmeier wrote: On Monday, 6 February 2023 at 06:55:02 UTC, Elfstone wrote: So how am I supposed to set the include path? https://dlang.org/spec/importc.html#preprocessor The -Ppreprocessorflag switch passes preprocessorflag to the preprocessor. So if you normally use `-I/foo`, you'd add `-P-I/foo`. How to do this in the dub.json file? and work across DMD/LDC/GDC? Thanks.
[Issue 24622] Modify const data with void[] concatenation/append
https://issues.dlang.org/show_bug.cgi?id=24622 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16606 "Fix Bugzilla 24622 - Modify const data with void[] concatenation/append" was merged into master: - d8ecf576e77ab611668a344b961b5c4663818852 by Nick Treleaven: Fix Bugzilla 24622 - Modify const data with void[] concatenation/append https://github.com/dlang/dmd/pull/16606 --
[Issue 24622] Modify const data with void[] concatenation/append
https://issues.dlang.org/show_bug.cgi?id=24622 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel created dlang/dmd pull request #16606 "Fix Bugzilla 24622 - Modify const data with void[] concatenation/append" fixing this issue: - Fix Bugzilla 24622 - Modify const data with void[] concatenation/append https://github.com/dlang/dmd/pull/16606 --
[Issue 24622] New: Modify const data with void[] concatenation/append
https://issues.dlang.org/show_bug.cgi?id=24622
Issue ID: 24622
Summary: Modify const data with void[] concatenation/append
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: n...@geany.org
Related to issue 17148.
void g(int*[] a, const(int*)[] b) @system
{
void[] va = a;
va[] = va.init ~ b; // a now contains b's data
*a[0] = 0; // modify const data
}
Appending a const array to void[] also needs to be disallowed.
typeof(void[] ~ const(void)[]) should be const(void)[], not void[].
--
[Issue 24621] ImportC: can't access members in static array
https://issues.dlang.org/show_bug.cgi?id=24621 ryuukk_ changed: What|Removed |Added Keywords||ImportC --
[Issue 24621] New: ImportC: can't access members in static array
https://issues.dlang.org/show_bug.cgi?id=24621
Issue ID: 24621
Summary: ImportC: can't access members in static array
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ryuukk@gmail.com
```C
typedef struct {
char* buffer;
} stuff;
void testtest(void)
{
stuff s[1];
s->buffer = NULL;
}
```
I get:
```
it.c(11): Error: `buffer` is not a member of `stuff[1]`
```
DMD: 2.109.0
--
[Issue 24620] ImportC: Missing builtins floating point (GCC)
https://issues.dlang.org/show_bug.cgi?id=24620 Richard (Rikki) Andrew Cattermole changed: What|Removed |Added CC||alphaglosi...@gmail.com Summary|ImportC: can't compile |ImportC: Missing builtins |cJSON |floating point (GCC) --- Comment #2 from Richard (Rikki) Andrew Cattermole --- https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html --
[Issue 24620] ImportC: can't compile cJSON
https://issues.dlang.org/show_bug.cgi?id=24620 --- Comment #1 from anonymous4 --- It's `isinf` definition on your system. --
[Issue 24620] ImportC: can't compile cJSON
https://issues.dlang.org/show_bug.cgi?id=24620 ryuukk_ changed: What|Removed |Added Keywords||ImportC --
[Issue 24620] New: ImportC: can't compile cJSON
https://issues.dlang.org/show_bug.cgi?id=24620
Issue ID: 24620
Summary: ImportC: can't compile cJSON
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ryuukk@gmail.com
clone: https://github.com/DaveGamble/cJSON
create: 'it.c' (otherwise it complains about `main.d(5): Error: import
`main.cJSON` is used as a type`)
```
#include "cJSON.c"
```
create: 'main.d'
```D
import it;
void main()
{
cJSON* request = cJSON_Parse(null);
}
```
compile: 'dmd main.d it.c -of=bug && ./bug'
```
$ dmd main.d it.c -of=bug && ./bug
In file included from :
/usr/include/dlang/dmd/importc.h:101:8: warning: undefining "__has_feature"
101 | #undef __has_feature
|^
/usr/include/dlang/dmd/importc.h:104:8: warning: undefining "__has_extension"
104 | #undef __has_extension
|^~~
cJSON.c(569): Error: undefined identifier `__builtin_isinf_sign`
cJSON.c(1205): Error: `buffer` is not a member of `printbuffer[1]`
cJSON.c(1206): Error: `length` is not a member of `printbuffer[1]`
cJSON.c(1207): Error: `format` is not a member of `printbuffer[1]`
cJSON.c(1208): Error: `hooks` is not a member of `printbuffer[1]`
cJSON.c(1228): Error: `buffer` is not a member of `printbuffer[1]`
cJSON.c(1242): Error: `buffer` is not a member of `printbuffer[1]`
cJSON.c(1251): Error: `buffer` is not a member of `printbuffer[1]`
```
--
[Issue 24619] Allow pointer slicing for slices of length 0 or 1
https://issues.dlang.org/show_bug.cgi?id=24619 --- Comment #2 from Bolpat --- (In reply to Dennis from comment #1) > Similar situation to this: > > https://github.com/dlang/dmd/pull/15581#issuecomment-1738649867 It has some vague similarity, but AFAICT, PR 15581 is almost the reverse, going from slice to pointer to the first element. The `@safe` way to get a pointer to the first element is `[0]`. If `xs` has compile-time-known length, surely the compiler does not do a run-time check for index bounds. On the other hand, going from pointer to 1-element slice, best one can do is `(() @trusted => ptr[0 .. 1])()`, and that is unnecessary. I don’t know about the semantics about a slice with a `null` pointer component and a length of 1, but my bet would be that it should be exactly as any other `null` dereference. Any index except `0` would throw an `ArrayIndexError` and the index `0` is a `null` dereference. > Do you have a use case? The use case is passing a single value to a function that expects a slice of such values. While one can create a length-1 array with a copy of the value, not all values are copyable and not all values are cheap to copy. I can’t imagine a use case for `[0 .. 0]` though. I just included that one because it’s obviously safe and if we make an exception for `[0 .. 1]`, it would be weird to disallow it. --
[Issue 24619] Allow pointer slicing for slices of length 0 or 1
https://issues.dlang.org/show_bug.cgi?id=24619 Dennis changed: What|Removed |Added CC||dkor...@live.nl Summary|[DIP1000] Allow pointer |Allow pointer slicing for |slicing for slices of |slices of length 0 or 1 |length 0 or 1 | --- Comment #1 from Dennis --- Similar situation to this: https://github.com/dlang/dmd/pull/15581#issuecomment-1738649867 Do you have a use case? --
[Issue 24619] [DIP1000] Allow pointer slicing for slices of length 0 or 1
https://issues.dlang.org/show_bug.cgi?id=24619 Bolpat changed: What|Removed |Added Keywords||safe CC||qs.il.paperi...@gmail.com --
[Issue 24619] New: [DIP1000] Allow pointer slicing for slices of length 0 or 1
https://issues.dlang.org/show_bug.cgi?id=24619 Issue ID: 24619 Summary: [DIP1000] Allow pointer slicing for slices of length 0 or 1 Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: qs.il.paperi...@gmail.com Allow `()[0 .. 1]` (and `()[0 .. 0]`) in `@safe` code. --
Re: Why is this happening to my software? An illegal instruction error.
On Tuesday, 18 June 2024 at 23:07:47 UTC, Murilo wrote: I've created a software which performs the Fermat's Primality Test, however if I input a very big number it causes an error saying "Illegal instruction (core dumped)". Does anyone know why? I've used GDB and here is the message: Program received signal SIGILL, Illegal instruction. 0x555e40b0 in _D3std8internal4math11biguintcore7BigUint3powFNaNbNfNkMSQCcQCbQBvQBtQBjmZQs () Here is the link to the source code: https://github.com/MuriloMir/Fermat-primality-test That has to be an assertion failure happening at runtime. IIRC the `ud2` instruction (causing SIGILL) is used in -betterC mode. If you look at biguintcore.d you'll see a couple of them, e.g https://github.com/dlang/phobos/blob/master/std/internal/math/biguintcore.d#L1042.
[Issue 12885] const union wrongly converts implicitly to mutable
https://issues.dlang.org/show_bug.cgi?id=12885 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Dlang Bot --- dlang/dmd pull request #16594 "Fix Bugzilla 12885 - const union wrongly converts implicitly to mutable" was merged into master: - 7531b1ae708a478900984734aec044d4dd38379c by Nick Treleaven: Fix Bugzilla 12885 - const union wrongly converts implicitly to mutable https://github.com/dlang/dmd/pull/16594 --
Re: Why is this happening to my software? An illegal instruction error.
On Wednesday, 19 June 2024 at 00:02:38 UTC, H. S. Teoh wrote: Among the above causes, I'd say (1) is the most likely, (2) is the 2nd most likely if (1) isn't the cause. Thank you, I will try this software on other computers to see if it's number 2. I've reviewed the code and I don't think it could be number 1.
Re: Why is this happening to my software? An illegal instruction error.
On Wednesday, 19 June 2024 at 07:46:07 UTC, ryuukk_ wrote: why do you convert the number to string? My mistake, I thought BigInt() only took strings, I've corrected the code.
[Issue 24618] New: redefined core type errors should show fully qualified name
https://issues.dlang.org/show_bug.cgi?id=24618 Issue ID: 24618 Summary: redefined core type errors should show fully qualified name Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: diagnostic Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: schvei...@gmail.com Some types in D are considered core to the language, but are defined in the library. For example: size_t ptrdiff_t string Object TypeInfo One can redefine these symbols in a module, but the resulting confusion in the error messages is really hard to parse by the person reading the message. For example, I stared at an error message for about 20 minutes thinking I had a broken compiler that looked like this: cannot pass argument `(*aa.impl).keysz` of type `immutable(uint)` to parameter `size_t len` Of course, a normal immutable uint can be converted to a normal size_t. But I had accidentally redefined size_t to an enum. My suggestion is to prefix any symbols that shadow ones defined in object.d with the fully qualified name. This could be based on a chart of core symbols like string or size_t, or it could be all symbols. So if an error message is referring to a locally-defined size_t, it could say instead: cannot pass argument `(*aa.impl).keysz` of type `immutable(uint)` to parameter `local.mod.size_t len` This at least gives a hint that the type is not the size_t you are expecting. --
[Issue 24617] array runtime erroneously copies flags from existing block
https://issues.dlang.org/show_bug.cgi?id=24617 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel created dlang/dmd pull request #16599 "Fix Bugzilla 24617 - array runtime erroneously copies flags from exis…" fixing this issue: - Fix Bugzilla 24617 - array runtime erroneously copies flags from existing block https://github.com/dlang/dmd/pull/16599 --
Re: Google Auth API
On Tuesday, 18 June 2024 at 01:38:04 UTC, Vahid wrote: Hi, Has anyone here had experience implementing the Google Auth Library in DLang? Specifically, I am looking for guidance on handling OAuth 2.0 using JWT. Are there any current libraries available for this purpose? Oh a pain-point of D =( The regular answer from D web-Gods: "oh it is very simple. just implement it by yourself" :) But we have something (not sure if anything from the list is working): Hunt solution (when I've tried it recently - it wasn't built and gave me an error) - https://code.dlang.org/packages/hunt-jwt (fork jwt) --- Plain JWT - https://code.dlang.org/packages/jwt (uses ideas of jwtd) - https://code.dlang.org/packages/jwtd-es (fork jwtd) - https://code.dlang.org/packages/jwtd --- Vibe-based solutions - https://code.dlang.org/packages/oauth - https://code.dlang.org/packages/vibe-auth --- ARSD CGI - (openD) https://github.com/adamdruppe/arsd/blob/master/oauth.d (OAuth 1.0)
Re: Get Private Key in a File
On 19/06/2024 7:23 AM, Vahid wrote: Hi, I have a private key file and aim to retrieve the private key for utilization in other functions. In PHP, there exists a function named 'openssl_pkey_get_private' for this purpose. Is there a corresponding function available in D to achieve the same outcome? That function from PHP wraps a bunch of calls into OpenSSL. Long story short, you need to understand OpenSSL BIO's and call into ``PEM_write_bio_PKCS8PrivateKey`` with the ``EVP_PKEY`` already loaded which isn't the easiest thing to do. My version of the code: https://github.com/Project-Sidero/eventloop/blob/master/source/sidero/eventloop/certificates/defs.d#L168C17-L168C46 You'll also need an OpenSSL binding such as: https://github.com/D-Programming-Deimos/openssl
Re: Why is this happening to my software? An illegal instruction error.
On Tuesday, 18 June 2024 at 23:07:47 UTC, Murilo wrote: I've created a software which performs the Fermat's Primality Test, however if I input a very big number it causes an error saying "Illegal instruction (core dumped)". Does anyone know why? I've used GDB and here is the message: Program received signal SIGILL, Illegal instruction. 0x555e40b0 in _D3std8internal4math11biguintcore7BigUint3powFNaNbNfNkMSQCcQCbQBvQBtQBjmZQs () Here is the link to the source code: https://github.com/MuriloMir/Fermat-primality-test ```D else if (BigInt(to!string(tester)) ^^ number % number != tester) ``` why do you convert the number to string?
Re: Why is this happening to my software? An illegal instruction error.
On Tue, Jun 18, 2024 at 11:07:47PM +, Murilo via Digitalmars-d-learn wrote: > I've created a software which performs the Fermat's Primality Test, > however if I input a very big number it causes an error saying > "Illegal instruction (core dumped)". Does anyone know why? > > I've used GDB and here is the message: > Program received signal SIGILL, Illegal instruction. > 0x555e40b0 in > _D3std8internal4math11biguintcore7BigUint3powFNaNbNfNkMSQCcQCbQBvQBtQBjmZQs > () [...] There are a few possible causes: 1) There's a pointer bug in your program that corrupted some memory, causing a function pointer to point to something that isn't a function, and when the CPU tried to execute instructions from there it triggered a fault. 2) The optimized assembly code in std.bigint may contain an instruction that's incompatible with your CPU, so a fault is triggered when the CPU tried to execute it. 3) Your program may have been incorrectly linked, and the ABI incompatibility could have triggered this fault. 4) You may be using std.bigint for numbers far bigger than the range it's designed for. While this is unlikely to be the cause of this error (I've tested std.bigint with numbers up to 100,000+ digits without any crashes), using an unusually large number may cause the code to do something unexpected that may trigger the crash. The chances are pretty low that this is actually the case, though. Among the above causes, I'd say (1) is the most likely, (2) is the 2nd most likely if (1) isn't the cause. T -- Truth, Sir, is a cow which will give [skeptics] no more milk, and so they are gone to milk the bull. -- Sam. Johnson
Why is this happening to my software? An illegal instruction error.
I've created a software which performs the Fermat's Primality Test, however if I input a very big number it causes an error saying "Illegal instruction (core dumped)". Does anyone know why? I've used GDB and here is the message: Program received signal SIGILL, Illegal instruction. 0x555e40b0 in _D3std8internal4math11biguintcore7BigUint3powFNaNbNfNkMSQCcQCbQBvQBtQBjmZQs () Here is the link to the source code: https://github.com/MuriloMir/Fermat-primality-test
Re: aligned struct field weirdness
On Tuesday, 18 June 2024 at 09:10:28 UTC, realhet wrote:
I tried to narrow the problem, but I wasn't able, but I guess
I've found another solution: There is a part in my framework
which works with LDC2 1.28, but that's 'illegal' with later
versions.
Oh yeah. That is many versions ago! Released in 2021.
That's why I'm stuck in the past, but now it adds more
motivation to catch up with the latest version.
Another motivation -- even if you found this was a bug and it is
still in the latest compiler, the fix will go into the *latest
compiler*, not the one that works with your code!
That part declares an enum, whose members have UDA's pointing
to the enum's members.
With 2 step parsing it is valid, but later compiler versions
don't like this.
It's a quite big state machine graph, I have to refactor this
to eliminate this self-referencing to catch up with the latest
compiler.
Hm... a possibility is to change the UDAs to strings, and then
post-process the strings into the actual members using
`__traits(getMember, State, name)`
So e.g.:
```d
enum State {
@"state2" state1,
@"state1" state2
}
```
-Steve
Re: SHA256 Signature
On Tuesday, 18 June 2024 at 17:18:18 UTC, Erdem wrote:
On Tuesday, 18 June 2024 at 06:49:24 UTC, Vahid wrote:
How can I create a SHA256 signature hash in D?
Does this do what you want?
```d
import std.digest.md;
import std.digest.sha;
import std.stdio;
void main()
{
auto key = makeDigest!SHA256();
key.put(cast(ubyte[])"çorba");
auto result = key.finish();
writeln(result.toHexString());
}
```
Thank you for your reply.
I have found that the issue is related to the 'Secret' variable.
In fact, I possess a private key that needs to sign it for the
JWT. How can I accomplish this? It appears that RSA encryption is
required in this scenario.
Re: Demo for The Art of Reflection released (a 3D game and engine fully written in D)
On Tuesday, 18 June 2024 at 08:49:57 UTC, cookiewitch wrote: On Friday, 24 May 2024 at 17:45:31 UTC, Lewis wrote: Hello! Not sure if it's of interest, but I've been developing a 3D game and engine in D for a few years, and finally have a demo up on Steam for anyone interested in poking around (Windows only unfortunately). [...] https://store.steampowered.com/app/2290770/The_Art_of_Reflection/ I've just played through the demo, it's impressive! It's a pleasantly confusing experience and my brain hurts now. Also, it works perfectly fine on Linux via Proton. Added to my wishlist, as I always like to share with others projects built in D :)
Re: SHA256 Signature
On Tuesday, 18 June 2024 at 06:49:24 UTC, Vahid wrote:
How can I create a SHA256 signature hash in D?
Does this do what you want?
```d
import std.digest.md;
import std.digest.sha;
import std.stdio;
void main()
{
auto key = makeDigest!SHA256();
key.put(cast(ubyte[])"çorba");
auto result = key.finish();
writeln(result.toHexString());
}
```
[Issue 24583] di generator emits return scope and scope return in wrong order
https://issues.dlang.org/show_bug.cgi?id=24583 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16595 "Fix bugzilla 24583 - di generator emits return scope and scope return…" was merged into master: - d77327ff35452958c5412811393f6d6d0bbdd574 by Dennis Korpel: Fix bugzilla 24583 - di generator emits return scope and scope return in wrong order https://github.com/dlang/dmd/pull/16595 --
[Issue 24617] New: array runtime erroneously copies flags from existing block
https://issues.dlang.org/show_bug.cgi?id=24617
Issue ID: 24617
Summary: array runtime erroneously copies flags from existing
block
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: schvei...@gmail.com
If an array slice starts from a GC allocated block that is *not* marked
appendable, the appendable flag never gets set until appending occurs.
example:
```d
struct S
{
int[1] val;
}
void main()
{
auto s = new S;
int[] arr = s.val[];
assert(arr.capacity == 0); // starts out without appendability
arr.length = 2;
assert(arr.capacity > 0); // this fails
arr.reserve(100);
assert(arr.capacity > 0); // this fails
arr ~= 10;
assert(arr.capacity > 0); // finally, this succeeds
}
```
The issue is that the `__arrayAlloc` function copies the original bits instead
of using the typeinfo to decide the new array bits if a BlkInfo has already
been looked up. I guess the thought is that using the TypeInfo to build the
bits is more expensive, and we "already have something".
Options are to just always use the typeinfo, or to check for the appendable bit
before using the old bits (but copying the other bits might be questionable as
well).
--
Re: aligned struct field weirdness
On Tuesday, 18 June 2024 at 02:26:00 UTC, Steven Schveighoffer wrote: All the code you posted here looks fine to me. It compiles and runs fine on run.dlang.io (even with the `version(none)` changed to `version(all)`, or using `scoped!B`). Thank You for checking. Also to add to the weirdness, this happens only with release build. I tried to narrow the problem, but I wasn't able, but I guess I've found another solution: There is a part in my framework which works with LDC2 1.28, but that's 'illegal' with later versions. That's why I'm stuck in the past, but now it adds more motivation to catch up with the latest version. That part declares an enum, whose members have UDA's pointing to the enum's members. With 2 step parsing it is valid, but later compiler versions don't like this. It's a quite big state machine graph, I have to refactor this to eliminate this self-referencing to catch up with the latest compiler. So now I have fixes that seem to be working, and soon with the latest compiler I will check it again, and hopefully the fixes aren't needed anymore.
Re: Demo for The Art of Reflection released (a 3D game and engine fully written in D)
On Friday, 24 May 2024 at 17:45:31 UTC, Lewis wrote: Hello! Not sure if it's of interest, but I've been developing a 3D game and engine in D for a few years, and finally have a demo up on Steam for anyone interested in poking around (Windows only unfortunately). [...] https://store.steampowered.com/app/2290770/The_Art_of_Reflection/ I've just played through the demo, it's impressive! It's a pleasantly confusing experience and my brain hurts now. Also, it works perfectly fine on Linux via Proton.
Re: Sovereign Tech Fund: call for proposals
On Tuesday, 18 June 2024 at 03:21:25 UTC, Forest wrote: On Monday, 17 June 2024 at 19:44:15 UTC, angel wrote: "Slang" is actually a great name for a programming language. Someone else thought so, too: https://www.jedsoft.org/slang/doc/html/slang.html Weird.. Because S language is pretty old. It was developed in Bell Labs and became a predecessor of R language (as an open source answer to S). Both languages are statistical one.
[Issue 24616] spam
https://issues.dlang.org/show_bug.cgi?id=24616 anonymous4 changed: What|Removed |Added Status|NEW |RESOLVED URL|https://www.veronapress.com | |/contributed/thc-gummies-to | |p-5-weed-edibles-reviewed/a | |rticle_dff5ffae-f1cb-11ee-a | |555-23b82b574988.html | Resolution|--- |MOVED Summary|THC Gummies |spam --
Re: Sovereign Tech Fund: call for proposals
On Monday, 17 June 2024 at 19:44:15 UTC, angel wrote: "Slang" is actually a great name for a programming language. In german we can have a D-alekt of D :-)
SHA256 Signature
Hi, How can I create a SHA256 signature hash in D? Something similar to the PHP code below: ```php openssl_sign($body, $signature, $secret, OPENSSL_ALGO_SHA256); ``` I've tried the code below without success: ```d auto signature = body.representation.hmac!SHA256(secret.representation).toHexString!(LetterCase.lower).to!string; ```
Re: Sovereign Tech Fund: call for proposals
On Monday, 17 June 2024 at 17:33:06 UTC, M. M. wrote: https://www.sovereigntechfund.de/news/new-proposals-criteria-process-timeline Nice catch! Funkwerk could definitely apply. Their system is valuable for society.
[Issue 24616] THC Gummies
https://issues.dlang.org/show_bug.cgi?id=24616 THC Gummies changed: What|Removed |Added URL||https://www.veronapress.com ||/contributed/thc-gummies-to ||p-5-weed-edibles-reviewed/a ||rticle_dff5ffae-f1cb-11ee-a ||555-23b82b574988.html --
Re: Sovereign Tech Fund: call for proposals
On Monday, 17 June 2024 at 19:44:15 UTC, angel wrote: "Slang" is actually a great name for a programming language. Someone else thought so, too: https://www.jedsoft.org/slang/doc/html/slang.html
Re: aligned struct field weirdness
On Monday, 17 June 2024 at 19:45:18 UTC, realhet wrote: Hello, I'm having a weird case of access violation. Often times, you are focused on something that isn't the problem, but *triggers* the problem. Not saying it's not a compiler error, it could be. But chances are pretty low. If you cannot get this to happen unless you use your custom writeln thing, I'd focus on trying to figure out if that custom writeln is doing something incorrect. All the code you posted here looks fine to me. It compiles and runs fine on run.dlang.io (even with the `version(none)` changed to `version(all)`, or using `scoped!B`). -Steve
Google Auth API
Hi, Has anyone here had experience implementing the Google Auth Library in DLang? Specifically, I am looking for guidance on handling OAuth 2.0 using JWT. Are there any current libraries available for this purpose?
[Issue 24602] Internal compiler error: failed to detect static initialization of associative array
https://issues.dlang.org/show_bug.cgi?id=24602 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #16592 "Fix Bugzilla 24602 - Internal compiler error: failed to detect static…" was merged into stable: - 17200412f5d1ebcf73fca199d86aaba1ced1bdfe by Dennis Korpel: Fix Bugzilla 24602 - Internal compiler error: failed to detect static initialization of associative array https://github.com/dlang/dmd/pull/16592 --
[Issue 24615] ImportC can't import Python 3.12 header
https://issues.dlang.org/show_bug.cgi?id=24615 Atila Neves changed: What|Removed |Added Keywords||ImportC --
[Issue 24615] New: ImportC can't import Python 3.12 header
https://issues.dlang.org/show_bug.cgi?id=24615 Issue ID: 24615 Summary: ImportC can't import Python 3.12 header Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: atila.ne...@gmail.com // foo.d import python; // python.c #include % dmd -c -P-I/usr/include/python3.12 foo.d In file included from : /usr/include/dlang/dmd/importc.h:101:8: warning: undefining "__has_feature" 101 | #undef __has_feature |^ /usr/include/dlang/dmd/importc.h:104:8: warning: undefining "__has_extension" 104 | #undef __has_extension |^~~ /usr/include/linux/types.h(12): Error: __int128 not supported /usr/include/linux/types.h(13): Error: unsigned __int128 not supported --
[Issue 24583] di generator emits return scope and scope return in wrong order
https://issues.dlang.org/show_bug.cgi?id=24583 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @dkorpel created dlang/dmd pull request #16595 "Fix bugzilla 24583 - di generator emits return scope and scope return…" fixing this issue: - Fix bugzilla 24583 - di generator emits return scope and scope return in wrong order https://github.com/dlang/dmd/pull/16595 --
Re: What's the latest GDC stable release version?
and GDC 14: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=09992f8b881aa2dfbee1e9d6954c3ca90cd3fe41 So GDC 14.1 includes the D language at v2.108.0. This is wonderful: Synchronizing with the upstream release of v2.108.0. BTW, if the following two pages are updated with version information, that will be great: https://dlang.org/download.html https://gdcproject.org/downloads
[Issue 12885] const union wrongly converts implicitly to mutable
https://issues.dlang.org/show_bug.cgi?id=12885 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #9 from Dlang Bot --- @ntrel created dlang/dmd pull request #16594 "Fix Bugzilla 12885 - const union wrongly converts implicitly to mutable" fixing this issue: - Fix Bugzilla 12885 - const union wrongly converts implicitly to mutable https://github.com/dlang/dmd/pull/16594 --
aligned struct field weirdness
Hello,
I'm having a weird case of access violation.
I tried to narrow the problem and put up a reproducible testCase
on compilerexploer, but it requires my framework too which
overrides std.stdio.writeln() in order to produce colorful text,
and logging, etc.
The error is an access violation when I access the struct in the
f() function.
Sometimes it can be fixed (marked the place.)
In one sentence: It is an aligned struct field, whose struct is
given to a class as a template parameter.
Maybe the weirdness is caused by the align(16)? When the fields
of the struct are placed on the instance of the class?
I know it's not reproduceable, maybe it was a bug that had been
already fixed. So I only ask if the situation is familiar to
someone, please tell me, what tricks I need to avoid.
I can avoid the align using dummy fields.
I can allocate the struct with new.
But it's a bummer, that the nicest version is unstable.
```
import het;
struct S
{
int a;
align(16)//<-this triggers it
int[4] b;
}
class A(T)
{
version(none)
{ T u; }
else
{
T* p; //<- this fixes it. (The struct is not on the class
surface)
ref u() { return *p; }
this() { p = new T; }
}
}
class B: A!S
{ void f() { writeln(u.text/+<-The access violation can be
here+/); } }
void main()
{
//writeln("a"); <- this fixes it
auto b = new B; //<-scoped! can trigger it too
b.f;
}
```
Thank You in advance.
Re: Sovereign Tech Fund: call for proposals
"Slang" is actually a great name for a programming language. On Monday, 17 June 2024 at 17:46:30 UTC, M. M. wrote: On Monday, 17 June 2024 at 17:33:06 UTC, M. M. wrote: https://www.sovereigntechfund.de/news/new-proposals-criteria-process-timeline Chance for slang to apply? Slang --> Dlang
[Issue 24602] Internal compiler error: failed to detect static initialization of associative array
https://issues.dlang.org/show_bug.cgi?id=24602 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @dkorpel created dlang/dmd pull request #16592 "Fix Bugzilla 24602 - Internal compiler error: failed to detect static…" fixing this issue: - Fix Bugzilla 24602 - Internal compiler error: failed to detect static initialization of associative array https://github.com/dlang/dmd/pull/16592 --
Re: What's the latest GDC stable release version?
On Monday, 17 June 2024 at 16:20:55 UTC, mw wrote: On Monday, 17 June 2024 at 15:33:46 UTC, Dejan Lekic wrote: On Sunday, 16 June 2024 at 16:26:08 UTC, mw wrote: Hi, What's the latest GDC stable release version? Stable release version is the same as stable GCC release version. Find it here: https://gcc.gnu.org/ (GDC is part of the GCC project for years) Thanks, but it's not clear which D (dmd) language version they are corresponding to，e.g. I found: https://forum.dlang.org/post/qbjmtdyglcwmzekyx...@forum.dlang.org GCC version 12.2 has been released. Updated the D front-end from v2.100.0-rc1 to v2.100.1. But for GCC 13, 14, the status is less clear: are these version stable and released, and when? https://forum.dlang.org/post/amsduzcnbgvptaxjt...@forum.dlang.org He was also preparing to push out GDC 13.2. GDC 13 maps to DMD 2.103. He had backported around ten regression fixes for it so far. GDC 14, the current development version, was still tracking the upstream DMD mainline. There were no blockers there and everything was going fine merging from DMD master down to GDC. The changes document for gcc-12 did provide this information: https://gcc.gnu.org/gcc-12/changes.html However, the changes document for gcc-13 and gcc-14 appear not to. Iain does always document updates to the language version: https://gcc.gnu.org/git/?p=gcc.git=search=HEAD=commit=D+front-end To get the D versions for any version of GDC, you can triangulate commits. That will lead you to this commit for GDC 13: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=328477f6ee82d27fa6bb09617644d409be300688 and GDC 14: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=09992f8b881aa2dfbee1e9d6954c3ca90cd3fe41 So GDC 14.1 includes the D language at v2.108.0. ~Brian
Re: Sovereign Tech Fund: call for proposals
On Monday, 17 June 2024 at 17:33:06 UTC, M. M. wrote: https://www.sovereigntechfund.de/news/new-proposals-criteria-process-timeline Chance for slang to apply? Slang --> Dlang
Re: What's the latest GDC stable release version?
On Monday, 17 June 2024 at 15:33:46 UTC, Dejan Lekic wrote: On Sunday, 16 June 2024 at 16:26:08 UTC, mw wrote: Hi, What's the latest GDC stable release version? Stable release version is the same as stable GCC release version. Find it here: https://gcc.gnu.org/ (GDC is part of the GCC project for years) Thanks, but it's not clear which D (dmd) language version they are corresponding to，e.g. I found: https://forum.dlang.org/post/qbjmtdyglcwmzekyx...@forum.dlang.org GCC version 12.2 has been released. Updated the D front-end from v2.100.0-rc1 to v2.100.1. But for GCC 13, 14, the status is less clear: are these version stable and released, and when? https://forum.dlang.org/post/amsduzcnbgvptaxjt...@forum.dlang.org He was also preparing to push out GDC 13.2. GDC 13 maps to DMD 2.103. He had backported around ten regression fixes for it so far. GDC 14, the current development version, was still tracking the upstream DMD mainline. There were no blockers there and everything was going fine merging from DMD master down to GDC.
Re: What's the latest GDC stable release version?
On Sunday, 16 June 2024 at 16:26:08 UTC, mw wrote: Hi, What's the latest GDC stable release version? Stable release version is the same as stable GCC release version. Find it here: https://gcc.gnu.org/ (GDC is part of the GCC project for years)
Re: Pointer to dlang spec for this alias construct?
On Monday, 17 June 2024 at 05:05:06 UTC, Jonathan M Davis wrote: alias Unshared(T) = T; alias Unshared(T: shared U, U) = U; ... Unshared is an eponymous template. https://dlang.org/spec/template.html#implicit_template_properties And it's using a shortcut syntax. ... The second template uses a template specialization https://dlang.org/spec/template.html#parameters_specialization No wonder I couldn't find it in the spec; I was looking for an "alias" language feature. alias as used here leans on a template mechanism--specialization. It might have taken many readings of the spec to have hunted that down, so--thank you. It's quite an interesting mechanism. D is quite easy for a C programmer to get started with, but it certainly has its depths! Andy
[Issue 24587] Allow negated qualifiers in cast expressions
https://issues.dlang.org/show_bug.cgi?id=24587 --- Comment #2 from Bolpat --- I just found out `cast(const)` not only adds `const` if it’s not present, it also removes any other qualifiers. (In reply to RazvanN from comment #1) > I don't find this very useful. Not an argument. > It seems that we are complicating the type > system only to obtain something that is actually more confusing. The type system remains unchanged. It only adds a concise syntax to cast away specific qualifiers without having to query the type. You can argue the syntax is confusing. I don’t think it is. > cast() is > used to drop all qualifiers whereas if you want to keep some of them you can > just cast to the appropriate combination of qualifiers (i.e. cast(const > shared)). Yes, but that’s not easy. One has to know which qualifiers are present. In a template-context, one has to tediously query them, and in a non-template context, one has to look them up and repeat them, and if they change, too bad, the cast now does something unintended. > That way [with `cast(Quals)`] you know exactly what the type is at the cast > site, > whereas introducing the possibility to negate a single qualifier makes it > ambiguous with regards to what the type at the cast site is. When is that a use-case? When is “I don’t care what qualifiers a type has, make it XYZ” a use case? The only one I see is when you want to extract information of what template instance or whatnot something is, and qualifiers are in the way. I.e. in an unevaluated context. Of course, if you have a `const shared LongAndComplicated!(Template!Instance) x`, it’s easy to write `cast(const)x`, but here I have to look up its type, see that it’s `const` and repeat(!) that qualifier. What I want is not repeat anything and express intent, i.e. the intent to remove `shared`. What did a `cast(const)` intend? Add `const`? Remove something else and retain `const`? Who knows. > Also, can you provide a concrete code example where this is useful? I can’t because I don’t work professionally with D. Any example I’d provide would be dismissed as “toy project example” anyways. > It seems > to me that this is a theoretical proposal without any actual practical > usefulness. Among the negated qualifier casts, most definitely `cast(!shared)` would be useful. If you `cast()`, you might end up casting away `const` and mutate stuff that you shouldn’t. For `cast(!shared)` on a `const shared` type object, I see two uses: 1. You intend to read, then you lock a mutex, `cast(!shared)` and do the read while being assured by the compiler you’re not mutating anything as `const` (or anything else) goes nowhere. Also, `const` member functions are used instead of non-`const` ones. 2. You intend to write, and because `cast(!shared)` leaves `const` intact, you’ll get a compile-error instead of UB if you accidentally write to something that’s `const`. I don’t know where in run-time code you want to override all qualifiers. In general, I’d assume you always want to add or remove specific ones. E.g. template code can’t really use `cast(const)` not because it adds `const` (that’s obvious), but because it removes `shared` when it’s present and does so “silently”. --
[Issue 21644] spam
https://issues.dlang.org/show_bug.cgi?id=21644 anonymous4 changed: What|Removed |Added URL|https://www.fieldengineer.c | |om/blogs| Summary|job search engines |spam --
[Issue 24588] spam
https://issues.dlang.org/show_bug.cgi?id=24588 anonymous4 changed: What|Removed |Added URL|http://www.veronapress.com/ | |contributed/you-can-now-buy | |-magic-mushrooms-online-100 | |-legal/article_40c42984-e7d | |4-11ee-b152-5778bdfa4e1d.ht | |ml | Summary|Buy Psilocybin Magic|spam |Mushrooms | --
[Issue 24605] spam
https://issues.dlang.org/show_bug.cgi?id=24605 anonymous4 changed: What|Removed |Added Keywords|accepts-invalid | URL|https://www.veronapress.com | |/contributed/disposable-car | |ts-the-5-best-brands-for-sa | |le/article_e95bfdee-f1c3-11 | |ee-8fe8-fb94a994b030.html | Summary|Disposable Carts|spam --
[Issue 23797] Improve type-testing `is` expressions
https://issues.dlang.org/show_bug.cgi?id=23797 --- Comment #1 from Bolpat --- As for the right-hand side of `is(Type == Keyword)` for function pointer and delegate types, it also makes sense to ask if they’re carrying attributes. The keyword attributes should be allowed, but I think also user-defined ones should be allowed. Also visibility can be allowed for any symbols. The same for the simplified `is …` syntax. `DG is @nogc` is clear to read. --
[Issue 24608] spam
https://issues.dlang.org/show_bug.cgi?id=24608 anonymous4 changed: What|Removed |Added Status|NEW |RESOLVED URL|https://www.themountainmail | |.com/contributed/article_58 | |eb12f8-e7c9-11ee-8f71-6be28 | |c8df8d4.html| Resolution|--- |MOVED Summary|Magic Mushrooms |spam --
[Issue 24611] Cannot explicitly instantiate template function with `auto ref`
https://issues.dlang.org/show_bug.cgi?id=24611 --- Comment #1 from Bolpat --- Grammar change needed for the suggested fix: ```diff TemplateArgument: Type + ref Type AssignExpression Symbol ``` --
[Issue 24614] Can’t throw in -betterC mode with -preview=dip1008 (@nogc Exceptions)
https://issues.dlang.org/show_bug.cgi?id=24614 Richard (Rikki) Andrew Cattermole changed: What|Removed |Added Status|NEW |RESOLVED CC||alphaglosi...@gmail.com Resolution|--- |WONTFIX --- Comment #1 from Richard (Rikki) Andrew Cattermole --- D classes depend upon druntime. Runtime exceptions ala ``Throwable`` hierarchy depend upon druntime. As of right now this is expected and correct behavior for runtime exceptions to not work in -betterC. There is a high desire to see some variant of value based sumtype returns in the language hooked into ``throw`` and ``catch`` that do not depend upon druntime, however that is not currently in the DIP queue due to a dependency upon sumtypes. --
[Issue 24614] New: Can’t throw in -betterC mode with -preview=dip1008 (@nogc Exceptions)
https://issues.dlang.org/show_bug.cgi?id=24614
Issue ID: 24614
Summary: Can’t throw in -betterC mode with -preview=dip1008
(@nogc Exceptions)
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
Maybe this is invalid, but the Description section of DIP 1008 ("Exceptions and
@nogc") gives the impression that this should be possible.
Quote from DIP 1008:
> The issue is [exceptions being GC allocated] […] prevents building D programs
> that do not link in the GC runtime.
The prime example for D programs without GC runtime are `-betterC` programs.
That `-betterC` mode does not allow for Exceptions may be due to reasons other
than being unable to GC-allocate them, but maybe not, and therefore this bug
report.
--
[Issue 24607] __traits(isDeprecated, ...) result incorrect on an alias member
https://issues.dlang.org/show_bug.cgi?id=24607 Nick Treleaven changed: What|Removed |Added Summary|__traits(isDeprecated, ...) |__traits(isDeprecated, ...) | not working on a member|result incorrect on an ||alias member --
[Issue 24607] __traits(isDeprecated, ...) not working on a member
https://issues.dlang.org/show_bug.cgi?id=24607 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org Severity|enhancement |normal --- Comment #1 from Nick Treleaven --- > pragma(msg, __traits(isDeprecated, A, "foo"))); The docs say it takes only one argument (like other trait docs), though actually the result is true if both A and "foo" are deprecated. https://dlang.org/spec/traits.html#isDeprecated > Should support checking on member > pragma(msg, __traits(isDeprecated, A.bar3)); That is actually the correct syntax, but the result is false when it should be true. (I am adding a member symbol example in this pull https://github.com/dlang/dlang.org/pull/3851). --
[Issue 17148] Copying from const(void)[] to void[] breaks immutable
https://issues.dlang.org/show_bug.cgi?id=17148 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dmd pull request #16583 "Fix Bugzilla 17148 - Copying from const(void)[] to void[] breaks immu…" was merged into master: - e93d798c2bccffed4c66bd797e10e32cdab22d82 by Nick Treleaven: Fix Bugzilla 17148 - Copying from const(void)[] to void[] breaks immutable https://github.com/dlang/dmd/pull/16583 --
Re: Pointer to dlang spec for this alias construct?
On Sunday, June 16, 2024 10:32:50 PM MDT Andy Valencia via Digitalmars-d-learn
wrote:
> In the alias:
>
> alias Unshared(T) = T;
> alias Unshared(T: shared U, U) = U;
>
> as used in:
>
> cast(Unshared!mytype)value
>
> turns a mytype with shared attribute into one without shared.
>
> I deduce the alias is using some sort of type matching and
> decomposition?
>
> I've read through the language spec, and didn't spot this
> mechanism. Can somebody tell me what section of the spec covers
> this very interesting mechanism?
>
> Thanks in advance,
> Andy
Unshared is an eponymous template.
https://dlang.org/spec/template.html#implicit_template_properties
And it's using a shortcut syntax.
alias Unshared(T) = T;
alias Unshared(T: shared U, U) = U;
is equivalent to
template Unshared(T)
{
alias Unshared = T;
}
template Unshared(T : shared U, U)
{
alias Unshared = U;
}
The alias is simply a normal alias that's the result of evaluating the
template.
https://dlang.org/spec/declaration.html#alias
The second template uses a template specialization
https://dlang.org/spec/template.html#parameters_specialization
that matches based on the fact that the given type implicitly converts to
shared, and the shared U part separates out shared from the type so that you
can get the type without shared. That's then used for the alias to get the
type without shared. The way that the shared U part works comes from is
expressions:
https://dlang.org/spec/expression.html#is_expression
Eponymous templates get used in a variety of circumstances, not just with
aliases. For instance, they can be used with enums, e.g.
enum sizeOf(T) = T.sizeof;
which would be equivalent to
template sizeOf(T)
{
enum sizeOf = T.sizeof;
}
and they're used with function templates, e.g.
T identity(T)(T value)
{
return value;
}
is equivalant to
template identity(T)
{
T identity(T value)
{
return value;
}
}
- Jonathan M Davis
Re: Pointer to dlang spec for this alias construct?
On Monday, 17 June 2024 at 04:32:50 UTC, Andy Valencia wrote: In the alias: alias Unshared(T) = T; alias Unshared(T: shared U, U) = U; as used in: cast(Unshared!mytype)value turns a mytype with shared attribute into one without shared. I deduce the alias is using some sort of type matching and decomposition? I've read through the language spec, and didn't spot this mechanism. Can somebody tell me what section of the spec covers this very interesting mechanism? Thanks in advance, Andy not sure if it works the same with template arguments but here is the rules https://dlang.org/spec/expression.html#IsExpression
Pointer to dlang spec for this alias construct?
In the alias: alias Unshared(T) = T; alias Unshared(T: shared U, U) = U; as used in: cast(Unshared!mytype)value turns a mytype with shared attribute into one without shared. I deduce the alias is using some sort of type matching and decomposition? I've read through the language spec, and didn't spot this mechanism. Can somebody tell me what section of the spec covers this very interesting mechanism? Thanks in advance, Andy
[Issue 24592] ImportC: Bitfield layout wrong for int64 on 32-bit Linux
https://issues.dlang.org/show_bug.cgi?id=24592 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16590 "Fix bugzilla 24592 - ImportC: Bitfield layout wrong for int64 on 32-b…" was merged into master: - e427ca656d801bcc438afce7fd6fba94d0e860c5 by Tim Schendekehl: Fix bugzilla 24592 - ImportC: Bitfield layout wrong for int64 on 32-bit Linux Type ulong is 64-bit on 32-bit Linux, but has 32-bit alignment. This affects the layout of bitfields. Also add a new test for ImportC bitfields, which compares size, alignment and layout with the host C++ compiler. The existing tests compared with fixed values instead. https://github.com/dlang/dmd/pull/16590 --
[Issue 24613] New: Bitfield with 64 bits always zero
https://issues.dlang.org/show_bug.cgi?id=24613
Issue ID: 24613
Summary: Bitfield with 64 bits always zero
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: tim.dl...@t-online.de
Values for a bitfield with 64 bits are not stored and remain 0.
```
struct S
{
ulong a:64;
}
void main()
{
S s;
s.a = 1;
assert(s.a == 1); // Fails: s.a is 0
}
```
This affects both ImportC and normal D with -preview=bitfields.
--
[Issue 24592] ImportC: Bitfield layout wrong for int64 on 32-bit Linux
https://issues.dlang.org/show_bug.cgi?id=24592 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @tim-dlang created dlang/dmd pull request #16590 "Fix bugzilla 24592 - ImportC: Bitfield layout wrong for int64 on 32-b…" fixing this issue: - Fix bugzilla 24592 - ImportC: Bitfield layout wrong for int64 on 32-bit Linux Type ulong is 64-bit on 32-bit Linux, but has 32-bit alignment. This affects the layout of bitfields. Also add a new test for ImportC bitfields, which compares size, alignment and layout with the host C++ compiler. The existing tests compared with fixed values instead. https://github.com/dlang/dmd/pull/16590 --
Re: Demo for The Art of Reflection released (a 3D game and engine fully written in D)
On Friday, 24 May 2024 at 17:45:31 UTC, Lewis wrote: Hello! Not sure if it's of interest, but I've been developing a 3D game and engine in D for a few years, and finally have a demo up on Steam for anyone interested in poking around (Windows only unfortunately). - All code (engine and game) written in D. Shaders in HLSL. External libraries used for some subsystems (eg. PhysX, FMOD) - Custom 3D DX11 renderer using PBR + IBL - Supports mirror rendering, with hundreds of simultaneous mirrors and recursive mirrors (passing seamlessly through mirrors is a core game mechanic) - Asset burning/cooking system for textures, geometry, materials, and shaders. All asset types support hotswapping. - Flexible code hotswapping, by putting 99% of the game and engine in a DLL - Scrappy in-game level editor that supports editing during gameplay Since I'm building the game as a commercial project I haven't released source code, but plan to open source it after the game releases. Happy though of course to answer any questions, share code snippets, techniques, general experiences, etc. https://store.steampowered.com/app/2290770/The_Art_of_Reflection/ Nice, experience is quite smooth. But it does feel a bit like a tech demo. I want to know why I am trying to get out of this wizard home. Maybe he is also walking around here and I need to hide my movement from him as well later in the game :)
What's the latest GDC stable release version?
Hi, What's the latest GDC stable release version? The GDC link on: https://dlang.org/download.html is very out dated. I think it at least should show the latest version number, and link to the announcement. Thanks.
Beerconf June
# BEERCONF! Beerconf for June is approaching, it will be here in 2 weeks on June 29-30. Hope to see you all then! Obligatory link to beerconf T's: https://www.zazzle.com/store/dlang_swag/products?cg=196874696466206954 ## What is Beerconf? Check out the [wiki article](https://wiki.dlang.org/Beerconf) ## Presentations? Let me know if you have anything you want to schedule, via discord, email, or anywhere you find me. I will announce it, and get you an audience! Last month I did a quick demonstration of IES, and I just remembered yesterday that I haven't posted the video for it. I'll do that soon. Cheers! -Steve
[Issue 24612] New: Explicitly given `auto ref` parameter can’t bind by lvalue by value
https://issues.dlang.org/show_bug.cgi?id=24612
Issue ID: 24612
Summary: Explicitly given `auto ref` parameter can’t bind by
lvalue by value
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
```d
void f(T)(auto ref T x) {}
void main()
{
int x;
f!long(x); // Error: template `f` is not callable using argument types
`!(long)(int)`
}
```
This should instantiate `f` as `f!long(long x)`, as `int` converts to `long`
and `cast(long)x` is an rvalue.
I don’t know how far with implicit conversions this should go, but it should
work for built-in integer and floating-point types. It should also work for
class/interface types with inheritance relationship, and while binding those by
`auto ref` is weird to do explicitly, such a binding might end up from
templates that bind arbitrary type objects that happen to be class handles in
the user’s code. Then:
```d
Exception e = new Exception("");
f!Object(e); // Currently error, should be pass-by-value
```
With my proposed fix for Issue 24611, users could opt-into `ref` explicitly if
they need to.
--
[Issue 24612] Explicitly given `auto ref` parameter can’t bind by lvalue by value
https://issues.dlang.org/show_bug.cgi?id=24612 Bolpat changed: What|Removed |Added Priority|P1 |P2 CC||qs.il.paperi...@gmail.com --
[Issue 24611] Cannot explicitly instantiate template function with `auto ref`
https://issues.dlang.org/show_bug.cgi?id=24611 Bolpat changed: What|Removed |Added Priority|P1 |P2 CC||qs.il.paperi...@gmail.com --
[Issue 24611] New: Cannot explicitly instantiate template function with `auto ref`
https://issues.dlang.org/show_bug.cgi?id=24611
Issue ID: 24611
Summary: Cannot explicitly instantiate template function with
`auto ref`
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
```d
void f(T)(auto ref T x) {}
void main()
{
int x;
f(x); // infers T = int, auto ref = ref
f(0); // infers T = int, auto ref = Ø
f!int(x); // same as first
f!int(0); // same as second
auto fp = !int; // Error: cannot explicitly instantiate template function
with `auto ref`
alias f_int = f!int; // Error: cannot explicitly instantiate template
function with `auto ref`
}
```
The spec nowhere says that one can’t explicitly instantiate function templates
with `auto ref` parameters.
I suggest we extend template type parameters and let them be bound not just to
a type, but also, optionally, a `ref`. Any template type parameter is
effectively a bool–type pair where the bool says if `ref` was given as an
argument.
Supplying `ref` only makes a difference when the type parameter is used as a
function parameter type. In every other use, it is ignored. When a template
type parameter is `ref` and used as a function parameter type, that parameter
must be `auto ref`, otherwise it is an error. If it is an `auto ref` parameter,
it becomes `ref`. Explicit instantiations of function templates with `auto ref`
parameters become valid and if no `ref` is given for the template type
argument, the `auto ref` becomes pass-by-value.
As for IFTI, nothing changes. The `ref` as part of a template type argument
will be inferred even if the corresponding type of the bool–type pair is given.
(Unlike say in C++, where the information of being reference is part of the
type.)
Example:
```d
void f(T)(auto ref T x) {}
void main()
{
int x;
f(x); // infers T = ref int, therefore auto ref = ref
f(0); // infers T = int, therefore auto ref = Ø
f!int(x); // same as first, T = ref int, ref inferred
f!int(0); // same as second, no ref inferred as argument is rvalue
// nothing really changed up until here
auto fp1 = !int; // Okay, T = int, pass-by-value
auto fp2 = !(ref int); // T = ref int, pass-by-reference
alias f_int = f!int; // Okay, T = int, pass-by-value
alias f_ref_int = f!(ref int); // T = ref int, pass-by-reference
```
--
[Issue 24610] Basic range-based `toString` not recognized
https://issues.dlang.org/show_bug.cgi?id=24610 Max Samukha changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Max Samukha --- Ok, my bad. The range wants a char, not string. (Anyway, nothing is more annoying than the silent acceptance of malformed toString.) --
[Issue 24610] Basic range-based `toString` not recognized
https://issues.dlang.org/show_bug.cgi?id=24610 --- Comment #1 from Max Samukha --- `import std.stdio;` is unnecessary. --
[Issue 24610] New: Basic range-based `toString` not recognized
https://issues.dlang.org/show_bug.cgi?id=24610
Issue ID: 24610
Summary: Basic range-based `toString` not recognized
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: maxsamu...@gmail.com
import std.array;
import std.format;
struct S
{
void toString(Output)(ref Output output)
{
import std.range: put;
output.put("S");
}
}
void main()
{
S s;
auto output = appender!(char[]);
s.toString(output);
assert(output[] == "S"); // ok
output.clear();
formattedWrite!"%s"(output, s);
import std.stdio;
assert(output[] == "S"); // fail
}
The `toString` is implemented according to the spec
(https://dlang.org/phobos/std_format_write.html), and the formatter should use
it.
--
[Issue 24597] FreeBSD/OpenBSD: Enable ELF_COMDAT
https://issues.dlang.org/show_bug.cgi?id=24597 --- Comment #3 from Dlang Bot --- dlang/dmd pull request #16589 "merge stable" was merged into master: - aa5f1b4a6014a52c7118dde37274f8d336dc2ec0 by Brian Callahan: Fix Bugzilla 24597 https://github.com/dlang/dmd/pull/16589 --
[Issue 24566] condition that starts with runtime value and uses compile time array does not short circuit
https://issues.dlang.org/show_bug.cgi?id=24566 --- Comment #3 from Dlang Bot --- dlang/dmd pull request #16589 "merge stable" was merged into master: - d92734bdac94e09538911838051f8edb54b25185 by Timon Gehr: Fix bugzilla issue 24566 - condition that starts with runtime value and uses compile time array does not short circuit https://github.com/dlang/dmd/pull/16589 --
