Re: How does one attach a manifest file to a D executable on Windows?
On Friday, 24 May 2024 at 21:26:12 UTC, Ferhat Kurtulmuş wrote: I think this is what you need https://github.com/aferust/doitlater/tree/master/views/res No, I meant something like this: https://learn.microsoft.com/en-us/windows/win32/controls/cookbook-overview
Re: Beerconf May
Its time for another link! https://meet.jit.si/Dlang2024MayBeerConf Oh and don't forget to update your Intellij D plugin, and have your Intellij instance at 2024.1.2 there some nice improvements and bug fixes in both!
[Issue 24565] out contract variable is implicitly const
https://issues.dlang.org/show_bug.cgi?id=24565 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #2 from timon.g...@gmx.ch --- FWIW, I would prefer fixing the implementation instead of documenting this annoying behavior that makes contracts less useful. --
[Issue 24565] out contract variable is implicitly const
https://issues.dlang.org/show_bug.cgi?id=24565 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel created dlang/dlang.org pull request #3836 "[spec/function] Improve contract docs" fixing this issue: - [spec/function] Improve contract docs Move in/out grammar to respective subheadings. Use list for contract expression arguments. Fix grammar for invalid state sentences. Fix wording of postcondition best practice. Mention postcondition identifier is implicitly const. Add anchor for example subheading. Fix Bugzilla 24565 - out contract variable is implicitly const https://github.com/dlang/dlang.org/pull/3836 --
Re: The D Programming Language and Its Role in Cybersecurity
On Saturday, 25 May 2024 at 07:58:35 UTC, aberba wrote: On Friday, 24 May 2024 at 19:54:16 UTC, Steven Schveighoffer wrote: On Monday, 20 May 2024 at 21:21:24 UTC, aberba wrote: Found this article by Raymond Andrè Hagen: https://www.linkedin.com/pulse/d-programming-language-its-role-cybersecurity-raymond-andr%C3%A8-hagen-nfvgf/ My goodness this is a terrible article. Almost no substance. Is this AI generated? -Steve Lol, the author looks like a seasoned security professional. Not for long if he continues to produce such garbage. The article contains almost no arguments, only a few claims without deeper reasoning, but those are repeated in each chapter with almost the same words. I assume even an AI can do better.
Re: The D Programming Language and Its Role in Cybersecurity
On Friday, 24 May 2024 at 19:54:16 UTC, Steven Schveighoffer wrote: On Monday, 20 May 2024 at 21:21:24 UTC, aberba wrote: Found this article by Raymond Andrè Hagen: https://www.linkedin.com/pulse/d-programming-language-its-role-cybersecurity-raymond-andr%C3%A8-hagen-nfvgf/ My goodness this is a terrible article. Almost no substance. Is this AI generated? -Steve Lol, the author looks like a seasoned security professional.
[Issue 22646] [REG2.099] CT bounds checking ignores short circuit evaluation
https://issues.dlang.org/show_bug.cgi?id=22646 Steven Schveighoffer changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=24566 --
[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 Steven Schveighoffer changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=22646 --
[Issue 24566] New: condition that starts with runtime value and uses compile time array does not short circuit
https://issues.dlang.org/show_bug.cgi?id=24566
Issue ID: 24566
Summary: condition that starts with runtime value and uses
compile time array does not short circuit
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: schvei...@gmail.com
If I mix a runtime and compile time expression in a condition, short circuiting
doesn't prevent a compile-time bounds check for constant folded arrays.
```d
enum a = true;
bool b = true;
enum str = "a";
if(a && str.length > 1 && str[1] == 'a') {} // ok
if(b && str.length > 1 && str[1] == 'a') {} // compiler error
if(!b && str.length > 1 && str[1] == 'a') {} // compiler error
if(str.length > 1 && b && str[1] == 'a') {} // ok
```
The error is:
Error: string index 1 is out of bounds [0 .. 1]
If the runtime condition is not first, then it compiles.
Note that even if the runtime condition is false and should short circuit the
whole thing, the compiler still errors.
As far as I can tell, this has always been the case, so not a regression.
Though a related issue might be issue 22646.
--
Re: Parallel safe associative array?
https://code.dlang.org/packages/rust_interop_d wrapped: DashMap: is an implementation of a concurrent associative array/hashmap in Rust.
[Issue 24564] std.file.DirEntry throws Exception instead of FileException
https://issues.dlang.org/show_bug.cgi?id=24564 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #9004 "Fix Bugzilla 24564 - std.file.DirEntry throws Exception instead of Fi…" was merged into master: - 44407884d464d60f980cb73b68a8024516ec7129 by Nick Treleaven: Fix Bugzilla 24564 - std.file.DirEntry throws Exception instead of FileException https://github.com/dlang/phobos/pull/9004 --
Re: Demo for The Art of Reflection released (a 3D game and engine fully written in D)
On Friday, 24 May 2024 at 19:22:32 UTC, Jonathan Gerlach wrote: I'm impressed. Are you using DirectX "11 on 12" or standard DirectX11? Did you need to avoid the GC at all? I imagine the GC could ruin your framerate if you're not careful. Thanks for sharing and congrats on finishing (close enough) your game. Plain old DX11. I've used DX12 in industry, and it basically amounts to opting in to writing 70% of the graphics driver along with your renderer :) I don't need to push AAA levels of performance or asset load for this game, so DX11 is fine. Regarding the GC, copy-pasting my reply from Discord: I don't have the GC fully disabled, but I make a point to avoid GC allocations in runtime code. I allow myself to use it for initialization, tooling, editor code, etc. For runtime code it really just acts as a fallback. If I messed something up, a memory leak just becomes a periodic hitch instead of an eventual crash. I've also hacked some changes into druntime to help with this: - I added a "scrapheap" GC implementation, which is a simple linear allocator that resets at the end of each frame. I have a mixin that makes a scope use the scrapheap instead of the regular GC, which is useful for allowing me to still use phobos or other libraries, as long as I'm okay with all allocated memory being discarded at the end of the frame. Each worker thread also gets one, which resets when a unit of work completes. - I added a quick and dirty mode I can enable that logs the callstack of every GC allocation, to help me track down stray allocations that occur during runtime. @nogc is too restrictive, and doesn't understand that my scrapheap usage bypasses the GC. Runtime allocations that need to stick around almost entirely use a structure I've internally called a GenerationalStorage. Pretty common idea in games, a fixed size object pool that hands out IDs, and IDs can be used to retrieve a pointer to the object. Each ID contains the object's index, along with a generation number that increments every allocation, letting you reliably catch and assert on any use-after-frees of IDs.
Re: How does one attach a manifest file to a D executable on Windows?
On Friday, 24 May 2024 at 21:04:53 UTC, Ferhat Kurtulmuş wrote: On Friday, 24 May 2024 at 19:07:24 UTC, solidstate1991 wrote: I have tried resource compiling, then using `dflags` in dug to add the resulting obj file, but I still get the issue of the old GUI style. I did that before, but I don't remember now. Probably you will figure that out based on this. https://gitlab.com/aferust/gtkdappcreator/-/tree/master/win_res?ref_type=heads I think this is what you need https://github.com/aferust/doitlater/tree/master/views/res
Re: How does one attach a manifest file to a D executable on Windows?
On Friday, 24 May 2024 at 19:07:24 UTC, solidstate1991 wrote: I have tried resource compiling, then using `dflags` in dug to add the resulting obj file, but I still get the issue of the old GUI style. I did that before, but I don't remember now. Probably you will figure that out based on this. https://gitlab.com/aferust/gtkdappcreator/-/tree/master/win_res?ref_type=heads
Re: The D Programming Language and Its Role in Cybersecurity
On Monday, 20 May 2024 at 21:21:24 UTC, aberba wrote: Found this article by Raymond Andrè Hagen: https://www.linkedin.com/pulse/d-programming-language-its-role-cybersecurity-raymond-andr%C3%A8-hagen-nfvgf/ My goodness this is a terrible article. Almost no substance. Is this AI generated? -Steve
[Issue 24565] New: out contract variable is implicitly const
https://issues.dlang.org/show_bug.cgi?id=24565
Issue ID: 24565
Summary: out contract variable is implicitly const
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: minor
Priority: P1
Component: dlang.org
Assignee: nob...@puremagic.com
Reporter: n...@geany.org
The spec does not mention this:
https://dlang.org/spec/function.html#postconditions
struct R
{
bool empty(); // only logically const, not D const
}
R f() // returns a mutable R
out(r; r.empty) // Error: mutable method `R.empty` is not callable using a
`const` object
{
R r; // not const
return r;
}
For the above case, an `out` contract cannot be used. Note that inserting
`assert(r.empty);` before the return statement does work.
--
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/ I'm impressed. Are you using DirectX "11 on 12" or standard DirectX11? Did you need to avoid the GC at all? I imagine the GC could ruin your framerate if you're not careful. Thanks for sharing and congrats on finishing (close enough) your game.
[Issue 24564] std.file.DirEntry throws Exception instead of FileException
https://issues.dlang.org/show_bug.cgi?id=24564 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel created dlang/phobos pull request #9004 "Fix Bugzilla 24564 - std.file.DirEntry throws Exception instead of Fi…" fixing this issue: - Fix Bugzilla 24564 - std.file.DirEntry throws Exception instead of FileException https://github.com/dlang/phobos/pull/9004 --
[Issue 24564] std.file.DirEntry throws Exception instead of FileException
https://issues.dlang.org/show_bug.cgi?id=24564 johanenge...@weka.io changed: What|Removed |Added Keywords||industry --
[Issue 24564] New: std.file.DirEntry throws Exception instead of FileException
https://issues.dlang.org/show_bug.cgi?id=24564 Issue ID: 24564 Summary: std.file.DirEntry throws Exception instead of FileException Product: D Version: D2 Hardware: All OS: Linux Status: NEW Severity: major Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: johanenge...@weka.io `_ensureStatDone` and `_ensureLStatDone` use `enforce` https://github.com/dlang/phobos/blob/976dbf65566145e645f5963f76f16f7d9cb96dbf/std/file.d#L4061 (which throws an `Exception`) instead of using `cenforce` (used elsewhere in std.file, which throws `FileException`). --
Demo for The Art of Reflection released (a 3D game and engine fully written in D)
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/
Parallel safe associative array?
I was playing with parallel programming, and experienced "undefined behavior" when storing into an Associative Array in parallel. Guarding the assignments with a synchronized barrier fixed it, of course. And obviously loading down your raw AA with thread barriers would be foolish. But this set me searching through the library for a standard Associative Array construct which _is_ thread safe? It didn't jump out at me. I know I can place such a thing within a synchronized class, but I was wondering if there's a standard AA which has the standard usage but is safe when called in parallel? Thanks, Andy
Re: Beerconf May
On Thursday, 23 May 2024 at 17:42:38 UTC, Steven Schveighoffer wrote: On Saturday, 11 May 2024 at 20:35:17 UTC, Steven Schveighoffer wrote: [...] Hi All, just a friendly reminder this is happening in 2 days! [...] Nobody has asked to show anything, so I thought I might do a quick dive into how the new [Interpolation Expression Sequences](https://dlang.org/spec/istring.html) (a.k.a. string interpolation) work. These were added in the last major version of D, and I'm excited to start using these in my libraries! I will do a very informal presentation (no slides, just talking and coding) at about 18:00 UTC on Saturday. We will send out an announcement when it's about to start as well. See you then! -Steve Awesome. I wish there were more of these
[Issue 24563] Make the compiler provide a reason for why it has disabled a function
https://issues.dlang.org/show_bug.cgi?id=24563 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- The problem here is that the error is found in generated code which generally is cryptic to the user. Ideally, you would have a way to propagate the error that is found in generated code in a way that you can link the error message to actual user code. --
[Issue 24560] dmd crash on imported function with default parameter containing `new`
https://issues.dlang.org/show_bug.cgi?id=24560 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #5 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #16519 "Fix Bugzilla Issue 24560 - dmd crash on imported function with default parameter containing new" fixing this issue: - Fix Bugzilla Issue 24560 - dmd crash on imported function with default parameter containing new https://github.com/dlang/dmd/pull/16519 --
[Issue 24560] dmd crash on imported function with default parameter containing `new`
https://issues.dlang.org/show_bug.cgi?id=24560 RazvanN changed: What|Removed |Added Assignee|nob...@puremagic.com|razvan.nitu1...@gmail.com --
[Issue 24560] dmd crash on imported function with default parameter containing `new`
https://issues.dlang.org/show_bug.cgi?id=24560
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #4 from RazvanN ---
The import is not necessary. Having the code in a single file also segfaults:
class C { }
struct S
{
static void fun(C heur = new C) { }
}
void main()
{
S.fun();
}
--
[Issue 24563] New: Make the compiler provide a reason for why it has disabled a function
https://issues.dlang.org/show_bug.cgi?id=24563 Issue ID: 24563 Summary: Make the compiler provide a reason for why it has disabled a function Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: issues.dl...@jmdavisprog.com Currently, whenever the compiler is unable to generate a function that it would normally generate for a type (e.g. a copy constructor, because it has a member variable with a copy constructor, or an opAssign, because it has a member variable with an overloaded opAssign), it seems to just mark it as @disable as if the user had explicitly written the function prototype and then marked it with @disable. The result of this is that when you try to use such an operation on a type, you get an extremely uninformative error message - e.g. from https://issues.dlang.org/show_bug.cgi?id=24562: --- q.d(36): Error: generated function `q.main.S2.opAssign` cannot be used because it is annotated with `@disable` --- It _is_ fortunately smart enough to say that it's a generated function, but it says nothing about why opAssign has been disabled. This can make it extremely difficult to figure out what the actual problem is, and I'm unaware of any way to get that information short of running the compiler through a debugger. So, please fix it so that when the compiler says that a generated function was disabled, it explains _why_ it was disabled, so that we have some hope of actually figuring out what the problem is and how to fix it. In some cases, it might be a simple fix on the programmer's part, whereas in others, it could be a compiler bug. Either way, there's no hint as to what the problem could be. The compiler has basically just said that it failed without giving an actual reason. --
[Issue 24562] New: inout on the copy constructor makes it so that a normal opAssign does not work with multiple layers of objects
https://issues.dlang.org/show_bug.cgi?id=24562
Issue ID: 24562
Summary: inout on the copy constructor makes it so that a
normal opAssign does not work with multiple layers of
objects
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: blocker
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: issues.dl...@jmdavisprog.com
This code fails to compile
---
void main()
{
static struct V
{
int _data;
this(ref return scope inout(V) rhs) scope @trusted inout pure nothrow
{
this._data = rhs._data;
}
ref opAssign(T)(auto ref T rhs)
if(is(immutable T == immutable V))
{
this._data = rhs._data;
return this;
}
}
static struct S1
{
V v;
}
S1 a;
auto b = a;
a = b;
static struct S2
{
S1 s;
}
S2 s;
auto t = s;
s = t;
}
---
and gives the error:
---
q.d(36): Error: generated function `q.main.S2.opAssign` cannot be used because
it is annotated with `@disable`
---
No reason is given as to why it's been disabled, so I really don't know what
the problem is, but removing the copy constructor fixes the problem (which
obviously is unacceptable for code that needs a copy constructor), and adding
inout to opAssign fixes the problem. However, putting inout on an opAssign
makes _no_ sense, because outside of really weird edge cases when the type
isn't actually holding the data, you can't assign to a const or immutable
variable. And opAssign with inout on it shouldn't even compile if it assigns to
any members (like this opAssign does), since the object could be const or
immutable underneath the hood. If opAssign isn't templated, then putting inout
on it gives the proper error (I've reported the issue with inout and opAssign
here: https://issues.dlang.org/show_bug.cgi?id=24561).
Regardless, something really weird is happening with opAssign to make it so
that you have to declare it with inout and templatize it to make example code
work.
And note that it's only S2 which has issues. Assigning to an S1 is fine. So, it
seems likely that something funny is going on with the opAssign generated for
S1 which then makes it so that the opAssign for S2 cannot be generated.
Maybe there are actually is a good reason for this situation, and someone can
explain it, but certainly from what I can see, this should be considered a
compiler bug. It should _never_ be required to annotate opAssign with
mutability qualifiers, and in the vast majority of cases, it would make no
sense for the compiler to generate an opAssign with any mutability qualifiers,
since its implementation wouldn't work anyway.
I'm marking this a blocker, because it's blocking stuff that I'm trying to do
at Symmetry. Copy constructors and opAssign need to play together nicely, and
they're clearly not. Part of the problem is that the language basically forces
you to put inout on a copy constructor right now, but even if that problem is
fixed, it should still work to have a copy constructor with inout while
simultaneously having an opAssign with no mutability qualifiers - and it _does_
work for the type itself and the type containing it, but once you go one level
deeper, it doesn't. Instead, it just gives a cryptic error message about
opAssign having been disabled.
--
[Issue 24561] New: inout on opAssign allows you to mutate member variables
https://issues.dlang.org/show_bug.cgi?id=24561
Issue ID: 24561
Summary: inout on opAssign allows you to mutate member
variables
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: issues.dl...@jmdavisprog.com
This code compiles
---
void main()
{
static struct V {
int _data;
ref opAssign(T)(auto ref T rhs) inout
if(is(immutable T == immutable V))
{
this._data = rhs._data;
return this;
}
}
V v;
auto u = v;
v = u;
}
---
However, it really shouldn't, because inout could be const or immutable
underneath the hood. If the opAssign is not templated, then it correctly gives
an error, but it doesn't if it's templated like here.
That being said, the compiler still manages to give an error for the assignment
to v if v is marked as const, so that may be why the issue hasn't been caught
previously.
This may or may not be related to
https://issues.dlang.org/show_bug.cgi?id=12793, which points to a similar
problem but specifically with a this This template parameter.
--
[Issue 24560] dmd crash on imported function with default parameter containing `new`
https://issues.dlang.org/show_bug.cgi?id=24560 hst...@qfbox.info changed: What|Removed |Added Severity|critical|regression --- Comment #3 from hst...@qfbox.info --- Changed to regression: code compiles with 2.107.1. --
[Issue 24560] dmd crash on imported function with default parameter containing `new`
https://issues.dlang.org/show_bug.cgi?id=24560 --- Comment #2 from hst...@qfbox.info --- Also affects LDC 1.38.0: https://github.com/ldc-developers/ldc/issues/4669 --
[Issue 24560] dmd crash on imported function with default parameter containing `new`
https://issues.dlang.org/show_bug.cgi?id=24560 hst...@qfbox.info changed: What|Removed |Added Keywords||ice, ice-on-valid-code --
[Issue 24560] dmd crash on imported function with default parameter containing `new`
https://issues.dlang.org/show_bug.cgi?id=24560 --- Comment #1 from hst...@qfbox.info --- This bug has existed at least since 2.108.1, since ldc2 1.38.0, which is based on 2.108.1, shows the same problem (segfault upon compiling the above code). --
[Issue 24560] New: dmd crash on imported function with default parameter containing `new`
https://issues.dlang.org/show_bug.cgi?id=24560
Issue ID: 24560
Summary: dmd crash on imported function with default parameter
containing `new`
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: critical
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: hst...@qfbox.info
Code:
```
// mod.d
class C { }
struct S
{
static void fun(C heur = new C) { }
}
// test.d
import mod;
void main()
{
S.fun();
}
```
Compile command: dmd test.d
Compiler output:
```
Segmentation fault
```
--
[Issue 24559] Compiler fails to error about using enum type as a value when compiling with -o-
https://issues.dlang.org/show_bug.cgi?id=24559 --- Comment #2 from Luís Ferreira --- Interesting enough, if you run `-verror=spec` with `-o-` it fails (enables display of error gagging on speculative compilations). --
[Issue 24559] Compiler fails to error about using enum type as a value when compiling with -o-
https://issues.dlang.org/show_bug.cgi?id=24559 Luís Ferreira changed: What|Removed |Added CC||cont...@lsferreira.net --- Comment #1 from Luís Ferreira --- >From what I investigated, semantics gags the error and defer that to e2ir glue code, hence it doesn't happen on `-o-`. We have two possible options: - We do the check for expressions with EXP.error after semantic3 and remove it from e2ir visitor; - Detect these situations when we encounter them. It seems expressionsem assumes its a forward reference and goes on, which to me, shouldn't. --
[Issue 24559] New: Compiler fails to error about using enum type as a value when compiling with -o-
https://issues.dlang.org/show_bug.cgi?id=24559
Issue ID: 24559
Summary: Compiler fails to error about using enum type as a
value when compiling with -o-
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: e...@weka.io
enum Flags : ubyte { Foo = 1, }
void foo() {
if(Flags) { // "Flags" as an expression should yield an error, but is only
an error when generating object code, -o- succeeds
}
}
--
Re: Beerconf May
On Saturday, 11 May 2024 at 20:35:17 UTC, Steven Schveighoffer wrote: # BEERCONF! This month, we are having our favorite online gathering on the 25-26 of May. We will announce the stream the day of the 25th. Hi All, just a friendly reminder this is happening in 2 days! ## 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! Nobody has asked to show anything, so I thought I might do a quick dive into how the new [Interpolation Expression Sequences](https://dlang.org/spec/istring.html) (a.k.a. string interpolation) work. These were added in the last major version of D, and I'm excited to start using these in my libraries! I will do a very informal presentation (no slides, just talking and coding) at about 18:00 UTC on Saturday. We will send out an announcement when it's about to start as well. See you then! -Steve
[Issue 24127] ImportC - no way to organize files
https://issues.dlang.org/show_bug.cgi?id=24127 Andrea Fontana changed: What|Removed |Added CC||trik...@gmail.com --- Comment #4 from Andrea Fontana --- Similar problem here. A C library with different file with the same name: hello/utils.c world/utils.c dmd hello/utils.c world/utils.c won't compile. --
Re: Recommendations on porting Python to D
On Friday, 3 May 2024 at 17:53:41 UTC, mw wrote: On Friday, 3 May 2024 at 17:38:10 UTC, Chris Piker wrote: On Thursday, 25 April 2024 at 16:57:53 UTC, mw wrote: [...] Thanks for the suggestions. I put the question aside for a bit, but yesterday ran across a python transpiler here: https://github.com/py2many/py2many It already has support for C++, Go and others. Since I have mountains of python code created over many years, maybe it would be worth contributing to this project out of self interest. Can you take a look at py2many and see what you think about it? Getting D on the support list might be good. (Haven't checked its own implementation and output code quality.) But it says has output for Kotlin, Dart, these two languages are similar to D syntactically, so will be a good start. I took another quick look of the project, it uses the Python builtin `ast` module as parser, and visitor design pattern to implement the transcompiler, so I think it's of decent quality. HTH.
Re: Dlang club meeting Thu May 30 7pm at the Red Robin
On Monday, 20 May 2024 at 22:36:30 UTC, Walter Bright wrote: Given last month's successful conversion of a sand pile to an atomic pile, this #dlang meeting will be about resurrecting the lost technology of the Atomic Earth Blaster. Thu May 30 7pm at the Red Robin 2390 148th Ave NE, Redmond, WA 98052 https://twitter.com/WalterBright/status/1792685408620605709 See you all there.
[Issue 24558] C asserts segfault on Glibc
https://issues.dlang.org/show_bug.cgi?id=24558 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16515 "Fix assert; arguments were in reverse order" was merged into master: - e97c9365f1f1ea08fbc45f45ad6a28bf57a418e7 by Connor: Fix bugzilla issue 24558: C asserts segfault on Glibc Use irs.target.c.runtime instead of version(CRuntime_) Unify musl and glibc implementation https://github.com/dlang/dmd/pull/16515 --
Re: Dlang club meeting Thu May 30 7pm at the Red Robin
On Monday, 20 May 2024 at 22:36:30 UTC, Walter Bright wrote: Given last month's successful conversion of a sand pile to an atomic pile, this #dlang meeting will be about resurrecting the lost technology of the Atomic Earth Blaster. Thu May 30 7pm at the Red Robin 2390 148th Ave NE, Redmond, WA 98052 https://twitter.com/WalterBright/status/1792685408620605709 I am planning on being there, and I've got a list...
Re: Anybody know about SDL and particularly SDL_TTF initialization?
On Sunday, 12 May 2024 at 20:13:04 UTC, WhatMeWorry` wrote: INFO: SDL loaded v2.30.2 INFO: SDL initialized: 0 INFO: TTF loaded: v2.0.14 Error Program exited with code -1073741819 Something hit a null pointer, time to fire up the debugger :)
[Issue 24558] C asserts segfault on Glibc
https://issues.dlang.org/show_bug.cgi?id=24558 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @Connor-GH updated dlang/dmd pull request #16515 "Fix assert; arguments were in reverse order" fixing this issue: - Fix bugzilla issue 24558: C asserts segfault on Glibc Use irs.target.c.runtime instead of version(CRuntime_) Unify musl and glibc implementation https://github.com/dlang/dmd/pull/16515 --
[Issue 24558] New: C asserts segfault on Glibc
https://issues.dlang.org/show_bug.cgi?id=24558
Issue ID: 24558
Summary: C asserts segfault on Glibc
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: connor...@outlook.com
When running the minimal test case of ``extern(C) int main() {assert(0);}``,
dmd would segfault (this also applies to ldc2).
Expected behavior: ``file: /home/user/file.d:2: file.main: Assertion `0'
failed.``
Observed behavior: ``Segmentation Fault``
--
Re: Anybody know about SDL and particularly SDL_TTF initialization?
On Sunday, 12 May 2024 at 20:13:04 UTC, WhatMeWorry` wrote:
This should be trivial, right?
I've been looking at existing D repo code for hours. Can't
figure why TTF_Init doesn't work?
It would help if I could figure out how to use SDL_GetError()
INFO: SDL loaded v2.30.2
INFO: SDL initialized: 0
INFO: TTF loaded: v2.0.14
Error Program exited with code -1073741819
loadSDL();
SDL_version v;
SDL_GetVersion();
toStdout("SDL loaded v%d.%d.%d", v.major, v.minor, v.patch);
auto initSDL = SDL_Init(SDL_INIT_EVERYTHING); // returns 0
on success
toStdout("SDL initialized: %d", initSDL);
auto loadTTF = loadSDLTTF();
SDL_TTF_VERSION();
toStdout("TTF loaded: v%d.%d.%d", v.major, v.minor, v.patch);
auto initTTF = TTF_Init(); // SDL must be initialized before
calls to this library
No idea why this fails, seems alright to me. You can use:
TTF_GetError() for a human-readable error message,when the call
to TTF_Init() fails (return -1).
Good luck
Danny
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Dlang Bot --- dlang/dmd pull request #16510 "fix issue24534 : goto can skip declarations in labeled statements without error" was merged into master: - 7f30b66d3dae37544c7629af1178f908984c2a93 by Ben Jones: Fix Bugzilla Issue 24534 : goto can skip declarations in labeled statements without error https://github.com/dlang/dmd/pull/16510 --
Dlang club meeting Thu May 30 7pm at the Red Robin
Given last month's successful conversion of a sand pile to an atomic pile, this #dlang meeting will be about resurrecting the lost technology of the Atomic Earth Blaster. Thu May 30 7pm at the Red Robin 2390 148th Ave NE, Redmond, WA 98052 https://twitter.com/WalterBright/status/1792685408620605709
The D Programming Language and Its Role in Cybersecurity
Found this article by Raymond Andrè Hagen: https://www.linkedin.com/pulse/d-programming-language-its-role-cybersecurity-raymond-andr%C3%A8-hagen-nfvgf/
[Issue 24557] File.readln does not properly handle case where last character in terminator is repeated
https://issues.dlang.org/show_bug.cgi?id=24557
Steven Schveighoffer changed:
What|Removed |Added
CC||schvei...@gmail.com
Hardware|x86_64 |All
OS|Linux |All
--- Comment #1 from Steven Schveighoffer ---
readln does use the last character, but it is also validating the "line" ends
in the full termination sequence.
However, the bug is that if the last character is repeated in the termination
sequence, it checks just the new data that it has read for the termination
sequence.
So for example, if you look for `ging` as the termination sequence, the
following algorithm results (assume input is `bringing home the bacon`):
1. result = "", readln('g') => "bring". Does "bring" end in "ging"? no
2. result = "bring", readln('g') => "ing". Does "ing" end in "ging"? no
3. result = "bringing", readln('g') => " home the bacon". readln returned no
delim found, so result is "bringing home the bacon"
Instead, readln should check the *concatenated* result (but obviously, only the
result that has been appended since the readln call was started.
--
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534 --- Comment #10 from Ben --- "Since this is used in C code quite often, and therefore ported code (such as dmd's backend)." >From what I can tell, there's only one place in the whole compiler that's affected by this bug, so I don't think this is something that was commonly relied on. --
[Issue 24557] New: File.readln does not properly handle case where last character in terminator is repeated
https://issues.dlang.org/show_bug.cgi?id=24557
Issue ID: 24557
Summary: File.readln does not properly handle case where last
character in terminator is repeated
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: zopsi...@use.startmail.com
Consider the following program:
-
import std.stdio : readln, writefln;
void main()
{
char[] buf;
readln(buf, "ABA");
writefln!"%(%s%)"([buf]);
}
-
Compiled and run as follows:
-
$ dmd example.d
$ printf 'XABAY' | ./example
-
Expected output: "XABA"
Actual output: "XABAY"
readln does not properly handle the case where the last character of the
terminator (in this case A) appears multiple times in the terminator (in this
case, A also appears at the front of the terminator).
--
Re: DCV has a new release.
On Monday, 20 May 2024 at 11:47:25 UTC, Ferhat Kurtulmuş wrote: I've been working on DCV for some years. Recently, DCV has started to be used by some projects, such as etichetta[1]. Even though it's still far from perfect, I think DCV deserves a new version. Existing unit tests pass. New ones are also necessary. Docs are produced for most functions. Here it is https://github.com/libmir/dcv/releases/tag/v0.4.0 And here are some fun examples: panorama stitching: https://github.com/libmir/dcv/tree/master/examples/imagestitchinghomography Binary region analysis: https://github.com/libmir/dcv/tree/master/examples/measure Video input: https://github.com/libmir/dcv/blob/master/examples/video/source/app.d Basic image manipulation: https://github.com/libmir/dcv/blob/master/examples/imgmanip 1: https://github.com/trikko/etichetta Well done Ferhat!
Re: DCV has a new release.
On Monday, 20 May 2024 at 11:47:25 UTC, Ferhat Kurtulmuş wrote: I've been working on DCV for some years. Recently, DCV has started to be used by some projects, such as etichetta[1]. Even though it's still far from perfect, I think DCV deserves a new version. Existing unit tests pass. New ones are also necessary. Great! With your help etichetta would never have been able to use the AI. I hope DCV will continue evolving. :) Andrea
DCV has a new release.
I've been working on DCV for some years. Recently, DCV has started to be used by some projects, such as etichetta[1]. Even though it's still far from perfect, I think DCV deserves a new version. Existing unit tests pass. New ones are also necessary. Docs are produced for most functions. Here it is https://github.com/libmir/dcv/releases/tag/v0.4.0 And here are some fun examples: panorama stitching: https://github.com/libmir/dcv/tree/master/examples/imagestitchinghomography Binary region analysis: https://github.com/libmir/dcv/tree/master/examples/measure Video input: https://github.com/libmir/dcv/blob/master/examples/video/source/app.d Basic image manipulation: https://github.com/libmir/dcv/blob/master/examples/imgmanip 1: https://github.com/trikko/etichetta
[Issue 24556] New: Allow IFTI for dotted template parameters used as function type parameter
https://issues.dlang.org/show_bug.cgi?id=24556
Issue ID: 24556
Summary: Allow IFTI for dotted template parameters used as
function type parameter
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: b2.t...@gmx.com
Minor enhancement, not very useful but maybe that this should work:
```d
version(all)
void v(T,U)(T.U tu){}
else
void v(U, T = __traits(parent, U))(U tu){}; // that works fine RN
void main()
{
struct S1 { S2 s2; struct S2 {} }
S1 s1;
v(s1.s2);
struct G1 { struct G2 {} }
G1.G2 g1g2;
v(g1g2);
}
```
That is currently rejected but the compiler could guess that `U` is either `S2`
or `G2` and then infer `T` as being the parent type (if any). That would be
similar to the case where D deduces T, let's say in `void v(T)(T[] t)`.
--
[Issue 24546] importC musl setjmp.h failure
https://issues.dlang.org/show_bug.cgi?id=24546 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dmd pull request #16507 "Fix https://issues.dlang.org/show_bug.cgi?id=24546 for musl libc" was merged into stable: - af9f2e3234dc29f91f4029517260005a1cd87bb3 by Johan Engelen: Fix bugzilla 24546 for musl libc https://github.com/dlang/dmd/pull/16507 --
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534 --- Comment #9 from Jonathan M Davis --- (In reply to Richard (Rikki) Andrew Cattermole from comment #7) > But, it is also desirable to skip variable declarations, as long as you > don't touch them you do not violate the spec clause. The spec clause specifically disallows that: "It is illegal for a GotoStatement to be used to skip initializations." There's certainly an argument to be made that the rule could be more fine-grained and require that no variable be accessed whose declaration was skipped (which would also mean that the variable couldn't have a destructor), but as the rule currently stands, you can't legally skip variable declarations whether the variable is then used or not. --
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534
--- Comment #8 from Richard (Rikki) Andrew Cattermole
---
I've done some playing around to see if backward goto's have an equivalent
issue.
It seems dmd is actually smart there, and I couldn't get that to not work.
Generates a try/finally:
```
Label:
SomethingWithSideEffects var = 0;
try
{
if (uniform01() > 0.5)
return 0;
goto Label;
}
finally
var.~this();
```
This means only forward goto's have broken analysis.
--
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534 --- Comment #7 from Richard (Rikki) Andrew Cattermole --- It is a bug in the compiler, I agree on that too. But, it is also desirable to skip variable declarations, as long as you don't touch them you do not violate the spec clause. Since this is used in C code quite often, and therefore ported code (such as dmd's backend). A shortcut was taken with the current reverse search to analyze it, and it doesn't work as a result. Solving this properly requires type state analysis as that is what this particular clause involves. Therefore any attempts to fix this that does not do type state analysis is unfortunately another shortcut. --
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534 Jonathan M Davis changed: What|Removed |Added Severity|enhancement |normal --- Comment #6 from Jonathan M Davis --- Since this is in violation of the spec, I'm changing this back to a bug. If it's decided that the current behavior is desirable for whatever reason, then the spec will need to be updated instead. And even if the spec is updated instead of making this code illegal like the spec says it should be, the fact that @safe works with this code in spite of the fact that the variable is not properly initialized means that there's a compiler bug either way. So, it's not an enhancement. --
Re: Debug with GDB on Windows
The dub build with --verbose option generates the output ``` Generating using build Configuring dependent testd1, deps: Performing "debug" build using c:\D\ldc2-1.38.0-windows-x64\bin\ldc2.exe for x86_64. testd1 ~master: building configuration "application"... c:\D\ldc2-1.38.0-windows-x64\bin\ldc2.exe -gdwarf -O0 -c -ofapplication-debug-windows-x86_64-ldc_v1.38.0-6D670FD1992E8FC1 1A1557D635DBD69E\testd1.obj -d-debug -g -w --oq -od=application-debug-windows-x86_64-ldc_v1.38.0-6D670FD1992E8FC11A1557D6 35DBD69E\/obj -d-version=Have_testd1 -IC:\TestD1\src C:\TestD1\src\app.d -vcolumns Linking... c:\D\ldc2-1.38.0-windows-x64\bin\ldc2.exe -ofapplication-debug-windows-x86_64-ldc_v1.38.0-6D670FD1992E8FC11A1557D635DBD69 E\testd1.exe application-debug-windows-x86_64-ldc_v1.38.0-6D670FD1992E8FC11A1557D635DBD69E\testd1.obj -g ``` Still unclear what is wrong.
Debug with GDB on Windows
I am trying to debug on windows.
A simple hello world app compiled with
```
"c:\D\ldc2-1.38.0-windows-x64\bin\ldc2.exe" -gdwarf -O0 app.d
```
has debug symbols.
But the same app compiled with
```
dub build -b debug
--compiler="c:\D\ldc2-1.38.0-windows-x64\bin\ldc2.exe" --force
--root ../..
```
and dub.json
```
{
"name" : "testd1",
"description" : "Hello World - A minimal DUB bundle.",
"dependencies" : {
},
"dflags": ["-gdwarf", "-O0", "-d-debug"]
}
```
has NO debug symbols. gdb reports
```
Reading symbols from ./testd1.exe...
(No debugging symbols found in ./testd1.exe)
```
If add additional option `-vv` to `dflags` the it is visible that
ldc2 receives the `gdwarf` option. Probably the dub does some
thing wrong? Or I am wrong. :-(
Re: D Language Foundation January 2024 Monthly Meeting Summary
Mike Parker kirjoitti 14.5.2024 klo 16.23: The D Language Foundation's monthly meeting for January 2024 was held on Friday the 12th. There were two things of particular note about this meeting. Thanks for the write-up once again! Always nice to know what is cooking, even when the news come a bit late.
DIP1045--Symbol Representation--Status
Rikki's DIP, "Symbol Representation", which deals primarily with improving how we work with DLLs on Windows, was the first DIP to enter Formal Assessment under the new process. Ideally, we'd like decisions on DIPs to be reached within a couple of weeks, but upon reviewing the final edit of the DIP, Walter and Atila decided further discussion was warranted. They had an email discussion about the DIP that included Adam Wilson, who has a good bit of experience working with Windows DLLs in different contexts. I then set up a meeting that included Walter, Atila, Adam, Rikki, and Martin Kinkelin. Martin solved LDC's DLL issues a while back, so his perspective was important for this discussion. The end result is that **something** is going to be done, but it's probably not going to be the entirety of the solution Rikki proposed in the DIP. For now, two exploratory steps have been identified that may get us to where we need to be. One is that some of the work Martin did for LDC will need to be upstreamed into DMD. Although the problem being solved here is on Windows, the first step here involves upstreaming some Mac-specific, Mach-O format changes. The other is a new import path command-line flag, like the `-extI` proposed in the DIP, for use specifically with shared libraries. I'll leave it to others to provide details.
DConf '24 Submissions Closed
Thanks to everyone who submitted a talk for DConf '24. We're looking at another set of quality talks this year. Look for the schedule next weekend.
Re: __gshared is "somewhat" transitive, isn't it ?
On Thursday, 16 May 2024 at 17:04:09 UTC, user1234 wrote:
Given
```d
struct S
{
int member;
}
__gshared S s;
```
It's clear that `s.member` is `__gshared` too, right ?
What does happen for
```d
struct S
{
int member;
static int globalMember;
}
__gshared S s;
```
Is then `S.globalMember` a TLS variable ? (I'd expect that)
`__gshared` is a storage class. It means, store this thing in the
global memory segment. `static` storage class means store this
thing in TLS.
Storage classes are *not* transitive, and they are not type
constructors. They optionally might apply a type constructor to
the type (such as the `const` storage class), but not always.
So in this case `typeof(s)` is `S`, not `__gshared S`. `s.member`
is in the global segment since structs members are placed within
the struct memory location (in this case, the global memory
segment).
`globalMember` is placed in TLS because it's storage class is
`static`, and `static` means, do not store with the instance
(which for `s` would mean the global memory segment), but rather
in TLS.
-Steve
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #5 from Dlang Bot --- @benjones updated dlang/dmd pull request #16510 "fix issue24534 : goto can skip declarations in labeled statements without error" fixing this issue: - Fix Bugzilla Issue 24534 : goto can skip declarations in labeled statements without error https://github.com/dlang/dmd/pull/16510 --
[Issue 24555] New: macOS: Add shared druntime/Phobos (libphobos2.dylib)
https://issues.dlang.org/show_bug.cgi?id=24555
Issue ID: 24555
Summary: macOS: Add shared druntime/Phobos (libphobos2.dylib)
Product: D
Version: D2
Hardware: All
OS: Mac OS X
Status: NEW
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: ki...@gmx.net
While DMD and its druntime support a shared libphobos2.so for most ELF
platforms, there's no Mach-O support for macOS yet. LDC does support shared
druntime/Phobos on macOS/iOS, and upstreaming shouldn't be very hard.
The main adaptations are required in druntime's `rt.sections_elf_shared`
module, extending it to work with Mach-O binaries too. LDC's version is here:
https://github.com/ldc-developers/ldc/blob/master/runtime/druntime/src/rt/sections_elf_shared.d.
In LDC, we've already extended it to Windows too, so the file/diff is
unfortunately pretty messy, and the whole module could very much use a
refactoring (and a better name!!!). LDC uses `rt.sections_elf_shared` for all
major platforms, for static *and* shared druntime; all the other upstream
rt.sections* implementations are unused and could probably be dropped upstream
too in time.
Then each binary needs to register itself with druntime, calling
`_d_dso_registry`. DMD does this by emitting a `d_dso_init` function into every
compiled object file, like LDC used to. We then switched to doing this in
druntime directly (no magic compiler-generated code anymore, which for Mach-O
would need an extra helper variable + function), via some special little
module:
https://github.com/ldc-developers/ldc/blob/master/runtime/druntime/src/rt/dso.d.
If adopting that approach, make sure to read the comments to understand what
needs to be done, like bundling that precompiled object file with the compiler
installation packages, and linking it automatically into every binary linked
against *shared* druntime. And note that DMD would then need to adopt some
`@hidden` UDA too; `dso.d` absolutely needs that functionality (of making
symbols binary-internal only).
I'd propose adopting LDC's `-link-defaultlib-shared` too, instead of DMD's
platform-specific `-defaultlib={libphobos2.so,libphobos2.dylib,phobos2.dll}`.
Linking in the bundled `dso.o` would become easier then too.
After that, adapting variable `SHARED` in druntime's Makefile (setting it to 1
on macOS) might be enough.
--
[Issue 24554] New: Clarrification for bad codegen on postfix operators
https://issues.dlang.org/show_bug.cgi?id=24554
Issue ID: 24554
Summary: Clarrification for bad codegen on postfix operators
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dlang.org
Assignee: nob...@puremagic.com
Reporter: alphaglosi...@gmail.com
Johan Engelen asked me on the ldc bug ticket to create a ticket to find out
what the specification means.
All three compilers have differing behavior.
DMD: https://github.com/ldc-developers/ldc/issues/4651
GDC: https://forum.dlang.org/post/zybltjuxkbvtvirzw...@forum.dlang.org
ldc fe 2.107 as per run.dlang.org
```d
void main()
{
int d = 42;
bool o = d > d++;
}
```
```
define i32 @_Dmain({ i64, ptr } %unnamed) #0 {
%d = alloca i32, align 4; [#uses = 4, size/byte = 4]
%o = alloca i8, align 1 ; [#uses = 1, size/byte = 1]
store i32 42, ptr %d, align 4
%1 = load i32, ptr %d, align 4 ; [#uses = 2]
%2 = add i32 %1, 1 ; [#uses = 1]
store i32 %2, ptr %d, align 4
%3 = load i32, ptr %d, align 4 ; [#uses = 1]
%4 = icmp sgt i32 %3, %1; [#uses = 1]
%5 = zext i1 %4 to i8 ; [#uses = 1]
store i8 %5, ptr %o, align 1
ret i32 0
}
```
Note; the icmp is after the add, which it shouldn't be.
Source: https://twitter.com/marcos_don/status/1787629240550150361
--
[Issue 24546] importC musl setjmp.h failure
https://issues.dlang.org/show_bug.cgi?id=24546 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @JohanEngelen updated dlang/dmd pull request #16507 "Fix https://issues.dlang.org/show_bug.cgi?id=24546 for musl libc" fixing this issue: - Fix bugzilla 24546 for musl libc https://github.com/dlang/dmd/pull/16507 --
Re: LDC 1.38.0
On 5/10/2024 6:22 PM, kinke wrote: Glad to announce LDC 1.38.0. Major changes: - Based on D 2.108.1. - Support for LLVM 18; the prebuilt packages use v18.1.5. - Android: Switch to native ELF TLS, supported since API level 29 (Android v10), dropping our former custom TLS emulation (requiring a modified LLVM and a legacy ld.bfd linker). The prebuilt packages themselves require Android v10+ (armv7a) / v11+ (aarch64) too, and are built with NDK r26d. Shared druntime and Phobos libraries are now available (`-link-defaultlib-shared`), as on regular Linux. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.38.0 Thanks to all contributors & sponsors! Great work!
[Issue 24553] New: all 0 struct initializer with float is still stored in data section
https://issues.dlang.org/show_bug.cgi?id=24553
Issue ID: 24553
Summary: all 0 struct initializer with float is still stored in
data section
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: backend
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: schvei...@gmail.com
Consider these structs:
```d
struct A {
int[1] x;
}
struct B {
float[1] x;
}
struct C {
float[1] x = 0;
}
struct D {
char[1] x = 0;
}
```
A and D do not store any static data in the binary, because they are
zero-initialized types (char.init is non-zero, but the assignment sets it to
0).
B obviously must store static data because float.init is NaN.
But C still stores static data (1 32-bit 0s). This should not happen.
--
[Issue 24549] std.process.environment.get(null) segfaults
https://issues.dlang.org/show_bug.cgi?id=24549 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/phobos pull request #9002 "Fix issue 24549 - std.process.environment.get(null) segfaults" was merged into stable: - 6ea12cf3a4b2fb6e3e962a87e1954b949f349a79 by Steven Schveighoffer: Fix bugzilla issue 24549 -- environment.get(null) segfaults on Linux https://github.com/dlang/phobos/pull/9002 --
[Issue 6297] cast() does not remove const or immutable on arrays and pointers
https://issues.dlang.org/show_bug.cgi?id=6297 Steven Schveighoffer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Steven Schveighoffer --- I have no idea what I was thinking those 13 years ago. OK to close ;) --
[Issue 6297] cast() does not remove const or immutable on arrays and pointers
https://issues.dlang.org/show_bug.cgi?id=6297 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- The spec (now) says: > Casting with no type or qualifiers removes any top level const, immutable, > shared or inout type modifiers from the type of the UnaryExpression https://dlang.org/spec/expression.html#cast_qualifier Note 'top level'. So I think this is invalid. --
[Issue 24552] cast to immutable in @safe not rejected
https://issues.dlang.org/show_bug.cgi?id=24552 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- As is(immutable Foo!uint : Foo!uint) is false, `opCast` should not be matched. --
Re: My interest in contributing to the D language and participation in the Symmetry Autumn of code
On 16/05/2024 11:43 PM, Dennis wrote: just in case I've worked on an issue, how do I communicate with the community/mentors about it? Is there a discord/slack community I can join? On the main website under Community there is an invite link to the community Discord. Many people are there including Mike Parker and Razvan.
Re: My interest in contributing to the D language and participation in the Symmetry Autumn of code
On Wednesday, 15 May 2024 at 14:23:32 UTC, RazvanN wrote: On Tuesday, 14 May 2024 at 18:42:56 UTC, Dennis wrote: Hello everyone, My name is Dennis and I’m from Nigeria and I want to contribute to the D language, perhaps engage in the upcoming Symmetry Autumn of code, and contribute immensely to the D language and beyond. I’m open to anyone directing me on things to work on. I'd really appreciate that. Hi Dennis! We have a bunch of projects that you could work on, however, choosing the right project depends of what you are interested in and your experience with the concepts involved. Generally, we have multiple fronts that work could be done on: the compiler, the runtime library, the standard library, ecosystem tools etc. I suggest you pick one of the categories, get the code, try to fix the issues (you can find our list of issues here: https://issues.dlang.org/ - searching for the keywork "bootcamp" will list issues that are considered entry level, but note that some of those might be more complicated then you would expect at a first glance) and then we can have a hat on projects you can work on. How does that sound? RazvanN just in case I've worked on an issue, how do I communicate with the community/mentors about it? Is there a discord/slack community I can join?
[Issue 21626] foreach create reference to rvalue tuple returned by front
https://issues.dlang.org/show_bug.cgi?id=21626 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- Confirmed with dmd v2.108.0-rc.1. --
[Issue 7361] No documentation for front tuple expansion in foreach over range
https://issues.dlang.org/show_bug.cgi?id=7361 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Nick Treleaven --- Initial docs were added in https://github.com/dlang/dlang.org/pull/3001. Improvements: https://github.com/dlang/dlang.org/pull/3832 --
[Issue 24552] New: cast to immutable in @safe not rejected
https://issues.dlang.org/show_bug.cgi?id=24552
Issue ID: 24552
Summary: cast to immutable in @safe not rejected
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid
Severity: critical
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: elpenguin...@gmail.com
```
void fun() @safe {
static struct Foo(E) {
private E[] data;
Foo!NewElement opCast(T : Foo!NewElement, NewElement)() {
return Foo!NewElement(cast(NewElement[])data);
}
}
int[] data = [1,2,3,4,5];
Foo!int tmp = Foo!int(data);
immutable tmp2 = (cast(immutable Foo!uint)tmp).data;
assert(tmp2[2] == 3);
data[2] = 77;
assert(tmp2[2] == 77); // immutable data mutated?!
}
```
This should not be allowed to compile.
--
Re: My interest in contributing to the D language and participation in the Symmetry Autumn of code
On Wednesday, 15 May 2024 at 14:23:32 UTC, RazvanN wrote: On Tuesday, 14 May 2024 at 18:42:56 UTC, Dennis wrote: Hello everyone, My name is Dennis and I’m from Nigeria and I want to contribute to the D language, perhaps engage in the upcoming Symmetry Autumn of code, and contribute immensely to the D language and beyond. I’m open to anyone directing me on things to work on. I'd really appreciate that. Hi Dennis! We have a bunch of projects that you could work on, however, choosing the right project depends of what you are interested in and your experience with the concepts involved. Generally, we have multiple fronts that work could be done on: the compiler, the runtime library, the standard library, ecosystem tools etc. I suggest you pick one of the categories, get the code, try to fix the issues (you can find our list of issues here: https://issues.dlang.org/ - searching for the keywork "bootcamp" will list issues that are considered entry level, but note that some of those might be more complicated then you would expect at a first glance) and then we can have a chat on projects you can work on. How does that sound? RazvanN That sounds great, looking forward to participate.
Re: LDC 1.38.0
On Sat, May 11, 2024 at 01:22:58AM +, kinke via Digitalmars-d-announce wrote: > Glad to announce LDC 1.38.0. Major changes: > > - Based on D 2.108.1. > - Support for LLVM 18; the prebuilt packages use v18.1.5. > - Android: Switch to native ELF TLS, supported since API level 29 (Android > v10), dropping our former custom TLS emulation (requiring a modified LLVM > and a legacy ld.bfd linker). The prebuilt packages themselves require > Android v10+ (armv7a) / v11+ (aarch64) too, and are built with NDK r26d. > Shared druntime and Phobos libraries are now available > (`-link-defaultlib-shared`), as on regular Linux. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.38.0 > > Thanks to all contributors & sponsors! Thanks for continuing to bring us this awesome compiler! --T
Re: My interest in contributing to the D language and participation in the Symmetry Autumn of code
On Tuesday, 14 May 2024 at 18:42:56 UTC, Dennis wrote: Hello everyone, My name is Dennis and I’m from Nigeria and I want to contribute to the D language, perhaps engage in the upcoming Symmetry Autumn of code, and contribute immensely to the D language and beyond. I’m open to anyone directing me on things to work on. I'd really appreciate that. Hi Dennis! We have a bunch of projects that you could work on, however, choosing the right project depends of what you are interested in and your experience with the concepts involved. Generally, we have multiple fronts that work could be done on: the compiler, the runtime library, the standard library, ecosystem tools etc. I suggest you pick one of the categories, get the code, try to fix the issues (you can find our list of issues here: https://issues.dlang.org/ - searching for the keywork "bootcamp" will list issues that are considered entry level, but note that some of those might be more complicated then you would expect at a first glance) and then we can have a chat on projects you can work on. How does that sound? RazvanN
[Issue 24551] Missing O_NOFOLLOW enum on macOS
https://issues.dlang.org/show_bug.cgi?id=24551 --- Comment #1 from Andrea Fontana --- Probably 0x0100? https://opensource.apple.com/source/xnu/xnu-6153.81.5/bsd/sys/fcntl.h --
[Issue 24551] New: Missing O_NOFOLLOW enum on macOS
https://issues.dlang.org/show_bug.cgi?id=24551 Issue ID: 24551 Summary: Missing O_NOFOLLOW enum on macOS Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: trik...@gmail.com Here it is missing the O_NOFOLLOW def for darwin: https://github.com/dlang/dmd/blob/001b66ed4033ae642e3501dd8ccb5e15bf1b7933/druntime/src/core/sys/posix/fcntl.d#L461 Not sure which is the right value. --
Re: My interest in contributing to the D language and participation in the Symmetry Autumn of code
On Tuesday, 14 May 2024 at 18:42:56 UTC, Dennis wrote: Hello everyone, My name is Dennis and I’m from Nigeria and I want to contribute to the D language, perhaps engage in the upcoming Symmetry Autumn of code, and contribute immensely to the D language and beyond. I’m open to anyone directing me on things to work on. I'd really appreciate that. Hi, Dennis. Nice to meet you. I'll be making the announcement about SAOC 2024 in a few weeks. In the meantime, you can visit the SAOC page to learn everything you need to know about how to apply: https://saoc.io It's still got the info from last year, but very little will change for this year. The application deadline could be different this time, but the rest of the dates should be the same. It will run from September 15 of this year to January 14 of next year. I'll leave it to Razvan Nitu and/or Dennis Korpel to help you with contributing.
Re: D Language Foundation January 2024 Monthly Meeting Summary
Wow I see I was mentioned at a lot at this meeting! In saying that I do have some points to add about Item 2 data structures. Data structures come in one of two forms generally: owning and non-owning. ### Non-owning Non-owning is the simplest, its an index. It doesn't own any memory that isn't internal. Takes in a single memory allocator for its internal state. For its memory safety you are pretty limited to concerns surrounding read-only-ness of its internal state. Which only exist because the GC allocator might be in use. You pass a value in, you get a value out. No references. ### Owning Owning data structures come with two subsets which may be mixed to form a third combined subset. Cleans up Takes in two memory allocators, one for its internal state, one for its deallocation of values. Will deallocate any memory given to it, which also means that once memory is placed into it, it now owns it and is responsible for its cleanup. As for memory safety you have only one (as long as you don't use references out). Owner escape analysis, this is a DIP Walter has required for me to work on before reference counting. So its going in anyway. References out I'll assume here that it does not clean up any memory passed in, that you handle this manually, that the data structure is merely an index. In almost all ways its similar to non-owning, one memory allocator, still has the memory safety concerns of the owner. An you also have to worry about borrows typically from a struct acting as a reference. Which once again is resolved with owner escape analysis (noticing a trend yet?). What this tells us is that non-owning data structures can go in pretty much immediately, although there will need to be some remedial work once we get reference counting and with that a solution to read only memory. But of course because Walter wants owner escape analysis first, it doesn't matter, both owning and non-owning will need to go together. Note: concurrent data structures will need the read only memory solution due to the locks (notice a trend yet?) as well. We'll likely want to use long names to differentiate all these behaviors unfortunately. As it could be quite desirable to have all the different variations.
Re: LDC 1.38.0
On Saturday, 11 May 2024 at 01:22:58 UTC, kinke wrote: Glad to announce LDC 1.38.0. Major changes: - Based on D 2.108.1. - Support for LLVM 18; the prebuilt packages use v18.1.5. - Android: Switch to native ELF TLS, supported since API level 29 (Android v10), dropping our former custom TLS emulation (requiring a modified LLVM and a legacy ld.bfd linker). The prebuilt packages themselves require Android v10+ (armv7a) / v11+ (aarch64) too, and are built with NDK r26d. Shared druntime and Phobos libraries are now available (`-link-defaultlib-shared`), as on regular Linux. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.38.0 Thanks to all contributors & sponsors! Thanks a lot Martin! I'm super excited to integrate the new NDK support to my engine tool so it can still automatically integrate with the most up to date version :)
Re: My interest in contributing to the D language and participation in the Symmetry Autumn of code
On Tuesday, 14 May 2024 at 18:42:56 UTC, Dennis wrote: Hello everyone, My name is Dennis and I’m from Nigeria and I want to contribute to the D language, perhaps engage in the upcoming Symmetry Autumn of code, and contribute immensely to the D language and beyond. I’m open to anyone directing me on things to work on. I'd really appreciate that. Hi Dennis, nice to hear that! Razvan and Mike probably are good persons to ask such question. There are some project milestones in GitHub repo.. But you can start with issues https://forum.dlang.org/group/issues
Re: Setting field of struct object
On Monday, 22 January 2024 at 08:54:21 UTC, Danilo wrote: On Monday, 22 January 2024 at 08:35:01 UTC, Joel wrote: [...] Nonetheless, this usually used with Objects (new class/struct instances), like so: ```d import std; [...] Fluent Interface
Re: FIFO
On Monday, 13 May 2024 at 15:07:39 UTC, Andy Valencia wrote: On Sunday, 12 May 2024 at 22:03:21 UTC, Ferhat Kurtulmuş wrote: https://dlang.org/phobos/std_container_slist.html This is a stack, isn't it? LIFO? Ahh yes. Then use dlist Thank you. I read its source, and was curious so I wrote a small performance measurement: put 10,000 things in a FIFO, pull them back out, and loop around that 10,000 times. My FIFO resulted in: Also try the code I gave in this thread: https://forum.dlang.org/post/fgzvdhkdyevtzznya...@forum.dlang.org In fact, please use this facility in the standard library: https://dlang.org/phobos/std_datetime_stopwatch.html#benchmark SDB@79
My interest in contributing to the D language and participation in the Symmetry Autumn of code
Hello everyone, My name is Dennis and I’m from Nigeria and I want to contribute to the D language, perhaps engage in the upcoming Symmetry Autumn of code, and contribute immensely to the D language and beyond. I’m open to anyone directing me on things to work on. I'd really appreciate that.
[Issue 23812] ImportC: allow adding function attributes to imported C functions
https://issues.dlang.org/show_bug.cgi?id=23812 ponce changed: What|Removed |Added CC||alil...@gmail.com --- Comment #2 from ponce --- I've translated a fair share of C and AFAIK they all could be `nothrow @nogc`. --
Re: Sokol now has official D bindings
On Tuesday, 14 May 2024 at 12:36:27 UTC, ryuukk_ wrote: - float nan default Complaints from C and C++ programmers could mention that at least stack variables gets initialized to something.
Re: D Language Foundation January 2024 Monthly Meeting Summary
On Tuesday, 14 May 2024 at 14:01:28 UTC, Hipreme wrote: [snip] ### Item 8 There was a project which is basically rdmd but faster out there, done by Jonathan Marler. - https://github.com/dragon-lang/rund Sometime ago I thought about just pushing to d tools, but since no one cared about, I simply abandoned the idea, but there it is: I was thinking the same thing! I had used it a few times, but I just don't use rdmd enough to want to use an alternative to it. If the improved functionality were built-in, then that would be a positive.
Re: D Language Foundation January 2024 Monthly Meeting Summary
On Tuesday, 14 May 2024 at 13:23:17 UTC, Mike Parker wrote: The D Language Foundation's monthly meeting for January 2024 was held on Friday the 12th. There were two things of particular note about this meeting. [...] I have some things to feedback on those points ### Item 6 I had done my DIP thinking mostly about intermediate values on mixin template. That would make the value not included in mixin template, but yes, static foreach also needs that, so a good solution would be one that solves them both. ### Item 7 Redub is a tool that is basically a dub clone which improves what dub is not doing very smartly: building. Recently I've done a simple, yet major UX improvement: if dmd is not found, it tries ldc. But the apex of UX I've done is inside my engine, but I've shared a plenty of times: build selector. This tool is focused into: All the items ending with a `*` are optionally done by the user. - Downloads a D compiler if none is found on the user system - Downloads and installs git [only on Windows that is automatic. Other systems it shows an error requiring that to be done] - [Windows] - Installs MSVC and vcruntime so D is able to build it on systems that doesn't have this option (I needed that when running with a VM). - Download Android SDK/NDK [based on the user system], with the supported LDC compiler and sets up the DFLAGS required to build for Android.* - Sets up a custom D runtime which supports building to WASM, sets up the DFLAGS required to build it. May also get a supported compiler.* - Sets the DFLAGS required for being able to build for iOS.* ### Item 8 There was a project which is basically rdmd but faster out there, done by Jonathan Marler. - https://github.com/dragon-lang/rund Sometime ago I thought about just pushing to d tools, but since no one cared about, I simply abandoned the idea, but there it is:
