Re: RFC: std.json sucessor
I notice in the docs there are several references to a `parseJSON` and `parseJson`, but I can't seem to find where either of these are defined. Is this just a typo? Hope this helps: https://github.com/s-ludwig/std_data_json/search?q=parseJson&type=Code
Re: Closures and loop scope
Have there been any updates on this issue? I can't seem to find anything else written about it, and it's still wreaking havoc with my team.
Re: DMD 2.066.1 is missing in the Digitalmars FTP
On Tuesday, 2 December 2014 at 17:10:12 UTC, Jacob Carlborg wrote: DMD 2.066.1 is missing in the Digitalmars FTP. The release candidates are present but the final release is missing. This breaks DVM. Yes please! The dmd chocolatey package[1] just downloads and unpacks the Windows zip from the FTP site, so until that's up, choco users won't have access to 2.066.1. [1] https://chocolatey.org/packages/dmd
Re: Idea/request: If you have a DUB project, add a code.dlang.org badge to README
On Tuesday, 30 December 2014 at 21:22:01 UTC, Kiith-Sa wrote: (accidentally posted this into D.learn first, was intended to be here) A few weeks/months ago someone here mentioned that it'd be good if DUB projects linked to code.dlang.org to help anyone who runs into such a project quickly discover other D projects. MAny GitHub projects have "badges"/"shields" on top of their READMEs - little image strips showing things like continuous integration status, code coverage, etc. There's also a service generating these: shields.io I generated a simple "listed at| code.dlang.org" shield, and added it to my project READMEs as a link pointing to code.dlang.org for example, see D:YAML README: https://github.com/kiith-sa/D-YAML You can do the same by either linking to or downloading the shield: https://img.shields.io/badge/listed%20at-code.dlang.org-red.png (used red... because mars) and putting the image (whether as a link to shields.io or your own copy) into your README. It's not likely to be a huge improvement, but I expect it *can* help people notice more D projects and it's trivial to do. Thank you for raising awareness of this! It'd be great to see more awareness for dub from people not intimately familiar with D. I also currently have a PR pending with dub-registry[1] to add a download stats API, so that we could have the same badges as all of the other package managers. As soon as that PR gets merged, a friend and I are going to PR download and version badges to shields.io directly. The other common badge type, whether or not dependencies are up to date, could also be pretty trivial to add to the API. [1] https://github.com/D-Programming-Language/dub-registry/pull/76
Re: Casts and some suggestions to avoid them
On Wednesday, 9 April 2014 at 11:27:24 UTC, Marco Leise wrote: Am Tue, 08 Apr 2014 21:30:08 + schrieb "Colden Cullen" : One issue I've had huge amounts of trouble with is casting to and from shared. The primary problem is that most of phobos doesn't handle shared values at all. If there was some inout style thing but for shared/unshared instead of mutable/immutable/const that would be super helpful. Can you explain what level of atomicity you expect? 1) what atomicity? 2) atomic operations on single instructions 3) the whole Phobos function should be atomic with respect to the shared values passed to it 4) some mutex in your "business logic" will make sure there are no race conditions Shared currently does two things I know of (besides circumventing TLS): - simply tag a variable as "multi-threaded" so you don't forget that fact - the compiler will not reorder or cache access to it So what would it add to Phobos if everything accepted shared? In particular how would that improve thread-safety, which is the aim of marking things shared? It doesn't, because only the functions in core.atomic make sense to accept shared. The reason is simply that they are running a single instruction on a single shared operand and not a complete algorithm. Anything longer needs to be implemented with thought put into race conditions. Example: x = min(a, b); Say a == 1 and b == 2. The function would load a from memory into a CPU register, then some other thread changes a to 3, then the function compares the register content with b and returns 1, which is no longer correct at this point in time. It is not that it can never be what you want, but that min() alone cannot decide what is right for YOUR code. So instead of passing shared values to generic algorithms, we only really need UNSHARED! I was under the impression that casting away from shared was bad form. Is this not true? I don't expect any atomicity (at least from the standard library). All locking should be done by the user. I just want to not have to cast away from shared whenever using the standard library. I'm not asking for guaranteed atomicity, just something that says that this function may take a shared value. I would like to reiterate that I think that having to cast away from shared is a bad solution.
Re: Ready for testing: vibe.d 0.7.26-alpha.3
On Wednesday, 14 October 2015 at 06:29:03 UTC, Brad Anderson wrote: [snip] https://github.com/rejectedsoftware/vibe.d/pull/1293
Re: DIP 84: Static Inheritance
On Tuesday, 10 November 2015 at 10:45:16 UTC, Atila Neves wrote:
[snip]
Updated.
Atila
As long as we're talking about syntax features that help this
emulate regular inheritance, would it be worth adding a feature
like this:
template MySuperType(T)
{
enum MySuperType = validate!T;
}
void doAThing(MySuperType T)(T val) { }
That would effectively lower to:
void doAThing(T)(T val) if(__traits(compiles, MySuperType!T)) { }
with better error reporting? This would certainly make the code
more readable, and would simplify the conditional dramatically if
you had more than 1 or 2 template parameters.
