Re: Compiler bug?

[Daniel Kozak via Digitalmars-d-learn]

and some doc:
http://dlang.org/spec/function.html#function-inheritance

On Wed, Aug 16, 2017 at 7:45 AM, Daniel Kozak  wrote:

> No it is not a bug, there is no s() in B, you can fix this by adding:
>
> alias s = A.s;
>
> to class B
>
> On Wed, Aug 16, 2017 at 7:21 AM, apz28 via Digitalmars-d-learn <
> digitalmars-d-learn@puremagic.com> wrote:
>
>> abstract class A
>> {
>> string _s;
>>
>> @property:
>> final string s()
>> {
>> return _s;
>> }
>>
>> A s(string x)
>> {
>> _s = x;
>> return this;
>> }
>> }
>>
>> class B : A
>> {
>> @property:
>> final override A s(string x)
>> {
>> _s = x;
>> return this;
>> }
>> }
>>
>> void main()
>> {
>> B b = new B();
>> b.s = "abc";
>> assert(b.s == "abc");
>> }
>>
>> Compilation output
>> /d536/f408.d(32): Error: function f408.B.s (string x) is not callable
>> using argument types ()
>>
>
>

Re: Compiler bug?

[Daniel Kozak via Digitalmars-d-learn]

No it is not a bug, there is no s() in B, you can fix this by adding:

alias s = A.s;

to class B

On Wed, Aug 16, 2017 at 7:21 AM, apz28 via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:

> abstract class A
> {
> string _s;
>
> @property:
> final string s()
> {
> return _s;
> }
>
> A s(string x)
> {
> _s = x;
> return this;
> }
> }
>
> class B : A
> {
> @property:
> final override A s(string x)
> {
> _s = x;
> return this;
> }
> }
>
> void main()
> {
> B b = new B();
> b.s = "abc";
> assert(b.s == "abc");
> }
>
> Compilation output
> /d536/f408.d(32): Error: function f408.B.s (string x) is not callable
> using argument types ()
>

Re: How to fix wrong deprecation message - dmd-2.075.1

[Daniel Kozak via Digitalmars-d-learn]

You should open an issue on https://issues.dlang.org/

until it is fixed you can use lazy variation byChar, byWchar or byUTF:

void main()
{

import std.utf : byWchar;
import std.array : array;

wstring s = byWchar("abc").array;
}

On Wed, Aug 16, 2017 at 7:09 AM, apz28 via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:

> void main()
> {
> import std.utf : toUTF16; // Same problem with toUTF8
>
> wstring s = toUTF16!string("abc");
> }
>
> Compilation output:
> /d500/f513.d(3): Deprecation: function std.utf.toUTF16 is deprecated - To
> be removed November 2017. Please use std.utf.encode instead.
> /d500/f513.d(3): Deprecation: function std.utf.toUTF16 is deprecated - To
> be removed November 2017. Please use std.utf.encode instead.
>
>

Compiler bug?

[apz28 via Digitalmars-d-learn]

abstract class A
{
string _s;

@property:
final string s()
{
return _s;
}

A s(string x)
{
_s = x;
return this;
}
}

class B : A
{
@property:
final override A s(string x)
{
_s = x;
return this;
}
}

void main()
{
B b = new B();
b.s = "abc";
assert(b.s == "abc");
}

Compilation output
/d536/f408.d(32): Error: function f408.B.s (string x) is not 
callable using argument types ()

How to fix wrong deprecation message - dmd-2.075.1

[apz28 via Digitalmars-d-learn]

void main()
{
import std.utf : toUTF16; // Same problem with toUTF8

wstring s = toUTF16!string("abc");
}

Compilation output:
/d500/f513.d(3): Deprecation: function std.utf.toUTF16 is 
deprecated - To be removed November 2017. Please use 
std.utf.encode instead.
/d500/f513.d(3): Deprecation: function std.utf.toUTF16 is 
deprecated - To be removed November 2017. Please use 
std.utf.encode instead.

Re: SpaceD - a racing game written in D

[VanAnorld via Digitalmars-d-announce]

On Wednesday, 28 June 2017 at 07:41:30 UTC, Murzistor wrote:

On Tuesday, 21 March 2017 at 00:49:14 UTC, WebFreak001 wrote:
I just released my racing game I have been working on for the 
past few days for a linux game jam on itch.io[1].
OK, it can slow down, but I still cannot keep it within the 
bounds. It lacks of some maneuvering thrusters.

