What does assigning void mean?
In Adam Ruppe's D Cookbook there're these lines in a ref counting example: RefCountedObject o = void; // What does this mean/do? o.data = new Implementation(); o.data.refcount = 1; I don't understand the first line; could someone explain please?
Converting Lua source to D
I am making an attempt convert Lua to D. This is less about the conversion and more about exploring the tooling to make it happen. I have chosen to do this file by file and attempting to start with linint. I wanted to make use of dpp, however I hit a segmentation fault and reduced dependency. https://github.com/JesseKPhillips/lua/blob/dpp/init/linit.d I wasn't able to get a core dump for debugging. Anyone willing to give some advice or solution? I have gone through a number of compilers and better. I have implemented a build pipeline but didn't incorporate the D portion at this time.
Re: Nice readable code with initializer
On Thursday, 5 March 2020 at 06:48:53 UTC, Виталий Фадеев wrote:
Searching for beauty code implementation.
Goal is: Create new object with "custom initializer".
"custom initializer" - is function, executed in _ctor, in
object scope.
Main Goal is: "clean readable beauty code".
Like this and better:
class DataGrid : Base
{
this()
{
super();
CR!VBoxLayout({
sizeWidthMode = SIZE_MODE.PARENT;
sizeHeightMode = SIZE_MODE.PARENT;
CR!GridLayout({
id = "grid";
sizeWidthMode = SIZE_MODE.PARENT;
sizeHeightMode = SIZE_MODE.FIXED;
h = 400;
});
CR!HCenterLayout({
CR!(Pager!TextButton) ({
id = "pager";
});
});
});
}
}
class Base
{
T CR( T, F )( F func )
{
auto c = new T();
c.Apply( func );
return c;
}
void Apply( F )( F func )
{
func();
}
}
In code above created tree and configured nodes.
Trouble in code above is: "custom initializer" - executed in
DataGrid context.
How to execute "custom initializer" in VBoxLayout context and
keep readable beauty ?
Conceptual question.
How to implement next pseudo-code in D ?
VBoxLayout
sizeWidthMode = SIZE_MODE.PARENT
sizeHeightMode = SIZE_MODE.PARENT
GridLayout
id = "grid"
sizeWidthMode = SIZE_MODE.PARENT
sizeHeightMode = SIZE_MODE.FIXED
h = 400
HCenterLayout
Pager!TextButton
id = "pager"
Nice readable code with initializer
Searching for beauty code implementation.
Goal is: Create new object with "custom initializer".
"custom initializer" - is function, executed in _ctor, in object
scope.
Main Goal is: "clean readable beauty code".
Like this and better:
class DataGrid : Base
{
this()
{
super();
CR!VBoxLayout({
sizeWidthMode = SIZE_MODE.PARENT;
sizeHeightMode = SIZE_MODE.PARENT;
CR!GridLayout({
id = "grid";
sizeWidthMode = SIZE_MODE.PARENT;
sizeHeightMode = SIZE_MODE.FIXED;
h = 400;
});
CR!HCenterLayout({
CR!(Pager!TextButton) ({
id = "pager";
});
});
});
}
}
class Base
{
T CR( T, F )( F func )
{
auto c = new T();
c.Apply( func );
return c;
}
void Apply( F )( F func )
{
func();
}
}
In code above created tree and configured nodes.
Trouble in code above is: "custom initializer" - executed in
DataGrid context.
How to execute "custom initializer" in VBoxLayout context and
keep readable beauty ?
Re: spawn a function with object as arg?
On Wednesday, 4 March 2020 at 23:37:00 UTC, Martin Brezel wrote:
The documentation for spawn() states: "all arguments to fn must
either be shared or immutable or have no pointer indirection."
The easiest thing to do is to just cast
import std.concurrency;
import std.socket;
void main() {
auto s = new Socket();
spawn((shared Socket s_) {
Socket s = cast() s_;
}, cast(shared) s);
}
Note the shared argument to the function... then cast AWAY shared
inside that function, and cast TO shared when passing the
argument.
That basically just tricks the compiler. But if you aren't going
to actually use the socket from the original thread anymore, it
should be perfectly fine to do.
(if you do actually share it across threads, using it from
both... it would actually probably still be fine - the Socket
class is a thin wrapper around OS functions that work with
threads. But then you re on your own, the compiler won't help get
it right at all. Abandoning the old one isn't really getting
compiler help either but it is so easy to do that you prolly
won't make a mistake.)
You can also not use `spawn` and instead give `new Thread` a try
from core.thread. That's totally DIY, the compiler won't even try
to help you, but it can be simpler if you know what you're doing
and don't need to pass a lot of
spawn a function with object as arg?
I want to create a Client, which receives and handles received
data in background while the Client can send via the same socket.
My first idea was something like this:
class Client {
private Socket socket;
private Tid receiverTid;
this(Socket socket) {
this.socket = socket;
this.receiverTid = spawn( &receiver, this.socket );
}
void command(Command[] cmd) {
this.socket.send(cmd.makeMessage());
}
}
void receiver(Socket socket) {
/*..*/
}
..how naive of me :)
The compiler says: "Error: static assert: "Aliases to mutable
thread-local data not allowed."
The documentation for spawn() states: "all arguments to fn must
either be shared or immutable or have no pointer indirection."
So, now i am thinking about to create a instance of Socket inside
the spawned worker and do send and receive via Message Passing
between Client and the worker.
But, is there another way?
I am writing lot of golang lately and i am sure something like
`go receive(&socket)` would be valid. Now, i am wondering if
there is a similar simple way to do it in dlang.
Re: Safely wrapping an uncopyable struct to implement an interface
On 3/4/20 9:04 AM, aliak wrote:
On Wednesday, 4 March 2020 at 12:03:48 UTC, Gregor Mückl wrote:
Hi!
I've just created a situation in my code that is summarized by the
following example. I don't know how to solve it with @safe code.
A third party library provides a struct that is not copyable:
// provided by third party
struct Foo {
@disable this() @safe;
@disable this(ref return scope Foo other) @safe;
void magic() @safe;
}
What I want to do is to provide a safe wrapper around it that adapts
to another interface:
// intended common interface
interface IWrapper {
void bar() @safe;
}
Now, the obvious way to wrap this fails:
class FooWrapper : IWrapper {
Foo f;
this(Foo f) @safe {
this.f = f; // this fails because it would be a copy
}
override void bar() @safe
{
f.magic();
}
}
If Foo were a class, f would be a reference and everything would be
fine. But f is a struct that can't be copied and taking a pointer to f
makes FooWrapper obviously unsafe. How could I solve this?
I've come up with a workaround for my actual use case that doesn't
need to use the uncopyable struct this way. But I'm curious if I'm
missing something regarding references to structs.
You can use move maybe? :
https://dlang.org/library/std/algorithm/mutation/move.html
So
this.f = f.move;
In addition, you must call the constructor with either an rvalue or your
own move call.
In other words, you need to do new FooWrapper(f.move);
Alternatively, you can take the parameter via ref, but that might not be
what you wish for.
In general, when you use non-copyable structs, you will need to use move.
But you should be aware that it could cause problems when f has pointers
to its internals. I.e. if Foo had a pointer to it's own member then the
value of of that pointer to me "copied" over to this.f, but the address
of the member in this.f is different that the original f's member address.
In general, you should not worry about this as it's highly unusual in D,
and it's generally accepted that one can always move structs without
issues (the compiler can do this without you asking it to).
However, in practice it does happen, sometimes not intentionally. I
think there's a function somewhere that checks to see if a type is
pointing at itself, but can't find it right now.
-Steve
Re: Safely wrapping an uncopyable struct to implement an interface
On Wednesday, 4 March 2020 at 12:03:48 UTC, Gregor Mückl wrote:
Hi!
I've just created a situation in my code that is summarized by
the following example. I don't know how to solve it with @safe
code.
A third party library provides a struct that is not copyable:
// provided by third party
struct Foo {
@disable this() @safe;
@disable this(ref return scope Foo other) @safe;
void magic() @safe;
}
What I want to do is to provide a safe wrapper around it that
adapts to another interface:
// intended common interface
interface IWrapper {
void bar() @safe;
}
Now, the obvious way to wrap this fails:
class FooWrapper : IWrapper {
Foo f;
this(Foo f) @safe {
this.f = f; // this fails because it would be a copy
}
override void bar() @safe
{
f.magic();
}
}
If Foo were a class, f would be a reference and everything
would be fine. But f is a struct that can't be copied and
taking a pointer to f makes FooWrapper obviously unsafe. How
could I solve this?
I've come up with a workaround for my actual use case that
doesn't need to use the uncopyable struct this way. But I'm
curious if I'm missing something regarding references to
structs.
You can use move maybe? :
https://dlang.org/library/std/algorithm/mutation/move.html
So
this.f = f.move;
But you should be aware that it could cause problems when f has
pointers to its internals. I.e. if Foo had a pointer to it's own
member then the value of of that pointer to me "copied" over to
this.f, but the address of the member in this.f is different that
the original f's member address.
Re: Improving dot product for standard multidimensional D arrays
On 01.03.20 21:58, p.shkadzko wrote:
**
Matrix!T matrixDotProduct(T)(Matrix!T m1, Matrix!T m2)
in
{
assert(m1.rows == m2.cols);
This asserts that the result is a square matrix. I think you want
`m1.cols==m2.rows` instead.
}
do
{
Matrix!T m3 = Matrix!T(m1.rows, m2.cols);
for (int i; i < m1.rows; ++i)
{
for (int j; j < m2.cols; ++j)
{
for (int k; k < m2.rows; ++k)
{
m3.data[toIdx(m3, i, j)] += m1[i, k] * m2[k, j];
}
}
}
return m3;
}
**
...
I can see that accessing the appropriate array member in Matrix.data is
costly due to toIdx operation but, I can hardly explain why it gets so
much costly. Maybe there is a better way to do it after all?
Changing the order of the second and third loop probably goes a pretty
long way in terms of cache efficiency:
Matrix!T matrixDotProduct(T)(Matrix!T m1,Matrix!T m2)in{
assert(m1.cols==m2.rows);
}do{
int m=m1.rows,n=m1.cols,p=m2.cols;
Matrix!T m3=Matrix!T(m,p);
foreach(i;0..m) foreach(j;0..n) foreach(k;0..p)
m3.data[i*p+k]+=m1.data[i*n+j]*m2.data[j*p+k];
return m3;
}
(untested.)
Safely wrapping an uncopyable struct to implement an interface
Hi!
I've just created a situation in my code that is summarized by
the following example. I don't know how to solve it with @safe
code.
A third party library provides a struct that is not copyable:
// provided by third party
struct Foo {
@disable this() @safe;
@disable this(ref return scope Foo other) @safe;
void magic() @safe;
}
What I want to do is to provide a safe wrapper around it that
adapts to another interface:
// intended common interface
interface IWrapper {
void bar() @safe;
}
Now, the obvious way to wrap this fails:
class FooWrapper : IWrapper {
Foo f;
this(Foo f) @safe {
this.f = f; // this fails because it would be a copy
}
override void bar() @safe
{
f.magic();
}
}
If Foo were a class, f would be a reference and everything would
be fine. But f is a struct that can't be copied and taking a
pointer to f makes FooWrapper obviously unsafe. How could I solve
this?
I've come up with a workaround for my actual use case that
doesn't need to use the uncopyable struct this way. But I'm
curious if I'm missing something regarding references to structs.
