[Issue 18650] DMD shouldn't include all unittests with -deps

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18650

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--

[Issue 18629] std.algorithm.iteration.subsitute is slow

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18629

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--

[Issue 18598] cyclic constructor calls have undefined behavior but are accepted in @safe code

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18598

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--

[Issue 18661] auto ref and return attribute inference

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18661

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--

[Issue 18657] std.range and std.algorithm can't handle refRange

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18657

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--

[Issue 18645] DMD segmentation fault

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18645

greenify  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greeen...@gmail.com
 Resolution|--- |FIXED

--

[Issue 18661] auto ref and return attribute inference

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18661

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17512

--

[Issue 17512] [REG 2.073] [DIP1000] Error on bad interplay of 'auto ref' and 'return' attribute deduction.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17512

Walter Bright  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18661
 Resolution|--- |FIXED

--- Comment #8 from Walter Bright  ---
(In reply to John Colvin from comment #7)
> This seems to not to be totally resolved in very similar cases:

Please do not reopen bugs because more issues come up. File a new issue
instead. Otherwise, bugzilla loses the 1:1 correlation between PRs and issues,
and becomes much less manageable.

I refiled it as https://issues.dlang.org/show_bug.cgi?id=18661

Closing this again.

--

[Issue 18661] New: auto ref and return attribute inference

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18661

  Issue ID: 18661
   Summary: auto ref and return attribute inference
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

John Colvin reports:

struct S0(T)
{
int a;
auto ref immutable(int) getA() { return a; }
}

alias A = S0!int;

test.d(4): Error: function type pure nothrow @nogc return @safe
immutable(int)() has return but does not return any indirections

--

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17449

--- Comment #13 from Walter Bright  ---
> Checking the disassembly for compiling with -dip1000 it doesn't generate the 
> closure that it is generating without the switch.

When I check it, it does generate the closure. Perhaps this is due to other
related PRs that exist on my machine but haven't been pulled yet.

--

[Issue 18652] hashOf example doesn't compile

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18652

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/druntime/pull/2152

--

[Issue 18645] DMD segmentation fault

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18645

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #5 from Walter Bright  ---
Fixed by https://github.com/dlang/dmd/pull/8072

--

[Issue 18606] [REG2.072] "cannot append type const(T) to type T[]" in .dup

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18606

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 18489] [REG 2.073]Internal error: dmd/backend/cgcod.c 1688

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18489

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/65eed9c366c3a07f72152603cdb5f047e6d8948c
Fix issue 18489 - SROA w/ vector arguments

Since we can't easily slice the contents of a XMM register avoid slicing
symbols passed in such registers.

https://github.com/dlang/dmd/commit/a142adda22e2f7194f1fd85cbffc6e48624ef06f
Merge pull request #8057 from LemonBoy/b18489

Fix issue 18489 - SROA w/ vector arguments

--

[Issue 18489] [REG 2.073]Internal error: dmd/backend/cgcod.c 1688

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18489

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18489] [REG 2.073]Internal error: dmd/backend/cgcod.c 1688

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18489

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8057

--

[Issue 16189] Optimizer bug, with simple test case

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16189

--- Comment #8 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/27dd8373a06cafa7e6038bf853cf15ab9575518d
fix Issue 16189 - Optimizer bug, with simple test case

https://github.com/dlang/dmd/commit/88a963a8ce44d062d45c34677a697ff2bd1fe2fa
Merge pull request #8074 from WalterBright/fix16189

fix Issue 16189 - Optimizer bug, with simple test case

--

[Issue 16189] Optimizer bug, with simple test case

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16189

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

DIP: The Deprecation Process

[Mike Parker via Digitalmars-d-announce]

This is another candidate to become DIP 1013. It standardizes the 
deprecation process for DMD, DRuntime and Phobos. It is currently 
in Draft Review and has had some discussion already, but I'd like 
to get a few more eyes on it before moving forward.


Please familiarize yourself with the intent of the Draft Review 
stage [1] and keep all feeback in the PR thread [2].


Thanks!

[1] 
https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#draft-review

[2] https://github.com/dlang/DIPs/pull/108

Re: Optional type - how to correctly reset a wrapped immutable T

[Simen Kjærås via Digitalmars-d-learn]

On Sunday, 25 March 2018 at 21:26:57 UTC, aliak wrote:

struct Optional(T) {
  Unqual!T value;
  opAssign(T t) {
value = cast(Unqual!T)(t);
  }
}


Consider this case:

Optional!(immutable int) a = some(3);
immutable int* p = 
a = some(5);

Clearly the above code shouldn't compile - you can't overwrite 
the value, as it would break immutability. If you want to support 
both immutability and reassignment, you will need to use 
redirection - either an array as you did, or a pointer.


As for the problems you've had with inout, I wrote this template 
a few years back:


template SubstituteInout(FromType, ToType) {
static if (is(ToType == inout(SubType), SubType)) {
alias SubstituteInout = CopyTypeQualifiers!(FromType, 
SubType);

} else static if (is(ToType == SubType*, SubType)) {
alias SubstituteInout = SubstituteInout!(FromType, 
SubType)*;

} else static if (is(ToType == SubType[], SubType)) {
alias SubstituteInout = SubstituteInout!(FromType, 
SubType)[];
} else static if (is(ToType == SubType[n], SubType, size_t 
n)) {
alias SubstituteInout = SubstituteInout!(FromType, 
SubType)[n];
} else static if (is(ToType == SubType[KeyType], SubType, 
KeyType)) {
alias SubstituteInout = SubstituteInout!(FromType, 
SubType)[SubstituteInout!(FromType, KeyType)];

} else {
alias SubstituteInout = ToType;
}
}

unittest {
static assert(is(SubstituteInout!(const(string), int) == 
int));
static assert(is(SubstituteInout!(const(string), 
inout(int)[]) == const(int)[]));
static assert(is(SubstituteInout!(const(string), inout(int)) 
== const(int)));
static assert(is(SubstituteInout!(const(string), 
inout(int)*[][3][int]) == const(int)*[][3][int]));
static assert(is(SubstituteInout!(const(string), 
inout(int)[inout(string)]) == const(int)[const(string)]));

}

I really should get around to making a PR for it...

--
  Simen

[Issue 18657] std.range and std.algorithm can't handle refRange

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18657

--- Comment #1 from ag0aep6g  ---
PR to fix the first three examples without touching RefRange:
https://github.com/dlang/phobos/pull/6346

--

Re: Must ranges support `r1 = r2;`?

[ag0aep6g via Digitalmars-d]

On 03/25/2018 01:49 AM, Jonathan M Davis wrote:

assignment really isn't part of the range API. I don't think that any of the
range traits even test that assignment works on any level. So, it could be
argued that generic, range-based functions simply shouldn't ever be
assigning one range to another.

So we have to remove all range assignments from generic code. Ugh.

The first three: https://github.com/dlang/phobos/pull/6346

Re: Aggressive conditional inlining with ldc only, not dmd

[kinke via Digitalmars-d-learn]

On Sunday, 25 March 2018 at 22:09:43 UTC, Nordlöw wrote:
And I haven't found a way to conditionally qualify these inner 
loop functions with `pragma(inline, true)` for the ldc case 
only.