It is also very important for real spaceship.


Access violation 
https://drive.google.com/file/d/0B-Fhj3lTfwGdZGZLU21tNDk2UkU/view


I love racing game, this is so awesome. I love speed, though in 
the game I'm playing, controlling the speed is quite hard! ( I'm 
playing Carx Highway Racing 
http://appnaz.com/android/carx-highway-racing-com.CarXTech.highWay )

Re: Debugging Visual D using Visual D

[Johnson via Digitalmars-d-debugger]

	VisualD.dll	C:\Program Files 
(x86)\VisualD\Debug\VisualD.dll	N/A	Yes	Symbols 
loaded.	C:\Program Files 
(x86)\VisualD\Debug\VisualD.pdb	229	0.45.1-rc2	12/31/1969 7:00 
PM	13FB-143C*	[8972] devenv.exe		
	VisualD.dll	C:\Program Files 
(x86)\VisualD\VisualD.dll	N/A	Yes	Cannot find or open the PDB 
file.		271	0.45.1-rc2	12/31/1969 7:00 
PM	18D4-1904E000*	[8972] devenv.exe		



I was finally able to get it to work. Something is wonky. I think 
it's when I use a normal VS side by side with the experimental 
that the experimental can't find the symbols and somehow the 
registry changes I made got reset.


So far it is working(I can hit BP's) but it's still basically the 
same scenario in that I have to completely shut down VS in order 
to reload visualD. Before I could automate because the normal 
visual studio instance could stay open... but it seems like it 
screws up the debugging symbols and such.


I could try to use another, different exp instance(different 
registry) but I feel the same problem might occur.


But I guess it's better than nothing.

Re: Issues with std.format template function

[LeqxLeqx via Digitalmars-d-learn]

On Tuesday, 15 August 2017 at 05:22:44 UTC, HyperParrow wrote:

On Tuesday, 15 August 2017 at 04:44:25 UTC, LeqxLeqx wrote:

[...]


GDC front-end is based on DMD 2.068.2 but the feature you use 
(format specifier as template parameter) is only there since 
DMD 2.075. The error comes from the fact that you read the 
online documentation which is not valid for GDC.


with GDC you can only does unchecked fmt:

`auto s = format("%s is %s", "Pi", 3.14);`


Well that explains it. Thanks for the info

Re: WebCam or Video in D

[brian via Digitalmars-d-learn]

On Monday, 14 August 2017 at 13:19:30 UTC, Guillaume Piolat wrote:


It wouldn't be very hard to write a minimal OpenCV loader (for 
example based on DerelictUtil) with only the few functions you 
need in OpenCV.


Do you know of any simple examples that I could try mimic?
I've looked through some of the Derelict code before and it 
doesn't seem exceptionally straight-forward, but maybe I haven't 
spent enough time on it.

[Issue 17632] [REG 2.075-b1] opBinary and delegate code generation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17632

--- Comment #6 from briancsch...@gmail.com ---
I can confirm that this bug no longer happens in Emsi's code with 2.075.1.

--

Re: DLang quarterly EU?

[Atila Neves via Digitalmars-d]

On Sunday, 7 May 2017 at 16:37:02 UTC, Ethan Watson wrote:

On Sunday, 7 May 2017 at 11:32:53 UTC, Adam Wilson wrote:

On 5/7/17 12:57, Seb wrote:
+1 - maybe its worth considering to make it for two days 
(=one weekend)


That can work. It would be two or three days vacation 
depending on flight schedules.

...
Not to mention a cool way to see new cities if it moves around.


Yes, that was the intention on both counts. There's no point to 
flying somewhere just for the day. Especially since there will 
doubtless be Micro BeerConfs in the evening ;-)


Andrei suggested that Bucharest be the first city we hold this 
in. Sounds like a great plan to me.


We should probably organise this!

Atila

Re: An Issue I Wish To Raise Awareness On

[Atila Neves via Digitalmars-d]

On Monday, 14 August 2017 at 18:59:17 UTC, Arek wrote:

On Monday, 14 August 2017 at 16:49:22 UTC, Atila Neves wrote:

[...]

... /cut/...

[...]


I've tested this code on dmd 2.075.0 and it doesn't behave like 
postblit.


[...]


I'd have to double check, but this seems like a bug to me.

