Re: Tuple enumeration without integers or strings
On Friday, 1 January 2021 at 23:14:43 UTC, Rekel wrote:
I seem to have hit a bit of a wall when comparing D enums to
Java enums.
Of course the latter is just a fancy class, though it'd be nice
to see partially equivalent usefulness regardless.
For example, as soon as non-integer, non-string values are
given to enums things get messy for me when using switch cases,
I haven't yet found a satisfying way of doing this.
D's switch statement only works on strings and integers. For more
complex values, the easiest thing is to just use an if-else chain.
If you really want to use a switch statement, you can do it by
defining a function that maps each of your enum values to a
unique integer; for example:
enum Wind { ... }
size_t index(Wind w)
{
if (w = Wind.N) return 0;
// etc.
}
void someFunction(Wind w)
{
switch(w.index) {
case Wind.N.index: // uses CTFE
// ...
break;
// etc.
default: assert(0);
}
}
Re: Tuple enumeration without integers or strings
On Saturday, 2 January 2021 at 00:57:48 UTC, Paul wrote: So this neither seems a satisfiable solution to me :/ Couldn't you just use Wind.N.hashOf and a custom format() expression for string-representation?
Why there is no support for Dlang to convert Qt Creator .ui file to Dlang .d for use with QtE5?
I have a GUI created using Qt Creator and save it to .ui file. I can convert .ui file to .cpp or .py (C++ or Python), but I can not convert .ui to .d for use with Dlang and QtE5.
Re: Tuple enumeration without integers or strings
It seems w.to!string works in conjunction with Wind.N.stringof,
though I wonder about the efficiency/wastefulness of this method.
Sadly this also leads to very funny behavior when some of the
enums have the same value, as to!string(Enum) will yield the name
of the first of these enums having the same values.
alias Thing = Tuple!(int, int);
enum Enum {
A = Thing(0, 1),
B = Thing(0, 2),
C = Thing(0, 2)
}
void main(){
Enum.C.to!string.writeln;
}
For example, the code above will print 'B' (I'm slightly curious
how & why std.conv uses the Enum name when converting to string,
instead of using the value, especially since I didn't see this
pitfall coming partly due to this)
So this neither seems a satisfiable solution to me :/
Re: Socket handle leak and active handle warning with Vibe-D
On 1/1/21 5:07 PM, Selim Ozel wrote: I created the simplest possible example as explained by the Vibe-D community in [1]. The exact source code of what I run is in [2]. On Windows I get a socket handle leak warning on shutdown with crtl+c from terminal after running the executable. [main() INF] Listening for requests on http://[::1]:8080/ [main() INF] Listening for requests on http://127.0.0.1:8080/ [main() INF] Please open http://127.0.0.1:8080/ in your browser. [() INF] Received signal 2. Shutting down. Warning: 2 socket handles leaked at driver^ Cshutdown On Ubuntu 20.04 I get leaking drivers warning with the same process. [main() INF] Listening for requests on http://[::1]:8080/ [main() INF] Listening for requests on http://127.0.0.1:8080/ [main() INF] Please open http://127.0.0.1:8080/ in your browser. ^C[main() INF] Received signal 2. Shutting down. Warning (thread: main): leaking eventcore driver because there are still active handles FD 6 (streamListen) FD 7 (streamListen) Warning (thread: main): leaking eventcore driver because there are still active handles FD 6 (streamListen) FD 7 (streamListen) I really don't know what this is all about but it is at the core of my Vibe-D development. So any pointers you might have would be very helpful to me. Thanks in advance. 1. the sockets are leaked for a reason that is pretty obscure -- namely, the GC might need to access those sockets as the process is shut down. Prior to this, the end result of vibe.d server was frequently a segfault. 2. The reason they are leaking is most likely because you still have a listening socket somewhere. I wish it would tell you how that socket was allocated, but it doesn't. To fix, make sure all your listening sockets are closed. In my vibe.d app, I have the following: auto listener = listenHTTP(settings, router); scope(exit) listener.stopListening(); I also clean up my session store connection (something I had to add support for in vibe.d), which was a different source of leaking handles. I also clean up database connections, which might be cached. And finally, even with all this, I still get leaking driver messages if an HTTP keepalive socket is open. I really feel like vibe.d should give you the option of not printing this message, as most of the time, it's something you can ignore. -Steve
Re: New integer promotion rules
On Thursday, 18 January 2018 at 16:31:02 UTC, ag0aep6g wrote: I'm interpreting that to mean that it will become an error for some time, but later it will be allowed again with the new behavior. And then you can throw away `-transition=intpromote`. Seeing as it's almost 3 years later, I'd like to ask, is there an indication of when this will happen? It seems to still be around.
Tuple enumeration without integers or strings
I seem to have hit a bit of a wall when comparing D enums to Java
enums.
Of course the latter is just a fancy class, though it'd be nice
to see partially equivalent usefulness regardless.
For example, as soon as non-integer, non-string values are given
to enums things get messy for me when using switch cases, I
haven't yet found a satisfying way of doing this.
Note the reason I'm using tuples is to somehow replicate the way
java enumerals can contain several member variables, which tends
to be very useful.
Something along the lines of the following is what i'd like to
achieve;
alias Direction = Tuple!(byte, "x", byte, "y");
enum Wind {N = Direction(0, 1) ... etc}
...
void some_function(Wind w) {
switch (w) {
case Wind.N:
... etc
break;
... etc
default:
assert(0);
}
}
One thing that might have worked would have been an equivalent of
java's "ordinal", though from what I've found D doesn't seem to
have something equivalent to this?
(I'd prefer not to have a seperate tuple member purely for
ordinality, and dropping enumerals altogether also seems like a
waste)
Socket handle leak and active handle warning with Vibe-D
I created the simplest possible example as explained by the Vibe-D community in [1]. The exact source code of what I run is in [2]. On Windows I get a socket handle leak warning on shutdown with crtl+c from terminal after running the executable. [main() INF] Listening for requests on http://[::1]:8080/ [main() INF] Listening for requests on http://127.0.0.1:8080/ [main() INF] Please open http://127.0.0.1:8080/ in your browser. [() INF] Received signal 2. Shutting down. Warning: 2 socket handles leaked at driver^ Cshutdown On Ubuntu 20.04 I get leaking drivers warning with the same process. [main() INF] Listening for requests on http://[::1]:8080/ [main() INF] Listening for requests on http://127.0.0.1:8080/ [main() INF] Please open http://127.0.0.1:8080/ in your browser. ^C[main() INF] Received signal 2. Shutting down. Warning (thread: main): leaking eventcore driver because there are still active handles FD 6 (streamListen) FD 7 (streamListen) Warning (thread: main): leaking eventcore driver because there are still active handles FD 6 (streamListen) FD 7 (streamListen) I really don't know what this is all about but it is at the core of my Vibe-D development. So any pointers you might have would be very helpful to me. Thanks in advance. S [1] https://vibed.org/blog/posts/a-scalable-chat-room-service-in-d [2] https://github.com/SelimOzel/vibe_noLeaks
Re: C++ or D?
On Friday, 1 January 2021 at 18:00:57 UTC, SealabJaster wrote: Meanwhile I believe C++ (keep in mind I very rarely touch or look at C++) already has a standard allocator interface that parts of the STL (and I assume libraries, when/if they care) are able to use? I'm unaware of the issues it might have in C++, but that's mostly because of my lack of use and knowledge of the language. It has standard pointer types, etc. So, C++ had the same issues as D prior to C++11, that you had many many different options, but none of them were standard... Which was ok if you used one big framework, but if you wanted to mix libraries... yuck. Since C++11 things are looking better although it obviously takes time for frameworks/libraries to catch up. In C++ everything is up to the library/programmer so there is basically no way for the compiler to be particularly clever with heap allocations, although it can be clever with values (e.g. stack allocations). So, that is an area where D could be bold make the compiler smart, and do better than C++, but that takes some courage. C++ smart pointers do allow for custom allocators, but then the owning pointers will have an extra field for referencing it, which is used for deallocation. I suspect most people don't use it, but it might be important for creating nice C++ wrappers for C libraries? I wonder what problems D faces in comparison to C++ and other languages in this regard, since it's been in a limbo, fragmented state for a while now. Mostly a lack of strategic decision making? Just map out the various alternatives and pick a combination that is "wholesome". (Do you want to be a bird and fly or a fish that can swim? Being neither bird nor fish isn't working in the long run, I don't think so.)
Re: C++ or D?
On Friday, 1 January 2021 at 16:45:16 UTC, Ola Fosheim Grøstad wrote: I don't know anything about any official positions other than the fact that Walter dislikes having more than one pointer type and is working on some kind of "liveness" verification for a C-style free/malloc regime, which is rather rare in other languages these days. Not really sure how that fits with modern code bases. Isn't there some work on move-semantics to make C++ interfacing better? But shared_ptr is only for C++ interop, perhaps? Or is it meant for D-code? To me it looks like things are a bit up-in-the-air at the moment. Unsurprising answers unfortunately :( As for the move-semantics, I know that DIP 1014 was accepted, but I don't know anything beyond that (haven't really looked into it at all tbh). And well, having many options that are incompatible would not be good for library interop, so choices have to be made to avoid "tower of Babel". This is a concern of mine, especially when D touts about the GC being optional, but I do have doubts about any ground being made on this front, either in discussions, decisions, or implementations, within the next year or two. Meanwhile I believe C++ (keep in mind I very rarely touch or look at C++) already has a standard allocator interface that parts of the STL (and I assume libraries, when/if they care) are able to use? I'm unaware of the issues it might have in C++, but that's mostly because of my lack of use and knowledge of the language. It has standard pointer types, etc. I wonder what problems D faces in comparison to C++ and other languages in this regard, since it's been in a limbo, fragmented state for a while now.
Re: Associative Array Question
On 12/31/20 8:54 PM, Adam D. Ruppe wrote: On Friday, 1 January 2021 at 01:43:50 UTC, Chris Bare wrote: a1[10] = "testing a1"; this actually constructs a new thing since it is a straight x = y assignment. a2[10].name = "testing a2"; But this looks up something first. It doesn't construct a2[10], it looks it up first to fetch the name member... hence the range violation since it isn't constructed yet. a3[10] = new Project; and this again will construct since it is a straight x = y again. So you could also do a2[10] = Person() then do the lookup of name or a2[10] = Person(null, "testing a2") -Steve
Re: C++ or D?
On Thursday, 31 December 2020 at 07:17:45 UTC, RSY wrote: On Wednesday, 30 December 2020 at 21:03:36 UTC, Paulo Pinto wrote: On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote: On Wednesday, 23 December 2020 at 19:00:14 UTC, evilrat wrote: [...] C++ you need to write duplicate code (.h and .cpp) C++ you need to care about header include order C++ you need to forward declare everything you gonna use if it is not included before C++ you need to waste time waiting for compile Fixed with C++20 modules. I am already playing with the experimental support on VC++. C++ you need to fight to get proper reflection Coming in C++23, and partially available already with a mix of type traits and constexpr. I am all good for D vs C++, but one needs to update their knowledge specially when the audience is up to date with latest ISO C++'s capabilities. It's like the story with the GC You want everyone to like D because it has a GC despite it being not updated in ages, and proved to not scale well You do the same with modules and reflections now, D is clearly better but for some reasons you don't want people to believe that, worse you want people to see them as inferior to the poor C++ one, because you clearly didn't mention any of that poor 1 phase compilation model What is your goal here? you for sure don't want D to take off It would be nice to see D taking off, I just happen not to be blind to the competition. That is the beauty of being an enterprise polyglot consultant, I get to pick what customers want, and they want eco-systems and platforms. Which not only use GC in domains that D fails to, also get to catch up with almost every feature that made D a better choice 10 years ago. Blind advocacy won't get new users.
Re: C++ or D?
On Friday, 1 January 2021 at 16:23:45 UTC, SealabJaster wrote: Slightly off but also on topic but, has there been any general consensus yet around standard pointer types (e.g. shared_ptr) and standard allocator-aware data structures, or just in general any discussions around non-GC memory management as part of Phobos/core parts of D outside of "use/write a library"? I don't know anything about any official positions other than the fact that Walter dislikes having more than one pointer type and is working on some kind of "liveness" verification for a C-style free/malloc regime, which is rather rare in other languages these days. Not really sure how that fits with modern code bases. Isn't there some work on move-semantics to make C++ interfacing better? But shared_ptr is only for C++ interop, perhaps? Or is it meant for D-code? To me it looks like things are a bit up-in-the-air at the moment. And well, having many options that are incompatible would not be good for library interop, so choices have to be made to avoid "tower of Babel". *shrugs*
Re: C++ or D?
On Friday, 1 January 2021 at 15:12:43 UTC, Ola Fosheim Grøstad wrote: On Friday, 1 January 2021 at 15:01:15 UTC, RSY wrote: one big move would be to finally put the allocators out of std.experimental, and finally embrace this everywhere (just like ziglang) I am bit torn on this, the less the compiler knows about allocation strategies, the less opportunity there are for the compiler to be smart about allocations. So, those things ought to be language constructs, not library constructs. At least if D is going to stay in the lane of high level programming. (Zig is firmly staking ground in the manual-labour department, as far as I can tell.) Slightly off but also on topic but, has there been any general consensus yet around standard pointer types (e.g. shared_ptr) and standard allocator-aware data structures, or just in general any discussions around non-GC memory management as part of Phobos/core parts of D outside of "use/write a library"? (And for completely off-topic: What are the plans for std.experimental packages right now? Is std.experimental.logging just going to sit there until the end of time?)
Re: C++ or D?
On Friday, 1 January 2021 at 15:01:15 UTC, RSY wrote: one big move would be to finally put the allocators out of std.experimental, and finally embrace this everywhere (just like ziglang) I am bit torn on this, the less the compiler knows about allocation strategies, the less opportunity there are for the compiler to be smart about allocations. So, those things ought to be language constructs, not library constructs. At least if D is going to stay in the lane of high level programming. (Zig is firmly staking ground in the manual-labour department, as far as I can tell.)
Re: C++ or D?
On Thursday, 31 December 2020 at 19:57:53 UTC, Ola Fosheim Grøstad wrote: On Thursday, 31 December 2020 at 19:27:23 UTC, Sebastiaan Koppe wrote: On Thursday, 31 December 2020 at 16:03:54 UTC, Ola Fosheim Grøstad wrote: What would you like to see? For shared to mean something. Stackless coroutines. Compile-time lifetime management, i.e. better ways to define ownership. I second that. At least some way to know whether a pointer takes ownership (GC/RC) or just is an auxiliary reference. i agree with this, C++ has GC, smart pointer and even some facilities for ownership via various move semantic that is an area where D could improve, but that would be catch up with C++.. one big move would be to finally put the allocators out of std.experimental, and finally embrace this everywhere (just like ziglang)
Re: Field Initialiser Reused Across Object Instances
That's a fantastic answer! Thank you. I was not aware that initializers were always compile time, that was the missing piece in my understanding. It's a shame that I can't use the nicer (IMO) syntax, but the reasoning is sound.
Re: Field Initialiser Reused Across Object Instances
On Friday, 1 January 2021 at 13:34:16 UTC, Adam wrote: A a = new A; // I would expect this to be called for each "new B". Your expectation is wrong for D. Since that's in a `static` context, it is run at compile time. Any variable marked `static`, `__gshared`, or is struct/class/module-top-level member is a static context. So all those are set up at compile time (or triggers a compile error if this fails btw, either a thing is a static context and thus CTFEd or not a static context and thus never CTFEd) and just blindly copied at run time. Basically any assignment outside a function is a compile time thing. Is this intended? Yes, it is a frequent thing to surprise people though. The reference there is part of the object but it points to the same default thing because of how that was made. Constructors are actually run at runtime, but initializers are considered compile time constants. My gut reaction is the compiler is memoising "new A" because purity is inferred note that ctfe never happens because of anything inferred or pure or stuff like that. It is purely decided by the initialization context. I can fix using a dedicated constructor, but I much prefer initializers where possible. no real choice here, if you want a unique object to be referenced it needs to run with the constructor.
Field Initialiser Reused Across Object Instances
Consider the following:
class A
{
int x;
}
class B
{
A a = new A; // I would expect this to be called for each
"new B".
}
void main()
{
import std.stdio;
auto c = new B;
writeln("c ", c.a.x);
c.a.x++;
writeln("c ", c.a.x);
writeln;
auto d = new B;
writeln("d ", d.a.x, " expected 0!");
d.a.x++;
writeln("d ", d.a.x, " expected 1!");
}
*** Output ***
c 0
c 1
d 1 expected 0!
d 2 expected 1!
There is only one instance of A in the above program, although I
would expect one for each instance of B. The field is not marked
static.
Is this intended? My gut reaction is the compiler is memoising
"new A" because purity is inferred, but doesn't that contradict
the meaning of "new Class" which should always yield an object
with it's own identity?
I can fix using a dedicated constructor, but I much prefer
initializers where possible.