From https://dlang.org/spec/pragma.html#inline: 'If inside a 
function, it affects the function it is enclosed by.'


So:

void foo()
{
version(LDC) pragma(inline, true); // affects foo()
...
}

Vulkan ErupteD breaking changes and transition strategy

[Peter Particle via Digitalmars-d-announce]

ErupteD [0] is deprecated (one of its major modules). The project 
content is supposed to be replaced completely. Current state was 
copied into ErupteD-V1 [1] (without deprecation message), neither 
ErupteD nor ErupteD-V1 will be further developed.
The breaking changes and Vulkan 1.1 are implemented in ErupteD-V2 
[2]. At some future point ErupteD will be destroyed and recreated 
with all releases of ErupteD-V2 [3].


Two issues bugged me with the previous design of the binding:
1. versions are not only disconnected from, but also far beyond 
Vulkan
2. too many dub dependencies - if on windows, than platform 
foreign ones


1. this is the reason for the involved transition, ErupteD needs 
to get rid of all releases / version tags to restart with a clean 
slate.
I also extracted the python generator script into its own non-dub 
project, V-Erupt [5]. It was kind of wired to mix two different 
purposes into one project version scheme.


2. the new approach does not require dependencies at all (other 
than phobos / druntime). Platform dependent extensions are 
implemented in form of a parameterizable mixin template. User is 
supposed to mix them into his project and take care of the 
dependencies himself [4]. Platform windows is pre-instantiated, 
as it relies only on druntime. With this approach dub cache stays 
clean from foreign platform dependencies and silences version 
mismatch noise.
While at it, I also removed the DerelictUtil dependency and added 
simple entrypoint loading mechanics. ErupteD-V2 is now fully 
nothrow @nogc and should be -betterC compatible (not tested yet). 
Moreover, no requirement for dub configurations any more.


[0] : https://github.com/ParticlePeter/ErupteD
[1] : https://github.com/ParticlePeter/ErupteD-V1
[2] : https://github.com/ParticlePeter/ErupteD-V2
[3] : 
https://github.com/ParticlePeter/ErupteD-V2#erupted-deprecation-and-upgrade-process
[4] : 
https://github.com/ParticlePeter/ErupteD-V2#platform-extensions

[5] : https://github.com/ParticlePeter/V-Erupt

Re: Binding rvalues to ref parameters

[Andrei Alexandrescu via Digitalmars-d]

On 03/25/2018 03:24 PM, Rubn wrote:

On Sunday, 25 March 2018 at 14:28:30 UTC, Andrei Alexandrescu wrote:

On 3/25/18 9:40 AM, Rubn wrote:

On Saturday, 24 March 2018 at 12:51:07 UTC, Andrei Alexandrescu wrote:
Filing a DIP is like filing a police report: once it's in the 
system, we're obligated to work on it. There's a guarantee of a 
response.


https://wiki.dlang.org/DIP36


The DIP system has changed extensively since Mike Parker took it over. 
This "old format" DIP would need to be submitted to 
https://github.com/dlang/DIPs.


That's not the issue... That DIP was already labelled as rejected. 
Wasn't able to find an explanation anywhere as to why either. No point 
changing the format for a DIP that was already rejected.


The entire procedure and approach has been rebooted. All old DIPs should 
be moved to the new system if there is one or more champions for them. 
Thanks! -- Andrei

Re: LDC 1.8.0

[aberba via Digitalmars-d-announce]

On Saturday, 24 March 2018 at 17:33:18 UTC, Matthias Klumpp wrote:
On Tuesday, 13 March 2018 at 01:52:48 UTC, Matthias Klumpp 
wrote:

[...]
Aww, just a little bit too late to easily get into Ubuntu 
18.04 LTS


Well It still made it, yay! (Even without me explicitly 
requesting it)
This means Ubuntu 18.04 will be pretty up-to-date when it comes 
to D stuff, only GDC 8 won't be the default (but still 
available).
The thing that is facilitating an up-to-date D stack in Debian 
and Ubuntu is software in the archive using D. The Tilix 
terminal emulator is at the forefront there, followed by my 
appstream-generator and the Laniakea archive management suite 
and all the bits and pieces those projects depend on (like GtkD 
in Tilix' case).


Thanks to all.

Aggressive conditional inlining with ldc only, not dmd

[Nordlöw via Digitalmars-d-learn]

Is there a way to make ldc do more aggressive inlining other than

pragma(inline, true)

?

Reason for asking is that

https://github.com/nordlow/phobos-next/blob/master/src/open_hashmap_or_hashset.d

achieves much better performance when I qualify some inner loop 
functions with


pragma(inline, true)

instead of

pragma(inline)

eventhough I compile with -release -inline -nobounds flags.

Unfortunately these functions cannot be inlined by dmd in release 
mode so my code either runs slower than possible or it cannot be 
built by dmd in release mode.


And I haven't found a way to conditionally qualify these inner 
loop functions with `pragma(inline, true)` for the ldc case only.

Re: dddb lightweight and simple key-value database

[aerto via Digitalmars-d-announce]

On Friday, 23 March 2018 at 05:19:16 UTC, Fra Mecca wrote:

On Thursday, 22 March 2018 at 15:34:28 UTC, aerto wrote:
I just start yesterday with d, I write dddb a lightweight and 
simple key-value database for dlang build on top of std.json 
source and usage  https://github.com/cvsae/dddb I'm waiting 
your comments


Hi, well done!
Your code is very concise, you could expand your database by 
adding tests and unit tests, that are a very important part of 
programming projects and widely supported in D.


To get an example of possible test you can check this: 
https://github.com/damphat/kv-bash


You can read about unittests in the D-Gems section 
https://tour.dlang.org/tour/en/gems/unittesting and the D wiki 
https://wiki.dlang.org/Unittest and also an article by Funkwerk 
https://dlang.org/blog/2017/10/20/unit-testing-in-action/


Also, it could be important to take care of error management in 
your program. What happens if the database stores an invalid 
json? What happens if I retrieve a key that is not in the 
database?
You can read more about error handling and exceptions and scope 
guards here: https://tour.dlang.org/tour/en/basics/exceptions


These are points that I hope can give you suggestion on how to 
further improve your code and abilities and hopefully continue 
learning D.


Thank you very much, i did some updates

[Issue 18197] [REG2.073] Internal error: backend\cgcod.c 1659

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18197

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #2 from bitter.ta...@gmx.com ---
DMD PR https://github.com/dlang/dmd/pull/8082

--

Re: Help with specific template function

[aliak via Digitalmars-d-learn]

On Sunday, 25 March 2018 at 19:06:14 UTC, Vladimirs Nordholm 
wrote:
On Sunday, 25 March 2018 at 18:24:37 UTC, Vladimirs Nordholm 
wrote:

The underlying problems are:
* How do I ensure the two first arguments (used as 
coordinates) are types of numbers (all kinds: ints, floats, 
reals, etc.)

* At least one argument is passed after the coordinates


I found a solution which satisfies my needs :)