Atila

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[Steven Schveighoffer via Digitalmars-d-learn]

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 shared A());
}


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 = receiveOnly!(shared A)();
}

void main()
{
 auto cons = spawn();
 send(cons, shared A());
}


The issue is that send cannot handle shared value types due to a bug in 
the implementation. In essence, there is no reason to send a shared A -- 
it's an unrelated copy and not actually shared.


You can send a shared reference to an A just fine:

static shared A a;

send(tid, ); // works

You *should* be able to send a shared(A). There is no reason to disallow 
it. But again, it's not super useful.



This very simple code also doesn't compile:

shared struct S
{
 int i;

 ~this()
 {
 }
}

void main()
{
 shared s = shared S();
}

In general, shared structs with postblit and destructor make problems.


postblit should work.

It does look like destructors are a problem. It appears the compiler 
attempts to call the destructor while unshared.


-Steve

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[Arek via Digitalmars-d-learn]

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());
}


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 = receiveOnly!(shared A)();
}

void main()
{
auto cons = spawn();
send(cons, shared A());
}

This very simple code also doesn't compile:

shared struct S
{
int i;

~this()
{
}
}

void main()
{
shared s = shared S();
}

In general, shared structs with postblit and destructor make 
problems.


Arek

Re: Named multi-imports

[jmh530 via Digitalmars-d]

On Tuesday, 15 August 2017 at 20:33:18 UTC, Johnson wrote:


Or instead of a new language feature, the gtk-d guys could 
have package files ;)


But then that only helps with one specific instance. D is full 
of language features, I do not see why everyone is so against 
them. Without them, D would be empty, nothing, and no one would 
use it. Adding language features should be see as something 
good, cause without them, we wouldn't get anywhere.


In the past, I've thought it would be convenient to have 
something like


import io = std.stdio : writeln, write;

and allow someone to write

io.write("foo");
io.writeln("bar");

though I don't know if that causes any kinds of problems to 
implement.


That being said, the code you refer to above probably could be 
simplified quite a bit with mixins. I just did a simple version, 
but I imagine it could be extended. It also might be even easier 
to accomplish when static foreach is in the language, that would 
you can just loop through the LowLevels to accomplish it. Some 
kind of hierarchy to the HighLevels/MidLevels/LowLevels would 
also need to be established.


import std.meta : AliasSeq;

alias LowLevels = AliasSeq!("writeln", "write");

template GenImport(string TopLevel, string MidLevel, string 
LowLevel)

{
const char[] GenImport = "import " ~ TopLevel ~ "." ~ MidLevel
   ~ " : " ~ 
LowLevel ~ ";";

}

mixin(GenImport!("std", "stdio", LowLevels[0]));
mixin(GenImport!("std", "stdio", LowLevels[1]));

void main()
{
write("foo");
writeln("bar");
}

Re: C++17 Init statement for if/switch

[bachmeier via Digitalmars-d]

On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler wrote:

Without alot of usage, it will just be an esoteric construct 
that looks confusing to the average developer.


That is correct. After a while it gets tiring to see a 
neverending stream of complexity added to the language while 
things that would actually help (like IDE support) do not get any 
attention. As a general rule, if it's being added to C++, it's 
probably a bad idea.

Re: RFC: Implementation of binary assignment operators (e.g s.x += 2) for @property functions

[Johan Engelen via Digitalmars-d]

On Tuesday, 15 August 2017 at 03:53:44 UTC, Michael V. Franklin 
wrote:
An implementation of binary assignment operators for @property 
functions has been submitted to the DMD pull request queue at 
https://github.com/dlang/dmd/pull/7079.


[snip]

Walter has requested that I make this forum post to inform the 
community of this change in an effort to discuss its merits 
and/or shortcomings.


We ask for your comments whether they be in approval or 
disapproval of this pull request so we can determine the best 
way forward.


Thanks for the heads up. I think this would have been good for a 
DIP, to better guard against bad interplay with other D 
constructs.
I've added to the PRs a few comments that immediately came to 
mind.


It seems you already spent some time trying to break the new 
mechanics, that's good. But perhaps we need some more breakage 
;-)  (for example I think we can dig a little deeper down the 
opBinary hole)


-Johan

Re: Named multi-imports

[Johnson via Digitalmars-d]

On Tuesday, 15 August 2017 at 03:37:39 UTC, rikki cattermole 
wrote:

