Re: DIP 1024---Shared Atomics---Accepted

2020-01-07 Thread Ola Fosheim Grøstad via Digitalmars-d-announce

On Wednesday, 8 January 2020 at 02:31:24 UTC, Manu wrote:
On Wed, Jan 8, 2020 at 12:20 PM Walter Bright via 
Digitalmars-d-announce  
wrote:

It will still do that, either now... or later. So, why wait?


Since @safe and shared is all syntactical in nature then all 
these problems can be avoided by just adding compiler switches:


-ignore-shared, -ignore-safe etc...



Re: DIP 1024---Shared Atomics---Accepted

2020-01-07 Thread Manu via Digitalmars-d-announce
On Wed, Jan 8, 2020 at 12:20 PM Walter Bright via
Digitalmars-d-announce  wrote:
>
> On 1/6/2020 10:17 PM, Manu wrote:
> > Well it was a preview for an unaccepted DIP, so it could have been
> > withdrawn. I guess I have increased confidence now, but it still seems
> > unnecessary to delay.
>
> Preview means for accepted DIPs as well when they break existing code.
>
> >> Don't really have a schedule at the moment. It'll likely be at least a 
> >> year.
> > A year? That's disappointing. What is the reason to delay this? It
> > doesn't break anything, and it likely fixes bugs on contact.
>
> It breaks all code that manipulates shared data directly, whether it was
> correctly written or not.

It will still do that, either now... or later. So, why wait?


Re: DIP 1024---Shared Atomics---Accepted

2020-01-07 Thread Walter Bright via Digitalmars-d-announce

On 1/6/2020 10:17 PM, Manu wrote:

Well it was a preview for an unaccepted DIP, so it could have been
withdrawn. I guess I have increased confidence now, but it still seems
unnecessary to delay.


Preview means for accepted DIPs as well when they break existing code.


Don't really have a schedule at the moment. It'll likely be at least a year.

A year? That's disappointing. What is the reason to delay this? It
doesn't break anything, and it likely fixes bugs on contact.


It breaks all code that manipulates shared data directly, whether it was 
correctly written or not.




Re: DConf 2019 Pictures

2020-01-07 Thread John Colvin via Digitalmars-d-announce

On Tuesday, 7 January 2020 at 13:37:24 UTC, Ethan wrote:

On Tuesday, 7 January 2020 at 09:04:04 UTC, Ali Çehreli wrote:

This one is Laeeth introducing Andrei at Symmetry Investments:

  http://acehreli.org/photo/dconf_2019/DSC04839.html

Ali


And if you start here you get to the important bits: BeerConf!

http://acehreli.org/photo/dconf_2019/DSC04853.html


Damn... I miss beerconf.


Re: DConf 2019 Pictures

2020-01-07 Thread Ethan via Digitalmars-d-announce

On Tuesday, 7 January 2020 at 09:04:04 UTC, Ali Çehreli wrote:

This one is Laeeth introducing Andrei at Symmetry Investments:

  http://acehreli.org/photo/dconf_2019/DSC04839.html

Ali


And if you start here you get to the important bits: BeerConf!

http://acehreli.org/photo/dconf_2019/DSC04853.html


Re: Release D 2.090.0

2020-01-07 Thread Andrea Fontana via Digitalmars-d-announce

On Tuesday, 7 January 2020 at 11:12:09 UTC, JN wrote:

Loving the JSON getter :)



Did you give jsonwrap[1] a try?


[1] https://code.dlang.org/packages/jsonwrap


Re: Release D 2.090.0

2020-01-07 Thread JN via Digitalmars-d-announce

On Tuesday, 7 January 2020 at 10:30:09 UTC, Martin Nowak wrote:

Glad to announce D 2.090.0, ♥ to the 48 contributors.

This release comes with the ability to convert lazy parameters 
to delegates, new intrinsics to force rounding to specific 
floating point precision, unittest builds that no longer 
execute main by default, a new GC.inFinalizer API, and various 
other changes.


http://dlang.org/download.html 
http://dlang.org/changelog/2.090.0.html


-Martin


Loving the JSON getter :)


Release D 2.090.0

2020-01-07 Thread Martin Nowak via Digitalmars-d-announce
Glad to announce D 2.090.0, ♥ to the 48 contributors.

