Re: Finding position of a value in an array
On Saturday, 6 February 2021 at 22:32:53 UTC, Ali Çehreli wrote: On 2/6/21 2:26 PM, mw wrote: On Tuesday, 31 December 2019 at 14:52:55 UTC, Steven Schveighoffer wrote: On 12/31/19 9:47 AM, Steven Schveighoffer wrote: for the original example: int[] a = [77,66,55,44]; int i = a.bwin.find(55).bufRef.pos; sorry, should be size_t i. Unsigned? Then how the function signal no such element found? The convention of indexOf is to use -1. I bet it returns size_t.max in that case. Make it harder to port code from other languages.
Vibe.d diet template help
Hi all, I'm trying to render a diet template out to a WebSocket as a string to be inserted into a specific portion of the currently served page. Does anyone know how to go about this?
Re: Finding position of a value in an array
On 2/6/21 2:26 PM, mw wrote: On Tuesday, 31 December 2019 at 14:52:55 UTC, Steven Schveighoffer wrote: On 12/31/19 9:47 AM, Steven Schveighoffer wrote: for the original example: int[] a = [77,66,55,44]; int i = a.bwin.find(55).bufRef.pos; sorry, should be size_t i. Unsigned? Then how the function signal no such element found? The convention of indexOf is to use -1. I bet it returns size_t.max in that case. Ali
Re: Finding position of a value in an array
On Tuesday, 31 December 2019 at 14:52:55 UTC, Steven Schveighoffer wrote: On 12/31/19 9:47 AM, Steven Schveighoffer wrote: for the original example: int[] a = [77,66,55,44]; int i = a.bwin.find(55).bufRef.pos; sorry, should be size_t i. Unsigned? Then how the function signal no such element found? The convention of indexOf is to use -1.
Re: Minimize GC memory footprint
On Saturday, 6 February 2021 at 19:13:33 UTC, Mike Parker wrote: On Saturday, 6 February 2021 at 17:50:18 UTC, frame wrote:> But .length = 0 should. What do you expect it to do in this case? Don't know - some compiler optimization? :D On Saturday, 6 February 2021 at 19:31:39 UTC, Siemargl wrote: 64bit heal a problem, but uses about 500Mb of RAM continuosly for this simple example, so its only patching sinkin' ship :-( Hmmm.. with -m64 it's reporting 80 MB used, 203 MB are really marked as private bytes. Constant. If I use GC.minimize() it goes up and down and sometimes consumes more than 203 MB. Best is 100MB. But it doesn't leak endlessly like the 32bit variant.
Re: Minimize GC memory footprint
On Saturday, 6 February 2021 at 19:10:14 UTC, Mike Parker wrote: On Saturday, 6 February 2021 at 17:50:18 UTC, frame wrote: Sorry, i forgot mem leak. Or maybe i incorrect understand Gc counters So log Usage: 698.46 MiB (free 187.42 MiB) / collected: 14 Round: 12 Usage: 759.72 MiB (free 184.16 MiB) / collected: 15 ... Usage: 802.00 MiB (free 202.88 MiB) / collected: 16 Usage: 871.38 MiB (free 197.50 MiB) / collected: 17 Usage: 935.64 MiB (free 200.24 MiB) / collected: 18 Usage: 995.86 MiB (free 210.02 MiB) / collected: 19 Usage: 1071.70 MiB (free 207.18 MiB) / collected: 20 Usage: 1139.22 MiB (free 215.66 MiB) / collected: 21 Usage: 1214.83 MiB (free 219.05 MiB) / collected: 22 Usage: 1297.88 MiB (free 218.00 MiB) / collected: 23 Usage: 1378.43 MiB (free 222.45 MiB) / collected: 24 Usage: 1416.72 MiB (free 184.16 MiB) / collected: 25
Re: Minimize GC memory footprint
On Saturday, 6 February 2021 at 19:10:14 UTC, Mike Parker wrote: On Saturday, 6 February 2021 at 17:50:18 UTC, frame wrote: On Saturday, 6 February 2021 at 15:45:47 UTC, rikki cattermole wrote: Default settings should work out of the box. If not - it's bad for reputation of the language. Given that 32-bit has been the default on Windows for D's entire lifetime, I don't expect this is so common of an issue. More harmful would be requiring Visual Studio to compile with the default settings. That said, dub already uses -m64 by default on Windows. And the goal is to enable 64-bit in dmd on Windows by default. That's the reason the MinGW-based link libraries and the LDC linker were added to the distribution, so that it will work out of the box. I don't know what the timetable is supposed to be, but at some point after that is rock solid, the switch to 64-bit by default will be made. This example seems been as a corner uglyness of AA realisation. 64bit heal a problem, but uses about 500Mb of RAM continuosly for this simple example, so its only patching sinkin' ship :-(
Re: Minimize GC memory footprint
On Saturday, 6 February 2021 at 17:50:18 UTC, frame wrote:> But .length = 0 should. What do you expect it to do in this case?
Re: Minimize GC memory footprint
On Saturday, 6 February 2021 at 17:50:18 UTC, frame wrote: On Saturday, 6 February 2021 at 15:45:47 UTC, rikki cattermole wrote: Default settings should work out of the box. If not - it's bad for reputation of the language. Given that 32-bit has been the default on Windows for D's entire lifetime, I don't expect this is so common of an issue. More harmful would be requiring Visual Studio to compile with the default settings. That said, dub already uses -m64 by default on Windows. And the goal is to enable 64-bit in dmd on Windows by default. That's the reason the MinGW-based link libraries and the LDC linker were added to the distribution, so that it will work out of the box. I don't know what the timetable is supposed to be, but at some point after that is rock solid, the switch to 64-bit by default will be made.
Re: Tuple or struct as return type?
On Saturday, 6 February 2021 at 18:02:46 UTC, Martin wrote: Why/when i should prefer Tuple as a return type over returning a struct (or even string[2] in this case)? A Tuple is just a struct declared inlined. I personally use struct every single time - structs can be separately documented and be custom tailored to other situation, more compatible if you change your mind and add stuff later - but I guess if it is utterly trivial the inline definition of Tuple might be convenient.
Tuple or struct as return type?
Hi, lets say i want to create a function that returns multiple values - e.g. Tuple!(string,string). Why/when i should prefer Tuple as a return type over returning a struct (or even string[2] in this case)? Thank you
Re: Minimize GC memory footprint
On Saturday, 6 February 2021 at 15:45:47 UTC, rikki cattermole wrote: The GC shouldn't be aware of the scope guard. It expands out into a try finally block. But .length = 0 should. Nah, this is old. It is also bad D code. Allocate up front and then set. I agree but it has to work anyway. New users do not ask about how they can write friendly GC code. This will be significantly faster, as it won't require allocating more than once and will prevent heap fragmentation which 32bit is severely affected by (hence why precise GC is important for testing on this target). Ah, yes. I read about it in another thread. This is a specific problem for any GC that work on the same way, not only in D. But if it's a known problem, the default architecture should be 64bit where things just work. 32bit should be an opt-in then. Default settings should work out of the box. If not - it's bad for reputation of the language.
Re: Finding position of a value in an array
On Saturday, 6 February 2021 at 15:47:05 UTC, Rumbu wrote: On Sunday, 29 December 2019 at 08:26:58 UTC, Daren Scot Wilson wrote: [...] Just reactivating this post to tell you that I lost 15 minutes of my life searching for a basic way to obtain the position of an element in an array; Out of frustration, I ended to write my own indexOf function. Any library on Earth has such function and it's not named countUntil, nor giveMeTheDamnPositionOfXInThatArray. It seems that D is specialised in finding needles in haystacks, not finding elements in arrays. https://issues.dlang.org/show_bug.cgi?id=21615 +1
Re: Finding position of a value in an array
On Sunday, 29 December 2019 at 08:26:58 UTC, Daren Scot Wilson wrote: Reading documentation... Array, Algorithms, ... maybe I've been up too late... how does one obtain the index of, say, 55 in an array like this int[] a = [77,66,55,44]; I want to do something like: int i = a.find_value_returning_its_index(55); assert(i==2) I'm sure it's obvious but I'm not seeing it right now. Just reactivating this post to tell you that I lost 15 minutes of my life searching for a basic way to obtain the position of an element in an array; Out of frustration, I ended to write my own indexOf function. Any library on Earth has such function and it's not named countUntil, nor giveMeTheDamnPositionOfXInThatArray. It seems that D is specialised in finding needles in haystacks, not finding elements in arrays. https://issues.dlang.org/show_bug.cgi?id=21615
Re: Minimize GC memory footprint
On 07/02/2021 4:22 AM, frame wrote:
On Saturday, 6 February 2021 at 13:30:03 UTC, rikki cattermole wrote:
Okay, its still seeing something is alive then.
That's why I used the scope guard. I know it shouldn't have any effect
but I want to give the GC an extra hint ;)
The GC shouldn't be aware of the scope guard. It expands out into a try
finally block.
I've compiled and ran it under ldc. Dmd in 32bit mode is certainly
doing something that the GC doesn't appreciate. I can reproduce it
with -m32mscoff as well. So yeah dmd specific all right.
The sad story never ends.
But seriously are there no runtime tests before releasing the next DMD?
The GC is a main feature of D and such things give a bad impression.
Nah, this is old. It is also bad D code.
Allocate up front and then set.
T[] buffer;
buffer.length = 1_000_000;
foreach(i, v; source[0 .. 1_000_000]) {
buffer[i] = someOp(v);
}
This will be significantly faster, as it won't require allocating more
than once and will prevent heap fragmentation which 32bit is severely
affected by (hence why precise GC is important for testing on this target).
Re: unittest compiles w/o error though module file is not named after the module
On 06.02.21 16:05, kdevel wrote:
On Saturday, 6 February 2021 at 14:52:57 UTC, Adam D. Ruppe wrote:
[...]
That one `import p;` is kinda weird, it should probably complain then
you imported one thing and got another, but generally the name not
matching is no problem at all.
```main.d (version 2)
// import x;
unittest {
// import pp: foo; // wrong name is accepted if x is imported
import p: foo;
foo;
}
```
Looks like .
Re: Can someone explain this?
On Saturday, 6 February 2021 at 15:00:45 UTC, Adam D. Ruppe wrote: On Saturday, 6 February 2021 at 14:39:38 UTC, Jeff wrote: Okay, the above works. But, I'm not sure why? Phobos's enum conversion always looks at the identifier, whereas the rest of the language looks at the value. ... to!string(op) // goes through the library's conversion This makes sense and is what I was missing. Thanks!
Re: Minimize GC memory footprint
On Saturday, 6 February 2021 at 13:30:03 UTC, rikki cattermole wrote: Okay, its still seeing something is alive then. That's why I used the scope guard. I know it shouldn't have any effect but I want to give the GC an extra hint ;) I've compiled and ran it under ldc. Dmd in 32bit mode is certainly doing something that the GC doesn't appreciate. I can reproduce it with -m32mscoff as well. So yeah dmd specific all right. The sad story never ends. But seriously are there no runtime tests before releasing the next DMD? The GC is a main feature of D and such things give a bad impression.
Re: Why filling AA in shared library freezes execution?
On Saturday, 6 February 2021 at 10:44:08 UTC, Siemargl wrote: On Saturday, 30 January 2021 at 20:32:36 UTC, Siemargl wrote: No, this is a deadlock in memory manager. To find roots of problem, needed a debug version of druntime, but i were unsuccesfull to compile it. I make debug vesion of druntime and catch nicer stacktrace. Maybe this can help somebody knowing GC internals So it seems, that disabling parallel GC, solves problem. I add in BOTH dll and main module and cant reproduce freeze anymore extern(C) __gshared string[] rt_options = [ "gcopt=parallel:0" ];
Re: unittest compiles w/o error though module file is not named after the module
On Saturday, 6 February 2021 at 14:52:57 UTC, Adam D. Ruppe wrote:
[...]
That one `import p;` is kinda weird, it should probably
complain then you imported one thing and got another, but
generally the name not matching is no problem at all.
```main.d (version 2)
// import x;
unittest {
// import pp: foo; // wrong name is accepted if x is imported
import p: foo;
foo;
}
```
also passes the unittest, same output (void pp.foo()). I am under
the impression that at least this main.d version should fail
because there is no module named "p" (it's named "pp").
Re: Can someone explain this?
On Saturday, 6 February 2021 at 14:39:38 UTC, Jeff wrote:
Okay, the above works. But, I'm not sure why?
Phobos's enum conversion always looks at the identifier, whereas
the rest of the language looks at the value. Remember phobos'
writeln forwards to the rest of its conversions just like `to`.
So in the language like
string s = op; // gives the value under language rules
auto s = cast(string) op; // the value under language rules
to!string(op) // goes through the library's conversion functions
and thus gives the name
The idea is the library tries to be more consistent and names are
generally nice:
enum ERROR {
OK = 1,
FILE_NOT_FOUND = 2,
ETC = 3
}
writeln(error); // FILE_NOT_FOUND prolly better than 2 here
string s = "OK";
ERROR e = to!ERROR(s); // looks it up by name
So it is generally nice and then it does it consistently for
string values too.
So, I'm guessing there's something going on under-the-hood
using the ~ operator with the enum and I'd like to understand
what it is.
mixin and ~ follow language rules and thus work on the value.
Likewise, if there's an easier method of getting the "value of
enum" I haven't discovered yet, that'd be just as nice to know.
So when you're writelning, do something under language rules
first so Phobos doesn't see the static type. If phobos doesn't
know it is is an enum, it is forced to work with a value too.
Easiest is to just cast it:
writeln(cast(string) op);
Re: Can someone explain this?
On Saturday, 6 February 2021 at 14:39:38 UTC, Jeff wrote: So, I'm guessing there's something going on under-the-hood using the ~ operator with the enum and I'd like to understand what it is. Enum to string conversion is usually implemented using the name of the enum member, regardless of it's value (which might be any type). String concatenation is not defined for A, so the enum member is implicitly converted to it's base type (see [1], paragraph 5). Likewise, if there's an easier method of getting the "value of enum" I haven't discovered yet, that'd be just as nice to know. ;) You can use an is expression to determine the base type... ``` is(A BaseType == enum) ``` ...and use `cast(BaseType) A.foo` [1] https://dlang.org/spec/enum.html#named_enums
Re: unittest compiles w/o error though module file is not named after the module
Module names and file names are completely independent on the language level. You can have a file `whatever.d` with `module foo.bar.totally.different;` and `import foo.bar.totally.different` and it all works as long as you add the whatever.d to the build. The only reason people recommend they match is that then the file can be found automatically. dmd program.d whatever.d # works from module names dmd -i program.d # now it will look for foo/bar/totally/different.d by convention because you didn't list the file. That one `import p;` is kinda weird, it should probably complain then you imported one thing and got another, but generally the name not matching is no problem at all.
Re: Can someone explain this?
Also wanted to note that if I do: string enumValue = op; writeln(enumValue); Then it also outputs foo and bar. So, why would the behavior of op.to!string not be the same?
Can someone explain this?
I'm trying to get the values of an enum at compile-time and
running into a behavior I don't understand.
Consider the following enum:
enum A {x="foo", y="bar"}
And now, I just want to print out the values of A at runtime
(e.g. A.x = "foo").
void main()
{
static foreach(i, op; EnumMembers!A)
{
writeln("A." ~ op.to!string ~ " = " ~ op);
}
}
Okay, the above works. But, I'm not sure why?
If I just do writeln(op), it prints out x and y, which is the
same if I do op.to!string. If I use a mixin... mixin("\"" ~ op ~
"\"") then it prints foo and bar.
So, I'm guessing there's something going on under-the-hood using
the ~ operator with the enum and I'd like to understand what it
is.
Likewise, if there's an easier method of getting the "value of
enum" I haven't discovered yet, that'd be just as nice to know. ;)
Thanks!
unittest compiles w/o error though module file is not named after the module
```p.d
module pp;
void foo ()
{
import std.stdio: writeln;
__PRETTY_FUNCTION__.writeln;
}
```
```x.d
import p;
```
```main.d
import x;
unittest {
import pp: foo; // wrong name is accepted if x is imported
// import p: foo;
foo;
}
```
$ dmd -i -unittest -main -run main
void pp.foo()
1 unittests passed
Came across this while doing a comprehensive file renaming in a
package.
I usually let me guide thru the codebase by the compile error
messages.
However, make test unexpectedly succeeded though I have not yet
adapted
all import directives.
Of course I could use git grep for this process but I would
prefer that
the compilation would fail in the first place.
Re: Minimize GC memory footprint
On 07/02/2021 12:38 AM, Siemargl wrote:
On Saturday, 6 February 2021 at 11:20:18 UTC, Imperatorn wrote:
On Saturday, 6 February 2021 at 09:42:38 UTC, rikki cattermole wrote:
On 06/02/2021 3:32 PM, frame wrote:
[...]
This won't do anything.
[...]
Don't forget to stdout.flush; Otherwise stuff can get caught in the
buffer before erroring out.
[...]
Turn on the precise GC, 32bit is a bit too small of a range and you
can get false positives like in this case (at least looks like it).
For reference, how does one turn on precise GC?
https://dlang.org/spec/garbage.html#gc_config
Strange things happens:
- precise scanning dont change result - OOM @ same round 27
Okay, its still seeing something is alive then.
--DRT-gcopt=help wont show used gc implementation, also cleanup type
not printed
https://github.com/dlang/druntime/blob/master/src/core/gc/config.d#L36
- maxPoolSize:N dont limit total size of GC
Shouldn't change anything, except make OOM happen faster.
- in gc:manual mode GC.collect() not releasing memory
https://github.com/dlang/druntime/blob/master/src/gc/impl/manual/gc.d#L84
When i print free GC memory, it seems to memory leaking
writefln("Usage: %.2f MiB (free %.2f MiB) / collected: %d",
(cast(double) GC.stats.usedSize) / 1_048_576,
(cast(double) GC.stats.freeSize) / 1_048_576,
GC.profileStats.numCollections);
stdout.flush();
I've compiled and ran it under ldc. Dmd in 32bit mode is certainly doing
something that the GC doesn't appreciate. I can reproduce it with
-m32mscoff as well. So yeah dmd specific all right.
Re: Minimize GC memory footprint
On Saturday, 6 February 2021 at 11:20:18 UTC, Imperatorn wrote:
On Saturday, 6 February 2021 at 09:42:38 UTC, rikki cattermole
wrote:
On 06/02/2021 3:32 PM, frame wrote:
[...]
This won't do anything.
[...]
Don't forget to stdout.flush; Otherwise stuff can get caught
in the buffer before erroring out.
[...]
Turn on the precise GC, 32bit is a bit too small of a range
and you can get false positives like in this case (at least
looks like it).
For reference, how does one turn on precise GC?
https://dlang.org/spec/garbage.html#gc_config
Strange things happens:
- precise scanning dont change result - OOM @ same round 27
--DRT-gcopt=help wont show used gc implementation, also cleanup
type not printed
- maxPoolSize:N dont limit total size of GC
- in gc:manual mode GC.collect() not releasing memory
When i print free GC memory, it seems to memory leaking
writefln("Usage: %.2f MiB (free %.2f MiB) / collected: %d",
(cast(double) GC.stats.usedSize) / 1_048_576,
(cast(double) GC.stats.freeSize) / 1_048_576,
GC.profileStats.numCollections);
stdout.flush();
Re: Minimize GC memory footprint
On Saturday, 6 February 2021 at 09:42:38 UTC, rikki cattermole wrote: On 06/02/2021 3:32 PM, frame wrote: [...] This won't do anything. [...] Don't forget to stdout.flush; Otherwise stuff can get caught in the buffer before erroring out. [...] Turn on the precise GC, 32bit is a bit too small of a range and you can get false positives like in this case (at least looks like it). For reference, how does one turn on precise GC?
Re: Why filling AA in shared library freezes execution?
On Saturday, 30 January 2021 at 20:32:36 UTC, Siemargl wrote: No, this is a deadlock in memory manager. To find roots of problem, needed a debug version of druntime, but i were unsuccesfull to compile it. I make debug vesion of druntime and catch nicer stacktrace. Maybe this can help somebody knowing GC internals ntdll!ZwWaitForSingleObject+0xa ntdll!RtlDeNormalizeProcessParams+0x5a8 ntdll!RtlDeNormalizeProcessParams+0x4a4 ntdll!RtlInitializeCriticalSectionEx+0x3b9 KERNELBASE!HeapDestroy+0x3a KERNELBASE!GetModuleHandleExW+0x39 test_dll!D4core6thread8osthread23ll_startDLLUnloadThreadFNbNiZb+0x86 test_dll!D4core6thread8osthread20createLowLevelThreadFNbNiDFNbZvkDFNbZvZk+0x153 test_dll!D2gc4impl12conservativeQw3Gcx16startScanThreadsMFNbZv+0xc5 test_dll!D2gc4impl12conservativeQw3Gcx11fullcollectMFNbbZm+0x12f test_dll!D2gc4impl12conservativeQw3Gcx10smallAllocMFNbmKmkxC8TypeInfoZPv+0x135 test_dll!D2gc4impl12conservativeQw14ConservativeGC__T9runLockedS_DQCeQCeQCcQCnQBs12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS_DQEgQEgQEeQEp10mallocTimelS_DQFiQFiQFgQFr10numMallocslTmTkTmTxQCzZQFcMFNbKmKkKmKxQDsZQDl+0xa1 test_dll!D2gc4impl12conservativeQw14ConservativeGC6mallocMFNbmkxC8TypeInfoZPv+0x4b test_dll!gc_malloc+0x2d test_dll!aaGetX+0x2ca test_dll!aaGetY+0x39 test_dll!test_dll.TestFun+0x93 test_dll_exe!D main+0x111 test_dll_exe!D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZ9__lambda1MFZv+0x33 test_dll_exe!D2rt6dmain212_d_run_main2UAAamPUQgZiZ7tryExecMFMDFZvZv+0x3c
Re: Minimize GC memory footprint
On 06/02/2021 3:32 PM, frame wrote:
On Friday, 5 February 2021 at 22:46:05 UTC, Bastiaan Veelo wrote:
?? Do you mean no collections happen? 32bit GC should just work.
No, it doesn't - this code fails on memory allocation and works fine
with -m64 switch:
import std.stdio;
import core.memory : GC;
void main() {
void usage() {
writefln("Usage: %.2f MiB / collected: %d", (cast(double)
GC.stats.usedSize) / 1_048_576, GC.profileStats.numCollections);
}
void foo() {
string[] s;
scope (exit) {
s.length = 0;
This won't do anything.
}
foreach (i; 0 .. 50_000_00) {
s ~= "a";
}
}
foreach (i; 0 .. uint.max) {
writefln("Round: %d", i + 1);
Don't forget to stdout.flush; Otherwise stuff can get caught in the
buffer before erroring out.
foo();
GC.collect();
usage();
}
}
...
Round: 24
Usage: 1603.57 MiB / collected: 27
Round: 25
Usage: 1691.64 MiB / collected: 28
Round: 26
Usage: 1729.50 MiB / collected: 29
Round: 27
core.exception.OutOfMemoryError@src\core\exception.d(647): Memory
allocation failed
Turn on the precise GC, 32bit is a bit too small of a range and you can
get false positives like in this case (at least looks like it).
Re: Ugly c++ syntax
On Friday, 5 February 2021 at 21:10:21 UTC, Rumbu wrote:
Can some C++ guru translate in D the template below?
I gave up after reading a lot, but I didn't manage to
understand the meaning "&& ..."
template static uint8_t
composite_index_size(Tables const&... tables) { return
(composite_index_size(tables.size(),
impl::bits_needed(sizeof...(tables))) && ...) ? 2 : 4; }
Thanks.
modern cpp looks like 10 lines of decl for 1 of actual code.
Re: Ugly c++ syntax
On Saturday, 6 February 2021 at 00:35:12 UTC, Ali Çehreli wrote: On 2/5/21 1:10 PM, Rumbu wrote: I gave up after reading a lot, but I didn't manage to understand the meaning "&& ..." I think it's the universal reference. Thank you Ali, but nope, it's "parameter pack folding". This allows starting with C++ 17 to have recursive templates in one liner. Basically, it means "&& template(the rest of arguments)" https://github.com/microsoft/cppwin32/blob/8a6b2507734dd9e9892059b5794f35109688fc20/cppwin32/winmd/impl/winmd_reader/database.h#L490