On 15/08/2017 2:59 AM, Johnson wrote:
Not only that, but it requires adding more files to the 
command line.


I currently have 3 import files to separate the gtk from gdk 
that and the only reason they exist is to combine them in to 
one named import ;/



Doesn't seem like much but that's 3 extra files that don't 
really need to exist.


Hopefully D already implements a way to do what I'm asking.


Or instead of a new language feature, the gtk-d guys could have 
package files ;)


But then that only helps with one specific instance. D is full of 
language features, I do not see why everyone is so against them. 
Without them, D would be empty, nothing, and no one would use it. 
Adding language features should be see as something good, cause 
without them, we wouldn't get anywhere.

Re: C++17 Init statement for if/switch

[Jonathan Marler via Digitalmars-d]

On Tuesday, 15 August 2017 at 20:17:40 UTC, ag0aep6g wrote:

On 08/15/2017 08:55 PM, Daniel Kozak wrote:

C++17 will have this feature:
https://tech.io/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/init-statement-for-ifswitch


What do you think about it, can we have something similar to 
that.

Maybe something like this:


int func() return 5;

with(auto x = func()) if (condition(x))
 do_something_with(x);
else
 do_something_else_with(x);


Previous discussion:
http://forum.dlang.org/post/vfjlpvpwuyfqoljvp...@forum.dlang.org

Andrei doesn't like the C++ way, but he seems to be ok with the 
`with` way:

http://forum.dlang.org/post/oktru0$159b$1...@digitalmars.com

Walter didn't comment.

I think this has a good chance of getting in, but someone will 
have to write a DIP and implement it.


I wouldn't mind writing a DIP but I haven't seen enough benefit 
to warrant the change yet.


I grep'd for 'if' statements in a couple phobos modules and 
didn't see too many places it could be used there.


The syntax does remind me of Andrei's scoped imports proposal:

with(import std.stdio : File) void foo(File file)
{
//...
}

I think if that proposal gets accepted it would be a natural 
extension to allow both imports and declarations inside a 'with' 
expression and it would get more exposure/usage among the greater 
community.  Without alot of usage, it will just be an esoteric 
construct that looks confusing to the average developer.  So I 
guess it depends on whether or not you think it would gain 
widespread adoption?

Re: C++17 Init statement for if/switch

[ag0aep6g via Digitalmars-d]

On 08/15/2017 08:55 PM, Daniel Kozak wrote:

C++17 will have this feature:
https://tech.io/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/init-statement-for-ifswitch 



What do you think about it, can we have something similar to that.
Maybe something like this:


int func() return 5;

with(auto x = func()) if (condition(x))
 do_something_with(x);
else
 do_something_else_with(x);


Previous discussion:
http://forum.dlang.org/post/vfjlpvpwuyfqoljvp...@forum.dlang.org

Andrei doesn't like the C++ way, but he seems to be ok with the `with` way:
http://forum.dlang.org/post/oktru0$159b$1...@digitalmars.com

Walter didn't comment.

I think this has a good chance of getting in, but someone will have to 
write a DIP and implement it.

Re: C++17 Init statement for if/switch

[Daniel Kozak via Digitalmars-d]

On Tuesday, 15 August 2017 at 19:24:00 UTC, Daniel Kozak wrote:


int func() { return 5; }

int func() return 5;

was a typo in all my previous posts :)

Re: C++17 Init statement for if/switch

[Daniel Kozak via Digitalmars-d]

On Tuesday, 15 August 2017 at 19:04:32 UTC, Daniel Kozak wrote:

On Tuesday, 15 August 2017 at 18:55:57 UTC, Daniel Kozak wrote:

C++17 will have this feature:
int func() return 5;

with(auto x = func()) if (condition(x))
do_something_with(x);
else
do_something_else_with(x);


this would be rewrite to

int func() return 5;

{
auto x = func();
if (condition(x))
do_something_with(x);
else
do_something_else_with(x);
}


int func() { return 5; }

Re: C++17 Init statement for if/switch

[Daniel Kozak via Digitalmars-d]

On Tuesday, 15 August 2017 at 18:55:57 UTC, Daniel Kozak wrote:

C++17 will have this feature:
https://tech.io/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/init-statement-for-ifswitch

What do you think about it, can we have something similar to 
that.

Maybe something like this:


int func() return 5;

