Re: Fiber overhead
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. (Change the stack pointer, etc.) Memory overhead is memory for call stack, size of which can be determined by the programmer. Ali Thanks, that was what I was hoping.
Re: Fiber overhead
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 call stack, size of which can be determined by the programmer. Ali
Fiber overhead
What is the overhead of using a fiber?
Re: GC question
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 something else until D's memory management story gets better. This is sad because the language otherwise looks quite good, and I'd love to try assertions, contracts, scope guards, macros etc. you can use less auto GC. use the RC to replace the GC. https://github.com/huntlabs/SmartRef
Re: Is there anything fundamentally wrong with this code?
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 local variable and assigning to it.
[...]
Thank you so much. This is where I deserve a big Duh. I guess there is
no way to to make this idiot proof. I'll print it out and hang it over
my desk.
No matter how experienced, these happen to most programmers. :-/
Somebody else had a similar problem just the other day on this forum.
The same problem somewhat commonly happens when one copy+pastes members
into the constructor and assigns to them forgetting to remove the types:
struct S {
int i;
int j;
this(int a) {
// Declarations pasted from the members
int i = 42 + a;// meant 'i = 42 + a' (or this.i = ...)
int j = 43 + a;
}
}
Another related one is assigning to a parameter usually in the constructor:
struct S {
int i;
this(int i) {
i = i;// meant this.i = i
}
}
Ali
Re: Is there anything fundamentally wrong with this code?
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. [...] Thank you so much. This is where I deserve a big Duh. I guess there is no way to to make this idiot proof. I'll print it out and hang it over my desk.
Re: Is there anything fundamentally wrong with this code?
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; // just a declaration (no memory
allocation)
class Game
{
...
void initGame(){
...
PostProcessor postProc = new PostProcessor(...);
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.
...
}
...
void update(GLfloat deltaTime){
...
writeln("Right Before");
writeln("postProcesor.FBO = ", postProc.FBO);
writeln("Right After);
...
}
...
}
Is there anything fundamentally wrong with this code?
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_processor.d --
module post_processor;
class PostProcessor
{
...
GLuint FBO;
}
-file game.d ---
module game;
PostProcessor postProc; // just a declaration (no memory
allocation)
class Game
{
...
void initGame(){
...
PostProcessor postProc = new PostProcessor(...);
...
}
...
void update(GLfloat deltaTime){
...
writeln("Right Before");
writeln("postProcesor.FBO = ", postProc.FBO);
writeln("Right After);
...
}
...
}
Right Before
Program exited with code -1073741819
myapp exited with code 2
Any full-text search library
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?
Re: GC question
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. This is sad because the language otherwise looks quite good, and I'd love to try assertions, contracts, scope guards, macros etc.
Re: GC question
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 likely in 32-bit processes and unlikely in 64-bit processes. See e.g. https://issues.dlang.org/show_bug.cgi?id=15723 Do I need to be careful with some operations to avoid leaks? Leaks happen only due to false pointers. But data allocated in GC with new operator and known to have no pointers (e.g. strings) is not scanned. Premature collection happen when GC doesn't see a pointer to the allocated data, happens when such pointer is put in a memory GC doesn't see, like C heap. Is a precise GC in the roadmap? There's an effort on it: https://forum.dlang.org/post/hdwwkzqswwtffjehe...@forum.dlang.org It's fine if I have to do manual memory management, but I don't want any leaks. If you manually deallocate memory, it gets deallocated for sure, shouldn't leak. Comparing to java, D GC trades GC performance for code execution performance, which can result in better overall performance when you don't allocate much and worse performance for allocation-heavy code that java GC is optimized for.
Re: The reason of vibed slow down (request timeout)
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 = environment.get("PORT", "8080").to!short;
