Re: RC buffer
On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei Alexandrescu wrote: I've eliminated all UTF nonsense from https://github.com/dlang/phobos/pull/4878 resulting in a bare reference counted buffer of (qualified) ubyte. The goal is to get the buffer @safe and be able to have a reasonable explanation for each and every cast. (There are no safety annotations currently, but the code passes unittests and supports qualifiers.) No undefined behavior casts should be used (e.g. that cast away immutability), only simple adjustments for realities that the type system is unable to cover. In order to make opAssign safe, a language change will be necessary. Andrei Great goal, I wish you to do it!
Re: Got a post for the D Blog?
On Monday, 31 October 2016 at 03:51:16 UTC, Mike Parker wrote: So far, getting content for the blog has, with a few exceptions, been a process of sending out emails prompted by activity on my radar. This is no problem when it comes to project highlights or other fairly broad topics, but it's highly inefficient for ginning up technical posts on the implementation of specific algorithms, or optimization details, or how a D feature prevented a nuclear meltdown. I want to publish more posts like Andreas's 'Find Was Too Damn Slow, So We Fixed It` [1] (which, by the way, is the most-viewed post so far, just ahead of Joakim's interview with Walter [2]), or Steven's 'How to Write @trusted Code in D' [3], but I need help. If you, or someone you know, have done something interesting with an algorithm or optimization in D, or have used a D idiom to do things in a way that pleasantly surprised you, please let me know. If I think it's something we can work with, I'll help you in putting together a guest post, or something like I do with the project highlights (where I build a post around whatever info you give me). Also, I need news. If you see or hear any D news anywhere outside of the forums -- new projects, research papers, usage at a company, a game using D -- please drop me a line. I'll either get a post together for it or make sure Adam knows about it for 'This Week in D'. I'm also open to ideas for other types of posts, like project highlights, but I'd really like more of the technical stuff. Please send any suggestions to aldac...@gmail.com. Thanks! [1] http://dlang.org/blog/2016/06/16/find-was-too-damn-slow-so-we-fixed-it/ [2] http://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/ [3] http://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/ It's excellent, thanks)
Re: Ever want to compile D on your Android phone? Well, now you can!
On Sunday, 24 January 2016 at 15:12:30 UTC, Joakim wrote: An alpha release of ldc, the llvm-based D compiler, for Android devices is now available. It is best used with the excellent Termux app (https://play.google.com/store/apps/details?id=com.termux=en) and a bluetooth keyboard. ;) Updated test runners, that run most tests from the standard library on any Android device, are also available (results have been reported for everything from a TomTom BRIDGE GPS navigation device to a Huawei Watch): https://github.com/joakim-noah/android/releases/tag/polish You can install a test runner app or run a command-line binary. Please report your results in this thread in the ldc forum, which requires no registration, with the info and format requested there, particularly for Android 4.1 or earlier: https://forum.dlang.org/thread/bafrkjfwmoyriyhmq...@forum.dlang.org If you try out the native compiler, take a look at the README that comes with it for instructions. If you have a D/OpenGL app you'd like to port to Android and submit to the Play Store, let me know if I can help with that process. great, thanks))
Re: newbie problem with nothrow
On Monday, 31 October 2016 at 22:29:19 UTC, Jonathan M Davis
wrote:
On Monday, October 31, 2016 22:20:59 Kapps via
Digitalmars-d-learn wrote:
Assuming you're sure it'll never throw. To enforce this, use
try
{ } catch { throw new Error("blah"); }. You can still throw
errors, just not exceptions (as errors are not meant to be
caught).
I always use assert(0). e.g.
try
return format("%s", 42);
catch(Exception)
assert(0, "format threw when it shouldn't be possible.");
- Jonathan M Davis
have the same problem
Re: Minimizing "reserved" words
On Monday, 31 October 2016 at 20:45:56 UTC, Jacob Carlborg wrote: The "reserved" words I'm referring to are not necessarily keywords in the language but otherwise words that should be avoided, especially for defining methods in aggregates. I'm mostly thinking of built-in properties like .init, .classinfo, .sizeof, .outer and so on. All of the above can be used as variable names. Some of the above names can be used as methods in aggregates but some cannot. Of the above names only "sizeof" cannot be used as a method name. Would it be better to try to minimize these special words and instead use either compiler recognized functions/templates or something like __traits? If they were compiler recognized functions, defined somewhere in druntime, the normal language lookup rules could be used to disambiguate the compiler recognized functions from user defined functions. Or if a __trait is used, that would have it's own namespace and not cause any conflicts. In the latest release of DMD (2.072.0) TypeInfo.init has been deprecate in favor of TypeInfo.initializer. That would not have been needed if .init wasn't a built-in property but instead a compiler recognized function. Thoughts? Too late to change, to much could would break? This information from Wiki, I hope it will be useful. That general reserved words and keywords need not coincide, but in most modern languages keywords are a subset of reserved words, as this makes parsing easier, since keywords cannot be confused with identifiers. In some languages, like C or Python, reserved words and keywords coincide, while in other languages, like Java, all keywords are reserved words, but some reserved words are not keywords – these are "reserved for future use". In yet other languages, such as the older languages ALGOL, FORTRAN and PL/I, there are keywords but no reserved words, with keywords being distinguished from identifiers by other means. This makes parsing more difficult with look-ahead parsers necessary.
