Re: sumtype 0.5.0
On Wednesday, 8 August 2018 at 20:54:13 UTC, Paul Backus wrote: SumType is a generic sum type for modern D. It is meant as an alternative to `std.variant.Algebraic`. New point release, 0.5.3, with the following updates: - SumType now uses the smallest possible integer type for its tag (e.g., `ubyte` if the number of types is less than 255). - A bug involving structs with invalid .init values has been fixed.
Re: Optional and NotNull version 0.5.0 - swift optional like and scala option like
On Wednesday, 22 August 2018 at 22:11:05 UTC, aliak wrote: On Monday, 20 August 2018 at 19:52:53 UTC, jmh530 wrote: It's interesting that both sumtype and optional have match templates. Maybe scope to combine these projects? That'd be cool. Optional uses .match on a "some" or "none" range, while SumType uses it on a union. So ideas on how to go about it? In theory, Optional(T) could be implemented as a wrapper around SumType!(T, None), which would let it reuse SumType's match method. I'm not sure if it'd be worth the effort to convert at this point, though.
Re: Optional and NotNull version 0.5.0 - swift optional like and scala option like
On Monday, 20 August 2018 at 19:52:53 UTC, jmh530 wrote: On Monday, 20 August 2018 at 19:06:36 UTC, Seb wrote: [snip] That looks pretty cool! I added optional to run.dlang.io (e.g. https://run.dlang.io/is/912kVG) and the project tester (https://github.com/dlang/ci/pull/288). It's interesting that both sumtype and optional have match templates. Maybe scope to combine these projects? That'd be cool. Optional uses .match on a "some" or "none" range, while SumType uses it on a union. So ideas on how to go about it?
Re: RFC: initial release of dtoh
On 2018-08-22 13:01, Mihails wrote: https://gitlab.com/mihails.strasuns/dtoh Tool to grab all `extern(C)` declarations in a D module and generate C header file based on it. Partially addresses https://issues.dlang.org/show_bug.cgi?id=9285 but is intended to be much more simple (no C++, no human-readable emphasis). Main differences from version written by Adam some years ago: - Uses DMD frontend as a library directly - Has tests Former is quite intentional decision though I do expect it to be controversial. Using json output requires parsing information that is already present in DMD FE in a strongly typed way - and the only benefit is that the tool becomes more decoupled from compiler. In my opinion, this functionality _should_ be part of compiler itself, similar to .di generation. Sadly can't put it on code.dlang.org right now because there are no tagged versions of http://code.dlang.org/packages/dmd to depend on, thus have to resort to submodule. Iain has a PR in DMD for generating C++ headers from extern(C++) declarations [1]. Perhaps join forces on this. [1] https://github.com/dlang/dmd/pull/8591 -- /Jacob Carlborg
Re: RFC: initial release of dtoh
On Wed, 22 Aug 2018 at 04:05, Mihails via Digitalmars-d-announce wrote: > > https://gitlab.com/mihails.strasuns/dtoh > > Tool to grab all `extern(C)` declarations in a D module and > generate C header file based on it. Partially addresses > https://issues.dlang.org/show_bug.cgi?id=9285 but is intended to > be much more simple (no C++, no human-readable emphasis). > > Main differences from version written by Adam some years ago: > > - Uses DMD frontend as a library directly > - Has tests > > Former is quite intentional decision though I do expect it to be > controversial. Using json output requires parsing information > that is already present in DMD FE in a strongly typed way - and > the only benefit is that the tool becomes more decoupled from > compiler. In my opinion, this functionality _should_ be part of > compiler itself, similar to .di generation. > > Sadly can't put it on code.dlang.org right now because there are > no tagged versions of http://code.dlang.org/packages/dmd to > depend on, thus have to resort to submodule. This is very topical for me just now... but no extern(C++)?? I have some extern(C++) classes that need to have .h files generated for them. Is this a goal for the project?
Re: RFC: initial release of dtoh
On Wednesday, 22 August 2018 at 13:59:35 UTC, Sönke Ludwig wrote: Can't we at least use something like "0.0.1-dmd-2.080.0" that is sure to not interfere with any official scheme that might be decided on later? Sounds like a good workaround, though it does have to actually be present as a tag in DMD repo as far as I understand and it will definitely confuse the hell out of random by-passers.
Re: D support for ChromeOS
On Wednesday, 22 August 2018 at 10:28:32 UTC, Joakim wrote: It's up: $ apt search ldc Sorting... Done Full Text Search... Done ipcalc/stable 0.41 aarch64 Calculates IP broadcast, network, Cisco wildcard mask, and host ranges ldc/stable 1.11.0 aarch64 D programming language compiler, built with LLVM http://termux.net/dists/stable/main/binary-aarch64/ It is downloading now at 37 % :-), Thank you!
Re: RFC: initial release of dtoh
Am 22.08.2018 um 15:59 schrieb Sönke Ludwig: Am 22.08.2018 um 14:32 schrieb Mihails: On Wednesday, 22 August 2018 at 11:51:59 UTC, Seb wrote: Yeah, the dub registry is "smart" enough to reject all tags from the dmd repository as they all don't conform with SemVer. There has been a long discussion on this (https://forum.dlang.org/post/drcekmxvfszpwifbu...@forum.dlang.org), but sadly it seems that no consensus has been reached. This is a bit sad, because that means no stable tool can be built to use DMD FE as a library as long as it want to be available via code.dlang.org (also afair branch dependencies are deprecated in dub itself now). For dtoh it is probably less of a problem as I intend to propose it for inclusion in dmd if it proves itself good enough in production, but it feels like a missed opportunity overall. Can't we at least use something like "0.0.1-dmd-2.080.0" that is sure to not interfere with any official scheme that might be decided on later? correction: "0.0.1+dmd-2.080.0"
Re: RFC: initial release of dtoh
Am 22.08.2018 um 14:32 schrieb Mihails: On Wednesday, 22 August 2018 at 11:51:59 UTC, Seb wrote: Yeah, the dub registry is "smart" enough to reject all tags from the dmd repository as they all don't conform with SemVer. There has been a long discussion on this (https://forum.dlang.org/post/drcekmxvfszpwifbu...@forum.dlang.org), but sadly it seems that no consensus has been reached. This is a bit sad, because that means no stable tool can be built to use DMD FE as a library as long as it want to be available via code.dlang.org (also afair branch dependencies are deprecated in dub itself now). For dtoh it is probably less of a problem as I intend to propose it for inclusion in dmd if it proves itself good enough in production, but it feels like a missed opportunity overall. Can't we at least use something like "0.0.1-dmd-2.080.0" that is sure to not interfere with any official scheme that might be decided on later?
Re: RFC: initial release of dtoh
On Wednesday, 22 August 2018 at 11:51:59 UTC, Seb wrote: Yeah, the dub registry is "smart" enough to reject all tags from the dmd repository as they all don't conform with SemVer. There has been a long discussion on this (https://forum.dlang.org/post/drcekmxvfszpwifbu...@forum.dlang.org), but sadly it seems that no consensus has been reached. This is a bit sad, because that means no stable tool can be built to use DMD FE as a library as long as it want to be available via code.dlang.org (also afair branch dependencies are deprecated in dub itself now). For dtoh it is probably less of a problem as I intend to propose it for inclusion in dmd if it proves itself good enough in production, but it feels like a missed opportunity overall.
Re: RFC: initial release of dtoh
On Wednesday, 22 August 2018 at 11:01:02 UTC, Mihails wrote: https://gitlab.com/mihails.strasuns/dtoh Cool!! Sadly can't put it on code.dlang.org right now because there are no tagged versions of http://code.dlang.org/packages/dmd to depend on, thus have to resort to submodule. Yeah, the dub registry is "smart" enough to reject all tags from the dmd repository as they all don't conform with SemVer. There has been a long discussion on this (https://forum.dlang.org/post/drcekmxvfszpwifbu...@forum.dlang.org), but sadly it seems that no consensus has been reached.
RFC: initial release of dtoh
https://gitlab.com/mihails.strasuns/dtoh Tool to grab all `extern(C)` declarations in a D module and generate C header file based on it. Partially addresses https://issues.dlang.org/show_bug.cgi?id=9285 but is intended to be much more simple (no C++, no human-readable emphasis). Main differences from version written by Adam some years ago: - Uses DMD frontend as a library directly - Has tests Former is quite intentional decision though I do expect it to be controversial. Using json output requires parsing information that is already present in DMD FE in a strongly typed way - and the only benefit is that the tool becomes more decoupled from compiler. In my opinion, this functionality _should_ be part of compiler itself, similar to .di generation. Sadly can't put it on code.dlang.org right now because there are no tagged versions of http://code.dlang.org/packages/dmd to depend on, thus have to resort to submodule.
Re: D support for ChromeOS
On Wednesday, 22 August 2018 at 10:06:39 UTC, Joakim wrote: On Wednesday, 22 August 2018 at 07:14:22 UTC, Martin Tschierschke wrote: On Wednesday, 22 August 2018 at 01:56:45 UTC, Joakim wrote: unning. [...] Oh, I forgot, if you're running Android apps in your Chromebook, you can install the Termux app and use LDC through there: https://play.google.com/store/apps/details?id=com.termux&hl=en The first AArch64 build of LDC for Termux should be up in a day or so, `apt install ldc`, or you can build it from source in Termux, if you can't wait. ;) +1 ; Cool, not sure if I can wait, but probably I will :-) I must say I really like looking at this version string, straight from the Termux app: $ ldc2 --version LDC - the LLVM D compiler (1.11.0): based on DMD v2.081.2 and LLVM 6.0.1-2 built with LDC - the LLVM D compiler (1.11.0) Default target: aarch64--linux-android Host CPU: cortex-a73 http://dlang.org - http://wiki.dlang.org/LDC Registered Targets: aarch64- AArch64 (little endian) aarch64_be - AArch64 (big endian) arm- ARM arm64 - ARM64 (little endian) armeb - ARM (big endian) thumb - Thumb thumbeb- Thumb (big endian) x86- 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 It's up: $ apt search ldc Sorting... Done Full Text Search... Done ipcalc/stable 0.41 aarch64 Calculates IP broadcast, network, Cisco wildcard mask, and host ranges ldc/stable 1.11.0 aarch64 D programming language compiler, built with LLVM http://termux.net/dists/stable/main/binary-aarch64/
Re: D support for ChromeOS
On Wednesday, 22 August 2018 at 07:14:22 UTC, Martin Tschierschke wrote: On Wednesday, 22 August 2018 at 01:56:45 UTC, Joakim wrote: unning. [...] Oh, I forgot, if you're running Android apps in your Chromebook, you can install the Termux app and use LDC through there: https://play.google.com/store/apps/details?id=com.termux&hl=en The first AArch64 build of LDC for Termux should be up in a day or so, `apt install ldc`, or you can build it from source in Termux, if you can't wait. ;) +1 ; Cool, not sure if I can wait, but probably I will :-) I must say I really like looking at this version string, straight from the Termux app: $ ldc2 --version LDC - the LLVM D compiler (1.11.0): based on DMD v2.081.2 and LLVM 6.0.1-2 built with LDC - the LLVM D compiler (1.11.0) Default target: aarch64--linux-android Host CPU: cortex-a73 http://dlang.org - http://wiki.dlang.org/LDC Registered Targets: aarch64- AArch64 (little endian) aarch64_be - AArch64 (big endian) arm- ARM arm64 - ARM64 (little endian) armeb - ARM (big endian) thumb - Thumb thumbeb- Thumb (big endian) x86- 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64
Re: D support for ChromeOS
On Wednesday, 22 August 2018 at 01:56:45 UTC, Joakim wrote: unning. [...] Oh, I forgot, if you're running Android apps in your Chromebook, you can install the Termux app and use LDC through there: https://play.google.com/store/apps/details?id=com.termux&hl=en The first AArch64 build of LDC for Termux should be up in a day or so, `apt install ldc`, or you can build it from source in Termux, if you can't wait. ;) +1 ; Cool, not sure if I can wait, but probably I will :-)
