Re: blog post about how you can make your gc code faster
On Wednesday, 9 November 2022 at 11:55:28 UTC, Guillaume Piolat wrote: I've been avoiding void[] for this reason (I mean, void[] _could_ contain pointers), but I think I'm cargo-culting this? If I do: ubyte[] arr = new ubyte[100_000_000]; void[] arr2 = cast(void[]) arr; // will this still avoid scanning? Does the GC still know that this area is NO_SCAN? Yes (as per Adam's post). However, it's easy to lose it with operations like concatenation or appending. `a ~ b` will allocate `void[]` (without `NO_SCAN`) if either are `void[]`. This is why I still use `ubyte[]` (or, in ae, `Data` / `DataVec`) for raw data.
Re: A new Tree-Sitter Grammar for D
On Monday, 17 October 2022 at 05:21:10 UTC, Garrett D'Amore wrote: I'm happy to announce that I've created what I believe is a complete, or at least very nearly so, Tree-Sitter grammar for D. You can find it at https://github.com/gdamore/tree-sitter-d Congratulations! Linking to a response in another thread you pinged - perspective from the existing project: https://github.com/CyberShadow/tree-sitter-d/issues/3#issuecomment-1280343366
Re: Giving up
On Friday, 5 August 2022 at 15:36:06 UTC, Rumbu wrote: The last issues are generated by unpublished changes in the parser: Examples: ```d float z = 85886696878585969769557975866955695.E0; //integer overflow, I don't see any int ``` The last version where this compiled successfully was D 2.057, released on December 13, 2011. ```d real x = 0x1p-16383; //number `0x1p-16383` is not representable. It is, trust me. ``` The last version where this compiled successfully was D 0.116, released on March 7, 2005. Perhaps you may have had a bug in your test suite which caused these lines to not be compiled.
Re: argparse version 1.0.0
On Friday, 10 June 2022 at 14:14:27 UTC, Andrey Zherikov wrote: On Friday, 10 June 2022 at 09:20:24 UTC, Vladimir Panteleev wrote: Congratulations on the release. Though there's a good number of libraries for this task in D already, this solution looks very complete. I looked at them when I started this project and they didn't provide complete set of features I was looking for. That was the main reason to start this work. I invoke https://xkcd.com/927/ ! :) I was wondering if you ran into any strong reasons for describing the arguments as a struct, rather than, well, function arguments. I have had good success so far with the latter, which has the benefit of being succinct: https://github.com/CyberShadow/btdu/blob/116d190079ca77d61383eb738defa4318d5a1e5f/source/btdu/main.d#L59 This is an interesting approach. I think they are equivalent for simple cases but how would you model subcommands with common arguments for all of them? Glad you asked! I use an approach similar to the one here, with commands in a struct. The common arguments are parsed before invoking the command. https://github.com/CyberShadow/steamkeyactivator/blob/144d322ecee65f4f536e5fd4141837e51d61a27a/activator.d#L142 When only some commands need to share some arguments, you can put them in a tuple. https://github.com/CyberShadow/Digger/blob/7c7dd167aea2214d594bab932ea4e41e5f0a357a/digger.d#L34
Re: argparse version 1.0.0
On Thursday, 9 June 2022 at 19:08:16 UTC, Andrey Zherikov wrote: Hi everyone, I'm glad to announce first major version of [argparse](https://code.dlang.org/packages/argparse) - a library for creating command line interface. It took some time to figure out public API of this library and I believe it's mature enough for the major version. Congratulations on the release. Though there's a good number of libraries for this task in D already, this solution looks very complete. I was wondering if you ran into any strong reasons for describing the arguments as a struct, rather than, well, function arguments. I have had good success so far with the latter, which has the benefit of being succinct: https://github.com/CyberShadow/btdu/blob/116d190079ca77d61383eb738defa4318d5a1e5f/source/btdu/main.d#L59
Re: A New Game Written in D
On Tuesday, 17 May 2022 at 16:36:34 UTC, Kenny Shields wrote: This isn't an open-source project, but I wanted to post this here for anyone who might be interested in seeing D used for cross-platform game development. Any questions/comments about the implementation and design of the game/engine are welcome. Cool game! I got to stage 19. I had no problems with the Linux port, except the occasional crash when generating maps that was already mentioned. Some feedback about the game: - The engine handles 144Hz screens correctly and changes in frame rate, well done. - You can make collision less frustrating by making the player slide along the edge of the obstacle partially in the direction they're facing. The easiest way to do this is that, when a collision happens, instead of preventing movement in the player's direction, you allow it to happen, but then as long as the player and the obstacle intersects, the obstacle pushes the player out, away from its center. Doing this in the same frame will make it seem like the player is sliding along the side of the obstacle. - This game could be almost categorized as a twin-stick shooter, though it's not quite so due to only being able to move forward in the direction you're aiming. I'm not sure what this constraint adds but it does seem very unusual. - I didn't try all combinations of craftables, but there is almost no reason to build a regular turret instead of the tesla coil. The tesla coil has a higher DPS/$, never misses, and does not have friendly fire. - Oddly, sprinting energy does not recover when standing still but holding Shift. - "Game seed" seems to affect only the generation of the map layout, but not of pickups or your initial position; perhaps calling it "map seed" would be more accurate. - Choosing to play on a larger map seems to be strictly disadvantageous, as pickups are more rare due to being more spread out.
Re: Release: serverino - please destroy it.
On Monday, 9 May 2022 at 16:37:15 UTC, H. S. Teoh wrote: Why is memory protection the only way to implement write barriers in D? Well, it's the only way I know of without making it a major backwards-incompatible change. The main restriction in this area is that it must continue working with code written in other languages, and generally not affect the ABI drastically.
Re: Release: serverino - please destroy it.
On Monday, 9 May 2022 at 00:25:43 UTC, H. S. Teoh wrote: In the past, the argument was that write barriers represented an unacceptable performance hit to D code. But I don't think this has ever actually been measured. (Or has it?) Maybe somebody should make a dmd fork that introduces write barriers, plus a generational GC (even if it's a toy, proof-of-concept-only implementation) to see if the performance hit is really as bad as believed to be. Implementing write barriers in the compiler (by instrumenting code) means that you're no longer allowed to copy pointers to managed memory in non-D code. This is a stricter assumption that the current ones we have; for instance, copying a struct (which has indirections) with memcpy would be forbidden.
Re: Release: serverino - please destroy it.
On Sunday, 8 May 2022 at 23:44:42 UTC, Ali Çehreli wrote: While we are on topic :) and as I finally understood what generational GC is[1], are there any fundamental issues with D to not use one? I implemented one a long time ago. The only way to get write barriers with D is memory protection. It worked, but unfortunately the write barriers caused a severe performance penalty. It's possible that it might be viable with more tweaking, or in certain applications where most of the heap is not written to; I did not experiment a lot with it.
Re: D Language Foundation Monthly Meeting for February 2022
On Tuesday, 1 March 2022 at 08:12:43 UTC, bauss wrote: Can't beat the nice integration and ease of access Github provides, we need stay fresh to attract new younger souls I sort of agree with that. I usually don't bother reporting anything because I don't like bugzilla, it would just be much more convenient to use Github. New Bugzilla is much nicer (preview: https://dbugs.k3.1azy.net/), but I agree that it's not possible to beat GitHub's integration with GitHub (and GitHub does not provide the opportunity for better integration either unlike some libre competitors). On the other hand with Bugzilla we are fully in control and own our data, which allows doing a few things not possible with GitHub. This is why we're doing both approaches in parallel (Bugzilla work is currently waiting on obtaining the issues.dlang.org configuration files).
Re: trash-d: Replacement for rm that uses the trash bin
On Wednesday, 25 August 2021 at 13:30:36 UTC, rushsteve1 wrote: `trash-d` tries to mimic `rm`'s semantics as much as possible. It also unifies all the different `trash-*` commands that `trash-cli` provides into a single one with flags. One of my goals with `trash-d` was to make a simpler and smaller alternative to `trash-cli`. That makes sense, thanks! The only advantage that `trash-cli` has that I know of (aside from maturity at this point) is that it handles `.Trash/` directories on separate drives/partitions while `trash-d` always moves to the one in the user's home. Both approaches are spec-compliant, so I opted for the simpler one. I suggest investigating that as a future improvement. Not only is moving files within the same volume much faster (potentially an O(1) operation as opposed to having to read then write every byte of data), but it can also result in space savings (in the case of filesystem snapshots).
Re: trash-d: Replacement for rm that uses the trash bin
On Tuesday, 24 August 2021 at 02:19:58 UTC, rushsteve1 wrote: https://github.com/rushsteve1/trash-d A near drop-in replacement for `rm` that uses the Freedesktop trash bin. Started because an acquaintance `rm -rf`'d his music folder and I thought there had to be a better way. Cool! How does it compare to the `trash` command from the `trash-cli` package?
Re: Why RSS is not working?
On Thursday, 15 July 2021 at 07:23:31 UTC, Gleb Kulikov wrote: Gentleman, good afternoon! And what is the reason that the RSS of Announce Forum has not been working since May? XML is broken and ends like this: Hi, First, please only post announcements in the Announce forum. The feed is fine according to https://validator.w3.org/feed/check.cgi?url=https%3A//forum.dlang.org/feed/threads/announce . It also looks OK with e.g. https://addons.mozilla.org/en-US/firefox/addon/smart-rss-reader/ . I'm guessing it is a problem with your feed reader.
Re: Symmetry looking for D programmers in Singapore/Hong Kong/Australia/New Zealand
On Wednesday, 16 June 2021 at 16:38:58 UTC, Atila Neves wrote: On Wednesday, 16 June 2021 at 15:48:07 UTC, Vladimir Panteleev wrote: On Wednesday, 16 June 2021 at 14:40:05 UTC, Atila Neves wrote: Interested? Please send a CV to dot name> at Replying for the benefit of forum.dlang.org users, for whom the tags were not visible due to Markdown. I did wonder what the warning was about when I posted and didn't even know it was markup to begin with... oops. I improved the warning text. Apologies for the confusion :) Also, what about remote?
Re: Symmetry looking for D programmers in Singapore/Hong Kong/Australia/New Zealand
On Wednesday, 16 June 2021 at 16:49:56 UTC, Tejas wrote: On Wednesday, 16 June 2021 at 16:24:58 UTC, Vladimir Panteleev wrote: On Wednesday, 16 June 2021 at 16:15:31 UTC, Tejas wrote: On Wednesday, 16 June 2021 at 15:48:07 UTC, Vladimir Panteleev wrote: Have a look at the "Also via" column on the forum index ( https://forum.dlang.org/ ) :) I wondered why I couldn't see what you're talking about, then switched to desktop mode and finally saw it... that column doesn't even exist in mobile... I thought I was blind or something for a good 15 minutes. Ah, sorry! Yes, the other ways aren't very mobile friendly, so listing them isn't worth the very limited screen space on mobile.
Re: Symmetry looking for D programmers in Singapore/Hong Kong/Australia/New Zealand
On Wednesday, 16 June 2021 at 16:15:31 UTC, Tejas wrote: On Wednesday, 16 June 2021 at 15:48:07 UTC, Vladimir Panteleev wrote: Replying for the benefit of forum.dlang.org users, for whom the tags were not visible due to Markdown. Thank you so much :D Also, what other ways exist to visit this news group? Have a look at the "Also via" column on the forum index ( https://forum.dlang.org/ ) :)
Re: Symmetry looking for D programmers in Singapore/Hong Kong/Australia/New Zealand
On Wednesday, 16 June 2021 at 14:40:05 UTC, Atila Neves wrote: Interested? Please send a CV to dot name> at Replying for the benefit of forum.dlang.org users, for whom the tags were not visible due to Markdown. Also, what about remote?
ae v0.0.3000
*ae* (***a**lmost **e**verything*) is an auxiliary general-purpose D library. It is used by forum.dlang.org, Digger, the D documentation auto-tester, and most of my D projects in general. Among many things, it implements an asynchronous event loop, several network protocols, and various utility code to complement the D standard library (Phobos). https://github.com/CyberShadow/ae The library's Git repository reached a nice round number of commits the other day, which might as well be an occasion to make this announcement, in case someone finds something useful for their D adventures here. Please see [the README document](https://github.com/CyberShadow/ae#overview) for an overview of what can be found in the library. ### What's new in *ae*? Notable additions within the last 1000 commits: - All public declarations have been documented (with help from [a DMDFE-based linter](https://github.com/CyberShadow/dlint)). You can browse the documentation on [ae.dpldocs.info](https://ae.dpldocs.info/ae.html). - [`ae.net.http`](https://github.com/CyberShadow/ae/tree/master/net/http) can now be used to accept HTTP requests and send replies not just over plain HTTP(S)-over-TCP, but also using CGI, FastCGI or SCGI over a variety of transports. - [`ae.net.http.app`](https://github.com/CyberShadow/ae/blob/master/net/http/app/server.d) provides a central point which allows your users to configure and integrate your web app with practically any environment. [Example of a configuration file doing so](https://github.com/CyberShadow/cirun/blob/86d54e4724bcdf4395c01cb488c1d059ae482d01/src/cirun.conf.sample#L36-L114). - [`ae.net.ssl.openssl`](https://github.com/CyberShadow/ae/blob/master/net/ssl/openssl.d) now passes most badssl.com tests. - [`ae.sys.file.listDir`](https://ae.dpldocs.info/~next/ae.sys.file.listDir.html) is a fast and flexible directory iterator. It sacrifices providing results as a range to instead gain allowing to decide on-the-spot when to recurse. The speed gains come from avoiding `stat` calls by taking advantage of the `dirent.d_type` field, and allowing applications to avoid GC allocations when querying directory entry names. - [`ae.utils.mapset`](https://github.com/CyberShadow/ae/blob/master/utils/mapset.d) is a data structure which allows holding and performing operations on very large sets of maps. Applications include fully exploring program states for all possible inputs, e.g. for fuzzing. - [`ae.utils.promise`](https://github.com/CyberShadow/ae/blob/master/utils/promise.d) is an implementation of JavaScript-like promises, and attempts to follow the Promises/A+ specification as closely as possible. [Discussed here](https://forum.dlang.org/post/pzbyxaxssokctpgpr...@forum.dlang.org). - [`ae.utils.meta.tuplerange`](https://github.com/CyberShadow/ae/blob/master/utils/meta/tuplerange.d) contains constructs for iterating and chaining together operations on range-like constructs which operate on heterogeneous types. The standard D range interface does not provide this, so an internal iteration API is used instead. You may recall me mentioning `ae.utils.meta.chain` during a DConf talk - `meta.tuplerange` is `meta.chain`'s successor. - [`ae.utils.math.longmul`](https://github.com/CyberShadow/ae/blob/master/utils/math/longmul.d) wraps x86 long (up to 128-bit) multiplication and division in D. [Also seen is DustMite](https://dlang.org/blog/2020/04/13/dustmite-the-general-purpose-data-reduction-tool/). - [`ae.utils.graphics.libpng`](https://github.com/CyberShadow/ae/blob/master/utils/graphics/libpng.d) bridges libpng and `ae.utils.graphics.image`, allowing decoding arbitrary PNGs into the user-defined `Image` type. Because the `Image` color type is set at compile-time, the module configures `libpng` to decode the PNG into the `Image`'s color type. The exhaustingly thorough test suite even identified [some bugs in libpng itself](https://github.com/glennrp/libpng/pull/270). - [`ae.utils.sound`](https://github.com/CyberShadow/ae/tree/master/utils/sound) is a package to generate, load, and save simple audio samples. Waveforms can be generated as D ranges (using e.g. `std.algorithm`) and then mixed / played / saved. The included space shooter demo game [pewpew](https://github.com/CyberShadow/ae/blob/master/demo/pewpew/) uses this package to generate and play procedural sound effects. Thanks for reading!
Re: DustMite: the General-Purpose Data Reduction Tool (from the D Blog)
On Tuesday, 14 April 2020 at 07:03:42 UTC, WebFreak001 wrote: very nice article! Thank you! Also for the performance changes: what do the numbers mean in the diagram there? Is higher better? What exactly is the unit of these numbers? Should I even read it from top to bottom or from bottom to top like usual git logs? Why did it jump from 487 to 200 and is that good or bad? Yes, sorry, I was going to add some explanations but forgot. They go in chronological order and going from 200 to 487 was bad (the new tree data structure added a lot of overhead, which was not yet taken advantage of). The numbers represent seconds for 200 reduction steps for reducing my test program. The source code for all programs/scripts used to create the graphics can be found here: https://gitlab.com/CyberShadow/dustmite-article
Re: DustMite: the General-Purpose Data Reduction Tool (from the D Blog)
On Monday, 13 April 2020 at 18:53:39 UTC, Steven Schveighoffer wrote: Very nice article! Thank you! Interesting from the animation that it decided that importing std.stdio can be "reduced" to importing std! Yes, it's a new minor annoyance for all DustMite users :) I see that you can prevent reductions via regex. Regex and similar rules are applied at input parsing time, not on the emitted output. How do you say "Don't reduce `std\..*` to `std`" or is that possible? In other words, I'm fine with reducing imports, but not that specific reduction. The canonical way, right now, is to add something like `if grep -q 'import .*std[;,]' ; then exit 1 ; fi` to the test script. To make this test reusable, it can be saved to e.g. "dustmite-no-std" and DustMite invoked with `dustmite src "dustmite-no-std && ../actual-test-script.sh"`. I don't know if it's worth it, but to make this common annoyance easier to handle without baking in more highly-D-specific stuff into a tool which aims to be general-purpose, I'm thinking of the following additions: 1. Allow more than one test command. A reduction is considered successful only if all test commands pass. (It would be the equivalent of chaining them with && in a shell command.) 2. Add built-in tests which can be used in place of a test command, such as ":d-no-std".
win32 - Windows API declarations for all platforms
https://github.com/CyberShadow/win32 https://code.dlang.org/packages/win32 This is a repository + dub package which tracks core.sys.windows, and makes the declarations within available to all platforms. This is useful if you need to write cross-platform applications which e.g. read/write BMP or PE files. More details in the README: https://github.com/CyberShadow/win32#readme
Re: Beta 2.089.0
On Thursday, 17 October 2019 at 06:02:33 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.089.0 release, ♥ to the 44 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.089.0.html As usual please report any bugs at https://issues.dlang.org -Martin Martin, DMD has been unbuildable from ZIP files for many releases now. This has been reported to Bugzilla a while ago and has been asked about on the forum a few times. Could you please look into it? https://issues.dlang.org/show_bug.cgi?id=18791
Re: Dlang documentation as CHM file + transform C# project
On Wednesday, 25 September 2019 at 11:40:04 UTC, a11e99z wrote: I had an idea to make CHM help as D-documentation after a post about man pages popped up https://thecybershadow.net/d/docs/ https://github.com/dlang/dlang.org/commits/master/chmgen.d Generates keyword index, navigation as on dlang.org, embeds necessary files, also lints HTML... It is also used to generate the dman keyword index. CHM is no longer being built as part of the release because everyone got angry at me every time it broke, so I stopped maintaining it. Nobody complained.
Chunker - Content-Defined Chunking based on Rabin Checksums
Hi, This is a D port of a Go package implementing Content-Defined Chunking: https://github.com/CyberShadow/chunker The package contains the following modules: - chunker.polynomials - implements Pol, a type which represents a polynomial from F_2[X]. I'm not quite sure what that is, but they seem to be very useful. - chunker.rabin - implements RabinHash, which calculates a rolling Rabin Fingerprint. - chunker - implements Chunker, an adapter range which accepts chunks of bytes (such as from File.byChunk) and emits variable-size content-defined chunks, which are split when the local Rabin Fingerprint reaches a certain value. Links - - Wikipedia: https://en.wikipedia.org/wiki/Rolling_hash#Rabin_fingerprint - Original Go version: https://github.com/restic/chunker - Dub package: https://code.dlang.org/packages/chunker - Documentation: https://chunker.dpldocs.info/chunker.html (courtesy of Adam Ruppe's dpldocs service) - Example: https://github.com/cybershadow/chunker/blob/master/src/chunker/example.d Differences from the Go version --- - Chunker was adapted to be a D range and accept D ranges as input. - The Rabin Fingerprint implementation was extracted out of Chunker and into its own module. It is usable stand-alone. - Significant refactorings and simplifications of the implementation. The original code made some sacrifices in code readability to work around limitations of the language and compiler optimization to achieve reasonable performance. - 20% faster than the Go version (LDC release build). - Improved test coverage and symbol documentation. The original package was written by Alexander Neumann and is used in the restic backup program.
Re: Five Projects Selected for SAOC 2019
On Tuesday, 27 August 2019 at 17:11:33 UTC, Mike Franklin wrote: On Tuesday, 27 August 2019 at 12:58:20 UTC, Vladimir Panteleev wrote: It will eventually zero in to commit-level accuracy after it's been running for a while. I cleared the database as the last time it was running, it was on another CPU, so the timings are going to be different. (Still need to decide on a way to measure execution time in some deterministic way.) If you look at the vibe.d compile-time graph, you'll see there's a 2.5s increase around Mid-2014. When I zoom in and visit the commit, it's just a DDoc comment change (https://github.com/dlang/phobos/pull/3542). I don't see how that could account for the large increase in compile time. The JS part of the project was adopted from somewhere else (Mozilla's project for tracking Firefox performance), so it was a bit hammered-on to the data schema we use here. Mozilla never builds individual successive commits; you have to do it yourself to zero in on a specific change. Because of this, the UI was confusing and it wasn't obvious whether a commit is actually the cause of a change in the metrics. I've now changed it to only draw a line between two points if they're adjacent in the git history. Still not perfect but better. You can see this now by zooming into the big change in e.g. "Empty program - compilation - peak heap size". (The vibe.d one isn't resolved yet, give it a few days.) The problem with representing this data is that we have the whole commit list, which is nice and linear, but not all commits are tested, and we can't graph untested commits because they effectively don't have an Y value. There's also way too many commits to draw at once, so it groups commits that occurred near the same time together in one node, which again causes complications when it's a mix of tested and untested commits. (Currently it uses the median of the test results for tested commits.) More changes: https://github.com/CyberShadow/TrenD/commits/master
Re: Five Projects Selected for SAOC 2019
On Monday, 26 August 2019 at 18:51:54 UTC, Vladimir Panteleev wrote: On Sunday, 25 August 2019 at 13:38:24 UTC, Mike Parker wrote: The Symmetry Autumn of Code 2019 application selection process has come to an end. This year, we've got five projects instead of three. Congratulations to everyone who was selected! You can read about them and their projects over at the D Blog: https://dlang.org/blog/2019/08/25/saoc-2019-projects-and-participants/ Sorry, I haven't been following. Don't we already have an implementation of the "Create a CI or other infrastructure for measuring D’s progress and performance" project? I just haven't been maintaining it because there hasn't been a lot of interest in it while it was being maintained. Max, if you're still excited about this project, please ping me on IRC or Slack. Would love to brainstorm with you and hear your ideas.
Re: Five Projects Selected for SAOC 2019
On Tuesday, 27 August 2019 at 09:08:58 UTC, Mike Franklin wrote: It's great to see this back up and running. The compile-time data is quite interesting. Is there any way to identify a particular offending commit. The commits identified in the data points on the chart don't seem to be precise. It will eventually zero in to commit-level accuracy after it's been running for a while. I cleared the database as the last time it was running, it was on another CPU, so the timings are going to be different. (Still need to decide on a way to measure execution time in some deterministic way.)
Re: Five Projects Selected for SAOC 2019
On Sunday, 25 August 2019 at 13:38:24 UTC, Mike Parker wrote: The Symmetry Autumn of Code 2019 application selection process has come to an end. This year, we've got five projects instead of three. Congratulations to everyone who was selected! You can read about them and their projects over at the D Blog: https://dlang.org/blog/2019/08/25/saoc-2019-projects-and-participants/ Sorry, I haven't been following. Don't we already have an implementation of the "Create a CI or other infrastructure for measuring D’s progress and performance" project? I just haven't been maintaining it because there hasn't been a lot of interest in it while it was being maintained. Here's the original blog post: https://blog.thecybershadow.net/2015/05/05/is-d-slim-yet/ I'll give it a kick and get it back online if there is interest. Seems wasteful to reimplement it from scratch, though.
Re: Release D 2.087.0
On Monday, 15 July 2019 at 19:56:29 UTC, David Nadlinger wrote: (Corollary: This should be fixed in a point release to unbreak various tooling and dependent build systems.) Fortunately, these changes still have not appeared in a release, so we can still fix them. The reason why this discussion occurred in this thread was that a Digger user tried to install the "master" version after a stable release, at which point the change had already occurred in the master branch. https://github.com/dlang/druntime/pull/2681
Re: Release D 2.087.0
On Monday, 15 July 2019 at 13:27:39 UTC, Mike Franklin wrote: I asked for input from other developers before moving forward. They helped me understand that `rt` is where the core language features are implemented. Assuming it was the discussion linked in this thread, it did not seem like the finer details which we covered today have been considered back then. There are also two developers in this thread which are arguing the contrary, and it would be unfair to count only those participating in the prior discussion if you would make this a matter of numbers. I submitted PRs that were scrutinized by the reviewers and merged. Bad PRs get merged all the time. It happens. We need to recognize mistakes and do our best to address them. The code that I moved into `rt/array` initially came from `rt`, depends on implementations in `rt` and is the core implementation of D's built-in arrays, so it is perfectly logical for it to be in `rt`. That's a subjective assessment, and it would be perfectly fine to rely on subjective opinions to make decisions which would otherwise have no consequence, but it is not the case here. The decision was an avoidable breaking change. I'm sorry you disagree and don't find my explanations convincing. There are a few arguments remaining in this thread to which you have not responded.
Re: Release D 2.087.0
On Monday, 15 July 2019 at 12:42:57 UTC, Mike Franklin wrote: ... and are the exception, not the rule. I believe they should be moved to `rt`. BTW, from this discussion it seems to me that you did not have a good overview of the situation and made a bad decision based on that. No problem there, however, throughout this discussion, you've made a number of claims that have been refuted, and instead of re-evaluating the situation, you've stuck to your position while presenting continuously more radical counter-arguments. At this point, I apologize and would like to ask you to carefully consider whether you are trying to neutrally argue for the best outcome to make D better, or merely to continue supporting your position.
Re: Release D 2.087.0
On Monday, 15 July 2019 at 12:57:46 UTC, Mike Franklin wrote: On Monday, 15 July 2019 at 12:27:22 UTC, Vladimir Panteleev wrote: This isn't exactly true. The restriction is that core should not *import* rt. Have a look at all the extern(C) definitions in Druntime - using extern(C) functions to communicate between the compiler and rt, as well as core and rt, is not a "hack", but an established mechanism to invoke the low-level implementations in Druntime. We are trying to implement many of those `extern(C)` runtime hooks as templates. Those templates need to be implicitly imported through object.d. That means code that was in `rt` is converted to a template, and then moved to object.d. However, as we do more and more of them object.d becomes unwieldy. I took the initiative to prevent object.d from turning into a more of a monstrosity that it already is, and moved those runtime templates (which used to reside in `rt`) back into `rt`. This is not a problem, and not at all related to the issue we're discussing. The problem is that you chose to move them into `rt` instead of somewhere under `core`, which would respect existing conventions and avoid breakages like the ones we've seen reported in this thread.
Re: Release D 2.087.0
On Monday, 15 July 2019 at 12:42:57 UTC, Mike Franklin wrote: On Monday, 15 July 2019 at 12:40:50 UTC, Vladimir Panteleev wrote: - core.internal.hash contains the implementation of hashing routines used for associative arrays. - core.internal.arrayop contains the implementation of array vector operations. This one doesn't seem to be too far from your work in question. ... and are the exception, not the rule. I believe they should be moved to `rt`. To what end? You are supporting a change (and proposing further changes) which breaks existing conventions and solves zero problems, while simultaneously opposing a change that would fix at least two situations that we know of (Digger and Jonathan's installation script).
Re: Release D 2.087.0
On Monday, 15 July 2019 at 12:36:14 UTC, Mike Franklin wrote: Many of the implementations in `rt/array` are templates, so the entire implementation should be available through object.d, not just declarations. The amount of templated code is still finite, otherwise you would have needed to include all of rt into the set of files to be made importable. In `core.internal`, I see utilities that appear to be intended for use only within runtime, or "privately" imported by Phobos. I do not see implementations for fundamental language features as can be found in `rt`. The code in `rt/array` implementations for fundamental language features, not utilities to be used privately with druntime. Please have a closer look: - core.internal.hash contains the implementation of hashing routines used for associative arrays. - core.internal.arrayop contains the implementation of array vector operations. This one doesn't seem to be too far from your work in question. "rt can import core, but core can't import rt." makes it pretty clear to me. Please see my other reply.
Re: Release D 2.087.0
On Monday, 15 July 2019 at 12:14:16 UTC, Mike Franklin wrote: Many of the implementations in `rt/array` require importing or referencing other implementations in `rt` (e.g. `rt.lifetime`). If they were moved to `core.internal` they would require importing `rt` or peeking into `rt` with various hacks, which exactly what you've said should not be done. This isn't exactly true. The restriction is that core should not *import* rt. Have a look at all the extern(C) definitions in Druntime - using extern(C) functions to communicate between the compiler and rt, as well as core and rt, is not a "hack", but an established mechanism to invoke the low-level implementations in Druntime.
Re: Release D 2.087.0
On Monday, 15 July 2019 at 12:14:16 UTC, Mike Franklin wrote: On Monday, 15 July 2019 at 12:02:35 UTC, Seb wrote: I think that fits core.internal better than rt. Have you considered that during said discussion? The implementations in `rt/array` contain templates that are ports of runtime hooks that used to reside in `rt`. The implementations also require importing implementations from `rt` so it makes sense to me that they should all stay within `rt`. You don't need to move the implementations themselves into core.internal. Adding declarations there for the rt implementations would suffice. `rt` is not imported by the user; it is imported by the compiler indirectly through `object.d`. So is the rest of core.internal. Please take a few minutes to have a look at the contents of the core.internal package, as well as all the places in object.d where modules from core.internal are already imported. Would you say that those cases are very unlike the case of this particular change? If so, would you mind explaining how? Based on what you and Vladimir have said, I'm even more confident I've made the right decision putting them in `rt`. I really don't see the series of logical steps one would need to take to reach that conclusion.
Re: Release D 2.087.0
On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote: I discussed that briefly on Slack with a couple other developers. My understanding is the `rt` is the language implementation and `core` is the low level library for users. The code in `rt/array` are language implementations. They are not to be imported by the user. They are, however, required by the language to implement D's built-in arrays, so that is why they are publicly imported in object.d. I think that fits core.internal better than rt. Have you considered that during said discussion?
Re: Release D 2.087.0
On Friday, 5 July 2019 at 03:47:20 UTC, Jonathan M Davis wrote: Yeah. I ran into the same problem with my own build tool. There wasn't previously an rt folder in the imports. It was all hidden in the implementation, and my build tool didn't copy it over, resulting in confusing errors at first when druntime was recently changed to have an rt folder in the imports. I think that for druntime, it currently works to just copy over everything in the import folder, whereas with Phobos, you have to copy over specific directories (std and etc IIRC). So, for Phobos, you can't just grab everything from a single folder, and it may have been the case with druntime at one point that you couldn't either (I'm not sure). So, it doesn't really surprise me that digger broke. Any time that a tool is having to duplicate any logic from the build system (even if it's just which files to grab to install rather than for the build itself), it risks breaking any time that the build system is altered. Digger has a good reason and a not-so-good reason to avoid using the included build system logic. The good reason is that Digger attempts to support building a range of D versions as large as possible on modern systems. Sometimes, that means patching or entirely avoiding parts of the build system included with the D source code. However, this was not the case in this situation. The not-so-good reason, and the root issue here, is the "digger install" functionality, which attempts to merge an existing "standard" D installation with one built by Digger. At the time I implemented it, we didn't have a good well-defined process of building release archives (rather, it was the duty of the release manager at the time to get it right), so, there was no way for Digger to know how to correctly build a complete D distribution including all the extra files which are not versioned, but nevertheless included in the archives; "digger install" was thus created as a work-around for that situation. This Digger feature has a hard-coded list of objects it needs to patch / update, which as you can guess did not include the "rt" package from Druntime.
Re: Release D 2.087.0
On Thursday, 4 July 2019 at 12:57:43 UTC, Mike Franklin wrote: The copy should take place when building druntime from the makefiles. The files to be copied are listed at https://github.com/dlang/druntime/blob/12bcb73da97a0c26aaf4b943eabd3c25051a89da/mak/COPY#L405-L408 and, for Windows, should be copied https://github.com/dlang/druntime/blob/12bcb73da97a0c26aaf4b943eabd3c25051a89da/mak/WINDOWS#L1187-L1197 is executed. But, I don't know if that happens or not with digger. Why have these declarations been placed in the "rt" package, and not in "core.internal"? The "rt" package has historically always been for the Druntime implementation part which is not importable from D programs. I think "core.internal" would have been more suitable.
Re: D syntax highlight support by Chroma in Hugo
On Wednesday, 22 May 2019 at 01:36:46 UTC, Shigeki Karita wrote: Recently, I sent a PR [1] in Chroma (syntax highlighter) to support D. I think my implementation is not perfect. I made this announcement to ask some experts for help and to ask Dlang blogger to use this. Thank you for working on this. Did you have a practical reason to work on this considering that Hugo supports Pygments, and Pygments has decent support for D already? Here are the test files I used when working on D syntax highlighting in other projects, perhaps they can be useful: https://github.com/colorer/Colorer-schemes/blob/master/hrc/test/other/d-sample.d https://github.com/Emacs-D-Mode-Maintainers/Emacs-D-Mode/tree/master/tests
Re: dlang.ru is updated
On Friday, 17 May 2019 at 06:25:23 UTC, Suliman wrote: Waterfox 56.2.9 Oh! I used on my site new js future. It will work after updating browser. Waterfox 56.2.9 is currently the latest version of Waterfox. There is no newer version to update to. Waterfox uses an older version of Gecko (because it is a Firefox fork), but it's not THAT old. Did you check browser support at caniuse.com ? And, what feature is so necessary to display a HTML web page?
Re: dlang.ru is updated
On Thursday, 16 May 2019 at 17:58:52 UTC, Suliman wrote: Very strange... it’s working for me now even from mobile. Which browser? Waterfox 56.2.9 It does work in Chromium.
Re: Static Webpages of Forum Threads
On Monday, 13 May 2019 at 07:40:37 UTC, Johannes Loher wrote: I still think that we should make them easily available from either the website or the forums. On the forum front page, in the right column, you will find an "Archive" link. I believe Mike already mentioned that during the AGM. Is there anybody already working on that? I wasn't at this year's DConf. Could you please explain what's lacking in the HTML pages generated by the forum software?
Re: Fundraising Updates: We did it!
On Tuesday, 26 March 2019 at 15:14:03 UTC, Mike Parker wrote: Long story short, both milestones are nearly complete now (he hasn't worked on them sequentially, and has done other tasks besides). He still wants to wait until he completes them before we payout the $1000 for the milestones. However, he has asked that $1500 of the remaining $2000 be applied to the forum server campaign. We have obliged. Thus, our forum server campaign exceeded our target by $125 and is now closed. The money will be transferred to Vladimir in short order. The excess will be put toward the General Fund. Thank you, Jan, and thank you to everyone who donated. I have some news regarding the server hosting the forum and services. Last month, a circumstance with the then-current server provider forced us to move away from them immediately. We were completely cut off from the server, so I had to improvise, and launched all services directly from a backup on my home PC. This is how they are running currently. I've been working on a more permanent replacement since then. The good news is that I found a server plan with suitable hardware at a much lower price than the previous plan, which means that the $2000 you raised will cover not one, but almost exactly three years of hosting! :) The replacement server has already been ordered, and I've begun setting it up. The data is already in place, and I expect it to be ready to be live with a few more days of work.
Re: D compilation is too slow and I am forking the compiler
On Friday, 23 November 2018 at 13:23:22 UTC, welkam wrote: If we run these steps in different thread on the same core with SMT we could better use core`s resources. Reading file with kernel, decoding UTF-8 with vector instructions and lexing/parsing with scalar operations while all communication is done trough L1 and L2 cache. You might save some pages from the data cache, but by doing more work at once, the code might stop fitting in the execution-related caches (code pages, microcode, branch prediction) instead.
Re: D compilation is too slow and I am forking the compiler
On Wednesday, 21 November 2018 at 20:51:17 UTC, Walter Bright wrote: Unfortunately, you're right. The title will leave the impression "D is slow at compiling". You have to carefully read the article to see otherwise, and few will do that. Sorry about that. I'll have to think of two titles next time, one for the D community and one for everyone else. If it's of any consolation, the top comments in both discussion threads point out that the title is inaccurate on purpose.
Re: D compilation is too slow and I am forking the compiler
On Wednesday, 21 November 2018 at 11:18:22 UTC, Nicholas Wilson wrote: This is #2 on HN at the moment. Also on reddit: https://www.reddit.com/r/programming/comments/9z36xg/d_compilation_is_too_slow_and_i_am_forking_the/
Re: D compilation is too slow and I am forking the compiler
On Wednesday, 21 November 2018 at 11:35:02 UTC, Atila Neves wrote: I'm also currently working on a project to save my bloodstream from the cortisol drip that happens when anything a computer does takes over a second, which these days means waiting for dmd to compile my code so I can see the result of the tests. I'll share more details when I have time. Looking forward to it! But: one of the things I want to do is a version of this / precompiled headers. I've complained before that compiling std.path with -unittest takes forever (0.5s or so, and most of it due to std.uni). That's a price I pay every time I make a one line change to any file, and the linker hasn't even been invoked yet. Here's the thing: Phobos only changes from one release to the next. Why am I waiting to recompile a read-only file that won't change unless I update the compiler, over and over again? That particular problem is in large part due to that the -unittest switch is not namespaced. I ran into the same issue with -allinst - with std.path, it breaks only if -unittest is also specified. I don't want to compile std.path unit tests, just my own! Have we tried disabling -unittest for modules that aren't on the compiler's command line yet (or, in case of -i, not excluded)? I'd love it if I could precompile Phobos and just use the digested information every time I'm iterating. I agree, it would be nice if we could ship some "precompiled module" files along with Phobos .lib / .so files, but it looks like implementing this feature correctly might be non-trivial. Maybe this hack could be developed further into a more generic "compiler server" idea.
Re: D compilation is too slow and I am forking the compiler
On Wednesday, 21 November 2018 at 09:46:44 UTC, Walter Bright wrote: It works by allocating memory from a memory-mapped file, which serves as the precompiled header. Hey, that's a great idea! Can we do this for DMD? :D On a more serious note: do you think that with D's features (type system / metaprogramming), you could have avoided some of those bugs? For example, one thing we can do in D which is still impossible in C++ is to automatically serialize/deserialize all fields of a struct/class (using tupleof / allMembers).
Re: D compilation is too slow and I am forking the compiler
On Wednesday, 21 November 2018 at 08:32:39 UTC, Nicholas Wilson wrote: You gave me a fright there with the title there for a moment. :) Awesome stuff though. Not sure how easy it will be to upstream considering this needs to not wreck Windows and needs to work with LDC/GDC (at least we have inlining in the backend). All the DMD-side logic is all encapsulated in one function: https://github.com/CyberShadow/dmd/blob/dmdforker/src/dmd/mars.d#L501-L673 Its body can be versioned out in incompatible platforms/implementations.
D compilation is too slow and I am forking the compiler
https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/
Re: Profiling DMD's Compilation Time with dmdprof
On Saturday, 17 November 2018 at 23:01:23 UTC, Basile B. wrote: I put a start to the project then today i remembered callgrind... What are the pros and cons in comparison with callgrind ? By coincidence i had to callgrind dmd today and got answers to a performance issue in a very straight forward way because for example: $ valgrind --tool=callgrind generated/debug/dmd somefile.d is very simple procedure and produce a file that's easy to interpret in kcachegrind (which can then also produce a graph in ps format). Note that i don't try to discredit your work, i'm just curious to know. It sounds like you misunderstood the purpose of dmdprof. dmdprof will show you a profile graph of the source code *being compiled* (i.e. which parts take more time to compile and which parts cause other parts to get compiled), not of DMD source code.
Re: Profiling DMD's Compilation Time with dmdprof
On Saturday, 17 November 2018 at 06:21:20 UTC, Manu wrote: What was the batch size for module grouping? I just use dmd -i, which compiles everything at once (except Phobos/Druntime).
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 15 November 2018 at 19:18:27 UTC, Manu wrote: I'm not sure how VisualStudio (read: MSBuild) should behave differently than make? It's not like the build script is taking a long time, it's the invocation of DMD that takes 100% of that time. That seems to take about half the time for me (2 out of the 4 seconds). 36% slower seems highly optimistic? Perhaps you're building a debug build of DMD with a debug build of DMD? I guess that wouldn't be so slow... I suspect it's the optimiser that's very slow? 36% slower for compiling a real-life program with the built D compiler. The comparison is between a normal and debug build of DMD (used to build the program).
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 07:54:56 UTC, Manu wrote: And all builds are release builds... what good is a debug build? DMD is unbelievably slow in debug. If it wasn't already slow enough... if I try and build with a debug build, it takes closer to 5 minutes. I just got to try a side-by-side comparison of a release and debug (as in `make -f posix.mak BUILD=debug`) build of DMD. With a 25KLOC project, the debug build is only 36% slower. Maybe the experience on Windows / Visual Studio is very different.
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 19:07:32 UTC, Jacob Carlborg wrote: 21 seconds on a Windows 10 virtual machine compiling using the win32.mak file. Sounds like we're narrowing it down to the Visual Studio solution.
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 07:54:56 UTC, Manu wrote: https://youtu.be/msWuRlD3zy0 DMD only builds with one core, since it builds altogether. And all builds are release builds... what good is a debug build? DMD is unbelievably slow in debug. If it wasn't already slow enough... if I try and build with a debug build, it takes closer to 5 minutes. I think the default posix.mak target is neither a debug nor a release build, meaning it is neither optimized nor has the additional asserts/invariants of a debug build. Not sure the Visual Studio solution has that, but perhaps it could be an acceptable middle ground. I suspect one part of the problem is that DMD used to be built with a C compiler, and now it's built with DMD... Well, my latest test was against master, that even has parts of the backend apparently converted to D, so I'm not sure that's relevant.
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 06:08:20 UTC, Vladimir Panteleev wrote: It was definitely about 4 seconds not too long ago, a few years at most. No, it's still 4 seconds. digger --offline --config-file=/dev/null -j auto -c local.cache=none build 7.31s user 1.51s system 203% cpu 4.340 total It does seem to take more time now; I wonder why. If it takes longer, then it's probably because it's being built in one CPU core, or in the release build.
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 04:16:44 UTC, Manu wrote: ...what!? DMD takes me... (compiling) ... 1 minute 40 seconds to build! And because DMD does all-files-at-once compilation, rather than separate compilation for each source file, whenever you change just one line in one file, you incur that entire build time, every time, because it can't just rebuild the one source file that changed. You also can't do multi-processor builds with all-in-one build strategies. 4 seconds? That's just untrue. D is actually kinda slow these days... In my experience it's slower than modern C++ compilers by quite a lot. It was definitely about 4 seconds not too long ago, a few years at most. It does seem to take more time now; I wonder why.
Re: Profiling DMD's Compilation Time with dmdprof
On Tuesday, 6 November 2018 at 19:01:58 UTC, H. S. Teoh wrote: I don't have the time to look into this right now, but at a cursory glance, WOW. This is awesome! It looks like it would be really useful one day when I try to tackle the dmd-on-lowmem-system problem again. This will greatly help identify which Phobos modules cause big slowdowns on a low-memory host system. Great. Also, assuming that DMD still never deallocates, it should be pretty easy to turn this into a memory usage profiler by measuring the delta between the resident set size in samples.
Profiling DMD's Compilation Time with dmdprof
This is a tool + article I wrote in February, but never got around to finishing / publishing until today. https://blog.thecybershadow.net/2018/02/07/dmdprof/ Hopefully someone will find it useful.
Re: Beta 2.082.0
On Wednesday, 17 October 2018 at 12:14:55 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.083.0 release, ♥ to the 48 contributors for this release. Thanks! CppRuntime_* version identifiers - https://dlang.org/changelog/2.083.0.html#cppVersions When is this different from the corresponding CRuntime version? DUB_PACKAGE_VERSION environment variable - https://dlang.org/changelog/2.083.0.html#env_var_package_version The documentation for this one seems rather sparse. - Is the environment variable set or read by Dub? - What is the exact syntax for its contents? - How does it affect the build process? - What are some potential use cases?
Re: Webassembly TodoMVC
On Sunday, 23 September 2018 at 18:36:11 UTC, Joakim wrote: Vladimir mentioned that there's a Musl port to wasm, have you tried it? My knowledge of the intersection of Musl and WASM is that Musl is used as the libc in Emscripten (and, as extension, in Dscripten), and Emscripten/Dscripten can target WASM as well as asm.js / regular ol' JavaScript.
Re: expectations 0.1.0
On Sunday, 2 September 2018 at 06:59:20 UTC, Paul Backus wrote:
expectations is an error-handling library that lets you bundle
exceptions together with return values. It is based on Rust's
Result [1] and C++'s proposed std::expected. [2] If
you're not familiar with those, Andrei's NDC Oslo talk, "Expect
the Expected" [3], explains the advantages of this approach to
error handling in considerable detail.
Sorry, I didn't watch the talk, but this sounds like something
that's been on my mind for a while.
There are generally two classic approaches to error handling:
- Error codes. Plus: no overhead. Minus: you need to remember to
check them. Some languages force you to check them, but it
results in very noisy code in some cases (e.g.
https://stackoverflow.com/a/3539342/21501).
- Exceptions. Plus: simple to use. Minus: unnecessary (and
sometimes considerable) overhead when failure is not exceptional.
Now, Rust's Result works because it forces you to check the error
code, and provides some syntax sugar to pass the result up the
stack or abort if an error occurred. D, however, has nothing to
force checking the return value of a function (except for pure
functions, which is inapplicable for things like I/O).
Please correct me if I'm wrong, but from looking at the code,
given e.g.:
Expected!void copyFile(string from, string to);
nothing prevents me from writing:
void main() { copyFile("nonexistent", "target"); }
The success value is silently discarded, so we end up with a "ON
ERROR RESUME NEXT" situation again, like badly written C code.
One way we could improve on this in theory is to let functions
return a successfulness value, which is converted into a thrown
exception IFF the function failed AND the caller didn't check if
an error occurred.
Draft implementation:
struct Success(E : Exception)
{
private E _exception;
private bool checked = false;
@property E exception() { checked = true; return _exception; }
@property ok() { return exception is null; }
@disable this(this);
~this() { if (_exception && !checked) throw _exception; }
}
Success!E failure(E)(E e) { return Success!E(e); }
Success!Exception copyFile(string from, string to)
{
// dummy
if (from == "nonexistent")
return failure(new Exception("EEXIST"));
else
return typeof(return)();
}
void main()
{
import std.exception;
copyFile("existent", "target");
assert(!copyFile("nonexistent", "target").ok);
assertThrown!Exception({ copyFile("nonexistent", "target"); }());
}
This combines some of the advantages of the two approaches above.
In the above draft I used a real exception object for the
payload, constructing which still has a significant overhead (at
least over an error code), though we do get rid of a try/catch if
an error is not an exceptional situation. The advantage of using
a real exception object is that its stack trace is generated when
the exception is instantiated, and not when it's thrown, which
means that the error location inside the copyFile implementation
is recorded; but the same general idea would work with a
numerical error code payload too.
Any thoughts?
Re: GitHub could be acquired by Microsoft
On Thursday, 7 June 2018 at 05:28:26 UTC, Nick Sabalausky (Abscissa) wrote: I've always felt GitLab was better than GitHub (in large part because they're sensible enough to support self-hosting), so it's tempting to use this as a great reason to move to GitLab. I've been following the discussions (mainly on HN) on the subject, and there are a few arguments against GitLab (i.e. the gitlab.com SaaS) as well. - The company might be purchased by a bigger one in the same way that happened to GitHub. - The conflict of interest between the free and paid tiers means that some issues that are useful for open-source projects won't be available to them, even though they are available at their competitors. - gitlab.com provides features unavailable in the open-source (community) edition to all projects, which means that migrating away from gitlab.com and to a self-hosted instance would be a compromise involving losing features. In any case, I've always thought it was absolutely sick that that even though GitHub/BitBucket/GitLab/Launchpad/etc. all provide basically the same features on top of the standard ***distributed*** version control systems, they are all completely incapable of talking to each other or acting as interchangable viewers on a single set of common project data. So much for the "distributed" in "DVCS". Many people think so too: https://gitlab.com/gitlab-org/gitlab-ee/issues/4517 https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 Unfortunately it looks like the current plan for federation in GitLab will once again be only in the paid version.
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 05:50:26 UTC, Anton Fediushin wrote: I can think of hundreds of things what can go wrong including: forcing users to use Microsoft accounts, advertising own products, changing search to Bing (that's pretty bad one, no idea how I came up with it) and more and more. Something that might be worth being concerned about is that Microsoft might be more strict in policing its online properties than GitHub, so watch out for them shutting down projects/repositories of politically charged subjects, or those e.g. based on reverse-engineered MS code.
Re: A bit more Emscripten
On Tuesday, 8 May 2018 at 08:53:36 UTC, Vladimir Panteleev wrote: https://github.com/CyberShadow/dscripten-tools Progress update: - std.stdio.writeln() works - Using a D main() works (though unittests and static constructors still don't) - WebAssembly output works! - std.allocator works (at least, Mallocator + building-blocks do)
Re: A bit more Emscripten
On Tuesday, 8 May 2018 at 09:51:11 UTC, Mike Franklin wrote:
I've been recently assigned the task of building a web-based
Ladder Logic editor/compiler
(https://en.wikipedia.org/wiki/Ladder_logic). This would not be
a short-lived application, however.
Hmm, sounds like this would be an interactive application that
would need access to the HTML DOM. Currently, this isn't directly
possible - when running in an asm.js VM, there is no D type to
represent a JavaScript object. It is possible to call out to /
eval JavaScript, though, so perhaps it could be possible using a
shim, where a JavaScript array holds JavaScript/DOM objects, and
D refers to them by index.
I'm not sure if I would be much help with this, but know that
there is demand for it. I think the difficult part would be
porting the D runtime to "browser" environment, and I'm not
sure what's involved with that, especially given all platform
dependencies that the runtime is currently bound to.
Here are some of the challenges with getting D to run on
emscripten:
- Emscripten is neither Windows nor Posix, which causes most
version(platform){...}else... blocks to fail. Emscripten does
provide a libc (based on glibc, I think) which even abstracts
some things like I/O and the filesystem, but the feature set is
definitely less complete than the platforms we currently support,
so there's lots of stubbing involved.
- As a result of this, some parts of Phobos simply have no way of
working correctly. For example, a good part of std.math concerns
itself with the floating-point environment and flags, but in our
case these all come down to "whatever the browser gives you" -
which is probably standardized, but not under your control. So,
these definitions would need a version(dscripten){}else wrapper.
- In theory, garbage collection might be made to work, with
extensive help from the compiler. The problem is that we are
still using JavaScript's stack, which means we can't scan it for
pointers. It could be worked around by getting the compiler to
also place references to heap objects somewhere else, like a
second stack. For the short term, a practical approach would be
to use @nogc memory allocation / container libraries
(std.allocator etc.) and minimize GC allocations (e.g. closures
are still nice to have).
- Exceptions do not work - throwing simply aborts. C++ exceptions
do work in emscripten, so I think this could be made to work if a
compiler guru spends some time on it.
- Threads look like they could be made to work - emscripten seems
to have some wrappers to create/control Web Workers through a
libpthreads-like API.
A bit more Emscripten
https://github.com/CyberShadow/dscripten-tools This builds a little upon Sebastien Alaiwan (Ace17)'s excellent prior work of putting together a toolchain for compiling D to JavaScript / asm.js. Improvements include a DMD-like driver and rdmd wrapper, meaning that most tools that know how to use dmd/rdmd will be able to also use this toolchain. Dub is an example. Currently the focus is on headless scripts - Web Workers and Node. Also included are some hacked up parts of Phobos/Druntime. Generally such environments are restricted to @nogc stuff, but I wanted to see how far we can get without prior restrictions. As a result, things like Appender and format(...) (i.e. formatting to the heap) work. Of course, garbage collection is unavailable - it's using the "manual" GC implementation (allocates only), though considering most webpages are short-lived, it might not be a problem for many use cases. I heard there was a bit of general interest on the subject, so would be interesting to hear about more potential use cases.
Re: run.dlang.io can now display ASM + AST + IR
On Sunday, 14 January 2018 at 04:18:41 UTC, Seb wrote: It was bad weather in Munich on Saturday, so run.dlang.io got a couple of new cool features: Very cool, thanks!
Re: Beta D 2.075.1
On Thursday, 10 August 2017 at 20:15:12 UTC, Walter Bright wrote: It could use all of the runtime library functions added to the index, instead of just a smattering. This should be the case as of a few years. Is there anything missing specifically that you can point out?
Re: Beta D 2.075.1
On Thursday, 10 August 2017 at 17:24:41 UTC, Martin Nowak wrote: Try dman 2.074.0, opens http://dlang.org/changelog/2.019.html#2.074.0. That would be a bug. It extends to the generated CHM's index as well, so we should fix it. So in the end the search bar works much better for me. If dman doesn't find the exact thing you're looking for, it falls back to a Google search, which is what the website search uses as well.
Re: Beta D 2.075.1
On Tuesday, 8 August 2017 at 14:57:58 UTC, Daniel Kozak wrote: https://issues.dlang.org/show_bug.cgi?id=17731 Thanks. I've submitted a fix.
Re: Beta D 2.075.1
On Tuesday, 8 August 2017 at 08:41:15 UTC, Martin Nowak wrote: This release does not ship with the dman tool due to an unresolved issue. What's the problem with dman?
Re: Release D 2.075.0
On Thursday, 20 July 2017 at 07:19:03 UTC, Patrick Schluter wrote: version 2.067 that still had the C++ frontend took more than 100 seconds. I think if the backend is translated to D, building the compiler will take not more than 2 seconds. To put it in perspective, building gcc with only C and C++ support takes around 15 minutes on my machine and clang+llvm is ridiculously slow to compile with not far from 1 hour compilation. Ok, these projects are much, much bigger but that doesn't change the fact that C++ is slow to compile. One day, a colleague and I were working on migrating a large MSVC project to LLVM. Due to various reasons (using git master / bisecting regressions), this involved building LLVM from source code, which took an exorbitant amount of time (about 40 minutes IIRC). Later that day, I mentioned in passing that we might make building D part of the build process (of a project using D code), since building the compiler took only 3 seconds on my machine. To quote my colleague: "Whaaat? How can a compiler compile in 3 seconds?!"
Re: static foreach is now in github master
On Tuesday, 18 July 2017 at 10:02:10 UTC, Seb wrote: And thanks to dmd-nightly, also on run.dlang.io: https://run.dlang.io/?compiler=dmd-nightly=void%20main(string%5B%5D%20args)%0A%7B%0A%20%20%20%20static%20foreach%20(i;%20%5B0,1,2,3%5D)%0A%09%7B%0A%20%20%20%20%09pragma(msg,%20i);%0A%09%7D%0A%7D This link doesn't work, looks like it cuts off at the first ; ...
Re: DMD now has colorized syntax highlighting in error messages
On Sunday, 14 May 2017 at 19:11:32 UTC, Basile B. wrote: Yes +1 for configurable. IDEs already parse and make things clickable. It's not just +1, it's mandatory. If you implement this you must add a new compiler switch. No problem, it could only print out the line if the output is a terminal, same as for how it decides whether to output colors by default.
Re: DConf 2017 Hotel - book now!
On Thursday, 2 March 2017 at 02:24:50 UTC, Walter Bright wrote: http://www.ibis.com/gb/hotel-5694-ibis-berlin-neukoelln/index.shtml Last year, some people booked late and it was full and they had to stay at another hotel. Aaand it's sold out. 2 months before the conference. Wow :)
Re: Call for arms: Arch Linux D package maintenance
On Thursday, 16 February 2017 at 19:58:47 UTC, Rory McGuire wrote: I am planning on asking to become TU for the dlang packages in community. I've been building and working with the current packages and making my own packages to make sure I know what I'm getting in to. Sounds great, good luck!
Re: Call for arms: Arch Linux D package maintenance
On Wednesday, 1 February 2017 at 12:47:51 UTC, Dicebot wrote: As I have previously announced (http://forum.dlang.org/post/o6fbbu$1qli$1...@digitalmars.com), I am stepping down from maintaining Arch Linux packages for D. Hi, wondering what the outcome of this was. Also, how big is the maintenance burden? Is there more to it than a version number bump & push on each release? Perhaps it could be automated or integrated into the release process. FWIW, I've got a few packages on AUR: https://aur.archlinux.org/packages/?SeB=m=CyberShadow
Re: Release D 2.072.0
On Monday, 31 October 2016 at 20:35:24 UTC, Martin Nowak wrote: and I did take care of that forward reference bug (Issue 16607). Thanks again for that. That one would've actually kept me from upgrading for my current project.
Re: daffodil, a D image processing library
On Friday, 1 July 2016 at 11:09:49 UTC, Relja Ljubobratovic wrote: When loading images, bit depth should be determined in the runtime, depending on the image you'd be loading at the moment. Or am I wrong? Generally most use cases for using an image library can be divided into: 1. You have full control over the images being loaded. This is the case when you're loading graphical assets for your application which otherwise doesn't concern itself for graphical work. 2. You're writing an image editor, or some other program that processes images out of your control, i.e. supplied by the user. Generally the first case is by far the most common one (think GUI applications, video games...). In this case, since you already know or have control over the format of your images, there is no reason to burden your application with performance-killing abstraction layers - you should load and work in the format that your images already are. Additionally, if necessary, it is easy to build such a runtime abstraction layer over a templated library by creating an algebraic type from only the set of formats that you want to support. Doing the inverse is impossible. In case anyone from this thread haven't seen it, I have my own image library, which I wrote about here: https://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/
Re: foo => "bar" key/value literals in D!
On Saturday, 11 June 2016 at 11:15:43 UTC, ArturG wrote: On Saturday, 11 June 2016 at 09:07:43 UTC, Andrei Alexandrescu wrote: No, both are nice to have. If one name is needed for both, "args" is indeed a good commonality. "Invoke function f with these args" and "Construct an object of type T with these args". The problem is it's not very intuitive in usage. Perhaps "call" for functions and "make" for objects are better. If we add these to std.experimental.functional and std.experimental.conv and they get a lot of usage we might make a small change to the language. Andrei would'nt it be possible to take the type as a runtime param and support struct, class and all callables? e.g. ().args!(a=>5, b=>6); Taking an address creates a function pointer, which loses the argument names. (Doesn't it?)
Re: foo => "bar" key/value literals in D!
On Tuesday, 31 May 2016 at 06:21:03 UTC, Andrei Alexandrescu wrote: On 5/27/16 10:17 PM, Taylor Hillegeist wrote: On Friday, 27 May 2016 at 18:10:59 UTC, Vladimir Panteleev wrote: On Monday, 23 May 2016 at 19:00:40 UTC, Adam D. Ruppe wrote: Have I gone completely mad?!?! Yes, though what does it have to do with this thread? :D This is by far the most appealing way to implement named arguments that I've seen so far: https://github.com/CyberShadow/ae/blob/master/utils/meta/args.d This is very nice... way more clean than I imagined possible. s/args/make/g and we have a nice function for std.conv. -- Andrei Do I gather from that that you propose adding only the overload that creates structs?
Re: foo => "bar" key/value literals in D!
On Wednesday, 8 June 2016 at 09:19:46 UTC, John wrote: On Friday, 27 May 2016 at 18:10:59 UTC, Vladimir Panteleev wrote: This is by far the most appealing way to implement named arguments that I've seen so far: https://github.com/CyberShadow/ae/blob/master/utils/meta/args.d Another cool thing this enables: object initializers. Already in the link you quoted, FYI.
Re: foo => "bar" key/value literals in D!
On Monday, 23 May 2016 at 19:00:40 UTC, Adam D. Ruppe wrote: Have I gone completely mad?!?! Yes, though what does it have to do with this thread? :D This is by far the most appealing way to implement named arguments that I've seen so far: https://github.com/CyberShadow/ae/blob/master/utils/meta/args.d
Re: Introducing mach.d, the github repo where I put whatever modules I happen to write
On Wednesday, 25 May 2016 at 22:19:28 UTC, Seb wrote: A bit off-topic, but I can't help to say it. I know that writing your own library is fun, but something that I see quite often when looking at e.g. https://github.com/adamdruppe/arsd https://github.com/CyberShadow/ae https://github.com/nordlow/phobos-next is that people love to collect and build their own ecosystem, but it would be a lot better if for a specific use-case there's a great dub package or it's part of Phobos. At least for me, here are the main motivators: 1. Trivia. There are a lot of one-liners in ae which although used often and make the code somewhat more readable, would not be suitable for Phobos because you can think of any number of them. 2. Very often I put a function in ae not because I know I'll need it again, but simply because it seems generic enough that it would better belong in a generic library than the specific program I'm writing. This of course leads to functions that are used only once. Sometimes (rarely) I realize that I don't need that function after all, so some functions probably have never been used. 3. Commitment. Making your library for general consumption means proper versioning, upgrade paths and things like that. It's an additional mental burden on top of getting the thing you want done done. That said I did add a dub.sdl file to ae a while ago.
Re: Diamond - MVC / Template engine
On Saturday, 21 May 2016 at 08:20:00 UTC, Bauss wrote: Just finished up the base for Diamond and its initiate state with Github and Dub, as well the first guide on using Diamond with vibe.d for websites. The name is taken :) https://github.com/CyberShadow/Diamond I don't mind though.
Re: D's Auto Decoding and You
On Tuesday, 17 May 2016 at 17:26:59 UTC, Steven Schveighoffer wrote: However, it's perfectly legal for a front function not to be tagged @property. BTW, where is this coming from? Is it simply an emergent property of the existing implementations of isInputRange and ElementType, or is it actually by design?
Re: D's Auto Decoding and You
On Tuesday, 17 May 2016 at 17:26:59 UTC, Steven Schveighoffer wrote: On 5/17/16 1:18 PM, Vladimir Panteleev wrote: On Tuesday, 17 May 2016 at 14:06:37 UTC, Jack Stouffer wrote: http://jackstouffer.com/blog/d_auto_decoding_and_you.html Thanks for writing this. Great article. Some remarks: static assert(is(typeof(s.front()) == dchar)); I believe .front is a property (so some ranges can implement it as a field, not a @property function). Hence, no parens. Right, but s is a string. So front is a function. Then what happened to writing generic code? There is an inconsistency in the compiler for this. If s.front is a function is(typeof(s.front)) will not be what front *returns*, but the function type itself. Unless you tag with @property. However, it's perfectly legal for a front function not to be tagged @property. There is a simple answer to this, and it is to either use ElementType or do what it does (is(typeof(R.init.front.init) T)).
Re: D's Auto Decoding and You
On Tuesday, 17 May 2016 at 14:06:37 UTC, Jack Stouffer wrote: http://jackstouffer.com/blog/d_auto_decoding_and_you.html Thanks for writing this. Great article. Some remarks: static assert(is(typeof(s.front()) == dchar)); I believe .front is a property (so some ranges can implement it as a field, not a @property function). Hence, no parens. So, why is typeof(s.front) == dchar. Question mark? In plain English, this means when iterating over strings in D, D will look ahead in the string and combine any code units that make up a single code point. Perhaps clarify that this only applies to ranges. `foreach` on a string will iterate over chars, but you can iterate over code points if you specify the dchar type explicitly. More confusing text on the same issue lower, and in the intro: Iterating a char array with C style for loops produces different results than foreach loops due to auto decoding. One feature of D that is confusing to a lot of new comers is the behavior of strings in relation to range based features like the foreach statement and range algorithms. --- E.g. for ë the code units C3 AB (for UTF-8) would turn into a single code point. Perhaps choose a character that is not also expressable via composite characters, to avoid potential for confusion. string s = "cassé"; Ditto (unless the goal was to complement the example from my .d file below) These glaring inconsistencies are the cause of a lot of confusion for new comers. (Opinion) I would say that they also cause issues in generic code. Every time one wants a generic algorithm to work with both strings and ranges, you wind up special casing via static if-ing narrow strings to defeat the auto decoding, or to decode the ranges. Case in point. Link to the exact SHA to prevent the link from getting outdated. On Github, just hit 'y' on your keyboard to go to the "permalink" version. Auto decoding has two choices when encountering invalid code units: throw, or produce an error dchar like std.utf.byUTF does. (Aside) This was an interesting discussion on the subject: https://issues.dlang.org/show_bug.cgi?id=14519 However, in my opinion D is too far along to to suddenly ask people "to to" --- Some more info / links on the subject I collected a few years ago: http://wiki.dlang.org/Language_issues#Unicode_and_ranges
Re: The D language online tour - tour.dlang.org
On Monday, 16 May 2016 at 17:32:06 UTC, André wrote: Hi, after another round of polishing, bug fixing, very useful user contributions and suggestions, I'd like to present the new home of the D language online tour: http://tour.dlang.org/ Awesome! As I mentioned on GitHub, we should aim towards making the tour the target of the "Learn" link in the top navigation bar. So, how about integrating the contents of http://dlang.org/getstarted.html into the first page (or first few pages) of the tour? Thank you very much to the D foundation for hosting this service! Hey, this is news to me. What are the details?
Re: To all DConf speakers: please upload slides!
On Thursday, 12 May 2016 at 23:14:05 UTC, Leandro Lucarella wrote: Steven Schveighoffer, el 12 de May a las 16:55 me escribiste: On 5/12/16 4:13 PM, Seb wrote: >On Wednesday, 11 May 2016 at 09:17:54 UTC, Dicebot wrote: >>To do the editing of HD videos we need presentation slides >>which are currently scattered over different places. It >>would help a lot to have them all in >>github.com/dlang/dlang.org repo - please submit pull >>requests asap! > >Just a minor complaint - would it be possible for the next >dconf to have the slides (or a link to them) on dconf.org >before the talk starts? Thanks for the great work! I think it's better to not have the slides available until the talk starts. There may be jokes/surprises in the slides that you don't want to give away before the talk happens :) Exactly, I would say it depends on the talk, for my talk I didn't want to provide the slides beforehand ;-) Here's a crazy idea: provide a simple/short URL to the slides as the second slide of your talk (and speak out loud the URL just in case the camera doesn't get it) :) Bonus: getting the slides on the presenting machine becomes easy too. (Just make sure that the relevant software supports the features that your presentation uses, cough...)
Re: 2DRPG - Small console game
On Thursday, 12 May 2016 at 18:30:04 UTC, Vladimirs Nordholm wrote: I have had lots of fun during the development of 2DRPG. There have been many difficulties, but I have learned much from making this game. Sadly this game is Windows only, meaning POSIX users cannot play it. This is due to technical limitations in my own console engine, scone (https://github.com/vladdeSV/scone), which cannot read input on POSIX terminals. If anyone would like to test the game, it would be awesome. Any sort of feedback is always appreciated! I managed to build and run it under wine/wineconsole and make it through one playthrough. The only issue is that all the non-printable characters showed up as euro signs, I guess I may need to play with the font selection some more for that. Games with time limits are not my cup of tea - other than that, it was nice, well done.
DustMite now has -j
By popular demand. https://github.com/CyberShadow/DustMite/compare/e175b95da070d84029f75ba8a15f5d900fb90704...15693cbd5a5c0f47ee9cc68be9dada39b99c3836
Re: To all DConf speakers: please upload slides!
On Wednesday, 11 May 2016 at 09:17:54 UTC, Dicebot wrote: To do the editing of HD videos we need presentation slides which are currently scattered over different places. It would help a lot to have them all in github.com/dlang/dlang.org repo - please submit pull requests asap! I think you mean the https://github.com/dlang/dconf.org repo :) I have a related pull request: https://github.com/dlang/dconf.org/pull/134
Re: Looking for D developers, Saint-Petersburg
On Tuesday, 10 May 2016 at 14:39:27 UTC, drug wrote: I'm curious are there D developers in Saint Petersburg who doesn't mind to make some money? Здравствуй Друг, If the position is likely to remain open for at least some time, I recommend adding this to the job listing page on our wiki: https://wiki.dlang.org/Jobs
Re: Release D 2.071.0
On Tuesday, 5 April 2016 at 22:43:05 UTC, Martin Nowak wrote: Glad to announce D 2.071.0. http://dlang.org/download.html This release fixes many long-standing issues with imports and the module system. See the changelog for more details. http://dlang.org/changelog/2.071.0.html -Martin http://downloads.dlang.org/releases/2.x/2.071.0/dmd.2.071.0.zip is a 404. I know the all-platform .zip files are wasteful, but any practical reason for removing them? Unless the hosting cost is not negligible, breaking existing tools/scripts may not be worth it.
Re: DConf 2016 announces programme, general registration opened thrugh April 22
On Monday, 28 March 2016 at 16:34:55 UTC, Andrei Alexandrescu wrote: The Fourth Annual Conference of the D Programming Language: DConf 2016 May 4 to May 6, 2016 Berlin, Germany http://dconf.org/2016/ Awesome. Is there an official hotel yet?
Re: DigitalWhip
On Saturday, 13 February 2016 at 21:10:11 UTC, Adam D. Ruppe wrote: On Saturday, 13 February 2016 at 20:45:41 UTC, David Nadlinger wrote: Your scripts had bounds checking enabled for LDC but not the other two D compilers. I strongly recommend people to always keep bounds checking enabled in real world programs because it is so useful in keeping programs sane. I agree - but not for all situations. Sometimes it's fine to let programs crash, if performance is important, and the environment is configured to handle that gracefully, or where there is no risk of data loss, such as video games. I think that in the context of a render farm, disabling bounds checking is completely reasonable. Bugs will manifest as crashes or rendering artifacts, and there is no risk of code execution exploits.
