On Saturday, 4 February 2017 at 06:54:01 UTC, Ali Çehreli wrote:
On 02/03/2017 08:47 PM, Profile Anaysis wrote:
What is the overhead of using a fiber?
The performance overhead of call() and yield() are comparable
to function calls because it's simply a few register
assignments in each case.
On 02/03/2017 08:47 PM, Profile Anaysis wrote:
What is the overhead of using a fiber?
The performance overhead of call() and yield() are comparable to
function calls because it's simply a few register assignments in each
case. (Change the stack pointer, etc.)
Memory overhead is memory for c
What is the overhead of using a fiber?
On Friday, 3 February 2017 at 11:36:26 UTC, osa1 wrote:
On Friday, 3 February 2017 at 10:49:00 UTC, Kagamin wrote:
Leaks are likely in 32-bit processes and unlikely in 64-bit
processes. See e.g.
https://issues.dlang.org/show_bug.cgi?id=15723
This looks pretty bad. I think I'll consider someth
On 02/03/2017 11:43 AM, WhatMeWorry wrote:
On Friday, 3 February 2017 at 18:37:15 UTC, Johan Engelen wrote:
On Friday, 3 February 2017 at 17:20:43 UTC, WhatMeWorry wrote:
[...]
The error is in this line. Instead of assigning to the `postProc` at
module scope, you are defining a new lo
On Friday, 3 February 2017 at 18:37:15 UTC, Johan Engelen wrote:
On Friday, 3 February 2017 at 17:20:43 UTC, WhatMeWorry wrote:
[...]
The error is in this line. Instead of assigning to the
`postProc` at module scope, you are defining a new local
variable and assigning to it.
[...]
On Friday, 3 February 2017 at 17:20:43 UTC, WhatMeWorry wrote:
-file post_processor.d --
module post_processor;
class PostProcessor
{
...
GLuint FBO;
}
-file game.d ---
module game;
PostProcessor postProc; // ju
The code below compiles fine but I always get a run time abort
with the error down below. Isn't the postProc at module scope so
shouldn't the class instance always be around (ie not
deallocated?) If it helps, this was translated from C++ code.
Thanks.
-file post_proces
Is there any usable full-text search library? for D I couldn't
find any except the Elasticsearch client called elasticsearch-d
in the package registry a very old Lucene port for D1 called
dlucene. This is it or did I miss something?
On Friday, 3 February 2017 at 10:49:00 UTC, Kagamin wrote:
Leaks are likely in 32-bit processes and unlikely in 64-bit
processes. See e.g.
https://issues.dlang.org/show_bug.cgi?id=15723
This looks pretty bad. I think I'll consider something else until
D's memory management story gets better.
On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote:
Are there any disallowed memory operations?
Currently can't touch GC from destructor during collection.
Another concern is interoperability with C-allocated memory: GC
knows nothing about C heap.
How often does it leak?
Leaks are
On Friday, 3 February 2017 at 06:46:37 UTC, Suliman wrote:
If I open it's from VPS (as localhost:8080) it's work same as
from Internet (no do not open at all).
One this I may suggest is the port if its used already (8080).
Try to use;
import std.process: environment;
settings.port = environm
12 matches
Mail list logo