Re: Typed Message Passing between D Processes
On Thursday, 25 June 2015 at 23:23:01 UTC, Laeeth Isharc wrote: not sure if this is quite what you are looking for, or if the performance overhead is acceptable but have you looked at msgpack to go on top of a lower level pipe ? Why is a lower-level pipe needed, when we have pipe in std.process?
Re: Typed Message Passing between D Processes
On Friday, 26 June 2015 at 09:06:18 UTC, Per Nordlöw wrote: On Thursday, 25 June 2015 at 23:23:01 UTC, Laeeth Isharc wrote: not sure if this is quite what you are looking for, or if the performance overhead is acceptable but have you looked at msgpack to go on top of a lower level pipe ? Why is a lower-level pipe needed, when we have pipe in std.process? well, that is the sort of lower level pipe I was referring to.
Re: Typed Message Passing between D Processes
On Friday, 26 June 2015 at 10:23:26 UTC, Laeeth Isharc wrote: On Friday, 26 June 2015 at 09:06:18 UTC, Per Nordlöw wrote: On Thursday, 25 June 2015 at 23:23:01 UTC, Laeeth Isharc wrote: not sure if this is quite what you are looking for, or if the performance overhead is acceptable but have you looked at msgpack to go on top of a lower level pipe ? Why is a lower-level pipe needed, when we have pipe in std.process? well, that is the sort of lower level pipe I was referring to. Ok, thanks.
Struct vs. Class
I have still some classes lying around in my code. As threading
is becoming more and more of an issue, classes and OOP in general
turn out to be a nuisance. It's not so hard to turn the classes
into structs, a lot of classes are in fact singletons (yes, I've
been kinda fading out classes for a while now). My question is
now, what do I have to keep in mind if I turn a cached class into
a cached struct, i.e.
initProgram()
{
auto myClass = new AwesomeDoEverything.instance(); // lives
for the rest of the program, is a singleton
}
// ...
myClass.call(input);
initProgram()
{
auto myStruct = AwesomeDoEverything(); // lives for the rest
of the program
}
// ...
myStruct.call(input); // Can live in different threads without
reinitializing it.
Or is there a way I can make a singleton class "thread-able"?
I cannot afford to re-initialize certain classes / structs
because I don't wanna hit the file system every time I do so.
Re: Struct vs. Class
On Fri, 26 Jun 2015 11:11:15 +
Chris via Digitalmars-d-learn wrote:
> I have still some classes lying around in my code. As threading
> is becoming more and more of an issue, classes and OOP in general
> turn out to be a nuisance. It's not so hard to turn the classes
> into structs, a lot of classes are in fact singletons (yes, I've
> been kinda fading out classes for a while now). My question is
> now, what do I have to keep in mind if I turn a cached class into
> a cached struct, i.e.
>
> initProgram()
> {
>auto myClass = new AwesomeDoEverything.instance(); // lives
> for the rest of the program, is a singleton
> }
>
> // ...
>
>myClass.call(input);
>
> initProgram()
> {
>auto myStruct = AwesomeDoEverything(); // lives for the rest
> of the program
> }
>
> // ...
>
>myStruct.call(input); // Can live in different threads without
> reinitializing it.
>
> Or is there a way I can make a singleton class "thread-able"?
>
> I cannot afford to re-initialize certain classes / structs
> because I don't wanna hit the file system every time I do so.
http://dlang.org/library/std/concurrency/init_once.html
Re: Struct vs. Class
On Fri, 26 Jun 2015 11:11:15 +
Chris via Digitalmars-d-learn wrote:
> I have still some classes lying around in my code. As threading
> is becoming more and more of an issue, classes and OOP in general
> turn out to be a nuisance. It's not so hard to turn the classes
> into structs, a lot of classes are in fact singletons (yes, I've
> been kinda fading out classes for a while now). My question is
> now, what do I have to keep in mind if I turn a cached class into
> a cached struct, i.e.
>
> initProgram()
> {
>auto myClass = new AwesomeDoEverything.instance(); // lives
> for the rest of the program, is a singleton
> }
>
> // ...
>
>myClass.call(input);
>
> initProgram()
> {
>auto myStruct = AwesomeDoEverything(); // lives for the rest
> of the program
> }
>
> // ...
>
>myStruct.call(input); // Can live in different threads without
> reinitializing it.
>
> Or is there a way I can make a singleton class "thread-able"?
>
> I cannot afford to re-initialize certain classes / structs
> because I don't wanna hit the file system every time I do so.
bad link:
http://dlang.org/phobos/std_concurrency.html#.initOnce
Re: Importing local modules in C style
On Thursday, 25 June 2015 at 13:57:35 UTC, Binarydepth wrote:
I want to import a module from my local project in C style
(#include "local.h").
You can theoretically do this with `mixin(import("local.d"));`.
This will more or less copy-paste the content of local.d into the
current scope. You also need to pass `-J.` to the compiler to
allow it to read the file.
But I would try to make it work with normal imports instead.
Re: Struct vs. Class
On Friday, 26 June 2015 at 11:28:38 UTC, Daniel Kozák wrote:
On Fri, 26 Jun 2015 11:11:15 +
Chris via Digitalmars-d-learn
wrote:
I have still some classes lying around in my code. As
threading is becoming more and more of an issue, classes and
OOP in general turn out to be a nuisance. It's not so hard to
turn the classes into structs, a lot of classes are in fact
singletons (yes, I've been kinda fading out classes for a
while now). My question is now, what do I have to keep in mind
if I turn a cached class into a cached struct, i.e.
initProgram()
{
auto myClass = new AwesomeDoEverything.instance(); // lives
for the rest of the program, is a singleton
}
// ...
myClass.call(input);
initProgram()
{
auto myStruct = AwesomeDoEverything(); // lives for the
rest
of the program
}
// ...
myStruct.call(input); // Can live in different threads
without
reinitializing it.
Or is there a way I can make a singleton class "thread-able"?
I cannot afford to re-initialize certain classes / structs
because I don't wanna hit the file system every time I do so.
bad link: http://dlang.org/phobos/std_concurrency.html#.initOnce
Thanks a million! This might do the trick and my classes can live
happily ever after :-)
Re: Typed Message Passing between D Processes
On Thursday, 25 June 2015 at 14:04:23 UTC, Per Nordlöw wrote: Is there an alternative to http://dlang.org/phobos/std_process.html#.pipe that can be used to do _typed_ _message_ _passing_ between two D processes with the same convenience as `send` and `receive` in std.concurrency ? Either in Phobos or in a third party library? You'd have to implement your own IPC for that to work. You can always use TCP and serialise everything. Atila
Re: Typed Message Passing between D Processes
std.concurrency was supposed to be able to handle that by design but it is impossible to do without any sort of standard serialization utility in Phobos (and, ideally, very fast binary serialization utility)
Re: Abstract sockets (linux)
On Thursday, 25 June 2015 at 19:47:37 UTC, Ali Çehreli wrote:
I've found an old example of mine, which uses abstract sockets.
Apparently, it was a concurrency experiment as well. Just
translated from Turkish to English:
http://ddili.org/ornek_kod/client_server.d
One difference I see is that mine doesn't set blocking. You can
use it like this:
1) Start it as a server:
./deneme --role=server
2) Start as many clients as needed:
./deneme --role=client
Ali
P.S. And here is the original Turkish version:
http://ddili.org/ornek_kod/istemci_sunucu.d
Thank you for the example code! I verified that client and
server communicated, and that a standard file-based unix socket
was not created. Then I simply changed the socketName to the
socket I was interested in, and tried the client against it.
Still no luck unfortunately, same error as earlier.
I have noticed that successful connect calls appear to show the
size as 23, whereas unsuccessful connect calls show 24.
This works (socat):
connect(3, {sa_family=AF_FILE, path=@"/var/run/ptmd.socket"},
23) = 0
This does not (from deneme, modified):
connect(3, {sa_family=AF_FILE, path=@"/var/run/ptmd.socket"},
24) = -1 ECONNREFUSED (Connection refused)
Re: Abstract sockets (linux)
On Friday, 26 June 2015 at 13:36:49 UTC, freeman wrote:
This works (socat):
connect(3, {sa_family=AF_FILE,
path=@"/var/run/ptmd.socket"}, 23) = 0
This does not (from deneme, modified):
connect(3, {sa_family=AF_FILE,
path=@"/var/run/ptmd.socket"}, 24) = -1 ECONNREFUSED
(Connection refused)
Looks like contrary to other sockets, name of an abstract socket
is treated as byte array instead of a string, hence every byte
counts.
Re: Abstract sockets (linux)
On Thursday, 25 June 2015 at 15:56:06 UTC, freeman wrote:
I am having trouble using abstract sockets on Linux.
Here is sample python code that works, which works:
ptm_sockname = "\0/var/run/ptmd.socket"
sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
sock.connect(ptm_sockname)
sock.setblocking(1)
sock.sendall('get-status detail')
Similar code in D, which does not work:
string socket_name = "\0/var/run/ptmd.socket";
auto address = new UnixAddress(socket_name);
auto sock = new Socket(AddressFamily.UNIX,
SocketType.STREAM);
scope(exit) sock.close();
sock.blocking = true;
sock.connect(address);
sock.send("get-status detail");
This is the equivalent with socat, which works:
$ echo "get-status detail" | socat -
ABSTRACT-CLIENT:/var/run/ptmd.socket
My test D program exits on connect:
std.socket.SocketOSException@runtime/phobos/std/socket.d(2674):
Unable to connect socket: Connection refused
Any pointers?
OK, I believe I've figured it out. The strace output I posted
was the clue I needed to see what was going on. The length of
abstract sockets are seemingly improperly calculated.
In socket.d, I modified the constructor for UnixAddress as such:
this(in char[] path)
{
//len =
cast(socklen_t)(sockaddr_un.init.sun_path.offsetof + path.length
+ 1);
len =
cast(socklen_t)(sockaddr_un.init.sun_path.offsetof + path.length);
writefln("inside UnixSocket, len is %s", len);
sun = cast(sockaddr_un*) (new ubyte[len]).ptr;
sun.sun_family = AF_UNIX;
sun.sun_path.ptr[0..path.length] = (cast(byte[])
path)[];
sun.sun_path.ptr[path.length] = 0;
}
This also explains why Ali's client/server code works with
itself, but it doesn't work with my test case.
This seems to be a bug in socket.d. If the first character of
the path is a null character, do not add 1 to the length. I
don't have much socket programming experience, but my test code
does work now.
My full test.d code follows, which now works as expected. I
compiled it with » ldc2 test.d std2/socket.d std2/socketstream.d.
The only modifications to socketstream.d was the module name and
std.socket import.
import std.stdio;
import std2.socket;
import std.stream;
import std2.socketstream;
void main() {
enum string socket_name = "\0/var/run/ptmd.socket";
auto address = new UnixAddress(socket_name);
writefln("path is --%s--", address.path);
writefln("length of string is --%s--",
socket_name.length);
writefln("length of address is --%s--", address.nameLen);
auto sock = new Socket(AddressFamily.UNIX,
SocketType.STREAM);
scope(exit) sock.close();
sock.blocking = true;
sock.connect(address);
writeln("connected!");
Stream streamer = new SocketStream(sock);
scope(exit) streamer.close();
streamer.writeLine("get-status detail");
while(true) {
auto line = streamer.readLine();
if (line.length == 0 || line == "EOF") {
break;
}
writeln(line);
}
}
Is this worthy of a bug report? Not a lot of people use abstract
sockets, but this was certainly frustrating for my use case :)
Help the old man learn D
On Wednesday, 24 June 2015 at 16:21:47 UTC, weaselcat wrote: On Wednesday, 24 June 2015 at 07:52:10 UTC, Charles Hawkins wrote: On Wednesday, 24 June 2015 at 06:54:57 UTC, weaselcat wrote: On Tuesday, 23 June 2015 at 06:50:28 UTC, Charles Hawkins wrote: [...] you can instruct dub to use other compilers with the --compiler option valid options include dmd,ldc,gdc,gdmd,ldmd [...] Is there a quick way to get gdc to recognize std.experimental.logger? I'm already spoiled by it. Choosing between it and a backtrace is difficult. I believe it's available as a dub package albeit outdated, should be roughly similar though. Thanks. I've changed to thread topic to "Help the old man learn D". :) logger package allows those statements to compile with gdc although I'm now getting lots of errors saying "undefined identifier format" even though I'm importing std.format, but not all of them are being flagged. Once I get it to where those are the only errors, perhaps I can figure it out. I'm converting one of my OCaml programs and I have a class (call it Dispatcher) that uses callbacks. With OCaml, it didn't matter if the callbacks were functions or methods but apparently D makes a distinction, which I can understand. I guess this is an opinion question, but should I duplicate Dispatcher's register functions and data structures to handle both, or do I define global functions that call the called-back methods (there's only one instance of the called-back class) and pass those to Dispatcher? Or is there a better way?
Re: Help the old man learn D
On Friday, 26 June 2015 at 14:39:05 UTC, Charles Hawkins wrote: Thanks. I've changed to thread topic to "Help the old man learn D". :) logger package allows those statements to compile with gdc although I'm now getting lots of errors saying "undefined identifier format" even though I'm importing std.format, I believe the `format` method used to be in `std.string` a few releases ago, try importing that one.
Re: Help the old man learn D
On Friday, 26 June 2015 at 14:52:51 UTC, Marc Schütz wrote: On Friday, 26 June 2015 at 14:39:05 UTC, Charles Hawkins wrote: Thanks. I've changed to thread topic to "Help the old man learn D". :) logger package allows those statements to compile with gdc although I'm now getting lots of errors saying "undefined identifier format" even though I'm importing std.format, I believe the `format` method used to be in `std.string` a few releases ago, try importing that one. Thank you! That explains why it wasn't flagging all of them since some of my modules import std.string as well. I think I've answered my own question regarding the callbacks as well. I realized that the only reason I made those sections of code classes in OCaml, even though there would only be one instance of them, was so I could do forward referencing. I'm hoping that I'll get function pointers instead of delegate pointers if I convert the class back to a module.
using new in shared library causes access violation
hi, I have a c++ program with a plugin system and i try to write a plugin for it. when the plugin is loaded by the program the extern (C) int OnInit() method is called. so far everything works fine. But as soon as i try to create a new class instance a segmentation fault occurs ( the constructor is empty ). Here is a screenshot with all the important code # error message in the left console # right top the executed code # right bottom the dub.json i use http://imgur.com/PfvsAm4 hopefully any1 can make sense of this error :/ thank you for helping
Re: using new in shared library causes access violation
Did you call Runtime.initialized in the D side of that initialization fucntion?
Re: using new in shared library causes access violation
On Friday, 26 June 2015 at 16:32:44 UTC, Adam D. Ruppe wrote: Did you call Runtime.initialized in the D side of that initialization fucntion? No i wasn't aware of that. Thank you so much Adam. I still don't know what it does exactly but i just call it when OnPluginInit() is called. Are you aware of any resources where i can read up on this? btw bought your D Cookbook, and like it alot :3 if any1 is looking for it http://dlang.org/phobos/core_runtime.html import core.runtime; then call Runtime.initialize();
Re: Help the old man learn D
On Friday, 26 June 2015 at 15:33:25 UTC, Charles Hawkins wrote: On Friday, 26 June 2015 at 14:52:51 UTC, Marc Schütz wrote: On Friday, 26 June 2015 at 14:39:05 UTC, Charles Hawkins wrote: [...] I think I've answered my own question regarding the callbacks as well. I realized that the only reason I made those sections of code classes in OCaml, even though there would only be one instance of them, was so I could do forward referencing. I'm hoping that I'll get function pointers instead of delegate pointers if I convert the class back to a module. Sorry for talking to myself, but I'm hoping someone will help me out. The above idea doesn't work. It appears that only the main program file is going to have function pointers while modules and classes will have delegates. So, does a library that uses callbacks need 2 callback register functions as well as parallel storage mechanisms, or is there a fairly simple way to make it polymorphic? I was hoping a newbie would be able to use this library, but not many newbies are going to understand this. I suppose I could tell them to call registerFunction and if they get a compiler error, then call registerDelegate? Or am I missing something?
Re: Help the old man learn D
On Friday, 26 June 2015 at 16:57:14 UTC, Charles Hawkins wrote: Sorry for talking to myself, but I'm hoping someone will help me out. The above idea doesn't work. It appears that only the main program file is going to have function pointers while modules and classes will have delegates. So, does a library that uses callbacks need 2 callback register functions as well as parallel storage mechanisms, or is there a fairly simple way to make it polymorphic? I was hoping a newbie would be able to use this library, but not many newbies are going to understand this. I suppose I could tell them to call registerFunction and if they get a compiler error, then call registerDelegate? Or am I missing something? I don't fully understand what you're doing, but functions can easily be turned into delegates using std.functional.toDelegate [1]: import std.functional : toDelegate; registerDelegate((&topLevelFunction).toDelegate); [1] http://dlang.org/phobos/std_functional.html#.toDelegate
Re: Abstract sockets (linux)
On 06/26/2015 07:39 AM, freeman wrote: > Is this worthy of a bug report? If it's a bug, yes. :) Ali
Why aren't Ranges Interfaces?
I have been learning D over the past three weeks and I came to the chapter in "Programming in D" on Ranges. And I am a little confused on the choice to make Ranges based on the methods you have in the struct, but not use a interface. With all of the isInputRange!R you have to write everywhere, it just seems like it would have made a lot more sense and made everyone's jobs easier if the different types of Ranges where just interfaces that you could inherit from. The only reason I can think of to not do it this way is the weird distinction between structs and classes in D.
Re: Why aren't Ranges Interfaces?
On Friday, 26 June 2015 at 18:37:51 UTC, Jack Stouffer wrote: The only reason I can think of to not do it this way is the weird distinction between structs and classes in D. If anything, C++ is the weird one in having two keywords that mean the same thing... But the reason comes down to three things: 1) They are! http://dlang.org/phobos/std_range_interfaces.html That works in some cases, but not all. They aren't typically used though because of the other reasons: 2) interfaces have an associated runtime cost, which ranges wanted to avoid. They come with hidden function pointers and if you actually use it through them, you can get a performance hit. In theory, the compiler could optimize that in some cases, making the interface syntax sugar for the isInputRange thing, but that still doesn't solve... 3) Ranges don't just meet an interface, they can also have other optional elements, like infiniteness or additional methods, that aren't expressible through inherited methods. Some of that could be solved by having many interfaces together, but not all of it. Infiniteness, for example, is seen by the fact that empty is a constant false rather than a method. Perhaps you could reengineer this too, but then the interfaces don't look as clean as they otherwise would. (Look at how many variants there are in that std.range.interfaces, and it still doesn't actually cover everything!) These two items together mean ranges typically don't fit the interface model well. If you're looking at a case where it is a good fit though, you can use the provided interfaces and wrappers.
Re: Why aren't Ranges Interfaces?
On Friday, 26 June 2015 at 18:37:51 UTC, Jack Stouffer wrote: I have been learning D over the past three weeks and I came to the chapter in "Programming in D" on Ranges. And I am a little confused on the choice to make Ranges based on the methods you have in the struct, but not use a interface. With all of the isInputRange!R you have to write everywhere, it just seems like it would have made a lot more sense and made everyone's jobs easier if the different types of Ranges where just interfaces that you could inherit from. The only reason I can think of to not do it this way is the weird distinction between structs and classes in D. They're essentially compile-time interfaces. I would prefer having a real name/binding implementation for this, like contract.
Re: Why aren't Ranges Interfaces?
Thanks for the reply! I understand the reasoning now. On Friday, 26 June 2015 at 18:46:03 UTC, Adam D. Ruppe wrote: 2) interfaces have an associated runtime cost, which ranges wanted to avoid. They come with hidden function pointers and if you actually use it through them, you can get a performance hit. How much of a performance hit are we talking about? Is the difference between using an interface and not using one noticeable?
Re: Why aren't Ranges Interfaces?
On Friday, 26 June 2015 at 19:26:57 UTC, Jack Stouffer wrote: Thanks for the reply! I understand the reasoning now. On Friday, 26 June 2015 at 18:46:03 UTC, Adam D. Ruppe wrote: 2) interfaces have an associated runtime cost, which ranges wanted to avoid. They come with hidden function pointers and if you actually use it through them, you can get a performance hit. How much of a performance hit are we talking about? Is the difference between using an interface and not using one noticeable? It can be in a tight loop. http://eli.thegreenplace.net/2013/12/05/the-cost-of-dynamic-virtual-calls-vs-static-crtp-dispatch-in-c this is for C++, but it applies directly to D. Interestingly, CRTP is a gigantic C++ hack that D gets for free with alias this.
Re: Why aren't Ranges Interfaces?
On Friday, 26 June 2015 at 19:26:57 UTC, Jack Stouffer wrote: How much of a performance hit are we talking about? Is the difference between using an interface and not using one noticeable? It can be huge difference if you take inlning in mind. LDC is capable of flattening most simple range-based pipelines into simple in-place loop during optimization - something you can't do with interfaces unless some sort of runtime profiling optimization is involved.
Re: Why aren't Ranges Interfaces?
On Fri, 26 Jun 2015 19:26:56 +, Jack Stouffer wrote: > Thanks for the reply! I understand the reasoning now. > > On Friday, 26 June 2015 at 18:46:03 UTC, Adam D. Ruppe wrote: >> 2) interfaces have an associated runtime cost, which ranges wanted to >> avoid. They come with hidden function pointers and if you actually use >> it through them, you can get a performance hit. > > How much of a performance hit are we talking about? Is the difference > between using an interface and not using one noticeable? For some real numbers, a while back I wrote up several variations on a "big data" type process for a presentation on memory performance and the importance of cache hits. The classic Java-style class-based version ran in 4 seconds while the lazy range struct version ran in 0.83 seconds. Using LDC to inline (impossible with interfaces) brought the runtime down to 0.38 seconds.
Re: Why aren't Ranges Interfaces?
On Friday, 26 June 2015 at 19:40:41 UTC, rsw0x wrote: On Friday, 26 June 2015 at 19:26:57 UTC, Jack Stouffer wrote: Thanks for the reply! I understand the reasoning now. On Friday, 26 June 2015 at 18:46:03 UTC, Adam D. Ruppe wrote: 2) interfaces have an associated runtime cost, which ranges wanted to avoid. They come with hidden function pointers and if you actually use it through them, you can get a performance hit. How much of a performance hit are we talking about? Is the difference between using an interface and not using one noticeable? It can be in a tight loop. http://eli.thegreenplace.net/2013/12/05/the-cost-of-dynamic-virtual-calls-vs-static-crtp-dispatch-in-c this is for C++, but it applies directly to D. Interestingly, CRTP is a gigantic C++ hack that D gets for free with alias this. In my code I need to use polymorphism. But, if I replace the code for my interface inheritance with an inherit of an class that implements empty methods and my methods just override the empty ones I get an essentially free performance boost 0_0? Good to know; thanks for the link.
Re: Typed Message Passing between D Processes
On Friday, 26 June 2015 at 11:13:11 UTC, Per Nordlöw wrote: On Friday, 26 June 2015 at 10:23:26 UTC, Laeeth Isharc wrote: On Friday, 26 June 2015 at 09:06:18 UTC, Per Nordlöw wrote: On Thursday, 25 June 2015 at 23:23:01 UTC, Laeeth Isharc wrote: not sure if this is quite what you are looking for, or if the performance overhead is acceptable but have you looked at msgpack to go on top of a lower level pipe ? Why is a lower-level pipe needed, when we have pipe in std.process? well, that is the sort of lower level pipe I was referring to. Ok, thanks. It should be easy enough to write so you can switch out the transport protocol. You could use something like nanomsg if you are prepared to use a beta product. I wrote some D bindings, but they are pretty raw and haven't been used much except for tiny applications. Fantastic if you feel like giving them a try and improving them. However if you don't like them you can just call nanomsg C api directly. But nanomsg itself is still early stage. http://nanomsg.org/index.html http://java.dzone.com/articles/look-nanomsg-and-scalability https://github.com/Laeeth/d-nanomsg
Re: function default parameters lost
On Thursday, 25 June 2015 at 14:17:13 UTC, Paul D Anderson wrote: On Thursday, 25 June 2015 at 07:10:57 UTC, tcak wrote: On Thursday, 25 June 2015 at 04:43:51 UTC, Paul D Anderson wrote: I'm trying to pass a function pointer while keeping the default parameter values intact. Given the following: [...] I filed a bug about 2-3 months ago about default parameters similar to yours. My guess is that it hasn't been fixed yet, and you have hit the same issue. Thanks Turns out this is expected behavior. Default parameter values are stripped from function pointers.
Re: Why aren't Ranges Interfaces?
On 06/26/2015 11:37 AM, Jack Stouffer wrote: > easier if the different types of Ranges where > just interfaces that you could inherit from. If you think you need polymorphic interfaces, the next chapter talks about inputRangeObject(): http://ddili.org/ders/d.en/ranges_more.html#ix_ranges_more.polymorphism,%20run-time Ali
Re: Typed Message Passing between D Processes
On Friday, 26 June 2015 at 12:31:04 UTC, Dicebot wrote: std.concurrency was supposed to be able to handle that by design but it is impossible to do without any sort of standard serialization utility in Phobos (and, ideally, very fast binary serialization utility) I'd have to benchmark it against something, but I'm pretty sure cerealed is fast.
how do I create an array of objects as member of class?
Imaginary code:
class Foo { }
class Baa {
Foo a = new Foo();
Foo b = new Foo();
Foo[] l = [a,b];
}
What should I use instead of to it work? Array!Foo(a,b) didn't
worked either.
I know this works:
class Baa {
Foo a = new Foo();
Foo b = new Foo();
Foo[] l;
this() {
l = [a,b];
}
But I'd like to initializa it at declaration time
Static constructors guaranteed to run?
Are static constructors guaranteed to run if the module is imported? Also are static constructors in templated types guaranteed to run for every instantiation? Even if the instantiation is never actually used outside of compile time code, like in an alias or in a UDA?
Re: how do I create an array of objects as member of class?
On Friday, 26 June 2015 at 21:50:30 UTC, Assembly wrote:
class Baa {
Foo a = new Foo();
Foo b = new Foo();
Foo[] l = [a,b];
Keep in mind that those instances are *static* and probably not
what you expect; modifying a will be seen across all instances of
Baa unless you actually assign it to a new member.
I know this works:
Doing it in the constructor is really the best way.
string to time conversion (when string contains time but no date)
is there a way to convert a string representing a time (without date) to a time, eg: auto t = "19:03:40.143656"; auto a=SysTime.fromTimeString(t); // doesn't exist My current workaround is to append a dummy date before and then calling SysTime.fromSimpleString. Is there a better way? seems needed
Re: Help the old man learn D
On Friday, 26 June 2015 at 17:11:54 UTC, Marc Schütz wrote: On Friday, 26 June 2015 at 16:57:14 UTC, Charles Hawkins wrote: [...] I don't fully understand what you're doing, but functions can easily be turned into delegates using std.functional.toDelegate [1]: import std.functional : toDelegate; registerDelegate((&topLevelFunction).toDelegate); [1] http://dlang.org/phobos/std_functional.html#.toDelegate Thanks, Marc. That should work if my brute force duplicate code doesn't. Thanks to everyone, at long last my project compiles with dmd. It crashes right away, but that's not unexpected since I haven't used pointers in several years. Unfortunately, compiling with gdc spits out a bunch of errors regarding getopt so I'm back to sprinkling log statements to find the problem.
