[Issue 17747] extern(C) shared static module constructor should be called in betterC programs

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

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

--- Comment #12 from Steven Schveighoffer  ---
(In reply to anonymous4 from comment #11)
> (In reply to Steven Schveighoffer from comment #10)
> > There is also no other precedent where a compiled D program only works
> > properly if you link in the correct order.
> 
> Issue 7063

So that program works properly if you link in a different order?

--

[Issue 11188] std.math.abs fails for shared BigInt type

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

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

--- Comment #11 from anonymous4  ---
I think concurrency support is unreasonable here (and lacks rationale and use
case). How it would work? Create a mutex for every BigInt?

--

[Issue 17747] extern(C) shared static module constructor should be called in betterC programs

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

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

--- Comment #11 from anonymous4  ---
(In reply to Steven Schveighoffer from comment #10)
> There is also no other precedent where a compiled D program only works
> properly if you link in the correct order.

Issue 7063

--

[Issue 17844] std.process.execute should allow not capturing stderr

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

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Vladimir Panteleev  ---
https://github.com/dlang/phobos/pull/5742

--

[Issue 17844] New: std.process.execute should allow not capturing stderr

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

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

  Issue ID: 17844
   Summary: std.process.execute should allow not capturing stderr
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dlang-bugzi...@thecybershadow.net

Currently, std.process.execute returns in its output a mix of the executed
process's stdout and stderr output.

However, capturing stderr is not always desirable. In fact, unless the D
program invoking std.process.execute needs to parse the child process's error
messages, or needs to relay the error output of the child process to the user
(as it would otherwise not be visible), it is not necessary, and potentially
dangerous, as the program might confuse or attempt to parse the program's error
output as its produced output.

Compare this to the common shell pattern of redirecting a program's output to a
file:

$ program > output.txt

In this manner, should the program fail, the command will complete with a
non-zero exit status, and any error messages emitted by the program will be
directly visible to the user.

D's execute behaviour is as follows:

$ program > output.txt 2>&1

This mixes output and error streams. If the invoking program or script is not
careful to check the error code, and attempts to process the program's output
(which now contains error messages mixed in), it can cause such garbage data to
propagate further than desired.

This is especially egregious if the child program writes informational messages
(warnings) to stderr, which do not affect the correctness of the output (on
stdout) or the exit status. In such a case, it becomes impossible to use
std.process.execute correctly. In some circumstances, such messages can be
printed only in some cases (for example, image processing libraries such as gd,
or text encoding conversion libraries such as iconv, will only print warnings
to stderr on malformed data), which may cause bugs in D programs only
discovered in production.

Thus, std.process.execute needs to be changed to allow stderr to be passed to
the invoking D program's stderr, and only capture stdout (probably via a Config
flag).

--

[Issue 17843] -betterC struct with `double` field generates references to TypeInfo

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

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

--- Comment #2 from Walter Bright  ---
For older compilers, a workaround is to add a toHash() dummy member function:

  extern (D) size_t toHash() const nothrow @safe { return 0; }

for the struct with a float/double/real in it.

--

[Issue 17843] -betterC struct with `double` field generates references to TypeInfo

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

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

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7151

--

[Issue 9591] std.typetuple.staticApplyMap

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

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

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

https://github.com/dlang/phobos/commit/f3cec8bdd38529848c5c1bed1f5a2a9817e07203
Fix issue 9591 - Allow Instantiate template to be public, give example
of how Instantiate + ApplyRight can be used to solve the problem.

https://github.com/dlang/phobos/commit/efae08503d9a83d6abdf29270e4c363c393e53de
Merge pull request #5739 from schveiguy/fix9591

Fix issue 9591 - Allow Instantiate template to be public

--

[Issue 17843] New: -betterC struct with `double` field generates references to TypeInfo

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

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

  Issue ID: 17843
   Summary: -betterC struct with `double` field generates
references to TypeInfo
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

Example:

struct S { double d; }

TypeInfo is in druntime, and druntime is not linked in for -betterC.

--

[Issue 17843] -betterC struct with `double` field generates references to TypeInfo

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

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||betterC

--

[Issue 12324] std.uni.Grapheme / byGrapheme can't search for decomposed form

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

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

--- Comment #1 from Dmitry Olshansky  ---
Normalization is the answer here.
Should I do it on grapheme construction? I don't think so.

--

[Issue 16779] VRP for array literals does not work with templated functions taking a static array if the size is inferred

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

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

timon.g...@gmx.ch changed:

   What|Removed |Added

 CC||timon.g...@gmx.ch
   Severity|enhancement |normal

--