Buildkite and the Project Tester
Hi, So for those of you who have contributed to D on GitHub in the last few months, you might have noticed the new Buildkite CI status checks. tl;dr: - it's the replacement for the Jenkins project tester (which has been deactivated ~ three months ago) - it allows us to add our own agents to the build fleet [1, 2] - it's intended to unify all CI systems on the long run (currently not possible due to a lack of build resources) So what are the other CIs doing? auto-tester: normal testing pipeline DAutotest: documentation testing (diff + preview) CircleCi: code coverage builds + style checks SemaphoreCI: self-bootstrapping (build dmd with LDC, GDC or a freshly built dmd) AppVeyor: 64-bit Windows builds + Visual Studio builds Travis: only used for tools, dlang.org and dub (test steps) CodeCov: code coverage diff (install the browser extension to see uncovered lines in the diff) Why can't I access the Buildkite build logs? Unfortunately Buildkite doesn't allow public access to their logs yet (though they are working on it). This is why I have just sent out a few more invitations. If I haven't gotten you, I'm sorry, but please send me a ping [3]. Otherwise you can also use the read-only dummy account below. Having an account has the advantage that you can restart builds, the dummy account is read-only. My build is failing and I think the failure isn't related to my changes --- Report this on #ci in Slack or https://github.com/dlang/ci The Auto-tester has its own GitHub repository: https://github.com/braddr/d-tester/issues Dlang-Bot has its own GitHub repository too: https://github.com/dlang-bots/dlang-bot I want my project to be tested on the Project Tester Your project's testsuite will be run on every PR which should prevent any regressions with a new DMD release. Open an issue (or a PR) here: https://github.com/dlang/ci I have resources I can spare for more testing agents Awesome! Talk to us in #ci or https://github.com/dlang/ci Dummy Account - user: du...@dlang.io password: dlangrocks Happy hacking! [1] https://buildkite.com/docs/agent/v3 [2] https://buildkite.com/docs/agent/v3/ubuntu [3] https://github.com/wilzbach
Re: Updating D beyond Unicode 2.0
On Friday, 21 September 2018 at 23:00:45 UTC, Erik van Velzen wrote: Agreed with Walter. I'm all on board with i18n but I see no need for non-ascii identifiers. Even identifiers with a non-latin origin are usually written in the latin script. As for real-world usage I've seen Cyrillic identifiers a few times in PHP. A: Wait. Using emojis as identifiers is not a good idea? B: Yes. A: But the cool kids are doing it: https://codepen.io/andresgalante/pen/jbGqXj In all seriousness I hate it when someone thought its funny to use the lambda symbol as an identifier and I have to copy that symbol whenever I want to use it because there's no convenient way to type it. (This is already supported in D.)
Re: Small @nogc experience report
On Thursday, 20 September 2018 at 13:21:21 UTC, Atila Neves wrote:
On Thursday, 20 September 2018 at 12:41:07 UTC, Petar Kirov
[ZombineDev] wrote:
On Thursday, 20 September 2018 at 10:50:49 UTC, Atila Neves
wrote:
This pattern is incredibly easy to wrap and reuse as needed.
I would've done already if only I'd known @nogc was ignored
as well as pure.
It's a recent development:
https://dlang.org/changelog/2.082.0#debug-unsafe :
Unsafe code can now be used in debug blocks
https://dlang.org/changelog/2.079.0 :
Bugzilla 16492: support @nogc in debug{} blocks
Ah. I was wondering how that passed me by! Thanks.
The only bit missing is `nothrow`:
https://github.com/dlang/dmd/pull/8449
Re: dub auto-tester
On Thursday, 20 September 2018 at 05:04:49 UTC, Neia Neutuladh wrote: On Thursday, 20 September 2018 at 04:41:21 UTC, Joakim wrote: Nice, what will it take to get this integrated with the official dub website? I need to: * add JSON output to the auto-tester * get the dub registry to scrape the data (or, optionally, push the data to the registry, but that opens up trust issues that I'd rather not get into) * enable SSL on the report site (and probably get a new domain Feel free to send me a ping if you want a .dlang.io subdomain.
Re: Truly @nogc Exceptions?
On Wednesday, 19 September 2018 at 21:28:56 UTC, Steven Schveighoffer wrote: On 9/19/18 5:16 PM, Steven Schveighoffer wrote: One further thing: I didn't make the sink version of message @nogc, but in actuality, it could be. We recently introduced support for output ranges in the formatting of Phobos: https://dlang.org/changelog/2.079.0.html#toString Output ranges have the advantage that they could be @nogc and because of the templatization also @safe.
Re: Embrace the from template?
On Friday, 24 August 2018 at 20:04:22 UTC, Jonathan Marler wrote: I'd gladly fix it but alas, my pull requests are ignored :( They aren't! It's just that sometimes the review queue is pretty full. I have told you before that your contributions are very welcome (like they are from everyone else) and if there's anything blocking your productivity you can always ping me on Slack.
Re: D on Twitter
On Thursday, 23 August 2018 at 22:49:32 UTC, Peter Alexander wrote: For comparison: @rustlang: 32.7k followers 12.7k tweets @D_Programming: 10.1k followers 1k tweets 10,000 is a lot of people to reach, and 1k tweets over 8 years is too little to seem engaging. Fair point. Thanks for bringing this up! It's worth noting that Rust has full-time paid people working on "community engineering". Some suggestions: * Post everything that happens from the Announce forum. https://twitter.com/dlang_ng does this, but it has effectively no followers. A bot could do this. It's already automated and doing this automatically with the trusted account is risky as everyone can post to NG.annouce. However, every new blog entry does get posted on Twitter and Facebook (not sure whether that's automated). BTW we also have @dlangbot (https://twitter.com/dlangbot) which tweets about every merged PR, but I think somehow no one knows about this. * Subscribe to #dlang on twitter and retweet anything good. Not only does this highlight interesting D-related content, but also gives others incentive to discuss #dlang there. AFAICT this is already been done and the official Twitter account regularly retweets important #dlang tweets. I don't know who runs the account, but I think both of these should be quite easy to achieve with little effort. Of course, it is easy to be generous with others' time :-) Mike Parker (aka aldacron) is the person who currently runs it and while I agree that things could be better (they always can) I do think he does a very good job at his one-man fight for D's outreach.
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 02:18:15 UTC, Mike Franklin wrote: On Wednesday, 22 August 2018 at 01:07:28 UTC, Mike Franklin wrote: But what bothers me the most... Something else that rubs me the wrong way is that DIP 1000 is currently in a status of `DRAFT`: https://github.com/dlang/DIPs/blob/master/DIPs/README.md What the heck is going on here? We're adding features to the compiler and modifying Phobos in production releases based on a `DRAFT` proposal? No, it's behind a flag, so you can't really say that we're shipping it as "production ready release". In fact I think we should have a hell of a lot more of such experimental flags. This would allow us to be able to merge things quickly, and gain real-world feedback and testing on complicated matters instead of PRs stalling to death in the queue. For reference, Rust has currently 148 opt-in experimental language features: https://doc.rust-lang.org/unstable-book/index.html
Re: Engine of forum
On Tuesday, 21 August 2018 at 03:42:21 UTC, Ali wrote: On Monday, 20 August 2018 at 09:52:01 UTC, Peter Alexander wrote: What are the specific problems solved or opportunities realised by moving to a real forum? What are the specific problems solved by using better software? Well, most software projects, have different channels of communications, some use forums, some use newsgroups, some use irc, some use slack, Yep, D also has an active IRC channel (#d) and Slack group (https://forum.dlang.org/post/gidqeijjswgnpveog...@forum.dlang.org). some rely on stackoverflow, some have an active wiki There are a few good points to move D.learn to Stack Overflow and that's actually one thing that we have talked about a few times and somehow never has happened. In the D survey there was a 2:1 "consensus" for StackOverflow.
Re: Give DLS a try
On Tuesday, 14 August 2018 at 23:24:58 UTC, Soulsbane wrote: On Tuesday, 14 August 2018 at 22:24:48 UTC, Laurent Tréguier wrote: On Tuesday, 14 August 2018 at 21:07:34 UTC, Soulsbane wrote: Perhaps I missed it but is there an option to disable dfmt completely. I see several options, for example, d.dls.format.dfmtSoftMaxLineLength. If you're using the VSCode extension or Atom package, then there is no way to deactivate any features, I'm going to add that to the extensions' settings. No problem. Thanks! It's the mainly the d.dls.format.dfmtBraceStyle that is bothering me. It seems each one uses the if () style and I prefer if(). If that makes sense. Again, thanks a lot for this! In theory it would be `dfmt_space_after_keywords` in the .editorconfig, but it's not implemented yet: https://github.com/dlang-community/dfmt#dfmt-specific-properties
Re: Signed DMD binaries
On Monday, 13 August 2018 at 19:09:55 UTC, Jacob Carlborg wrote: Any plans for doing the same thing for the installer on macOS? It complains that it's from an unidentified developer and forces the user to go into System Preferences and reopen the installer. Yes, the certificate allows signing binaries for OSX too. However, as we still haven't fully figured out how to integrate the binary signing for Windows in the release process (and this can be done on Linux) and OSX binary signing can only be done on OSX AFAICT, this might take a bit until it gets integrated. Also I think Martin is the only one who currently has the VirtualBox image for OSX setup which is required by the create_dmd_release build tool. In case someone wants to have a look, the relevant steps happen/should happen here: https://github.com/dlang/installer/blob/master/create_dmd_release/build_all.d#L329
Re: Remove CRT (C's runtime) from betterC binaries?
On Tuesday, 14 August 2018 at 13:11:57 UTC, Rel wrote: Can I or is it even possible to remove the CRT (C's runtime library) completely from my executables compiled with betterC flag? Have a look at example 3 of the 2.079 changelog: https://dlang.org/changelog/2.079.0.html#minimal_runtime
Signed DMD binaries
As a few of you might have noticed, we bought a Code Signing Certificate a few days ago and while we're still investigating on how to integrate the code signing best into the release process, I thought a share a first preview of signed DMD binaries with you. So I semi-officially repacked 2.081.2 and signed the released binaries and libraries: http://files.wilzba.ch/dlang/releases sha256sum dmd.2.081.2.windows.7z 598a477e3692fb43c2bf010d62620506e0d0169e5dbaaa909ab9fca84204f751 dmd.2.081.2.windows.7z In the future, the official releases will come with signed binaries, but as there are a few people running into troubles with their company software policy or virus scanner, I thought I share this semi-official release with you. Feedback is welcome ;-)
Re: ./install.sh dmd broken?
On Monday, 13 August 2018 at 17:10:13 UTC, Jonathan Marler wrote: Seb and I found the issue (TLDR: fix here: https://github.com/dlang/installer/pull/338) ... What made it more confusing is that if it doesn't download d-keyring.gpg, then it will create a default one...making you think it was downloaded but it actually wasn't...odd. In your case you'll want to manually remove "~/dlang/d-keyring.gpg" and use the new "install.sh" script after PR 338 is merged/deployed. The respective hotfix PR is merged and deployed now ;-)
Re: dub is not able to install any package
On Monday, 13 August 2018 at 13:37:28 UTC, Adil wrote: On Monday, 13 August 2018 at 13:28:02 UTC, Joakim wrote: On Monday, 13 August 2018 at 13:02:43 UTC, Adil wrote: dub build Package gelfd not found in registry at https://code.dlang.org/ (fallback ["registry at http://code.dlang.org/";, "registry at https://code-mirror.dlang.io/";, "registry at https://code-mirror2.dlang.io/";, "registry at https://dub-registry.herokuapp.com/";]): Failed to load curl, tried "libcurl.so", "libcurl.so.4", "libcurl-gnutls.so.4", "libcurl-nss.so.4", "libcurl.so.3". Looks like you need to install a libcurl package also, in some place where dub can find it. Thanks. It seems the `snap` version is not packaged with a libcurl. It worked when i switched to a `dub` installed via `apt` I opened an issue for you: https://github.com/dlang-snaps/dmd.snap/issues/24
Re: dub is not able to install any package
On Monday, 13 August 2018 at 13:02:43 UTC, Adil wrote: Dub details are: adil@adil-HP-ENVY-Notebook:~/workspace/screener-d$ whereis dub dub: /snap/bin/dub adil@adil-HP-ENVY-Notebook:~/workspace/screener-d$ dub --version DUB version 1.9.0, built on May 31 2018 How did you install D / dub? As Joakim mentioned curl is a dependency of std.net.curl which is used by dub.
Re: ./install.sh dmd broken?
On Friday, 10 August 2018 at 13:19:21 UTC, Jean-Louis Leroy wrote: jll@euclid:~/dlang$ ./install.sh dmd Is there anything specific about your machine? We ship our own keyring on the first usage of the install.sh script, which will get stored to ~/dlang/d-keyring.gpg You can do the following to check the current keyring: gpg --no-default-keyring --keyring ~/dlang/d-keyring.gpg --list-keys You should see a similar output as on https://dlang.org/gpg_keys.html Also: sha256sum ~/dlang/d-keyring.gpg 4de1bb6028bb1e3d4eefd9e1a1651ad6c372ead0482b63e3aafdfdc0fbb48dbd /home/seb/dlang/d-keyring.gpg However, if this is really the issue I don't know how you could have ended up with an old keyring on a new machine. So please provide all the input and information about your machine that could be relevant. Thanks! Same problem with 'install update'. But not when installing ldc or gdc. That's because they don't ship signed binaries ;-)
Re: Is there any hope for "lazy" and @nogc?
On Wednesday, 1 August 2018 at 20:32:11 UTC, Iain Buclaw wrote: On 1 August 2018 at 18:52, Shachar Shemesh via Digitalmars-d wrote: [...] My first thought was to have a look at enforce(), but on closer observation it is neither @nogc or nothrow. Maybe you should raise a bug report? It's certainly worth an attempt to bridge these two features together. I think it makes sense enough that lazy parameters should infer attributes from the function, and that it should be an error to pass a parameter that does not meet those constraints. i.e: --- // Signatures. void myAssert(bool cond, lazy string msg) @nogc nothrow; string mayAlloc() nothrow; string mayThrow() @nogc; // Code myAssert(cond, mayAlloc());// violates @nogc myAssert(cond, mayThrow());// violates nothrow --- Iain. Isn't this https://issues.dlang.org/show_bug.cgi?id=12647?
Re: Interested in participating SAOC 2018
On Wednesday, 1 August 2018 at 20:32:10 UTC, Venu Vardhan Reddy Tekula wrote: Hello! Myself, Venu. I am in the second year of my Computer Science and Engineering at Amrita School of Engineering, Kerala, India. I heard about SAoC and had a look at the projects list and one thing got my attention was this one, https://wiki.dlang.org/SAOC_2018_ideas#Automate_the_collection_and_publishing_of_data_for_monitoring_D.27s_progress_as_a_software_development_project. [...] Great to hear that you are interested in helping out! Yes, vibe.d is a popular web framework in D. I recommend you try it out as projects who plan to mainly use D mainly will for obvious reasons be preferred.
Re: Moving druntime into the DMD repository
On Tuesday, 31 July 2018 at 19:54:20 UTC, Steven Schveighoffer wrote: If anything makes sense, it would be to remove the compiler-dependencies out of druntime into a smaller runtime library that is included in the dmd project. Most of druntime is dependencies for the platform, not the compiler. Moving object.d to the dmd repository would be rather easy: https://github.com/dlang/dmd/pull/8529 https://github.com/dlang/druntime/pull/2262 and already help a lot in decoupling both. Maybe that's a compromise that can be made?
Re: Moving druntime into the DMD repository
On Tuesday, 31 July 2018 at 19:54:20 UTC, Steven Schveighoffer wrote: On 7/31/18 2:24 PM, Walter Bright wrote: Since DMD and Druntime require each other, it is the right thing to do. I think this is an incorrect relationship. DMD does NOT require Druntime, *testing* DMD requires Druntime. Well DMD ships just happens to ship with Druntime ;-) In fact, I thought the whole point of the -betterC feature was to eliminate any dependency on druntime. That's only partially true. Even with -betterC, `object.d` will still be imported by default and actually many language features that work in -betterC will be lowered to druntime (even in betterC): One simple example: https://run.dlang.io/is/41vvoO As we move to more and more library-provided hooks and away from "compiler magic", this coupling will become less and less prevalent. On the contrary, DMD will depend more and more on druntime as the magic is now in druntime and not in the dmd source code. In fact, most of the changes that require both projects to be simultaneously to be updated are these magic-removing ones. Yes and no. Whenever you want to update a library hooks (which are implementation-defined and not part of the specification), it's rather complicated to do with keeping all CIs happy. If anything makes sense, it would be to remove the compiler-dependencies out of druntime into a smaller runtime library that is included in the dmd project. Most of druntime is dependencies for the platform, not the compiler. Good idea!
Re: @betterC, @TestBetterC , @betterCTest or @("betterC") to annotate Phobos's unittests?
On Tuesday, 31 July 2018 at 10:09:08 UTC, Jacob Carlborg wrote: Shouldn't be any conflict because the "betterC" symbol would be in a different module. ... I would say, if it's only for internal use then it can be placed in `std.internal` with the `package` protection. If you want this to be used outside of Phobos then I recommend putting it in `core.attribute` in druntime, since that already exists. Cool! std.internal.attributes and @betterC it is then: https://github.com/dlang/phobos/pull/6645 This should allow to gradually annotate more unittests in Phobos with @betterC (like we did with @safe or @nogc), and allow us to gradually increase the -betterC subset.
Re: Is there any hope for "lazy" and @nogc?
On Tuesday, 31 July 2018 at 07:49:40 UTC, Shachar Shemesh wrote: On 31/07/18 10:29, Mike Franklin wrote: Please clarify if I'm missing the point. You are. I want something along the lines of: assertEQ(a, b, "a and b are not equal"); When run, it would issue an assert that says: Assertion failed: 3!=7: a and b are not equal You could also vote for this PR (https://github.com/dlang/dmd/pull/8517) - this PR will generate such error messages. It's intended to work in -betterC and @nogc (once the PR is ready).
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sunday, 29 July 2018 at 08:28:08 UTC, Walter Bright wrote:
On 7/29/2018 1:15 AM, Manu wrote:
All we're asking for is that C++ namespaces do **nothing**
except affect the mangling.
If I do that, the next bug report will be:
extern (C++, "ab") { void foo(); }
extern (C++, "cd") { void foo(); } // Error, foo() is already
declared
foo(); // which one gets called?
The reason namespaces were added to C++ is to not have such
name collisions. Namespaces in C++ introduce a scope. D cannot
interoperate with this without introducing a scope as well.
FYI: this doesn't error as of now, but with
https://github.com/dlang/dmd/pull/8429 it will.
Re: Moving druntime into the DMD repository
On Friday, 27 July 2018 at 11:25:37 UTC, Mike Franklin wrote: On Friday, 27 July 2018 at 11:03:50 UTC, Seb wrote: - Do you have a better suggestion? Do we have a rich enough CI API to recognize dependencies between repositories? For example, if I create a local branch in my dmd repository named `fix_bug` and a local branch in my druntime repository also named `fix_bug` and submit both PRs to their corresponding repositories, can the CI scripts recognize that they have the same branch name and pull them both for testing? Mike It's already implemented for branches under the respective dlang repository. This roughly happens on every CI: ```sh for proj in druntime phobos; do if [ $BRANCH != master ] && [ $BRANCH != stable ] && ! git ls-remote --exit-code --heads https://github.com/dlang/$proj.git $BRANCH > /dev/null; then # use master as fallback for other repos to test feature branches clone https://github.com/dlang/$proj.git ../$proj master else clone https://github.com/dlang/$proj.git ../$proj $BRANCH fi done ``` However, this only applies if the PR is targeting the respective branch, which means the workflow is a bit more annoying * push dmd branch to dlang/druntime-dmd * open PR at dmd targeting master (from druntime-dmd) * create druntime-dmd branch at dlang/druntime * push changes to private branch * open PR at druntime targetting druntime-dmd * merge druntime-dmd back to master once the druntime PR has been approved and merged It's a bit of an overhead for small changes though :/ Checking out the branch from your repository is problematic, because it's not exposed as environment variable and we would need to query the GitHub API to find this. Now the GitHub API gets rate-limited pretty quick, we would have to use our own GitHub API cache layer and ensure the requests coming from the CIs are really ours.
@betterC, @TestBetterC , @betterCTest or @("betterC") to annotate Phobos's unittests?
Phobos has recently gotten a primitive way to run betterC tests
(https://github.com/dlang/phobos/pull/6640).
Now, it would be really cool if we can annotate existing tests
with e.g. `@betterCTest` and thus ensure that those tests work
with -betterC (i.e. extract them and run them with a minimal test
runner.
a) @betterC
Probably too popular and would lead to too many conflicts.
b) @TestBetterC
c) @betterCTest || @bettercTest
Would probably be defined a enum somewhere in `std.internal`
d) @("betterC")
A bit ugly and harder to work with. If we ever want to name the
unittests in Phobos, this will make it harder.
At some point we might also want to test whether something runs
even without any runtime
(https://github.com/dlang/phobos/pull/6641), so e.g.
`@baremetalTest` might be defined too.
My favorite is (c) - any objections?
See also: https://github.com/dlang/tools/pull/357 (implementation
of the test extraction filter for UDAs)
Re: Moving druntime into the DMD repository
On Friday, 27 July 2018 at 12:02:50 UTC, Russel Winder wrote: On Fri, 2018-07-27 at 11:03 +, Seb via Digitalmars-d wrote: This a thread to explore whether it would be feasible to do so. Motivation -- DRuntime and DMD heavily depend on each other. But DMD is only one of the compilers, there is LDC and GDC. Is Druntime unique to DMD or do the other compilers also use it? It's unique to the DMD Frontend which is used by LDC/GDC ;-) They use it with small modifications, e.g. for the LLVM intrinsincs and a few LDC specific features: https://github.com/ldc-developers/druntime https://github.com/dlang/druntime/compare/master...ldc-developers:ldc
Re: Moving druntime into the DMD repository
On Friday, 27 July 2018 at 12:04:18 UTC, Jonathan M Davis wrote: On Friday, July 27, 2018 5:03:50 AM MDT Seb via Digitalmars-d wrote: What do you think? -- - Has the dmd/druntime split being annoying you too? - Do you have a better suggestion? - Would this break your workflow in a drastic way? It would break all existing tools and scripts that are used to build the existing repos - many of which are not official tools. So, yes, it would be very annoying. FWIW I don't think this would be the case. All build scripts I have seen call the Makefile (except for LDC/GDC, of course). The Makefile build would continue to work at any stage. That's not necessarily a good enough reason not to do it, but IMHO, it really needs to provide solid benefits to rearrange things like that for it to be worth breaking all of the existing tools that anyone uses for building dmd, druntime, and Phobos. As mentioned, I don't know of any tool that builds druntime itself. Everyone calls the Makefiles. If there are tools that build druntime on their own, it would be a very good point yes. It also arguably makes no sense in that a lot of what's in druntime has nothing to do with dmd - e.g. all of the OS C bindings are in there. There are also several modules that need to be in druntime, because druntime uses them but don't really have much to do with the compiler (e.g. core.time and core.thread). And not only from a code organizational standpoint does the current separation make a lot of sense for a lot of what's in druntime, but it also matters from the standpoint of who has permissions to do what. Right now, it's reasonable to give privileges to folks to merge PRs for druntime who have no business merging PRs for dmd. If the repos are merged, then we're forced to either give some of those folks dmd merge rights or make the smaller pool of folks who have merge rights for dmd deal with those PRs. This shouldn't be a problem either as GitHub's CODEOWNERS files, are made for this use case and all we need would be sth. this: * @team-dmd src/druntime @team-druntime https://help.github.com/articles/enabling-required-reviews-for-pull-requests (Step 8) Also, given that druntime gets linked into Phobos, having that repo be part of the compiler is that much weirder. In that sense, it belongs more with Phobos than dmd. The dependencies between the three repos do occasionally cause problems, but overall, I think that the separation makes a lot of sense. It causes A LOT of problems in terms of maintaining the CI and build scripts, moving things between DMD and adding test for druntime features to the dmd testsuite.
Moving druntime into the DMD repository
This a thread to explore whether it would be feasible to do so.
Motivation
--
DRuntime and DMD heavily depend on each other.
It happens very often that a PR needs to touch both and then a
complicated three-step (or sometimes four-step PR series) needs
to be done to keep the CIs happy.
Moreover, as the whole testsuite is at dmd, it happens more often
that an error is caught in the testsuite, but would require a
druntime PR or the opposite you make a PR to druntime and want
its accompanying test to be checked by the CI.
How would this happen?
--
A potential migration could look like this:
- lock druntime (e.g. only allowing admins to merge)
- move source code to dmd (of course with the git history, see
e.g. [1])
- update the druntime/posix.mak build script to forward to the
new source location
- update other dlang Makefiles
- remove everything else from druntime (optional check for the
Makefile update step)
- update CIs and build scripts (more on this below)
[1] https://stackoverflow.com/a/10548919/3026245
What would need to be updated?
-
- Makefiles for DMD, Druntime, Phobos, Tools, Dlang.org (mostly
path updates)
- LDC/GDC (I think LDC already includes druntime as git submodule)
If we update the druntime/posix.mak file to call the
druntime/posix.mak at its new location, then there would be zero
breakage (druntime already requires dmd to cloned) and over time
these can be updated:
- CI scripts (all of them explicitly clone druntime, but removing
that line should be all)
- Release scripts at dlang/installer
- Packager build scripts
(most distros just ship the the libphobos2.{so,a} libraries, but
if druntime is shipped too, it will require a path update for the
release after such a potential migration.)
What do you think?
--
- Has the dmd/druntime split being annoying you too?
- Do you have a better suggestion?
- Would this break your workflow in a drastic way?
Re: C's Biggest Mistake on Hacker News
On Thursday, 26 July 2018 at 09:55:39 UTC, Ecstatic Coder wrote: You can choose whatever priorities you prefer for your scholarship and funded projects. I only tried to point out that the SAoC scholarships depend on proposal ideas by the D community (e.g. through the D wiki) and encouraging students to submit their applications. Thus complaining about the D leadership not respecting your proposal if you didn't even bother to put up a potential proposal in the D wiki isn't really fair to them. Sorry to have showed my disagreement with some of your choices and strategies. That was silly, being a loss of time for both of us, indeed. Sorry if you misunderstood. Critics and negative feedback is welcome (!), but if it's just "they don't follow me", it's hard to put it into actionable items and make it happen.
Re: Kaspersky Endpoint Security 10 flags the DMD installer as malicious!
On Wednesday, 25 July 2018 at 09:13:27 UTC, Mike Franklin wrote: On Wednesday, 25 July 2018 at 08:27:25 UTC, Rel wrote: To be exact as a "HEUR:Trojan-Downloader.Win32.Agent.gen". Few other AV software does the same: https://www.virustotal.com/#/file/0aa364c5cb90630a5757aacc0c3c05a2273f5fdb88e14e2b80d4c19ee5b16d10/detection I think, we should do something about it, at very least report for false-positive to Kaspersky or something. It's been reported at https://issues.dlang.org/show_bug.cgi?id=18786 For some reason it's not being taken seriously. It's embarrassing to say the least. Mike See https://forum.dlang.org/post/reccnvpdbboenpome...@forum.dlang.org - I also forwarded a few internal mails to you.
Re: "catch" not catching the correct exception
On Thursday, 26 July 2018 at 05:52:51 UTC, Shachar Shemesh wrote: At which point I'm stuck. I don't know how D's catch matching works, so I don't know where to continue looking. https://github.com/dlang/druntime/blob/master/src/rt/dwarfeh.d You still use druntime, right?
Re: Kaspersky Endpoint Security 10 flags the DMD installer as malicious!
On Wednesday, 25 July 2018 at 09:49:54 UTC, Radu wrote: On Wednesday, 25 July 2018 at 08:31:05 UTC, rikki cattermole wrote: On 25/07/2018 8:27 PM, Rel wrote: To be exact as a "HEUR:Trojan-Downloader.Win32.Agent.gen". Few other AV software does the same: https://www.virustotal.com/#/file/0aa364c5cb90630a5757aacc0c3c05a2273f5fdb88e14e2b80d4c19ee5b16d10/detection I think, we should do something about it, at very least report for false-positive to Kaspersky or something. This is a pretty regular problem for Windows. Until we start signing the executables, it will never end. It is a very simple thing to do. But the foundation hasn't bothered buying a code signing certificate, even though it is cheap. Would be nice to hear why they haven't done this yet, considering that just the recurring open collective donations could cover expenses like this. It's not about paying for the certificate, if that would be all, we would have done this long ago! The problem is to integrate it in our release process and that no one involved has much experience with Windows. It doesn't make things easier that we run Windows via VirtualBox for the release building and the snake oil industry requires a hardware 2FA process when signing binaries with their certificate. Let me quote Martin (our release tzar) from one of the many internal mails: I can figure this all out, it's again a small but lower-priority issue cutting the line though. After my vacation I'm currently finalizing the highly-available code.dlang.org migration. Next will be migrating ci.dlang.io to Buildkite, then beginning the research for use-after-free/alias tracking. --- Would be great if someone with actual interest in this would take care of it completely. Win binary builds to sign .exe and .dll: https://github.com/dlang/installer/blob/master/create_dmd_release/create_dmd_release.d#L267-L268 Win installer build: https://github.com/dlang/installer/blob/e780ad79a1b2721f3c1a3c841bd46a4bd39b37dc/create_dmd_release/build_all.d#L313-L322 Setup script for Win box in case we need to install tools: https://gist.github.com/MartinNowak/8270666 --- <<<
Re: C's Biggest Mistake on Hacker News
On Tuesday, 24 July 2018 at 13:52:20 UTC, Ecstatic Coder wrote: On Tuesday, 24 July 2018 at 12:13:27 UTC, Atila Neves wrote: Same in D, it's just that nobody's bothered writing a string class/struct. Atila Indeed... Better late than never: https://forum.dlang.org/post/fsjspoewhdooowjot...@forum.dlang.org
Re: C's Biggest Mistake on Hacker News
On Wednesday, 25 July 2018 at 17:23:40 UTC, Ecstatic Coder wrote: On Wednesday, 25 July 2018 at 16:39:51 UTC, bpr wrote: On Tuesday, 24 July 2018 at 17:24:41 UTC, Seb wrote: On Tuesday, 24 July 2018 at 17:14:53 UTC, Chris M. wrote: On Tuesday, 24 July 2018 at 16:15:52 UTC, bpr wrote: On Tuesday, 24 July 2018 at 14:07:43 UTC, Ecstatic Coder wrote: [...] No. For many C++ users, tracing GC is absolutely not an option. And, if it were, D's GC is not a shining example of a good GC. It's not even precise, and I would bet that it never will be. If I'm able to tolerate a GC, there are languages with much better GCs than the D one, like Go and Java. [...] There was a precise GC in the works at one point, no clue what happened to it. The newest PR is: https://github.com/dlang/druntime/pull/1977 Though there's already a bit of precise scanning on Windows, e.g. https://github.com/dlang/druntime/pull/1798 and IIRC Visual D uses a precise GC too. Well, this is a big problem with D IMO. There are a lot of unfinished, half baked features which linger in development for years. How long for precise GC now, over 5 years? I don't think D was really designed to be friendly to GC, and it just isn't realistic to expect that there will *ever* be a production quality precise GC for all of D. Maybe giving up on some things and finishing/fixing others would be a better strategy? I think so, which is why I think DasBetterC is the most appealing thing I've seen in D lately. +1 But don't be too optimistic about BetterC... Honestly, considering D's leadership current priorities, I don't see how it could become soon a true C++ or Go competitor, even with the half-baked BetterC initiative... For instance, I've suggested they consider using reference counting as an alternative default memory management scheme, and add it to the lists of scolarship and crowdsourced project, and of course they have added all the other suggestion, but not this one. What a surprise ;) The scholarship list is an idea list that is community-maintained. Let me quote Mike: "Thanks to everyone for the project ideas, but I put the list on the Wiki for a reason. I'm always pressed for time, so if you have an idea for a project suggestion, it would help me tremendously if you can just summarize it on the Wiki rather than here." The crowdsourced project was an experiment and the most popular item of the state of D survey that had someone who could be contacted and was more than willing to work for a scholarship salary, was picked. As Mike has already announced in the blog, it wasn't known before that essentially only one goal could be selected. In the future, it will be possible to select the project(s) you are most interested in when donating. Despite this is probably one of the most used allocation management scheme in typical C++ development, as this drastically reduces the risks of memory leaks and dangling pointers... Agreed, but it's easily implemented in a library like RefCounted (automem has good implementation too: https://github.com/atilaneves/automem). For example, std.stdio.File is reference-counted ;-) core.rc will come, but at the moment only Martin is planning to work on it and he's busy with a lot of other things (e.g. the release process, maintaining the project tester, migrating code.dlang.org to a highly-available cluster, fixing DMD regressions, ...) It's the same story as always, just from complaining, things won't get magically better... (though it would be great if the world worked that way because then maybe my relationships would be more successful :O)
Re: Will the PhotoObject DIP depercated the old Object class?
On Tuesday, 24 July 2018 at 20:25:33 UTC, 12345swordy wrote: I am asking this, because if true then the DIP that I am currently working on has been render obsolete as I have taken the old Object class into account when writing this. -Alexander It's called ProtoObject and "deprecated". And no, while many of us want this, it would lead to too much breakage and there is no easy transition path.
Re: C's Biggest Mistake on Hacker News
On Tuesday, 24 July 2018 at 17:14:53 UTC, Chris M. wrote: On Tuesday, 24 July 2018 at 16:15:52 UTC, bpr wrote: On Tuesday, 24 July 2018 at 14:07:43 UTC, Ecstatic Coder wrote: [...] No. For many C++ users, tracing GC is absolutely not an option. And, if it were, D's GC is not a shining example of a good GC. It's not even precise, and I would bet that it never will be. If I'm able to tolerate a GC, there are languages with much better GCs than the D one, like Go and Java. [...] There was a precise GC in the works at one point, no clue what happened to it. The newest PR is: https://github.com/dlang/druntime/pull/1977 Though there's already a bit of precise scanning on Windows, e.g. https://github.com/dlang/druntime/pull/1798 and IIRC Visual D uses a precise GC too.
Struct Initialization syntax
tl;dr: the currently proposed syntax options are:
---
struct S
{
int a = 2, b = 4, c = 6;
}
void foo()
{
bar(S({c: 10})); // Option 1
bar(S(c: 10)); // Option 2
bar(S{c: 10}); // Option 3
}
---
So the struct-initialization DIP has been stalled for too long
and I think it's time we finally get this story done.
I personally prefer option 2, but this might be in conflict to
named arguments which we hopefully see in the near future too.
Hence, I'm leaning forward to proposing Option 1 as the
recommended Option for the DIP (that's also what the PoC DMD PR
implements). What's your take on this?
DIP: https://github.com/dlang/DIPs/pull/71
Rendered view:
https://github.com/wilzbach/DIPs/blob/struct-initialization/DIPs/DIP1xxx-sw.md
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
This is the feedback thread for the first round of Community
Review for DIP 1016, "ref T accepts r-values":
https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md
All review-related feedback on and discussion of the DIP should
occur in this thread. The review period will end at 11:59 PM ET
on August 3, or when I make a post declaring it complete.
At the end of Round 1, if further review is deemed necessary,
the DIP will be scheduled for another round. Otherwise, it will
be queued for the Final Review and Formal Assessment by the
language maintainers.
Please familiarize yourself with the documentation for the
Community Review before participating.
https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review
Thanks in advance to all who participate.
I like this too. Solid work!
One minor point: the DIP could mentioned structs with disabled
postblits (it currently only tangentially touches it by stating
that no copy operation should happen).
It would be great to make sure that this will work:
---
struct A
{
int i;
@disable this(this);
}
void fun(ref A x);
void test()
{
fun(A(42));
}
---
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Friday, 20 July 2018 at 10:43:54 UTC, Dgame wrote:
On Friday, 20 July 2018 at 10:31:48 UTC, Seb wrote:
On Friday, 20 July 2018 at 10:08:03 UTC, Dgame wrote:
On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson
wrote:
On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
appending something (like .byRef or byRef!long, the latter
making an implicit type conversion)
That can't work: either it returns an expired stack
temporary (*very* bad), or allocates with no way to
deallocate (bad).
What about something like this?
import std.stdio;
ref T byRef(T)(T value) {
static T _val = void;
_val = value;
return _val;
}
void foo(ref int a) {
writeln("A = ", a);
}
void main() {
foo(42.byRef);
foo(23.byRef);
}
That can't work, consider e.g.:
foo(10.byRef, 20.byRef); // calls foo with (20, 20)
https://run.dlang.io/is/lazeu2
True.. But this could work (but is way more uglier):
https://run.dlang.io/is/rKs2yQ
Putting the missing syntax sugar aside and performance overhead
due to unneeded copies, this won't work either.
Consider for example that A could be a non-copyable type:
---
struct A {
int i;
@disable this(this);
}
---
With this DIP it should be possible to do `foo(A(1))` because
only a reference is passed around.
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Friday, 20 July 2018 at 10:08:03 UTC, Dgame wrote:
On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson wrote:
On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
appending something (like .byRef or byRef!long, the latter
making an implicit type conversion)
That can't work: either it returns an expired stack temporary
(*very* bad), or allocates with no way to deallocate (bad).
What about something like this?
import std.stdio;
ref T byRef(T)(T value) {
static T _val = void;
_val = value;
return _val;
}
void foo(ref int a) {
writeln("A = ", a);
}
void main() {
foo(42.byRef);
foo(23.byRef);
}
That can't work, consider e.g.:
foo(10.byRef, 20.byRef); // calls foo with (20, 20)
https://run.dlang.io/is/lazeu2
Re: DMD, Vibe.d, and Dub
On Wednesday, 18 July 2018 at 15:21:29 UTC, Russel Winder wrote: On Wed, 2018-07-18 at 14:20 +, Seb via Digitalmars-d wrote: On Wednesday, 18 July 2018 at 12:56:05 UTC, Russel Winder wrote: > [...] You have openssl 1.1 installed, but vibe.d tries to link with openssl 1.0 by default. See https://github.com/vibe-d/vibe.d#switching-between-openssl-versions tl;dr: use dub --override-config vibe-d:tls/openssl-1.1 I went for the: dependency "vibe-d:tls" version="*" subConfiguration "vibe-d:tls" "openssl-1.1" in the dub.sdl file. I now have a build. I believe 1.1 should be the default if available, falling back to 1.0, 0.9,… Of course, but it's not that easy, because dub doesn't support such a detection. However, we can hack it: https://github.com/vibe-d/vibe.d/pull/2190
dlang.slack.com
tl;dr: send me a short ping (https://github.com/wilzbach) if you would like to join I know that there are many out there who don't like Slack (especially after they killed the IRC gateway), but a lot of the internal discussions still happens on Slack, so I just thought I mention it here on the NG for those who have never heard about it and still would like to join.
Re: DMD, Vibe.d, and Dub
On Wednesday, 18 July 2018 at 12:56:05 UTC, Russel Winder wrote: [...] You have openssl 1.1 installed, but vibe.d tries to link with openssl 1.0 by default. See https://github.com/vibe-d/vibe.d#switching-between-openssl-versions tl;dr: use dub --override-config vibe-d:tls/openssl-1.1
Re: std.experimental.collections.rcstring and its integration in Phobos
On Tuesday, 17 July 2018 at 18:09:13 UTC, Jonathan M Davis wrote:
On Tuesday, July 17, 2018 17:28:19 Seb via Digitalmars-d wrote:
On Tuesday, 17 July 2018 at 16:58:37 UTC, Jonathan M Davis
wrote:
> [...]
Well, there are few cases where the range type doesn't matter
and one can simply compare bytes, e.g.
equal (e.g. "ä" == "ä" <=> [195, 164] == [195, 164])
commonPrefix
find
...
That effectively means treating rcstring as a range of char by
default rather than not treating it as a range by default. And
if we then do that only with functions that overload on
rcstring rather than making rcstring actually a range of char,
then why aren't we just treating it as a range of char in
general?
IMHO, the fact that so many alogorithms currently special-case
on arrays of characters is one reason that auto-decoding has
been a disaster, and adding a bunch of overloads for rcstring
is just compounding the problem. Algorithms should properly
support arbitrary ranges of characters, and then rcstring can
be passed to them by calling one of the functions on it to get
a range of code units, code points, or graphemes to get an
actual range - either that, or rcstring should default to being
a range of char. going halfway and making it work with some
functions via overloads really doesn't make sense.
Well, the problem of it being a range of char is that this might
lead to very confusing behavior, e.g.
"ä".rcstring.split.join("|") == �|�
So we probably shouldn't go this route either.
The idea of adding overloads was to introduce a bit of
user-convenience, s.t. they don't have to say
readText("foo".rcstring.by!char)
all the time.
You can still normalize with auto-decoding (the code units -
and thus code points - are in a specific order even when
encoded, and that order can be normalized), and really, anyone
who wants fully correct string comparisons needs to be
normalizing their strings. With that in mind, rcstring probably
should support normalization of its internal representation.
It currently doesn't support this out of the box, but it's a very
valid point and I added it to the list.
Re: std.experimental.collections.rcstring and its integration in Phobos
On Wednesday, 18 July 2018 at 03:40:08 UTC, Jon Degenhardt wrote:
On Tuesday, 17 July 2018 at 15:21:30 UTC, Seb wrote:
So we managed to revive the rcstring project and it's already
a PR for Phobos:
https://github.com/dlang/phobos/pull/6631 (still WIP though)
The current approach in short:
- uses the new @nogc, @safe and nothrow Array from the
collections library (check Eduardo's DConf18 talk)
- uses reference counting
- _no_ range by default (it needs an explicit
`.by!{d,w,}char`) (as in no auto-decoding by default)
[snip]
What do you think about this approach? Do you have a better
idea?
I don't know the goals/role rcstring is expected to play,
especially wrt existing string/character facilities. Perhaps
you could describe more?
Sorry for the brevity yesterday.
One of long-term pain point of D is that usage of string can't be
@nogc.
rcstring is intended to be a drop-in @nogc replacement for
everywhere where string is currently used (that's the idea, at
least).
Strings are central to many applications, so I'm wondering
about things like whether rcstring is intended as a replacement
for string that would be used by most new programs,
Yes, that's the long-term goal. An opt-in @nogc string class.
There's no plan to do sth. disruptive like replacing the `alias
string = immutable(char)[];` declaration in druntime. However, we
might move rcstring to druntime at some point, s.t. e.g.
Exceptions or asserts can use @nogc strings.
and whether applications would use arrays and ranges of char
together with rcstring, or rcstring would be used for
everything.
That point is still open for discussion, but at the moment
rcstring isn't a range and the user has to declare what kind of
range he/she wants with e.g. `.by!char`
However, one current idea is that for some use cases (e.g.
comparison) it might not matter and an application could add
overloads for rcstrings.
The current idea is to do the same this for Phobos - though I
have to say that I'm not really looking forward to adding 200
overloads to Phobos :/
Perhaps its too early for these questions, and the current goal
is simpler. For example, adding a meaningful collection class
that is @nogc, @safe and ref-counted that be used as a proving
ground for the newer memory management facilities being
developed.
That's the long-term goal of the collections project.
However, with rcstring being the first big use case for it, the
idea was to push rcstring forward and by that discover all
remaining issues with the Array class.
Also the interface of rcstring is rather contained (and doesn't
expose the underlying storage to the user), which allows us to
iterate over/improve upon the Array design.
Such simpler goals would be quite reasonable. What's got me
wondering about the larger questions are the comments about
ranges and autodecoding. If rcstring is intended as a vehicle
for general @nogc handling of character data and/or for
reducing the impact of autodecoding, then it makes sense to
consider from those perspectives.
Hehe, it's intended to solve both problems (auto-decoding by
default and @nogc) at the same time.
However, it looks like to me like there isn't a good solution to
the auto-decoding problem that is convenient to use for the user
and doesn't sacrifice on performance.
Re: std.experimental.collections.rcstring and its integration in Phobos
On Tuesday, 17 July 2018 at 18:43:47 UTC, jmh530 wrote: On Tuesday, 17 July 2018 at 15:21:30 UTC, Seb wrote: So we managed to revive the rcstring project and it's already a PR for Phobos: [snip] I'm glad this is getting worked on. It feels like something that D has been working towards for a while. Unfortunately, I haven't (yet) watched the collections video at Dconf and don't see a presentation on the website. Because of that, I don't really understand some of the design decisions. For instance, I also don't really understand how RCIAllocator is different from the old IAllocator (the documentation could use some work, IMO). It looks like RCIAllocator is part of what drives the reference counting semantics, Well AFAICT the idea is that with RCIAllocator (or its convenience function allocatorObject) is that you can convert any allocator to a reference-counted one, e.g. RCIAllocator a = allocatorObject(Mallocator.instance); but it also looks like Array has some support for reference counting, like addRef, that invoke RCIAllocator somehow. But Array also has some support for gc_allocator as the default, so my cursory examination suggests that Array is not really intended to be an RCArray... Yes, Array is a reference-counted Array, but it also has a reference-counted allocator. So at that point I started wondering why not just have String as an alias of Array, akin to how D does it for dynamic arrays to strings currently. If there is stuff in rcstring now that isn't in Array, then that could be included in Array as a compile-time specialization for the relevant types (at the cost of bloating Array). And then leave it up to the user how to allocate. There's lots of stuff in rcstring related to better interoperability with existing strings. e.g. you just want `"foo".rcstring == "foo"` to work. I think part of the above design decision connects in with why rcstring stores the data as ubytes, even for wchar and dchar. Recent comments suggest that it is related to auto-decoding. Yes rcstring doesn't do any auto-decoding and hence stores its data as an ubyte array. My sense is that an rcstring that does not have auto-decoding, even if it requires more work to get working with phobos is a better solution over the long-run. What do you mean by this?
Re: DMD, Vibe.d, and Dub
On Wednesday, 18 July 2018 at 11:35:05 UTC, Russel Winder wrote: On Tue, 2018-07-17 at 21:46 +, Radu via Digitalmars-d wrote: On Tuesday, 17 July 2018 at 18:55:07 UTC, Russel Winder wrote: > [...] Missing openssl libs? Try installing openssl-dev package. The Debian Sid openssl package is definitely installed. There doesn't seem to be a separate openssl-dev package. It's called libssl-dev
Re: std.experimental.collections.rcstring and its integration in Phobos
On Tuesday, 17 July 2018 at 17:41:05 UTC, Jacob Carlborg wrote:
On 2018-07-17 17:21, Seb wrote:
- _no_ range by default (it needs an explicit
`.by!{d,w,}char`) (as in no auto-decoding by default)
What do you think about this approach? Do you have a better
idea?
I vote for .by!char to be the default.
The problem here is this would also lead to very confusing
behavior for newcomers, e.g.
```
"ä".split.join("|") == �|�
```
Re: std.experimental.collections.rcstring and its integration in Phobos
On Tuesday, 17 July 2018 at 16:58:37 UTC, Jonathan M Davis wrote: On Tuesday, July 17, 2018 15:21:30 Seb via Digitalmars-d wrote: [...] If it's not a range by default, why would you expect _anything_ which operates on ranges to work with rcstring directly? IMHO, if it's not a range, then range-based functions shouldn't work with it, and I don't see how they even _can_ work with it unless you assume code units, or code points, or graphemes as the default. If it's designed to not be a range, then it should be up to the programmer to call the appropriate function on it to get the appropriate range type for a particular use case, in which case, you really shouldn't need to add much of any overloads for it. - Jonathan M Davis Well, there are few cases where the range type doesn't matter and one can simply compare bytes, e.g. equal (e.g. "ä" == "ä" <=> [195, 164] == [195, 164]) commonPrefix find ... Of course this assumes that there's no normalization necessary, but the current auto-decoding assumes this too.
std.experimental.collections.rcstring and its integration in Phobos
So we managed to revive the rcstring project and it's already a
PR for Phobos:
https://github.com/dlang/phobos/pull/6631 (still WIP though)
The current approach in short:
- uses the new @nogc, @safe and nothrow Array from the
collections library (check Eduardo's DConf18 talk)
- uses reference counting
- _no_ range by default (it needs an explicit `.by!{d,w,}char`)
(as in no auto-decoding by default)
Still to be done:
- integration in Phobos (the current idea is to generate
additional overloads for rcstring)
- performance
- use of static immutable rcstring in fully @nogc
- extensive testing
Especially the "seamless" integration in Phobos will be
challenging.
I made a rough listing of all symbols that one would expect to be
usable with an rcstring type
(https://gist.github.com/wilzbach/d74712269f889827cff6b2c7a08d07f8). It's more than 200.
As rcstring isn't a range by default, but one excepts
`"foo".rcstring.equal("foo")` to work, overloads for all these
symbols would need to be added.
What do you think about this approach? Do you have a better idea?
Re: Weird bugs in DMD 2.81.0
On Saturday, 14 July 2018 at 01:27:03 UTC, solidstate1991 wrote: On Saturday, 14 July 2018 at 00:58:08 UTC, solidstate1991 wrote: I found a temporary workaround. Basically I just save the content of the AA, then reapply it after the application's constructor finished, before that it always generated an exception when I tried to check its content e.g. via printing it to the screen. The program still crashes when I close it, and it seems like it's something GC related, which will be extremely hard to reproduce. I'm going to make a commit soon to Github (maybe even an alpha release), so people can check it out for themselves. The AA issue still happens when I disable the GC. What happens if I accidentally write into the memory space of an AA? Might be a pointer-overflow related issue I messed up, which will be a hell of a ride to find. Any chance you can make a minimal, reproducible example of this? Would be great because then it can be put on bugzilla and other people can have a look at it too.
Re: REPL semantics
On Friday, 13 July 2018 at 16:20:03 UTC, Luís Marques wrote: On Friday, 13 July 2018 at 06:22:41 UTC, Jacob Carlborg wrote: On Friday, 13 July 2018 at 02:26:28 UTC, jmh530 wrote: No Windows support. For drepl: "Works on any OS with full shared library support by DMD (currently linux, OSX, and FreeBSD)." For macOS that means using LDC. It doesn't seem to work with LDC on macOS either: $ dub --compiler=ldc2 (...) Undefined symbols for architecture x86_64: "_rt_loadLibrary", referenced from: __D4core7runtime7Runtime__T11loadLibraryZQoFxAaZPv in drepl.o ld: symbol(s) not found for architecture x86_64 Did you try the Docker image?
Re: donations
On Wednesday, 11 July 2018 at 22:46:02 UTC, Ali wrote: there is not two options to donate online 1. Donate through OpenCollective 2. Donate through PayPal are they the same thing, does the money, end up going to the same group, same activities or are they different See also: https://dlang.org/foundation/sponsors.html PayPal has lower fees, but OpenCollective is more transparent (it lists _all_ transactions publicly).
Re: Multiple functions, same signature
On Wednesday, 11 July 2018 at 15:58:05 UTC, Luís Marques wrote:
I was surprised to find out today that this compiles:
void foo() {}
void foo() {}
void main() {}
Is it a bug, or just a weird design decision? "alphaglosined"
on IRC seemed to think it was a regression. Please confirm, so
that I can file a bug, or understand the design decision
rationale.
This will be deprecated soon:
https://github.com/dlang/dmd/pull/8429
Re: Should I write a DIP for Null functions?
On Wednesday, 11 July 2018 at 02:20:01 UTC, 12345swordy wrote: I was think about about writing one about this as this is an "obvious" small easy feature to introduce as it practically a function that does nothing when called and that itself is quite useful. Any objections to this? Alexander I think you will only find objections once you dive into the topic and actually write the DIP. I don't think anyone will object to you experimenting with this. Go for it! That being said, it certainly won't hurt to post a draft version of your DIP here, s.t. people have a better understanding to what they will object/agree to. Also I would recommend to highlight in your DIP use cases and why a library solution based on mixin is inferior.
Re: Struct destructors not available in -betterC?
On Tuesday, 10 July 2018 at 19:28:34 UTC, SrMordred wrote: On Tuesday, 10 July 2018 at 19:14:26 UTC, Gary Willoughby wrote: Looking at the page on -betterC it says that struct destructors are not available. See point 11: https://dlang.org/spec/betterc.html#consequences This doesn't seem to be true as I'm using them with no problem. Yep, the docs are not up to the last dmd updates. But they easily can be: https://github.com/dlang/dlang.org/pull/2415
Re: DIP 1013--The Deprecation Process--Final Review
On Friday, 22 June 2018 at 07:38:04 UTC, Mike Parker wrote: On Thursday, 7 June 2018 at 06:22:04 UTC, Mike Parker wrote: DIP 1013, "The Deprecation Process", is now ready for final review. This is a last chance for community feedback before the DIP is handed off to Walter and Andrei for the Formal Assessment. Please read the procedures document for details on what is expected in this review stage: https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review The current revision of the DIP for this review is located here: https://github.com/dlang/DIPs/blob/1de69e85527aa0e5efea0533c03e8cc732105d02/DIPs/DIP1013.md In it you'll find a link to and summary of the previous review round. This round of review will continue until 11:59 pm ET on June 21st unless I call it off before then. This review round is now complete. Thanks to all who participated! I know that I'm super late with this small addition, but as the DIP still hasn't reached its final stage there might be time to incorporate the following nit: The DIP should clarify at which point the language specification CAN and SHOULD be updated.
Re: Adding more projects to the Project Tester
On Monday, 9 July 2018 at 05:58:17 UTC, Jonathan M Davis wrote: On Thursday, 5 July 2018 21:19:44 MDT Seb via Digitalmars-d wrote: [...] dxml should probably be on the list. Yes! https://github.com/dlang/ci/pull/230 Assuming that this is only on *nix and not Windows Yes. (I have yet to write a test script for Windows) This might help: https://github.com/Abscissa/AppVeyor-D then ./test.sh will run the tests without -release, and ./testRelease.sh will run the tests with -release (simply running dub test won't do anything useful, because all of the unittest blocks are versioned to avoid problems when projects depending on dxml compile their tests). The Project Tester will by default look at (if existent) the .travis.yml and run the same 'script' commands, so it should do the right thing, but I will keep this in mind. Thanks for the explanation!
Re: Adding more projects to the Project Tester
On Friday, 6 July 2018 at 05:02:56 UTC, Joakim wrote: The LDC compiler? kinke recently had an issue because of all the C++ integration changes upstream: https://github.com/ldc-developers/ldc/pull/2752#issuecomment-398897813 As perhaps the largest consumer of extern(C++), it may make sense to add it for all the C++ work being done. It would require the llvm package be pre-installed in the test environ. List of current projects looks great, was tough to think of anything to add. Good idea. Not sure how easy/hard it is, but let's give it a try: https://github.com/dlang/ci/pull/228
Re: local enum
On Sunday, 8 July 2018 at 18:45:48 UTC, Mr.Bingo wrote: On Sunday, 8 July 2018 at 11:29:23 UTC, Seb wrote: On Saturday, 7 July 2018 at 18:48:35 UTC, Mr.Bingo wrote: static foreach and enum do not play nice together! import std.meta, std.stdio; import std.string : leftJustify, center, rightJustify; alias functions = staticMap!(ApplyRight!(Instantiate, string), leftJustify, center, rightJustify); [...] __local has actually been suggested and implemented as part of DIP 1010. IIRC it was removed because A&W wanted to see how static foreach plays out. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1010.md Interesting. A lot of goodies in that Dip! I guess we won't get any crackers though? As mentioned Timon already has an implementation for the goodies. At the review of the DIP, it was agreed to only merge the basic set of the DIP to gain more experience with it before adding more complexity. However, imho it became clear that static break and __local would be very useful. While there are hacks around it (you already mentioned the mixin trick and there's a similar one for static break: define a dummy symbol when you want to break out and check for its existence with typeof in an overall static if, the proposed syntax would be much more concise and readable. It just requires someone to step up and submit a follow-up DIP.
Re: Adding more projects to the Project Tester
On Friday, 6 July 2018 at 21:25:28 UTC, tide wrote: On Friday, 6 July 2018 at 03:19:44 UTC, Seb wrote: So learning from the recent Vibe.d regression fiasco (we temporarily disabled a subconfiguration in Vibe.d and promptly got a regression in 2.081), I think we should try to add more projects to the Project Tester. The current list is here: https://github.com/dlang/ci/blob/master/vars/runPipeline.groovy#L443 Any suggestions? Why should I add my project to the Project Tester? -- Once a project is added to the Project Tester, DMD can't regress on it anymore as for every PR at dmd, druntime, phobos, tools and dub the testsuite of the added projects are run. How does the Project Tester work? - - By default, it will run the same commands as Travis would do. Although, if necessary, custom commands can be used too. - It will checkout the latest, stable git tag Requirements - moderately popular or was prone to regressions in the past - rather easy to build (i.e. you don't need to download and recompile clang) - no flaky testsuite (random errors in the testsuite due to network connectivity shouldn't happen. Though there's `DETERMINISTIC_HINT=1` set, s.t. you could disable such parts of your testsuite) - reachable author or development (if there's ever a case where we need to push changes via a trivial PR to the repo, it shouldn't sit in the queue for weeks) Include Windows as part of the testing done. Just to avoid confusion, testing of DMD/Druntime/Phobos/etc. is done on Windows: https://auto-tester.puremagic.com/platform-history.ghtml?projectid=1&os=Win_32 https://auto-tester.puremagic.com/platform-history.ghtml?projectid=1&os=Win_32_64 https://ci.appveyor.com/project/greenify/dmd ... In my experience are the huge majority of all regressions originating in the D frontend where architecture actually doesn't matter so much. That being said, we are currently investigating to move the Project Tester from Jenkins to Buildkite (https://github.com/dlang/ci/pull/225) and one advantage of this move is that it'll be a lot easier to add new machines to the build cloud (so you could then hook up that Windows machine in your garage with the Project Tester). However, AFAICT many of the dub projects do have dependencies that are harder to install on Windows, so this might not happen in the near future.
Re: Adding more projects to the Project Tester
On Saturday, 7 July 2018 at 08:04:47 UTC, Timoses wrote:
On Friday, 6 July 2018 at 23:56:01 UTC, Basile B. wrote:
On Friday, 6 July 2018 at 21:47:34 UTC, JN wrote:
By the way, is there any policy for outdated dub packages?
You just found an idea for the score algorithm.
Why isn't there something like "compiler compatibility" in a
dub config file? E.g. currently the vibe.d project lists the
compiler versions the code is compatible with [1].
Wouldn't a field in dub like
"compilerCompatibility":
{
"dmd": "2.080.0",
"ldc": "..."
}
be nice? This could also help code.dlang.org to show
compatibility of libraries/packages.
The only pain I guess would be to keep such a list up to date.
[1]: https://github.com/vibe-d/vibe.d#support
I'm not sure it's a good idea to manually hard-code such a list
into the dub.json.
However, for every release or so, the dub registry could crawl
all its packages and run `dub test` on them. Of course, there's
the chance that a build still fails (e.g. due to missing
dependencies) even though it would pass locally, but each package
that passes with the latest registry could receive additional
points.
Re: local enum
On Saturday, 7 July 2018 at 18:48:35 UTC, Mr.Bingo wrote: static foreach and enum do not play nice together! import std.meta, std.stdio; import std.string : leftJustify, center, rightJustify; alias functions = staticMap!(ApplyRight!(Instantiate, string), leftJustify, center, rightJustify); [...] __local has actually been suggested and implemented as part of DIP 1010. IIRC it was removed because A&W wanted to see how static foreach plays out. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1010.md
Re: Weird bugs in DMD 2.81.0
On Saturday, 7 July 2018 at 17:07:42 UTC, solidstate1991 wrote:
On Saturday, 7 July 2018 at 07:31:29 UTC, Seb wrote:
I'm sorry but without code there's not much we can do for you.
However, one thing we can try is to get your project on the
project tester once this regression is fixed.
https://github.com/ZILtoid1991/pixelperfectengine
Just did a commit recently. PixelPerfectEditor runs as it
should (unfinished, but most drawing algorithms work), under
WindowMaker, some stuff just disappear from AA.
Patching "PixelPerfectEngine.concrete.stylesheet"'s
StyleSheet.getColor to the following reveals that some elements
may have disappeared from the AA:
public ushort getColor(string colorName){
return color.get(colorName,0);
}
Also tested with an LDC, which is based on 2.80.1, and the same
anomaly still happens.
Sure, I will make a PR for it later, but we can't do much more
than running `dub test` or whatever testing commands you use for
Travis.
So if this isn't covered by your testsuite, it won't help much
for this specific issue.
Re: Adding more projects to the Project Tester
On Saturday, 7 July 2018 at 16:29:15 UTC, Guillaume Piolat wrote: Please include the intel-intrinsics package, its test expose a regression on 2.081 that I haven't looked after yet. The goal is to provide a _stable and usable_ SIMD interface. https://github.com/dlang/ci/pull/224
Re: Weird bugs in DMD 2.81.0
On Saturday, 7 July 2018 at 02:21:31 UTC, solidstate1991 wrote: I'll upload code tomorrow, but here's the premise: Sometimes elements disappear from associative arrays, causing all sorts of errors down the line, mostly access violations. [...] I'm sorry but without code there's not much we can do for you. However, one thing we can try is to get your project on the project tester once this regression is fixed.
Adding more projects to the Project Tester
So learning from the recent Vibe.d regression fiasco (we temporarily disabled a subconfiguration in Vibe.d and promptly got a regression in 2.081), I think we should try to add more projects to the Project Tester. The current list is here: https://github.com/dlang/ci/blob/master/vars/runPipeline.groovy#L443 Any suggestions? Why should I add my project to the Project Tester? -- Once a project is added to the Project Tester, DMD can't regress on it anymore as for every PR at dmd, druntime, phobos, tools and dub the testsuite of the added projects are run. How does the Project Tester work? - - By default, it will run the same commands as Travis would do. Although, if necessary, custom commands can be used too. - It will checkout the latest, stable git tag Requirements - moderately popular or was prone to regressions in the past - rather easy to build (i.e. you don't need to download and recompile clang) - no flaky testsuite (random errors in the testsuite due to network connectivity shouldn't happen. Though there's `DETERMINISTIC_HINT=1` set, s.t. you could disable such parts of your testsuite) - reachable author or development (if there's ever a case where we need to push changes via a trivial PR to the repo, it shouldn't sit in the queue for weeks)
Re: dmd optimizer now converted to D!
On Thursday, 5 July 2018 at 12:50:18 UTC, Ivan Kazmenko wrote:
With D, I used mixins, and they were cumbersome. Now that we
have static foreach, it's just this:
for (int i = 0; i < 4 * n; i += 4)
static foreach (k; 0..4)
a[i + k] += i + k;
This looks very nice to me, but still not ideal: a
static-foreach argument cannot encapsulate a runtime variable,
so we have to repeat "i + k" twice. This can get cumbersome
for a more complex example. Is there any better way? To
prevent introducing bugs when micro-optimizing, I'd like the
loop body to remain as unchanged as it can be.
Ivan Kazmenko.
FYI: you can introduce scopes with static foreach to declare new
variables:
for (int i = 0; i < 4 * n; i += 4)
{
static foreach (k; 0..4)
{{
auto idx = i + k
a[idx] += idx;
}}
}
However, LDC is pretty good at loop unrolling out of the box:
https://godbolt.org/g/4nSWzQ
(even though gdc is written there, it's "ldc" - known typo:
https://github.com/mattgodbolt/compiler-explorer/pull/988)
Re: Interoperability, code & marketing
On Tuesday, 3 July 2018 at 14:40:52 UTC, Nicholas Wilson wrote: If [1] gets merged we will have a situation where code[2] is required to interoperate with D's slices from C++. I think we should have an official repository where such code and documentation lives (i.e. on the dlang github). This would also be a good place to have links to other interoperability successes in D like pyd, dpp, embedr, luad, autowrap etc. and put the D interoperability story out there, coherently and in one place. Thoughts? In the past A&W became a bit more conservative with creating new repos in the dlang organization and typically only agree to move things there if it "has been proven to be successfully adopted by the community". Though I'm more than happy to create a repo (or move repos) to dlang-community to get the ball rolling.
Re: Parenthesis around if/for/while condition is not necessary
On Sunday, 1 July 2018 at 12:02:03 UTC, Nick Treleaven wrote: On Sunday, 24 June 2018 at 23:40:56 UTC, Timoses wrote: The others may be rewritten to not have a leading "!" as well, e.g. if (!(t1.ty == Tarray && t2.ty == Tarray && needsDirectEq(t1, t2)) if (t1.ty != Tarray || t2.ty != Tarray || ...) Yes, but you might make a mistake, and sometimes it makes more intuitive sense to read it in a non-minimized form. This type of change is also much harder to review. Consider why the change got checked into dmd, without it being minimized at the time or in a later pull. C# supports `if !(`. and it wouldn't be hard for D to support it too: https://github.com/dlang/dmd/pull/8440 It just requires someone to step up and write the DIP.
Re: D and shared librery
On Sunday, 1 July 2018 at 13:53:12 UTC, boolangery wrote: Hi, I didn't find resources on what are actually supported with D and shared library. I didn't find resources on what are actually supported with D and shared library. https://dlang.org/articles/dll-linux.html https://dconf.org/2013/talks/nowak.html The docs: https://dlang.org/phobos/core_runtime.html I read on some forum that shared library is conflicting with garbage collection of the druntime ? I haven't heard about issues with this. Also the garbage collection is enabled lazily since 2.080. Druntime itself can be linked as a shared library too btw. I absolutely need shared library due to space constraints (and multiple binaries ),so I need to know if D should be abandoned. On which OS/architecture do you plan to ship your binaries? D doesn't have full support for creating Windows DLLs, but there's active work on this: https://forum.dlang.org/post/shonvwuauwbhrszys...@forum.dlang.org
Re: D and shared librery
On Sunday, 1 July 2018 at 14:05:30 UTC, rikki cattermole wrote: On 02/07/2018 1:53 AM, boolangery wrote: Hi, I didn't find resources on what are actually supported with D and shared library. I need to reduce binary size, so I would like to ship all dependencies as shared I read on some forum that shared library is conflicting with garbage collection of the druntime ? I absolutely need shared library due to space constraints (and multiple binaries ),so I need to know if D should be abandoned. Thanks You should abandon D if you require (hard no compromise): 1) Shared libraries (D, not e.g. C) Shared libraries are working fine on Linux and OSX. For example, on ArchLinux LDC builds shared libraries by default. Maybe you have recently run into an issue on Windows and are frustrated because of this? AND 2) Languages features like classes (and with it type info) What's wrong about D's classes? 3) Cross platform support (Windows mostly is the problem atm) Some may say, but it works for me! But it doesn't work for most users. It simply hasn't been designed as an experience. I hear a lot of frustration here, but even though one might hit a bump here and there, it doesn't mean that D hasn't been designed to have a nice experience. Did you post your issues to the #dbugfix campaign?
Re: 64bit DMD on Windows
On Friday, 29 June 2018 at 14:39:29 UTC, 9il wrote: Hi, I am migrating a project to Windows. DMD fails with Fatal error: out of memory Splitting the project to dozen subpackages allows to workaround the issue. In other hand, dub test doesn't test subpackages. It would be nice to have 64 bit DMD. Best Regards, Ilya Yaroshenko You can grab one at AppVeyor https://ci.appveyor.com/project/greenify/dmd/build/1.0.4829/artifacts (it gets build with every PR/commit at DMD). I hope we manage to ship it with the official releases soon.
Re: Security point of contact
On Sunday, 10 June 2018 at 00:59:11 UTC, Cym13 wrote: On Sunday, 10 June 2018 at 00:31:55 UTC, Vladimir Panteleev wrote: [...] This is the thing exactly, first of all the idea that the main developer of the part of the project impacted should be the one receiving the report is sound but far from obvious. In many countries there is a (stupid) legal risk associated with vulnerability disclosure, so as a researcher you'd rather be sure that you're talking to the right person. [...] Another step at setting such a security point of contact up: https://github.com/dlang/dlang.org/pull/2398 Input is welcome.
Re: Sign the installers
On Wednesday, 27 June 2018 at 23:54:55 UTC, Manu wrote: Hey people, So I had a few people in the office refuse to install DMD because when they launched the installer, Windows displayed the prompt that it was untrusted (ie, unsigned) and not offer the install button without manual override. True also for VisualD. Can we get a key and start signing the install packages? It would be super-cool to sign the 2.081 release since it's like, imminent ;) - Manu For the record, the releases are already signed: http://downloads.dlang.org/releases/2018/ dmd.2.080.1.windows.zip.sig dmd.2.080.1.windows.zip dmd.2.080.1.windows.7z.sig dmd.2.080.1.windows.7z Though I know that a PGP signature isn't what you are looking for ;-)
Re: `update` and `require` properties for AA
On Wednesday, 27 June 2018 at 13:41:46 UTC, Jacob Carlborg wrote: On 2018-06-27 01:22, Seb wrote: On Tuesday, 26 June 2018 at 17:12:37 UTC, H. S. Teoh wrote: On Tue, Jun 26, 2018 at 12:54:11PM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...] 1. The dlang.org repository is backwards -- master generates the docs for the default dlang.org. I've brought this up before, still don't understand why we don't use stable for the latest dlang.org. Probably because we want to keep phobos-prerelease up-to-date with git master? FWIW the docs in the release archives are built from stable. The reason is that both stable _and_ master are built on dlang.org, so historically no one was interested in doing release management for the docs. The only sane way to do this IMO is to make the dlang.org makefiles generate multiple versions of the docs, thereby acting as the authoritative source for all dlang.org pages. It already takes 20 minutes to do a full build of all dlang.org HTML pages. Doing it for old versions is a REALLY bad idea as you are susceptible to - more random failures (e.g. DUB registry being down) - it will take hours for each build - it won't be possible to do it in a CI for each PR due to the large time required, which means the deployment could be broken without us knowing - resources might be offline or change (e.g. currently it fetches the RSS from the DBlog for the frontpage indexes, this already broke the build a few times) - building all versions will fail due to newer dependencies or OS-level changes (e.g. -fPIC, glibc changes, ...) An alternative would be to specify for each symbol when it was introduced. A simple way would be to just add it to the documentation. Or it could be added as a UDA, this would be more flexible. If the current docs now which version itself is it could add an option to filter out symbols for a given version. Having it as a UDA could also give other future advantages. For example, when building applications on macOS, Apple recommends always using the latest SDK even when deploying to older version of the OS. Symbols are annotated with in which version of the OS they were introduced. Then the compiler will give an error/warning if using a symbol without the proper guards and deploying to an older version of the OS. Not sure if this would be interesting to us but it shows using a UDA could have advantages. If someone wants to build sth like this, this should be easily doable without attributes as we have DMD's json Output for each phobos version: https://github.com/dlang/docarchives.dlang.io/blob/master/archives/v2.080.0/docs-latest.json Ddox uses this file to generate its entire documentation, so just iterating over the json files and checking in which json file a specific symbol stops to appear shouldn't be too hard to automate. The harder bit is to integrate this aggregated information with the actual docs, but in the worst case we can always fallback to a bit of JavaScript (and we have a custom preprocessor for ddoc too). Of course an aggregator could also edit Phobos directly, s.t. all this work doesn't need to be done by hand...
Re: DIP 1013--The Deprecation Process--Final Review
On Friday, 22 June 2018 at 07:38:04 UTC, Mike Parker wrote: On Thursday, 7 June 2018 at 06:22:04 UTC, Mike Parker wrote: DIP 1013, "The Deprecation Process", is now ready for final review. This is a last chance for community feedback before the DIP is handed off to Walter and Andrei for the Formal Assessment. Please read the procedures document for details on what is expected in this review stage: https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review The current revision of the DIP for this review is located here: https://github.com/dlang/DIPs/blob/1de69e85527aa0e5efea0533c03e8cc732105d02/DIPs/DIP1013.md In it you'll find a link to and summary of the previous review round. This round of review will continue until 11:59 pm ET on June 21st unless I call it off before then. This review round is now complete. Thanks to all who participated! I know that this comes a bit too late, but when the final version of the DIP is prepared/approved it might be worthwhile to define whether version should start with "v" or not. I have now seen these three different variants in the wild already: @@@DEPRECATED_v2.085@@@ @@@DEPRECATED_2.085@@@ @@@DEPRECATED_2.085.0@@@
Re: `update` and `require` properties for AA
On Tuesday, 26 June 2018 at 16:17:03 UTC, Timoses wrote: Doesn't it already offer it? Here https://dlang.org/spec/hash-map.html in the very top right corner you can diverge from master. However it seems a bit bugged that when selecting something else than master, it suddenly prints master again, and there is no way to get back to master. Looks a bit broken. Well, it takes you to the exact snapshot of the page of your selected version: https://github.com/dlang/docarchives.dlang.io That's why if you select anything before 2.079 at the spec pages, it won't even show the version chooser as it was introduced a bit before the 2.079 release (the Phobos documentation has had the button for a bit longer). We can probably fix this by injecting a bit of custom JavaScript in the old snapshots that detects the current version and adds a "correct" version chooser button, but it's not on my priority list and no one else has bothered/cared enough about it either.
Re: `update` and `require` properties for AA
On Tuesday, 26 June 2018 at 16:54:11 UTC, Steven Schveighoffer wrote: On 6/26/18 12:48 PM, Steven Schveighoffer wrote: On 6/26/18 11:51 AM, H. S. Teoh wrote: On Tue, Jun 26, 2018 at 07:25:09AM +, Mike Franklin via Digitalmars-d wrote: [...] I think the documentation gets published prematurely. The new methods for the associative arrays should come in the next release, scheduled for July 1st. https://dlang.org/changelog/pending.html#require_update [...] Seriously, we need to start implementing versioned docs on dlang.org. We do. But stable right now is in beta, so the docs are going to reflect what will soon be released. What we probably should do is have a "released" branch for the docs. Or just answer the odd question every once in a while on the forums :) Oh wait, this is the dlang.org repository. Yeah, so in answer to a few questions here: 1. The dlang.org repository is backwards -- master generates the docs for the default dlang.org. I've brought this up before, still don't understand why we don't use stable for the latest dlang.org. It's actually not so difficult to change, you just need to ping Vladimir who is in charge of dlang.org's deployment and then we should set `stable` as default GitHub branch. As mentioned, stable is already used for the released docs in the official archives/installer and Martin already does the entire merging/branching off for dlang.org. Though I'm pretty sure that if we are going to change this, people are going to confused and try to make changes to master and wonder why they don't end up on dlang.org We typically don't have many changes like this one that have to be delayed for one version and in this case in the past we simply tagged the PR as "don't merge before X". Anyway, if we want to go this route, we probably want to have a way to preview the upcoming spec on dlang.org (e.g. spec-prerelease).
Re: `update` and `require` properties for AA
On Tuesday, 26 June 2018 at 17:12:37 UTC, H. S. Teoh wrote:
On Tue, Jun 26, 2018 at 12:54:11PM -0400, Steven Schveighoffer
via Digitalmars-d wrote: [...]
1. The dlang.org repository is backwards -- master generates
the docs for the default dlang.org. I've brought this up
before, still don't understand why we don't use stable for the
latest dlang.org.
Probably because we want to keep phobos-prerelease up-to-date
with git master?
FWIW the docs in the release archives are built from stable.
The reason is that both stable _and_ master are built on
dlang.org, so historically no one was interested in doing release
management for the docs.
The only sane way to do this IMO is to make the dlang.org
makefiles generate multiple versions of the docs, thereby
acting as the authoritative source for all dlang.org pages.
It already takes 20 minutes to do a full build of all dlang.org
HTML pages.
Doing it for old versions is a REALLY bad idea as you are
susceptible to
- more random failures (e.g. DUB registry being down)
- it will take hours for each build
- it won't be possible to do it in a CI for each PR due to the
large time required, which means the deployment could be broken
without us knowing
- resources might be offline or change (e.g. currently it fetches
the RSS from the DBlog for the frontpage indexes, this already
broke the build a few times)
- building all versions will fail due to newer dependencies or
OS-level changes (e.g. -fPIC, glibc changes, ...)
This means released specs need to be archived separately (e.g.,
by copying to spec/${version}/* and linking stuff there).
I just checked the versioned docs with the button on the upper
right of the page... it links to dlang.io, which IMO is a bad
idea, not because of dlang.io itself but because we're
basically relying on an external URL to contain what we assume
it might contain. IMO it's better to keep all versions of the
docs in a single repo (dlang.org) so that things can be
updated/refreshed from a single source, in keeping with SSOT.
Doing it that way then lets us do things like fix typos in
older docs without unnecessary complications.
Ehm the docarchives are simple a snapshot of each version (that's
why the "Improve this page" doesn't work or the "Version" button
says it's stable even though it's 2.076 (or there isn't even a
version button at all).
Anyhow, I'm pretty sure that we don't want to put all the HTML
files into the main dlang.org git repo. It's about 5 GB extracted.
The repo is here and part of the official D GitHub organization
https://github.com/dlang/docarchives.dlang.io
I don't see any problem of hosting it there, after all, the
content never changes.
There hasn't been much interest in it so far, so I doubt that
moving things will make this any better.
Re: D hash table comparison benchmark
On Tuesday, 26 June 2018 at 02:53:22 UTC, Nathan S. wrote: With LDC2 the times for vibe.utils.hashmap and memutils.hashmap are suspiciously low, leading me to suspect that the optimizer might be omitting most of the work. Here are the figures without optimizations enabled. == Speed Ranking using DMD (no optimizations) == 95 msecs built-in AA 168 msecs vibe.utils.hashmap 182 msecs jive.map 224 msecs memutils.hashmap 663 msecs containers.hashmap w/GCAllocator 686 msecs containers.hashmap w/Mallocator == Speed Ranking using LDC2 (no optimizations) == 68 msecs built-in AA 143 msecs vibe.utils.hashmap 155 msecs jive.map 164 msecs memutils.hashmap 515 msecs containers.hashmap w/GCAllocator 537 msecs containers.hashmap w/Mallocator Did you by chance also benchmark it with other languages like C++, Go or Rust? BTW I'm not sure what your plans are, but are you aware of this recent article? https://probablydance.com/2018/05/28/a-new-fast-hash-table-in-response-to-googles-new-fast-hash-table There were also plans to lower the AA implementation entirely into D runtime/user space, s.t. specialization can be done easier, but sadly these plans stagnated so far: https://github.com/dlang/druntime/pull/1282 https://github.com/dlang/druntime/pull/1985
opDispatch and alias this
Apparently three years ago it was we decided to ban alias this and opDispatch in the same class. What are your thoughts on this now? Is anyone depending on using alias this + opDispatch together like e.g. in https://github.com/dlang/phobos/pull/6596?
Re: Phobos' std.conv.to-conversion from enum to string doesn't scale beyond hundreds of enumerators
On Friday, 22 June 2018 at 20:56:58 UTC, Stefan Koch wrote: On Friday, 22 June 2018 at 20:23:51 UTC, Steven Schveighoffer wrote: On 6/22/18 2:15 PM, Steven Schveighoffer wrote: On 6/22/18 1:41 PM, Stefan Koch wrote: (I'd suggest a non-recursive mergesort.) How will that perform in CTFE? I'm concerned about swapping values making it allocate new arrays all over the place. This kind of sounded like a fun experiment, so I tried it: https://run.dlang.io/gist/7c23567e0fa2e3b663d0b0695d3c257e No idea of the performance or capability given hundreds of enum members, but something new to try. -Steve run.dlang.io is down for me. maybe you can provide a gh link? Huh? There was never any downtime. Do you still have troubles? (if so, it would be good to figure out what's happening)
Re: Cannot hash a std.datetime.Date
On Sunday, 17 June 2018 at 18:15:19 UTC, Per Nordlöw wrote:
The following
unittest
{
import std.datetime.date : Date;
Date date;
import core.internal.hash : hashOf;
auto hash = date.hashOf;
}
[...]
Well it definitely used to work before:
https://run.dlang.io/is/ayjpcH
I opened an issue for you:
https://issues.dlang.org/show_bug.cgi?id=19005
The PR that introduced this regression was
https://github.com/dlang/druntime/pull/2200
Re: An (old/new?) pattern to utilize phobos better with @nogc
On Monday, 18 June 2018 at 06:54:46 UTC, Dukc wrote: On Sunday, 17 June 2018 at 20:17:36 UTC, Dukc wrote: Yes, I agree. And each too, of course. Thought again and not so sure anymore: I just realized that if we are to do that, it should apply the same changes to tee, find, filter etc. Probably too complicated to be worth it. Yep, I'm aware of this and that's the argument why it has previously been rejected.
Re: D community's view on syntactic sugar
On Monday, 18 June 2018 at 01:06:48 UTC, evilrat wrote:
On Sunday, 17 June 2018 at 17:48:21 UTC, FromAnotherPlanet
wrote:
On Sunday, 17 June 2018 at 16:52:59 UTC, Neia Neutuladh wrote:
The only case where D loses out is compared to { get; private
set; }.
That's a pretty big thing to give up. That allows for pretty
valuable control over visibility of encapsulated properties.
He means that in D this is split like that, which isn't as
clean as C# does
class MyClass
{
private int _myProp; // backing field
private @property void myProp(int a) { _myProp = a; } //
private setter
public @property int myProp() { return _myProp; } // getter
}
Well the cool part about D is that we can generate such sugar
without necessarily needing to have it in the language (though a
better property syntax would be great).
Anyhow here's an example from the accessors package
(https://github.com/funkwerk/accessors):
import accessors;
class WithAccessors
{
@Read @Write
private int num_;
// list all your fields here
mixin(GenerateFieldAccessors);
}
Re: An (old/new?) pattern to utilize phobos better with @nogc
On Saturday, 16 June 2018 at 11:58:47 UTC, Dukc wrote: What are your thoughts? Do you agree with this coding pattern? It would even be better if map can recognize tuples and thus allows to simply use a lambda functions with two parameters, but in the past with a few exceptions there hasn't been much support/consensus on specializing Phobos functions for tuples.
Re: D community's view on syntactic sugar
On Saturday, 16 June 2018 at 00:32:24 UTC, H. S. Teoh wrote: On Sat, Jun 16, 2018 at 12:20:35AM +, Seb via Digitalmars-d wrote: On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote: > For someone coming from a C# background there is some > seemingly simple syntactic sugar missing from D. > > * The null conditional operator `?.` e.g. SafeAccess https://github.com/BBasile/iz/blob/7336525992cb178ead83a7893a5a54597d840441/import/iz/sugar.d#L1551 Didn't Andrei propose an Elvis operator some time ago? Whatever became of that DIP? T https://forum.dlang.org/post/ot1q8b$23pt$1...@digitalmars.com https://github.com/dlang/dmd/pull/7242 I think Razvan focused on other projects no one else bothered enough to write a DIP about this.
Re: D community's view on syntactic sugar
On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote: For someone coming from a C# background there is some seemingly simple syntactic sugar missing from D. * The null conditional operator `?.` e.g. SafeAccess https://github.com/BBasile/iz/blob/7336525992cb178ead83a7893a5a54597d840441/import/iz/sugar.d#L1551 * Something like a `yield return` statement for coroutines. The library solution only has the downside of requiring parenthesis: https://dlang.org/phobos/std_concurrency.html#.yield T* he `async` & `await` keyword from C# make proactor pattern async code extremely easy to reason about. There was some talk about adding async/await to the language once we actually get an eventloop library into Phobos/DRuntime. A very promising approach and project: http://dconf.org/2018/talks/olshansky.html * a good syntax for properties so there's less code bloat. It's typically solved with `mixin`. https://github.com/funkwerk/accessors https://github.com/funkwerk/boilerplate There's also somewhere on this forum a nice mixin that generates default constructors for you if you don't need any specialization. * replacing `Allocator.make()` with `new!Allocator`. After all `new` can be concidered as just a wrapper around the standard GC allocator. Why can't we just have a special template of it? How would you pass a reference to the allocator object around with new!Allocator? I have realized that I have become quite dependant on syntactic sugar to the point that it severely impacts my productivity when I work whitout. And these ones are my biggest obstacles when I try to work with D from a C# experience. I think that C# really nailed down some of these particular examples except the last one of course. And I also think D could do a better job of embracing productivity through supporting syntax of common tasks and borrow from other languages in that regard. But the most important question is how other people feel about that. If people hate syntactic sugar D will never become that gem for me that I would like it to be. But if key people want it, it one day might. Don't get me wrong, I like convenience features too - I was just trying to point that for most of these things a library solution is just one keystroke more effort and allows more rapid iteration on the design. So of course, people obviously like syntactic sugar, but the problem is that nowadays one needs a strong argument when trying to convince W&A for introducing yet another language feature as it bloats the language and makes it harder for newcomers to learn it and read code in it. Also in the past a few language features haven't turned out to be that great, so that's why nowadays there's more caution. However, there's quite an interest and we regularly do get new sugar, e.g. the new contract syntax: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1009.md (will be part of the upcoming 2.081)
Re: install.sh gives Invalid signature error
On Friday, 15 June 2018 at 12:02:57 UTC, Arjan wrote: Trying to execute the install.sh on a centos7.5 system gives an error: Invalid signature http://downloads.dlang.org/releases/2.x/2.080.1/dmd.2.080.1.linux.tar.xz.sig For each version I tried. Whats wrong? Maybe you have an outdated version of the d-keyring.gpg in your ~/dlang directory and never did an update of it? The command is ./install.sh update (or simply remove it).
Re: Security point of contact
On Saturday, 9 June 2018 at 23:19:34 UTC, Cym13 wrote: On Saturday, 9 June 2018 at 21:52:59 UTC, Seb wrote: On Saturday, 9 June 2018 at 19:03:59 UTC, Cym13 wrote: Yop. I need to discuss an issue related to dub. No need to alarm everyone yet, that only concerns 1.3% of dub projects, but still it's something that shouldn't be taken lightly. Who should I contact? Sönke, Martin und myself. https://github.com/s-ludwig (look in the DUB git log for his email address) https://github.com/MartinNowak https://github.com/wilzbach Thank you, the mail should be in your box already. Sorry - I never got a mail :/ Which address did you use? In doubt, this is my official one: https://seb.wilzba.ch/contact/
Re: Replacing C's memcpy with a D implementation
On Sunday, 10 June 2018 at 13:45:54 UTC, Mike Franklin wrote:
On Sunday, 10 June 2018 at 13:16:21 UTC, Adam D. Ruppe wrote:
arr1[] = arr2[]; // the compiler makes this memcpy, the
optimzer can further do its magic
void memcpyD()
{
dst = src.dup;
}
void memcpyD2()
{
dst[] = src[];
}
-
memcpyD: 1 ms, 725 μs, and 1 hnsec
memcpyD2: 587 μs and 5 hnsecs
memcpyASM: 119 μs and 5 hnsecs
Still, the ASM version is much faster.
btw, what's the difference between the two. If you can't tell,
I'm actually not a very good D programmer.
Mike
I would increase the test data size, s.t. you get a least a few
seconds.
Otherwise the benchmarking won't tell you much because it's
subject to too much randomness.
Re: Security point of contact
On Saturday, 9 June 2018 at 19:03:59 UTC, Cym13 wrote: Yop. I need to discuss an issue related to dub. No need to alarm everyone yet, that only concerns 1.3% of dub projects, but still it's something that shouldn't be taken lightly. Who should I contact? Sönke, Martin und myself. https://github.com/s-ludwig (look in the DUB git log for his email address) https://github.com/MartinNowak https://github.com/wilzbach I'd very very much like to have something like a secur...@dlang.org for such things, it's not the first and likely not the last time this need arises, and the lack of a clear procedure doesn't encourage coordinated disclosure. I will try to get this email address setup. At least we already have an official GPG keyring: https://dlang.org/gpg_keys.html
Re: DIP 1013--The Deprecation Process--Final Review
On Thursday, 7 June 2018 at 07:10:37 UTC, Mike Franklin wrote: On Thursday, 7 June 2018 at 06:22:04 UTC, Mike Parker wrote: @@@DEPRECATED_[version]@@@ This is still ambiguous to me. Deprecations are done in stages. For example: Stage 1 (version 2.081) - Compiler emits deprecation warning Stage 2 (version 2.086 = 2.081 + 5) - Compiler emits error Stage 3 (version 2.091 = 2.086 + 5) - Feature is removed. In @@@DEPRECATED_[version]@@@ does "version" mean "2.081" or "2.086". That is, is it the version in which the deprecation happened (2.081), or is it the version for which the code must be changed to an error (2.086). I believe it should be the former, but I have been corrected in the past that it should be the latter. Yep it would be great if the DIP would make this non-ambiguous once and for all. How about using two different tags? @@@DEPRECATED_[version]_DOCUMENTATION@@@ @@@DEPRECATED_[version]_REMOVAL@@@ All required actions will still show up in the grep. BTW it would be great to have a short summary table like the one above in the description of the DIP as a quick reference for future readers of the DIP. On the first release in the deprecation period, the removed symbol(s) SHOULD be removed from any module or package wide list of public functions/booktables/cheatsheets to deemphasize its use. I don't think that's a very good idea because users, in order to transition their code, will need to refer to the existing documentation in order to understand the semantics of their existing code. I recommend, instead, requiring the documentation to be annotated with a deprecation notice, and then removed when the feature itself is removed. The point is to dis-encourage new uses of the deprecated symbol. The symbol will still show up in the symbol search if the users searches for it. Besides since we have the docarchives, we could even remove the documentation fully as the user will still find it on Google, but it was agreed that this "keep the docstring, but don't promote" is a comprise between both world.
Re: Help with semaphoreci issue?
On Wednesday, 6 June 2018 at 06:33:08 UTC, Manu wrote: I have 2 DMD PR's that show this issue with semaphoreci: https://semaphoreci.com/dlang/dmd-2/branches/pull-request-8336/builds/1 I don't understand what's wrong, and whether or not it's my fault... If it's not, I guess someone needs to know about it? Seems to be something related to their recent platform upgrade. Installing libcurl-gnutls:i386 runs into conflicts on their new 14.04 image :/ I will try to have a look into it, but for now downgrading to the older image seems to resolve the problem.
Re: stride in slices
On Sunday, 3 June 2018 at 07:30:56 UTC, Meta wrote: On Saturday, 2 June 2018 at 18:49:51 UTC, DigitalDesigns wrote: Proposal: [a..b;m] m is the stride, if ; is not a good char then |, :, !, or # could be good chars. This is exactly what std.range.stride does. The syntax [a..b;m] directly translates to [a..b].stride(m). We even have slide which is a generalization of stride (striding is sliding with a window size of 1): [a..b].slide(1, m) https://dlang.org/phobos/std_range.html#slide
Re: Installation on Ubuntu 18.04 is broken
On Friday, 1 June 2018 at 16:41:21 UTC, bachmeier wrote: I would file a bug, but I don't have time to dig into this now, and it would just sit there with no response for six months anyway. I cannot find a way to get std.net.curl to work with Ubuntu 18.04. Details can be found here: https://forum.dlang.org/thread/bug-1864...@https.issues.dlang.org%2F but that only lets you install the package without having a broken package management system. It resolves nothing wrt actually being able to use curl, which is part of the standard library, and should be expected to work. I tried using the install script, but that leads to this bug https://issues.dlang.org/show_bug.cgi?id=18808 which was filed more than a month ago and still hasn't received a response. This experiment with having a new release every couple of weeks was fun, but can we please be realistic about our resources, and move to a sensible schedule. D is simply not an option in situations that require reliability. And all the various deprecations and language changes that are inserted in these high-frequency releases (changes of arbitrary size can come with little warning in *any* release) make it that much more difficult. The bug you referenced has long been fixed and is part of 2.080.0 Please do report a bug with instructions on how to reproduce if you are still experiencing problems. How else can we be able to help you? Also this has nothing to do with the release model, but with Ubuntu throwing out new releases that break a ton of things. So on the contrary if we wouldn't have such a frequent release process, the bug wouldn't have been fixed and released.
Re: Ideas for students' summer projects
On Wednesday, 23 May 2018 at 03:56:32 UTC, Mike Franklin wrote: On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! Building and running the DMD test suite on vanilla Windows is a pain. I never succeeded but it appears to require the user to first set up a posix environment and then battle environment configuration, and other vague dependencies such as whether you are building for 32-bit or 64-bit and whether Visual Studio 2017 is installed. I believe most contribute to D with a Linux development machine, but sometimes there are Windows-only issues that need to be solved. For that we need to be able to build and test our changes on Windows without hassle. I'd like to see the requirement for a posix environment lifted by porting all makefiles to D, so the same code (with appropriate `version`ing of course) could be used to compile and build dlang repositories on all platforms without a lot of environment setup and configuration. All that would be required a recent D compiler in one's PATH. See https://github.com/dlang/dmd/pull/8162 for some working moving in that direction. Mike Yep, `test/run.d` is a first step in this direction and apart from the few shell tests, it should allow running the DMD testsuite without the prior hassles. Though for the shell tests, just using the shell shipped with the Windows version of Git is enough. I just gave converting the DMD Make build script to D a quick shot and it doesn't look too complicated: https://github.com/dlang/dmd/pull/8293
Re: CI buildbots
On Monday, 21 May 2018 at 04:46:15 UTC, Manu wrote: This CI situation with the DMD/druntime repos is not okay. It takes ages... **hours** sometimes, for CI to complete. It's all this 'auto-tester' one, which seems to lock up on the last few tests. This makes DMD is a rather unenjoyable project to contribute to. I had a sudden burst of inspiration, but it's very rapidly wearing off. As mentioned on GitHub, running the compile+fail testsuite locally takes 10 seconds. Typically a PR doesn't touch much cross-platform stuff and if it does, you should get a negative reply pretty early from any CI. If you use CIs to detect merge conflicts, they will also occur locally. As explained on GitHub auto-tester gives priority to PRs with the auto-merge label and will constantly invalidate old builds whenever something got merged, so it typically never completes for a PR. OTOH if your PR has been approved, it will have priority access and normally it will be merged quite quickly. That being said, if you have ideas on how to improve the ecosystem, please let us/me know (except for adding new machines to the auto-tester - that's something that seems to be out of our reach).
