what's the most efficient way to implement std.container.binaryheap.back()?
Hi, https://dlang.org/phobos/std_container_binaryheap.html The binary heap induces structure over the underlying store such that accessing the largest element (by using the front property) is a Ο(1) operation. I'm wondering what's the most efficient (in terms of both speed and memory usage) way to implement std.container.binaryheap.back()? i.e accessing the smallest element. Has anyone done this before? Thanks.
Re: Are there anything like leetcode.com but that supports D?
On Sunday, 24 October 2021 at 19:14:59 UTC, Imperatorn wrote: On Sunday, 24 October 2021 at 05:46:48 UTC, Dr Machine Code wrote: I'd like that to some friends getting start with programming. Sadly that platform doesn't support D. https://exercism.org/tracks/d also good one, thanks
Re: Are there anything like leetcode.com but that supports D?
On Sunday, 24 October 2021 at 12:49:03 UTC, jfondren wrote: On Sunday, 24 October 2021 at 05:46:48 UTC, Dr Machine Code wrote: I'd like that to some friends getting start with programming. Sadly that platform doesn't support D. Here are a few: https://www.codingame.com/ https://www.spoj.com/ https://www.hackerrank.com/ very good list, thanks
Re: Dub failing to use the linker correctly.
On Friday, 22 October 2021 at 19:56:37 UTC, Ruby The Roobster wrote: I have a simple vibe-d project built with dub. Running the command, dub build --force returns the following output: Performing "debug" build using E:\Programs\D\dmd2\windows\bin\dmd.exe for x86_64. mir-linux-kernel 1.0.1: building configuration "library"... taggedalgebraic 0.11.22: building configuration "library"... eventcore 0.9.18: building configuration "winapi"... stdx-allocator 2.77.5: building configuration "library"... vibe-core 1.21.0: building configuration "winapi"... vibe-d:crypto 0.9.4: building configuration "library"... vibe-d:utils 0.9.4: building configuration "library"... vibe-d:data 0.9.4: building configuration "library"... diet-ng 1.8.0: building configuration "library"... vibe-d:stream 0.9.4: building configuration "library"... vibe-d:textfilter 0.9.4: building configuration "library"... vibe-d:inet 0.9.4: building configuration "library"... vibe-d:tls 0.9.4: building configuration "openssl-mscoff"... vibe-d:http 0.9.4: building configuration "library"... vibe-d:mail 0.9.4: building configuration "library"... vibe-d:mongodb 0.9.4: building configuration "library"... vibe-d:redis 0.9.4: building configuration "library"... vibe-d:web 0.9.4: building configuration "library"... vibe-d 0.9.4: building configuration "vibe-core"... web ~master: building configuration "application"... Compiling Diet HTML template caccount.dt... Linking... lld-link: error: subsystem must be defined Error: linker exited with status 1 Does anybody know why this happens? I am on the latest version of the dmd compiler(2.098.0.) Thanks in advance. Try to install another linker. https://code.dawg.eu/reducing-vibed-turnaround-time-part-1-faster-linking.html
Re: TimeoutException for connecting to MySQL using a hunt-entity.
On Friday, 22 October 2021 at 11:51:03 UTC, WebFreak001 wrote: On Friday, 22 October 2021 at 11:42:34 UTC, greenbyte wrote: Hi, all! I use the hunt-entity library to work with MySQL. I get the hunt.Exceptions.TimeoutException: "Timeout in 30 secs" when trying to connect. I configured MySQL and ran the code from the instructions https://github.com/huntlabs/hunt-entity MySQL: mysql Ver 8.0.27 for Linux on x86_64 (MySQL Community Server - GPL) DUB: version 1.25.0, built on Apr 23 2021 In dub.json enabled "hunt-entity": "~>2.7.3" From the error message you posted it seems like it's failing to connect. Did you check that the IP address and port you are connecting to are correct? In case of localhost, try 127.0.0.1 instead of "localhost" Yes, I did.
Re: Are there anything like leetcode.com but that supports D?
On Sunday, 24 October 2021 at 05:46:48 UTC, Dr Machine Code wrote: I'd like that to some friends getting start with programming. Sadly that platform doesn't support D. https://exercism.org/tracks/d
Re: Are there anything like leetcode.com but that supports D?
On Sunday, 24 October 2021 at 14:39:27 UTC, jfondren wrote: On Sunday, 24 October 2021 at 14:14:48 UTC, Imperatorn wrote: On Sunday, 24 October 2021 at 05:46:48 UTC, Dr Machine Code wrote: I'd like that to some friends getting start with programming. Sadly that platform doesn't support D. May I ask what platform? It's in the subject: leetcode.com Oh, I totally missed that
Re: Possible runtime bug in preprocessing of command line arguments passed to the D main
On Sunday, 24 October 2021 at 14:38:44 UTC, jfondren wrote: With nothing to the contrary, I'd take "must be terminated by a null pointer" as "can't itself be a null pointer". The execve(2) is more explicit: "The argument argv is a pointer to a null-terminated array of character pointers to NUL-terminated character strings. These strings construct the argument list to be made available to the new process. At least one non-null argument must be present in the array; by custom, the first element should be the name of the executed program (for example, the last component of path)."
Re: Possible runtime bug in preprocessing of command line arguments passed to the D main
On Sunday, 24 October 2021 at 14:38:44 UTC, jfondren wrote: [...] With nothing to the contrary, I'd take "must be terminated by a null pointer" as "can't itself be a null pointer". ah yeah, and thanks, of course ... how would the count of arg be known without the sentinel...
Re: Are there anything like leetcode.com but that supports D?
On Sunday, 24 October 2021 at 14:14:48 UTC, Imperatorn wrote: On Sunday, 24 October 2021 at 05:46:48 UTC, Dr Machine Code wrote: I'd like that to some friends getting start with programming. Sadly that platform doesn't support D. May I ask what platform? It's in the subject: leetcode.com
Re: Possible runtime bug in preprocessing of command line arguments passed to the D main
On Sunday, 24 October 2021 at 14:21:52 UTC, Basile B. wrote: What do you think ? I'm very surprised that this is even allowed. Apparently it's Linux userspace that normally complains about it: https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/progname.c#n54 The manpages just say ``` v - execv(), execvp(), execvpe() The char *const argv[] argument is an array of pointers to null-terminated strings that represent the argument list available to the new program. The first argument, by convention, should point to the filename associated with the file being executed. The array of pointers must be terminated by a null pointer. ``` With nothing to the contrary, I'd take "must be terminated by a null pointer" as "can't itself be a null pointer". On OpenBSD this fails outright: ``` RET execve -1 errno 14 Bad address ``` You can get `execv` from `core.sys.posix.unistd`
Re: Possible runtime bug in preprocessing of command line arguments passed to the D main
On Sunday, 24 October 2021 at 14:21:52 UTC, Basile B. wrote:
The following code, on linux
[...]
What do you think ?
Forgot to say that this change
```diff
- execv("a", null);
+ execv("a", ["whatever".ptr].ptr);
```
makes the problem goes away, so it would be caused by how `null`
args are handled, presumably.
Possible runtime bug in preprocessing of command line arguments passed to the D main
The following code, on linux
```d
module runnable;
extern(C) int execv(const char* p, const char** args);
immutable src = `
import std.getopt;
void main(string[] args)
{
bool c;
getopt(args, "c", &c);
}
`;
void prepareProgram()
{
import std.process : execute;
import std.file : write;
write("a.d", src);
execute(["dmd", "a.d"]);
}
void main(string[] args)
{
prepareProgram();
execv("a", null);
}
```
results in a std.getopt exception:
object.Exception@/usr/include/dmd/phobos/std/getopt.d(423):
Invalid arguments string passed: program name missing
Context is a program not written in D that uses execv to call a D
program that uses getopt.
What do you think ?
Re: Is there an alternative to "__FUNCTION__" that gives the actual function symbol and not the name as a string?
On Sunday, 24 October 2021 at 14:05:35 UTC, Simon wrote: On Saturday, 23 October 2021 at 20:24:32 UTC, Tim wrote: [...] That worked! I needed to modify it a bit, since there is the "execution_count_to_log_reproduction_on"-template parameterto the enum. If I try to use that inside the token string, it just says it can't find the identifier, so I had to inject some non-token string in the middle that plays nice with the token string, where I can actually reference the parameter. For completeness, here is how the code looks like now (I am completely horrified by the result): [...] and the usage just looks like this: [...] The "mixin(OUTPUT_REPRO_CASE!());" then expands to: [...] Thanks for your help!!! Maybe core.reflect and codegen could help with this when it gets released
Re: std.zip expand: memory allocation failed
On Sunday, 24 October 2021 at 12:00:39 UTC, Selim Ozel wrote: On Friday, 15 October 2021 at 20:41:36 UTC, Selim Ozel wrote: [...] It turns out my computer was literally running out of memory as the file was getting unzipped. For some reason to uncompress a 1-gig file with uncompressed size of 4-gig, Zip Archive of D-Lang tries to use more than 16 gig of RAM. I don't know why. Maybe I missed something. I use a Windows 10, DMD v2.091 with x86_mscoff. My work around was to call 7z from D Lang and do the compression over there. That worked like a charm. It seems that zip.d [1] calls uncompress routine from zlib.d [2]. Would calling zlib uncompress by chunks solve this memory issue? Any ideas? S [1] https://github.com/dlang/phobos/blob/master/std/zip.d [2] https://github.com/dlang/phobos/blob/master/std/zlib.d Create an issue and we can solve it
Re: Are there anything like leetcode.com but that supports D?
On Sunday, 24 October 2021 at 05:46:48 UTC, Dr Machine Code wrote: I'd like that to some friends getting start with programming. Sadly that platform doesn't support D. May I ask what platform?
Re: Is there an alternative to "__FUNCTION__" that gives the actual function symbol and not the name as a string?
On Saturday, 23 October 2021 at 20:24:32 UTC, Tim wrote:
import std.traits, std.stdio;
string generateLogCode(alias func)()
{
string code = "writeln(";
code ~= "\"" ~ fullyQualifiedName!func ~ "(\"";
foreach(i, param; ParameterIdentifierTuple!func)
{
if(i)
code ~= ", \", \"";
code ~= ", " ~ param;
}
code ~= ", \");\");";
return code;
}
enum OUTPUT_REPRO_CASE = q{
pragma(msg, generateLogCode!(__traits(parent, {}))());
mixin(generateLogCode!(__traits(parent, {}))());
};
void test(int a, int[] b)
{
mixin(OUTPUT_REPRO_CASE);
}
void main()
{
test(1, [2, 3]);
}
That worked! I needed to modify it a bit, since there is the
"execution_count_to_log_reproduction_on"-template parameterto the
enum. If I try to use that inside the token string, it just says
it can't find the identifier, so I had to inject some non-token
string in the middle that plays nice with the token string, where
I can actually reference the parameter.
For completeness, here is how the code looks like now (I am
completely horrified by the result):
string generate_call_to_log_reproduction(alias func)(){
string code =
"dlog(generate_reproduction_for_current_function_call!("~fullyQualifiedName!func~", [get_string_argument_list_of_function!([ParameterIdentifierTuple!(__traits(parent, {}))])])(context.temp_allocator";
foreach(i, param; ParameterIdentifierTuple!func)
code ~= "," ~ param;
code ~= "));";
return code;
}
string generate_call_to_log_execution_count(alias func)(){
return "dlog(\""~fullyQualifiedName!(func)~" execution count:
%lld\", execution_count);";
}
enum OUTPUT_REPRO_CASE(s64
execution_count_to_log_reproduction_on = -1) = q{
static s64 execution_count = 0;
if(context.settings.debug_.output_call_counts_for_reproducible_functions){
mixin(generate_call_to_log_execution_count!(__traits(parent,
{})));
}
} ~ "if(execution_count ==
"~execution_count_to_log_reproduction_on.stringof~")"~q{
{
mixin(generate_call_to_log_reproduction!(__traits(parent,
{}))());
trigger_breakpoint();
}
execution_count++;
};
and the usage just looks like this:
void some_function(int a, int b){
mixin(OUTPUT_REPRO_CASE!());
return a + b;
}
The "mixin(OUTPUT_REPRO_CASE!());" then expands to:
static s64 execution_count = 0;
if(context.settings.debug_.output_call_counts_for_reproducible_functions){
mixin(generate_call_to_log_execution_count!(__traits(parent,
{})));
}
if(execution_count == -1L){
mixin(generate_call_to_log_reproduction!(__traits(parent,
{}))());
trigger_breakpoint();
}
execution_count++;
Thanks for your help!!!
Re: Are there anything like leetcode.com but that supports D?
On Sunday, 24 October 2021 at 05:46:48 UTC, Dr Machine Code wrote: I'd like that to some friends getting start with programming. Sadly that platform doesn't support D. Here are a few: https://www.codingame.com/ https://www.spoj.com/ https://www.hackerrank.com/
Re: std.zip expand: memory allocation failed
On Friday, 15 October 2021 at 20:41:36 UTC, Selim Ozel wrote: I am simply trying to unzip a compressed zip file slightly over 1GB. The de-compressed size is about 4 GB. The code is very similar to what's explained in the documentation [1] and it works for smaller files. Anyone has a solution? Memory mapping [2] previously solved some part of my issue but expand is still throwing memory allocation failure. Selim [1] https://dlang.org/phobos/std_zip.html [2] https://forum.dlang.org/thread/mfnleztnwrbgivjvz...@forum.dlang.org It turns out my computer was literally running out of memory as the file was getting unzipped. For some reason to uncompress a 1-gig file with uncompressed size of 4-gig, Zip Archive of D-Lang tries to use more than 16 gig of RAM. I don't know why. Maybe I missed something. I use a Windows 10, DMD v2.091 with x86_mscoff. My work around was to call 7z from D Lang and do the compression over there. That worked like a charm. It seems that zip.d [1] calls uncompress routine from zlib.d [2]. Would calling zlib uncompress by chunks solve this memory issue? Any ideas? S [1] https://github.com/dlang/phobos/blob/master/std/zip.d [2] https://github.com/dlang/phobos/blob/master/std/zlib.d
