On 2018-10-22 12:06, Russel Winder wrote:
Jacob,
GitHub is currently making a total mess for me of our conversation on
Issue 42, I see stuff then it goes away. Apologies if I have made a
mess of that conversation for you.
Yeah, I noticed that. GitHub had/still having some major issues [1].
S
On 2018-10-21 22:31, Patrick Schluter wrote:
I like it and I'm looking forward that it gets beyond swt 3.4.
I ported my Java GUI SWT program to D and it was a breeze to do. I
didn't even require to change the structure of the app and the class
hierarchy. There was only the file and string hand
On Mon, 2018-10-22 at 16:23 +, Gregor Mückl via Digitalmars-d
wrote:
>
[…]
> It's easy to go and proclaim a strategic goal such as this. What
> actually matters is execution. And that requires some serious
> developer time that someone (ideally a whole team) needs to
> invest. I don't see t
On Mon, Oct 22, 2018 at 6:00 AM Timon Gehr via Digitalmars-d
wrote:
>
> On 22.10.18 12:26, Timon Gehr wrote:
> > ---
> > module borked;
> >
> > void atomicIncrement(int* p)@system{
> > import core.atomic;
> > atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
> > }
> >
> > struct Atomic(T)
On Mon, Oct 22, 2018 at 4:50 AM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Monday, 22 October 2018 at 00:22:19 UTC, Manu wrote:
>
> > No no, they're repeated, not scattered, because I seem to have
> > to keep repeating it over and over, because nobody is reading
> > the text, or perhaps imag
On Mon, Oct 22, 2018 at 3:30 AM Timon Gehr via Digitalmars-d
wrote:
>
> On 22.10.18 02:54, Manu wrote:
> > On Sun, Oct 21, 2018 at 5:40 PM Timon Gehr via Digitalmars-d
> > wrote:
> >>
> >> On 21.10.18 21:04, Manu wrote:
> >>> On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
> >>> wr
On Sunday, 21 October 2018 at 17:15:03 UTC, Russel Winder wrote:
On Sun, 2018-10-21 at 08:42 +, Paolo Invernizzi via
Digitalmars-d wrote:
[…]
Linux is not only the desktop, and Qt simply dominates in
industrial, medical and automation sector, that's where the
money is.
Qt is pushing str
On Mon, 22 Oct 2018 03:49:44 -0400, Nick Sabalausky (Abscissa) wrote:
> So I'm honestly *shocked* to hear this. I NEVER would've guessed. I'm
> pretty sold on rolling-release at this point, but I'm intrigued enough
> that I'm gonna have to give the latest Ubuntu a try, at least in a VM.
The latest
On Monday, 22 October 2018 at 14:31:28 UTC, Timon Gehr wrote:
On 22.10.18 16:09, Simen Kjærås wrote:
On Monday, 22 October 2018 at 13:40:39 UTC, Timon Gehr wrote:
module reborked;
import atomic;
void main()@safe{
auto a=new Atomic!int;
import std.concurrency;
spawn((shared(Atomic!i
On Monday, 22 October 2018 at 11:24:27 UTC, Dukc wrote:
Frankly, this does not sound credible. According to this
rationale, array access should be @system too, because it
relies on the array not giving direct access to its length to
the user, which would also in itself be @safe.
For reading,
On Monday, 22 October 2018 at 00:22:19 UTC, Manu wrote:
On Sun, Oct 21, 2018 at 2:35 PM Walter Bright via Digitalmars-d
wrote:
On 10/21/2018 2:08 PM, Walter Bright wrote:
> On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
>> Yes, but the problem you describe is arises from implicit
>> conversio
On 22.10.18 16:09, Simen Kjærås wrote:
On Monday, 22 October 2018 at 13:40:39 UTC, Timon Gehr wrote:
module reborked;
import atomic;
void main()@safe{
auto a=new Atomic!int;
import std.concurrency;
spawn((shared(Atomic!int)* a){ ++*a; }, a);
++a.tupleof[0];
}
Finally! Proof th
On Monday, 22 October 2018 at 11:24:27 UTC, Dukc wrote:
Frankly, this does not sound credible. According to this
rationale, array access should be @system too, because it
relies on the array not giving direct access to its length to
the user, which would also in itself be @safe.
Arrays are a
On Monday, 22 October 2018 at 00:22:19 UTC, Manu wrote:
On Sun, Oct 21, 2018 at 2:35 PM Walter Bright via Digitalmars-d
wrote:
Then I don't know what the proposal is. Pieces of it appear to
be scattered over numerous posts, mixed in with other text,
No no, they're repeated, not scattered, b
On Monday, 22 October 2018 at 13:40:39 UTC, Timon Gehr wrote:
module reborked;
import atomic;
void main()@safe{
auto a=new Atomic!int;
import std.concurrency;
spawn((shared(Atomic!int)* a){ ++*a; }, a);
++a.tupleof[0];
}
Finally! Proof that MP is impossible. On the other hand,
On 22.10.18 15:26, Simen Kjærås wrote:
Here's the correct version:
module atomic;
void atomicIncrement(int* p) @system {
import core.atomic;
atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
}
struct Atomic(T) {
// Should probably mark this shared for extra safety,
// but it
On 22.10.18 03:01, Manu wrote:
On Sun, Oct 21, 2018 at 5:55 PM Timon Gehr via Digitalmars-d
wrote:
On 22.10.18 02:45, Manu wrote:
On Sun, Oct 21, 2018 at 5:35 PM Timon Gehr via Digitalmars-d
wrote:
On 21.10.18 20:46, Manu wrote:
Shared data is only useful if, at some point, it is read/wri
On Monday, 22 October 2018 at 09:40:42 UTC, Manu wrote:
On Mon, Oct 22, 2018 at 2:21 AM ag0aep6g via Digitalmars-d
wrote:
On 22.10.18 10:39, Simen Kjærås wrote:
> On Sunday, 21 October 2018 at 22:03:00 UTC, ag0aep6g wrote:
[...]
> It's invalid only if Atomic.badboy exists.
I don't agree. I pr
On Monday, 22 October 2018 at 11:06:42 UTC, Jonathan M Davis
wrote:
On Monday, October 22, 2018 2:30:21 AM MDT Basile B. via
Digitalmars-d wrote:
On Monday, 22 October 2018 at 08:25:17 UTC, Andrea Fontana
wrote:
> Moreover: you're the author of the module so you're supposed
> to know how it wor
On Monday, 22 October 2018 at 10:26:14 UTC, Timon Gehr wrote:
module borked;
void atomicIncrement(int* p)@system{
import core.atomic;
atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
}
struct Atomic(T){
private T val;
void opUnary(string op : "++")() shared @trusted {
at
On 22.10.18 14:39, Aliak wrote:
On Monday, 22 October 2018 at 10:26:14 UTC, Timon Gehr wrote:
---
module borked;
void atomicIncrement(int* p)@system{
import core.atomic;
atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
}
struct Atomic(T){
private T val;
void opUnary(string op :
On 22.10.18 12:26, Timon Gehr wrote:
---
module borked;
void atomicIncrement(int* p)@system{
import core.atomic;
atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
}
struct Atomic(T){
private T val;
void opUnary(string op : "++")() shared @trusted {
atomicIncrement(ca
On Monday, 22 October 2018 at 10:26:14 UTC, Timon Gehr wrote:
---
module borked;
void atomicIncrement(int* p)@system{
import core.atomic;
atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
}
struct Atomic(T){
private T val;
void opUnary(string op : "++")() shared @trusted {
On Monday, 22 October 2018 at 00:22:19 UTC, Manu wrote:
No no, they're repeated, not scattered, because I seem to have
to keep repeating it over and over, because nobody is reading
the text, or perhaps imaging there is a lot more text than
there is.
...
You mean like every post in opposition
On Sunday, 21 October 2018 at 22:03:00 UTC, ag0aep6g wrote:
The @trusted contract says that an @trusted function must be
safe when called from an @safe function. That calling @safe
function might be located in the same module, meaning it might
have the same level of access as the @trusted funct
On Monday, October 22, 2018 2:30:21 AM MDT Basile B. via Digitalmars-d
wrote:
> On Monday, 22 October 2018 at 08:25:17 UTC, Andrea Fontana wrote:
> > Moreover: you're the author of the module so you're supposed to
> > know how it works and which members you should call or not.
>
> - team
> - maint
On 22.10.18 11:40, Manu wrote:
On Mon, Oct 22, 2018 at 2:21 AM ag0aep6g via Digitalmars-d
wrote:
[...]
I don't agree. I prefer the stronger @trusted. As far as I know, the
stronger one is the current one.
The current one has the critical weakness that it causes **EVERY
USER** to write unsafe
On 22.10.18 11:33, Manu wrote:
On Sun, Oct 21, 2018 at 3:05 PM ag0aep6g via Digitalmars-d
wrote:
[...]
It's @trusted, not @safe... so I don't think you can say "It's invalid
because we can even possibly write an Atomic.badboy" (I would agree to
that statement if it were @safe).
That's the thin
On Sunday, 21 October 2018 at 22:03:00 UTC, ag0aep6g wrote:
It took me a while to understand Manu's idea for `shared`, and
I suspect that it was/is the same for others...
Three threads one...
Three threads two...
Three threads three! Sold! Thank you very much, ladies and
gentlemen!
On 22.10.18 02:54, Manu wrote:
On Sun, Oct 21, 2018 at 5:40 PM Timon Gehr via Digitalmars-d
wrote:
On 21.10.18 21:04, Manu wrote:
On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
wrote:
On 21.10.18 17:54, Nicholas Wilson wrote:
As soon as that is done, you've got a data rac
On Mon, 2018-10-22 at 03:49 -0400, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
> […]
> Just to see what's up with this "Qt-based Ubuntu", which to me, is
> much
> like hearing of Mario on a Dreamcast, or Sonic on SNES...
Canonical got heavily into Qt (well QML actually) when they were goi
Jacob,
GitHub is currently making a total mess for me of our conversation on
Issue 42, I see stuff then it goes away. Apologies if I have made a
mess of that conversation for you.
On Sun, 2018-10-21 at 20:24 +0200, Jacob Carlborg via Digitalmars-d
wrote:
>
[…]
> There's probably a ton of busines
On Mon, Oct 22, 2018 at 2:30 AM Walter Bright via Digitalmars-d
wrote:
>
> On 10/22/2018 1:34 AM, Manu wrote:
> > I posted it, twice... 2 messages, back to back, and you're responding
> > to this one, and not that one. I'll post it again...
>
>
> Posting it over and over is illustrative of the fai
On Mon, Oct 22, 2018 at 2:21 AM ag0aep6g via Digitalmars-d
wrote:
>
> On 22.10.18 10:39, Simen Kjærås wrote:
> > On Sunday, 21 October 2018 at 22:03:00 UTC, ag0aep6g wrote:
> [...]
> > It's invalid only if Atomic.badboy exists.
>
> I don't agree. I prefer the stronger @trusted. As far as I know, t
On 22/10/2018 10:28 PM, Walter Bright wrote:
On 10/22/2018 1:34 AM, Manu wrote:
I posted it, twice... 2 messages, back to back, and you're responding
to this one, and not that one. I'll post it again...
Posting it over and over is illustrative of the failure of posting
proposal documents to
On Sunday, 21 October 2018 at 22:03:00 UTC, ag0aep6g wrote:
With Manu's `shared`, there is implicit conversion from
non-`shared` to `shared`. It would essentially become a
language rule. For that rule to be sound, any access to
`shared` data must be @system. And more challengingly,
@system/@tr
On Sun, Oct 21, 2018 at 3:05 PM ag0aep6g via Digitalmars-d
wrote:
>
> It took me a while to understand Manu's idea for `shared`, and I suspect
> that it was/is the same for others. At the same time, Manu seems
> bewildered about the objections. I'm going to try and summarize the
> situation. Maybe
On 10/22/2018 1:34 AM, Manu wrote:
I posted it, twice... 2 messages, back to back, and you're responding
to this one, and not that one. I'll post it again...
Posting it over and over is illustrative of the failure of posting proposal
documents to the n.g. instead of posting it as a DIP which
On 22.10.18 10:39, Simen Kjærås wrote:
On Sunday, 21 October 2018 at 22:03:00 UTC, ag0aep6g wrote:
[...]
It's invalid only if Atomic.badboy exists.
I don't agree. I prefer the stronger @trusted. As far as I know, the
stronger one is the current one.
Essentially, since the module is the uni
On 10/22/2018 1:42 AM, Manu wrote:
You removed whatever comment you're referring to.
If your newsreader cannot find the antecedent, you badly need to use a better
one. Thunderbird handles this rather well, there's no reason to use an inferior one.
Or just click the <- button:
https://digita
On Mon, Oct 22, 2018 at 12:55 AM Walter Bright via Digitalmars-d
wrote:
>
> On 10/21/2018 11:58 AM, Timon Gehr wrote:
> > [...]
>
> Thank you, Timon, for a nice explanation of what I was trying to express.
You removed whatever comment you're referring to.
I don't understand any of Timon's posts i
On Sunday, 21 October 2018 at 22:03:00 UTC, ag0aep6g wrote:
(2) What's Wrong with That?
The @trusted contract says that an @trusted function must be
safe when called from an @safe function. That calling @safe
function might be located in the same module, meaning it might
have the same level o
Third time's the charm maybe?
- repeated, 3rd time
On Sun., 21 Oct. 2018, 2:55 am Walter Bright via Digitalmars-d,
wrote:
>
> On 10/20/2018 11:24 AM, Manu wrote:
> > This is an unfair dismissal.
>
> It has nothing at all to do with fairness. It is
On Mon, Oct 22, 2018 at 12:50 AM Walter Bright via Digitalmars-d
wrote:
>
> On 10/21/2018 5:54 PM, Manu wrote:
> > Would you please respond to my messages, and specifically, respond to
> > the code that I presented to you in response to your broken example.
> > Or any of my earlier fragments throu
On Monday, 22 October 2018 at 08:25:17 UTC, Andrea Fontana wrote:
Moreover: you're the author of the module so you're supposed to
know how it works and which members you should call or not.
- team
- maintainer of a module written by someone that works elsewhere
now.
that's two cases where st
On Sunday, 21 October 2018 at 03:17:23 UTC, 12345swordy wrote:
So that classes can share some of their variables but not
others in a module.
IE.
class A
{
internal int A; //This is shared in the module
private int B; // But not this.
}
No need to reintroduce the "Friend" feature from cpp.
A
On Sunday, 21 October 2018 at 23:50:57 UTC, 12345swordy wrote:
If the cost out way the benefits then I simply introduce the
"strict" keyword to avoid code breakage, or introduce the
optional module scoping.
-Alex
Looking at the dlang.org page about visibility attributes, the
`package` keywo
On 10/21/2018 11:58 AM, Timon Gehr wrote:
[...]
Thank you, Timon, for a nice explanation of what I was trying to express.
On 10/22/18 1:58 AM, Neia Neutuladh wrote:
Unity 7 and prior for the desktop use Nux, an OpenGL-based widget toolkit.
Unity 8 and all mobile versions of Unity use Qt. The application set that
Ubuntu shipped with Unity was, I think, heavier on the GTK+ side.
Fascinating. I'm actually shocked b
On 10/21/2018 5:54 PM, Manu wrote:
Would you please respond to my messages, and specifically, respond to
the code that I presented to you in response to your broken example.
Or any of my earlier fragments throughout this thread. I've shared
quite a few, and so far, nobody has ever produced a crit
On Sunday, 21 October 2018 at 23:50:57 UTC, 12345swordy wrote:
On Sunday, 21 October 2018 at 21:48:22 UTC, Laurent Tréguier
wrote:
On Sunday, 21 October 2018 at 17:09:05 UTC, 12345swordy wrote:
[...]
It's not "my" solution. It's D's solution. I perfectly
understand why you'd want this and I
51 matches
Mail list logo
