Re: Some Observations on the D Development Process

[Nicholas Wilson via Digitalmars-d]

On Sunday, 7 January 2018 at 16:52:55 UTC, Random D user wrote:
While not directly applicable to 'technical debt', has anyone 
ever written a fuzzer for dmd?


Johan Engelen has used LLVM libFuzzer on it.

Re: Release D 2.078.0

[Andre Pany via Digitalmars-d-announce]

On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:

Glad to announce D 2.078.0.

This release comes with runtime detection of Visual Studio 
installation paths, an integral promotion transition for unary 
operations on byte and short sized integers, more -betterC 
features, and a couple of language and library tweaks.


Thanks to everyone involved in this  
https://dlang.org/contributors.html.


http://downloads.dlang.org/releases/2.x/2.078.0/ 
http://dlang.org/changelog/2.078.0.html


- -Martin


What is the purpose of the coverage option "srcpath"?

In my scenario I have a folder "dependencies" and a folder 
"source". I want to generate

code coverage only for the files in folder "source".

dmd -unittest -cov source/app.d dependencies/dep.d
app.exe --DRT-covopt="srcpath:./source dstpath:./cov"

By specifying "srcpath" there are 2 empty files created in folder 
cov:

source-app.lst
dependencies-dep.lst

I thought by specifying "srcpath" I limit the code coverage 
generation to the files located in folder source...


Kind regards
André

Re: Some Observations on the D Development Process

[Dmitry Olshansky via Digitalmars-d]

On Friday, 5 January 2018 at 04:26:25 UTC, Walter Bright wrote:

On 1/4/2018 9:44 AM, Jack Stouffer wrote:
DMD also has at least 30 PRs which have had no action from the 
author in over a year. There's no reason these should be kept 
open; they just take up auto-tester resources and lower the 
signal to noise ratio.


If the author comes back later, they can always ask a 
maintainer to reopen.


I can't agree with the "just close older bugs and PRs." There's 
good stuff in them. Even if the PR is no good, it provides 
insight to someone working on a better fix. Closing it means 
nobody will ever be aware of it or look at it again.


Sure, by surfing through 100-s of stalled PRs among real active 
work.


Somebodies archive currently is a burndown list of others. That 
can’t be good and is highly frustrating.


What I’m saying is that closing PR doesn’t evaporate it. Mark as 
stalled and close.
If someone is on treasure hunting, just click closed PRs and add 
‘stalled’ tag to search.




Relying on the original author to revive it will not work.


Then by definition PR won’t get merged in the first place. It 
takes a fair amount of motivation and busy work by author even 
when all is good.


If we can’t merge it, why keep it around as OPEN?



It's similar with older bugs. They still have discussion on 
them that contributes valuable information and insight to 
anyone wishing to work on it. Closing them with no action means 
the information is all lost.


Piling them in bugzilla has the same downside - actionable items 
are intermingled with some “archived” and largely irrelevant 
non-actionable stuff. Bugzilla is though a lost case, so I will 
not suggest to move anything there.

Re: Dll support: testers needed

[Domain via Digitalmars-d]

On Saturday, 6 January 2018 at 19:32:51 UTC, Benjamin Thaut wrote:
I'm currently back on dll support and I'm applying finishing 
touches to my dll support PR. Now I want to know if I missed 
any corner cases and it would be great if a few more people 
gave the dll support a try.


[...]


I am glad to see this happen. But my use case is not working:
http://forum.dlang.org/post/giywzmvfeuddvmvkr...@forum.dlang.org

[Issue 18040] rdmd --exclude= --include= should allow passing in modules (not just packages)

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

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

Jonathan Marler  changed:

   What|Removed |Added

 CC||johnnymar...@gmail.com

--- Comment #1 from Jonathan Marler  ---
I think this will be fixed with: https://github.com/dlang/tools/pull/271

--

[Issue 18042] rdmd ignores --exclude when -deps is provided

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

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

Jonathan Marler  changed:

   What|Removed |Added

 CC||johnnymar...@gmail.com

--- Comment #1 from Jonathan Marler  ---
Just wanted to make a note that we should retest this bug once this PR is
integrated.

https://github.com/dlang/tools/pull/271

--

[Issue 18079] rdmd does not discover all dependencies

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

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

--- Comment #1 from Jonathan Marler  ---
This bug should be fixed with this PR.

https://github.com/dlang/tools/pull/271

--

Re: [howto] Serve ddox documentation on github.io deployed by Travis CI

[Martin Nowak via Digitalmars-d-announce]

On Monday, 8 January 2018 at 22:06:44 UTC, Bastiaan Veelo wrote:

Cheers,
Bastiaan.

(It turned out as a gist. I don't mind it being recycled on 
wiki's, blog's or elsewhere.)


Using Travis' built-in deployment toGithub Pages is indeed a bit 
simpler.
Also adding the token in Travis' settings page instead in the 
yaml makes things easier.
I've changed my blueprint project accordingly 
https://github.com/MartinNowak/bloom/blob/1e2c2729a2618962e596d68635c5e7e46def2189/.travis.yml.


Maybe worthwile to add this scaffolding to dub or some other 
tool? Anyone volunteering?

Re: Some Observations on the D Development Process

[Mike Franklin via Digitalmars-d]

On Saturday, 6 January 2018 at 02:53:38 UTC, Walter Bright wrote:

For example, there were several uses of the word 'ctor' instead 
of 'constructor'.


I couldn't find any cases like that.  If you know of them, please 
explicitly identify them for me.


Thanks,
Mike

[Issue 18218] New: __traits(isDeprecated, creal) should return true

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

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

  Issue ID: 18218
   Summary: __traits(isDeprecated, creal) should return true
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

--

Re: Rvalue references

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/8/18 6:07 PM, Jiyan wrote:


Sry i know i asked it already in IRC:
Are rvalue references already solved with auto ref?

https://p0nce.github.io/d-idioms/#Rvalue-references:-Understanding-auto-ref-and-then-not-using-it 



Says rvalues are moved!


But an rvalue move is cheaper. You construct it right on the stack where 
it needs to be, and no actual copy is happening. Then inside the 
function, no further indirections are needed, just stack offsets.



The other solution seems not so practical.


The other solution exploits a hole in the "rvalues cannot be references" 
mantra. Because all member functions take 'this' by reference, the 
function call can be used to blur the line between rvalues and lvalues.


It makes for some... interesting things:

struct Int
{
   int value;
   Int opBinary(string op : "+")(ref const Int other) const
   {
   return Int(other.value + value);
   }
}

auto v = Int(5);

auto v2 = s + Int(5); // error
auto v3 = Int(5) + s; // OK!

Is any solution to them intended, or was all the talk about rvalue 
references simply discarded?


auto ref was actually proposed as a non-template solution, but Walter 
implemented it the way it is now. The original proposal would have meant 
that rvalue references like C++ were possible (without conflating it 
with const).


But current auto ref is what we have, so I would recommend using it.

-Steve

Re: Is old style compile-time foreach redundant?

[Seb via Digitalmars-d-learn]

On Tuesday, 9 January 2018 at 23:27:42 UTC, H. S. Teoh wrote:
On Wed, Jan 10, 2018 at 12:18:46AM +0100, Timon Gehr via 
Digitalmars-d-learn wrote:

On 09.01.2018 22:04, H. S. Teoh wrote:
> [...]

I think "if (0 == 3) { static break; }" should be a 
compile-time error.


That's also a possible solution, perhaps a better solution than 
what I described.  Make it so that static break/continue cannot 
be nested inside runtime conditionals.  That should exclude all 
of the pathological cases, hopefully.



T


FWIW I recently bumped into a problem where `static break` would 
be _really_ useful:


https://github.com/dlang/dmd/pull/7577#discussion_r159175229

Re: Dll support: testers needed

[Bastiaan Veelo via Digitalmars-d]

On Tuesday, 9 January 2018 at 20:07:03 UTC, Andre Pany wrote:
On Tuesday, 9 January 2018 at 18:32:24 UTC, Benjamin Thaut 
wrote:
Thanks for your deep analysis. There are several reasons I want 
to have the exe as Delphi application:
1) I faced some minor (Delphi) IDE/Libraries bugs with having 
the Delphi gui within a dll.
2) The Delphi IDE provides you the possibility to e.g. easily 
change the exe icon/attach additional resources to the exe, ...
3) Delphi lets you also create android/iPhone applications. I 
assume there will be no other way than place the D coding 
within a shared object for this scenario.


I wrote a mixed language app with interdependent components (no D 
though). The exe is minimal and does not export anything, its 
main function is practically a one liner that calls into one of 
the DLLs; but it could contain a lot more. First only the export 
library is built for component 1. With it, component 2 is built 
completely, giving a DLL and export lib. Now the DLL for 
component 1 can be built and the exe.


I don’t know if this is possible in your case, but you may be 
able to have a Delphi exe wth the things that must be there but 
no exports, then have a Delphi DLL and D DLL with exports to each 
other.


Not sure if it would make a difference, but this construction 
works well for us.

[Issue 15206] ICE on optimized build, tym = x1d Internal error: backend\cgxmm.c 547

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

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

--- Comment #4 from briancsch...@gmail.com ---
It seems that the problem is in the allocreg function called from loaddata.

I added some debugging printfs before and after calls to `allocreg` and I see
the following:

before: tym = 0x1d, forregs = 0x02, reg =
BP|SI|DI|R10|R12|R15|XMM0|XMM1|XMM3|XMM4|XMM5|XMM6|XMM7|PSW|NOREG|RMload

after: tym = 0x1d, forregs = 0x02, reg = AX|SP

It seems that the `forregs` variable (The `pretregs` parameter to allocreg) is
not getting modified properly. It still has the value 0x2, which matches
the XMMREGS mask even though `allocreg` has correctly removed all the XMM
registers from the list of valid registers in the `reg` variable. Because this
`forregs` variable is not masked out by XMMREGS, there is a call to `xmmload`
even though `xmmload` doesn't support `tym` values of 0x1d.