with(auto x = func()) if (condition(x))
do_something_with(x);
else
do_something_else_with(x);


this would be rewrite to

int func() return 5;

{
auto x = func();
if (condition(x))
do_something_with(x);
else
do_something_else_with(x);
}

C++17 Init statement for if/switch

[Daniel Kozak via Digitalmars-d]

C++17 will have this feature:
https://tech.io/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/init-statement-for-ifswitch

What do you think about it, can we have something similar to that.
Maybe something like this:


int func() return 5;

with(auto x = func()) if (condition(x))
do_something_with(x);
else
do_something_else_with(x);

Re: Stefan Koch: New CTFE fix

[Johnson via Digitalmars-d]

I'm sorry, but you are obviously someone in *need* to prove 
something. No need to respond, ever.

Re: RFC: Implementation of binary assignment operators (e.g s.x += 2) for @property functions

[Jeremy DeHaan via Digitalmars-d]

On Tuesday, 15 August 2017 at 03:53:44 UTC, Michael V. Franklin 
wrote:
An implementation of binary assignment operators for @property 
functions has been submitted to the DMD pull request queue at 
https://github.com/dlang/dmd/pull/7079.  It addresses the 
following issues:


Issue 8006 - Implement proper in-place-modification for 
properties

https://issues.dlang.org/show_bug.cgi?id=8006
--
This is the primary issue motivating the pull request.  The 
pull request is only a partial resolution of this issue; it 
implements binary assignment operators (e.g. `s.x += 2`), but 
not unary assignment operators (e.g. `s.x++`).  The plan is to 
implement unary assignment operators in a separate pull request 
after the fate of the binary assignment operators pull request 
is decided.


I'm a huge fan of this, but then I am of the mindset that 
@property functions should act like variables much in the way 
that they do for C# properties.

[Issue 13262] Cannot send certain shared data to another thread

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13262

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--

[Issue 14893] std.concurrency: can't send shared arrays or shared structs

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14893

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[Steven Schveighoffer via Digitalmars-d-learn]

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, 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?


I think also I understand why it's working for shared int* but not 
shared int -- IFTI automatically infers tail-modified for such things to 
cut down on instantiations. tail-modified means the head is not shared 
(which is in this case more accurate). This means the cast is not 
necessary, since you are copying unqualified data.


-Steve

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[Kagamin via Digitalmars-d-learn]

https://github.com/dlang/phobos/blob/master/std/variant.d#L623
memcpy(, cast(const(void*)) , rhs.sizeof);

should be ok to cast unconditionally

Release D 2.075.1

[Martin Nowak via Digitalmars-d-announce]

Glad to announce D 2.075.1.

http://dlang.org/download.html

This point release fixes a few issues over 2.075.0, see the changelog
for more details.

http://dlang.org/changelog/2.075.1.html

-Martin

Re: How to specify a template that uses unqualified type, like any normal function

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/14/17 6:27 PM, Jonathan M Davis via Digitalmars-d-learn wrote:



As I understand it, sufficiently smart C++ compilers will figure out that
the code for two template instantiations can be the same even if the types
aren't, and they'll merge the definitions in the generated code, so you only
really get one.

This isn't that problem.

I can define a function foo(int), which accepts all forms of int, and 
then *inside the function* I can mutate the parameter.


If I define foo as taking a template parameter T, then the 
implementations that accept just a straight int can modify the local 
copy of the parameter, but implementations that take a const(int) 
cannot. This means your function can't be the same for multiple 
instantiations. But there's no true limitation -- const(int) implicitly 
casts to int.


What IFTI would need is a mechanism to change the parameter types to 
mutable similar to how you can do this:


foo(T)(const(T) t);

This now generates one function for int, const(int), immutable(int), and 
t is const within the function.


What we need is something like:

foo(T)(mutable(T) t) // fictitious type constructor, doesn't work.

Or a more general mechanism to modify IFTI when it is deciding the 
parameters to use based on the call.


In my case, I've run into this when I'm trying to use short or ubyte, 
and someone uses literals:


void foo(short s) { ...}

void fooT(T)(T t) { foo(s); }

foo(1); // ok
fooT(1); // error.

It would be nice if there was some way to tell IFTI to infer T as short 
in this case.


-Steve

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[Steven Schveighoffer via Digitalmars-d-learn]

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

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. Any ideas?


Unfortunately, send and receive do not currently work with shared
because of issues with Variant, which they use internally.