void foo(X, Y, Args...)(X x, Y y, Args args)
if (__traits(isArithmetic, x) && __traits(isArithmetic, y) 
&& args.length >= 1)

{
// ...
}


FYI there's also 
https://dlang.org/library/std/traits/is_numeric.html incase you 
haven't see it -takes in to account bools and chars, which 
depending on your usecase you may not want to count as arithmetic.


Cheers
- Ali

Optional type - how to correctly reset a wrapped immutable T

[aliak via Digitalmars-d-learn]

Hi, I have this optional type I'm working on and I've run in to a 
little snag when it comes to wrapping an immutable. Basically 
what I want is for an Optional!(immutable T) to still be settable 
to "some" value or "no" value because the Optional wrapper itself 
is mutable.


Optional!(immutable int) a = some(3);
a = none;

I used to do this via a dynamic array and opAssign would recreate 
the array


struct Optional(T) {
  T[] bag;
  opAssign(T t) {
bag = [t]
  }
}

But then there were problems with inout, namely:

Error: variable `Optional!(inout(A)).Optional.bag` only 
parameters or stack based variables can be inout


So I changed it to a stack variable (prefer this anyway, it's not 
only because of the inout error) but now I'm unsure if I'm 
violating the type system. Basically I'm now storing T as 
Unqual!T, but what I'm looking for is a Rebindable implementation 
that's for value types as well. Is this possible?


Now I do this:

struct Optional(T) {
  Unqual!T value;
  opAssign(T t) {
value = cast(Unqual!T)(t);
  }
}

I put up a PR if anyone wants to see the code. Any pointers, tips 
would be highly appreciated:


https://github.com/aliak00/optional/pull/13/files#diff-cb543fea6a0b5eeb07b6aac9f068e262

Cheers
- Ali

Re: The first example in the Learning D book, wont compile

[Ali via Digitalmars-d-learn]

On Sunday, 25 March 2018 at 20:52:29 UTC, Ali wrote:

On Sunday, 25 March 2018 at 20:45:58 UTC, Ali wrote:
I now see my typo, should be retro, not range


We need better IDEs, this would have been easily highlighted by a 
good ide

Re: The first example in the Learning D book, wont compile

[Seb via Digitalmars-d-learn]

On Sunday, 25 March 2018 at 20:45:58 UTC, Ali wrote:

Hi

The first example in the Learning D book

import core.thread;
import std.stdio;

void main() {
import std.range: iota, range;
write("Greeting in, ");
foreach(num; iota(1, 4).range) {
writef("%s...", num);
stdout.flush();
Thread.sleep(1.seconds);
}
writeln();
writeln("Hello, World");
}


wont compile and give this error

hello.d(5): Error: module `std.range` import range not found

this should be an easy issue to fix, except that googling this 
error doesnt return anything useful


The problem is `std.range : range` - range is not a symbol of 
std.range:


---
import core.thread;
import std.stdio;

void main() {
import std.range: iota;
write("Greeting in, ");
foreach(num; iota(1, 4)) {
writef("%s...", num);
stdout.flush();
Thread.sleep(1.seconds);
}
writeln();
writeln("Hello, World");
}
---

https://run.dlang.io/is/p9rFrS

Re: Binding rvalues to ref parameters

[Dgame via Digitalmars-d]

On Sunday, 25 March 2018 at 19:24:00 UTC, Rubn wrote:
On Sunday, 25 March 2018 at 14:28:30 UTC, Andrei Alexandrescu 
wrote:

On 3/25/18 9:40 AM, Rubn wrote:
On Saturday, 24 March 2018 at 12:51:07 UTC, Andrei 
Alexandrescu wrote:
Filing a DIP is like filing a police report: once it's in 
the system, we're obligated to work on it. There's a 
guarantee of a response.


https://wiki.dlang.org/DIP36


The DIP system has changed extensively since Mike Parker took 
it over. This "old format" DIP would need to be submitted to 
https://github.com/dlang/DIPs.


That's not the issue... That DIP was already labelled as 
rejected. Wasn't able to find an explanation anywhere as to why 
either. No point changing the format for a DIP that was already 
rejected.


There is one: 
https://forum.dlang.org/thread/ylebrhjnrrcajnvtt...@forum.dlang.org?page=9

Re: The first example in the Learning D book, wont compile

[Ali via Digitalmars-d-learn]

On Sunday, 25 March 2018 at 20:45:58 UTC, Ali wrote:

Hi

The first example in the Learning D book

import core.thread;
import std.stdio;

void main() {
import std.range: iota, range;
write("Greeting in, ");
foreach(num; iota(1, 4).range) {
writef("%s...", num);
stdout.flush();
Thread.sleep(1.seconds);
}
writeln();
writeln("Hello, World");
}


wont compile and give this error

hello.d(5): Error: module `std.range` import range not found

this should be an easy issue to fix, except that googling this 
error doesnt return anything useful



I now see my typo, should be retro, not range

The first example in the Learning D book, wont compile

[Ali via Digitalmars-d-learn]

Hi

The first example in the Learning D book

import core.thread;
import std.stdio;

void main() {
import std.range: iota, range;
write("Greeting in, ");
foreach(num; iota(1, 4).range) {
writef("%s...", num);
stdout.flush();
Thread.sleep(1.seconds);
}
writeln();
writeln("Hello, World");
}


wont compile and give this error

hello.d(5): Error: module `std.range` import range not found

this should be an easy issue to fix, except that googling this 
error doesnt return anything useful

Re: Homebuilt dmd fails to link my dub application

[Seb via Digitalmars-d-learn]

On Sunday, 25 March 2018 at 20:26:22 UTC, Nordlöw wrote:

On Sunday, 25 March 2018 at 18:43:09 UTC, Seb wrote:

Are you on a 32-bit system?
(For 64-bit -fPIC is the default since 2.072.2 - though DMD's 
build scripts were only updated a few releases later)


No, I have my own build script for dmd, though because I can't 
get Digger to work either.


What error do you get with Digger?
Note that you the version on Dub just has been updated today:

https://github.com/dlang-bots/dlang-bot/pull/194#issuecomment-375993106

For building everything locally, it should be as easy as:

---
git clone https://github.com/dlang/dmd
git clone https://github.com/dlang/druntime
git clone https://github.com/dlang/phobos
cd phobos && make -f posix.mak -j10
---

(dmd + druntime are built automatically from Phobos)

I advise against rolling your own built script and reporting your 
issues either here, Slack or IRC.
If we can reproduce your issue, chances are that someone else 
will run into them too ;-)


BTW there's also this setup script:

https://github.com/dlang/tools/blob/master/setup.sh

Re: Homebuilt dmd fails to link my dub application

[Nordlöw via Digitalmars-d-learn]

On Sunday, 25 March 2018 at 18:43:09 UTC, Seb wrote:

Are you on a 32-bit system?
(For 64-bit -fPIC is the default since 2.072.2 - though DMD's 
build scripts were only updated a few releases later)


No, I have my own build script for dmd, though because I can't 
get Digger to work either.

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16107

--- Comment #13 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/6c42ce082744e721bba802e5dae96dc0ed6c598f
fix Issue 16107 - [ICE] - Internal error: backend/cgcod.c 2297

