Re: D is dead
On 8/24/18 10:02 AM, David Nadlinger wrote: On Friday, 24 August 2018 at 03:53:38 UTC, David Nadlinger wrote: […] All this is not to say that nothrow constructors aren't a good idea, though. This was meant to say nothrow DEstructors, as hopefully obvious from context. —David I was about to throw down some constructive criticism, but you caught it early ;)
Re: Is @safe still a work-in-progress?
On 8/17/18 7:26 AM, H. S. Teoh wrote: It will continue to be a problem as long as @safe is implemented via blacklisting, because every single time there's a new language feature, there's a chance that a loophole is introduced into @safe. And that's not counting the combinatorial explosion of existing language features that might lead to @safe loopholes, that we simply haven't thought of yet. It's like allowing anyone to enter your house freely except those few people whom you've explicitly named. You can't possibly expect *not* to get robbed that way. We should tag bugs like these as #safecracking
Re: D course material
On 3/13/18 2:08 PM, aberba wrote: On Tuesday, 13 March 2018 at 17:20:57 UTC, Meta wrote: On Tuesday, 13 March 2018 at 12:39:24 UTC, Dmitry Olshansky wrote: [...] Honestly I'd recommend TDPL. It's got a lot of good real-world examples, including some OOP ones, but more importantly examples that demonstrate concurrent programming, generic programming, procedural, and I think a few functional examples as well. Basically, it covers a very broad area in one book while also teaching you D. Boring stuff IMO. Interesting that you found it boring--I found it to be the opposite. It is one of the few programming books that I can read for enjoyment.
Re: Advent of D
On 3/6/18 11:09 AM, Jordi Gutiérrez Hermoso wrote: I wrote a blog post about working on Advent of Code in D. You can read it here: http://jordi.inversethought.com/blog/advent-of-d/ I really enjoyed this. Thank you!
Re: State of D: The survey is killing man, way too much
On 3/3/18 8:08 AM, 0x wrote: The D survey is killing maan! Those are lots of questions in there If I ever get hold of the people behind it... Is it a coincidence that your user handle is "negative one"? ;)
Re: Dub, Cargo, Go, Gradle, Maven
On 2/21/18 10:30 AM, H. S. Teoh wrote:
I think the ideal situation straddles the divide between declarative
build specs and a full-fledged general programming language. You don't
want it to get too general, lest you end up with the build equivalent of
spaghetti code where the build script becomes unreadable and
unmaintainable. OTOH a purely declarative approach is limited by how
well the DSL is designed. An insufficiently-expressive declarative
language leads to much frustration when you find yourself unable to
express something that you need to do with your build.
Working in the Java world, I was extremely happy when I discovered
Gradle. It looks declarative thanks to the Groovy language, but you can
easily mix 'n' match more imperative code inline.
For a taste of Gradle, here's a Java-centric build file from their
getting-started guides [1]:
```
apply plugin: 'java'
apply plugin: 'application'
repositories {
jcenter()
}
dependencies {
compile 'com.google.guava:guava:21.0'
testCompile 'junit:junit:4.12'
}
mainClassName = 'App'
```
And here's a C++ one:
```
apply plugin: 'cpp'
model {
components {
main(NativeExecutableSpec)
}
}
```
Of course in the real world build files get bigger and more complex, but
to me they tend to remain very readable.
Comparing Java's Maven and Gradle (and in the JS world, Grunt and Gulp)
have given me a strong preference for code-based build scripts, as long
as they remain readable.
[1]: https://gradle.org/guides/#getting-started
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On 2/2/18 1:38 PM, welkam wrote: On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote: ** Wall of text ** I dont post here often but... Most of what you complain is known already and/or not entirely correct. People who work on D are not some glue sniffing brain dead individuals that are incapable of understanding that documentation is not perfect, library support is lacking and user experience is not at the same level as C#. That and more are known here. Over the years that I lurked here I saw many people come on forums and complain about things that are obvious and say them in a way that indirectly imply incompetence of core contributors. Things don't work not because of incompetence but because there is not enough people working on things. Thats why you get answers you get. To fix problems we need people who work so either you become one (fix it yourself) or get some one else to work (pay money). The entire D project is fueled by coffee and dislike of C/C++ and its amazing that it achieved so much with so little It is pretty amazing, and it's a testament to how appealing the D language can be, even with all its surrounding pain points. As a long time lurker it seems like I see posts like Benny's more often recently than I recall seeing in years past. This makes me happy--to me it's a sign that more people are seriously considering D than used to. I also think it's good to be reminded of what newcomers' pain points are, and I'm glad Benny took the time to list his.
Re: Quora: Why hasn't D started to replace C++?
On 1/31/18 9:13 AM, John Gabriele wrote: On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote: On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote: And 3 different installation method's depending on the platform. Windows: DMD installer, LDC manually extract zip and setup path, GDC ... That's only an issue on Windows. For Posix there's the official install.sh script [1]. [1] https://dlang.org/install.html I've never seen that page. Would've helped me to see it earlier. The D download page should include a blurb with a link to that install page. I tried going to github.com/dlang/dlang.org, finding the download page, and adding a blurb+link to install.html above those `curl ... install.sh` commands, but that download.dd page is written in a format I'm not familiar with. It's difficult to read, and appears quite clumsy to write as well. It surprises me that D docs are written in that ddoc macro format --- especially for standalone docs like the download page. I think people unfamiliar with D have a perception of D as being this older language from times past, before C++11, and using ddoc for docs instead of markdown contributes to this perception. Let me know if you'd like help in translating D website and doc pages from ddoc to markdown. I'm working on adding Markdown support to DDoc. If my changes are accepted it could make these kinds of edits easier, without having to change the whole website at once. Ages ago I helped redesign the website, which involved messing with DDoc macros. I have to agree that DDoc macros aren't always the friendliest.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On 1/26/18 5:50 PM, Dgame wrote: On Saturday, 27 January 2018 at 00:13:51 UTC, Benny wrote: On Saturday, 27 January 2018 at 00:08:17 UTC, Benny wrote: * Rust: Jetbrain IntelliJ + Rust plugin. It looks like it has become a official supported plugin by Jetbrain. Works perfectly out of the box. Impressive results and issue hinting. https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-other-jetbrains-ides/ Yep, i was right. Its now a official support plugin by Jetbrain. And no offense but i doubt it has anything to do with Mozilla officially backing Rust but more a sign of popularity. Just as how Go got its own Editor by Jetbrain. My impression so far is that most of the D users love to program in a tiny editor without the features which modern IDE's gives you. That's impressive, but outdated and even a bit silly if the project is bigger. In any company I've been so far we've used IDE's, because their feature-set and tools take so much work away from you - I don't want to miss them anymore. Nowadays, the majority of programmers who are willing to try new/others programming languages, think so too. I'm somewhat sure that this unneccessary hurdle is one of D's biggest mistakes. As an IDE junkie I've noticed this correlation in the past too. I wonder which direction the causation runs--does D tend to appeal to the no-IDE crowd, or do IDE-prefering people abandon D since there hasn't been great IDEs support? Regardless I'm very pleased by the recent trends. The vs-code plugins are good and getting better, and DMD as a library should enable simpler and more complete language support in any IDE. I believe we're getting closer to the point where IDE junkies like me won't feel somewhat short-changed, and that's impressive for a community-driven language like D.
Re: Lazily parse a JSON text file using stdx.data.json?
On 12/30/17 8:16 PM, Marco Leise wrote: There is also the JSON parser from https://github.com/mleise/fast if you need to parse 2x faster than RapidJSON ;) Nice, I'll take a look. My original post was mainly to express how surprised I was that one of D's front-page features was, for me, impossible to get working in this context. I posted in hopes that more experienced folks might consider making fixes to help smooth future attempts by others. I realize that compile-time ranges are not runtime interfaces like many languages provide for iteration, but right now ranges seem too hard to get right when it feels like they should just work.
Re: Lazily parse a JSON text file using stdx.data.json?
On 12/17/17 3:28 AM, WebFreak001 wrote: On Sunday, 17 December 2017 at 04:34:22 UTC, David Gileadi wrote: uh I don't know about stdx.data.json but if you didn't manage to succeed yet, I know that asdf[1] works really well with streaming json. There is also an example how it works. [1]: http://asdf.dub.pm Thanks, reading the whole file into memory worked fine. However, asdf looks really cool. I'll definitely look into next time I need to deal with JSON.
Lazily parse a JSON text file using stdx.data.json?
I'm a longtime fan of dlang, but haven't had a chance to do much in-depth dlang programming, and especially not range programming. Today I thought I'd use stdx.data.json to read from a text file. Since it's a somewhat large file, I thought I'd create a text range from the file and parse it that way. stdx.data.json has a great interface for lazily parsing text into JSON values, so all I had to do was turn a text file into a lazy range of UTF-8 chars that stdx.data.json's lexer could use. (In my best Clarkson voice:) How hard could it be? Several hours later, I've finally given up and am just reading the whole file into a string. There may be a magic incantation I could use to make it work, but I can't find it, and frankly I can't see why I should need an incantation in the first place. It really ought to just be a method of std.stdio.File. Apparently some of the complexity is caused by autodecoding (e.g. joiner returns a range of dchar from char ranges), and some of the fault may be in stdx.data.json, but either way I'm surprised that I couldn't do it. This is the kind of thing I expected to be ground level stuff.
Re: Adding Markdown to Ddoc
On 12/11/17 1:45 PM, Walter Bright wrote: On 12/11/2017 6:22 AM, Jakob Bornecrantz wrote: There are loads of implementations of CommonMark https://github.com/commonmark/CommonMark/wiki/List-of-CommonMark-Implementations They appear to be libraries that offer an implementation. Does the Markdown used in github, reddit, wikipedia, doxygen, etc., use any of those libraries? It appears that github now uses their own fork of cmark, which adds support for tables, etc. [1] [1] https://githubengineering.com/a-formal-spec-for-github-markdown/
Re: Adding Markdown to Ddoc
On 12/9/17 2:25 PM, Adam D. Ruppe wrote: On Saturday, 9 December 2017 at 21:05:04 UTC, David Gileadi wrote: For instance, as I've been working on adding Markdown features I was surprised to discover that DDoc's current support for backtick-delimited code only works within a single line. Most implementations I've seen allow it to span hard-wrapped lines, as long as it's within a single paragraph. I kinda object to calling the ddoc `` thing markdown, since that wasn't the intention. When I added it, I had exactly one goal: be able to write `` in ddoc without it breaking the html output. At the same time, I didn't want it to accidentally trigger if someone pasted a linker error in their doc: undefined reference to `foo' undefined reference to `bar' So it was limited to a single line and required a matching ` to trigger the new code. Then, btw, it does NOT just wrap it in a $(BACKTICK) macro. It first *escapes the string*, for example turning < into <, etc, THEN wraps it in the macro. Though, the reason it uses ` as the delimiter is because markdown does it so it looks familiar... but it wasn't actually based on a desire to be markdown. Similarly, my adrdox thing has some markdown-ish features, but it is explicitly NOT markdown, giving me the freedom to avoid brain damage. (I am not a fan of markdown, it is such a mess and hard to write.) That makes sense--thanks for the background. To be fair to markdown, it does also require matching backticks and escapes < and > within backtick-quoted sections. But I agree that some markdown "features" are rather messy.
Re: Adding Markdown to Ddoc
On 12/8/17 6:49 PM, Walter Bright wrote: On 12/8/2017 7:30 AM, Jacob Carlborg wrote: Otherwise it will be confusing and very hard to remember which features are supported with Markdown syntax and which are not. This is way overstating the case. Ddoc already supports some markdown, and some markdown in different ways. For instance, as I've been working on adding Markdown features I was surprised to discover that DDoc's current support for backtick-delimited code only works within a single line. Most implementations I've seen allow it to span hard-wrapped lines, as long as it's within a single paragraph. I'd like to support as many Markdown features as we can, but there will always be a some differences--particularly those that conflict with existing DDoc features.
Re: Adding Markdown to Ddoc
On 12/5/17 9:11 PM, Walter Bright wrote: https://help.github.com/articles/basic-writing-and-formatting-syntax/ Anyone interested in picking up the flag? (I know this has come up before, and I've been opposed to it, but I've changed my mind.) I didn't notice anyone pick this up yet. I'm taking a stab at it, writing it mostly from scratch. However if someone else wants to pick it up you're very welcome; my attempt is likely to be slow, especially this time of year :)
Re: Adding Markdown to Ddoc
On 12/6/17 6:41 AM, Nemanja Boric wrote: On Wednesday, 6 December 2017 at 04:11:33 UTC, Walter Bright wrote: https://help.github.com/articles/basic-writing-and-formatting-syntax/ Anyone interested in picking up the flag? (I know this has come up before, and I've been opposed to it, but I've changed my mind.) These are great news. We are using harbored-mod (https://github.com/dlang-community/harbored-mod) which does this for quite some time, but it feels like a second-class citizen compared to the ddoc. Speaking of that tool, I suspect Ddoc's Markdown support will have to do the same as harboured-mod does with respect to the bits of Markdown syntax that are already claimed by Ddoc [1] [1] https://github.com/dlang-community/harbored-mod#differences-from-vanilla-markdown
A potential danger to dub
Let me preface this by saying I love package managers and think dub is one of the best things with dlang. However they can also sometimes be dangerous, as this PyPI incident[1] shows: several Python packages were uploaded that contained names similar to the standard library, and had an extra semi-malicious payload. They are apparently now part of live software. You could of course expect developers to do due diligence with the things they download, but of course they don't. It's probably worth paying attention to what the PyPI devs do to help mitigate this, and perhaps repeat some of those things with dub. [1] https://arstechnica.com/information-technology/2017/09/devs-unknowingly-use-malicious-modules-put-into-official-python-repository/
Re: How do you use D?
On 7/29/17 3:05 AM, Russel Winder via Digitalmars-d wrote: In 2004 maybe "D as better C++" was a good line. In 2017 "D is a general purpose programming language that allow faster development time than C++, Go, and Rust" is a far better line? This is what attracts me to D--it's easy to write, clean to read, and super powerful. However the "faster development time" is a bit marred by D's current ecosystem: it's faster/easier than other languages in certain domains, but lack of libraries/integration make it a tough choice in other domains (like mobile). And we have fairly regular complaints on the forum about the new-to-D experience (and good on them for taking the time to post about it here!). If I had free time for D I'd be trying to work on improving those things.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
On 7/21/17 11:41 AM, Moritz Maxeiner wrote: On Friday, 21 July 2017 at 18:35:53 UTC, David Gileadi wrote: On 7/21/17 6:51 AM, Mike Parker wrote: DIP 1009 is titled "Improve Contract Usability". For out contracts that use the return identifier, could the keyword "return" be used? out(return > 0) One possible problem with this syntax is a future where functions could have multiple return values... No, see Round 1 discussion [1] [1] http://forum.dlang.org/post/oihbot$134s$1...@digitalmars.com Ah, thanks--I missed that.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
On 7/21/17 6:51 AM, Mike Parker wrote: DIP 1009 is titled "Improve Contract Usability". For out contracts that use the return identifier, could the keyword "return" be used? out(return > 0) One possible problem with this syntax is a future where functions could have multiple return values...
Re: Expressing range constraints in CNF form
On 6/11/17 1:32 PM, Sebastiaan Koppe wrote: What about using ddoc? enum bool isInputRange(R) = is(typeof((ref R r) => r)) /// must be copyable && is(ReturnType!((R r) => r.empty) == bool) /// must support bool empty && is(typeof(lvalueOf!R.front)) /// must support front && is(typeof(lvalueOf!R.popFront)) /// must support back If there's going to be compiler magic, this seems like a sensible syntax--documenting constraints is a good idea anyway, particularly for those of us who aren't is-expression masters.
Re: Another "D is cool" post
On 5/29/17 12:07 PM, H. S. Teoh via Digitalmars-d wrote: [snip an excellent post] I think a longish post like this would make an excellent shortish post for the D blog. In any case, great writeup!
Re: C and memory safety comments by me
On 5/18/17 10:00 AM, Walter Bright wrote: https://www.reddit.com/r/cpp/comments/6b4xrc/walter_bright_believes_memory_safety_will_kill_c/dhkxhef/ Oddly enough that link took me to a comment thread about Rust CFFI, with no comments by you in it. Perhaps you meant the link to not include the dhkxhef/ at the end?
Re: DIP 1003 Formal Review
On 5/12/17 9:17 AM, Mike Parker wrote: The first stage of the formal review for DIP 1003 [1], "Remove body as a Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM GMT on May 27), the community has the opportunity to provide last-minute feedback. If you missed the preliminary review [2], this is your chance to provide input. At the end of the feedback period, I will submit the DIP to Walter and Andrei for their final decision. Thanks in advance to those of you who participate. [1] https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md [2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvn...@forum.dlang.org One possible substitute for the `function` keyword in option 2 could be `do`. I'm not convinced it's a good substitute, but I thought I'd throw it out there.
Re: NG technical issues: Is it just me?
On 4/20/17 2:05 PM, lawrence wrote: On 04/20/2017 02:09 PM, Timon Gehr wrote: On 20.04.2017 21:45, Nick Sabalausky (Abscissa) wrote: [snip] It's not just you. I have the same issues. I used to have this same problem, until I sent the server settings to check for updates every 2 minutes. I don't have this problem, but my server settings check every 2 minutes as well.
Re: Compare boost::hana to D
On 4/19/17 11:30 AM, Adrian Matoga wrote: On Wednesday, 19 April 2017 at 18:26:20 UTC, Sebastiaan Koppe wrote: On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga wrote: [2] https://epi.github.io/2017/03/18/less_fun.html Great article! Thanks! I should mention I've also got somewhat positive feedback from Louis [1]. [1] https://twitter.com/LouisDionne/status/843227582803849216 Minor nit in the article--in the following paragraph "runtime" should probably be replaced with "compile time": "Note the enum in place where C++ version used auto. The type is also inferred automatically, but using enum forces index to be computed at runtime and only then it can be used in static assert."
Re: Name That Technique!
On 2/3/17 5:00 PM, deadalnix wrote: On Friday, 3 February 2017 at 23:33:58 UTC, Walter Bright wrote: I agree, it's pretty dazz! We need to give this technique a memorable name (not an acronym). I thought "Voldemort Types" turned out rather well, whereas CTFE is klunky, UFCS is even worse. The absolute worst is C++ SFINAE. Any ideas? Scherkl-Nielsen Lookup? The perfect bikeshedding moment! Daniel, Dominikus: please consider writing an article about this. That's obviously a self important lookup. This. So much this.
Re: D future ...
On 12/24/16 5:11 PM, WebFreak001 wrote: On Thursday, 22 December 2016 at 04:47:06 UTC, Chris Wright wrote: CTFE ( Stefan is dealing with that ), Documentation, better Editor support... I think code-d could potentially be extended to install its dependencies, which would improve the situation there. It does already do that though :/ Will it auto-update them as new versions are released, or when code-d is updated?
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On 12/14/16 4:38 PM, Timon Gehr wrote:
On 15.12.2016 00:17, Andrej Mitrovic wrote:
ubyte[] readSomeBytes ( )
{
return read(1024);
}
It's a non-trivial exercise for the reader to understand where the
`read` symbol is coming from.
pragma(msg,fullyQualifiedName!read);
Or, for the IDE-addict, hover or control-click on `read`.
Re: All function attributes possible with "@"?
On 12/14/16 2:34 PM, ketmar wrote: On Wednesday, 14 December 2016 at 21:02:09 UTC, Jonathan M Davis wrote: If we keep making breaking changes, we will never have a significant user base so the core issue is a direction D developement should go: 1) have a good language, or 2) have big userbase. it looks like those goals are in conflict now. while i can see how userbase matters, i also can't see how it matters for me -- it turns out that i got a mediocre language as a result. well, there are alot of "acceptable" languages out there, and c++ has a huge userbase and a huge codebase, so it will always win here. the only way for D to win (as i see it) is to deliver a better language. and that means dropping support for old code from time to time, not to stick with bad design forever. also, tools like dfix can be made to "upgrade" code. so far being "stable" didn't brought Bick Bucks or Big Corporate Support to D. yet instead of using that to advance the language, to redesign features and so on, D is stuck in a hope of getting some Big Future Support. i may be completely wrong, of course, but i see the unique strength that D can exploit: the ability to change. sure, turning D into "moving target" will make some older code invalid. but if the author doesn't want to maintain his code, is there any real reason to use it? with automatic upgrade utility it wouldn't be that hard to keep the code up-to-date. i believe that pediodical "cleanups" will make D better, and will win more users in the long run. so i will continue advocating "moving target" concept from time to time. ;-) I've noticed that recent languages like Go and Swift are trying to have both by bundling a code fixer with new versions of their language. I have a hard time seeing the downsides of that.
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On 12/14/16 9:27 AM, Andrei Alexandrescu wrote:
On 12/14/2016 11:02 AM, default0 wrote:
On Wednesday, 14 December 2016 at 14:21:55 UTC, Andrei Alexandrescu
wrote:
On 12/14/16 8:26 AM, Dominikus Dittes Scherkl wrote:
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu
wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Why not leave it as it is and only change the compiler to
perform inputs _within_ a function before evaluating the
declaration, so
that the symbols imported can be used in the declaration?
Thanks. I considered this but it put pressure on the relationship
between the name and where it's looked up. Consider that imports in a
function don't need to be at the top. They may also be in nested
scopes inside the function. It becomes quite tenuous to explain where
the parameter type names are looked up. -- Andrei
Could restrict to imports that come before any other statements in the
function body, ie:
// valid, compiles when instantiated
void fun(Range)(Range r) if(isInputRange!Range) {
import std.range;
}
// invalid, import is not picked up because it is not the first
statement in the method body
void fun(Range)(Range r) if(isInputRange!Range) {
doThings();
import std.range;
}
If this is desirable, the error message for failed symbol lookup of
symbols in a function declaration should hint that imports in the
function body are only considered if they stand at the beginning of the
function, to help mitigate confusion.
Seems simple enough to specify and explain, honestly.
To me it seems like adding additional rules to make up for a weakness
that should be avoided in the first place. -- Andrei
For the little that it's worth, my opinion is that it's easier to
understand/teach the proposed rule above than the new syntax in DIP1005.
This is true for me whether the proposed rule applies to all imports
within the top scope of the template function/class/struct, or only to
imports at the beginning of that scope.
The above rule doesn't cover non-template function declarations like the
`process` example in the DIP, however. Are they an important enough use
case to justify new syntax?
Re: core.intrinsics
On 10/13/16 12:52 PM, Stefan Koch wrote: On Thursday, 13 October 2016 at 19:49:42 UTC, Johan Engelen wrote: On Thursday, 13 October 2016 at 19:35:08 UTC, Stefan Koch wrote: Please share your thoughts and tell me what other intrinsic functions could/should be added. I think the name should be different from "intrinsics", so that it can also contain functions like "likely-functionptr" / "likely-class" optimization functions (e.g. the is_likely template from the other thread). -Johan What name would you suggest then ? As an ignorant bystander I like core.intrinsics, but if not then perhaps core.compilerhints or something to that effect?
Re: Stack Overflow Documentation D language page
On 7/21/16 9:20 AM, Bennet Leff wrote: If you haven't heard, Stack Overflow is starting an open documentation reference. It's brand new but I've already seen large contributions for other languages. I've started to get the ball rolling but it seems like the community would be interested in adding. Here's the page: http://stackoverflow.com/documentation/d Interestingly, Microsoft is going to curate examples from SO's Documentation into their own docs [1]. Perhaps we can do something similar at some point. [1] https://docs.microsoft.com/teamblog/stackoverflow-documentation-for-microsoft-developers/#futureintegration
Re: Elm on error messages and compiler as an assistant
On 2/1/16 2:17 PM, Laeeth Isharc wrote: http://elm-lang.org/blog/compilers-as-assistants Thanks for sharing this. While D's error messages have improved over time, this shows that there's another level of friendliness possible.
Re: D for Game Development
On 8/10/15 12:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote: People keep talking about Rust, I'm thinking of giving it a shot. I feel there is something wrong with the Rust and Go agendas, both languages have interesting features, but then they seem to get too moralistic/political. Is there a way to turn off bounds-checks in Rust? Apparently not? And apparently the same misguided obsession with iterators (aka ranges): https://users.rust-lang.org/t/c-has-vector-n-value-c-has-calloc-rust-has-uh/146 …Rust has a long way to go… …Go is frozen… …D has a long way to go… …C++ is fit, moving and annoying… I guess the only way forward is to write your own language. …[insert your language here] has a long way to go… :)
Re: Where will D sit in the web service space?
On 7/24/15 9:57 AM, Joakim wrote: On Friday, 24 July 2015 at 14:50:23 UTC, Ola Fosheim Grøstad wrote: ART. Of course Metal isn't general-purpose, nobody said it is, but I don't see why you'd say Swift isn't. Swift is clearly designed around Objective-C and Cocoa. Oh, and I didn't respond to this because I didn't even know what you meant, think I got it now. You're now saying Swift isn't general-purpose simply because it's initially designed around Apple's Cocoa OS APIs? Being tied to a single platform doesn't make a language any less general-purpose, and since they announced that they're open-sourcing Swift later this year, it will be ported to other platforms, just as Obj-C has. I've been doing a lot of Swift programming recently, and here are my impressions: Yes, it's heavily designed around Objective-C and Cocoa, but it's a nice language on its own. It feels like the designers are working for an all-Swift future, and are discarding some Objective-C/Cocoa-isms along the way. As for the language itself I really like the syntax and many of the constructs. The nil/non-nil typing tends to intrude a bit too often for my liking (like D's const does but more pervasive). And I miss the things that D lets me do, particularly its fantastic metaprogramming and ability to go low-level. I don't love Swift like I love D, but it's a nice language to work with.
Re: std.experimental.testing PR review
On 6/26/15 7:30 AM, Atila Neves wrote: On Friday, 26 June 2015 at 13:32:39 UTC, Dicebot wrote: Just in case it wasn't clear : I will vote "no" on this proposal as long as it features longish "readable" names like "shouldEquals". You'd rather `should!"=="`? I'm not sure which I'd prefer; the thing is that so far you're the only one strongly against it. The only other thing I heard was a question at DConf on why it wasn't `assertEquals` instead. Atila Let's paint this bikeshed! I tend to like "must" instead of "should"; it's a bit shorter and stronger. I tend to like dot-separated English for testing, e.g. throwRangeError.must.throw!RangeError; One advantage is that the dot after "must" (or "should") can trigger code completion on IDEs. Finally, I wonder if it's possible to hijack operator overloading to support this: 2.timesTwo.must == 4;
Re: std.uni.toLowerCase / .toUpperCase
On 6/25/15 7:10 AM, Vladimir Panteleev wrote:
And, IMHO, this:
fileName.readText.lowerCased.detabbed.toFile(fileName.withExtension(".foo"))
looks much better than this:
fileName.readText.lowerCaser.detabber.toFile(fileName.extensionSetter(".foo"))
I agree with Jonathan that the latter is clearer as to what the method
is doing--constructing something that will do the work. However, I agree
that the former reads much better. My bikeshed is painted the former
way, mainly because it encourages people to use the range-based style
because it reads so well.
With that said I'm hopeful that Adam's trick will obviate at least some
of this discussion.
Re: Martin Nowak is officially MIA
On 6/19/15 2:00 PM, Brad Anderson wrote: IRC, I hope, is what you mean. Chatting by interrupts sounds hor- It sure does! :)
Re: split up the changelog?
On 6/19/15 12:22 PM, Steven Schveighoffer wrote: But, what about making the changelog menu an accordion expander, and then you have your version list right there on the left? I really like that idea. The left nav is supposed to be an index to things, after all.
Re: split up the changelog?
On 6/19/15 8:59 AM, anonymous wrote: The changelog.html file is at about 1MB. That makes for a noticeable load time. And with all the issue lists, it's also a pretty solid wall of text: "Wait, is all this still for 2.067.0? Did I miss a version heading? I think I'm lost." Let's split it up by version! Pull request: https://github.com/D-Programming-Language/dlang.org/pull/1006 Preview: http://d-ag0aep6g.rhcloud.com/changelog/index.html I think these are the typical use cases for the changelog: 1) Looking up the changes in the latest or some particular version: This benefits from a shorter load time and no more unrelated content. 2) Finding the version which made a particular change: This can't be done with Ctrl+F anymore, as Vladimir Panteleev (CyberShadow) mentions in the PR discussion. He also gives the alternative: google with "site:dlang.org/changelog". Good enough? 3) Reading through language history: This becomes more pleasant with a split changelog, as you don't have to scroll over pages of bugzilla issues anymore to get to the good stuff: prose and code samples. Opinions? I like it! My only suggestion is that perhaps the landing page should be the changelog for the latest version, since most of the time I'm interested in what the latest changes are.
Re: D could catch this wave: web assembly
On 6/18/15 10:41 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= " wrote: And whyyy are they calling a binary format "assembly"? Because it sounds faster, of course :)
Re: Better forums
On 6/18/15 1:12 AM, Tofu Ninja wrote: On Thursday, 18 June 2015 at 07:24:34 UTC, Jens Bauer wrote: On Thursday, 18 June 2015 at 04:35:31 UTC, Rikki Cattermole wrote: On 18/06/2015 4:25 p.m., Joakim wrote: On Thursday, 18 June 2015 at 04:01:42 UTC, Rikki Cattermole wrote: I agree with Rikki that it'd be better to add features to the web forum in a backward-compatible way, such as putting tag names in the titles or using Markdown for the forum's markup, which is perfectly readable in email. We're already doing it. Why not just make it easier? Also makes posts like this a thing of the past. +1 Adding a "tag" field encourages tags to be used. It would be particularly useful for me, as the [embedded] tag would probably become my favourite. ;) ... Oh, and a "Like" button (and no dislike button), please. -That works very well to encourage a good tone on the ARM Connected Community :) (I think "Like" and "Me too" buttons would only make sense in the Web-interface). +1 Replies with a +1 on a line by itself could also be considered a like, so non web-interface users can like as well. Also it might be beneficial to show the most liked post near the top or have a link to it or something for D-learn so people can quickly see the answer. +1
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On 6/10/15 6:43 PM, Tofu Ninja wrote: On Thursday, 11 June 2015 at 01:30:08 UTC, weaselcat wrote: 'he' has been a gender neutral pronoun for centuries, and as far as I'm aware this has its roots in latin using 'man'(vir?) as a gender neutral pronoun. I am just saying that personally it sounds odd to me to use it that way and I don't hear people use it that way either. In gender neutral contexts where you don't know the gender I almost always say/hear they/their. Maybe he losing its gender neutrality is a recent thing, I don't know. Maybe its just a thing with mid-westerners? It does appear to be a recent thing, if you trust Wikipedia: http://en.wikipedia.org/wiki/Gender-specific_and_gender-neutral_pronouns#Generic_he Also the earlier section on "Historical and dialectal gender-neutral pronouns" is interesting: maybe we can start using "a" or "yo" as pronouns.
Re: Automatic documentation builds
On 6/11/15 7:04 AM, Steven Schveighoffer wrote: On 6/11/15 8:21 AM, Vladimir Panteleev wrote: I've put together a CI system of sorts that builds the documentation for all pull requests. Hopefully this should avoid the dlang.org build breaking again in the future. It integrates with GitHub as well, and on repositories covered by Brad's auto-tester, will create a second status for the documentation. The whole thing is Digger-powered, so uses the same code as Digger and http://digger.k3.1azy.net/trend/. Sample page: http://dtest.thecybershadow.net/results/a6e6883454a4d62c8d4b41819b9a7e33899b6222/31744d2fb90cf25ef1778f52ef640abc56c494c2/ Source code: https://github.com/CyberShadow/DAutoTest Cool fact: When you request a built file (e.g. a .html page), it'll fetch the data directly from the Git cache repository, through a named pipe (bypassing disk) connected to a long-living Git process. This is also done transparently for included resources (images, CSS etc.) On a PR I was doing for ddoc, the "old" and "new" seem to be reversed: http://dtest.thecybershadow.net/results/a6e6883454a4d62c8d4b41819b9a7e33899b6222/6d3c95ecc5422ae1d5bd6f3308da78b733175ba7/ While randomly browsing through for a PR to see this magic on, I ran across an error page: http://dtest.thecybershadow.net/artifact/website-9bbe7b16aaa20f28b879722609308a024a12ae52-005ef14643f10a0919ace4bd80bcfa44/web/library-prerelease/std/range/merge.html I get it when I click on the New link for merge.html on this page: http://dtest.thecybershadow.net/results/a6e6883454a4d62c8d4b41819b9a7e33899b6222/82878d02c06ec112663fd953e78d541dda69a38e/ I believe that, like Steven says, the Old and New links are reversed (since the diff shows that merge.html to be new in this PR but the new page shows up under the Old link), and perhaps the tool should better handle added/deleted files. In any case this is a seriously awesome tool!
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On 6/10/15 12:56 PM, Russel Winder via Digitalmars-d wrote: Please note, OED (which is the definition of the English language whatever any USA upstarts may try to pretend) is gearing up to define "they" as both singular and plural, thus at a stroke solving all the he/she, she/he, (s)he, it faffing. Is they out of its mind? :)
Re: Bad Sound Quality on Livestreamed Videos
On 5/30/15 8:37 AM, John Colvin wrote: On Saturday, 30 May 2015 at 14:12:10 UTC, Per Nordlöw wrote: The livestreaming videos just published are really frustrating to watch because lots of stuttering in speech about once every 20 seconds or so and sometimes difficult to here what people say. Sorry about that, the WiFi wasn't quite up to the task at some points. Hopefully it was still better than nothing :) Much better; I really enjoyed the livestream. And the quality was pretty good, considering its impromptu nature. Many thanks!
Re: D installer installs outdated D
On 5/22/15 10:53 AM, Chris wrote: Hi other Chris. Just to make sure, people can tell us apart :-) Uh, oh; an identity Chrisis!
Re: D, Python, and Chapel
On 4/3/15 6:36 AM, Gary Willoughby wrote: Chapel overview: http://chapel.cray.com/overview.html Their hello world examples do a fantastic job of illustrating their main selling point. My hat's off to whoever put that on their site. D may have difficulty coming up with something like that, since its selling point(s) may be harder to distil. But if we could, it should get front 'n' center attention on dlang.org.
Re: unittests are really part of the build, not a special run
On 4/2/15 2:46 PM, Wyatt wrote: On Thursday, 2 April 2015 at 20:55:04 UTC, David Gileadi wrote: Having never used Cucumber but having been interested in it, what was the unpleasantness? Dealing with it at work, I find it puts us scarily at the mercy of regexen in Ruby, which is unsettling to say the least. More pressingly, the "plain English" method of writing tests hinders my ability to figure out what the test is actually trying to do. There's not enough structure to give you good visual anchors that are easy to follow, so I end up having to build a mental model of an entire feature file every time I look at it. It's hugely inconvenient. And if I can't remember what a phrase corresponds to, I have to hunt down the implementation and read that anyway, so it's not saving any time or making life any easier. -Wyatt On 4/2/15 2:32 PM, Dicebot wrote: > The very fact of being forced to install some external application) > which is not even available in my distro repositories) to run set of > basic tests that could be done with 10 line D or shell script instead. > > It is hardly surprising that so far I preferred to submit pull requests > without testing instead. Thanks to you both for the answers!
Re: unittests are really part of the build, not a special run
On 4/2/15 1:34 PM, Dicebot wrote: On Wednesday, 1 April 2015 at 20:48:43 UTC, Atila Neves wrote: On Wednesday, 1 April 2015 at 19:31:37 UTC, Dicebot wrote: P.S. I hate all the Ruby testing facilities, hate with bloody passion. You're going to _love_ my DConf talk ;) I was expecting that already, you let me know what you thought of them last year! Atila Oh yeah, looking forward to listening it :) I had an unpleasant experience of encountering Cucumber when trying to contribute to dstep so this specific name is like a trigger to me :) Having never used Cucumber but having been interested in it, what was the unpleasantness?
Re: Named unittests
On 3/31/15 3:28 PM, Andrei Alexandrescu wrote:
On 3/31/15 2:50 PM, Martin Nowak wrote:
On 03/30/2015 11:52 PM, Andrei Alexandrescu wrote:
I'd like to make a DIP for named unittests. Who can help me with that?
Why a DIP, isn't the only question what syntax to use.
unittest (myname) vs. unittest ("mynameexpression")
Also unittest myname and unittest "mynameexpression". There will be no
shortage of folks willing to debate this to smithereens.
One argument for myname (using standard identifier naming rules) is that
it's command-line friendly: it won't require quoting when invoking a
single unit test, and tends toward shorter names. It may also be more
obvious that standard identifier names would use the existing lookup
rules for guaranteeing uniqueness among unittest names.
One argument for "mynameexpression" is that it allows for nice
descriptions (e.g. unittest "count should accept a custom comparator
function").
One compromise might be something like:
@description("count should accept a custom comparator function")
unittest countCustomComparator
Under this example the unittest could be invoked from the command line
by the countCustomComparator name or possibly by the description string
as an alternative.
For the very little it's worth my bikeshed is painted without
parentheses, assuming that's easily implemented.
Re: Where's "This week in D?"
On 3/24/15 11:09 AM, Andrei Alexandrescu wrote: On 3/24/15 10:52 AM, CraigDillabaugh wrote: On Monday, 23 March 2015 at 21:28:27 UTC, Andrei Alexandrescu wrote: No issue for the past week? -- Andrei Maybe Adam was vaporized by Aliens! Adam was on reddit a couple of hours ago. This is a bit of a bummer because an important feature of a weekly newsletter is that it's, well, weekly. -- Andrei In this case it's only weakly weekly.
Re: A few notes on choosing between Go and D for a quick project
On 3/19/15 10:22 PM, Walter Bright wrote: On 3/19/2015 10:44 AM, Joakim wrote: One underused resource seems to be all the examples bearophile has put on Rosetta Code: http://rosettacode.org/wiki/Category:D If he, Adam, or some other proficient D user were to do a weekly series breaking down each of those 733 examples one at a time- what idioms were used, why certain variations were more efficient- that could go a long way to introduce the language and its idioms to beginners. It would provide enough examples for 14 years of such a weekly series, by which time D3 will be getting started! I didn't know about rosettacode. Thanks! It also might be a great resource for better examples to use in the Phobos documentation. Someone who knows about copyright/licensing would probably need to check that it's okay if we plan to use them verbatim. If we can't then it might be worth linking to the above page from somewhere on dlang.org.
Re: Enhancement: issue error on all public functions that are missing ddoc sections
On 3/19/15 3:26 PM, deadalnix wrote:
On Thursday, 19 March 2015 at 22:04:01 UTC, Walter Bright wrote:
On 3/19/2015 2:43 AM, deadalnix wrote:
Here is what will pass review :
Presumably the reviewers will have some common sense and taste.
class User {
/**
* Accessor to get the id of the user.
*
* @return : the id of the user
*/
uint getUserID() { ... }
/**
* Accessor to get the name of the user.
*
* @return : the name of the user
*/
string getName() { ... }
Accessor functions that merely return a field variable are bull anyway.
That is completely missing the point. If that is not clear enough :
/**
* This class is the in program represention for a user.
* It contains various user related data, and provides
* various facilities for common user related operations.
*/
class User {
/**
* Accessor to get the id of the user.
*
* @return : the id of the user
*/
uint getUserID() { ... }
/**
* Accessor to get the name of the user.
*
* @return : the name of the user
*/
string getName() { ... }
/**
* This method will subscribe the user to the Subscribable
* passed as argument.
*
* S: The Subscribable the user is going to subsribe to.
*
* @throw CantSubscribeException : In case the subscription fails,
* an exception is thrown.
*/
void subscribeUserTo(Subsribable S) { ... }
/**
* Send a message to the user. This can be used for commercial offers
* or general information about the system.
*
* msg: The message you wish to send to the user.
*
* @throw MessageNotSentException : If for some reason, the message
isn't
* sent properly, a MessageNotSentException is sent.
*/
sendMessage(string msg) { ... }
// And so on like forever...
}
Mandatory comment block is how you end up with overbloated code like
this where it is explained to you 3 times in the comment what the
method's name already tells you. And that is only the begging because
starting from this point, overtime, comment become more and more out of
date to ends up looking like an surrealistic form of humor.
I agree with the uselessly overcommented code you describe; I've seen
plenty of it too.
And yet there is a little room for useful comments here: does getName
return the user's given/family name or an account username? Possibly
obviated by the context of whatever app this User class is in, but how
will the user receive the sent message? Comments on purpose and use can
save a bit of maintenance developers' time.
Re: A few notes on choosing between Go and D for a quick project
On 3/18/15 4:54 PM, David Gileadi wrote:
On 3/18/15 4:48 PM, jkpl wrote:
On Wednesday, 18 March 2015 at 23:41:41 UTC, Walter Bright wrote:
On 3/18/2015 5:45 AM, CraigDillabaugh wrote:
You said that "Unfortunately" this thinking is going out of style
"for good
reasons". I am confused (sorry, I am at work, and didn't have time
to watch
the 1+ hour video you linked to - maybe some clues were there)!
Consider this C code:
#include
#include
typedef long T;
bool find(T *array, size_t dim, T t) {
int i;
for (i = 0; i <= dim; i++);
{
int v = array[i];
if (v == t)
return true;
}
}
There are several bugs in it. I've showed this to probably over 1000
programmers, and nobody found all the bugs in it (they are obvious
once pointed out). It is not easy to write bug free loop code, and
find() is a trivial function.
just for fun:
1/ '<=' instead of '<'
2/ array should be tested against null before entering the loop
3/ 'int v' instead of 'T v'
Got them all ?
4. The semicolon after the for loop's closing paren...
5. No return if the item isn't found, leading to undefined behavior.
There may well be more, but I'll stop spamming this topic. Sorry Walter.
Re: A few notes on choosing between Go and D for a quick project
On 3/18/15 4:48 PM, jkpl wrote:
On Wednesday, 18 March 2015 at 23:41:41 UTC, Walter Bright wrote:
On 3/18/2015 5:45 AM, CraigDillabaugh wrote:
You said that "Unfortunately" this thinking is going out of style
"for good
reasons". I am confused (sorry, I am at work, and didn't have time
to watch
the 1+ hour video you linked to - maybe some clues were there)!
Consider this C code:
#include
#include
typedef long T;
bool find(T *array, size_t dim, T t) {
int i;
for (i = 0; i <= dim; i++);
{
int v = array[i];
if (v == t)
return true;
}
}
There are several bugs in it. I've showed this to probably over 1000
programmers, and nobody found all the bugs in it (they are obvious
once pointed out). It is not easy to write bug free loop code, and
find() is a trivial function.
just for fun:
1/ '<=' instead of '<'
2/ array should be tested against null before entering the loop
3/ 'int v' instead of 'T v'
Got them all ?
4. The semicolon after the for loop's closing paren...
Re: DIP74: Reference Counted Class Objects
On 2/27/15 6:36 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " wrote: On Friday, 27 February 2015 at 08:26:14 UTC, Ola Fosheim Grøstad wrote: On Thursday, 26 February 2015 at 22:04:09 UTC, Andrei Alexandrescu wrote: On 2/26/15 2:03 PM, Brian Schott wrote: One of the first things that stood out to me is that "add ref" is two words and "release" is one. For the sake of symmetry, how about these: * opIncRef, opDecRef * opAcquire, opRelease All - please PLEASE do not derail this into yet another debate about which names are best. -- Andrei Using protocols rather than enforcing a particular implementation is nice, but D needs to stop reinventing terminology and syntax matters. -- snip -- AddRef/Release is established COM terminology. One reason for keeping COM terminology might be if std.c.windows.com.IUnknown can automatically take advantage of DIP74. Of course this could also be a downside—would DIP74 break existing COM code in D?
Re: RFC: std.*.concept convention
On 2/11/15 12:47 PM, Brad Anderson wrote: On Wednesday, 11 February 2015 at 08:00:54 UTC, Jakob Ovrum wrote: [snip] Putting the complexity of the container concept aside; I think we should factor out the concept checkers from std.range.primitives and put them in std.range.concept and establish a convention of using modules named std.*.concept for concept checkers in the future. The consistency gained by such a convention makes type concepts easier to understand and commonly used module names easier to remember. If we do it now, there is no breakage, as the splitting of std.range has not yet been released: hence the otherwise clumsy timing of this suggestion. [snip] +1. Makes a lot of sense to do it this way. I prefer "concept" over "trait". I think of traits as more primitive building blocks. With a trait you are querying information about a type. With a concept you are fitting a type to its requirements. My uneducated feeling is that if there's a clear dividing line as to what is a trait and what is a concept—for instance if they have different syntax—then it makes sense to have two names. Otherwise I think it makes more sense to have just one. Fuzzy categorization tends to hurt.
Re: Should we remove int[$] before 2.067?
On 2/1/15 9:26 AM, Andrei Alexandrescu wrote: I agree indecision is bad. -- Andrei Whereas I'm still on the fence...
Re: [website redesign] PR for the one with the big red menu bar
On 1/30/15 9:30 AM, anonymous wrote: Another variant somewhere between the all-red one and the all-grey one: http://ag0aep6g-dlang.rhcloud.com/variants/grey-newlogo/ I think it might look better if the red blends into the gray: http://i.imgur.com/ZCvmkVq.png
Re: dlang.org redesign -- the state of documentation and learning resources [part 2]
On 1/25/15 4:42 AM, Andrej Mitrovic via Digitalmars-d wrote: Here's another one: The search box allows selecting between: - Entire D Site - Library reference - Newsgroup archives But where's the Language spec option? It's missing due to how dlang.org is set up, and the limitations of Google's site search feature. If you click on a link in the language spec, like on Types, you'll notice that its URL has the page directly under dlang.org, e.g. http://dlang.org/type.html. In contrast, the standard library is in a subfolder (e.g. http://dlang.org/phobos/std_algorithm.html) and the newsgroup archives are in another subfolder. Being in a subfolder allows us to pass a prefix parameter to Google's site search that will limit its results to URLS with that prefix. Since the language reference isn't in a subfolder there's no prefix for the language reference that doesn't also include everything else in the site, and hence there's no option for Language Spec. I don't know how hard it would be to put all the language spec pages into their own subfolder, but doing so would allow us to add the Language Spec option to the dropdown.
Re: Thanks to p0nce for a nicer DConf logo!
On 1/19/15, 3:02 PM, Steven Schveighoffer wrote: The thing is, there are several state abbreviations that always confuse people. For instance AL is Alabama, but could be Alaska (AK) and AK might be confused as Arkansas (AR), which may be confused as Arizona (AZ).* I can confirm this: as a teen from UT I took a job at a gas station near the north rim of the Grand Canyon in AZ and spent most of the summer entering AR as the state code on their paper credit card entry form. Finally someone kindly set me straight. In any case I think the potential confusion from "UT" in the dconf.org headline may be mitigated by the fact that it's preceded by "Utah" in the university name.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/19/14, 9:12 AM, bearophile wrote:
David Gileadi:
writefln("%s", b.length - a.length); // Yup, 2
writefln("%s", a.length - b.length); // WAT? 18446744073709551614
Nowadays a better way to write such kind of code is using the Phobos
"signed" function:
writefln("%s", b.length.signed - a.length.signed);
writefln("%s", a.length.signed - b.length.signed);
But this requires the following knowledge:
1. That the signed function exists, and its location. As a casual D
programmer I didn't know about it.
2. That there's a need for it at all, which requires knowing that length
is unsigned. I did know this, but I bet in the heat of programming I'd
easily forget it. In a semi-complex algorithm the bug could easily hide
for a long time before biting.
This is why I agree with Don that:
> Having arr.length return an unsigned type, is a dreadful
language mistake.
This mistake is by design. Walter has resisted several times turning
them into signed values, and even making size_t a type strongly
different from uint/ulong. I don't agree with this design decision, but
it's unlikely that Walter has changed his mind on it. So better to go on
and discuss other things more likely to happen.
Yes, I bet you're right about the likelihood of change.
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On 11/19/14, 6:57 AM, ketmar via Digitalmars-d wrote:
On Wed, 19 Nov 2014 13:47:50 +
Don via Digitalmars-d wrote:
If I have two pencils of length 10 cm and 15 cm, then the first
one is -5 cm longer than the other.
and again "length" is not a relation. show me pencil of length -10 cm.
when you substractin lengthes, you got completely different type as a
result, not "length" anymore. ah, that untyped real-life math! ;-)
To me the salient point is that this is not just a mess with real-life
math but also with math in D: lengths are unsigned but people subtract
them all the time. If they're (un)lucky this will return correct values
for a while, but then someday the lengths may be reversed and the values
will be hugely wrong:
int[] a = [1, 2, 3];
int[] b = [5, 4, 3, 2, 1];
writefln("%s", b.length - a.length); // Yup, 2
writefln("%s", a.length - b.length); // WAT? 18446744073709551614
This is why I agree with Don that:
> Having arr.length return an unsigned type, is a dreadful language
> mistake.
Re: D in my trashbin
On 10/24/14, 5:05 PM, ketmar via Digitalmars-d wrote: On Fri, 24 Oct 2014 23:59:08 + Kyoji Klyden via Digitalmars-d wrote: I'm not sure what else we could call it though.. D.ask? .questions is good. Others have suggested D.users.
Re: OT: Minecraft death by GC
On 10/21/14, 2:47 AM, monarch_dodra wrote: Hurp, I wonder why GC issues only appear with application that use a GC. Hurp-a-durp. Also, the issue of memory leak and core dumps seem to only appear when you use a systems language. How crazy is that? Happily with a little work D allows you to have both! :)
Re: D mention on developer.apple.com
On 9/26/14, 11:25 AM, Walter Bright wrote: I see the Apple blog did mention D. A glorious exception! Which is odd because Swift doesn't support exception handling :)
Re: Automated source translation of C++ to D
On 8/22/14 1:29 AM, David Nadlinger wrote: On Friday, 22 August 2014 at 07:48:30 UTC, Daniel Murphy wrote: So no, you can't magically upgrade a project from C++ to D. Hence the name "magicport"? Sorry, could not resist. David It's pronounced "sufficiently advanced technology port" :)
Re: What have I missed?
On 8/9/14, 2:16 AM, Era Scarecrow wrote: On Saturday, 9 August 2014 at 09:15:10 UTC, Era Scarecrow wrote: and run as a LiceCD on a VM that contains all the tools and LiveCD LIVE!!! Wish i had an edit button for quick edits... Yeah, NNTP is lousy for editing.
Re: assert semantic change proposal
On 8/7/14, 9:51 AM, Sean Kelly wrote: On Thursday, 7 August 2014 at 07:57:14 UTC, Johannes Pfau wrote: Attempting to continue operating is irresponsible if the program is doing or can do anything important. Again: unittests? unittests shouldn't use assert. Or alternately, we can have onAssertError (the assertion failure callback) do something different if unit testing is taking place than when the program is actually running. Considering that TDPL, Ali's Book[1] and dlang.org[2] all use assert when introducing unittest, I think the latter solution is probably the right one. [1] http://ddili.org/ders/d.en/unit_testing.html [2] http://dlang.org/unittest.html
Re: checkedint call removal
On 7/29/14, 1:52 PM, Walter Bright wrote: I find this splitting of hares ... to be entirely meaningless. Hunters claim that rabbit tastes less gamey, if we're going to be splitting anything. (Please forgive the silliness.)
Re: What Programming Book Should I Read Next?
On 7/26/14, 4:26 PM, H. S. Teoh via Digitalmars-d wrote: On Sat, Jul 26, 2014 at 04:23:23PM -0700, Walter Bright via Digitalmars-d wrote: http://www.reddit.com/r/programming/comments/2bt8a5/what_programming_book_should_i_read_next/ Ali's book is the latest, so I posted that one! What about TDPL? Even though it's somewhat dated, it *was* what finally drove me to non-trivial programming in D. I am, alas, still a D dabbler, but I'm a huge fan of Andrei's book. It's not just the fantastic content, it's also the engaging style. I like it so well that I read it once in a while just for enjoyment.
Re: WAT: opCmp and opEquals woes
On 7/23/14, 11:09 AM, Dicebot wrote:
On Wednesday, 23 July 2014 at 17:15:12 UTC, Ary Borenszweig wrote:
Imagine you have a list of integers and strings denoting integers: [1,
"2", 100, "38"]. Now you want to sort them according to their numeric
value. Of course, 1 and "1" would have the same order. However, 1 and
"1" are different, so "==" would give false, while 1.opCmp("1") would
give 0.
Equality and comparison are different. opCmp is used for sorting
objects, which has nothing to do with equality. Inferring equality
from opCmp is wrong in my opinion.
Well this is why you can actually override those :) I think automatic
opCmd -> opEqual generation covers vast majority of use cases and as
such will have a vary good effort / decreased annoyance ratio.
I agree. In fact I think if you've implemented opCmp to sort 1 and "1"
as equal that in most cases you'd expect "1" and 1 to compare as
logically equal. Automatic opCmp -> opEquals seems like a very sane
default to me.
Re: [OT] Uploading DConf videos
On 7/18/14, 9:32 AM, ponce wrote: On Friday, 18 July 2014 at 15:44:21 UTC, Andrei Alexandrescu wrote: On 7/17/14, 11:53 PM, Jacob Carlborg wrote: On 18/07/14 03:55, Israel Rodriguez wrote: This man has it right. I dont think quality is a huge issue though unless youre watching something that needs to be sensitive to the eye in which case youtube will work just fine for these videos. Youtube supports resolutions of 4k, I don't see the problem with quality. Somehow the same DConf videos are of better quality on archive.org than on youtube.com. Could you explain that? -- Andrei archive.org serves the same file you uploaded to Youtube, without change. Youtube always re-encodes the video, for various reasons: - sources are very heterogeneous - multiple formats needed for various devices, various resolutions, and bandwidth adaptation - insanely low bitrates (3000kbps for 1080p H.264 is scarce, yet it's not so bad with the encode Youtube does) So while Youtube quality might be worse, the used bitrates are probably not the same. My opinion is that it's best to let Youtube serve the content for maximum reach. And you can always download a high-quality version from YouTube in various formats (including the original format) using something like ClipGrab.
Re: Weird…
On 7/15/14, 9:56 AM, Russel Winder via Digitalmars-d wrote: Funny how when people send big smiles, they always mention D? :-D :D I seem to recall that at some point someone proposed a larger version of :D as a logo for dlang. It even preserves the two moons :D
Re: Cool Stuff for D that we keep Secret
On 7/14/14, 5:03 AM, w0rp wrote: Then I wondered if the "Documentation" section should be renamed "Language Specifications" and the links renamed to "DMD 1" and "DMD 2" or if they should be merged into the sections for DMD 1 and DMD 2 respectively, because 7 year old DMD 1 specs are now pretty much obsolete? Someone new to the web site looking for (current) compiler documentation will only get confused. That's a good shout. I like the "Language Specifications" suggestion. I'll make a note to change that later. When I first reorganized the current site I ended up using "Language Reference" and "Library Reference" for the D-spec and Phobos docs, respectively. There was also a collection of articles which fell under documentation, for lack of a better place to put them, and the Documentation section has grown since. I don't know where the documentation link should take you, but there are a number of sections under the current Documentation (including not one, not two but three "tutorial" links, each named slightly differently and all of which leave dlang.org). I personally think that "Language Specification" is a bit narrow to cover all those topics.
Re: This week's pull stats
On 7/13/14, 10:32 PM, Brad Roberts via Digitalmars-d wrote: I'm playing with the idea of a once a week sort of status email. There's a lot of people to thank and recognize their valuable work. With the recent calls for more folks to review pull requests, I think a message like this may help with motivation and with keeping the topic fresh in folks' minds. It might be worth also including a link to the pull request page(s). In any case I like the idea of a weekly update like this.
Re: Random points from a D n00b CTO
On 7/14/14, 4:56 AM, Joakim wrote: One line of thought that's been evolving for me lately is that D needs a blog, where we can highlight good stuff about the language. Go has one: http://blog.golang.org/ This post should go on D's: http://forum.dlang.org/post/mailman.3738.1405098936.2907.digitalmar...@puremagic.com I could see H.S. Teoh writing a series of such posts, expanding on each of the bullet points. Right now, he'll throw something off on the forum and it'll get buried by all the posts on here, missed by most users. A blog is where such material could be highlighted. We even have a D blog engine built on vibe.d that we could put to use: https://github.com/rejectedsoftware/vibelog I'd be happy to administer such a blog, if it's a matter of someone volunteering. I think some of Walter's Dr. Dobb's posts would also fit very well in a D blog format. It would be cool if he could get permission to post a copy on this hypothetical blog. The current Articles section on the website may have some overlap with the purposes of a blog, too. Perhaps they could be merged somehow, or perhaps provide a "promotion" process from one to the other. This blog idea (and offer to volunteer) probably deserves its own thread.
Re: before D there was d
On 7/9/14, 6:17 AM, jim schmit wrote: i recently sent this email to andrei. he encouraged me to post it in this forum. here it is: hi andrei a colleague recently pointed me to the wired article about you & your D computer language. thought you might be interested an earlier attempt to produce a new & better computer language that we called d (lower case). fear not, i am an engineer, not a lawyer, & do not sue people. my name is jim schmit. i am a retired engineer / professor / entrepreneur / international business man / corporate executive. I wrote my 1st program over 50 years ago. i worked for IBM as a systems engineer on the first OS on big iron. disillusioned with the consequences of complexity in computer design (i am a pathological minimalist), i dropped out to become a computer science professor & "do my own thing". i was extremely active at the birth of the microcomputer. in the mid 70's i created a programming system for small cheap control computers based on a stack architecture pseudo machine. it was tiny intended to fit entirely in a 2K byte eprom. the run time system consisted of a set of “base” functions that fit in less than 1/2 K bytes of memory. there was no interpreter, the code was threaded. the application fit in the other 1 1/2K. the functions used byte codes & used less than 1/3 the space of well written machine language and ran at 1/2 the speed of machine code. net results…3x the functionality in the same rom while far easier to write & debug code. i called it omega before i could commercialize my system, i was distracted. i was commissioned to design & build what became known as CompuTrac, the first microcomputer based technical analytic system for trading the commodities markets. it became an instant hit & we soon found ourselves at the forefront of real time trading systems. we developed initially for the apple II & later the PC. by the late 70’s we were searching for a new hardware platform & disappointed in the options available decided to “roll our own”. we revisited omega as the basis for a real time graphic workstation. a former customer, turned competitor, named his product omega, so we renamed the language d (after c). with 2 former student assistants, paul johnstone & ana maria roa, we started delta digital designs “strong designs & innovative coffee”. we introduced our delta computer with d software in late ’83. the software extended into the new windowed environment but remained small & quick. Our first product was called TradePlan. it was a real time vector spreadsheet with constantly changing graphic output. it could monitor 3 real time ticker feeds of exchange trading data, maintain a local data base of time series prices, feed 4 spreadsheets that were fully user programable to calculate technical indicators & create a trading system with alarms of opportunity & display all on constantly updating charts. the d machine run time system containing multitasking scheduler, real time i/o handlers, a complete graphic windowing capability ran in under 8K of code. The trade plan app code was under 24K. running on a 6809 processor, it was highly user responsive & could keep up with the workload. it became famous in it’s small world of finance. In 1985 both CompuTrac & Delta Digital Designs was bought by Dow Jones / Telerate. at dow, our products were renamed, extended & added to. we did another product called Matrix that was a user programmable financial market monitor / consolidator that proved very popular. In the late 80’s our products generated just under $1B revenue for DJ. Matrix used the 3rd iteration of the d language, rebuilt to be fully object oriented. I retired in 1992 but my team continued the work for dow & a series of other owners until 2003. if any of this is of any interest to you, please let me know. regards Whew, Walter dodged a bullet there by capitalizing his "D" language! :) Seriously though, this is a fascinating glimpse at some interesting technology and history. Many thanks for taking the time to post this here.
Re: Thanks for the bounty!
On Friday, 4 July 2014 at 20:31:20 UTC, Walter Bright wrote: On 7/4/2014 5:49 AM, Andrej Mitrovic via Digitalmars-d wrote: Now *that* I definitely cannot work on. It's a complete conflict of interest due to our two companies. :) Dang, we can't afford any mutiny on the bounty! I just have to say, it's messages like this that keep me reading this newsgroup! :)
Re: Redesign of dlang.org
On 6/30/14, 2:11 PM, Gary Willoughby wrote: On Sunday, 29 June 2014 at 22:15:48 UTC, w0rp wrote: I just finished translating all of the pages I have worked on so far from diet templates to Markdown files. Now there is only one diet layout loaded, and the rest is all Markdown files. This has dramatically reduced the amount of memory consumed at build time. You can see the results at the usual place at http://w0rp.com:8010 and view the source on GitHub. I'll keep at it and convert more pages from the main site. Please use the correct logo and the correct colours. Branding is extremely important! http://media.sukimashita.com/d/d-5.svg My opinion is that the redesign preserves the spirit of the current logo while fitting in well with the flatter look. I think someone who sees the one logo will recognize the other in it (unlike some of the recent proposed logos).
Re: Redesign of dlang.org
On 6/29/14, 3:15 PM, w0rp wrote: I just finished translating all of the pages I have worked on so far from diet templates to Markdown files. Now there is only one diet layout loaded, and the rest is all Markdown files. This has dramatically reduced the amount of memory consumed at build time. You can see the results at the usual place at http://w0rp.com:8010 and view the source on GitHub. I'll keep at it and convert more pages from the main site. This is looking really good!
Re: D Logos
On 6/24/14, 9:03 AM, Alix Pexton wrote: On 22/06/2014 9:52 AM, Alix Pexton wrote: I feel that most of the new logos that have been proposed lately are too much of a departure from what we already have, so I'm throwing a few of my own designs into the ring. https://drive.google.com/file/d/0B3i8FWPuOpryQU9OQlMydXJmeTQ/edit https://drive.google.com/file/d/0B3i8FWPuOpryMmJZSnpkdnNyR2M/edit A... In the spirit of being my own harshest critic, I did one more logo that addresses my biggest gripe with the originals. While the originals were still distinctive at small sizes, the incorporated letter-Ds became illegible. This revision retains the same character but with more clarity when shrunk. https://drive.google.com/file/d/0B3i8FWPuOpryYWxJOXUwYU8yQ0U/edit A... I really like this. With all the three-faced cube designs I worry a little that it's saying "3D" instead of "D language" but I mostly don’t care; this is a very good-looking logo.
Re: Adding the ?. null verification
On 6/21/14, 4:32 PM, deadalnix wrote:
On Saturday, 21 June 2014 at 22:40:32 UTC, H. S. Teoh via Digitalmars-d
wrote:
On Sat, Jun 21, 2014 at 03:26:45PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
On 6/19/14, 1:29 PM, Etienne wrote:
>writeln(currAssignment.safeDeref.typeInfo.ident.or("meh"));
"or" is really nice and terse. I think we should add that to std.
safeDeref isn't the best choice of name.
[...]
What's your suggestion?
T
maybe is fine. Last time I checked, it isn't only a monad in haskell,
but also vastly used by these peoples who speak english.
I like "maybe" too. "nullSafe" might also be a reasonable bikeshed color.
Re: A Perspective on D from game industry
On 6/15/14, 11:56 PM, w0rp wrote: I was considering getting a job in the games industry, so I applied to a bunch of places in the UK during my final year of university. When you filtered out the jobs that were looking for years of industry experience, then filtered out the jobs that expected you to work terribly long hours, you got to the positions that said, "We'll get you started as a tester." I switched to web development, where I work roughly 9-5 for a good salary, and I never looked back. Pretty similar to me, although like Nick I never even tried to interview. Now I write iPhone games as a hobby with no pressure to try to make a living from it, and enjoy it quite a bit!
Re: [OT] DConf socks
On 6/10/14, 1:52 PM, Walter Bright wrote: On 6/10/2014 1:18 AM, JR wrote: Missed opportunity to use std.socks.assumeMine and netting yourself an extra pair... The trouble with the socks datatype is the destructor is randomly run on only one of each pair. For Windows users this situation was recently complicated by marking winsock.d as nothrow, with the upshot that now you can't throw away the remaining sock.
Re: pyd - continuous integration
On 6/10/14, 1:31 AM, Russel Winder via Digitalmars-d wrote: On Mon, 2014-06-09 at 22:37 +, Ellery Newcomer via Digitalmars-d wrote: So pyd is at the point where it really needs some sort of test suite runner. It's kind of complicated since I need to test against * multiple versions of dmd/ldc/gdc * multiple versions of python (2.4 - 3.4, but I'm thinking of dropping 2.4 and 2.5 this year) Unless there is an extant user base for 2.4 and 2.5, I would drop them with immediate effect, which would allow to upgrade to a reasonable Python code quality. There are very few people still stuck with 2.5 even fewer with 2.4 and increasingly 2.6 is going away (but not totally thanks to Red Hat :-( I suggest ignoring 3.0, 3.1 and 3.2, and supporting only 3.3 and later. This gives a much greater chance of having a single Python codebase executable with either 2.7 or 3.3/3.4. So if you can drop 2.6 as well, things get almost livable with. Personally I only use 3.4, but there are those who will not upgrade and insist on using 2.7. * redhat, ubuntu, osx, windows, etc Fedora and Debian. Does anyone have any suggestions on how or where to set this up? I had a peek at atlassian bamboo, but it looks like it only plays with ec2, which I don't know anything about. There is TeamCity, I am involved in a couple of projects using that. Works well and (unsurprisingly) had excellent support in IntelliJ IDEA and PyCharm. Bamboo can be a bit of a pain, but once set up work well. I am using the Codehaus instance because some of the project I work on are Codehaus projects. You could run Jenkins somewhere. I guess the issue is being able to set up 9 or 10 virtual machines for all the variants needed. Perhaps a good solution would be to run Buildbot, have the server local to you and ask for volunteers to offer slaves. This used to work very well for me for a now dead project. It also used to work excellently for the SCons project, but since the exit of the two main developers, there has been a bit of hiatus. This is being fixed now, and a good Buildbot set up being put in place. In regards to setting up virtual machines the folks at my work use Vagrant. I don't have experience with this but I thought I'd mention it in case it helps.
Re: What's going on with std.experimental.lexer?
On 6/10/14, 3:57 AM, Iain Buclaw via Digitalmars-d wrote: I agree all the way with std.experimental as the package name. Though I might throw in an alternative argument to stdx and instead promote unsafe.* or std.unsafe. ;-) The only issue I see with *.unsafe.* is that it sounds related to @safety. So far I haven't seen a better name than std.experimental.
Re: [OT] Extra time spent
On 6/6/14, 11:01 AM, Nick Sabalausky wrote: Bottom line is, managers are purely liabilities, not assets. It's no surprise to me that the best software out there is usually OSS, where there isn't one damn manager anywhere to be found. Funny how people think managers perform an actual function, and yet we get by fine - BETTER - without their existence. In my experience a good manager protects you from outrageous demands from the customer. Just the kinds of examples that were mentioned earlier in this thread, in fact. I'm lucky to have had a couple of managers that actually do this, and I'm super grateful for them.
Re: Optional monitors suggestion
On 5/18/14, 7:10 AM, David Nadlinger wrote: ... Java classes could just be translated to "@synchronizable class" or whatever. Whether we preserve backwards compatibility or not, @synchronizable has my vote for the bikeshed's color.
Re: New opportunities for D => ASM.js
On 5/16/14, 11:52 AM, Nick Sabalausky wrote: But then using it as a GUI engine and software platform is like abusing Latex or PDF to make software run inside Acrobat Viewer. All the effort, bloat and compromises...and for what point? I assume that question is mostly rhetorical, because of course the point for many companies is that while some subset of users may have Acrobat Viewer installed, everyone has a browser. Compare the process of installing a native app (even on simple devices like phones) to the single click for loading a web app. Add to that making sure the user gets timely bug fixes and new features and it's easy to see why web apps make sense for many companies. It's just tragic that the format for them evolved through HTML; it's become monstrous and deformed in all the ways you've discussed.
Re: Redesign of dlang.org
Is this still happening? Is there a repo or a place I can go to help?
Re: std.allocator: false pointers
On 5/2/14, 11:56 AM, Andrei Alexandrescu wrote: If speed is no issue, sure :o). My intuition is that the TwoBitVector would need certain primitives from BitVector to work well. Heh, however it's implemented, TwoBitVector's very name implies that it's cheap to use ;)
Re: Redesign of dlang.org
On 4/21/14, 12:38 PM, Aleksandar Ruzicic wrote: I'm not sure if it is smart to use simple text macro processing system as a replacement for full-featured DSL such is Sass. And I don't think that some features available (and really useful!) in Sass are even possible with Ddoc. For example branching with @if, composing of various style sets to optimal CSS (Sass has @extend directive for this). Also, Ddoc can't minify resulting CSS which is something that is considered good practice (serve gzipped minified JS/CSS), so some external tool must be used for that. With node-sass we can get all that and more (i.e. source maps).. A little searching turned up libsass.org which apparently is the native library that node.js uses for its implementation. So if there's an objection to full node.js (or if vibe.d is used) then perhaps the native library would do.
Re: Redesign of dlang.org
On 4/18/14, 9:25 AM, Aleksandar Ruzicic wrote: On Friday, 18 April 2014 at 15:30:52 UTC, David Gileadi wrote: [snip] Also note that there's a movement to make at least part of the website (the Phobos docs) use a different documentation generator, so the new look would need to be ported to that too. I suspect that wouldn't be hard. I wasn't aware of that, do you by any chance have links to those threads? I'm having trouble finding the thread, but I think the idea was to use vibe.d's ddox[1]. There's a preview of it live at the "Preview new Layout" link at dlang.org. Folks, please correct me if I got this wrong and that preview is not powered by ddox. [snip] Finally I like your look; I think it would be worth refining and pursuing. I make no claim to be a graphic designer and I'm certainly not offended by any criticism of the current look; at the time I had two goals; 1) look better than the previous site at digitalmars.com and 2) tame the massive sidebar into something more reasonable. I think they both succeeded but I'm very aware that things can look better. Thanks! It is just a mockup I made in an hour or so, I would like to have some real designer(s) involved in this to make it really better. If you have access to real designers (as you mentioned in another message) that would be fantastic. I think the mockup you created is already a good direction but folks with experience in UX, typography, responsive design etc. could probably make dlang.org properly great. The current design is waaay better than what we had before and I thank you on that! That change was really refreshing. I just think that we should keep pushing forward. And I would also like if you could be able to join me in a new redesign (if it gets approval), at least in a consulting role. :) I'd be happy to help. My time is more divided nowadays but I'm sure I can put some time into this. While we're at it some good mobile support would be awesome too. [1] http://devdocs.io/ [1] https://github.com/rejectedsoftware/ddox
Re: Redesign of dlang.org
On 4/18/14, 7:22 AM, Steven Schveighoffer wrote: On Fri, 18 Apr 2014 10:04:03 -0400, Aleksandar Ruzicic wrote: Hello, I've been D enthusiast for couple of years now (but I do not participate much in discussions here, although I read forums almost daily), and I keep telling people about D and how awesome it is. Great! But, all this time D's official website somehow archaic look kept troubling me. It reminds me of early 2000's design and I really cannot associate this design with "modern" or "elegant", what D really is. I think that we must invest time and energy improving the website's look and feel as that is what people first coming to D will see. We need to strive for "wow" and not "meh" as a first impression. So I have started this thread to see if there is a chance for complete redesign of dlang.org. I have also tried to design something myself (although I'm not a designer) and this is what I came up with: http://krcko.net/dlang.org/dlang-home-draft1.png I'm not entirely satisfied with it but I believe that it looks better (or at least more modern) than the current design. So, what do you guys think? To be honest, it looks no "better" than the current website. Basically it's more windows-8-ish. But I don't think it's a significant improvement. BTW, I don't think you properly remember early 2000's web sites... I don't share your opinion that the web site need to be "modern" to avoid warding off potential adopters. If they are turned off of using a system programming language by a bland (debatable) site look and feel, then I think there was really something else bothering them. That being said, changing look and feel has a "this site is being maintained" air to it. I just don't think it's critical enough at this point to diverge talent away from working on the language. -Steve As the guy who was mostly responsible for the current look and feel of the website I can provide some insight into the effort required. The website is built using DDoc[1], and anyone who wants to change the look and feel will need to learn it. It's not difficult. It does mean that the site is static HTML, so any dynamism needs to be JS-only (and I think any efforts to make the pages largely JS-driven would meet resistance). What was a little weird was trying to use DDoc to expand" the navigation tree when you're on a subpage of a main category. The original website listed every single page in the sidebar, which made the sidebar extremely unwieldy. Due to DDoc limitations I ended up having to put a CATEGORY_FOO macro in each page in the site, where the FOO is one of the categories in the sidebar. You may be able to figure out a better way. Just fork the site on github[2] and experiment! Also note that there's a movement to make at least part of the website (the Phobos docs) use a different documentation generator, so the new look would need to be ported to that too. I suspect that wouldn't be hard. Be aware that the current Tweets sidebar on the main page may be hard to get rid of; I noticed it wasn't in your mockup :) Based on the last go-around there would be some work required from Walter and Andrei, but assuming you're implementing the new look and feel then their work would be mostly related to pushing changes to a beta site and then to the main site. They can probably speak better to the amount of effort they'd need to put in. If you're not doing the work of implementing the new look and feel then I suspect this proposal is dead on arrival unless someone else steps up to help. Finally I like your look; I think it would be worth refining and pursuing. I make no claim to be a graphic designer and I'm certainly not offended by any criticism of the current look; at the time I had two goals; 1) look better than the previous site at digitalmars.com and 2) tame the massive sidebar into something more reasonable. I think they both succeeded but I'm very aware that things can look better. [1] http://dlang.org/ddoc.html [2] https://github.com/D-Programming-Language/dlang.org
