Re: Why is string.front dchar?
On 01/23/2014 02:39 AM, Jakob Ovrum wrote: On Thursday, 23 January 2014 at 01:17:19 UTC, Timon Gehr wrote: On 01/16/2014 06:56 AM, Jakob Ovrum wrote: Note that the Unicode definition of an unqualified character is the translation of a code *point*, which is very different from a *glyph*, which is what people generally associate the word character with. Thus, `string` is not an array of characters (i.e. an array where each element is a character), but `dstring` can be said to be. A character can be made of more than one dchar. (There are also more exotic examples, eg. IIRC there are cases where three dchars make approximately two characters.) No, I believe you are thinking of graphemes. Sure. Their existence means it is in general wrong to think of a dchar as one character.
Ddoc
I have looked at http://dlang.org/ddoc.html and http://qznc.github.io/d-tut/documentation.html and have some idea about how to write the text that will eventually become the document. But I have no clue as to go from the input file with Ddoc comments to the final document. I am on Windows 7, 64 bit; I have not installed anything related to the D Programming Language yet. I usually develop in C/C++ and my present interest is in commenting C/C++ code with Ddoc comments and ending up with the documentation. So what do I need to install and where can I find an example of generating documentation for a hello world program?
Re: Ddoc
On Thursday, 23 January 2014 at 13:57:43 UTC, sg wrote: I have looked at http://dlang.org/ddoc.html and http://qznc.github.io/d-tut/documentation.html and have some idea about how to write the text that will eventually become the document. But I have no clue as to go from the input file with Ddoc comments to the final document. I am on Windows 7, 64 bit; I have not installed anything related to the D Programming Language yet. I usually develop in C/C++ and my present interest is in commenting C/C++ code with Ddoc comments and ending up with the documentation. So what do I need to install and where can I find an example of generating documentation for a hello world program? Ddoc itself is provided as part of the D compiler. For usage with D source code. There is no form of preprocessor to my knowledge that you could utilise. Its too heavily tied into D's frontend to be usable from other languages. At this point I don't think you can get the power of Ddoc without using D itself.
TLF = thread local functions
So, TLS solves the data issue with threading. I just thought,
with out much thinking, what about having thread local functions?
Doesn't make sense? Let me explain.
Functions generally are not thread safe because of reentry,
right? The same data is used by the function for each thread
calling it and sense threads could effectively call a function
while the same function is being executed by another thread, the
data is correct.
To solve this, why not parameterize functions based on threads.
Essentially:
void funcThread1(...) { ... }
void funcThread2(...) { exactly the same code as above }
funcThread1 is only ever called on thread 1 and funcThread2 is
only ever called on thread 2. There is no issues of threading as
these functions are essentially thread local.
We can also combine them into one function:
// set stack based on threadidx before call. (for n threads there
are n stacks for this function)
void funcThread(...) { ... }
in this case, the compiler can simply set the stack based on the
thread id.
Should this not solve issues with functions in threading in a
similar way that TLS works? (it's just making the stack thread
local and functions are just code and data, the data part being
the issue)
While suck code might not work in all scenarios(such as in
general parallelization) it would make code for threading much
simpler to write(no locks) in many cases. As far as I can see,
the only real issue is that the stack is not thread local for
functions and hence acts as a global variable for functions,
which is the problem?
Is this possible?
Re: TLF = thread local functions
On Thursday, 23 January 2014 at 14:44:01 UTC, Frustrated wrote: Functions generally are not thread safe because of reentry, right? No. They are not thread safe because they use shared data (explicitly/implicitly). Functions that only use thread-local data are always thread-safe.
Re: Ddoc
On Thursday, 23 January 2014 at 14:25:41 UTC, Rikki Cattermole wrote: On Thursday, 23 January 2014 at 13:57:43 UTC, sg wrote: Ddoc itself is provided as part of the D compiler. For usage with D source code. Following is from http://dlang.org/ddoc.html Using Ddoc for other Documentation Ddoc is primarily designed for use in producing documentation from embedded comments. It can also, however, be used for processing other general documentation. The reason for doing this would be to take advantage of the macro capability of Ddoc and the D code syntax highlighting capability. If the .d source file starts with the string Ddoc then it is treated as general purpose documentation, not as a D code source file. ... Much of the D documentation itself is generated this way, including this page. Such documentation is marked at the bottom as being generated by Ddoc.
getting Key:Value pairs of an enum at compile time ?
Hello,
I have an Enum to represent possible Options for a selectList
e.g
enum options {
blueish=Blue,
redish =Red
}
and I want the List-Entrys to say
blueish or redish.
the value send to the app should be
Blue or Red.
I can use __traits(allMembers,Enum)
for the identifiers, but how do I get the Values ?
Re: getting Key:Value pairs of an enum at compile time ?
On Thursday, 23 January 2014 at 15:07:18 UTC, Uplink_Coder wrote:
Hello,
I have an Enum to represent possible Options for a selectList
e.g
enum options {
blueish=Blue,
redish =Red
}
and I want the List-Entrys to say
blueish or redish.
the value send to the app should be
Blue or Red.
I can use __traits(allMembers,Enum)
for the identifiers, but how do I get the Values ?
import std.stdio;
enum Options {
blueish=Blue,
redish =Red
}
void main() {
foreach(m; __traits(allMembers, Options)) {
writeln(m);
writeln(cast(string)__traits(getMember, Options, m));
}
}
The cast forces it to grab the value. Note where Options values
are of type string. Its the same as explicitly saying enum T :
string {.
Re: Ddoc
On Thursday, 23 January 2014 at 15:00:17 UTC, sg wrote: On Thursday, 23 January 2014 at 14:25:41 UTC, Rikki Cattermole wrote: On Thursday, 23 January 2014 at 13:57:43 UTC, sg wrote: Ddoc itself is provided as part of the D compiler. For usage with D source code. Following is from http://dlang.org/ddoc.html Using Ddoc for other Documentation Ddoc is primarily designed for use in producing documentation from embedded comments. It can also, however, be used for processing other general documentation. The reason for doing this would be to take advantage of the macro capability of Ddoc and the D code syntax highlighting capability. If the .d source file starts with the string Ddoc then it is treated as general purpose documentation, not as a D code source file. ... Much of the D documentation itself is generated this way, including this page. Such documentation is marked at the bottom as being generated by Ddoc. Yes, but it requires the source file to have the extension of d as listed in the quote you gave. It may be possible to rig it to do what you want. But you'll loose all the niceness e.g. function parameter grabbing. This may be a good use case for an enhancement to the front end, to provide what you want.
Re: getting Key:Value pairs of an enum at compile time ?
On 2014-01-23 16:07, Uplink_Coder wrote:
Hello,
I have an Enum to represent possible Options for a selectList
e.g
enum options {
blueish=Blue,
redish =Red
}
and I want the List-Entrys to say
blueish or redish.
the value send to the app should be
Blue or Red.
I can use __traits(allMembers,Enum)
for the identifiers, but how do I get the Values ?
Try getMember: http://dlang.org/traits.html#getMember
--
/Jacob Carlborg
User defined types: Problems with ref
Here's what I'm trying to do.
struct Element(T) {
T x;
T y;
public void setX(T value) {
x = value;
}
// More fancy functions ...
}
I store Element(s) in an array and want to pass each one by
reference, which does not work.
class Tree {
Element!string[] elements;
public ref auto createElement(string name) {
elements ~= Element!string(name);
return elements[$-1];
}
}
in main:
auto tag = Element!string(first);
The elements in Tree.elements and the ones in main are not the
same, instead I obtain a copy of each.
How can I make them refer to the same Elements? If I have to add
a .ptr property to Element, how do I do that? Is that possible at
all or did I shoot myself in the foot with the template?
Re: User defined types: Problems with ref
On Thursday, 23 January 2014 at 15:24:19 UTC, Chris wrote:
Here's what I'm trying to do.
struct Element(T) {
T x;
T y;
public void setX(T value) {
x = value;
}
// More fancy functions ...
}
I store Element(s) in an array and want to pass each one by
reference, which does not work.
class Tree {
Element!string[] elements;
public ref auto createElement(string name) {
elements ~= Element!string(name);
return elements[$-1];
}
}
in main:
auto tag = Element!string(first);
The elements in Tree.elements and the ones in main are not the
same, instead I obtain a copy of each.
How can I make them refer to the same Elements? If I have to
add a .ptr property to Element, how do I do that? Is that
possible at all or did I shoot myself in the foot with the
template?
Sorry in main it is:
auto tree = new Tree();
auto tag = tree.createElement(first);
Re: getting Key:Value pairs of an enum at compile time ?
Try getMember: http://dlang.org/traits.html#getMember if i try it, I get __aggr2297 cannot be read at compile time
Re: User defined types: Problems with ref
On Thursday, 23 January 2014 at 15:24:19 UTC, Chris wrote:
Here's what I'm trying to do.
struct Element(T) {
T x;
T y;
public void setX(T value) {
x = value;
}
// More fancy functions ...
}
I store Element(s) in an array and want to pass each one by
reference, which does not work.
class Tree {
Element!string[] elements;
public ref auto createElement(string name) {
elements ~= Element!string(name);
return elements[$-1];
}
}
in main:
auto tag = Element!string(first);
The elements in Tree.elements and the ones in main are not the
same, instead I obtain a copy of each.
How can I make them refer to the same Elements? If I have to
add a .ptr property to Element, how do I do that? Is that
possible at all or did I shoot myself in the foot with the
template?
You can use pointer
Tree tree = new Tree();
Element!(string)* element = tree.createElement(first);
is to get address of returned value element.
You also can rewrite your function like this:
public Element!(string)* createElement(string name) {
elements ~= Element!string(name);
return elements[$-1];
}
to return pointer without need to get address on caller side.
Best way of handling a receive()d message with a class instance.
Suppose that I receive a message, but instead of defining a
function inside the receive() block, I want to call a member of a
class instance. (This is useful to me for several reasons). Right
now my code looks like:
class Handler {
auto handle() {
return (string msg) {
writeln(received: , msg, count: , i);
}; // this ';' ends the return statement
} // handle()
private:
i;
}
//somewhere inside main
auto handler = new Handler;
receiveTimeout( dur!seconds(1),
handler.handle
);
It works, but I must say I'm not even sure about what the hell I
am doing :D
If I got it correctly, I'm calling a function that returns a
delegate, which is used by the receiveTimeout() somehow to
dispatch the message (and everything is in some way decided at
compile time, I believe).
Does this ugly piece of code make any sense? Should I rework it?
Re: User defined types: Problems with ref
On Thursday, 23 January 2014 at 15:34:38 UTC, FreeSlave wrote:
On Thursday, 23 January 2014 at 15:24:19 UTC, Chris wrote:
Here's what I'm trying to do.
struct Element(T) {
T x;
T y;
public void setX(T value) {
x = value;
}
// More fancy functions ...
}
I store Element(s) in an array and want to pass each one by
reference, which does not work.
class Tree {
Element!string[] elements;
public ref auto createElement(string name) {
elements ~= Element!string(name);
return elements[$-1];
}
}
in main:
auto tag = Element!string(first);
The elements in Tree.elements and the ones in main are not the
same, instead I obtain a copy of each.
How can I make them refer to the same Elements? If I have to
add a .ptr property to Element, how do I do that? Is that
possible at all or did I shoot myself in the foot with the
template?
You can use pointer
Tree tree = new Tree();
Element!(string)* element = tree.createElement(first);
is to get address of returned value element.
You also can rewrite your function like this:
public Element!(string)* createElement(string name) {
elements ~= Element!string(name);
return elements[$-1];
}
to return pointer without need to get address on caller side.
Thanks, that was fast! Yes I was tinkering around with pointers,
but didn't get it right, you did. However, the output is still
the same, i.e. two different sets:
// After creating and changing
div id=1
Hello, world!
span
/span
/div
// The Elements in Tree.elements:
[div
/div
, span
/span
]
Re: Best way of handling a receive()d message with a class instance.
Sorry, MY BAD! You can just write auto handler = new Handler; receive(handler.MyFunc); Somehow when I tried this before it failed to compile, and I thought I had to go through loops for achieving this.
Re: TLF = thread local functions
On Thursday, 23 January 2014 at 14:49:11 UTC, Dicebot wrote: On Thursday, 23 January 2014 at 14:44:01 UTC, Frustrated wrote: Functions generally are not thread safe because of reentry, right? No. They are not thread safe because they use shared data (explicitly/implicitly). Functions that only use thread-local data are always thread-safe. Um, duh, but in d data is already TLS. The point is that making the **STACK** TLS too should a way around having to use synchronization. Precisely because the STACK is not TLS makes functions not thread safe(since data is already safe in d). A strongly pure thread local function would never have any threading issues what so ever. Hence, no synchronization would be required and they would be very fast(just an extra instruction or two to fix up the stack if the thread id can be quickly known).
Compare type with another at CT
I am trying to compare a type with another type at compile time.
My code is
class Q(T)
{
static auto foo()
{
static if (T is A)
{
...
}
static assert(0, error);
}
}
and get the error cannot interpret A at compile time on the
static if line.
A is an interface.
I simply want to determine if a type is derived from another type
at compile time.
Re: Compare type with another at CT
On Thursday, 23 January 2014 at 16:21:39 UTC, Frustrated wrote:
static if (T is A)
Try:
static if(is(T : A)) {}
The is() thingy is different than the is operator. T:A means T
implicitly converts to A, so if T is a class implementing
interface A, that would pass.
There's also is(T == A) if you want a more specific check, as
well as IIRC 5 other forms of the is() thing which get weirder
but all do a specific task.
Re: getting Key:Value pairs of an enum at compile time ?
On Thursday, 23 January 2014 at 15:31:53 UTC, Uplink_Coder wrote:
Try getMember: http://dlang.org/traits.html#getMember
if i try it, I get __aggr2297 cannot be read at compile time
There's a convenience wrapper for that, EnumMembers:
http://dlang.org/phobos/std_traits.html#.EnumMembers
void main() {
foreach(m; EnumMembers!Options) {
writeln(m, , cast(string)m);
}
}
Re: TLF = thread local functions
On Thursday, 23 January 2014 at 16:15:46 UTC, Frustrated wrote: On Thursday, 23 January 2014 at 14:49:11 UTC, Dicebot wrote: On Thursday, 23 January 2014 at 14:44:01 UTC, Frustrated wrote: Precisely because the STACK is not TLS makes functions not thread safe(since data is already safe in d). Well, with a nasty hack you sort of can make a copy of stack for a delegate, but even then: pointers and references live on the stack too, yet they are aliases.
Re: Compare type with another at CT
Yes, I that is what I tried initially but the error was due to
that static if.
Not sure why
but
static if (is(T : A))
{
...
}
static assert(0, error);
doesn't work as the assert is called no matter what. Initially I
forgot to return the value after changing the code but that
doesn't matter.
Had to change it to
static if (is(T : A))
{
...
return ...;
} else
static assert(0, error);
return null;
I guess because return is not static in some sense.
Re: TLF = thread local functions
On Thursday, 23 January 2014 at 16:15:46 UTC, Frustrated wrote: The point is that making the **STACK** TLS too should a way around having to use synchronization. Precisely because the STACK is not TLS makes functions not thread safe(since data is already safe in d). Maybe you could elaborate a bit on where you see the problem here? The claim that stack memory is not thread-local contradicts commonly used terminology, since the execution stack is intrinsically part of a single thread. In fact, from a user-space perspective a context switch is little more than just switching out the CPU registers, including the stack pointer, for a different set. David
Re: Compare type with another at CT
On Thursday, 23 January 2014 at 16:40:49 UTC, Frustrated wrote:
Yes, I that is what I tried initially but the error was due to
that static if.
Not sure why
but
static if (is(T : A))
{
...
}
static assert(0, error);
doesn't work as the assert is called no matter what. Initially I
forgot to return the value after changing the code but that
doesn't matter.
As it should be. That static assert gets compiled
unconditionally, thus asserts.
Had to change it to
static if (is(T : A))
{
...
return ...;
} else
static assert(0, error);
return null;
I guess because return is not static in some sense.
else is the correct thing to do here. Otherwise you could have
put a runtime assert(0) there, i.e.:
static if (is(T : A))
{
return All is good;
}
assert(0, This should never happen!);
Re: getting Key:Value pairs of an enum at compile time ?
On Thursday, 23 January 2014 at 17:15:41 UTC, Uplink_Coder wrote:
void main() {
foreach(m; EnumMembers!Options) {
writeln(m, , cast(string)m);
}
}
Still not there at compile-time
... because I need to index my members
Could you show an exact code that fails?
Re: getting Key:Value pairs of an enum at compile time ?
void main() {
foreach(m; EnumMembers!Options) {
writeln(m, , cast(string)m);
}
}
Still not there at compile-time
... because I need to index my members
Re: getting Key:Value pairs of an enum at compile time ?
On Thursday, 23 January 2014 at 15:07:18 UTC, Uplink_Coder wrote:
Hello,
I have an Enum to represent possible Options for a selectList
e.g
enum options {
blueish=Blue,
redish =Red
}
and I want the List-Entrys to say
blueish or redish.
the value send to the app should be
Blue or Red.
I can use __traits(allMembers,Enum)
for the identifiers, but how do I get the Values ?
import std.traits;
import std.range;
import std.conv;
enum Nums
{
one,
two,
three,
four,
five,
}
void main()
{
//For a range of tuples
auto kvRange = zip([EnumMembers!Nums],
[EnumMembers!Nums]
.to!(OriginalType!Nums[]))
//For an associative array
import std.array;
auto aa = kvRange.assocArray();
}
Re: Best way of handling a receive()d message with a class instance.
On Thursday, 23 January 2014 at 16:00:30 UTC, Francesco Cattoglio wrote: Sorry, MY BAD! You can just write auto handler = new Handler; receive(handler.MyFunc); Somehow when I tried this before it failed to compile, and I thought I had to go through loops for achieving this. It's also useful to mention that in this code here: auto handler = new Handler; receiveTimeout( dur!seconds(1), handler.handle ); The expressions handler.handle is actually invoking the method handle(). This is due to parentheses being optional in D, which means that even the function name without the parentheses is a valid function call. I don't know if you knew that or not, just in case you didn't.
Re: getting Key:Value pairs of an enum at compile time ?
Could you show an exact code that fails?
sure!
auto EnumToSelect(Enum)(string Name = __traits(identifier,Enum))
if (is(Enum==enum)) {
foreach (i,Item;[__traits(allMembers,Enum)]) {
else
form_string ~= \toption(value='~Item~')
~__traits(getMember,Enum,Item)~\n;
}
debug import std.stdio;
debug writeln(form_string);
return form_string;
}
Re: getting Key:Value pairs of an enum at compile time ?
Oh my bad
wasn't too carefull with deletion
auto EnumToSelect(Enum)(string Name = __traits(identifier,Enum))
if (is(Enum==enum)) {
foreach (i,Item;[__traits(allMembers,Enum)]) {
reslt ~= \toption(value='~__traits(getMember,Enum,Item)~')
~Item~\n;
}
debug import std.stdio;
debug writeln(form_string);
return reslt;
}
Re: Shared objects aka dynamic libraries
On Tuesday, 21 January 2014 at 17:53:38 UTC, Russel Winder wrote: I'll have to get my wife's Windows 7 machine out to test all the D tool changes I am making. It is a real shame that anyone actually uses Windows for anything :-) It's linux users, who use linux. Windows users don't use windows for anything, they use software running on windows, lol.
Re: Shared objects aka dynamic libraries
On Thursday, 23 January 2014 at 19:40:42 UTC, Kagamin wrote: On Tuesday, 21 January 2014 at 17:53:38 UTC, Russel Winder It's linux users, who use linux. Windows users don't use windows for anything, they use software running on windows, lol. It awesome how this statement can be read as both linux flaw and merit depending on who reads it :)
can't I use __traits(allMembers) recursivly ?
When I try to
struct _pod_ {
string s1;
enum e1 { v1,v2 };
}
auto printPod(Pod)() if (__traits(isPOD,Pod)) {
string result;
foreach (member;__traits(allMembers,Pod) ) {
auto _member=__traits(getMember,Pod,member);
}
writeln(result);
}
void main() {printPod!(_pod_);}
I get
Error: need 'this' for 's1' of type 'string'
Error: type e1 has no value
Re: can't I use __traits(allMembers) recursivly ?
On Thursday, 23 January 2014 at 23:42:26 UTC, Uplink_Coder wrote:
When I try to
struct _pod_ {
string s1;
enum e1 { v1,v2 };
}
auto printPod(Pod)() if (__traits(isPOD,Pod)) {
string result;
foreach (member;__traits(allMembers,Pod) ) {
auto _member=__traits(getMember,Pod,member);
}
writeln(result);
}
void main() {printPod!(_pod_);}
I get
Error: need 'this' for 's1' of type 'string'
Error: type e1 has no value
__traits(getMember, Pod, member) is the same as Pod.member. In
your case Pod is _pod_, so in the end you are trying to access an
non-static member via the struct type. That cannot work and the
error message tells you exactly that in errorspeak.
Since you are never appending to result your code has some more
flaws and I'm not sure what you are trying to do? Do you try to
mirror std.conv.to!string?
Re: User defined types: Problems with ref
On Thursday, 23 January 2014 at 15:24:19 UTC, Chris wrote: Thanks, that was fast! Yes I was tinkering around with pointers, but didn't get it right, you did. However, the output is still the same, i.e. two different sets: // After creating and changing div id=1 Hello, world! span /span /div // The Elements in Tree.elements: [div /div , span /span ] Maybe more code will explain more. Note that array requires data to be continuous, so if there are no space for new element, it reallocates the whole chunk and therefore invalidates old pointers. Use linked list or replace struct with class.
Re: User defined types: Problems with ref
Anyway, why do you need pointers to elements?
Re: User defined types: Problems with ref
On 01/23/2014 07:26 AM, Chris wrote:
On Thursday, 23 January 2014 at 15:24:19 UTC, Chris wrote:
Here's what I'm trying to do.
struct Element(T) {
T x;
T y;
public void setX(T value) {
x = value;
}
// More fancy functions ...
}
I store Element(s) in an array and want to pass each one by reference,
which does not work.
class Tree {
Element!string[] elements;
public ref auto createElement(string name) {
elements ~= Element!string(name);
return elements[$-1];
}
}
in main:
auto tag = Element!string(first);
The elements in Tree.elements and the ones in main are not the same,
instead I obtain a copy of each.
How can I make them refer to the same Elements? If I have to add a
.ptr property to Element, how do I do that? Is that possible at all or
did I shoot myself in the foot with the template?
Sorry in main it is:
auto tree = new Tree();
auto tag = tree.createElement(first);
createElement does return a reference. However, because D does not have
local references the type of tag is Element!string (not 'ref
Element!string').
The following program demonstrates that the address of the returned
reference is indeed the same as the one that has been created:
import std.stdio;
struct Element(T) {
T x;
T y;
public void setX(T value) {
x = value;
}
// More fancy functions ...
}
class Tree {
Element!string[] elements;
public ref auto createElement(string name) {
elements ~= Element!string(name);
writefln( created element at %s, elements[$-1]);
return elements[$-1];
}
}
void main()
{
auto tree = new Tree();
writefln(received element at %s, tree.createElement(first));
}
Sample output:
created element at 7F14C72C0F80
received element at 7F14C72C0F80
You can use the returned element directly as well:
tree.createElement(second).setX(hello);
Ali
Re: Shared objects aka dynamic libraries
On Tuesday, 21 January 2014 at 14:19:51 UTC, Russel Winder wrote: I appear to be unable to use Google the last couple of days :-( so I admit defeat, expose my current ignorance, hopefully to quickly become enlightened. Is it possible to easily with DMD, LDC and/or GDC create shared objects aka dynamic libraries from a D code base? Currently for me DMD and LDC refuse to accept the existence of a -shared flag, and GDC always fails with some deeply incomprehensible messages about not finding _tls.* functions. There should be a page better than http://dlang.org/dll-linux.html I'm making a game engine using shared objects as scripts, take a look at https://github.com/ICGCC/Breaker-Engine You should also check out my fork, which is a little more recent. Point in case, look at src/breaker/util/core.d and you'll see what you need to do. Oh, than and shared objects only REALLY work with DMD and linux atm, windows is dodgy, and I've tested it.
Re: TLF = thread local functions
Am 23.01.2014 15:44, schrieb Frustrated: So, TLS solves the data issue with threading. I just thought, with out much thinking, what about having thread local functions? Doesn't make sense? Let me explain. Functions generally are not thread safe because of reentry, right? The same data is used by the function for each thread calling it and sense threads could effectively call a function while the same function is being executed by another thread, the data is correct. no - the parameters and local vars of the function are in the stack of the thread - so there is no problem with them, only shared variables can have a need to synchronization your idea tries to solve non existing problems?
Re: can't I use __traits(allMembers) recursivly ?
I'm trying to serialize my struct through CT-Refelction
Re: can't I use __traits(allMembers) recursivly ?
On 2014-01-24 07:11, Uplink_Coder wrote: I'm trying to serialize my struct through CT-Refelction Here's a serialization library if you need it [1]. It will hopefully be included as std.serialization in Phobos at some point. https://github.com/jacob-carlborg/orange -- /Jacob Carlborg
