On 8/22/17 12:15 PM, Kagamin wrote:
https://issues.dlang.org/show_bug.cgi?id=6585 is this fixed too? How
various opIndex will behave now?
Seems to work. I closed as a duplicate.
-Steve
https://issues.dlang.org/show_bug.cgi?id=6585 is this fixed too?
How various opIndex will behave now?
On 8/16/17 11:23 AM, Steven Schveighoffer wrote:
On 8/16/17 8:58 AM, Steven Schveighoffer wrote:
However, I have found a better way to call postblit that involves the
qualifiers than the way Variant currently does it. I'm going to submit
a PR to fix these issues.
On Monday, 21 August 2017 at 02:17:57 UTC, crimaniak wrote:
...
shared A a;
...
Sorry, accidental delete, read this as shared A a = new
shared(A);
On Monday, 14 August 2017 at 03:59:48 UTC, Jonathan M Davis wrote:
And no, this isn't ideal, but the only semi-decent solution
that's been proposed that safely casts away shared for you is
synchronized classes, which Andrei describes in TDPL but have
never been implemented.
After reading
On Thursday, 17 August 2017 at 13:09:29 UTC, Kagamin wrote:
On Wednesday, 16 August 2017 at 23:15:10 UTC, crimaniak wrote:
I wonder if it possible and usable to make some template to
support this pattern, where we give mutex(es), shared
object(s) and delegate to operate with objects as
On 8/17/17 8:41 AM, Kagamin wrote:
On Wednesday, 16 August 2017 at 13:14:55 UTC, Steven Schveighoffer wrote:
But that isn't a concern for Variant. It is only calling the postblit,
which does work.
Shouldn't it call destructor when it goes out of scope?
You're right, and it does. It uses the
On Wednesday, 16 August 2017 at 23:15:10 UTC, crimaniak wrote:
I wonder if it possible and usable to make some template to
support this pattern, where we give mutex(es), shared object(s)
and delegate to operate with objects as non-shared.
https://dpaste.dzfl.pl/8b3b05c8ec0a like this? Not
On Wednesday, 16 August 2017 at 13:14:55 UTC, Steven
Schveighoffer wrote:
But that isn't a concern for Variant. It is only calling the
postblit, which does work.
Shouldn't it call destructor when it goes out of scope?
On Monday, 14 August 2017 at 03:59:48 UTC, Jonathan M Davis wrote:
The way to handle shared is to protect the section of code
that's using the shared object with either a mutex or
synchronized block, and then you cast away shared from the
object within that section and operate on it as
On Tuesday, 15 August 2017 at 21:54:23 UTC, Steven Schveighoffer
wrote:
On 8/15/17 5:27 PM, Arek wrote:
On Tuesday, 15 August 2017 at 10:37:08 UTC, Kagamin wrote:
Well, no wrapper is actually needed here:
[...]
The issue is that send cannot handle shared value types due to
a bug in the
On 8/16/17 8:58 AM, Steven Schveighoffer wrote:
However, I have found a better way to call postblit that involves the
qualifiers than the way Variant currently does it. I'm going to submit a
PR to fix these issues.
https://github.com/dlang/phobos/pull/5694
-Steve
On 8/16/17 9:04 AM, Kagamin wrote:
On Wednesday, 16 August 2017 at 12:58:25 UTC, Steven Schveighoffer wrote:
Use cases don't matter. What matters is: is it proper for Variant to
call the postblit (as it does currently) without regard for the
qualifiers?
Looks like it isn't,
On Wednesday, 16 August 2017 at 12:58:25 UTC, Steven
Schveighoffer wrote:
Use cases don't matter. What matters is: is it proper for
Variant to call the postblit (as it does currently) without
regard for the qualifiers?
Looks like it isn't, https://dpaste.dzfl.pl/183e6dae9867 - shared
On 8/16/17 6:23 AM, Kagamin wrote:
On Tuesday, 15 August 2017 at 15:19:02 UTC, Steven Schveighoffer wrote:
However, I'm not sure about the postblit being called afterward. Does
a postblit need to be marked shared in order to work for shared types?
Ideally yes, but it's difficult to come up
On Tuesday, 15 August 2017 at 15:19:02 UTC, Steven Schveighoffer
wrote:
However, I'm not sure about the postblit being called
afterward. Does a postblit need to be marked shared in order to
work for shared types?
Ideally yes, but it's difficult to come up with a good shared
postblit, send
On Tuesday, 15 August 2017 at 21:27:49 UTC, Arek wrote:
Yes, but this doesn't compile:
import std.stdio;
import std.concurrency;
struct A
{
int t;
int r;
int method() shared
{
return 0;
}
}
void consumer()
{
shared a =
On 8/15/17 5:27 PM, Arek wrote:
On Tuesday, 15 August 2017 at 10:37:08 UTC, Kagamin wrote:
Well, no wrapper is actually needed here:
class A
{
int method() shared;
}
void consumer()
{
shared a = receiveOnly!(shared A)();
}
void producer()
{
auto cons = spawn();
send(cons, new
On Tuesday, 15 August 2017 at 10:37:08 UTC, Kagamin wrote:
Well, no wrapper is actually needed here:
class A
{
int method() shared;
}
void consumer()
{
shared a = receiveOnly!(shared A)();
}
void producer()
{
auto cons = spawn();
send(cons, new shared A());
}
On 8/15/17 10:42 AM, Kagamin wrote:
https://github.com/dlang/phobos/blob/master/std/variant.d#L623
memcpy(, cast(const(void*)) , rhs.sizeof);
should be ok to cast unconditionally
Agreed, the T value being copied has already been copied onto the stack,
so it's not really shared.
However,
https://github.com/dlang/phobos/blob/master/std/variant.d#L623
memcpy(, cast(const(void*)) , rhs.sizeof);
should be ok to cast unconditionally
On 8/14/17 5:27 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Monday, August 14, 2017 15:22:23 Steven Schveighoffer via Digitalmars-d-
learn wrote:
On 8/13/17 11:40 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Saturday, August 12, 2017 18:57:44 Arek via Digitalmars-d-learn
Well, no wrapper is actually needed here:
class A
{
int method() shared;
}
void consumer()
{
shared a = receiveOnly!(shared A)();
}
void producer()
{
auto cons = spawn();
send(cons, new shared A());
}
On Monday, 14 August 2017 at 22:22:58 UTC, Arek wrote:
I've found some simple workaround for this problem:
import std.stdio;
import std.concurrency;
struct Envelope(T) if (is(T == class)) // for simplicity of
this example, only classes
{
shared(T)[] obj;
this(shared T o)
On Monday, 14 August 2017 at 20:13:28 UTC, Arek wrote:
If I can ensure the uniqueness of the object, there is no need
to "share" it or synchronize the access.
You use manually managed multithreading, that's why you need
shared. And because compiler can't verify uniqueness, you are
requested
On Monday, 14 August 2017 at 21:27:48 UTC, Jonathan M Davis wrote:
On Monday, August 14, 2017 15:22:23 Steven Schveighoffer via
Digitalmars-d- learn wrote:
On 8/13/17 11:40 PM, Jonathan M Davis via Digitalmars-d-learn
wrote:
> On Saturday, August 12, 2017 18:57:44 Arek via
>
On Monday, August 14, 2017 15:22:23 Steven Schveighoffer via Digitalmars-d-
learn wrote:
> On 8/13/17 11:40 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
> > On Saturday, August 12, 2017 18:57:44 Arek via Digitalmars-d-learn
wrote:
> >> I have the folowing problem:
> >> I like to envelope
On Monday, 14 August 2017 at 19:22:23 UTC, Steven Schveighoffer
wrote:
On 8/13/17 11:40 PM, Jonathan M Davis via Digitalmars-d-learn
wrote:
On Saturday, August 12, 2017 18:57:44 Arek via
Digitalmars-d-learn wrote:
I have the folowing problem:
I like to envelope the class object in struct to
On Monday, 14 August 2017 at 03:59:48 UTC, Jonathan M Davis wrote:
On Sunday, August 13, 2017 16:40:03 crimaniak via
Digitalmars-d-learn wrote:
More of this, I think, you can't avoid __gshared for any
complex work. Even mutexes from Phobos doesn't support shared,
so I had to 'cowboy with
On 8/13/17 11:40 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Saturday, August 12, 2017 18:57:44 Arek via Digitalmars-d-learn wrote:
I have the folowing problem:
I like to envelope the class object in struct to control the
destruction moment and then send this object to another
On Monday, 14 August 2017 at 03:40:26 UTC, Jonathan M Davis wrote:
On Saturday, August 12, 2017 18:57:44 Arek via
Digitalmars-d-learn wrote:
I have the folowing problem:
I like to envelope the class object in struct to control the
destruction moment and then send this object to another
On Monday, 14 August 2017 at 03:59:48 UTC, Jonathan M Davis wrote:
[snip]
Now, the fact that the mutex objects don't handle shared
correctly is another issue entirely. Having to cast away shared
from mutexes is dumb, because you're obviously not going to be
protecting them with a mutex, and
On Sunday, August 13, 2017 16:40:03 crimaniak via Digitalmars-d-learn wrote:
> More of this, I think, you can't avoid __gshared for any complex
> work. Even mutexes from Phobos doesn't support shared, so I had
> to 'cowboy with __gshared' when implementing my site engine.
The way to handle shared
On Saturday, August 12, 2017 18:57:44 Arek via Digitalmars-d-learn wrote:
> I have the folowing problem:
> I like to envelope the class object in struct to control the
> destruction moment and then send this object to another
> thread/fiber (or task, cause I use vibe-d).
>
> I can't find any
On Sunday, 13 August 2017 at 11:35:05 UTC, Arek wrote:
Yeah, I've read this. But conurrency.send cannot pass immutable
object. The same story with Unique.
Sorry, read this as 'efficient immutable'.
More over, "shared" looks rather like unfinished concept.
Yes, exactly.
Anyway, _gshared
On Sunday, 13 August 2017 at 02:50:13 UTC, crimaniak wrote:
On Saturday, 12 August 2017 at 18:57:44 UTC, Arek wrote:
I have the folowing problem:
I like to envelope the class object in struct to control the
destruction moment and then send this object to another
thread/fiber (or task, cause I
On Saturday, 12 August 2017 at 18:57:44 UTC, Arek wrote:
I have the folowing problem:
I like to envelope the class object in struct to control the
destruction moment and then send this object to another
thread/fiber (or task, cause I use vibe-d).
I can't find any method to make it working.
37 matches
Mail list logo
