Re: Challenge Tuples
On Friday, 26 April 2024 at 13:25:34 UTC, Salih Dincer wrote:
You have a 5-item data tuples as Tuple(1, 2, 3, [1, 3], 5) and
implement the sum (total = 15) with the least codes using the
sum() function of the language you are coding...
Let's start with D:
Here's [STYX](https://gitlab.com/styx-lang/styx) solution:
function sum[T,U](U u): u32
{
var T result;
foreach const e in u do
if echo(is, e, T) do
result += e;
else do
result += sum;
return result;
}
function main(): s32
{
assert((1, 2, 3, [1, 3], 5).sum![u32]() == 15);
return 0;
}
A few notes:
- tuples are first class citizen
- `foreach` over tuple is like in D, i.e unrolling
- `echo` is like D `__traits`
- _Implicit Generic Application_ of `U` (that's like D's IFTI)
makes the task easy
Re: LDC Internal Compiler Error (ICE) mentioning attribute 'nocapture'
On Saturday, 30 March 2024 at 09:35:24 UTC, Per Nordlöw wrote:
Does anybody recognize the error
```
Attribute 'nocapture' does not apply to function return values
%12 = call noalias nocapture align 8 ptr @_D3xxx(ptr nonnull
%10, { i64, ptr } %11) #2, !dbg !7978
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz1
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz2
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz3
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz4
Attribute 'nocapture' does not apply to function return values
%164 = call noalias nocapture align 8 ptr @_D3xyz5(ptr
nonnull %rS72) #0, !dbg !9872
Attribute 'nocapture' does not apply to function return values
%285 = call noalias nocapture align 8 ptr @_D3xyz6(ptr
nonnull %284) #0, !dbg !9949
LLVM ERROR: Broken module found, compilation aborted!
#0 0x5ee4d001e927
llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(~/.local/ldc2-1.37.0-beta1-linux-x86_64/bin/ldc2+0x6ad4927)
Error ldc2 failed with exit code -6.
```
? It's outputted when building and running a test application
with ldc with the compiler flag `-fsanitize=address`.
You can try to add the flag `--disable-verify` (see
https://github.com/ldc-developers/ldc/issues/4284, that prevents
an internal verification).
The error message indicates that a "parameter-only" attribute is
used as a "call-site" one. Not sure if this is a bug in LDC or in
LLVM but if you're lucky the attribute will be a no-op and the
generated binary will just work.
Re: Challenge: Make a data type for holding one of 8 directions allowing increment and overflow
On Friday, 15 March 2024 at 00:00:01 UTC, Richard (Rikki) Andrew Cattermole wrote: On 15/03/2024 12:47 PM, Basile B. wrote: On Thursday, 14 March 2024 at 23:39:33 UTC, Liam McGillivray wrote: On Thursday, 14 March 2024 at 01:58:46 UTC, Richard (Rikki) Andrew Cattermole wrote: [...] I tried to rework the functions to use bitwise operations, but it was difficult to figure out the correct logic. I decided that it's not worth the hassle, so I just changed the value storage from `bool[3]` to `ubyte`. Now it works much more like your version. https://github.com/LiamM32/Open_Emblem/blob/c2014ab3f77e89c0cedcd6dbf7f8362ebfac33a9/source/common.d I did a little reading, so now I understand what it means when you have `&= 7`. But I want to ask, is this faster than `%= 8`? If not, I would like to change it to the latter for readability. `%=8` will be codegened using slower intructions w/o optimz enabled but with `&=7` you directly get the right instruction, which does not involves integer division. See https://godbolt.org/z/74vbba5aG Yes, it'll depend upon how smart the compiler is at optimizing and it may not occur in non-optimizing builds. Indeed GDC (so very likely GCC too, or whatever language uses it as backend...) does it without optimz (https://godbolt.org/z/Ke7c54Gqj). That's not very surprising. If you look at LLVM bug tracker, for the tag "missed optimisations", in the report body you'll see a lot of "GDC does that but we dont", even if here it's a bit different, as optimz are not enabled.
Re: Challenge: Make a data type for holding one of 8 directions allowing increment and overflow
On Thursday, 14 March 2024 at 23:39:33 UTC, Liam McGillivray wrote: On Thursday, 14 March 2024 at 01:58:46 UTC, Richard (Rikki) Andrew Cattermole wrote: [...] I tried to rework the functions to use bitwise operations, but it was difficult to figure out the correct logic. I decided that it's not worth the hassle, so I just changed the value storage from `bool[3]` to `ubyte`. Now it works much more like your version. https://github.com/LiamM32/Open_Emblem/blob/c2014ab3f77e89c0cedcd6dbf7f8362ebfac33a9/source/common.d I did a little reading, so now I understand what it means when you have `&= 7`. But I want to ask, is this faster than `%= 8`? If not, I would like to change it to the latter for readability. `%=8` will be codegened using slower intructions w/o optimz enabled but with `&=7` you directly get the right instruction, which does not involves integer division. See https://godbolt.org/z/74vbba5aG
Re: varargs when they're not all the same type?
On Thursday, 14 March 2024 at 20:58:21 UTC, Andy Valencia wrote:
On Thursday, 14 March 2024 at 18:05:59 UTC, H. S. Teoh wrote:
...
The best way to do multi-type varags in D is to use templates:
import std;
void myFunc(Args...)(Args args) {
Thank you. The first parenthetical list is of types, is it
not? I can't find anywhere which says what "type" is inferred
for "Args..."? (gdb pretends like "arg" is not a known
symbol.) Is it basically a tuple of the suitable type?
Andy
Most of the time the variadic template parameters are infered
from the run time parameters. In that case indeed `Args` will be
a type tuple of `args` types.
```d
void myFunc(Args...)(Args args) {}
myFunc(0,0.1); // is like the more verbose
`myFunc!(int,double)(0,0.1)`
```
However explicit instantiation can take whatever is known at
compile time, such as constant expressions or even certain static
variables. So that is rather called an `alias sequence` in D.
That being said and with the signature of `myFunc` that will
effectively only work if `Args` is made of types.
About debugging, each individual runtime arg can be inspected
using a bit of knowledge of D internals.
As you can see the elements are named following this pattern
`__param_[0-9]+`.
So with gdb used as CLI, `$ p __param_0` will (爛爛) print the
first variadic element, and so on.
Re: Challenge: Make a data type for holding one of 8 directions allowing increment and overflow
On Tuesday, 12 March 2024 at 05:38:03 UTC, Liam McGillivray wrote:
I am in need of a data type for holding direction information;
one of 8 directions on a single axis. They are named in terms
of compass directions. If D had a 4-bit datatype, I would just
use this and do `+=2` whenever I want to change the datatype,
but it doesn't.
Perhaps this would be a good programming challenge for someone
more experienced than me. Make a data type (probably a struct)
for holding one of 8 directional values using 3 bits. It should
accept the use of increment operators to change the angle.
Ideally (but optionally), it should work as an enum of the same
name; "Direction".
Here's a unittest that it should ideally pass:
```
unittest
{
Direction direction = Direction.N;
direction++;
assert(direction == Direction.NE);
direction+=3;
assert(direction == Direction.S);
direction--;
assert(direction == Direction.SE);
direction-=4;
assert(direction == Direction.NW);
}
```
While there are workarounds (as proposed in the other answers,
using operator overloads) I tend to think that the way currently
enums work with arithmetic operators is a symptom of an
incomplete type-system. Enums made of integer numbers are sub
classes of the parent [integral
sequence](https://en.wikipedia.org/wiki/Integer_sequence).
The semantics of the operators are actually not as clear as that.
What if you define
```d
enum Direction
{
N = 1, NE, S = 45, SW
}
```
?
You directly see that the proposed workarounds dont work anymore.
There are natural numbers, sub-sets of natural numbers, unordered
sequences, etc.
The type system does not represent that. Anyway, I dont blame D,
plenty of languages have the exact same problem.
Re: what was the problem with the old post blit operator already ?
On Thursday, 15 February 2024 at 03:17:11 UTC, Jonathan M Davis wrote: On Wednesday, February 14, 2024 7:17:15 PM MST Basile B. via Digitalmars-d- learn wrote: From what I remember, it was that there was no reference to the source. Things got blitted and you had to fix the copy, already blitted. Was that the only issue ? There were probably some use cases where you needed access to both the source and the destination so that you could do something to the source as well, but the core problem was simply that blitting and then mutating the copy to fix it doesn't work with const or immutable objects, since it would violate the type system to cast away const or immutable to fix the copy. The only way to work properly with const or immutable is to construct the object with the changes in the first place rather than mutating the copy after the fact. - Jonathan M Davis That point was raised by Teoh too, which raises another question. Did the "old" postblit exist before the introduction of type qualifiers ? I think to D1 obviously. That would suggest that the introduction of type qualifiers was not perfectly executed, i.e some aspects were not mastered, until, years after, someone said "wait a minute, there's something wrong".
Re: Safety is not what you think
On Monday, 5 February 2024 at 14:26:45 UTC, Basile B. wrote:
On Tuesday, 30 January 2024 at 15:38:26 UTC, Paul Backus wrote:
[...]
This definitely isn't allowed in C or C++. I wonder what the
rationale is for having this behavior in D?
[1]: https://dlang.org/spec/expression.html
An hypothesis is that this makes codegening the pre and the
post variants almost identical. The only difference is what is
yield.
[Proof](https://gitlab.com/styx-lang/styx/-/blob/master/src/styx/backend/irgen.sx?ref_type=heads#L3383).
Now there's not much to say about the topic, I just thought it
was amusing to share that (user1234 is my noname nickname here)
as people might not realize how much certain expressions allows.
In the same vein you have the possibility to select an lvalue
with a conditional expression. Pretty sure nobody knows that
the following is legal
```d
int a,b;
int c = rand();
((c & 3) ? a : b) = 42;
```
BTW, "achtung off topic", that's pretty much how the optional
access can be an lvalue:
```d
struct S {int a};
S* s; // null, by default init
s?.a = 0; // no access violation !! + valgrind is happy
```
You can lower that to a conditional expression:
```d
struct S {int a};
S* s;
typeof(S.a) __fallback; // compiler-generated
(s ? s.a : __fallback) = 0;
```
I've played a lot with that kind of expressions during the two
last years. They're funny but apparently not good enough for D ;)
To conclude.
Re: Safety is not what you think
On Tuesday, 30 January 2024 at 15:38:26 UTC, Paul Backus wrote: [...] This definitely isn't allowed in C or C++. I wonder what the rationale is for having this behavior in D? [1]: https://dlang.org/spec/expression.html An hypothesis is that this makes codegening the pre and the post variants almost identical. The only difference is what is yield. [Proof](https://gitlab.com/styx-lang/styx/-/blob/master/src/styx/backend/irgen.sx?ref_type=heads#L3383). Now there's not much to say about the topic, I just thought it was amusing to share that (user1234 is my noname nickname here) as people might not realize how much certain expressions allows. In the same vein you have the possibility to select an lvalue with a conditional expression. Pretty sure nobody knows that the following is legal ```d int a,b; int c = rand(); ((c & 3) ? a : b) = 42; ```
Re: Checking path name
On Thursday, 14 December 2023 at 03:58:37 UTC, Joel wrote:
If I get user input, for example, how do I check to see if it's
a valid path, like, file name.
```d
// something like this:
if (getUserInput.isValidPath) {
...
}
```
https://dlang.org/phobos/std_file.html#exists
Re: question
On Wednesday, 13 December 2023 at 12:49:14 UTC, fred wrote: [...] a bug ? thanks anyway Try to define the flag as static ```d static shared(bool) isDone = false; ``` I dont know if that should be a compiler error to have local shared (I tend to think yes as locals are specific to a frame, i.e a thread). At least you know how to fix the issue.
Re: mixin under -betterC
On Thursday, 23 November 2023 at 16:33:52 UTC, DLearner wrote:
Code below is intended to test simple mixin with lambda
function under -betterC.
Works with full-D, but fails with 'needs GC' errors under
-betterC.
Why is this so, bearing in mind the concatenations are executed
at
compile, not run, time?
```
// Test harness
extern(C) void main() {
import core.stdc.stdio : printf;
import testmod;
bool FirstVarGreater;
int Var_A = 4;
int Var_B = 3;
FirstVarGreater = mixin(mxnTest("Var_A", "Var_B"));
if (FirstVarGreater) {
printf("First Var is Greater\n");
} else {
printf("First Var is not Greater\n");
}
}
// testmod
string mxnTest(string strVar1, string strVar2) {
return `(int Var1, int Var2) {
if (Var1 > Var2) {
return true;
} else {
return false;
}
}(` ~ strVar1 ~ `,` ~ strVar2 ~ `)`;
}
```
You've been explained the reason why that does not work, note
however that it's not hopeless see
-
https://forum.dlang.org/thread/ahqnylrdftmmvtyvo...@forum.dlang.org
- https://github.com/dlang/dmd/pull/15636
unfortunately the PR is stalled since two months.
Re: iz v0.6.18 - Now with a modern, fast, @safe, getopt-like function
On Monday, 28 May 2018 at 00:53:45 UTC, Basile B. wrote: Last time i promoted my stuff here there were two compiler/Phobos bugs preventing to activate this nice getopt-like function. specs: - It's based on UDA. - It supports multiple locations for UDA-fied functions and variables. - It doesn't use pointers, UDA-ified variable are accessed without intermediary. - It's faster than the phobos one (although getopt is never a bottleneck) - It's `@safe` and can be even `nothrow` It could be easily added to phobos (just need to convert some EnumSet to BitFlag). - code: https://github.com/BBasile/iz/blob/master/import/iz/options.d#L596 - DUB: https://code.dlang.org/packages/iz - doc: https://iz.dpldocs.info/v0.6.18/iz.options.handleArguments.html - cool demo: https://github.com/BBasile/Coedit/blob/master/dastworx/src/main.d#L18 Note that despite of the run-time compatibility mention in the README, this module is part of a subset of IZ that can be used without all the concept of Nogc as used in iz. (at some point i should split the twos parts). such attribute-based getopt is now used in styx driver e.g - [here](https://gitlab.com/styx-lang/styx/-/blob/master/src/styx/session.sx?ref_type=heads#L107) - [here](https://gitlab.com/styx-lang/styx/-/blob/master/src/styx/session.sx?ref_type=heads#L492) In styx now I just do ``` if !getOpt, ) do return 1; ``` At some point we forgot what we wanted to do in D ;)
Re: Why can't we use strings in C++ methods?
On Saturday, 4 November 2023 at 13:51:20 UTC, Dadoum wrote:
On Saturday, 4 November 2023 at 13:45:56 UTC, Emmanuel Danso
Nyarko wrote:
[...]
There is a syntax disagreement here that's why the D compiler
is instantly stopping you from doing any symbol generated
interaction with string in C++ interop. C++ doesn't know
'string' and C++ mangles with parameters and so passing string
will make string get involved with the symbol generation and
since string(std::string) in C++ is a template library, the D
compiler stops you from engaging with 'string'
I don't think it's related to the existence of std::string at
all since all dynamic array types are forbidden.
```d
extern (C++) void hello(ubyte[] arg) {
import std.stdio;
writeln(arg);
}
```
also fails to compile while this works:
```d
extern (C) void hello(ubyte[] arg) {
import std.stdio;
writeln(arg);
}
```
The type simply cannot be mangled using the C++ mangler as it
does not exist over there. You might have the impression that
this should be allowed, e.g as an extension, but keep in mind
that `extern(C++)` is firstly designed to link against object
produced by a C++ compiler.
Now why this works in `extern(C)` ? Because C does not mangle the
parameters, a function linkage name is simply its unqualified
name, so linking will work even if the parameter types are
specific to D.
Now there is still the question whether the `extern(C)` code will
work as expected or not.
Re: Function Overloading
On Thursday, 2 November 2023 at 11:17:42 UTC, Salih Dincer wrote:
On Wednesday, 1 November 2023 at 20:04:52 UTC, Basile B. wrote:
Yes. D constructors are not named but the current
implementation adds a name that is `__ctor`, so add
```d
alias add = __ctor;
```
to you struct.
Yeah, it works! Thanks...:)
SDB@79
I'm no sure how this could be used IRL but keep well in mind that
**this is not nice code**.
My answer should be more interepreted as "yes that is technically
possible". ("can do" -> yes VS "should do" -> no).
You also have the `opCall()` option btw.
Re: Function Overloading
On Tuesday, 31 October 2023 at 20:09:44 UTC, Salih Dincer wrote:
[...]
is it possible to do something like `alias add = this;`?
```d
struct Calculate
{
int memory;
string result;
auto toString() => result;
// alias add = this;
import std.string : format;
this(string str)
{
result ~= str.format!"%s + ";
}
this(int num)
{
memory += num;
add(num.format!"%s");
}
}
```
SDB@79
Yes. D constructors are not named but the current implementation
adds a name that is `__ctor`, so add
```d
alias add = __ctor;
```
to you struct.
Note that however this kind of internal details should not be
used, even if chances that this name changes are low (old 2014
code that uses it still compiles and have never broke, phobos
uses it too IIRC).
Otherwise take care to copy construction, that wont work with the
alias.
Re: How to use core.vararg to print D variadic arguments and their types without using ! (template instantiation)?
On Thursday, 14 September 2023 at 15:19:29 UTC, BoQsc wrote:
https://dlang.org/phobos/core_vararg.html
The common way to use **va_arg** is `va_arg!(int)(_argptr);`
What would be the alternative way or syntax that behave exactly
the same way, even if more verbose?
`va_arg!(int)(_argptr);` is taken from an example in:
https://dlang.org/spec/function.html#d_style_variadic_functions
here's how
```d
import core.vararg;
void main()
{
foo(.5, 5);
}
void foo(...)
{
int i = void;
va_arg(_argptr, typeid(i), );
assert(i == 5);
double d = void;
va_arg(_argptr, typeid(d), );
assert(d == .5);
}
```
Re: Weird floating point rounding - Bug or how to control it correctly
On Thursday, 14 September 2023 at 03:23:48 UTC, An Pham wrote:
import std.stdio;
void main()
{
float f = 6394763.345f;
import std.format : sformat;
char[80] vBuffer = void;
writeln("6394763.345 = ", sformat(vBuffer[], "%.4f",
f));
}
Output
6394763.345 = 6394763.5000
Classic question. The float literal `6394763.345f` is not
representable as IEEE-754 floating point number.
Try https://www.h-schmidt.net/FloatConverter/IEEE754.html for a
short introduction to the issue.
Re: malloc error when trying to assign the returned pointer to a struct field
On Friday, 8 September 2023 at 19:14:47 UTC, H. S. Teoh wrote: [...] My guess is that you have a double-free somewhere, or there's a buffer overrun. Or maybe some bad interaction with the GC, e.g. if you tried to free a pointer from the GC heap. That cant be a GC problem as rempas project is compiled with `-betterC`
Re: malloc error when trying to assign the returned pointer to a struct field
On Friday, 8 September 2023 at 18:59:21 UTC, rempas wrote: On Friday, 8 September 2023 at 16:02:36 UTC, Basile B. wrote: Could this be a problem of copy construction ? I don't think so. My idea was that if you dont have defined a copy constructor and if an instance is assigned to another, then that other instance share the same pointer, which can cause memory errors. To eliminate that risk and to detect where default post-blitting may happen you can add ```d @disable this(this); ``` to the struct.
Re: malloc error when trying to assign the returned pointer to a struct field
On Friday, 8 September 2023 at 07:59:37 UTC, rempas wrote: I do have the following struct: [...] Is there any possible that there is a compiler bug? I do use ldc2 and `betterC`! Could this be a problem of copy construction ?
Re: Pointer to environment.get
On Monday, 28 August 2023 at 10:20:14 UTC, Basile B. wrote:
On Monday, 28 August 2023 at 06:38:50 UTC, Vino wrote:
Hi All,
The the below code is not working, hence requesting your
help.
Code:
```
import std.stdio;
import std.process: environment;
void main () {
int* ext(string) = ("PATHEXT");
writeln(*ext);
}
```
Problems is that "PATHEXT" is a runtime argument. If you really
want to get a pointer to the function for that runtime argument
you can use a lambda:
```d
import std.stdio;
import std.process: environment;
void main () {
alias atGet = {return environment.get("PATHEXT");}; //
really lazy
writeln(atGet); // pointer to the lambda
writeln((*atGet)());// call the lambda
}
```
There might be other ways, but less idiomatic (using a struct +
opCall, a.k.a a "functor")
To go further, the correct code for syntax you wanted to use is
actually
```d
alias Ext_T = string (const char[] a, string b); // define a
function type
alias Ext_PT = Ext_T*; // define a function **pointer** type
Ext_PT ext =
```
But as you can see that does not allow to capture the argument.
Also it only work as AliasDeclaration RHS.
Re: Pointer to environment.get
On Monday, 28 August 2023 at 06:38:50 UTC, Vino wrote:
Hi All,
The the below code is not working, hence requesting your help.
Code:
```
import std.stdio;
import std.process: environment;
void main () {
int* ext(string) = ("PATHEXT");
writeln(*ext);
}
```
Problems is that "PATHEXT" is a runtime argument. If you really
want to get a pointer to the function for that runtime argument
you can use a lambda:
```d
import std.stdio;
import std.process: environment;
void main () {
alias atGet = {return environment.get("PATHEXT");}; // really
lazy
writeln(atGet); // pointer to the lambda
writeln((*atGet)());// call the lambda
}
```
There might be other ways, but less idiomatic (using a struct +
opCall, a.k.a a "functor")
Re: Adding to a global AliasSeq
On Tuesday, 15 August 2023 at 12:20:54 UTC, repr_man wrote: On Tuesday, 15 August 2023 at 07:02:45 UTC, Basile B. wrote: You can add a kind of tag with the mixin, that will allow to to test if the type supplied to `f` is well a Base implementor: Firstly, thank you for your help. This is probably the best solution. Secondly, I feel very stupid for not having come up with this by myself. Would you be willing to explain some of the thought process behind your solution? Are there any key factors that I should look for in future template-related problems? Or, if it just comes from experience and seeing this sort of thing repeatedly, that's fair, too. Thanks, once again! This is just classic D. The way this works is tied to overload-sets resolution. You have two functions templates, same name, same count of parameters. The only way to make both exist in the set is "template constraint", one works given certain static conditions, the other not. Also, as it's time for the explanations, one thing about that system and that you should keep in mind is that it's costly, i.e "can cause major slowdown of compilation".
Re: Adding to a global AliasSeq
On Tuesday, 15 August 2023 at 02:30:37 UTC, repr_man wrote:
Consider the following template mixin:
```d
mixin template Base()
{
int x(){ return 10; }
}
```
It could be used in a variety of structs as follows:
```d
struct Child
{
mixin Base!();
}
```
Now, let's suppose we write a function with a parameter that
should only be able to take items that mix in `Base`:
```d
auto f(T)(T arg)
{
return arg.x;
}
```
This works because D uses structural subtyping. However, this
creates a problem: if we make another struct that looks like it
mixes in `Base` and pass it to the function, we could get
unexpected results:
```d
struct Other
{
int x = 5;
}
unittest
{
import std.stdio;
auto c = Child();
auto o = Other();
writeln(f(c));
writeln(f(o));
}
```
The output from running `dub test` is as follows:
```
10
5
```
[...]
Is there any template-fu of which I am not aware that would
make the thing I am trying to do possible?
You can add a kind of tag with the mixin, that will allow to to
test if the type supplied to `f` is well a Base implementor:
```d
mixin template Base()
{
enum LookImABase = true;
int x(){ return 10; }
}
struct Child
{
mixin Base!();
}
auto f(T)(T arg)
if (is(typeof(T.LookImABase)))
{
return arg.x;
}
struct Other
{
int x = 5;
}
void main(string[] args)
{
import std.stdio;
auto c = Child();
auto o = Other();
writeln(f(c)); // ok
writeln(f(o)); // error
}
```
This is what is called in D the "design by introspection". There
are alternatives way of doing that, notably with UDAs.
```d
mixin template Base()
{
enum Base;
@Base int x(){ return 10; }
}
```
But the introspection code is more complex (std.traits getUDA,
hasUDA)
Finally a different approach, with no introspection, is to use a
named mixin:
```d
mixin template Base()
{
enum Base;
int x(){ return 10; }
}
struct Child
{
mixin Base!() base;
}
auto f(T)(T arg)
{
return arg.base.x;
}
struct Other
{
int x = 5;
}
void main(string[] args)
{
import std.stdio;
auto c = Child();
auto o = Other();
writeln(f(c));
writeln(f(o)); // error
}
```
which works but has the same problem as what lead you to ask your
question, for example if it turns out that the supplied argument
has unfortunately a `base` member that itself has a `x` member.
Re: Compiler interoperability
On Friday, 7 July 2023 at 08:19:28 UTC, Chris Katko wrote: For a specific system (Linux, e.g): What is the level of interoperability between the different D compilers; DMD, LDC, and GDC? It appears each one has different benefits, and, different experimental features. Link-time optimization for LDC. GDC offering static analysis. I imagine there are more. If I compile a D program with say, DMD, will every D library I include also have to use that same compiler Yes because of exception handling, the runtime functions are different. You can try and you'll see linking error because of a missing "*personality*", symbol. (and compiler version) from scratch and need recompiled? From version to version of a same vendor that might work but as phobos is not binary compatible (ABI of functions is allowed to change from a version to another) this is a bit the lottery. Or is there a pre-defined ABI that makes everything compatible? If I use shared libraries instead of static linking, does the situation change? Additionally, how do the debuggers GDB vs LLDB behave when compiled using a different brand D compiler? (e.g. demangling) Mangling is identical for each vendor (this is a language spec) but as mentioned, EH functions are different so the breakpoint set to break on `throw` for DMD (i.e `_d_throwdwarf`) will not work for `LDC` (i.e `_d_throw_exception`) I have my own experiences but I'm not sure if there's clear cut "yes, definitely it's [this case]." answers out there. So to conclude there's no interoperability
Re: key membership in multi-dimensional assoc. array
On Thursday, 15 June 2023 at 01:47:45 UTC, Paul wrote:
I found I can check for key membership in a multi-D aa...
```d
byte zKey = someval;
byte[byte][byte][byte] cubelist;
foreach(byte xK, yzcubelist; cubelist) {
foreach(byte yK, zcubelist; yzcubelist) {
foreach(byte zK, val; zcubelist) {
```
with this expression...
```d
if(zKey in cubelist[xK][yK])
```
Is there a way to check for membership in the x & y dimensions?
```d
if(yKey in cubelist[xK] ??? [zK])
```
*Thanks in advance for any ideas or solutions.*
`&&`
Re: assert/static assert message format difference
On Tuesday, 13 June 2023 at 16:46:26 UTC, DLearner wrote:
Only a small thing, but is it intended that:
```
void main() {
// static assert (false, "Static Assert triggered");
assert(false, "Assert triggered");
}
```
produces
```
core.exception.AssertError@staticassertex01.d(4): Assert
triggered
```
but removing the // produces
```
staticassertex01.d(3): Error: static assert: "Static Assert
triggered"
```
ie message surrounded by double-quotes?
internal detail.
Static assert will render the message by formatting an AST node,
i.e the StringExp (as the string has to be statically evaluable),
using a compiler module called the hdrgen, leading to have the
double quotes included, because the hdrgen is supposed to give
back the source code for a particulat node.
Runtime assert only know the string ptr and len, which are
runtime values. So... in that case it's more like a format %s,
that takes another path.
Re: byte and short data types use cases
On Friday, 9 June 2023 at 15:07:54 UTC, Murloc wrote:
On Friday, 9 June 2023 at 12:56:20 UTC, Cecil Ward wrote:
On Friday, 9 June 2023 at 11:24:38 UTC, Murloc wrote:
If you have four ubyte variables in a struct and then
an array of them, then you are getting optimal memory usage.
Is this some kind of property? Where can I read more about this?
Yes, a classsic resource is
http://www.catb.org/esr/structure-packing/
So you can optimize memory usage by using arrays of things
smaller than `int` if these are enough for your purposes,
It's not for arrays, it's also for members
```d
struct S1
{
ubyte a; // offs 0
ulong b; // offs 8
ubyte c; // offs 16
}
struct S2
{
ubyte a; // offs 0
ubyte c; // offs 1
ulong b; // offs 8
}
static assert(S1.sizeof > S2.sizeof); // 24 VS 16
```
this is because you cant do unaligned reads for `b`, but you can
for `a` and `c`.
but what about using these instead of single variables, for
example as an iterator in a loop, if range of such a data type
is enough for me? Is there any advantages on doing that?
Not really the loop variable takes a marginal part of the stack
space in the current function. You can just use `auto` and let
the compiler choose the best type.
Re: How do I generate `setX` methods for all private mutable variables in a class?
On Tuesday, 6 June 2023 at 14:23:59 UTC, Steven Schveighoffer
wrote:
On 6/5/23 11:33 AM, Basile B. wrote:
[...]
Ugh, don't do it that way. Always give opDispatch a template
constraint or it will suck to use.
Also, given the problem constraints, you can build the method
automatically using the string.
```d
auto opDispatch(string member, T)(auto ref T t)
if(member.startsWith("set"))
{
mixin(toLower(m[3]), m[4 .. $], " = t;");
}
```
-Steve
yeah I know that opDispatch is disliked because it is tried in a
SFINAE fashion, as citicized by Adam. But on the other side it's
the best opover.
Re: How do I generate `setX` methods for all private mutable variables in a class?
On Monday, 5 June 2023 at 15:28:34 UTC, Paul Backus wrote:
Is there a reason you can't just make these fields `public`?
My bet is that OP actually wants to generate something like
```d
void setStrokeWidth(uint value)
{
if (value = strokeWidth) return;
strokeWidth = value;
redraw();
// or maybe...
// needRedraw = true;
}
```
that's a common pattern in 2D graphic libraries.
Re: How do I generate `setX` methods for all private mutable variables in a class?
On Monday, 5 June 2023 at 15:28:34 UTC, Paul Backus wrote:
Is there a reason you can't just make these fields `public`?
My bet is that OP actually wants to generate something like
```d
void setStrokeWidth(uint value)
{
if (value = strokeWidth) return;
strokeWidth = value;
redraw();
// or maybe...
// needRedraw = true;
}
```
that's a common pattern in 2D graphics libraries
Re: How do I generate `setX` methods for all private mutable variables in a class?
On Monday, 5 June 2023 at 15:13:43 UTC, Basile B. wrote:
On Monday, 5 June 2023 at 13:57:20 UTC, Ki Rill wrote:
How do I generate `setX` methods for all private mutable
although I did not spent time on the setter body... I suppose
the question was more about the metprogramming technic, and
that you don't want a pre-mashed solution ;)
By the way...an other solution is to use
[opDispatch](https://dlang.org/spec/operatoroverloading.html#dispatch):
```d
class Color {}
class Rectangle {
private Color fillColor;
private Color strokeColor;
private uint strokeWidth;
auto opDispatch(string member, T)(auto ref T t)
{
static if (member == "setStrokeWidth") {}
else static if (member == "setStrokeColor") {}
else static if (member == "setFillColor") {}
else static assert(0, "cannot set " ~ member);
return this;
}
}
void main()
{
(new Rectangle)
.setStrokeWidth(0)
.setStrokeColor(null)
.setFillColor(null);
}
```
Sure the first solution takes advantage of D features but to
generate code that finally looks like C# or Delphi (`Set`, `Get`;
`property`, etc.)
On top of that I tend to prefer the later solution because
self-introspection based on `__traits` has corner issues,
especially when typecons-like structures are used for the members
(e.g sumtype, nullable, etc.).
Re: How do I generate `setX` methods for all private mutable variables in a class?
On Monday, 5 June 2023 at 13:57:20 UTC, Ki Rill wrote:
How do I generate `setX` methods for all private mutable
variables in my class? Do I need to use `__traits`?
I need this for my
[tiny-svg](https://github.com/rillki/tiny-svg) project to
generate `setX` methods for all Shapes.
Example:
```D
class Rectangle {
private immutable ...;
private Color fillColor;
private Color strokeColor;
private uint strokeWidth;
this(int x, int y) {...}
mixin(???);
// I need this:
Rectangle setFillColor(Color color) {...}
Rectangle setStrokeColor(Color color) {...}
Rectangle setStrokeWidth(uint color) {...}
}
```
Usage:
```D
new Rectangle(10, 10)
.setFillColor(Colors.white)
.setStrokeColor(Colors.black)
.setStrokeWidth(3);
```
You need to put an user attribute on the fieldd then to use
static introspection to generate the setters.
Very basically that works like that
```d
enum Set;
class Color {}
auto generateSetters(T)()
{
string result;
import std.traits;
static foreach (m; __traits(allMembers, T))
{{
alias member = __traits(getMember, T, m);
static if (hasUDA!(member, Set))
result ~= "void set" ~ m ~ "(" ~
typeof(member).stringof ~ "){}\n";
}}
return result;
}
class Rectangle {
@Set private Color fillColor;
@Set private Color strokeColor;
@Set private uint strokeWidth;
mixin(generateSetters!(Rectangle)());
}
void main()
{
with (new Rectangle) {
setstrokeWidth(0);
setstrokeColor(null);
setfillColor(null);
}
}
```
although I did not spent time on the setter body... I suppose the
question was more about the metprogramming technic, and that you
don't want a pre-mashed solution ;)
Re: Concepts like c++20 with specialized overload resolution.
On Saturday, 27 May 2023 at 13:23:38 UTC, vushu wrote: [...] Is there something equivalent in dlang, doesn't seem like d support specialized overload? D solution is called [template constraints](https://dlang.org/spec/template.html#template_constraints).
Re: Multiple destructors
On Friday, 26 May 2023 at 09:07:07 UTC, Alex Biscotti wrote:
Hello everyone! While researching the phobos library, I
discovered that a class can have multiple destructors if the
destructors are added via mixin injection. Accordingly, the
question is whether a description of such feature should be
added to the documentation, since the current description is a
bit confusing - ["There can be only one destructor per
class"](https://dlang.org/spec/class.html#destructors)?
This is not a compiler bug, mixin templates are allowed to
introduce a dtor; observe the output of
```d
import std;
mixin template AddNewDtor()
{
~this()
{
writeln("Mixin dtor");
}
}
class Foo
{
~this()
{
writeln("Class dtor");
}
mixin AddNewDtor;
}
void main()
{
{
Foo s = new Foo;
writeln("-- dtor effect --");
s.__dtor;
}
{
Foo s = new Foo;
writeln("-- xdtor effect --");
s.__xdtor;
}
writeln("-- auto generated destruction... --");
}
```
as you can see, the internal `__xdtor` function is designed to
call the two destructors, while `__dtor` only the "normal one",
i.e the one that 's not mixed in.
This is more a documentation bug IMO.
Re: Beta 2.104.0
On Tuesday, 2 May 2023 at 08:47:35 UTC, Iain Buclaw wrote: On Tuesday, 2 May 2023 at 03:08:00 UTC, zjh wrote: On Tuesday, 2 May 2023 at 00:34:45 UTC, Iain Buclaw wrote: Glad to announce the first beta for the 2.104.0 release, ♥ to the 36 contributors. [104](https://dlang.org/changelog/2.104.0.html) ```d alias Tint = int; @Tint void f(); ``` Here says not to use basic types as attributes, but the following example give it another basic type? ```d @int void f(); ``` The keyword here in the changelog is: **would**; that is to say, the compiler previously rejected basic types, but now they are accepted. It was already allowed to put types in UDAs, but the parser would reject basic types written directly, requiring the use of an alias. I'll have a think about how that entry could be rephrased to avoid confusion, though you are welcome to raise your own pull request to clarify the wording. That's a half baked change, it would have been better to go a bit further: previously ```d alias Tint = int; @Tint void f(); ``` now ```d @int void f(); ``` nice. But previously ```d alias Tint = int; @Tint(1) void f(); ``` now ```d @int(1) void f(); // Not Good ``` that's unfortunately still an error.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 27 April 2023 at 00:16:10 UTC, Walter Bright wrote: This also works: alias F = MySuperLongNameFlag; auto flag = F.A | F.B | F.C | F.D; set_flags(F.A | F.B | F.C | F.D); It's similar to setting a local variable to some complex expression, just so you don't have to repeat that expression multiple times. It's a misconception of the problem that the DIP tried to solve. What the DIP tried to solve is that the compiler should know that you are using an enum member. Actually I even think this should work without any special syntax, as a "last resort", let's say. But as you've explained, through Mike's report, this causes problems for D because the identifier resolution is tied to a particular implementation, i.e your fast symtabs.
Re: D style - member functions
On Wednesday, 26 April 2023 at 18:24:08 UTC, DLearner wrote:
Consider:
```
struct S1 {
int A;
int B;
int foo() {
return(A+B);
}
}
struct S2 {
int A;
int B;
}
int fnAddS2(S2 X) {
return (X.A + X.B);
}
void main() {
import std.stdio : writeln;
S1 Var1 = S1(1, 2);
writeln("Total Var1 = ", Var1.foo());
S2 Var2 = S2(1, 2);
writeln("Total Var2 = ", fnAddS2(Var2));
return;
}
```
Of the two ways shown of producing the total from the same
underlying structure, which is the better style?
To make both version really equivalent you should rather write
int fnAddS2(ref S2 X) {
return (X.A + X.B);
}
the `this` for the member functions is a reference as obviously
you want to eventually mutate the members and not their copy.
What happened in your `fnAddS2` is that the whole stuff was
blitted and mutation of the members would have no effect on the
argument used in the call.
Further, do we care about the situation where there are many
variables of type 'S', which presumably means the function code
generated from S1 gets duplicated many times, but not so with
S2?
Your presumption is wrong. The code generated for a function is
not regenerated per instance. One version is enough to handle all
the instances as the instance is itself a parameter of the
function. What is happening for `foo()`, i.e the member function,
is that there is an hidden parameter. Depending on the language
the way the hidden argument is read might be slightly different
but you really should consider that
struct S1 {
int A;
int B;
int foo() {
return(A+B);
}
}
is like
struct S1 {
int A;
int B;
static int foo(ref S1 that) {
return(that.A+that.B);
}
}
or
struct S1 {
int A;
int B;
}
int foo(ref S1 that) {
return(that.A+that.B);
}
One problem of the hidden parameter is that for example
int foo(const ref S1 that) {
return(that.A+that.B);
}
cannot be expressed (at first glance)... how to qualify `const`
something that is hidden ? It's actually possible using a member
function attribute:
struct S1 {
int A;
int B;
int foo() const /*const is for the hidden parameter*/ {
return(A+B);
}
}
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. [...] While I was rather "pro" I think that D lacked an absolute necessity for that. As explained earlier on IRC, enum type inference is also very intersting when the language has a bitfield type based on an enum, like the `Set Of` pascal construct, which makes enum member something really commonly used, much more than in D.
Re: alias Error: need 'this'
On Sunday, 19 March 2023 at 13:49:36 UTC, bomat wrote: Thanks for the suggested workaround, I can live with the `static` solution, I guess. I still don't understand why it's necessary, though. Since a `struct` is a value type and, as I understand it, stack allocated, what difference does it make to the compiler whether I alias `variableWithALongName` or `myStruct.memberWithALongName`? Shouldn't it be the exact same underlying mechanism? Thanks and regards bomat D aliases are for symbols, but what you try to alias is an expression. You might feel that what you request may work, but that's only a very particular case. Generally expressions cannot be aliased because without context they become polymorphic (or erather polysemous).
Re: Difference between using `import` with/without the colon
On Sunday, 19 March 2023 at 07:20:17 UTC, Jeremy wrote: Hello, is there any difference at all between the following lines, as an example: ```d import std.regex; import std.regex : matchFirst; ``` What technical differences does it make (except for having the identifier available), using the colon? Does it make any speed/optimization changes or am I better off just importing the whole module? The colon-form, aka "selective import" has for effect 1. to create a local alias so this can indeed speedup symbol lookups in the sense that search will succeed before looking in the scope of the imports. 2. to make non-selected symbols, i.e not listed in the colon right hand side, in the import not available. Note that using both makes no sense, but I guess you did that to express more clearly what you meant.
Re: const in functions
On Sunday, 12 March 2023 at 15:09:45 UTC, Salih Dincer wrote:
Hi,
[...]
// A, we can get its to guarantee us that parameters
// won't change:
auto inConst(T)(T a, const T b) // const
{ // it's not needed --^ but ^-- why can't this be used
Well you got the great answers to your questions already but I
like to add a comment that is that
**`const` parameters without `ref` are really moot.**
I whish at least that they could give the guarantee to be rvalues
(i.e have no address) but this is actually not the case. All the
D compilers will actually copy `const` parameters to locals,
making them lvalues, unless optimizations are requested(1).
See codegen : https://godbolt.org/z/vev1PGWh3.
This brings the idea that maybe a `rvalue` storage class could be
added to the language.
(1): Actually DMD does not drop the copy **at all**, even with -O.
Re: Using Windbg to debug D applications and unittests
On Saturday, 4 March 2023 at 19:19:26 UTC, Chris Piker wrote: On Monday, 27 February 2023 at 12:09:50 UTC, Basile B. wrote: At least this is what is done for the Dexed GDB widget, so that gdb breaks automatically when an Error or an Exception is new'd (https://gitlab.com/basile.b/dexed/-/blob/master/src/u_gdb.pas#L2072). Glad you mentioned Dexed. I Had been meaning to try it out but forgot about it. I just downloaded the deb and will give it a go. Thanks! The GDB widget wont work on windows I think. The point of my first answer was just to show you how to automatically break when something is thrown.
Re: Using Windbg to debug D applications and unittests
On Saturday, 25 February 2023 at 15:55:33 UTC, solidstate1991 wrote: I had a lot of trouble trying to get Visual Studio to catch handled exceptions, which would have been mandatory for debugging unittests, but I either forgot how to do it, or something have changed in either the newer versions of VS or the D compilers I use (LDC, DMD). [...] You must break on `_d_throwc` (windows), `_d_throwdwarf` (linux), `_d_throw_exception` (ldc). They are defined in - https://github.com/dlang/dmd/blob/master/druntime/src/rt/deh.d - https://github.com/dlang/dmd/blob/master/druntime/src/rt/deh_win32.d - https://github.com/dlang/dmd/blob/master/druntime/src/rt/deh_win64_posix.d At least this is what is done for the Dexed GDB widget, so that gdb breaks automatically when an Error or an Exception is new'd (https://gitlab.com/basile.b/dexed/-/blob/master/src/u_gdb.pas#L2072).
Re: What is the 'Result' type even for?
On Friday, 20 January 2023 at 03:11:33 UTC, Ruby The Roobster
wrote:
Take this example:
[...]
What is the purpose of this 'Result' type? To serve as a
generic range?
Yes this is a lazy input range. Use `.array` to yield directly as
a concrete value,
then you can append using `~=`.
Note that there are special functions to keep the laziness, e.g
`chain` to happen an input range to another element-compatible
input range
```
import std;
void main()
{
auto c = "a|b|c|d|e".splitter("|").chain(["f"]);
string[] e = ["a", "b", "c", "d", "e", "f"];
assert(c.equal(e));
}
```
Re: Is there a formula for overflow?
On Wednesday, 30 November 2022 at 03:19:49 UTC, Basile B. wrote: [...] It's always a wraparound (think modulo) but your examples with negative number can be explained because there are hidden unsigned to signed implicit convertions. That the only special things D does. forgot to say, you can use the dmd flag -vcg-ast to see the hidden rewrites
Re: Is there a formula for overflow?
On Wednesday, 30 November 2022 at 03:07:44 UTC, thebluepandabear
wrote:
I am reading through Ali's book about D, and he gives the
following examples for an overflow:
```D
import std.stdio;
void main() {
// 3 billion each
uint number_1 = 30;
uint number_2 = 30;
}
writeln("maximum value of uint: ", uint.max);
writeln("
number_1: ", number_1);
writeln("
number_2: ", number_2);
writeln("
sum: ", number_1 + number_2);
writeln("OVERFLOW! The result is not 6 billion!");
```
writeln((30LU + 30LU) % uint.max);
The result overflows and is 1705032704.
Also for the second example, it overflows and comes up with the
value of 4294967286:
```D
void main() {
uint number_1 = 10;
uint number_2 = 20;
writeln("PROBLEM! uint cannot have negative values:");
writeln(number_1 - number_2);
writeln(number_2 - number_1);
}
```
Also a fun one, the following produces 4294967295:
```D
uint number = 1;
writeln("negation: ", -number);
```
writeln( cast(uint) -(cast(int)1) );
But the book doesn't talk about why the D compiler came up with
these results (and it also goes for division/multiplication)
for the overflow (or maybe it did further down ?), as in it
didn't talk about the formula it used for calculating this
value.
I am curious as to what formula the D compiler uses for
calculating 'overflowed' values, if such thing exists? :)
Regards,
thebluepandabear
It's always a wraparound (think modulo) but your examples with
negative number can be explained because there are hidden
unsigned to signed implicit convertions.
That the only special things D does.
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Tuesday, 29 November 2022 at 18:59:46 UTC, DLearner wrote:
To me, it appears that there are really two (_entirely
separate_) concepts:
A. Supporting the useful concept of variable length (but
otherwise entirely conventional) arrays;
B. Supporting a language feature that acts as a window to an
array, through which that array can be manipulated.
And currently these two concepts are combined.
Suggestion: it would be clearer if the two concepts were
separated:
1. Convert 'int[] VarArr;' so it produces a straightforward
_value-type_ variable array, called 'VarArr';
2. Implement a new concept 'int slice Window;' to produce an
object of type 'int slice', called 'Window'.
'Window' is a 'slice' into an int array, not an array itself
or even a variable.
Opinions?
I have implemented that in
[styx](https://gitlab.com/styx-lang/styx).
1. You have the type for dynamic arrays, called TypeRcArray,
syntax is `Type[+]`
2. You have the type for slices (what you describe as a window),
syntax is `Type[]`
but it is mostly obtained using expressions, e.g `mySlice =
myRcArray[lo .. hi]` or
`myStaticArray[lo .. hi]` or `myPointer[lo .. hi]`.
This sounded like a good idea but it [has appeared very
quickly](https://styx-lang.gitlab.io/styx/type.html#noteonlifetime) that slices are not so useful, especially when management is based on reference counting because then slices requires a form of management too. Here is why:
Main caracteristics of a slice are
- they cannot modify the identity of their sources. The identity
of the source is what makes the integrity of a dynamic array,
what makes their references countable. So it is the content
pointer and the length. In consequence you cannot change the
length of the source, you can only reduce the view. You can
change the elements in the view.
- the length and the pointer are cached as a value on the stack
while for a dynamic array this is stored before that data, on the
heap.
Problems start happening when you escape a slice
```d
struct S
{
var s32[] memberSlice;
}
function f(var S s): auto
{
var s32[+] a = (new s32[+])(2);
// problem 1 : `s` lifetime > `a` lifetime
s = (a[]).tupleof; // note: tuples are used in pace of
struct literals
// problem 2
return a[1 .. $]; // a is automatically decref'd on return
// so the caller pulls a dead heap block.
}
```
Essentially slices are only useful to be consumed locally,
typically
```d
while mySlice.length do
{
slice = slice[1..$];
}
```
And that's it. So at first glance slices are some cool,
simplified, functionally stripped down arrays but they introduce
new problems, at least when management of dynamic arrays is based
on reference counting. Those new problems can only be solved
using lifetime analysis (so a compile-time check... still better
than runtime ref counting however).
GDB completions in dexed debugger GUI
For those who are not aware, GDB completion in CLI (TAB) is not just like standard bash completions, that also allows to complete using DWARF informations, very similarly to IDE completion. [Dexed-ide](https://gitlab.com/basile.b/dexed/-/releases/v3.9.20) debugger (aka "GDB Commander") now support this feature: short video demonstration: https://www.youtube.com/watch?v=hZYslYFohrI
GDB completions in dexed debugger GUI
For those who are not aware, GDB completion in CLI (TAB) is not just like standard bash completions, that also allows to complete using DWARF informations, very similarly to IDE completion. [Dexed-ide](https://gitlab.com/basile.b/dexed/-/releases/v3.9.20) debugger (aka "GDB Commander") now support this feature: short video demonstration : https://www.youtube.com/watch?v=hZYslYFohrI
Dexed-ide 3.9.18
This update allows to open makefiles as language-agnostic projects. For example The sortcut for "Compile project" will have the same effect as make -f Not very interesting for D one would say, however as this feature is useful for another of my project that addition gives strong guarantees that dexed will not be abandoned. Otherwise the release comes with a few fixes: - The lack of maintenance of dparse lead to use a derived Parser class to fix crashes that can happen with incomplete code. - Projects groups and workspace persistence was broken - Packagers wont have to deal with my old, unmaintained "iz" D library. Links: - [release](https://gitlab.com/basile.b/dexed/-/releases) - [homepage](https://gitlab.com/basile.b/dexed)
Re: What exact debugging information is added to the binary and how to parse it all?
On Friday, 13 May 2022 at 16:11:14 UTC, BoQsc wrote: Haven't used debuggers or debugged a lot just yet, but I've had this question in my mind and I'd like to inspect some debugging information manually. Are there some kind of documentation or specification and are there a lot of information that is hidden in a an average "debuggable" binary? if you're on linux then the debug information are generated in a format that's well specified called DWARF. DWARF essentially contain information about - translation unit filename - call stack - each instruction of the runtime code is associated to a location (allowing to put breakpoints) - the layout of user defined types (allowing to inspect instances) - the inheritance chain of user defined types - the variable types (alowing to inspect variables) That's a lot of information, they non-trivially increase the size of the binary, but this is required to debug a program. [learn more](https://dwarfstd.org/)...
Re: What are (were) the most difficult parts of D?
On Thursday, 12 May 2022 at 15:31:03 UTC, Steven Schveighoffer
wrote:
On 5/12/22 11:18 AM, jmh530 wrote:
On Thursday, 12 May 2022 at 12:13:32 UTC, Basile B. wrote:
[snip]
```
is ( Type : TypeSpecialization , TemplateParameterList )
is ( Type == TypeSpecialization , TemplateParameterList )
is ( Type Identifier : TypeSpecialization ,
TemplateParameterList )
is ( Type Identifier == TypeSpecialization ,
TemplateParameterList )
```
I never remember those variants, because basically you never
need them...
They were required for std.traits and that's it.
What's the difference between a Type and Type Identifier?
Type is a type, Identifier is an identifier.
In general, after such expressions, Identifier is now declared
as an alias to the type, if the is expression was true. But in
special forms, it might be a portion of the type.
So e.g.:
```d
static if(is(Foo Bar == struct))
{
// inside here, it was determined that `Foo` was a type, and
it is a
// struct, and now, `Bar` is aliased to `Foo`
}
```
It's very confusing syntax though.
-Steve
yess that kind of stuff
Re: What are (were) the most difficult parts of D?
On Thursday, 12 May 2022 at 14:06:13 UTC, Arjan wrote:
On Thursday, 12 May 2022 at 11:05:08 UTC, Basile B. wrote:
On Wednesday, 11 May 2022 at 05:41:35 UTC, Ali Çehreli wrote:
- Operator overloading in certain cases was confusing, I
remember that for one particular form once I had to use your
book instead of the official specs (when opSlice and opIndex
are combined)
I still have the thing :
```d
/**
* CharMap is an helper struct that allows to test
* if a char is within a set of characters.
*/
struct CharMap
{
private bool[] _map;
private dchar _min, _max;
private void setMinMax(dchar value) pure nothrow @safe
{
if (value <= _min) _min = value;
else if (value >= _max) _max = value;
_map.length = _max + 1 - _min;
}
/**
* Used in the construction process.
*
* Params:
* lo = The dchar that defines the range lower bound.
* hi = The dchar that defines the range upper bound
(inclusive).
*
* Examples:
* ---
* CharMap cm = CharMap['0'..'9'];
* ---
*/
static CharRange opSlice(int index)(dchar lo, dchar hi) pure
nothrow @safe @nogc
{
return CharRange(lo, hi);
}
/**
* Used in the construction process.
*
* Params:
* a = A list made of character slices, of single
characters or
*
* any other values whose type is implicitly convertible to
dchar.
*
* Examples:
* ---
* CharMap cm = CharMap['0'..'9', '.', 'f', 'd', 38, 39];
* ---
*/
static CharMap opIndex(A...)(A a) pure nothrow @safe
{
CharMap result;
// bounds
foreach(elem; a)
{
alias T = typeof(elem);
static if (isSomeChar!T ||
isImplicitlyConvertible!(T, dchar))
{
result.setMinMax(elem);
}
else static if (is(T == CharRange))
{
result.setMinMax(elem._min);
result.setMinMax(elem._max);
}
else static assert(0, "unsupported opIndex argument
type: " ~ T.stringof);
}
result._map[] = false;
foreach(elem; a)
{
alias T = typeof(elem);
static if (isSomeChar!T ||
isImplicitlyConvertible!(T, dchar))
result._map[elem - result._min] = true;
else static if (is(T == CharRange))
{
foreach(size_t i; elem._min - result._min ..
elem._max - result._min + 1)
result._map[i] = true;
}
}
return result;
}
/**
* Returns true if a character is within the map.
*
* Params:
* c = A character or any value convertible to a dchar.
*/
bool opBinaryRight(string op = "in", C)(C c) const pure
nothrow @safe @nogc
if (op == "in")
{
static if (isSomeChar!C || isImplicitlyConvertible!(C,
dchar))
{
if (_min > c || c > _max) return false;
else return _map[c - _min];
}
else static assert(0, `invalid argument type for
CharMap.opBinaryRight!"in"(): ` ~ C.stringof);
}
}
///
pure @safe unittest
{
CharMap cm = CharMap['a'..'f', '0'..'9' , 'A'..'F', '_', 9];
assert('a' in cm);
assert('b' in cm);
assert('c' in cm);
assert('d' in cm);
assert('e' in cm);
assert('f' in cm);
assert('g' !in cm);
assert('A' in cm);
assert('B' in cm);
assert('C' in cm);
assert('D' in cm);
assert('E' in cm);
assert('F' in cm);
assert('G' !in cm);
assert('0' in cm);
assert('4' in cm);
assert('9' in cm);
assert('_' in cm);
assert('%' !in cm);
assert('\t' in cm);
}
```
Re: What are (were) the most difficult parts of D?
On Thursday, 12 May 2022 at 12:13:32 UTC, Basile B. wrote: On Thursday, 12 May 2022 at 11:50:59 UTC, Alain De Vos wrote: Some keywords are overloaded and have different meaning when used in a different place. Also some syntactic-sugar is way to much meaning too many different ways to do the same thing. I would prefer one way which is advised. `ptr1 is ptr2` VS `is(T==U)` is ok even if the keyword is reused for two different things. Problem is more (from https://dlang.org/spec/expression.html#is_expression) ``` is ( Type : TypeSpecialization , TemplateParameterList ) is ( Type == TypeSpecialization , TemplateParameterList ) is ( Type Identifier : TypeSpecialization , TemplateParameterList ) is ( Type Identifier == TypeSpecialization , TemplateParameterList ) ``` I never remember those variants, because basically you never need them... They were required for std.traits and that's it. Perfect example of reuse that is never a problem : `final`. what statically does `is` should have been several `__traits` I think.
Re: What are (were) the most difficult parts of D?
On Thursday, 12 May 2022 at 11:50:59 UTC, Alain De Vos wrote: Some keywords are overloaded and have different meaning when used in a different place. Also some syntactic-sugar is way to much meaning too many different ways to do the same thing. I would prefer one way which is advised. `ptr1 is ptr2` VS `is(T==U)` is ok even if the keyword is reused for two different things. Problem is more (from https://dlang.org/spec/expression.html#is_expression) ``` is ( Type : TypeSpecialization , TemplateParameterList ) is ( Type == TypeSpecialization , TemplateParameterList ) is ( Type Identifier : TypeSpecialization , TemplateParameterList ) is ( Type Identifier == TypeSpecialization , TemplateParameterList ) ``` I never remember those variants, because basically you never need them... They were required for std.traits and that's it.
Re: What are (were) the most difficult parts of D?
On Wednesday, 11 May 2022 at 05:41:35 UTC, Ali Çehreli wrote: What are you stuck at? What was the most difficult features to understand? etc. To make it more meaningful, what is your experience with other languages? Ali Overhall I think that D was not hard to learn because well designed (i.e intuitive). A few specific points however that I remember - Certain variant forms of the `is` Expression are not obvious (not intuitive), I'm pretty sure I still cant use them without a quick look to the specs. - Operator overloading in certain cases was confusing, I remember that for one particular form once I had to use your book instead of the official specs (when opSlice and opIndex are combined) The main difficulty I had is actually not specific to D. It was to accept that a GC is OK.
Re: Trait for "can be instantiated"?
On Tuesday, 10 May 2022 at 16:10:26 UTC, Ben Jones wrote:
On Tuesday, 10 May 2022 at 16:05:15 UTC, H. S. Teoh wrote:
Using wrapper structs, etc., for this is IMO total overkill.
Just use an enum for your token types. Something like this
would suffice:
That's basically what sumtype is going to do for me, but
(hopefully) more safely. Also, the token types are "user
defined," my lexer just grabs everything annotated with @Token
and passes those types/wrapped enums to sumtype.
How about being more explicit in the UDA ?
The idea would be to associate the enum value to a type or not:
```d
import std.traits;
import std.stdio;
struct Token(T);
struct Token(T...)
if (T.length == 0) { }
@Token!(string) enum str_tok;
@Token!(float) enum float_tok;
@Token!() enum lparen_tok;
void main()
{
alias toks = getSymbolsByUDA!(mixin(__MODULE__), Token);
static foreach (t; toks)
{{
alias U = getUDAs!(t, Token);
alias A = TemplateArgsOf!(U);
static if (A.length)
pragma(msg, "add a `" ~ A[0].stringof ~ "`for `" ~
t.stringof ~ "`");
else
pragma(msg, "no SumType data needed for `" ~
t.stringof ~ "`");
}}
}
```
Re: Make shared static this() encoding table compilable
On Monday, 14 March 2022 at 09:40:00 UTC, zhad3 wrote: Hey everyone, I am in need of some help. I have written this Windows CP949 encoding table https://github.com/zhad3/zencoding/blob/main/windows949/source/zencoding/windows949/table.d which is used to convert CP949 to UTF-16. After some research about how to initialize immutable associative arrays people suggested using `shared static this()`. So far this worked for me, but I recently discovered that DMD cannot compile this in release mode with optimizations. `dub build --build=release` or `dmd` with `-release -O` fails: ``` code windows949 function zencoding.windows949.fromWindows949!(immutable(ubyte)[]).fromWindows949 code table function zencoding.windows949.table._sharedStaticCtor_L29_C1 dmd failed with exit code -11. ``` That's a compiler bug of type "ICE", the compiler crashes. Try reducing to a simple module that does not use phobos and report to bugzilla.
Re: Detecting manifest contants
On Saturday, 12 March 2022 at 18:49:32 UTC, Anonymouse wrote:
I'm introspecting structs, and I ran into an issue where
`__traits(derivedMembers)` includes manifest constant enums in
the returned tuple.
What is the correct way to statically detect these? The
immediate thing that springs to mind is `is(symbol == enum)`,
but it's not it.
Currently I'm testing if a function that takes the address of
the member compiles, and I think it works, but like with
everything `__traits(compiles)` it strikes me as it might not
be the right way to go about things.
```d
struct Foo
{
int i;
enum k = 42;
}
void main()
{
foreach (memberstring; __traits(derivedMembers, Foo))
{
static if (__traits(compiles, { Foo f; auto ptr =
&__traits(getMember, f, memberstring); }))
{
// ...
}
}
}
```
What else can I try?
A way is to try declaring an enum with the value returned by the
`getMember` trait.
```d
/**
* Indicates wether something is a value known at compile time.
*
* Params:
* V = The value to test.
* T = Optional, the expected value type.
*/
template isCompileTimeValue(alias V, T...)
if (T.length == 0 || (T.length == 1 && is(T[0])))
{
enum isKnown = is(typeof((){enum v = V;}));
static if (!T.length)
enum isCompileTimeValue = isKnown;
else
enum isCompileTimeValue = isKnown && is(typeof(V) ==
T[0]);
}
///
unittest
{
string a;
enum b = "0";
enum c = 0;
static assert(!isCompileTimeValue!a);
static assert(isCompileTimeValue!b);
static assert(isCompileTimeValue!c);
static assert(isCompileTimeValue!(b,string));
static assert(isCompileTimeValue!(c,int));
static assert(!isCompileTimeValue!(c,char));
static assert(!isCompileTimeValue!(char));
}
/// ditto
template isCompileTimeValue(V, T...)
if (T.length == 0 || (T.length == 1 && is(T[0])))
{
enum isCompileTimeValue = false;
}
```
Re: https://run.dlang.io/ vs All dmd compilers (2.060 - latest)
On Sunday, 27 February 2022 at 16:14:31 UTC, Matheus wrote: Hi, [...] After one minute I think I get: rdmd playground.d Server error: Thanks, Matheus. This was [reported before]. Apparently this would be caused by a timeout. [reported before]: https://forum.dlang.org/post/skc2dd$1o52$1...@digitalmars.com
Re: Set output location for dub --single
On Sunday, 27 February 2022 at 16:58:34 UTC, Chris Piker wrote: Hi D Coming from a python background it's worked well to organize my D projects as a dub `sourceLibrary` and then to put top level programs in a directory named `scripts` that are just dub single file projects. So the layout looks like this: [...] After reading over the dub documentation I don't see a general way to override project options via the command line, but maybe it's there and I couldn't understand what the dub docs were trying to say. That 's not exactly what you ask for but you can define the path in the embedded recipe (targetPath) ```d #!/usr/bin/env dub /+ dub.sdl: dependency "mypackage" version="*" path=".." targetPath "./bin" +/ ```
Re: Why writeln can't be converted to nothrow with just catching of StdioException
On Monday, 21 February 2022 at 11:12:38 UTC, partypooper wrote: On Monday, 21 February 2022 at 11:07:55 UTC, Basile B. wrote: Yeah there must be another one then. Something actionnable is the documentation. What about Mike Parker answer? if nothrow fails that's because things are checked. We could imagine a second flow analysis leading to better error messages. You see, instead of the generic error message you get now. "If it fails, let's see why"
Re: Why writeln can't be converted to nothrow with just catching of StdioException
On Monday, 21 February 2022 at 11:05:42 UTC, partypooper wrote: On Monday, 21 February 2022 at 10:58:26 UTC, Basile B. wrote: more likely UTFException actually Additionaly catching UTF and Conv exceptions doesn't help. Yeah there must be another one then. Something actionnable is the documentation.
Re: Why writeln can't be converted to nothrow with just catching of StdioException
On Monday, 21 February 2022 at 10:49:13 UTC, partypooper wrote:
Do I completely not understand what is `nothrow` or why I can't
make function nothrow with just catching StdioException?
This doesn't work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (StdioException) {}
}
```
This doest work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (Exception) {}
}
```
https://issues.dlang.org/show_bug.cgi?id=22800
Re: Why writeln can't be converted to nothrow with just catching of StdioException
On Monday, 21 February 2022 at 10:53:56 UTC, Basile B. wrote:
On Monday, 21 February 2022 at 10:49:13 UTC, partypooper wrote:
Do I completely not understand what is `nothrow` or why I
can't make function nothrow with just catching StdioException?
This doesn't work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (StdioException) {}
}
```
This doest work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (Exception) {}
}
```
I believe it's because it can throw ConvException as well ;)
more likely UTFException actually
Re: Why writeln can't be converted to nothrow with just catching of StdioException
On Monday, 21 February 2022 at 10:53:56 UTC, Basile B. wrote:
On Monday, 21 February 2022 at 10:49:13 UTC, partypooper wrote:
Do I completely not understand what is `nothrow` or why I
can't make function nothrow with just catching StdioException?
This doesn't work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (StdioException) {}
}
```
This doest work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (Exception) {}
}
```
I believe it's because it can throw ConvException as well ;)
However you're totally right to open a discussion, the
documentation is innacurate:
in https://dlang.org/phobos/std_stdio.html#.writeln
just StdioException is mentioned ;)
Re: Why writeln can't be converted to nothrow with just catching of StdioException
On Monday, 21 February 2022 at 10:49:13 UTC, partypooper wrote:
Do I completely not understand what is `nothrow` or why I can't
make function nothrow with just catching StdioException?
This doesn't work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (StdioException) {}
}
```
This doest work
```d
nothrow void hello() {
try {
writeln("Hello, World!")
} catch (Exception) {}
}
```
I believe it's because it can throw ConvException as well ;)
Re: keyword as struct field
On Sunday, 20 February 2022 at 11:08:55 UTC, partypooper wrote:
Hello, I'm new to D.
Title is self described, is it possible to use keyword as
struct field?
Maybe it is XYproblem, so here I will describe a little what I
need.
I'm parsing some json currently with
[mir-ion](https://code.dlang.org/packages/mir-ion)
(better/simpler suggestions for only json de/serialization?),
that has "version" as one of it's keys, so I can't use that as
field in my struct. Maybe some annotation in mir library to
parse "version" into other struct field name, can't find though
(its docs pretty concise).
I have a library solution based on opDispatch +
__traits(getMember):
```d
/**
* Mixin template allowing to use a field as if its identifier is
a D keyword.
* Note that this only works with `__traits(getMember)`.
* Params:
* keywordFieldPairs = An array of keyword and field pairs.
*/
template FieldOfKeyword(string[2][] keywordFieldPairs)
{
template opDispatch(string member)
{
static foreach (pair; keywordFieldPairs)
static if (member == pair[0])
mixin("alias opDispatch = ", pair[1], ";" );
}
}
///
unittest
{
struct Foo
{
mixin FieldOfKeyword!([["scope", "scope_"],["class",
"class_"]]);
string scope_;
string class_;
}
Foo foo;
__traits(getMember, foo, "scope") = "The Universe";
assert(__traits(getMember, foo, "scope") == "The Universe");
__traits(getMember, foo, "class") = "Atom";
assert(__traits(getMember, foo, "class") == "Atom");
}
```
never used it TBH.
Re: Beta 2.099.0
On Tuesday, 15 February 2022 at 16:12:25 UTC, Iain Buclaw wrote: On Tuesday, 15 February 2022 at 13:27:18 UTC, Basile B. wrote: On Tuesday, 15 February 2022 at 13:06:47 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.099.0 release, ♥ to the 99 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.099.0.html As usual please report any bugs at https://issues.dlang.org -Martin Issue 3 is wrongly [referenced]. I will not create a bugzilla entry because I think this is not fixable [referenced]: https://dlang.org/changelog/2.099.0.html#bugfix-list Maybe an issue could be raised against the [dlang-bot](https://github.com/dlang/dlang-bot) to request better handling of ambiguous commit messages? Yes but in the meantime I find strange that you have just approved a PR that will have the same effect [with issue 2]. [with issue 2]: https://github.com/dlang/dmd/pull/13663
Re: Beta 2.099.0
On Tuesday, 15 February 2022 at 13:06:47 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.099.0 release, ♥ to the 99 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.099.0.html As usual please report any bugs at https://issues.dlang.org -Martin Issue 3 is wrongly [referenced]. I will not create a bugzilla entry because I think this is not fixable [referenced]: https://dlang.org/changelog/2.099.0.html#bugfix-list
Re: Declaring a reusable formula and using it in other scopes.
On Saturday, 12 February 2022 at 12:36:06 UTC, BoQsc wrote: `bool nextArgumentDoesNotReachEndOfArray = i + 1 < args.length;` How can I declare it out of scope and reuse it in any scope that has `i` and `args.length` declared? Here is an ugly solution, just to encourage someone else to post better: ```d enum n = "i+1The problem of the initial problem is to have automatic capture of `i` and `args` in any scope... Lost cause ?
Re: Is there an equivavlent to C# boxing in D?
On Saturday, 12 February 2022 at 16:50:16 UTC, H. S. Teoh wrote: Without alias this it would be harder to pull off, yes. I don't see any other way that allows to unbox *implictly*. That would require a new operator. Something like opCast but more permissive, that works without `cast`.
Re: ldc executable crashes with this code
On Thursday, 3 February 2022 at 01:51:34 UTC, Basile B. wrote:
On Thursday, 3 February 2022 at 01:39:33 UTC, forkit wrote:
On Wednesday, 2 February 2022 at 23:30:50 UTC, H. S. Teoh
wrote:
[...]
that explains ldc perhaps (although i don't really get it.
It's cast to mutable and being assigned to mutable.
in any case... ldc doesn't like it, but dmd is fine with this
??
your cast from immutable to mutable is an undefined behavior,
this may work or not.
Note that casting away a const qualifier and then mutating is
undefined behavior, too, even when the referenced data is
mutable. This is so that compilers and programmers can make
assumptions based on const alone. For example, here it may be
assumed that f does not alter x:
(from https://dlang.org/spec/const3.html#removing_with_cast)
the D safe way :
```
void main() @safe
{
char[] palindrome = "able was I ere I saw elba".dup;
writeln(palindrome);
writeln(palindrome.reverse);
}
```
Re: ldc executable crashes with this code
On Thursday, 3 February 2022 at 01:39:33 UTC, forkit wrote: On Wednesday, 2 February 2022 at 23:30:50 UTC, H. S. Teoh wrote: [...] that explains ldc perhaps (although i don't really get it. It's cast to mutable and being assigned to mutable. in any case... ldc doesn't like it, but dmd is fine with this ?? your cast from immutable to mutable is an undefined behavior, this may work or not. Note that casting away a const qualifier and then mutating is undefined behavior, too, even when the referenced data is mutable. This is so that compilers and programmers can make assumptions based on const alone. For example, here it may be assumed that f does not alter x: (from https://dlang.org/spec/const3.html#removing_with_cast)
Re: styx, a programming languange written in D, is on the bootstrap path
On Sunday, 16 January 2022 at 18:53:45 UTC, Brian Callahan wrote: I was able to make a quick port to OpenBSD; works fine there too. Thanks for your work on this! ~Brian holly s**t ! I'm a bit surprised that it works, especially because of the way linking is done.
Re: styx, a programming languange written in D, is on the bootstrap path
On Monday, 18 January 2021 at 18:03:12 UTC, IGotD- wrote: On Thursday, 14 January 2021 at 17:51:51 UTC, Basile B. wrote: This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. I'd like to thank the D compiler developers, that let me work on DMD even if I borrow another path. [1] : https://gitlab.com/styx-lang/styx Interesting project. A few questions. I see that you use "var auto name" in order to automatically infer the type. Would it be possible just using "var name" for that, similar to other popular languages. There is currently no information about memory management, is this something you have an idea how to design right now? It has a memory management system very comparable to older Delphi (<= 2007) or current FreePascal. So dynamic arrays are reference counted and automatically managed when used a local var. Classes and structures are manually managed but the dtor is automatically called when the instance is a local. This system is proven to work as the compiler itself is now rewritten in styx. (example, the valgrind report after running the compiler with the equivalent of D "-unittest" CLI option : https://gitlab.com/styx-lang/styx/-/jobs/1980055910#L110. To be honest I already knew it will work before implementing ref counting. This has been used for something like 30 years by hundreds and hundreds of programmers.
Re: styx, a programming languange written in D, is on the bootstrap path
On Friday, 15 January 2021 at 09:54:59 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 January 2021 at 17:51:51 UTC, Basile B. wrote: This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. Interesting project! How did you move from D to Styx? (I assume bootstrapping means a self hosting compiler?) Did you write some scripts to translate? It turns out that finally everything was translated manually. This was a bit painful but also an opportunity to review older parts and to change a details that otherwise would not have been done.
Re: Is DMD still not inlining "inline asm"?
On Friday, 12 November 2021 at 00:46:05 UTC, Elronnd wrote: On Thursday, 11 November 2021 at 13:22:15 UTC, Basile B. wrote: As for now, I know no compiler that can do that. GCC can do it. Somewhat notoriously, you meant "infamously" ? LTO can lead to bugs from underspecified asm constraints following cross-TU inlining. I have missed the LTO train TBH, gotta try that once...
Re: Is DMD still not inlining "inline asm"?
On Thursday, 11 November 2021 at 08:58:43 UTC, rempas wrote: I've seen from [this](https://forum.dlang.org/post/op.vrzngqeavxi10f@biotronic-laptop) reply in a thread from 2011 that DMD will not inline functions that contain inline assembly. Is this still the case? Yes, this is still the case. A particularity of DMD inliner is that it does its job in the front-end, so inlining asm is totally impossible. Then, even if inlining was done in the backend inlining of asm would not be guaranteed because the byte code is generated at a very late stag, which causes problem with the registry allocator, the preservation of the stack, etc. For example ldc2 does not inline a trival asm func https://godbolt.org/z/1W6r693Tq. As for now, I know no compiler that can do that.
Re: Possible runtime bug in preprocessing of command line arguments passed to the D main
On Sunday, 24 October 2021 at 14:38:44 UTC, jfondren wrote: [...] With nothing to the contrary, I'd take "must be terminated by a null pointer" as "can't itself be a null pointer". ah yeah, and thanks, of course ... how would the count of arg be known without the sentinel...
Re: Possible runtime bug in preprocessing of command line arguments passed to the D main
On Sunday, 24 October 2021 at 14:21:52 UTC, Basile B. wrote:
The following code, on linux
[...]
What do you think ?
Forgot to say that this change
```diff
- execv("a", null);
+ execv("a", ["whatever".ptr].ptr);
```
makes the problem goes away, so it would be caused by how `null`
args are handled, presumably.
Possible runtime bug in preprocessing of command line arguments passed to the D main
The following code, on linux
```d
module runnable;
extern(C) int execv(const char* p, const char** args);
immutable src = `
import std.getopt;
void main(string[] args)
{
bool c;
getopt(args, "c", );
}
`;
void prepareProgram()
{
import std.process : execute;
import std.file : write;
write("a.d", src);
execute(["dmd", "a.d"]);
}
void main(string[] args)
{
prepareProgram();
execv("a", null);
}
```
results in a std.getopt exception:
object.Exception@/usr/include/dmd/phobos/std/getopt.d(423):
Invalid arguments string passed: program name missing
Context is a program not written in D that uses execv to call a D
program that uses getopt.
What do you think ?
Re: Gordon programming language
On Sunday, 24 October 2021 at 10:13:14 UTC, Tero Hänninen wrote: Hello, decided I'd post about my primarily D-influenced programming language here. Nice work. It's data oriented, compact and despite D's influence, has a very different personality with no emphasis on metaprogramming – albeit having simple polymorphism and even compile time execution. Stability is something I care about deeply so you can expect few to no deprecations over time after some initial instability perhaps. Feature set is not large and I'm not willing to add a whole lot of "cool" convenience features besides what there already is, and there is no support for either OO or functional style programming. However, I'm rather open to adding features that unlock great performance benefits, such as intrinsics support. Support for LLVM intrinsics should be indeed of a great value added. That could work by adding a new attribute with a string exp to recognize it. without that the oprations that are done in the FPU can only be based on assembly and less inlinable. The module system is similar to Rust and works nicely with conditional compilation in that you can exclude entire modules and directories and, unlike in Rust, use conditional symbols that are automatically visible to all submodules. The compiler frontend is about 34k lines of code, self hosting and very fast. LLVM is the backend, but with the MIR used in the compiler, it's fairly straight forward to bolt on other backends. Congrats for reaching self-hosting. Once thing I notice is that there does not seem to be a way to generate debug info. You really should support them (LLVM C api has a whole header with everything you need to achieve that), because not only this allows to debug the compiler more easily but also can be used to easily instrument code in a generic way. With debug info, you can of course debug but also profile (valgrind --tool=calgrind), find leaks (valgrind), cover (kcov), etc. Compiler source code: https://github.com/tjhann/gordon Website: https://tjhann.github.io/gordon-web/ I don't know how to make websites... and I want a much lighter background actually. Take a look! :)
Re: How to make a function that accepts optional struct but can accept struct literal too
On Friday, 15 October 2021 at 20:33:33 UTC, JN wrote: Is there some nice way of achieving something like this C99 code in D? [...] The [literal](https://www.ibm.com/docs/sr/xl-c-and-cpp-aix/13.1.0?topic=operators-compound-literal-expressions) in the C version creates an alloca too but it's hidden.
Re: dexed-ide v3.9.13
On Monday, 11 October 2021 at 06:58:18 UTC, Basile B. wrote: [...] - [assets](https://gitlab.com/basile.b/dexed/-/releases). Note that the automated Windows build is still broken. Windows assets are now live [here](https://ci.appveyor.com/project/BBasile/dexed/builds/41098624/artifacts).
Re: dexed-ide v3.9.13
On Monday, 11 October 2021 at 09:52:14 UTC, Basile B. wrote: On Monday, 11 October 2021 at 07:42:12 UTC, Imperatorn wrote: On Monday, 11 October 2021 at 06:58:18 UTC, Basile B. wrote: ## Enhancements - messages, search results: exclude backticks if the option _backTicksHighlight_ is enabled. - GDB commander: double click on the call stack to select a frame and refresh the different views. This is especially useful to go back to the frame where a D Exception is thrown. (#52) - completion: partial support for dependencies of type _package:subpackage_. [...] I'm on Windows though, but thanks for maintaining dexed it's easy to build. If a script can do it on appveyor, a human can do it on its windows box. Actually if the appveyor build fails it's because of d-scanner, not dexed. mmmh lmao actually. The build fails because the checkout is done before entering the repo dir: https://gitlab.com/basile.b/dexed/-/blob/master/.appveyor.yml#L52
Re: dexed-ide v3.9.13
On Monday, 11 October 2021 at 07:42:12 UTC, Imperatorn wrote: On Monday, 11 October 2021 at 06:58:18 UTC, Basile B. wrote: ## Enhancements - messages, search results: exclude backticks if the option _backTicksHighlight_ is enabled. - GDB commander: double click on the call stack to select a frame and refresh the different views. This is especially useful to go back to the frame where a D Exception is thrown. (#52) - completion: partial support for dependencies of type _package:subpackage_. [...] I'm on Windows though, but thanks for maintaining dexed it's easy to build. If a script can do it on appveyor, a human can do it on its windows box. Actually if the appveyor build fails it's because of d-scanner, not dexed.
dexed-ide v3.9.13
## Enhancements - messages, search results: exclude backticks if the option _backTicksHighlight_ is enabled. - GDB commander: double click on the call stack to select a frame and refresh the different views. This is especially useful to go back to the frame where a D Exception is thrown. (#52) - completion: partial support for dependencies of type _package:subpackage_. ## Bugs fixed - diff dialog: the content reloaded matched to the state when the dialog was shown, not when closed. (#97) - editor, debugging: during a debugging session, wrong icon displayed when a breakpoint is removed. - DUB project inspector: the tree was empty if the project is moslty organized in subpackages. - DUB projects: version number without the patch component were not accepted. ## links - [homepage](https://gitlab.com/basile.b/dexed) - [assets](https://gitlab.com/basile.b/dexed/-/releases). Note that the automated Windows build is still broken.
Re: Release 2.098.0
On Sunday, 10 October 2021 at 14:10:53 UTC, Martin Nowak wrote: Glad to announce D 2.098.0, ♥ to the 62 contributors. This release comes with template alias assignments, ImportC, a forking parallel GC for POSIX systems, and many more changes. http://dlang.org/download.html http://dlang.org/changelog/2.098.0.html -Martin The most important fix in this version for me is not well exposed in the changelog. With https://github.com/dlang/dmd/pull/12978, finally all inherited fields of a class are displayed, e.g when using `p *instance` in gdb, which painfully missed before (unless you used GDB or LDC of course). Thanks in particular to Rainers for that fix !
Re: Better debugging?
On Sunday, 3 October 2021 at 22:21:45 UTC, Tim wrote:
Hi all,
I am currently using GDB within VScode with the -gc DMD2
compiler switch and my debugging is not amazing. Whenever I
inspect a struct/object it just shows me the pointer rather
than the object information and strings come up as a gross
array of the characters. Does anybody happen to know whether
LDB is better or how I can have a nicer debug environment?
Thanks in advance
1. LDC2 generate better debug infos, especially for classes,
although this might change from the next DMD version (it will
include the inherited fields, just like LDC2).
2. to inspect objects you must evluate the dereference of an
instance.
for example for a project, if i eval `d`, a class instance VS
`*d`, the pointed chunk of memory.
| name| value
| ---| ---
d | 0x77b4b480
s | 0x77b506c0
locParentAggr | 0x0
symParentAggr | 0x0
thisParentAggr | 0x0
needInheritance | false
this | 0x77b506c0
loc | 0x77b43ea0
evaluation of `d` | 0x77b4b480
evaluation of `*d` | { = {
= {}, startPos = {line = 18, column = 1}, ir =
0x0}, name = 0x77b4e5e0, symbol = 0x77b506c0, attributes
= 0x0, asTypeDeclared = 0x77b50720, kind = 34 '\"',
protection = 0 '\\000', progress = 0 '\\000'}
I don't know how the debugger gui you use works, here this is
just a paste of dexed-ide table for locals and custom
expressions. More often I use a debug popup:
[A similar feature seems possible in
vscode](https://github.com/microsoft/vscode-java-debug/issues/444), maybe post a feature request to the extension developpers, as the debug popup is often very handy (no need to type expressions, as they are already there in the code !)
Re: Mutually recursive template expansion
On Saturday, 2 October 2021 at 08:48:24 UTC, Stephen wrote:
Is this by design?
No but it's easily explainable.
## without mixins
```d
struct Ar { Br b; ubyte a; }
struct Br { ubyte b; }
```
`Ar` semantic starts, members are analyzed, that begins with the
variable declaration `Br b`. `Br` type needs to be resolved. `Br`
can be found in the AST as it is declared manually. Now `Br` is
run and finally `Ar` sema continues.
## with mixins
```d
mixin(q{struct Ar { Br b; ubyte a; }});
mixin(q{struct Br { ubyte b; }});
```
The first mixin is compiled (`compileIt()` in dmd code base).
The AST is now the same as obtained by parsing
```d
struct Ar { Br b; ubyte a; }
mixin(q{struct Br { ubyte b; }});
```
`Ar` semantic starts, members are analyzed, that begins with the
variable declaration`Br b`. But `Br` cannot be resolved because
**it is not yet in the AST** and the symbol tables.
Re: 0 cost template instantiation
On Thursday, 30 September 2021 at 02:02:19 UTC, Hipreme wrote:
On Thursday, 30 September 2021 at 01:56:42 UTC, Basile B. wrote:
On Thursday, 30 September 2021 at 01:09:47 UTC, Hipreme wrote:
I have a template function that all it does is given a
symbol, it loads a dll for its type + its name:
```
void loadSymbol(alias s, string symName = "")()
{
static if(symName == "")
s = cast(typeof(s))_loadSymbol(_dll, (s.stringof~"\0").ptr);
else
s = cast(typeof(s))_loadSymbol(_dll, (symName~"\0").ptr);
}
```
The main problem is that this function is costing 2KB per
instantiation, which is something pretty high. Specially if I
inline, there is almost no cost when compared to its inline
version. Trying to use pragma(inline, true) didn't do
anything too.
cant you just use a regular functions ? loading happens at
runtime right ?
The entire reason to having that function is having that syntax
which would pretty much do the monkey's job for me:
Instead of writing
myFunction = cast(typeof(myFunction))_loadSymbol(_dll,
"myFunction");
I could write
loadSymbol!myFunction;
But if no other way is found of doing that, I will do the
massive rewriting.
Anyway, I don't think the problem is not in the way I'm doing,
but the output, as that template could easily be inlined
well ok. Maybe try to see if overloads
void loadSymbol(alias s)()
void loadSymbol(alias s, string symName)()
helps. That save the static if. In addition there's the null
sentinel that can save a bit of memory, as you've been suggested.
Re: 0 cost template instantiation
On Thursday, 30 September 2021 at 01:09:47 UTC, Hipreme wrote:
I have a template function that all it does is given a symbol,
it loads a dll for its type + its name:
```
void loadSymbol(alias s, string symName = "")()
{
static if(symName == "")
s = cast(typeof(s))_loadSymbol(_dll, (s.stringof~"\0").ptr);
else
s = cast(typeof(s))_loadSymbol(_dll, (symName~"\0").ptr);
}
```
The main problem is that this function is costing 2KB per
instantiation, which is something pretty high. Specially if I
inline, there is almost no cost when compared to its inline
version. Trying to use pragma(inline, true) didn't do anything
too.
cant you just use a regular functions ? loading happens at
runtime right ?
Dexe-ide 3.9.12
# v3.9.12 - editor: a new option, _textCompletion_, sets if the completion menu includes the identifiers obtained by word-splitting the whole document. (#85) - editor: prevent completion menu to show on fast enough (< to the _autoDotDelay_ setting) `..`. - Halstead metrics: show full function signatures. - projects: added the _Check semantics_ to the menu. (#83) - DUB projects: added support for the _syntax_ build type. (#83) - GDB commander: arguments of the _Debugee Options_ can be temporarily deactivated by prepending `//`. - GDB commander: add an option allowing to set the path to the gdb binary. (#73) - GDB commander: the context menu of the ASM view allows to resume execution until the selected instruction. (#71) - Search results: use GNU style messages. (#84) ## Regressions fixed - editor, _closeCompletionCharsWithSpace_ broken by [git b65bb860](https://gitlab.com/basile.b/dexed/-/commit/b65bb860e45c47e3c48bf513aeafd9968daa2482). ## Bugs fixed - D2 highlighter: for `Call()`, `Call` wont be considered anymore as a type. (#69) - GDB commander: 5 empty arguments were passed to the main function called by libc. (#86) - Symlist: errors were not visible enough since moved to the top. (#92) ## Other - can be build with Lazarus 2.2 but backward compatible 2.0.z. - provided binaries are build with Lazarus 2.0.12 due to 2.2 not being released. --- To get a release [see here](https://gitlab.com/basile.b/dexed/-/releases). Note that the appveyor build has failed this time so no offical windows binaries.
Re: Bugzilla Reward System
On Thursday, 16 September 2021 at 11:56:21 UTC, Mike Parker wrote: In my summary of last month's D Language Foundation meeting, I mentioned that we discussed a system intended to reward contributors who contribute pull requests that fix Bugzilla issues. This was Razvan Nitu's baby from conception to implementation, and we all think it is a great idea. The system has been running in the background for a few weeks now, quietly gathering data and awarding points, proving that the programming side works as intended. Our first round of point scoring kicks off on September 20th. Razvan has put together a blog post explaining how the system works. We'll revise and adapt the system as needed as time goes by. In the meantime, happy bug fixing! The blog: https://dlang.org/blog/2021/09/16/bugzilla-reward-system/ Reddit: https://www.reddit.com/r/d_language/comments/ppbp7d/bugzilla_reward_system/ This is a good move, I hope it will work so that D will keep contributors that are not already gone and gain new talented ones. Another answer mentions that the lack of "issue triage" might cause problems. I think to the opposite that this system could encourage 1. better triage 2. better reviews But well, we'll see if this works next year. Let's not be negative ;)
Re: Which operators cannot be overloaded and why not?
On Monday, 13 September 2021 at 14:42:42 UTC, jfondren wrote:
On Monday, 13 September 2021 at 14:33:03 UTC, user1234 wrote:
- condition al expression ` cond ? exp : exp `
And many other boolean operators, unary !, binary && and ||
https://dlang.org/spec/operatoroverloading.html lists all the
overloadable operators, and
https://dlang.org/spec/expression.html has all the operators,
so "which operators" is a matter of close comparison. "why not"
is much harder to answer.
Oh! I have never noticed that `&&` and `||`, despite of being
quite "ordinary" binary ops are not overloadable.
In
[styx](https://styx-lang.gitlab.io/styx/attribute.html#operatorattribute) that works because, although inspired by the D way, in the sense that overloads are implemented in custom types, the selection is done using an expression template
```d
struct S {
@operator(a && b) function andAnd(T other): auto {return
false}
}
```
So as long as the expression in the attribute argument looks like
a valid expression the stuff is found (and the supprot code in
the compiler is super simple), e.g with code in a body:
```d
e1 && e2; // look if e1 is an aggregate and if it contains
@operator(a && b)
e1 + e2; // look if e1 is an aggregate and if it contains
@operator(a && b)
```
While D uses specific identifier + templates value param for
strings.
(note that only the equivalent of D opBinary**Right** works...)
anyway. zorry for this off-topic.
Re: GDC - program runs in one thread, DMD - in 4 threads, why?
On Friday, 10 September 2021 at 09:27:49 UTC, eugene wrote: Here is test program (which is using DList aggressively) [...] Can this (really unwanted) behavior be disabled in DMD? I do not want to have multiple threads, a program (real program, not the test above) has to be single-threaded. system used: @dexp ~ $ cat /etc/debian_version 8.11 most recent dmd has a GC that collect in threads. it can be tuned but I dont find the documentation for this right now.
Re: Absence of isAllocator trait
On Saturday, 4 September 2021 at 19:43:27 UTC, Per Nordlöw wrote: Is there a reason for the absence of an `isAllocator` trait under `std.experimental.allocator`? I had ask a similar Q once and I've been told that (more or less): It's because the clients of an allocator should rather statically check for specific traits of an allocator, there are too many possible permutations of capabilities possible, not all can allocate and deallocate, not all can reallocate, and so on. actually I'm 100% sure that what you want is `isMallocator` and not `isAllocator` ;)