https://github.com/dlang/dmd/commit/7d79100827427ce6fecc33a533999c7d93f857b6
Merge pull request #8078 from WalterBright/fix16107

fix Issue 16107 - [ICE] - Internal error: backend/cgcod.c 2297

--

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16107

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

[Walter Bright via Digitalmars-d]

On 3/25/2018 6:23 AM, Rubn wrote:

On Sunday, 25 March 2018 at 09:27:31 UTC, Walter Bright wrote:

On 3/23/2018 10:55 PM, Chris Katko wrote:
Last question though, is there any kind of list of features, and minor 
features and fixes that can or need to be done? Perhaps it already exists,

And here it is:

https://issues.dlang.org/


Virtually all of those issues have no comment on them.


Hence there's plenty of "need to be done" contributions to make!

People often make very valuable contributions to issues in the comments by:

1. producing a reduced test case (the smaller the test case, the easier it is to 
track down)

2. finding the cause of the bug
3. finding the pull request that introduced the bug
4. connecting to related work
5. any other information helpful in resolving it

Re: Binding rvalues to ref parameters

[Rubn via Digitalmars-d]

On Sunday, 25 March 2018 at 14:28:30 UTC, Andrei Alexandrescu 
wrote:

On 3/25/18 9:40 AM, Rubn wrote:
On Saturday, 24 March 2018 at 12:51:07 UTC, Andrei 
Alexandrescu wrote:
Filing a DIP is like filing a police report: once it's in the 
system, we're obligated to work on it. There's a guarantee of 
a response.


https://wiki.dlang.org/DIP36


The DIP system has changed extensively since Mike Parker took 
it over. This "old format" DIP would need to be submitted to 
https://github.com/dlang/DIPs.


That's not the issue... That DIP was already labelled as 
rejected. Wasn't able to find an explanation anywhere as to why 
either. No point changing the format for a DIP that was already 
rejected.

Re: Help with specific template function

[Vladimirs Nordholm via Digitalmars-d-learn]

On Sunday, 25 March 2018 at 18:24:37 UTC, Vladimirs Nordholm 
wrote:

The underlying problems are:
* How do I ensure the two first arguments (used as coordinates) 
are types of numbers (all kinds: ints, floats, reals, etc.)

* At least one argument is passed after the coordinates


I found a solution which satisfies my needs :)

void foo(X, Y, Args...)(X x, Y y, Args args)
if (__traits(isArithmetic, x) && __traits(isArithmetic, y) && 
args.length >= 1)

{
// ...
}

Re: dmd download sig file, how do I use it

[Seb via Digitalmars-d-learn]

