Re: Weak Purity Blog Post
Yeah, there's a lot more stuff I could have talked about, but I think I'll leave it for other posts. About testing, I think the way protection works in D (i.e., private members are accessible within the same file) is important, too. I was a bit suspicious of that feature when I first looked at D (coming from C++) but now I actually like the kind of project structure it leads to. I think better testability is just one of the advantages, but I'll write up a full blog post sometime.
Re: Beta D 2.071.0-b2
On Wednesday, 30 March 2016 at 12:04:19 UTC, Basile B. wrote: On Wednesday, 30 March 2016 at 11:03:51 UTC, Martin Nowak wrote: Second beta for the 2.071.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.0.html Please report any bugs at https://issues.dlang.org -Martin Two regressions found in previous beta are now fixed. Otherwise NAD. Actually this morning I've setup and tested 2.070.2 instead of the beta and now, with the right version, one of the regression is still there. Unfortunately I was not able to make a good report: https://issues.dlang.org/show_bug.cgi?id=15836
Re: Weak Purity Blog Post
On Monday, 28 March 2016 at 01:44:02 UTC, sarn wrote: D's implementation of functional purity supports "weak" purity - functions that can mutate arguments but are otherwise traditionally pure. I wrote a post about some of the practical benefits of this kind of purity: https://theartofmachinery.com/2016/03/28/dirtying_pure_functions_can_be_useful.html Nice article. A suggestion: The point about improved testability when designing for purity is well made. In D, this is further supported by the ability to write and place unit tests alongside the functions themselves. That's my personal opinion at least - because unit test are so easy to write in D, it encourages design for testability. My suggestion is to add a note about this to the post. --Jon
Re: Blog article on new import changes
On Tue, Mar 29, 2016 at 11:25:27AM -0400, Steven Schveighoffer via Digitalmars-d-announce wrote: > I anticipate 2.071.0 is going to cause a lot of deprecation messages > and strange errors to occur, due to the fixes of very long-standing > import bugs. > > I wrote a blog post (actually my first ever) on this, let me know what > you think (and please, any clarifications/errors, let me know): > > http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/ Excellent, thanks for writing this up! T -- Computers are like a jungle: they have monitor lizards, rams, mice, c-moss, binary trees... and bugs.
Re: Blog article on new import changes
On 3/30/2016 5:58 AM, Steven Schveighoffer wrote: Thanks for the feedback. And thanks for writing the article. Much appreciated.
Re: simple VFS implementation
p.s. it's only for opening files with known names and doing file i/o. it doesn't support other FS operations (like getting list of files, or file renaming), as i wrote it for using in my game engines, and i don't need such operations there. so i won't add that, it's out of scope of the library.
Re: simple VFS implementation
oops. almost forgot to mention that it works only with POSIX systems now. windoze port *may* be done in the future (it's not that hard — basically, replace fopen/fseek/etc. imports and calls). sure, you can DIY and send me a patch too.
simple VFS implementation
here[1] you can get a simple VFS system (yep, another one!). it introduces `VFile` struct (kinda like `std.stdio.File`, but with less features), which can wrap your own custom streams, `std.stdio.File`, libc `FILE*`, integer file descriptor... actually, anything you'll do a simple wrapper for. it's designed in the spirit of `fopencookie()`. also it includes VFS features like "pak file registration", and built-in ZIP reader. ZIP reader doesn't use `std.zip`, and doesn't unpack the whole file in memory. it is even possible to register ZIP inside ZIP as "pak" file! ;-) also, it has functions to read and write numbers of various sizes in both endiannesses. VFile i/o is thread-safe (but not VFile itself!) works with DMD 2.070+ GNU GPL. i wanted you to read the whole text to find this, yeah. 1. http://repo.or.cz/iv.d.git/tree/HEAD:/vfs
Re: Beta D 2.071.0-b2
On Wednesday, 30 March 2016 at 16:00:34 UTC, Luís Marques wrote: On Wednesday, 30 March 2016 at 15:48:28 UTC, John Colvin wrote: That would be me. Waiting for merge: https://github.com/Homebrew/homebrew/pull/50539 Thanks! Would it be against the homebrew spirit for the DMD recipe to link to some URL like <...lastest-devel.tar.gz>? After all, that already happens with the --HEAD version, which doesn't link to any specific git commit. That way we wouldn't have to wait for the homebrew merges. There's the issue of the hash, but the --HEAD version doesn't have that either, and https://dlang.org should be trusted. I'm 99.9% certain the Homebrew core devs wouldn't allow something like that.
Re: Beta D 2.071.0-b2
On Wednesday, 30 March 2016 at 15:48:28 UTC, John Colvin wrote: That would be me. Waiting for merge: https://github.com/Homebrew/homebrew/pull/50539 Thanks! Would it be against the homebrew spirit for the DMD recipe to link to some URL like <...lastest-devel.tar.gz>? After all, that already happens with the --HEAD version, which doesn't link to any specific git commit. That way we wouldn't have to wait for the homebrew merges. There's the issue of the hash, but the --HEAD version doesn't have that either, and https://dlang.org should be trusted.
Re: Beta D 2.071.0-b2
On Wednesday, 30 March 2016 at 13:04:08 UTC, Luís Marques wrote: On Wednesday, 30 March 2016 at 11:03:51 UTC, Martin Nowak wrote: Second beta for the 2.071.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.0.html Please report any bugs at https://issues.dlang.org -Martin Who maintains the homebrew recipe? The --devel package is still at beta 1. That would be me. Waiting for merge: https://github.com/Homebrew/homebrew/pull/50539
Small rdmd wrapper for windows
Hi, I made a simple wrapper around rdmd, which can be used to make .d files executable on windows and supports import paths. (A bat and a .d file) Not really a big announcement, but maybe useful to some of you. https://github.com/hardliner66/rdmd_windows
Re: Beta D 2.071.0-b2
On Wednesday, 30 March 2016 at 11:03:51 UTC, Martin Nowak wrote: Second beta for the 2.071.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.0.html Please report any bugs at https://issues.dlang.org -Martin Who maintains the homebrew recipe? The --devel package is still at beta 1.
Re: Blog article on new import changes
On 3/29/16 11:08 PM, xenon325 wrote: On Tuesday, 29 March 2016 at 15:25:27 UTC, Steven Schveighoffer wrote: I anticipate 2.071.0 is going to cause a lot of deprecation messages and strange errors to occur, due to the fixes of very long-standing import bugs. I wrote a blog post (actually my first ever) on this, let me know what you think (and please, any clarifications/errors, let me know): http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/ 1. In addition, importing a module using static, renamed, or selective imports, then the module was imported publicly, even though it was supposed to be private. Not an English speaker, but this doesn't sound right (at least stylistically). Reread it several times, but I couldn't get the meaning of the sentence, until opened bug report. Definitely some grammar issues there. New reworded sentence: In addition, when importing a module using static, renamed, or selective imports, the symbols imported were incorrectly made public to importing modules. Sound better? 2. With 2.070.2 and prior versions, compiling this works just fine. With 2.071.0 and above, you will get either a deprecation warning, or an error. With 2.070.2, this compiled just fine. [...] With 2.071.0 and above, this will trigger a deprecation warning. In the future, the code will trigger an error. In 2.070.2, this produces no warning or error. In 2.071.0 and beyond, this will produce a deprecation warning, and eventually an error. Not sure if it's worth it to repeat after each example. Feels redundant. I think it's important to state the previous and new behavior, even though it's always the same. It does sound redundant, but makes it easier to understand. 3. I think it's OK to write just major compiler versions, no need for patch version: 2.070 and 2.071 Yes, I did that. Thanks for the feedback. -Steve
Re: Beta D 2.071.0-b2
On Wednesday, 30 March 2016 at 11:03:51 UTC, Martin Nowak wrote: Second beta for the 2.071.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.0.html Please report any bugs at https://issues.dlang.org -Martin Two regressions found in previous beta are now fixed. Otherwise NAD.
Beta D 2.071.0-b2
Second beta for the 2.071.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.0.html Please report any bugs at https://issues.dlang.org -Martin
Re: Weak Purity Blog Post
On Monday, 28 March 2016 at 01:44:02 UTC, sarn wrote: I wrote a post about some of the practical benefits of this kind of purity: https://theartofmachinery.com/2016/03/28/dirtying_pure_functions_can_be_useful.html Great. It would be nice if you added a section that discusses purity in collaboration with allocators. See discussions: http://forum.dlang.org/post/yvwtjybwphxovrxav...@forum.dlang.org http://forum.dlang.org/post/ejaarbdzcqgqhkxla...@forum.dlang.org and https://github.com/D-Programming-Language/druntime/pull/1183#issuecomment-202444315
Re: Blog article on new import changes
On 03/29/2016 05:25 PM, Steven Schveighoffer wrote: > I wrote a blog post (actually my first ever) on this, let me know what > you think (and please, any clarifications/errors, let me know): > > http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/ Thanks
Re: Beta D 2.071.0-b1
On 03/28/2016 10:54 PM, deadalnix wrote: >> This doesn't look like a bugfix or anything urgent, so it seems like >> it can wait for 2.072. > > This is type system breaking, if that is not important or a bugfix, I'm > not sure what is. The PR didn't address the stable branch, but also missed the merging of master, and thus isn't beta tested. It fixes an issues that is already 16 month old. We're releasing every 2 month. Please take care of landing fixes in time on the right branch (stable), just wait for the next release, or use the nightly. -Martin
Re: Weak Purity Blog Post
On Monday, 28 March 2016 at 09:59:12 UTC, ag0aep6g wrote: On 28.03.2016 03:44, sarn wrote: https://theartofmachinery.com/2016/03/28/dirtying_pure_functions_can_be_useful.html From there: Well, you can get the usual (“strong”) purity guarantee just by making all pointer or reference type arguments const. Indirections in the return type also play into this. David Nadlinger explains this in his article on the matter: http://klickverbot.at/blog/2012/05/purity-in-d/#indirections-in-the-return-type Thanks. I updated the post.
