Re: Unit Testing in Action

[Ali Çehreli via Digitalmars-d-announce]

On 10/24/2017 07:15 PM, Walter Bright wrote:

On 10/24/2017 3:06 PM, Ali Çehreli wrote:

It would be very useful if the compiler could do that automatically.


On 10/24/2017 2:58 PM, qznc wrote:
 > The information is there just not expressed in a useable way.


The problem is how to display it in a text file with the original source 
code.




I wouldn't mind as ugly as needed. The following original code

if (api1 == 1 && api2 == 2 ||
api2 == 2 && api3 == 3) {
foo();
}

could be broken like the following and I wouldn't mind:

if (api1 == 1 &&
api2 == 2 ||
api2 == 2 &&
api3 == 3) {
foo();
}

I would go work on the original code anyway.

Ali

Re: Note from a donor

[Walter Bright via Digitalmars-d]

On 10/24/2017 6:20 AM, Andrei Alexandrescu wrote:

* better dll support for Windows.


It's been there, but it breaks repeatedly because it is not in the test suite.

Re: call Pascal DLL functions from D

[Basile B. via Digitalmars-d-learn]

On Wednesday, 25 October 2017 at 03:12:56 UTC, Oleg B wrote:
Hello. I have DLL written on Pascal and "headers" for use it 
(types and functions signatures definitions). How I can port 
"headers" to D?


Calling convention is `stdcall` (`extern (Windows)` for D), 
arguments of some functions is structs of structs and etc with 
static array fields:


```Pascal
type
  TOneHarmonic = record
Koef: Single;
Angle: Single;
  end;

  THarmonicsArray = array[2..50] of TOneHarmonic;
  TInterharmonicsArray = array[1..49] of TOneHarmonic;

  TVoltageCurrentOneFaza = record
KalibKoef: Single;
IncludeMainFreq: Boolean;
MainFreqVoltCur: TOneHarmonic;
Harmonics: THarmonicsArray;
Interharmonics: TInterharmonicsArray;
  end;

  TVoltageCurrent = record
Enable: Boolean;
NominalID: Byte;
Faza_A: TVoltageCurrentOneFaza;
Faza_B: TVoltageCurrentOneFaza;
Faza_C: TVoltageCurrentOneFaza;
  end;

  TSignal = record
HasInterharmonics: Boolean;
Voltage: TVoltageCurrent;
Current: TVoltageCurrent;
...
  end;
  ...
```

in other file

```Pascal
function CheckSignalData(SignalData: PUserSignalData): Word;
  stdcall; external SIGNALK2MDLL;
```
PUserSignalData is pointer to TUserSignalData, first field of 
TUserSignalData is Signal, other fields is pointers to other 
types


If I understand correctly
1. `Single` is `float` in D, `Byte` is `byte`, `Boolean` is 
`bool`, `Word` is `ushort`


No Pascal's "Byte" is D's "ubyte". But unless NominalID goes over 
127 this is not the source of the problem.



2. `array[A..B] of TFoo` is `TFoo[B-A+1]` (static array)


No A-B. In Pascal the upper bound of a range (like here but i'm 
not sure this i called like that in the grammar) or of a slice is 
inclusive.




Can I rewrite records to structs like this?

```d
alias Word = short;
alias Single = float;
alias Byte = byte;
alias Boolean = bool;

struct OneHarmonic
{
Single coef;
Single angle;
}

alias HarmonicArray = OneHarmonic[49];


48 !


// TVoltageCurrentOneFaza
struct PhaseInfo
{
// Must I align fields and/or structs?


No, unless the record is packed.


Single calibCoef;
Boolean includeMainFreq;
OneHarmonic mainFreqVoltCur;
HarmonicArray harmonics; // Can I replace Pascal static 
arrays with D static arrays?

HarmonicArray interharmonics;
}

// TVoltageCurrent
struct ChannelInfo
{
Boolean enable;
Byte nominalID;
PhaseInfo[3] phase; // Can I replace 3 fields to static 
array?


yes


}

struct Signal
{
Boolean hasInterharmonics;
ChannelInfo voltage;
ChannelInfo current; // #1
...
}
```

