Re: DUB doesn't seem to respect my config, am I doing something wrong?
On Saturday, 22 May 2021 at 20:28:56 UTC, rempas wrote: I'm compiling using `dub --config=development` and I'm getting the following line: `Performing "debug" build using /usr/bin/dmd for x86_64`. The same exactly happens when I'm trying to do the release config. If I disable the `targetType` option, it seems that it's creating a library and I can also manually change the compiler and the build-type so I don't know what's going on I just looked in the dub documentation for "build" and "compiler" entries, which I had never heard of, and I see none now. As Jordan said, those have always been configured on the command line. Did you perhaps see something about those somewhere else? FYI, the first configuration you define is always the default, so you don't need to specify it on the command line unless you really want to.
Re: DUB doesn't seem to respect my config, am I doing something wrong?
On Saturday, 22 May 2021 at 20:28:56 UTC, rempas wrote:
I've read the documentation about DUB's config (I'm using the
SDL format) and it seems that DUB completely ignores my config.
My config file is:
```
name "test"
description "Testing dub"
authors "rempas"
copyright "Copyright © 2021, rempas"
license "AGPL-3.0"
compiler "ldc2"
configuration "development" {
platforms "linux"
build "dubug"
compiler "ldc2"
targetType "executable"
}
configuration "release" {
platforms "linux"
dflags "-Oz" platform="/bin/ldc2"
build "release"
compiler "ldc2"
targetType "executable"
}
```
I'm compiling using `dub --config=development` and I'm getting
the following line: `Performing "debug" build using
/usr/bin/dmd for x86_64`. The same exactly happens when I'm
trying to do the release config. If I disable the `targetType`
option, it seems that it's creating a library and I can also
manually change the compiler and the build-type so I don't know
what's going on
Ignoring the "dubug" typo...normally, I think you pass compiler
values directly to dub via the ```--compiler``` flag. For example:
```shell
dub --config=development --compiler=ldc2
```
Note: you can also pass "debug" and "release" builds (among
others), like so:
```shell
dub -b "debug" --compiler=ldc2
```
Passing in the compiler allows any end user building your code to
use whatever compiler they want. Otherwise, something like
```toolchainRequirements dmd="no" ldc=">=1.21.0"``` may achieve
what you want.
Thanks,
Jordan
Re: Compiler version "dirty"
On Monday, 8 March 2021 at 22:29:58 UTC, Q. Schroll wrote: When I enter `dmd --version`, it says: DMD64 D Compiler v2.095.1-dirty What should the "dirty" mean? To me, it seems looks something went wrong somewhere. This comes from `git describe --dirty` and indicates there were uncommitted changes in the repo when the release was built. This would raise red flags if seen in a commercial setting and looks a bit unprofessional but it is most likely harmless. Probably one of the build scripts or unittests are polluting the repo.
DUB doesn't seem to respect my config, am I doing something wrong?
I've read the documentation about DUB's config (I'm using the SDL
format) and it seems that DUB completely ignores my config. My
config file is:
```
name "test"
description "Testing dub"
authors "rempas"
copyright "Copyright © 2021, rempas"
license "AGPL-3.0"
compiler "ldc2"
configuration "development" {
platforms "linux"
build "dubug"
compiler "ldc2"
targetType "executable"
}
configuration "release" {
platforms "linux"
dflags "-Oz" platform="/bin/ldc2"
build "release"
compiler "ldc2"
targetType "executable"
}
```
I'm compiling using `dub --config=development` and I'm getting
the following line: `Performing "debug" build using /usr/bin/dmd
for x86_64`. The same exactly happens when I'm trying to do the
release config. If I disable the `targetType` option, it seems
that it's creating a library and I can also manually change the
compiler and the build-type so I don't know what's going on
Re: ugly and/or useless features in the language.
On Saturday, 22 May 2021 at 17:32:34 UTC, sighoya wrote: But I think providing an external ast tree mapped onto the changing internal one used by DMD would be a feasible approach. It is feasible, but if you want to do it well you should think in terms of rewrite engines with patternmatching, think XSLT or Pure (not exactly, but in that direction). I think it is better to design such a language from scratch.
Re: ugly and/or useless features in the language.
On Saturday, 22 May 2021 at 13:31:45 UTC, Ola Fosheim Grøstad wrote: The D AST is not really suitable as it stands. D is a bit like C++ in this regard, there might be a minimal core language that could be distilled from it, but it would take a D3 full breaking change to get there, so it won't happen. Well, I think D without templates is already a lightweight core language. The real cost comes with the template language. But I think providing an external ast tree mapped onto the changing internal one used by DMD would be a feasible approach.
Re: ugly and/or useless features in the language.
On Saturday, 22 May 2021 at 13:26:38 UTC, sighoya wrote: But the more general problem in D are not features per se, but how they are composed of. For instance: Why no AST macros instead of string mixins, templates, mixin templates and alias? All these forms could be special ast macros. I think AST macros require a tiny core language and having most of the language features being implemented by macros. The D AST is not really suitable as it stands. D is a bit like C++ in this regard, there might be a minimal core language that could be distilled from it, but it would take a D3 full breaking change to get there, so it won't happen. Structs are nice but at the same time awful to use because they are incompatible with interfaces and classes, I hope this will change to some extent, but I think it wouldn't be that smooth. You could probably expose classes in a form that is compatible with structs, but that would expose implementation details and give implementors less freedom.
Re: ugly and/or useless features in the language.
On Saturday, 15 May 2021 at 14:31:08 UTC, Alain De Vos wrote: Which parts in dlang don't you use and why ? Well, I don't like magic constructs in the language like the type of AliasSeq you can't touch. But the more general problem in D are not features per se, but how they are composed of. For instance: Why no AST macros instead of string mixins, templates, mixin templates and alias? All these forms could be special ast macros. Structs are nice but at the same time awful to use because they are incompatible with interfaces and classes, I hope this will change to some extent, but I think it wouldn't be that smooth. Being multi-paradigmatic seems nice at a first sight, but which paradigm should your standard library and other frameworks follow? Providing all paradigms at once make your frameworks redundant and bloated, so you just follow one which is most of the time not OOP. This is the same problematic with custom memory containers. I wish we would only use structs as ref/value types with the ability to box them to interfaces automatically increasing compatibility between libraries to a large extent.
Re: stack out of scope ?
On Sunday, 16 May 2021 at 18:27:40 UTC, H. S. Teoh wrote:
On Sun, May 16, 2021 at 05:24:40PM +, Alain De Vos via
Digitalmars-d-learn wrote:
On Sunday, 16 May 2021 at 16:58:15 UTC, H. S. Teoh wrote:
> On Sun, May 16, 2021 at 04:40:53PM +, Alain De Vos via
> Digitalmars-d-learn wrote:
> > This works also,
> >
> > ```
> > import std.stdio:writeln;
> >
> > int [] fun(){
> > int[3]s=[1,2,3];
> > int[] r=s;
> > return r;
> > }
> >
> > void main(){
> > writeln(fun()[0]);
> > }
> > ```
>
> https://issues.dlang.org/show_bug.cgi?id=15932
>
> Though I believe if you compile with -dip25 -dip1000 the
> compiler should emit an error for the above code. If not,
> please file a bug against -dip1000.
[...]
I use ldc2. No dip flags here.
-snip-
import std.stdio:writeln;
int [] fun() @safe {// N.B.: need @safe
int[3]s=[1,2,3];
int[] r=s;
return r;
}
void main() @safe { // N.B.: need @safe
writeln(fun()[0]);
}
-snip-
LDC output:
-snip-
$ ldc2 -dip1000 /tmp/test.d
/tmp/test.d(6): Error: scope variable `r` may not be returned
-snip-
T
Trying @safe is painfull in practice.
Large parge of functions are not @safe and call functions which
are not @safe.
Only tiny end-subroutines i can put @safe.