--

[Issue 13742] undefined reference to __coverage

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

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

Martin Nowak  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #7 from Martin Nowak  ---
https://github.com/dlang/dmd/pull/7654

--

Re: Is old style compile-time foreach redundant?

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

On Wed, Jan 10, 2018 at 12:18:46AM +0100, Timon Gehr via Digitalmars-d-learn 
wrote:
> On 09.01.2018 22:04, H. S. Teoh wrote:
> > if (0 == 3) {}
> > // all subsequent iterations deleted
> > 
> > because the static break is unconditionally compiled (it has nothing
> > to do with the runtime branch).  You'd have to use static if to make
> > it conditionally-compiled and thus not instantly aborting the loop.
> > 
> > Such semantics would be logically consistent, but unfortunately
> > rather counterintuitive at first glance.
> 
> I think "if (0 == 3) { static break; }" should be a compile-time error.

That's also a possible solution, perhaps a better solution than what I
described.  Make it so that static break/continue cannot be nested
inside runtime conditionals.  That should exclude all of the
pathological cases, hopefully.


T

-- 
The diminished 7th chord is the most flexible and fear-instilling chord. Use it 
often, use it unsparingly, to subdue your listeners into submission!

Re: Another take on decimal data types

[Dennis Cote via Digitalmars-d-announce]

On Tuesday, 9 January 2018 at 22:00:13 UTC, rumbu wrote:

Documentation: http://rumbu13.github.io/decimal/doc/package.html


I noticed a minor typo in the documentation:

auto b = decimal32(123456789); //inexact, represented as 
1234568 * x 10^^2


I believe the "*" should be deleted.

This is great documentation!

[Issue 18212] Usage of cfloat,cdouble,cfloat,ifloat,idouble,ireal shouldn't trigger an error in deprecated code

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

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

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

https://github.com/dlang/dmd/commit/028e362d9564a7a4bdb35ac6f8a3e5843587141d
Fix Issue 18212 - Usage of cfloat,cdouble,cfloat,ifloat,idouble,ireal shouldn't
trigger an error in deprecated code

https://github.com/dlang/dmd/commit/254c9634f8498c3d7eb38f37de23b14f1c509e36
Merge pull request #7647 from wilzbach/fix-18212

Fix Issue 18212 - Usage of cfloat,cdouble,cfloat,ifloat,idouble,ireal shouldn't
trigger an error in deprecated code
merged-on-behalf-of: Iain Buclaw 

--

[Issue 18212] Usage of cfloat,cdouble,cfloat,ifloat,idouble,ireal shouldn't trigger an error in deprecated code

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

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

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

   What|Removed |Added

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

--

Re: Is there a way to get this associative array initialization to work?

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

On Tuesday, 9 January 2018 at 23:05:21 UTC, WhatMeWorry wrote:

source\app.d(148,1): Error: not an associative array initializer


The C-style struct initialization in there is a problem. Try 
making it


immutable Sound[string] soundLibrary  =   // line 148
[
"SCRATCH"  : Sound("scratch.wav", 
SoundType.SOUND_EFFECT, null ),
"BACKGROUND_TRACK" : Sound("beat.wav",SoundType.MUSIC,
null ),
"HIGH" : Sound("high.wav",
SoundType.SOUND_EFFECT, null

)
];

using positional values instead of named. Moreover, note that 
such initialization needs to be done in a function, not at global 
scope. you may need to declare it outside then initialize it in a 
static constructor.

Re: Is old style compile-time foreach redundant?

[Timon Gehr via Digitalmars-d-learn]

On 09.01.2018 22:04, H. S. Teoh wrote:

if (0 == 3) {}
// all subsequent iterations deleted

because the static break is unconditionally compiled (it has nothing to
do with the runtime branch).  You'd have to use static if to make it
conditionally-compiled and thus not instantly aborting the loop.

Such semantics would be logically consistent, but unfortunately rather
counterintuitive at first glance.


I think "if (0 == 3) { static break; }" should be a compile-time error.

Re: Is there a way to get this associative array initialization to work?

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/9/18 6:05 PM, WhatMeWorry wrote:

enum SoundType { MUSIC = 0, SOUND_EFFECT };

struct Sound
{
     string file;
     SoundType  musicOrSfx;
     void*  ptr;   // Mix_Chunk* for sfx;  Mix_Music* for music;
}

immutable Sound[string] soundLibrary  =   // line 148
[
     "SCRATCH"  : { file : "scratch.wav", musicOrSfx : 
SOUND_EFFECT, ptr : null },
     "BACKGROUND_TRACK" : { file : "beat.wav",    musicOrSfx : 
MUSIC,    ptr : null },
     "HIGH" : { file : "high.wav",    musicOrSfx : 
SOUND_EFFECT, ptr : null }

];


I keep getting a
source\app.d(148,1): Error: not an associative array initializer




https://issues.dlang.org/buglist.cgi?list_id=218715=not%20an%20associative%20array%20initializer_type=allwordssubstr_format=advanced=---

Note, I think you need at least Sound.SOUND_EFFECT, etc.

This bug looks particularly relevant: 
https://issues.dlang.org/show_bug.cgi?id=11221


I think it should really work.

-Steve

Is there a way to get this associative array initialization to work?

[WhatMeWorry via Digitalmars-d-learn]

enum SoundType { MUSIC = 0, SOUND_EFFECT };

struct Sound
{
string file;
SoundType  musicOrSfx;
void*  ptr;   // Mix_Chunk* for sfx;  Mix_Music* for 
music;

}

immutable Sound[string] soundLibrary  =   // line 148
[
"SCRATCH"  : { file : "scratch.wav", musicOrSfx : 
SOUND_EFFECT, ptr : null },
"BACKGROUND_TRACK" : { file : "beat.wav",musicOrSfx : 
MUSIC,ptr : null },
"HIGH" : { file : "high.wav",musicOrSfx : 
SOUND_EFFECT, ptr : null }	

];  


I keep getting a
source\app.d(148,1): Error: not an associative array initializer

Re: ArithEval v0.5.0 released

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

On Tue, Jan 09, 2018 at 10:32:33PM +, bachmeier via Digitalmars-d-announce 
wrote:
> On Monday, 8 January 2018 at 11:45:25 UTC, rjframe wrote:
> > But don't let anyone peer-pressure you into changing licenses.
> > Figure out your goals and license your code accordingly.
> 
> The main cost of using the GPL is that the anti-GPL zealots will post
> messages telling you to change the license because the GPL is not
> sufficiently pure. I'm old enough to remember when it was FSF members
> that constantly bothered developers to conform to their philosophy.

In the old days, it was the GPL that was considered most pure, and the
other licenses were considered to be "compromising" with the
proprietary.  How the times have changed.


T

-- 
The most powerful one-line C program: #include "/dev/tty" -- IOCCC

Re: ArithEval v0.5.0 released

[bachmeier via Digitalmars-d-announce]

On Monday, 8 January 2018 at 11:45:25 UTC, rjframe wrote:
But don't let anyone peer-pressure you into changing licenses. 
Figure out your goals and license your code accordingly.


The main cost of using the GPL is that the anti-GPL zealots will 
post messages telling you to change the license because the GPL 
is not sufficiently pure. I'm old enough to remember when it was 
FSF members that constantly bothered developers to conform to 
their philosophy.

[Issue 18217] Don't repeatedly call unpredictableSeed to initialize rndGen

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

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

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

https://github.com/dlang/phobos/commit/befc9896d0f699163e6c252771ef3f4234b48f3b
Fix Issue 18217: Don't repeatedly call unpredictableSeed to initialize rndGen

Explanation: https://github.com/dlang/phobos/pull/5788#discussion_r146110307

https://github.com/dlang/phobos/commit/6fe220f6f2cf6d475c881e9105c6821961281789
Merge pull request #6021 from n8sh/rndGen-seeding

Fix Issue 18217: Don't repeatedly call unpredictableSeed to initialize rndGen
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 18217] Don't repeatedly call unpredictableSeed to initialize rndGen

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

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

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

   What|Removed |Added

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

--

Re: Test case available for issue 15206

[Brian Schott via Digitalmars-d]

On Tuesday, 9 January 2018 at 21:59:58 UTC, Ali Çehreli wrote:

On 01/09/2018 01:33 PM, H. S. Teoh wrote:
> On Tue, Jan 09, 2018 at 09:08:11PM +, Brian Schott via
Digitalmars-d wrote:
> This made me smile and cringe at the same time.

I took it as Brian Schott humor right away. :)


I was actually serious, since this is new information about a bug 
that's almost three years old.

Re: Another take on decimal data types

[rumbu via Digitalmars-d-announce]

On Monday, 8 January 2018 at 22:54:06 UTC, rikki cattermole wrote:

Great job.

1) Assembly
2) That file needs to be split up. I can feel the lag as I 
scroll it.


1) I don't understand :)
2) Done.