This can't be a correct statement. This is the whole point of shared.


What's incorrect about it? It's a longstanding issue that because Variant
can't contain shared data, send and receive do not work with shared.


The implementation details aren't important. From the documentation (and 
no, this documentation is not wrong):


From spawn:
args must not have unshared aliasing. In other words, all arguments to 
fn must either be shared or immutable or have no pointer indirection. 
This is necessary for enforcing isolation among threads.


From send:
As with std.concurrency.spawn, T must not have unshared aliasing.

So clearly passing shared pointers or things containing shared pointers 
should work fine.


As I was building code to test, I found that it does actually work for 
shared int pointers:


import std.concurrency;
import std.typecons;
import std.stdio;
import core.thread;

void threadfunc()
{
bool done = false;
while(!done)
{  receive(
  (shared(int)*foo) {*foo = 5; done = true;},
  (Variant v) {}
  );
}
}

shared int f;

void main()
{
auto tid = spawn();
tid.send();
Thread.sleep(1.seconds);
writeln(f);
}


No error, completes as expected, and outputs 5.

So it looks like this is really a straight up bug and has nothing to do 
with the shared type qualifier. It is documented as working, and does 
work in some cases.


I think if the shared item is not a reference, it is doing something 
different, and this is incompatible with something in the 
implementation. Indeed, if you attempt to send unshared references, you 
get an assert. However, if you send a shared int (not a pointer), you 
get a bunch of compiler errors. Clearly the implementation expects it to 
work, as it doesn't fail the logical checks.


-Steve

Re: OOP Design Pattern examples in D

[CRAIG DILLABAUGH via Digitalmars-d-announce]

On Tuesday, 15 August 2017 at 10:38:44 UTC, thinwybk wrote:
I created a project on GitHub 
(https://github.com/fkromer/d-design-patterns) which shall end 
up containing examples of all common OOP design patterns 
implemented in D. D beginners should be able to run the 
examples easily with rdmd. (That's the reason why patterns 
should reside in a single file.) If D-specific implementations 
are reasonable they are favored about the generic OOP 
implementation variants. Feel free to come round...


Interesting idea, I will try to pop in from time to time.

[Issue 17755] PhantomGhost

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17755

anonymous4  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--

Berlin D Meetup August 2017

[Ben Palmer via Digitalmars-d-announce]

Hi All,

The Berlin August D meetup is happening on this Friday the 18th 
at 19:30 at Berlin Co-Op (http://co-up.de/) on the fifth floor. 
In this meetup the idea is to have a bit of a play with static 
foreach and see what interesting things can be done with it. Feel 
free to come along with your examples, questions, or just an 
interest in what static foreach can do.


As always we will have both alcoholic and non-alcoholic drinks 
available.


The meetup page is: 
https://www.meetup.com/Berlin-D-Programmers/events/242557986/


Thanks,
Ben.

OOP Design Pattern examples in D

[thinwybk via Digitalmars-d-announce]

I created a project on GitHub 
(https://github.com/fkromer/d-design-patterns) which shall end up 
containing examples of all common OOP design patterns implemented 
in D. D beginners should be able to run the examples easily with 
rdmd. (That's the reason why patterns should reside in a single 
file.) If D-specific implementations are reasonable they are 
favored about the generic OOP implementation variants. Feel free 
to come round...

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[Kagamin 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());
}

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[Kagamin via Digitalmars-d-learn]

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)
{
this.obj = [o];
}

T get() @property nothrow @nogc
{
return cast() obj[0];
}
}

class A
{

}

void consumer()
{
auto r = receiveOnly!(Envelope!(A))();
writeln("Got: ", typeof(r).stringof);
}

void main()
{
auto cons = spawn();
auto o = Envelope!A(new A());
send(cons, o);
}

Shared object can be encapsulated in the array. In case of 
other (non-class) types the pointer can be used, and get() 
should return ref to the pointed object (after stripping off 
the shared qualifier).


Rather like this:

struct Sendable(T)
{
shared T o;
alias o this;
}

import std.concurrency;

class A
{
int method() shared;
}

void consumer()
{
shared A a = receiveOnly!(Sendable!(A))();
}

void producer()
{
auto cons = spawn();
shared A a = new shared A();
send(cons, Sendable!A(a));
}

Re: Need some vibe.d hosting advice

[aberba via Digitalmars-d]

