[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #10 from Cy Schubert  ---
Sorry about the absence. Too many projects, this one happened to be pushed down
the stack. I'm looking at this again.

--

[Issue 17851] htonl already defined in phobos64.lib

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17851

--- Comment #1 from Heromyth  ---
It seems these functions have been defined in Ws2_32.lib, see
https://msdn.microsoft.com/en-us/library/windows/desktop/ms738556(v=vs.85).aspx

--

[Issue 17851] New: htonl already defined in phobos64.lib

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17851

  Issue ID: 17851
   Summary: htonl already defined in phobos64.lib
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: bitwo...@qq.com

When building a simple demo for
libevent(https://github.com/D-Programming-Deimos/libevent) on Windows 10 X64, I
got these errors blown:


ws2_32.lib(WS2_32.dll) : error LNK2005: htonl already defined in
phobos64.lib(winsock2_1f3b_225.obj)
ws2_32.lib(WS2_32.dll) : error LNK2005: htons already defined in
phobos64.lib(winsock2_1f3a_22c.obj)
ws2_32.lib(WS2_32.dll) : error LNK2005: ntohl already defined in
phobos64.lib(winsock2_1f3d_225.obj)
ws2_32.lib(WS2_32.dll) : error LNK2005: ntohs already defined in
phobos64.lib(winsock2_1f3c_22c.obj)


I redefined these functions in druntime\src\core\sys\windows\winsock2.d. For
example:

uint htonl(uint x)
{
return bswap(x);
}

is changed to:
   uint htonl(uint x);

After rebuilding the phobos64.lib, I can eliminate these errors.


Here is a test code:

import std.stdio;
import deimos.event2.event; 
import std.socket;

void main()
{  

event_base_loopbreak(null);

InternetAddress addr1 = new InternetAddress("127.0.0.1", 80);
writeln(addr1.port);
writeln(addr1.addr);
}

Compiler: dmd v2.076.0/VC++ 2017
OS: Windows 10 x64

--

[Issue 17850] New: Poor Documentation of the Realtime thread feature

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17850

  Issue ID: 17850
   Summary: Poor Documentation of the Realtime thread feature
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: vorl...@web.de

I've spent far more time than an average C/C++ developer taking a quick glance
at Dlang and then immediately dismissed it as not suitable because it has a gc
and yet I still had trouble finding this feature and even after knowing it
exists it still wasn't easy to find it. Without seeing some ad hoc comments
from Walter Bright on reddit I probably would even know a about the existence
of this feature at all. The other reddit users always suggested a suboptimal
solution to the problem.

The https://dlang.org/spec/garbage.html page drowns you with a wall of text yet
hides the ability to avoid the garbage collector for individual threads. This
is a critical feature for D to compete with C/C++/Rust rather than Java or the
billion other programming languages with a garbage collector. Without it I
didn't even consider using D at all.

"Normally, all threads other than the collector thread must be halted while the
collection is in progress."

Should be clarified by something along the lines of "The stop the world pause
can be mitigated by detaching the thread from the runtime to turn it into a
realtime thread. The thread function of a realtime thread must be marked with
@nogc and it must not hold any GC roots." which is written here
https://wiki.dlang.org/Memory_Management#Real_Time but unless you're looking
for it you won't find it.

I also have a problem with the documentation of the detaching functions.

https://dlang.org/phobos/core_thread.html#.thread_detachThis
"Deregisters the calling thread from use with the runtime. If this routine is
called for a thread which is not registered, the result is undefined."

They do not clarify what detaching the runtime actually does. At the very least
the documentation should mention that detached threads will not be paused by
the garbage collector.

The general description of the thread class should also hint at the possibility
of realtime threads so that it will be more visible even to those who just want
to use regular threads which should include most developers.

https://dlang.org/phobos/core_thread.html#.Thread

Finally I would suggest that someone writes a small blogpost about realtime
threads that illustrates how to use them which hopefully appears at the top of
google search results.

--

[Issue 17848] Example of floating point literals in the documentation is invalid

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17848

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

https://github.com/dlang/dlang.org/commit/90bce087c1671bec00cf1a2d2d2d6bc84ed3cc4e
fix issue 17848 - Example of floating point literals in the documentation is
invalid

'd' is not a valid float suffix. It's not in the grammar, and dmd doesn't
accept it.

https://github.com/dlang/dlang.org/commit/0b2a4a97797c2ec462dfbafa5248e7cc068d0e43
Merge pull request #1897 from aG0aep6G/patch-3

fix issue 17848 - Example of floating point literals in the documenta…
merged-on-behalf-of: Steven Schveighoffer 

--

[Issue 16548] Shadowing a variable not detected when nesting foreach with associative arrays

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16548

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||accepts-invalid, diagnostic
   Hardware|x86_64  |All
 OS|Windows |All

--- Comment #1 from Vladimir Panteleev  ---
Second variable doesn't need to be a foreach variable, either:

/// test.d ///
void main()
{
int x;
int[int] aa;
foreach (k, v; aa)
{
int x;
}
}
//

--

[Issue 17849] Lexical link for align keyword goes to obscure iasm usage

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17849

Steven Schveighoffer  changed:

   What|Removed |Added

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

--- Comment #5 from Steven Schveighoffer  ---
PR was merged.

--

[Issue 17849] Lexical link for align keyword goes to obscure iasm usage

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17849

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #4 from Steven Schveighoffer  ---
PR: https://github.com/dlang/dlang.org/pull/1898

--

[Issue 17849] Lexical link for align keyword goes to obscure iasm usage

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17849

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||schvei...@yahoo.com
   Hardware|x86 |All
 Resolution|INVALID |---
Summary|Documentation of align is   |Lexical link for align
   |incorrect   |keyword goes to obscure
   ||iasm usage
 OS|Linux   |All
   Severity|enhancement |trivial

--- Comment #3 from Steven Schveighoffer  ---
Agreed. There is no reason to link to iasm, as align is much more prevalent as
a normal attribute. It's also telling that zero other keywords link to the iasm
page. Reopening with altered title.

--

[Issue 17849] Documentation of align is incorrect

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17849

--- Comment #2 from Peter Varo  ---
My confusion was coming from the fact, that the 'lexical' page is referencing
the 'iasm' when introducing the 'align' keyword.
(https://github.com/dlang/dlang.org/blob/master/spec/lex.dd#L942)

I think the fact alone, that we have a keyword that can be used in two ways,
yet the documentation fails to connect those two explaining the difference
between these scenarios is confusing, not to mention how hard it is to
follow/understand this for a new comer, who has no idea that D has a "built-in
mini-language" and the official documentation they are following is pointing at
the "lesser used feature"...

So I agree, the bug I reported is invalid, but the above case related to this
one is still something that needs attention IMO.

--

[Issue 17848] Example of floating point literals in the documentation is invalid

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17848

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||pull, spec
 CC||ag0ae...@gmail.com
   Hardware|x86 |All
   Assignee|nob...@puremagic.com|ag0ae...@gmail.com
 OS|Linux   |All
   Severity|enhancement |minor

--- Comment #1 from ag0ae...@gmail.com ---
https://github.com/dlang/dlang.org/pull/1897

--

[Issue 17849] Documentation of align is incorrect

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17849

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |INVALID

--- Comment #1 from ag0ae...@gmail.com ---
The iasm.html page is only about asm blocks. In an asm block, `align 64;` is
correct.

The documentation for the align attribute is here:
https://dlang.org/spec/attribute.html#align

Closing as invalid.

--

[Issue 17849] New: Documentation of align is incorrect

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17849

  Issue ID: 17849
   Summary: Documentation of align is incorrect
   Product: D
   Version: D2
  Hardware: x86
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: he...@petervaro.com

The documentation of the https://dlang.org/spec/iasm.html#align keyword is
incorrect. It is suggesting here:
https://github.com/dlang/dlang.org/blob/master/spec/iasm.dd#L74, that this
should be the correct way of using it:

```
struct S
{
align 64 ubyte b;
}
```

instead of the one, that can actually be compiled:

```
struct S
{
align(64) ubyte b;
}
```

Therefore further action is required:

- If the documented usage is the desired one, then this is a different issue,
and that behaviour needs to be implemented.

- If the keyword requires parenthesis, then the documentation should be updated
according to that.

--

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

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17844

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

https://github.com/dlang/phobos/commit/71adbeee85f4f97d5b3cf93bed28c0f4779e2d23
Fix Issue 17844 - std.process.execute should allow not capturing stderr

https://github.com/dlang/phobos/commit/5b5bc615cdebca8b909e70b0e33cde6ffe594376
Merge pull request #5742 from CyberShadow/pull-20170920-102045

Fix Issue 17844 - std.process.execute should allow not capturing stderr
merged-on-behalf-of: Steven Schveighoffer 

--

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

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17844

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

   What|Removed |Added

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

--

[Issue 17848] New: Example of floating point literals in the documentation is invalid

2017-09-22 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17848

  Issue ID: 17848
   Summary: Example of floating point literals in the
documentation is invalid
   Product: D
   Version: D2
  Hardware: x86
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: he...@petervaro.com

The documentation about the 'Floating Point Literals'
(https://dlang.org/spec/lex.html#floatliteral) is not mentioning any kind of
'd' suffix for float literals, yet in the examples it is showing as both good
and bad ones:

the good: https://github.com/dlang/dlang.org/blob/master/spec/lex.dd#L918
the bad:  https://github.com/dlang/dlang.org/blob/master/spec/lex.dd#L919

So further actions are required:

- If the 'd' suffix should be supported, then it needs further explanation and
at the same time, the compiler should accept it as valid float literal. (Which
I believe is not a valid one, hence currently dmd is complaining about it.)

- If the 'd' suffix is as invalid float literal, then it should be removed from
the examples.

--