Re: Request assistance converting C's #ifndef to D
On Thursday, 12 May 2016 at 22:51:17 UTC, Andrew Edwards wrote:
The following preprocessor directives are frequently
encountered in C code, providing a default constant value where
the user of the code has not specified one:
#ifndef MIN
#define MIN 99
#endif
#ifndef MAX
#define MAX 999
#endif
I'm at a loss at how to properly convert it to D. I've tried
the following:
enum MIN = 0;
static if(MIN <= 0)
{
MIN = 99;
}
it works as long as the static if is enclosed in a static
this(), otherwise the compiler complains:
mo.d(493): Error: no identifier for declarator MIN
mo.d(493): Error: declaration expected, not '='
This however, does not feel like the right way to do thinks but
I cannot find any documentation that provides an alternative.
Is there a better way to do this?
Thanks,
Andrew
One thing you could try is compile the C code without the
#ifndef's and see if it compiles without issues. If it does,
simply use a D enum and don't worry about translating the
#ifndef's.
(Alternately check the C code to see if there really are
differing definitions of MIN/MAX -- if there are, then the code
is already messed up and you need to implement your D code taking
into consideration the implications of that -- maybe use
different variable names in each section of the code for the
MIN/MAX that takes the different MIN/MAX values. I've typically
seen this kind of ifdef'ing to quick-fix compile issues in new
code without having to rewrite a whole bunch of existing code or
code-structure and it is never to have differing values for the
defines -- if differing values are used with the same name, then
the code is bad and it's best to cleanup as you migrate to D.)
Re: Need help understanding exception...
On Sunday, 21 February 2016 at 06:24:54 UTC, sanjayss wrote: On Sunday, 21 February 2016 at 01:06:16 UTC, Ali Çehreli wrote: [...] Thanks. That helps. I am making the stdin non-blocking (but reverting it back before doing the readln()) -- maybe that is causing some problems. Will follow this line of reasoning to see if I can figure out the problem. Just doing a "stdin.clearerr()" after switching back from non-blocking mode helped. Thanks again.
Re: Need help understanding exception...
On Sunday, 21 February 2016 at 01:06:16 UTC, Ali Çehreli wrote: On 02/20/2016 04:45 PM, sanjayss wrote: > [...] basically "line > [...] is saying. > [...] ioctls and > [...] this, but > [...] am doing > [...] issue). > [...] std.stdio.readlnImpl(shared(core.stdc.stdio._IO_FILE)*, ref > [...] Judging frome the fact that the exception object does not contain a message, it must be coming from one of several of the following checks: if (ferror(fps)) StdioException(); For example: https://github.com/D-Programming-Language/phobos/blob/master/std/stdio.d#L4180 And the only meaning is that the input stream is in error state. :-/ Ali Thanks. That helps. I am making the stdin non-blocking (but reverting it back before doing the readln()) -- maybe that is causing some problems. Will follow this line of reasoning to see if I can figure out the problem.
Need help understanding exception...
I got the following exception on a line of code that is basically "line = readln()" and need help in understanding what the exception is saying. (I am playing around with stdio prior to this using unix ioctls and maybe I am messing something up in the process resulting in this, but understanding the exception will give me a clue as to what I am doing wrong -- a basic D progam with readln() doesn't have the same issue). This is on linux with DMD version 2.07. std.stdio.StdioException@std/stdio.d(3969) ??:? void std.stdio.StdioException.opCall() [0x4c8891] ??:? ulong std.stdio.readlnImpl(shared(core.stdc.stdio._IO_FILE)*, ref char[], dchar, std.stdio.File.Orientation) [0x4c89e5] /usr/include/dmd/phobos/std/stdio.d:1547 ulong std.stdio.File.readln!(char).readln(ref char[], dchar) [0x4acd95] /usr/include/dmd/phobos/std/stdio.d:1408 immutable(char)[] std.stdio.File.readln!(immutable(char)[]).readln(dchar) [0x4acca2] /usr/include/dmd/phobos/std/stdio.d:3377 immutable(char)[] std.stdio.readln!(immutable(char)[]).readln(dchar) [0x4acc2f] telnetc.d:1572 void telnetc.handleEscapeMode(telnetc.TelnetInfo, ubyte) [0x4a6638] telnetc.d:1591 void telnetc.handleKey(telnetc.TelnetInfo, ubyte) [0x4a6707] telnetc.d:1603 void telnetc.handleKeyPress(telnetc.TelnetInfo, ubyte[]) [0x4a6788] telnetc.d:1740 bool telnetc.readSocket!(void function(telnetc.TelnetInfo, ubyte[])*, telnetc.TelnetInfo).readSocket(immutable(char)[], std.socket.Socket, void function(telnetc.TelnetInfo, ubyte[])*, telnetc.TelnetInfo) [0x4adb18] telnetc.d:1802 void telnetc.receiveAndProcessData(telnetc.TelnetInfo) [0x4a6f00] telnetc.d:2165 _Dmain [0x4a7831] ??:? _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv [0x4b9742] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x4b9680] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() [0x4b96fe] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x4b9680] ??:? _d_run_main [0x4b95dd] ??:? main [0x4b3827] ??:? __libc_start_main [0xf762ec4]
Problem with release build.
In the following sample program (which tries to set terminal to
raw mode and check for key presses), compiling as usual (dmd
t.d), the program works, but compiling in release mode (dmd
-release t.d) and the raw mode doesn't seem to work. Where do I
start looking to figure this out or if it is obvious, what am I
doing wrong? (In the release mode output, notice the character
getting echo-ed before the "Got").
MacBook-Pro:$ dmd --version
DMD64 D Compiler v2.069.2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
MacBook-Pro:$ dmd t.d
MacBook-Pro:$ ./t
Got: a
Got: b
Got: c
Got: d
Got: q
MacBook-Pro:$ dmd -release t.d
MacBook-Pro:$ ./t
aGot: a
bGot: b
cGot: c
dGot: d
eGot: e
qGot: q
MacBook-Pro:$ cat t.d
import core.thread;
import core.stdc.stdio;
import core.sys.posix.fcntl;
import core.sys.posix.termios;
import std.stdio : writeln;
int oldf;
termios oldt;
void
makeraw()
{
termios newt;
assert(tcgetattr(0, ) == 0);
newt = oldt;
newt.c_lflag &= ~(ICANON | ECHO | ECHONL | ISIG | IEXTEN);
newt.c_iflag &= ~(IGNBRK | BRKINT | ISTRIP | INLCR | ICRNL |
IGNCR | IXON | IXOFF);
newt.c_cc[VMIN] = 1;
assert(tcsetattr(0, TCSANOW, ) == 0);
oldf = fcntl(0, F_GETFL, 0);
fcntl(0, F_SETFL, oldf | O_NONBLOCK);
}
void
makecooked()
{
fcntl(0, F_SETFL, oldf);
assert(tcsetattr(0, TCSANOW, ) == 0);
}
void
main(string[] args)
{
int ch;
makeraw();
scope(exit) makecooked();
do
{
while ((ch = fgetc(stdin)) == EOF)
{
Thread.sleep(dur!("seconds")(1));
}
writeln("Got: ", cast(dchar)ch);
} while (ch != 'q');
}
Re: Problem with release build.
Ignore this -- this is probably due to how I am doing the
assert(). In the release build, it is getting compiled out and in
the process compiling out the tcgetattr and the tcsetattr.
On Tuesday, 9 February 2016 at 05:08:20 UTC, sanjayss wrote:
In the following sample program (which tries to set terminal to
raw mode and check for key presses), compiling as usual (dmd
t.d), the program works, but compiling in release mode (dmd
-release t.d) and the raw mode doesn't seem to work. Where do I
start looking to figure this out or if it is obvious, what am I
doing wrong? (In the release mode output, notice the character
getting echo-ed before the "Got").
MacBook-Pro:$ dmd --version
DMD64 D Compiler v2.069.2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
MacBook-Pro:$ dmd t.d
MacBook-Pro:$ ./t
Got: a
Got: b
Got: c
Got: d
Got: q
MacBook-Pro:$ dmd -release t.d
MacBook-Pro:$ ./t
aGot: a
bGot: b
cGot: c
dGot: d
eGot: e
qGot: q
MacBook-Pro:$ cat t.d
import core.thread;
import core.stdc.stdio;
import core.sys.posix.fcntl;
import core.sys.posix.termios;
import std.stdio : writeln;
int oldf;
termios oldt;
void
makeraw()
{
termios newt;
assert(tcgetattr(0, ) == 0);
newt = oldt;
newt.c_lflag &= ~(ICANON | ECHO | ECHONL | ISIG | IEXTEN);
newt.c_iflag &= ~(IGNBRK | BRKINT | ISTRIP | INLCR | ICRNL
| IGNCR | IXON | IXOFF);
newt.c_cc[VMIN] = 1;
assert(tcsetattr(0, TCSANOW, ) == 0);
oldf = fcntl(0, F_GETFL, 0);
fcntl(0, F_SETFL, oldf | O_NONBLOCK);
}
void
makecooked()
{
fcntl(0, F_SETFL, oldf);
assert(tcsetattr(0, TCSANOW, ) == 0);
}
void
main(string[] args)
{
int ch;
makeraw();
scope(exit) makecooked();
do
{
while ((ch = fgetc(stdin)) == EOF)
{
Thread.sleep(dur!("seconds")(1));
}
writeln("Got: ", cast(dchar)ch);
} while (ch != 'q');
}
std.socket question
Are the functions lastSocketError() and wouldHaveBlocked() from std.socket thread-safe? i.e. can they be reliably used to see the status of the last socket call when sockets are being read/written in multiple threads?
Re: core.sys.posix.sys.ioctl
On Friday, 15 January 2016 at 21:49:38 UTC, Adam D. Ruppe wrote: On Friday, 15 January 2016 at 21:21:26 UTC, sanjayss wrote: Is the contribution process straightforward. For this, yes. Should be able to just fork druntime and edit the ioctl.d that exists to flesh it out to be more complete. Make sure it matches the original C names, values, etc., and there should be no real friction in getting it in (just remember to use spaces rather than tabs lol) So I got round to doing this -- https://github.com/D-Programming-Language/druntime/pull/1485 -- it's not clear what happens now -- is there a set of people that reviews pull requests and comment on it or is it open to all?
core.sys.posix.sys.ioctl
Is there any reason that this module is not complete for platforms other than Linux -- the ioctl() system call is common across all Unix-like OSes, so it doesn't make sense that this is only partially supported. (I am using the latest DMD).
Re: core.sys.posix.sys.ioctl
On Friday, 15 January 2016 at 18:34:14 UTC, Adam D. Ruppe wrote: On Friday, 15 January 2016 at 18:32:22 UTC, sanjayss wrote: Is there any reason that this module is not complete for platforms other than Linux Nobody has written it up, except the parts they use. Is the contribution process straightforward. Since I am mucking around in this area on OSX, I could attempt creating a more complete ioctl module for OSX...unless ofcourse someone else has already tried it and there are too many gotchas or there already have been too many discussions on the right way to do this and there is no consensus (I don't want to get into too much of these types of discussions -- not enough time).
concurrency and standard logger of std.experimental.logger
Is there a way to include some form of thread-id in the standard logger log messages without resorting to the use of the 'f' functions to log this info too?
Re: std.experimental.logger
On Tuesday, 5 January 2016 at 09:18:21 UTC, Robert burner Schadek
wrote:
On Tuesday, 5 January 2016 at 02:44:48 UTC, sanjayss wrote:
I'm doing the following:
import std.experimental.logger;
int
main(string[] args)
{
sharedLog = new FileLogger("logfile.log");
log("Test log 1");
log("Test log 2");
log("Test log 3");
}
diff:
sharedLog = new FileLogger("logfile.log", LogLevel.all);
calling log uses the globalLogLevel, which is LogLevel.all by
default.
The default LogLevel of a new FileLogger is LogLevel.info.
So the new FileLogger drops the log messages.
This is an inconsistency I will fix.
Thanks -- seems like you found my bugzilla issue and fixed the
problem. I'll try using your diff above and see if that helps me.
Re: std.experimental.logger
On Tuesday, 5 January 2016 at 02:49:01 UTC, Mike wrote:
On Tuesday, 5 January 2016 at 02:44:48 UTC, sanjayss wrote:
I'm doing the following:
import std.experimental.logger;
int
main(string[] args)
{
sharedLog = new FileLogger("logfile.log");
log("Test log 1");
log("Test log 2");
log("Test log 3");
}
and I expected the logs to be seen in the logfile.log, but it
seems like my reading of the docs on this is incorrect and the
logfile.log is not populated at all (though it is created).
What am I missing or using incorrectly?
Basically I am trying to have the default logger log to a file
instead of stderr.
(I am on a Mac (OS-X 10.11.1, 64 bit) and using DMD 2.069.2)
You need to log with sharedLog:
sharedLog.log("Test log 1");
sharedLog.log("Test log 2");
sharedLog.log("Test log 3");
Thanks, that works. But the docs are confusing -- it gives the
impression that "sharedLog" is something associated with the
default logger -- so I would expect the above to work with just
the plain log() call to invoke the default logger. But it seems
like I am just creating a new logger and using that by saying
"sharedLog.log()".
From the doc:
The default Logger will by default log to stderr and has a
default LogLevel of LogLevel.all. The default Logger can be
accessed by using the property called sharedLog. This property a
reference to the current default Logger. This reference can be
used to assign a new default Logger.
sharedLog = new FileLogger("New_Default_Log_File.log");
std.experimental.logger
I'm doing the following:
import std.experimental.logger;
int
main(string[] args)
{
sharedLog = new FileLogger("logfile.log");
log("Test log 1");
log("Test log 2");
log("Test log 3");
}
and I expected the logs to be seen in the logfile.log, but it
seems like my reading of the docs on this is incorrect and the
logfile.log is not populated at all (though it is created). What
am I missing or using incorrectly?
Basically I am trying to have the default logger log to a file
instead of stderr.
(I am on a Mac (OS-X 10.11.1, 64 bit) and using DMD 2.069.2)
Re: socketpair
On Thursday, 31 December 2015 at 07:48:03 UTC, Vladimir Panteleev wrote: On Thursday, 31 December 2015 at 02:37:07 UTC, sanjayss wrote: OK; one way I realized was to put the network socket select in one thread and the watching for keypress in another thread and then use the concurrency primitives to message pass events to the main thread -- may be a little expensive, but it probably will achieve the effect I desire. Here is my implementation of this idea: https://github.com/CyberShadow/ae/blob/master/net/sync.d Thanks, Vladimir...though I didn't fully understand your code example, it gave me the idea to use delegates to capture one of the socketpair sockets for use in a thread where I could write to it and read the other socket to read from in the main task. Just beginning to use D and am getting used to the various features...
socketpair
std.socket supports the socketpair() function, but it seems like this api is not really usable in any of the concurrency primitives supported by D. So what is the purpose of the socketpair() support? Basically I am trying to create two threads and am trying to use socketpair() to create two sockets and use them to communicate between the threads, but none of the socket API's allow use of shared socket-pair (probably correctly so). So how else can one implement a foreground event loop that supports both key-presses and network socket events -- I was hoping to do the keyboard event in one thread and use the socketpair to communicate to the actual foreground event loop via the socketpair sockets. Any help on how one would code this in D is welcome.
Re: socketpair
On Thursday, 31 December 2015 at 02:31:09 UTC, sanjayss wrote: On Thursday, 31 December 2015 at 02:26:23 UTC, Rikki Cattermole wrote: On 31/12/15 3:22 PM, sanjayss wrote: [...] Wrong tool for the job. You want message passing not sockets to communicate between threads in this case. You're wanting the functions receive and send relating to: http://dlang.org/phobos/std_concurrency.html Sure -- I understand the concurrency primitives, but what I was trying to achieve was to have a single foreground loop that could select on a network socket while also watching for a keypress (and in C socketpair is one way you would achieve this using one thread to listen for keypresses -- see http://stackoverflow.com/questions/11461106/socketpair-in-c-unix). How do you suggest I achieve this in D? OK; one way I realized was to put the network socket select in one thread and the watching for keypress in another thread and then use the concurrency primitives to message pass events to the main thread -- may be a little expensive, but it probably will achieve the effect I desire.
Re: socketpair
On Thursday, 31 December 2015 at 02:26:23 UTC, Rikki Cattermole wrote: On 31/12/15 3:22 PM, sanjayss wrote: std.socket supports the socketpair() function, but it seems like this api is not really usable in any of the concurrency primitives supported by D. So what is the purpose of the socketpair() support? Basically I am trying to create two threads and am trying to use socketpair() to create two sockets and use them to communicate between the threads, but none of the socket API's allow use of shared socket-pair (probably correctly so). So how else can one implement a foreground event loop that supports both key-presses and network socket events -- I was hoping to do the keyboard event in one thread and use the socketpair to communicate to the actual foreground event loop via the socketpair sockets. Any help on how one would code this in D is welcome. Wrong tool for the job. You want message passing not sockets to communicate between threads in this case. You're wanting the functions receive and send relating to: http://dlang.org/phobos/std_concurrency.html Sure -- I understand the concurrency primitives, but what I was trying to achieve was to have a single foreground loop that could select on a network socket while also watching for a keypress (and in C socketpair is one way you would achieve this using one thread to listen for keypresses -- see http://stackoverflow.com/questions/11461106/socketpair-in-c-unix). How do you suggest I achieve this in D?
