Re: Release D 2.089.0
On Wednesday, 6 November 2019 at 01:16:00 UTC, Manu wrote: On Tue, Nov 5, 2019 at 5:14 PM Manu wrote: On Tue, Nov 5, 2019 at 1:20 PM John Chapman via Digitalmars-d-announce wrote: > > On Tuesday, 5 November 2019 at 19:05:10 UTC, Manu wrote: > > Incidentally, in your sample above there, `a` and `b` are > > not shared... why not just write: `cas(, null, b);` ?? > > If source data is not shared, you shouldn't cast to shared. > > Because casts were needed in 2.088 and earlier and I just > updated to 2.089, unaware of the API change. Should I log > `null` not working as a bug? Yes But I also think you should update your code to not perform the casts. Can you confirm that the null works when removing the shared casts? Yes and no - it compiles when removing the casts, but AVs at runtime. Bug filed: https://issues.dlang.org/show_bug.cgi?id=20359
Re: Release D 2.089.0
On Tuesday, 5 November 2019 at 19:05:10 UTC, Manu wrote: On Mon, Nov 4, 2019 at 11:55 PM John Chapman via Digitalmars-d-announce wrote: [...] [...] The keyword of share is really annoying for a class。
Re: Release D 2.089.0
On Tuesday, 5 November 2019 at 07:52:12 UTC, John Chapman wrote:
On Tuesday, 5 November 2019 at 06:44:29 UTC, Manu wrote:
On Mon., 4 Nov. 2019, 2:05 am John Chapman via
Digitalmars-d-announce, <
digitalmars-d-announce@puremagic.com> wrote:
[...]
Changes were made because there were a lot of problems with
that module...
but the (reasonably comprehensive) unit tests didn't reveal
any such
regressions. We also build+test many popular OSS projects via
buildkite,
and there weren't problems.
Can you show the broken code?
Sure - this AVs on DMD 2.088 Windows:
import core.atomic;
void main() {
Object a, b = new Object;
cas(cast(shared), null, cast(shared)b);
}
There are some bugs in cas. See here:
https://issues.dlang.org/show_bug.cgi?id=20354
https://issues.dlang.org/show_bug.cgi?id=20355
Re: Release D 2.089.0
On Tue, Nov 5, 2019 at 5:14 PM Manu wrote: > > On Tue, Nov 5, 2019 at 1:20 PM John Chapman via Digitalmars-d-announce > wrote: > > > > On Tuesday, 5 November 2019 at 19:05:10 UTC, Manu wrote: > > > Incidentally, in your sample above there, `a` and `b` are not > > > shared... why not just write: `cas(, null, b);` ?? If source > > > data is not shared, you shouldn't cast to shared. > > > > Because casts were needed in 2.088 and earlier and I just updated > > to 2.089, unaware of the API change. Should I log `null` not > > working as a bug? > > Yes But I also think you should update your code to not perform the casts. Can you confirm that the null works when removing the shared casts?
Re: Release D 2.089.0
On Tue, Nov 5, 2019 at 1:20 PM John Chapman via Digitalmars-d-announce wrote: > > On Tuesday, 5 November 2019 at 19:05:10 UTC, Manu wrote: > > Incidentally, in your sample above there, `a` and `b` are not > > shared... why not just write: `cas(, null, b);` ?? If source > > data is not shared, you shouldn't cast to shared. > > Because casts were needed in 2.088 and earlier and I just updated > to 2.089, unaware of the API change. Should I log `null` not > working as a bug? Yes
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Tuesday, 5 November 2019 at 12:20:04 UTC, Jacob Carlborg wrote: On Tuesday, 5 November 2019 at 11:49:20 UTC, Daniel Kozak wrote: Generally no, because Apline use musl libc instead of glibc, so there are some issues with that The correct way is to use static linking and putting only the binary in a Docker image, i.e. "from scratch" [1] ;). But using Alpine and musl will help with building the binary. [1] https://hub.docker.com/_/scratch And the neat way to do that is with a multi-stage build: one Dockerfile, with an Alpine container building the binary, then copying to a FROM scratch container: https://docs.docker.com/develop/develop-images/multistage-build/ The musl build is practically necessary because glibc has effectively given up standalone static binary support. So, thanks BPF Korea :)
Re: Release D 2.089.0
On Tuesday, 5 November 2019 at 19:05:10 UTC, Manu wrote: Incidentally, in your sample above there, `a` and `b` are not shared... why not just write: `cas(, null, b);` ?? If source data is not shared, you shouldn't cast to shared. Because casts were needed in 2.088 and earlier and I just updated to 2.089, unaware of the API change. Should I log `null` not working as a bug?
LDC 1.19.0-beta1
Glad to announce the first beta for LDC 1.19: * Based on D 2.089.0. * Slight codegen improvements, incl. a breaking extern(D) ABI change for Posix x86[_64] targets, and dead branch elimination for if statements with constant condition (in the hopes of possibly increasing compilation speed). * Fixed misc. CMake issues with some LLVM 9 configurations. * Default Posix linker driver is now `cc` instead of `gcc`. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.19.0-beta1 Please help test, and thanks to all contributors!
Re: Release D 2.089.0
On Mon, Nov 4, 2019 at 11:55 PM John Chapman via
Digitalmars-d-announce wrote:
>
> On Tuesday, 5 November 2019 at 06:44:29 UTC, Manu wrote:
> > On Mon., 4 Nov. 2019, 2:05 am John Chapman via
> > Digitalmars-d-announce, < digitalmars-d-announce@puremagic.com>
> > wrote:
> >
> >> Something has changed with core.atomic.cas - it used to work
> >> with `null` as the `ifThis` argument, now it throws an AV. Is
> >> this intentional?
> >>
> >> If I use `cast(shared)null` it doesn't throw but if the change
> >> was deliberate shouldn't it be mentioned?
> >>
> >
> > Changes were made because there were a lot of problems with
> > that module...
> > but the (reasonably comprehensive) unit tests didn't reveal any
> > such
> > regressions. We also build+test many popular OSS projects via
> > buildkite,
> > and there weren't problems.
> > Can you show the broken code?
>
> Sure - this AVs on DMD 2.088 Windows:
>
> import core.atomic;
> void main() {
>Object a, b = new Object;
>cas(cast(shared), null, cast(shared)b);
> }
Oh... a class.
Yeah, that's an interesting case that I actually noted had a low
testing surface area.
It's also theoretically broken; despite what's practical, I think it's
improperly spec-ed that shared classes can be used with atomics.
With a struct, you can declare `shared(T)* s_ptr`, but with classes
you can only `shared(C) c_ptr`, where the difference is that `s_ptr`
can be read/written... but `c_ptr` is typed such that the pointer
itself is shared (because classes are implicitly a pointer), so that
`c_ptr` can't be safely read/write-able...
So, I actually think that atomic API is mal-formed, and it should not
support `shared` arguments, but I tried to preserve existing
behaviour, while being more strict about what is valid. I obviously
missed something with `null` here.
Incidentally, in your sample above there, `a` and `b` are not
shared... why not just write: `cas(, null, b);` ?? If source data is
not shared, you shouldn't cast to shared.
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Monday, 28 October 2019 at 19:23:30 UTC, jmh530 wrote: they are all const. That there is only one mutable way to access data sounds like restrict to me. Well, if you add the constraint that there also is no const way to access the data. But unique ownership is stricter than «restrict», which only guarantees that there is no aliasing (overlapping) between the pointed-too-memory. No guarantees for there not being other pointers to the same memory. It is basically only significant when accessing arrays, like when you are calling a function with two windows onto the same array. Proving that the two windows don't overlap is not always possible without a performance loss. Being able to tell the compiler that there is no overlap makes sense when doing inline updates in an array, so that the compiler can restructure instructions and use SIMD. Without restrict you would often have to write the single array element before reading another (as they could point to the same memory location). BUT «restrict» is very crude. It would probably be better to provide more narrow guarantees (e.g. «the offset between the two pointers is at least 16 bytes»).
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Monday, 28 October 2019 at 21:53:50 UTC, Walter Bright wrote: I've always known it was a bad idea (not just me, it was common knowledge). People have a hard time understanding restrict, and are guaranteed to use it wrong. Let alone errors using it from people who do understand it. Compiler enforcement is the only way to make it go. It isn't possible to prove it for a compiler in many cases. Not without full verification, and even then it is hard. So yeah, having it is good, but requiring it isn't competitive (vs C restrict).
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Tuesday, 5 November 2019 at 02:16:28 UTC, Mathias Lang wrote: At BPF Korea, we're working on a blockchain written in D Hello, Sorry if this has been said already: would you consider being listed in https://dlang.org/orgs-using-d.html? Thanks
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
Am 05.11.2019 um 10:48 schrieb Petar Kirov [ZombineDev]: On Tuesday, 5 November 2019 at 02:16:28 UTC, Mathias Lang wrote: [..] That's great news! Thanks a lot for your hard work! # Note: This will redownload your dependencies every time, which doesn't play well with docker I have been meaning to add a docker and CI friendly command to dub that fetches all dependencies without building them. In the Node.js world they have the `npm ci` [0] command. [0]: https://docs.npmjs.com/cli/ci.html Sounds like "dub upgrade --missing-only" will do that, as it implicitly downloads all dependencies in addition to filling the (non-existent in this case) gaps.
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Tuesday, 5 November 2019 at 11:49:20 UTC, Daniel Kozak wrote: Generally no, because Apline use musl libc instead of glibc, so there are some issues with that The correct way is to use static linking and putting only the binary in a Docker image, i.e. "from scratch" [1] ;). But using Alpine and musl will help with building the binary. [1] https://hub.docker.com/_/scratch
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Tue, Nov 5, 2019 at 12:05 PM Dejan Lekic via Digitalmars-d-announce wrote: > > On Tuesday, 5 November 2019 at 02:16:28 UTC, Mathias Lang wrote: > > Hi all, > > Recently there have been inquiries about support for D on > > Alpine Linux, a distribution mostly used in combination with > > Docker to create lightweight container images for microservices. > > > > At BPF Korea, we're working on a blockchain written in D, and > > wanted to be able to easily test and distribute our node using > > Alpine images, but there was no package for it yet. > > I am confused... Why do you need LDC, DMD, dub, etc on Alpine? > Can't you build it anywhere and just put the final artifact (or > set of artifacts) inside an Alpine-based container? Generally no, because Apline use musl libc instead of glibc, so there are some issues with that
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Tuesday, 5 November 2019 at 02:16:28 UTC, Mathias Lang wrote: Hi all, Recently there have been inquiries about support for D on Alpine Linux, a distribution mostly used in combination with Docker to create lightweight container images for microservices. At BPF Korea, we're working on a blockchain written in D, and wanted to be able to easily test and distribute our node using Alpine images, but there was no package for it yet. I am confused... Why do you need LDC, DMD, dub, etc on Alpine? Can't you build it anywhere and just put the final artifact (or set of artifacts) inside an Alpine-based container?
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Tuesday, 5 November 2019 at 02:16:28 UTC, Mathias Lang wrote: [..] That's great news! Thanks a lot for your hard work! # Note: This will redownload your dependencies every time, which doesn't play well with docker I have been meaning to add a docker and CI friendly command to dub that fetches all dependencies without building them. In the Node.js world they have the `npm ci` [0] command. [0]: https://docs.npmjs.com/cli/ci.html
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Tuesday, 5 November 2019 at 02:16:28 UTC, Mathias Lang wrote: Hi all, Recently there have been inquiries about support for D on Alpine Linux, a distribution mostly used in combination with Docker to create lightweight container images for microservices. [...] This is great! Much thanks to all for all the work towards this!
