Re: Sutter's ISO C++ Trip Report - The best compliment is when someone else steals your ideas....
On 7/11/2018 3:24 PM, crimaniak via Digitalmars-d wrote: On Wednesday, 11 July 2018 at 18:27:33 UTC, Brad Roberts wrote: ... application exiting asserts in production. Yes, you kill the app. You exit as fast and often as the errors occur. You know what happens? You find the bugs faster, you fix them even faster, and the result is solid software. You mean that the serious consequences of errors better motivate programmers? Then I have an idea. If you connect the current to the chairs of the developers, and with each failed assert the programmer responsible for this part will receive an electrical discharge, the code will surely become even more reliable. But I want the error found in the production not to lead to a drop in the service, affecting all the users who are currently on the site, and this is a slightly different aspect. Motivation is a part of it, to be sure, but only a tiny part. Asserts and the heavy use of them changes how you think about system state validation. Yes, you can do that without asserts but I've found that when you tend towards system recovery and error mitigation style thinking you tend to be thinking about getting out of that state, not never getting into it. As to applying punishments for errors, that tends to be a bad motivator too. It encourages hiding problems rather than preventing them. All in all, I'm mostly presenting anecdotal that embracing the style of programming you're arguing against has produced very good results, repeatably, in my work experience. There's a big topic / discussion area in here about fault isolation. If you really want things to be able to fail independently, then they need to be separate enough that faults in one cannot affect the other. Most languages today don't provide the barriers within a process to have multiple fault domains. None in the c family of languages does. Erlang is a good example of one that does. Given the industry and userbase that uses the language, it's not at all shocking that it too embraces the concept of fail fast, don't try to recover. Anyway, this is one of the areas where people clearly have different philosophies and changing minds is unlikely to happen.
Re: Sutter's ISO C++ Trip Report - The best compliment is when someone else steals your ideas....
On 7/11/2018 5:45 AM, crimaniak via Digitalmars-d wrote: On Tuesday, 10 July 2018 at 22:59:08 UTC, Jonathan M Davis wrote: Or aside from that strawman that RangeError shouldn't be an Error even... I suspect that we're going to have to agree to disagree on that one. ... ... continuing to execute the program is risky by definition. ... This error handling policy makes D not applicable for creating WEB applications and generally long-running services. I think anyone who has worked in the enterprise sector will confirm that any complex WEB service contains some number of errors that were not detected during the tests. These errors are detected randomly during operation. And the greatest probability of their detection - during the peak traffic of the site. Do you kill the whole application even in the case of undisturbed memory, with one suspicion of a logical error? At the peak of attendance? To prevent a potential catastrophe, which could theoretically arise as a result of this error? Congratulations! The catastrophe is already here. And in the case of services, the strategy for responding to errors must be exactly the opposite. The error should be maximally localized, and the programmer should be able to respond to any type of errors. The very nature of the work of WEB applications contributes to this. As a rule, queries are handled by short-lived tasks that work with thread-local memory, and killing only the task that caused the error, with the transfer of the exception to the calling task, would radically improve the situation. And yes, RangeError shouldn't be an Error. From experience, on multiple teams with extremely large fleets of machines running some of the largest websites and services, one of the most powerful tools that helped us go from good up times (2-4 9's) to excellent up times (4-6 9's) was from using application exiting asserts in production. Yes, you kill the app. You exit as fast and often as the errors occur. You know what happens? You find the bugs faster, you fix them even faster, and the result is solid software. One caveat that's affects this is delivered vs managed software. The rules and patterns are drastically different if you're burning software on cd and selling it through stores with no path to make updates, but that's less and less the case every day. When you're afraid of your software and afraid to make changes to it, you make bad choices. Embrace every strategy you can find to help you find problems as quickly as possible.
Re: Sign the installers
On 6/27/2018 5:34 PM, Jonathan M Davis via Digitalmars-d wrote: On Wednesday, June 27, 2018 17:26:36 Manu via Digitalmars-d wrote: I guess people feel nervous about installing allegedly potentially dangerous software on their corporate workstation. Honestly, that's exactly the sort of thing that I always ignore. I'd pay attention if anti-virus software outright said that it found a virus, but "unrecognized software?" That's exactly the sort of thing that's just going to get me pissed off at Microsoft for getting in my way. Though honestly, Microsoft pops up so many useless messages that it becomes easy to miss any that actually matter, because you have to skip through so many of them all the time that you stop paying attention to them. So, I'm definitely surprised to hear about programmers refusing to install something just because Microsoft doesn't recognize it. - Jonathan M Davis It's all about removing resistance and raising the level of professionalism. D isn't a hobby project and shouldn't act like one. This is an obvious barrier that's worth removing. In this day and age of rampant actively dangerous software, it's an obvious improvement to sign it and make the strong claim that this is produced and vended by the d foundation and we vouch for it's contents. We already do for some (all?) of the posix distribution bundles.
Re: SecureD Futures (v2.0)
On 5/29/2018 1:57 AM, Adam Wilson via Digitalmars-d wrote: One of the pillars of SecureD is that ONLY safe, well-known, algorithms are presented. If reasonable we will only present one algorithm for a specific purpose. If there is a good reason to add more than one algorithm, we will. One of the pillars of crypto is that eventually a problem will be found with every algorithm, it's just a matter of time. So, having just one available means that eventually the library will be horribly broken. The corollary here is that having a fallback is pretty essential.
Re: NNTP client configuration
On 2/20/2018 7:43 PM, Jonathan M Davis via Digitalmars-d wrote: On Tuesday, February 20, 2018 19:20:27 Walter Bright via Digitalmars-d wrote: On 2/20/2018 4:26 PM, Manu wrote: I shouldn't have your email address in the reply-to header (as Jonathan has noted multiple times). I do that deliberately as a service to those who wish to contact me privately about something I posted, which happens now and then. I think that it's also pretty common for the e-mail address of posters to end up being visible somewhere for mailing lists - enough so that using an e-mail address that you don't want to be public is risky. Either way, having the poster's e-mail address in the Reply-To header is a problem, because that's going to tell the e-mail client to send a reply there. So, if the poster's e-mail address is going to be somewhere in the headers, it needs to be in a different header (e.g. the From header). Looking back at e-mails from the mailing list from the last few years, it looks like it used to be the case that the From header listed the user's name but with the mailing list's address (just like it does now), and the Reply-To header just listed the mailing list's address (whereas now, it lists the mailing list's e-mail address _and_ the poster's e-mail address). So, prior to the last update that Brad did, I don't think that the poster's e-mail address was available anywhere in messages from the mailing list. However, if I look at messages from several years ago, it used to be that the From field listed the poster's name and e-mail address (not the mailing lists's), and the Reply-To header listed the mailing list's address. So, if we want to try to hide the poster's e-mail address, the behavior that mailman had a few months ago would be best, whereas if we want that information to be available, then it's behavior from several years ago would be best. Either way, having Reply-To include the poster's e-mail address is going to result in a lot of unnecessary e-mails going directly to folks in addition to the mailing list. - Jonathan M Davis We cannot go back to several years ago unless you can convince the world to also roll back dmarc. That travesty of justice really screwed up mailing lists in general. It was designed and implemented fairly ignorant of the ways in which lists work. So that's off the table. For the moment, we're back to the posters email is nowhere to be found, which is bad for some use cases. There really is no one correct answer here. Reasonable people are going to disagree.
Re: NNTP client configuration
On 2/20/2018 6:00 PM, Manu wrote: Hey Brad; is it possible to strip out the HTML copy from emails before distribution? I'm a bit tired of being a bad guy for unknowingly committing a crime by using my email client in the default and completely normal way ;) Yes, mailman can filter messages and message parts, but I've never used them and those features aren't enabled on any list I run. I'm hesitant to start playing those sorts of games on lists with as many subscribers (on either side of the nntp/smtp divide) and as much traffic as the d lists get.
Re: NNTP client configuration
On 2/20/2018 4:53 PM, Seb via Digitalmars-d wrote: On Wednesday, 21 February 2018 at 00:32:54 UTC, Manu wrote: On 20 February 2018 at 02:05, Jonathan M Davis via Digitalmars-d wrote: Now, the double-posting with both text and html is another matter entirely but if the NG really doesn't want the html version of the email, it would be easy for the mailing list to mechanically truncate the html, Yes, but only one guy (Brad) is admin here. There's really no point is discussing this for hours here. Simply write Brad. You can reach him either via GitHub Issues: https://github.com/braddr/d-tester/issues Or for his email, simply look at the git log (he made the first git commit) Do not use the d-tester issues for non tester related issues, please. Jonathan alerted me to the issue a couple days ago and I've been looking into this today. It's due to a behavior change between versions of mailman used on the old (being a relative term.. been a few months now) mail server and the current mail server. I don't see the solution yet, but I'm working to figure out how to restore the previous behavior.
Re: Bump the minimal version required to compile DMD to 2.076.1
Typically support isn't dropped the instant the most recent version of the OS drops support but rather when the last supported OS release is no longer supported. So, once 10.13 is no longer supported, then we can have the conversation about dropping 32 bit binary creation support. On 1/13/2018 2:14 AM, Jacob Carlborg via Digitalmars-d wrote: On 2018-01-12 19:45, Joakim wrote: For now, I think you have no choice but to simply work around whatever that bug is. We should drop support for 32-bit OS X sometime soon, and if that fixes the issue, you have no problem. Exactly. Apple will drop support for running 32bit applications in their next major OS release, 10.14.
Re: OT: Evidence of A Intel Virtual Memory Vulnerability
On 1/3/2018 7:51 AM, Jack Stouffer via Digitalmars-d wrote: The gist of the story is that an Intel vulnerability is requiring OS vendors to institute Page Table Isolation in their kernels. This fix has an _across the board_ 5-7% slowdown on Intel chips. Worse yet, programs which do lots of syscalls will see around a 30% slowdown or more, including compilation. AMD is not effected. Details and discussion: Reddit: https://www.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/ HN: https://news.ycombinator.com/item?id=16046636 Calling it a vendor or architecture specific issue is a bit misleading, based on the reading I did today. There's a couple different vulnerabilities here and they tie back to speculative (ie out of order) execution, timing of branch prediction, and timing of various conditions. These techniques are _widely_ used among high speed processors and any that use them are likely to be vulnerable when an adversary can control and time execution of code and data in caches. The same basic techniques have shown up in a number of recent exploits, for example some of those in SSL and TLS over the last few years. It's very interesting research and I fully expect more of this sort of issue as more and more research is done.
Re: Note from a donor
On 10/27/2017 1:06 AM, Jacob Carlborg via Digitalmars-d wrote: On 2017-10-27 04:34, Brad Roberts wrote: Actually, one of the 3 macos boxes is using stock xcode tooling these days. I specifically went that direction when setting up a new system that replaced one that died on me (well, it boots but if I actually _use_ it it crashes, sigh). So, but on the older osx releases (not positive the exact versions off the top of my head) there were issues that forced us back to an old gcc version rather than the default clang compiler. I haven't been using GCC in years and I never had any problems with compiling DMD using Clang. The issues weren't compiling dmd but passing the full test suite. Both are required.
Re: Note from a donor
On 10/26/17 5:23 AM, Steven Schveighoffer via Digitalmars-d wrote: On 10/26/17 7:09 AM, Mike Parker wrote: I also didn't like that I had to install the Xcode tools on my Mac, but that's needed for any development on Mac from what I can see. Want to hear something scary? The autotester does not use xcode tools :) In fact, I've been meaning to bug Brad about checking to see if things have improved (xcode's compiler used to generate a dmd that would fail some of the tests). I've never used gnu gcc, only ever Xcode's compiler (which is llvm). -Steve Actually, one of the 3 macos boxes is using stock xcode tooling these days. I specifically went that direction when setting up a new system that replaced one that died on me (well, it boots but if I actually _use_ it it crashes, sigh). So, but on the older osx releases (not positive the exact versions off the top of my head) there were issues that forced us back to an old gcc version rather than the default clang compiler.
Re: AWS SDK
On 10/17/2017 6:32 PM, Ky-Anh Huynh via Digitalmars-d wrote: On Tuesday, 28 June 2016 at 00:36:31 UTC, Brad Roberts wrote: On 6/27/16 10:53 AM, Brad Roberts via Digitalmars-d wrote: On 6/26/2016 4:06 PM, Jadbox via Digitalmars-d wrote: [...] I have some old code here: https://github.com/braddr/downloads.dlang.org/tree/master/src It has sig v2 signing and some s3 object related code. Super minimal and sig v2 is out of date (though still very usable, in most aws regions). Ideally, someone would partner with aws -- there's a developer tools forum -- to add D to the suite of languages. I'm fairly sure they code generate at least a large part of the tool kits from the api definitions for each of the tons of services. Trying to manage them all by hand is a loosing battle. I've been tempted to do this a couple times, but the time investment would likely be more than I'm willing to spend. I've started talking with a few of the aws sdk engineers (some of who I worked with when I was there) today about their sdk and the tooling involved. It might not be a horrible job to add another language to the mix. I'm going to meet with them and dig through some of the tooling to get a better feel for it. Later, Brad Hi Brad, Do we have any good update on this? I'm writting my devops tools in Dlang now (Golang is too hot to use, isn't it:D). It's a great win if we can have AWS SDK support. I'm not a master however if there is any thing I can help, please let me know. Thanks for your reading. Unfortunately, I haven't made the time. Too much contract work being thrown my way for the last year or so.
Re: D on quora ...
On 10/6/2017 10:19 PM, Adam Wilson via Digitalmars-d wrote: What if we stop focusing on the C/C++ people so much? The like their tools and have no perceivable interest in moving away from them (Stockholm Syndrome much?). The arguments the use are primarily meant as defensive ploys, because they compare everything to C/C++ and when it doesn't match in some way or another the other language must be deficient. They've already decided that C/C++ is the meter stick against which all other languages are to be judged. Unsurprisingly, nothing that is NOT C/C++ meets their exacting demands. I saw we ditch the lot and focus on the large languages where D can get some traction (C#/Java). Or recognize that painting huge diverse groups as if there's a single brush with which to do so is a huge fallacy. Consider that the two leaders, as well as a large number of the contributing developers, come from the c++ community and that's not a bad thing, but rather a big part of _why_ they came to D. As always, focusing on the users of the language tends to pay a lot more dividends than focusing on nay sayers. Luckily, that's how things tend to proceed here, so yay for that.
Re: Deimos X11 bindings license question
On 9/5/2017 10:19 PM, Joakim via Digitalmars-d wrote: I'll also note that if a developer uses GPL software on the server, he doesn't have to give any source to users who access apps on the server remotely. For example, Google uses a linux kernel with proprietary modifications on a million servers running their search engine, yet my understanding is that they have not made most of those modifications available, as they're not required to under the GPL. By contrast, every Android vendor has to release the source for their linux kernel. It's not a coincidence that GPL software took off on the sever, until and except for Android's kernel. Your understanding is somewhat flawed. Google is a major contributor to the linux kernel as well as quite a few other projects. They are extraordinary members of the open source community and the internet at large. They have one of the most proactive security teams out there as another example. Please, do a little research. While there's a lot to dislike about google and their public facing services, they offset that quite a bit in my eyes through how their engineering staff behaves.
Re: Call to Runtime.unloadLibrary corrupts stdout and stderr
On 9/3/2017 1:07 PM, Rainer Schuetze via Digitalmars-d wrote: This workaround has side effects, i.e. it doesn't automatically close any file still open by the DLLs' instance of the C runtime, so it might cause incomplete files if someone relies on these being automatically flushed and closed. It's a bug in the dmc runtime. Only Walter can fix it as it is closed source. The source is on github, but it's in a private repo. I'm sure Walter would be happy to give access to it should someone who wants to fix it step forward and ask him.
Re: Community Rant
On 8/23/2017 3:58 PM, Mark via Digitalmars-d wrote: On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote: [...] But lets be honest. If I was just interested to learn about this "modern system programming language" that is C++ done right, I would dismiss D very quickly. We need to get together as a community and rethink your priorities, because with problems like this we're making it very hard for newcomers to trust in this very poorly adapted language. Programming tools used by day to day programmers should be a priority. Because everyone expects valgrind to work. [...] This kind of criticism comes up fairly often in the forums, maybe once every few weeks. I can link to the recent threads on the matter, but I'm sure you can make an educated guess about the responses therein. The gist of it, in my view, is that: "[Making] D more approachable and attractive to people thinking of picking up the language." just isn't a high priority right now. That's one way to look at it. Another, slightly more accurate and nuanced version is that there are many areas for improvement, and those that are doing work to improve things are doing them in areas they believe are important and useful for their work. That there's not more in the area , that you (and others) believe is important, merely shows that the number that believe is important enough to work on right now is close to zero. That doesn't mean that isn't also important, just that it's not at the top of the priority list for those getting things done. Convince someone that is higher priority than the things they're working on then you might see some movement on those fronts. Or convince yourself that it's important enough to engage in yourself. This isn't really a community level issue so much as a very personal level issue. It's not sufficient for something to be declared a community level priority if no one at the personal level is interested enough to contribute their time.
Re: proposed @noreturn attribute
On 7/17/2017 5:06 PM, Seb via Digitalmars-d wrote: I can't agree more. This is textbook procrastination and bike-shedding [1]! There are dozens of open regressions that could have fixed or great, stalled PRs that could have been reviewed. In fact if only PRs would be as heartily reviewed as the discussion here, things like the fact that DMD leaks all symbols when imported selectively [2] would have been uncovered earlier. [1] https://en.wikipedia.org/wiki/Law_of_triviality [2] https://github.com/dlang/phobos/pull/5584#issuecomment-314910297 Semi-valid, but fungability of time and effort>.
Re: size_t.sizeof == 2 && __LINE__.sizeof == 4
On 7/10/17 10:49 AM, Luís Marques via Digitalmars-d wrote: On Monday, 10 July 2017 at 17:32:01 UTC, Iain Buclaw wrote: The official stance is that we don't. There is just far too much baggage that gets piled in by default that makes it very hostile, however those of us who are capable of doing so won't try to stop you, and you have the likes of minilibd and other minimal D libraries as friendly replacement, perhaps you could even use them on top of musl. ;-) By "we don't" it seems you are referring to supporting D + druntime + Phobos. But, to clarify, plain -betterC D seems to work well. One issue is that size_t currently has the wrong size, and changing it involves at least some druntime support (changing object.d, and changing all of the size_t line = __LINE__ fallout). BTW, I wasn't sure how I should go about changing druntime and Phobos regarding the size_t line -> line_t line transition. I opted to change LDC's fork of druntime first, because it seemed to me like the contribution had a better chance of being accepted, and afterwards make a separate dlang/druntime pull request. But the more natural way would probably be to change the canonical druntime first and then merge the changes on the LDC side, no? - Luís I think this is a great example of a project where the best path is to fork the compiler, runtime, and phobos (if you intend to go that high up the stack) and just go do it. Don't worry, for the short term, about any of the naming issues, mergability, etc. Make it work, use it, learn what the big issues are, etc. Then, cycle back and look at how to merge. I suspect there's going to be a lot of issues and finding out what's important to disucss in what order is useful. Getting bogged down early is going to be frustrating.
Re: Experience with https://www.patreon.com
On 7/6/17 6:53 AM, Andrei Alexandrescu via Digitalmars-d wrote: Does anyone have experience with https://www.patreon.com either as a patron or creator? Thanks! -- Andrei I have experience as both. Feel free to grab me off-list to talk in more detail.
Re: Experience with https://www.patreon.com
On Thursday, 6 July 2017 at 16:00:05 UTC, Jack Stouffer wrote: On Thursday, 6 July 2017 at 13:53:08 UTC, Andrei Alexandrescu wrote: Does anyone have experience with https://www.patreon.com either as a patron or creator? Thanks! -- Andrei It works well for supporting artists. I support many people with it. However, if you're thinking of an application for the D foundation, I don't know if that's the right avenue. It would certainly work, but Patreon is more built for people who release discrete pieces of content, not necessarily charities who have less concrete results. Pippin from GIMP uses it pretty successfully for general work mostly related to GIMP https://www.patreon.com/pippin
Re: regressions
On 7/2/2017 7:27 AM, Vladimir Panteleev via Digitalmars-d wrote: On Friday, 30 June 2017 at 12:48:12 UTC, Martin Krejcirik wrote: DMD, Phobos and Druntime open regressions over time: http://bid.iline.cz/~mk/tmp/regs.png Used to be stable, but seems to be getting worse since 2016. One thing that might have contributed to that is that until a year or two ago, we weren't really checking whether filed bugs were regressions. As it turns out, a good deal of the time when someone runs into a bug, they don't even realize that it's some behaviour that used to work previously. This is why you will occasionally see recently-filed bugs that are marked as regressions in very old versions, likely older than since the submitter started using D. Knowing whether a bug is a regression is useful because then you can track down the change that caused it, and it's often much easier to find the bug in a small diff and fix it. The downside is that it makes the meaning of the "regression" severity less useful when tracking how many of those issues actually broke someone's code (that we know about), which is why the regressing version is prefixed in issue summaries. One of the biggest issues is that for a small period of time a few years ago, releases were actually gated on fixing regressions. That stopped at some point and the backslide has gotten pretty bad. There was a period where there was exactly one open regression. It's one of my big disappointments in the current dev/release cycles. That said, since I really haven't been participating in active development, I tend to just bite my tongue and say nothing. Holding to a line of no known regressions is a critical aspect of incrementally better releases.
Re: Phobos PR in need of review/merge
On 6/27/17 11:09 AM, Dukc via Digitalmars-d wrote: But there is just no reason I see to keep a request in "alive" state if I don't check it actively anymore. The closed pr can be opened later if I or someone else wishes to push for it again. There's a very good reason to leave requests open: a closed request is gone, never to be seen again (yes, it's technically still findable if you search closed but not merged requests, but it's super unlikely to ever happen). An open request, though one among many, is still discoverable. It's in the list and eventually someone will ping it or stumble on it, or maybe one dream day there will be sufficient activity to chip away at the massive (350ish right now) queue of pulls and it'll be taken care of.
Re: Windows integration [was: Re: There really needs to be some moderation]
On Sunday, 18 June 2017 at 21:47:48 UTC, Laeeth Isharc wrote: [snip] Windows has been a bit of a pain, but mostly from the native code library side. It should be easy to install google snappy right? On Linux it is. On Windows, not so much... And that's just one library. vcpkg is making it pretty easy to get C and C++ libraries on Windows. Snappy is supported. https://github.com/Microsoft/vcpkg
Re: What is your favorite D feature?
On Thursday, 22 June 2017 at 00:48:25 UTC, Seb wrote:
Hi,
I am currently trying to modernize the D code example roulette
on the dlang.org front page [1]. Hence, I would love to hear
about your favorite feature(s) in D.
Ideas:
- favorite language construct
- favorite code sample
- "only possible in D"
Before you ask, yes - I want to add a couple of cool examples
to dlang.org (and yep the roulette rotation is currently broken
[2]).
[1]
https://github.com/dlang/dlang.org/pulls?q=is%3Apr+is%3Aopen+label%3A%22Frontpage+example%22
[2] https://github.com/dlang/dlang.org/pull/1757
A very simple vibe app could be added using dub's single-file
package format. Something like (I haven't tried this):
#!/usr/bin/env dub
/+ dub.sdl:
name "hello"
dependency "vibe-d" version="~>0.8.0-rc.1"
+/
import vibe.d;
shared static this()
{
auto settings = new HTTPServerSettings;
settings.port = 8080;
listenHTTP(settings, &handleRequest);
}
void handleRequest(HTTPServerRequest req,
HTTPServerResponse res)
{
if (req.path == "/")
res.writeBody("Hello, World!", "text/plain");
}
// Dependencies fetched, compiled, cached, built against, and
result executed
// in one command:
// $ ./hello.d
Re: DMD is now part of the doc pages on dlang.org
No idea how much work it is to add another section specifically for the front end, but the front end docs really don't belong co-mingled with the phobos and library directories. It's part of neither. On 6/6/17 3:13 PM, Seb via Digitalmars-d wrote: Hi all, I have excellent news on the front of DMD becoming a library. DMD on dlang.org Since today DMD's documentation is browseable online on the released docs: Ddoc: https://dlang.org/phobos/ddmd_mars.html Ddox: https://dlang.org/library/ddmd/mars.html In particular this is pretty handy with DDox's symbol search (top right), see e.g. [2] for example screenshots. I guess that not many people noticed, but the prereleases pages (i.e. the current master branch) contained the DMD pages for quite some time: Ddoc: https://dlang.org/phobos-prerelease/ddmd_mars.html Ddox: https://dlang.org/library-prerelease/ddmd/mars.html Status quo -- Many pages aren't well-documented for now and the blacklist of exposed modules [3] needs some expansion as well. However, fixing these pages is now just a PR away (see the "Improve this page" button on the top-right). Building DMD documentation pages If you build the pages yourself, you will be interested in the `-prerelease` ones as they are built from latest (i.e. your local dmd repository). Just clone dlang.org and for the Ddoc pages, execute the `dmd-prerelease` target: make -f posix.mak dmd-prerelease html Of course the `html` target is only needed once and don't get confused by the files being in web/phobos-prerelease. Or alternatively with Ddox (and the files being in web/library-prerelease): make -f posix.mak apidocs-prerelease There's also a bit hidden target that will spawn a Vibe.d instance and is faster to start as it only renders a documentation page on-demand: make -f posix.mak apidocs-serve Other work -- - Jacob is putting a ton of effort into making DMD easily accessible via DUB [4] - Razvan is making sure that you can use the resulting library [5] [1] Enable DMD docs on dlang.org PR: https://github.com/dlang/dlang.org/pull/1671 [2] DDox search examples : http://imgur.com/a/lddjt [3] Module blacklist: https://github.com/dlang/dlang.org/blob/master/posix.mak#L73 [4] DMD as DUB package PR: https://github.com/dlang/dmd/pull/6771 [5] DMD as a library PR: https://github.com/dlang/dmd/pull/6836
Re: Phobos 2
On Friday, 2 June 2017 at 09:14:14 UTC, qznc wrote: Frankly, I do not see the need for Phobos2. If you want to build alternative packages, just go ahead and publish them via dub like Mir, for example. You can even make a meta package, if you find yourself using the same group of packages all the time. Still, why would you call that meta package "Phobos2"? It only confuses people. If you want to rewrite parts of the standard library, build the alternatives first and then we can adopt them piecewise. Makes sense. I've said in the past that the standard library should be smaller now that we have Dub. The standard library should serve as a common framework that lets libraries interoperate easier. If an effort was undertaken it should probably not be called Phobos2 until such time (if ever) that it becomes Phobos2 by community vote and Walter and Andrei approval. C++'s Boost has a problem where libraries people are working on get called Boost Whatever in anticipation of being proposed for Boost and many of them never even make it to the review stage so it becomes confusing about what is and isn't in Boost. It's also confusing because competing libraries will be proposed and a non-Boost library is already taking Boost ObviousName so they have to come up with some weird name instead. Nevertheless, I would love to read a detailed analysis of Phobos and what should be improved. Please, write a blog post somewhere. However, do not mention "Phobos2". This is the heart of why I made the post. I want to read what people want myself. D has a painful history with two competing standard libraries. If you seriously propose this path, I hope Andrei and Walter will publicly and vehemently oppose it. Otherwise that ghost from the past becomes a PR disaster for D. Not very seriously. I'm more interested in the discussion than anything. Like I said, I don't think this will go anywhere. I do want to say that I don't think the Phobos/Tango situation is relevant. Those were two competing, mutually exclusive standard libraries. That problem has long since been resolved with people using Tango and Phobos together in their D2 programs just fine. I understand why anyone would be weary at the idea though.
Phobos 2
A (surely controversial) idea popped into my head while talking in #d on Freenode. The C++ guys are making an STL2 (the highlight of it being that it is range based). What about taking all the lessons learned from Phobos and creating a Phobos 2? It wouldn't replace the current version. You could import either in one program. It also wouldn't be a radical redesign. Most of Phobos could be used as is. What it would do is allow fixing some hard or impossible problems without losing backward compatibility. We could do away with auto-decoding. Design it around using Andrei's allocators throughout. Make the GC optional from the start. Fix a few important naming conflicts and discrepancies. There are problems, of course. Rampant code duplication is probably the biggest (though maybe public imports of identical code would help a lot). I don't really expect this to go anywhere but I am curious to hear what changes you'd all like to see made to Phobos that can't happen because of backward compatibility. Also, how would you approach doing this? An on disk copy of Phobos with changes would not be an acceptable approach, I think.
Re: Bad array indexing is considered deadly
On 5/31/2017 5:37 PM, John Colvin via Digitalmars-d wrote: P.S. Sometimes I do feel D is a bit eager on the self-destruct switch, but I think the solution is to rise to the challenge of making better software, not to be more blasé about pretending to know how to recover from unknown logic errors (exposed by unexpected input). This.. exactly this. I've worked on software from the tiny device level to the largest distributed systems in the world and many in between. The ones that are aggressive about defining application correctness through asserts and similar mechanisms and use the basic precepts of failing fast are the most stable. Problems are caught early, they're loud, obnoxious, and obvious. And they get fixed, fast. I'm happy that D takes a similar stance. It makes my job easier. - Brad
Re: A Few thoughts on C, C++, and D
On 5/29/2017 1:36 PM, Moritz Maxeiner via Digitalmars-d wrote: On Monday, 29 May 2017 at 17:09:21 UTC, aberba wrote: IMO, the most important thing is getting the job done. * getting the job done right. Otherwise, you are just going to accumulate patchy code for which you will pay down the line continuously. At least as important as getting the job done, is doing jobs. As much fun as it is to debate and discuss what could or needs to be done to attract one group of developers or another, actually using and releasing systems built with D are going to contribute to accumulating to the total mass of code. Each time someone wraps a new library, each time someone fixes some bug because it affects them, etc.. these all push things forward inch by inch. Eventually that mass might actually reach critical. But even if it doesn't, things continue to get incrementally easier for those that already use D and it's ecosystem.
Re: Low hanging fruit: dub git integration
On Tuesday, 16 May 2017 at 18:10:52 UTC, Andre Pany wrote: Hi, While integrating the git protocol into dub is complex, there is a much much easier solution. Github and bitbucket provides access to the source code, including releases, branches and commits as archive files using the http protocol. Without counting the actual unzip/untar coding I assume more or less 100 lines of additional coding is needed in dub. In dub.json in addition to the existing path attribute of the dependeny object a new attribute "url" has to be added. You can specify here an url to a zip/tar.gz. This file has to be downloaded and extracted. The extract path is then filled into the existing path attribute of the dependency object. The only issue is the untar/unzip logic... This little tweak would make dub a lot more flexible like npm. Kind regards André This is actually exactly how dub fetches source code but the registry does it rather than dub itself (I'm not sure why)[1]. A bare URL dependency may be controversial though because it makes versioning more difficult to ensure. 1. https://github.com/dlang/dub-registry/blob/d825840770bb29356495f265480035ed7e3321b8/source/dubregistry/repositories/github.d#L89
Re: dmd: can't build on Arch Linux or latest Ubuntu
On 5/10/2017 9:20 AM, Seb via Digitalmars-d wrote: On Wednesday, 10 May 2017 at 11:51:03 UTC, Atila Neves wrote: Maybe add newer distros on the autotester? Hehe, that's nearly not possible. Since a couple of months there's an ongoing effort to change the directory layout to src/ddmd, which is been blocked by necessary changes the autotester. Yup, but not on my side for a change. :) The first pull request was broken in that it unilaterally broke old branches (ie, stable would have been broken since it still had the old layout). Then it turned out that the windows new layout doesn't match the posix new layout, so still broken at the packages to be tested layer. I'm confident that one day the directory layout changes will actually be completed and consistent.
Re: DConf Hackathon Ideas
The pending pull requests. In person is a great high-bandwidth way to work through the massive backlog. On 4/27/2017 7:53 AM, Mike Parker via Digitalmars-d wrote: This year, DConf has an extra day tacked on for problem solving in the form of a hackathon. The intent is to work on issues people find frustrating in the D ecosystem. While there will be time given at the event for proposals, and those involving third-party projects are welcome, it will help speed things along for the organizers to come in with a list of big issues to get the ball rolling. To help in compiling the list, what are some major issues from the ecosystem that you'd like to see fixed?
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Friday, 21 April 2017 at 17:20:14 UTC, Vasudev Ram wrote: [snip] DLanger? DLangist? D'er? Doer? :) Martian.
Re: Upgrading the minimum version of FreeBSD supported
On 4/2/2017 9:20 PM, Jonathan M Davis via Digitalmars-d wrote: On Sunday, April 02, 2017 20:40:15 Brad Roberts via Digitalmars-d wrote: I grabbed the official 10.3-CURRENT vm image from the freebsd website and gave it a whirl. For the 64 bit test run, the only failure was std.datetime unit tests failure. Apparently LocalTime().stdName is null and the assert at line 28248 fails. Weird. I was running on PC-BSD 10.3 for a while (which should be the same as FreeBSD 10.3 proper for everything that matters), and I never saw that failure. I guess that I'll have to find some time to look into it. - Jonathan M Davis Following up on this thread, I've setup another auto-tester project with just two new freebsd machines, 10.3 and 11.0. The purpose is to allow anyone who has the time and desire to help fix the issues to have a place to view the results. So please, submit pull requests so we can get the issues fixed and retire the old 8.x machines. The github project they're building is github.com/braddr/dmd|druntime|phobos/tree/freebsd-update.
Re: Upgrading the minimum version of FreeBSD supported
On 3/31/2017 6:30 PM, Jonathan M Davis via Digitalmars-d wrote: On Friday, March 31, 2017 15:51:33 Walter Bright via Digitalmars-d wrote: The autotester is currently at FreeBSD 8.4. This is rather obsolete. The linker that is standard on 8.4 is causing problems: https://github.com/dlang/dmd/pull/6564 The oldest supported version of FreeBSD stands at 10.3: https://www.freebsd.org/security/unsupported.html I know the linker with FreeBSD 11.0 does work correctly. I don't know which FreeBSD version it was fixed on. So the question is, can we at least move to FreeBSD 10.3 as the minimum supported version? Is anyone very dependent on an older FreeBSD? Is there a case for supporting FreeBSD versions that are officially unsupported? Some work was done a year or two ago to fix FreeBSD 9 and 10, and AFAIK, they both work, though I've never used FreeBSD 9. 10.3 did work the last time I tried it, as did 11.0 (both passed druntime and phobos' unit tests, and I _think_ that I ran dmd's tests and that they passed, but I'm not 100% sure, since I don't run those normally). FreeBSD CURRENT does _not_ currently work properly due to a problem with stack unwinding that results in bus errors when an exception is thrown. I think that there's a decent chance that it's a FreeBSD bug as opposed to ours, but I haven't gotten around to contacting the FreeBSD devs about it yet. However, that problem has not yet made it into an official release, and hopefully it never does. As for the minimum version to support, I'd be very much inclined to argue that we only officially support the versions that the FreeBSD folks currently support, or we're just asking for trouble. And honestly, I think that we should do the same on all platforms. If someone wants to run an unsupported version of an OS, they're just begging for trouble anyway, and they can always use an older version of the compiler that did support that OS. And actually, the last time I checked, the official FreeBSD port for dmd claimed that we don't officially support FreeBSD, even though we theoretically do (probably because support for it hasn't been as good - e.g. we test on an outdated version of the OS and took quite a while to fix druntime for newer versions of FreeBSD). Sadly, I think that the primary reason that druntime works correctly on FreeBSD 10 and 11 now is because I switched to using it as my primary OS and complained when it didn't work. It seems to have primarily gone under the radar otherwise. - Jonathan M Davis I grabbed the official 10.3-CURRENT vm image from the freebsd website and gave it a whirl. For the 64 bit test run, the only failure was std.datetime unit tests failure. Apparently LocalTime().stdName is null and the assert at line 28248 fails. There's at least one additional failure on 32 bits in allocator/building_blocks/region.d line 652. I ran out of time to dig for today, but the bottom line is that 10.3 isn't ready to be the base platform for dmd as is. Chances are it could be with only a little work though. I haven't tried 11 yet either. Later, Brad
Re: So no one is using Amazon S3 with D, why?
I've been in touch with the manager of the aws sdk team (he and I worked together for a while). He's willing to help with adding another language to the full sdk, but it'd be non-trivial. There's a code generator (maybe more a generation language) involved that emits from a base service description for the entire suite of aws services. It'd take some work to do the full sdk. Ignoring all that and just doing a thin s3 specific api would be extremely easy since the api itself is so simple. I have a quickly hacked together -- ie would do better on a new round -- for a specific tool: https://github.com/braddr/downloads.dlang.org Ignore the tool on top of the code, it's out of date. On 3/14/17 1:21 PM, aberba via Digitalmars-d wrote: Amazon S3 seem like a common solution for object storage these days[1] but I'm seeing almost no activity in this area (stable native D API). Why? [1] https://trends.builtwith.com/cdn/Amazon-S3
Re: If you needed any more evidence that memory safety is the future...
On 3/8/2017 5:56 AM, Moritz Maxeiner via Digitalmars-d wrote: On Wednesday, 8 March 2017 at 13:30:42 UTC, XavierAP wrote: On Wednesday, 8 March 2017 at 12:42:37 UTC, Moritz Maxeiner wrote: Doing anything else is reckless endangerment since it gives you the feeling of being safe without actually being safe. Like using @safe in D, or Rust, and being unaware of unsafe code hidden from you behind "safe" facades. Safe code should be unable to call unsafe code -- including interop with any non-D or binary code, here I agree. I was supposing this is already the case in D but I'm not really sure. You can hide unsafe code in D by annotating a function with @trusted the same way you can hide unsafe code in Rust with unsafe blocks. Clearly marked is an interesting definition of hidden.
Re: Under 1000 opened bugs for Phobos
On 12/24/2016 7:24 AM, Andrei Alexandrescu via Digitalmars-d wrote: On 11/03/2015 09:35 AM, Andrei Alexandrescu wrote: https://goo.gl/r24Izw Replying to my own message from November 2015... well, right now we have 953 open bugs for Phobos. 500 is next! -- Andrei Progress is progress, but I prefer looking at more targeted lists than all open bugs. My favorite is all open bugs with severity above normal (which is the default for new bugs). That trend, unfortunately, is generally upwards and always has been. Here's my saved search, which I just made public: https://issues.dlang.org/buglist.cgi?cmdtype=runnamed&list_id=212617&namedcmd=high%20severity There's more open regressions than ever before too. My 2 cents, Brad
Re: Red Hat's issues in considering the D language
On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote: On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. Is moving to LLVM backend or LDC something that is on the roadmap? What does it mean to "move" to LDC? Why can't you use LDC now? Moving the reference compiler to LLVM as was suggested in the list. I've never been able to understand why it matters. You can use LDC or GDC now. Slapping the name "reference compiler" on one of them won't change anything. I think most frontend developers prefer working in the DMD umbrella for speed and simplicity reasons. Editing and building DMD is dead simple. In theory the backend should be completely divorced from the frontend and people would be editing a libd repo or something and there wouldn't be a need for a reference compiler.
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 15:47:38 UTC, Nordlöw wrote: On Tuesday, 20 December 2016 at 15:40:57 UTC, Nordlöw wrote: DIP-32 has been dormant since 2013. I've been waiting for builtin tuples ever since I started using D. I wonder if it might be possible to add the tuple syntax incrementally into DMD? It's always easier to approve something less complex. Could the comma expression be contextually removed? Specifically in return expressions as discussed initially in this post? Back in May a change was introduced to issue a deprecation message for uses of the comma operator outside of a for statement. Not sure which dmd version it got introduced into but it's surely in there by now. https://github.com/dlang/dmd/pull/5737
Re: The Computer Language Benchmarks Game - no D
On Sunday, 18 December 2016 at 21:29:05 UTC, jmh530 wrote: On Sunday, 18 December 2016 at 21:26:36 UTC, Boston wrote: Some days ago I'd been looking for comparisons between different programming languages, and I found this site: It's been discussed on the forum before. Yeah, many times. We'd all like to see D there but Isaac Gouy (the maintainer of the language shootout) has made it pretty clear D isn't getting on there but he welcomes anyone to use the shootout's infrastructure to run their own benchmarks for D and put it up on their own site. I understand his position because no matter what he does and what he includes there will always be someone unhappy with it. I'd like to see something like the Techempower web framework benchmarks done for general computation language benchmarking like the language shootout, personally.
Re: Making AssertError a singleton
On 12/12/16 12:59 PM, Andrei Alexandrescu via Digitalmars-d wrote: On 12/12/2016 11:35 AM, safety0ff wrote: On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote: But of course there are many situations out there. Wouldn't it break chained assertion errors? Once a type in Error's cone gets thrown there is no guarantee of unwinding, hence no guarantee of chaining. -- Andrei For this to have much meaning, at some-point druntime (for all the various compilers) is going to need to be changed to not unwind. It does, and has all the effects that come from that. What actually happens tends to trump what the documentation claims it's allowed to not do. Of course, then you'll find the fun of all the tests (and probably code) that catch AssertError.
Re: How about a bounty for a new windows installer using inno setup ?
On Monday, 5 December 2016 at 19:33:33 UTC, Jim Hewes wrote: On 12/5/2016 3:19 AM, Kjartan F. Kvamme wrote: On Monday, 5 December 2016 at 09:24:59 UTC, Basile B. wrote: How about a bounty for a new windows installer using inno setup ? There are several issues related to the nsis-based windows installer (even on bugzilla). The problem that happened last Fall with a virus false detection may happen again. "Braddr" proposed to handle digital signatures in case it would involve payment. Programming an installer is a small job but it has a long term impact on the user experience. Worth 100€ imo. Any particular reason to use Inno Setup over for example Wix Toolset? In my last job I worked on installers (which I didn't like but someone had to do it.) I recommend WiX over Inno. The main reason is that WiX produces an MSI and Inno doesn't. An MSI is just a data file, not an executable, and is thus better for security. I normally wrapped the MSI in a bootstrap exe. But we had one customer that was part of the government and wouldn't accept anything but an MSI. If you want, you can generate the XML with a program. I just didn't because I figured it was easier to modify if you can directly see the XML. My install builder was actually a combination of C# and WiX. I never found scripts to be flexible enough and it's just one more language to know. Jim Yes, if DMD is going to switch the installer to something else it should be MSI. It's the official way to create installers on Windows and IT departments prefer it. Just switching to another installer executable generator is a lateral step, rather than a step forward. Microsoft seems to be wanting to quietly deprecate MSIs too and are increasingly not using them for their own products (likely to push people to the Windows Store). I'm not sure if the Windows Store is suitable for DMD though and adapting DMD to it would probably involve quite a bit of work and would likely involves legal agreements with Microsoft that only the D Foundation could make.
Re: State of issues.dlang.org
On 11/2/16 2:44 PM, Vladimir Panteleev via Digitalmars-d wrote: On Wednesday, 2 November 2016 at 12:34:04 UTC, Wyatt wrote: This was added in Bugzilla 5.0. We're just running 4.4.2 on issues.d.o. Unfortunately, I'm not sure how easy it is to upgrade... I believe Brad is using the Debian packaged version, so we'll get it whenever it reaches whatever Debian flavor Brad is running. Actually, bugzilla is one of the few things that's not from pre-packaged installers. :) I do have some minor modifications that have to be ported over, primarily related to interacting with the newsgroups. I haven't looked at the 4 -> 5 update to see how easily they changes will translate. The 3 -> 4 transition took some re-working due to internal changes in bugzilla. Upgrading is on my todo list. I'll try to get to it soon. Later, Brad
Re: The bug tracker certificate is expired
Yeah, I let it expire since it's been several years since it was used for anything other than redirecting a couple urls to their real homes. On 10/26/16 9:24 PM, deadalnix via Digitalmars-d wrote: The title says it all. The certificate for https://d.puremagic.com/issues/ is expired.
Re: Meta issue:
On 10/14/2016 3:56 PM, Andrei Alexandrescu via Digitalmars-d wrote: So I just added https://issues.dlang.org/show_bug.cgi?id=16614, which is a meta documentation issue for bootcamp. I'd appreciate it if any of you folks kept in mind to add separate issues (and make this one depend on them) whenever you see bad or nonexistent documentation examples. Thanks, Andrei Why not a keyword? Consider a basic criteria for a trackable entity like this: when can it be considered resolved?
Re: Old bugs
On 10/14/16 4:18 AM, Andrei Alexandrescu via Digitalmars-d wrote: On 10/14/2016 07:17 AM, Andrei Alexandrescu wrote: On 10/14/2016 05:12 AM, Mathias Lang via Digitalmars-d wrote: I've been doing a bit of triaging when I got time, trying to get rid of old bugs / duplicated. It's usually easy to confirm a bug if there's a minimal code example, in which case you can just close it. The enhancement requests, however, nobody but a bunch of people in the core team can get rid of them, because they require a decision to be made. So unless there was a discussion where you or Walter agreed on it (like for deprecating comma operator or implicit string concatenation), they just sit there forever. Eventually, with the new DIP process, we could gradually get rid of them by pointing the author to the DIP repo, then let him/her close the bug as he ACK the notification, or do it after a certain time. What do you think ? Yes, I've already closed a few enhancement requests (such as overhauling the syntax of templates) suggesting they are pursued as DIPs. I'll do more of that in the future, for now I'm focused on bootcamping select issues. If you could lend a hand, please to! -- Andrei s/please to/please do/ Taking a pass through the whole db is a worthy thing to do, but to reduce the enormous time cost of that, focusing on the regression-major set (ie, saving normal and below) would 'only' be 500ish bugs that have a reasonable urgency to them.
Re: Interesting talk about language design and evolution
On Saturday, 24 September 2016 at 03:39:00 UTC, Martin Nowak wrote: A somewhat lengthy but very interesting talk about the tradeoffs for language design and evolution. [CppCon 2016: Bjarne Stroustrup "The Evolution of C++ Past, Present and Future"](https://www.youtube.com/watch?v=_wzc7a3McOs) In particular the part about direction https://youtu.be/_wzc7a3McOs?t=51m29s, and the section about tradeoffs for new features https://youtu.be/_wzc7a3McOs?t=30m16s. Relevant is this list of C++17 features (many of which already work in popular compilers). http://stackoverflow.com/a/38060437/216300 I've got to admit, the D side of me is jealous of a few things on this list. Structured bindings, init ifs (one of those "why did it take so long to come up with this?" ideas), and constructor IFTI. Not sure if it's in C++17 yet but the stackless coroutines look nice too. The baby steps toward CTFE are welcome, of course. It appears C++ still has a long way to go though.
Re: [WORK] std.file.update function
On 9/18/2016 8:17 AM, Andrei Alexandrescu via Digitalmars-d wrote: There is actually an even better way at the application level. Consider a function in std.file: updateS, Range)(S name, Range data); updateFile does something interesting: it opens the file "name" for reading AND writing, then reads data from the Range _and_ the file. For as long as the data and the contents in the file agree, it just moves reading along. At the first difference between the data and the file contents, starts writing the data into the file through the end of the range. So this makes zero writes (and leaves the "last modified time" intact) if the file has the same content as the data. Better yet, if it so happens that the file and the data have the same prefix, there's less writing going on, which IIRC is faster for most filesystems. Saving on writes happens to be particularly nice on new solid-state drives. Who wants to take this with testing, measurements etc? It's a cool mini project. Andrei This is nice in the case of no changes, but problematic in the case of some changes. The standard write new, rename technique never has either file in a half-right state. The file is atomically either old or new and nothing in between. This can be critical.
Re: Autotester farm is down
On 8/17/16 4:47 PM, Walter Bright via Digitalmars-d wrote: On 8/17/2016 4:13 PM, Brad Roberts via Digitalmars-d wrote: Several of the machines are run out of aws. The cost of running a windows instance inside aws is pretty awful. Shrug.. it's a wash, for the most part. For the ones in house, I wonder if it would be cost effective to replace them with ones that draw less power. For example, Win7 laptops can be picked up at the pawn shop for about $150. Put an SSD drive in them, max out the ram, turn off the display, and run them. Of course, they'll be slow, but that may not matter if 2 or 3 running in parallel can replace a single power hungry machine. More slow machines would increase throughput, but would also hurt latency. Both are important, for different reasons. MOST of the equipment is old hardware, so newer machines would also tend to be faster. I'd be willing to accept donations of any i5 or better hardware (maybe i3, reluctantly). Even better would be for me to just get shell access to machines that someone else hosts. It doesn't need to all be centralized in my house.
Re: Autotester farm is down
On 8/17/16 3:27 PM, wobbles via Digitalmars-d wrote: On Monday, 15 August 2016 at 22:33:26 UTC, Brad Roberts wrote: Network connectivity issues. That set of machines runs out of my house and the comcast connection isn't happy, apparently. On 8/15/16 12:55 PM, Lodovico Giaretta via Digitalmars-d wrote: I don't know much about PRs and the autotester, so I'm probably wrong, but... It looks like [1] the autotester farm is down: most hosts have been unreachable for more than two hours and a half, as of this writing. This may slow down the PRs, as all FreeBSD and all Windows hosts are gone. Is it known and expected (maybe maintainance)? [1] https://auto-tester.puremagic.com/hosts/ I wonder how much it would cost to host this in AWS? I imagine it wouldn't be that big a job (famous last words)... plus - I'm sure you don't want to be paying for power and internet bandwidth for it forever either. Now that we have the foundation - this should all be fundable (hell, I'm sure most of us here wouldn't mind donating if it took that!) Several of the machines are run out of aws. The cost of running a windows instance inside aws is pretty awful. Shrug.. it's a wash, for the most part.
Re: Autotester farm is down
Network connectivity issues. That set of machines runs out of my house and the comcast connection isn't happy, apparently. On 8/15/16 12:55 PM, Lodovico Giaretta via Digitalmars-d wrote: I don't know much about PRs and the autotester, so I'm probably wrong, but... It looks like [1] the autotester farm is down: most hosts have been unreachable for more than two hours and a half, as of this writing. This may slow down the PRs, as all FreeBSD and all Windows hosts are gone. Is it known and expected (maybe maintainance)? [1] https://auto-tester.puremagic.com/hosts/
Re: Code signing to help with Windows virus false positives
On Monday, 15 August 2016 at 18:52:03 UTC, Basile B. wrote: On Monday, 15 August 2016 at 17:05:32 UTC, Brad Anderson wrote: With all of the issues people are having with Windows Defender now would be a good time to start code signing the Windows installer and binaries (doing this is the first thing Microsoft suggests on their page for Software Developers about Windows Defender false positives). I propose the D Foundation acquire a code signing certificate and we start using it for releases. Alternatively any well known organization member could be the signer (having "The D Foundation" on the popup sure would look nice though). I'd be happy to put my money where my mouth is and chip in some of the money to cover the certificate cost. I've used StartSSL's code signing certificates successfully for this purpose but I imagine any vendor will do. The biggest hassle is certificate format conversion but once you've got the certificate in the Windows certificate store signing is just a command line call that can be easily scripted. There is already an issue created for this here: https://issues.dlang.org/show_bug.cgi?id=16065 Do you think that a certificate prevents an antivirus to scan an executable ? I'm laughing out of loud here. No. Of course not. To quote Microsoft: "Signing your program’s files in a consistent manner, with a digital certificate issued by a trusted root authority, helps our research team quickly identify the source of a program and apply previously gained knowledge. In some cases this can result in your program being quickly added to the known list or, far less frequently, in adding your digital certificate to a list of trusted publishers." At work we added class 3 code signing and it helped quite a bit with McAfee's warnings about our software for end users. In that case it was warnings about new releases of our software that hadn't had many installs yet. Microsoft isn't selling certificates (though it'd be nice if they offered them like Apple does although with Apple you have to get a DUNS number which I'm sure you consider a scam as well). Please share your suggestions for how to help with the false positive issue (or just continue laughing in ignorance based on an assumption of something I never said).
Code signing to help with Windows virus false positives
With all of the issues people are having with Windows Defender now would be a good time to start code signing the Windows installer and binaries (doing this is the first thing Microsoft suggests on their page for Software Developers about Windows Defender false positives). I propose the D Foundation acquire a code signing certificate and we start using it for releases. Alternatively any well known organization member could be the signer (having "The D Foundation" on the popup sure would look nice though). I'd be happy to put my money where my mouth is and chip in some of the money to cover the certificate cost. I've used StartSSL's code signing certificates successfully for this purpose but I imagine any vendor will do. The biggest hassle is certificate format conversion but once you've got the certificate in the Windows certificate store signing is just a command line call that can be easily scripted. There is already an issue created for this here: https://issues.dlang.org/show_bug.cgi?id=16065
Re: Unable to download DMD as Chrome is convinced it contains a virus
On Tuesday, 9 August 2016 at 17:58:32 UTC, David Colson wrote: Hi, I'm trying to download DMD 2.071.1 on Chrome Version 52.0.2743.116 m (the most recent version as of today) and I can't get the download past the virus checker. Assuming it's a false positive (which it may not be, hence why I'm here asking) why is it getting caught and what can I do about it? I can't find anything in the chrome settings for disabling virus checking on downloads. I even tried to download it in Microsoft Edge (on Win10) and it still got caught. How do I proceed? Chrome just uses whatever virus scanner you have (usually Windows Defender unless you've installed a third party). If you open Windows Defender you can go to History and restore the file from quarantine. Do so at your own risk, of course. Maybe it does have a virus. We do get a lot of false positives with the installer but lately I've been worried about the extra NSIS DLLs we use. They are just pulled from the NSIS wiki...not a very trustworthy source for binaries. We should really switch to an MSI at some point. I have no experience with those unfortunately.
Re: Our docs should be more beautiful
On Monday, 18 July 2016 at 17:09:57 UTC, Kagamin wrote: Do we see the same thing? I see ugly justified hyphenated text https://abload.de/img/tmpr5ow8.png It's hyphenated on browsers that support it. The chrome team is very close to supporting hyphenation so it'll soon be justified in all the major browsers (I think they are just trying to decide what to do on desktops browsers that don't have a system-wide hyphenation dictionary).
Re: year to date pull statistics (2016-07-09)
total open: 266 created since 2016-01-01 and still open: 137 created closed delta 2016-07-10 - today 25 24 -1 2016-07-03 - 2016-07-09 75 97 22 2016-06-26 - 2016-07-02 91 89 -2 2016-06-19 - 2016-06-25 44 24-20 2016-06-12 - 2016-06-18 37 48 11 2016-06-05 - 2016-06-11 40 42 2 2016-05-29 - 2016-06-04 59 66 7 2016-05-22 - 2016-05-28 46 33-13 2016-05-15 - 2016-05-21 40 36 -4 2016-05-08 - 2016-05-14 82 55-27 2016-05-01 - 2016-05-07 37 59+22 2016-04-24 - 2016-04-30 74 85+11 2016-04-17 - 2016-04-23 51 58 +7 2016-04-10 - 2016-04-16 52 58 +6 2016-04-03 - 2016-04-09 64 44-20 2016-03-27 - 2016-04-02 65 60 -5 2016-03-20 - 2016-03-26 65 62 -3 2016-03-13 - 2016-03-19 44 51 +7 2016-03-06 - 2016-03-12 41 46 +5 2016-02-28 - 2016-03-05 54 47 -7 2016-02-21 - 2016-02-27 29 20 -9 2016-02-14 - 2016-02-20 32 36 +4 2016-02-07 - 2016-02-13 52 52 0 2016-01-31 - 2016-02-06 54 61 +7 2016-01-24 - 2016-01-30 40 37 -3 2016-01-17 - 2016-01-23 31 21-10 2016-01-10 - 2016-01-16 39 42 +3 2016-01-03 - 2016-01-09 26 33 +7 2016-01-01 - 2016-01-02 2 5 +3 --- ------ 13911391 0 https://auto-tester.puremagic.com/chart.ghtml?projectid=1
Re: year to date pull statistics (2016-06-25)
total open: 295 created since 2016-01-01 and still open: 159 created closed delta 2016-06-26 - today 47 37-10 2016-06-19 - 2016-06-25 44 24-20 2016-06-12 - 2016-06-18 37 48 11 2016-06-05 - 2016-06-11 40 42 2 2016-05-29 - 2016-06-04 59 66 7 2016-05-22 - 2016-05-28 46 33-13 2016-05-15 - 2016-05-21 40 36 -4 2016-05-08 - 2016-05-14 82 55-27 2016-05-01 - 2016-05-07 37 59+22 2016-04-24 - 2016-04-30 74 85+11 2016-04-17 - 2016-04-23 51 58 +7 2016-04-10 - 2016-04-16 52 58 +6 2016-04-03 - 2016-04-09 64 44-20 2016-03-27 - 2016-04-02 65 60 -5 2016-03-20 - 2016-03-26 65 62 -3 2016-03-13 - 2016-03-19 44 51 +7 2016-03-06 - 2016-03-12 41 46 +5 2016-02-28 - 2016-03-05 54 47 -7 2016-02-21 - 2016-02-27 29 20 -9 2016-02-14 - 2016-02-20 32 36 +4 2016-02-07 - 2016-02-13 52 52 0 2016-01-31 - 2016-02-06 54 61 +7 2016-01-24 - 2016-01-30 40 37 -3 2016-01-17 - 2016-01-23 31 21-10 2016-01-10 - 2016-01-16 39 42 +3 2016-01-03 - 2016-01-09 26 33 +7 2016-01-01 - 2016-01-02 2 5 +3 --- ------ 12471218-29 https://auto-tester.puremagic.com/chart.ghtml?projectid=1
Re: AWS SDK
On 6/27/16 10:53 AM, Brad Roberts via Digitalmars-d wrote: On 6/26/2016 4:06 PM, Jadbox via Digitalmars-d wrote: Is there an AWS library in the works for D? It's seriously the main blocker for me to push adoption of the language internally. If not, I can try to invest time into making one, but I could use help. (fyi, there's one in the works for Rust: https://github.com/rusoto/rusoto) I have some old code here: https://github.com/braddr/downloads.dlang.org/tree/master/src It has sig v2 signing and some s3 object related code. Super minimal and sig v2 is out of date (though still very usable, in most aws regions). Ideally, someone would partner with aws -- there's a developer tools forum -- to add D to the suite of languages. I'm fairly sure they code generate at least a large part of the tool kits from the api definitions for each of the tons of services. Trying to manage them all by hand is a loosing battle. I've been tempted to do this a couple times, but the time investment would likely be more than I'm willing to spend. I've started talking with a few of the aws sdk engineers (some of who I worked with when I was there) today about their sdk and the tooling involved. It might not be a horrible job to add another language to the mix. I'm going to meet with them and dig through some of the tooling to get a better feel for it. Later, Brad
Re: AWS SDK
On 6/26/2016 4:06 PM, Jadbox via Digitalmars-d wrote: Is there an AWS library in the works for D? It's seriously the main blocker for me to push adoption of the language internally. If not, I can try to invest time into making one, but I could use help. (fyi, there's one in the works for Rust: https://github.com/rusoto/rusoto) I have some old code here: https://github.com/braddr/downloads.dlang.org/tree/master/src It has sig v2 signing and some s3 object related code. Super minimal and sig v2 is out of date (though still very usable, in most aws regions). Ideally, someone would partner with aws -- there's a developer tools forum -- to add D to the suite of languages. I'm fairly sure they code generate at least a large part of the tool kits from the api definitions for each of the tons of services. Trying to manage them all by hand is a loosing battle. I've been tempted to do this a couple times, but the time investment would likely be more than I'm willing to spend.
Re: Is dmd fast?
On Thursday, 23 June 2016 at 17:57:33 UTC, Andrei Alexandrescu wrote: On 06/23/2016 01:33 PM, David Nadlinger wrote: On Thursday, 23 June 2016 at 17:24:34 UTC, Andrei Alexandrescu wrote: On my Ubuntu, /usr/bin/ld -> x86_64-linux-gnu-ld. What does that mean? -- Andrei `ld --version` should clear that up. ;) GNU ld (GNU Binutils for Ubuntu) 2.26 So how do I get and install gold? Thanks, Andrei Martin covered it here: https://code.dawg.eu/reducing-vibed-turnaround-time-part-1-faster-linking.html
Re: Andrei's list of barriers to D adoption
On 6/7/2016 12:52 PM, Walter Bright via Digitalmars-d wrote: On 6/7/2016 11:32 AM, Timon Gehr wrote: The @safe subset should be specified and implemented by inclusion, such that it is obvious that it does the right thing. I don't know what's 'unspecific' about this. Closing holes one-by-one is not the right approach here. You don't know when you are done and might never be. I don't see how it is any different painting the fence from one direction or the other. There are omissions possible either way. Yes, either direction has the probability of being incomplete. However, when the disallow by default and allow only explicitly activities is _far_ more correct in the face of omissions. In the case of an omission of something that should be allowed, you haven't discovered a violation of safety, you've discovered a place to allow additional safe code. To use an analogy, would you trust a security model where the list of people not allowed to withdraw from your bank account be a whitelist or a blacklist? Another issue is implementing such a spec. The "disapproved" list is how the compiler works, and makes it reasonably straightforward to check the implementation against the list. It's quite a mess to try to tag everything the compiler does with approved/disapproved, so you wind up in exactly the same boat anyway. In any case, writing such a large specification covering every semantic action of the of the language is way, way beyond being a bugzilla issue. Yes, it's hard to implement. Shrug, you signed up for it.
Re: Andrei's list of barriers to D adoption
On 6/6/2016 11:22 PM, Walter Bright via Digitalmars-d wrote: On 6/6/2016 10:38 PM, Brad Roberts via Digitalmars-d wrote: The D ecosystem is a large pile of incomplete features, with more added all the time. Even with only array bounds checking, D is safer than C++. Nice deflection, has the benefit of being both correct and irrelevant. Yes, bounds checking is great. Yes, D is safer than C++, but we were talking about @safe as a specific, advertised, but low-priority and largely unrealized feature, not the general safety of the language. @safe is intended to be a big leap forward, but falls flat outside toys. I want the protections it's intended to bring. I want the notification I've accidentally violated one of the rules. I want the productivity gains from not having to debug cases it's intended to catch. This minimization and deflection of real user feedback is rather disappointing and somewhat insulting. Instead, I'd prefer to see acceptance that it's an actual issue and not hand waved away as not really a problem of current, real, users. Sigh, Brad
Re: Andrei's list of barriers to D adoption
On 6/6/2016 10:25 PM, Walter Bright via Digitalmars-d wrote: On 6/6/2016 5:19 PM, Brad Roberts via Digitalmars-d wrote: Safety as a usable subset of D is still pretty non-existent and yet is used as a selling point. The language still has holes -- I don't have bug report numbers, but others have reported them in the past, some closed some not. At the library level things are far worse. I've yet to be able to write any interesting apps with an @safe main. Without knowing any details of why your app wouldn't compile as @safe, there's nothing useful nor actionable in the complaint. There also is a conflation of two issues in the complaint - compiling programs that are unsafe despite being marked @safe, and the compiler complaining about unsafe code in code you'd like to be marked @safe. Which is it? For me, it's the latter, but the issues with the former make it hard to trust either all that much. I've fixed some of the issues in a couple bursts of activity over the last several years, and filed a bunch more bugs, but the specifics aren't the point I'm raising here, though your trimming of the thread dropped that part of the context. You dismissed complaints of the incompleteness of safety as the whining of non-users. I'm a user. I was a much more frequent user until I got tired of the sheer number of only partially complete nature of so much of the language + core library. Yes they're separate, no that's not relevant to the majority of users. Yes, I can and have contributed to the fixes, but it's clearly (just based on commit history) not a priority to many people. The D ecosystem is a large pile of incomplete features, with more added all the time.
Re: Andrei's list of barriers to D adoption
On 6/6/2016 2:16 AM, Walter Bright via Digitalmars-d wrote: On 6/6/2016 1:15 AM, Russel Winder via Digitalmars-d wrote: * Safety has holes and bugs. Then so does C, C++ and Rust, so this is just a comment made because it can be made and sounds bad. Bad enough to salve the conscience of the speaker as to why they are not already using D. It's pretty clear when they say that, and then continue using C++ which has no safety, that safety isn't the real reason. This isn't a small problem, don't dismiss it quite that quickly. Safety as a usable subset of D is still pretty non-existent and yet is used as a selling point. The language still has holes -- I don't have bug report numbers, but others have reported them in the past, some closed some not. At the library level things are far worse. I've yet to be able to write any interesting apps with an @safe main. Has anyone? Later, Brad
Re: The Case Against Autodecode
On Thursday, 2 June 2016 at 20:13:14 UTC, Andrei Alexandrescu wrote: On 06/02/2016 03:34 PM, tsbockman wrote: [...] They do work per spec: find this code point. It would be surprising if 'ö' were found but the string were positioned at a different code point. [...] Well there's gotta be a reason why my basic comprehension is under constant scrutiny whereas yours is safe. [...] Would be happy to. To whom would I delegate? Andrei If there were to be a unicode lieutenant, Dmitry seems to be the obvious choice (if he's interested).
Re: Free the DMD backend
On Tuesday, 31 May 2016 at 20:18:34 UTC, default0 wrote: I have no idea how licensing would work in that regard but considering that DMDs backend is actively maintained and may eventually even be ported to D, wouldn't it at some point differ enough from Symantecs "original" backend to simply call the DMD backend its own thing? Or are all the changes to the DMD backend simply changes to Symantecs backend period? Then again even if that'd legally be fine after some point, someone would have to make the judgement call and that seems like a potentially large legal risk, so I guess even if it'd work that way it would be an unrealistic step. Copyright law's answer to the Ship of Theseus paradox is that it's the same ship (i.e. derivative works are still covered under the original copyright).
Re: Dealing with Autodecode
On 5/31/2016 7:40 PM, Walter Bright via Digitalmars-d wrote: On 5/31/2016 7:28 PM, Jonathan M Davis via Digitalmars-d wrote: The other critical thing is to make sure that Phobos in general works with byDChar, byCodeUnit, etc. For instance, pretty much as soon as I started trying to use byCodeUnit instead of naked strings, I ran into this: https://issues.dlang.org/show_bug.cgi?id=15800 That was posted 3 months ago. No PR to fix it (though it likely is an easy fix). If we can't get these things fixed in Phobos, how can we tell everyone else to fix their code? I hope that wasn't a serious question. The answer is trivial. The rate of incoming bug reports exceeds the rate of bug fixing which exceeds the rate of fix pulling. Has since about the dawn of time.
Re: year to date pull statistics (week ending 2016-05-28)
total open: 284 created since 2016-01-01 and still open: 142 created closed delta 2016-05-29 - today 25 25 0 2016-05-22 - 2016-05-28 46 34-12 2016-05-15 - 2016-05-21 40 36 -4 2016-05-08 - 2016-05-14 82 55-27 2016-05-01 - 2016-05-07 37 59+22 2016-04-24 - 2016-04-30 74 85+11 2016-04-17 - 2016-04-23 51 58 +7 2016-04-10 - 2016-04-16 52 58 +6 2016-04-03 - 2016-04-09 64 44-20 2016-03-27 - 2016-04-02 65 60 -5 2016-03-20 - 2016-03-26 65 62 -3 2016-03-13 - 2016-03-19 44 51 +7 2016-03-06 - 2016-03-12 41 46 +5 2016-02-28 - 2016-03-05 54 47 -7 2016-02-21 - 2016-02-27 29 20 -9 2016-02-14 - 2016-02-20 32 36 +4 2016-02-07 - 2016-02-13 52 52 0 2016-01-31 - 2016-02-06 54 61 +7 2016-01-24 - 2016-01-30 40 37 -3 2016-01-17 - 2016-01-23 31 21-10 2016-01-10 - 2016-01-16 39 42 +3 2016-01-03 - 2016-01-09 26 33 +7 2016-01-01 - 2016-01-02 2 5 +3 --- ------ 10451027-18 https://auto-tester.puremagic.com/chart.ghtml?projectid=1
Re: Transient ranges
On 5/28/2016 10:27 AM, Joseph Rushton Wakeling via Digitalmars-d wrote: On Saturday, 28 May 2016 at 01:48:08 UTC, Jonathan M Davis wrote: On Friday, May 27, 2016 23:42:24 Seb via Digitalmars-d wrote: So what about the convention to explicitely declare a `.transient` enum member on a range, if the front element value can change? Honestly, I don't think that supporting transient ranges is worth it. I have personally wondered if there was a case for a TransientRange concept where the only primitives defined are `empty` and `front`. `popFront()` is not defined because the whole point is that every single call to `front` will produce a different value. Um. that's wrong, just look at byLine as evidence. It is popFront that changes the value to the 'next' one in the iteration. Front called twice in a row does NOT change the value, and shouldn't. I think you're misunderstanding something.
Re: [RFC] List of contributors per module
I enjoy a good ego stroking, but there are enough issues with the docs being cluttered and harder to digest than necessary already. I'm not a big fan of adding more clutter. On 5/24/16 12:22 PM, Seb via Digitalmars-d wrote: Hei, I recently made a PR to dlang.org which is aimed to show a list of all contributors to a Phobos module based on the git history. The idea is to give all the awesome people who have helped and contributed their earned credit! https://github.com/dlang/dlang.org/pull/1307 A couple of questions from this PR are still open though: 1) How can we best integrate this with the author section? - Should we move this into the header? - Maybe a module could also have a current maintainer(s) (that is in charge of approving changes) 2) Should we show the avatars? They are loaded lazily, so they don't block the page load. If neccessary out of privacy concerns, contribs.dlang.io could act as a proxy. 3) I would prefer to generate this information on deploy-time, but rolling a small (vibe.d) service was a lot easier than integrating this properly in the current Makefile. Maybe once we migrate to ddox this would be easier?
Re: Wiki hacked?
On Monday, 16 May 2016 at 16:27:51 UTC, Luís Marques wrote: Was the wiki hacked or something? I'm getting a certificate error, and the content is just this: [snip] Works fine for me (both http and https).
Re: year to date pull statistics (week ending 2016-05-07)
total open: 252 created since 2016-01-01 and still open: 106 created closed delta 2016-05-08 - today 46 35-11 2016-05-01 - 2016-05-07 37 59+22 2016-04-24 - 2016-04-30 74 85+11 2016-04-17 - 2016-04-23 51 58 +7 2016-04-10 - 2016-04-16 52 58 +6 2016-04-03 - 2016-04-09 64 44-20 2016-03-27 - 2016-04-02 65 60 -5 2016-03-20 - 2016-03-26 65 62 -3 2016-03-13 - 2016-03-19 44 51 +7 2016-03-06 - 2016-03-12 41 46 +5 2016-02-28 - 2016-03-05 54 47 -7 2016-02-21 - 2016-02-27 29 20 -9 2016-02-14 - 2016-02-20 32 36 +4 2016-02-07 - 2016-02-13 52 52 0 2016-01-31 - 2016-02-06 54 61 +7 2016-01-24 - 2016-01-30 40 37 -3 2016-01-17 - 2016-01-23 31 21-10 2016-01-10 - 2016-01-16 39 42 +3 2016-01-03 - 2016-01-09 26 33 +7 2016-01-01 - 2016-01-02 2 5 +3 --- ------ 898 912 14 https://auto-tester.puremagic.com/chart.ghtml?projectid=1
Re: year to date pull statistics (week ending 2016-04-30)
total open: 265 created since 2016-01-01 and still open: 110 created closed delta 2016-05-01 - today 16 14 -2 2016-04-24 - 2016-04-30 74 85+11 2016-04-17 - 2016-04-23 51 58 +7 2016-04-10 - 2016-04-16 52 58 +6 2016-04-03 - 2016-04-09 64 44-20 2016-03-27 - 2016-04-02 65 60 -5 2016-03-20 - 2016-03-26 65 62 -3 2016-03-13 - 2016-03-19 44 51 +7 2016-03-06 - 2016-03-12 41 46 +5 2016-02-28 - 2016-03-05 54 47 -7 2016-02-21 - 2016-02-27 29 20 -9 2016-02-14 - 2016-02-20 32 36 +4 2016-02-07 - 2016-02-13 52 52 0 2016-01-31 - 2016-02-06 54 61 +7 2016-01-24 - 2016-01-30 40 37 -3 2016-01-17 - 2016-01-23 31 21-10 2016-01-10 - 2016-01-16 39 42 +3 2016-01-03 - 2016-01-09 26 33 +7 2016-01-01 - 2016-01-02 2 5 +3 --- ------ 831 832 1 https://auto-tester.puremagic.com/chart.ghtml?projectid=1
Re: Slides bevorehand
On Monday, 2 May 2016 at 15:59:27 UTC, Benjamin Thaut wrote: Hi, I'm wondering if it would be a good idea to put up my slides before the talk. And when. On the day of the talk? Today? Tomorrow (Start of the Conference)? I assume if you wanted to do this you would simply do a PR to the dconf.org site on GitHub? Kind Regards Benjamin Thaut It could be nice to have them available in case the livestream doesn't show them very well (bad angle or blown out projection).
Re: year to date pull statistics
The astute observer might notice that the past results aren't 100% constant (and that I skipped a week): 1) I had a sign flip issue for april in the delta column. That column is: closed - created. 2) some past weeks have slightly different closed counts than previous emails. That can occur when a pull is reopened and then closed. The pull will be removed from the past week and reappear in the newer week. total open: 273 created since 2016-01-01 and still open: 114 created closed delta 2016-04-24 - today 16 17 +1 2016-04-17 - 2016-04-23 51 58 +7 2016-04-10 - 2016-04-16 52 58 +6 2016-04-03 - 2016-04-09 64 44-20 2016-03-27 - 2016-04-02 65 60 -5 2016-03-20 - 2016-03-26 65 62 -3 2016-03-13 - 2016-03-19 44 51 +7 2016-03-06 - 2016-03-12 41 46 +5 2016-02-28 - 2016-03-05 54 47 -7 2016-02-21 - 2016-02-27 29 20 -9 2016-02-14 - 2016-02-20 32 36 +4 2016-02-07 - 2016-02-13 52 52 0 2016-01-31 - 2016-02-06 54 61 +7 2016-01-24 - 2016-01-30 40 37 -3 2016-01-17 - 2016-01-23 31 21-10 2016-01-10 - 2016-01-16 39 42 +3 2016-01-03 - 2016-01-09 26 33 +7 2016-01-01 - 2016-01-02 2 5 +3 --- ------ 757 750 -7 https://auto-tester.puremagic.com/chart.ghtml?projectid=1
Re: So, to print or not to print?
Something that's been bouncing around in the back of my head for a while. I can't decide if it's a good idea or a really bad one. Consider a series of small modules that are essentially language mappers. Something like: std.adapt.ruby std.adapt.python std.adapt.mumble Each could contain little functions that map between idioms and names from the various languages to the d native version. There's no way that we can or should have all those sorts of little helpers in the core library, but that doesn't mean that they shouldn't exist or wouldn't be useful. On 4/25/16 12:35 PM, Andrei Alexandrescu via Digitalmars-d wrote: https://github.com/dlang/phobos/pull/3971 Walter and I were talking this morning that there should be a high barrier of entry for one-liners in Phobos. The "print" function is technically a one-liner (i.e. writefln with the appropriate format string). On the other hand, it may be convivial enough to warrant inclusion, and saves us from embarrassing things such as producing meaningless output when numbers are printed together. There's been a bit of churn in the PR comments regarding the utility of "print", and discussion diverged into other functions such as "dump" etc. Keeping it on topic: any strong cons and pros regarding the function? I want to either merge or close the PR and move on. Thanks, Andrei
Re: On the origins of github.com/D-Programming-Language
On 4/15/16 5:06 PM, Vladimir Panteleev via Digitalmars-d wrote: On Friday, 15 April 2016 at 06:11:22 UTC, Vladimir Panteleev wrote: Assuming no objections, I'll do the move tomorrow, around 2016-04-16 00:00 UTC. Done. Speak up if anything seems broken or wrong. I've updated the auto-tester to point directly at the new organization. About the only thing I haven't seen go through yet is a merge. But testing seems to be going just fine.
Re: Dead link finding automation
On 4/15/16 5:38 PM, Vladimir Panteleev via Digitalmars-d wrote: On Friday, 15 April 2016 at 18:25:58 UTC, Andrei Alexandrescu wrote: Can we automate stuff like https://issues.dlang.org/show_bug.cgi?id=15929? There are quite a few tools around, not to mention we could easily roll our own. Who'd like to take this project? Thx! -- Andrei It's something I've been thinking about for a while. This particular case is a DDox deficiency. The macros we use in our documentation are not meant for the URL structure that DDox uses. This incompatibility creates broken links. People have stepped up with PRs to replace them with better macros, which will work in DDox as well, so it's an area of active improvement. chmgen reports broken internal links (for stuff that goes into the CHM, which is based on the DDoc Phobos documentation format, thus it wouldn't find the above broken DDox link). I've been planning into integrating it into the documentation tester, so that new broken internal links result in a test failure. External links are a different issue. They can't be tested in the autotester (at least not fail the build), otherwise a site we link to going (temporarily) down means our master is broken. They would need special treatment, e.g. report them as some form of warnings but don't fail them. You don't want the link checker checking external links directly anyway, that'd be a nice way to use the tester as an attack vector. Instead, you could have the tester accumulate a set of external links and check them separately maybe once a day or whatever. It'd also be a good way to detect new external links and give reviewers a chance to make sure it's a site we want to rely on being available enough.
Re: On the origins of github.com/D-Programming-Language
On 4/14/16 5:34 PM, Vladimir Panteleev via Digitalmars-d wrote: On Friday, 15 April 2016 at 00:32:38 UTC, Andrei Alexandrescu wrote: On 04/14/2016 06:07 PM, Walter Bright wrote: Nice work getting that! I prefer dlang to d-lang. Same here. It's a done deal - let's move to dlang. Thanks to the donor and Seb who made that happen. Vladimir, would you want to be in charge with the moving process? You choose the tactics, basically please try to make it as painless as possible. Sure. You'll have to hand me the keys to the empire (organization) first though :) I'll do some tests to make sure all will go as expected. Don't worry about the auto-tester. Ideally it'll just work, and if it doesn't, it'll be trivial to fix the db to point to the new organization names.
Re: year to date pull statistics (week ending 2016-04-09)
total open: 270 created since 2016-01-01 and still open: 100 created closed delta 2016-04-10 - today 9 10 -1 2016-04-03 - 2016-04-09 64 45+19 2016-03-27 - 2016-04-02 65 60 +5 2016-03-20 - 2016-03-26 65 63 +2 2016-03-13 - 2016-03-19 44 51 -7 2016-03-06 - 2016-03-12 41 46 +5 2016-02-28 - 2016-03-05 54 48 -6 2016-02-21 - 2016-02-27 29 20 -9 2016-02-14 - 2016-02-20 32 36 +4 2016-02-07 - 2016-02-13 52 52 0 2016-01-31 - 2016-02-06 54 61 +7 2016-01-24 - 2016-01-30 40 37 -3 2016-01-17 - 2016-01-23 31 21-10 2016-01-10 - 2016-01-16 39 42 +3 2016-01-03 - 2016-01-09 26 33 +7 2016-01-01 - 2016-01-02 2 5 +3 --- ------ 647 630+17 https://auto-tester.puremagic.com/chart.ghtml?projectid=1
Re: On the origins of github.com/D-Programming-Language
On Saturday, 9 April 2016 at 00:04:35 UTC, Brad Anderson wrote: On Friday, 8 April 2016 at 23:49:35 UTC, Seb wrote: Hei, I just wanted to ask a short question - why did you pick such a long github namespace? Having something short is easier to remember, shorter to type, better visible and often recognized as more important (that's how our brains work). Another good example is that since github started to include the user/organization name in the header of issue /PR mails the title is barely readable. The name was chosen before Oscar Brynolf kindly offered up the domain name dlang.org. The lang idiom for languages was only just starting to become common back then. By "back then" I mean in 2011[1]. The original domain was d-programming-language.org and having the github organization match made sense. http://forum.dlang.org/post/jc0asl$sms$1...@digitalmars.com
Re: On the origins of github.com/D-Programming-Language
On Friday, 8 April 2016 at 23:49:35 UTC, Seb wrote: Hei, I just wanted to ask a short question - why did you pick such a long github namespace? Having something short is easier to remember, shorter to type, better visible and often recognized as more important (that's how our brains work). Another good example is that since github started to include the user/organization name in the header of issue /PR mails the title is barely readable. The name was chosen before Oscar Brynolf kindly offered up the domain name dlang.org. The lang idiom for languages was only just starting to become common back then.
Re: year to date pull statistics (week ending 2016-04-02)
total open: 270 created since 2016-01-01 and still open: 100 created closed delta 2016-04-03 - today 15 10 +5 2016-03-27 - 2016-04-02 65 60 +5 2016-03-20 - 2016-03-26 65 63 +2 2016-03-13 - 2016-03-19 44 51 -7 2016-03-06 - 2016-03-12 41 46 +5 2016-02-28 - 2016-03-05 54 48 -6 2016-02-21 - 2016-02-27 29 20 -9 2016-02-14 - 2016-02-20 32 36 +4 2016-02-07 - 2016-02-13 52 52 0 2016-01-31 - 2016-02-06 54 61 +7 2016-01-24 - 2016-01-30 40 37 -3 2016-01-17 - 2016-01-23 31 21-10 2016-01-10 - 2016-01-16 39 42 +3 2016-01-03 - 2016-01-09 26 33 +7 2016-01-01 - 2016-01-02 2 5 +3 --- ------ 589 585 +4 https://auto-tester.puremagic.com/chart.ghtml?projectid=1
Re: year to date pull statistics (week ending 2016-03-26)
total open: 264 created since 2016-01-01 and still open: 93 created closed delta 2016-03-27 - today 20 16 +4 2016-03-20 - 2016-03-26 65 63 +2 2016-03-13 - 2016-03-19 44 51 -7 2016-03-06 - 2016-03-12 41 46 +5 2016-02-28 - 2016-03-05 54 48 -6 2016-02-21 - 2016-02-27 29 20 -9 2016-02-14 - 2016-02-20 32 36 +4 2016-02-07 - 2016-02-13 52 52 0 2016-01-31 - 2016-02-06 54 61 +7 2016-01-24 - 2016-01-30 40 37 -3 2016-01-17 - 2016-01-23 31 21-10 2016-01-10 - 2016-01-16 39 42 +3 2016-01-03 - 2016-01-09 26 33 +7 2016-01-01 - 2016-01-02 2 5 +3 --- ------ 529 531 -2 https://auto-tester.puremagic.com/chart.ghtml?projectid=1
Re: Improve reability of GC on win64
On Thursday, 24 March 2016 at 18:58:56 UTC, Adam Wilson wrote: [snip] Interestingly enough, there is a GSoC candidate this year that is proposing a project that would make the D GC precise. There was already a GSOC project to make the GC precise by Antti-Ville Tuuainen back in 2012. Rainer expanded upon it[1] and gave a talk about it at DConf 2013[2]. I'm not sure why it never went anywhere. In any case, I don't think a precise GC is a good GSOC project since most of the work has already been done. I feel like a GC focused GSOC project should be more ambitious than merely tying up the loose ends of the existing precise GC work. 1. https://github.com/rainers/druntime/tree/gcx_precise 2. http://dconf.org/2013/talks/schuetze.pdf
Re: year to date pull statistics
Another week, so another update to the pull statistics for the D-P-L dmd, runtime, and phobos repositories. There's been a bit of progress chipping away at the queue, though there's still a long way to go. The number of open phobos pulls has grown quite a bit over the last few weeks and months, currently 92. I don't have the details readily available, but wasn't there a point in the last year where phobos was down to something like 20 open pull requests? total open: 260 created since 2016-01-01 and still open: 85 created closed delta 2016-03-20 - today 21 19 +2 2016-03-13 - 2016-03-19 44 51 -7 2016-03-06 - 2016-03-12 41 46 +5 2016-02-28 - 2016-03-05 54 48 -6 2016-02-21 - 2016-02-27 29 20 -9 2016-02-14 - 2016-02-20 32 36 +4 2016-02-07 - 2016-02-13 52 52 0 2016-01-31 - 2016-02-06 54 61 +7 2016-01-24 - 2016-01-30 40 37 -3 2016-01-17 - 2016-01-23 31 21-10 2016-01-10 - 2016-01-16 39 42 +3 2016-01-03 - 2016-01-09 26 33 +7 2016-01-01 - 2016-01-02 2 5 +3 --- ------ 465 471 -6 Oldest open pull for each repository: dmd: 2012-09-27 https://github.com/D-Programming-Language/dmd/pull/1145 Add -versions option to list predefined version identifiers. druntime: 2014-02-14 https://github.com/D-Programming-Language/druntime/pull/724 assumeLocal: convert shared lvalue to a non-shared one phobos: 2014-03-14 https://github.com/D-Programming-Language/phobos/pull/2011 fix Issue 12368 - std.file.write conflicts with std.stdio.write Later, Brad
Re: year to date pull statistics
Updating last week's email, the pull statistics for the D-P-L dmd, runtime, and phobos repositories: total open: 263 created since 2016-01-01 and still open: 82 created closed delta 2016-03-13 - today 8 10 +2 2016-03-06 - 2016-13-12 41 46 +5 2016-02-28 - 2016-03-05 54 48 -6 2016-02-21 - 2016-02-27 29 20 -9 2016-02-14 - 2016-02-20 32 36 +4 2016-02-07 - 2016-02-13 52 52 0 2016-01-31 - 2016-02-06 54 61 +7 2016-01-24 - 2016-01-30 40 37 -3 2016-01-17 - 2016-01-23 31 21-10 2016-01-10 - 2016-01-16 39 42 +3 2016-01-03 - 2016-01-09 26 33 +7 2016-01-01 - 2016-01-02 2 5 +3 --- ------ 408 411 -3 Oldest open pull request: https://github.com/D-Programming-Language/dmd/pull/692
Re: TypeInfo madness
On 3/8/16 1:38 PM, Andrei Alexandrescu via Digitalmars-d wrote: On 3/7/16 1:33 PM, Yuxuan Shui wrote: On Monday, 7 March 2016 at 08:49:36 UTC, Johan Engelen wrote: On Monday, 7 March 2016 at 01:47:53 UTC, Yuxuan Shui wrote: On Sunday, 6 March 2016 at 23:27:45 UTC, Adam D. Ruppe wrote: It is just a mistake that TypeInfo isn't immutable, in my opinion. ...though changing it would be a breaking change, I think it would make sense to do it. Is there really anything relies on TypeInfo being mutable? LDC produces a crashing program when you change TypeInfo.name: https://github.com/ldc-developers/ldc/issues/1337 This is because LDC put the TypeInfo struct in .rodata! Which is great. Further prove the point that no one is modifying TypeInfo. Great evidence. Guess we should make everything immutable then. -- Andrei The fun part is going to be all the ripple effect changes required to api's to pass them around as const. Those result in mangling changes and thus is a reasonably massive amount of low level ABI churn.
year to date pull statistics
A topic that rolls around periodically is the number of open pulls and or the frequency at which a pull is 'ignored' (no, it's not ignored, it's just lost in the noise). I've dug up some rate of change statistics for the year to date for pulls to the D-P-L master branches of the dmd, druntime, and phobos repositories: created closed delta 2016-03-06 - today 12 10 -2 2016-02-28 - 2016-03-05 54 48 -6 2016-02-21 - 2016-02-27 29 20 -9 2016-02-14 - 2016-02-20 32 36 +4 2016-02-07 - 2016-02-13 52 52 0 2016-01-31 - 2016-02-06 54 61 +7 2016-01-24 - 2016-01-30 40 37 -3 2016-01-17 - 2016-01-23 31 21-10 2016-01-10 - 2016-01-16 39 42 +3 2016-01-03 - 2016-01-09 26 33 +7 2016-01-01 - 2016-01-02 2 5 +3 --- ------ 371 365 -6 Not bad at all; lots of activity going on pretty much constantly. The problem is that there's so much traffic with such a large backlog: total open: 272 created since 2016-01-01 and still open: 86 that unless something brings a pull request to the top of the queue then it's visibility is shot. A great illustration of that effect is in the age (in number of days) histogram of closed pulls for all pulls created since 2016-01-01: +--+--+ | age | count(*) | acc% of closed +--+--+ |0 | 120 | 42% |1 | 64 | 65% |2 | 25 | 73% |3 | 12 | 78% |4 |5 | 79% |5 |5 | 81% |6 |6 | 83% |7 |6 | 85% |8 |5 | 87% |9 |5 | 89% | 10 |2 | 89% | 11 |2 | 90% | 12 |4 | | 13 |1 | | 14 |2 | | 15 |1 | | 16 |1 | | 17 |1 | | 18 |1 | | 20 |1 | | 21 |1 | | 22 |1 | | 23 |3 | | 24 |1 | | 26 |1 | | 28 |1 | | 29 |1 | | 37 |1 | | 39 |1 | | 41 |2 | | 42 |1 | | 46 |1 | | 47 |1 | +--+--+ sum: 285 So, I guess one point that comes from this data, and is already anecdotally well known, if you have a pull request that you believe is ready to be merged and nothing has progressed in a couple days or maybe a week, please ping the PR. Chances are good that it has simply fallen off the active radar. To see a live view of the above data: https://auto-tester.puremagic.com/chart.ghtml?projectid=1 The top graph is a histogram of the current number of open pull requests in monthly sized buckets. The next two are the same data as the first chart above broken down by week for the last year. The last two are similar but looking at the issue data rather than the pull data. Later, Brad
Re: Waste of computing resources in pull requests that only change the ddoc
It wouldn't be very difficult to add an "ignore me please" sort of flag on pull requests, but ignoring the ddoc only change subset of pulls would only have a minor overall impact on tester coverage. By _far_, the bigger issue is the number of open pull requests as a whole. There's currently 270 open pull requests between the three repositories (dmd, druntime, and phobos). By design, the tester re-tests every open pull request in most recently updated order after every merge. If you want to help the D project, the best way to do so right now, imho, is code reviews and getting pulls merged or closed. On 3/4/2016 1:03 AM, BBasile via Digitalmars-d wrote: I don't know If it's a known problem but auto tester resources are lost by PR that only change or add DDOC comments. For example whole dmd+runtime+phobos can be rebuild 3 times per day on 8 machines while it's not necessary. I understand that's a side-effect of the doc being directly in the code, but... Wouldn't be possible to run a background tool, based on libdparse, that - detects changed lines in the diff. - run the libdparse-based tool to see if changed lines are only in the ddoc. Depending on the results, either only CyberShadow's doc builder would run or also the big auto-tester.
Re: A very interesting slide deck comparing sync and async IO
On Thursday, 3 March 2016 at 17:31:59 UTC, Andrei Alexandrescu wrote: https://www.mailinator.com/tymaPaulMultithreaded.pdf Andrei Related to this, I watched a talk about user-level threads by another Google engineer awhile back (also named Paul but not the same person). https://www.youtube.com/watch?v=KXuZi9aeGTw It's been awhile so I may have this a bit wrong but as I remember it the gist was that OSes don't have enough information for efficient scheduling and context switching of threads but if the OS lets the application handle it the context switching cost drops significantly (down to roughly 200ns). I came across it while following some Rust development which was a very interesting read: https://mail.mozilla.org/pipermail/rust-dev/2013-November/006550.html It's a bit over two years old now so I'm not sure what path Rust took.
Re: A suggestion for dub
On Monday, 29 February 2016 at 05:59:56 UTC, mahdi wrote: On Monday, 29 February 2016 at 05:16:50 UTC, Brad Anderson wrote: On Monday, 29 February 2016 at 04:46:13 UTC, mahdi wrote: [...] A neat feature would be to deploy it using the github releases feature. There is an API for it: https://developer.github.com/v3/repos/releases/ Being able to upload program binaries for end users (non-programmers) to use would be killer. But definitely those binaries won't be cross-platform! That's why I think uploading/downloading source code is more robust. You can upload multiple platform binaries. I'm pretty sure LDC or GDC can do some cross compiling too. It's not reasonable to expect all end users to compile a program.
Re: A suggestion for dub
On Monday, 29 February 2016 at 04:46:13 UTC, mahdi wrote: I just want to get some feedback to see if this is a good idea or no. I propose adding a new command to dub (`dub dist` or `dub package`) which will produce a zipped version of the current package. This zip file can be uploaded to a central repository (code.dlang.com maybe), and others can use this package in their `dub.json` file by adding relevant dependency (Behind the scene, dub will fetch and decompress the package). A neat feature would be to deploy it using the github releases feature. There is an API for it: https://developer.github.com/v3/repos/releases/ Being able to upload program binaries for end users (non-programmers) to use would be killer.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 20:49:02 UTC, Bubbasaur wrote: On Wednesday, 10 February 2016 at 16:26:33 UTC, Gary Willoughby wrote: Can I get more opinions on increasing the logo size on the website please. See here for an example: https://github.com/D-Programming-Language/dlang.org/pull/1227 Destroy! I'd prefer this version but smaller. The current one with black borders is ugly for the new layout. Bubba. https://dlang.org :P (the forums just haven't updated yet)
Re: Dwarf Exception Handling now on FreeBSD!
On 2/4/2016 1:27 AM, Jacob Carlborg via Digitalmars-d wrote: On 2016-02-03 21:18, Brad Roberts via Digitalmars-d wrote: I haven't put much time into investigation, but the last time I tried it, neither 9 nor 10 passed the test suite. If someone puts in the effort to get either or both of those working, I'd be happy to upgrade some of the freebsd testers to newer versions. There's currently 4 freebsd machines, so plenty of room to have a mix of versions. Not enough to test every combination of version and bitness, but enough to allow randomness to expose issues. Perhaps it's worth taking a look at Docker. As far as I understand there's experimental support for FreeBSD [1]. It uses ZFS, jail and the 64bit Linux compatibility layer. Seems to be possible to run both Linux and FreeBSD images in Docker for FreeBSD. Although I'm not sure if it's possible to mix 32bit and 64bit with Docker. [1] https://wiki.freebsd.org/Docker It's not about mechanism, it's about compute hours in the day. Yes, making each machine a little more flexible would be useful for leveling out the progress across platforms, but there just isn't enough hardware in my fleet for adding a bunch more configurations to the matrix.
Re: Dwarf Exception Handling now on FreeBSD!
On 2/3/16 11:28 AM, Jonathan M Davis via Digitalmars-d wrote: On Sunday, 31 January 2016 at 06:34:26 UTC, Walter Bright wrote: 32/64 support now on Linux and FreeBSD. https://github.com/D-Programming-Language/dmd/pull/5376 Turns out that FreeBSD is close enough to Linux that it "just worked". It's always nice when that happens, especially when there's not much FreeBSD-specific work going on, and the autotesters have generally been on older versions of FreeBSD such that issues on the newer versions don't always get noticed (e.g. for a while there, the shared library stuff passed the tests on FreeBSD 8 but not later; fortunately Martin got that fixed though). - Jonathan M Davis I haven't put much time into investigation, but the last time I tried it, neither 9 nor 10 passed the test suite. If someone puts in the effort to get either or both of those working, I'd be happy to upgrade some of the freebsd testers to newer versions. There's currently 4 freebsd machines, so plenty of room to have a mix of versions. Not enough to test every combination of version and bitness, but enough to allow randomness to expose issues.
Re: reduce -> fold?
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote: As has been discussed before there's been discussion about std.algorithm.reduce taking the "wrong" order of arguments (its definition predates UFCS). I recall the conclusion was there'd be subtle ambiguities if we worked reduce to implement both orders. So the next best solution is to introduce a new name such as the popular "fold", and put them together in the documentation. Thoughts? Andrei +1 Let's make sure to write the half dozen other names for it in the documentation so people coming to D from other languages can easily find it. And just for completeness, here is monarchdodra's valiant but ultimately unsuccessful pull request which attempted fix reduce: https://github.com/D-Programming-Language/phobos/pull/861#issuecomment-20760448
Re: D vs Rust
On Thursday, 28 January 2016 at 23:28:04 UTC, tsbockman wrote: On Thursday, 28 January 2016 at 23:18:34 UTC, Ola Foaheim Grøstad wrote: D depends on two people I disagree with this. Even if Walter Bright and Andrei Alexandrescu both suddenly decided to go join the Amish tomorrow, D would go on. Just because D development is currently *controlled* by two people doesn't mean that no one else is willing or able to replace them, if the need/opportunity arose. Yeah, a few years ago D definitely had a Bus Factor of one but Walter (and Andrei) have successfully delegated and opened it up enough that if the worst should happen I think D could still move forward.
Re: What are the real advantages that D offers in multithreading?
On Thursday, 28 January 2016 at 17:21:21 UTC, Chris Wright wrote: On Wed, 27 Jan 2016 17:30:28 +, Brad Anderson wrote: Yeah, boost can do fibers. ASIO has clever/hacky "stackless coroutines" and C++17 is going to add "stackless resumable functions" for async/await. D is about to lose a competitive advantage here. I looked at those stackless coroutines. They're nowhere near good enough for what I wanted to do. You can't use them for a vibe-like framework. But they're still called coroutines, so D's going to lose a marketing advantage. They aren't fit for every task, of course. They've been discussed here on the NG in the past: http://forum.dlang.org/thread/izosaywbnlxnbzyhj...@forum.dlang.org
