Re: Is std.xml seriously broken, or is it me?
On Sunday, 30 July 2017 at 03:16:35 UTC, Mike wrote:
On Sunday, 30 July 2017 at 02:58:09 UTC, Mike wrote:
[...]
It appears `onStartTag` does not handle the root element. For
example, this code seems to work:
import std.xml;
import std.stdio;
void main()
{
auto parser = new DocumentParser("encoding=\"utf-8\"?>");
parser.onStartTag["peripheral"] = (ElementParser parser)
{
writeln("peripheral");
};
parser.parse();
}
Mike
You may want to try the experimental candidate for Phobos
instead, which was developed as a GSoC project but never finished:
http://code.dlang.org/packages/std-experimental-xml
Re: Struct Postblit Void Initialization
On Sunday, 30 July 2017 at 19:22:07 UTC, Jiyan wrote:
Hey,
just wanted to know whether something like this would be
possible sowmehow:
struct S
{
int m;
int n;
this(this)
{
m = void;
n = n;
}
}
So not the whole struct is moved everytime f.e. a function is
called, but only n has to be "filled"
I'll assume you mean copying (as per the title) not moving
(because moving doesn't make sense to me in this context); use a
dedicated method:
struct S
{
int m, n;
S sparseDup()
{
S obj;
obj.n = n;
return obj;
}
}
Re: Struct Postblit Void Initialization
On Sunday, 30 July 2017 at 19:32:48 UTC, Eugene Wissner wrote:
On Sunday, 30 July 2017 at 19:22:07 UTC, Jiyan wrote:
Hey,
just wanted to know whether something like this would be
possible sowmehow:
struct S
{
int m;
int n;
this(this)
{
m = void;
n = n;
}
}
So not the whole struct is moved everytime f.e. a function is
called, but only n has to be "filled"
this(this) is called after the struct is copied. Doing
something in the postblit constructor is too late. The second
thing is that the struct is copied with memcpy. What you
propose would require 2 memcpy calls to copy the first part of
the struct and then the second part. Besides it is difficult to
implement, it may reduce the performance of the copying since
memcpy is optimized to copy memory chunks.
Ok thank you :)
Re: Struct Postblit Void Initialization
On Sunday, 30 July 2017 at 19:22:07 UTC, Jiyan wrote:
Hey,
just wanted to know whether something like this would be
possible sowmehow:
struct S
{
int m;
int n;
this(this)
{
m = void;
n = n;
}
}
So not the whole struct is moved everytime f.e. a function is
called, but only n has to be "filled"
this(this) is called after the struct is copied. Doing something
in the postblit constructor is too late. The second thing is that
the struct is copied with memcpy. What you propose would require
2 memcpy calls to copy the first part of the struct and then the
second part. Besides it is difficult to implement, it may reduce
the performance of the copying since memcpy is optimized to copy
memory chunks.
Struct Postblit Void Initialization
Hey,
just wanted to know whether something like this would be possible
sowmehow:
struct S
{
int m;
int n;
this(this)
{
m = void;
n = n;
}
}
So not the whole struct is moved everytime f.e. a function is
called, but only n has to be "filled"
Re: D move semantics
On Sunday, 30 July 2017 at 16:12:41 UTC, piotrekg2 wrote:
What is the idiomatic D code equivalent to this c++ code?
There's no direct equivalent of all your code to D using only
druntime+phobos AFAIK.
class Block
{
[...]
};
Since you don't seem to be using reference type semantics or
polymorphism this should be mapped to a struct, such as
---
import std.experimental.allocator;
import std.experimental.allocator.mallocator;
struct Block
{
public:
static Block create()
{
Block obj;
obj.data_ = Mallocator.instance.makeArray!char(4096);
return obj;
}
~this() nothrow
{
if (data_ !is null) {
Mallocator.instance.dispose(data_);
data_ = null;
}
}
@disable this(this); // Forbid copying
private:
char[] data_;
}
---
// What is the equivalent of std::vector, the closest thing I
could find is
// std.container.array
std::vector blocks;
for (int i = 0; i < 100; ++i) {
// NOTE: blocks are moved when relocation happens
// because of move-ctor and move-assign-operator marked
noexcept
blocks.emplace_back();
}
That's the closest one in Phobos AFAIK. There are custom
container implementations out there such as the emsi containers
[1]. If you use one of them, the above should be as simple as
---
Array!Block blocks;
foreach (i; 0..100)
{
blocks ~= Block.create();
}
---
I've added your example as a unittest to my own dynamic array
implementation, should you wish to have a look [2].
A little bit of background:
Classes are reference types, structs are value types i.e there's
no copy/move mechanics for classes w.r.t. your code. The one for
structs is roughly like this: Whenever the compiler sees a struct
object `obj` being assigned a new value `other`, it will run the
destructor for `obj` (should one exist), then copy `other` over
`obj`, followed by calling the postblit constructor `this(this) {
... }` (should it exist) on `obj`.
In some instances (such as return from function, or first
assignment in constructor, i.e. initialization) the compiler may
automatically optimize the copy to a move.
Assuming the compiler tries to do a copy, it will only work if
`typeof(obj)` is copyable (doesn't have the postblit disabled via
`@disable this(this)`), if it isn't, the compiler will error out;
you can force a move by using `std.algorithm : move`. There's
also `std.algorithm : moveEmplace` in case you don't wish the
target to be destroyed.
[1] https://github.com/economicmodeling/containers
[2]
https://github.com/Calrama/libds/blob/83211c5d7cb866a942dc9dd8ba1c622573611ccd/src/ds/dynamicarray.d#L351
Re: Convert ResultSet to List of Associted Array
On Sunday, 30 July 2017 at 16:39:05 UTC, Jshah wrote: Hi I am new to D writing a web service with vibe. My webservice connect to mysql and return the result as JSON. How do I convert resultset to Array of Associated Array [["col1" : value, "col2" : value], ] I am using mysql-native
Convert ResultSet to List of Associted Array
Hi I am new to D writing a web service with vibe. My webservice connect to mysql and return the result as JSON. How do I convert resultset to Array of Associated Array [["col1" : value, "col2" : value], ]
D move semantics
What is the idiomatic D code equivalent to this c++ code?
class Block
{
public:
Block()
: data_(new char[4096])
{}
...
// NOTE: both members marked noexcept
Block(Block &) noexcept = default;
Block& operator=(Block &) noexcept = default;
...
private:
std::unique_ptr data_;
};
// What is the equivalent of std::vector, the closest thing I
could find is
// std.container.array
std::vector blocks;
for (int i = 0; i < 100; ++i) {
// NOTE: blocks are moved when relocation happens
// because of move-ctor and move-assign-operator marked noexcept
blocks.emplace_back();
}
Re: Static array * scalar is not working for me
On Sunday, 30 July 2017 at 08:18:07 UTC, Danni Coy wrote: The following code is not working for me float[3] f; f[] = abs(f)[] * -1.0f; where abs is a function that returns a float[3]; it complains that f should be attached to some memory. Is it a bug or am I missing something? This is unimplemented currently and no one cares about it. You can do: f[] = abs(f)[]; f[] *= -1;
Re: GC
On Sunday, 30 July 2017 at 09:12:53 UTC, piotrekg2 wrote: I would like to learn more about GC in D. [...] It would be great if you could point me out to articles on this subject. The primary locations to get information are the language specification [1] and the druntime documentation [2]. I also suggest reading the excellent GC series on the official language blog [3]. Additionally, in this [5] - despite being mostly about the Go GC - gives a good overview of garbage collection in general. [1] https://dlang.org/spec/garbage.html [2] https://dlang.org/phobos/core_memory.html [3] https://dlang.org/blog/the-gc-series/ [4] http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html [5] https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e?gi=78635e05a6ac#.6zz5an77a
Re: GC
On Sunday, 30 July 2017 at 09:12:53 UTC, piotrekg2 wrote: I would like to learn more about GC in D. For example can anyone explain why do we need memset(0) here: https://github.com/dlang/phobos/blob/master/std/container/array.d#L356 , doesn't it assume a certain type of GC? What if there is a need to change the GC algorithm in the future? The current GC is a conservative one, which means that it has at best an incomplete knowledge of the types in the memory it scans. Therefore, whenever it sees a value that, when interpreted as a pointer, points to a pool of memory owned by the GC, it needs to assume that it is indeed a pointer, which means it has to keep the referenced object alive. A false pointer is one that only looks like a valid pointer but is in reality some other kind of data, or in this case data in a block of memory that's still allocated, but no longer actually in use. False pointers can keep GC-managed objects alive that could actually be freed, so they're something that should be avoided. The container overwrites the memory with zeroes because a zero value is never a valid pointer. Changing the GC algorithm would do no harm here. The best we could hope for is that the GC at some pointer becomes fully precise (unlikely), so it can distinguish false from real pointers by itself. In this case, the memset would become unnecessary, but it wouldn't lead to wrong behaviour.
Re: Static array * scalar is not working for me
On Sunday, 30 July 2017 at 08:18:07 UTC, Danni Coy wrote: The following code is not working for me float[3] f; f[] = abs(f)[] * -1.0f; where abs is a function that returns a float[3]; it complains that f should be attached to some memory. Is it a bug or am I missing something? I cannot reproduce the error with the code you've given. It's either missing some import, or a definition of `abs()`. The one in std.math doesn't accept arrays at all.
Re: GC
On 30/07/2017 10:12 AM, piotrekg2 wrote: I would like to learn more about GC in D. For example can anyone explain why do we need memset(0) here: https://github.com/dlang/phobos/blob/master/std/container/array.d#L356 , doesn't it assume a certain type of GC? What if there is a need to change the GC algorithm in the future? It would be great if you could point me out to articles on this subject. Basically instead of having possibly random data in the array, it forces it to be all 0. What its protecting against is false pointers and stopping the GC seeing a reference to a block of memory that doesn't exist. It's just general protection against GC's thinking that memory is alive when it isn't. More of a problem for 32bit than 64bit. Hasn't got much to do with the algorithm :)
GC
I would like to learn more about GC in D. For example can anyone explain why do we need memset(0) here: https://github.com/dlang/phobos/blob/master/std/container/array.d#L356 , doesn't it assume a certain type of GC? What if there is a need to change the GC algorithm in the future? It would be great if you could point me out to articles on this subject.
Static array * scalar is not working for me
The following code is not working for me float[3] f; f[] = abs(f)[] * -1.0f; where abs is a function that returns a float[3]; it complains that f should be attached to some memory. Is it a bug or am I missing something?
Re: Questions about dmd source
Francis Nixon wrote: I have two completely unrelated questions about the dmd source code. 1. What does the mtype.Type.dotExp method do? The documentation comment says that it "Accesses the members of the object e". I'm not sure exactly why I would want to do that? Is it for handling types specified using an identifier/template chain (aka foo.bar!(uint).c)? types has some built-in properties, like `.length`, `.sizeof`, `.init` and so on. this method is used to access those properties. 2. I've noticed there are some rather long methods in the dmd source, involving more than one goto; parse.d is particularly bad. Is there a reason for this/is it being fixed? it just was done this way. dmd parser was "evolved", so what you see is a result of evolution (it is not stopeed yet ;-), and evolution doesn't produce ideal results. there is no need to specifically "fix" working things, it doesn't do any good.
Re: Questions about dmd source
On Sunday, 30 July 2017 at 06:18:16 UTC, Francis Nixon wrote: I have two completely unrelated questions about the dmd source code. 2. I've noticed there are some rather long methods in the dmd source, involving more than one goto; parse.d is particularly bad. Is there a reason for this/is it being fixed? It is impossible to write short parser, and goto operators are quite useful in such code. Also, there is no need to rewrite anything unless it is slow or buggy, and parse.d probably isn't.
