Re: Tuple enumeration without integers or strings
On Sunday, 3 January 2021 at 04:16:20 UTC, Paul Backus wrote: On Sunday, 3 January 2021 at 02:41:12 UTC, Paul wrote: hashOf is not guaranteed to produce unique values, so I would not advise using it here. Of course it's a hashing method but also internally used for comparison and good enough, at least in that example code. By using an enum I don't assume there will be that much members to take care of anyway. The hash is also generated at compile time.
Re: Tuple enumeration without integers or strings
On Sunday, 3 January 2021 at 02:41:12 UTC, Paul wrote: I haven't used hashOf before, though assuming no equal values, which I generally wouldn't do, I take it this is reliable? I haven't tried it before, and I dont know how to effectively compare it to using 'switch(w.to!string)' & 'case Wind.B.stringof' (regarding speed/reliability). hashOf is not guaranteed to produce unique values, so I would not advise using it here. to!string is expensive both at compile time (requires a lot of template instantiations) and runtime (needs to allocate memory for the string). It will work if you need to hack something together quickly, but I would not recommend it for "serious" code.
Re: Tuple enumeration without integers or strings
On Sunday, 3 January 2021 at 02:17:43 UTC, frame wrote:
Besides the problem with equal values, what's wrong with that:
alias Thing = Tuple!(int, int);
enum Wind {
A = Thing(0, 1),
B = Thing(0, 2),
C = Thing(0, 2)
}
void some_function(Wind w) {
switch (w.hashOf) {
case Wind.B.hashOf:
break;
default:
assert(0);
}
}
void main() {
some_function(Wind.B);
writefln("%d%d", Wind.C.expand);
}
I haven't used hashOf before, though assuming no equal values,
which I generally wouldn't do, I take it this is reliable? I
haven't tried it before, and I dont know how to effectively
compare it to using 'switch(w.to!string)' & 'case
Wind.B.stringof' (regarding speed/reliability).
Re: Tuple enumeration without integers or strings
On Sunday, 3 January 2021 at 01:15:56 UTC, Paul wrote:
On Saturday, 2 January 2021 at 21:48:04 UTC, Paul Backus wrote:
Yes, but this will be true of any approach you choose. If two
enum members have exactly the same value, there is no way to
distinguish between them, either at compile time or at runtime.
Oh I see, thanks!
A bit of a bummer as I guess that means you're pretty much
required to use an additional seperate structure like an array
or map/associative array, the latter making the use of an enum
instead of string names slightly pointless in this scenario,
thank you nontheless .
Besides the problem with equal values, what's wrong with that:
alias Thing = Tuple!(int, int);
enum Wind {
A = Thing(0, 1),
B = Thing(0, 2),
C = Thing(0, 2)
}
void some_function(Wind w) {
switch (w.hashOf) {
case Wind.B.hashOf:
break;
default:
assert(0);
}
}
void main() {
some_function(Wind.B);
writefln("%d%d", Wind.C.expand);
}
Re: Tuple enumeration without integers or strings
On Saturday, 2 January 2021 at 21:48:04 UTC, Paul Backus wrote: Yes, but this will be true of any approach you choose. If two enum members have exactly the same value, there is no way to distinguish between them, either at compile time or at runtime. Oh I see, thanks! A bit of a bummer as I guess that means you're pretty much required to use an additional seperate structure like an array or map/associative array, the latter making the use of an enum instead of string names slightly pointless in this scenario, thank you nontheless .
Re: D static library on Windows 64 problem
On Saturday, 2 January 2021 at 22:04:28 UTC, WhatMeWorry wrote: I'm stepping through the windows static library tutorial at http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/CompilingLinkingD#Linkingmanually [...] Oops. used the manual example. Should be /LIBPATH:c:\dev\LibraryStudy\StaticLibrary\libfoobar
D static library on Windows 64 problem
I'm stepping through the windows static library tutorial at http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/CompilingLinkingD#Linkingmanually ``` The fix is to specify the prebuilt .lib file on the command line: dmd driver.d %cd%\libs\libfoo\libfoo.lib ``` The tutorial is for 32 bit so it uses OPTLINK. I'm using 64 bits so it uses Microsoft's link.exe When I try dmd -m64 -v driver.d -L=/LIBPATH:"c:\dev\LibraryStudy\StaticLibrary\libfoobar" I get this monstrosity link.exe /NOLOGO "driver.obj" /DEFAULTLIB:phobos64 /LIBPATH:"c:\dev\LibraryStudy\StaticLibrary\libfoobar" /OPT:NOICF /LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.27.29110\lib\x64" legacy_stdio_definitions.lib /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\ucrt\x64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x64" which I think would work except for the fact the path argument looses its double quotes. Is there a fix? I tried invoking link.exe directly with the ""s added manually, but then link.exe complains that phobos64.lib can't be found.
Re: Tuple enumeration without integers or strings
On Saturday, 2 January 2021 at 21:41:34 UTC, Paul wrote: On Saturday, 2 January 2021 at 03:20:29 UTC, Paul Backus wrote: 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: Im afraid that would still result in issues when duplicate enum vlues are at play right? Yes, but this will be true of any approach you choose. If two enum members have exactly the same value, there is no way to distinguish between them, either at compile time or at runtime.
Re: Tuple enumeration without integers or strings
On Saturday, 2 January 2021 at 03:20:29 UTC, Paul Backus wrote: 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: Im afraid that would still result in issues when duplicate enum vlues are at play right? (This issue would maybe warrant a compile time warning imho)
Re: What is the difference between "delegate()" and "lazy delegate()" ?
On 1/2/21 4:29 AM, Marcone wrote:
Why "lazy delegate()" need two parentheses to execute function?
lazy automatically makes a delegate that returns the type of the parameter:
void bar(lazy int i) {
writeln(i); // i is a delegate called automatically
}
Strangely, the delegateness leaks out and i() works as well:
writeln(i()); // WAT?
I agree with you that double parenthesis is strange for a lazy delegate
but the fact above explains to me what is happening: The first set is
for lazy's delegate to get the actual delegate, and the second set is
used for calling the actual delegate.
I agree that it feels wrong that d(3) is not allowed below even though
'i' alone is allowed above. I vaguely remember issues around delegates
where it wouldn't be clear whether one is referring to the delegate
itself with 'd' or whether calling the delegate as d() but without the
parenthesis.
Yeah, that's it: If we were allowed to call delegates without the
optional parenthesis, we would never be allowed to refer to a delegate
itself:
typeof(d)// <-- Is that the type of the delegate or what it returns?
So, the double parenthesis are needed for the fact that delegates cannot
be called without optional parenthesis. (I think. :) )
Here is a program that I played with before writing this:
import std.stdio;
import core.thread;
import std.random;
void foo(lazy int delegate(int) d) {
if (dice(50, 50)) {
writeln("Using the delegate");
d()(3);// d(3) should work as well
}
}
int delegate(int) delegateMaker(int multiplier) {
writeln("Waiting for expensive delegate making operation...");
Thread.sleep(2.seconds);
return (int i) {
writeln("Delegate called");
return multiplier * i;
};
}
void main(string[] args) {
foo(delegateMaker(2));
}
Ali
Re: What is the difference between "delegate()" and "lazy delegate()" ?
On Saturday, 2 January 2021 at 12:29:43 UTC, Marcone wrote: Why "lazy delegate()" need two parentheses to execute function? AFAIK is 'lazy' some kind of delegate storage class which accept an expression to execute. The reason you can actually use the parameter without "()" is just CTFE sugar which calls it automatically on use. On the other hand, if you supply a 'lazy delegate()' the compiler does not know to call only the lazy expression or the delegate itself.
Re: Socket handle leak and active handle warning with Vibe-D
On Friday, 1 January 2021 at 22:07:28 UTC, 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. [...] On Ubuntu 20.04 I get leaking drivers warning with the same process. [...] 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 For further reference, I also went through this issue [1]. It seems like I am seeing the same behavior as kinexis-uk. S [1] https://github.com/vibe-d/vibe.d/issues/2245
Re: Socket handle leak and active handle warning with Vibe-D
On Saturday, 2 January 2021 at 00:28:43 UTC, Steven Schveighoffer wrote: 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. [...] On Ubuntu 20.04 I get leaking drivers warning with the same process. [...] 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 Hey Steve. Thanks a ton for all the tips. FWIW I am writing down my findings below because just maybe they might be helpful for someone else later on. The scope guard seems to have fixed some of the leak complaints. Unfortunately there is still a leak after a single connection. Without connection Windows 10: Running .\vibe_noleaks.exe [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. [main() INF] Stopped to listen for HTTP requests on ::1:8080 [main() INF] Stopped to listen for HTTP requests on 127.0.0.1:8080 Without connection Ubuntu 20.04: Running ./vibe_noleaks [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. [main() INF] Stopped to listen for HTTP requests on ::1:8080 [main() INF] Stopped to listen for HTTP requests on 127.0.0.1:8080 After logging into to 127.0.0.1 for a single time in my browser, if I do a ctrl+c it still leaks two socket handles. With connection Windows 10: Running .\vibe_noleaks.exe [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. [main() INF] Stopped to listen for HTTP^ requests on C::1:8080 [main( ) INFC:\Software\vibe_noLeaks>] Stopped to listen for HTTP requests on 127.0.0.1:8080 Warning: 2 socket handles leaked at driver shutdown. Warning: 2 socket handles leaked at driver shutdown. I think vibe-d is also leaking more sockets when there is a web interface attached (not included in my toy repository). These haven't stopped me from developing but they are just things I wanted to write down and learn more before building even more infrastructure with it. I might dive into vibe-d codebase at some point too. Best, S
Re: Simple BeamUI project won't link
On Friday, 18 December 2020 at 19:14:25 UTC, Daren Scot Wilson wrote: So maybe beamui isn't ready for the real world. It's a one-off personal tool for image processing, maybe will go up on Github, so I don't need anything super-solid or well established. OTOH, if it's too much on the WIP side with lots of loose ends, it might be more work than my free time allows. At least, beamui appears to be more workable than dlangui which seems to have fallen away. Did you find a GUI library to work with? I'm in the same boat as you working on a tool for image processing in my free time.
What is the difference between "delegate()" and "lazy delegate()" ?
Why "lazy delegate()" need two parentheses to execute function?