On Sunday, 25 March 2018 at 14:13:41 UTC, Ali wrote:
(Note: the individual keys in the keyring are currently 
expired and we are working on rolling out a new keyring, but 
that doesn't affect yverifying the existing signatures.)


while you are at it, also add a sha1 or a sh256 checksum, i 
think it will work better to verify the download


Sha1 or sha256 can't be verified automatically, because it 
requires you to download the checksum from the same source.
They can be used if you have checked the authenticity in another 
way, but if dlang.org is compromised the attacker would also 
change the checksums, but he can't change your local, verified 
keyring.


For this reason, it's common for Linux distro to sign their 
packages:


https://wiki.archlinux.org/index.php/Pacman/Package_signing
https://wiki.debian.org/SecureApt

Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side

[H. S. Teoh via Digitalmars-d-announce]

On Sun, Mar 25, 2018 at 04:22:32PM +, pineapple via Digitalmars-d-announce 
wrote:
> I really like `unittest`. It's my personal conviction that a developer
> should not be able to view the documentation, tests, or implementation
> for some part of a code base in isolation. `unittest` makes it easier
> for me to work this way.
> 
> Automated tests are vital for stability and documentation is vital for
> maintainability and making it possible for others to understand your
> code.  But when they aren't right there in the same place as the
> implementation, I've noticed that it is the inevitable habit of
> developers to think of tests and documentation as second-class, if
> they are thought of at all. The developer updates the implementation
> and doesn't think to update the tests or the docs. This happens a few
> times. Then instead of updating the tests to work with the updated
> implementation, the tests are discarded as an inconvenience. And then
> end users become confused by docs that have since become inapplicable.

Exactly. This is why inline unittests are one of the best design
decisions ever made in D.  Along with built-in documentation (in spite
of all ddoc's warts).

Before D, almost none of my code was ever thoroughly tested -- I just
couldn't be bothered to install, setup, write, and then keep in-sync a
separate unittesting system. Ditto for a documentation system.  I tried
DOxygen for one project, but it did not even get past writing a
Doxyfile. :-(  Fortunately, now I'm in the process of migrating that
project from C++ to D, and now I have 90%+ test coverage, integrated
into the build system so that it will fail loudly should any test fail.
A large part of the tests are inline unittests -- otherwise they would
just be too cumbersome to maintain and I would've given up long ago.
(The external testsuite is there only out of necessity, due to the
original C++ design; if I had the started from a blank slate, I would've
hands-down preferred inline unittests.)

D's unittests and inline docs (in spite of said warts) have
significantly (and measurably) improved the quality of my code. And the
fundamental reason is exactly as you said: proximity to the actual code
make a huge difference.  External docs does have the tendency of quickly
falling out-of-date, and external tests tend to get ignored and
eventually thrown out -- I've seen this with my own eyes in large
projects with large numbers of developers, where the code simply changes
way too fast for any external docs/tests to be kept up-to-date without
lots of external motivation (like an angry manager holding threats over
your head, :-P or an irate QA department complaining about regressions).


T

-- 
Philosophy: how to make a career out of daydreaming.

Re: Homebuilt dmd fails to link my dub application

[Seb via Digitalmars-d-learn]

On Sunday, 25 March 2018 at 12:05:32 UTC, Nordlöw wrote:

If my homebuilt dmd fails to build my dub project with message

/usr/bin/ld: error: 
.dub/build/application-unittest-linux.posix-x86_64-dmd_2079-C9019ECA621321CC168B385F53D82831/knetquery.o: requires dynamic R_X86_64_32 reloc against '_D6object9Throwable7__ClassZ' which may overflow at runtime; recompile with -fPIC


what have I done wrong?

Where should I add the -fPIC switch?


Are you on a 32-bit system?
(For 64-bit -fPIC is the default since 2.072.2 - though DMD's 
build scripts were only updated a few releases later)

Help with specific template function

[Vladimirs Nordholm via Digitalmars-d-learn]

Hello Dlang community!

I need help in creating a template function which would look like 
the following pseudo-code:


void foo(, , , 
...);

// would be used as `void foo(x, y, arg1, arg2, ..., argN)`

// valid examples:
foo(5.332, 1, "a string", 123, "42");
foo(3, 44, false);

// invalid examples:
foo(1, 1);
foo(3, "stringers", "arg");

The underlying problems are:
* How do I ensure the two first arguments (used as coordinates) 
are types of numbers (all kinds: ints, floats, reals, etc.)

* At least one argument is passed after the coordinates

Best regards,
Vladimris Nordholm

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

[Seb via Digitalmars-d]

On Sunday, 25 March 2018 at 13:23:04 UTC, Rubn wrote:

On Sunday, 25 March 2018 at 09:27:31 UTC, Walter Bright wrote:

On 3/23/2018 10:55 PM, Chris Katko wrote:
Last question though, is there any kind of list of features, 
and minor features and fixes that can or need to be done? 
Perhaps it already exists,

And here it is:

https://issues.dlang.org/


Not a very comprehensive list. Virtually all of those issues 
have no comment on them. If it's a feature request you might as 
assume it requires a DIP cause there's no reason to otherwise 
waste your time implementing the feature.


Well, first off - most of these issues are bug reports and would 
obviously be pulled if fixed.
Also, bigger improvements to Phobos don't require a DIP - just 
Andrei's approval.
There have been many discussions on this (a recent one: 
https://forum.dlang.org/post/mailman.1298.1521583794.3374.digitalmar...@puremagic.com), but in short it's going to stay like this, but you can easily shoot Andrei a mail _before_ doing something bigger at Phobos.


Now regarding language features, the DIP process has been 
revamped:


https://forum.dlang.org/post/p95hjs$1nf$1...@digitalmars.com

Oddly enough there's almost no other way to get anyone's 
attention of whether a feature requires a DIP or not unless 
there's a pull request for the feature. So if you want a 
feature you almost have to risk wasting your time implementing 
it.


Improvements to the language will require a DIP. Sometimes (like 
e.g. for a new trait) it's possible to get direct approval by 
Walter/Andrei on GitHub, but the rule of thumb is that it needs a 
DIP.


In doubt, you can discuss a new feature on Slack, IRC or this NG 
here.


It's not a very good system, but someone throws up some stats 
about how many issues get solved/pull requests get created per 
month and they conclude that it's working fine.


You aren't alone:

https://github.com/wilzbach/state-of-d-2018/blob/master/09c:%20What%2C%20if%20anything%2C%20do%20you%20dislike%20about%20D's%20issue%20process%3F

https://github.com/wilzbach/state-of-d-2018/blob/master/09d:%20What%2C%20if%20anything%2C%20has%20prevented%20you%20from%20opening%20an%20issue%3F

There are many improvements hopefully coming up to 
issues.dlang.org in the near future:


https://forum.dlang.org/post/tneyowfjewrlrtnqs...@forum.dlang.org

If you have more specific ideas on what could be done to improve 
issues.dlang.org, share them on #dlang_org in Slack, here or in 
Bugzilla.


Note:
- Switch to GH issues is a common request and while I also fought 
for that one (I even tested an automatic migration to GH), there 
are quite some downsides with GH issue tracker and at the moment 
the consensus is to give Mozilla's fork of Bugzilla a fair try
- "there are almost no comments" on issues isn't actionable, but 
a system/idea to improve this would be.

[Issue 18660] getSymbolsByUDA stops after encountering a function

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18660

--- Comment #6 from Seb  ---
> it's resolved in stable.

https://github.com/dlang/phobos/pull/6342

Also note that DMD nightlies are currently broken and haven't been built since
the end of February (in case you tried this with run.dlang.io)
In any case I hope that 2.079.1 will be released soon.

--

Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side

[pineapple via Digitalmars-d-announce]

I really like `unittest`. It's my personal conviction that a 
developer should not be able to view the documentation, tests, or 
implementation for some part of a code base in isolation. 
`unittest` makes it easier for me to work this way.


Automated tests are vital for stability and documentation is 
vital for maintainability and making it possible for others to 
understand your code. But when they aren't right there in the 
same place as the implementation, I've noticed that it is the 
inevitable habit of developers to think of tests and 
documentation as second-class, if they are thought of at all. The 
developer updates the implementation and doesn't think to update 
the tests or the docs. This happens a few times. Then instead of 
updating the tests to work with the updated implementation, the 
tests are discarded as an inconvenience. And then end users 
become confused by docs that have since become inapplicable.

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

[Andrei Alexandrescu via Digitalmars-d]

On 3/25/18 10:48 AM, Abdulhaq wrote:

On Sunday, 25 March 2018 at 14:46:23 UTC, Abdulhaq wrote:

On Saturday, 24 March 2018 at 21:24:28 UTC, Andrei Alexandrescu wrote:


That'd be great. I'm thinking something like an option 
std.getopt.config.commandLineOrder. Must be first option specified 
right after arguments. Sounds good?


I thought this was a clever joke, but everyone is taking it seriously ?!

"When running mygreatprog.exe, always run with --command-line-order 
CommandLine as the first command line option, otherwise 
mygreatprog.exe may misinterpret the command line"


Oops sorry to reply to myself, I realise my mistake now :-)


To purge thy mistake: implement :o).

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

[Abdulhaq via Digitalmars-d]

On Sunday, 25 March 2018 at 14:46:23 UTC, Abdulhaq wrote:
On Saturday, 24 March 2018 at 21:24:28 UTC, Andrei Alexandrescu 
wrote:


That'd be great. I'm thinking something like an option 
std.getopt.config.commandLineOrder. Must be first option 
specified right after arguments. Sounds good?


I thought this was a clever joke, but everyone is taking it 
seriously ?!


"When running mygreatprog.exe, always run with 
--command-line-order CommandLine as the first command line 
option, otherwise mygreatprog.exe may misinterpret the command 
line"


Oops sorry to reply to myself, I realise my mistake now :-)

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

[Abdulhaq via Digitalmars-d]

On Saturday, 24 March 2018 at 21:24:28 UTC, Andrei Alexandrescu 
wrote:


That'd be great. I'm thinking something like an option 
std.getopt.config.commandLineOrder. Must be first option 
specified right after arguments. Sounds good?


I thought this was a clever joke, but everyone is taking it 
seriously ?!


"When running mygreatprog.exe, always run with 
--command-line-order CommandLine as the first command line 
option, otherwise mygreatprog.exe may misinterpret the command 
line"

Re: The final form of the keyboard = ShionKeys

[Abdulhaq via Digitalmars-d-announce]

On Sunday, 25 March 2018 at 05:39:33 UTC, shion wrote:

See, this is one of the idiots who suppress ShionKeys.


I was just having a little joke, don't take it too seriously.

Your story is reading like a tragedy:

https://mastodon.social/@ShionKeys

You need to take a holiday and visit your friends.

Re: libdvbv5_d

[Russel Winder via Digitalmars-d]

On Sun, 2018-03-25 at 06:29 +, Joakim via Digitalmars-d wrote:
> 
[…]
> I'm curious why you're interested in DVB at all. Online video and 
> various OTT streaming services are killing off these protocols in 
> most of the world. Why do you want to access them with D?

Online and streaming requires large bandwidth and no metering.

Freeview is going strong.

I have many DVB-T2 USB devices.

I need to watch television on my laptop during Autumn Internationals and Six
Nations, why pay for streaming when you can get stuff free.  ITV requires
Flash to watch television via the Internet at least BBC jut used HTML5.

Linux DVB API is used in most televisions. Often using GStreamer. It is not
dead. They are switching from C to Rust it seems.

C sucks for anything like this, anyone using C for this is suffering Stockholm
Syndrome.

Rust works well for this stuff, except MPEG-TS, I will have to write the Rust
binding, but it's not that bad due to GIR. 

D has bindings for all this including MPEG-TS.

This is all a straight comparison between D which is great, but sucks, versus
Rust which is irritating in places but generally works very well. I just want
D to be better than it is for this stuff.

I am retired, I need something to keep me amused on the road to being an ex-
person.
  
-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

[Andrei Alexandrescu via Digitalmars-d]

On 3/25/18 10:22 AM, Johannes Pfau wrote:

I don't really understand why you want to this keep lexical order
functionality.


I don't want. I think others will, once their programs depending on the 
current semantics will have trouble.

Re: Binding rvalues to ref parameters

[Andrei Alexandrescu via Digitalmars-d]

On 3/25/18 9:40 AM, Rubn wrote:

On Saturday, 24 March 2018 at 12:51:07 UTC, Andrei Alexandrescu wrote:
Filing a DIP is like filing a police report: once it's in the system, 
we're obligated to work on it. There's a guarantee of a response.


https://wiki.dlang.org/DIP36


The DIP system has changed extensively since Mike Parker took it over. 
This "old format" DIP would need to be submitted to 
https://github.com/dlang/DIPs.

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

[Johannes Pfau via Digitalmars-d]

Am Sat, 24 Mar 2018 17:24:28 -0400 schrieb Andrei Alexandrescu:

> On 3/24/18 12:59 PM, H. S. Teoh wrote:
>> On Sat, Mar 24, 2018 at 12:11:18PM -0400, Andrei Alexandrescu via
>> Digitalmars-d wrote:
>> [...]
>>> Anyhow. Right now the order of processing is the same as the lexical
>>> order in which flags are passed to getopt. There may be use cases for
>>> which that's the more desirable way to go about things, so if you
>>> author a PR to change the order you'd need to build an argument on why
>>> command-line order is better. FWIW the traditional POSIX doctrine
>>> makes behavior of flags independent of their order, which would imply
>>> the current choice is more natural.
>> 
>> So what about making this configurable?
> 
> That'd be great. I'm thinking something like an option
> std.getopt.config.commandLineOrder. Must be first option specified right
> after arguments. Sounds good?

I don't really understand why you want to this keep lexical order 
functionality. There's a well defined use case for command line order: 
Allowing users to write commands in a natural, left-to-right style, where 
options on the right are more specific: systemctl status -l ...

I've never heard of any use case where the lexical order of the arguments 
passed to getopt matters for parsing user supplied command arguments. Is 
there any use case for this?

I thought the only reason we have this lexical order parsing is because 
it's simpler to implement. But if we'll get the non-quadratic command-line 
order implementation there's no reason to keep and maintain the quadratic 
implementation.

-- 
Johannes

Re: code.dlang.org having problems?

[Russel Winder via Digitalmars-d]

On Sat, 2018-03-24 at 13:31 -0700, H. S. Teoh via Digitalmars-d wrote:
> 
[…]
> Well, if you don't have dependencies installed locally (via dub or
> otherwise), then obviously it's impossible to build anything. :-D
> That's hardly a dub problem, right?