On Monday, 8 January 2018 at 22:46:27 UTC, Daniel Kozak wrote:
Wow awesome, it would be nice if you could add it as a dub 
package (
http://code.dlang.org/publish) to dub repository 
(http://code.dlang.org)


Done.


Github project: https://github.com/rumbu13/decimal
Documentation: http://rumbu13.github.io/decimal/doc/package.html
Dub package: https://code.dlang.org/packages/decimal

Re: Test case available for issue 15206

[Ali Çehreli via Digitalmars-d]

On 01/09/2018 01:33 PM, H. S. Teoh wrote:
> On Tue, Jan 09, 2018 at 09:08:11PM +, Brian Schott via 
Digitalmars-d wrote:

> [...]
>> I'm posting here so that this doesn't get lost in the bug tracker.
> [...]
>
> This made me smile and cringe at the same time.

I took it as Brian Schott humor right away. :)

Ali

[Issue 15206] ICE on optimized build, tym = x1d Internal error: backend\cgxmm.c 547

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

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

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

   What|Removed |Added

 CC||hst...@quickfur.ath.cx
   Severity|normal  |critical

--- Comment #3 from hst...@quickfur.ath.cx ---
All ICEs should be critical.

--

Re: Test case available for issue 15206

[H. S. Teoh via Digitalmars-d]

On Tue, Jan 09, 2018 at 09:08:11PM +, Brian Schott via Digitalmars-d wrote:
[...]
> I'm posting here so that this doesn't get lost in the bug tracker.
[...]

This made me smile and cringe at the same time.  I thought it was stuff
posted *here* on the forum that get lost and forgotten, buried under
whatever hot discussion is at hand. :-P  Whereas Walter has always
insisted on filing bugs in Bugzilla so that there's a chance it will be
foudn again.


T

-- 
Political correctness: socially-sanctioned hypocrisy.

[Issue 10930] std.array.replace cannot simple replace an element in array

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

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

Seb  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #8 from Seb  ---
PR https://github.com/dlang/phobos/pull/6022

--

Re: ArithEval v0.5.0 released

[Dechcaudron via Digitalmars-d-announce]

On Monday, 8 January 2018 at 11:45:25 UTC, rjframe wrote:
But don't let anyone peer-pressure you into changing licenses. 
Figure out your goals and license your code accordingly.


Your opinion is much appreciated. For this particular project, 
MIT will do just fine.

Re: Is old style compile-time foreach redundant?

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

On Tue, Jan 09, 2018 at 03:26:32PM -0500, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
> On 1/9/18 2:31 PM, H. S. Teoh wrote:
[...]
> > If there were a hypothetical `static continue` or `static break`
> > that's recognized by the static foreach unroller, we could in theory
> > automate this branching in the compiler itself, e.g., by deleting
> > the AST nodes that would be skipped.  Of course, the syntax need not
> > be `static continue`; if there were a way to overload `break LABEL;`
> > for the same purpose, i.e., have the static foreach unroller inspect
> > the label to see if it is referring to the static foreach itself,
> > then this would work.
> > 
> > But I don't know the static foreach implementation enough to be able
> > to tell whether this is actually possible at the time static foreach
> > is processed, or whether there may be some chicken-and-egg problem
> > with inspecting the target of a break/continue before semantic or
> > whatever.
> 
> Yeah, I think in terms of static foreach, it's not a straightforward
> problem. Because the compiler may not know enough information at the
> time to figure out whether it should still keep generating code.
> 
> For example:
> 
> static foreach(i; 0 .. 5)
> {
>if(i == 3) static break;
>static assert(i < 3);
> }
> 
> How does it know whether the static break should be "executed" at
> compile-time if it hasn't evaluated the if-statement? The code would
> have to have no runtime branches to make sure that static break can be
> evaluated at compile-time.
[...]

Static foreach does not (and should not!) evaluate a runtime branch,
because this is before CTFE even happens. CTFE cannot happen until the
static foreach has been fully unrolled, so it doesn't even make sense to
talk about evaluating the if-statement at this point. For your example
to make sense, you'd have to use static if, then the break would be
possible, and non-problematic.

Of course, that still doesn't solve the problem of what static break is
supposed to do from inside a runtime branch. I'm tempted to say that
static break should mean "delete all subsequent nodes from the AST that
follows this node in depth-first traversal order", so your example above
would be transformed into:

if (0 == 3) {}
// all subsequent iterations deleted

because the static break is unconditionally compiled (it has nothing to
do with the runtime branch).  You'd have to use static if to make it
conditionally-compiled and thus not instantly aborting the loop.

Such semantics would be logically consistent, but unfortunately rather
counterintuitive at first glance.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- 
Christopher

Test case available for issue 15206

[Brian Schott via Digitalmars-d]

With some of the changes that are part of release of 2.078.0, 
this old bug can be more easily reproduced. I'm posting here so 
that this doesn't get lost in the bug tracker.


Fortunately I can work around this by disabling optimizations on 
one or two executables, but it would be nice to have this fixed 
soon.


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

[Issue 18215] std.array.replace throws a range violation if the from range is longer than the array

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

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

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

https://github.com/dlang/phobos/commit/7c0dab8d121a34ae73f467cf7aa9be9d306b4fea
Fix Issue 18215 - std.array.replace throws a range violation if the from range
is longer than the array

https://github.com/dlang/phobos/commit/aeb7b9b69e06f280c269721c427f3242e5507562
Merge pull request #6017 from wilzbach/fix-18215

--

Re: Arch Linux ldc package can't use asan

[Johan Engelen via Digitalmars-d]

On Tuesday, 9 January 2018 at 20:43:05 UTC, Wild wrote:

On Tuesday, 9 January 2018 at 18:28:46 UTC, Johan Engelen wrote:

Extra info:
LDC should also recognize the libclang_rt.asan and 
libclang_rt.fuzzer libraries if they are in the same path 
where LDC would try to find the libldc copies. So the symlink 
is not even necessary in that case.


-Johan


On Arch these files are stored in 
"/usr/lib/clang/5.0.1/lib/linux/",

and the archlinux package tool doesn't like symlinks that point
outside of the package. So a patch would be my only choice.

So my solution is:
sed -i "s/libclang_rt/clang\/$_llvmversion\/lib\/linux\/&/g" 
driver/linker-gcc.cpp


Would be nice if a future version of ldc checked this 
directory, or
if it would be possible to send in a constant to gnumake with 
this path.


Yeah, I have this PR that I didn't look at for a while:
https://github.com/ldc-developers/ldc/pull/2345

-Johan

Re: Arch Linux ldc package can't use asan

[Wild via Digitalmars-d]

On Tuesday, 9 January 2018 at 20:43:05 UTC, Wild wrote:
On Arch these files are stored in 
"/usr/lib/clang/5.0.1/lib/linux/",

and the archlinux package tool doesn't like symlinks that point
outside of the package. So a patch would be my only choice.

So my solution is:
sed -i "s/libclang_rt/clang\/$_llvmversion\/lib\/linux\/&/g" 
driver/linker-gcc.cpp


Would be nice if a future version of ldc checked this 
directory, or
if it would be possible to send in a constant to gnumake with 
this path.


The ldc-1:1.7.0-2 is now pushed and -fsanitize=address works,
the -fsanitize=fuzzer option should work when this issue has been
fixed: https://bugs.archlinux.org/task/56023

Re: Arch Linux ldc package can't use asan

[Wild via Digitalmars-d]

On Tuesday, 9 January 2018 at 18:28:46 UTC, Johan Engelen wrote:

Extra info:
LDC should also recognize the libclang_rt.asan and 
libclang_rt.fuzzer libraries if they are in the same path where 
LDC would try to find the libldc copies. So the symlink is not 
even necessary in that case.


-Johan


On Arch these files are stored in 
"/usr/lib/clang/5.0.1/lib/linux/",

and the archlinux package tool doesn't like symlinks that point
outside of the package. So a patch would be my only choice.

So my solution is:
sed -i "s/libclang_rt/clang\/$_llvmversion\/lib\/linux\/&/g" 
driver/linker-gcc.cpp


Would be nice if a future version of ldc checked this directory, 
or
if it would be possible to send in a constant to gnumake with 
this path.

Re: Submit D Machine Learning libraries

[aberba via Digitalmars-d]

On Tuesday, 9 January 2018 at 19:46:00 UTC, aberba wrote:
[1] is a curated list of machine learning libraries for several 
programming languages (no D library in list). I don't know much 
about ML that much to suggest any of those in the Dub registry. 
I know we have Vectorflow from Netflix 
(http://code.dlang.org/packages/vectorflow), D computer Vision 
(https://code.dlang.org/packages/dcv), and all these MIR 
related libs (http://code.dlang.org/search?q=mir)


Please make pull request for D at 
https://github.com/josephmisiti/awesome-machine-learning


[1] https://github.com/josephmisiti/awesome-machine-learning


Might win some people over.


Also http://code.dlang.org/packages/dopt (A numerical 
optimisation and deep learning framework)

Re: Is old style compile-time foreach redundant?

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/9/18 2:31 PM, H. S. Teoh wrote:

On Tue, Jan 09, 2018 at 02:24:11PM -0500, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
[...]

A break or continue is simply a goto underneath. A goto in an unrolled
loop isn't much different than a goto in a um... rolled loop :) It's
just that there are copies of each loop body, and the gotos need
copies of the labels.

So no, it's not "interpreted" by the foreach statement, but the
foreach statement provides the anchors for the goto label targets.


True.


[...]

And then of course, the optimizer weeds out the unreachable
statements.  Doing this with static foreach wouldn't be as pleasant.
You'd have to branch the entire loop body, or use a goto in the case
of a break.

[...]

If there were a hypothetical `static continue` or `static break` that's
recognized by the static foreach unroller, we could in theory automate
this branching in the compiler itself, e.g., by deleting the AST nodes
that would be skipped.  Of course, the syntax need not be `static
continue`; if there were a way to overload `break LABEL;` for the same
purpose, i.e., have the static foreach unroller inspect the label to see
if it is referring to the static foreach itself, then this would work.

But I don't know the static foreach implementation enough to be able to
tell whether this is actually possible at the time static foreach is
processed, or whether there may be some chicken-and-egg problem with
inspecting the target of a break/continue before semantic or whatever.


Yeah, I think in terms of static foreach, it's not a straightforward 
problem. Because the compiler may not know enough information at the 
time to figure out whether it should still keep generating code.


For example:

static foreach(i; 0 .. 5)
{
   if(i == 3) static break;
   static assert(i < 3);
}

How does it know whether the static break should be "executed" at 
compile-time if it hasn't evaluated the if-statement? The code would 
have to have no runtime branches to make sure that static break can be 
evaluated at compile-time.


And this still puts it at a disadvantage when compared to tuple-foreach, 
at least as far as break/continue are concerned.


-Steve

Re: Release D 2.078.0

[Martin Nowak via Digitalmars-d-announce]

On 01/05/2018 03:30 PM, Глеб Куликов/Gleb Kulikov wrote:
> Martin Nowak wrote:
> 
> 
>>
>> Glad to announce D 2.078.0.
> 
> Hello and Happy New Year ! :)
> 
> Unfortunally, linux x86_64 version(*) has problems:

Please file a bug report under https://issues.dlang.org/enter_bug.cgi
and link to it from here.
This is an announce forum, and soon this information is lost.

Please make sure to list necessary information to reproduce this issue
(e.g. cc --version; ld -v; uname -a; cat /etc/redhat-release).
If it works in 2.077.1, it should be filed as regression and the bug
title should start with [2.078].

-Martin

Re: Dll support: testers needed

[Andre Pany via Digitalmars-d]

On Tuesday, 9 January 2018 at 18:32:24 UTC, Benjamin Thaut wrote:

Am 09.01.2018 um 16:03 schrieb Andre Pany:

[...]


First let me say that what you are describing is a very 
uncommon and ill-advised use case. As such there is not going 
to be any nice to use workflow to acieve what you are trying to 
do. Still this doesn't mean that it won't be possible.


Why ill-advised? What you're describing is a cyclic dependency 
between your main executable and your dll written in delphi. If 
you google for "cyclic dependency dll" you will usually get the 
advice to break your cylic dependency by splitting your code 
into more dlls. My personal experience shows the same. Cyclic 
dependencies in dlls are usually not worth the additional 
effort and hassle. Also you want to export things from your 
executable, which is also very uncommon. What you should be 
doing is having 2 dlls and one executable. You have one common 
library written in D that is build into a dll. Then you have 
your delphi library which uses the common.dll. Finally you have 
your main executable written in D which uses both the 
common.dll and your delphi.dll. This should make it possibly to 
break the cycle and get you an easy setup.



If you absolutley must do it the way you describe it, its still 
possible. You will have to compile all modules that export 
something from your executable with the "-c -shared" 
parameters. E.g.
dmd -m64 -c -shared moduleThatExports1.d moduleThatExports2.d 
-ofexports.obj


Now you link the resulting exports.obj file into your 
executable by calling dmd again


dmd -m64 restOfModules.d exports.obj delphi.lib -ofmain.exe

Finally you have to get the handle to your main executable by 
calling


HMODULE handle;
GetModuleHandleExA(0, null, );

in your delphi dll and then fetching the function pointer for 
each and every function you want to call from delphi via:


GetProcAddress(handle, "mangeledFunctionSymbol")

Now finally you can call these functions pointers from delphi 
and they will call into the D code within your executable.



Instead of all that hassle you could instead just have a 
function in your delphi dll:


void recieveFunctionPointer(const(char)* name, void* ptr);

which you call for every function that you want to make 
available from D to delphi. Your delphi code then stores away 
these pointers depending on the name. That way you don't need 
to export anything from your executable and can build it 
normally. Instead of having a function call per function you 
could obviosuly also use a struct that is defined the same way 
in D and delphi and contains all relevant functions pointers.


Thanks for your deep analysis. There are several reasons I want 
to have the exe as Delphi application:
1) I faced some minor (Delphi) IDE/Libraries bugs with having the 
Delphi gui within a dll.
2) The Delphi IDE provides you the possibility to e.g. easily 
change the exe icon/attach additional resources to the exe, ...
3) Delphi lets you also create android/iPhone applications. I 
assume there will be no other way than place the D coding within 
a shared object for this scenario.