On Saturday, 12 August 2017 at 08:49:44 UTC, Paolo Invernizzi 
wrote:

On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote:



[...]


We are using dockerized vibe.d containers in a docker swarm 
hosted on DigitalOcean.


/Paolo


Breaking the app into microservices and in a managed environment 
since we don't have devOps.


Among the container hosting options, I'm seeing Google's App 
Engine Flex which supports running docker containers and Google 
cloud for object storage (their api is much easy to use). And 
their SQL service too. Everything managed under one dashboard

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[Kagamin via Digitalmars-d-learn]

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 to do it manually by casting.

Re: RFC: Implementation of binary assignment operators (e.g s.x += 2) for @property functions

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 15 August 2017 at 07:52:17 UTC, Gary Willoughby wrote:
On Tuesday, 15 August 2017 at 03:53:44 UTC, Michael V. Franklin 
wrote:
An implementation of binary assignment operators for @property 
functions has been submitted to the DMD pull request queue at 
https://github.com/dlang/dmd/pull/7079.  It addresses the 
following issues:


Issue 8006 - Implement proper in-place-modification for 
properties

https://issues.dlang.org/show_bug.cgi?id=8006


I thought @property's behaviour had been removed from the 
language and even though the attribute remains, it doesn't 
actually do anything?


@property changes the typeof result (useful for introspection) 
[1][2]:


---
For the expression typeof(exp) where exp is an @property 
function, the type is the return type of the function, rather 
than the type of the function.

---

---
If the expression is a Property Function, typeof gives its return 
type.

---

[1] https://dlang.org/spec/declaration.html#typeof
[2] https://dlang.org/spec/function.html#property-functions

Re: RFC: Implementation of binary assignment operators (e.g s.x += 2) for @property functions

[Johannes Pfau via Digitalmars-d]

Am Tue, 15 Aug 2017 07:52:17 +
schrieb Gary Willoughby :

> On Tuesday, 15 August 2017 at 03:53:44 UTC, Michael V. Franklin 
> wrote:
> > An implementation of binary assignment operators for @property 
> > functions has been submitted to the DMD pull request queue at 
> > https://github.com/dlang/dmd/pull/7079.  It addresses the 
> > following issues:
> >
> > Issue 8006 - Implement proper in-place-modification for 
> > properties
> > https://issues.dlang.org/show_bug.cgi?id=8006  
> 
> I thought @property's behaviour had been removed from the 
> language and even though the attribute remains, it doesn't 
> actually do anything?
> 
> 

You're probably thinking of the special optional/non-optional
parenthesis rules and the -property compiler switch which was removed.

@property should still be used according to the style guide:
https://dlang.org/dstyle.html
and as far as I can tell it's heavily used in phobos.

Properties behave more like field variables in some traits:
http://dlang.org/spec/traits.html
https://dlang.org/phobos/std_traits.html

But I think that's the only relevant difference between properties and
normal functions right now.

-- Johannes

Re: RFC: Implementation of binary assignment operators (e.g s.x += 2) for @property functions

[Gary Willoughby via Digitalmars-d]

On Tuesday, 15 August 2017 at 03:53:44 UTC, Michael V. Franklin 
wrote:
An implementation of binary assignment operators for @property 
functions has been submitted to the DMD pull request queue at 
https://github.com/dlang/dmd/pull/7079.  It addresses the 
following issues:


Issue 8006 - Implement proper in-place-modification for 
properties

https://issues.dlang.org/show_bug.cgi?id=8006


I thought @property's behaviour had been removed from the 
language and even though the attribute remains, it doesn't 
actually do anything?

Re: RFC: Implementation of binary assignment operators (e.g s.x += 2) for @property functions

[Johannes Pfau via Digitalmars-d]

Am Tue, 15 Aug 2017 03:53:44 +
schrieb Michael V. Franklin :

> We ask for your comments whether they be in approval or 
> disapproval of this pull request so we can determine the best way 
> forward.
> 
> Thank you,
> Michael V. Franklin

+1. Then @property finally becomes useful ;-)


-- Johannes

[Issue 17755] New: PhantomGhost

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17755

  Issue ID: 17755
   Summary: PhantomGhost
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: phantomgh...@getnada.com

Created attachment 1654
  --> https://issues.dlang.org/attachment.cgi?id=1654=edit
PhantomGhost

phantomghost

--