Re: The New DIP Process
On 2/28/2024 7:34 PM, Jonathan M Davis via Digitalmars-d-announce wrote: On Wednesday, February 28, 2024 7:18:29 PM MST Mike Parker via Digitalmars-d- announce wrote: On Wednesday, 28 February 2024 at 19:24:32 UTC, Jonathan M Davis wrote: I see that they're up on the NNTP server, and the web forum is hooked up to them, but there is no mailing list. Is that forthcoming and just isn't up yet since that takes some time, or are these lists not going to have mailing lists like the others? They had to be up on NNTP for them to be added to the forums. I just didn't think about the mailing list. I'll contact Brad. Thanks. - Jonathan M Davis I set them up earlier today. It's entirely possible I missed something while configuring them as it's been just over 6 years since the last new group was added, so do shout if anything looks off. I see that the first two messages already posted made it through, so my confidence is reasonably high. Also worth noting, the news group names are NOT dip.idea and dip.development. They're actually digitalmars.dip.ideas (note the plural) and digitalmars.dip.development. I made the list names just dip.ideas@ and dip.development@ for brevity. Later, Brad
Re: GitHub could be acquired by Microsoft
On 6/8/2018 2:34 PM, Walter Bright via Digitalmars-d-announce wrote: On 6/7/2018 10:01 PM, H. S. Teoh wrote: And that is why it's a bad thing to build a walled garden around a code repo, esp. when the underlying VCS is well capable of distributed development. If only there has been a standard protocol for communicating such associated content, such as PR comments and discussions, bugs and issues (this latter not applicable in our case, thankfully), then we could have setup an archival system to retrieve and store all of this information. Unfortunately, AFAIK there isn't a way to do this, and so if Github for whatever reason shuts down, all of this valuable information would be lost forever. Since I have (most) of the Github discussions in email form, I could do something like this if we had to: https://digitalmars.com/d/archives/digitalmars/D/index.html There's a program that runs over the NNTP database to generate the static pages: https://github.com/DigitalMars/ngArchiver Essentially (if not actually) everything on github is available through their api's. No need for scraping or other heroics to gather it.
Re: list server maintenance
On Sat, 16 Sep 2017, Brad Roberts via Digitalmars-d-announce wrote: The server that hosts the d email/newsgroup gateway is migrating to new hardware today, so there's going to be some down time (rough estimate, a couple hours). This includes bugzilla emails as well. Ok, took a lot longer than I anticipated, and we're still finding things that aren't working quite right, but mail is flowing again. Please report problems you experience to me. Thanks, Brad
list server maintenance
The server that hosts the d email/newsgroup gateway is migrating to new hardware today, so there's going to be some down time (rough estimate, a couple hours). This includes bugzilla emails as well.
Re: Release D 2.075.0
On 7/24/2017 10:35 PM, Dmitry Olshansky via Digitalmars-d-announce wrote: On Saturday, 22 July 2017 at 21:22:00 UTC, Walter Bright wrote: On 7/22/2017 2:04 AM, Martin Nowak It'll be converted anyway. :-) Putting the entire set in D (C compiler, C++ compiler, C preprocessor, htod converter, optimizer, code generator) makes the whole thing much more tractable, and who knows what we will be able to do with it! Does that mean that DMC++ will hit Github? I'm also interested in open-sourced version of snn library, of course. It did that a long time ago, but as a private repository. I suspect it won't stay private forever though.
Re: Work on ARM backend for DMD started
On 7/3/2017 11:50 PM, Iain Buclaw via Digitalmars-d-announce wrote: On Monday, 3 July 2017 at 23:16:07 UTC, solidstate1991 wrote: While I currently don't have an ARM based hardware that would be easy to develop on, I'm planning to use QEMU to emulate some form of ARMv6 CPU, as it'll be the main target, as it's still being used in devices like the Raspberry Pi. ARMv5 is being considered if it doesn't need a lot of work, although I don't see a lot of reason behind doing it besides of the possibility of enabling the development of homebrew GBA, NDS, GP32, etc stuff. As I became unemployed recently, I have a lot more time for development, so time now isn't an issue. Or at least until I find a job, which is hard due to my state as a college student, which I'm on the verge of losing it. I would accept your input on various things, like if I should do some adjustments to the in-line assembly stuff, whether I should care about thumb (reduced size instruction set, not available on some newer targets) or not, etc. Got my hands on some official reference manual, it wouldn't hurt if I could research other ones too. I'm aware that this is a topic that's occasionally brought up, but as someone is proposing to go from idea to implementation. It seems like a good time to point out. Someone did this 5 years ago as part of splitting the backend into interfaces - or at least as a working concept that the new interfaces actually allowed you to implement a new target. Maybe you should use their work as a starting or reference point. You'd probably save yourself most the trouble of working out how things connect. Iain. Unless someone else toyed with it also, it was me. There's a branch called 'arm' in my fork of dmd that has a lot of groundwork. I'm sure it's somewhat bitrotten in the few years since I last looked at it. I got as far as being able to emit some _extremely_ basic functions (like calls to libc -- printf worked) and link. I wrote the asm code -- as an exercise to force being able to encode much of the arm instruction set (if I remember right, pretty much everything except the neon vector instructions, and maybe even part of that set) in code structs. But I didn't get to writing the arm version of almost any cd* functions to translate the ir into actual code objects. Honestly, it's a pretty bad proposition. I did what I did as much to learn about the arm instruction set as to get an arm dmd backend. It did teach me a lot and I don't consider it entirely wasted time, but if the aim is to do anything beyond learning, I'd urge looking for a different project. Just getting code of really bad quality emitted will be a lot of work (on top of all the parts I did). Getting mediocre code will be another large amount of work. Getting code close to ldc or gdc is unlikely to ever happen. So, look closely at your motivations and available time.
Re: Vision document for H2 2016
On 7/7/16 12:55 PM, Andrei Alexandrescu via Digitalmars-d-announce wrote: https://wiki.dlang.org/Vision/2016H2 -- Andrei In the release management section, I'd like to see some priority placed on regressions. There was a time that releases were held until those where addressed. It was only a couple releases, but the list did get down to just 1 that was deemed not blocking (I don't remember the details).
Re: 4x faster strlen with 4 char sentinel
On 6/26/2016 11:47 AM, Jay Norwood via Digitalmars-d-announce wrote: On Sunday, 26 June 2016 at 16:59:54 UTC, David Nadlinger wrote: Please keep general discussions like this off the announce list, which would e.g. be suitable for announcing a fleshed out collection of high-performance string handling routines. A couple of quick hints: - This is not a correct implementation of strlen, as it already assumes that the array is terminated by four zero bytes. That iterating memory with a stride of 4 instead of 1 will be faster is a self-evident truth. - You should be benchmarking against a "proper" SIMD-optimised strlen implementation. — David This is more of just an observation that the choice of the single zero sentinel for C string termination comes at a cost of 4x strlen speed vs using four terminating zeros. I don't see a SIMD strlen implementation in the D libraries. The strlen2 function I posted works on any string that is terminated by four zeros, and returns the same len as strlen in that case, but much faster. How to get strings initialized with four terminating zeros at compile time is a separate issue. I don't know the solution, else I might consider doing more with this. Yup.. there's a reason that many many hours have been spent optimizing strlen and other memory related length and comparison routines. They are used a lot and the number of ways of making them fast varies almost as much as the number of cpu's that exist. This effort is embedded in the code gen of compilers (other than dmd) and libc runtimes. Trying to re-invent it is noble, and very educational, but largely redundant.
Re: Qt's MOC getting replicated in D for Calypso
On 2/21/2016 9:09 AM, Elie Morisse via Digitalmars-d-announce wrote: On Saturday, 20 February 2016 at 17:34:48 UTC, Nicolas F. wrote: This is really cool and an interesting project, though I've got one concern: How will this fit in with the rest of the C++ efforts done upstream? (...) or is the goal to upstream these changes and make them an officially supported feature? The two efforts are independent, and the main issue with Calypso's approach: it's tied to LDC, LLVM and Clang. Although I had a slight hope that the approach would get recognized as allowing perfect interfacing with C++ incl. things unthinkable with the « from scratch » approach (like C++ template instantiation) and give D an edge that would probably be sufficient to make lots and lots of people switch from C++ to D, as long as DMD is there and a GDC/GCC version isn't proved feasible there's no question about whether this approach should get officially endorsed or not, and nevertheless the current efforts towards better C++ support in DMD should still yield important results. Calypso will exist as a LDC plugin, and yes code using Calypso features will only be build-able by LDC+Calypso. As I see it the goal here is to spearhead a working Qt <-> D interaction, but how would this be used in production? Would Calypso simply be run to generate bindings The goal of Calypso is to make any C++ library of any complexity usable in D straightaway, and there's no binding involved. moc was a barrier for Qt because it only parses C++ code, and Qt's C++ API can hardly be used without the code moc generates. Is there anything preventing Calypso from turning into a code and interface generator? Making it an application that is part of the build rather than a plug in to ldc would make it available to both dmd and gdc users, no?
Re: https everywhere update - dlang.org gets an "A" now!
On 12/3/15 5:38 PM, Brad Anderson via Digitalmars-d-announce wrote: On Wednesday, 2 December 2015 at 22:17:20 UTC, Walter Bright wrote: https://www.ssllabs.com/ssltest/analyze.html?d=dlang.org=on Dlang.org gets an "A" now! Thanks to Jan Knepper's efforts. Nice work by Jan. I know how big of a hassle things like this can be so taking the time to actually do it is much appreciated. On a related note, Let's Encrypt hit public beta today[1]. With that I think we should be able to get all of the official infrastructure on TLS now. It's unfortunate it didn't come a bit sooner because now the NSA knows I read the entire DUB JSON thread, much to my shame. 1. https://letsencrypt.org/2015/12/03/entering-public-beta.html I'm glad that letsencrypt is out there doing the publicity, but getting and using ssl certs has been free via startssl for several years now. What this new group is doing is the PR and marketing to get people to do it, of course under their own umbrella rather than another company's. - Brad
auto-tester partial outage
Tuesday and Wednesday between 8:00am and 4:30pm PDT the auto-tester is going to loose a significant fraction of its build hardware due to power maintenance (my entire neighborhood is loosing its incoming power lines, apparently). I'm in the process of spinning up additional ec2 instances to ensure that we don't loose platform coverage during the maintenance, though there will likely not be the level of redundancy that is available normally. Bad timing considering the hackathon, but hopefully it won't be particularly noticeable to anyone other than me. Later, Brad
Re: Release D 2.067.0
On 3/24/2015 11:18 AM, Martin Nowak via Digitalmars-d-announce wrote: One way to improve this would be to have changelogs in the dmd/druntime/phobos repo and make the entries part of the pull requests. For what it's worth, that's how things were setup a long time ago (by me), but a lot of people argued enough that it was dropped. I can't remember why.
Re: Travis-CI support for D
On 12/11/2014 3:16 AM, Martin Nowak via Digitalmars-d-announce wrote: On Thursday, 11 December 2014 at 07:40:14 UTC, Andrej Mitrovic via Digitalmars-d-announce wrote: On 12/11/14, Martin Nowak via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Glad to announce that D support on Travis-CI was launched today. http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/ Awesome!! Btw, I've noticed this command in the log file of a Travis run: $ curl http://downloads.dlang.org/releases/2014/dmd.2.066.1.linux.zip ~/dmd.zip It seems a bit of a waste of bandwidth to re-download the release for each run? Indeed, and we'll have to see how that works. Easiest solution would be to add a caching proxy on either side (incapsula?). We could also come up with some chef recipes to preinstall a bunch of compilers on certain worker boxes. For the last 30 days, travis represents about 2.5% of all downloads (1k of 40k). So, not horrible, but could also be a whole lot less (down from 1k to 74 based on January's data) if it were cached on each host.
Re: Travis-CI support for D
On 12/10/2014 11:34 PM, Andrej Mitrovic via Digitalmars-d-announce wrote: On 12/11/14, Martin Nowak via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Glad to announce that D support on Travis-CI was launched today. http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/ Awesome!! Btw, I've noticed this command in the log file of a Travis run: $ curl http://downloads.dlang.org/releases/2014/dmd.2.066.1.linux.zip ~/dmd.zip It seems a bit of a waste of bandwidth to re-download the release for each run? Also, this will likely skew download statistics for us. Yes, it will. And bandwidth costs money. Please discuss with the travis-ci people how to cache that.
Re: [OT Security PSA] Shellshock: Update your bash, now!
On 10/3/2014 3:25 AM, David Nadlinger via Digitalmars-d-announce wrote: On Friday, 3 October 2014 at 07:16:14 UTC, Kagamin wrote: On Thursday, 2 October 2014 at 12:44:08 UTC, eles wrote: I doubt. At least, not easily. However, installing LMDE should be a one-time process (it's a rolling distribution). Do rolling distributions guarantee to not overwrite fstab? How mint package update differs from a rolling distro package update? Arch Linux warns you about the conflict and installs the new files as e.g. /etc/fstab.pacnew. David I've used at various points in time Debian, Ubuntu, Redhat, Centos, and amazon linux. At no point has any of them ever lost my fstab file, or any other critical file for that matter. My oldest system at this point is about 8 years old and has been ubuntu since it was born and still is. It's current and has rolled through every intervening version quite easily, which is a good thing since it's a vm off in a data center. It's not hard to maintain systems, but they do require maintenance. I wouldn't really expect to neglect a system for many years and be able to rapidly jump it all the way to current. About once a year I go on a big maintenance spree, independent of more frequent minor maintenance. My 2 cents, Brad
Re: D 2.066 is out. Enjoy!
On 8/22/2014 11:33 AM, Andrei Alexandrescu via Digitalmars-d-announce wrote: On 8/22/14, 10:05 AM, John Colvin wrote: As I'm sure has been mentioned elsewhere, the website changes should be part of the release process, not an afterthought. Agreed. Who would like to volunteer being our webmaster? We'll discuss with our admin to give push rights. -- Andrei cronjob that does a git pull, and then everyone with pull permissions can keep the website updated.
Re: DMD v2.066.0-b3
On 7/12/14, 4:31 PM, Andrew Edwards via Digitalmars-d-announce wrote: On Saturday, 12 July 2014 at 00:13:47 UTC, David Nadlinger wrote: For convenience, the list of unresolved issues marked as regressions: https://issues.dlang.org/buglist.cgi?bug_severity=regressionresolution=--- Seems like there is still quite a way to go until we can release RC1. David David, I'm sure you are aware that list will never be empty. The last release lasted from mid November to 24 February and that list was never empty once during that entire time. The only way we will empty that list is to prevent people from submitting new regressions during a review. When I checked the list yesterday the count was at 9: right now it is at 12. And at least on of those items on the list has been there since 2011. The reality is that zero emphasis is place on regressions unless it's time for a release, and even then, only a few people pay attention to them. Everyone else just continue on in their happy world doing what's important to them. You you cannot ask that anyone work on anything because if it's not important in their minds, they will not do it. They'd much rather sit around and biker about how you did it incorrectly. Which, in my opinion, is a huge wast of time and resource. So I have some questions: What is the magic number that will trigger the release? What happens if we never reach that number? Do we just continue waiting for it or do we make a decision at some point that it's time? If so, how long do we wait? Is there one person who makes the decision, or is it decision automatic? If there is a person, who is it? An important topic, certainly. But not for the announce newsgroup. Please continue this over on the beta list.
Re: DMD v2.066.0-b3
Also available at downloads.dlang.org On 7/11/14, 5:00 PM, Andrew Edwards via Digitalmars-d-announce wrote: The v2.066.0-b3 binaries are now available. The review period for beta 3 will run until 0700 UTC ( PDT, 0300 EDT, 1600 JST) on 14 July 2014, at which time binaries for RC1 will be produced and released. Due diligence in identifying regressions as early as possible is requested and appreciated. Issue 13101, [1], is provided for identifying anyfixedregressions that needs to be picked and included in RC1. B3 binaries are located here: ALL ftp.digitalmars.com/dmd.2.066.0-b3.zip OSX ftp.digitalmars.com/dmd.2.066.0-b3.dmg ftp.digitalmars.com/dmd.2.066.0-b3.osx.zip FREEBSD ftp.digitalmars.com/dmd.2.066.0-b3.freebsd-64.zip ftp.digitalmars.com/dmd.2.066.0-b3.freebsd-32.zip LINUX ftp.digitalmars.com/dmd_2.066.0~b3-0_i386.deb ftp.digitalmars.com/dmd_2.066.0~b3-0_amd64.deb ftp.digitalmars.com/dmd.2.066.0-b3.linux.zip ftp.digitalmars.com/dmd-2.066.0~b3-0.openSUSE.i386.rpm ftp.digitalmars.com/dmd-2.066.0~b3-0.openSUSE.x86_64.rpm ftp.digitalmars.com/dmd-2.066.0~b3-0.fedora.i386.rpm ftp.digitalmars.com/dmd-2.066.0~b3-0.fedora.x86_64.rpm ftp.digitalmars.com/libphobos2-66_2.066.0~b3-0_i386.deb ftp.digitalmars.com/libphobos2-66_2.066.0~b3-0_amd64.deb WINDOWS ftp.digitalmars.com/dmd-2.066.0-b3.exe ftp.digitalmars.com/dmd.2.066.0-b3.windows.zip A maintenance release is scheduled for 2.065 on September 15. Request assistance in identifying non-breaking changes (fixes) for inclusion in 2.065.1 by 30 August. Issue 13036, [2], is opened for documenting/consolidating candidates for the point release. Enjoy, Andrew [1] [Cherry-pick v2.066.0-rc1]https://issues.dlang.org/show_bug.cgi?id=13101 [2] [Cherry-pick v2.065.1-b1]https://issues.dlang.org/show_bug.cgi?id=13036
Re: DMD 2.066.0-b1
The same set of available files are also here: http://downloads.dlang.org/pre-releases/2014/ NOTE: The amd64 linux build is listed as available, but it's not, yet. On 7/3/14, 6:13 PM, Andrew Edwards via Digitalmars-d-announce wrote: A number of technical difficulties resulted in a delayed beta review. The review period has commenced and will continue until 0700 UTC ( PDT) 14 July 2014. Your assistance in identifying and reporting bugs are greatly appreciated. Binaries are located here: ALL ftp://ftp.digitalmars.com/dmd.2.066.0-b1.zip OSX ftp://ftp.digitalmars.com/dmd.2.066.0-b1.osx.zip ftp://ftp.digitalmars.com/dmd.2.066.0-b1.dmg FREEBSD ftp://ftp.digitalmars.com/dmd.2.066.0-b1.freebsd-32.zip ftp://ftp.digitalmars.com/dmd.2.066.0-b1.freebsd-64.zip LINUX ftp://ftp.digitalmars.com/dmd.2.066.0-b1.linux.zip ftp://ftp.digitalmars.com/dmd_2.066.0-b1-0_amd64.deb * ftp://ftp.digitalmars.com/dmd_2.066.0-b1-0_i386.deb * ftp://ftp.digitalmars.com/libphobos2-66_2.066.0~b1-0_amd64.deb * ftp://ftp.digitalmars.com/libphobos2-66_2.066.0~b1-0_i386.deb * ftp://ftp.digitalmars.com/dmd-2.066.0~b1-0.fedora.i386.rpm * ftp://ftp.digitalmars.com/dmd-2.066.0~b1-0.fedora.x86_64.rpm * ftp://ftp.digitalmars.com/dmd-2.066.0~b1-0.openSUSE.i386.rpm * ftp://ftp.digitalmars.com/dmd-2.066.0~b1-0.openSUSE.x86_64.rpm * ftp://ftp.digitalmars.com/dmd_2.066.0~b1-0_amd64.deb * ftp://ftp.digitalmars.com/dmd_2.066.0~b1-0_i386.deb WINDOWS ftp://ftp.digitalmars.com/dmd.2.066.0-b1.windows.zip * ftp://ftp.digitalmars.com/dmd-2.066.0-b1.windows.exe * Note: installers are not yet available for Linux or Windows, please check back again as they will be uploaded upon availability. You can find find a list of changes that have occurred since the release 2.065.0 at [1]. I'm looking for a better way but this should provide an good idea as to what has changed since the last release. Request assistance in identifying non-breaking changes (fixes) for inclusion in the 2.065.1 point release. I need assistance with this because I do not have the expertise to determine what goes into the point release. If nothing is identified, I will abandon the idea of providing point releases. A big thanks to the developers who have dedicated their time and effort to making improvements to the language and making this release possible. A issues ([1] [2]) have been created for identifying commits that require cherry picking for inclusion in future beta/release candidates. Commits not identified will not be picked. Enjoy, Andrew [1] https://github.com/AndrewEdwards/dmd/wiki [2] [Cherry-pick v2.066.0-b2] https://issues.dlang.org/show_bug.cgi?id=13035 [3] [Cherry-pick v2.065.1-b1] https://issues.dlang.org/show_bug.cgi?id=13036
bugzilla and auto-tester temporarily down
The host that runs these two services is down. I'm working on getting them back up. There's a reasonable chance I'll end up having to restore both db's from last night's backups, meaning a loss of the last 18 hours of bugzilla changes other than the messages sent to the bugs newsgroup/forum/mailing-list.
Re: bugzilla and auto-tester temporarily down
Both are back up and running, with about 17 hours of data loss (just after midnight pacific time is when the backup ran). I forced the auto-tester to invalidate all 'current' results and start testing everything. For bugzilla, there's 9 messages during that time span, some are due to dupes, so very little data loss. I'll re-enter those now. Please report anything that seems broken (... relative to how it was yesterday). On 7/1/14, 3:30 PM, Brad Roberts via Digitalmars-d-announce wrote: The host that runs these two services is down. I'm working on getting them back up. There's a reasonable chance I'll end up having to restore both db's from last night's backups, meaning a loss of the last 18 hours of bugzilla changes other than the messages sent to the bugs newsgroup/forum/mailing-list.
D's timeline
I'm working on my presentation for the conference and I'm running out of time. I'd like to ask you guys for some help locating a few dates: 1) When 0.x transitioned from alpha to beta 2) Was there a beta to release candidate transition for 0.x - 1.x? If so, when? I have the 1.00 release date, that one is easy. 3) When did the 2.x series switch similarly (alpha, beta, rc)? 4) When were the various platforms added to the release bundles? Any other events you consider major in the history of D. I've already got a bunch, but have room to include more and would hate to miss anything big. We each have our own view on what's important and I won't promise to include ones mentioned, but I'd love to have more to consider including. Please send them directly to me (bra...@puremagic.com) rather than follow up in the news group to avoid a long and not really appropriate for the announce group discussion. Thanks, Brad
