Re: LDC 1.31.0
On Saturday, 11 February 2023 at 13:47:54 UTC, kinke wrote: Glad to announce LDC 1.31.0. Major changes: * Based on D 2.101.2. * ImportC: The C preprocessor isn't invoked yet. * mac/iOS arm64: Linking with `-g` is working again without unaligned pointer warnings/errors. * *Preliminary* support for LLVM 15. Thanks @jamesragray for helping out! * Initial ABI support for 64-bit RISC-V. Thanks @Ast-x64! Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.31.0 Thanks to all contributors & sponsors! Wonderful! Thanks for all the effort you're putting into LDC!
Re: Release D 2.102.0
On Friday, 3 February 2023 at 08:33:26 UTC, Max Samukha wrote: BTW, check out another case of D violating the "if in an invalid state, die" precept. The following code not only runs the upstream destructor (which depends on successful completion of the downstream one), but does that in an infinite loop: [...] Yep, it's a regression: https://issues.dlang.org/show_bug.cgi?id=23164
Re: Release D 2.101.0
On Tuesday, 15 November 2022 at 20:54:03 UTC, Iain Buclaw wrote: Glad to announce D 2.101.0, ♥ to the 63 contributors. This release comes with shortened method syntax enabled by default, new bit-field support added as a preview feature, a new `std.typecons.SafeRefCounted` type that can be used in `@safe`, numerous improvements to dub (including colorized output), and many more. http://dlang.org/download.html http://dlang.org/changelog/2.101.0.html -Iain on behalf of the Dlang Core Team Thanks a lot for getting this through the finish line! Release management is an essential part of our ecosystem and a thankless job. And thanks a lot to Martin Nowak for his many years of stewardship and the much improved process he pioneered.
Re: New WIP DUB documentation
On Thursday, 18 August 2022 at 20:00:10 UTC, Bastiaan Veelo wrote: That's already possible, as unrecognised items are ignored. Actually, from next version, dub will start to warn you (in dub.json) about unknown keys. It does catch quite a lot of mistakes, see https://github.com/dlang/dub/pull/2280#issuecomment-1223326664
D-YAML v0.9.0 released (DIP1000 compatibility)
Hi everyone, A few days ago, I released [v0.9.0](https://github.com/dlang-community/D-YAML/releases/tag/v0.9.0) of D-YAML. D-YAML is the most used package for parsing YAML file, and part of dlang-community. This new release makes the library compatible with DIP1000, which required getting rid of Variant (but forking `std.sumtype`).
Vibe.d v0.9.5 released!
Hi everyone, A new version of Vibe.d has been released today. You can see the list of changes [on Github](https://github.com/vibe-d/vibe.d/releases/tag/v0.9.5). Of particular interest to me is the bump of the deimos/OpenSSL dependency to v3.x.x. deimos/OpenSSL v3.x.x is something I worked on a few months ago when Ubuntu 22.04, which includes OpenSSL3 was released. The code in Deimos is now compatible with all OpenSSL versions (v1.0.2 through v3), removing the need for a lot of workaround OpenSSL users previous needed to support multiple versions. With this version, projects depending on Vibe.d and using OpenSSL directly can upgrade to the newest version and take full advantage of it. And if you're an Ubuntu 22.04 user, or need to support it, it will make your life a whole lot simpler! Note that while using dub, the OpenSSL version is auto-detected. If that detection fails, or if you are using another build system (or want to force a specific version), make sure to check [the compatibiliy guide](https://github.com/D-Programming-Deimos/openssl#compatibility) of deimos/OpenSSL.
Re: DConf 2022 in London?
On Tuesday, 15 February 2022 at 12:22:05 UTC, Mike Parker wrote: Yes! Thanks to Symmetry Investments, DConf 2022 is happening in London Aug 1-4. I'll have the web site up soon (waiting to make sure there's no issue with our logo), but I wanted to get the news out ASAP since I have permission now to announce it. [...] Looking forward to it! See you all there.
Re: Added copy constructors to "Programming in D"
On Thursday, 10 February 2022 at 02:39:11 UTC, Ali Çehreli wrote: Yeah, that issue bugs me a little. Ali I think an *immediate* improvement we could make to ease people's life is to make `auto` peel the outermost qualifier level inside functions. So that: ```D const int* ptr; auto p2 = ptr; static assert(is(typeof(p2) == const(int)*)); ``` I really can't think of any downside to it, only upsides: - It is still predictable / consistent; - It *might* reduce the number of template instantiations in some cases; - It just flows more naturally... If you want full constness, there's still `const`; Likewise, I've been tinkering with having `const* p2 = ptr` to allow `p2` to be mutated. But it has far more implications and the benefits aren't as clear. For `auto`, I think the case is pretty straightforward. Fun fact: C++ mangling actually does that. ```D extern(C++) void foo (const int a); extern(C++) void bar (int a); pragma(msg, foo.mangleof); // _Z3fooi not _Z3fooKi pragma(msg, bar.mangleof); // _Z3bari ``` P.S: Thanks for spreading the love about `-preview=in`. I haven't moved forward with enabling it by default yet, because it just does exactly what we want it to do and has never bothered us, so we tend to forget it's not the default. I shall however start to move ahead now that the switch has been available for a few releases.
Re: D Language Quarterly Meeting Summary for January 2021
On Friday, 21 January 2022 at 12:55:58 UTC, ag0aep6g wrote:
On 21.01.22 13:33, Mike Parker wrote:
### Mathias
Mathias would very much like to see the unification of
delegates and function pointers. There was general agreement
that this is a good goal to aim for. Mathias subsequently
informed me he will look into it once some other things are
off his TODO list if no one else gets to it first.
I still believe it should be fairly simple:
https://forum.dlang.org/post/ofc0lj$2u4h$1...@digitalmars.com
Actually, the idea I had in mind is a little different.
Because a delegate is essentially:
```D
T function (T, Args..)(void* ctx, Args args)
```
It should be possible for the compiler to generate a call to a
trampoline function that just forwards to the actual function:
```D
RT _d_trampoline (FT, RT, Args..)(void* ctx, Args args)
{
return (cast(FT) ctx)(args);
}
```
Re: D Language Foundation Quarterly Meeting, October 2021
On Monday, 8 November 2021 at 21:48:03 UTC, Kagamin wrote: On Friday, 5 November 2021 at 11:57:40 UTC, Mike Parker wrote: `-preview=in` will not be killed. It needs to be changed such that: * `in` always means `const scope ref`; the compiler will not attempt to pass by value based on platform-specific heuristics. What about C functions? The ABI changes. `in` doesn't exist in C. All DRuntime bindings have been switched not to use `in` AFAIK (I'll do another pass on druntime / Phobos when my other changes are ready). There's a PR to disable it for non D/C++: https://github.com/dlang/dmd/pull/12242 but that was before this meeting.
Re: New library: argparse, for parsing CLI arguments
On Wednesday, 13 October 2021 at 11:27:40 UTC, Andrey Zherikov wrote: Hi everyone, I'm happy to announce that I've published a CLI argument parsing library - [argparse](https://code.dlang.org/packages/argparse). It's been around for some time already so please take a look and provide your feedback if you haven't done so. The reasoning to create one more CLI parsing library is that the existing libraries do not provide enough flexibility in parsing that I'm looking for and/or they depend on other libraries. As a result `argparse` supports wide variety of data types including enums, callbacks and arrays as well as a fully customized argument parsing. It also doesn't depend on anything besides the standard library. Since it's in active development (activeness depends on my availability of course), I have few things to do before making the first major release so stay tuned and/or contribute if you'd like to. Very interesting! I was looking for something similar recently, will definitely give it a try! One thing that it'd be interested to see would be subcommand support. Check what DUB is doing for example.
Re: LDC 1.26.0
On Wednesday, 28 April 2021 at 15:30:58 UTC, kinke wrote: Glad to announce LDC 1.26: * Based on D 2.096.1+. * Fixes a v1.25 regression wrt. corrupt `TypeInfo_Interface.info`. * Some more fixes and dcompute improvements. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.26.0 Thanks to all contributors & sponsors! Thanks a lot for your work on this Martin! We exclusively use LDC, and we're really looking forward to be able to use non-POD C++ types by value across language boundaries, and finally use `-checkaction=context`!
Re: LDC 1.25.0
On Thursday, 25 February 2021 at 19:57:04 UTC, Dennis wrote: In the PR you mentioned tracy*, but I'm still looking at how to compile it for Linux since the release only seems to include Windows binaries. I guess I'll try it out on Windows first. *https://github.com/ldc-developers/ldc/pull/3624#issuecomment-735446453 If it's the regular client, then just cd to https://github.com/wolfpld/tracy/tree/master/profiler/build/unix and run `make`. We use it on Linux without problem, but the profiler crashes on Mac OSX ATM.
Re: LDC 1.25.0
On Sunday, 21 February 2021 at 18:26:38 UTC, kinke wrote: Glad to announce LDC 1.25 - some highlights: - Based on D 2.095.1. - LLVM for prebuilt packages bumped to v11.0.1; support added for LLVM 11.1 and upcoming 12.0. - Profile/trace LDC invocations via --ftime-trace. - New Windows installer and native 'Apple silicon' package. - New experimental template emission scheme for -linkonce-templates. This option can significantly accelerate compilation times for optimized builds (e.g., 56% faster on my box when compiling the optimized Phobos unittests). Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.25.0 Thanks to all contributors & sponsors! Amazing! We were really looking forward to this release, as it makes both Alpine Linux and `-preview=in` finally usable for us, and will allow us to build some useful tools on top of the GC. Many thanks for your continuous efforts in maintaining the project!
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 13:48:52 UTC, angel wrote: On Wednesday, 6 January 2021 at 09:24:28 UTC, Mike Parker wrote: The Feedback Thread is here: https://forum.dlang.org/post/qglydztoqxhhcurvb...@forum.dlang.org Why not "int[auto] arr = [1, 2, 3]" ? IMHO auto keyword is less ambiguous than $. Someone else could misunderstand `auto` to mean partial type deduction on associative array, e.g. `int[auto] arr = ["Hello": ubyte(1), "World": ubyte(2)];`. Personally, I think `$` is very natural here, but I also didn't consider `auto` before.
Re: Release Candidate [was: Re: Beta 2.095.0]
On Wednesday, 30 December 2020 at 14:23:39 UTC, Paolo Invernizzi wrote: On Wednesday, 30 December 2020 at 10:51:38 UTC, Martin Nowak wrote: On Sunday, 20 December 2020 at 13:21:46 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.095.0 release, ♥ to the 61 contributors. The release candidate for 2.095.0 is live now. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.095.0.html As usual please report any bugs at https://issues.dlang.org -Martin Thank you Mathias for commit 5f701dc! Unfortunately it doesn't fix the exact case you found, it was a byproduct of working on your test case. And I don't think I'll have time to get to it before the release (which is scheduled January 1st).
Re: Beta 2.095.0
On Monday, 28 December 2020 at 20:22:50 UTC, Per Nordlöw wrote: On Sunday, 20 December 2020 at 13:21:46 UTC, Martin Nowak wrote: http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.095.0.html Feature https://dlang.org/changelog/2.095.0.html#better-vtemplates was already added at https://dlang.org/changelog/2.094.0.html#better-vtemplates Shall I fix? Yes please! And thanks for paying attention to the changelog, it matters a lot!
Re: Beta 2.095.0
On Thursday, 24 December 2020 at 21:59:31 UTC, Paolo Invernizzi wrote: My point is that the result without -de is [...] Which unfortunately is pretty useless in my case ... Could you point me towards the code that triggers this ?
Re: Beta 2.095.0
On Thursday, 24 December 2020 at 11:38:11 UTC, Paolo Invernizzi
wrote:
The point is that the deprecation is coming from an external
library, it would be great to have the precise instantiation
point in that source code, so I was wondering if that dmd
improvement [1] should print a more detailed trace.
[1] https://dlang.org/changelog/2.095.0.html#deprecation-context
It does print a detailed stack trace (up to the first symbol that
is not a template) if you don't use `-de`. If you use `-de`,
since the checks in Phobos are `is(typeof(n.toString()))` or
`__traits(compiles, n.toString())`, then it just changes whether
or not the code compiles, and as a result changes the output of
the program. A trivial example:
```
import std.stdio, std.typecons;
struct Foo {
deprecated string toString() const { return "Oops"; }
}
void main () { writefln("%s", Foo.init); }
```
Will print, with v2.094.2 or before (dmd -run):
```
/usr/local/opt/dmd/include/dlang/dmd/std/format.d(3921):
Deprecation: function foo.Foo.toString is deprecated
/usr/local/opt/dmd/include/dlang/dmd/std/format.d(4053):
Deprecation: function foo.Foo.toString is deprecated
Oops
```
Not great. If you use `dmd -de -run`, you'll get:
```
Foo()
```
Notice the deprecations are gone, but so is the usage of the
`toString` method. Using DMD v2.095.0-beta.1 with `-de` should
give you the same output, but without `-de`:
```
% ~/dlang/dmd-2.095.0-beta.1/osx/bin/dmd -run foo.d
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(3921):
Deprecation: function foo.Foo.toString is deprecated
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(4420):
instantiated from here: hasToString!(Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(4053):
Deprecation: function foo.Foo.toString is deprecated
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(4430):
instantiated from here: formatObject!(LockingTextWriter, Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(1875):
instantiated from here: formatValueImpl!(LockingTextWriter, Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/format.d(576):
instantiated from here: formatValue!(LockingTextWriter, Foo, char)
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/stdio.d(1661):
... (1 instantiations, -v to show) ...
/Users/geod24/dlang/dmd-2.095.0-beta.1/osx/bin/../../src/phobos/std/stdio.d(4271):
instantiated from here: writefln!(char, Foo)
foo.d(5):instantiated from here: writefln!(char, Foo)
Oops
```
So the feature works as intended, however `-de` is a dangerous
trap, as it changes what is instantiated.
Re: Beta 2.095.0
On Wednesday, 23 December 2020 at 15:38:17 UTC, Steven Schveighoffer wrote: What is happening is that some speculative compilation is checking something via the get function. It might not make a difference, but the error message is useless (who knows where that traits call is triggered). FYI, v2.095.0 *should* print the instantiation trace, so you can actually track down where it comes from. And the reason DMD now shows the trace is exactly because of this deprecation. Most likely, it doesn't change anything. Therefore when you turn on the deprecation as an error, it doesn't affect compilation, it just fails in the speculation instead of succeeds. But the ultimate result doesn't actually change anything. I can't wait until this deprecation has been finalized, because I hate seeing seas of deprecation messages I can't do anything about. 2.097 cannot come soon enough... FYI, in theory we could use `__traits(isDeprecated)` to silence this. But I haven't looked at the code myself.
Re: LDC 1.24.0
On Saturday, 24 October 2020 at 15:11:08 UTC, kinke wrote: Glad to announce LDC 1.24 - some highlights: - Based on D 2.094.1+. - Support for LLVM 11. The prebuilt packages use v11.0.0, and the x86 packages newly include the LLVM backend for AMD GPUs. - Experimental support for targeting macOS on 64-bit ARM. The macOS package includes prebuilt druntime/Phobos libraries for cross-compilation via `-mtriple=arm64-apple-macos`. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.24.0 Thanks to all contributors & sponsors! Thanks for all your work on this and the great releases!
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 16:47:37 UTC, Meta wrote: This seems ridiculous to me. We now have ANOTHER way of asking the compiler to choose for us whether to pass by ref or by value, completely mutually exclusive of auto ref. Where was the DIP (apologies if I just didn't see it)? Did Walter approve this? How do we explain the difference between in and auto ref with (as Andrei would say) a straight face? Yes we have a 3rd way. Because `auto ref` just doesn't cut it for most usages, and `-preview=rvaluerefparam` never worked. You can have a look at the full discussion in the PR that introduced it (dmd#11000). I try to summarize a few arguments in favor of it here: https://github.com/dlang/dmd/pull/11000#issuecomment-674498704 As you can see from the discussion, it's not really something that was quickly merged, but the results of months of work. So while it might seems "ridiculous" to you, I'd appreciate if you could take the time to read through the discussion, as well as taking a look at Herb Sutter's presentation which was linked. The key takeaway from that presentation is that instead of having the users specify *how* to pass the parameter, they should specify what is the parameter's semantic. In our case, input (in), output (out), or input/output (ref). I'm not aware of a situation where you want to use `auto ref` on a parameter without `const` (or `const` semantic), because if you intend to modify the parameter, you need to be sure whether it's `ref` or not. I'm aware some people use it for forwarding but this has its own set of problem.
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 07:02:12 UTC, Imperatorn wrote: On Sunday, 27 September 2020 at 19:20:34 UTC, Daniel N wrote: On Saturday, 26 September 2020 at 22:12:17 UTC, Imperatorn wrote: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Hurrah! Yay! "-preview=in" is beyond epic! I like epic things. What does it do? :D Author here. The most complete way to know would be to read the changelog: https://dlang.org/changelog/2.094.0.html#preview-in The TL;DR is that, in addition to `const scope`, `in` now automatically behaves as `ref` when "it makes sense" such as large value types or presence of destructors / postblit (more details in the changelog!) and will accept rvalues, unlike other ref parameters.
Re: Symmetry Investments and the D Language Foundation are Hiring
On Tuesday, 1 September 2020 at 09:09:36 UTC, Jacob Carlborg wrote: On Sunday, 30 August 2020 at 14:13:36 UTC, Mike Parker wrote: Looking for a full-time or part-time gig? Not only is Symmetry Investments hiring D programmers, they are also generously funding two positions for ecosystem work under the D Language Foundation. And they've put up a bounty for a new DUB feature. Read all about it here: https://dlang.org/blog/2020/08/30/symmetry-investments-and-the-d-language-foundation-are-hiring/ As an alternative to use SHA-1 hashing. There's the option to have a daemon running the background listing on filesystem events. BTW, is timestamps vs SHA-1 hashing really the most pressing issue with Dub? -- /Jacob Carlborg Agreed. A server approach would probably scale much better, if the intent is to speed up the developer's CTR cycle. But in any case, thanks to Symmetry for doing this! This is huge.
Re: Beta 2.093.1
On Monday, 24 August 2020 at 08:08:52 UTC, Martin Nowak wrote: On Thursday, 20 August 2020 at 03:28:38 UTC, Mathias LANG wrote: Just tried to install it on OSX: ``` ~/dlang/install.sh dmd :( Downloading and unpacking http://downloads.dlang.org/releases/2.x/2.093.1/dmd.2.093.1.osx.tar.xz ### 100.0% Invalid signature http://downloads.dlang.org/releases/2.x/2.093.1/dmd.2.093.1.osx.tar.xz.sig ``` Works for me, maybe retry the download or run `~/dlang/install.sh update` to update your keyring? Right, I just needed to update the script. Perhaps this could be suggested when this error happens ?
Github Actions now support D out of the box!
Hi everyone, Almost a year ago, Ernesto Castelloti (@ErnyTech) submitted a PR for Github's "starter-workflow" to add support for D out of the box (https://github.com/actions/starter-workflows/pull/74). It was in a grey area for a while, as Github was trying to come up with a policy for external actions. I ended up picking up the project, after working with actions extensively for my own projects and the dlang org, and my PR was finally merged yesterday (https://github.com/actions/starter-workflows/pull/546). Starter workflow are suggested to you when you go to the `Actions` tab of a Github repository, or when you first make one. They are templates you can use to easily set-up a CI. Thanks to the work of Mihails Strasuns (@Dicebot) we have an action to install the compiler on all three platforms (https://github.com/dlang-community/setup-dlang), which this workflow use. This is how it looks: https://pbs.twimg.com/media/Ef58CrdU0AA2R7W?format=jpg=4096x4096 Using actions have several benefits over Travis: - Very easy to set up cross platform (Linux, Mac, Windows); - Usually faster machines; - Better integrated with Github; One major downside is that you can't re-triggger a single matrix row in a workflow, hence if your CI is flakey, you're going to have a bad time. Another great thing that is easy to setup with actions is automatically upload documentation. You can see an example here: https://github.com/bpfkorea/agora/blob/08a628ab8e7e38738a88f4c72dc0b42d43da185c/.github/workflows/main.yml#L125-L187 I hope to extract it to an action at some point so anyone can set it up with a single click.
Re: Beta 2.093.1
On Tuesday, 11 August 2020 at 09:30:48 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.093.1 point release, ♥ to the 11 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.093.1.html As usual please report any bugs at https://issues.dlang.org -Martin Just tried to install it on OSX: ``` ~/dlang/install.sh dmd :( Downloading and unpacking http://downloads.dlang.org/releases/2.x/2.093.1/dmd.2.093.1.osx.tar.xz ### 100.0% Invalid signature http://downloads.dlang.org/releases/2.x/2.093.1/dmd.2.093.1.osx.tar.xz.sig ```
Re: Release Candidate [was: Re: Beta 2.093.0]
On Friday, 3 July 2020 at 15:27:54 UTC, user1234 wrote: On Friday, 3 July 2020 at 11:10:25 UTC, Martin Nowak wrote: On Wednesday, 24 June 2020 at 21:01:05 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.093.0 release, ♥ to the 53 contributors. Release Candidate is live now. thanks but Have you see that full changelog is still missing ? A regression caused by the changes in tools. Martin already found the issue and it's in the process of getting fixed.
Re: Alpine Linux 3.12 Released With D Language Support
On Saturday, 30 May 2020 at 21:48:32 UTC, Johan wrote: On Saturday, 30 May 2020 at 20:30:09 UTC, Cogitri wrote: On Saturday, 30 May 2020 at 20:03:30 UTC, Andrei Alexandrescu wrote: https://www.phoronix.com/scan.php?page=news_item=Alpine-Linux-3.12-Released I'm one of the DLang maintainers for Alpine - please feel free to open issues at https://gitlab.alpinelinux.org/alpine/aports/issues if you notice something being broken. Unfortunately *some* C bindings in core aren't quite up to speed on musl yet but I try to add those when I notice that they're missing, but filing an issue about that (or making a PR to core to add the bindings) would be of great help! Also thanks to @geod24 who made this happen and did most of the hard work :) Great work. Which compilers (and versions) are available? -Johan All 3 compilers. The version will be frozen for the next 6 months, but that just means a 2 to 3 releases support period, so it's not an issue IMO. There are still some small issues to iron out, and there's still no support for LTO out of the box (although one can compile it), but we've been using it for ~8 months and it works quite well. Also some of those issues are Musl specific and not related to Dlang, e.g. https://gitlab.alpinelinux.org/alpine/aports/-/issues/11154 Initial announcement: https://forum.dlang.org/post/oznltcuropwzxaakp...@forum.dlang.org Looking at it, all the "What's next?" have been done too :)
Re: DIP 1028 "Make @safe the Default" is dead
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote: The subject says it all. If you care about memory safety, I recommending adding `safe:` as the first line in all your project modules, and annotate individual functions otherwise as necessary. For modules with C declarations, do as you think best. For everyone else, carry on as before. Thank you for listening to the community's feedback.
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 18:24:39 UTC, Atila Neves wrote:
Am I saying nothing bad can happen if we implicitly trust
extern(C) declarations? No. I'm saying we'll be no worse off if
they're all implicitly @system.
This compiles with no warnings right *now*:
void main() {
import core.stdc.stdlib: free;
free(cast(void*) 42);
free(new int);
free();
}
And this code won't compile at all when you make `@safe` the
default:
```
void main ()
{
int[] myArray = (cast(int*) malloc(42 * int.sizeof))[0 .. 42];
}
```
So, we changed the default.
Now those people that want to easily prototype something, or
write applications that extensively use system libraries, will be
extremely inconvenienced, but we satisfied the people that want
more `@safe`ty, which we all known and agree is the future.
Except that in that process we also destroyed the meaning of
`@safe` by shooting a hole into it, for the convenience of the
people that want to easily prototype something and write
applications that interact extensively with system libraries,
because that's what half of the D users do.
Clearly, an improvement.
Re: DConf 2020 Canceled
On Saturday, 7 March 2020 at 20:37:32 UTC, Mike Parker wrote: I really wish I didn't have to make this announcement, but in light of the COVID-19 outbreak and with an abundance of caution, the D Language Foundation and Symmetry Investments have agreed to cancel DConf 2020. Though it's possible that things will have cleared up by June, we can't be sure that will be the case. We don't want to put members of the D community at risk if things are not cleared up, or risk travel disruptions for those who do register and make travel plans. We decided it's better to cancel earlier rather than later to minimize the number of people who will need to cancel or rebook their travel arrangements. Personally, I was really looking forward to heading to London and seeing everyone again, but I do agree with the decision. We hope not many of you will be impacted by the decision and we're terribly sorry if you are. Sad to hear this, I was really looking forward to it. But indeed there seem to be no other choice. Don't think an online event will quite fill the gap, many of us already interact online very frequently anyway.
Re: Beta 2.091.0
On Thursday, 27 February 2020 at 09:05:47 UTC, JN wrote: "Class deallocator have been deprecated in v2.080.0 (see ), and turned into an error in v2.087.0. They have now been completely removed from the language, and the parser won't recognize them anymore." missing a link after the see Thanks, corrected: https://github.com/dlang/dmd/pull/10841
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Wednesday, 15 January 2020 at 11:48:29 UTC, kinke wrote: On Wednesday, 15 January 2020 at 04:00:26 UTC, Mathias Lang wrote: The LDC package is not going to be cross-architecture in the near future, but it should be able to correctly cross-compile once LDC a version matching 2.090.1 is released (most likely LDC 1.20.0). What's the reason for that requirement? I'll soon release LDC v1.20.0-beta1, so is there something from DMD stable you'd need as prerequisite? While I've never fully understood the popularity of Alpine-based docker images (okay, the base image is tiny, but if all images are based on the same, say, Ubuntu image, the few hundred MB only need to be stored once on each host), it'd probably be nice to have the official prebuilt LDC Linux packages linked against musl, to get rid of the glibc dependency. I assume that would be enough to make it runnable on almost all Linux x64 hosts. Nothing from DMD, but some fixes in Druntime. The `stat` struct definition was broken (among other things), so anything involving files was failing on other architecture. This was fixed in https://github.com/dlang/druntime/pull/2899 . Regarding Alpine's popularity: I think it's a matter of convenience. Just like distributing a single binary (or, like in your case, a standalone package) is easier to deal with, being able to distribute a tiny image packaging your application is great (because the economy of scale argument only holds if you have many images on the same host and don't wipe it frequently). Also, the Ubuntu base image is much slower to build, and just I like my compilation time to be low, I like my image build time to be low. I think the README of alpine covers it pretty well: https://github.com/alpinelinux/docker-alpine#why .
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: What's next ? 1) There is a pending PR (https://github.com/alpinelinux/aports/pull/12006) to have GDC working on all architectures alpine supports, not just x86_64. 2) Adding a package for gdmd 3) Rebuild packages based on GDC, so that all architectures are supported. 4) Move the packages to community so they are available out of the box. It would be great for it to happen by the end of the month, as the next alpine release would be around end of December according to their schedule, but that depends on how long PR take to be reviewed. 5) A DMD package for x86 and x86_64 shouldn't be hard to make either Time for an update! The GDC PR have been merged, and followed by another large fix to make it work on most architectures. So if you use Alpine edge, you can just run `apk add gcc-gdc` and you'll get GDC-9.2.0 (with a lot of patches), which is a 2.076.0 frontend, but allow you to bootstrap efficiently. The package is present on ARMv7, AArch64, x86, x86_64, and s390x. Only ppc64le is not supported as GDC hasn't been ported to it (at least not as of the time of 9.2.0 release). Additionally, `gdmd` has been added to `testing` to make it easier to build packages. LDC has been updated to v1.19.0 and the package definition fixed (only `ldc` and `ldc-runtime` present now, no more `ldc-static`). Dub v1.19.0 is also available, also built with GDC, on all the architectures GDC supports. The LDC package is not going to be cross-architecture in the near future, but it should be able to correctly cross-compile once LDC a version matching 2.090.1 is released (most likely LDC 1.20.0). I am now working on finalizing the LDC package so all tests pass on x86 & x86_64, and to provide a DMD package. While there are still a few details to flesh out, most things should work perfectly on x86_64 (we've been using it for months), so feel free to test it and report back. I also hope we can use it in some of the official dlang repositories (e.g. dlang-tour and the dub testsuite). The best place to report issues with the packages is on the Alpine Gitlab ( https://gitlab.alpinelinux.org/alpine/aports/issues) and to tag @Geod24.
Re: Beta 2.090.0
On Sunday, 22 December 2019 at 22:22:26 UTC, Per Nordlöw wrote: Have I missed something or is this a known problem with dub? If so, do I have any alternative to brute-forcing the problem with dub run --compiler=dmd --build=unittest dub run --compiler=dmd --build=debug which, for me, doubles my development iteration time. If it's something common enough, I suggest just creating an alias such as `dubtest` which does `dub test --compiler=dmd && dub run --compiler --build=debug`. Should you want to change compiler, you can make it a function that takes an argument. The druntime issue with `--DRT` is something that is on the map, and should be fixed soon, but I can't promise it will be fixed before the release, as it requires a druntime fix. Alternatively, some other bugs need to be fixed for the druntime fix to be truly efficient.
Re: A program that does OCR(Optical Character Recognition) inspired by Neural Networks
Nice work! You might want to take a look at the MNIST database ( https://en.wikipedia.org/wiki/MNIST_database) which is freely available and commonly used to train neural network. It will also allow you to benchmark your implementation against other algorithms. On Fri, Dec 6, 2019 at 10:07 AM Murilo via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > Hi everyone. I've spent the last weeks working on a program which > is able to read and understand text from an image file(OCR) by > using a rudimentary neural network after training with a large > amount of images(I made them myself, manually). It even shows a > map of all the parts of the images that have the highest synaptic > weights(warmer colors). It was made purely in D using the arsd > library. Below is the link to it if you wish to take a look. For > now it only understands upper case letters from the English > alphabet. I'll be adding more over time. Cheers. > https://github.com/MuriloMir/Optical-Character-Recognition >
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Wednesday, 13 November 2019 at 12:27:52 UTC, user wrote: On Tuesday, 5 November 2019 at 02:16:28 UTC, Mathias Lang wrote: ``` apk --no-cache add -X http://dl-cdn.alpinelinux.org/alpine/edge/testing ldc ldc-static dtools-rdmd dub ``` A hello world vibe project doesn't build for me using a Dockerfile using your template. I tried to add missing deps, but I couldn't really figure out what's missing. I get an error during the `dub build` step: ``` eventcore 0.8.48: building configuration "epoll"... /root/.dub/packages/eventcore-0.8.48/eventcore/source/eventcore/drivers/posix/processes.d(316,10): Error: module `core.sys.posix.sys.wait` import `idtype_t` not found` ``` My full Dockefile: ``` FROM alpine:edge as builder RUN apk --no-cache add build-base git RUN apk --no-cache add -X http://dl-cdn.alpinelinux.org/alpine/edge/testing ldc ldc-static dtools-rdmd dub RUN apk --no-cache add -X http://dl-cdn.alpinelinux.org/alpine/edge/testing libevent ibevent-dev WORKDIR /tmp/app ADD source ./source ADD dub.json ./ RUN dub build --compiler=ldc2 ``` Unfortunately recent versions of Vibe.d seems to be broken with Alpine. We use eventcore v0.8.43, Vibe.d v0.8.6, vibe-core v1.7.0. I'll see if I can get a CI in place for Vibe (and fix the issues). Thanks for reporting!
D for microservices: ldc, rdmd, dub now available on Alpine x86_64
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.
However, thanks to the work of many contributors before (Joakim
Noah, yshui, Petar Kirov/zombinedev, and many others), most of
the porting was already done and it was just a matter of fixing a
few small issues and and creating the package definitions.
A package for `dub` (v1.18.0), `dtools` (ddemangle & rdmd), and
`ldc` (v1.18.0) are now available in the `testing` repository of
Alpine Linux edge. As `testing` is not enabled by default, you
will need to specify the repository (or add it to your
`/etc/apk/repositories`) when installing the packages.
For example:
```
apk --no-cache add -X
http://dl-cdn.alpinelinux.org/alpine/edge/testing ldc ldc-static
dtools-rdmd dub
```
This command needs to originate from an `alpine:edge` image as it
links with a recent libc and LLVM.
If you just want the compiler, you still need to provide `ldc` &
`ldc-static` for things to work out of the box.
More complete example of how we use it to build a D program,
using multi-stage builds:
```
# Build from source
FROM alpine:edge AS Builder
ARG DUB_OPTIONS
RUN apk --no-cache add build-base git
RUN apk --no-cache add -X
http://dl-cdn.alpinelinux.org/alpine/edge/testing ldc ldc-static
dtools-rdmd dub
ADD . /root/myproject/
WORKDIR /root/myproject/
# Note: This will redownload your dependencies every time, which
doesn't play well with docker
# We use submodules for dependencies, hence we have
`--skip-registry=all`
RUN dub build --compiler=ldc2 ${DUB_OPTIONS}
# Runner
FROM alpine:edge
COPY --from=Builder /root/project/executable /usr/bin/executable
RUN apk --no-cache add libexecinfo
WORKDIR /root/
ENTRYPOINT [ "/usr/bin/executable" ]
```
`DUB_OPTIONS` can be used to select a build, for example enabling
coverage in a CI pipeline.
What's next ?
1) There is a pending PR
(https://github.com/alpinelinux/aports/pull/12006) to have GDC
working on all architectures alpine supports, not just x86_64.
2) Adding a package for gdmd
3) Rebuild packages based on GDC, so that all architectures are
supported.
4) Move the packages to community so they are available out of
the box. It would be great for it to happen by the end of the
month, as the next alpine release would be around end of December
according to their schedule, but that depends on how long PR take
to be reviewed.
5) A DMD package for x86 and x86_64 shouldn't be hard to make
either
Bitblob (hash wrapper) & Minivariant (tagged union) dub packages
Hi everyone!
I usually don't post on the forums, but I got two small projects
I developed as helpers for some other projects, and figured some
people might have interest in them. They are registered on dub.
## Bitblob
https://github.com/Geod24/bitblob
Bitblob is a simple wrapper for hashes. While it was almost
exclusively tested with 256 bits hash, it should work with any
hash size.
It's a value type with 0 overhead (as in (Bitblob!256).sizeof ==
32), can be initialized from an hex string or the result of
`std.digest.sha : shaXXXOf()` (which is an `ubyte[XXX/8]`).
It also provides allocation-less string representation via the
`void toString(scope void delegate(const(char)[]))` method.
## Minivariant
https://github.com/Geod24/minivariant
Minivariant is a "works for me" replacement of `std.variant :
Algebraic`.
I just wanted a simple tagged union that did the job, but the
following code does not compile:
```d
import std.variant : Algebraic;
void main ()
{
immutable int a = 42;
Algebraic!(int, bool, string) var;
var = a;
}
```
```
dlang/dmd/std/variant.d(628): Error: static assert: "Cannot
store a immutable(int) in a VariantN!(16LU, int, bool, string).
Valid types are (int, bool, string)"
wat.d(7):instantiated from here: opAssign!(immutable(int))
```
I looked into fixing it, but given Variant's design (which relies
heavily on `TypeInfo`) it would have been a wild goose chase. And
I know I'm not the only one that needed his own tagged union (see
e.g. https://github.com/s-ludwig/taggedalgebraic). It also has a
`visit` method similar to std.variant, although not with
delegates, as there is currently no way to merge delegates into
an overload set, so you have to use an existing overload set (see
the examples).
The README of each repo contains more details and examples, and
the code is usually documented.
Re: DConf 2016 news: 20% sold out, book signing
On Monday, 7 December 2015 at 17:39:14 UTC, Andrei Alexandrescu wrote: We're over 20% full and seats are going fast! We planned to send an announcement when we're 50% sold out. However, this time around registrations are coming quite a bit quicker than before so we thought we'd keep you posted earlier. [...] Looking forward to seeing you at DConf! Andrei Awesome ! Can we get an approximation of how many persons is 100% full ? :)
Re: LDC 0.15.2 beta2 is out!
2015-07-05 18:00 GMT+02:00 Kai Nacke via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: Hi everyone, LDC 0.15.2 beta2, the LLVM-based D compiler, is available for download! This release is based on the 2.066.1 frontend and standard library and supports LLVM 3.1-3.6 (OS X: no support for 3.3). Don't miss to check if your preferred system is supported by this release. There is even an alpha-quality Win64 version available! As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/ccuhfwbuzzqvpqpnh...@forum.dlang.org Regards, Kai Congrats ! Though, I don't know if you'd notice, but those binary are not using from Travis-ci: https://github.com/rejectedsoftware/vibe.d/pull/1171#issuecomment-119005076 Which makes it sensitively harder to test it (and I'd like to thank Martin Nowak again for making it so easy to test compilers - testing a beta compiler is now one additional line to .travis.yml, commit, push).
Re: This Week in D #23 - Interview with Dmitry Olshansky, dmd beta, std.experimental.color
Very interesting interview ! On the question about love/hate of D, there's this sentence: ' for, works with any range or something that can be sliced to get a range.'. Didn't you mean foreach ? 2015-06-29 5:46 GMT+02:00 Adam D. Ruppe via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: http://arsdnet.net/this-week-in-d/jun-28.html
Re: Summer cleanup on https://issues.dlang.org
2015-06-09 13:20 GMT+02:00 Stewart Gordon via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: * Retired D1. It's closed for new submissions. snip What has happened to those bugs that were applicable to D1 only - either specific to D1 in the first place or fixed in D2 but not in D1? Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit. They are still here, but apparently you can tag any new D1 issue, see for example: https://issues.dlang.org/show_bug.cgi?id=12634 (they also still show up in the search).
Re: Arch Linux D package update
You're the man ! Thanks for the switch back, I can re-install ldc now ;) 2015-06-04 16:46 GMT+02:00 Dicebot via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: gdc - now uses 5.1 gcc base and 2.066.1 frontend - patched to correctly use system zlib library (resulted in linker errors before) dtools - switched back to use dmd as default compiler dub - switched back to use dmd as default compiler dcd - new package, release 0.6.0 - only x86_64 for now (upstream bug) - provides systemd service : `sudo systemctl enable dcd.service` to start automatically upon system startup - provides default /etc/dcd.conf with stdlib paths for Arch Linux
Re: DConf 2015 has ended. See you in Berlin at DConf 2016!
2015-06-01 14:39 GMT+02:00 Dicebot via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: On Monday, 1 June 2015 at 12:00:53 UTC, extrawurst wrote: Thanks for the chance to be there! Even if I am dissapointed with many decisions being made, the main thing is that D is getting new users and new success stories. And DConf tells those stories :) Out of curiosity, what decisions are you talking about ? I think these are most unpleasant ones for me: - Same hypocrite attitude to language/stdlib breaking changes that neither allows to fix it nor gives stability guarantees. - Going for kitchen sink Phobos (and distributing vibe.d as part of Phobos) - Moving fibers between threads (though there is some hope that Liran managed to convince Walter it is a bad idea) On the other hand, AST macros have been officially rejected and that I like a lot :) While it's for different reasons - and I wouldn't qualify it hypocrite -, I follow you on every point :) Thanks Chuck, Walter and Andrei, and every speaker for making this happen. It's also very nice to see that the community is being listen to (w.r.t. dub for example). Looking forward to play at home next year !
Re: Monday is last day for DConf 2015 registrations
Joe, Mihails and I will be there in a few hours, and we'll have a car. 2015-05-22 17:04 GMT-07:00 David Nadlinger via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: On Friday, 22 May 2015 at 13:12:35 UTC, Daniel Murphy wrote: Steven Schveighoffer wrote in message news:mjkncd$21e7$1...@digitalmars.com... BTW, I will stress again that I'm going to be at the hotel all day Tuesday (and without a car) if anyone is interested in hanging out :) I'll be there from Saturday night. I am going to arrive Monday afternoon, probably with a car. — David
Re: dsq-1: open-source software synthesizer
2015-04-01 13:54 GMT+02:00 Rikki Cattermole via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: There are more types of abstractions than just classes vs interfaces. What goes into a module for example is a prime example of an abstraction. A purpose. Which also have it's problem. For example, most symbols in vibe.internal are public. That's because we didn't have `package(identifier)` (and we still don't have, since we're supporting 2.065).
Re: vibe.d 0.7.23 has been released
2015-03-25 22:37 GMT+01:00 Sönke Ludwig digitalmars-d-announce@puremagic.com: This release adds support for the just released DMD 2.067.0 frontend. There are also some preparatory changes in vibe.core.sync (TaskMutex etc.) for planned nothrow related changes to D's mutexes and object monitors. These changes lead to a changed behavior when TaskMutex'es are mixed with the Task.interrupt() functionality. If your code uses both, please have a look at the change log for more details. Thanks for all the time and work you put on Vibe :)
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
I just wish D examples didn't include string lambdas. 2015-03-25 22:00 GMT+01:00 Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_ disservice_to_intelligent/ Andrei
Re: Release D 2.067.0
2015-03-24 18:07 GMT+01:00 Martin Nowak via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: Glad to announce D 2.067.0. This release comes with many improvements. The GC is a lot faster for most use-cases, we have improved C++ interoperability and fixed plenty of bugs. See the changelog for more details. http://dlang.org/changelog.html Download pages and documentation will be updated within the next few hours. http://downloads.dlang.org/releases/2.x/2.067.0/ http://ftp.digitalmars.com/ Until the binaries are mirrored to the official site, you can get them here. https://dlang.dawg.eu/downloads/dmd.2.067.0/ -Martin Congrats to everyone involved ! A special thanks to Martin, that helped a lot to get Vibe.d ready for 2.067, and reverted the problematic changes when we realize it wasn't gonna cut it.
Re: This Week in D #9 - marketing discussion, final beta, special interview with Sönke
On Monday, 16 March 2015 at 04:54:12 UTC, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/mar-15.html Also remember about the RSS feed here: http://arsdnet.net/this-week-in-d/twid.rss I'm currently out west so I'm a couple hours off, but here's the next installment with summaries of forum discussions - with a few of my opinions added in - and a contributed interview! Lots of cool stuff this week. Nice ! The interview is a cool idea. Nitpick: Loose (P after the dub question ;)
Re: DDocs.org: auto-generated documentation for all DUB projects (WIP)
On Tuesday, 10 February 2015 at 22:40:18 UTC, Kiith-Sa wrote: DDocs.org (http://ddocs.org) is a repository of documentation for DUB projects that automatically re-generates docs as new projects/releases/branch changes are added. The idea is to make documenting D projects as simple as possible, to the point where you don't need to do any work to get documentation for your project other than adding it to the DUB registry. Also, users can now browse documentation for DUB projects even if the author was too lazy to generate it themselves (assuming thy did include some documentation comments). Note that this is still in a very early stage, it was put together in a very quick-and-dirty style by a person with little webdev experience. Currently it just scans `code.dlang.org`, looking for changes (yes, I know, this will break as soon as code.dlang.org changes, I plan to raise issue/s (PRs?) to the dub registry project so it can have a full/stable API, but I wanted to get something to work *right now*. Code is here: * ddocs.org: https://github.com/kiith-sa/ddocs.org * hmod-dub: https://github.com/kiith-sa/hmod-dub * harbored-mod: https://github.com/kiith-sa/harbored-mod Background: When optimizing harbored-mod by testing it on big D projects (gtk-d, tango, vibe.d, etc.), I wrote a simple tool to fetch/generate docs for any DUB project; I got carried away and used that as base for a tool that checks for changes in the DUB registry and generates docs for all projects. Awesome ! I've wanted to do it for quite some time, I think it's really important we get that as a part of code.dlang.org (as well as compatibility badges, but that's another story. Regarding the macros: I recently completed the set of definitions in libddoc ( https://github.com/economicmodeling/libddoc/commit/82fcd8fdcdfe0809437f2415361ef92ee21a5c12 ), so if you're based on Harbored, you should have everything you need. I'm currently working on a fully compliant macro parser in libddoc. The macro WEB is not part of the standard definition, it's part of dlang.org's definitions, which you can find on Github (.ddoc files). More precisely, it's defined in html.ddoc ( https://github.com/D-Programming-Language/dlang.org/blob/master/html.ddoc ). I guess it can make sense to had that file included by default, but at the same time I'd like to avoid projects documentation to rely on non-standard behavior.
Re: Martin Nowak is our new release czar
On Thursday, 5 February 2015 at 00:07:37 UTC, Andrei Alexandrescu wrote: Andrew Edwards, our former release czar, declined his czardom because he went to college. Thanks and good luck! He left a void of power. After a period of turmoil and intestine political fights, we have a new, ruthless czar: Martin Nowak. He plans to put us on a path of regular, predictable 6-week releases, thus ending the D Middle Ages. Please throw your hat in the air with me to hail the new czar! :o) Andrei Wonderful news ! Looking forward to 2.067.
Re: 2015 H1 Vision
On Sunday, 1 February 2015 at 01:17:41 UTC, Andrei Alexandrescu wrote: Hello, Walter and I have been mulling for a while on a vision for the first six months of 2015. http://wiki.dlang.org/Vision/2015H1 This is stuff we consider important for D going forward and plan to work actively on. We encourage the D community to focus contributions along the same lines. We intentionally kept the document short and high-level as opposed to discussing tactical details. Such discussions are encouraged in the appropriate forums. Thanks, Walter and Andrei I'm surprised by one of the goals: Our aim is to top 2000 pull requests by June 30, 2015. This is arguably the most well-defined goal here, but at the same time, it sounds strange to judge the contributions by the numbers of pull request. We could top that number -and I'm afraid we'll be tempted to do so- by submitting a streamline of pull requests fixing trivial doc problems / mispelling (I'm not saying docs P.R. are worthless), or implementing trivial functions. I'd rather see a list of (high-level) wanted features here, either in Phobos (better file abstraction, better release process...) than Receive accept 2000 P.R in 6 months. Regarding Vibe.d: I partly agree with Dicebot that we should focus on dub first. However, I like the idea that not-breaking-Vibe.d should be required for a release (2.067 being a perfect example of a major breaking change for Vibe.d). In fact, something that I wanted to do for a long time is to have badges on code.dlang.org, which indicates which library builds with which compiler. This is important for the overall quality of the language, as, once it's in place, dub will be able to refuse fetching a library that's not building with 2.0XX, providing a much nicer experience to user. We'll also be able to see how much code a release / nightly (which is also something we lack) will break code, and how much code in code.dlang.org works with which version.
Re: 2015 H1 Vision
On Monday, 2 February 2015 at 05:57:27 UTC, ketmar wrote: On Mon, 02 Feb 2015 16:24:00 +1100, Daniel Murphy wrote: Vladimir Panteleev wrote in message news:viqwfixznbdbdwvha...@forum.dlang.org... I don't use Dub You really should! I put it off for months and months but I'm quite happy with it now. dub is very limited tool. first: it can't do separate compilation. some of my modules, for example, do alot of CTFE things (including parsing disk files) and eating memory like crazy. there is simply no way to to batch compiles for me. besides, batch compile means that if i'll change one line in one module, dub will recompile them all, so i forced to group modules to libraries by size, not by intent. second: dub can't compile code in other languages. some of my projects includes several C modules, for example, and my build tool has no problems building that and automatically tracking dependencies. third (it's an extension of second, actually): track arbitrary dependencies and exec arbitrary tools to generate some files based on that dependencies. dub is good, but only in limited use cases. so it's almost no sense in using dub if some use cases are not suitable for it: it's way better to adapt build tool that one already using (or write his own) instead of use TWO build tools for different projects. You can do separate compilation (--build-mode=singleFile). It was implemented, quick and dirty (my bad), for one purpose: compile Vibe.d on a very limited machine (512 Mbs of RAM). It has, however, no tracking of module dependency ATM, so it'll recompile everything, everytime. This is a known issue which, either no one is interested in, or no one has the time to. I also remember facing DMD bugs when I gave it a shot, but they may be fixed by now (one of them is for sure), so maybe this feature needs a second chance. I will not disagree on the other points (support for other languages is what I'm missing most ATM). If you wish to contribute patches, contact me, and I'll be the strawman (geod24/gmail).
Re: My D Cookbook on sale: $5 ebook from the publisher
On Sunday, 28 December 2014 at 21:13:50 UTC, Adam D. Ruppe wrote: I just noticed they temporarily reduced the price of my book: https://www.packtpub.com/application-development/d-cookbook If you haven't gotten a copy yet, start off the new year right! :) Among the stuff covered are how to use ranges, reflection, structs for resource management, OS APIs, and even a little on starting to write a kernel level program in D. Practical to fun, educational all around! PS for those of you who have read it and haven't yet, write an amazon review! http://www.amazon.com/gp/product/1783287217/ref=s9_simh_gw_p14_d0_i1?pf_rd_m=ATVPDKIKX0DERpf_rd_s=center-2pf_rd_r=1P864AG6WY9Y7H86MVFGpf_rd_t=101pf_rd_p=1688200382pf_rd_i=507846 Nice ! Time to finally get mine :)
Re: Travis-CI support for D
On Thursday, 11 December 2014 at 12:50:04 UTC, Martin Nowak wrote: Nice, that I can finally get hold of you Brad. Need your help on three topics. Cam we please rework the download folder structure? It's a PITA to work with, see https://github.com/travis-ci/travis-build/pull/340/files#diff-ac986a81b67f1bd5851c535881c18abeR91. Most obvious idea, make a sub folder per version. http://forum.dlang.org/post/mailman.2638.1417638975.9932.digitalmar...@puremagic.com We need some sort of LATEST redirect, you cannot expect all downstream maintainers to update their scripts for each release. And last we need dlang.org on the auto-tester. The documentation breaks with many pull requests. Just building would be enough for now, though it's a nice reward for people if they could see the result of their pull. https://github.com/braddr/d-tester/issues/41 -Martin Brad, are we going to see this ? It could be VERY useful for some tools. Also, thank you Martin, Iain and David for this. It was really needed :)
Re: DUB 0.9.22 released
On Thursday, 13 November 2014 at 11:06:06 UTC, Suliman wrote: - Added general support for single-file compilation mode, as well as separate compile/link mode for GDC. I do not see any mentions about this key at docs. Can I add it to dub.json? Nope. It must be specified from the command-line. The relevant option, `build-mode`, is accessible through `dub build --help` (or any of the command that subclass build).
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 23 October 2014 at 11:03:35 UTC, Kagamin wrote: On Thursday, 23 October 2014 at 09:57:38 UTC, Dicebot wrote: Uh, what will it link to? extern(C) function like gc_malloc? druntime links to those statically itself so you will get application that links to different GC than druntime itself. The reason is CDGC provides symbols like gc_malloc and after that the linker has no reason to pull default GC from the library: it doesn't pull what's not necessary. It will clash at best, or just ignore cdgc, as objects are considered as a whole, in link order. Now, if druntime defines gc_alloc, it won't link. You have to extract all conflicting symbols out of druntime. However, one could provide a full druntime patched with CDGC as a dub module, and that might work, I suppose.
Re: DUB 0.9.22 released
Awesome :) Thanks for the time you put in dub, it has become a vital part in D now. 2014-09-22 11:33 GMT+02:00 Sönke Ludwig digitalmars-d-announce@puremagic.com: If you can think of any potentially important and especially backwards-incompatible changes/additions, please mention them (ideally as GitHub tickets), so that we can include them before the 1.0.0 release. Full shared library support (building them, and as dependency). Aside from that, any plan to move the auto-tester to puremagic ? Currently, Travis works under linux (IIRC OSX is not activated), so dub is not auto-tested on windows. Also, the test cases are very basic.
Re: DUB Bash Completion
On Sunday, 13 July 2014 at 22:11:17 UTC, Nordlöw wrote: On Sunday, 13 July 2014 at 20:15:06 UTC, w0rp wrote: I suppose one extra step you could go would be to somehow complete --config= too, so you could tab complete --config=foo and --config=bar or something. --config is not documented by dub -h Is it a sub command flag? Yeah it's a build subcommand. But you have to use dub describe to do the completion (it depends on the project file).
Re: dmd front end now switched to Boost license
On Friday, 13 June 2014 at 11:31:10 UTC, Dmitry Olshansky wrote: 13-Jun-2014 04:31, Walter Bright пишет: https://github.com/D-Programming-Language/dmd/pull/3655 It's probably nice to have less restrictive license, but what we aim to achieve with that? Make commercial companies contribute to DMD more freely? There is no problem even with GPL. Let them build and sell their own products out of DMDFE? Highly unlikely to be a profitable anyway, and we'd better get back the patches. Wild guess: DMD in fedora, debian et al. repositories ?
