Re: CTFE in imported static initializers
On 5/14/19 8:06 PM, kinke wrote: On Tuesday, 14 May 2019 at 10:21:23 UTC, Steven Schveighoffer wrote: I too am out of my league when it comes to what's valid here ;) Valid or not, 1 second is ridiculous, please file a bug. For an importing module, it's just an external TLS global. As you mentioned, type inference shouldn't need a full evaluation of the initializer, but that's not the problem, as `static string moddata = buildModData();` doesn't improve anything. OK, now that I have a compiler developer agreeing, I feel more comfortable filing ;) -Steve
Re: CTFE in imported static initializers
On Tuesday, 14 May 2019 at 10:21:23 UTC, Steven Schveighoffer wrote: I too am out of my league when it comes to what's valid here ;) Valid or not, 1 second is ridiculous, please file a bug. For an importing module, it's just an external TLS global. As you mentioned, type inference shouldn't need a full evaluation of the initializer, but that's not the problem, as `static string moddata = buildModData();` doesn't improve anything.
Re: Windows / redirect STDERR to see assert messages
On 2019-05-12 22:46:37 +, Adam D. Ruppe said: You might need to catch all the throwable exceptions and print your way instead... Adam, thanks, that was the missing link. I thought that assert() is dumb hard exit with a short message and not throwing a full exception. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Alias to template instance wokrs, but non-template does not?
I have the rather strange question: Why does this work?
struct S
{
int value0;
alias opApply = opApplyImpl!(int delegate(ref int)); //1
int opApplyImpl(DG : int delegate(ref int))(scope DG
callback) //2
{
if (auto result = callback(value0)) return result;
return 0;
}
}
@safe pure nothrow @nogc unittest
{
S xs = S(3);
int sum = 0;
foreach (x; xs) sum += x;
assert(sum == 3);
}
But replacing Lines //1 and //2 with
int opApply(int delegate(ref int) callback)
(replacing the alias to a template instance by equivalent(?)
non-template code) does not. As far as I know, template
instantiation should make them exactly the same thing.
The spec does not say anything to this.
Even after replacing //1 by
alias opApply = opApplyImpl!(int delegate(ref int) @system);
//1
i.e. marking the callback @system explicitly,
the @safe unittest will still compile!
Using
xs.opApply((ref int x) { sum += x; return 0; });
in the unittest directly makes it fail. The compiler claims as
expected that the template instance is not satisfy the conditions
for either attribute on the unittest.
But somehow, it does respect attributes. An un-@safe unittest
like this
static bool b = false; // some global state to break pure
static foreach (i; 0 .. 4)
{
version(failure)
@safe pure nothrow @nogc unittest
{
static immutable exc = new immutable Exception("");
S xs = S(3);
int* p = // some pointer to break @safe-ty
foreach (x; xs)
{
static if (i == 0) { p = new int(x); } //
allocates
static if (i == 1) { ++p; } // un-@safe
static if (i == 2) { b = true; } // impure
static if (i == 3) { throw exc; } // throws
Exceptions
}
}
}
actually shows that any single attribute can be failed,
suggesting it is the same for all.
Is there some attribute magic in the compiler's opApply
rewriting? It should be mentioned.
I've filed a bug report [1] some time ago. I'm posting here,
because I want to understand what's going on here.
A runnable example is here: https://run.dlang.io/is/KQ0tmL
[1] https://issues.dlang.org/show_bug.cgi?id=19706
Blog Post #0035 - AboutDialog Howto
Today starts a new series on gtkDcoding, this one covers a large wad of Dialogs starting with (perhaps) the simplest of them all: the AboutDialog. The post can be found here: http://gtkdcoding.com/2019/05/14/0035-help-about-dialog.html
Re: Windows / redirect STDERR to see assert messages
Assert failure uses system IO API, try https://docs.microsoft.com/en-us/windows/console/setstdhandle
Re: CTFE in imported static initializers
On 5/13/19 9:39 PM, Steven Schveighoffer wrote:
I have just discovered an interesting behavior, and I'm wondering if
this behavior is intentional or even necessary.
Let's say I have this module called mod2.d:
module mod2;
string buildModData()
{
string result;
foreach(i; 0 .. 1)
result = result ~ "lots and lots and lots of data";
return result;
}
static moddata = buildModData();
A workaround found by Jonathan Davis:
string moddata() {
static result = buildModData();
return result;
}
-Steve
Re: CTFE in imported static initializers
On 5/14/19 10:25 AM, Bastiaan Veelo wrote: On Monday, 13 May 2019 at 20:39:57 UTC, Steven Schveighoffer wrote: Why? I can't even use it at compile time... pragma(msg, moddata.length); Is that a good test or "usable at compile time", though? Isn't pragma(msg) done at an earlier stage than CTFE? I think that was the argument for ctfeWriteln. No, pragma(msg) can happen after CTFE: pragma(msg, buildModData()[0 .. 100]); (We both know that I'm out of my league here, but anyway :)) Well, this is the learn forum, I too am out of my league when it comes to what's valid here ;) -Steve
Re: CTFE in imported static initializers
On 5/14/19 10:30 AM, Stefan Koch wrote: On Tuesday, 14 May 2019 at 08:26:41 UTC, Steven Schveighoffer wrote: On 5/13/19 9:39 PM, Steven Schveighoffer wrote: Does anyone have a good answer for why this should happen, or should I file a bug? It's been mentioned to me that type inference is used here. However, one could argue that the CTFE doesn't need to complete in order to infer the type, the function is not a template or auto function. In addition, if I change the declaration to: static string moddata = ...; It still takes 1 second to compile mod1. try changing it to static immutable. Still 1 second. -Steve
Re: is there a way to embed python 3.7 code in D program?
On Monday, 13 May 2019 at 08:33:46 UTC, Russel Winder wrote: I'd like to use D for the "brain" of a small robot (Anki vector) whose API is coded in Python 3.6+. I had a look at Pyd but it's limited to python 2.7... PyD works entirely fine for me using Python 3.7. Yes, it seems to work so far for me too, just modifying the dub.json file. Thank you all for the tips!!
Re: Windows / redirect STDERR to see assert messages
On Sunday, 12 May 2019 at 13:39:15 UTC, Robert M. Münch wrote:
When developing Windows GUI applications I use:
// detach from console and attach to a new one, works for
x86 and x86_64
FreeConsole();
AllocConsole();
freopen("CONIN$", "r", stdin);
freopen("CONOUT$", "w", stdout);
freopen("CONOUT$", "w", stderr);
so that the GUI app opens a console for writeln() output etc. I
assumed this should work for assert() messages as well. But it
seems it doesn't. If an assert fails, I don't see any output.
Is assert using something else? What's wrong about this
approach?
Are you sure the last call to freopen doesn't return NULL? You
are opening the same file twice and I'm not sure that works. Test
with `stderr.writeln("test")`.
Bastiaan.
Implementing a watchdog process for a console program
So I'm implementing a watchdog process for my web server, or a
deadman switch as it's called here:
https://www.digitalmars.com/articles/b40.html
But I ran into a problem with filtering watchdog kicks and then
forwarding other I/O through the watchdog process. Here's what I
have done so far:
import std.experimental.all;
immutable watchdogResetMessage = "check";
enum watchdogTriggerTime = 3.seconds;
version (Watchdog) void main(string[] args)
{ while (true)
{ resetPipe = std.process.pipe();
auto server = spawnProcess(["the web server"], stdin,
resetPipe.writeEnd, stderr, null, Config.retainStdout |
Config.suppressConsole);
auto watchdogTriggered = Clock.currTime;
auto outputTask = spawn(function void(File file)
{ foreach(line; file.byLine)
{ if (line == watchdogResetMessage)
ownerTid.send(ubyte(0));
else line.writeln;
}
}, resetPipe.readEnd);
//waits until no reset message is coing
while (watchdogTriggerTime.receiveTimeout((ubyte){})) {}
writeln(Clock.currTime.toISOExtString, ": Server does not
sign life anymore. Restarting.");
server.kill;
server.wait;
}
}
The problem is that this won't pass compilation, because File
contains theard-local indirection and thus cannot be sent to
another theard.
I haven't done any complicated concurrency in D before. What's a
good way to handle this?
Re: CTFE in imported static initializers
On Tuesday, 14 May 2019 at 08:26:41 UTC, Steven Schveighoffer wrote: On 5/13/19 9:39 PM, Steven Schveighoffer wrote: Does anyone have a good answer for why this should happen, or should I file a bug? It's been mentioned to me that type inference is used here. However, one could argue that the CTFE doesn't need to complete in order to infer the type, the function is not a template or auto function. In addition, if I change the declaration to: static string moddata = ...; It still takes 1 second to compile mod1. -Steve try changing it to static immutable.
Re: CTFE in imported static initializers
On Monday, 13 May 2019 at 20:39:57 UTC, Steven Schveighoffer wrote: Why? I can't even use it at compile time... pragma(msg, moddata.length); Is that a good test or "usable at compile time", though? Isn't pragma(msg) done at an earlier stage than CTFE? I think that was the argument for ctfeWriteln. (We both know that I'm out of my league here, but anyway :)) Bastiaan.
Re: CTFE in imported static initializers
On 5/13/19 9:39 PM, Steven Schveighoffer wrote: Does anyone have a good answer for why this should happen, or should I file a bug? It's been mentioned to me that type inference is used here. However, one could argue that the CTFE doesn't need to complete in order to infer the type, the function is not a template or auto function. In addition, if I change the declaration to: static string moddata = ...; It still takes 1 second to compile mod1. -Steve
