On 10/18/18 10:08 AM, aliak wrote:
On Wednesday, 17 October 2018 at 23:34:55 UTC, Paul Backus wrote:
On Wednesday, 17 October 2018 at 07:32:37 UTC, aliak wrote:
lazy S x = () {
// do some heavy stuff
}();
if (condition) {
func(x.y); // heavy stuff evaluated here
}
auto x = () {
//
On Thursday, 18 October 2018 at 13:35:22 UTC, Steven
Schveighoffer wrote:
struct ThreadSafe
{
private int x;
void increment()
{
++x; // I know this is not shared, so no reason to use
atomics
}
void increment() shared
{
atomicIncrement(); // use atomics, to avoid
On Thursday, 18 October 2018 at 07:51:07 UTC, Andre Pany wrote:
On Thursday, 18 October 2018 at 00:24:29 UTC, Kai wrote:
On Wednesday, 17 October 2018 at 17:44:34 UTC, Adam D. Ruppe
wrote:
[...]
Hmm - wish it was so. When architecture not specified, the
linker crashes. When it's given,
On Thu., 18 Oct. 2018, 5:05 am Patrick Schluter via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote:
> >> If something might be used by someone else it's better not to
> >> touch it, unless one has confirmation it is not used
On Thursday, 18 October 2018 at 16:10:04 UTC, aliak wrote:
On Thursday, 18 October 2018 at 14:16:56 UTC, Simen Kjærås
wrote:
On Wednesday, 17 October 2018 at 07:32:37 UTC, aliak wrote:
Hi,
Is there any notion of lazy vars in D (i see that there're
parameters)?
What the language doesn't
On Thursday, 18 October 2018 at 13:09:10 UTC, Simen Kjærås wrote:
Well, sorta. But that's not a problem, because you can't do
anything that's not threadsafe to something that's shared.
Yes you can. You silently agree to another function's
assumption that you pass shared data, while actually
On Wednesday, 17 October 2018 at 21:12:49 UTC, Stefan Koch wrote:
Hi,
reading the other shared thread "shared - i need to be
useful"(https://forum.dlang.org/thread/mailman.4299.1539629222.29801.digitalmar...@puremagic.com)
let me to an important realisation concerning the reason
shareding
On 10/18/18 1:17 PM, Atila Neves wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
1. shared should behave exactly like const, except in addition to
inhibiting write access, it also inhibits read access.
How is this significantly different from now?
-
shared int
On Wednesday, 17 October 2018 at 07:32:37 UTC, aliak wrote:
Hi,
Is there any notion of lazy vars in D (i see that there're
parameters)?
What the language doesn't provide, it generally provides the
tools to make:
struct Lazy(T) {
T delegate() _payload;
this(lazy T t) {
On 10/18/18 10:11 AM, Simen Kjærås wrote:
On Thursday, 18 October 2018 at 13:35:22 UTC, Steven Schveighoffer wrote:
struct ThreadSafe
{
private int x;
void increment()
{
++x; // I know this is not shared, so no reason to use atomics
}
void increment() shared
{
On Thursday, 18 October 2018 at 17:10:03 UTC, aliak wrote:
Out of curiosity, when it comes to primitives, what could you
do under MP in void "atomicInc(shared int*)" that would be
problematic?
void atomicInc(shared int*) {
// i.e. what goes here?
}
1. Anything if int* implicitly converts
On Thursday, 18 October 2018 at 17:17:37 UTC, Atila Neves wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
1. shared should behave exactly like const, except in addition
to inhibiting write access, it also inhibits read access.
How is this significantly different from now?
On Thursday, 18 October 2018 at 17:43:40 UTC, Steven
Schveighoffer wrote:
On 10/18/18 1:17 PM, Atila Neves wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
1. shared should behave exactly like const, except in
addition to inhibiting write access, it also inhibits read
access.
On Wednesday, 17 October 2018 at 20:32:40 UTC, Ali Çehreli wrote:
On 10/17/2018 12:32 AM, aliak wrote:
[...]
Not very clean but something like this:
import std.stdio;
struct LazyVar(alias exp) {
alias T = typeof(exp());
T value() {
static bool initialized = false;
On Thursday, 18 October 2018 at 14:16:56 UTC, Simen Kjærås wrote:
On Wednesday, 17 October 2018 at 07:32:37 UTC, aliak wrote:
Hi,
Is there any notion of lazy vars in D (i see that there're
parameters)?
What the language doesn't provide, it generally provides the
tools to make:
struct
On Thursday, 18 October 2018 at 14:11:36 UTC, Steven
Schveighoffer wrote:
Yes, but that's what lazy variables do.
-Steve
Not in Swift at least...
Pardon the snarkiness, I probably need to get some air from that
other shared thread.
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
1. shared should behave exactly like const, except in addition
to inhibiting write access, it also inhibits read access.
How is this significantly different from now?
-
shared int i;
++i;
Error: read-modify-write
https://issues.dlang.org/show_bug.cgi?id=19308
--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos
https://github.com/dlang/phobos/commit/2e6c538dc69b74125cfd7f39376b0d9289565728
Fix issue 19308 - optimize stripLeft
Add ASCII fast
https://issues.dlang.org/show_bug.cgi?id=19308
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On 10/18/18 9:35 AM, Steven Schveighoffer wrote:
struct NotThreadsafe
{
private int x;
void local()
{
++x; // <- invalidates the method below, you violate the other
function's `shared` promise
}
void notThreadsafe() shared
{
atomicIncrement();
}
}
[snip]
But
On Thursday, 18 October 2018 at 14:08:11 UTC, aliak wrote:
On Wednesday, 17 October 2018 at 23:34:55 UTC, Paul Backus
wrote:
auto x = () {
// do some heavy stuff
};
if (condition) {
func(x().y); // heavy stuff evaluated here
}
That would do heavy stuff everytime i wanted to get y
On Thursday, 18 October 2018 at 16:31:33 UTC, Vijay Nayar wrote:
Imagine a simple algorithm that does logic on very long
numbers, split into bytes. One multi-threaded implementation
may use 4 threads. The first operating on bytes 0, 4, 8, etc.
The second operating on bytes 1, 5, 9, etc.
On 10/18/18 12:11 PM, aliak wrote:
On Thursday, 18 October 2018 at 14:11:36 UTC, Steven Schveighoffer wrote:
Yes, but that's what lazy variables do.
Not in Swift at least...
Apparently so (I have not used them before), but this is D! So you
should be aware that lazy parameters work that
On Thu, Oct 18, 2018 at 6:40 AM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/17/18 10:26 PM, Manu wrote:
> > On Wed, Oct 17, 2018 at 6:50 PM Steven Schveighoffer via Digitalmars-d
> >>
> >> The implicit cast means that you have to look at more than just your
> >> method. You have to
On Thursday, 18 October 2018 at 18:39:18 UTC, Samir wrote:
which leads me to believe that the output of `uniq` is not
necessarily another integer array.
Right, it is actually a "range" - an object that generates the
result on-demand, so it doesn't do work you don't actually need.
If you
On Thu, Oct 18, 2018 at 7:20 AM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/18/18 10:11 AM, Simen Kjærås wrote:
> > On Thursday, 18 October 2018 at 13:35:22 UTC, Steven Schveighoffer wrote:
> >> struct ThreadSafe
> >> {
> >>private int x;
> >>void increment()
> >>{
> >>
On Thursday, 18 October 2018 at 18:24:47 UTC, Manu wrote:
I have demonstrated these usability considerations in
production. I am
confident it's the right balance.
Then convince us. So far you haven't.
I propose:
1. Normal people don't write thread-safety, a very small
number of
unusual
On Thursday, 18 October 2018 at 17:01:46 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 16:31:33 UTC, Vijay Nayar wrote:
Imagine a simple algorithm that does logic on very long
numbers, split into bytes. One multi-threaded implementation
may use 4 threads. The first operating
On 10/18/18 2:55 PM, Manu wrote:
On Thu, Oct 18, 2018 at 7:20 AM Steven Schveighoffer via Digitalmars-d
wrote:
On 10/18/18 10:11 AM, Simen Kjærås wrote:
On Thursday, 18 October 2018 at 13:35:22 UTC, Steven Schveighoffer wrote:
struct ThreadSafe
{
private int x;
void increment()
On Thursday, 18 October 2018 at 23:47:56 UTC, Timon Gehr wrote:
I'm pretty sure you will have to allow operations on shared
local variables. Otherwise, how are you ever going to use a
shared(C)? You can't even call a shared method on it because it
involves reading the reference.
Because you
On 18.10.18 23:34, Erik van Velzen wrote:
If you have an object which can be used in both a thread-safe and a
thread-unsafe way that's a bug or code smell.
Then why do you not just make all members shared? Because with Manu's
proposal, as soon as you have a shared method, all members
On Friday, 19 October 2018 at 00:36:11 UTC, Timon Gehr wrote:
On 19.10.18 02:29, Stanislav Blinov wrote:
On Thursday, 18 October 2018 at 23:47:56 UTC, Timon Gehr wrote:
I'm pretty sure you will have to allow operations on shared
local variables. Otherwise, how are you ever going to use a
On Thu, Oct 18, 2018 at 3:10 PM Simen Kjærås via Digitalmars-d
wrote:
>
>
> Now, Two very good points came up in this post, and I think it's
> worth stating them again, because they do present possible issues
> with MP:
It is easy to respond to these.
> 1) How does MP deal with reorderings in
I am working my way through the exercises in the "Programming in
D" tutorial (http://ddili.org/ders/d.en/arrays.html). Why is the
line assigning the length of the dynamic array required?
/*
Write a program that asks the user how many values will be
entered and then
reads all of them. Have
On Friday, 19 October 2018 at 01:53:00 UTC, Manu wrote:
This is a red-herring.
In short, he made up this issue, it doesn't exist.
This is just hot air, and only strengthen my conviction.
Produce, or drop this presumptious crap.
You are an obscene person. I'm out.
Oooh, I'm srry,
On Friday, 19 October 2018 at 02:13:15 UTC, Shigeki Karita wrote:
On Sunday, 14 October 2018 at 22:16:47 UTC, jmh530 wrote:
On Saturday, 13 October 2018 at 16:05:31 UTC, kinke wrote:
* New, Easy::jit-like interface for dynamic/JIT compilation.
I'm not familiar with Easy::jit. Would it make
On Friday, 19 October 2018 at 02:04:37 UTC, Samir wrote:
I am working my way through the exercises in the "Programming
in D" tutorial (http://ddili.org/ders/d.en/arrays.html). Why
is the line assigning the length of the dynamic array required?
[...]
Without the line:
myArray.length =
On Thu., 18 Oct. 2018, 7:10 pm Stanislav Blinov via Digitalmars-d, <
digitalmars-d@puremagic.com> wrote:
> On Friday, 19 October 2018 at 01:53:00 UTC, Manu wrote:
>
> > This is a red-herring.
> > In short, he made up this issue, it doesn't exist.
> > This is just hot air, and only strengthen my
On 19.10.18 02:29, Stanislav Blinov wrote:
On Thursday, 18 October 2018 at 23:47:56 UTC, Timon Gehr wrote:
I'm pretty sure you will have to allow operations on shared local
variables. Otherwise, how are you ever going to use a shared(C)? You
can't even call a shared method on it because it
On Friday, 19 October 2018 at 00:29:01 UTC, Timon Gehr wrote:
On 18.10.18 23:34, Erik van Velzen wrote:
If you have an object which can be used in both a thread-safe
and a thread-unsafe way that's a bug or code smell.
Then why do you not just make all members shared? Because with
Manu's
https://issues.dlang.org/show_bug.cgi?id=5217
Mathias LANG changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://issues.dlang.org/show_bug.cgi?id=6449
Mathias LANG changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On 10/18/2018 07:04 PM, Samir wrote:
> myArray.length = noValues; // I get a run-time error if I comment
> this out
It's because the expression that reads the elements below is readf,
which reads on top of an existing element.
> while (i < noValues) {
> write("enter value
On Thu, Oct 18, 2018 at 6:50 PM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Friday, 19 October 2018 at 01:22:53 UTC, Manu wrote:
> > On Thu, Oct 18, 2018 at 3:10 PM Simen Kjærås via Digitalmars-d
> > wrote:
> >>
> >>
> >> Now, Two very good points came up in this post, and I think
> >> it's
On Sunday, 14 October 2018 at 22:16:47 UTC, jmh530 wrote:
On Saturday, 13 October 2018 at 16:05:31 UTC, kinke wrote:
* New, Easy::jit-like interface for dynamic/JIT compilation.
I'm not familiar with Easy::jit. Would it make sense to do some
kind of simple tutorial? Or maybe blog post?
I'm
https://issues.dlang.org/show_bug.cgi?id=5577
Mathias LANG changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Friday, 19 October 2018 at 02:20:22 UTC, Manu wrote:
I've given use cases constantly, about taking object ownership,
promotions, and distribution for periods (think parallel for),
Manu, you haven't shown *any* code in which conversion from
mutable to shared, an *implicit* one at that, was
On 10/15/2018 2:23 PM, Walter Bright wrote:
I'm giving a presentation at:
http://nwcpp.org/
See you there!
Had a nice crowd there last night. Apparently lots of people were interested in
this topic!
Video: https://www.youtube.com/watch?v=lbp6vwdnE0k=youtu.be
Slides:
On Thu, Oct 18, 2018 at 3:40 PM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/18/18 5:22 PM, Manu wrote:
> > On Thu, Oct 18, 2018 at 12:15 PM Steven Schveighoffer via
> > Digitalmars-d wrote:
> >>
> >> On 10/18/18 2:55 PM, Manu wrote:
> >>> On Thu, Oct 18, 2018 at 7:20 AM Steven
On Thu, Oct 18, 2018 at 5:30 PM Timon Gehr via Digitalmars-d
wrote:
>
> On 18.10.18 23:34, Erik van Velzen wrote:
> > If you have an object which can be used in both a thread-safe and a
> > thread-unsafe way that's a bug or code smell.
>
> Then why do you not just make all members shared? Because
On Friday, 19 October 2018 at 01:22:53 UTC, Manu wrote:
On Thu, Oct 18, 2018 at 3:10 PM Simen Kjærås via Digitalmars-d
wrote:
Now, Two very good points came up in this post, and I think
it's worth stating them again, because they do present
possible issues with MP:
It is easy to respond
On Thursday, 18 October 2018 at 20:07:54 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 19:51:17 UTC, Erik van Velzen
wrote:
On Thursday, 18 October 2018 at 19:26:39 UTC, Stanislav Blinov
Manu said clearly that the receiving thread won't be able to
read or write the pointer.
On Thursday, 18 October 2018 at 21:14:54 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 20:59:59 UTC, Erik van Velzen
wrote:
[...]
Quite a simple reason: it was years ago, however old you are
now you were younger and less experienced, and probably didn't
understand something
On Thursday, 18 October 2018 at 22:08:14 UTC, Simen Kjærås wrote:
On Thursday, 18 October 2018 at 16:31:02 UTC, Stanislav Blinov
Now, if the compiler generated above in the presence of any
`shared` members or methods, then we could begin talking about
it being threadsafe...
Again, this is
On 10/18/18 2:59 PM, Manu wrote:
On Thu, Oct 18, 2018 at 7:20 AM Steven Schveighoffer via Digitalmars-d
wrote:
On 10/18/18 10:11 AM, Simen Kjærås wrote:
a.increment(); // unsafe, non-shared method call
}
When a.increment() is being called, you have no idea if anyone else is
using the
On Thursday, 18 October 2018 at 18:53:06 UTC, Adam D. Ruppe wrote:
But, if you need to copy it into a new array, use `.array` at
the end.
Thanks. That did the trick. But if I may, what is the
difference between
uniqueArray = uniq(sort(unsortedArray)).array;
and
uniqueArray =
On Thursday, October 18, 2018 4:50:18 AM MDT Paolo Invernizzi via
Digitalmars-d-learn wrote:
> There's a rational behind the fact that there's not a 'shared'
> version of notify/wait method in Condition?
>
> Thanks,
> Paolo
The original author of the stuff in core.sync didn't want to update it
Are there a function like C#'s Path.GetDirectoryName()
(https://docs.microsoft.com/en-us/dotnet/api/system.io.path.getdirectoryname?redirectedfrom=MSDN=netframework-4.7.2#System_IO_Path_GetDirectoryName_System_String_) in D standard library or some dub package?
just checking if there's one, so
On Thursday, 18 October 2018 at 19:26:39 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 19:04:58 UTC, Erik van Velzen
wrote:
On Thursday, 18 October 2018 at 17:47:29 UTC, Stanislav Blinov
wrote:
Doesn't work. No matter what you show Manu or Simen here they
think it's just a bad
On Thursday, 18 October 2018 at 19:54:59 UTC, Dr.No wrote:
Are there a function like C#'s Path.GetDirectoryName()
Looks the same as "dirName" from "import std.path"
http://dpldocs.info/experimental-docs/std.path.dirName.1.html
On Thursday, 18 October 2018 at 19:51:17 UTC, Erik van Velzen
wrote:
On Thursday, 18 October 2018 at 19:26:39 UTC, Stanislav Blinov
Manu said clearly that the receiving thread won't be able to
read or write the pointer.
Yes it will, by casting `shared` away. *Just like* his
proposed "wrap
On Wednesday, 17 October 2018 at 15:20:08 UTC, Mike Parker wrote:
The blog:
https://dlang.org/blog/2018/10/17/interfacing-d-with-c-arrays-part-1/
A good read! It’s always nice to discover new content on the blog.
On Thursday, 18 October 2018 at 18:12:03 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 18:05:51 UTC, aliak wrote:
Right, but the argument is a shared int*, so from what I've
understood... you can't do anything with it since it has no
shared members. i.e. you can't read or write
Manu, Erik, Simen... In what world can a person consciously say
"casting is unsafe", and yet at the same time claim that
*implicit casting* is safe? What the actual F, guys?
On 10/18/18 5:22 PM, Manu wrote:
On Thu, Oct 18, 2018 at 12:15 PM Steven Schveighoffer via
Digitalmars-d wrote:
On 10/18/18 2:55 PM, Manu wrote:
On Thu, Oct 18, 2018 at 7:20 AM Steven Schveighoffer via Digitalmars-d
wrote:
On 10/18/18 10:11 AM, Simen Kjærås wrote:
On Thursday, 18 October
On Wednesday, 17 October 2018 at 12:14:55 UTC, Martin Nowak wrote:
Glad to announce the first beta for the 2.083.0 release, ♥ to
the 48 contributors for this release.
http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.083.0.html
As usual please report any bugs at
On 18.10.18 20:26, Steven Schveighoffer wrote:
i = 1;
int x = i;
shared int y = i;
This should be fine, y is not shared when being created.
However, this still is allowed, and shouldn't be:
y = 5;
-Steve
I'm pretty sure you will have to allow operations on shared local
variables.
https://issues.dlang.org/show_bug.cgi?id=9274
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=6777
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=9274
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
See Also|
On Thu, Oct 18, 2018 at 1:10 PM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Thursday, 18 October 2018 at 19:51:17 UTC, Erik van Velzen
> wrote:
> > On Thursday, 18 October 2018 at 19:26:39 UTC, Stanislav Blinov
>
> >>> Manu said clearly that the receiving thread won't be able to
> >>> read
On Thursday, 18 October 2018 at 17:17:37 UTC, Atila Neves wrote:
[snip]
Assuming this world... how do you use shared?
https://github.com/atilaneves/fearless
I had posted your library before to no response...
I had two questions, if you'll indulge me.
The first is perhaps more wrt
Manu I'm also making a plea for you to write a document with your
proposal which aggregates all relevant examples and objections.
Then you can easily refer to it and we can introduce ppl to idea
without reading a megathread.
On Thu, Oct 18, 2018 at 2:40 PM Erik van Velzen via Digitalmars-d
wrote:
>
> Manu I'm also making a plea for you to write a document with your
> proposal which aggregates all relevant examples and objections.
> Then you can easily refer to it and we can introduce ppl to idea
> without reading a
On Thursday, 18 October 2018 at 14:19:41 UTC, Steven
Schveighoffer wrote:
On 10/18/18 10:11 AM, Simen Kjærås wrote:
On Thursday, 18 October 2018 at 13:35:22 UTC, Steven
Schveighoffer wrote:
struct ThreadSafe
{
private int x;
void increment()
{
++x; // I know this is not shared,
On Thursday, 18 October 2018 at 16:31:02 UTC, Stanislav Blinov
wrote:
You contradict yourself and don't even notice it. Per your
rules, the way to open that locked box is have shared methods
that access data via casting. Also per your rules, there is
absolutely no way for the programmer to
On Thu, Oct 18, 2018 at 2:55 PM Stanislav Blinov via Digitalmars-d
wrote:
>
> Manu, Erik, Simen... In what world can a person consciously say
> "casting is unsafe", and yet at the same time claim that
> *implicit casting* is safe? What the actual F, guys?
Implicit casting exists in a world where
On Thursday, 18 October 2018 at 21:54:55 UTC, Stanislav Blinov
wrote:
Manu, Erik, Simen... In what world can a person consciously say
"casting is unsafe", and yet at the same time claim that
*implicit casting* is safe? What the actual F, guys?
In a world where the implicit casting always ends
On Thursday, 18 October 2018 at 21:51:52 UTC, aliak wrote:
On Thursday, 18 October 2018 at 18:12:03 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 18:05:51 UTC, aliak wrote:
Right, but the argument is a shared int*, so from what I've
understood... you can't do anything with it
On Thursday, 18 October 2018 at 22:09:02 UTC, Manu wrote:
The 2 different strategies are 2 different worlds, one is my
proposal,
the other is more like what we have now. They are 2 different
rule-sets.
You are super-attached to some presumptions, and appear to
refuse to
analyse the proposal
https://issues.dlang.org/show_bug.cgi?id=5363
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
On Thu, Oct 18, 2018 at 12:15 PM Steven Schveighoffer via
Digitalmars-d wrote:
>
> On 10/18/18 2:55 PM, Manu wrote:
> > On Thu, Oct 18, 2018 at 7:20 AM Steven Schveighoffer via Digitalmars-d
> > wrote:
> >>
> >> On 10/18/18 10:11 AM, Simen Kjærås wrote:
> >>> On Thursday, 18 October 2018 at
On Thu, Oct 18, 2018 at 6:50 AM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/18/18 9:35 AM, Steven Schveighoffer wrote:
> >
> > struct NotThreadsafe
> > {
> >private int x;
> >void local()
> >{
> > ++x; // <- invalidates the method below, you violate the other
> >
On Thu, Oct 18, 2018 at 7:20 AM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/18/18 10:11 AM, Simen Kjærås wrote:
> > a.increment(); // unsafe, non-shared method call
> > }
> >
> > When a.increment() is being called, you have no idea if anyone else is
> > using the shared
On Thursday, 18 October 2018 at 17:23:36 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 17:10:03 UTC, aliak wrote:
Out of curiosity, when it comes to primitives, what could you
do under MP in void "atomicInc(shared int*)" that would be
problematic?
void atomicInc(shared int*)
On 10/18/18 1:47 PM, Stanislav Blinov wrote:
On Thursday, 18 October 2018 at 17:17:37 UTC, Atila Neves wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
1. shared should behave exactly like const, except in addition to
inhibiting write access, it also inhibits read access.
How
On 10/18/18 2:24 PM, Manu wrote:
I understand your argument, and I used to think this too... but I
concluded differently for 1 simple reason: usability.
You have not demonstrated why your proposal is usable, and the proposal
to simply make shared not accessible while NOT introducing implicit
On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
On Thu., 18 Oct. 2018, 5:05 am Patrick Schluter via
Digitalmars-d, < digitalmars-d@puremagic.com> wrote:
On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh
wrote:
>> If something might be used by someone else it's better not
>>
What is the proper way to find the unique values of an array and
store them in another array? When I try:
import std.stdio: writeln;
import std.conv;
import std.algorithm;
void main() {
int[] unsortedArray = [5, 3, 8, 5, 2, 3, 0, 8];
int[] uniqueArray;
uniqueArray =
On Thursday, 18 October 2018 at 18:26:27 UTC, Steven
Schveighoffer wrote:
On 10/18/18 1:47 PM, Stanislav Blinov wrote:
On Thursday, 18 October 2018 at 17:17:37 UTC, Atila Neves
wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
1. shared should behave exactly like const, except in
On Thursday, 18 October 2018 at 17:47:29 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 17:17:37 UTC, Atila Neves wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
Assuming the rules above: "can't read or write to members",
and the understanding that `shared` methods
On 10/18/18 2:42 PM, Stanislav Blinov wrote:
On Thursday, 18 October 2018 at 18:26:27 UTC, Steven Schveighoffer wrote:
On 10/18/18 1:47 PM, Stanislav Blinov wrote:
On Thursday, 18 October 2018 at 17:17:37 UTC, Atila Neves wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
1.
On Thu, Oct 18, 2018 at 07:09:42PM +, Patrick Schluter via Digitalmars-d
wrote:
[...]
> I often have the impression that a lot of things are going slower than
> necessary because a mentality where the perfect is in the way of good.
That is indeed an all-too-frequent malady around these
On Thu, Oct 18, 2018 at 07:26:08PM +, MDtox via Digitalmars-d wrote:
> How to convert decimal and string to binary?
What exactly do you mean by "binary"? If you mean convert a string to a
numerical type, use std.conv.to:
import std.conv : to;
auto x = "12345";
auto i
On Thursday, 18 October 2018 at 19:09:42 UTC, Patrick Schluter
wrote:
On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
Elaborate on this... It's clearly over-ambitious if anything.
What issues am I failing to address? I'm creating a situation
where using
shared has a meaning, is
On Thursday, 18 October 2018 at 20:10:18 UTC, Erik van Velzen
wrote:
When shared stood up in its current form, expectation was made
"this will be threadsafe automatically - we'll figure out how
in the future".
It never was like that. At all. I don't think either Walter or
Andrei are
On Thursday, 18 October 2018 at 18:05:51 UTC, aliak wrote:
Right, but the argument is a shared int*, so from what I've
understood... you can't do anything with it since it has no
shared members. i.e. you can't read or write to it. No?
Obviously the implementation would cast `shared` away,
How to convert decimal and string to binary?
On Thursday, 18 October 2018 at 19:04:58 UTC, Erik van Velzen
wrote:
On Thursday, 18 October 2018 at 17:47:29 UTC, Stanislav Blinov
wrote:
On Thursday, 18 October 2018 at 17:17:37 UTC, Atila Neves
wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
Assuming the rules above: "can't
1 - 100 of 160 matches
Mail list logo
