Re: Building basic gtkd,opengl application
On Monday, 21 September 2015 at 03:26:36 UTC, BBasile wrote: On Sunday, 20 September 2015 at 22:30:54 UTC, Michał wrote: I am trying to make some application using gtkd and opengl. I have made simple program but it didn't work and I have no idea why. I have never used gtk so maybe I'm doing something stupid : / The code: http://pastebin.com/7NfbMqaK Error: http://pastebin.com/vaFAP0bu Some ideas? Any tips to gtkd/gtk/gl are welcome. at least one obvious error: line 37, `MyArea glarea = new MyArea();` `Myarea` scope is limited to the __ctor. You should declare it as a class private variable and then instantiate it in the _ctor, otherwise. With the GC it's probably still alive til next collection but this is nevertheless an error. NVM this is totally wrong. You can create an instance without keeping trace of it in a variable. This even something common in laguages using ownership and if you don't need to manipulate the class instance after its construction... :/
Re: Building basic gtkd,opengl application
On Sunday, 20 September 2015 at 22:30:54 UTC, Michał wrote: I am trying to make some application using gtkd and opengl. I have made simple program but it didn't work and I have no idea why. I have never used gtk so maybe I'm doing something stupid : / The code: http://pastebin.com/7NfbMqaK Error: http://pastebin.com/vaFAP0bu Some ideas? Any tips to gtkd/gtk/gl are welcome. at least one obvious error: line 37, `MyArea glarea = new MyArea();` `Myarea` scope is limited to the __ctor. You should declare it as a class private variable and then instantiate it in the _ctor, otherwise. With the GC it's probably still alive til next collection but this is nevertheless an error.
Building basic gtkd,opengl application
I am trying to make some application using gtkd and opengl. I have made simple program but it didn't work and I have no idea why. I have never used gtk so maybe I'm doing something stupid : / The code: http://pastebin.com/7NfbMqaK Error: http://pastebin.com/vaFAP0bu Some ideas? Any tips to gtkd/gtk/gl are welcome.
Re: What difference between std.typecons.Tuple and std.meta.AliasSeq
On Sunday, 20 September 2015 at 18:28:13 UTC, Alex Parrill wrote: (though you can declare a variable using an AliasSeq containing only types; I think this acts like defining one variable for each type in the seq). This is what is used inside std.typecons.Tuple
Re: Weird behaviour with File.eof
V Sun, 20 Sep 2015 20:17:36 +
Dandyvica via Digitalmars-d-learn
napsáno:
> Hi all,
>
> I can't explain to myself this weird behavior:
>
> void main(string[] argv)
> {
> char[] line;
> auto fh = File(argv[1]);
> while (!fh.eof) {
> writef("before readln eof=%s, ", fh.eof);
> fh.readln(line,std.ascii.newline);
> writefln("line=<%s>, after readln
> eof=%s",chomp(line), fh.eof); }
> fh.close();
> }
>
> My file is made of 10 lines:
>
>
> cat numbers.txt
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> 10
>
> ╰─$ wc -l numbers.txt
> 10 numbers.txt
>
> When run:
>
> before readln eof=false, line=<1>, after readln eof=false
> before readln eof=false, line=<2>, after readln eof=false
> before readln eof=false, line=<3>, after readln eof=false
> before readln eof=false, line=<4>, after readln eof=false
> before readln eof=false, line=<5>, after readln eof=false
> before readln eof=false, line=<6>, after readln eof=false
> before readln eof=false, line=<7>, after readln eof=false
> before readln eof=false, line=<8>, after readln eof=false
> before readln eof=false, line=<9>, after readln eof=false
> before readln eof=false, line=<10>, after readln eof=false
> before readln eof=false, line=<>, after readln eof=true
>
> I can't explain why eof is not set to true after reading the last
> line ?!
>
> Last DMD 2.68.1.0, Linux Mint 17.2.
>
>
> Thanks for any clue.
This is normal behavior
http://www.cplusplus.com/reference/cstdio/feof/
"Notice that stream's internal position indicator may point to the
end-of-file for the next operation, but still, the end-of-file
indicator may not be set until an operation attempts to read at that
point."
Weird behaviour with File.eof
Hi all,
I can't explain to myself this weird behavior:
void main(string[] argv)
{
char[] line;
auto fh = File(argv[1]);
while (!fh.eof) {
writef("before readln eof=%s, ", fh.eof);
fh.readln(line,std.ascii.newline);
writefln("line=<%s>, after readln eof=%s",chomp(line), fh.eof);
}
fh.close();
}
My file is made of 10 lines:
cat numbers.txt
1
2
3
4
5
6
7
8
9
10
╰─$ wc -l numbers.txt
10 numbers.txt
When run:
before readln eof=false, line=<1>, after readln eof=false
before readln eof=false, line=<2>, after readln eof=false
before readln eof=false, line=<3>, after readln eof=false
before readln eof=false, line=<4>, after readln eof=false
before readln eof=false, line=<5>, after readln eof=false
before readln eof=false, line=<6>, after readln eof=false
before readln eof=false, line=<7>, after readln eof=false
before readln eof=false, line=<8>, after readln eof=false
before readln eof=false, line=<9>, after readln eof=false
before readln eof=false, line=<10>, after readln eof=false
before readln eof=false, line=<>, after readln eof=true
I can't explain why eof is not set to true after reading the last
line ?!
Last DMD 2.68.1.0, Linux Mint 17.2.
Thanks for any clue.
Re: Question about Object.destroy
Thank you, this clarified a lot.
Re: Question about Object.destroy
On Sunday, 20 September 2015 at 18:52:17 UTC, Lambert Duijst wrote: Just want to know if D protects against dangling pointers or is this just something you should never do. The answer is both: it tries to protect you but you still shouldn't do it. If we are not supposed to use Object.destroy anymore then how can we still free non-memory resources that are held by classes (which are typically cg'ed) in a deterministic way ? The function btw is actually destroy(Object). It works as Object.destroy because of the uniform function call syntax feature which will rewrite it. But I recommend doing destroy(Object) because then you get consistent results, even if an interface has its own destroy method. But you can use it, destroy is cool. delete was teh problem because it doesn't provide even the minimal protection the destroy function has. (You can also malloc/free or stack allocate if you really want to take matters into your own hands but then the language basically doesn't help you at all in the dangling pointer problem.)
Re: Identifying and dealing with deprecated/removed language features
On 2015-09-20 13:17, Martin Krejcirik wrote: __VERSION__ ? Will only solve identifying if a feature is supported or not. When the features is actually used a string mixin will still be required, as far as I know. -- /Jacob Carlborg
Re: Question about Object.destroy
On Sunday, 20 September 2015 at 18:50:44 UTC, Adam D. Ruppe wrote: On Sunday, 20 September 2015 at 18:41:18 UTC, anonymous wrote: But that doesn't change either. I think Adam is mistaken here. huh, I just checked the source... and you are right, it doesn't set classes to null itself, but does null out the vtable inside. *ppv = null; // zero vptr even if `resetMemory` is false druntime/src/rt/lifetime.d line 1373 So that's why it is segfaulting, the table of virtual functions is nulled after it is destroyed rather than the reference. Oops, I think I replied too fast, did not read this reply of yours, which answers some of my questions. If the vtable is nulled then this will always lead to a segfault when methods of deleted object are called, which is good because doing so is a programming error anyway, but at least it does not lead to weird memory corruptions etc..
Re: Question about Object.destroy
On Sunday, 20 September 2015 at 18:41:18 UTC, anonymous wrote: But that doesn't change either. I think Adam is mistaken here. huh, I just checked the source... and you are right, it doesn't set classes to null itself, but does null out the vtable inside. *ppv = null; // zero vptr even if `resetMemory` is false druntime/src/rt/lifetime.d line 1373 So that's why it is segfaulting, the table of virtual functions is nulled after it is destroyed rather than the reference.
Re: Question about Object.destroy
On Sunday, 20 September 2015 at 18:39:57 UTC, Adam D. Ruppe wrote:
On Sunday, 20 September 2015 at 18:34:37 UTC, Lambert Duijst
wrote:
Oh that surprises me a bit, because I read in the list of
deprecated features that delete is deprecated and that the
right thing to do is to use destroy instead.
Right. One of the benefits of destroy is that it nulls the
reference. Once you destroy it, you aren't supposed to use it
again*. The zombie is kept around until the GC reaps it to
protect against dangling pointers (somewhat), but you still
aren't actually supposed to reuse it.
* If you really want to you can cheat by making a separate
local variable to hold it before destroy it... destroy only
nulls the variable you pass in, but I do not recommend doing
this. Instead, you should reconstruct the object, even if
implementing an object pool or something.
I use writeln("Address of s ", &s) to print the address, not
sure if that is correct though.
that gives you the address of the local variable, not the
reference. For address of the reference, try `cast(void*) s`.
An Object in D is like an Object* in C++. So when you & it, you
get a pointer to a pointer.
Ah, that clarifies a lot ! Thanks. Also does destroy set all
references to that object to null in this case there was only 1,
but in a real program there can of course be many references to
an object.
I wasn't interested in reusing an object after it was deleted,
but more in the behaviour of a program if you do use it after a
deletion. Just want to know if D protects against dangling
pointers or is this just something you should never do.
If we are not supposed to use Object.destroy anymore then how can
we still free non-memory resources that are held by classes
(which are typically cg'ed) in a deterministic way ?
Re: Question about Object.destroy
On Sunday 20 September 2015 20:34, Lambert Duijst wrote:
> On Sunday, 20 September 2015 at 18:21:52 UTC, Adam D. Ruppe wrote:
[...]
>> So after calling destroy(s), s is null, so it segfaults when
>> you try to use it.
[...]
> Also when I print the address of s it gives me some hex number,
> but not 0 (null).
> I use writeln("Address of s ", &s) to print the address, not sure
> if that is correct though.
> Before and after the explicit destroy I get the same address,
> which is 7FFF549108D8.
&s is the address of the variable. We're not interested that but in the
reference that's stored in s. You can print that by casting to void*:
writeln(cast(void*) s);
But that doesn't change either. I think Adam is mistaken here.
Re: Question about Object.destroy
On Sunday, 20 September 2015 at 18:34:37 UTC, Lambert Duijst
wrote:
Oh that surprises me a bit, because I read in the list of
deprecated features that delete is deprecated and that the
right thing to do is to use destroy instead.
Right. One of the benefits of destroy is that it nulls the
reference. Once you destroy it, you aren't supposed to use it
again*. The zombie is kept around until the GC reaps it to
protect against dangling pointers (somewhat), but you still
aren't actually supposed to reuse it.
* If you really want to you can cheat by making a separate local
variable to hold it before destroy it... destroy only nulls the
variable you pass in, but I do not recommend doing this. Instead,
you should reconstruct the object, even if implementing an object
pool or something.
I use writeln("Address of s ", &s) to print the address, not
sure if that is correct though.
that gives you the address of the local variable, not the
reference. For address of the reference, try `cast(void*) s`.
An Object in D is like an Object* in C++. So when you & it, you
get a pointer to a pointer.
Re: Question about Object.destroy
On Sunday, 20 September 2015 at 18:21:52 UTC, Adam D. Ruppe wrote:
Very simple: destroy(s) (or s.destroy but i prefer destroy(s))
will set the reference it is passed to null because you aren't
supposed to use it anymore.
So after calling destroy(s), s is null, so it segfaults when
you try to use it.
Oh that surprises me a bit, because I read in the list of
deprecated features that delete is deprecated and that the right
thing to do is to use destroy instead.
Also when I print the address of s it gives me some hex number,
but not 0 (null).
I use writeln("Address of s ", &s) to print the address, not sure
if that is correct though.
Before and after the explicit destroy I get the same address,
which is 7FFF549108D8.
Btw I use dmd v2.067 on mac os 10.10.3
Thanks for the quick replies.
Re: What difference between std.typecons.Tuple and std.meta.AliasSeq
On Sunday, 20 September 2015 at 18:10:49 UTC, Suliman wrote:
Sometimes it's hard to understand the D philosophy, for example
now I can't understand diffrence between std.typecons.Tuple and
std.meta.AliasSeq. I know that in language like Python there is
spatial data type named tuple like:
tup1 = ('physics', 'chemistry', 1997, 2000);
But what in D? That was Tuples module, but it's look like it
was renamed to
http://forum.dlang.org/thread/mnhfhs$2b9o$1...@digitalmars.com
But look like std.typecons.Tuple and std.meta.AliasSeq are
exists. So I really can't understand what and how I should to
use that's all.
std.typecons.Tuple is more like Python's tuples. It effectively
defines a struct with one field per type in the tuple definition,
and only holds values.
std.meta.AliasSeq (aka std.typetuple.TypeTuple) is a compile-time
construct, used mostly with templates, and is more like a list.
They can hold types, values, or symbol aliases, but only exist
during compilation (though you can declare a variable using an
AliasSeq containing only types; I think this acts like defining
one variable for each type in the seq).
Re: What difference between std.typecons.Tuple and std.meta.AliasSeq
AliasSeq is just a random collection of stuff. A Tuple is more like a struct.
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 17:02:37 UTC, Russel Winder wrote: English and Spanish meanings of the word are very different. In UK (not sure about Canada, USA, Australia, New Zealand, South Africa,…) it is generally a somewhat derogatory term. In French it means "to rub down with abrasive paper".
Re: Question about Object.destroy
Very simple: destroy(s) (or s.destroy but i prefer destroy(s)) will set the reference it is passed to null because you aren't supposed to use it anymore. So after calling destroy(s), s is null, so it segfaults when you try to use it.
What difference between std.typecons.Tuple and std.meta.AliasSeq
Sometimes it's hard to understand the D philosophy, for example
now I can't understand diffrence between std.typecons.Tuple and
std.meta.AliasSeq. I know that in language like Python there is
spatial data type named tuple like:
tup1 = ('physics', 'chemistry', 1997, 2000);
But what in D? That was Tuples module, but it's look like it was
renamed to
http://forum.dlang.org/thread/mnhfhs$2b9o$1...@digitalmars.com
But look like std.typecons.Tuple and std.meta.AliasSeq are
exists. So I really can't understand what and how I should to use
that's all.
Re: Question about Object.destroy
On Sunday, 20 September 2015 at 17:43:01 UTC, Lambert Duijst wrote: Is it because: - The GC did decide to run and cleanup memory straight after the call to s.destroy() - An object being in an invalid state means the program segfaults when the object is used ? - Another reason.. All methods are virtual by default. My guess would be that the invalid state implies that the virtual table pointer is not valid anymore, hence the crash.
Question about Object.destroy
Hi all,
I have a question about the following piece of code that I wrote
to experiment with explicit deletion of objects. I am interested
in this because, even though D has a garbage collection,
sometimes an object holds a non-memory resource, such as a file
handle. In these cases explicit calls to a destructor are needed
if you want deterministic release of resources.
The code I wrote is this :
import std.stdio;
class MyClass
{
this(int a) {this.a = a;}
~this()
{
writeln("Destructor call");
}
void doSomething()
{
writeln("A is ", this.a);
}
int a;
};
void main(string args[])
{
MyClass s = new MyClass(42);
s.doSomething();
s.destroy();
s.doSomething();
}
The output of this program is:
A is 42
Destructor call
And then it segfaults.
This is obviously because of that last call to doSomething
Now the description of Object.destroy mentions that no GC memory
is freed by Object.destroy. It does, however, put the object in
an invalid state, but what does that mean and why does my program
segfault.
Is it because:
- The GC did decide to run and cleanup memory straight after the
call to s.destroy()
- An object being in an invalid state means the program
segfaults when the object is used ?
- Another reason..
And more importantly, can this way of programming with explicit
destroy calls lead to memory corruption due to dangling pointers
? or will D always let your program segfault whenever a deleted
object is accessed ?
Please enlighten me, I am just a newbie :-)
Re: This is probably trivial or impossible Code Introspection...
On Sunday, 20 September 2015 at 05:50:16 UTC, Ali Çehreli wrote:
On 09/19/2015 10:30 PM, H. S. Teoh via Digitalmars-d-learn
wrote:
On Sun, Sep 20, 2015 at 05:21:03AM +, WhatMeWorry via
Digitalmars-d-learn wrote:
[...]
Thanks. But now I have an even more fundamental problem. I
keep
getting a FieldNameTuple is not defined. But I've clearly
got the
import statement. I even copied the example from Phobos
verbatim:
import std.traits;
struct S { int x; float y; }
static assert(FieldNameTuple!S == TypeTuple!("x", "y"));
You need to use is(...) when comparing types:
static assert(is(FieldNameTuple!S == TypeTuple!("x", "y")));
HTH,
--T
True but ever-confusingly, they are not types. :) It works
without the is expression. Otherwise, we need to add typeofs as
well:
static assert(is(typeof(FieldNameTuple!S) ==
typeof(AliasSeq!("x", "y";
Ali
Should of tried this earlier, but just for grins I threw in
another trait: EnumMembers.
import std.traits;
struct S { int x; float y; }
static assert(FieldNameTuple!S == TypeTuple!("x", "y")); // FAILS
enum E : int { a, b, c }
int[] abc = cast(int[]) [ EnumMembers!E ];// WORKS
The EnumMembers from traits compiles/links fine. Ergo, it must
be I've got an old version of D Lib? I see on the web site that
D Lib is now at 2.068.1
Looking at my old folders, I see a
dmd-2.066_0-OneClickWindowInstaller folder that I must of used
around October 2014 for my initial install. Is there a tool or
subsystem that I can use to see the history or FildNameTyple?
Now, I need to figure out how to upgrade my D, DMD or Phobos (not
sure about terminology) without disturbing my Visual D
environment. Wish me luck :)
Thanks for helping me with these beginner questions.
Re: Debugging D shared libraries
Am Sun, 20 Sep 2015 17:47:00 +0200
schrieb Johannes Pfau :
> Am Sat, 19 Sep 2015 17:41:41 +0100
> schrieb Russel Winder via Digitalmars-d-learn
> :
>
> > On Sat, 2015-09-19 at 16:33 +, John Colvin via
> > Digitalmars-d-learn wrote:
> > > On Saturday, 19 September 2015 at 16:15:45 UTC, Russel Winder
> > > wrote:
> > > > Sadly the:
> > > >
> > > > pragma(LDC_global_crt_ctor, 0)
> > > > void initRuntime() {
> > > > import core.runtime: Runtime;
> > > > Runtime.initialize();
> > > >}
> > > >
> > > > will not compile under DMD :-(
> > >
> > > version(LDC){ /* ... */ }
> > >
> > > not that it helps make things work correctly, but at least
> > > they'll compile :)
> >
> > Indeed, it works well. Well for LDC. DMD and GDC are still broken.
> > My GDC problems are deeper that this code: Debian packages seem to
> > have weird problems and Fedora do not package GDC.
> >
>
> Have you tried using a newer GDC version? The debian jessie version
> probably uses the 2.064.2 frontend.
>
> I wanted to add @attribute(cctor/cdtor) support for some time now, I
> even wrote the code some time but didn't push it to the main repo for
> some reason. I'll put it on the TODO list but I can't work on this for
> the next 2-3 weeks.
Just realized this thread is titled "Debugging D shared libraries" ;-)
GDC does not yet support shared libraries.
Re: Debugging D shared libraries
Am Sat, 19 Sep 2015 17:41:41 +0100
schrieb Russel Winder via Digitalmars-d-learn
:
> On Sat, 2015-09-19 at 16:33 +, John Colvin via Digitalmars-d-learn
> wrote:
> > On Saturday, 19 September 2015 at 16:15:45 UTC, Russel Winder
> > wrote:
> > > Sadly the:
> > >
> > > pragma(LDC_global_crt_ctor, 0)
> > > void initRuntime() {
> > > import core.runtime: Runtime;
> > > Runtime.initialize();
> > >}
> > >
> > > will not compile under DMD :-(
> >
> > version(LDC){ /* ... */ }
> >
> > not that it helps make things work correctly, but at least
> > they'll compile :)
>
> Indeed, it works well. Well for LDC. DMD and GDC are still broken. My
> GDC problems are deeper that this code: Debian packages seem to have
> weird problems and Fedora do not package GDC.
>
Have you tried using a newer GDC version? The debian jessie version
probably uses the 2.064.2 frontend.
I wanted to add @attribute(cctor/cdtor) support for some time now, I
even wrote the code some time but didn't push it to the main repo for
some reason. I'll put it on the TODO list but I can't work on this for
the next 2-3 weeks.
Re: How do you handle OutOfMemoryError?
On Sunday, 20 September 2015 at 00:16:50 UTC, Enjoys Math wrote: Here's my code: https://drive.google.com/file/d/0B3LYxKGJ4ZI_MV91SkxPVVlSOW8/view?usp=sharing I don't have access to a debugger. Run the code for a few minutes and it tends to crash with a core OutOfMemoryError. Any suggestions welcome including regularly cleaning up memory used. Thanks. Memory allocated with the GC (e.g. using new) will never be freed if a reference is kept to it. Are you accidentally or deliberately keeping a complete history of all programs? Are you allocating any memory from anywhere other than the GC? What OS? How much RAM? Are you compiling with -m32 (and conversely what happens if you compile with -m64)?
Re: Get AA key and value type
On Sunday, 20 September 2015 at 09:34:15 UTC, Ali Çehreli wrote: On 09/20/2015 12:47 AM, Pierre wrote: I see, maybe .KeyType and .ValueType should be integrated in AA. Or like C++ with map, make a ValueType(::value_type) field wich contain a pair of type. Currently, they are templates in std.traits: http://dlang.org/phobos/std_traits.html#KeyType Ali Nice! thank you for the information.
Re: Identifying and dealing with deprecated/removed language features
Dne 20. 9. 2015 v 11:55 Jacob Carlborg napsal(a): > I guess I can use __traits(compiles) to check if typedef and then insert > the "static if" with a string mixing. But is there a better way to do this? __VERSION__ ? -- mk
Re: Debugging D shared libraries
Dne 19. 9. 2015 v 18:41 Russel Winder via Digitalmars-d-learn napsal(a): > Indeed, it works well. Well for LDC. DMD and GDC are still broken. My > GDC problems are deeper that this code: Debian packages seem to have > weird problems and Fedora do not package GDC. All I need to do to make your example work, is to move the calls of Runtime.initialize and Runtime.terminate to a wrapper functions called at the start and end of the main program. -- mk
Identifying and dealing with deprecated/removed language features
I have a library that needs to check if a type is a typedef. Something like: static if (is(T == typedef)) But now typedef is deprecated or even removed. I want my library to compile with the latest version of DMD without any deprecation warnings but at the same time be backwards compatible. What's the best way to deal with this? I guess I can use __traits(compiles) to check if typedef and then insert the "static if" with a string mixing. But is there a better way to do this? -- /Jacob Carlborg
Re: Get AA key and value type
On 09/20/2015 12:47 AM, Pierre wrote: I see, maybe .KeyType and .ValueType should be integrated in AA. Or like C++ with map, make a ValueType(::value_type) field wich contain a pair of type. Currently, they are templates in std.traits: http://dlang.org/phobos/std_traits.html#KeyType Ali
Re: Anybody use Derelict FreeType recently (successfully)
On Sunday, 20 September 2015 at 02:58:21 UTC, WhatMeWorry wrote: For my D programming I use the Visual D Studio package (plug-in?) with the "free Visual Studio Shell (2013). I download Visual Studio Express 2015 and used the FreeType 2.6 solution file. (So no makefile). I tried making both a 32 and 64 bit freetype.dll I've got a 64 bit Windows 8.1 machine, but I tried to leave no stone untouched. I'm kinda self taught, so I might have made an error somewhere. Or Could Visual Studio Express 2015 be too new? The new unified C runtime that MS uses with VS 2015 could potentially be an issue, but you would have seen a SharedLibLoadException if that were a problem in this case. I'll play around with it when I have time. I want to try to reproduce it if possible so that if it turns out to be an issue others are likely to face, I can add a warning to the future documentation about how *not* to build FreeType on Windows. I've had problems with Visual Studio builds of open source libraries in the past. The project solutions that they ship are often outdated, missing certain files or options. Visual Studio support tends to, understandably, lag behind in projects that are primarily maintained by Linux or Mac users, so it's often up to community members to keep it updated. For that reason, I prefer to build Windows DLLs with MinGW + MSYS2. I rarely have any issues taking that approach. PS. Derelict is great. I'm using FreeImage and OpenAL as well. Thanks!
Re: Get AA key and value type
On Saturday, 19 September 2015 at 18:13:09 UTC, Marc Schütz wrote:
You can also do it with built-in syntax:
template AATypes(AA : K[V], K, V)
{
alias Key = K;
alias Value = V;
}
K[V] supposed to be V[K] btw...
Re: Get AA key and value type
On Saturday, 19 September 2015 at 18:13:09 UTC, Marc Schütz wrote:
On Saturday, 19 September 2015 at 12:50:51 UTC, Pierre wrote:
Hi everybody,
I would like to extract key and value type from AA.
You can also do it with built-in syntax:
template AATypes(AA : K[V], K, V)
{
alias Key = K;
alias Value = V;
}
I see, maybe .KeyType and .ValueType should be integrated in AA.
Or like C++ with map, make a ValueType(::value_type) field wich
contain a pair of type.
Re: Debugging D shared libraries
On Saturday, 19 September 2015 at 10:45:22 UTC, Russel Winder
wrote:
Calling D from Python. I have two functions in D, compiled to a
shared object on Linux using LDC (but I get same problem using
DMD).
The sequential code:
extern(C)
double sequential(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * reduce!(
(double t, int i){ immutable x = (i - 0.5) * delta;
return t + 1.0 / (1.0 + x * x); })(
0.0, iota(1, n + 1));
Runtime.terminate();
return pi;
}
works entirely fine. However the "parallel" code:
extern(C)
double parallel(const int n, const double delta) {
Runtime.initialize();
const pi = 4.0 * delta * taskPool.reduce!"a + b"(
map!((int i){ immutable x = (i - 0.5) * delta; return
1.0 / (1.0 + x * x); })(iota(1, n + 1)));
Runtime.terminate();
return pi;
}
causes an immediate segfault (with LDC and DMD. I am assuming
that the problem is the lack of initialization of the
std.parallelism module and hence the use of taskPool is causing
a problem. I am betting I am missing something very simple
about module initialization, and that this is not actually a
bug.
Anyone any proposals?
Isn't it simply that when doing some work asynchronously, as with
task pool, work is being done in other threads than the main. All
the while, you're killing the Runtime. The fact that when
removing Runtime.terminate makes the code work might support
that explanation.