There is supposed to be a set of servers so the probability of all failing is
vanishing small,thus the probability of not being able to build is vanishingly
small. Except in my case where I seem to have found a server set state or Dub
state such that the probability of t building was 1.

:-(
 
-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

[Issue 18598] cyclic constructor calls have undefined behavior but are accepted in @safe code

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18598

--- Comment #4 from ag0aep6g  ---
(In reply to Walter Bright from comment #3)
> I'm open to advice on what to do about it.

I'm by no means an expert here, but don't we have a guaranteed guard page
beyond the stack? If we have, stack overflow is guaranteed to fail with a
segfault, as long as the access doesn't jump over guard page (cf. issue 17566).

The situation is very similar to null dereferences then. A null dereference
also hits a guard page, as long as the offset from null isn't too large (cf.
issue 5176).

In both cases, the compiler has to detect offsets that are so large that they
would jump over the guard page, and then it has to inject code that makes an
earlier access to trigger the segfault. If I got the term right, for the stack
that's called "stack probing".

--

Re: dmd download sig file, how do I use it

[Ali via Digitalmars-d-learn]

On Sunday, 25 March 2018 at 04:01:28 UTC, Seb wrote:
gpg --verify --keyring ~/dlang/d-keyring.gpg 
--no-default-keyring dmd.2.079.0.linux.tar.xz.sig 
dmd.2.079.0.linux.tar.xz


Thanks, I guess this kinda works
I am now getting

 gpg: Signature made Fri 02 Mar 2018 01:47:57 PM EST
 gpg:using RSA key B273811612BB1939
 gpg: Good signature from "Martin Nowak 
" [expired]
 gpg: aka "Martin Nowak (dawg) " 
[expired]

 gpg: aka "Martin Nowak " [expired]
 gpg: Note: This key has expired!
 Primary key fingerprint: AFC7 DB45 693D 62BB 472B  F27B AB8F 
E924 C2F7 E724
  Subkey fingerprint: A734 4DAD 3C34 1EA1 2D13  C4E6 B273 
8116 12BB 1939


The command is a bit tricky, originally i kept trying the command 
with only the keyring file name, which didnt work, it needed the 
path


(Note: the individual keys in the keyring are currently expired 
and we are working on rolling out a new keyring, but that 
doesn't affect yverifying the existing signatures.)


while you are at it, also add a sha1 or a sh256 checksum, i think 
it will work better to verify the download

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

[H. S. Teoh via Digitalmars-d]

On Sat, Mar 24, 2018 at 10:05:36PM -0700, H. S. Teoh via Digitalmars-d wrote:
[...]
> OK, the part about defensiveness may be just my overreaction. I
> apologize.  But yeah, I glanced at the code, and don't see any easy
> way to implement what Andrei agreed with. It's just too much work for
> something I could just write for myself in a much shorter time. I
> guess I'll just log an enhancement request in bugzilla and leave it at
> that.
[...]

Turns out, there's already been an issue for this, filed 2 years ago:

https://issues.dlang.org/show_bug.cgi?id=16539


T

-- 
People say I'm arrogant, and I'm proud of it.

[Issue 16539] std.getopt should invoke callbacks in the order given on the command line

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16539

--- Comment #3 from hst...@quickfur.ath.cx ---
Andrei has proposed adding std.getopt.config.commandLineOrder, which must be
the first argument in the list, to switch to this behaviour.

Cf. https://forum.dlang.org/post/p96fmv$20m7$1...@digitalmars.com

--

[Issue 16539] std.getopt should invoke callbacks in the order given on the command line

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16539

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

Re: Binding rvalues to ref parameters

[Rubn via Digitalmars-d]

On Saturday, 24 March 2018 at 12:51:07 UTC, Andrei Alexandrescu 
wrote:
Filing a DIP is like filing a police report: once it's in the 
system, we're obligated to work on it. There's a guarantee of a 
response.


https://wiki.dlang.org/DIP36

Guess there's no point in writing another one then is there? Or 
how many "police reports" do you need to file before the "police" 
change their decision?


I repeat: there is a GUARANTEED mechanism to get us to work on 
binding rvalues to ref parameters. GUARANTEED. This is so 
powerful, it's disconcerting. You need to get a DIP written in 
all detail, get it through community review, and then we have 
no choice but to look into it.


https://wiki.dlang.org/DIP66

"Approved conditionally"

https://github.com/dlang/dmd/pull/3998

*crosses fingers* it's been 4 years but maybe this is the year 
this actually happens.


Anyways there's a whole list of DIPs that didn't get any 
attention, they were just dumped. I know a new DIP processes was 
created but not even a quick pass through of the DIPS with some 
comments of whether it would be worth migrating the DIP to the 
new process or not. I mean there's one DIP that was accepted but 
the PR implementing it has been sitting in the queue for 4 years.

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

[Rubn via Digitalmars-d]

On Sunday, 25 March 2018 at 09:27:31 UTC, Walter Bright wrote:

On 3/23/2018 10:55 PM, Chris Katko wrote:
Last question though, is there any kind of list of features, 
and minor features and fixes that can or need to be done? 
Perhaps it already exists,

And here it is:

https://issues.dlang.org/


Not a very comprehensive list. Virtually all of those issues have 
no comment on them. If it's a feature request you might as assume 
it requires a DIP cause there's no reason to otherwise waste your 
time implementing the feature. Oddly enough there's almost no 
other way to get anyone's attention of whether a feature requires 
a DIP or not unless there's a pull request for the feature. So if 
you want a feature you almost have to risk wasting your time 
implementing it. It's not a very good system, but someone throws 
up some stats about how many issues get solved/pull requests get 
created per month and they conclude that it's working fine.

Re: converting a number into bit array

[Alex via Digitalmars-d-learn]

On Sunday, 25 March 2018 at 11:32:56 UTC, Alex wrote:
how to convert a number to a BitArray as fast as possible, 
given that the BitArray is already allocated to the needed 
length?
Is bit checking the way to go, or is there a way to cast one to 
the other somehow?


Via bit checking I would end with this:

´´´
void assign(BitArray ba, size_t val) //@nogc
{
import std.algorithm : each;

assert(ba.length == size_t.sizeof * CHAR_BIT);

val.bitsSet.each!(b => ba.flip(b));
}
´´´

[Issue 18660] getSymbolsByUDA stops after encountering a function

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18660

Basile B.  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Basile B.  ---
it's resolved in stable.

*** This issue has been marked as a duplicate of issue 18624 ***

--

[Issue 18624] getSymbolsByUDA produces wrong result if one of the symbols having the UDA is a function

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18624

--- Comment #5 from Basile B.  ---
*** Issue 18660 has been marked as a duplicate of this issue. ***

--

[Issue 18660] getSymbolsByUDA stops after encountering a function

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18660

--- Comment #4 from Basile B.  ---
as a proof, log for
https://github.com/dlang/phobos/pull/6341#partial-pull-merging:

https://auto-tester.puremagic.com/show-run.ghtml?projectid=1=3091204=true

--

[Issue 18660] getSymbolsByUDA stops after encountering a function

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18660

Basile B.  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |---

--- Comment #3 from Basile B.  ---
i had tested with DMD ~master. So it's no yet fixed.

--

Re: inline asm return values

[Dave Jones via Digitalmars-d-learn]

On Sunday, 25 March 2018 at 12:23:03 UTC, kinke wrote:

On Sunday, 25 March 2018 at 10:58:37 UTC, Dave Jones wrote:

Is this stuff documented somewhere?


See 
https://dlang.org/spec/abi.html#function_calling_conventions. 
It defines the D calling convention for Win32 (int return value 
in EAX) and states that it matches the C calling convention on 
all other platforms [but note that the args are actually 
reversed].



Is the inline asm portable between compilers?


LDC supports the DMD-style inline asm too, GDC doesn't.


Thanks!

Re: inline asm return values

[kinke via Digitalmars-d-learn]

On Sunday, 25 March 2018 at 10:58:37 UTC, Dave Jones wrote:

Is this stuff documented somewhere?


See https://dlang.org/spec/abi.html#function_calling_conventions. 
It defines the D calling convention for Win32 (int return value 
in EAX) and states that it matches the C calling convention on 
all other platforms [but note that the args are actually 
reversed].



Is the inline asm portable between compilers?


LDC supports the DMD-style inline asm too, GDC doesn't.

Re: Homebuilt dmd fails to link my dub application

[rikki cattermole via Digitalmars-d-learn]

On 26/03/2018 1:05 AM, Nordlöw wrote:

If my homebuilt dmd fails to build my dub project with message

/usr/bin/ld: error: 
.dub/build/application-unittest-linux.posix-x86_64-dmd_2079-C9019ECA621321CC168B385F53D82831/knetquery.o: 
requires dynamic R_X86_64_32 reloc against 
'_D6object9Throwable7__ClassZ' which may overflow at runtime; recompile 
with -fPIC


what have I done wrong?

Where should I add the -fPIC switch?


-fPIC needs to go into dmd's configuration file.

Homebuilt dmd fails to link my dub application

[Nordlöw via Digitalmars-d-learn]

If my homebuilt dmd fails to build my dub project with message

/usr/bin/ld: error: 
.dub/build/application-unittest-linux.posix-x86_64-dmd_2079-C9019ECA621321CC168B385F53D82831/knetquery.o: requires dynamic R_X86_64_32 reloc against '_D6object9Throwable7__ClassZ' which may overflow at runtime; recompile with -fPIC


what have I done wrong?

Where should I add the -fPIC switch?

[Issue 18624] getSymbolsByUDA produces wrong result if one of the symbols having the UDA is a function

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18624

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||b2.t...@gmx.com

--- Comment #4 from Simen Kjaeraas  ---
*** Issue 18660 has been marked as a duplicate of this issue. ***

--

[Issue 18660] getSymbolsByUDA stops after encountering a function

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18660

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||simen.kja...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #2 from Simen Kjaeraas  ---


*** This issue has been marked as a duplicate of issue 18624 ***

--

converting a number into bit array

[Alex via Digitalmars-d-learn]

Given this,

´´´
import std.bitmanip;
import core.stdc.limits;

void main()
{
BitArray ba;
	ba.length = size_t.sizeof * CHAR_BIT; // enough length, known at 
compile time

size_t arbitrary; // = random size_t, not known at compile time

// ba ???assign??? arbitrary;
assert(cast(size_t[])ba == [arbitrary]);
}
´´´

how to convert a number to a BitArray as fast as possible, given 
that the BitArray is already allocated to the needed length?
Is bit checking the way to go, or is there a way to cast one to 
the other somehow?

inline asm return values

[Dave Jones via Digitalmars-d-learn]

Given this...

int mulDiv64(int a, int b, int c)
{
asm
{
movEAX,a;
imul   b;
idiv   c;
}
}

which computes a*b/c, with the intermediate value in 64 bit. It 
returns value that is left in EAX.


Is this stuff documented somewhere? I mean I found the page on 
inline asm but it's pretty sparse. I'm porting code from C++ and 
tested it so it works, but it'd be nice to be able to look up the 
rules on how to do return values with asm without having to dump 
it to the stack and then return that.


Is the inline asm portable between compilers?

[Issue 18660] getSymbolsByUDA stops after encountering a function

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18660

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com
   Severity|normal  |regression

--- Comment #1 from Seb  ---
That's a regression. It used to work until 2.079:

https://run.dlang.io/is/wqC9ZT (the all compiler features hasn't been updated
to 2.079 yet)

--

[Issue 18660] New: getSymbolsByUDA stops after encountering a function

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18660

  Issue ID: 18660
   Summary: getSymbolsByUDA stops after encountering a function
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

test case:

```
unittest
{
import std.traits;
struct UDA {}

static struct Foo
{
static @UDA bool b;
void brickWall(){}
static @UDA bool c;
}

static assert(getSymbolsByUDA!(Foo, UDA).stringof == "tuple(b, c)");
}
```

comment the `brickWall` declaration then the assertion is okay.

--

[Issue 18461] codegen bug - OPbt expressions and assignments to ambiguous symbols

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18461

--- Comment #12 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/85251fa4bc1907f5ecee1106f2cca9cb1f023d11
fix Issue 18461 - codegen bug - OPbt expressions and assignments to ambiguous
symbols

https://github.com/dlang/dmd/commit/74226cfab38a6e32f78a877af4a2a89687aac348
Merge pull request #8065 from WalterBright/fix18461

fix Issue 18461 - codegen bug - OPbt expressions and assignments to a…
merged-on-behalf-of: Iain Buclaw 

--

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

[Walter Bright via Digitalmars-d]

On 3/23/2018 10:55 PM, Chris Katko wrote:
Last question though, is there any kind of list of features, and minor features 
and fixes that can or need to be done? Perhaps it already exists,

And here it is:

https://issues.dlang.org/

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16107

--- Comment #12 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8078

--

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16107

Walter Bright  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 25 March 2018 at 06:58:50 UTC, Seb wrote:
I think that there are at least a couple alternatives to 
std.getopt on code.dlang.org if you want alternatives.


Yes, two good ones are:

https://blog.thecybershadow.net/2014/08/05/ae-utils-funopt


funopt is based on getopt underneath, so this issue still applies 
to it, sorry!


Well, funopt translates options to function arguments, so there's 
no way to specify a delegate anyway, but at least the performance 
aspect applies.

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

[Seb via Digitalmars-d]

On Sunday, 25 March 2018 at 04:30:31 UTC, Jonathan M Davis wrote:
On Saturday, March 24, 2018 09:59:44 H. S. Teoh via 
Digitalmars-d wrote:
And given the defensiveness surrounding std.getopt, my 
conclusion can only be: dump std.getopt, roll my own.  It's 
sad, since in general Phobos design tends to be superior to


Yeah I have "dumb XYZ, roll my own" experience often too.
As there are already many big libraries like `arsd` or `ae` out 
there, I don't think I'm the only one with these feeling.
I wonder if someone ever tries to fork/reboot Phobos with all the 
goodies, but without the legacy cruft like auto-decoding and 
similar friends whose breaking changes can't be made.


its C++ counterparts.  But we then have warts like std.getopt 
that people refuse to acknowledge is a problem.  So be it.


I think that there are at least a couple alternatives to 
std.getopt on code.dlang.org if you want alternatives.


Yes, two good ones are:

https://blog.thecybershadow.net/2014/08/05/ae-utils-funopt
http://code.dlang.org/packages/darg


Personally, the only complaints I've had with std.getopt is


Hehe I like many things about std.getopt, but it's not perfect 
either.

A few examples:

- I often just want to map CLI arguments to a config object where 
using UDAs would more natural and less boilerplate


struct Config {
   @option("c|compiler")
   string compiler;
}

Now with the rejected/postponeed __traits(documentation) the ddoc 
help text could be automatically read and put into the 
auto-generated CLI help.


- I don't like to manually check for .helpWanted

Imho I constantly find myself doing this:

if (helpInformation.helpWanted)
{
`DDoc wrapper
All unknown options are passed to the compiler.
./ddoc ...
`.defaultGetoptPrinter(helpInformation.options);
return 1;
}

I would have preferred this being the default behavior or at 
least the default behavior if a help text string is explicitly 
provided e.g. like:


getopt(`My program
./program ...`, args, ...);

or maybe with sth. like `.withHelp("")`

- setting shared configs doesn't work

I know, I could use a TLS config or use an atomicOp or 
synchronized assignment to set it, but often casting is easier 
and that's rather ugly:


https://github.com/dlang/dlang.org/blob/master/dspec_tester.d#L101

- in theory getopt should be @safe and use ref

It just does a bit of string manipulation, but it looks like we 
have to wait until DIP1000 for this:


https://github.com/dlang/phobos/pull/6281

Also similarly to std.stdio.read or std.format.formattedRead 
there's no need to use pointers, D's @safe ref would have worked 
too. Now, it looks like this change can't be made anymore as it 
would be a breaking one due to ambiguities.


- it would be really cool to support generating zsh/bash 
completions files


This is the last point on my list as it's not really a limitation 
of std.getopt and GetoptResult should be enough for this, but it 
looks like no one bothered enough to write a zshGetoptPrinter so 
far.


getopt can probably be improved to work with Nullable so that 
it'll be easier to figure out whether an argument has been set.


Yes, supporting Nullable would really cool!

[Issue 17942] Enums are evaluated differently in global scope

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17942

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8077

--

Re: libdvbv5_d

[Joakim via Digitalmars-d]

On Saturday, 24 March 2018 at 14:25:19 UTC, Russel Winder wrote:
I suspect no-one other than me is interested in libdvbv5, but 
just in case: libdvbv5_d (https://github.com/russel/libdvbv5_d) 
is a D binding created using DStep and lot of manual hacking. 
There is no test suite. :-( Also there is not yet a Dub package.


The driving application at the moment is DVBTune 
(https://github.com/russel/DV BTune) which is a D 
reimplementation of dvbv5-scan.



PS Should everything be on GitLab as well as GitHub to protect 
against "singlepoint of failure"?


I'm curious why you're interested in DVB at all. Online video and 
various OTT streaming services are killing off these protocols in 
most of the world. Why do you want to access them with D?

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16107

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #11 from Seb  ---
> Seb, do you confirm that run.dlang.io adds -g ?

Yes, -g is always added except if you just use -c

https://github.com/dlang-tour/core-exec/blob/master/entrypoint.sh

So the failure is still there:

https://run.dlang.io/is/8NVvW1

All compilers (called dreg) is a different image, but again omits -g only for
-g:

https://github.com/dlang-tour/core-dreg/blob/master/entrypoint.sh

--

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16107

Basile B.  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #10 from Basile B.  ---
Still reproducible here too. 

I think that it works online because -g is added to the switches so that the
object can be disasm and displayed. You can try on your machines with -g an
you'll see that the ICE doesn't appear.

Seb, do you confirm that run.dlang.io adds -g ?

--