Re: Compiling with SQLite
On Tuesday, 18 November 2014 at 05:06:59 UTC, impatient-dev wrote: On Tuesday, 18 November 2014 at 03:41:42 UTC, uri wrote: Are you linking with libsqlite3.a? For example: $ dmd prog.d -L-lsqlite3 That worked, thanks. I didn't know you had to anything special to link with code in the standard library; is there documentation for this somewhere? D doesn't have the whole implementation of SQLite. It is implemented as a library, and the sqlite3 module hooks up to library's functions. So, you should give your program the library ie. implementation of SQLite.
Re: get machine arch
http://dlang.org/phobos/core_cpuid.html#.isX86_64 - this should probably detect x86-64.
Re: Debugging a Memory Leak
On 11/17/14 11:41 PM, Maxime Chevalier-Boisvert wrote: GC problems are *nasty*. My advice is to run the simplest program you can think of that still exhibits the problem, and then put in printf debugging everywhere to see where it breaks down. Not sure if this is useful. Unfortunately, the program doesn't break or crash. It just keeps allocating memory that doesn't get freed. There must be some false reference somewhere. I'm not sure how I can printf debug my way out of that. By break down, I mean it does what you don't want :) You will need to instrument the GC and/or druntime. Note, if there is a false pointer, it's likely stack based, and likely there is not very many of them. But you have NO_INTERIOR set. This means the false pointer MUST point at the beginning of the block in order to keep it alive. As I said, these are tricky issues. It would not be easy to determine. One thing you can try -- allocate the block as a class, with a finalizer. This gives you the ability to sense when/if a block is finalized. That can help you determine the point at which your program starts to misbehave. -Steve
Re: vibe.d problem
Thread name: Re: vibe.d problem Mail number: 2 Date: Tue, Nov 18, 2014 In reply to: DigitalmarsD learn On Mon, 17 Nov 2014 16:24:17 -0500 låzaro via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Building vibe-d 0.7.20 configuration libevent, build type debug. this is very old. try git HEAD instead, it should help. How could I do that using dub?
Re: vibe.d problem
On Tue, 18 Nov 2014 08:37:14 -0500 Lázaro Armando via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Thread name: Re: vibe.d problem Mail number: 2 Date: Tue, Nov 18, 2014 In reply to: DigitalmarsD learn On Mon, 17 Nov 2014 16:24:17 -0500 låzaro via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Building vibe-d 0.7.20 configuration libevent, build type debug. this is very old. try git HEAD instead, it should help. How could I do that using dub? dunno, not using it. let's hope that some DUB user will answer. signature.asc Description: PGP signature
Overloading struct members (or cast?)
Hello again and welcome to another tale of mystery :)
I, again, am facing problems connecting my D program to the C API
as seen in the callback thread before.
I want to write a callback function that is assigned to a struct
member. The function should write data from members of another
struct to the command line. Please consider my code:
void MyCB(void* pVoid) {
DataInfo_t* userData; //DataInfo_t is a struct
userData = cast(DataInfo_t*) pVoid;
writeln(Value: , pMsgUserData.Values[i].value.string);
}
Here the DataInfo_t struct has a member Values which itself is a
struct. The programmer of the API called the members of the union
inside the Values struct after simple data types or pointers to
them, specifically
union value {
const char *string;
}
When I try to compile I get the following error:
Error: need 'this' for 'string' of type 'const(char*)'
I'm not quite sure what the error wants to tell me. The way I see
it is that there is some kind of problem with the instance of the
struct and hence the reference to that specific member value does
not work.
Any ideas?
Re: Overloading struct members (or cast?)
Wsdes:
union value {
const char *string;
}
Try:
union Value {
const char* myString;
}
Note the upper caseing, the spacing after the star, and the
string name replaced with something else.
Bye,
bearophile
Re: vibe.d problem
On 2014-11-18 8:37 AM, Lázaro Armando via Digitalmars-d-learn wrote: How could I do that using dub? You must download the most recent version of dub from http://code.dlang.org Run the commands: dub remove vibe-d --force-remove dub fetch vibe-d --version=0.7.21-rc.4 The list of versions you can use is here: https://github.com/rejectedsoftware/vibe.d/releases
Re: vibe.d problem
On Tuesday, 18 November 2014 at 17:16:33 UTC, CraigDillabaugh wrote: On Monday, 17 November 2014 at 22:02:13 UTC, låzaro via Digitalmars-d-learn wrote: Error executing command run: dmd failed with exit code 1. Not sure exactly what your issue is, and am a bit rusty on Vibe/dub, but you may have better luck getting answers here: http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/ What if you just type dub instead of dub run. Sorry for the noise - I see you got an answer in the 'other' version of this thread.
Re: vibe.d problem
On Monday, 17 November 2014 at 22:02:13 UTC, låzaro via Digitalmars-d-learn wrote: Hi there folks, let me the fact talk for me lazaro@leviatan:~$ dub init aplicacion vibe.d Successfully created an empty project in '/home/lazaro/aplicacion'. lazaro@leviatan:~$ cd aplicacion/ lazaro@leviatan:~/aplicacion$ dub run Building vibe-d 0.7.20 configuration libevent, build type debug. Running dmd... ../.dub/packages/vibe-d-0.7.20/source/vibe/templ/parsertools.d(12): Deprecation: module std.metastrings is deprecated - Please use std.string.format, std.conv.to or std.conv.parse instead ../.dub/packages/vibe-d-0.7.20/source/vibe/templ/diet.d(28): Deprecation: module std.metastrings is deprecated - Please use std.string.format, std.conv.to or std.conv.parse instead ../.dub/packages/vibe-d-0.7.20/source/vibe/core/drivers/libevent2.d(491): Deprecation: function core.time.Duration.fracSec is deprecated - Please use split instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/core/drivers/libevent2_tcp.d(110): Deprecation: function core.time.Duration.fracSec is deprecated - Please use split instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/core/drivers/libevent2_tcp.d(269): Deprecation: function core.time.Duration.fracSec is deprecated - Please use split instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/core/task.d(203): Deprecation: alias object.clear is deprecated - Please use destroy instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/core/task.d(204): Deprecation: alias object.clear is deprecated - Please use destroy instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/inet/message.d(186): Deprecation: constructor std.datetime.SimpleTimeZone.this is deprecated - Please use the overload which takes a Duration. ../.dub/packages/vibe-d-0.7.20/source/vibe/inet/webform.d(53): Error: std.string.indexOfAny!(char, char).indexOfAny at /usr/include/dmd/phobos/std/string.d(1044) conflicts with vibe.utils.string.indexOfAny at ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/string.d(123) ../.dub/packages/vibe-d-0.7.20/source/vibe/inet/webform.d(63): Error: std.string.indexOfAny!(char, char).indexOfAny at /usr/include/dmd/phobos/std/string.d(1044) conflicts with vibe.utils.string.indexOfAny at ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/string.d(123) ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(124): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!+=(this.m_bytes, sz) instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(140): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!-=(this.m_bytes, *pb) instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(143): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!+=(this.m_bytes, new_size) instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(152): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!-=(this.m_bytes, *pb) instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(161): Warning: calling std.exception.enforceEx!(OutOfMemoryError).enforceEx!bool.enforceEx without side effects discards return value of type bool, prepend a cast(void) if intentional ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(466): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!-=(this.m_nfree, 1) instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(471): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!+=(this.m_nalloc, 1) instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(489): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!-=(this.m_nalloc, 1) instead. ../.dub/packages/vibe-d-0.7.20/source/vibe/utils/memory.d(490): Deprecation: Read-modify-write operations are not allowed for shared variables. Use core.atomic.atomicOp!+=(this.m_nfree, 1) instead. FAIL ../.dub/packages/vibe-d-0.7.20/.dub/build/libevent-debug-linux.posix-x86-dmd_2066-316CEFCAEB0F07469ED054933004D631/ vibe-d staticLibrary Error executing command run: dmd failed with exit code 1. Not sure exactly what your issue is, and am a bit rusty on Vibe/dub, but you may have better luck getting answers here: http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/ What if you just type dub instead of dub run.
Re: Overloading struct members (or cast?)
On 11/18/2014 07:32 AM, Wsdes wrote:
Error: need 'this' for 'string' of type 'const(char*)'
Reduced:
struct S
{
union Value
{
const char* myString;
}
}
void main()
{
auto s = S();
auto mine = s.Value.myString;// ERROR
}
You may be thinking that Value introduces a name scope so that you can
reference its myString by Value.myString.
You have two options:
a) Remove Value so that it is an anonymous union. myString becomes a
direct member of S:
struct S
{
union// -- Anonymous
{
const char* myString;
}
}
void main()
{
auto s = S();
auto mine = s.myString;// -- No more Value
}
b) Make S have an actual member of type Value:
struct S
{
union Value
{
const char* myString;
}
Value value;// -- Added
}
void main()
{
auto s = S();
auto mine = s.value.myString;// -- Note lower initial
}
Ali
Re: vibe.d problem
On Tuesday, 18 November 2014 at 13:37:54 UTC, Lázaro Armando via Digitalmars-d-learn wrote: this is very old. try git HEAD instead, it should help. How could I do that using dub? Running `dub upgrade` should be enough as a new version of vibe.d was just released.
Re: Overloading struct members (or cast?)
On 11/18/14 1:28 PM, Ali Çehreli wrote:
On 11/18/2014 07:32 AM, Wsdes wrote:
Error: need 'this' for 'string' of type 'const(char*)'
Reduced:
struct S
{
union Value
{
const char* myString;
}
}
void main()
{
auto s = S();
auto mine = s.Value.myString;// ERROR
}
You may be thinking that Value introduces a name scope so that you can
reference its myString by Value.myString.
You have two options:
a) Remove Value so that it is an anonymous union. myString becomes a
direct member of S:
struct S
{
union// -- Anonymous
{
const char* myString;
}
}
void main()
{
auto s = S();
auto mine = s.myString;// -- No more Value
}
b) Make S have an actual member of type Value:
struct S
{
union Value
{
const char* myString;
}
Value value;// -- Added
}
void main()
{
auto s = S();
auto mine = s.value.myString;// -- Note lower initial
}
Ali
This works in C++:
struct S
{
union
{
const char *myString;
} Value;
};
But the issue is that D does not require the semicolon at the end of the
struct, so by the closing brace, it is done with the union.
the closest solution you can get is the last one you said.
I never even considered that you can't make an anonymous struct or union
type and assign it to a member in D. Not sure if we really need to
support it though.
-Steve
Explicitly Freeing Memory
I posted a thread the other day explaining that I was running into a memory leak issue which is very hard to debug. There seems to be a false pointer somewhere, and I have no way of knowing where that is or which object is being pointed to. I decided to take the easy way out and explicitly free memory when I don't need it. Unfortunately, this brings about more problems. I'm trying to explicitly free chunks of memory allocated with GC.malloc() in a destructor. This works fine while the program is running, but when the program terminates, it seems the GC calls all destructors in an arbitrary order. I then get a core.exception.InvalidMemoryOperationError because I'm trying to free memory that is already freed. Not quite sure where to go from here... I guess I'd have to allocate all of the objects I want to free outside of GC'd space, but D doesn't seem to provide a convenient syntax for doing so. The alternate solution I'm considering is to have a special function to destroy all the objects owned by my parent object before destroying the parent object itself, and calling this function explicitly.
Re: Explicitly Freeing Memory
On Wed, Nov 19, 2014 at 03:47:03AM +, Maxime Chevalier-Boisvert via Digitalmars-d-learn wrote: [...] I'm trying to explicitly free chunks of memory allocated with GC.malloc() in a destructor. This works fine while the program is running, but when the program terminates, it seems the GC calls all destructors in an arbitrary order. I then get a core.exception.InvalidMemoryOperationError because I'm trying to free memory that is already freed. [...] Yeah, it is well-known that relying on destructor calling order is a bad idea. The GC makes no guarantees about what order destructors will get called, if they get called at all. Also, calling GC allocation / deallocation functions from inside a dtor is also a bad idea, since the GC is not reentrant. Unfortunately I don't have any good suggestions... I have been avoiding depending on dtors in D because of the aforementioned issues (and more), so I haven't had much experience in debugging dtor-related problems in D. T -- An elephant: A mouse built to government specifications. -- Robert Heinlein
Re: Explicitly Freeing Memory
On Wednesday, 19 November 2014 at 03:47:04 UTC, Maxime Chevalier-Boisvert wrote: I posted a thread the other day explaining that I was running into a memory leak issue which is very hard to debug. There seems to be a false pointer somewhere, and I have no way of knowing where that is or which object is being pointed to. I decided to take the easy way out and explicitly free memory when I don't need it. Unfortunately, this brings about more problems. I'm trying to explicitly free chunks of memory allocated with GC.malloc() in a destructor. This works fine while the program is running, but when the program terminates, it seems the GC calls all destructors in an arbitrary order. I then get a core.exception.InvalidMemoryOperationError because I'm trying to free memory that is already freed. InvalidMemoryOperationError occurs when you're trying to invoke GC functions during a GC pass (because the current D GC is non-reentrant). This can occur if you explicitly free objects from the destructor, and the destructor is invoked by the GC. I suppose you can work around this by using a separate function which deallocates owned objects' memory. P.S. Still working on Diamond.
Re: Overloading struct members (or cast?)
On 11/18/2014 11:01 AM, Steven Schveighoffer wrote:
This works in C++:
struct S
{
union
{
const char *myString;
} Value;
};
But the issue is that D does not require the semicolon at the end of the
struct, so by the closing brace, it is done with the union.
Interesting. It never occurred to me that the lack of semicolons could
have that effect.
the closest solution you can get is the last one you said.
I never even considered that you can't make an anonymous struct or union
type and assign it to a member in D. Not sure if we really need to
support it though.
I wouldn't miss that feature. :)
If I am not mistaken, the only benefit of anonymous types is that they
cannot refer to themselves. I remember reading in a C++ thread years ago
that anonymous types could not have contructors, destructors, and
assignment operators either because they could not spell out the name of
the type to define such functions.
Ali
