Re: Fiber based UI-Toolkit
On 10.07.17 00:23, Christian Köstlin wrote: To elaborate on the previous post, I uploaded a small example, that tries naively to mix dlangui with fibers. Please have a look at: https://github.com/gizmomogwai/fibered-ui.git For sure it does not work. The fiber in the callback is started, but after the first yield, dlangui never returns to the fiber. Does anybody know what needs to be done for that? thanks a lot, Christian > On 09.07.17 23:12, bauss wrote: >> On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote: >>> I wonder if there is any fiber based / fiber compatible UI-Toolkit out >>> for dlang. The second question is, if it would make sense at all to >>> have such a thing? >>> >>> christian >> >> It doesn't really make sense to have that, because most (if not all) >> operating systems only allow rendering from a single thread and I >> believe OSX (possibly macOS too.) only allows it from the main thread. >> Which means the only thing you can really operate on other threads are >> events, but you'll always have to do callbacks to your UI thread in >> order to render. > Thanks for answering! you are touching exactly my question: > Lets say, that all the event handling is done by fiber-aware code (means > all io gives the thread free, when it would block, and perhaps > a yield function for calculation heavy operations). It would then > I think reduce the "risk" of a ANR (Application not responding (from > android) or the famous beachball) without sacrificing the clarity of the > code. > > e.g. you want to download something from a webpage and process the data, > if you click a button. you cannot do this in the buttons-onclick > callback (because this is usually a long running operation and the > callback is called from the main thread). with fibers, the main thread > could continue running (and update the screen) as soon as the io thread > is blocking or the process thread calls yield (which he should on a > regular basis). after the processing as soon as the fiber gets back the > control, the result can easily be integrated back into the ui, because > its already in the right thread. > compare this with the traditionally apporach of spawning a new thread, > passing over the arguments, processing it, passing back the result and > integrating this into the ui, it could perhaps be "simpler". > > on the other hand, the process code would get a little bit messy because > of the manually inserted yields (as far as i know, the erlang vm for > example inserts such instructions automatically every n instructions). > > what do you think? >
Re: How to get the address of a static struct?
On Monday, 10 July 2017 at 03:48:17 UTC, FoxyBrown wrote: static struct S auto s = &S; // ?!?!?! invalid because S is a struct, but... basically s = S. So S.x = s.x and s.a = S.a; Why do I have to do this? Static has a different meaning for struct. More or less it means it won't have access to a delegate/fat pointer to the function that uses it. It doesn't mean there's only 1 instantiation ever (unlike like the static variables). So static is a no-op in this case (though still syntactically legal to use). To get the address of the struct you STILL have to instantiate it first. Although you don't to in order to access it's static members. Though if all the members are static, it's basically a namespace and doing so is kinda pointless.
Re: How to get the address of a static struct?
Thread local struct:
```D
module foobar;
struct Foo {
int x;
}
Foo foo = Foo(8);
void main() {
import std.stdio;
writeln(&foo);
}
```
Global struct:
```D
module foobar;
struct Foo {
int x;
}
__gshared Foo foo = Foo(8);
void main() {
import std.stdio;
writeln(&foo);
}
```
Compile time constant:
```D
module foobar;
struct Foo {
int x;
}
enum FOO = Foo(8);
void main() {
import std.stdio;
Foo foo = FOO;
writeln(&foo);
}
```
How to get the address of a static struct?
static struct S
{
public static:
int x;
string a;
}
auto s = &S; // ?!?!?! invalid because S is a struct, but...
basically s = S. So S.x = s.x and s.a = S.a;
Why do I have to do this?
Because in visual D, global structs don't show up in the
debugger. So if I create a local alias, I can see see them, but I
don't wanna have to do one variable for each variable in the
struct...
Re: Faster alternatives to std.xml
On Saturday, July 8, 2017 8:45:57 PM MDT Nordlöw via Digitalmars-d-learn wrote: > What's the fastest XML-parser on code.dlang.org? > > Are there any benchmarks that show performance improvements > compared to std.xml? I'm not aware of any benchmarks for std.xml, but from what I know of it, it would likely lose them all. I've used http://code.dlang.org/packages/std-experimental-xml which was a GSoC project last year and was aimed at becoming the new std.xml, but it hasn't been touched since November. It seems like the author got too busy with school, and it fell completely by the wayside. So, I don't know what's going to happen to it. It's worked reasonably well for my needs, but it does have bugs, and it needs some work. I'd still rather use it than std.xml though. - Jonathan M Davis
Re: The Nullity Of strings and Its Meaning
On Sunday, July 9, 2017 1:51:44 PM MDT kdevel via Digitalmars-d-learn wrote: > > You also shouldn't rely on it returning null for a null input, > > even when it currently does that. > > I assumed that a non-null string is returned for a non-null input. There are going to be functions that return null rather than an empty slice of the original array. You really can't rely on getting an empty array instead of a null one from a function unless the documentation tells you that. For most purposes, there is no practical difference between a null array and an empty array, so very little code is written which cares about the difference. The only place where I would expect a function in a library to distinguish is if its documentation says that it does (e.g. if returning null means something specific or if it specifically says that the result is a slice of the input). In general, relying on whether a dynamic array is null or not outside of code that you control or functions that are explicit about what they so with null is risky business. Sometimes, I wish that null were not treated as empty, and you were forced to allocate a new array or somesuch rather than having null arrays just work - then you could actually rely on stuff being null or not - but that would also result in a lot more segfaults when people screwed up. The status quo works surprisingly well overall. It just makes it dangerous to do much with distinguishing null arrays from empty ones. - Jonathan M Davis
Having a strange issue with std.net.curl.HTTP as a struct dependency
I'm currently learning D and started working on one of my first
projects which is an API wrapper. I'm currently having an issue
with my program getting a InvalidMemoryOperationError upon
exiting the process on Windows 7. On my Debian VM I get a
segmentation fault.
I have tried to minimize the code as much as I possibly can while
still reproducing the error. Here is the code:
import std.net.curl;
struct ThingA {
HTTP http;
this(HTTP http) {
this.http = http;
arrayOfThingBs();
}
ThingB[] arrayOfThingBs() {
ThingB[] thingBs;
thingBs ~= ThingB(this);
return thingBs;
}
}
struct ThingB {
ThingA thingA;
this(ThingA thingA) {
this.thingA = thingA;
}
}
void main() {
auto http = HTTP();
auto thingA = ThingA(http);
}
If I comment out the HTTP dependency like:
struct ThingA {
//HTTP http;
this(HTTP http) {
//this.http = http;
arrayOfThingBs();
}
ThingB[] arrayOfThingBs() {
ThingB[] thingBs;
thingBs ~= ThingB(this);
return thingBs;
}
}
The error goes away. The error also goes away if
ThingA.arrayOfThingBs returns a single instance of ThingB instead
of an array of ThingB. Removing ThingBs dependency on ThingA also
gets rid of the error. I'm new to low level languages in general
so maybe I'm doing something wrong, but this seems like really
strange behavior.
Re: iterate over variadic
On Sunday, 9 July 2017 at 22:21:59 UTC, FoxyBrown wrote:
How can we iterate over a variadic and have it's index. I'll do
different things depend on if it's an even or odd index, but
seems to be no way to get it.
import std.stdio;
import std.typecons, std.meta;
template indexedAllSatisfy(alias F, T...)
{
bool doTest()
{
bool result = true;
import std.range: iota;
foreach(i; aliasSeqOf!(iota(0, T.length)))
result &= F!(T[i], i, T.length);
return result;
}
enum indexedAllSatisfy = doTest();
}
unittest
{
template evenIntString(T, int index, int length)
{
static if (length & 1)
enum evenIntString = false;
else static if (index & 1)
enum evenIntString = is(T == string);
else
enum evenIntString = is(T == int);
}
static assert(indexedAllSatisfy!(evenIntString, int, string,
int, string));
static assert(!indexedAllSatisfy!(evenIntString, int ,
string, char, Object));
}
Re: iterate over variadic
10.07.2017 01:21, FoxyBrown пишет:
How can we iterate over a variadic and have it's index. I'll do
different things depend on if it's an even or odd index, but seems to be
no way to get it.
auto foo(Types...)()
{
foreach(T; Types)
{
// do what you need
}
}
index could be added like usual
Re: Lazy range, extract only Nth element, set range size constraint?
On 07/09/2017 11:51 PM, biocyberman wrote:
Following is the code for a more generalized Fibonacci range.
Questions:
1. How do I get only the value of the Nth (i.e. N = 25) element in an
idiomatic way?
As you've only got an input range, you have to popFront the 24 values
that come before. You can use std.range.drop:
import std.range : drop;
auto twentyfifth = fib.drop(24).front;
But if you're not sure that the range actually has 25 elements, you
should check `empty`, of course:
import std.range : popFrontN;
fib.popFrontN(24); /* or fib = fib.drop(24); */
if (!fib.empty)
{
auto twentyfifth = fib.front;
}
2. Can I set constraints in the range so that user gets warning if he
asks for Nth element greater than a limit, say N> 30;
You can keep track of N in FibonacciRange and when it hits 30 you throw
an exception or print a message or just set `empty` to true.
You can't make it a compilation warning/error as far as I can tell.
or if the actually
range value at N is greater than datatype limit (e.g. max long)?
You can use std.experimental.checkedint to detect it at run time:
private bool _empty = false;
bool empty() const @property { return _empty; }
void popFront()
{
import std.experimental.checkedint : checked, Throw;
long tmp = 0;
try tmp = (checked!Throw(first)*multifactor + second).get;
catch (Throw.CheckFailure e) _empty = true;
first = second;
second = tmp;
}
(There may be a smarter way than making the operation throw an exception
and catching that.)
Re: Fiber based UI-Toolkit
On 09.07.17 23:12, bauss wrote: > On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote: >> I wonder if there is any fiber based / fiber compatible UI-Toolkit out >> for dlang. The second question is, if it would make sense at all to >> have such a thing? >> >> christian > > It doesn't really make sense to have that, because most (if not all) > operating systems only allow rendering from a single thread and I > believe OSX (possibly macOS too.) only allows it from the main thread. > Which means the only thing you can really operate on other threads are > events, but you'll always have to do callbacks to your UI thread in > order to render. Thanks for answering! you are touching exactly my question: Lets say, that all the event handling is done by fiber-aware code (means all io gives the thread free, when it would block, and perhaps a yield function for calculation heavy operations). It would then I think reduce the "risk" of a ANR (Application not responding (from android) or the famous beachball) without sacrificing the clarity of the code. e.g. you want to download something from a webpage and process the data, if you click a button. you cannot do this in the buttons-onclick callback (because this is usually a long running operation and the callback is called from the main thread). with fibers, the main thread could continue running (and update the screen) as soon as the io thread is blocking or the process thread calls yield (which he should on a regular basis). after the processing as soon as the fiber gets back the control, the result can easily be integrated back into the ui, because its already in the right thread. compare this with the traditionally apporach of spawning a new thread, passing over the arguments, processing it, passing back the result and integrating this into the ui, it could perhaps be "simpler". on the other hand, the process code would get a little bit messy because of the manually inserted yields (as far as i know, the erlang vm for example inserts such instructions automatically every n instructions). what do you think?
iterate over variadic
How can we iterate over a variadic and have it's index. I'll do different things depend on if it's an even or odd index, but seems to be no way to get it.
Lazy range, extract only Nth element, set range size constraint?
Following is the code for a more generalized Fibonacci range.
Questions:
1. How do I get only the value of the Nth (i.e. N = 25) element
in an idiomatic way?
2. Can I set constraints in the range so that user gets warning
if he asks for Nth element greater than a limit, say N> 30; or if
the actually range value at N is greater than datatype limit
(e.g. max long)? Maybe this should be done outside of the range,
i.e. do check before accessing the range?
#!/usr/bin/env rdmd
import std.stdio : writeln;
long multifactor = 4;
int elemth = 25;
struct FibonacciRange
{
long first = 1;
long second = 1;
bool empty() const @property
{
// how to stop at n = 30?
return false;
}
void popFront()
{
long tmp = 0;
tmp = first*multifactor + second;
first = second;
second = tmp;
}
long front() const @property
{
return first;
}
}
void main()
{
import std.range : take;
import std.array : array;
FibonacciRange fib;
auto fib10 = take(fib, elemth);
long[] the10Fibs = array(fib10);
}
Re: Fiber based UI-Toolkit
On Sunday, 9 July 2017 at 21:12:24 UTC, bauss wrote: On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote: I wonder if there is any fiber based / fiber compatible UI-Toolkit out for dlang. The second question is, if it would make sense at all to have such a thing? christian It doesn't really make sense to have that, because most (if not all) operating systems only allow rendering from a single thread and I believe OSX (possibly macOS too.) only allows it from the main thread. Which means the only thing you can really operate on other threads are events, but you'll always have to do callbacks to your UI thread in order to render. Aren't all fibers executed from a single thread?
Re: Fiber based UI-Toolkit
On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote: I wonder if there is any fiber based / fiber compatible UI-Toolkit out for dlang. The second question is, if it would make sense at all to have such a thing? christian It doesn't really make sense to have that, because most (if not all) operating systems only allow rendering from a single thread and I believe OSX (possibly macOS too.) only allows it from the main thread. Which means the only thing you can really operate on other threads are events, but you'll always have to do callbacks to your UI thread in order to render.
Fiber based UI-Toolkit
I wonder if there is any fiber based / fiber compatible UI-Toolkit out for dlang. The second question is, if it would make sense at all to have such a thing? christian
Re: The Nullity Of strings and Its Meaning
On Sunday, 9 July 2017 at 18:55:51 UTC, kdevel wrote: Yes, it can obviously return one of the two representations of the empty D string. The two being null and ""? There are more than those. One for every possible .ptr value.
Re: The Nullity Of strings and Its Meaning
On Sunday, 9 July 2017 at 15:10:56 UTC, ag0aep6g wrote: On 07/09/2017 03:51 PM, kdevel wrote: On Sunday, 9 July 2017 at 10:32:23 UTC, ag0aep6g wrote: [...] A null char* is not a proper C string. A C string is a sequence of storage units containing legitimate character values of which the last one is the NUL character. It doesn't have length 0. It has no length. In C a NULL ptr does not refer to anything including not to a C string. A C function can't return a null char* when it's supposed to return an empty string. That is true. And this it what mislead me thinking that D behaves the same. But a D function can return a null char[] in that case. Yes, it can obviously return one of the two representations of the empty D string. Stefan
Re: NNTP error: Disconnected from server (Connection closed)
On 07/09/2017 06:10 AM, kdevel wrote: What's going on here? Happens all the time. Last time (I think) Martin Nowak had said that a network packet trace would be helpful to debug this issue. Ali
Re: CTFE output is kind of weired
On Sunday, 9 July 2017 at 08:43:47 UTC, Andre Pany wrote: Thanks for all the answers and explanations. I will create an issue to make the assert output more readable. The first 5 times I didn't recognize the slice information at the end of the string and thought dmd isn't working at all anymore. Kind regards André https://issues.dlang.org/show_bug.cgi?id=17627
Re: The Nullity Of strings and Its Meaning
On 07/09/2017 03:51 PM, kdevel wrote: On Sunday, 9 July 2017 at 10:32:23 UTC, ag0aep6g wrote: [...] As mentioned in the subject my posting is about the state of affairs wrt. the (non-)nullity of strings. In C/C++ once a char * variable became non-NULL 'it' never loses this property. In D this is not the case: The non-null value "" 'becomes' null in "".decodeComponent Nullity of D strings is quite different from nullity of C strings. A null D string is a valid string with length 0. A null char* is not a proper C string. It doesn't have length 0. It has no length. A C function can't return a null char* when it's supposed to return an empty string. But a D function can return a null char[] in that case. [...] Sure. But I am writing about the string value which comprises the (non-)nullity of the string. This is not preserved. Just like other pointers are not preserved. In the .ptr field of a D array, a null pointer isn't special. Null arrays aren't special beyond having a unique name. [...] string is not a pointer but a type. To the user of string it is completely irrelevant, if the nullity of the string is implemented by referring to a pointer inside the implementation of string. string is a type that involves a pointer. The type is not opaque. The user can access the pointer. A null array is not some magic (invalid) value. It's just just the one that has a null .ptr and a zero .length. I think that's widely known, but it might not actually be in the spec. At least, I can't find it. The page on arrays [1] just says that "`.init` returns `null`" and that "pointers are initialized to `null`, without saying what null means for arrays. On the `null` expression [2], the spec mentions a "null value" of arrays, but again doesn't say what that means. You also shouldn't rely on it returning null for a null input, even when it currently does that. I assumed that a non-null string is returned for a non-null input. As far as I see, you had no reason to assume that. If the spec or some other document mislead you, it needs fixing. [...] Yes. But that second proposition what not the one chosen in the documentation. It was not chosen because it does not extend to the nontrivial case where one has more than zero elements. ;-) Or the spec's just poorly written there, and wasn't meant the way you've interpreted it. [1] https://dlang.org/spec/arrays.html [2] https://dlang.org/spec/expression.html#null
Re: The Nullity Of strings and Its Meaning
On Sunday, 9 July 2017 at 13:51:44 UTC, kdevel wrote: But that second proposition what not the one chosen in the documentation. Shall read: "But that second predicate was not the one chosen in the documentation."
Re: The Nullity Of strings and Its Meaning
On Sunday, 9 July 2017 at 10:32:23 UTC, ag0aep6g wrote: On 07/09/2017 01:12 AM, kdevel wrote: On Saturday, 8 July 2017 at 18:39:47 UTC, ag0aep6g wrote: On 07/08/2017 07:16 PM, kdevel wrote: [...] Moreover everything I've written about strings is also valid for e.g. dynamic arrays of doubles. Here there are also two different kinds of empty arrays which compare equal but are not identical. I see no purpose for that. So you'd make `arr1 is arr2` true when they're empty, ignoring a difference in pointers. Otherwise, it would still compare pointers. Right? As a D novice am not in the position to suggest changes in the language (yet). I would appreciate a documentation that accurately represents what is implemented. I don't think that's a good idea, simply because it's a special case. I noticed that you haven't mentioned `==`. You're probably aware of it, but if not we might be talking past each other. So, just to be clear: You can also compare arrays with `==` which compares elements. `null == ""` is true. As mentioned in the subject my posting is about the state of affairs wrt. the (non-)nullity of strings. In C/C++ once a char * variable became non-NULL 'it' never loses this property. In D this is not the case: The non-null value "" 'becomes' null in "".decodeComponent You only get surprised if you expect that to check for emptiness (or something else entirely). As mentioned I was surprised, that the non-nullity did not pass thru decodeComponent. decodeComponent doesn't seem to return the same (identical) string you pass it, most of the time. Sure. But I am writing about the string value which comprises the (non-)nullity of the string. This is not preserved. [...] decodeComponent simply gives no promise of preserving pointers. string is not a pointer but a type. To the user of string it is completely irrelevant, if the nullity of the string is implemented by referring to a pointer inside the implementation of string. You also shouldn't rely on it returning null for a null input, even when it currently does that. I assumed that a non-null string is returned for a non-null input. The spec isn't very clear there. What does "the same array elements" mean for empty arrays? Mathematically that's easily answered: https://en.wikipedia.org/wiki/Universal_quantification#The_empty_set So "two empty arrays refer to the same elements" is true because everything said about the elements of empty arrays is true? Is "two empty arrays do *not* refer to the same elements" also true? Yes. But that second proposition what not the one chosen in the documentation. It was not chosen because it does not extend to the nontrivial case where one has more than zero elements. ;-) Stefan
Re: The Nullity Of strings and Its Meaning
On Saturday, 8 July 2017 at 23:12:15 UTC, Jonathan M Davis wrote: On Saturday, July 8, 2017 5:16:51 PM MDT kdevel via Digitalmars-d-learn wrote: [...] IMHO, if you want to check for empty, then you should use the empty property or check length directly, since those are clear about your intent, whereas with My starting point wasn't to check for emptiness but the question if I can use the additional two states (string var is null or !is null) of a string variable to indicate if a value is absent. If you understand all of this, it is perfectly possible to write code which treats null arrays as distinct from empty arrays. However, it's _very_ easy to get into a situation where you have an empty array rather than a null one. My case was: I get a null one from "".decodeComponent where I did not expect it. (cf. my corrected example in my post "13 hours ago", i.e Saturday, 08 July 2017, 23:12:20 +00:00). Pretty much as soon as you do anything to a null array other than pass it around or compare it, trusting that it's still null can get error-prone. It's the other way round. I was assuming that it is still not null (My example in my first post was wrong). [...] Personally, I think that it can make sense to have a function explicitly return null to indicate something, but beyond that, I'd actually consider using std.typecons.Nullable to make the whole thing clear, even if it is a bit dumb to have to wrap a nullable type in a Nullable to treat it as null. You hit the nail on the head. Stefan
NNTP error: Disconnected from server (Connection closed)
What's going on here?
Re: The Nullity Of strings and Its Meaning
On 07/09/2017 01:12 AM, kdevel wrote:
On Saturday, 8 July 2017 at 18:39:47 UTC, ag0aep6g wrote:
On 07/08/2017 07:16 PM, kdevel wrote:
null is one specific array. It happens to be empty, but that doesn't
really matter. `foo is null` compares with the null array. It doesn't
check for emptiness. Conversion to bool also compares with null. The
concept of emptiness is unrelated.
But why? What is the intended use of converting a string (or any other
dynamic array) to bool?
As I said: I wouldn't mind if it went away. I don't see a strong use
case that justifies the non-obvious behavior of `if (arr)`. But
apparently it is being used, and breaking code is a no-no.
As for how it's used, I'd start digging at the link Timon has posted.
In Issue 17623 Vladimir pointed out, that in the case of strings there
may be a need to store an empty D-string which also is a NUL-terminated
C-String. It would be sufficient if the ptr-Value would convert for
checking if there is a valid part of memory containing the NUL byte.
But just looking at .ptr doesn't tell if there's a '\0'. You'd have to
dereference the pointer too.
And that's not what Vladimir is getting at. Issue 17623 is about `arr1
is arr2`, not about conversions to bool like `if (arr)`. It makes sense
that `null !is ""`. They're not "the same". One place where the
difference matters is when working with C strings.
Issue 17623 is absolutely valid. But it's much more likely that the spec
will be changed rather than the implementation.
Moreover everything I've written about strings is also valid for e.g.
dynamic arrays of doubles. Here there are also two different kinds of
empty arrays which compare equal but are not identical. I see no purpose
for that.
So you'd make `arr1 is arr2` true when they're empty, ignoring a
difference in pointers. Otherwise, it would still compare pointers. Right?
I don't think that's a good idea, simply because it's a special case.
I noticed that you haven't mentioned `==`. You're probably aware of it,
but if not we might be talking past each other. So, just to be clear:
You can also compare arrays with `==` which compares elements. `null ==
""` is true.
You only get surprised if you expect that to check for emptiness (or
something else entirely).
As mentioned I was surprised, that the non-nullity did not pass thru
decodeComponent.
decodeComponent doesn't seem to return the same (identical) string you
pass it, most of the time. Try "foo":
void main()
{
import std.uri;
string a = "foo";
auto s = a.decodeComponent;
assert(s == a); /* passes */
assert(s is a); /* fails */
}
decodeComponent simply gives no promise of preserving pointers. You also
shouldn't rely on it returning null for a null input, even when it
currently does that.
The spec isn't very clear there. What does "the same array elements"
mean for empty arrays?
Mathematically that's easily answered:
https://en.wikipedia.org/wiki/Universal_quantification#The_empty_set
So "two empty arrays refer to the same elements" is true because
everything said about the elements of empty arrays is true? Is "two
empty arrays do *not* refer to the same elements" also true?
Is runtime info in shared memory?
When I look at ldc2's object.d I have the impression it's thread local. I may be wrong though, just beginning to learn about 'shared'.
Re: CTFE output is kind of weired
On Sunday, 9 July 2017 at 06:48:30 UTC, Stefan Koch wrote: On Sunday, 9 July 2017 at 04:03:09 UTC, H. S. Teoh wrote: On Sat, Jul 08, 2017 at 03:09:09PM -0700, Ali Çehreli via Digitalmars-d-learn wrote: On 07/08/2017 02:29 PM, Andre Pany wrote: > I use assert(false, tmp) to see the content of variable tmp > as it seems there is no other way in CTFE. A more natural way is pragma(msg), which you can use in main in this case: [...] Unfortunately, pragma(msg) can only be used *after* CTFE has finished. It's not possible to print the message *during* CTFE. Stefan Koch allegedly will add a ctfeWriteln to his new CTFE engine that should alleviate this limitation. T In fact ctfeWriteln harder to do for newCTFE then it is in the old interpreter. I suggest people stick with either returning a string or assert(0, message). Thanks for all the answers and explanations. I will create an issue to make the assert output more readable. The first 5 times I didn't recognize the slice information at the end of the string and thought dmd isn't working at all anymore. Kind regards André
