Re: New DConf Online 2020 Lightning Talk and a new Task Bounty
On Monday, 2 November 2020 at 17:54:48 UTC, Mike Parker wrote: My mistake was assuming that because it's an open issue, it still hasn't been resolved. Had I checked the release tags and the dates, For the dub registry releases aren't generally tagged, but often released from master. I would have seen that a release has since been made. But I didn't, so mea culpa. I tagged the release as a response to your post to show how easy it is/was. However, our conversation could have gone like this: I'm sorry about the rather aggressive tone.
Re: New DConf Online 2020 Lightning Talk and a new Task Bounty
On Monday, 2 November 2020 at 14:05:07 UTC, Mike Parker wrote: An anonymous donor has seeded a new Task Bounty with $400. The task: execute a new release of the dub-registry project. Tagging was never a problem as registry is/was building fine from master: https://github.com/dlang/dub-registry/releases/tag/v2.4.0 There are not so many tags because the registry is in maintenance mode and critical bug fixes are often directly deployed from master. Anyhow, the real problem is that no one except Sönke has access to the registry server for deploying a release and the DLF at least in the past wasn't interested in paying for the registry server(s) themselves, s.t. they could be setup in such a way that multiple people have access to it. I do _not_ want the bounty and while I appreciate that people want to support the D ecosystem, I do not understand why we put up a bounty to run "git tag" which would have no impact as deployment is the issue. IMHO we should address the real issues (registry lacking features + registry deployment). A worrying side note here is that there have been many private and public mails about the root causes (three years ago the registry was crashing because the VM only had 200M of memory and a small GC leak made the server collect slightly more memory than it should). Anyhow, even without prior knowledge an email to anyone who has ever contributed code to the registry - aka its maintainers - (e.g. Sönke, Martin, WebFreak, ZombineDev, Mathias, ...) would have yielded this information - very similar to the recent LDC bounty that was done without contacting any of the LDC maintainers.
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 21:09:55 UTC, Meta wrote: On Thursday, 1 October 2020 at 20:40:39 UTC, Seb wrote: [...] Okay, fair enough. Should this still not have had approval from either Walter or Atila before being merged in? Or is that not the case for changes behind -preview? Approval is not required for -preview. It's the testing phase of a new feature or change. As I tried to mention earlier real data and experimentation is super helpful for a DIP / formal approval (in this case one important question answered was how much code in the D ecosystem would need to be changed). There's a bit of implicit approval by no objection as something that's worthwhile to be explored/tested, but it's only a good chance that it will be activated by default, not a guarantee.
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote: On Thursday, 1 October 2020 at 17:29:56 UTC, Mathias LANG wrote: On Thursday, 1 October 2020 at 16:47:37 UTC, Meta wrote: [...] 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. I've read the discussion but skipped the presentation. All I see is Atila expressing distaste for the compiler choosing how to pass values, and no explicit sign-off from either Walter or Atila before it was merged. My objection is not to `in`'s new behaviour (although having something that functions similarly to auto ref but in subtly different ways is not good language design, IMO). My objection is that we have a major change to a language feature, that was merged without the apparent blessing of either of the two people who are supposed to be the gatekeepers for these decisions, and without a DIP (yes, it is behind -preview, but that implies that this will eventually make it into the language proper). That is what I am calling "ridiculous". If W or A did approve it and I just wasn't aware, then I apologize and retract my objection. You seem to have a wrong understanding of -preview. It doesn't even pretend to be an officially approved feature. I think this is what's been causing the confusion. Preview flags are what other compilers call "experimental". In fact, -preview is intended to predate a DIP or formal approval in other ways, because if you don't know the impact of a feature or usefulness, it's very hard to make an informed decision. This has the nice side effect that sometimes it becomes clear during an implementation that the idea as is unfeasible. implies that this will eventually make it into the language proper No, it doesn't.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 13:51:34 UTC, Mike Parker wrote: DIP 1028, "Make @safe the Default", has been accepted without comment. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1028.md "without comment" - even though there were a lot of unaddressed problems :/ Great! So what's the entire point of this process? To give people the illusion of progress and participation? Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options. I'm aware that Walter doesn't like the idea of giving up ownership, but it makes all the other people question why they should still bother with this process and not simply fork and move to an open, transparent development...
Re: Interfacing D with C: Arrays and Functions (Arrays Part 2)
On Tuesday, 28 April 2020 at 14:45:37 UTC, Mike Parker wrote:
I've finally gotten around to publishing the next article in my
D and C series on the D blog. This is the second post about
arrays, focusing on properly declaring in D functions from C
that accept array parameters.
The blog:
https://dlang.org/blog/2020/04/28/interfacing-d-with-c-arrays-and-functions-arrays-part-two/
Reddit:
https://www.reddit.com/r/programming/comments/g9o3wi/interfacing_d_with_c_arrays_and_functions_arrays/
HN:
https://news.ycombinator.com/item?id=23007409
Great article as always!
Maybe this article and conversation revives the interest in a
very much related area: array mangling still doesn't work for
extern(C++).
Example:
---
extern(C++) void foo(int[] arr);
void main()
{
foo([1, 2]);
}
---
// Internal Compiler Error: type int[] cannot be mapped to C++
There have been multiple attempts to fix this, the latest one is
https://github.com/dlang/dmd/pull/8120.
Now, that dmd comes with the (experimental) -H flag for C++
header generation, maybe there's more interest in making D
arrays/strings work seamlessly between D and C++?
Re: Beta 2.090.0
On Sunday, 22 December 2019 at 20:30:06 UTC, berni44 wrote: On Sunday, 22 December 2019 at 19:00:15 UTC, Eugene Wissner wrote: Probably differen email addresses. You can set an email address locally for the repository in .git/config. Or just add an alias: https://github.com/dlang/tools/blob/master/.mailmap git config -l reveals only one address (which is set at global level; there is no local and no systemwide email address). It's the same I use in github. In bugzilla I use a different one, but I guess, that this is not relevant. It looks like you made a commit via the GitHub UI. By default it uses a default generated (<...>@users.noreply.github.com) email address. You can change this in your GitHub user settings. Anyhow, I went ahead and made a PR to "reduce" you to only one person ;-) https://github.com/dlang/tools/pull/388 For future readers, here's how I found out the other email address: $ ./contributors.d -f git "v2.075.0..master" | grep -i berni
Re: Blog Post: Beating std::visit Without Really Trying
On Sunday, 6 October 2019 at 07:16:03 UTC, Joseph Rushton Wakeling wrote: On Sunday, 6 October 2019 at 03:47:25 UTC, Seb wrote: My earlier post tried to point out that SumType is an excellent candidate for v2. Sorry, Seb, but I don't get this. There's no reason to wait for a v2 to introduce a new SumType symbol that outperforms the old Variant (assuming it's not possible to just rewrite the latter implementation under the hood without changing behaviour). Well, my guess it will be similar to that one time when `Option` (https://github.com/dlang/phobos/pull/3915) was rejected because it was only slightly better than `only` or the other time when it was attempted to improve `Nullable` (e.g. https://github.com/dlang/phobos/pull/6253)? Alternatively, there is also the route pioneered by std.typecons.wrap whose improvements are - after more than four years - still stuck in std.experimental.wrap (https://github.com/dlang/phobos/pull/2945, https://dlang.org/phobos/std_experimental_typecons.html#.wrap). On the contrary, the best way to do a v2 is likely to be that all or most of the stuff we want in it is already there and has been battle tested in the wild. A standard library is _not_ supposed to be a place where actual battle-testing happens. It's where things move when they have been tested and no longer change. This "readiness" condition is one of the reasons why only a single function has been added to Phobos in 2019 so far. Please don't misunderstand me: I would love to see SumType in Phobos. There are tons of other great modules that would make a great base as well, e.g. http://rumbu13.github.io/decimal/doc/decimal.html, https://code.dlang.org/packages/optional, or https://github.com/dlang-community/std_data_json etc. I plainly doubt that we will ever see them in the current Phobos.
Re: Blog Post: Beating std::visit Without Really Trying
On Sunday, 6 October 2019 at 02:33:15 UTC, Walter Bright wrote: On 10/5/2019 6:58 AM, Seb wrote: Phobos is essentially dead/frozen (feature-wise). I beg to disagree. A couple cases in point: https://github.com/dlang/phobos/pull/7211 which is a re-imagining, rethinking of hexString. I'm sorry, my choice of words wasn't wise (and I certainly didn't mean it in a negative way). Phobos is amazing and stable, but exactly because of these attributes there isn't much active development happening. Stability implies no breaking changes which is **very very good** because it allows the ecosystem to thrive (and not break builds because Algebraic was swapped against SumType). Below I have listed a summary of all announced changes in Phobos since the beginning of this year (six releases, 2.088 - 2.083). This lists only the announced changes (and there are more bug fixes), but in total we're looking at one new function (getAvailableDiskSpace), two new overloads (schwarzSort, unpredictableSeed) over these six releases. That's what I was referring to. For comparison: in the meantime about 200 new Dub packages have been added [1, 2] and in total about 600 Dub packages have been updated [3]. 2.088: - std.array.Appender and RefAppender: use .opSlice() instead of data() - ErrnoException.errno is now nothrow pure @nogc @safe - Nullable alias get this has been deprecated - Added the std.file.getAvailableDiskSpace functionality. - Allow std.json to overlook trailing comma 2.087: - Added a table of control characters in ASCII table - Count processors via sched_getaffinity on Linux - Add overload std.algorithm.sorting.schwartzSort!(alias transform, SwapStrategy ss, R) - Phobos is now compiled with -preview=dip1000 2.086: - Fixed comparison bug in std.algorithm.comparison.levenshteinDistance - std.experimental.all has been moved to std 2.085: (no changes) 2.084: - Add overload std.random.unpredictableSeed!UIntType 2.083: (no changes) See more at [4]. [1] https://web.archive.org/web/20181229043818/http://code.dlang.org/ [2] https://code.dlang.org/ [3] https://code.dlang.org/?sort=updated==500=100 [4] https://dlang.org/changelog/index.html and: https://github.com/dlang/phobos/pull/7130 https://github.com/dlang/phobos/pull/7144 both of which work to remove autodecode from Phobos. 7130 in particular can use some help with anyone who wants to help drive this forward. I'm sorry and while I like this effort, I don't expect it to help because it does break the world. AFAICT the only way to avoid breaking the world when removing autodecode is to ship a new/different version of Phobos _together_ with the current one, s.t. it can be opted-in by users. Anyhow, I think Andrei summarized it better a few months ago: The time is ripe for std.v2 [https://forum.dlang.org/post/q7j3s0$15n7$1...@digitalmars.com] My earlier post tried to point out that SumType is an excellent candidate for v2.
Re: Blog Post: Beating std::visit Without Really Trying
On Saturday, 5 October 2019 at 06:40:35 UTC, Arun Chandrasekaran wrote: On Saturday, 5 October 2019 at 02:59:58 UTC, Paul Backus wrote: I was curious how C++17's std::variant compared to the options we have in D, like Algebraic and SumType, so I did a simple comparison of the generated assembly for each of them. You can read about it at the link below. And as you can probably guess from the title, D comes out ahead, in the end. https://pbackus.github.io/blog/beating-stdvisit-without-really-trying.html This is my first attempt at sharing something like this, so any comment or feedback is very much appreciated! Good one. Any plans to push SumType as a replacement of Phobo's Algebraic? Phobos is essentially dead/frozen (feature-wise). Though if someone ever manages to get v2 of the ground, SumType would be the obvious choice. Anyhow, currently we would have to name it differently (e.g. dts - https://github.com/wilzbach/dts). Maybe the upcoming SAoC project will change this and allow multiple versions of a library to co-exist in a binary.
Re: SoAC
On Sunday, 11 August 2019 at 19:16:22 UTC, Tiberiu Lepadatu wrote: Hi everyone, I want to participate to Symmetry Autumn of Code 2019 with either the project "Solve dependency hell" or "Implement Reactive programming into D". I have some experience with programming languages mainly Rust, FORTRAN, Python and JavaScript and this summer I have worked intensively with RxJS and with python FORTRAN wrapping. I think, giving my past experience that I can get each one of them to a finished state. But I think that the question that should be asked is which one of those will be more impactful to the community? Which one will better serve the D future? I will try by Wednesday to prepare an application for both of them. But I can't wait to hear your opinions. Thanks, Tiberiu You don't have to decide. Like GSoC submitting multiple project proposals is ok if you can't decide, though typically it makes sense to focus on one and making it a high-quality one.
Re: Release D 2.087.0
On Monday, 15 July 2019 at 14:00:23 UTC, Mike Franklin wrote: On Monday, 15 July 2019 at 13:00:08 UTC, Vladimir Panteleev wrote: We are trying to implement many of those `extern(C)` runtime hooks as templates. Those templates need to be implicitly imported through object.d. That means code that was in `rt` is converted to a template, and then moved to object.d. However, as we do more and more of them object.d becomes unwieldy. I took the initiative to prevent object.d from turning into a more of a monstrosity that it already is, and moved those runtime templates (which used to reside in `rt`) back into `rt`. This is not a problem, and not at all related to the issue we're discussing. The problem is that you chose to move them into `rt` instead of somewhere under `core`, which would respect existing conventions and avoid breakages like the ones we've seen reported in this thread. It is related. If I follow your suggestion to move these implementations to `core.internal` and continue with the objective of converting all runtime hooks to templates, the vast majority of `rt` will end up being moved to `core.internal`. Is that what you're suggesting? `rt` is the language implementation. `core.internal` contains the utilities used internally by druntime and "privately" imported by Phobos. Following that established convention, I made the right decision. I'm sorry it broke digger, but digger is not how we typically build DMD, druntime, and Phobos. Mike The point is that we don't ship the sources of rt to the user. That's the separation. With templates sources must be made available to the user, s.t. the compiler can instantiate them. However, rt doesn't get shipped to the user as it is compiled only. As probably more tools and distributions are affected I suggest we move all source code that needs to be instantiated by the user to core.internal.
Re: Release D 2.087.0
On Monday, 15 July 2019 at 11:49:31 UTC, Vladimir Panteleev wrote: On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote: I discussed that briefly on Slack with a couple other developers. My understanding is the `rt` is the language implementation and `core` is the low level library for users. The code in `rt/array` are language implementations. They are not to be imported by the user. They are, however, required by the language to implement D's built-in arrays, so that is why they are publicly imported in object.d. I think that fits core.internal better than rt. Have you considered that during said discussion? For reference, the discussion was this one: http://imgur.com/a/HszdtHd I'm sorry that I missed it, because Vladimir makes a very good point. rt isn't supposed to be available nor importable by the user. rt can import core, but core can't import rt.
Re: Beta 2.087.0
On Monday, 17 June 2019 at 02:30:45 UTC, Nicholas Wilson wrote: On Sunday, 16 June 2019 at 22:47:57 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.087.0 release, ♥ to the 66 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.087.0.html As usual please report any bugs at https://issues.dlang.org -Martin Quite a few duplicate contributors: Aurelien Fredouelle Aurélien Fredouelle Ben Merritt Benjamin L. Merritt kinke Martin Kinkelin shove shove70 Would be easy to fix: https://github.com/dlang/tools/pull/376
Re: Beta 2.086.1
On Thursday, 13 June 2019 at 03:48:05 UTC, Eugene Wissner wrote: On Wednesday, 12 June 2019 at 23:51:39 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.086.1 point release, ♥ to the 20 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.086.1.html As usual please report any bugs at https://issues.dlang.org -Martin Mathis Beer and FeepingCreature are the same person. PRs are welcome to: https://github.com/dlang/tools/blob/master/.mailmap
Re: nogc v0.5.0 - DIP1008 works!
On Friday, 24 May 2019 at 11:41:12 UTC, Atila Neves wrote: I'd been holding off on announcing this until DIP1008 actually got implemented, and now it has: [...] Awesome!! Now we just need to get to compile Druntime and Phobos with -preview=dip1008, s.t. we can enable it by default :) See e.g. https://github.com/dlang/dmd/pull/8508
dlang/projects: A collection of impact D projects
Hi everyone, at DConf one common concern raised was that it's hard to track the progress on important high-level projects. Furthermore, its also hard for interested contributors to find such projects and judge which ones really matter to the D community. Lastly, the existing wiki pages (wishlist, GSoC project list, vision document etc.) were chronically out-of-date. Hence, during DConf we created the dlang/projects repository - a collection of impactful projects in the D ecosystem: -> https://github.com/dlang/projects We have seeded the repository with the existing projects from the wiki and encourage everyone to vote on them (via GitHub reactions) or express their opinion as this will greatly help us to judge which projects are important to the community. -> vote for projects that matter to you/your company Furthermore, everyone is invited to submit new projects to this repository. However, please keep in mind that this repository tries to collect high-level goals and project. A good rule of thumb is that if a project can't be split into smaller parts, it might belong to its respective issue tracker. -> propose projects that matter to you/your company Projects marked with the "leadership vision" label are vision projects of the D Language Foundation. These projects are seen as key projects to D's success by the leadership. As many of the projects ideas will make good GSoC projects, we will also this repository as an idea list for future GSoC/SAoC. More details on this will be announced later. Happy voting!
Re: Phobos is now compiled with -preview=dip1000
On Thursday, 16 May 2019 at 10:03:42 UTC, Kagamin wrote: On Thursday, 16 May 2019 at 05:22:42 UTC, Seb wrote: Yes that sounds like the culprit. Btw as mentioned on DConf, the dip1000 switch contains a few other breaking changes which will make it even harder to adopt too. Well, it's an inherent property of DIP1000 to not compile code that previously compiled. Though safety of tupleof shouldn't depend on DIP1000. Well, here's the full discussion: https://github.com/dlang/dmd/pull/8035
Re: Phobos is now compiled with -preview=dip1000
On Thursday, 16 May 2019 at 05:14:39 UTC, Nicholas Wilson wrote: [...] Yes that sounds like the culprit. Btw as mentioned on DConf, the dip1000 switch contains a few other breaking changes which will make it even harder to adopt too.
Re: Release D 2.086.0
On Tuesday, 7 May 2019 at 17:29:34 UTC, Daniel N wrote:
On Tuesday, 7 May 2019 at 15:13:05 UTC, Andrea Fontana wrote:
import std;
void main()
{
std.file.write("/tmp/test", "hello");
}
How should I fix this?
import std;
import file = std.file;
void main()
{
file.write("/tmp/test", "hello");
}
Alternatively, you can use toFile. It was created because of
these std.file - std.stdio overlap:
https://dlang.org/phobos/std_stdio.html#.toFile
Re: Containerize Your D Server Application
On Friday, 19 April 2019 at 20:45:12 UTC, Valeriy Fedotov wrote: On Thursday, 14 March 2019 at 12:38:30 UTC, Mike Parker wrote: [...] Seems that multithe tutorial no longer works. ``` The dependency resolution process is taking too long. The dependency graph is likely hitting a pathological case in the resolution algorithm. Please file a bug report at https://github.com/dlang/dub/issues and mention the package recipe that reproduces this error. ``` [...] dlang2 was upgraded to Ubuntu 18.04 yesterday.
Re: New DConf Blog Post
On Tuesday, 16 April 2019 at 23:12:43 UTC, aberba wrote: On Sunday, 7 April 2019 at 06:19:31 UTC, Mike Parker wrote: On Saturday, 6 April 2019 at 22:30:58 UTC, bauss wrote: The design is terrible and it really looks unprofessional. While the old site wasn't responsive, the design was at least slightly better. It just doesn't look very well done. I'm not trying to be negative or anything, but it looks like someone who just learn html/css in 1999 tried to make the design of the page. Perhaps raising money to pay an experienced web designer would be a good topic for a fundraiser later this year. Given that I don't do compiler stuff, I could take a look at it to see how I can contribute, for free. Thanks! Where is the code hosted? https://github.com/dlang/dconf.org You can find D Logos here: https://github.com/dlang-community/artwork
Re: New DConf Blog Post
On Monday, 8 April 2019 at 16:42:50 UTC, matheus wrote: On Sunday, 7 April 2019 at 07:03:34 UTC, bauss wrote: [...] Design is a complicated matter and thankfully I'm mostly back-end developer. [...] Please move this discussions and ideas to DFeed ;-) https://github.com/CyberShadow/DFeed
Re: New DConf Blog Post
On Saturday, 6 April 2019 at 22:30:58 UTC, bauss wrote: Just going to respond to this: "If you haven’t visited the site in a while, you’ll surely notice that it’s been redesigned. The old version was not responsive and was quite annoying to manipulate on small screens." The design is terrible and it really looks unprofessional. While the old site wasn't responsive, the design was at least slightly better. It just doesn't look very well done. I'm not trying to be negative or anything, but it looks like someone who just learn html/css in 1999 tried to make the design of the page. Well, it takes up less browser resources than my proposal for DConf 2018 ;-) https://wilzbach.github.io/dconf18/ Source: https://github.com/wilzbach/dconf18
Re: The D Programming Language has been accepted as a GSoC 2019 organization
On Thursday, 7 March 2019 at 10:01:33 UTC, Seb wrote: On Tuesday, 26 February 2019 at 22:34:45 UTC, Seb wrote: Hi all, I have some very exciting news to share. The D Language Language got accepted as a Google Summer of Code organization! The official GSoC page provides a few initial pointers and details: https://summerofcode.withgoogle.com/organizations/6103365956665344 Below, I will try to answer a few common questions: What projects will be offered? -- You can find a list of potential projects at the D wiki: https://wiki.dlang.org/GSOC_2019_Ideas However, students can, of course, come up with their own projects, too! ... Happy hacking! @Students: you can find idea threads with more detailed and specific information about individual DLang GSoC subcomponents on our General Newsgroup with the [gsoc] tag. So far, these idea finding thread exists: - DUB (https://forum.dlang.org/thread/eftttpylxanvxjhoi...@forum.dlang.org) - DMD (https://forum.dlang.org/thread/iwvtxsecerbshhaga...@forum.dlang.org) Please don't be shy and start your own thread ;-) @students: There are a few more [gsoc] threads now: - Mir project: https://forum.dlang.org/post/jyzgzxqgaggltgifw...@forum.dlang.org - D Language server: https://forum.dlang.org/post/ersuicbdvzxsliafv...@forum.dlang.org Also please don't forget that the application period starts next week (March 25 18:00 UTC) and ends on April 9 18:00 UTC. -> https://developers.google.com/open-source/gsoc/timeline We're looking forward to your applications!
Re: Compiler benchmarker for D, C, C++, Go, Rust with more to come
On Monday, 18 March 2019 at 21:34:40 UTC, Per Nordlöw wrote: On Monday, 18 March 2019 at 12:33:12 UTC, Seb wrote: [1] https://github.com/dlang/installer Does this include a script for building dmd with ldc or this not yet possible? Well, you don't really need a script: git clone https://github.com/dlang/dmd HOST_DMD=ldmd2 make -f posix.mak -j10 Additionally, you can add `ENABLE_RELEASE=1` to create a fully optimized release binary. This has been possible for a very long time and actually is even tested on every PR with SemaphoreCI (Linux) and AppVeyor (Windows). BTW, the Arch DMD package [1] is the only package that I know of which is actually using LDC to compile DMD for the released binaries. [1] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/dmd#n54
Re: Compiler benchmarker for D, C, C++, Go, Rust with more to come
On Monday, 18 March 2019 at 11:02:55 UTC, aliak wrote: On Monday, 18 March 2019 at 10:05:40 UTC, Jacob Carlborg wrote: On 2019-03-17 21:09, Per Nordlöw wrote: I thought that already is the case... No, the official binaries are built with DMD as the host compiler. How come they're not built with LDC (for example) and then distributed? I'd think it'd be shit tonnes more performant? Yes it would be _a lot_ faster, but the release process is pretty complicated [1] and at the moment Martin is the only one who fully understands it and he's pretty busy with his day job and other tasks. [1] https://github.com/dlang/installer
Re: The D Programming Language has been accepted as a GSoC 2019 organization
On Tuesday, 26 February 2019 at 22:34:45 UTC, Seb wrote: Hi all, I have some very exciting news to share. The D Language Language got accepted as a Google Summer of Code organization! The official GSoC page provides a few initial pointers and details: https://summerofcode.withgoogle.com/organizations/6103365956665344 Below, I will try to answer a few common questions: What projects will be offered? -- You can find a list of potential projects at the D wiki: https://wiki.dlang.org/GSOC_2019_Ideas However, students can, of course, come up with their own projects, too! ... Happy hacking! @Students: you can find idea threads with more detailed and specific information about individual DLang GSoC subcomponents on our General Newsgroup with the [gsoc] tag. So far, these idea finding thread exists: - DUB (https://forum.dlang.org/thread/eftttpylxanvxjhoi...@forum.dlang.org) - DMD (https://forum.dlang.org/thread/iwvtxsecerbshhaga...@forum.dlang.org) Please don't be shy and start your own thread ;-)
Re: Release D 2.085.0
On Saturday, 2 March 2019 at 19:37:08 UTC, Cym13 wrote: On Saturday, 2 March 2019 at 18:19:37 UTC, Martin Nowak wrote: [...] In the -preview/-revert it is said: As of now, DMD offers these reverts: -preview=dip25: Reverts DIP25 changes -revert=import: Revert to single phase name lookup Shouldn't that be "-revert=dip25" instead of -preview there? Thanks! -> https://github.com/dlang/dlang.org/pull/2596
The D Programming Language has been accepted as a GSoC 2019 organization
Hi all, I have some very exciting news to share. The D Language Language got accepted as a Google Summer of Code organization! The official GSoC page provides a few initial pointers and details: https://summerofcode.withgoogle.com/organizations/6103365956665344 Below, I will try to answer a few common questions: What projects will be offered? -- You can find a list of potential projects at the D wiki: https://wiki.dlang.org/GSOC_2019_Ideas However, students can, of course, come up with their own projects, too! And @community: it's still possible to add more projects to this list. You can also put them new/old ideas up for discussion in the "General" Newsgroup. Though, it would be great if you could use the "[gsoc]" tag, s.t. we can keep track: https://forum.dlang.org/newpost/general?subject=%5Bgsoc%5D I want to propose my own project. What should I do? --- The list of proposed projects isn't final and we do encourage new project proposals as we want you to enjoy the GSoC and find a project that you care about. A rough road-map to a successful submission for your own project would be: 1) Evaluate your project and its planned outcome: how can this project help the D community? (good examples: compiler, druntime standard library, dub, popular dub projects) 2) Discuss your idea with the D community (e.g. here in the General forum) [optional, but recommended] 3) Get in touch with the D organization admins for guidance [optional, but recommended]. For obvious reasons we can't tell you whether your project proposal would be accepted, but we can tell you whether your project domain works in general. 4) Prepare and submit your proposal on the GSoC website What will you look at when judging applications? A few rough points that we will look at (we will publish more on this): - your proposed road-map (i.e. how likely is it for you to finish successfully?) - your skill set in regards to your project (i.e. have you done anything in the problem domain you're applying for?) - engagement in the community / experience with D (i.e. your prior contributions to D) ... I highly recommend you to read this student guide as it contains very helpful advice on the GSoC: http://write.flossmanuals.net/gsocstudentguide/what-is-google-summer-of-code I'm new to D and would like to apply. Is this still possible? - Yes of course and we do encourage you to do so. However, we recommend you to get involved with D prior to your proposal submission deadline in April. Two good starting points are: - https://tour.dlang.org/ - https://wiki.dlang.org/Get_involved Bugzilla can be a bit daunting at first, but there's also the "bootcamp" label on Bugzilla: https://issues.dlang.org/buglist.cgi?component=phobos=bootcamp%2C%20preapproved_type=anywords_id=225005=D_format=advanced=--- You can always ask for help and pointers to getting involved on the DForum, IRC or Slack. Where can I ask questions? -- - DForum (https://forum.dlang.org/newpost/general?subject=%5Bgsoc%5D) - Slack (#gsoc channel) - IRC (#d) - Mail (gsoc [at] dlang [dot] rocks) Happy hacking!
Re: Beta 2.085.0
On Saturday, 16 February 2019 at 19:21:12 UTC, Suliman wrote: -verrors=context Why this is not default behavior? It's the first release with them and the implementation may not be perfect (e.g. mixins and other corner cases).
Re: DCD 0.11.0 released
On Tuesday, 12 February 2019 at 19:46:29 UTC, notna wrote: On Tuesday, 12 February 2019 at 17:55:46 UTC, Basile B. wrote: On Monday, 11 February 2019 at 20:40:32 UTC, notna wrote: Installing DCD Downloading from https://github.com/dlang-community/DCD/releases/download/v0.10.2/dcd-v0.10.2-windows-x86.zip to C:\Users\\AppData\Roaming\code-d\bin Failed installing: std.net.curl.CurlException@std\net\curl.d(4340): Peer certificate cannot be authenticated with given CA certificates on handle I don't know what you are talking about, how are you installing DCD ? What is the installer you talk about ? Also the version number of this release is 0.11.0, not 0.10.2 Thats the errors vscode, better code-d, shows... seems like you want to update dcd and use the curl lib for that, which throws an error because the download (GitHub?) certificate cannot be validated. Just check the news group (or the "forum") for this code-d error and you should find a couple of similar complains. Have your ever considered reporting it at the code-d repository? https://github.com/Pure-D/code-d/issues It should drastically increase the chances of the maintainers of code-d actually seeing your problems.
Re: Google Summer of Code 2019
On Sunday, 25 November 2018 at 13:58:25 UTC, Mike Parker wrote: The time has come to start thinking about GSoC 2019. The application deadline for mentoring organizations is on February 6. I'd like to get a solid list of project ideas for potential student applications. I've set up a new page at the Wiki to collect ideas and seeded it with two from the GSoC 2018 page: https://wiki.dlang.org/GSOC_2019_Ideas I invite everyone to add ideas to the list. Please be as descriptive as you can in your summaries, and be explicit about the goals the project should achieve. We want projects that are both necessary and challenging. Anyone who is interested in participating as a student or a mentor, please contact me (aldac...@gmail.com). Be sure to visit the GSOC FAQ for links to details about what both roles entail: https://developers.google.com/open-source/gsoc/faq I'll be putting out more information in the coming weeks, here and on the blog. Just a ping to everyone that the application deadline is soon and that if you want to propose a project for this year's GSoC, this is your last chance to add it to the ideas pages. In doubt, please feel free to reach out to Mike (aldac...@gmail.com) or me (sebastian.wilzb...@gmail.com)
Re: Beta 2.084.1
On Tuesday, 5 February 2019 at 17:41:50 UTC, Johan Engelen wrote: On Tuesday, 5 February 2019 at 04:18:55 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.084.1 point release, Any chance of getting this in? https://github.com/dlang/phobos/pull/6814 -> https://github.com/dlang/phobos/pull/6855
Re: Release D 2.084.0
On Saturday, 5 January 2019 at 08:44:42 UTC, Mike Parker wrote: On Wednesday, 2 January 2019 at 13:25:25 UTC, Martin Nowak wrote: Glad to announce D 2.084.0, ♥ to the 53 contributors. This release comes with individual control over runtime checks, debuggable string mixins, and an experimental dub feature to improve build cache efficiency. http://dlang.org/download.html http://dlang.org/changelog/2.084.0.html -Martin The blog: https://dlang.org/blog/2019/01/05/dmd-2-084-0-has-arrived/ Reddit: https://www.reddit.com/r/programming/comments/acsg61/version_20840_of_dmd_the_d_reference_compiler_has/ -checkaction=context is only available with DMD nightly and will land in 2.085 (the documentation page has already been updated though as that one is generated from DMD master).
Re: D compilation is too slow and I am forking the compiler
On Wednesday, 21 November 2018 at 13:05:27 UTC, Nicholas Wilson wrote: On Wednesday, 21 November 2018 at 11:58:25 UTC, Vladimir Panteleev wrote: Have we tried disabling -unittest for modules that aren't on the compiler's command line yet (or, in case of -i, not excluded)? Not that I know of, thats a great idea! Yes it's sadly a well-known problem e.g. https://github.com/dlang/dmd/pull/8124
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.
Re: Optional and NotNull version 0.5.0 - swift optional like and scala option like
On Thursday, 16 August 2018 at 12:25:14 UTC, aliak wrote: Hi See: https://optional.dub.pm [...] 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).
Re: sumtype 0.5.0
On Thursday, 9 August 2018 at 00:07:05 UTC, Seb wrote: (It uses the version from DUB and updates itself once daily, but somehow dub still lists 0.4.1 at the moment) It looks like you didn't push the git tag to GitHub: https://github.com/pbackus/sumtype/releases
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`. Features: - Pattern matching, including support for structural matching (*) - Self-referential types, using `This` - Works with `pure`, `@safe`, `@nogc`, and `immutable` (*) - Zero runtime overhead compared to hand-written C - No heap allocation - Does not rely on runtime type information (`TypeInfo`) (*) Starred features (*) are those that are missing from `Algebraic`. Code examples are available in the documentation (linked below). New since the last announced version, 0.3.0: - Types with destructors and postblits are now handled correctly. - Unreachable handlers in `match` calls are now a compile-time error. - `match` handlers can now operate on the stored value by reference. - A new method, `tryMatch`, allows for non-exhaustive pattern matching. - Various small improvements to the documentation. Documentation: https://pbackus.github.io/sumtype/sumtype.html DUB: https://code.dlang.org/packages/sumtype Github: https://github.com/pbackus/sumtype That's a pretty cool library! I added it to run.dlang.io, s.t. it's easy for people to play with it and share examples, e.g. https://run.dlang.io/is/5znJXH (It uses the version from DUB and updates itself once daily, but somehow dub still lists 0.4.1 at the moment)
Re: Dpp on run.dlang.io
On Saturday, 4 August 2018 at 01:27:49 UTC, Laeeth Isharc wrote: Thanks to Seb and Atila it is now very easy to show a D program just #includeing C headers. If just works. Modulo bugs. In time I am hopeful Atila will start to have more of C++ headers working too. https://run.dlang.io/is/JlH3Th It now also supports multiple files (and compiling C files) with the Har format [1]: https://run.dlang.io/is/WwpvhT This should hopefully make it even more useful. [1] https://github.com/marler8997/har
Re: stri: string format/interpolation library for D. how to embed variables into string like shell scripts
On Sunday, 29 July 2018 at 14:55:46 UTC, Shigeki Karita wrote:
This library is very similar to Scala or shell scripts.
- https://github.com/ShigekiKarita/stri/tree/master
-
https://docs.scala-lang.org/overviews/core/string-interpolation.html
## example
import stri : s;
// runtime/compile-time variables
auto a = 1;
enum _a0 = "D-lang";
struct A {
static a = 0.123;
}
// you can use the default %s and custom ones e.g., %.3f
mixin s!"${a} is one. ${_a0} is nice. ${A.a%.3f}" i;
assert(i.str == "1 is one. D-lang is nice. 0.123");
Seems fairly similar to `interp` in scriptlike:
https://github.com/Abscissa/scriptlike
BTW it wouldn't be so hard to add string interpolation to the
language and compiler, there have been two PRs now. This was the
latest:
https://github.com/dlang/dmd/pull/7988
I think someone just needs to take a bit of time and write a DIP,
so that A can't say no ;-)
Re: Symmetry Autumn of Code
On Sunday, 22 July 2018 at 16:33:10 UTC, Zheng (Vic) Luo wrote: I'm interested in the "Graphics library for resource constrained embedded systems" project and have some spare time this autumn, but I have some questions: - Does this project aim at creating a hardware-agnostic rasterizer supporting a few primitives like https://skia.org/ or implementing a full GUI library like emWin rendering widget and handling I/O events such as mouse? The latter one sounds a little bit challenging to finish in four months I can't say too much about this as I'm not that familiar with the proposed project, but here's what I can say: it's just a suggestion. It's definition isn't set in stone and is just a pointer to a problem to get you started. For more pointers and discussion, I recommend to ping Mike (https://github.com/JinShil) as IIRC he was the one who proposed this project and could also be a potential mentor. (and I think the aim is sth. to sth. akin to Skia) - In the past year I primarily wrote C++ and don't have much experiences with production-level D programming, can I get involved into this program? Yes. Applicants aren't expected to be D experts. Also sound experience in C++ will definitely help you (especially for such a low-level project). AFAICT a sound proposal and showing that you are serious about the project/commitment is more important than your D history. There are a few posts in the D blog about the GSoC in 2016 (https://dlang.org/blog/category/gsoc) which provide a few more insights, but in short none of the students from GSoC 2016 were well-known member of the D community before the GSoC.
Re: The dub documentation is now on dub.pm
On Thursday, 19 July 2018 at 13:10:01 UTC, Martin Tschierschke wrote: There should be a big section for well done dub.sdl / dub.json examples. Yes, there should be! As always it just requires someone to step up, collect and add these examples. FWIW the dub and vibe.d repositories both contain a great selection of dub.sdl examples. What about defining "comment" as an special keyword for the .json parser inside Dub (just ignoring the content") to allow some kind comments inside .json In the moment only dub.sdl may be more descriptive with #comments. It's // or /* ... */ in dub.sdl ;-) But many people prefer .json where no comments are build in. So allow to write "comment" : "This string will will be parsed away", may do the difference? As you mentioned SDL already supports comments. JSON support was actually only added because too many people complained about SDL not being properly supported. Modifying the JSON parser is a bad idea as it will make integration with other tools harder. Actually the JSON parser already accepts dub.json files with a trailing comma which isn't valid JSON and has thus already resulted in a bit of pain for tool authors as they can't use an off-the-shelf JSON parser anymore. Currently, dub.json doesn't complain about unused fields (see https://run.dlang.io/is/2bbrN8), so you can already do the "comment" hack and if/once we actually check for valid field names, 'comment' could then be ignored.
The dub documentation is now on dub.pm
tl;dr: The dub documentation got split from the dub-registry repository and now lives on https://dub.pm (https://github.com/dlang/dub-docs). Motivation: --- - makes building the dub-registry faster - people hosting a mirror or a private instance don't need to host the documentation too - allows us to use a separate, more modern design for the dub docs (proposals are welcome!) - makes it easier for people contributing the docs (less code and dependencies to build) - allows us to remove the menu header at code.dlang.org and replace it with a nice, modern searchbar - makes the deployment for the documentation easier (they are static HTML after all) and we have already setup continuous deployment for the documentation (via Netlify) As always, ideas and PRs to make DUB's documentation better are welcome. PS: Of course all old documentation links will redirect to dub.pm
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ Reddit: https://www.reddit.com/r/programming/comments/8yram3/symmetry_autumn_of_code/
Re: D Security Team has been initiated
On Wednesday, 11 July 2018 at 13:58:42 UTC, bauss wrote: On Wednesday, 11 July 2018 at 05:28:45 UTC, Seb wrote: If you have a security-related concern or issue and feel like this shouldn't be discussed in public, please don't hesitate to contact us in private at: https://dlang.org/security The menu gives a 404 because it links to https://dlang.org/foundation/security.html and not https://dlang.org/foundation/security.html Good catch! Thanks. -> https://github.com/dlang/dlang.org/pull/2419
D Security Team has been initiated
If you have a security-related concern or issue and feel like this shouldn't be discussed in public, please don't hesitate to contact us in private at: https://dlang.org/security
Deploy your own Dub Registry to Heroku via one click
Ever wanted to run your own Dub registry and were too lazy to set it up? It's now one click away. Simply go to the Dub Registry (https://github.com/dlang/dub-registry) and press "Deploy to Heroku". Provided you have a Heroku account, everything else will automagically work. Note that Heroku even has a nice free tier for hobby projects. At the moment the Dub registry doesn't expose the Admin interface nor supports private packages. However, it's already very useful for Heroku's GitHub PR preview pipeline, e.g. https://github.com/dlang/dub-registry/pull/278 Also now there's a auto-deployed staging server based on master for the Dub registry: https://dub-registry-staging.herokuapp.com If you don't like Heroku, you can also use Docker to deploy your private Dub registry: https://github.com/dlang/dub-registry#deploy-your-private-dub-registry-with-docker
Re: LDC 1.11.0 beta
On Wednesday, 4 July 2018 at 20:38:54 UTC, kinke wrote: Glad to announce the first beta for LDC 1.11. * Based on D 2.081.0. * Prebuilt packages now using LLVM 6.0.1 and including additional cross-compilation targets (MIPS, MSP430, RISC-V and WebAssembly). Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.11.0-beta1 Thanks to all contributors! Would be great to include https://github.com/dlang/dmd/pull/8456 as it's a serious regression and the reason for the early 2.081.1 release.
Re: docker images
On Thursday, 28 June 2018 at 17:54:45 UTC, Radu wrote: Created a couple of docker images useful for dlang dev. LDC cross compiler for ARM - https://hub.docker.com/r/rracariu/ldc-linux-armhf/ This image allows one to easily cross compile to ARM. Main use-case is continuous integration servers. - https://hub.docker.com/r/rracariu/dub-registry/ Allows easily running a private dub repository on cloud. We now setup auto-deploy to DockerHub from the official dlang/dub-registry: https://github.com/dlang/dub-registry/pull/354 https://hub.docker.com/r/dlangcommunity/dub-registry/tags So your private Dub registry docker instance should be able to update itself automatically.
Re: Phobos and the Tools repo are now on DUB
On Monday, 25 June 2018 at 21:34:43 UTC, Seb wrote: Phobos ... I forgot the links to the DUB registry: https://phobos.dub.pm https://dtools.dub.pm
Phobos and the Tools repo are now on DUB
Phobos
--
It's now possible to access the latest version of Phobos's
experimental packages through dub:
```
#!/usr/bin/env dub
/++dub.sdl:
dependency "phobos:checkedint" version="~master"
+/
void main(string[] args)
{
import stdx.checkedint; // From latest Phobos
import std.stdio; // DMD's Phobos
writeln("checkedint: ", 2.checked + 3);
}
```
For now, only checkedint and allocator are exposed as subpackages.
FAQ
---
1) Why stdx and not std.experimental?
Otherwise the linker would run into symbol conflicts.
2) Why ~master?
D's versioning doesn't conform with SemVer yet. There are plans
to change it soon though.
3) What's the purpose?
Allow usage of experimental packages like
std.experimental.allocator for Dub packages.
For example, at the moment the upcoming collections library
(https://github.com/dlang-stdx/collections), doesn't compile
with stable dmd or ldc as it depends on very recent changes in
the std.experimental.allocator.
4) What are the next steps?
At the moment the "allocator" sub package doesn't fully work as
some parts of the allocator module depend on package(std) parts
of Phobos (e.g. std.conv.emplaceRef). So fixing this is of course
the next step. However, for now, there are no plans to expose the
more stable parts of Phobos on dub.
5) Wait. Aren't Phobos and DMD supposed to be built in sync?
It's certainly true that Druntime has a lot of dependencies on
DMD, but most modules in Phobos (except e.g. std.traits or
std.math) don't have such a strong dependence. This especially
applies to the experimental modules which were originally
developed as dub packages (and probably should have stayed on
dub).
6) What are your guarantees for stability?
None. This is experimental.
Tools
-
Almost all tools in the tools repo
(https://github.com/dlang/tools) can be built & run with dub now.
For example, this converts your Windows files to Posix file
ending:
```
dub fetch dtools
dub run dtools:tolf -- mywindowsfile.d
```
The long-term goal here is to replace the win32.mak with a pure
D/Dub build file.
Re: iopipe v0.1.0 - now with Windows support!
On Tuesday, 19 June 2018 at 13:04:24 UTC, Steven Schveighoffer wrote: On 6/19/18 7:18 AM, Jacob Carlborg wrote: On 2018-06-11 16:45, Steven Schveighoffer wrote: I just pushed v0.1.1 -- I realized that I never *actually* compiled on windows, and there were a couple things that didn't work. Note: the examples still don't work as they rely on openDev, which is only available on Posix systems now. I need to figure out a good way to open stdin/stdout in a cross platform way with std.io. You should setup AppVeyor [1] to make it works on Windows (when it works). [1] https://www.appveyor.com I just set up travis to do the Linux/mac testing. I need to add appveyor as well, but haven't gotten to it. I'm a complete CI noob, so I'm learning slowly :) -Steve Just copy/paste one of the existing configuration scripts and you should be good to go, e.g. https://github.com/dlang-community/DCD/blob/master/appveyor.yml And there's also: https://github.com/Abscissa/AppVeyor-D
Re: Beta 2.081.0
On Sunday, 17 June 2018 at 05:20:51 UTC, Manu wrote: The biggest highlight in this release for C++ users like myself is a huge amount of work relating to extern(C++). I think this is the biggest step forward since it was introduced in 2012. Mixed-language class hierarchies are now supported, and a whole raft of long-standing ABI issues have been worked out, making construction and destruction semantics compatible between languages. No more work-arounds for virtual destructors, or factory-style 'create' functions are required. It's still an amazing progress! Thank you!! I was planning to make this change to the release notes before the next release, but I had no idea a release was imminent. Are there announcements ahead of the release branch being tagged? https://dlang.org/changelog/release-schedule.html Anyway, if we could see that those patches are integrated into 2.081, that'd be very excellent. Targeting stable and getting it merged before the final 2.081 release (in two weeks) should be all you need. (The beta release announcement [1] would be updated too, but as it probably will be regenerated over the course of the beta period and will be removed once the beta period is over, it's not that important.) [1] https://github.com/dlang/dlang.org/blob/master/changelog/2.081.0_pre.dd
Re: AppVeyor-D: Project to track recommended appveyor.yml (Win CI)
On Thursday, 31 May 2018 at 11:03:43 UTC, jmh530 wrote: On Thursday, 31 May 2018 at 08:31:21 UTC, Nick Sabalausky (Abscissa) wrote: [snip] One nice thing about this (compared to the DWiki page) is that its actually being tested by AppVeyor itself. Plus, it now has full GitHub Issues/PR support for managing enhancement/submissions/discussion, all in one central place. [1]: https://wiki.dlang.org/Continuous_Integration Thanks for this. Is there something similar for Travis? https://dlang.org/install.html (the script is used by Travis)
DConf hackathon track document
As the DConf hackathon is coming up soon, we created a quick document to list the tracks people will be working: https://docs.google.com/document/d/1qrn7JZS62hzsylpGM1VhaT6YW2I1NVDDGQsANv5b1GQ/edit If you already have an idea or want to start a new group, now is the time to add yourself to the track document. Happy hacking tomorrow!
DUB registry is now Boost licensed
Just a quick heads-up at all those people how were considering of rolling a customized dub in-house (or on your favorite PaaS provider). You can now modify it without needing to publish all your patches which the GPL license before required. Of course, improvement patches (aka PRs) are still very welcome ;-) See also: https://github.com/dlang/dub-registry/pull/272
DConf Slack channel
Hey everyone, the DConf Slack channel is at dconf.slack.com If you haven't joined yet, visit the invite bot to get an invite: https://dconf-slack-invite.herokuapp.com
C++ Meetup @ DConf on Thursday, May 3rd (7pm)
We are very happy to announce another special event at this year's DConf. For the first time, DConf will host a C++ Meetup. On Thursday evening (7pm) (i.e. after all official talks and enough time to have dinner), the C++ folks will invade the DConf territory. There will be a main talk by Sandro Andrade, a professor at the Bahia Federal Institute of Technology, about "Implementing MOF-based Modeling Languages with C++ and Qt", but the main idea of hosting the C++ Meetup is to fuse the C++ and D community and open interesting discussions between "frenemies". You can find more details at the C++ Meetup page: https://www.meetup.com/MUCplusplus/events/250250374
Things to do in Munich
As I live in Munich and there have been a few threads about things to do in Munich, I thought I quickly share a few selected activities + current events. Activities -- A few highlights: - over 80 museums (best ones: Museum Brandhost, Pinakothek der Moderne, Haus der Kunst, Deutsches Museum, Glyptothek, potato museum, NS-Dokumentationszentrum) - English Garden (Munich's biggest park with many activities - e.g. there are surfers at Eisbachwelle) - BMW Welt (car museum + very modern architecture) - Old churches (Asamkirche, Marienkirche) - View over the city: Alter Peter or Vorhoelzer Cafe - Allianz Arena (arena of FC Bayern München) - Castle Nymphenburg (the king's summer residence) - Olympic Park (e.g. view from the Olympic Tower) - Glockenbackviertel/Gärtnerplatz (main square of the former LBGT scene) More sights at e.g. https://www.likealocalguide.com/munich/sights Current events to do There's much to do in Munich if you want to take an evening off or are staying a day longer. Munich city portal provides a good overview (in German): http://www.muenchen.de/veranstaltungen/event/listing.html?what06.05.2018 A few highlights include: ### Frühlingsfest http://www.muenchen.de/veranstaltungen/event/7816.html What: "Little" Oktoberfest Where: Theresienwiese (U6) ### Wannda https://www.wannda.de http://www.muenchen.de/veranstaltungen/event/25762.html What: Culture festival Where: Leonrodplatz When: starts at 4.5 ### MaiTUM http://maitum.de What: Maypole festival + 150 years of TUM celebrations Where: Garching When: 3-4.5 ### Long night of clubbing https://www.eventbrite.de/e/die-langste-nacht-der-munchner-clubs-10tes-jubilaum-mit-diesem-ticket-bitte-im-neuraum-sweet-musee-tickets-43160701821 What: One ticket for 14 clubs + bus lines between them When: 4.5
Re: Pre-DConf Meetup on May 1
On Wednesday, 25 April 2018 at 14:13:55 UTC, Seb wrote: Hi all, I hope you are all looking forward to DConf. We (Stefan, Dragos and I) have very good news for you. Our next D Munich Meetup will coincide with DConf to give our local community who can't join DConf an opportunity to meetup all the rockstars from the D community. Agenda -- We will kickoff with a lightning talk session where DConf speakers can practice a part of their talk in front of a live audience and give local D hackers a sneak-peak at DConf (thanks to all speakers who have already volunteered to give a short talk). @ others: There's no registration required, just bring your laptop and of course even non-DConf speakers are invited to present their ideas/projects. Afterwards we will have a Fishbowl conversation [1]. Logistics - The Meetup will be at Austin Fraser GmbH (Lenbachplatz 1, München). As Austin Fraser will sponsor Pizza and Drinks please RSVP on Meetup, s.t. we know how much food to order. https://www.meetup.com/Munich-D-Programmers/events/250094983/ For those of you who stay at the hotel, we will be at the NH München Messe hotel at 18:00 and lead you towards the venue. No risk at getting lost ;-) Looking forward to seeing you soon, The D Munich Meetup organizers [1] https://en.wikipedia.org/wiki/Fishbowl_(conversation) Just a quick reminder about the Pre-DConf Meetup. We are looking forward to kick-off DConf18 with all of you tomorrow! As mentioned I will be at München Messe hotel at 18:00 and make sure no one gets lost on the way to Austin-Fraser. If you haven't reached the hotel yet: - Taxis are rather expensive (>80€ from the airport) - With public transport: S8 to "Ostbahnhof" and then switch to Bus 190 towards "Messestadt Ost" and exit at "Zamdorf Siedlung" - The ticket will be 11.60€ one way (you need all four zones) Plan your trip online: https://efa.mvv-muenchen.de/index.html?itdTime=1720=20180501=de_origin=3240_destination=NH%20M%C3%BCnchen%20Messe,%20Eggenfeldener%20Str.%20100,%2081929%20M%C3%BCnchen=dep#trip@origdest If you want to leave earlier or on your own, going to Austin-Fraser (Lenbachplatz 1) via public transport from the NH Messe hotel takes about half an hour and will require a single trip "1 zone" ticket. You can plan this online too: https://efa.mvv-muenchen.de/index.html?itdTime=1720=20180501=de_origin=3240_destination=NH%20M%C3%BCnchen%20Messe,%20Eggenfeldener%20Str.%20100,%2081929%20M%C3%BCnchen=dep#trip@origdest
Re: The dlang-community releases DCD 0.9.3 and D-Scanner 0.5.2
On Friday, 27 April 2018 at 15:20:15 UTC, Jacob Carlborg wrote: On 2018-04-27 09:43, baz@dlang-community wrote: DCD 0.9.4 is available now. Same link. How come there are no binaries for macOS? Seems to be a release script and Travis CI configuration for macOS. Because the DCD release script was broken and was updated after DCD 0.9.4 was built: https://github.com/dlang-community/DCD/pull/464 And I can only easily build binaries for Linux and Windows locally. Sorry. DCD 0.9.5 will come with macOS binaries (the same applies for dfmt too).
Pre-DConf Meetup on May 1
Hi all, I hope you are all looking forward to DConf. We (Stefan, Dragos and I) have very good news for you. Our next D Munich Meetup will coincide with DConf to give our local community who can't join DConf an opportunity to meetup all the rockstars from the D community. Agenda -- We will kickoff with a lightning talk session where DConf speakers can practice a part of their talk in front of a live audience and give local D hackers a sneak-peak at DConf (thanks to all speakers who have already volunteered to give a short talk). @ others: There's no registration required, just bring your laptop and of course even non-DConf speakers are invited to present their ideas/projects. Afterwards we will have a Fishbowl conversation [1]. Logistics - The Meetup will be at Austin Fraser GmbH (Lenbachplatz 1, München). As Austin Fraser will sponsor Pizza and Drinks please RSVP on Meetup, s.t. we know how much food to order. https://www.meetup.com/Munich-D-Programmers/events/250094983/ For those of you who stay at the hotel, we will be at the NH München Messe hotel at 18:00 and lead you towards the venue. No risk at getting lost ;-) Looking forward to seeing you soon, The D Munich Meetup organizers [1] https://en.wikipedia.org/wiki/Fishbowl_(conversation)
Re: The dlang-community releases DCD 0.9.3 and D-Scanner 0.5.2
On Monday, 23 April 2018 at 17:04:09 UTC, Baz @dlang-community wrote: Time to update your favorite D completion daemon and D linter since previous patch were not announced. Changelogs: - https://github.com/dlang-community/DCD/releases - https://github.com/dlang-community/D-Scanner/releases For all those building IDE plugins for DCD & co: This is the first D-Scanner release which comes with release binaries for Windows, Linux and macOS. DCD and dfmt are in the process of receiving similar, automated builds too.
Re: DUB packages announce Telegram bot
On Sunday, 22 April 2018 at 08:41:36 UTC, Denis Feklushkin wrote: On Sunday, 22 April 2018 at 07:59:11 UTC, Seb wrote: On Sunday, 22 April 2018 at 07:49:00 UTC, Denis Feklushkin wrote: Hi! I also made a tool which periodically monitors code.dlang.org for new packages and a notifies its Telegram subscribers. To subscribe just write something to @dlang_announce_bot Also it can be added to groups. Code: https://github.com/denizzzka/paper_plane_bot Cool! BTW any reason why you parse the HTML and not use the JSON index? As I know, code.dlang.org provides JSON package list without any additional info. Thus, it is need to parse every package separately by calling https://code.dlang.org/packages/*.json to get packages versions, and it is need to do for every registerd package. Hmm, I just wanted to point out that in the time it took you to write the HTML parser, you could have added an API method to the registry: https://github.com/dlang/dub-registry/blob/master/source/dubregistry/api.d I created an issue, s.t. this isn't lost in the NG space: https://github.com/dlang/dub-registry/issues/326 Oh and the reason why I point out that parsing the HTML isn't ideal, it's because it might change soon, e.g. https://github.com/dlang/dub-registry/pull/303
Re: DUB packages announce Telegram bot
On Sunday, 22 April 2018 at 07:49:00 UTC, Denis Feklushkin wrote: Hi! I also made a tool which periodically monitors code.dlang.org for new packages and a notifies its Telegram subscribers. To subscribe just write something to @dlang_announce_bot Also it can be added to groups. Code: https://github.com/denizzzka/paper_plane_bot Cool! BTW any reason why you parse the HTML and not use the JSON index? Also adding a new API route to the dub registry might be a bit API friendlier then fetching all packages on every cron operation. Generating the index JSON is rather expensive (until a few recent fixes, you could kill the registry by requesting the index.json a few times in a row). Though of course the dub registry (or its reverse proxy) could cache the result for a bit...
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 16:51:57 UTC, Atila Neves wrote: If you get to the point where you can #include , it will be doubly impressive! Not *if*, *when*. ;) Atila FYI people have been fighting with this for a long time: https://github.com/dlang/druntime/pull/1316
Re: Dockerfile with cross-compiler targeting Windows x64
On Saturday, 7 April 2018 at 12:24:54 UTC, kinke wrote: Any MS libs that can be bundled "legally"? That's the problem. If there were, they'd be bundled with the LDC Windows packages, so that LDC on Windows wouldn't require a Visual C++ installation anymore and just work out of the box. To avoid confusion: we're talking about the static and import .lib files of the Visual C++ runtime & Windows SDK, not about the redistributable DLLs. The libs on DropBox are from Visual Studio 2015 Update 3, while the LDC 1.8 druntime/Phobos libs have been compiled with latest VS 2017, so this divergence could become problematic at some point. Hmm how hard would it be to use the MinGW libraries like DMD is doing as a fallback since 2.079? https://dlang.org/changelog/2.079.0.html#lld_mingw Rainer's excellent work on this is mostly found in dlang/installer: https://github.com/dlang/installer/blob/build-mingw-libs/windows/build_mingw.bat https://github.com/dlang/installer/blob/build-lld/windows/build_lld.bat https://github.com/dlang/installer/pull/281 https://github.com/dlang/dmd/pull/7500 (mingw and lld are separate branches, s.t. they aren't built on every AppVeyor run)
Re: Dockerfile with cross-compiler targeting Windows x64
On Thursday, 5 April 2018 at 22:10:08 UTC, WebFreak001 wrote: On Thursday, 5 April 2018 at 11:46:42 UTC, Jacob Carlborg wrote: I've created a Dockerfile [1] containing LDC, configured for cross-compiling targeting Windows x64. It's based on the instructions provided by kinke here [2]. Note, it downloads the MSVC libs from Dropbox. [1] https://github.com/jacob-carlborg/docker-ldc-windows/blob/master/Dockerfile [2] https://github.com/ldc-developers/ldc/pull/2142#issuecomment-304472412 -- /Jacob Carlborg cool exactly what I always wanted... but how do you use it? 1) Remove the last line which defines the ENTRYPOINT (the one that the root docker image defines is better suited 2) Run this: wget https://raw.githubusercontent.com/jacob-carlborg/docker-ldc-windows/master/Dockerfile docker build -t dlanguage/ldc-windows . docker run --rm -ti -v $(pwd):/src dlanguage/ldc-windows ldc2 hello.d If this gets pushed to DockerHub, just the last line will be enough because Docker would fetch the image automatically for you. See also: https://hub.docker.com/r/dlanguage/ldc (dub seems to still default to writing `.a` object files) BTW I just tested this and it works really nicely (I even managed to compile the whole DScanner for Windows (!) and it runs as expected in a quick test in a virtual machine). Thanks! Now how do we get this to DockerHub? :) Any MS libs that can be bundled "legally"?
Re: code-d 0.17.0 + serve-d 0.1.2
On Wednesday, 4 April 2018 at 06:36:41 UTC, WebFreak001 wrote: On Tuesday, 3 April 2018 at 23:50:24 UTC, Arredondo wrote: I could not get this to work for me in the past (I'm using Windows 10). I saw this announcement so I decided to try again. After reinstalling code-d I got this in the OUTPUT console: Installing DCD Installing into C:\Users\Wulfrick\AppData\Roaming\code-d\bin > git clone --recursive --depth=1 https://github.com/Hackerpilot/DCD.git DCD Failed to install DCD std.process.ProcessException@std\process.d(753): Failed to spawn new process (The system cannot find the file specified.) 0x00384D1F 0x00384AD2 0x00382ADD It looks like he doesn't have git installed... My extension still assumes you have git and that probably won't change until DCD provides precompiled binaries. The syntax coloring seems wrong, go to definition doesn't work, and there are no completition suggestions (Ctr+Space just displays "Loading..."). Moreover, the extension is completely SPAMMING the output console, making it pop up constantly with endless messages like: Yes without DCD many things will not work but formatting, code linting and outline and dub should still work. Loading... should not happen. FYI the latest release of dfmt, dscanner and dcd comes with binaries for Linux. The next release will have binaries for OSX: https://github.com/dlang-community/DCD/pull/458 We are still trying to find the easiest way to build binaries for Window on our CIs, see e.g. https://github.com/dlang-community/discussions/issues/9 But either AppVeyor or Wine should work.
Re: Need a fancy domain for your project? .dub.pm has you covered!
On Tuesday, 3 April 2018 at 21:28:01 UTC, Tony wrote: Not a big deal since the same table is on code.dlang.org, but on the https://dub.pm/index.htm table, the headings "Name", "Registered" and "Score" are all active links, but the sort is not currently working. Yes, that's expected. dub.pm is a __static__ page and we are currently in the progress of splitting up the documentation from code.dlang.org to dub.pm See e.g. https://github.com/dlang/dub-registry/pull/308
Re: Need a fancy domain for your project? .dub.pm has you covered!
On Thursday, 23 February 2017 at 14:16:35 UTC, Seb wrote: Hey all, As I own dub.pm since a year and it hasn't been used much, I have just configured automatic sub-domain rewriting, s.t. everyone can have nice and fancy URLs. All sub-domains get redirected to their respective DUB package page, so now you can browse e.g. eventcore.dub.pm vibe-core.dub.pm ... In the future the package pages might be served directly without redirects (vote for this behavior at [1]) If you don't like the layout, design or features of the dub-registry, it's just a PR away [2]! Last, but not least a reminder that if you need a .dlang.io or .dlang.rocks subdomain for your project, I am happy to set the DNS for you. Just give me a short ping [3]. Cheers and happy hacking! Seb [1] https://github.com/dlang/dub/issues/781 [2] https://github.com/dlang/dub-registry [3] https://seb.wilzba.ch/contact As Letsencrypt now supports SSL wildcards, *.dub.pm are now all accessible via SSL: https://mir.dub.pm https://container.dub.pm
Re: Beta 2.079.0
On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak wrote: On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote: 17. Allow multiple selective imports from different modules in a single import statement I have a bad feeling that that one is going to be a source of a raft of bugs for years to come. No need to use it if you don't like it. It's particularly useful for small examples, localized imports and hacking. It's mainly a generalisation of the existing possibility to mix module imports and one selective import at the end. If you prefer java-like 50 lines import manifests, then by all means keep using those. How would that feature cause bugs though? AFAICT Rust now has introduced the exactly same feature. It's quite interesting to see that there was no outcry by the community and it was universally liked: https://blog.rust-lang.org/2018/03/29/Rust-1.25.html https://github.com/rust-lang/rust/issues/44494
Re: Vulkan ErupteD breaking changes and transition strategy
On Monday, 26 March 2018 at 09:04:20 UTC, Anton Fediushin wrote: On Monday, 26 March 2018 at 07:51:31 UTC, Seb wrote: On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin wrote: This is a *bad* idea and you shouldn't do that. Just increase MAJOR version and start from there: 2.0.0 - Changing how binding works, Vulkan v1.0.69 2.1.0 - Vulkan 1.0.70 ...And so on. This way semver is followed and you don't have to mess with erupted-v1 and erupted-v2 repos. Also note that SemVer allows to attach meta data: 2.0.0+1.0.69 That'll work too, but I'm not sure how dub handles it. Anyway, even a little note in release description "Vulkan API vX.X.X" should be enough. It will work fine with dub (it just ignores the meta data). For example, if you do a `dub add-local`, your package version is "+ annotated" with the git commit sha.
Re: Vulkan ErupteD breaking changes and transition strategy
On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin wrote: This is a *bad* idea and you shouldn't do that. Just increase MAJOR version and start from there: 2.0.0 - Changing how binding works, Vulkan v1.0.69 2.1.0 - Vulkan 1.0.70 ...And so on. This way semver is followed and you don't have to mess with erupted-v1 and erupted-v2 repos. Also note that SemVer allows to attach meta data: 2.0.0+1.0.69 Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. https://semver.org/#spec-item-10
Re: Why think unit tests should be in their own source code hierarchy instead of side-by-side
On Thursday, 22 March 2018 at 12:25:59 UTC, bauss wrote: On Thursday, 22 March 2018 at 11:47:34 UTC, Alexandru Ermicioi wrote: On Thursday, 22 March 2018 at 11:19:46 UTC, Basile B. wrote: On Thursday, 22 March 2018 at 11:00:31 UTC, Atila Neves wrote: On Thursday, 22 March 2018 at 10:59:56 UTC, Atila Neves wrote: [...] Direct link: https://atilanevesoncode.wordpress.com/2018/03/22/keep-d-unittests-separated-from-production-code/ Sorry for the forum spam. Atila I don't agree at all. Everything is so much faster when unittest blocks are in the same module as the stuff that are tested. Generally i think that it makes things easier. It's easier, true. But not all code can be nicely unittested using small chunks of unittests near the actual code. Consider unittested objects/structs, in each unittest you'll have to instantiate and stuff with mocks if needed and test a small piece of functionality from them. Also there is a problem with mocked objects where they will go? If every bit of functionality will be tested in same module with source code, then unittest / line of actual code will be much more to unittests part. It will make your module hard to navigate and discover what your source code is actually doing. So having a separate module with unittests indeed will help in making more claner and more understandable since they won't interfere with actual code. Also if you use templates with unittests sometimes private symbols may succeed in the unittest, but fail when the template is used in practice. Such bugs have existed in Phobos plenty of times. Yes, but for the record they got extinct since ~ one year once CircleCi with its setup test extraction pipeline started to enforce this. There's no reason DMD couldn't do this by default internally when it finds a public unittest. Or your favorite build tool could do such an extraction though granted then you do loose the "built-in", simplistic aspect of unittests.
OT: Coffee prices [was Re: The D Language Foundation at Open Collective]
On Thursday, 15 March 2018 at 12:36:24 UTC, Meta wrote: On Wednesday, 14 March 2018 at 12:00:42 UTC, Seb wrote: Yeah, the idea is that 5$ a month isn't much (~ one coffee in most countries), but if 500 people donate one coffee a month, you get the entire coffee machine with a warp engine :) Sorry to derail, but I had to ask: where does 1 coffee (even extra large) cost $5 USD? Let me know so I know to never move there. Have you ever been to Starbucks (or similar companies)? Even in Germany which is among the cheapest Western European countries they charge 5$ (~4€) for a cup of coffee: http://www.fastfoodpreise.de/preisliste/starbucks.html For example, in Sweden it's even more expensive: https://www.quora.com/What-is-the-average-price-of-a-cup-of-Starbucks-coffee-in-Sweden Anyhow, it was just an analogy. Maybe you prefer one beer as a better analogy? (though in Germany that's often cheaper than one cup of coffee)
Re: State of D 2018 Survey
On Wednesday, 14 March 2018 at 07:37:02 UTC, Seb wrote: On Sunday, 11 March 2018 at 18:34:57 UTC, Seb wrote: On Wednesday, 28 February 2018 at 13:41:56 UTC, Mike Parker wrote: About a month ago, Sebastian Wilzbach sent an email out to a few of the core D folks asking for feedback on a survey he had put together. He thought it would be useful for the Foundation to use in order to make decisions about where to expend development efforts. Eventually Andrei gave his stamp of approval, the survey questions were tweaked, and then it was ready to roll. Of course I would love for you to read my blog post announcing it, but if you want to skip the prose and go straight to the good stuff, here's the survey link: https://seb134.typeform.com/to/H1GTak The blog: https://dlang.org/blog/2018/02/28/the-state-of-d-2018-survey/ Reddit: https://www.reddit.com/r/d_language/comments/80w29n/the_state_of_d_2018_survey/ Wow, we got more than 500 responses so far. A huge thank you already! The survey is still open for a few more days, so if you want to make your opinion count now is the last chance. Today is the final day of the survey. If you haven't taken it, use the last hours ;-) It's closed now. Thanks again for all your input! We have received 540 replies - thanks to each and everyone of you who has invested their time to give us such detailed feedback. An initial auto-generated report without the open-text questions can be viewed at: https://dlang.typeform.com/report/H1GTak/PY9NhHkcBFG0t6ig A more in-depth analysis and summary will follow in the next weeks.
Re: Proposal for a standard Decimal type in alpha
On Wednesday, 14 March 2018 at 14:23:44 UTC, Jordi Gutiérrez Hermoso wrote: On Friday, 12 January 2018 at 15:44:01 UTC, Jack Stouffer wrote: On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer wrote: ... While I believe my library has certain API advantages, I'm really not interested in duplicating a bunch of work when rumbu's version is pretty much complete, so I'm dropping this. I was daydreaming today about using D to replace a certain Python computation module at work, but to do this, we really require a bigfloat/bigdecimal type. I think I might want to help completing this work, either your's or rumbu's. What's the code to look at? I found yours, but I couldn't find rumbu's. https://forum.dlang.org/thread/mutegviphsjwqzqfo...@forum.dlang.org?page=1
Re: The D Language Foundation at Open Collective
On Wednesday, 14 March 2018 at 11:51:04 UTC, Martin Tschierschke wrote: On Tuesday, 13 March 2018 at 15:45:51 UTC, Mike Parker wrote: On Tuesday, 13 March 2018 at 15:26:24 UTC, Martin Tschierschke wrote: The Website needs the link, too!: https://dlang.org/foundation/donate.html Yes, there's a PR for it waiting to be merged. https://github.com/dlang/dlang.org/pull/2272 Cool, it is online now. On the Open Collective page should be mentioned, that it just has started. So no one wonders that so far only a few are listed. Good idea! The description at OpenCollective itself needs some work too :/ Additionally you should ensure to transfer the names "automatically" or periodically to https://dlang.org/foundation/sponsors.html That's already in the queue: https://github.com/dlang/dlang.org/pull/2273 And last but not least place a small donate button on every page page! Not sure whether that's a good idea, it might look a bit needy. We already have a donate button on the front page since a few weeks though. With 500 people participating in the survey there should be the chance to boost up the impact of D with more manpower and money. Yeah, the idea is that 5$ a month isn't much (~ one coffee in most countries), but if 500 people donate one coffee a month, you get the entire coffee machine with a warp engine :)
Re: Added Wiki page Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices
On Wednesday, 14 March 2018 at 09:29:26 UTC, dangbinghoo wrote: hello there, Just added a paper for cross compiling D on arm linux devices. https://wiki.dlang.org/Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices Great article! How about making a blog post for the DBlog out of this? --- A few comments: As my english is not that good, every body who find mistakes just try to fix it. The MediaWiki notation for links is [link title] - not Markdown. Pandoc can convert between markdown and MediaWiki. This means that all library path does not includes libssl, libcrypto, libz. You need to find or build a toolchain with extra lib built-in, or, just cross-compiling the desired c library and install to your toolchain sysroot path. You can disable ssl completely by adding `versions "VibeNoSSL"` to your dub.sdl (or `versions: ["VibeNoSSL"]` to dub.json) If you download LDC2 standalone release from github page, say: [ldc2-1.8.0-linux-x86_64.tar.xz](https://github.com/ldc-developers/ldc/releases/download/v1.8.0/ldc2-1.8.0-linux-x86_64.tar.xz) we need a little bit tricky thing to do: The recommended way is to use the official install script (https://dlang.org/install.html) curl https://dlang.org/install.sh | bash -s ldc $ vim test.d better use sth. like this, s.t. copy/pasting is easy: cat > test.d << EOF ... EOF
Re: State of D 2018 Survey
On Sunday, 11 March 2018 at 18:34:57 UTC, Seb wrote: On Wednesday, 28 February 2018 at 13:41:56 UTC, Mike Parker wrote: About a month ago, Sebastian Wilzbach sent an email out to a few of the core D folks asking for feedback on a survey he had put together. He thought it would be useful for the Foundation to use in order to make decisions about where to expend development efforts. Eventually Andrei gave his stamp of approval, the survey questions were tweaked, and then it was ready to roll. Of course I would love for you to read my blog post announcing it, but if you want to skip the prose and go straight to the good stuff, here's the survey link: https://seb134.typeform.com/to/H1GTak The blog: https://dlang.org/blog/2018/02/28/the-state-of-d-2018-survey/ Reddit: https://www.reddit.com/r/d_language/comments/80w29n/the_state_of_d_2018_survey/ Wow, we got more than 500 responses so far. A huge thank you already! The survey is still open for a few more days, so if you want to make your opinion count now is the last chance. Today is the final day of the survey. If you haven't taken it, use the last hours ;-)
Re: The D Language Foundation at Open Collective
On Monday, 12 March 2018 at 14:37:40 UTC, rikki cattermole wrote: Can you guys add another donation package, which is basically pay what you want towards a more long term issue? To incentivize fixing. Monetary wise I shouldn't donate but I do care about shared library support enough that I will talk with some cash. The idea is to create dedicated kickstarter campaigns for the most pressing issue of the community. Once the State of D survey has been concluded and analyzed, we will most likely kickoff the first campaign. Stay tuned!
Re: Vision document for H1 2018
On Monday, 12 March 2018 at 04:54:22 UTC, Jonathan M Davis wrote: On Monday, March 12, 2018 03:37:11 Laeeth Isharc via Digitalmars-d-announce wrote: On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote: > [...] Why are you adding -j8 ? Does it say to do so in the instructions ? Try without it. (I can't test here as typing from my phone). When dealing with building on Windows, it would definitely pay to read the instructions and not assume anything about make, since unfortunately, the Windows build uses the digital mars make, which is severely limited in comparison to the BSD make or GNU make. - Jonathan M Davis That's only partially true and the reason for the error. GNU/BSD make is required to run the DMD testsuite. BTW removal of DigitalMars Make has been officially approved since a long time, but it's blocked since it's so hard to make changes to the auto-tester.
Re: State of D 2018 Survey
On Wednesday, 28 February 2018 at 13:41:56 UTC, Mike Parker wrote: About a month ago, Sebastian Wilzbach sent an email out to a few of the core D folks asking for feedback on a survey he had put together. He thought it would be useful for the Foundation to use in order to make decisions about where to expend development efforts. Eventually Andrei gave his stamp of approval, the survey questions were tweaked, and then it was ready to roll. Of course I would love for you to read my blog post announcing it, but if you want to skip the prose and go straight to the good stuff, here's the survey link: https://seb134.typeform.com/to/H1GTak The blog: https://dlang.org/blog/2018/02/28/the-state-of-d-2018-survey/ Reddit: https://www.reddit.com/r/d_language/comments/80w29n/the_state_of_d_2018_survey/ Wow, we got more than 500 responses so far. A huge thank you already! The survey is still open for a few more days, so if you want to make your opinion count now is the last chance.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote: On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote: And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for. There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). Don't forget that "open source" != non-profit. For the C# compiler there's a dedicated team of full-time developers. Also to be fair, the activity on dmd isn't that low either though the last week was a one with low-traffic: https://github.com/dlang/dmd/pulse Typically ~40 PRs get merged per PR for dmd alone: https://auto-tester.puremagic.com/chart.ghtml?projectid=1 With druntime + phobos, it's a lot more. The difference (at least for me) is that contributing to C# is a no-brainer. Contributing to D needs an advanced degree in computer science. Using the information on the D wiki didn't helped me until now to successfully compile and test a fresh copy of dmd or phobos. I assume you are using Windows? Setup on Posix is really simple. git clone all three repos + run make. There's also a bash script to automate this: https://github.com/dlang/tools/blob/master/setup.sh From what I heard it's a bit tricky on Windows. I only tried with wine and that worked out-of-the-box for me. Execute the DMD installer, set PATH, DM_HOME and HOST_DC and then run the win32 makefiles work fine. What could be done from your perspective to make the setup easier?
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote: On 3/6/18 2:30 PM, Martin Nowak wrote: On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote: But if needed, you could have your dub package depend on a prior version. http://code.dlang.org/packages/stdx-allocator ;) This is the answer, vibe.d should depend on stdx-allocator. -Steve Vibe.d (and a lot of other projects) do depend on this package, see e.g. https://github.com/vibe-d/vibe.d/pull/1983 Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm and not released as the latest stable tag yet, which is the reason for Atila's justified complaint.
Re: Release D 2.079.0
On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote: On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote: Glad to announce D 2.079.0. This release comes with experimental `@nogc` exception throwing (-dip1008), a lazily initialized GC, better support for minimal runtimes, and an experimental Windows toolchain based on the lld linker and MinGW import libraries. See the changelog for more details. Thanks to everyone involved in this https://dlang.org/changelog/2.079.0.html#contributors. http://dlang.org/download.html http://dlang.org/changelog/2.079.0.html - -Martin Is is just me or did this release just break the latest non-beta vibe.d? Is the Jenkins build testing the dub packages on master instead of the latest tag? Atila https://github.com/vibe-d/vibe.d/issues/2058
Re: State of D 2018 Survey
On Wednesday, 28 February 2018 at 20:24:00 UTC, JN wrote: On Wednesday, 28 February 2018 at 20:01:16 UTC, Seb wrote: Thanks! I hope so too! Is there some way to access the results without retaking the survey? Yeah the link TypeForm generates at the end is permanent: https://dlang.typeform.com/report/H1GTak/PY9NhHkcBFG0t6ig though for some reason it doesn't show full-text answers (I have opened a support ticket for that a while ago). Anyhow, as Mike said we will look at all answers and do a summary once the survey concluded.
Re: State of D 2018 Survey
On Wednesday, 28 February 2018 at 19:31:27 UTC, Cym13 wrote: If that were to be done again here are a few points that I'd improve: - there are many occurences of open questions where I entered a text only to find that the next fixed-choice question was about what I had written. I therefore feel like open questions should be asked as late as possible. Ok. Understood. I tried to avoid this, but I obviously (partially) failed. - some questions introduce clear bias as they don't have a clear default exit path. For example for "How would you rate the importance of having documentation and error messages translated into your native language?" I feel like english speakers should have a way to exit cleanly as clearly they are both more numerous than the counter part (I think) and less likely to feel a need for supporting other languages. ... Good point! There are a few questions that already have logic jumps (e.g. you get only asked about your experience with the DTour if you actually said that you used it), but I obviously missed that one. It's too late for that one now, but I will definitely keep this in mind for 2019. (also TypeForms so called "smart" jumps are severely limited, but you got to use what you have.) - I don't know if typeform allows it but sometimes having a link to the feature discussion or library reference would have been great. I didn't had to search many of them to actually know what the survey was talking about (which doesn't always indicate that I'm not concerned about the consequences of the change). TypeForm only allows a general description for questions which very limited Markdown (not even link support, only raw links). Anyhow, the feedback: "better descriptions" for questions is noted. Thanks! That said, it was a very complete survey, thanks to everybody involved in putting this up! I hope it'll be of some use to the foundation. Thanks! I hope so too!
Re: State of D 2018 Survey
On Wednesday, 28 February 2018 at 17:42:29 UTC, H. S. Teoh wrote: I can't access the survey. It causes my browser to hang at 100% CPU because of some JS issues, and it doesn't work without JS. Not that's not a bug, but a feature (aka filter) ;-) No seriously, this shouldn't happen (TypeForm is the biggest company in this survey game). What browser do you use?
Re: State of D 2018 Survey
On Wednesday, 28 February 2018 at 14:53:23 UTC, bachmeier wrote: If you ask about tabs vs spaces but not Emacs vs vi, nobody will take the language seriously. And why are there no questions about beards? I thought one "fun" question is enough. Maybe next year we get more creative ;-)
Re: State of D 2018 Survey
On Wednesday, 28 February 2018 at 15:07:51 UTC, jmh530 wrote: On Wednesday, 28 February 2018 at 13:41:56 UTC, Mike Parker wrote: [snip] A few comments 1) How about an N/A or does not apply option? You can simply skip the questions. All questions are optional. 2) The progress bar was weird, I went from 80% done to 57% done at one point. Yeah that's a Typeform bug. It's due to their logic jumps. I have reported this to their support a while ago already. The problem is that depending on what you answer you "jump" through the survey and see only the relevant questions (e.g. If you state that you have tried the DTour, you will be asked no further questions about it). I think the way the implemented this is that the only insert questions until the next logic jump + the permanent ones at the end, hence the jumps ...
d.godbolt.org now supports DMD
Thanks to the work of Rabs Rincon [1] DMD is now supported on https://d.godbolt.org A simple example of comparing DMD's object code with LDC's + GDC's output: https://godbolt.org/g/EQCTNy [1] https://github.com/mattgodbolt/compiler-explorer/issues/306
Re: Beta 2.079.0
On Friday, 23 February 2018 at 17:47:08 UTC, Kagamin wrote:
auto result = foo(), bar();
Doesn't look like it works.
---
int f(int a){ return a; }
int main()
{
int a=f(0),f(1); //doesn't compile
return 0;
}
---
int f(int a){ return a; }
int main()
{
int a;
a=f(0),f(1);
assert(a==1); //fails
return 0;
}
---
https://run.dlang.io/is/IgArs0
Yeah that should result in an error:
https://issues.dlang.org/show_bug.cgi?id=18508
Re: Beta 2.079.0
On Friday, 23 February 2018 at 03:20:22 UTC, psychoticRabbit wrote: compared to the current change in beta. FWIW the change is almost gone from the beta: https://github.com/dlang/dmd/pull/7939
Re: Beta 2.079.0
On Friday, 23 February 2018 at 01:34:54 UTC, Rubn wrote: On Friday, 23 February 2018 at 00:05:59 UTC, Martin Nowak wrote: - each imported module should be on it's own line That's your opinion, my opinion is that importing 6 symbols from 6 different modules for a tiny cli tool sucks and bloats code example. So the alternative is to not use selective imports, but only those and static imports have a clear path to become lazy (https://issues.dlang.org/show_bug.cgi?id=13255). This can be solved by adding a package.d to phobos. This doesn't need a language change that introduces more ambiguities for such a subjective matter as "I'm too lazy to write 5 more lines of code". 5 Lines of code is hardly bloat for a code example. Example code is better to follow best practices, or you get the whole `using namespace std` situation like you do with C++. The people that actually can comprehend won't be hindered by it, and everyone else it won't make a difference cause they have no understanding of what they are doing and just copy and paste the code. Yes, with 2.079 those who want, can do `import std.experimental.all` [1]. (It has been renamed from scripting to all since the prerelease changelog was created) In later versions, it might be renamed to std/package.d, but we first want to assess whether there are potential problems except the potential collisions and potential decrease in "understandability". Anyhow, `experimental` is a good playground for such tests. [1] https://dlang.org/changelog/2.079.0.html#std-experimental-scripting
Re: Beta 2.079.0
On Thursday, 22 February 2018 at 13:35:00 UTC, aliak wrote: barring a revert, Who says we can't revert it? https://github.com/dlang/dmd/pull/7939 On the contrary, imho if it's so controversial it should be reverted now, s.t. it doesn't accidentally end up in 2.079 and we would be stuck with it for a long time.
Re: Beta 2.079.0
On Monday, 19 February 2018 at 18:30:56 UTC, Ali Çehreli wrote: On 02/19/2018 02:49 AM, Martin Nowak wrote: Thanks Martin! You can add at least the following aliases for the contributor list: acehreli: Ali Çehreli aldacron: Mike Parker Ali ... or you could have used your actual name for your GitHub commits ;-) https://github.com/dlang/tools/pull/322
