Re: Error in assignment to 'this' inside constructor
On Sunday, 12 May 2013 at 03:32:44 UTC, evilrat wrote: what? structs has value semantics, every time you assign a struct to variable it assign its copy. you also don't have to have constructor for structs, it initializes it fields in left-to-right order or so. [..] Yes, I know that. But I'm not trying to write a struct such as 'Test' in my example above. 'Test' is just the simplest example I could make in order to showcase the (assumed) compiler bug. The struct that I *am* trying to make does indeed need a constructor and it's a very complex one and I do need a way to assign different compile-time-constant values of that struct type over 'this' inside the constructor. Anyway, if no-one tells me otherwise, I'll just assume it's a compiler bug and make a bug-report about it.
Re: how to avoid memory leaking
Am 11.05.2013 01:18, schrieb maarten van damme: I'm trying to generate images and after displaying them I want to save them to a png file. I use parallelism to generate them asynchronously with the gui-thread to avoid blocking (don't know if this is really relevant). If I add a single line in the method where I generate the image that creates a class which allocates a pretty big array, slowly but surely the memory starts to rise until it ends in a spectacular out of memory exception. I always thought the garbage collector would deal with it. I tried reducing it but failed. Maybe I should let dustmite bite in it a bit later. How can I manually fix this? Is this a known bug in the garbage collector? btw, this code also caused segfaults on my 64 bit laptop on linux. How can I avoid this? main class: https://dl.dropboxusercontent.com/u/15024434/picturegenerator/generalised.d zip file with everything ready to go to compile: https://dl.dropboxusercontent.com/u/15024434/picturegenerator/picturegenerator.zip Try allocating the big array with: import core.memory; size_t imageSize = 1024*1024*3; auto imageData[] = (cast(ubyte*)GC.malloc(imageSize , GC.BlkAttr.NO_SCAN)[0..imageSize]; Which will result in the big memory block not beeing scanned by the GC which should reduce the number of false positives during collection. If this doesn't work, use malloc / free of the c standard library to allocate and free the image data. Kind Regards Benjamin Thaut
Re: C Memory
On Sunday, 5 May 2013 at 09:52:53 UTC, Namespace wrote:
Here a test example:
http://dpaste.1azy.net/2cfc8ead
The memory is allocated through the SDL as you can see.
1) You don't need to call unload on any Derelict loaders. That is
handled automatically by Derelict using static module destructors
just as you have here. And that leads to
2) Module destructors are run before the gc runs its final
collection at shutdown. So if in a destructor you try to call
into one of the libraries Derelict binds, you will be calling
into a library that is already unloaded, hence the error.
Never rely on destructors to release memory. Aside from this
Derelict-specific issue, you have no control over when, if, or in
what order the destructors are called. This can lead to all sorts
of subtle bugs.
The IMO ideal way to handle this is to give your app a
terminate() function somewhere that is always called before the
app exits and which initiates a clean release of system
resources. Assuming a game:
void main() {
initialize();
run();
scope(exit) terminate();
}
void terminate() {
Game.terminate();
Audio.terminate();
Network.terminate();
Graphics.terminate();
...
}
I adopted this style long ago in C and it applies well to D. I
never rely on destructors except for logging, statistics, or
other non-critical things. I release all C-side memory through a
terminate chain.
Re: C Memory
I should expand a bit. The heart of the issue in this case is that you need precise control over the order of deallocation: resource allocated through the shared libraries need to be deallocated before the libraries are unloaded. Even without the static module destructors, you can't rely on normal destructors to do that. I could just entirely skip unloading the libraries. The OS should handle that automatically when the process exits, meaning the GC should have done its final shutdown by then. I've thought about implementing such a change before, as this issue keeps cropping up around Derelict because so many people start out relying on D's destructors to release memory for them. Then again, the up side is that it highlights one of the issues of relying on destructors for this sort of thing. Another being that your SDL_Surface might never be deallocated at all until the app exits if you only rely on destructors, which could have a negative impact in a long running game. And yet another being that the GC doesn't know about the memory your SDL_Surface points to and could happily destruct your object, thereby freeing the surcface, while another pointer to it exists somewhere else in the program. Better just to use a terminate chain.
Re: C Memory
1) You don't need to call unload on any Derelict loaders. That
is handled automatically by Derelict using static module
destructors just as you have here. And that leads to
That good to know.
2) Module destructors are run before the gc runs its final
collection at shutdown. So if in a destructor you try to call
into one of the libraries Derelict binds, you will be calling
into a library that is already unloaded, hence the error.
As I thought. But I have currently no real solution for that.
Never rely on destructors to release memory. Aside from this
Derelict-specific issue, you have no control over when, if, or
in what order the destructors are called. This can lead to all
sorts of subtle bugs.
Never heard of RAII? ;) D structs should be able to do this
technique.
That's why I do this that way. It's more comfortable and you
don't forget to free memory.
The IMO ideal way to handle this is to give your app a
terminate() function somewhere that is always called before the
app exits and which initiates a clean release of system
resources. Assuming a game:
void main() {
initialize();
run();
scope(exit) terminate();
}
void terminate() {
Game.terminate();
Audio.terminate();
Network.terminate();
Graphics.terminate();
...
}
I adopted this style long ago in C and it applies well to D. I
never rely on destructors except for logging, statistics, or
other non-critical things. I release all C-side memory through
a terminate chain.
Well, maybe I could adapt it to my problem. It's a bit annoying
that you have to call it by yourself. :)
Re: C Memory
I get the error, although I don't call any unload method (or quit any SDL component) and although I recompiled derelict3, where I comment out all static (shared) DTor's. Maybe the only solution would be (as you said) to transfer all deallocations into a terminate method, but that is no opinion for me (and would cause a growing memory, if the game runs a long time). And I want to use RAII. So I must live with this invalid memory error. But thanks to you and all others for your help. :)
Re: Error in assignment to 'this' inside constructor
On Sunday, 12 May 2013 at 07:51:39 UTC, TommiT wrote:
On Sunday, 12 May 2013 at 03:32:44 UTC, evilrat wrote:
what? structs has value semantics, every time you assign a
struct to variable it assign its copy.
you also don't have to have constructor for structs, it
initializes it fields in left-to-right order or so.
[..]
Yes, I know that. But I'm not trying to write a struct such as
'Test' in my example above. 'Test' is just the simplest example
I could make in order to showcase the (assumed) compiler bug.
The struct that I *am* trying to make does indeed need a
constructor and it's a very complex one and I do need a way to
assign different compile-time-constant values of that struct
type over 'this' inside the constructor.
Anyway, if no-one tells me otherwise, I'll just assume it's a
compiler bug and make a bug-report about it.
the problem with structs in your case is that this a value type,
so may be you could use copy contructor?
struct Something {
// copy ctor
this(Something s) {}
}
now just imagine how do you change this for a variable(or
simply variable itself) which tried to copy something over
itself? the closest possible thing is a reference, and that
behavior seems absolutely logically correct, otherwise if
modifying this would be allowed that would be easy way to do
lots of errors where you don't expect them.
but still if you think it's a bug fill a request or try also
2.063 beta.
Re: Error in assignment to 'this' inside constructor
oops. nevermind i've forgot about how it done in D :( you'd better read about it in language reference.
Structure's inheritance
Hello to all ! I'm surprised that there is no structure's inheritance. There is a problem: I want to make Matrix MxN class. I also want to make child classes Square Matrix and Vector from it with additional functions. I don't want use class cause of new overhead. Std typecons's Scoped - workaround with many restrictions, so it isn't true solution. I'm tried mixin template but there is no luck. I don't know how to declare multiplication operator for example. Any suggestions ? Regards.
Re: Error in assignment to 'this' inside constructor
oh right,
struct A {
this(this) { copy referenced mem here}
}
or
struct A {
ref A opAssign(ref const A other) { this = other; return this; }
}
so if you have fields that should be fully copied like array this
is the place to do it, otherwise there is a reference arguments,
if both is no go for you then this behavior would make more
trouble than benefits and thats.
so gather all up here are some little example
struct A
{
int x;
int[] array;
this(int x) { this.x = x; array ~= x; }
this(this) { array = array.dup; }
ref A opAssign(ref const A other) { this = other; return this; }
}
void main()
{
A a1 = A(1);
A a2 = A(2);
A a3 = a2;
a2.x = 5;
assert(a2.x == 5);
assert(a2.array[0] == 5);
assert(a3.x == 2);
assert(a3.array[0] == 2);
assert(a2.array.length == 1);
assert(a3.array.length == 1);
}
Re: Structure's inheritance
On Sunday, 12 May 2013 at 11:21:16 UTC, Temtaime wrote: Hello to all ! I'm surprised that there is no structure's inheritance. There is a problem: I want to make Matrix MxN class. I also want to make child classes Square Matrix and Vector from it with additional functions. I don't want use class cause of new overhead. Std typecons's Scoped - workaround with many restrictions, so it isn't true solution. I'm tried mixin template but there is no luck. I don't know how to declare multiplication operator for example. Any suggestions ? Regards. opertor overloading described here http://dlang.org/operatoroverloading.html#Binary what are you trying to do that requires struct inheritance?
Re: Structure's inheritance
On Sunday, 12 May 2013 at 11:21:16 UTC, Temtaime wrote:
Hello to all !
I'm surprised that there is no structure's inheritance.
There is a problem:
I want to make Matrix MxN class. I also want to make child
classes Square Matrix and Vector from it with additional
functions.
I don't want use class cause of new overhead. Std
typecons's Scoped - workaround with many restrictions, so it
isn't true solution.
I'm tried mixin template but there is no luck. I don't know how
to declare multiplication operator for example.
Any suggestions ?
Regards.
You could make the base struct a member of the child struct and
refer with alias this Base; to the base:
[code]
import std.stdio;
struct A {
public:
int id;
}
struct B {
public:
A hidden_a;
alias hidden_a this;
int age;
this(int id, int age) {
this.age = age;
this.id = id;
}
}
void main() {
B b = B(42, 23);
writefln(Person #%d is %d years old., b.id, b.age);
}
[/code]
Re: Structure's inheritance
On Sunday, 12 May 2013 at 11:21:16 UTC, Temtaime wrote: Hello to all ! I'm surprised that there is no structure's inheritance. This was done by Walter Bright deliberately because he believes that polymorphism does not play well with automaic lifetime. There is a problem: I want to make Matrix MxN class. I also want to make child classes Square Matrix and Vector from it with additional functions. I don't want use class cause of new overhead. Std typecons's Scoped - workaround with many restrictions, so it isn't true solution. I'm tried mixin template but there is no luck. I don't know how to declare multiplication operator for example. Any suggestions ? Regards. You can place base struct instance inside nested and use alias this. Note that currently multiple alias this are not supported. Also note that you cannot override functions because there are no virtual table for structs.
Re: Structure's inheritance
On Sunday, 12 May 2013 at 11:56:53 UTC, Maxim Fomin wrote: You can place base struct instance inside nested and use alias this. Note that currently multiple alias this are not supported. Also note that you cannot override functions because there are no virtual table for structs. why multiple alias this not supported? i know it was broken in 2.060 but with 2.061 it was fixed right?
Re: Structure's inheritance
12-May-2013 16:00, evilrat пишет: On Sunday, 12 May 2013 at 11:56:53 UTC, Maxim Fomin wrote: You can place base struct instance inside nested and use alias this. Note that currently multiple alias this are not supported. Also note that you cannot override functions because there are no virtual table for structs. why multiple alias this not supported? i know it was broken in 2.060 but with 2.061 it was fixed right? It's not even on the horizon. It must be single alias this that finally started working (around that time ~ 2.061). -- Dmitry Olshansky
Re: Structure's inheritance
On 2013-05-12, 14:00, evilrat wrote: On Sunday, 12 May 2013 at 11:56:53 UTC, Maxim Fomin wrote: You can place base struct instance inside nested and use alias this. Note that currently multiple alias this are not supported. Also note that you cannot override functions because there are no virtual table for structs. why multiple alias this not supported? i know it was broken in 2.060 but with 2.061 it was fixed right? It's simply never been implemented. -- Simen
Re: Get difficulties with variadics
On Sunday, 12 May 2013 at 01:22:16 UTC, evilrat wrote:
On Saturday, 11 May 2013 at 22:01:33 UTC, Flamaros wrote:
Thanks a lot, I think using Variant[] is a better way. For the
moment (maybe for few minutes) it's necessary to always give
the Variant array to the getResource method, but it can be
null.
I actually use derelict3, but for this VBO isn't not necessary
to have something much more advanced as it's only for a Quad
generated by hand. I am sharing the indexes VBO of Quads.
The operational parameters can be useful to load a Texture
from an Image instance instead of only the filePath for
exemple. filePath also act as key to be able to get resources.
you don't even need to always pass null when you don't need
anything, use default parameters.
void someFunc(Variant[] array = null) {...}
or
void anotherFunc(Variant[] array = Variant[].init) {...}
ok, if this is just a part of tutorial or demo i don't bother
with my tips about api design anymore.
We hope to open our code in few weeks, and as it will be a
library, help on API design will be welcome. For the moment we
are working a doing a prototype, with core features to see if the
project is viable.
Re: C Memory
On Sunday, 12 May 2013 at 10:11:57 UTC, Namespace wrote: I get the error, although I don't call any unload method (or quit any SDL component) and although I recompiled derelict3, where I comment out all static (shared) DTor's. Maybe the only solution would be (as you said) to transfer all deallocations into a terminate method, but that is no opinion for me (and would cause a growing memory, if the game runs a long time). And I want to use RAII. So I must live with this invalid memory error. I think you need to reconsider your use-case for RAII here. Wanting to use it is fine, but letting these errors persist just so you can do so is not something I would recommend. What you are missing here is that there's no such thing as that this (and would cause a growing memory, if the game runs a long time) is an issue you are likely to run into by using D's class destructors to handle resource deallocation (as I mentioned in a previous post), but not with the system I describe here. You're misunderstanding the purpose of the terminate call. It's there not to release all the memory your app ever uses, but to clean up any resources /still hanging around/ at shutdown. You need to pay special attention to memory management when developing a game. RAII isn't going to help you with D's classes, but you can still get a comfortable system in place that keeps deallocations localized in specific places, allowing you to free as few or as many resources as you want. You're likely already using some sort of manager structure for most of your game systems anyway. Even in a simple Asteroids game you'd have a list of Sprites that are active. That list becomes your record of resources that need to be deallocated. So just add one function that does that, make sure it's called at shutdown, and now you've avoided this error you're having. By going with this approach, you can have exact control over when resources are released and in what order. That should always be an overriding goal in game development. I promise you, this will save you a lot of headaches down the road by eliminating a whole class of potential memory-related bugs (and they will pop up eventually) and code maintenance costs. One of the side-effects of mixing memory managed by the GC with that allocated outside of the GC is that you have to be responsible for the latter.
Re: C Memory
On Sunday, 12 May 2013 at 14:06:49 UTC, Mike Parker wrote: What you are missing here is that there's no such thing as that this (and would cause a growing memory, if the game runs a long time) is an issue you are likely to run into by using D's This was the result of a botched edit. You can ignore everything from what to that and just start with this.
Re: C Memory
On Sunday, 12 May 2013 at 14:06:49 UTC, Mike Parker wrote: What you are missing here is that there's no such thing as that this (and would cause a growing memory, if the game runs a long time) is an issue you are likely to run into by using D's This was the result of a botched edit. You can ignore everything from what to that and just start with this.
Re: Error in assignment to 'this' inside constructor
On Sunday, 12 May 2013 at 10:38:41 UTC, evilrat wrote:
the problem with structs in your case is that this a value
type, so may be you could use copy contructor?
struct Something {
// copy ctor
this(Something s) {}
}
D doesn't have copy constructors. What you have there is just a
regular constructor.
Re: Error in assignment to 'this' inside constructor
On Sunday, 12 May 2013 at 11:27:50 UTC, evilrat wrote:
oh right,
struct A {
this(this) { copy referenced mem here}
}
or
struct A {
ref A opAssign(ref const A other) { this = other; return this; }
}
so if you have fields that should be fully copied like array
this is the place to do it, otherwise there is a reference
arguments, if both is no go for you then this behavior would
make more trouble than benefits and thats.
so gather all up here are some little example
struct A
{
int x;
int[] array;
this(int x) { this.x = x; array ~= x; }
this(this) { array = array.dup; }
ref A opAssign(ref const A other) { this = other; return this;
}
}
void main()
{
A a1 = A(1);
A a2 = A(2);
A a3 = a2;
a2.x = 5;
assert(a2.x == 5);
assert(a2.array[0] == 5);
assert(a3.x == 2);
assert(a3.array[0] == 2);
assert(a2.array.length == 1);
assert(a3.array.length == 1);
}
You're assigning to 'this', i.e. calling assignment operator,
inside the assignment operator. That results in an infinite
recursion. That code never calls the assignment operator though,
but try a1 = a2 for example and that should crash.
Re: C Memory
I use RAII of course only with D structs, not with classes. Tonight I will take a closer look what the source of evil is.
Re: Error in assignment to 'this' inside constructor
On 05/11/2013 04:34 PM, TommiT wrote: ... // CTFE internal error: unsupported assignment this = Test(123) ... An internal error is always a compiler bug.
Re: Error in assignment to 'this' inside constructor
On Sunday, 12 May 2013 at 16:18:00 UTC, Timon Gehr wrote: On 05/11/2013 04:34 PM, TommiT wrote: ... // CTFE internal error: unsupported assignment this = Test(123) ... An internal error is always a compiler bug. Thanks. Bug report there: http://d.puremagic.com/issues/show_bug.cgi?id=10069
Interface vs pure abstract class - speed.
Hello, let's say I have the choice between using an abstract class or an interface to declare a plan, a template for the descendants. From the dmd compiler point of view, should I use the abstract class version (so I guess that for each method call, there will be a few MOV, in order to extract the relative address from the vmt before a CALL) or the interface version (are the CALL directly performed in this case). Are interface faster ? (to get the address used by the CALL). Thx.
Re: Interface vs pure abstract class - speed.
On Sunday, 12 May 2013 at 17:31:22 UTC, SundayMorningRunner wrote: Hello, let's say I have the choice between using an abstract class or an interface to declare a plan, a template for the descendants. From the dmd compiler point of view, should I use the abstract class version (so I guess that for each method call, there will be a few MOV, in order to extract the relative address from the vmt before a CALL) or the interface version (are the CALL directly performed in this case). Are interface faster ? (to get the address used by the CALL). Thx. I would expect abstract classes to be slightly faster (certainly they shouldn't be slower), but the difference to be insignificant compared to other factors. Deriving from an abstract base class is a much stronger relationship than implementing an interface, so it depends on your situation. If your class is a provider (eg. it provides some functionality such as being able to receive some event) then an interface makes more sense. If your class is a type of something (eg. a button is a type of gui control) then inheritance makes more sense.
Re: Interface vs pure abstract class - speed.
On Sunday, 12 May 2013 at 17:31:22 UTC, SundayMorningRunner wrote: Hello, let's say I have the choice between using an abstract class or an interface to declare a plan, a template for the descendants. From the dmd compiler point of view, should I use the abstract class version (so I guess that for each method call, there will be a few MOV, in order to extract the relative address from the vmt before a CALL) or the interface version (are the CALL directly performed in this case). Are interface faster ? (to get the address used by the CALL). Thx. I doubt that looking from buggy compiler POV is a good idea. Anyway you can take code and look into assembly.
Re: Interface vs pure abstract class - speed.
On Sunday, 12 May 2013 at 18:00:10 UTC, Diggory wrote: On Sunday, 12 May 2013 at 17:31:22 UTC, SundayMorningRunner wrote: Hello, let's say I have the choice between using an abstract class or an interface to declare a plan, a template for the descendants. From the dmd compiler point of view, should I use the abstract class version (so I guess that for each method call, there will be a few MOV, in order to extract the relative address from the vmt before a CALL) or the interface version (are the CALL directly performed in this case). Are interface faster ? (to get the address used by the CALL). Thx. I would expect abstract classes to be slightly faster (certainly they shouldn't be slower), but the difference to be insignificant compared to other factors. Deriving from an abstract base class is a much stronger relationship than implementing an interface, so it depends on your situation. If your class is a provider (eg. it provides some functionality such as being able to receive some event) then an interface makes more sense. If your class is a type of something (eg. a button is a type of gui control) then inheritance makes more sense. It's ok about the difference between an interface and an abstract class. My question is really technical: which is the fatest: to a method from an interface or to the overriden method of an abstract class ? Think about a context such as audio DSP, where a method will be called for each buffer during 2 or 3 hours without interuption, and maybe 3 or 4 times per second...
Re: Interface vs pure abstract class - speed.
On Sunday, 12 May 2013 at 18:14:51 UTC, Maxim Fomin wrote: On Sunday, 12 May 2013 at 17:31:22 UTC, SundayMorningRunner wrote: Hello, let's say I have the choice between using an abstract class or an interface to declare a plan, a template for the descendants. From the dmd compiler point of view, should I use the abstract class version (so I guess that for each method call, there will be a few MOV, in order to extract the relative address from the vmt before a CALL) or the interface version (are the CALL directly performed in this case). Are interface faster ? (to get the address used by the CALL). Thx. I doubt that looking from buggy compiler POV is a good idea. Anyway you can take code and look into assembly. Which is exactly what you could have done before answering ;)
Re: Interface vs pure abstract class - speed.
On Sunday, 12 May 2013 at 18:21:14 UTC, SundayMorningRunner wrote:
On Sunday, 12 May 2013 at 18:14:51 UTC, Maxim Fomin wrote:
On Sunday, 12 May 2013 at 17:31:22 UTC, SundayMorningRunner
wrote:
Hello, let's say I have the choice between using an abstract
class or an interface to declare a plan, a template for
the descendants.
From the dmd compiler point of view, should I use the
abstract class version (so I guess that for each method call,
there will be a few MOV, in order to extract the relative
address from the vmt before a CALL) or the interface version
(are the CALL directly performed in this case). Are interface
faster ? (to get the address used by the CALL).
Thx.
I doubt that looking from buggy compiler POV is a good idea.
Anyway you can take code and look into assembly.
Which is exactly what you could have done before answering ;)
This is exactly what I *have done* before answering to get
correct answer for me. I see no reasons to ask such questions if
you can do the test yourself.
interface I
{
void foo();
}
class A : I { void foo(){}}
abstract class B { void foo() {} }
class C : B {}
void bar(C c, I i)
{
c.foo();
i.foo();
}
void main()
{
A a = new A;
a.foo();
C c = new C;
c.foo();
bar(c, a);
}
disas _Dmain
Dump of assembler code for function _Dmain:
0x00419cd8 +0: push %rbp
0x00419cd9 +1: mov%rsp,%rbp
0x00419cdc +4: sub$0x10,%rsp
0x00419ce0 +8: movabs $0x639210,%rdi
0x00419cea +18: callq 0x41becc _d_newclass
0x00419cef +23: mov%rax,-0x10(%rbp)
0x00419cf3 +27: mov%rax,%rdi
0x00419cf6 +30: mov(%rax),%rcx
0x00419cf9 +33: rex.W callq *0x28(%rcx)
0x00419cfd +37: movabs $0x639380,%rdi
0x00419d07 +47: callq 0x41becc _d_newclass
0x00419d0c +52: mov%rax,-0x8(%rbp)
0x00419d10 +56: mov%rax,%rdi
0x00419d13 +59: mov(%rax),%rdx
0x00419d16 +62: rex.W callq *0x28(%rdx)
0x00419d1a +66: mov-0x8(%rbp),%rsi
0x00419d1e +70: cmpq $0x0,-0x10(%rbp)
0x00419d23 +75: je 0x419d2f _Dmain+87
0x00419d25 +77: mov-0x10(%rbp),%rax
0x00419d29 +81: lea0x10(%rax),%rdi
0x00419d2d +85: jmp0x419d32 _Dmain+90
0x00419d2f +87: xor%rdi,%rdi
---Type return to continue, or q return to quit---
0x00419d32 +90: callq 0x419cb0
_D4main3barFC4main1CC4main1IZv
0x00419d37 +95: xor%eax,%eax
0x00419d39 +97: leaveq
0x00419d3a +98: retq
End of assembler dump.
disas _D4main3barFC4main1CC4main1IZv
Dump of assembler code for function
_D4main3barFC4main1CC4main1IZv:
0x00419cb0 +0: push %rbp
0x00419cb1 +1: mov%rsp,%rbp
0x00419cb4 +4: sub$0x10,%rsp
0x00419cb8 +8: mov%rdi,-0x10(%rbp)
0x00419cbc +12: mov%rsi,%rdi
0x00419cbf +15: mov(%rsi),%rax
0x00419cc2 +18: rex.W callq *0x28(%rax)
0x00419cc6 +22: mov-0x10(%rbp),%rdi
0x00419cca +26: mov(%rdi),%rcx
0x00419ccd +29: rex.W callq *0x8(%rcx)
0x00419cd1 +33: leaveq
0x00419cd2 +34: retq
End of assembler dump.
Re: how to avoid memory leaking
This is ridiculous. Your solution appears to keep the memory somewhat constant around 20mb-28mb untill it suddenly runs out of memory. Literally out of nowhere. I have no idea what's causing everything, so I decided to get rid of the window altogether and to try saving the images instead of displaying + saving them. Now I run in Internal error: ..\ztc\cgcs.c 343... D is really dissapointing here. Maybe it's the gc having fun, maybe it's something else, no way to know for sure. Having to give up on displaying it altogether runs into internal error's.
Re: how to avoid memory leaking
maarten van damme: I have no idea what's causing everything, so I decided to get rid of the window altogether and to try saving the images instead of displaying + saving them. Now I run in Internal error: ..\ztc\cgcs.c 343... Once minimized, this may be fit for D Bugzilla. Bye, bearophile
Re: how to avoid memory leaking
Am 12.05.2013 21:05, schrieb maarten van damme: This is ridiculous. Your solution appears to keep the memory somewhat constant around 20mb-28mb untill it suddenly runs out of memory. Literally out of nowhere. I have no idea what's causing everything, so I decided to get rid of the window altogether and to try saving the images instead of displaying + saving them. Now I run in Internal error: ..\ztc\cgcs.c 343... D is really dissapointing here. Maybe it's the gc having fun, maybe it's something else, no way to know for sure. Having to give up on displaying it altogether runs into internal error's. As D is a relative new lagnauge stuff like this can happen. It would be great if you could reduce the compiler crash to a minimal test case using dustmite: https://github.com/CyberShadow/DustMite A description how to use it is aviable in the wiki. If you successfully reduced the compiler error please fill in a bug report at http://d.puremagic.com/issues/ -- Kind Regards Benjamin Thaut
Re: C Memory
Am 12.05.2013 12:11, schrieb Namespace: I get the error, although I don't call any unload method (or quit any SDL component) and although I recompiled derelict3, where I comment out all static (shared) DTor's. Maybe the only solution would be (as you said) to transfer all deallocations into a terminate method, but that is no opinion for me (and would cause a growing memory, if the game runs a long time). And I want to use RAII. So I must live with this invalid memory error. But thanks to you and all others for your help. :) Do you have multiple threads in your application? If you do so it is possible that you (or the derelict library) does a API call in a different then the main thread which might lead to the error you describe. As the GC runs the destructors in any arbitrary thread you can not free any SDL resources inside a destructor. -- Kind Regards Benjamin Thaut
Red-Black tree with customized sorting
I need to user Red-Black trees with non-default sorting.
Here is a minimal example
8
import std.container;
struct CC {
int a;
int b; }
bool less(const ref CC lhs, const ref CC rhs) {
if (lhs.a != rhs.a)
return lhs.a rhs.a;
else
return lhs.b rhs.b; }
void main() {
auto t = new RedBlackTree!(CC, a.a != b.a ? a.a b.a : a.b
b.b); }
8
It works, but I would like to pass the function less as
comparison operator since in my real problem the comparison is a
more complex.
I tried this ways:
auto t = new RedBlackTree!(CC, less);
auto t = new RedBlackTree!(CC, CC);
auto t = new RedBlackTree!(CC, less);
auto t = new RedBlackTree!(CC, less(a,b));
auto t = new RedBlackTree!(CC, what the hell!? just call
less! Is it too much to ask?);
None of them works, I am stuck. The documentation states:
(quote from:
http://dlang.org/phobos/std_container.html#.RedBlackTree )
To use a different comparison than a b, pass a different
operator string that can be used by std.functional.binaryFun, or
pass in a function, delegate, functor, or any type where less(a,
b) results in a bool value.
What is wrong? How I am supposed to pass less address to do the
comparison?
Thanks
Re: C Memory
Do you have multiple threads in your application? If you do so it is possible that you (or the derelict library) does a API call in a different then the main thread which might lead to the error you describe. As the GC runs the destructors in any arbitrary thread you can not free any SDL resources inside a destructor. No, I have no other threads. But currently I'm working on my VBO, so it could take some time until I could search for the problem and a possible solution.
Re: Interface vs pure abstract class - speed.
On Sunday, 12 May 2013 at 18:45:29 UTC, Maxim Fomin wrote:
On Sunday, 12 May 2013 at 18:21:14 UTC, SundayMorningRunner
wrote:
On Sunday, 12 May 2013 at 18:14:51 UTC, Maxim Fomin wrote:
On Sunday, 12 May 2013 at 17:31:22 UTC, SundayMorningRunner
wrote:
Hello, let's say I have the choice between using an abstract
class or an interface to declare a plan, a template for
the descendants.
From the dmd compiler point of view, should I use the
abstract class version (so I guess that for each method
call, there will be a few MOV, in order to extract the
relative address from the vmt before a CALL) or the
interface version (are the CALL directly performed in this
case). Are interface faster ? (to get the address used by
the CALL).
Thx.
I doubt that looking from buggy compiler POV is a good idea.
Anyway you can take code and look into assembly.
Which is exactly what you could have done before answering ;)
This is exactly what I *have done* before answering to get
correct answer for me. I see no reasons to ask such questions
if you can do the test yourself.
interface I
{
void foo();
}
class A : I { void foo(){}}
abstract class B { void foo() {} }
class C : B {}
void bar(C c, I i)
{
c.foo();
i.foo();
}
void main()
{
A a = new A;
a.foo();
C c = new C;
c.foo();
bar(c, a);
}
disas _Dmain
Dump of assembler code for function _Dmain:
0x00419cd8 +0: push %rbp
0x00419cd9 +1: mov%rsp,%rbp
0x00419cdc +4: sub$0x10,%rsp
0x00419ce0 +8: movabs $0x639210,%rdi
0x00419cea +18: callq 0x41becc _d_newclass
0x00419cef +23: mov%rax,-0x10(%rbp)
0x00419cf3 +27: mov%rax,%rdi
0x00419cf6 +30: mov(%rax),%rcx
0x00419cf9 +33: rex.W callq *0x28(%rcx)
0x00419cfd +37: movabs $0x639380,%rdi
0x00419d07 +47: callq 0x41becc _d_newclass
0x00419d0c +52: mov%rax,-0x8(%rbp)
0x00419d10 +56: mov%rax,%rdi
0x00419d13 +59: mov(%rax),%rdx
0x00419d16 +62: rex.W callq *0x28(%rdx)
0x00419d1a +66: mov-0x8(%rbp),%rsi
0x00419d1e +70: cmpq $0x0,-0x10(%rbp)
0x00419d23 +75: je 0x419d2f _Dmain+87
0x00419d25 +77: mov-0x10(%rbp),%rax
0x00419d29 +81: lea0x10(%rax),%rdi
0x00419d2d +85: jmp0x419d32 _Dmain+90
0x00419d2f +87: xor%rdi,%rdi
---Type return to continue, or q return to quit---
0x00419d32 +90: callq 0x419cb0
_D4main3barFC4main1CC4main1IZv
0x00419d37 +95: xor%eax,%eax
0x00419d39 +97: leaveq
0x00419d3a +98: retq
End of assembler dump.
disas _D4main3barFC4main1CC4main1IZv
Dump of assembler code for function
_D4main3barFC4main1CC4main1IZv:
0x00419cb0 +0: push %rbp
0x00419cb1 +1: mov%rsp,%rbp
0x00419cb4 +4: sub$0x10,%rsp
0x00419cb8 +8: mov%rdi,-0x10(%rbp)
0x00419cbc +12: mov%rsi,%rdi
0x00419cbf +15: mov(%rsi),%rax
0x00419cc2 +18: rex.W callq *0x28(%rax)
0x00419cc6 +22: mov-0x10(%rbp),%rdi
0x00419cca +26: mov(%rdi),%rcx
0x00419ccd +29: rex.W callq *0x8(%rcx)
0x00419cd1 +33: leaveq
0x00419cd2 +34: retq
End of assembler dump.
so take a tip: go on home.
so take a tip: you'll never beat the IRA.
Re: Red-Black tree with customized sorting
On 05/12/2013 02:09 PM, Paolo Bolzoni wrote:
I need to user Red-Black trees with non-default sorting.
Here is a minimal example
8
import std.container;
struct CC {
int a;
int b; }
bool less(const ref CC lhs, const ref CC rhs) {
if (lhs.a != rhs.a)
return lhs.a rhs.a;
else
return lhs.b rhs.b; }
void main() {
auto t = new RedBlackTree!(CC, a.a != b.a ? a.a b.a : a.b
b.b); }
8
It works, but I would like to pass the function less as comparison
operator since in my real problem the comparison is a more complex.
I think this is an issue with the template constraint of RedBlackTree.
It passes the alias template parameter through binaryFun and I think
that fails the check:
final class RedBlackTree(T, alias less = a b, bool allowDuplicates =
false)
if(is(typeof(binaryFun!less(T.init, T.init
A workaround:
auto t = new RedBlackTree!(CC, (a, b) = less(a, b));
Ali
Re: how to avoid memory leaking
aren't you guys all getting tons of internal error's as soon as you combine
dynamic arrays with static arrays? It seems as if these things are
completely seperate things, but their syntax sugests a more closely related
connection. I really find it confusing...
So, after reducing, I am very certain that at least one problem comes from
generating a png, the code used is here available :
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/png.d
seeing as this is pure d, am I right in assuming there should never be any
memory leaks when using this?
The reduced loop that only generates images is here :
TrueColorImage i= new TrueColorImage(width,height);
PNG* png;
double[][4] curtrans;
while(true){
curtrans=generateTransformationMatrix();
for(int y=0;yheight;y++)
for(int x=0;xwidth;x++)
i.data[(y*width+x)*4..y*width+x)*4+4]=colorify(applyTransformation(transformXY(x,y),curtrans)).dup[0..3]
~ 255;
// and finally write the data to a png file
png = pngFromImage(i);
//std.file.write(images/~toHexString(md5Of(curtrans))~.png,
writePng(png));
}
if you comment out png = pngFromImage(i) the program appears to not blow
up over time. I think the ice come from assiging a slice of a dynamic array
to a slice of a static array (hence the .dup). (I'll try reducing it with
dustmite)
2013/5/12 Benjamin Thaut c...@benjamin-thaut.de
Am 12.05.2013 21:05, schrieb maarten van damme:
This is ridiculous. Your solution appears to keep the memory somewhat
constant around 20mb-28mb untill it suddenly runs out of memory.
Literally out of nowhere.
I have no idea what's causing everything, so I decided to get rid of the
window altogether and to try saving the images instead of displaying +
saving them. Now I run in Internal error: ..\ztc\cgcs.c 343...
D is really dissapointing here. Maybe it's the gc having fun, maybe it's
something else, no way to know for sure. Having to give up on displaying
it altogether runs into internal error's.
As D is a relative new lagnauge stuff like this can happen. It would be
great if you could reduce the compiler crash to a minimal test case using
dustmite:
https://github.com/**CyberShadow/DustMitehttps://github.com/CyberShadow/DustMite
A description how to use it is aviable in the wiki. If you successfully
reduced the compiler error please fill in a bug report at
http://d.puremagic.com/issues/
--
Kind Regards
Benjamin Thaut
Disgusted
I went back from a trip...basically I spent 6 monthes in Yukon... Then, came back to my activities, I was a lot in the library of the university linked to my geo. location...I've noticed a strange guy...He was always reading some books about computer programming languages. After a few monthes, I've realized that he was learning from A to Z all the languagues...I've just realized that he was probably smarter than me...And despite of being disgusted, I wonder If It's time to hide again in the Yukon state...'cause I'm basically disgusted, and the basic concept of being alive is stupid and pointless.
Re: Disgusted
On Monday, 13 May 2013 at 00:18:34 UTC, D-Ratiseur wrote: I went back from a trip...basically I spent 6 monthes in Yukon... Then, came back to my activities, I was a lot in the library of the university linked to my geo. location...I've noticed a strange guy...He was always reading some books about computer programming languages. After a few monthes, I've realized that he was learning from A to Z all the languagues...I've just realized that he was probably smarter than me...And despite of being disgusted, I wonder If It's time to hide again in the Yukon state...'cause I'm basically disgusted, and the basic concept of being alive is stupid and pointless. There's always smarter people. Hell, most of my friends are smarter than me.
Re: Disgusted
On Monday, 13 May 2013 at 00:21:06 UTC, John Colvin wrote: On Monday, 13 May 2013 at 00:18:34 UTC, D-Ratiseur wrote: I went back from a trip...basically I spent 6 monthes in Yukon... Then, came back to my activities, I was a lot in the library of the university linked to my geo. location...I've noticed a strange guy...He was always reading some books about computer programming languages. After a few monthes, I've realized that he was learning from A to Z all the languagues...I've just realized that he was probably smarter than me...And despite of being disgusted, I wonder If It's time to hide again in the Yukon state...'cause I'm basically disgusted, and the basic concept of being alive is stupid and pointless. There's always smarter people. Hell, most of my friends are smarter than me. You're probably smarter than me. But I know why I left my predilection language: I'm comming from Pascal/Delphi and everything is done while in D there is still a field for the basic stuff. Maybe Roquentin was also looking for that: a free field.
Re: Structure's inheritance
On Sunday, May 12, 2013 14:00:49 evilrat wrote: why multiple alias this not supported? i know it was broken in 2.060 but with 2.061 it was fixed right? Multiple alias this-es have never worked. They're described in TDPL, but they've never been implemented. Hopefully, they'll get implemented at some point, but AFAIK, no one has been working on them yet, and no one knows when they might be implemented. - Jonathan M Davis
Re: how to avoid memory leaking
Instead of the .dup you can use the slice operator []. Although this really should not cause a compiler crash if you forgett to do so. int[3] staticArray; int[] normalArray = staticArray[]; I'm not seeing something fundamentally wrong with your code right now. I will most likely have some more time to look at it tomorrow. Does it use any plattform specific features? (E.g. does it work on windows?) Having a GC does not mean you can not have memory leaks. If you manage to keep the memory referenced by some hard rooted reference the GC is not allowed to free it and you will get a memory leak. I'm also currently not aware of any tools for D that will help you find memory leaks. Kind Regards Benjamin Thaut
