Re: Installing D on Fresh Windows 10 machine is a pain
DMD x86 on Windows have no dependencies, just unpack .zip and use. It's a pitty, that DMD x64 depend on VS :(
Re: How do I convert an ISO 8601 datetime into a unix timestamp - at compile-time?
On Friday, 28 August 2020 at 01:54:02 UTC, Andrej Mitrovic wrote:
-
import std.datetime;
void main ()
{
static time =
SysTime(DateTime.fromISOString("20220101T00")).toUnixTime;
}
-
I think I'm supposed to use MonoTime here, right?
How do I convert an ISO 8601 datetime into a unix timestamp - at compile-time?
-
import std.datetime;
void main ()
{
static time =
SysTime(DateTime.fromISOString("20220101T00")).toUnixTime;
}
-
-
/Library/D/dmd/src/phobos/std/concurrency.d(2574): Error: static
variable lock cannot be read at compile time
/Library/D/dmd/src/phobos/std/concurrency.d(2574):called
from here: atomicLoad(lock)
/Library/D/dmd/src/phobos/std/concurrency.d(2600):called
from here: initOnceLock()
/Library/D/dmd/src/phobos/std/concurrency.d(2600):called
from here: initOnce(delegate shared(bool)() pure @nogc @safe =>
init(), initOnceLock())
/Library/D/dmd/src/phobos/std/datetime/timezone.d(1106):
called from here: initOnce(delegate shared(bool)() pure nothrow
@nogc @safe => (*function () nothrow @nogc @safe => true)())
/Library/D/dmd/src/phobos/std/datetime/timezone.d(546):
called from here: (*& singleton)()
/Library/D/dmd/src/phobos/std/datetime/systime.d(524):
called from here: opCall()
/Library/D/dmd/src/phobos/std/datetime/systime.d(472):
called from here: this.this(dateTime, zero(), tz)
test.d(6):called from here: SysTime(0L, Rebindable(null,
)).this(fromISOString("20220101T00"), null)
-
I'm sure there must be a better way to do this. But I couldn't
find it in the documentation.
Re: Shallow copy object when type is know
On Thursday, 21 April 2016 at 11:53:13 UTC, rumbu wrote:
On Wednesday, 20 April 2016 at 12:32:48 UTC, Tofu Ninja wrote:
Is there a way to shallow copy an object when the type is
known? I cant seem to figure out if there is a standard way. I
can't just implement a copy function for the class, I need a
generic solution.
extern (C) Object _d_newclass(TypeInfo_Class ci);
Object dup(Object obj)
{
if (obj is null)
return null;
ClassInfo ci = obj.classinfo;
size_t start = Object.classinfo.init.length;
size_t end = ci.init.length;
Object clone = _d_newclass(ci);
(cast(void*)clone)[start .. end] = (cast(void*)obj)[start
.. end];
return clone;
}
Is this the established D-idiom of a generic class bit-wise clone
function (as of 2020)?
Any risk of using this implementation I should be aware of?
Thanks.
Re: in; scope; scope ref; DIP1000; documentation
On 27.08.20 20:49, James Blachly wrote:
1. The thread involves 'in' qualifier. Documentation
(https://dlang.org/spec/function.html#param-storage) indicates that `in`
is defined as `scope const` and should not be used as it is not
implemented. **Is this [fact and recommendation] still true?**
There is this:
https://dlang.org/changelog/2.092.0.html#preview-in
Which says that `in` is planned to become `const scope` in the future
and there is a preview switch for it: `-preview=in`.
But these are both false (with and without `-preview=in`):
is(void function (in int* x) == void function (const int* x))
is(void function (in int* x) == void function (scope const int* x))
So `in` is not strictly equivalent to anything else. I'd say the
recommendation is good: Avoid `in` until that stuff is sorted out and
`in` actually gets lowered to `scope const` (or whatever it ends up
meaning).
[...]
Is "scope ref" documented somewhere specifically? I found
https://dlang.org/spec/function.html#scope-parameters which discusses
the use of `scope` with ref type parameters, but the example given is
pointer-based. Is it correct that `scope ref T` behaves the same as
`scope T*` ?
I don't think there's documentation for `scope ref`. That may be because
`scope` doesn't affect `ref`. This is a corner of DIP 1000 that keeps
confusing me.
Consider this function:
int* fp(scope int** p) { return *p; }
This compiles with `-preview=dip1000`. That's because the `scope` only
applies to the outer pointer. It doesn't apply to the inner one. So
returning the inner pointer is fine. At least, that's how I understand
DIP 1000.
Now consider this one:
int* fr(scope ref int* r) { return r; }
One might expect the same result for fr. A `ref` is pretty much the same
thing as a pointer, isn't it? But you actually get an error: "scope
variable `r` may not be returned". I think that's because the `scope`
doesn't apply to the `ref` part of the parameter; it applies to the pointer.
Similarly, this compiles:
int* fp(int* p) { return p; }
But this doesn't:
int* fr(ref int r) { return &r; }
Apparently, a `ref` is not "pretty much the same thing as a pointer".
It's more restricted. It acts like a `scope` pointer without needing the
`scope` annotation. Unfortunately, this isn't documented, as far as I
can tell.
Regarding `scope` more generally, DIP1000 shows as "superseded" -- **can
I still rely on this document for guidance?** We have a `-dip1000` flag
but a superseded DIP. The discordance is extremely confusing.
I am glad D is iterating quickly and improving on safety, but I have
found that documentation may not well recent changes in this area.
Agreed. The documentation is in a bad state. The information is spread
over documents, forum posts, and of course the implementation in DMD.
And all of those are wrong/outdated in parts.
Regarding the different sources of information:
1) Start with the spec
(). Unlike DIP
documents, the spec is being updated. It might be incomplete or have
errors, but it at least has a chance to get fixed.
2) Ignore the DIP document
().
Only refer to it as a last resort. Any other source is more likely to be
correct.
3) Do check what the compiler does, but don't trust it blindly. The
implementation still has some serious bugs. A personal favorite:
4) Bugzilla (): If a bug report demonstrates a
safety violation with only @safe code, it's valid. If it doesn't,
there's a significant chance that the reporter missed some detail about
`scope` and the issue ends up being invalid.
Consequently I am reluctant to use (newer) features related to memory
safety. If this is all comprehensively documented somewhere please let
me know!
For the time being, I think it's perfectly fine to ignore
`-preview=dip1000`. The feature is clearly not finished.
Re: Vibe.d timer - change callback?
On Tuesday, 25 August 2020 at 18:42:53 UTC, codic wrote:
I'd like to be able to change the callback of a vibe.d Timer
(eg created with
http://vibe-core.dpldocs.info/v1.9.3/vibe.core.core.createTimer.html) after creation, something like:
auto timer = createTimer();
timer.rearm(duration, /*...*/);
timer.callback = delegate {
// things
}
Would creating a dynamic redirection function as delegate serve
your purpose?
https://dlang.org/library/std/functional/to_delegate.html
You can also pass object having `opCall` to `to_delegate` and th
is could also provide dynamic dispatch.
in; scope; scope ref; DIP1000; documentation
Peeling off from Mathias Lang's thread in General about making 'in' useful, for some novice questions: 1. The thread involves 'in' qualifier. Documentation (https://dlang.org/spec/function.html#param-storage) indicates that `in` is defined as `scope const` and should not be used as it is not implemented. **Is this [fact and recommendation] still true?** 2. Regarding scope: On 8/5/20 3:27 AM, Fynn Schröder wrote: On Friday, 31 July 2020 at 21:49:25 UTC, Mathias LANG wrote: I hope this will generate interest with people hitting the same problem. I've literally yesterday written some new code with `const scope ref` in almost every function to pass large, complex structs. Occasionally, I had to store rvalues temporarily to pass as lvalues (non-templated code). I would rather simply put `in` on those parameters :-) It's a lot easier to grasp function signatures only using `in` and `out` on parameters (and their effect/purpose being immediately obvious to new D programmers!) Is "scope ref" documented somewhere specifically? I found https://dlang.org/spec/function.html#scope-parameters which discusses the use of `scope` with ref type parameters, but the example given is pointer-based. Is it correct that `scope ref T` behaves the same as `scope T*` ? Regarding `scope` more generally, DIP1000 shows as "superseded" -- **can I still rely on this document for guidance?** We have a `-dip1000` flag but a superseded DIP. The discordance is extremely confusing. I am glad D is iterating quickly and improving on safety, but I have found that documentation may not well recent changes in this area. Consequently I am reluctant to use (newer) features related to memory safety. If this is all comprehensively documented somewhere please let me know!
Re: Vibe.d timer - change callback?
On Tuesday, 25 August 2020 at 18:42:53 UTC, codic wrote:
I'd like to be able to change the callback of a vibe.d Timer
(eg created with
http://vibe-core.dpldocs.info/v1.9.3/vibe.core.core.createTimer.html) after creation, something like:
auto timer = createTimer();
timer.rearm(duration, /*...*/);
timer.callback = delegate {
// things
}
An alternative method would be to recreate the timer, like so:
auto timer = createTimer();
timer.rearm(duration, /*...*/);
auto timer = createTimer();
timer.rearm(duration - timer.elapsed);
However, I can't find an `elapsed` property or similar in the
documentation.
I did not try it myself, but you can make an object which is
accessible from both callback scope and outside scope. Depending
on the state of the object it will call different functions. So
if you want to change the callback in the meantime, you just
change the state of the object.
Re: Installing D on Fresh Windows 10 machine is a pain
On Thursday, 27 August 2020 at 17:34:03 UTC, bachmeier wrote: It would be nice to have a screencast of this for someone that doesn't work often with Windows. There are screenshots in the VS docs, e.g., https://docs.microsoft.com/en-us/visualstudio/install/modify-visual-studio?view=vs-2019 And videos on YouTube.
Re: Installing D on Fresh Windows 10 machine is a pain
On Thursday, 27 August 2020 at 16:44:28 UTC, Mike Parker wrote: On Thursday, 27 August 2020 at 16:39:05 UTC, Mike Parker wrote: Or maybe better, just go to the 'Individual components', select the latest Windows 10 SDK version, and install it. Or just check the installation folder. For me, it's: C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\ucrt\x64 It would be nice to have a screencast of this for someone that doesn't work often with Windows.
Re: Installing D on Fresh Windows 10 machine is a pain
On Thursday, 27 August 2020 at 16:39:05 UTC, Mike Parker wrote: Or maybe better, just go to the 'Individual components', select the latest Windows 10 SDK version, and install it. Or just check the installation folder. For me, it's: C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\ucrt\x64
Re: Installing D on Fresh Windows 10 machine is a pain
On Thursday, 27 August 2020 at 15:59:51 UTC, Jesse Phillips wrote: Installing D isn't new to me but I haven't really had to do a fresh install for awhile and come from a time when I was installing VS from 2010 and up. VS 2019 Professional is installed on the system. I have installed the C++ desktop development for VS. DMD installer still is unable to find "VS installed" I've also installed the C++ 2010 redistributables to try and use the MinGW install path. I've also utilized the developer command prompt --- Upon compiling a 64bit hello world I get helloworld> dmd -m64 .\hello.d LINK : fatal error LNK1104: cannot open file 'libucrt.lib' Error: linker exited with status 1104 This appears to have been a library moved around VS 2015 release, and I don't want to do the copying around solution the internet suggests. I understand that as a compiler it is important to support systems of an older nature and so updating to the latest C++ runtimes might hinder usage of D. It is just sad that at one point the install really did just take care of things and now it can't find things. It has worked for me every time I've installed it since VS 2015. libucrt.lib should have been installed by the VS installer. Something to check: run the installer again, click the checkbox in corner of the 'Desktop development with C++' box, then look under the 'Installation details' list that comes up and make sure a version of the Windows 10 SDK is installed. If you don't see one with a check next to it, then check the latest one and modify the installation.
Re: Installing D on Fresh Windows 10 machine is a pain
On Thursday, 27 August 2020 at 16:35:07 UTC, Mike Parker wrote: It has worked for me every time I've installed it since VS 2015. libucrt.lib should have been installed by the VS installer. Something to check: run the installer again, click the checkbox in corner of the 'Desktop development with C++' box, then look under the 'Installation details' list that comes up and make sure a version of the Windows 10 SDK is installed. If you don't see one with a check next to it, then check the latest one and modify the installation. Or maybe better, just go to the 'Individual components', select the latest Windows 10 SDK version, and install it.
Re: Installing D on Fresh Windows 10 machine is a pain
On Thursday, 27 August 2020 at 15:59:51 UTC, Jesse Phillips wrote: Upon compiling a 64bit hello world I get helloworld> dmd -m64 .\hello.d LINK : fatal error LNK1104: cannot open file 'libucrt.lib' Error: linker exited with status 1104 I solved this by either installing c++ development tools from Community or by switching my path to the 64bit DMD.
Installing D on Fresh Windows 10 machine is a pain
Installing D isn't new to me but I haven't really had to do a fresh install for awhile and come from a time when I was installing VS from 2010 and up. VS 2019 Professional is installed on the system. I have installed the C++ desktop development for VS. DMD installer still is unable to find "VS installed" I've also installed the C++ 2010 redistributables to try and use the MinGW install path. I've also utilized the developer command prompt --- Upon compiling a 64bit hello world I get helloworld> dmd -m64 .\hello.d LINK : fatal error LNK1104: cannot open file 'libucrt.lib' Error: linker exited with status 1104 This appears to have been a library moved around VS 2015 release, and I don't want to do the copying around solution the internet suggests. I understand that as a compiler it is important to support systems of an older nature and so updating to the latest C++ runtimes might hinder usage of D. It is just sad that at one point the install really did just take care of things and now it can't find things.
