Re: Can't I allocate at descontructor?
On 3/5/21 8:29 PM, Jack wrote:
> Now about the behavior of a static destructor, like static ~this() { }
> is this guaranteed to be run?
I don't know any way of creating a module on the GC heap so their
destruction should not be related to GC collection. I would expect all
'static ~this()' blocks to be executed upon thread termination.
'shared static ~this()' blocks are said to be executed after main()
exits in the following page but that description is not precise enough
because 'shared static ~this()' blocks of a dynamic library would be
executed when the library is unloaded.
https://dlang.org/spec/class.html#SharedStaticConstructor
Ali
Re: Can't I allocate at descontructor?
On Saturday, 6 March 2021 at 04:29:41 UTC, Jack wrote:
Now about the behavior of a static destructor, like static
~this() { } is this guaranteed to be run?
Yes. Some perspective:
1. During program execution, class/struct destructors on
stack-allocated instances are invoked when the instances go out
of scope.
2. During program execution, class/struct destructors on
GC-allocated instances are only called when the GC determines the
instances are no longer referenced AND it needs to reclaim
memory. There is no way to know when or if this will happen
during the program's execution. Short-lived programs may never
need to reclaim memory, so the destructors may never be called.
The longer a program runs, and the more it allocates from the GC
heap, the more likely it is that a given object's destructor will
be called during execution since the GC will need to reclaim
memory more often. This is a consequence of relying on the GC to
manage memory.
3. After the main function exits, the runtime will invoke all
module destructors. They do not belong to any class or struct
instance, nor are they managed by the GC. They will always
execute.
4. After module destructors are invoked, the GC will begin its
shutdown. By default, it will invoke the destructors on every
class/struct instance for which it hasn't. This can be disabled
via a command-line argument for DRuntime.
So with the current implementation, all GC-managed class and
struct destructors will end up being called at some point. But
the spec does not require the GC to invoke destructors during
shutdown--that's an implementation detail. Moreover, since the
person executing the program can turn that behavior off via a
command-line argument, you can't rely on the default behavior
anyway. So that's why the documentation says that class and
struct destructors are not guaranteed to be invoked by the GC.
Re: Can't I allocate at descontructor?
On Friday, 5 March 2021 at 21:24:08 UTC, tsbockman wrote:
On Friday, 5 March 2021 at 21:17:24 UTC, tsbockman wrote:
On Friday, 5 March 2021 at 21:02:08 UTC, H. S. Teoh wrote:
class C {...}
import core.memory : GC;
C c = cast(C) GC.malloc(C.sizeof);
...
...
import core.memory : GC;
C c = cast(C) GC.malloc(C.sizeof);
...
Also, that's not the correct way to manually allocate a class
on the heap. C.sizeof is the size of a reference to C, not an
instance of C, and we need to blit and construct the instance
before it is safe to use:
import core.memory : GC;
C c = cast(C) GC.malloc(__traits(classInstanceSize, C));
import core.lifetime : emplace;
emplace(c, anyConstructorArgsGoHere);
...
good catch, thanks
Re: Can't I allocate at descontructor?
On Friday, 5 March 2021 at 21:25:52 UTC, Ali Çehreli wrote:
On 3/5/21 12:57 PM, Jack wrote:
>> destroy() executes the destructor.
>
> but I would need to call it manually and only after I
somewhat I've
> determined I no longer need the resources, right? so
destroy(c) would be
> no different from calling my own finalize-like method like
freeResources()?
Yes but perhaps with some extra functionality like the optional
'initialize':
https://dlang.org/phobos/object.html#.destroy
Ali
Now about the behavior of a static destructor, like static
~this() { } is this guaranteed to be run?
Re: Can't I allocate at descontructor?
On Friday, 5 March 2021 at 21:02:08 UTC, H. S. Teoh wrote:
On Fri, Mar 05, 2021 at 08:24:26PM +, Jack via
Digitalmars-d-learn wrote:
On Friday, 5 March 2021 at 20:18:44 UTC, Max Haughton wrote:
> On Friday, 5 March 2021 at 20:13:54 UTC, Jack wrote:
[...]
> > But the ones heap may never run at all, is that right?
>
> You can't rely on the garbage collector for deterministic
> destruction, no.
Are there some kind of replacement or I have to make my own
finalize-like method, once I determine somewhat the
application no longer need those resources?
[...]
If you know when you can deallocate something, that means you
don't need the GC to collect it,
I'll modify the program so that I know the right state to call my
finalize-like method or just destroy(c). Until I find out that
destrutor behavior, I was going to just use the destrutor
so you could just allocate it
on the malloc heap instead, and call destroy/free once you're
done. You could use the C version of malloc/free. You can
also optionally use GC.malloc/GC.free.
E.g.:
class C {...}
import core.memory : GC;
C c = cast(C) GC.malloc(C.sizeof);
... // use c
// We're done with c, destroy it
destroy(c); // this will call the dtor
GC.free(cast(void*) c);
c = null; // optional, just to ensure we don't accidentally
use it again
T
I'll do something like this, thanks
Re: Is there any generic iteration function that stops at first match?
On Friday, 5 March 2021 at 02:13:39 UTC, Jack wrote: something like filter[1] but that stops at first match? are there any native functions for this in D or I have to write one? just making sure to not reinvent the wheel [1]: https://devdocs.io/d/std_algorithm_iteration#filter std.algorithm.searching.find To summarize. * filter.front * find.front * until * find The first two provide you data at the first match, `until` produces a range exclusive of the first match. If you just use find it will produce a range that starts at the first match, unlike filter the range includes everything and not just the matching data.
Re: D's Continous Changing
On Friday, 5 March 2021 at 07:51:24 UTC, Siemargl wrote: On Friday, 5 March 2021 at 03:32:35 UTC, harakim wrote: I want this almost every week at work. When I run into some trivial statement that I need to know for sure how it works, it's rarely worth it to create a whole new file and make a main method and all that. I just edit and run the entire program again, which is a waste of time. So about ten seconds later: PS> rdmd --eval="writeln(format!`%b`(5));" ~\AppData\Local\Temp\.rdmd\eval.F4ADE5F0F88B126B82870415B197BF60.d(18): Error: template argument expected following `!` Failed: ["C:\\Program Files\\D\\dmd2\\windows\\bin\\dmd.exe", "-d", "-v", "-o-", "~\\AppData\\Local\\Temp\\.rdmd\\eval.F4ADE5F0F88B126B82870415B197BF60.d", "-I~\\AppData\\Local\\Temp\\.rdmd"] PS> rdmd --eval="writeln(__VERSION__);" 2095 That was pretty sweet. However, it kind of goes to the point of my post. A one-revision difference means the documentation is not accurate for my compiler. This is problem with Powershell. (May by need to create bugreport ?) This example runs fine from CMD (but i recommend FAR for conveniety) and fails from PS. Tested Win10.1909, dmd 2.095 The file never includes the quote marks for some reason, I've tried a few different ways although I haven't been able to figure out why yet. The documentation for powershell says it should work. This undocumented feature works though: PS> rdmd --eval='writeln(format!`"%b`"(78));' 1001110 On Friday, 5 March 2021 at 03:35:31 UTC, Mike Parker wrote: On Friday, 5 March 2021 at 03:32:35 UTC, harakim wrote: correct version of compiler, but this will be helpful. Is it possible to download old versions of the compiler somewhere? From this page you can follow a trail all the way back to 0.00 if you're so inclined: https://dlang.org/changelog/index.html Thanks, I bookmarked this.
Re: How to get output of piped process?
On Wednesday, 17 February 2021 at 06:58:55 UTC, Jedi wrote: I an using pipeShell, I have redirected stdout, stderr, and stdin. I am trying to read from the output and display it in my app. I have followed this code almost exactly except I use try wait and flush because the app is continuously updating the output. (it outputs a progress text on the same line and I'm trying to poll it to report to the user) I think this post is going to answer your need. https://dev.to/jessekphillips/piping-process-output-1cai I haven't read all the replies, so maybe you have it working and this will benefit someone else.
Re: Broken examples
On Friday, 5 March 2021 at 22:01:37 UTC, Imperatorn wrote: Any idea why? The examples are compiled using an older host compiler (__VERSION__ is 2.093) but use features introduced in a later version. This will be fixed by upgrading the compiler (the examples are checked using current master IIRC).
Re: Broken examples
On Friday, 5 March 2021 at 22:59:09 UTC, H. S. Teoh wrote: On Fri, Mar 05, 2021 at 10:01:37PM +, Imperatorn via Digitalmars-d-learn wrote: Basically none of the examples on here compile: https://dlang.org/library/std/conv/parse.html Any idea why? File a bug. T Sad that there's such an uninviting space for outsiders coming in.
Re: Broken examples
On Fri, Mar 05, 2021 at 10:01:37PM +, Imperatorn via Digitalmars-d-learn wrote: > Basically none of the examples on here compile: > https://dlang.org/library/std/conv/parse.html > > Any idea why? File a bug. T -- By understanding a machine-oriented language, the programmer will tend to use a much more efficient method; it is much closer to reality. -- D. Knuth
Broken examples
Basically none of the examples on here compile: https://dlang.org/library/std/conv/parse.html Any idea why?
Re: Broken examples
On Friday, 5 March 2021 at 22:01:37 UTC, Imperatorn wrote: Basically none of the examples on here compile: https://dlang.org/library/std/conv/parse.html Any idea why? Output: onlineapp.d(10): Error: template `std.conv.parse` cannot deduce function from argument types `!(bool, string, cast(Flag)false)(string)`, candidates are: /dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(2183): `parse(Target, Source)(ref Source source)` /dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(2280): `parse(Target, Source)(ref Source s)` with `Target = bool, Source = string` must satisfy the following constraint: ` isIntegral!Target` /dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(2651): `parse(Target, Source)(ref Source source, uint radix)` /dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(2793): `parse(Target, Source)(ref Source s)` with `Target = bool, Source = string` must satisfy the following constraint: ` is(Target == enum)` /dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(2883): `parse(Target, Source)(ref Source source)` with `Target = bool, Source = string` must satisfy the following constraint: ` isFloatingPoint!Target` onlineapp.d(10):... (6 more, -v to show) ... onlineapp.d(13): Error: template `std.conv.parse` cannot deduce function from argument types `!(bool, string, cast(Flag)true)(string)`, candidates are: /dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(2183): `parse(Target, Source)(ref Source source)` /dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(2280): `parse(Target, Source)(ref Source s)` /dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(2651): `parse(Target, Source)(ref Source source, uint radix)` /dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(2793): `parse(Target, Source)(ref Source s)` /dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(2883): `parse(Target, Source)(ref Source source)` onlineapp.d(13):... (6 more, -v to show) ... onlineapp.d(16): Error: template `std.conv.parse` cannot deduce function from argument types `!(bool, string, cast(Flag)true)(string)`, candidates are: /dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(2183): `parse(Target, Source)(ref Source source)` /dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(2280): `parse(Target, Source)(ref Source s)` /dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(2651): `parse(Target, Source)(ref Source source, uint radix)` /dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(2793): `parse(Target, Source)(ref Source s)` /dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(2883): `parse(Target, Source)(ref Source source)` onlineapp.d(16):... (6 more, -v to show) ...
Re: Using YMM registers causes an undefined label error
On Friday, 5 March 2021 at 16:10:02 UTC, Rumbu wrote:
First of all, in 64 bit ABI, parameters are not passed on
stack, therefore a[RBP] is a nonsense.
void complement32(simdbytes* a, simdbytes* b)
a is in RCX, b is in RDX on Windows
a is in RDI, b is in RSI on Linux
I'm confused, with your help i've been able to find the function
calling convention but on LDC-generated code, sometimes i see the
layout being reversed(The function i was looking at is a 7
argument function, all are pointers. The first argument is on the
stack, the seventh and last is in RCX) and the offsets don't seem
to make sense either(first arguemnt as ss:[rsp+38], second at
ss:[rsp+30], and third at ss:[rsp+28])
Secondly, there is no such thing as movaps YMMX, [RAX], but
vmovaps YMM3, [RAX]
Same for vxorps, but there are 3 operands, not 2.
You're absolutely right, but apparently it only accepts the
two-operand version from SSE.
Other AVX/AVX2/AVX512 instructions that have «v» prefixed aren't
recognized either("Error: unknown opcode vmovaps"), is AVX(2)
with YMM registers supported for «asm{}» statements?
Re: Can't I allocate at descontructor?
On 3/5/21 12:57 PM, Jack wrote: >> destroy() executes the destructor. > > but I would need to call it manually and only after I somewhat I've > determined I no longer need the resources, right? so destroy(c) would be > no different from calling my own finalize-like method like freeResources()? Yes but perhaps with some extra functionality like the optional 'initialize': https://dlang.org/phobos/object.html#.destroy Ali
Re: Can't I allocate at descontructor?
On Friday, 5 March 2021 at 21:17:24 UTC, tsbockman wrote:
On Friday, 5 March 2021 at 21:02:08 UTC, H. S. Teoh wrote:
class C {...}
import core.memory : GC;
C c = cast(C) GC.malloc(C.sizeof);
...
...
import core.memory : GC;
C c = cast(C) GC.malloc(C.sizeof);
...
Also, that's not the correct way to manually allocate a class on
the heap. C.sizeof is the size of a reference to C, not an
instance of C, and we need to blit and construct the instance
before it is safe to use:
import core.memory : GC;
C c = cast(C) GC.malloc(__traits(classInstanceSize, C));
import core.lifetime : emplace;
emplace(c, anyConstructorArgsGoHere);
...
Re: Can't I allocate at descontructor?
On Friday, 5 March 2021 at 21:02:08 UTC, H. S. Teoh wrote:
If you know when you can deallocate something, that means you
don't need the GC to collect it, so you could just allocate it
on the malloc heap instead, and call destroy/free once you're
done. You could use the C version of malloc/free. You can
also optionally use GC.malloc/GC.free.
E.g.:
class C {...}
import core.memory : GC;
C c = cast(C) GC.malloc(C.sizeof);
... // use c
// We're done with c, destroy it
destroy(c); // this will call the dtor
GC.free(cast(void*) c);
c = null; // optional, just to ensure we don't accidentally
use it again
Unless the function is nothrow, that should really be:
import core.memory : GC;
C c = cast(C) GC.malloc(C.sizeof);
scope(exit) {
// We're done with c, destroy it
destroy(c); // this will call the dtor
GC.free(cast(void*) c);
c = null; // optional, just to ensure we don't
accidentally use it again
}
... // use c
Or,
import core.memory : GC;
C c = cast(C) GC.malloc(C.sizeof);
try {
... // use c
} finally {
// We're done with c, destroy it
destroy(c); // this will call the dtor
GC.free(cast(void*) c);
c = null; // optional, just to ensure we don't
accidentally use it again
}
Re: tiny alternative to std library
On Friday, 5 March 2021 at 16:54:48 UTC, Kagamin wrote: On Wednesday, 3 March 2021 at 20:54:43 UTC, Anthony Quizon wrote: I'm having some success pulling out small bits of code from other libraries and keeping things minimal and c-style-ish. If you're really ok with minimalism, I'm writing such a library https://filebin.net/7gtyh5j01gk1ofly I didn't publish it anywhere yet, feel free to do so. Not everything is finished there yet. GPL "virus" license does not fit for any commercial or even shareware work (
Re: Can't I allocate at descontructor?
On Fri, Mar 05, 2021 at 08:24:26PM +, Jack via Digitalmars-d-learn wrote:
> On Friday, 5 March 2021 at 20:18:44 UTC, Max Haughton wrote:
> > On Friday, 5 March 2021 at 20:13:54 UTC, Jack wrote:
[...]
> > > But the ones heap may never run at all, is that right?
> >
> > You can't rely on the garbage collector for deterministic
> > destruction, no.
>
> Are there some kind of replacement or I have to make my own
> finalize-like method, once I determine somewhat the application no
> longer need those resources?
[...]
If you know when you can deallocate something, that means you don't need
the GC to collect it, so you could just allocate it on the malloc heap
instead, and call destroy/free once you're done. You could use the C
version of malloc/free. You can also optionally use GC.malloc/GC.free.
E.g.:
class C {...}
import core.memory : GC;
C c = cast(C) GC.malloc(C.sizeof);
... // use c
// We're done with c, destroy it
destroy(c); // this will call the dtor
GC.free(cast(void*) c);
c = null; // optional, just to ensure we don't accidentally use it again
T
--
Freedom of speech: the whole world has no right *not* to hear my spouting off!
Re: Can't I allocate at descontructor?
On Friday, 5 March 2021 at 20:28:58 UTC, Ali Çehreli wrote:
On 3/5/21 12:24 PM, Jack wrote:
Are there some kind of replacement or I have to make my own
finalize-like method, once I determine somewhat the
application no longer need those resources?
destroy() executes the destructor.
but I would need to call it manually and only after I somewhat
I've determined I no longer need the resources, right? so
destroy(c) would be no different from calling my own
finalize-like method like freeResources()?
To my surprise, even though 'c' is not null below, the
destructor is not executed multiple times.
import std.stdio;
class C {
string fileName;
this(string fileName) {
writeln("constructing");
this.fileName = fileName;
writeln("creating file");
}
~this() {
writeln("destructing");
if (fileName) {
writeln("removing the file");
} else {
writeln("NOT removing the file");
}
}
}
void main() {
auto c = new C("some imaginary file name");
// Executes the destructor
destroy(c);
// This does not do anything
destroy(c);
// Neither does this
import core.memory;
GC.collect();
}
Ali
Re: Can't I allocate at descontructor?
On 3/5/21 12:24 PM, Jack wrote:
Are there some kind of replacement or I have to make my own
finalize-like method, once I determine somewhat the application no
longer need those resources?
destroy() executes the destructor.
To my surprise, even though 'c' is not null below, the destructor is not
executed multiple times.
import std.stdio;
class C {
string fileName;
this(string fileName) {
writeln("constructing");
this.fileName = fileName;
writeln("creating file");
}
~this() {
writeln("destructing");
if (fileName) {
writeln("removing the file");
} else {
writeln("NOT removing the file");
}
}
}
void main() {
auto c = new C("some imaginary file name");
// Executes the destructor
destroy(c);
// This does not do anything
destroy(c);
// Neither does this
import core.memory;
GC.collect();
}
Ali
Re: Can't I allocate at descontructor?
On Friday, 5 March 2021 at 20:18:44 UTC, Max Haughton wrote: On Friday, 5 March 2021 at 20:13:54 UTC, Jack wrote: On Friday, 5 March 2021 at 20:10:39 UTC, Max Haughton wrote: On Friday, 5 March 2021 at 20:03:58 UTC, Jack wrote: On Friday, 5 March 2021 at 09:23:29 UTC, Mike Parker wrote: On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote: [...] https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/ thanks for such good article. So if the object was allocated on heap, there's no guarantee that the object's destrutor will be called at all? do destrutor allocate at stack are guarantee to be run? Destructors of structs on the stack will always run deterministically. But the ones heap may never run at all, is that right? You can't rely on the garbage collector for deterministic destruction, no. Are there some kind of replacement or I have to make my own finalize-like method, once I determine somewhat the application no longer need those resources? aside from destructor for memory allocated on stack, what are uses for destrutors?
Re: Can't I allocate at descontructor?
On Friday, 5 March 2021 at 20:13:54 UTC, Jack wrote: On Friday, 5 March 2021 at 20:10:39 UTC, Max Haughton wrote: On Friday, 5 March 2021 at 20:03:58 UTC, Jack wrote: On Friday, 5 March 2021 at 09:23:29 UTC, Mike Parker wrote: On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote: [...] https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/ thanks for such good article. So if the object was allocated on heap, there's no guarantee that the object's destrutor will be called at all? do destrutor allocate at stack are guarantee to be run? Destructors of structs on the stack will always run deterministically. But the ones heap may never run at all, is that right? You can't rely on the garbage collector for deterministic destruction, no.
Re: Can't I allocate at descontructor?
On Friday, 5 March 2021 at 20:10:39 UTC, Max Haughton wrote: On Friday, 5 March 2021 at 20:03:58 UTC, Jack wrote: On Friday, 5 March 2021 at 09:23:29 UTC, Mike Parker wrote: On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote: The following code returns a memory error. I did notice it did happens whenever I did a memory allocation. Is this not possible in the descontrutor? if so, why? https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/ thanks for such good article. So if the object was allocated on heap, there's no guarantee that the object's destrutor will be called at all? do destrutor allocate at stack are guarantee to be run? Destructors of structs on the stack will always run deterministically. But the ones heap may never run at all, is that right?
Re: Can't I allocate at descontructor?
On Friday, 5 March 2021 at 20:03:58 UTC, Jack wrote: On Friday, 5 March 2021 at 09:23:29 UTC, Mike Parker wrote: On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote: The following code returns a memory error. I did notice it did happens whenever I did a memory allocation. Is this not possible in the descontrutor? if so, why? https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/ thanks for such good article. So if the object was allocated on heap, there's no guarantee that the object's destrutor will be called at all? do destrutor allocate at stack are guarantee to be run? Destructors of structs on the stack will always run deterministically.
Re: Can't I allocate at descontructor?
On Fri, Mar 05, 2021 at 08:03:58PM +, Jack via Digitalmars-d-learn wrote: > On Friday, 5 March 2021 at 09:23:29 UTC, Mike Parker wrote: > > On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote: > > > The following code returns a memory error. I did notice it did > > > happens whenever I did a memory allocation. Is this not possible > > > in the descontrutor? if so, why? > > > > https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/ > > thanks for such good article. So if the object was allocated on heap, > there's no guarantee that the object's destrutor will be called at all? Yes. And also if it does get called, there's no guarantee what order it will be called in w.r.t. other dtors. And you cannot perform any GC operations in it. > do destrutor allocate at stack are guarantee to be run? Yes. T -- If it tastes good, it's probably bad for you.
Re: Can't I allocate at descontructor?
On Friday, 5 March 2021 at 09:23:29 UTC, Mike Parker wrote: On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote: The following code returns a memory error. I did notice it did happens whenever I did a memory allocation. Is this not possible in the descontrutor? if so, why? https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/ thanks for such good article. So if the object was allocated on heap, there's no guarantee that the object's destrutor will be called at all? do destrutor allocate at stack are guarantee to be run?
Re: lockstep works with .each, but fails with .map
On Friday, 5 March 2021 at 19:26:38 UTC, Jacob Carlborg wrote: On 2021-03-05 19:49, realhet wrote: Why it works with each (or foreach), but not with map? o.O `lockstep` is specifically designed to work with `foreach`. I think `each` has a special case to work with `lockstep`. If you want to use other range functions, you should use `zip` instead of `lockstep`. It works now: zip(StoppingPolicy.requireSameLength, a, b).map!(a => SE(a[])).sum / float(a.length); I had a misconception (lazyness of learning) that zip is making a simple array, not a tuple array like I guessed lockstep does. Also in zip() the StoppingPolicy is the first parameter and in lockstep() it's the last. Thank you very much!
Re: lockstep works with .each, but fails with .map
On 2021-03-05 19:49, realhet wrote: Why it works with each (or foreach), but not with map? o.O `lockstep` is specifically designed to work with `foreach`. I think `each` has a special case to work with `lockstep`. If you want to use other range functions, you should use `zip` instead of `lockstep`. -- /Jacob Carlborg
Re: Can't I allocate at descontructor?
On Friday, 5 March 2021 at 05:42:03 UTC, evilrat wrote: On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote: The following code returns a memory error. I did notice it did happens whenever I did a memory allocation. Is this not possible in the descontrutor? if so, why? GC prohibits allocation during collection, since this dtor is likely called by GC this is what happens. If you REALLY need this just allocate using other mechanisms. I didn't know that, it seems even if I use other allocation mechanism there's no guarantee the deconstructor will be called so it seems the native descontrutor will not be of help at all
lockstep works with .each, but fails with .map
Hi
What am I doing wrong here?
import std.stdio, std.range, std.algorithm, std.uni, std.utf,
std.conv, std.typecons, std.array;
auto SE(A, B)(in A a, in B b){
return (a-b)^^2;
}
void main(){
auto a = [1, 2, 3], b = [1, 1, 1];
lockstep(a, b, StoppingPolicy.requireSameLength).each!((a,
b){ writeln(SE(a, b)); });
lockstep(a, b, StoppingPolicy.requireSameLength).map !((a,
b){ return SE(a, b) ; }).each!writeln; <- error here
}
The error:
map(Range)(Range r)
with Range = Lockstep!(int[], int[])
must satisfy the following constraint:
isInputRange!(Unqual!Range)
Why it works with each (or foreach), but not with map? o.O
I just wanted to make a Sum of squared errors function.
Thanks in advance!
Re: dub support for Mac M1?
On Thursday, 4 March 2021 at 23:57:25 UTC, kinke wrote: On Thursday, 4 March 2021 at 22:30:17 UTC, tastyminerals wrote: I got a company MacBook with M1 chip and gradually migrate all the stuff from Linux machine. I got precompiled ldc binary installed without any problem now is the time for dub since I have couple of D projects I use at work and all of them use dub. I can only see the dub-v1.23.0-osx-x86_64.tar.gz package so it should at least run via Rosetta. The official prebuilt LDC package comes with prebuilt dub, dustmite, ddemangle and rdmd, just like any other package. Oh, you are right! I was not aware of that. Thank you.
Re: tiny alternative to std library
On Friday, 5 March 2021 at 16:54:48 UTC, Kagamin wrote: On Wednesday, 3 March 2021 at 20:54:43 UTC, Anthony Quizon wrote: I'm having some success pulling out small bits of code from other libraries and keeping things minimal and c-style-ish. If you're really ok with minimalism, I'm writing such a library https://filebin.net/7gtyh5j01gk1ofly I didn't publish it anywhere yet, feel free to do so. Not everything is finished there yet. I was too looking for something like this, thanks! you should definitely host it somewhere, maybe on github, i'd love to contribute!
Re: tiny alternative to std library
On Wednesday, 3 March 2021 at 20:54:43 UTC, Anthony Quizon wrote: I'm having some success pulling out small bits of code from other libraries and keeping things minimal and c-style-ish. If you're really ok with minimalism, I'm writing such a library https://filebin.net/7gtyh5j01gk1ofly I didn't publish it anywhere yet, feel free to do so. Not everything is finished there yet.
Re: Using YMM registers causes an undefined label error
On Friday, 5 March 2021 at 12:57:43 UTC, z wrote: XMM registers work, but as soon as they are changed into YMM DMD outputs "bad type/size of operands %s" and LDC outputs an "label YMM0 is undefined" error. Are they not supported? To illutrate : https://run.dlang.io/is/IqDHlK By the way, how can i use instructions that are not listed in [1]?(vfmaddxxxps for example) And how are function parameters accessed if they are not on the stack?(looking up my own code in a debugger, i see that the majority of pointer parameters are already in registers rather than being on the stack.) I need those so that i can write a better answer for [2]. Big thanks [1] https://dlang.org/spec/iasm.html#supported_opcodes [2] https://forum.dlang.org/thread/qyybpvwvbfkhlvulv...@forum.dlang.org First of all, in 64 bit ABI, parameters are not passed on stack, therefore a[RBP] is a nonsense. void complement32(simdbytes* a, simdbytes* b) a is in RCX, b is in RDX on Windows a is in RDI, b is in RSI on Linux Secondly, there is no such thing as movaps YMMX, [RAX], but vmovaps YMM3, [RAX] Same for vxorps, but there are 3 operands, not 2.
Re: D's Continous Changing
On Friday, 5 March 2021 at 15:54:37 UTC, Paul Backus wrote: The website is *supposed* to keep documentation for old versions around, and allow you to select them using the drop-down menu at the top-right: note that in some cases my website lets you pull old versions too: http://phobos.dpldocs.info/v2.068.0/ for example. But since I rarely use old versions it probably won't be in cache and thus you have to wait for the slow process of it downloading and generating the files.
Re: D's Continous Changing
On Friday, 5 March 2021 at 03:32:35 UTC, harakim wrote: That was pretty sweet. However, it kind of goes to the point of my post. A one-revision difference means the documentation is not accurate for my compiler. I'm not saying the language shouldn't evolve, I'm just saying it might make sense to keep compatibility changes to every 6 months or a year. Then you could keep the old documentation around for the old version, and create new documentation for the new version and no matter which version someone is using they would have documentation (within limits.) The website is *supposed* to keep documentation for old versions around, and allow you to select them using the drop-down menu at the top-right: https://i.imgur.com/ICu9Z7a.png However, it looks like this feature is currently broken, since the archived documentation stops at version 2.081. I've filed an issue in the appropriate repository [1], so hopefully that will be fixed soon. [1] https://github.com/dlang/docarchives.dlang.io/issues/1
Re: Checking for manifest constants
On Friday, 5 March 2021 at 08:23:09 UTC, Bogdan wrote:
I was using a trick with dmd to check for manifest constants
which worked until dmd v2.094. Yesterday I tried it on the
latest compiler and it failed with:
source/introspection/manifestConstant.d(37,28): Error: need
this for name of type string
source/introspection/type.d(156,13): Error: value of this is
not known at compile time
any ideas how to fix it? or, is it a bug with dmd?
```
/// Check if a member is manifest constant
bool isManifestConstant(T, string name)() {
mixin(`return is(typeof(T.init.` ~ name ~ `)) &&
!is(typeof(` ~ name ~ `));`);
}
/// ditto
bool isManifestConstant(alias T)() {
return is(typeof(T)) && !is(typeof());
}
enum globalConfig = 32;
int globalValue = 22;
unittest {
struct Test {
enum config = 3;
int value = 2;
}
static assert(isManifestConstant!(Test.config));
static assert(isManifestConstant!(Test, "config"));
static assert(isManifestConstant!(globalConfig));
static assert(!isManifestConstant!(Test.value));
static assert(!isManifestConstant!(Test, "value"));
static assert(!isManifestConstant!(globalValue));
}
void main() {}
```
I suggest this:
enum globalConfig = 32;
int globalValue = 22;
immutable globaImmutablelValue = 22;
enum isManifestConstant(alias symbol) =
__traits(compiles, { enum e = symbol; }) &&
!__traits(compiles, { const ptr = });
unittest {
struct Test {
enum config = 3;
int value = 2;
}
static assert(isManifestConstant!(Test.config));
static assert(isManifestConstant!(mixin("Test.config")));
static assert(isManifestConstant!(globalConfig));
static assert(isManifestConstant!(mixin("globalConfig")));
static assert(!isManifestConstant!(Test.value));
static assert(!isManifestConstant!(mixin("Test.value")));
static assert(!isManifestConstant!(globalValue));
static assert(!isManifestConstant!(mixin("globalValue")));
static assert(!isManifestConstant!(globaImmutablelValue));
static
assert(!isManifestConstant!(mixin("globaImmutablelValue")));
}
Using YMM registers causes an undefined label error
XMM registers work, but as soon as they are changed into YMM DMD outputs "bad type/size of operands %s" and LDC outputs an "label YMM0 is undefined" error. Are they not supported? To illutrate : https://run.dlang.io/is/IqDHlK By the way, how can i use instructions that are not listed in [1]?(vfmaddxxxps for example) And how are function parameters accessed if they are not on the stack?(looking up my own code in a debugger, i see that the majority of pointer parameters are already in registers rather than being on the stack.) I need those so that i can write a better answer for [2]. Big thanks [1] https://dlang.org/spec/iasm.html#supported_opcodes [2] https://forum.dlang.org/thread/qyybpvwvbfkhlvulv...@forum.dlang.org
Re: Checking for manifest constants
On Friday, 5 March 2021 at 08:23:09 UTC, Bogdan wrote:
I was using a trick with dmd to check for manifest constants
which worked until dmd v2.094. Yesterday I tried it on the
latest compiler and it failed with:
source/introspection/manifestConstant.d(37,28): Error: need
this for name of type string
source/introspection/type.d(156,13): Error: value of this is
not known at compile time
any ideas how to fix it? or, is it a bug with dmd?
```
/// Check if a member is manifest constant
bool isManifestConstant(T, string name)() {
mixin(`return is(typeof(T.init.` ~ name ~ `)) &&
!is(typeof(` ~ name ~ `));`);
}
/// ditto
bool isManifestConstant(alias T)() {
return is(typeof(T)) && !is(typeof());
}
enum globalConfig = 32;
int globalValue = 22;
unittest {
struct Test {
enum config = 3;
int value = 2;
}
static assert(isManifestConstant!(Test.config));
static assert(isManifestConstant!(Test, "config"));
static assert(isManifestConstant!(globalConfig));
static assert(!isManifestConstant!(Test.value));
static assert(!isManifestConstant!(Test, "value"));
static assert(!isManifestConstant!(globalValue));
}
void main() {}
```
Hello, you can use this template instead:
template isManifestConstant(alias V, T...)
if (T.length == 0 || (T.length == 1 && is(T[0])))
{
enum isKnown = is(typeof((){enum v = V;}));
static if (!T.length)
enum isManifestConstant = isKnown;
else
enum isManifestConstant = isKnown && is(typeof(V) ==
T[0]);
}
The optional T is to verify if it is a compile time constant of a
certain type.
the tests you wrote and that are not based on a string pass.
Re: Can't I allocate at descontructor?
On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote: The following code returns a memory error. I did notice it did happens whenever I did a memory allocation. Is this not possible in the descontrutor? if so, why? https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/
Checking for manifest constants
I was using a trick with dmd to check for manifest constants
which worked until dmd v2.094. Yesterday I tried it on the latest
compiler and it failed with:
source/introspection/manifestConstant.d(37,28): Error: need this
for name of type string
source/introspection/type.d(156,13): Error: value of this is not
known at compile time
any ideas how to fix it? or, is it a bug with dmd?
```
/// Check if a member is manifest constant
bool isManifestConstant(T, string name)() {
mixin(`return is(typeof(T.init.` ~ name ~ `)) &&
!is(typeof(` ~ name ~ `));`);
}
/// ditto
bool isManifestConstant(alias T)() {
return is(typeof(T)) && !is(typeof());
}
enum globalConfig = 32;
int globalValue = 22;
unittest {
struct Test {
enum config = 3;
int value = 2;
}
static assert(isManifestConstant!(Test.config));
static assert(isManifestConstant!(Test, "config"));
static assert(isManifestConstant!(globalConfig));
static assert(!isManifestConstant!(Test.value));
static assert(!isManifestConstant!(Test, "value"));
static assert(!isManifestConstant!(globalValue));
}
void main() {}
```
