Re: Can you move a disabled this(this) struct in to a container type if it's an rvalue?
On Thursday, 13 December 2018 at 23:33:39 UTC, Stanislav Blinov wrote: On Thursday, 13 December 2018 at 13:17:05 UTC, aliak wrote: [...] Hypothetically, yes, e.g. an object that contains references to itself. However, D operates on the assumption that you don't have such objects. And even though it can't be statically checked, move and swap do actually perform this check at runtime in debug builds. Operating under that rule, it should be legal to move any values that are passed to you. In fact, I postulate that it *must* be done instead of making copies. Unfortunately, Phobos doesn't agree. [...] Oh cool! An isRef trait. TIL! And I see, thank you all for the tips!
How to define class type array?
Java code:
```java
class A extends Node {}
class B extends Node {}
class C extends Node {}
@Override public Set> getNodes() {
return new HashSet<>(Arrays.asList(
A.class,
B.class,
C.class
));
}
```
For dlang like this?
```D
class A : Node {}
class B : Node {}
class C : Node {}
override public Set!Node getNodes() {
return new HashSet!Node([
typeid(A),
typeid(B),
typeid(C)
]);
}
```
Re: How to initialize a globle variable nicely and properly?
On Saturday, 15 December 2018 at 03:48:15 UTC, Neia Neutuladh
wrote:
On Sat, 15 Dec 2018 02:54:55 +, Heromyth wrote:
shared static this() {
writeln("running A in shared static this(),
sharedField=", sharedField);
Thread th = new Thread(() { });
th.start();
When you start a D thread, thread-local static constructors get
run. So don't start threads until your shared static
constructors finish.
If I encountered something like this, I would set up a queue of
actions to be run at the start of main() and fill them with
static constructors. Instead of this static constructor
creating a thread, it would enqueue a delegate that starts the
thread.
Yes, it's very dangerous to create a new thread in shared static
this(). For a big project, it sometimes hard to identify this
problem. Maybe, the compiler should do something for this, should
it?
Re: How to initialize a globle variable nicely and properly?
On Sat, 15 Dec 2018 13:49:03 +, Heromyth wrote: > Yes, it's very dangerous to create a new thread in shared static this(). > For a big project, it sometimes hard to identify this problem. Maybe, > the compiler should do something for this, should it? The runtime, more likely. There are plenty of problems in this vein that the compiler can't detect, but the runtime should be able to detect all of them. Filed https://issues.dlang.org/show_bug.cgi?id=19492
Shared static this() not executed for unittest
Spec 27.5 states: "Unit tests, when enabled, are run after all
static initialization is complete and before the main() function
is called. " (https://dlang.org/spec/unittest.html)
main.d:
---
import std.stdio;
shared static this()
{
import vibe.core.log;
setLogLevel(LogLevel.trace);
logDebug("log: statc this");
WRITELN("WRiteln: static this");
}
void main()
{
writeln("Edit source/app.d to start your project.");
}
test.d:
---
import std.stdio;
unittest
{
import vibe.core.log;
logDebug("log: unittest");
writeln("writeln: unittest");
}
Running `dub test` will output:
Running ./unit-test-library
writeln: unittest
All unit tests have been run successfully.
Why is the `shared static this()` not executed?
Re: Shared static this() not executed for unittest
On Sat, 15 Dec 2018 17:19:05 +, Timoses wrote: > Running `dub test` will output: > Running ./unit-test-library writeln: unittest All unit tests have been > run successfully. > > Why is the `shared static this()` not executed? Run `dub clean; dub test -v` and you'll see that main.d isn't compiled into the test library. dub test substitutes its own main() function over yours. In order to do this, it needs to not compile in your main() and to compile in its own. dmd doesn't have an option to replace main(), so dub drops that entire source file.
Re: Shared static this() not executed for unittest
A look into `dub test --vverbose` showed that ./source/app.d is not even included in the compilcation step...
mir.ndslice: assign a vector to a matrix row
Hi
I am wondering if it is possible to assign a vector to a row of a
matrix?
main.d ==
import mir.ndslice;
void main() {
auto matrix = slice!double(3, 4);
matrix[] = 0;
matrix.diagonal[] = 1;
auto row = matrix[0];
row[3] = 4;
assert(matrix[0, 3] == 4);
// assign it to rows of a matrix?
auto vector = sliced!(double)([10, 11, 12, 13]);
// ??? Here I would like to assign the vector to the last (but
it is not working)
// matrix[2] = vector;
}
So I am wondering what the correct way is to do such an
assignment without looping?
Re: Native PDB Error
On Wednesday, 7 November 2018 at 14:43:07 UTC, Chris M. wrote: On Wednesday, 7 November 2018 at 01:37:29 UTC, Chris M. wrote: On Tuesday, 29 May 2018 at 07:47:07 UTC, Begah wrote: [...] This works fine on my home Win10 machine, dmd 2.082/2.083 + dub 1.11.0, installed using the executable from the downloads page. However I've had this same issue on my work PC for which I'll have to double-check my setup tomorrow. Reproduced the issue on my work machine with dmd 2.082, dub 1.9.0/1.11.0, so it seems to be a dmd issue. The only difference is that my work machine is using mingw libraries rather than Microsoft build tools. Bump. Encountering the same issue. Just reinstalled Windows and having the same error on DMD32 D Compiler v2.083.1 .
Re: Native PDB Error
On Saturday, 15 December 2018 at 20:54:03 UTC, JN wrote: Bump. Encountering the same issue. Just reinstalled Windows and having the same error on DMD32 D Compiler v2.083.1 . OK, fixed it. Since it's the first hit from Google, here's a solution: https://www.reddit.com/r/roguelikedev/comments/8s5x5n/roguelikedev_does_the_complete_roguelike_tutorial/e11p66q/ "What I did to fix it was install Visual Studio 2017 Community, then go into the VS installer and add both the "Desktop Development With C++" and "Game Development With C++" workloads. It is not enough to just install Visual Studio, and the C++ Build Tools do not have the sufficient .lib files to build the game." The Game development pack is probably unnecessary, since it's DirectX and stuff, but I installed it just to be safe.
Re: Shared static this() not executed for unittest
On Saturday, December 15, 2018 10:27:36 AM MST Neia Neutuladh via
Digitalmars-d-learn wrote:
> On Sat, 15 Dec 2018 17:19:05 +, Timoses wrote:
> > Running `dub test` will output:
> > Running ./unit-test-library writeln: unittest All unit tests have been
> > run successfully.
> >
> > Why is the `shared static this()` not executed?
>
> Run `dub clean; dub test -v` and you'll see that main.d isn't compiled
> into the test library.
>
> dub test substitutes its own main() function over yours. In order to do
> this, it needs to not compile in your main() and to compile in its own.
> dmd doesn't have an option to replace main(), so dub drops that entire
> source file.
Yeah. I hate how dub does this. I've been bitten by it on multiple
occasions, and it's really easy to miss that this is happening. It probably
would have been better if it required you to deal with main when the target
type is an executable, resulting in a linker error when you didn't provide
one. Instead, a number of us do stuff like
version(unittest) void main() {}
void main()
{
...
}
thinking that it's working, but whatever tests in the module with main
simply don't get run, because that module isn't compiled in. Maybe dub
should check the module with main to see if it contains any unittest blocks
and print out warning if it does, but even if it did, it actually wouldn't
have caught this case, because it involves a static constructor, not a
unittest block.
Anyway, the way that dub deals with this probably makes it so that the best
thing to do in general is to make it so that the module with main is pretty
much literally something like
int main(string[] args)
{
import somemodulename;
return realmain(args);
}
But of course, that just makes it so that you're less likely to accidentally
do something like create a static this which won't be called with -unittest
when you already know that that sort of thing is a problem with dub test. It
doesn't help those folks who aren't aware of this behavior or who forget it.
- Jonathan M Davis
Orphan format arguments: args[0..1]
This one confused me until I decided to talk to a rubber ducky:
import std.string;
void main() {
auto s = "%s is a good number".format(42);
}
Fine; it works... Then the string becomes too long and I split it:
auto s = "%s is a good number but one needs to know" ~
" what the question exactly was.".format(42);
Now there is a compilation error:
Orphan format arguments: args[0..1]
What? Is that a bug in format? It can't be because the string should be
concatenated by the compiler as a single string, no? No: operator dot
has precedence over ~, so format is applied to the second part of the
string before the concatenation. Doh! This puzzled me a lot.
Anyway, the solution, once again, is to use parentheses:
auto s = ("%s is a good number but one needs to know" ~
" what the question exactly was.").format(42);
Ali
Re: Can you move a disabled this(this) struct in to a container type if it's an rvalue?
On Thursday, 13 December 2018 at 23:33:39 UTC, Stanislav Blinov wrote: On Thursday, 13 December 2018 at 13:17:05 UTC, aliak wrote: Ah. Is there any case where you would not want to do that when you have a T value as parameter? Hypothetically, yes, e.g. an object that contains references to itself. However, D operates on the assumption that you don't have such objects. The spec actually forbids you creating self referencing structs. DIP 1014 tackles that. For the spec, see https://dlang.org/spec/garbage.html#pointers_and_gc
erlang NIF written in D?
I'm curious if it'd be possible to write erlang NIFs in D? From reading Interfacing to C, it seems like I'd need to generate a D interface file for the [not insignificant] erl_nif header, and then I'd be able to create a -shared file from D code and load it like any other shared object in Erlang?