I completely agree with you, it is mad. My gut feeling is, you 
have the greatest benefit from the IDE and convenience if the 
executable is written in Delphi.


I try to support both ways in my library, so the developer can 
decide.


Kind regards
Andre

[Issue 18217] New: Don't repeatedly call unpredictableSeed to initialize rndGen

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

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

  Issue ID: 18217
   Summary: Don't repeatedly call unpredictableSeed to initialize
rndGen
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

The offending code in std.random:
```
static if (isSeedable!(Random, typeof(map!((a) =>
unpredictableSeed)(repeat(0)
result.seed(map!((a) => unpredictableSeed)(repeat(0)));
```

Having this code in Phobos leads others to mistakenly copy it since
Phobos is generally a model of good D programming practices.
Calling unpredictableSeed just once would be faster and would give
a better result. See comment for an explanation:

https://github.com/dlang/phobos/pull/5788#discussion_r146110307

--

Submit D Machine Learning libraries

[aberba via Digitalmars-d]

[1] is a curated list of machine learning libraries for several 
programming languages (no D library in list). I don't know much 
about ML that much to suggest any of those in the Dub registry. I 
know we have Vectorflow from Netflix 
(http://code.dlang.org/packages/vectorflow), D computer Vision 
(https://code.dlang.org/packages/dcv), and all these MIR related 
libs (http://code.dlang.org/search?q=mir)


Please make pull request for D at 
https://github.com/josephmisiti/awesome-machine-learning


[1] https://github.com/josephmisiti/awesome-machine-learning


Might win some people over.

Re: Is old style compile-time foreach redundant?

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

On Tue, Jan 09, 2018 at 02:24:11PM -0500, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
[...]
> A break or continue is simply a goto underneath. A goto in an unrolled
> loop isn't much different than a goto in a um... rolled loop :) It's
> just that there are copies of each loop body, and the gotos need
> copies of the labels.
> 
> So no, it's not "interpreted" by the foreach statement, but the
> foreach statement provides the anchors for the goto label targets.

True.


[...]
> And then of course, the optimizer weeds out the unreachable
> statements.  Doing this with static foreach wouldn't be as pleasant.
> You'd have to branch the entire loop body, or use a goto in the case
> of a break.
[...]

If there were a hypothetical `static continue` or `static break` that's
recognized by the static foreach unroller, we could in theory automate
this branching in the compiler itself, e.g., by deleting the AST nodes
that would be skipped.  Of course, the syntax need not be `static
continue`; if there were a way to overload `break LABEL;` for the same
purpose, i.e., have the static foreach unroller inspect the label to see
if it is referring to the static foreach itself, then this would work.

But I don't know the static foreach implementation enough to be able to
tell whether this is actually possible at the time static foreach is
processed, or whether there may be some chicken-and-egg problem with
inspecting the target of a break/continue before semantic or whatever.


T

-- 
Государство делает вид, что платит нам зарплату, а мы делаем вид, что работаем.

Re: Is old style compile-time foreach redundant?

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/9/18 11:35 AM, H. S. Teoh wrote:

On Tue, Jan 09, 2018 at 10:57:03AM -0500, Steven Schveighoffer via 
Digitalmars-d-learn wrote:

I may have been misleading when I made my first comment. What I mean
is that you *can't* break or continue a static foreach, even with
labels. However, you *can* do it to a standard foreach over a tuple.
This may be one reason you want to use a tuple-foreach over a static
foreach.

[...]

Actually, that's wrong too. Tuple-foreach does not interpret
break/continue either. Here's a proof:

alias Seq(A...) = A;
foreach (i; Seq!(0, 1, 2, 3)) {
static if (i==2)
break;
static assert(i < 3); // will fail on the 4th iteration
}

What actually happens is that all iterations are unrolled, then the
unreachable iterations are elided by the optimizer during codegen. The
foreach itself is not affected by break/continue at all.


A break or continue is simply a goto underneath. A goto in an unrolled 
loop isn't much different than a goto in a um... rolled loop :) It's 
just that there are copies of each loop body, and the gotos need copies 
of the labels.


So no, it's not "interpreted" by the foreach statement, but the foreach 
statement provides the anchors for the goto label targets.


e.g.:

int x;

foreach(i; Seq!(0, 1, 2, 3)) {
   x += i;
   static if(i % 2) continue;
   x *= i;
}

=>

int x;
{
   x += 0;
   x *= 0;
}
{
   x += 1;
   goto label1;
   x *= 1;
}
{
label1:
   x += 2;
   x *= 2;
}
{
   x += 3;
   goto label2;
   x *= 3;
}
label2:

And then of course, the optimizer weeds out the unreachable statements. 
Doing this with static foreach wouldn't be as pleasant. You'd have to 
branch the entire loop body, or use a goto in the case of a break.


-Steve

Re: Storing struct in a array

[thedeemon via Digitalmars-d-learn]

On Tuesday, 9 January 2018 at 18:09:58 UTC, Vino wrote:
 It is possible to store struct in a array ans use the same 
in csvReader


Sure, you can just pass the type of your struct to csvReader:



Array!T1 T1s;
reader(fName, T1s); // pass the array Type as a function 
parameter


First you write a template function that takes an array of some 
generic type and fills it with records from CSV file:


void readData(DataType)(string fname, ref Array!DataType arr) {
foreach (record; fname.readText.csvReader!DataType('\t')) {
arr ~= record;
}
}

Then you can use it in your main program with different types:

struct S1 { string name; string value; int other; }
struct S2 { int a; string b; }

void main () {
...
if (someCondition) {
Array!S1 arr1;
readData("data1.csv", arr1);
} else {
Array!S2 arr2;
readData("data2.csv", arr2);
}
}

A little advice. Kindly pause and spend an evening reading this 
book:

http://ddili.org/ders/d.en/

Currently your code pieces look like a soup produced by someone 
who still confuses variables and types, and lacks basic 
programming skills. Read the book, don't rush with writing broken 
code.

Re: Another take on decimal data types

[aberba via Digitalmars-d-announce]

On Tuesday, 9 January 2018 at 10:41:42 UTC, Mike Franklin wrote:

On Monday, 8 January 2018 at 22:16:25 UTC, rumbu wrote:

This is my first D finalized project (+16k loc).

I know that there are other two projects intended to provide a 
decimal data type for D, but I consider mine the most complete 
and most compliant to the standards (at least until now).


Wow!.  So thorough.  Documentation is fantastic.  Very nice 
work, indeed!


Mike


I couldn't say it better. Its really well done...

[Issue 18215] std.array.replace throws a range violation if the from range is longer than the array

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

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

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

https://github.com/dlang/phobos/commit/7c0dab8d121a34ae73f467cf7aa9be9d306b4fea
Fix Issue 18215 - std.array.replace throws a range violation if the from range
is longer than the array

https://github.com/dlang/phobos/commit/aeb7b9b69e06f280c269721c427f3242e5507562
Merge pull request #6017 from wilzbach/fix-18215

Fix Issue 18215 - std.array.replace throws a range violation if the from range
is longer than the array
merged-on-behalf-of: H. S. Teoh 

--

[Issue 18215] std.array.replace throws a range violation if the from range is longer than the array

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

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

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

   What|Removed |Added

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

--

Re: Dll support: testers needed

[Benjamin Thaut via Digitalmars-d]

Am 09.01.2018 um 16:03 schrieb Andre Pany:


I am building a bridge between Delphi and D. At the moment the 
executable is written in D and the Dll (Firemonkey UI) is written in 
Delphi. But I think I want to enable also the other way around. The D 
coding which is then located in the Dll should be able to call Delphi 
methods located in the executable. The whole idea idea is that all logic 
is written in D and you only use the Framework (ui) and libraries Delphi 
provides.


I think this might be a valid use case for a Dll calling functionality 
located in the exe.


Kind regards
Andre


First let me say that what you are describing is a very uncommon and 
ill-advised use case. As such there is not going to be any nice to use 
workflow to acieve what you are trying to do. Still this doesn't mean 
that it won't be possible.


Why ill-advised? What you're describing is a cyclic dependency between 
your main executable and your dll written in delphi. If you google for 
"cyclic dependency dll" you will usually get the advice to break your 
cylic dependency by splitting your code into more dlls. My personal 
experience shows the same. Cyclic dependencies in dlls are usually not 
worth the additional effort and hassle. Also you want to export things 
from your executable, which is also very uncommon. What you should be 
doing is having 2 dlls and one executable. You have one common library 
written in D that is build into a dll. Then you have your delphi library 
which uses the common.dll. Finally you have your main executable written 
in D which uses both the common.dll and your delphi.dll. This should 
make it possibly to break the cycle and get you an easy setup.



If you absolutley must do it the way you describe it, its still 
possible. You will have to compile all modules that export something 
from your executable with the "-c -shared" parameters. E.g.

dmd -m64 -c -shared moduleThatExports1.d moduleThatExports2.d -ofexports.obj

Now you link the resulting exports.obj file into your executable by 
calling dmd again


dmd -m64 restOfModules.d exports.obj delphi.lib -ofmain.exe

Finally you have to get the handle to your main executable by calling

HMODULE handle;
GetModuleHandleExA(0, null, );

in your delphi dll and then fetching the function pointer for each and 
every function you want to call from delphi via:


GetProcAddress(handle, "mangeledFunctionSymbol")

Now finally you can call these functions pointers from delphi and they 
will call into the D code within your executable.



Instead of all that hassle you could instead just have a function in 
your delphi dll:


void recieveFunctionPointer(const(char)* name, void* ptr);

which you call for every function that you want to make available from D 
to delphi. Your delphi code then stores away these pointers depending on 
the name. That way you don't need to export anything from your 
executable and can build it normally. Instead of having a function call 
per function you could obviosuly also use a struct that is defined the 
same way in D and delphi and contains all relevant functions pointers.


--
Kind Regards
Benjamin Thaut

Re: Arch Linux ldc package can't use asan

[Johan Engelen via Digitalmars-d]

On Tuesday, 9 January 2018 at 17:54:11 UTC, kinke wrote:

On Tuesday, 9 January 2018 at 15:27:56 UTC, Wild wrote:

On Tuesday, 9 January 2018 at 15:19:37 UTC, Atila Neves wrote:
I don't know who's the current maintainer of the Arch Linux D 
packages. ldc1.7.0 from the Arch repositories doesn't work 
with -fsanitize=address right now, it fails to link. I 
originally filed an ldc bug here:


I will look into this.

- Dan / The maintainer


Thanks. The official package ships with a renamed copy of the 
LLVM compiler-rt library (matching the LLVM version LDC was 
built with), libldc_rt.asan-x86_64.a. If a copy is out of the 
question, a dependency on the package containing that lib 
(original name: libclang_rt.asan-x86_64.a) and a symlink may do 
the job.
libFuzzer is handled like this as well. See 
https://github.com/ldc-developers/ldc/blob/v1.7.0/CMakeLists.txt#L742-L795.


Extra info:
LDC should also recognize the libclang_rt.asan and 
libclang_rt.fuzzer libraries if they are in the same path where 
LDC would try to find the libldc copies. So the symlink is not 
even necessary in that case.


-Johan

Re: Storing struct in a array

[Vino via Digitalmars-d-learn]

On Tuesday, 9 January 2018 at 17:41:10 UTC, Vino wrote:

On Tuesday, 9 January 2018 at 17:00:05 UTC, thedeemon wrote:

On Tuesday, 9 January 2018 at 13:49:41 UTC, Vino wrote:

Hi All,

 It is possible to store struct in a array ans use the same 
in csvReader


Sure, you can just pass the type of your struct to csvReader:

struct Layout { string name; int value; double other; }

auto readArrayOfStructs(string fname) {
Array!Layout res;
foreach(record; fname.readText.csvReader!Layout('\t')) {
res ~= record;
}
return res;
}


Hi Deemon,

  Thank you, and sorry for the confusion, the requirement is as 
below


auto reader(T) (Array!T T1s, T fname) {
auto uFile = File(fName, "r");
foreach (record; 
uFile.byLineCopy().joiner("\n").csvReader!(Tuple!T1s)) // 
receive the type and fetch the record

writeln(record);
}

void main () {
auto fName = 
"C:\\Users\\bheev1\\Desktop\\Current\\Script\\Others\\Table1.csv";

struct T1 { string Name; string Country; int Age; }
Array!T1 T1s;
reader(fName, T1s); // pass the array Type as a function 
parameter

}


From,
Vino.B


Details

For example let say we have 3 struct
auto read(T) (T Filename, T ArrayType) {
T ArrayType res;
foreach (record; 
Filename.byLineCopy().joiner("\n").csvReader!(T)(Tuple!ArrayType))

foreach(i, T; ColumnTypes) { res[i].insert(record[i]); }
}
return res;
}

void main () {

struct S1 { }
struct S2 { }
struct S3 { }

Get user input(UI)
if(UI == S1) {
Array!S1 T1;
writeln(read(File1, Array Type));
}

From,
Vino.B

Re: Arch Linux ldc package can't use asan

[Wild via Digitalmars-d]

On Tuesday, 9 January 2018 at 17:54:11 UTC, kinke wrote:
Thanks. The official package ships with a renamed copy of the 
LLVM compiler-rt library (matching the LLVM version LDC was 
built with), libldc_rt.asan-x86_64.a. If a copy is out of the 
question, a dependency on the package containing that lib 
(original name: libclang_rt.asan-x86_64.a) and a symlink may do 
the job.
libFuzzer is handled like this as well. See 
https://github.com/ldc-developers/ldc/blob/v1.7.0/CMakeLists.txt#L742-L795.


Thanks! Now I don't need track down what was missing.

Small question, is only *.a needed and not *.so?

- Dan

Re: Arch Linux ldc package can't use asan

[kinke via Digitalmars-d]

On Tuesday, 9 January 2018 at 15:27:56 UTC, Wild wrote:

On Tuesday, 9 January 2018 at 15:19:37 UTC, Atila Neves wrote:
I don't know who's the current maintainer of the Arch Linux D 
packages. ldc1.7.0 from the Arch repositories doesn't work 
with -fsanitize=address right now, it fails to link. I 
originally filed an ldc bug here:


I will look into this.

- Dan / The maintainer


Thanks. The official package ships with a renamed copy of the 
LLVM compiler-rt library (matching the LLVM version LDC was built 
with), libldc_rt.asan-x86_64.a. If a copy is out of the question, 
a dependency on the package containing that lib (original name: 
libclang_rt.asan-x86_64.a) and a symlink may do the job.
libFuzzer is handled like this as well. See 
https://github.com/ldc-developers/ldc/blob/v1.7.0/CMakeLists.txt#L742-L795.

Re: Arch Linux ldc package can't use asan

[Cym13 via Digitalmars-d]

On Tuesday, 9 January 2018 at 15:27:56 UTC, Wild wrote:

On Tuesday, 9 January 2018 at 15:19:37 UTC, Atila Neves wrote:
I don't know who's the current maintainer of the Arch Linux D 
packages. ldc1.7.0 from the Arch repositories doesn't work 
with -fsanitize=address right now, it fails to link. I 
originally filed an ldc bug here:


I will look into this.

- Dan / The maintainer


Grasping the occasion to thank you for your work maintaining it.

Re: Storing struct in a array

[Vino via Digitalmars-d-learn]

On Tuesday, 9 January 2018 at 17:00:05 UTC, thedeemon wrote:

On Tuesday, 9 January 2018 at 13:49:41 UTC, Vino wrote:

Hi All,

 It is possible to store struct in a array ans use the same in 
csvReader


Sure, you can just pass the type of your struct to csvReader:

struct Layout { string name; int value; double other; }

auto readArrayOfStructs(string fname) {
Array!Layout res;
foreach(record; fname.readText.csvReader!Layout('\t')) {
res ~= record;
}
return res;
}


Hi Deemon,

  Thank you, and sorry for the confusion, the requirement is as 
below


auto reader(T) (Array!T T1s, T fname) {
auto uFile = File(fName, "r");
foreach (record; 
uFile.byLineCopy().joiner("\n").csvReader!(Tuple!T1s)) // receive 
the type and fetch the record

writeln(record);
}

void main () {
auto fName = 
"C:\\Users\\bheev1\\Desktop\\Current\\Script\\Others\\Table1.csv";

struct T1 { string Name; string Country; int Age; }
Array!T1 T1s;
reader(fName, T1s); // pass the array Type as a function parameter
}


From,
Vino.B

[Issue 10930] std.array.replace cannot simple replace an element in array

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #7 from Seb  ---
This applied on top of https://github.com/dlang/phobos/pull/6017 will make it
work:

diff --git a/std/array.d b/std/array.d
index 3a44612cb..207b1280d 100644
--- a/std/array.d
+++ b/std/array.d
@@ -2120,21 +2120,21 @@ if (isInputRange!RoR &&
 $(REF map, std,algorithm,iteration) which can act as a lazy replace
  +/
 E[] replace(E, R1, R2)(E[] subject, R1 from, R2 to)
-if (isDynamicArray!(E[]) && isForwardRange!R1 && isForwardRange!R2
-&& (hasLength!R2 || isSomeString!R2))
+if (isDynamicArray!(E[]))
 {
 import std.algorithm.searching : find;
 import std.range : dropOne;

-if (from.empty) return subject;
+static if (isInputRange!R1)
+if (from.empty) return subject;

-auto balance = find(subject, from.save);
+auto balance = find(subject, from);
 if (balance.empty)
 return subject;

 auto app = appender!(E[])();
 app.put(subject[0 .. subject.length - balance.length]);
-app.put(to.save);
+app.put(to);
 // replacing an element in an array is different to a range replacement
 static if (is(Unqual!E : Unqual!R1))
 replaceInto(app, balance.dropOne, from, to);
@@ -2158,6 +2158,11 @@ if (isDynamicArray!(E[]) && isForwardRange!R1 &&
isForwardRange!R2
 assert([3, 3, 4, 3].replace([3, 3], [1, 1, 1]) == [1, 1, 1, 4, 3]);
 }

+@safe unittest
+{
+assert([0, 1, 2].replace(1, 4) == [0, 4, 2]);
+}
+
 // https://issues.dlang.org/show_bug.cgi?id=18215
 @safe unittest
 {
@@ -2181,28 +2186,29 @@ if (isDynamicArray!(E[]) && isForwardRange!R1 &&
isForwardRange!R2

 /// ditto
 void replaceInto(E, Sink, R1, R2)(Sink sink, E[] subject, R1 from, R2 to)
-if (isOutputRange!(Sink, E) && isDynamicArray!(E[])
-&& isForwardRange!R1 && isForwardRange!R2
-&& (hasLength!R2 || isSomeString!R2))
+if (isOutputRange!(Sink, E) && isDynamicArray!(E[]))
 {
 import std.algorithm.searching : find;
 import std.range : dropOne;

-if (from.empty)
+static if (isInputRange!R1)
 {
-sink.put(subject);
-return;
+if (from.empty)
+{
+sink.put(subject);
+return;
+}
 }
 for (;;)
 {
-auto balance = find(subject, from.save);
+auto balance = find(subject, from);
 if (balance.empty)
 {
 sink.put(subject);
 break;
 }
 sink.put(subject[0 .. subject.length - balance.length]);
-sink.put(to.save);
+sink.put(to);
 // replacing an element in an array is different to a range
replacement
 static if (is(Unqual!E : Unqual!R1))
 subject = balance.dropOne;


Of course constraints need be set, but to be fair currently there aren't any
for this

--

Re: Bug in TypeInfo generation?

[H. S. Teoh via Digitalmars-d]

On Tue, Jan 09, 2018 at 06:20:31PM +0100, Benjamin Thaut via Digitalmars-d 
wrote:
> [...] The compiler should be able to figure out that the destructor of
> SomeOtherStruct must already exist, as its clearly always
> instanciated. As a result the compiler should not instanciate the
> TypeInfo for SomeStruct but instead assume that it also already
> exists.  By doing so it would never write the SomeStruct type info to
> the object file and the linker errors would go away.
> 
> I'm asking this because this behavior for type info generation turns
> out to be a problem for my dll-work.
[...]

AFAIK, originally the compiler had a similar behaviour when it comes to
instantiating templates, but some time ago that was changed so that the
relevant symbols were only generated if the module they originate from
is currently being compiled.

I think it will be a very good idea to implement something similar for
this dtor case as well, if not for the entire typeinfo generation
process.  It will help to cut off more unnecessary linker dependencies
and reduce the amount of executable bloat when linking in a library
where not all symbols are actually used.


T

-- 
Turning your clock 15 minutes ahead won't cure lateness---you're just making 
time go faster!

Bug in TypeInfo generation?

[Benjamin Thaut via Digitalmars-d]

Lets say I have a library and it contains the following module:

module a;

struct SomeStruct
{
  string name;
}

struct SomeOtherStruct(T)
{
  ~this()
  {
typeid(T).initializer;
  }
}

struct ThirdStruct
{
  SomeOtherStruct!SomeStruct m;
}

And now I have a second module:

module b;

import a;

int main()
{
  return 0;
}

I would expect that I can compile module .b into an executable like this:

dmd -m64 b.d

As I'm not using anything from module a I would expect that this 
compiles and links just fine. It does not, it gives linker errors:


b.obj : error LNK2001: unresolved external symbol 
"_D1a10SomeStruct9__xtoHashFNbNeKxSQBgQBhZm".
b.obj : error LNK2001: unresolved external symbol 
"_D1a10SomeStruct11__xopEqualsFKxSQBfQBgKxQjZb".


Debugging dmd a bit shows that the typeid expression in the destructor 
of SomeOtherStruct causes the type info of SomeStruct to be created and 
then in the gen object phase the full type info for SomeStruct is 
written into the object file. This is a bug in my eyes though. The 
compiler should be able to figure out that the destructor of 
SomeOtherStruct must already exist, as its clearly always instanciated. 
As a result the compiler should not instanciate the TypeInfo for 
SomeStruct but instead assume that it also already exists. By doing so 
it would never write the SomeStruct type info to the object file and the 
linker errors would go away.


I'm asking this because this behavior for type info generation turns out 
to be a problem for my dll-work.

--
Kind Regards
Benjamin Thaut

Re: Storing struct in a array

[thedeemon via Digitalmars-d-learn]

On Tuesday, 9 January 2018 at 13:49:41 UTC, Vino wrote:

Hi All,

 It is possible to store struct in a array ans use the same in 
csvReader


Sure, you can just pass the type of your struct to csvReader:

struct Layout { string name; int value; double other; }

auto readArrayOfStructs(string fname) {
Array!Layout res;
foreach(record; fname.readText.csvReader!Layout('\t')) {
res ~= record;
}
return res;
}

Re: Is old style compile-time foreach redundant?

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

On Tue, Jan 09, 2018 at 10:57:03AM -0500, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
> On 1/8/18 9:27 AM, H. S. Teoh wrote:
> > On Sun, Jan 07, 2018 at 10:39:19PM -0500, Steven Schveighoffer via 
> > Digitalmars-d-learn wrote:
> > > On 1/6/18 6:25 PM, Ali Çehreli wrote:
> > > > Is 'static foreach' sufficient for all needs or is there any
> > > > value for regular foreach over compile-time sequences?
> > > 
> > > If you use continues or breaks, then you need to switch to gotos
> > > if using static foreach, as it does not support them directly.
> > [...]
> > 
> > Are you sure?  I was under te impression that it does support
> > continues and breaks -- but only if they are labelled, because of a
> > syntactic ambiguity otherwise.
> 
> I thought it only worked for constructs outside the static foreach
> (like switch).
> 
> testing...
> 
> Nope, doesn't work.

Grrr... I thought it did, but you're right, attempting to break the
static foreach with a label gets this compile error:

-
test.d(7): Error: enclosing label FE for break not found
-


> The ambiguity is that if you have a breakable or continuable construct
> outside a static foreach (e.g. switch), then you may believe that the
> break statement is affecting the foreach (in fact, that is how
> tuple-foreach works), but you are actually affecting the outer
> construct.

Yes, that's the ambiguity I was referring to. :-)


> The extra requirement is to help you realize the implication. It may
> be removed in the future.

I vaguely remember Timon mentioning something about implementing static
break / static continue, and somehow I thought the labelled break /
labelled continue was supposed to be it. Or at least, they are stand-ins
until static break/continue are implemented.  Is that no longer on the
table?


> I may have been misleading when I made my first comment. What I mean
> is that you *can't* break or continue a static foreach, even with
> labels. However, you *can* do it to a standard foreach over a tuple.
> This may be one reason you want to use a tuple-foreach over a static
> foreach.
[...]

Actually, that's wrong too. Tuple-foreach does not interpret
break/continue either. Here's a proof:

alias Seq(A...) = A;
foreach (i; Seq!(0, 1, 2, 3)) {
static if (i==2)
break;
static assert(i < 3); // will fail on the 4th iteration
}

What actually happens is that all iterations are unrolled, then the
unreachable iterations are elided by the optimizer during codegen. The
foreach itself is not affected by break/continue at all.


T

-- 
Дерево держится корнями, а человек - друзьями.

Re: Is old style compile-time foreach redundant?

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/8/18 9:27 AM, H. S. Teoh wrote:

On Sun, Jan 07, 2018 at 10:39:19PM -0500, Steven Schveighoffer via 
Digitalmars-d-learn wrote:

On 1/6/18 6:25 PM, Ali Çehreli wrote:

Is 'static foreach' sufficient for all needs or is there any value
for regular foreach over compile-time sequences?


If you use continues or breaks, then you need to switch to gotos if
using static foreach, as it does not support them directly.

[...]

Are you sure?  I was under te impression that it does support continues
and breaks -- but only if they are labelled, because of a syntactic
ambiguity otherwise.


I thought it only worked for constructs outside the static foreach (like 
switch).


testing...

Nope, doesn't work. The ambiguity is that if you have a breakable or 
continuable construct outside a static foreach (e.g. switch), then you 
may believe that the break statement is affecting the foreach (in fact, 
that is how tuple-foreach works), but you are actually affecting the 
outer construct. The extra requirement is to help you realize the 
implication. It may be removed in the future.


I may have been misleading when I made my first comment. What I mean is 
that you *can't* break or continue a static foreach, even with labels. 
However, you *can* do it to a standard foreach over a tuple. This may be 
one reason you want to use a tuple-foreach over a static foreach.


-Steve

Re: Is old style compile-time foreach redundant?

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/8/18 3:07 PM, Jonathan M Davis wrote:

But regardless, labeled break definitely works within a static foreach, and
I expect that a labeled continue does as well, but I haven't tried it.


I didn't mean it that way, see my reply to H.

-Steve

Re: Arch Linux ldc package can't use asan

[Wild via Digitalmars-d]

On Tuesday, 9 January 2018 at 15:19:37 UTC, Atila Neves wrote:
I don't know who's the current maintainer of the Arch Linux D 
packages. ldc1.7.0 from the Arch repositories doesn't work with 
-fsanitize=address right now, it fails to link. I originally 
filed an ldc bug here:


I will look into this.

- Dan / The maintainer

Re: Storing struct in a array

[Vino via Digitalmars-d-learn]

On Tuesday, 9 January 2018 at 13:49:41 UTC, Vino wrote:

Hi All,

 It is possible to store struct in a array ans use the same in 
csvReader e.g.


import std.stdio;
import std.container.array;

void main () {
Array!string a;
struct Layout { string name; int value; double other; }

a.insert(Layout);
auto record =  
uFile.byLineCopy().joiner("\n").csvReader!(Tuple!a[0]))

foreach (record; records)
{
writeln(record.name);
writeln(record.value);
writeln(record.other);
}

From,
Vino.B


Hi All,

 Was able to find on hot to store a struct in an array, but not 
able to use that array in csvReader


Program:
import std.algorithm: joiner;
import std.container.array;
import std.csv: csvReader;
import std.stdio: File, writeln;
import std.typecons: Tuple, tuple;

void main () {
auto fName = 
"C:\\Users\\bheev1\\Desktop\\Current\\Script\\Others\\Table1.csv";

auto uFile = File(fName, "r");
struct T1 { string Name; string Country; int Age; }
Array!T1 T1s;
foreach (record; 
uFile.byLineCopy().joiner("\n").csvReader!(Tuple!T1s))

writeln(record);
}

Error:
C:\D\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(523): 
Error: template instance parseSpecs!(T1s) cannot use local 'T1s' 
as parameter to non-global template

 parseSpecs(Specs...)
C:\D\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(635): 
Error: CTFE failed because of previous errors in injectNamedFields
ArrayStruct.d(12): Error: template instance 
ArrayStruct.main.Tuple!(T1s) error instantiating

Failed: ["dmd", "-v", "-o-", "ArrayStruct.d", "-I."]

From,
Vino.B

Arch Linux ldc package can't use asan

[Atila Neves via Digitalmars-d]

I don't know who's the current maintainer of the Arch Linux D 
packages. ldc1.7.0 from the Arch repositories doesn't work with 
-fsanitize=address right now, it fails to link. I originally 
filed an ldc bug here:


https://github.com/ldc-developers/ldc/issues/2488

But it turns out that the pre-built version from dlang.org works 
fine, so I opened an Arch bug here:


https://bugs.archlinux.org/task/57026

Atila

Re: Dll support: testers needed

[Andre Pany via Digitalmars-d]

On Tuesday, 9 January 2018 at 14:43:43 UTC, Benjamin Thaut wrote:

Am 09.01.2018 um 12:02 schrieb MrSmith:
Is it possible to put common code in exe, and use that code 
from dlls? Or anything can be exported only by dll?


You can only export from dlls. I don't know of any use case 
where exporting from a executable would make sense. No, you 
can't put common code into a executable and use that code from 
dlls. Thats not how dlls are designed to work on windows.


If you absoutely still want to export from an executable you 
can still use -L/EXPORT:"mangledSymbolName"




Is it possible to have circular dependencies between dlls?


No. You will get linker errors. Same as in C/C++.



Tips for doing dlls with dub?

Well, first my PR will have to get merged. Then you'll have to 
wait until a release exists that actually has my changes and 
then maybe there is support added in dub. Before that I think 
trying to use dub to create dlls is wasted effort.


I am building a bridge between Delphi and D. At the moment the 
executable is written in D and the Dll (Firemonkey UI) is written 
in Delphi. But I think I want to enable also the other way 
around. The D coding which is then located in the Dll should be 
able to call Delphi methods located in the executable. The whole 
idea idea is that all logic is written in D and you only use the 
Framework (ui) and libraries Delphi provides.


I think this might be a valid use case for a Dll calling 
functionality located in the exe.


Kind regards
Andre

Re: Dll support: testers needed

[Benjamin Thaut via Digitalmars-d]

Am 09.01.2018 um 12:02 schrieb MrSmith:
Is it possible to put common code in exe, and use that code from dlls? 
Or anything can be exported only by dll?


You can only export from dlls. I don't know of any use case where 
exporting from a executable would make sense. No, you can't put common 
code into a executable and use that code from dlls. Thats not how dlls 
are designed to work on windows.


If you absoutely still want to export from an executable you can still 
use -L/EXPORT:"mangledSymbolName"




Is it possible to have circular dependencies between dlls?


No. You will get linker errors. Same as in C/C++.



Tips for doing dlls with dub?

Well, first my PR will have to get merged. Then you'll have to wait 
until a release exists that actually has my changes and then maybe there 
is support added in dub. Before that I think trying to use dub to create 
dlls is wasted effort.


--
Kind Regards
Benjamin Thaut

Re: Creating Struct for an output of a program.

[Vino via Digitalmars-d-learn]

On Tuesday, 9 January 2018 at 12:50:04 UTC, Mengu wrote:

On Tuesday, 9 January 2018 at 07:57:19 UTC, Vino wrote:

[...]


if S2 consists of data for Layout struct, then you can simply 
do:


auto S2 = S1.map!(a => Layout(a[0], a[1], a[2]));

which will give you a range of Layout.


Hi,

 We want the Layout struct to be created from the output of S1, 
in the above the Layout is a example of the struct structure that 
we needed.


From,
Vino.B

[Issue 18209] std.uni.byGrapheme is not usable in CTFE

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

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

--- Comment #3 from Jack Stouffer  ---
(In reply to Jack Stouffer from comment #2)
> Apparently this isn't possible.
> 
> There are two ways of fixing this
> 
> 1. remove the small string optimization from Grapheme
> 2. have byGrapheme return a specialized type of Grapheme that doesn't have
> SSO

Or

3. Create a special function byGraphemeCTFE which is a range of CTFEGraphemes.
That way there's no performance regression

--

[Issue 18209] std.uni.byGrapheme is not usable in CTFE

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

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

--- Comment #2 from Jack Stouffer  ---
(In reply to Jack Stouffer from comment #1)
> Pretty sure there's a way to change a struct's layout if it's being used in
> compile time. All that needs to be done is just bring the fields out of the
> union when used in CTFE.

Apparently this isn't possible.

There are two ways of fixing this

1. remove the small string optimization from Grapheme
2. have byGrapheme return a specialized type of Grapheme that doesn't have SSO

--

Storing struct in a array

[Vino via Digitalmars-d-learn]

Hi All,

 It is possible to store struct in a array ans use the same in 
csvReader e.g.


import std.stdio;
import std.container.array;

void main () {
Array!string a;
struct Layout { string name; int value; double other; }

a.insert(Layout);
auto record =  
uFile.byLineCopy().joiner("\n").csvReader!(Tuple!a[0]))

foreach (record; records)
{
writeln(record.name);
writeln(record.value);
writeln(record.other);
}

From,
Vino.B

Re: Creating Struct for an output of a program.

[Mengu via Digitalmars-d-learn]

On Tuesday, 9 January 2018 at 07:57:19 UTC, Vino wrote:

Hi All,

 Request your help on how to create a struct with the output of 
the below program.


Program:
import std.algorithm: all, map, filter;
import std.stdio: File, writeln;
import std.typecons: Tuple, tuple;
import std.container.array;
import std.string: split, strip;
import std.uni: isWhite, toLower;
import std.range: chunks;

void main () {
Array!string TableData, StructureData;
auto Meta = 
File("C:\\Users\\bheev1\\Desktop\\Current\\Script\\Others\\meta\\meta.txt", "r");

auto MetaData = Array!(Tuple!(string, string))(Meta.byLineCopy()
.filter!(line => !line.all!isWhite)
.map!(a => a.split(":"))
.map!(a => tuple(a[0].toLower.strip, a[1].toLower.strip)));
foreach (line; MetaData[]) { TableData.insertBack(line[0]); 
StructureData.insertBack(line[1]); }

for(int i = 0; i < TableData[].length; i++ ) {
auto S1 = StructureData[i].split(",").chunks(3);
auto S2 = S1.map!(a => tuple(a[0],a[1],a[2]));
for(int z =0; z < S2.length; z++)
{ writefln("%-8s %;s", S2[z][1] , S2[z][0]); }
}
}

Output:
string name;
string country;
int age;


Need to create as struct using the output

struct Layout {
{
string name;
string country;
int age;

}

From,
Vino.B


if S2 consists of data for Layout struct, then you can simply do:

auto S2 = S1.map!(a => Layout(a[0], a[1], a[2]));

which will give you a range of Layout.

[Issue 7054] format() aligns using code units instead of graphemes

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

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

Basile B.  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #14 from Basile B.  ---
pull: https://github.com/dlang/phobos/pull/6008

--

[Issue 7054] format() aligns using code units instead of graphemes

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

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

Basile B.  changed:

   What|Removed |Added

 CC||b2.t...@gmx.com
Summary|std.format.formattedWrite   |format() aligns using code
   |uses code units count as|units instead of graphemes
   |width instead of characters |
   |count   |

--

[Issue 18205] Format string with width specification doesn't work with multibyte characters

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

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

Basile B.  changed:

   What|Removed |Added

 Depends on|18209   |


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18209
[Issue 18209] std.uni.byGrapheme is not usable in CTFE
--

[Issue 18209] std.uni.byGrapheme is not usable in CTFE

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

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

Basile B.  changed:

   What|Removed |Added

 Blocks|18205   |


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18205
[Issue 18205] Format string with width specification doesn't work with
multibyte characters
--

Re: Release D 2.078.0

[Andre Pany via Digitalmars-d-announce]

On Monday, 8 January 2018 at 22:41:31 UTC, Rainer Schuetze wrote:


Unfortunately the corresponding installer PRs didn't make it 
into the release, so you still have to remove most options of 
section Environment64 from sc.ini yourself. This should be 
enough


[Environment64]
LIB=%@P%\..\lib64
DFLAGS=%DFLAGS% -L/OPT:NOICF

When using the 7z dmd file, the most harmful setting is 
LINKCMD, that doesn't work for VS2017.


Thanks a lot for the information. My use case is a XMake build 
plugin (Python) for D which currently only supports X86 COFF. 
Adapting the sc.ini from Python is only working with ugly 
workarounds as duplicate keys in sc.ini is not really allowed. I 
will wait until the corresponding pull request is merged. Does it 
make sense to open an issue or will it be anyway available in 
next relase?


Kind regards
André

Re: Dll support: testers needed

[MrSmith via Digitalmars-d]

Is it possible to put common code in exe, and use that code from 
dlls? Or anything can be exported only by dll?


Is it possible to have circular dependencies between dlls?

Tips for doing dlls with dub?

Re: Another take on decimal data types

[Mike Franklin via Digitalmars-d-announce]

On Monday, 8 January 2018 at 22:16:25 UTC, rumbu wrote:

This is my first D finalized project (+16k loc).

I know that there are other two projects intended to provide a 
decimal data type for D, but I consider mine the most complete 
and most compliant to the standards (at least until now).


Wow!.  So thorough.  Documentation is fantastic.  Very nice work, 
indeed!


Mike

Re: Another take on decimal data types

[Bastiaan Veelo via Digitalmars-d-announce]

On Monday, 8 January 2018 at 22:16:25 UTC, rumbu wrote:

Documentation: http://rumbu13.github.io/decimal/doc/decimal.html


Wow, slick documentation!

Re: Help optimizing UnCompress for gzipped files

[Christian Köstlin via Digitalmars-d-learn]

On 07.01.18 14:44, Steven Schveighoffer wrote:
> Not from what I'm reading, the C solution is about the same (257 vs.
> 261). Not sure if you have averaged these numbers, especially on a real
> computer that might be doing other things.
yes you are right ... for proper benchmarking proper statistics should
be in place, taking out extreme values, averaging them, ...

> Note: I would expect it to be a tiny bit faster, but not monumentally
> faster. From my testing with the reallocation, it only reallocates a
> large quantity of data once.
> 
> However, the D solution should be much faster. Part of the issue is that
> you still aren't low-level enough :)
> 
> Instead of allocating the ubyte array with this line:
> 
> ubyte[] buffer = new ubyte[200*1024*1024];
> 
> Try this instead:
> 
> // from std.array
> auto buffer = uninitializedArray!(ubyte[], 200*1024*1024);
thanks for that ... i just did not know how to get an uninitialized
array. i was aware, that dlang is nice and puts init there :)

> Yes! I am working on doing just that, but haven't had a chance to update
> the toy project I wrote: https://github.com/schveiguy/jsoniopipe
> 
> I was planning actually on having an iopipe of JsonItem, which would
> work just like a normal buffer, but reference the ubyte buffer underneath.
> 
> Eventually, the final product should have a range of JsonValue, which
> you would recurse into in order to parse its children. All of it will be
> lazy, and stream-based, so you don't have to load the whole file if it's
> huge.
> 
> Note, you can't have an iopipe of JsonValue, because it's a recursive
> format. JsonItems are just individual defined tokens, so they can be
> linear.
sounds really good. i played around with
https://github.com/mleise/fast/blob/master/source/fast/json.d ... thats
an interesting pull parser with the wrong licence unfortunately ... i
wonder if something like this could be done on top of iopipe instead of
a "real" buffer.

---
Christian Köstlin

Re: Dll support: testers needed

[Dylan Graham via Digitalmars-d]

On Tuesday, 9 January 2018 at 08:10:56 UTC, Benjamin Thaut wrote:

Am 09.01.2018 um 05:19 schrieb Dylan Graham:
It's pretty basic but I'm glad it works. I'll try doing 
something more advanced.


Hi Dylan,

I'm glad that it works for you. I'm curios though, why are you 
using an import library for your plugin? Normally plugins are 
build without and import library (the -L/IMPLIB parameter) and 
then loaded dynamically through LoadLibrary by your main 
executable.


In all honesty, I'm not sure. I saw the instructions on your 
website and just adapted it.


Also, please excuse me, I'm fairly new to compiling native 
programs. I've been using DUB this entire time.


With the common library (plugin base) DLL don't I need to 
generate a .lib for plugin implementations to compile/link 
against?


This way you can add/remove plugins without the need to 
recompile your main executable. Usually such plugin systems are 
done like this:


You have some common library that defines shared functionality 
and the base interfaces such as a Plugin base class or Plugin 
interface. This common library is build into a dll with import 
library.


You have one ore multiple plugins that link against the common 
library and implement the plugin interface / plugin base class. 
Each of these plugins provides a function "getPluginImpl" or 
something along the lines which can be used to get an instance 
of the Plugin implementation.


Check. I'm doing that.

You have the main executable, which links against the common 
library. It dynamically loads the plugin.dlls and calls the 
getPluginImpl method on them to retrieve the implementation. No 
import library involved here.


I'm doing that but the getPluginImpl call is done in the common 
library. The executable is only a bootstrap.


What your doing is also a valid use case. It is usually done 
when link times get to long or if you want to have clean 
interface between the different subsystems in your application. 
Your codebase is usually split into multiple dlls each with a 
import library which are then all used by the main executable.


I am doing that. I don't need to recompile anything. I can add as 
many plugin implementations without recompiling the common 
library/executable.

Re: Dll support: testers needed

[Benjamin Thaut via Digitalmars-d]

Am 09.01.2018 um 05:19 schrieb Dylan Graham:
It's pretty basic but I'm glad it works. I'll try doing something more 
advanced.


Hi Dylan,

I'm glad that it works for you. I'm curios though, why are you using an 
import library for your plugin? Normally plugins are build without and 
import library (the -L/IMPLIB parameter) and then loaded dynamically 
through LoadLibrary by your main executable. This way you can add/remove 
plugins without the need to recompile your main executable. Usually such 
plugin systems are done like this:


You have some common library that defines shared functionality and the 
base interfaces such as a Plugin base class or Plugin interface. This 
common library is build into a dll with import library.


You have one ore multiple plugins that link against the common library 
and implement the plugin interface / plugin base class. Each of these 
plugins provides a function "getPluginImpl" or something along the lines 
which can be used to get an instance of the Plugin implementation.


You have the main executable, which links against the common library. It 
dynamically loads the plugin.dlls and calls the getPluginImpl method on 
them to retrieve the implementation. No import library involved here.


What your doing is also a valid use case. It is usually done when link 
times get to long or if you want to have clean interface between the 
different subsystems in your application. Your codebase is usually split 
into multiple dlls each with a import library which are then all used by 
the main executable.


--
Kind Regards
Benjamin Thaut

Creating Struct for an output of a program.

[Vino via Digitalmars-d-learn]

Hi All,

 Request your help on how to create a struct with the output of 
the below program.


Program:
import std.algorithm: all, map, filter;
import std.stdio: File, writeln;
import std.typecons: Tuple, tuple;
import std.container.array;
import std.string: split, strip;
import std.uni: isWhite, toLower;
import std.range: chunks;

void main () {
Array!string TableData, StructureData;
auto Meta = 
File("C:\\Users\\bheev1\\Desktop\\Current\\Script\\Others\\meta\\meta.txt", "r");

auto MetaData = Array!(Tuple!(string, string))(Meta.byLineCopy()
.filter!(line => !line.all!isWhite)
.map!(a => a.split(":"))
.map!(a => tuple(a[0].toLower.strip, a[1].toLower.strip)));
foreach (line; MetaData[]) { TableData.insertBack(line[0]); 
StructureData.insertBack(line[1]); }

for(int i = 0; i < TableData[].length; i++ ) {
auto S1 = StructureData[i].split(",").chunks(3);
auto S2 = S1.map!(a => tuple(a[0],a[1],a[2]));
for(int z =0; z < S2.length; z++)
{ writefln("%-8s %;s", S2[z][1] , S2[z][0]); }
}
}

Output:
string name;
string country;
int age;


Need to create as struct using the output

struct Layout {
{
string name;
string country;
int age;

}

From,
Vino.B