[Issue 17479] Public constructor for std.process.Pid
https://issues.dlang.org/show_bug.cgi?id=17479 Chris Wright changed: What|Removed |Added Priority|P1 |P3 --
[Issue 17479] New: Public constructor for std.process.Pid
https://issues.dlang.org/show_bug.cgi?id=17479 Issue ID: 17479 Summary: Public constructor for std.process.Pid Product: D Version: D2 Hardware: x86_64 OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: dhase...@gmail.com I am trying to create a program that handles two types of processes: * Scripts and executables that it runs directly * Daemons that fork and exit, with a pid file containing the pid of the lingering daemon process I want to handle them in the same fashion. It would be convenient to use std.process to do so. I can easily parse an integer from a pid file, but in order to construct a std.process.Pid from that, I need to resort to tupleof hacks and manually constructing class instances. It would be better if std.process.Pid exposed its constructors publicly. For now, I'm using core.sys.posix directly. If I wanted to support Windows, though, I'd have to copy std.process into my project and make the relevant constructors public to handle things in a reasonable fashion. --
[Issue 17478] New: Socket.select return a write status change, but no connection is established.
https://issues.dlang.org/show_bug.cgi?id=17478
Issue ID: 17478
Summary: Socket.select return a write status change, but no
connection is established.
Product: D
Version: D2
Hardware: x86_64
OS: Other
Status: NEW
Severity: critical
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: encounterspr...@gmail.com
OS : debian 8
code below:
import std.socket;
import std.stdio;
import std.conv;
bool connect(string host , ushort port , int seconds)
{
import std.stdio;
string strPort = to!string(port);
AddressInfo[] arr = getAddressInfo(host , strPort ,
AddressInfoFlags.CANONNAME);
if(arr.length == 0)
{
writeln("getAddressInfo error");
return false;
}
Socket socket = new Socket(arr[0].family , arr[0].type , arr[0].protocol);
socket.blocking(false);
socket.connect(arr[0].address);
SocketSet writesets = new SocketSet();
writesets.reset();
writesets.add(socket);
TimeVal val;
val.seconds = seconds ;
val.microseconds = 0;
int ret = Socket.select(null ,writesets , null , &val);
if(ret < 0)
{
writeln("some error or interput");
return false;
}
else if(ret == 0)
{
writeln("timeout");
return false;
}
else
{
if(writesets.isSet(socket))
{
writeln("connected");
return true;
}
return false;
}
}
void main()
{
//1234 not listen in my OS. but socket.select show me connected.
connect("127.0.0.1" , 1234 ,3);
}
--
[Issue 15692] Allow struct member initializer everywhere
https://issues.dlang.org/show_bug.cgi?id=15692 greensunn...@gmail.com changed: What|Removed |Added CC||greensunn...@gmail.com --- Comment #4 from greensunn...@gmail.com --- I just revived a DIP that deals with this topic: https://github.com/dlang/DIPs/pull/71 Help to polish it is welcome ;-) --
[Issue 17477] DMD error message for delegate with wrong attributes is very confusing
https://issues.dlang.org/show_bug.cgi?id=17477 Eyal changed: What|Removed |Added Keywords||diagnostic --
[Issue 17477] New: DMD error message for delegate with wrong attributes is very confusing
https://issues.dlang.org/show_bug.cgi?id=17477
Issue ID: 17477
Summary: DMD error message for delegate with wrong attributes
is very confusing
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: e...@weka.io
When compiling this invalid program:
void f(void delegate(int) nothrow dlg) {}
void main() {
void g(int x) {}
f((x){ g(x); });
}
The error reported is:
Error: function f (void delegate(int) nothrow dlg) is not callable using
argument types (void)
This is wrong, as the argument type is not (void). It is also very difficult to
figure out what is wrong with this program from this error (when the code is
far more complicated).
A better error would be:
Error: function f expects (void delegate(int) **nothrow** dlg) but was given
(void delegate(int))
--
[Issue 17473] foreach on delegates incorrectly rejected
https://issues.dlang.org/show_bug.cgi?id=17473 --- Comment #5 from Eyal --- (In reply to Vladimir Panteleev from comment #4) > Adding `ref` to `char a` fixes compilation, but it's still weird that > `ref`'s presence is inconsistently needed. It also changes the meaning of the program in an undesired way. --
[Issue 17473] foreach on delegates incorrectly rejected
https://issues.dlang.org/show_bug.cgi?id=17473 ag0ae...@gmail.com changed: What|Removed |Added Keywords||rejects-valid CC||ag0ae...@gmail.com --
[Issue 17476] Static fields don't seem to be reliably initialized when using parallel()
https://issues.dlang.org/show_bug.cgi?id=17476 --- Comment #8 from Vladimir Panteleev --- (In reply to Mathias Lang from comment #7) > How can > "foobar" be printed twice if it's only set for one thread ? Because both times "foobar" is written are done from the same (main) thread. parallel() can (and does) reuse threads. --
[Issue 17476] Static fields don't seem to be reliably initialized when using parallel()
https://issues.dlang.org/show_bug.cgi?id=17476 --- Comment #7 from Mathias Lang --- When a thread runs I would expect the following (simplified) course of action: - Initialize the TLS data - Do the writeln - Exit Given the original code, I would then expect the code to print 3 times "/some/string/initializer" and one time "foobar". I would not expect any order. Which means the first 2 runs give a perfectly valid output. However, the 3rd run outputs "/some/string/initializer" twice, and "foobar" twice. How can "foobar" be printed twice if it's only set for one thread ? If the delegate generated from the `foreach` body would capture the static instance of the main thread, we would get 4 "foobar". but we don't. --
[Issue 17476] Static fields don't seem to be reliably initialized when using parallel()
https://issues.dlang.org/show_bug.cgi?id=17476
--- Comment #6 from Andrej Mitrovic ---
> In main, you set the TLS instance of path corresponding to the main thread to
> "foobar". The "parallel" loop body will use the current thread's TLS
> instance, but because the order of execution of threads is of course
> undefined, you get inconsistent results.
I was initially confused not by the order of things, but by the multiple
printouts of "foobar". However this explains everything:
-
import std.concurrency;
import std.stdio;
import std.parallelism;
struct Params
{
static string path = "/some/string/initializer";
}
void main()
{
Params.path = "foobar";
foreach (_; parallel([1, 2, 3, 4]))
{
writefln("%s %s", thisTid(), Params.path);
}
}
-
Tid(7fe4c452e800) foobar
Tid(7fe4c452e800) foobar
Tid(7fe4c452e900) /some/string/initializer
Tid(7fe4c452ea00) /some/string/initializer
It's a non-issue, we were just puzzled at first. :)
--
[Issue 17476] Static fields don't seem to be reliably initialized when using parallel()
https://issues.dlang.org/show_bug.cgi?id=17476 --- Comment #5 from Vladimir Panteleev --- (In reply to Mathias Lang from comment #4) > So you can implicitly capture TLS variables and use them from other thread ? > Doesn't that completely defeat the purpose of thread locality ? I don't understand your question. If you want to always refer to the main thread's TLS instance of "path" inside the parallel foreach body, you can explicitly save a copy or a pointer to it outside the foreach body on main's stack, then refer to it inside the foreach body. --
[Issue 17469] View source code
https://issues.dlang.org/show_bug.cgi?id=17469 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/dlang.org https://github.com/dlang/dlang.org/commit/d02045747db953d021649f222e07c71c0705dbb0 Fix Issue 17469 - View source code for object.d is broken --
[Issue 17476] Static fields don't seem to be reliably initialized when using parallel()
https://issues.dlang.org/show_bug.cgi?id=17476 Mathias Lang changed: What|Removed |Added CC||mathias.l...@sociomantic.co ||m --- Comment #4 from Mathias Lang --- > In main, you set the TLS instance of path corresponding to the main thread to > "foobar". The "parallel" loop body will use the current thread's TLS > instance, but because the order of execution of threads is of course > undefined, you get inconsistent results. So you can implicitly capture TLS variables and use them from other thread ? Doesn't that completely defeat the purpose of thread locality ? --
[Issue 17476] Static fields don't seem to be reliably initialized when using parallel()
https://issues.dlang.org/show_bug.cgi?id=17476 Vladimir Panteleev changed: What|Removed |Added Status|NEW |RESOLVED CC||thecybersha...@gmail.com Resolution|--- |INVALID --- Comment #3 from Vladimir Panteleev --- No bug here. path in a TLS variable, so there is one instance per thread. In main, you set the TLS instance of path corresponding to the main thread to "foobar". The "parallel" loop body will use the current thread's TLS instance, but because the order of execution of threads is of course undefined, you get inconsistent results. I'm not sure what you expect - that the order of thread execution is deterministic? This is of course impossible. Or do you want one instance of "path" per the entire program, shared across threads? Then move it out of the TLS into the stack or data segment (but watch out for data races). --
[Issue 17475] [REG2.075] linker error on specific code
https://issues.dlang.org/show_bug.cgi?id=17475 --- Comment #3 from Vladimir Panteleev --- (In reply to b2.temp from comment #2) > Are you sure ? Yes: ~/work/Digger/work/repo » git checkout 13da2d4e97bf15c7049138012bde243a221be117 ; git submodule update ; git submodule status Mdlang.org HEAD is now at 13da2d4e97... phobos: Merge pull request #5444 from klickverbot/quad-lrint Submodule path 'dlang.org': checked out '9f1f0155b03141dd842cd9664e1fc638c1a1aa9c' 9f1f0155b03141dd842cd9664e1fc638c1a1aa9c dlang.org (v2.074.1-82-g9f1f0155) 5f2f2811a3d756777bcf098983b94db543f1dfcf dmd (v2.074.1-347-g5f2f2811a) 2b14f6cd6b3ed338bbb54b0a3fe30427cf050d0b druntime (v2.074.1-60-g2b14f6cd) 19843d82476837ede8f2079fa8e5b405d481235a installer (v2.074.1-7-g19843d8) f036ef12eafda45b9bcb31c4d06975adb6313e6a phobos (v2.074.1-326-gf036ef12e) ed24fb441744a6c168d394970186456ae1484f5c tools (v2.073.2-26-ged24fb4) ~/work/Digger/work/repo » digger build 13da2d4e97bf15c7049138012bde243a221be117 ... ~/tmp/2017-06-07-scratch/15:52:31 » ( d-digger ; dmd --version ; dmd -run test.d ) DMD64 D Compiler v2.075.0-devel-5f2f2811a-dirty Copyright (c) 1999-2017 by Digital Mars written by Walter Bright digitalMars > The script i use to build worked well since months. I can't vouch for your script. If it's broken, it's your problem. --
[Issue 17475] [REG2.075] linker error on specific code
https://issues.dlang.org/show_bug.cgi?id=17475 --- Comment #2 from b2.t...@gmx.com --- (In reply to Vladimir Panteleev from comment #1) > You have a mismatching libphobos again. > > In the future, please test with a D build tool that removes the possibility > of user errors, such as Digger. Are you sure ? See here: https://forum.dlang.org/thread/dbmroothueyaexzqk...@forum.dlang.org The script i use to build worked well since months. --
[Issue 17475] [REG2.075] linker error on specific code
https://issues.dlang.org/show_bug.cgi?id=17475 Vladimir Panteleev changed: What|Removed |Added Status|NEW |RESOLVED CC||thecybersha...@gmail.com Resolution|--- |WORKSFORME --- Comment #1 from Vladimir Panteleev --- You have a mismatching libphobos again. In the future, please test with a D build tool that removes the possibility of user errors, such as Digger. --
[Issue 16566] hasLength should enforce that length has type size_t
https://issues.dlang.org/show_bug.cgi?id=16566 --- Comment #5 from Andrei Alexandrescu --- (In reply to Vladimir Panteleev from comment #4) > What about e.g. ranges representing files over 4GB on 32-bit architectures? Those are not supported. --
[Issue 16566] hasLength should enforce that length has type size_t
https://issues.dlang.org/show_bug.cgi?id=16566 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #4 from Vladimir Panteleev --- What about e.g. ranges representing files over 4GB on 32-bit architectures? --
[Issue 17473] foreach on delegates incorrectly rejected
https://issues.dlang.org/show_bug.cgi?id=17473 --- Comment #4 from Vladimir Panteleev --- Adding `ref` to `char a` fixes compilation, but it's still weird that `ref`'s presence is inconsistently needed. --
[Issue 17473] foreach on delegates incorrectly rejected
https://issues.dlang.org/show_bug.cgi?id=17473 --- Comment #3 from Vladimir Panteleev --- (In reply to Eyal from comment #2) > Perhaps you didn't pass -unittest? Yep, my bad --
[Issue 17473] foreach on delegates incorrectly rejected
https://issues.dlang.org/show_bug.cgi?id=17473 --- Comment #2 from Eyal --- (In reply to Vladimir Panteleev from comment #1) > Your example works here. Could you specify the compiler version and > compilation flags? dmd --version DMD64 D Compiler v2.074.0 Copyright (c) 1999-2017 by Digital Mars written by Walter Bright dmd -unittest testdlg.d int delegate(int delegate(char a) dlg) int delegate(int delegate(char a) dlg) testdlg.d(15): Error: delegate g (int delegate(char a) dlg) is not callable using argument types (int delegate(ref char __applyArg0) pure nothrow @nogc @safe) Perhaps you didn't pass -unittest? --
[Issue 17473] foreach on delegates incorrectly rejected
https://issues.dlang.org/show_bug.cgi?id=17473 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev --- Your example works here. Could you specify the compiler version and compilation flags? --
[Issue 17476] Static fields don't seem to be reliably initialized when using parallel()
https://issues.dlang.org/show_bug.cgi?id=17476 Stefan Koch changed: What|Removed |Added CC||uplink.co...@gmail.com --- Comment #2 from Stefan Koch --- make path shared. --
[Issue 17476] Static fields don't seem to be reliably initialized when using parallel()
https://issues.dlang.org/show_bug.cgi?id=17476 --- Comment #1 from anonymous4 --- In the first thread it will be "foobar", in other threads it will be "/some/string/initializer", the exact sequence may depend on how parallel selects threads. --
[Issue 17476] New: Static fields don't seem to be reliably initialized when using parallel()
https://issues.dlang.org/show_bug.cgi?id=17476
Issue ID: 17476
Summary: Static fields don't seem to be reliably initialized
when using parallel()
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: andrej.mitrov...@gmail.com
```
import std.stdio;
import std.parallelism;
struct Params
{
static string path = "/some/string/initializer";
}
void main()
{
Params.path = "foobar";
foreach (_; parallel([1, 2, 3, 4]))
{
writefln("%s", Params.path);
}
}
```
Run this a few times, and each time the results will be wildly different:
```
~/dev/d test.d * $ dmd -run test.d
foobar
/some/string/initializer
/some/string/initializer
/some/string/initializer
~/dev/d test.d * $ dmd -run test.d
/some/string/initializer
foobar
/some/string/initializer
/some/string/initializer
~/dev/d test.d * $ dmd -run test.d
foobar
foobar
/some/string/initializer
/some/string/initializer
```
--
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 --- Comment #2 from anonymous4 --- If you think it's not a property, you should invoke it with braces. --
[Issue 17475] New: [REG2.075] linker error on specific code
https://issues.dlang.org/show_bug.cgi?id=17475
Issue ID: 17475
Summary: [REG2.075] linker error on specific code
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: b2.t...@gmx.com
with dmd at 5f2f2811a3d756777bcf098983b94db543f1dfcf
with druntime at 2b14f6cd6b3ed338bbb54b0a3fe30427cf050d0b
with phobos at f036ef12eafda45b9bcb31c4d06975adb6313e6a
this code:
void main()
{
import std.stdio;
import std.compiler;
writeln(vendor);
}
cannot be linked:
/tmp/temp_7F12E3A4FF10.o : Dans la fonction «Â
_D3std6format60__T14formatUnsignedTS3std5stdio4File17LockingTextWriterTmTaZ14formatUnsignedFNfS3std5stdio4File17LockingTextWritermKxS3std6format18__T10FormatSpecTaZ10FormatSpeckbZvÂ
» :
/tmp/temp_7F12E3A4FF10.d:(.text._D3std6format60__T14formatUnsignedTS3std5stdio4File17LockingTextWriterTmTaZ14formatUnsignedFNfS3std5stdio4File17LockingTextWritermKxS3std6format18__T10FormatSpecTaZ10FormatSpeckbZv[_D3std6format60__T14formatUnsignedTS3std5stdio4File17LockingTextWriterTmTaZ14formatUnsignedFNfS3std5stdio4File17LockingTextWritermKxS3std6format18__T10FormatSpecTaZ10FormatSpeckbZv]+0x312)Â
: référence indéfinie vers «Â
_D3std6format18__T10FormatSpecTaZ10FormatSpec11flSeparatorMxFNaNbNdNiNfZb »
/tmp/temp_7F12E3A4FF10.d:(.text._D3std6format60__T14formatUnsignedTS3std5stdio4File17LockingTextWriterTmTaZ14formatUnsignedFNfS3std5stdio4File17LockingTextWritermKxS3std6format18__T10FormatSpecTaZ10FormatSpeckbZv[_D3std6format60__T14formatUnsignedTS3std5stdio4File17LockingTextWriterTmTaZ14formatUnsignedFNfS3std5stdio4File17LockingTextWritermKxS3std6format18__T10FormatSpecTaZ10FormatSpeckbZv]+0x436)Â
: référence indéfinie vers «Â
_D3std6format18__T10FormatSpecTaZ10FormatSpec11flSeparatorMxFNaNbNdNiNfZb »
/tmp/temp_7F12E3A4FF10.o : Dans la fonction «Â
_D3std6format64__T14formatUnsignedTS3std5array17__T8AppenderTAyaZ8AppenderTmTaZ14formatUnsignedFNaNfS3std5array17__T8AppenderTAyaZ8AppendermKxS3std6format18__T10FormatSpecTaZ10FormatSpeckbZvÂ
» :
/tmp/temp_7F12E3A4FF10.d:(.text._D3std6format64__T14formatUnsignedTS3std5array17__T8AppenderTAyaZ8AppenderTmTaZ14formatUnsignedFNaNfS3std5array17__T8AppenderTAyaZ8AppendermKxS3std6format18__T10FormatSpecTaZ10FormatSpeckbZv[_D3std6format64__T14formatUnsignedTS3std5array17__T8AppenderTAyaZ8AppenderTmTaZ14formatUnsignedFNaNfS3std5array17__T8AppenderTAyaZ8AppendermKxS3std6format18__T10FormatSpecTaZ10FormatSpeckbZv]+0x316)Â
: référence indéfinie vers «Â
_D3std6format18__T10FormatSpecTaZ10FormatSpec11flSeparatorMxFNaNbNdNiNfZb »
/tmp/temp_7F12E3A4FF10.d:(.text._D3std6format64__T14formatUnsignedTS3std5array17__T8AppenderTAyaZ8AppenderTmTaZ14formatUnsignedFNaNfS3std5array17__T8AppenderTAyaZ8AppendermKxS3std6format18__T10FormatSpecTaZ10FormatSpeckbZv[_D3std6format64__T14formatUnsignedTS3std5array17__T8AppenderTAyaZ8AppenderTmTaZ14formatUnsignedFNaNfS3std5array17__T8AppenderTAyaZ8AppendermKxS3std6format18__T10FormatSpecTaZ10FormatSpeckbZv]+0x43a)Â
: référence indéfinie vers «Â
_D3std6format18__T10FormatSpecTaZ10FormatSpec11flSeparatorMxFNaNbNdNiNfZb »
collect2: error: ld returned 1 exit status
--
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 ZombineDev changed: What|Removed |Added CC||petar.p.ki...@gmail.com Hardware|x86_64 |All OS|Linux |All --
[Issue 17474] non-property being treated as a property
https://issues.dlang.org/show_bug.cgi?id=17474 Tomer Filiba (weka) changed: What|Removed |Added Keywords||industry CC||to...@weka.io --- Comment #1 from Tomer Filiba (weka) --- I would like to elaborate a little. The existence/absence of a @property doesn't matter here. The thing is, the compiler first tries to lower `foo = bar` to `foo(bar)`. If it doesn't work, it will try `foo() = bar` which is what we expect. However, in the case of `foo = null`, the lowering to `foo(null)` does match because you can pass `null` for a string. So, depending on the *value* I'm assigning, it will choose different code paths, even though I'm expecting only the second behavior. This bug was caught in a UT, but figuring it out required I look at the generated assembly because it was impossible to understand otherwise. I don't know what's the "right semantics" here. It's basically the interaction of several different features that cause this, but I definitely know it's not what I expect from looking at the code. --