In this case I have error about current values (#1) and I think 
I badly rewrite Pascal records to D structs (ChannelInfo, 
PhaseInfo, OneHarmonic) and lose alignments and/or something 
else.


PS original pascal naming is very bad, I know


Most likely the problem is the array length.

Re: Advice requested for fixing issue 17914

[safety0ff via Digitalmars-d]

On Wednesday, 25 October 2017 at 01:26:10 UTC, Brian Schott wrote:


I've been reading the Fiber code and (so far) that seems seems 
to be reasonable. Can anybody think of a reason that this would 
be a bad idea? I'd rather not create a pull request for a 
design that's not going to work because of a detail I've 
overlooked.


Just skimming the Fiber code I found the reset(...) API functions 
whose purpose is to re-use Fibers once they've terminated.


Eager stack deallocation would have to coexist with the Fiber 
reuse API.


Perhaps the Fiber reuse API could simply be polished & made easy 
to integrate so that your original use case no longer hits system 
limits.


I.e. Perhaps an optional delegate could be called upon 
termination, making it easier to hook in Fiber recycling.


The reason my thoughts head in that direction is that I've read 
that mmap/unmmap 'ing frequently isn't recommended in performance 
conscious programs.

[Issue 11714] Improve error message for wrongly initialized thread-local class instances

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

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

calex  changed:

   What|Removed |Added

 CC||calex+bugzilla-mail@aristow
   ||eb.net

--

[Issue 17932] [scope] __traits(compiles, stmt) cannot test scope violations

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

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

calex  changed:

   What|Removed |Added

 CC||calex+bugzilla-mail@aristow
   ||eb.net

--

[Issue 17077] Unexpected optlink termination

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

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

Walter Bright  changed:

   What|Removed |Added

   Hardware|x86_64  |x86

--

[Issue 10780] Optlink doesn't work on shared folder in VirtualBox

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

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

Walter Bright  changed:

   What|Removed |Added

   Hardware|All |x86
 OS|All |Windows

--

[Issue 15183] Unexpected OPTLINK Termination at EIP=00425CF0

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

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

Walter Bright  changed:

   What|Removed |Added

   Hardware|x86_64  |x86

--

Re: call Pascal DLL functions from D

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 25 October 2017 at 03:12:56 UTC, Oleg B wrote:
Calling convention is `stdcall` (`extern (Windows)` for D), 
arguments of some functions is structs of structs and etc with 
static array fields:


Fun fact, D has extern(Pascal): 
https://dlang.org/spec/attribute.html#linkage



I don't know the details  of the rest... but I think you're right 
about what you have so far.


I'd suggest just trying it and seeing if the functions return 
what you expect.

[Issue 12054] PATH env. var longer than 1022 characters breaks OPTLINK search path

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

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

Walter Bright  changed:

   What|Removed |Added

   Hardware|All |x86
 OS|All |Windows

--

[Issue 3327] OPTLINK and the librarian fail to see a symbol in a library

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

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

Walter Bright  changed:

   What|Removed |Added

   Hardware|Other   |x86

--

[Issue 5215] Crash with empty program

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

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

Walter Bright  changed:

   What|Removed |Added

   Hardware|Other   |x86

--

[Issue 4823] CodeView: Thread local variables are stored as shared globals

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

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

Walter Bright  changed:

   What|Removed |Added

   Hardware|Other   |x86

--

[Issue 16129] Linker error when using zero length array

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Walter Bright  ---


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

--

[Issue 7997] Optlink issues 'Index Range' error with static zero length array

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||foolery...@gmail.com

--- Comment #2 from Walter Bright  ---
*** Issue 16129 has been marked as a duplicate of this issue. ***

--

[Issue 16855] Global void[0] causes OPTLINK Error when passed as ref Parameter

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Walter Bright  ---


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

--

[Issue 16129] Linker error when using zero length array

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||qs.il.paperi...@gmail.com

--- Comment #1 from Walter Bright  ---
*** Issue 16855 has been marked as a duplicate of this issue. ***

--

[Issue 15213] Unexpected OPTLINK Termination at EIP = 0040347E

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

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

Walter Bright  changed:

   What|Removed |Added

   Hardware|x86_64  |x86

--

[Issue 13172] optimize and rawread cause symbol undefined errors

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |WORKSFORME

--- Comment #17 from Walter Bright  ---
(In reply to joeyemmons from comment #16)
> (In reply to briancschott from comment #15)
> > I'm not able to reproduce this with 2.067.0-b2.
> 
> Had the same bug and switching to 2.067.0-b2 also fixed it. 
> See http://forum.dlang.org/thread/vuyznzmdhuxsefeep...@forum.dlang.org

I'll mark it as WORKSFORME then.

--

[Issue 7997] Optlink issues 'Index Range' error with static zero length array

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

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

Walter Bright  changed:

   What|Removed |Added

Summary|Optlink crash with static   |Optlink issues 'Index
   |zero length array   |Range' error with static
   ||zero length array

--

[Issue 6678] optlink crash with large array of structs

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Walter Bright  ---
(In reply to bearophile_hugs from comment #0)
> But this similar program:
> [...]
> Causes a crash of optlink at EIP=004114FC.

Now causes:

test.d(4): Error: variable test.array size of 0x3567e00 exceeds max allowed
size 0x100

--

[Issue 6397] D1: Empty const string causes bad obj

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |WORKSFORME

--- Comment #1 from Walter Bright  ---
Works with HEAD.

--

call Pascal DLL functions from D

[Oleg B via Digitalmars-d-learn]

Hello. I have DLL written on Pascal and "headers" for use it 
(types and functions signatures definitions). How I can port 
"headers" to D?


Calling convention is `stdcall` (`extern (Windows)` for D), 
arguments of some functions is structs of structs and etc with 
static array fields:


```Pascal
type
  TOneHarmonic = record
Koef: Single;
Angle: Single;
  end;

  THarmonicsArray = array[2..50] of TOneHarmonic;
  TInterharmonicsArray = array[1..49] of TOneHarmonic;

  TVoltageCurrentOneFaza = record
KalibKoef: Single;
IncludeMainFreq: Boolean;
MainFreqVoltCur: TOneHarmonic;
Harmonics: THarmonicsArray;
Interharmonics: TInterharmonicsArray;
  end;

  TVoltageCurrent = record
Enable: Boolean;
NominalID: Byte;
Faza_A: TVoltageCurrentOneFaza;
Faza_B: TVoltageCurrentOneFaza;
Faza_C: TVoltageCurrentOneFaza;
  end;

  TSignal = record
HasInterharmonics: Boolean;
Voltage: TVoltageCurrent;
Current: TVoltageCurrent;
...
  end;
  ...
```

in other file

```Pascal
function CheckSignalData(SignalData: PUserSignalData): Word;
  stdcall; external SIGNALK2MDLL;
```
PUserSignalData is pointer to TUserSignalData, first field of 
TUserSignalData is Signal, other fields is pointers to other types


If I understand correctly
1. `Single` is `float` in D, `Byte` is `byte`, `Boolean` is 
`bool`, `Word` is `ushort`

2. `array[A..B] of TFoo` is `TFoo[B-A+1]` (static array)

Can I rewrite records to structs like this?

```d
alias Word = short;
alias Single = float;
alias Byte = byte;
alias Boolean = bool;

struct OneHarmonic
{
Single coef;
Single angle;
}

alias HarmonicArray = OneHarmonic[49];

// TVoltageCurrentOneFaza
struct PhaseInfo
{
// Must I align fields and/or structs?
Single calibCoef;
Boolean includeMainFreq;
OneHarmonic mainFreqVoltCur;
HarmonicArray harmonics; // Can I replace Pascal static 
arrays with D static arrays?

HarmonicArray interharmonics;
}

// TVoltageCurrent
struct ChannelInfo
{
Boolean enable;
Byte nominalID;
PhaseInfo[3] phase; // Can I replace 3 fields to static array?
}

struct Signal
{
Boolean hasInterharmonics;
ChannelInfo voltage;
ChannelInfo current; // #1
...
}
```

In this case I have error about current values (#1) and I think I 
badly rewrite Pascal records to D structs (ChannelInfo, 
PhaseInfo, OneHarmonic) and lose alignments and/or something else.


PS original pascal naming is very bad, I know

[Issue 5950] [AA] Linker problem with AA.get()

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |WORKSFORME

--- Comment #3 from Walter Bright  ---
It is working with HEAD now.

--

[Issue 5215] Crash with empty program

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

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||Optlink

--

[Issue 4823] CodeView: Thread local variables are stored as shared globals

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

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||Optlink
 CC||bugzi...@digitalmars.com

--

[Issue 4541] Intrinsic functions do not have pointers

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |WORKSFORME

--- Comment #10 from Walter Bright  ---
It works fine when I try it with the latest.

--

[Issue 4315] Invalid object file created when appending const char[0] to char[]

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |WORKSFORME

--- Comment #3 from Walter Bright  ---
Can't reproduce a problem with the latest.

--

[Issue 4176] Link error in switch with 4 or more cases and no default

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

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #3 from Walter Bright  ---
What's happening is __d_switch_error is in phobos.lib. Phobos.lib is not
automatically linked in unless there's a "main" definition in the file. Hence
__d_switch_error is undefined.

__d_switch_error is what is called when there isn't a default.

In any case, now this error message is emitted:

test.d(2): Error: switch statement without a default; use final switch or add
default: assert(0); or add default: break;

--

[Issue 4010] dmd should support linkers other than OPTLINK

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

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #11 from Walter Bright  ---
dmd will now support MS-COFF output with the -m32mscoff compiler switch.

--

[Issue 3094] incorrect previous definition error

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |INVALID

--

[Issue 2249] DMD can't handle include paths with spaces in them

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #6 from Walter Bright  ---
It's working with the latest dmd.

--

[Issue 1404] Link failure with template mixin and function literal

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |WORKSFORME

--- Comment #4 from Walter Bright  ---
It works when I try it with the latest.

--

[Issue 1327] Long environment variable value causes link failure.

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

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||Optlink
 CC||bugzi...@digitalmars.com

--

Re: Advice requested for fixing issue 17914

[Brian Schott via Digitalmars-d]

On Tuesday, 24 October 2017 at 21:49:10 UTC, qznc wrote:
My question wrt to the bug: Why is munmap/freeStack called in 
the destructor? Could be done right after termination?


I've been reading the Fiber code and (so far) that seems seems to 
be reasonable. Can anybody think of a reason that this would be a 
bad idea? I'd rather not create a pull request for a design 
that's not going to work because of a detail I've overlooked.

Re: So why double to float conversion is implicit ?

[codephantom via Digitalmars-d]

On Wednesday, 25 October 2017 at 01:06:40 UTC, codephantom wrote:
Consensus within groups is kind of important actually...it 
encourages harmony and coherence..with which.. there is no 
group.




if only we could edit our post to correct it...when's that going 
to happen btw. ;-)


of course I meant .. 'without which' ...not 'with which' ...

btw. further below is a good study in group dynamics - I like the 
phrase "Stupidity certainly is not the explanation". (second 
paragraph)


http://web.mit.edu/curhan/www/docs/Articles/15341_Readings/Group_Dynamics/Janis_Groupthink_from_Psych_Today.pdf

Re: So why double to float conversion is implicit ?

[codephantom via Digitalmars-d]

On Tuesday, 24 October 2017 at 16:28:03 UTC, Fool wrote:


@all: It is sad to see how parts of the community are losing 
their distance to the project and even put a gloss on 
completely absurd design decisions.


Consensus within groups is kind of important actually...it 
encourages harmony and coherence..with which.. there is no group.


But just as important, is being aware of the danger of 
groupthink...


Many (implicitly) understand the former, few understand (or are 
even aware of) the latter..


https://www.jstor.org/stable/3791464?seq=1#page_scan_tab_contents

Not that I'm suggesting anything here other than... don't become 
the victim of groupthink.

[Issue 17935] New: [scope] auto-generated destructor not scope aware

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

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

  Issue ID: 17935
   Summary: [scope] auto-generated destructor not scope aware
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: safe
  Severity: normal
  Priority: P4
 Component: dmd
  Assignee: bugzi...@digitalmars.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
struct ByChunk(IO)
{
@safe:
~this() scope
{}

ubyte[] buf;
IO io;
}

struct IO
{
~this() @safe scope
{}
}

///
@safe @nogc unittest
{
ubyte[256] buf;
auto chunks = ByChunk!IO(buf[], IO());
chunks.__xdtor(); // auto-generated inclusive (fields and struct) dtor
}
CODE
dmd -c -dip1000 bug.d

bug.d(21): Error: scope variable `chunks` assigned to non-scope parameter
`this` calling bug.ByChunk!(IO).ByChunk.~this
bug.d(22): Error: scope variable `chunks` assigned to non-scope parameter
`this` calling bug.ByChunk!(IO).ByChunk.~this


Guess we should at best always attempt to infer scope for any generate method.

--

Re: Getting a safe path for a temporary file

[Ali Çehreli via Digitalmars-d-learn]

On 10/22/2017 06:41 PM, Shriramana Sharma wrote:
> On Sunday, 22 October 2017 at 15:21:37 UTC, Shriramana Sharma wrote:
>> For my program right now I'm using a souped-up version using a static
>> array:
>>
>> char[20] name = "/tmp/XX";

Literal strings have a '\0' attached, which does not become a part of 
the slice.


> Hmm I was wondering if I needed it to be static, and verily, 
substituting:

>
> char[] name = "/tmp/XX".dup;

However, .dup is not be aware of the special literal treatment so it 
does not copy the '\0' character.


> Is it because the D slice is subject to relocation and C is occasionally
> not able to access the proper pointer?

As long as you have a reference on the D side, the slice will remain 
valid. The actual issue is the missing '\0'. So, consider toStringz in 
this case:


  https://dlang.org/library/std/string/to_stringz.html

Ali

Re: DMD Callstacks

[user1234 via Digitalmars-d-learn]

On Tuesday, 24 October 2017 at 06:49:37 UTC, abad wrote:
On Monday, 23 October 2017 at 12:41:09 UTC, Márcio Martins 
wrote:
What is everyone doing to get proper file name and line number 
info for callstacks with DMD?


addr2line just gives me ??:0


You could try compiling with the -debug-switch. Of course if 
this turns out to be the fix, it doesn't help with std code.


"-debug" activates the debug condition. To get file and line it's 
"-g" (generate debug infos), although this won't have any effect 
for phobos since the static library is already compiled.

Re: Named arguments

[jmh530 via Digitalmars-d]

On Tuesday, 24 October 2017 at 20:36:00 UTC, H. S. Teoh wrote:

[snip]
it would be more self-documenting if written as:

// (Hypothetical syntax)
auto x = foo(width: 1, height: 2, userId: 3);



What about something that's a little uglier, but could be done 
with D magic?


For instance:
auto x = foo!(["width", "height", "userId"])(1, 2, 3)

So for instance, you could have some original function, like below

@namedParam("width", "height", "userId") auto x = _foo(int width, 
int height, UserId userId) { }


and then some D magic inserts a new function that is like

auto foo(string[] names)(...) { }

and then processes names, mixing in the correct named/typed 
variables and then returning a call to _foo with those variables.

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

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

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

--- Comment #1 from Martin Nowak  ---
Even if `l` is not inferred as scope, it should be a local with limited
lifetime.
The return value `l.front` should have that same lifetime b/c of `return
scope`.
Both of them should be shorter as `elem`, hence assignment should fail.

--

Re: Advice requested for fixing issue 17914

[Brian Schott via Digitalmars-d]

On Tuesday, 24 October 2017 at 14:28:01 UTC, Steven Schveighoffer 
wrote:
A failing use case would help. Fixing a bug when you can't 
reproduce is difficult.


-Steve


I've attached one to the bug report.

[Issue 17934] New: [scope] scopeness entrypoint for unique/ref-counted missing

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

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

  Issue ID: 17934
   Summary: [scope] scopeness entrypoint for unique/ref-counted
missing
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: safe
  Severity: normal
  Priority: P3
 Component: dmd
  Assignee: bugzi...@digitalmars.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
import core.stdc.stdlib;

struct List
{
Elem front() @safe return scope
{
return Elem(data);
}

~this() @trusted scope
{
free(data);
data = null;
}

@disable this(this);

private:
void* data;
}

struct Elem
{
private:
void* data;
}

/**
  There seems to be now way to write this functions so
  that the compiler infers the return value as scope.
 */
List list() @trusted
{
return List(malloc(1));
}

void test() @safe
{
Elem elem;
{
//scope l = list(); // works with explicit scope
auto l = list(); // not inferred as scope
elem = l.front; // escapes, b/c l isn't scoped
}
}
CODE
dmd -c -dip1000 bug.d


Repeatedly ending up with this problem. It doesn't seem possible to contain
allocated data, as there is now way to enforce that the call-site uses a scope
variable.

--

[Issue 15324] symbol is already defined / size of symbol changed

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

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 17332] optilink or dmd bug

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

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 17332] optilink or dmd bug

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |DUPLICATE

--- Comment #2 from Walter Bright  ---


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

--

[Issue 16687] Win COFF: Duplicate COMDAT on overloaded templated function

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||phreon...@gmail.com

--- Comment #2 from Walter Bright  ---
*** Issue 17332 has been marked as a duplicate of this issue. ***

--

[Issue 17914] Accidental per-process limit of fiber uses

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

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

--- Comment #1 from briancsch...@gmail.com ---
Minimal test case: 

void main()
{
import std.concurrency : Generator, yield;
import std.stdio : File, writeln;

auto f = File("/proc/sys/vm/max_map_count", "r");
ulong n;
f.readf("%d", );
writeln("/proc/sys/vm/max_map_count = ", n);
foreach (i; 0 .. n + 1000)
{
if (i % 1000 == 0)
writeln("i = ", i);
new Generator!int({ yield(1); });
}
}

--

[Issue 16687] Win COFF: Duplicate COMDAT on overloaded templated function

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
Optlink doesn't complain because when there are multiple COMDATs with the same
name, the linker just picks one.

--

Re: Note from a donor

[jmh530 via Digitalmars-d]

On Tuesday, 24 October 2017 at 21:11:37 UTC, Andre Pany wrote:


In general I agree with you that coff is the way to go. I just 
dislike the consequences. Today you just download the dmd 
Windows zip, extract it and you have a running compiler. Nice, 
self contained and a good advertisement for D. On the other 
side if the user is forced to install Visual Studio / C++ build 
pack, this might distract first time D users...


If the Microsoft linker could be added to dmd that would be the 
best solution. Just dreaming :)


Kind regards
Andre


I'm sympathetic to your point.

I think there was/is some effort to allow LLD (the LLVM linker) 
as a replacement for the MSVC linker in LDC. Perhaps if LLD could 
be a drop-in for MSVC in DMD for Windows, then eventually it 
could be the default? Not sure that's possible or not.

Re: Unit Testing in Action

[Ali Çehreli via Digitalmars-d-announce]

On 10/24/2017 01:51 PM, Walter Bright wrote:
> On 10/23/2017 4:44 AM, Martin Nowak wrote:

> There would be a separate coverage count for line 3 which would be the
> sum of counts for (api2 == 2) and (api3 == 3).
>
> Generally, if this is inadequate, just split the expression into more
> lines.

It would be very useful if the compiler could do that automatically.

Ali

Re: Named arguments

[Jonathan M Davis via Digitalmars-d]

On Tuesday, October 24, 2017 13:36:00 H. S. Teoh via Digitalmars-d wrote:
> On Tue, Oct 24, 2017 at 01:22:41PM -0600, Jonathan M Davis via
> > It also wouldn't play well with separate compilation unless the
> > parameter names were mangled into the function names, and symbol names
> > in D are already too often too long due to idioms like Voldemort types
> > creating really long symbol names. Recent work on the compiler has
> > reduced that problem, but adding more information to mangled names
> > would definitely not help.
>
> [...]
>
> Nah.  Parameter names are a concept only necessary at compile-time.  All
> you need is to import the function declaration with the right parameter
> names, and on the caller's side the compiler will always emit the
> arguments in the right order.  So no need to mangle parameter names at
> all.

Except that things get a bit interesting with regards to stuff like .di
files. Without the parameter names being mangled in, it would be possible
for the parameter names in the .di files to not match the ones in the .d
files. It's possible for that now, but right now, it doesn't matter, whereas
with named arguments, it would matter. To some extent, you could probably
get away with it, because the code that compiles against the .di files
wouldn't normally be compiled against the .d files or vice versa, but it
means that switching whether you used the .di files or the .d files could
break code, whereas now, it wouldn't.

Now, .di files are kind of terrible to use anyway, but introducing named
arguments would just make them even more fragile if the parameter names
aren't part of the function's mangled name.

- Jonathan M Davis

Re: Advice requested for fixing issue 17914

[qznc via Digitalmars-d]

On Monday, 23 October 2017 at 16:56:32 UTC, Brian Schott wrote:

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

I need to get this issue resolved as soon as possible so that 
the fix makes it into the next compiler release. Because it 
involves cleanup code in a class destructor a design change may 
be necessary. Who should I contact to determine the best way to 
fix this bug?


Looking at git blame [0], I guess Martin Nowak and Nemanja Boric 
seem to be pretty involved. Not sure how deep Petar Kirov and 
Sean Kelly are into Fibers.


My question wrt to the bug: Why is munmap/freeStack called in the 
destructor? Could be done right after termination?


[0] 
https://github.com/dlang/druntime/blame/ec9a79e15d446863191308fd5e20febce2053546/src/core/thread.d#L4077

[Issue 16660] Deprecate/Remove Optlink as Default Linker on Windows

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

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

Walter Bright  changed:

   What|Removed |Added

   Severity|major   |enhancement

--

[Issue 16334] dmd producing invalid OMF file

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright  ---
This is dmd generating a corrupt object file (not an Optlink problem).

--

[Issue 11869] Optlink doesn't detects strings duplicate

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

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #2 from Walter Bright  ---
String literals go into COMDATs now, so this is no longer an issue.

--

[Issue 17881] Provide mechanism to preallocate memory from the GC

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

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

--- Comment #10 from Andrei Alexandrescu  ---
(In reply to Steven Schveighoffer from comment #8)
> What I am looking for,
> though, is the high-level API of "I have 20 million T's I want to allocate,
> give me them properly allocated and typed one at a time".

This issue should be closed. A good allocator should be able to handle repeated
allocations of the same size without this kind of hint.

--

Re: Note from a donor

[solidstate1991 via Digitalmars-d]

On Tuesday, 24 October 2017 at 13:37:09 UTC, rikki cattermole 
wrote:

On 24/10/2017 2:25 PM, Mike Parker wrote:
On Tuesday, 24 October 2017 at 13:20:10 UTC, Andrei 
Alexandrescu wrote:



* better dll support for Windows.


This one is on a lot of wish lists.


It definitely needs to be a target for 2018H1, I'll be making 
sure its added! Too big a blocker and comes up a little too 
often...


DIP45 has the solution (make export an attribute), it needs to be 
updated for the new DIP format from what I heard. It needs to be 
pushed, as Windows still the most popular OS on the consumer side 
of things, then we can have Phobos and DRuntime as DLLs without 
using experimental versions of DMD. I have some plans with the 
better DLL support, such as the possibility of a D based Python 
(for better class interoperability with D), or even using a 
modified set of D for scripting (eg. SafeD only).

Re: Note from a donor

[Andre Pany via Digitalmars-d]

On Tuesday, 24 October 2017 at 20:27:26 UTC, Adam Wilson wrote:

On 10/24/17 07:14, Kagamin wrote:
On Tuesday, 24 October 2017 at 13:20:10 UTC, Andrei 
Alexandrescu wrote:

* RSA Digital Signature Validation in Phobos


https://issues.dlang.org/show_bug.cgi?id=16510 the blocker for 
botan was

OMF support.


IMO, the correct solution here is to deprecate OMF and use the 
System linker for 32-bit on Windows as that is already the 
default behavior on 64-bit Windows


So instead of -m32 and -m32mscoff, we would have -m32 and 
-m32omf. I think that this is a reasonable tradeoff. We could 
leave -m32mscoff in for a while, for backwards compat.


In general I agree with you that coff is the way to go. I just 
dislike the consequences. Today you just download the dmd Windows 
zip, extract it and you have a running compiler. Nice, self 
contained and a good advertisement for D. On the other side if 
the user is forced to install Visual Studio / C++ build pack, 
this might distract first time D users...


If the Microsoft linker could be added to dmd that would be the 
best solution. Just dreaming :)


Kind regards
Andre

Re: Unit Testing in Action

[Walter Bright via Digitalmars-d-announce]

On 10/23/2017 4:44 AM, Martin Nowak wrote:

On Saturday, 21 October 2017 at 22:50:51 UTC, Walter Bright wrote:

Coverage would give:

1|    x = 2;
2|    if (x == 1 || x == 2)

I.e. the second line gets an execution count of 2. By contrast,

1|    x = 1;
1|    if (x == 1 || x == 2)


Interesting point, but would likely fail for more complex stuff.

1| stmt;
2| if (api1 == 1 && api2 == 2 ||
    api2 == 2 && api3 == 3)


There would be a separate coverage count for line 3 which would be the sum of 
counts for (api2 == 2) and (api3 == 3).


Generally, if this is inadequate, just split the expression into more lines.

The same thing for for loop statements and ?:


Anyhow, I think the current state is good enough and there are gdc/ldc for 
further coverage features.

Re: My two cents

[Rainer Schuetze via Digitalmars-d]

On 23.10.2017 22:47, Walter Bright wrote:

On 10/18/2017 1:56 AM, Satoshi wrote:
Unable to publish closed source library without workaround and ugly 
PIMPL design.



Consider this:

--- file s.d 
   struct S {
     int x;
     this(int x) { this.x = x; }
     int getX() { return x; }
   }
--- file s.di 
   struct S {
     this(int x);
     int getX();
   }
--

User code:

     import s;
     S s = S(3);
     writeln(s.getX());


I doubt this reserves enough space on the stack for the copy.



Ta dah! Implementation is hidden, no PIMPL. Of course, inlining of the 
member functions won't work, but it won't work in C++, either, when this 
technique is used.


I.e. you can use .di/.d files just like you'd use .h/.cpp in C++. The 
technique works with classes, too.

Re: Named arguments

[H. S. Teoh via Digitalmars-d]

On Tue, Oct 24, 2017 at 01:22:41PM -0600, Jonathan M Davis via Digitalmars-d 
wrote:
[...]
> Personally, I don't want them in D. If you have enough arguments that
> it matters, then the function probably has too many parameters or too
> many similar parameters.

If a function has too many parameters, or only a small subset of
parameters need to be something other than some default value, or the
set of parameters may change frequently, then my default approach is to
abstract the parameters into a struct:

struct OutputArgs {
string filename;
int width = 300;
int height = 300;
string fontDir = "/usr/share/local/fonts/arial.ttf";
int fontSize = 12;
Color background = Color.black;
Color foreground = Color.white;
bool antiAlias = true;
}

void generateOutput(OutputArgs args) { ... }

void main() {
// Setup function arguments.
// N.B.: only .filename needs to be explicitly set.
OutputArgs args;
args.filename = "/tmp/output.png";

// Call function with mostly default arguments.
generateOutput(args);
}

This approach means that if you ever need to add more parameters to
OutputArgs, as long as the default value is compatible with previous
behaviour, you won't have to change existing code. Also, the caller can
set the arguments in any order without needing to memorize which
parameter is in which position.


> And as a library writer, I don't want to have the parameter names be
> part of the API. There are already enough problems getting the type
> and function names right without having to worry about bikeshedding
> over parameter names as well, and if we had named arguments, then you
> couldn't change parameter names without breaking code.

There are times, however, when named parameters might be desirable.
Self-documenting code is one. Rather than:

auto x = foo(1, 2, 3);

it would be more self-documenting if written as:

// (Hypothetical syntax)
auto x = foo(width: 1, height: 2, userId: 3);

There are ways around this, of course.  Here's a somewhat klunky, but
workable solution:

struct Width {
int value;
alias value this;
}
struct Height {
int value;
alias value this;
}
struct UserId {
int value;
alias value this;
}
int foo(Width w, Height h, UserId id) { ... }

auto x = foo(Width(1), Height(2), UserId(3));

Inside the body of foo, you can freely assign w, h, and id to int
variables, because of the `alias this`.  But the declared parameter
types of foo demands the user to use self-documenting syntax.

And presumably, if your code already has values of the requisite types,
you can pass them directly without needing to repeat the constructor
name:

int bar(Width w, Height h) {
UserId id = getUserId();
foo(w, h, id);  // no need to type Width(w), etc.
}

But of course, this scheme only works well if you have a common set of
parameters that are used in many places.  Otherwise you'll end up having
to declare tons of structs that are only ever used to call 1 or 2
functions, which would be a lot of typing for little benefit.  You
could, of course, write a mixin template to factor out the boilerplate
(somewhat), but even that doesn't necessarily cover all possible use
cases.


> It also wouldn't play well with separate compilation unless the
> parameter names were mangled into the function names, and symbol names
> in D are already too often too long due to idioms like Voldemort types
> creating really long symbol names. Recent work on the compiler has
> reduced that problem, but adding more information to mangled names
> would definitely not help.
[...]

Nah.  Parameter names are a concept only necessary at compile-time.  All
you need is to import the function declaration with the right parameter
names, and on the caller's side the compiler will always emit the
arguments in the right order.  So no need to mangle parameter names at
all.


T

-- 
An imaginary friend squared is a real enemy.

Re: My two cents

[Walter Bright via Digitalmars-d]

On 10/24/2017 3:36 AM, Satoshi wrote:

Can you provide an example?


I'd start with https://dlang.org/spec/interface.html

You'll see the same thing with Windows COM programming, and using interfaces in 
Java.


 view.di 
interface View {
void render();
}
View createView();

 button.di 
import view;
interface Button : View {
void simulateClick();
}
Button createButton();

 closed_src_library.d 
import view, button;
private class LibraryView : View {
   int hidden_data;
   void render() { do something with hidden_data }
}

private class LibraryButton : Button {
int hidden_data;
void simulateClick() {  }
}

View createView() {
return new LibraryView();
}

View createButton() {
return new LibraryButton();
}

--- my_extension.d ---
import view, button;
class ExtendView : View {
View base;
this() {
base = createView();
}
void render() {
base.render();
... do my rendering ...
}
}

Re: Named arguments

[jmh530 via Digitalmars-d]

On Tuesday, 24 October 2017 at 19:22:41 UTC, Jonathan M Davis 
wrote:


Personally, I don't want them in D. If you have enough 
arguments that it matters, then the function probably has too 
many parameters or too many similar parameters. And as a 
library writer, I don't want to have the parameter names be 
part of the API. There are already enough problems getting the 
type and function names right without having to worry about 
bikeshedding over parameter names as well, and if we had named 
arguments, then you couldn't change parameter names without 
breaking code. It also wouldn't play well with separate 
compilation unless the parameter names were mangled into the 
function names, and symbol names in D are already too often too 
long due to idioms like Voldemort types creating really long 
symbol names. Recent work on the compiler has reduced that 
problem, but adding more information to mangled names would 
definitely not help.


- Jonathan M Davis


Some good points. I realized that most of the languages that have 
named parameters are dynamically typed ones (Python/R) or ones 
with VMs (C#/Scala). Fortran has named parameters and function 
overloading, but I think it's a little quirky and not like C++ 
and D as far as I can tell.

Re: Note from a donor

[Adam Wilson via Digitalmars-d]

On 10/24/17 07:14, Kagamin wrote:

On Tuesday, 24 October 2017 at 13:20:10 UTC, Andrei Alexandrescu wrote:

* RSA Digital Signature Validation in Phobos


https://issues.dlang.org/show_bug.cgi?id=16510 the blocker for botan was
OMF support.


IMO, the correct solution here is to deprecate OMF and use the System 
linker for 32-bit on Windows as that is already the default behavior on 
64-bit Windows


So instead of -m32 and -m32mscoff, we would have -m32 and -m32omf. I 
think that this is a reasonable tradeoff. We could leave -m32mscoff in 
for a while, for backwards compat.


--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Re: iopipe alpha 0.0.1 version

[Dmitry Olshansky via Digitalmars-d-announce]

On Tuesday, 24 October 2017 at 19:05:02 UTC, Martin Nowak wrote:
On Tuesday, 24 October 2017 at 14:47:02 UTC, Steven 
Schveighoffer wrote:
iopipe provides "infinite" lookahead, which is central to its 
purpose. The trouble with bolting that on top of ranges, as 
you said, is that we have to copy everything out of the range, 
which necessarily buffers somehow (if it's efficient i/o), so 
you are double buffering. iopipe's purpose is to get rid of 
this unnecessary buffering. This is why it's a great fit for 
being the *base* of a range.


In other words, if you want something to have optional 
lookahead and range support, it's better to start out with an 
extendable buffering type like an iopipe, and bolt ranges on 
top, vs. the other way around.


Arguably this it is somewhat hacky to use a range as end marker 
for slicing sth., but you'd get the same benefit, access to the 
random buffer with zero-copying.


auto beg = rng.save; // save current position
auto end = rng.find("bla"); // lookahead using popFront
auto window = beg[0 .. end]; // get a random access window to 
underlying buffer



I had a design like that except save returned a “mark” (not full 
range) and there was a slice primitive. It even worked with 
patched std.regex, but at a non-zero performance penalty.


I think that maintaining the illusion of a full copy of range 
when you do “save” for buffered I/O stream is too costly. Because 
a user can now legally advance both - you need to RC buffers 
behind the scenes with separate “pointers” for each range that 
effectively pin them.



So basically forward ranges with slicing.
At least that would require to extend all algorithms with 
`extend` support, though likely you could have a small extender 
proxy range for IOPipes.


Note that rng could be a wrapper around unbuffered IO reads.

Re: My two cents

[Jonathan M Davis via Digitalmars-d]

On Monday, October 23, 2017 13:18:21 Guillaume Piolat via Digitalmars-d 
wrote:
> On Monday, 23 October 2017 at 11:39:58 UTC, Martin Nowak wrote:
> >> Every-symbol-public-by-default in Posix is annoying though :)
> >
> > We agreed on hidden visibility by default for everything that's
> > not exported.
> > This requires export to be fixed on non-Windows machines first.
>
> This is especially interesting since hidden visibility for most
> symbols is required to make -dead_strip effective (strips most of
> the object code here).

There are good technical reasons for requiring export, but man do I hate
having to deal with it when doing Windows development in C++. It is _so_
nice to not have to care when working on *nix codebases in C++ and so
annoying to deal with it when I have to worry about Windows that I lean
heavily towards not wanting export to be required in D even if there are
some definite technical problems with it. I've never had good things to say
about having to export stuff on Windows, no matter the language.

- Jonathan M Davis

Re: My two cents

[Jonathan M Davis via Digitalmars-d]

On Tuesday, October 24, 2017 18:53:49 Martin Nowak via Digitalmars-d wrote:
> On Monday, 23 October 2017 at 13:18:21 UTC, Guillaume Piolat
>
> wrote:
> >> By any means, if someone wants to help here, get in touch with
> >> Benjamin Thaut and me.
> >> This has been lingering around for way to long, and Benjamin
> >> alone has a hard time pushing this.
> >
> > Would Bountysource help be adequate?
>
> Not sure about Benjamin, but on my side it's time limited.
> I'd Bountysource didn't work out too well for us.

For it to work, it would likely either have to encourage developers who
aren't involved to get involved or provide enough money that developers who
are already involved could spend more time on D (e.g. because they're a
contractor and the money from a bounty was able to temporarily function as
their source of income). I don't think that either happened. Most of the
bounties were pretty small, and most full-time employees who work with D in
their free time are unlikely to be able to spend more time on D due to some
extra money, because time is the concern, not money. Best case, I'd expect
bountysource to encourage folks already working on D to work on something
specific, because they'd get a bit of extra money for it, but that doesn't
seem to have happened. I think that most of the folks contributing have
forgotten about bountysource entirely.

Anyone looking to help D grow via money is probably better off donating to
the D foundation - though whether this particular item is high enough of the
priority list for the D foundation to pay someone to work on it, I don't
know, and I don't know if there's someone with the appropriate skillset
who's available to be paid to work on it. The D Foundation is pretty new at
this (but the fact that it exists at all is a huge step forward).

There has been some interest in "improved DLL" support, which ties into
improving export on Windows, but there doesn't seem to have been a lot of
interest in actually working on it (at least not from folks with the time
to).

- Jonathan M Davis

Re: Named arguments

[Jonathan M Davis via Digitalmars-d]

On Tuesday, October 24, 2017 17:30:27 Andrey via Digitalmars-d wrote:
> Hello, why there are no named arguments for functions like, for
>
> example, in kotlin i.e.:
> > int sum(in int a, in int b) {
> >
> > return a + b;
> >
> > }
> >
> > sum(a = 1, b = 2);

Named arguments are not something that C-based languages typically have, and
D has a very strong C/C++ heritage. There are some folks who would like to
see them added to the language, but a DIP would have to be created and
approved by Walter and Andrei for that to happen. IIRC, in the past, Walter
didn't think that they interacted well with how D does function overloading,
but I don't know what he thinks now. Some folks have managed to implement
them using a library solution, and if you go digging in the
newsgroup/forum/mailing list history for "named parameters" or "named
arguments," you should be able to find discussions on that.

Personally, I don't want them in D. If you have enough arguments that it
matters, then the function probably has too many parameters or too many
similar parameters. And as a library writer, I don't want to have the
parameter names be part of the API. There are already enough problems
getting the type and function names right without having to worry about
bikeshedding over parameter names as well, and if we had named arguments,
then you couldn't change parameter names without breaking code. It also
wouldn't play well with separate compilation unless the parameter names were
mangled into the function names, and symbol names in D are already too often
too long due to idioms like Voldemort types creating really long symbol
names. Recent work on the compiler has reduced that problem, but adding more
information to mangled names would definitely not help.

- Jonathan M Davis

Re: iopipe alpha 0.0.1 version

[Martin Nowak via Digitalmars-d-announce]

On Tuesday, 24 October 2017 at 14:47:02 UTC, Steven Schveighoffer 
wrote:
iopipe provides "infinite" lookahead, which is central to its 
purpose. The trouble with bolting that on top of ranges, as you 
said, is that we have to copy everything out of the range, 
which necessarily buffers somehow (if it's efficient i/o), so 
you are double buffering. iopipe's purpose is to get rid of 
this unnecessary buffering. This is why it's a great fit for 
being the *base* of a range.


In other words, if you want something to have optional 
lookahead and range support, it's better to start out with an 
extendable buffering type like an iopipe, and bolt ranges on 
top, vs. the other way around.


Arguably this it is somewhat hacky to use a range as end marker 
for slicing sth., but you'd get the same benefit, access to the 
random buffer with zero-copying.


auto beg = rng.save; // save current position
auto end = rng.find("bla"); // lookahead using popFront
auto window = beg[0 .. end]; // get a random access window to 
underlying buffer


So basically forward ranges with slicing.
At least that would require to extend all algorithms with 
`extend` support, though likely you could have a small extender 
proxy range for IOPipes.


Note that rng could be a wrapper around unbuffered IO reads.

Re: My two cents

[Martin Nowak via Digitalmars-d]

On Monday, 23 October 2017 at 11:58:14 UTC, Laeeth Isharc wrote:

Bountysource went quiet, though I started contributing to it.
I wonder if there is a better way for commercial users to say 
what they might be willing to pay for and how much.


At best talk to Andrei, maybe you have a good idea to do this 
over the Foundation.

Re: My two cents

[Martin Nowak via Digitalmars-d]

On Monday, 23 October 2017 at 13:18:21 UTC, Guillaume Piolat 
wrote:
By any means, if someone wants to help here, get in touch with 
Benjamin Thaut and me.
This has been lingering around for way to long, and Benjamin 
alone has a hard time pushing this.


Would Bountysource help be adequate?


Not sure about Benjamin, but on my side it's time limited.
I'd Bountysource didn't work out too well for us.

Re: My two cents

[Martin Nowak via Digitalmars-d]

On Tuesday, 24 October 2017 at 09:56:50 UTC, rikki cattermole 
wrote:

scope+ref+out as arguments would be a no-no.
Now if we could ditch registers usage crossing before/after 
yield, we wouldn't need to do 'patching' like fibers do.


That's basically what asnyc/await does, some implementations as 
continuation (callback) some as jump rewrite.

Re: Note from a donor

[Joakim via Digitalmars-d]

On Tuesday, 24 October 2017 at 17:31:06 UTC, Ali Çehreli wrote:

On 10/24/2017 09:37 AM, H. S. Teoh wrote:
> On Tue, Oct 24, 2017 at 09:20:10AM -0400, Andrei Alexandrescu
via Digitalmars-d wrote:
>> A person who donated to the Foundation made a small wish
list known.
>> Allow me to relay it:
>>
>> * RSA Digital Signature Validation in Phobos
> [...]
>
> This is going to be a tricky one.  I'm very wary of
implementing
> cryptographic algorithms without a crypto expert on board.

deadalnix (Amaury Séchet) is in that field:

  http://dconf.org/2017/talks/sechet.html

Ali


He's a little busy right now: ;)

http://cryptotimes.org/alt-coin/amaury-sechet-discusses-the-values-of-bitcoin-abc-development/

Re: Address problem

[Ali Çehreli via Digitalmars-d-learn]

On 10/24/2017 10:47 AM, Gheorghe Gabriel wrote:

>  writeln(&_i);

That's the address of the local variable _i. You can think of class (and 
interface) variables as pointers to class objects.


> I need that I["s"] to have the same address like c.

The way to get the address of the actual object is to cast the class 
variable to void*. Here is your program with that change:


import std.stdio;

interface I { }

I[string] i;

class C : I {
this() {
i["s"] = this;
foreach (_i; i) {
writeln("value ", cast(void*)_i);
}
foreach (ref _i; i) {
writeln("ref   ", cast(void*)_i);
}
}
}

void main() {
C c = new C;
writeln("main  ", cast(void*)c);
assert(c is i["s"]);
}

Sample output for a 64-bit build:

value 7FCE3EB23110
ref   7FCE3EB23110
main  7FCE3EB23100

The reason why main's is different is because c is an object as opposed 
to an interface. Apparently, it has extra 16 bytes of stuff before the 
interface part.


Note the last line of main. Perhaps all you really need to do is to use 
the 'is' operator, which already takes care of such address calculations.


Ali

[Issue 17901] FreeBSD 10.3: AssertError@std/experimental/allocator/building_blocks/region.d(652)

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

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

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

   What|Removed |Added

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

--

[Issue 17901] FreeBSD 10.3: AssertError@std/experimental/allocator/building_blocks/region.d(652)

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

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

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

https://github.com/dlang/phobos/commit/71ed13678d682c0cc446067703cb0e464e7ff2ac
Fix issue 17901 - FreeBSD SbrkRegion alignment

https://github.com/dlang/phobos/commit/5a700c09d809a30ac885de884cd3e1335cf17967
Merge pull request #5806 from edi33416/fix_sbrk_region_freebsd

Fix issue 17901 - FreeBSD SbrkRegion alignment
merged-on-behalf-of: Andrei Alexandrescu 

--

Re: writeln double precision

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

On Tue, Oct 24, 2017 at 04:59:04PM +, jmh530 via Digitalmars-d-learn wrote:
> On Tuesday, 24 October 2017 at 16:18:03 UTC, H. S. Teoh wrote:
> > 
> > I have never seen a programming language in which dividing two
> > integers yields a float or double.  Either numbers default to a
> > floating point type, in which case you begin with floats in the
> > first place, or division is integer division, yielding an integer
> > result.
> > 
> > 
> > T
> 
> Haven't used Python 3+?

Haha, I guess I'm behind the times!


T

-- 
Gone Chopin. Bach in a minuet.

Re: So why double to float conversion is implicit ?

[Andrei Alexandrescu via Digitalmars-d]

On 10/24/2017 12:28 PM, Fool wrote:

On Tuesday, 24 October 2017 at 14:28:20 UTC, Basile B. wrote:

    float f0 = cos(2 * PI /  1.123548789545545646452154L);
    float f1 = cos(cast(float)(2 * PI / 1.123548789545545646452154L));

[...]

but paradoxically the first is more accurate.


There is no paradox. That's comparing apples with oranges. No offense.

@all: It is sad to see how parts of the community are losing their 
distance to the project and even put a gloss on completely absurd design 
decisions.


For the record, I remember the points made:

* When converting across integral types, any failed coercion yields a 
value essentially unrelated to the source. So we deemed these unacceptable.


* When converting int to float or long to double, there is a loss of 
accuracy - a float can represent all ints, but some of them will be 
represented with approximation. But here there _is_ a notion of "I'm 
okay with an approximation". So we deemed these acceptable.


* When converting double to float, again there is a loss of accuracy and 
also the risk of too large values. But there's never a gross mistake - 
too large values are converted to infinity, and otherwise an 
approximation occurs. This was also deemed acceptable.


Folks with other design sensibilities might choose differently. Actually 
I wasn't on board with this decision, but I accepted it. But deeming it 
absurd is a bit of a stretch.



Andrei

Address problem

[Gheorghe Gabriel via Digitalmars-d-learn]

Hi,
---
interface I { }

I[string] i;

class C : I {
this() {
i["s"] = this;
foreach (_i; i) {
writeln(&_i);
}
foreach (ref _i; i) {
writeln(&_i);
}
}
}

void main() {
C c = new C;
writeln();
}
---
output:
19FDD8
2802028
21FE58
---
I need that I["s"] to have the same address like c.

Named arguments

[Andrey via Digitalmars-d]

Hello, why there are no named arguments for functions like, for 
example, in kotlin i.e.:



int sum(in int a, in int b) {
return a + b;
}

sum(a = 1, b = 2);

Re: Note from a donor

[Ali Çehreli via Digitalmars-d]

On 10/24/2017 09:37 AM, H. S. Teoh wrote:
> On Tue, Oct 24, 2017 at 09:20:10AM -0400, Andrei Alexandrescu via 
Digitalmars-d wrote:

>> A person who donated to the Foundation made a small wish list known.
>> Allow me to relay it:
>>
>> * RSA Digital Signature Validation in Phobos
> [...]
>
> This is going to be a tricky one.  I'm very wary of implementing
> cryptographic algorithms without a crypto expert on board.

deadalnix (Amaury Séchet) is in that field:

  http://dconf.org/2017/talks/sechet.html

Ali

Re: writeln double precision

[Ali Çehreli via Digitalmars-d-learn]

On 10/24/2017 09:59 AM, Arun Chandrasekaran wrote:

>>> On Monday, 23 October 2017 at 18:08:43 UTC, Ali Çehreli wrote:

>>> > The rule is that every expression has a type and 22/7 is int.

> I'm just questioning the reasoning behind why D does it this way and if
> it is for compatibility or if there is any other reasoning behind the
> decision.

I'm not a language designer so I can't be sure but I think it has the 
same reasons that it has in C.


The alternative would not be fit for a system language because we 
wouldn't know what types would be used for certain operations. And types 
are related to performance because they may be operated on different 
sets of CPU registers. In the case of floating point, a CPU need not 
have floating registers at all. So, we don't want types slip from under 
our grasp because the compiler decided to help the programmer. (One may 
think that all common CPUs have FP processing units today but it may not 
be the case in the future. For example, the not-yet-shipping Mill CPU 
can be configured to have zero or more processing units of any kind.)


And we haven't talked about what type 14/7 should be. If we want that to 
be int, then I think we're in bigger trouble. (I think a timing values 
should be shorter than 22/7 and suddenly I get an int in my hand.)


And only after writing that last sentence I realize that perhaps you 
meant this only for literals. If so, having same rules for literals vs. 
variables is beneficial and very important.


There are known problems with C, C++, and D compilers' choosing finer 
precision during compile time for floating point literals during macro 
expansions. For example, calculations end up having different results on 
different compilations.


Languages like Python 3+ can afford all of this because types or 
performance don't play a strong role in that environment. ;)


Ali

Re: My two cents

[Paulo Pinto via Digitalmars-d]

On Tuesday, 24 October 2017 at 16:02:56 UTC, flamencofantasy 
wrote:
On Tuesday, 24 October 2017 at 05:40:06 UTC, Dmitry Olshansky 
wrote:

On Tuesday, 24 October 2017 at 04:26:42 UTC, Adam Wilson wrote:

[...]


I’ll throw in my 2 rubbles.

I actually worked on a VM that has async/await feature 
built-in (Dart language).
It is a plain syntax sugar for Future/Promise explicit 
asynchrony where async automatically return Future[T] or 
Observable[T] (the latter is async stream).


[...]


This is exactly what async/await in C# does.
I saw this idea in Jeffry Richter's Power Threading library 
(https://github.com/Wintellect/PowerThreading) sometime in the 
mid/late 2000, where he used the C# 'yield' keyword to generate 
the state machine code. When async/await was added MSFT either 
took his idea directly or at the very least got inspired by it.


Async/await was based on Midori's project related work.

http://joeduffyblog.com/2015/11/19/asynchronous-everything/

--
Paulo

Re: writeln double precision

[jmh530 via Digitalmars-d-learn]

On Tuesday, 24 October 2017 at 16:18:03 UTC, H. S. Teoh wrote:


I have never seen a programming language in which dividing two 
integers yields a float or double.  Either numbers default to a 
floating point type, in which case you begin with floats in the 
first place, or division is integer division, yielding an 
integer result.



T


Haven't used Python 3+?

Re: writeln double precision

[Arun Chandrasekaran via Digitalmars-d-learn]

On Tuesday, 24 October 2017 at 16:18:03 UTC, H. S. Teoh wrote:
On Tue, Oct 24, 2017 at 10:02:11AM +, Arun Chandrasekaran 
via Digitalmars-d-learn wrote:

On Monday, 23 October 2017 at 18:08:43 UTC, Ali Çehreli wrote:
> On 10/23/2017 07:22 AM, Arun Chandrasekaran wrote:
> > [...]
> The rule is that every expression has a type and 22/7 is int.

Thanks Ali. Is this for backward compatibility with C? 
Because, if there is a division, a natural/mathematical (not 
programmatic) expectation is to see a a double in the result.

[...]

I have never seen a programming language in which dividing two 
integers yields a float or double.  Either numbers default to a 
floating point type, in which case you begin with floats in the 
first place, or division is integer division, yielding an 
integer result.



T


I'm not denying that all the programming languages does it this 
way (even if it is a cause of related bugs).
I'm just questioning the reasoning behind why D does it this way 
and if it is for compatibility or if there is any other reasoning 
behind the decision.


Arun

Re: Note from a donor

[H. S. Teoh via Digitalmars-d]

On Tue, Oct 24, 2017 at 09:20:10AM -0400, Andrei Alexandrescu via Digitalmars-d 
wrote:
> A person who donated to the Foundation made a small wish list known.
> Allow me to relay it:
> 
> * RSA Digital Signature Validation in Phobos
[...]

This is going to be a tricky one.  I'm very wary of implementing
cryptographic algorithms without a crypto expert on board.  It's just
far too easy to get a tiny detail wrong, and open up a gaping security
hole as a result.  Even though we're not talking about encryption per
se, all it takes is for a bug to wrongly validate an invalid signature
and we have a problem.  And even if there are no bugs, there may be
(probably many) inadvertent side-channel attacks opened up if whoever
writes the code is unaware of them.

The other alternative is to wrap around a reputable crypto library like
openssl, but that would mean even more external dependencies of Phobos.
And we all know how well that went with libcurl, zlib, etc.: people
constantly complain about why this doesn't work and why that breaks.  If
we build Phobos with an external dependency on openssl, say, that means
the installer must make sure it finds the right DLL/.so paths, configure
the compiler accordingly, deal with possibly multiple incompatible local
versions of the same library on the user's system, etc..  But if we ship
openssl with Phobos to avoid this problem, then we have another problem:
needing to push out a high-priority security fixes if an exploit is
published, etc., which currently we simply don't have the infrastructure
to deal with.   Neither alternative sounds appealing to me.

(Having said all that, though, D is probably a far better language for
implementing crypto algorithms -- built-in bounds checking would have
prevented some of the worst security holes that have come to light
recently, like Heartbleed and Cloudbleed.  Still, I wouldn't feel
confident about a crypto library written in D unless it was reviewed by
someone with crypto expertise. Or preferably, *multiple* crypto experts.
It's just far, far too easy to get it wrong, with disastrous
consequences.)


T

-- 
A program should be written to model the concepts of the task it performs 
rather than the physical world or a process because this maximizes the 
potential for it to be applied to tasks that are conceptually similar and, more 
important, to tasks that have not yet been conceived. -- Michael B. Allen

Re: writeln double precision

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

On Tue, Oct 24, 2017 at 10:02:11AM +, Arun Chandrasekaran via 
Digitalmars-d-learn wrote:
> On Monday, 23 October 2017 at 18:08:43 UTC, Ali Çehreli wrote:
> > On 10/23/2017 07:22 AM, Arun Chandrasekaran wrote:
> > > [...]
> > The rule is that every expression has a type and 22/7 is int.
> 
> Thanks Ali. Is this for backward compatibility with C? Because, if
> there is a division, a natural/mathematical (not programmatic)
> expectation is to see a a double in the result.
[...]

I have never seen a programming language in which dividing two integers
yields a float or double.  Either numbers default to a floating point
type, in which case you begin with floats in the first place, or
division is integer division, yielding an integer result.


T

-- 
Real Programmers use "cat > a.out".

Re: So why double to float conversion is implicit ?

[Fool via Digitalmars-d]

On Tuesday, 24 October 2017 at 14:28:20 UTC, Basile B. wrote:

float f0 = cos(2 * PI /  1.123548789545545646452154L);
float f1 = cos(cast(float)(2 * PI / 
1.123548789545545646452154L));


[...]

but paradoxically the first is more accurate.


There is no paradox. That's comparing apples with oranges. No 
offense.


@all: It is sad to see how parts of the community are losing 
their distance to the project and even put a gloss on completely 
absurd design decisions.

Re: My two cents

[flamencofantasy via Digitalmars-d]

On Tuesday, 24 October 2017 at 05:40:06 UTC, Dmitry Olshansky 
wrote:

On Tuesday, 24 October 2017 at 04:26:42 UTC, Adam Wilson wrote:

[...]


I’ll throw in my 2 rubbles.

I actually worked on a VM that has async/await feature built-in 
(Dart language).
It is a plain syntax sugar for Future/Promise explicit 
asynchrony where async automatically return Future[T] or 
Observable[T] (the latter is async stream).


[...]


This is exactly what async/await in C# does.
I saw this idea in Jeffry Richter's Power Threading library 
(https://github.com/Wintellect/PowerThreading) sometime in the 
mid/late 2000, where he used the C# 'yield' keyword to generate 
the state machine code. When async/await was added MSFT either 
took his idea directly or at the very least got inspired by it.

Re: So why double to float conversion is implicit ?

[Basile B. via Digitalmars-d]

On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote:
I was working on some sort of math library for use in graphical 
computing and I wrote something like this:


const float PiOver2 = (atan(1.0) * 4) / 2;

Interestingly enough, I realized that atan() returns double (in 
this case) but wait, it's assigned to a float variable! 
Compiler didn't even emit warnings, let alone errors.


I see no reason as to why would this be legal in this century, 
especially in D.

So can someone tell me what's the argument against this?
Why type conversions differ between integral and floating types?
Why can't I assign a long to an int but it's fine when 
assigning double to float?


I think this is a serious topic and needs clarification.


I think that the rationale for allowing that is that you can feed 
the FPU with high precision values to get a better internal 
accuracy (temp values stored in ST0-ST7). At the end, even if 
there's a truncation the result is more accurate that if you 
would have feed the FPU with parameters of the same size as the 
result.

Re: Caching D compiler - preview version

[Dmitry Olshansky via Digitalmars-d-announce]

On Tuesday, 24 October 2017 at 14:17:32 UTC, Dmitry Olshansky 
wrote:

On Tuesday, 24 October 2017 at 13:29:12 UTC, Mike Parker wrote:
On Tuesday, 24 October 2017 at 13:19:15 UTC, Dmitry Olshansky 
wrote:

What is dcache?

It's a patch for dmd that enables a *persistent* 
shared-memory hash-map, protected by a spin-lock from races. 
Dmd processes with -cache flag would detect the following 
pattern:


Blog post or it didn't happen!


Let us at least try it outside of toy examples.

If anybody has std.regex.ctRegex usage I'd be curious to see:

1. Build time w/o -cache=mmap
2. First build time w -cache=mmap
3. Subsequent build times w -cache=mmap

P.S. It's a crude PoC. I think we can do better.


Another caveat: Posix-only for now.

Did a few cleanups and widened the scope a bit.

So here is what happens in my benchmark for std.regex.

-O -inline -release:
88s --> 80s,  memory use ~700Mb -> ~400Mb

-release:
19s -> 12.8s

Experimental std.regex.v2 is sadly broken by a recent change to 
array ops.
It would be very interesting to check as it eats up to 17Gb of 
RAM.

Re: iopipe alpha 0.0.1 version

[Steven Schveighoffer via Digitalmars-d-announce]

On 10/24/17 5:32 AM, Martin Nowak wrote:

On Monday, 23 October 2017 at 16:34:19 UTC, Steven Schveighoffer wrote:

On 10/21/17 6:33 AM, Martin Nowak wrote:

On 10/19/2017 03:12 PM, Steven Schveighoffer wrote:

On 10/19/17 7:13 AM, Martin Nowak wrote:

On 10/13/2017 08:39 PM, Steven Schveighoffer wrote:
It's solving a different problem than iopipe is solving. I plan on 
adding iopipe-on-range capability soon as well, since many times, all 
you have is a range.


You mean chunk based processing vs. infinite lookahead for parsing?
They both provide a similar API, sth. to extend the current window and 
sth. to release data.


Yes, definitely.

The example input here was an input range, but it's read in page sizes 
and could as well be a socket.


iopipe provides "infinite" lookahead, which is central to its purpose. 
The trouble with bolting that on top of ranges, as you said, is that we 
have to copy everything out of the range, which necessarily buffers 
somehow (if it's efficient i/o), so you are double buffering. iopipe's 
purpose is to get rid of this unnecessary buffering. This is why it's a 
great fit for being the *base* of a range.


In other words, if you want something to have optional lookahead and 
range support, it's better to start out with an extendable buffering 
type like an iopipe, and bolt ranges on top, vs. the other way around.


-Steve

Re: LDC 1.5.0-beta1

[kinke via Digitalmars-d-announce]

On Monday, 23 October 2017 at 22:43:15 UTC, Guillaume Piolat 
wrote:
So far my benchmark scripts are Windows-only so no LTO is 
available AFAIK. I can work on providing such measures (or any 
flags you want) on OSX in the future.


I performed an extremely rudimentary -flto=full test on Win64 for 
a hello-world program yesterday, linking manually via LLD 5.0 
(lld-link.exe), which worked (and saved 1 KB for the executable 
;)).

[Issue 17933] New: Warn in case of implicit truncating float conversion

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

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

  Issue ID: 17933
   Summary: Warn in case of implicit truncating float conversion
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

Implicit float conversions (e.g from real to float) may lead to a precision
loss.

--

Re: Advice requested for fixing issue 17914

[Steven Schveighoffer via Digitalmars-d]

On 10/23/17 12:56 PM, Brian Schott wrote:

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

I need to get this issue resolved as soon as possible so that the fix 
makes it into the next compiler release. Because it involves cleanup 
code in a class destructor a design change may be necessary. Who should 
I contact to determine the best way to fix this bug?


A failing use case would help. Fixing a bug when you can't reproduce is 
difficult.


-Steve

Re: So why double to float conversion is implicit ?

[Basile B. via Digitalmars-d]

On Tuesday, 24 October 2017 at 01:22:57 UTC, codephantom wrote:

On Monday, 23 October 2017 at 21:51:24 UTC, Basile B. wrote:

---
/**
 * Wraps a floating point type that doesn't follow D 
permissive float conversion

 * rules.
 *
 * In D, as in C++, implicit conversion from $(D double) to 
$(D float) is allowed,
 * leading to a possible precision loss. This can't happen 
when using this wrapper.

 */


Want to hammer in a nail.. just go ahead and use a bulldozer ;-)

Simple things should be simple.

I cannot see how the simplest solution would be any other than 
to have a compiler option for warning you of implicit 
conversions.


I'm gonna propose the change in a PR. But I already see 
problems...
One may call a trigo function with the highest precision possible 
so that the FP coprocessor get more accurate internally. The 
result, even if converted from real to float is better. This is 
exactly what happens here:


https://github.com/dlang/phobos/pull/5804/files#diff-f127f38af25baf8333b65fa51824b92fR3037

To be clear, w/ the patch a warning is emitted for the first cos:

void main()
{
import std.math;
float f0 = cos(2 * PI /  1.123548789545545646452154L);
float f1 = cos(cast(float)(2 * PI /  
1.123548789545545646452154L));

writefln("%.8g - %.8g", f0, f1);
}

but paradoxically the first is more accurate.

Re: LDC 1.5.0-beta1

[Guillaume Piolat via Digitalmars-d-announce]

On Monday, 23 October 2017 at 22:57:00 UTC, Nicholas Wilson wrote:


would it help to have them grouped/filterable by category?
e.g.
$ldc2 -help-hidden=category


Perhaps, but the sheer amount of customizability makes you wish 
for a superoptimizer for compiler flags (hard to do this 
generically though).