On 10/15/2018 11:46 AM, Manu wrote:
[...]
Shared has one incredibly valuable feature - it allows you, the programmer, to
identify data that can be accessed by multiple threads. There are so many ways
that data can be shared, the only way to comprehend what is going on is to build
a wall arou
On Wednesday, 17 October 2018 at 03:50:44 UTC, Manu wrote:
On Tue, Oct 16, 2018 at 8:20 PM Isaac S. via Digitalmars-d
wrote:
*snip*
Overloading for shared and unshared is my reason for not
allowing implicit conversion on my types (I have no problems
with implicit conversion being optional or
On Tue, Oct 16, 2018 at 8:20 PM Isaac S. via Digitalmars-d
wrote:
>
> On Tuesday, 16 October 2018 at 06:21:22 UTC, Manu wrote:
> > On Mon, Oct 15, 2018 at 8:55 PM Isaac S. via Digitalmars-d
> > wrote:
> >>
> >> On Tuesday, 16 October 2018 at 02:26:04 UTC, Manu wrote:
> >> >> I understand your poi
On Tuesday, 16 October 2018 at 06:21:22 UTC, Manu wrote:
On Mon, Oct 15, 2018 at 8:55 PM Isaac S. via Digitalmars-d
wrote:
On Tuesday, 16 October 2018 at 02:26:04 UTC, Manu wrote:
>> I understand your point but I think the current shared (no
>> implicit conversion) has its uses.
>> *snip*
>
On Wednesday, 17 October 2018 at 00:29:04 UTC, Manu wrote:
On Tue, Oct 16, 2018 at 3:25 PM Nicholas Wilson via
Digitalmars-d wrote:
On Tuesday, 16 October 2018 at 21:19:26 UTC, Steven
Schveighoffer wrote:
> There is in fact, no difference between:
>
> int *p;
> shared int *p2 = p;
> int *p3
On Tue, Oct 16, 2018 at 3:25 PM Nicholas Wilson via Digitalmars-d
wrote:
>
> On Tuesday, 16 October 2018 at 21:19:26 UTC, Steven Schveighoffer
> wrote:
> > There is in fact, no difference between:
> >
> > int *p;
> > shared int *p2 = p;
> > int *p3 = cast(int*)p2;
> >
> > and this:
> >
> > int *p;
On Tue, Oct 16, 2018 at 2:20 PM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/16/18 4:26 PM, Manu wrote:
> > On Tue, Oct 16, 2018 at 11:30 AM Steven Schveighoffer via
> > Digitalmars-d wrote:
> >>
> >> On 10/16/18 2:10 PM, Manu wrote:
> >>> On Tue, Oct 16, 2018 at 6:35 AM Steven Schveig
On Tuesday, 16 October 2018 at 22:59:18 UTC, Soulsbane wrote:
On Tuesday, 16 October 2018 at 02:34:47 UTC, Jabari Zakiya
wrote:
Just updated Atom editor and noticed D files read as plain
.txt and no D bindings in list of programs. Maybe someone
should bring that to Atom's devs attention.
Inte
On Tuesday, 16 October 2018 at 22:18:13 UTC, Walter Bright wrote:
On 10/16/2018 1:16 PM, notna wrote:
[...]
We're not going to automatically close stale pull requests, nor
are we going to arbitrarily close old unfixed bug reports.
Agreed, then there won't be those 5+ year old reports we can
On Tuesday, 16 October 2018 at 02:34:47 UTC, Jabari Zakiya wrote:
Just updated Atom editor and noticed D files read as plain .txt
and no D bindings in list of programs. Maybe someone should
bring that to Atom's devs attention.
Interesting, since my main editor, KDE's Kate, does have D file
sy
On Tuesday, 16 October 2018 at 21:19:26 UTC, Steven Schveighoffer
wrote:
There is in fact, no difference between:
int *p;
shared int *p2 = p;
int *p3 = cast(int*)p2;
and this:
int *p;
shared int *p2 = p;
int *p3 = p;
If I understand Manu correctly the first should compile, and the
second sh
On Tuesday, 16 October 2018 at 21:19:26 UTC, Steven Schveighoffer
wrote:
OK, so here is where I think I misunderstood your point. When
you said a lock-free queue would be unusable if it wasn't
shared, I thought you meant it would be unusable if we didn't
allow the implicit cast. But I realize n
On 10/16/2018 1:16 PM, notna wrote:
[...]
We're not going to automatically close stale pull requests, nor are we going to
arbitrarily close old unfixed bug reports.
On Tuesday, 16 October 2018 at 21:12:39 UTC, welkam wrote:
On Tuesday, 16 October 2018 at 20:58:54 UTC, Jabari Zakiya
wrote:
And they could be modded to catch semantics like this and
produce faster code.
Its hard to prove that you will only write 1 or 0 in the array
and even if you write such
On Tue, Oct 16, 2018 at 05:10:38PM -0400, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
> On 10/16/18 4:16 PM, notna wrote:
> > another interesting discussion [1]... and old/stale pull requests
> > are also discussed here now and then... not sure if this [2] is
> > known to many ppl?!
> >
>
On 10/16/18 4:26 PM, Manu wrote:
On Tue, Oct 16, 2018 at 11:30 AM Steven Schveighoffer via
Digitalmars-d wrote:
On 10/16/18 2:10 PM, Manu wrote:
On Tue, Oct 16, 2018 at 6:35 AM Steven Schveighoffer via Digitalmars-d
wrote:
On 10/16/18 9:25 AM, Steven Schveighoffer wrote:
On 10/15/18 2:46
On Tuesday, 16 October 2018 at 20:58:54 UTC, Jabari Zakiya wrote:
And they could be modded to catch semantics like this and
produce faster code.
Its hard to prove that you will only write 1 or 0 in the array
and even if you write such pass it wont fire very often. So
slower compile times for
On 10/16/18 4:16 PM, notna wrote:
another interesting discussion [1]... and old/stale pull requests are
also discussed here now and then... not sure if this [2] is known to
many ppl?!
- [1] https://marc.info/?t=15392665871&r=1&w=2
- [2] https://github.com/probot/stale
I've encountered st
On Tuesday, 16 October 2018 at 17:48:42 UTC, Jabari Zakiya wrote:
On Tuesday, 16 October 2018 at 02:34:47 UTC, Jabari Zakiya
wrote:
Just updated Atom editor and noticed D files read as plain
.txt and no D bindings in list of programs. Maybe someone
should bring that to Atom's devs attention.
On Tuesday, 16 October 2018 at 20:38:24 UTC, welkam wrote:
On Tuesday, 16 October 2018 at 17:57:23 UTC, Jabari Zakiya
wrote:
This is the exact same behavior I found with the Nim compiler
too.
Well Nim compiler is more like translator. It translates Nim
code to c or c++. Since gcc was responsi
On Tuesday, 16 October 2018 at 17:57:23 UTC, Jabari Zakiya wrote:
This is the exact same behavior I found with the Nim compiler
too.
Well Nim compiler is more like translator. It translates Nim code
to c or c++. Since gcc was responsible for optimizations and
instruction selection it would be
On Tue, Oct 16, 2018 at 11:30 AM Steven Schveighoffer via
Digitalmars-d wrote:
>
> On 10/16/18 2:10 PM, Manu wrote:
> > On Tue, Oct 16, 2018 at 6:35 AM Steven Schveighoffer via Digitalmars-d
> > wrote:
> >>
> >> On 10/16/18 9:25 AM, Steven Schveighoffer wrote:
> >>> On 10/15/18 2:46 PM, Manu wrot
another interesting discussion [1]... and old/stale pull requests
are also discussed here now and then... not sure if this [2] is
known to many ppl?!
- [1] https://marc.info/?t=15392665871&r=1&w=2
- [2] https://github.com/probot/stale
On Monday, 15 October 2018 at 21:26:52 UTC, solidstate1991 wrote:
I have done two mistakes: I underestimated the scope of the
project and overestimated my capabilities. This caused a chain
reaction, which in turn made the first milestone unreachable.
You've done the right thing by facing the s
On Tuesday, 16 October 2018 at 07:09:05 UTC, Vijay Nayar wrote:
On Monday, 15 October 2018 at 22:17:57 UTC, Jabari Zakiya wrote:
$ dub build --compiler=ldc2 -b=release && echo "30" |
./twinprimes
Enter integer number:
threads = 8
each thread segment is [1 x 65536] bytes array
twinprime
On 10/16/18 2:10 PM, Manu wrote:
On Tue, Oct 16, 2018 at 6:35 AM Steven Schveighoffer via Digitalmars-d
wrote:
On 10/16/18 9:25 AM, Steven Schveighoffer wrote:
On 10/15/18 2:46 PM, Manu wrote:
From there, it opens up another critical opportunity; T* -> shared(T)*
promotion.
Const would b
On Tue, Oct 16, 2018 at 6:35 AM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/16/18 9:25 AM, Steven Schveighoffer wrote:
> > On 10/15/18 2:46 PM, Manu wrote:
>
> >>> From there, it opens up another critical opportunity; T* -> shared(T)*
> >> promotion.
> >> Const would be useless without
On Tue, Oct 16, 2018 at 6:25 AM Timon Gehr via Digitalmars-d
wrote:
>
> On 16.10.2018 13:04, Dominikus Dittes Scherkl wrote:
> > On Tuesday, 16 October 2018 at 10:15:51 UTC, Timon Gehr wrote:
> >> On 15.10.2018 20:46, Manu wrote:
> >>>
> >>> Assuming the rules above: "can't read or write to member
On Tuesday, 16 October 2018 at 16:57:12 UTC, welkam wrote:
So I run profiler and 97% of time is spent in void twinsSieve
function and hotspots are seg[k] = seg[k] | 1; lines. Since
seg[k] can only be 1 or 0 I removed that or operation. And the
results are. Queue the drum-roll... 5% slower.
I
On Tuesday, 16 October 2018 at 02:34:47 UTC, Jabari Zakiya wrote:
Just updated Atom editor and noticed D files read as plain .txt
and no D bindings in list of programs. Maybe someone should
bring that to Atom's devs attention.
Interesting, since my main editor, KDE's Kate, does have D file
sy
On Tuesday, 16 October 2018 at 07:09:05 UTC, Vijay Nayar wrote:
D has multiple compilers, but for the speed of the finished
binary, LDC2 is generally recommended. I used version 1.11.0.
https://github.com/ldc-developers/ldc/releases/tag/v1.11.0
I was using DUB to manage the project, but to b
On Tue, Oct 16, 2018 at 3:20 AM Timon Gehr via Digitalmars-d
wrote:
>
> On 15.10.2018 20:46, Manu wrote:
> >
> > Assuming the rules above: "can't read or write to members", and the
> > understanding that `shared` methods are expected to have threadsafe
> > implementations (because that's the whole
On Tue, Oct 16, 2018 at 2:25 AM Kagamin via Digitalmars-d
wrote:
>
> On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
> > Current situation where you can arbitrarily access shared
> > members
> > undermines any value it has.
>
> The value of shared is existence of thread-local data that's
>
So I run profiler and 97% of time is spent in void twinsSieve
function and hotspots are seg[k] = seg[k] | 1; lines. Since
seg[k] can only be 1 or 0 I removed that or operation. And the
results are. Queue the drum-roll... 5% slower.
I thought that all of my studying was getting somewhere. That
On Tuesday, 16 October 2018 at 03:42:13 UTC, Russel Winder wrote:
Hi,
I am doing a presentation looking at DVB, GTK+, GStreamer, C,
C++, gtkmm, D, GtkD, GStreamerD, Rust, gtk-rs, and gstreamer-rs
in Norwich 2018-11-07. Anyone who wants to come and heckle
about ditching D and switching to Rust
On Monday, 15 October 2018 at 21:26:52 UTC, solidstate1991 wrote:
I try to resume my work on improving mago, but on a much
smaller scale and lower priority since I have to spend time
finding a job, which is a very hard thing in this fascist
country called Hungary, while also not supporting sa
On Tuesday, 16 October 2018 at 11:42:55 UTC, Tony wrote:
On Monday, 15 October 2018 at 08:21:11 UTC, Eugene Wissner
He doesn't argue against garbage collection.
Thanks, Eugene, I was starting to lose hope in humanity.
Well, can you state what he does argue against?
I did state what I was
On Monday, 15 October 2018 at 21:26:52 UTC, solidstate1991 wrote:
I have done two mistakes: I underestimated the scope of the
project and overestimated my capabilities. This caused a chain
reaction, which in turn made the first milestone unreachable.
Hello,
Just to say you seem like a nice
On 10/16/18 9:25 AM, Steven Schveighoffer wrote:
On 10/15/18 2:46 PM, Manu wrote:
From there, it opens up another critical opportunity; T* -> shared(T)*
promotion.
Const would be useless without T* -> const(T)* promotion. Shared
suffers a similar problem.
If you write a lock-free queue for in
On 10/15/18 2:46 PM, Manu wrote:
Okay, so I've been thinking on this for a while... I think I have a
pretty good feel for how shared is meant to be.
1. shared should behave exactly like const, except in addition to
inhibiting write access, it also inhibits read access.
I think this is the found
On 16.10.2018 13:04, Dominikus Dittes Scherkl wrote:
On Tuesday, 16 October 2018 at 10:15:51 UTC, Timon Gehr wrote:
On 15.10.2018 20:46, Manu wrote:
Assuming the rules above: "can't read or write to members", and the
understanding that `shared` methods are expected to have threadsafe
implement
On Tuesday, 16 October 2018 at 03:00:21 UTC, Manu wrote:
I don't see how an *implicit* cast can be a restriction. At
all.
Because a shared pointer can't access anything.
You can't do anything with a shared instance, so the can be no
harm done.
That just doesn't compute. You obviously *can*
On Sunday, 14 October 2018 at 15:27:07 UTC, Michael Coulombe
wrote:
On Sunday, 14 October 2018 at 14:35:36 UTC, lngns wrote:
On Sunday, 14 October 2018 at 13:18:37 UTC, lngns wrote:
That would require introducing a new type
Or just use int with a negative number... That's how it's done
in so
On Monday, 15 October 2018 at 08:21:11 UTC, Eugene Wissner wrote:
On Monday, 15 October 2018 at 05:26:56 UTC, Tony wrote:
Ideally you wouldn’t have chosen to even try D. You (and
others who spend so much time arguing against garbage
collection on a forum for a language designed with garbage
On Tuesday, 16 October 2018 at 10:15:51 UTC, Timon Gehr wrote:
On 15.10.2018 20:46, Manu wrote:
Assuming the rules above: "can't read or write to members",
and the
understanding that `shared` methods are expected to have
threadsafe
implementations (because that's the whole point), what are th
On 15.10.2018 20:46, Manu wrote:
Assuming the rules above: "can't read or write to members", and the
understanding that `shared` methods are expected to have threadsafe
implementations (because that's the whole point), what are the risks
from allowing T* -> shared(T)* conversion?
Unshared bec
On Sunday, 14 October 2018 at 12:14:06 UTC, bioinfornatics wrote:
Dear,
Some projects seem to have an extra directory for their include
directory, such as:
- stdx-allocator
- containers
- msgpack
- dparse
...
[...]
up
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
Current situation where you can arbitrarily access shared
members
undermines any value it has.
The value of shared is existence of thread-local data that's
guaranteed to be not shared, so you don't need to worry about
thread-local data
On 2018-10-15 20:46, Manu wrote:
1. traditional; assert that the object become thread-local by
acquiring a lock, cast shared away
Instead of having to explicitly cast away shared we could leverage the
synchronized statement. It could be enhanced to allow the following:
shared int a;
Mutex m
On Monday, 15 October 2018 at 22:17:57 UTC, Jabari Zakiya wrote:
$ dub build --compiler=ldc2 -b=release && echo "30" |
./twinprimes
Enter integer number:
threads = 8
each thread segment is [1 x 65536] bytes array
twinprime candidates = 175324676; resgroups = 1298702
each 135 threads has
50 matches
Mail list logo