This release comes with the ability to convert lazy parameters to
delegates, new intrinsics to force rounding to specific floating point
precision, unittest builds that no longer execute main by default, a new
GC.inFinalizer API, and various other changes.

http://dlang.org/download.html
http://dlang.org/changelog/2.090.0.html

-Martin


Re: Proposal for porting D runtime to WebAssembly

2020-01-07 Thread Petar via Digitalmars-d-announce
On Tuesday, 7 January 2020 at 08:17:37 UTC, Sebastiaan Koppe 
wrote:
On Sunday, 5 January 2020 at 08:24:21 UTC, Denis Feklushkin 
wrote:
On Friday, 3 January 2020 at 10:34:40 UTC, Sebastiaan Koppe 
wrote:



- reals (probably are going to be unsupported)


It seems to me for now they can be threated as double without 
any problems


Yeah, that is what I have done so far.


I believe that's the best choice even long term. `real` is 
supposed to represent the largest natively supported FP type by 
the underlying ISA. In WebAssembly that's f64, so there's no need 
emulate anything. Of course, people who need wider 
integer/fixed/floating types can use third-party libraries for 
that.
There are other platforms where D's real type is the same as 
double, so I don't see a reason to worry.


DConf 2019 Pictures

2020-01-07 Thread Ali Çehreli via Digitalmars-d-announce

This one is Laeeth introducing Andrei at Symmetry Investments:

  http://acehreli.org/photo/dconf_2019/DSC04839.html

Ali


Re: Proposal for porting D runtime to WebAssembly

2020-01-07 Thread Sebastiaan Koppe via Digitalmars-d-announce

On Saturday, 4 January 2020 at 16:28:24 UTC, kinke wrote:
On Friday, 3 January 2020 at 10:34:40 UTC, Sebastiaan Koppe 
wrote:
You can track the work here: 
https://github.com/skoppe/druntime/tree/wasm


I gave it a quick glance; looks pretty good, and like pretty 
much work. ;) - Thx.


Great. Thanks for looking.

The compiler should probably help a bit by firstly predefining 
a version `CRuntime_WASI` (either for all wasm targets, or for 
triples like wasm32-unknown-unknown-wasi) and secondly emitting 
TLS globals as regular globals for now, so that you don't have 
to add `__gshared` everywhere.


Yes. I will probably manage to do the first, but for the second 
one I definitely need some pointers.



- reals (probably are going to be unsupported)


It's probably just a matter of checking which type clang uses 
for C `long double` when targeting wasm, and making LDC use the 
same type.


Could be. I personally prefer to avoid them because wasm only 
supports f32/f64, which I guess means they will be emulated (I 
have no idea though, maybe some wasm hosts do the right thing). 
But some people might need them, so if fixing the ABI is not a 
big deal, we could include them.


- wasi libc needs to be distributed (either in source and 
compiled into wasm druntime) or statically linked


I'd prefer a static lib (and referencing that one via 
`-defaultlib=druntime-ldc,phobos2-ldc,wasi` in ldc2.conf's wasm 
section).


Good.

Building it via LDC CI for inclusion in (some?) prebuilt LDC 
packages is probably not that much of a hassle with a clang 
host compiler.


I don't think so either. I have already got it building, so I 
just need to go over my notes.



once ldc-build-druntime works


If you need some CMake help (excluding C files etc.), 
https://github.com/ldc-developers/ldc/pull/2787 might have 
something useful.


Thanks.


(_start is the wasm's equivalent of _Dmain)


Not really; _start (in libc) is used on Linux too, which sets 
up the C runtime, then calls C main, which calls druntime's 
_d_run_main which in turn calls _Dmain.


Ahh, fumbling as I go along. Thanks for the correction.


Re: Proposal for porting D runtime to WebAssembly

2020-01-07 Thread Sebastiaan Koppe via Digitalmars-d-announce

On Sunday, 5 January 2020 at 08:24:21 UTC, Denis Feklushkin wrote:
On Friday, 3 January 2020 at 10:34:40 UTC, Sebastiaan Koppe 
wrote:



- reals (probably are going to be unsupported)


It seems to me for now they can be threated as double without 
any problems


Yeah, that is what I have done so far.