Re: How to detect free/unfree memory segments?
On Saturday, 24 December 2016 at 01:15:43 UTC, jkpl wrote: On Friday, 23 December 2016 at 06:18:02 UTC, Suliman wrote: I would like to visualize how GC works and display free/not free memory segments. How I can understand which of them are used and which not? Could anybody explain what dangerous of memory fragmentation in languages without GC? Am I right understand that there is stay some small memory chunks that very hard to reuse? You start with a wrong assumption. The C malloc functions is not just a nasty and mean memory provider. Several implementations uses internally freelists. Which means that the gaps created by a free() may be filled again. For example - TCMallocator use free lists - GCC C malloc use free lists (as stated here http://www.gnu.org/software/libc/manual/html_node/Freeing-after-Malloc.html) - for snn.lib malloc (used by DMD win32) I can't say. So there is no any problems with memory fragmentation and all used memory arr successfuly reuse?
Re: How to detect free/unfree memory segments?
On Friday, 23 December 2016 at 06:18:02 UTC, Suliman wrote: I would like to visualize how GC works and display free/not free memory segments. How I can understand which of them are used and which not? Could anybody explain what dangerous of memory fragmentation in languages without GC? Am I right understand that there is stay some small memory chunks that very hard to reuse? You start with a wrong assumption. The C malloc functions is not just a nasty and mean memory provider. Several implementations uses internally freelists. Which means that the gaps created by a free() may be filled again. For example - TCMallocator use free lists - GCC C malloc use free lists (as stated here http://www.gnu.org/software/libc/manual/html_node/Freeing-after-Malloc.html) - for snn.lib malloc (used by DMD win32) I can't say.
Re: How to initialize a associative array?
On Saturday, 24 December 2016 at 00:57:04 UTC, Yuxuan Shui wrote:
On Saturday, 24 December 2016 at 00:55:01 UTC, Yuxuan Shui
wrote:
I tried this:
immutable int[char] xx = ['Q':0, 'B':1, 'N':2, 'R':3,
'P':4];
And got a "non-constant expression" error (with or without
'immutable').
What's the correct way?
This example here: https://dlang.org/spec/hash-map.html,
doesn't work either.
Is this at global scope?
You need to use a `shared static this() { ... }` to initialise it.
How to initialize a associative array?
I tried this: immutable int[char] xx = ['Q':0, 'B':1, 'N':2, 'R':3, 'P':4]; And got a "non-constant expression" error (with or without 'immutable'). What's the correct way?
Re: Simplest way to build a DMD compatible C lib, and how to link using DUB.
On Saturday, 17 December 2016 at 04:58:45 UTC, Mike Parker wrote:
On Friday, 16 December 2016 at 22:37:13 UTC, hardreset wrote:
To be honest I was having some odd linking problems anyway. I
initially wrapped the FT init function in plain D function and
that kept causing "_FT_ not found" link errors. As soon as
I took all the actual D functions out and left just FT
declarations in there it stopped. Even now if I add...
int foo() { return 0; }
to my freetype.d (contains just FT interface declarations)
and call it from font.d (my font class)
i start getting linker errors. Why would adding a plain D
function suddenly make it sound the linker cant find what it
needs in the freetype.lib?
The only thing I can think of offhand: did you compile and link
your freetype.d? As long as it's just interface declarations,
there's no need to -- it only needs to be on the import path.
But once you start adding implementations, it needs to be
compiled and linked into the executable.
Yeah that was it. I had it in a separate folder for libs and
mistakenly assumed that because it was importing OK that mean it
was being compiled and linked too. I moved it into the source
folder and it worked fine! It makes sense now.
thanks for the help!
Re: Poll
On Friday, 23 December 2016 at 12:51:29 UTC, Nemanja Boric wrote: What's in the `core.sys.posix.poll` is just a C wrapper, meaning if you use functions declared there, you're just calling the same one you would do in C, so it's very likely that you're doing something different in D and C program. Here's the example that works for me: [...] Thank you so much! That worked perfectly. It looks like the problem was that I was passing in the wrong fileno and this was causing it to always return 1. Thanks again!
Re: How to detect free/unfree memory segments?
I can just partially answer this part of the question: Could anybody explain what dangerous of memory fragmentation in languages without GC? Am I right understand that there is stay some small memory chunks that very hard to reuse? On Unix-like systems, system call for allocating memory is traditionally `brk`/`sbrk` which just moves "program break" which indicates how much memory program has allocated. Say that you're running your application, and your heap looks like this: 4096 --- | heap [myarr] | --- ^ | program break now you call `sbrk(2 * 4096)` as you need which will allocate 2*4096 for you: 4096 -- | heap [myarr][my new array] | -- ^ | program break Now, if you want to discard [myarr], it will leave a hole in heap, since you don't want to move `[my new array]`. This hole can be reused, but sometimes it can't, depending on the size, etc. That's why there's another system call you can use: mmap, which you would use to allocate space for `my new array`, non-contiguously and not adjacent to `myarr`, and so when you discard myarr, you don't have fragmentation issue: 4096 -- | heap [myarr] | | [my new array] | -- ^ | program break These, and many more facts (reusing freed area, when to use brk, when to use mmap, locking contention detection, for example) are used by the standard memory allocators you would use in non-GC program (such is malloc), so while it is possible that you will have memory fragmentation problems, it is very unlikely, unless you're writing something that's very different than vast majority of the programs. And in that case, there are different allocators that you can use, or you can write your own. Nemanja On Friday, 23 December 2016 at 06:18:02 UTC, Suliman wrote: I would like to visualize how GC works and display free/not free memory segments. How I can understand which of them are used and which not? Could anybody explain what dangerous of memory fragmentation in languages without GC? Am I right understand that there is stay some small memory chunks that very hard to reuse?
Re: Poll
What's in the `core.sys.posix.poll` is just a C wrapper, meaning
if you use functions declared there, you're just calling the
same one you would do in C, so it's very likely that you're doing
something different in D and C program. Here's the example that
works for me:
```
void main()
{
import core.stdc.stdio: fileno, stdin;
import core.sys.posix.poll: poll, pollfd, POLLIN;
import std.stdio: writeln, write, readln;
import std.exception: enforce;
pollfd fds;
fds.fd = fileno(stdin);
fds.events = POLLIN;
for (;;)
{
int ret = poll(, 1, -1);
switch (ret)
{
case POLLIN:
auto data = readln();
write("Data on stdin: ", data);
break;
case 0:
writeln("timeout");
break;
case -1:
default:
enforce(false, "Error");
}
}
}
```
> If anyone has any suggestions, they would be much appreciated.
Really all I need is a way of checking if a stream / file will
block if I read it.
Be very careful here, poll works on the readiness principle, and
POSIX enforces that the regular files are always ready for
reading and writing, meaning that this will not work.
http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html
Regular files shall always poll TRUE for reading and writing.
Nemanja
On Friday, 23 December 2016 at 11:07:49 UTC, LeqxLeqx wrote:
I've recently been attempting to detect whether or not stdin
would block a read if I tried. I have attempted to use the
/core/sys/posix/poll.d but that seems to be always returning
'1' whether or not stdin has anything on it, whereas for the
corresponding program written in C, it will return 1 only if
there is something on stdin.
If anyone has any suggestions, they would be much appreciated.
Really all I need is a way of checking if a stream / file will
block if I read it.
Thanks
Poll
I've recently been attempting to detect whether or not stdin would block a read if I tried. I have attempted to use the /core/sys/posix/poll.d but that seems to be always returning '1' whether or not stdin has anything on it, whereas for the corresponding program written in C, it will return 1 only if there is something on stdin. If anyone has any suggestions, they would be much appreciated. Really all I need is a way of checking if a stream / file will block if I read it. Thanks
