Re: dlang.org Re-Design Dark Theme
On Monday, 14 March 2016 at 16:42:27 UTC, Russel Winder wrote: Is this intended as a Stylist style option for the site? Yeah, I just don't want to bother with authenticating on their site right now. Feel free to submit it if you'd like to see it there. I don't know how maintenance/updating of userstyles on the Stylish repository works but how bad could it be? :) Light writing on dark background is so much nicer that the reverse. I personally agree, but I don't really care which is the default as long as both are available. The issue with light-on-dark is that if it's not applied consistently then the occasional "flashes of light" will be really disruptive, bordering on painful, and apparently for some people it's even a medical issue. I really like how Stylish handles this conveniently in a non-intrusive manner. People who don't care don't even have to know about it.
Re: dlang.org Re-Design Dark Theme
On Monday, 14 March 2016 at 13:25:02 UTC, Nordlöw wrote: On Monday, 14 March 2016 at 12:00:24 UTC, Jakob Ovrum wrote: Suggestions, forks, uploads to Stylish and so forth are all welcome. The important part is that we have an alternative that is nice on the eyes for us who use dark-coloured UIs. Looks great, apart from the red-flags on the bottom-right of the screen being a bit too dark. Thanks. Those are actually Gravatar images blocked by the Request Policy extension.
dlang.org Re-Design Dark Theme
Hello, Here's a light-on-dark theme userstyle for the recent dlang.org re-design: https://gist.github.com/JakobOvrum/e00f97f30bba4b24b6bc The front page looks like this: https://i.imgur.com/zuwVu7r.png The theme supports the front page, articles, language specification, Phobos documentation and the forums. Other subdomains, like code.dlang.org, issues.dlang.org and wiki.dlang.org are unaffected. The userstyle document is compatible with Stylish/Firefox. I might put it on the Stylish repository in the future for easier install. Suggestions, forks, uploads to Stylish and so forth are all welcome. The important part is that we have an alternative that is nice on the eyes for us who use dark-coloured UIs.
Re: D Article: Memory Safety
On Thursday, 21 January 2016 at 17:39:11 UTC, Andrei Alexandrescu wrote: Good work, thanks! Has this been reddited yet? -- Andrei I don't think so. Personally I don't think I have a reddit account, but people are more than welcome to post it wherever they like :)
Re: D Article: Memory Safety
On Thursday, 21 January 2016 at 13:52:57 UTC, Dicebot wrote: Reasonable, but the UFCS call can result from some other function defined in same module (Phobos modules are not small at all). Even small unlikely violation can completely destroy benefits of @safe so in my opinion one can't be overly cautious when documenting stuff that requires verification. I agree. Do you think it's worth mentioning UFCS functions in the article?
Re: D Article: Memory Safety
On Thursday, 21 January 2016 at 13:39:48 UTC, Dicebot wrote: I'd suggest at the very least to add a comment before "p.bar();" saying "Must not escape 'p' pointer or @safe-ty will be compromised". I thought about this case, but it relies on UFCS which is controlled by the callee. The caller can't inject that call if the callee is careful with its imports. For member functions, the this reference is `ref` and its address cannot be taken in @safe code.
Re: D Article: Memory Safety
On Wednesday, 20 January 2016 at 14:04:53 UTC, Jakob Ovrum wrote: snip Thanks for all the feedback. I've pushed a revision with further changes, most of it based on the feedback in this thread. https://github.com/JakobOvrum/jakobovrum.github.io/commit/07c270567097f6cae5d9b95c88bd4d6c8124498c (I'll try to remember not to force push over this commit and break the link, but if it is broken in the future, sorry, I probably slipped up and forgot.)
Re: D Article: Memory Safety
On Thursday, 21 January 2016 at 06:20:01 UTC, rsw0x wrote: okay, I'll just use @safe here... and nothing else in third party libraries/half of phobos is @safe friendly so I guess I'll wrap it in @trusted oh fuck it Yeah, using @trusted like that is counterproductive. Just use @system or improve the dependencies.
Re: D Article: Memory Safety
On Wednesday, 20 January 2016 at 20:28:03 UTC, Jon D wrote: This is passes the @safe constraint, but 'stdout.writeln()' and 'stderr.writeln()' do not. (My program uses stderr.) stderr/stdout/stdin are __gshared and can't be referenced by safe code. The module level version of writeln, etc., access a trusted version of stdout to avoid this. Yeah, the standard library still has a ways to go even with @safe. I always imagined that the standard pipes should use shared as opposed to __gshared. I don't think the current implementation is thread-safe, but I don't know how this affects in memory safety in this case.
Re: D Article: Memory Safety
On Wednesday, 20 January 2016 at 15:28:05 UTC, jmh530 wrote: I like the description of @trusted and template inference. Template inference, in particular, was not something that was obvious to me when first reading about D. I'm not sure how clear you make it that you can still mark templates @safe and what have you (you seem to just say don't make templates @trusted). Templated functions can still be explicitly annotated with attributes, which disables inference for those attributes. This is often a good idea even for templated functions when template arguments do not inject code, so that every instantiation has the same, known set of attributes. Attribute inference can handle it, but explicit annotations provide documentation value. I might incorporate this into the article, but I'm wary of it losing focus. I wasn't aware of the point that "@trusted nested functions in templated functions do not have to have a memory safe interface as long as all calls to the function are memory safe". Interesting. It is a necessary evil to propagate attributes correctly. Don't use it when you don't have to.
Re: D Article: Memory Safety
On Wednesday, 20 January 2016 at 19:55:45 UTC, H. S. Teoh wrote:
On Wed, Jan 20, 2016 at 07:25:43PM +, Dicebot via
Digitalmars-d-announce wrote:
`auto p = () @trusted { return &t; } ();`
Huh, I thought Andrei was opposed to this idiom? Is it now
considered reserved for templates or something has changed?
Yeah, I thought this was exactly the case where some of us
Phobos contributors got lambasted by Andrei and Walter for
abusing @trusted.
That was for non-templated functions where this approach makes no
sense. Indeed it is counterproductive, because @trusted on the
whole function is a better indication of what needs to be
reviewed for memory safety (the whole function!).
Any exception to the strict usage of @trusted to me smells like
a time bomb waiting to explode. It may not be today or
tomorrow, but sooner or later somebody is going to slip up and
the compiler won't help you. It's bad enough that every single
change to a @trusted function must be vetted to ensure actual
safety; now we have to also vet any modification to any
function that contains @trusted anonymous functions? In a large
template function, it's too easy to miss these @trusted
sub-functions, because if the code change is far away enough,
the @trusted annotation won't even show up in the diff. So
reviewers may not even realize it's a change that may have
broken @trusted.
It is the only way to solve this problem.
D Article: Memory Safety
The article aims to explain how to use @safe, @system and importantly, @trusted, including all the hairy details of templates. https://jakobovrum.github.io/d/2016/01/20/memory-safety.html Any and all feedback appreciated.
Re: LDC 0.17.0 alpha cross-compiler for Android/ARM, D 2.068.2
On Wednesday, 11 November 2015 at 22:43:01 UTC, Jakob Ovrum wrote: On Saturday, 7 November 2015 at 18:39:22 UTC, Joakim wrote: OK, I've rebuilt ldc with one small tweak: I've added the current directory to its rpath and bundled my system libconfig along with it, which is what the official ldc release does too. You shouldn't need libconfig installed by your system anymore. Please download the updated release of the Android/ARM cross-compiler and let me know if it works for you. Thanks, now compilation works! I have some unrelated issues with the NDK, so I will confirm how the end-to-end process works for me later once I solve that. The issues I had came with using the 64-bit NDK - it worked as explained in the article once I switched to the 32-bit NDK. The issue appeared to be with the linker: /usr/bin/ld.bfd would complain that it was not configured for --sysroots. Changing to --fuse-ld=mcld revealed further issues. Perhaps the wiki article should recommend the 32-bit NDK until these issues are figured out.
Re: LDC 0.17.0 alpha cross-compiler for Android/ARM, D 2.068.2
On Saturday, 7 November 2015 at 18:39:22 UTC, Joakim wrote: OK, I've rebuilt ldc with one small tweak: I've added the current directory to its rpath and bundled my system libconfig along with it, which is what the official ldc release does too. You shouldn't need libconfig installed by your system anymore. Please download the updated release of the Android/ARM cross-compiler and let me know if it works for you. Thanks, now compilation works! I have some unrelated issues with the NDK, so I will confirm how the end-to-end process works for me later once I solve that. Note that this linux/x86 ldc cross-compiler also depends on the ncurses and zlib shared libraries, so you'll have to install those if you want to run it. Yeah, libconfig was the only library that I couldn't find an Arch Linux multilib package for, I already had the others. Note that the NDK clang executable also relies on ncurses, so there wouldn't be much point in eliminating that dependency.
Re: LDC 0.17.0 alpha cross-compiler for Android/ARM, D 2.068.2
On Friday, 6 November 2015 at 20:24:18 UTC, Joakim wrote: On Friday, 6 November 2015 at 20:10:36 UTC, Jakob Ovrum wrote: On Friday, 6 November 2015 at 11:56:35 UTC, Joakim wrote: [...] Thanks for the thorough instructions! LLVM is rather massive and I'd prefer to avoid building it if I can, so I downloaded the pre-built LDC binary from the release page. However, the binary is 32-bit and depends on libconfig, which doesn't appear to have a multilib package in Arch Linux. There are of course ways around this, but would it be possible to release a pre-built 64-bit binary? Maybe, I'll see. In the meantime, you can use ldmd2, which doesn't depend on libconfig. But ldmd2 depends on ldc2, doesn't it? It seems to be trying to invoke it.
Re: LDC 0.17.0 alpha cross-compiler for Android/ARM, D 2.068.2
On Friday, 6 November 2015 at 11:56:35 UTC, Joakim wrote: https://github.com/joakim-noah/android/releases/tag/runners You will need a linux/x86 host and the Android NDK, optionally the SDK if you want to create a GUI app. A slightly older build was used to create the test runners from earlier this week. You can use this cross-compiler to build command-line or GUI apps, by following the instructions from these sections in the wiki: http://wiki.dlang.org/Build_LDC_for_Android#Build_a_command-line_executable http://wiki.dlang.org/Build_LDC_for_Android#Build_a_sample_OpenGL_Android_app_ported_to_D Make sure to set the NDK environment variable to the path of your Android NDK. There are also instructions to build the cross-compiler and test runner from source yourself: http://wiki.dlang.org/Build_LDC_for_Android Thanks for the thorough instructions! LLVM is rather massive and I'd prefer to avoid building it if I can, so I downloaded the pre-built LDC binary from the release page. However, the binary is 32-bit and depends on libconfig, which doesn't appear to have a multilib package in Arch Linux. There are of course ways around this, but would it be possible to release a pre-built 64-bit binary?
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Thursday, 26 March 2015 at 02:04:26 UTC, Laeeth Isharc wrote: You describe these as issues forming part of a critique and suggesting the substance of what he wrote is wrong, but are these substantive in the context of a quick blog post (where it is more important to say something generative than to be perfect in its expression). The comparison, as-is, is unfair. He writes a long-winded Go snippet (which it turns out is completely unrepresentative of an idiomatic Go solution[1]) then counters it with a short D solution that deceptively does less work. I did not mean to suggest his overall claims are wrong; I strongly agree with him on his main points. The problem is that he's using faulty data to reach that conclusion. I don't claim to know Go, but is his basic point off the mark? At the very least, he's completely misrepresented the difference with the unnaturally long Go snippet[1] and the incomplete D snippet. stderr.writeln(text); return 1; correctness is important, but does this change much? The size of the code is an essential point in this post. It's probably safe to say most readers can't spot the difference in semantics, which makes Go look disproportionally verbose. In the second example maybe you should print four lists to be equivalent of the Go code. I think it's misrepresentative to shorten the D example by making it do less work. surely people can see beyond a difference of three lines ? would this change his point? I think it makes a big difference visually. fair point if true (I will let others who know better say whether .array. or something is needed). join and array on byLine both suffer the same problem. Using joiner instead of join would fix it and still allow it to forego copying each line. What he wrote is correct English, and he is an Englishman living in England. Great. Again, nobody English would think this was more than mildly humorous (and by no means insulting). To suggest somebody is rabid is not to insult their intelligence, but merely to tease them about their likely strong emotional reaction. I wasn't referring to that, I was referring to the grammatical error in the quote. But what is one to do when making the trade-off between being blandly corporate and acceptable to everyone, versus writing with some character and spirit and offending the sensitive. It's a personal choice, but not easy to criticize another for theirs. I personally find the world too bland these days. One cannot police the forms of expression of people who do not speak for a community or claim to be acting as such (apologies if I am mistaken and he does have an official position within D). And perhaps one ought not to try. I intentionally did not want to criticize his post as a whole, just the methodology employed. The post has been met with a lot of scorn on Reddit, and I think it would help D's case to get the facts right. [1] https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/cpqpfjx
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Wednesday, 25 March 2015 at 21:00:37 UTC, Andrei Alexandrescu wrote: https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/ Andrei As I know Gary is sometimes (often?) on these forums I'll post some critique here. Misrepresenting Go in a comparison with D doesn't reflect well on the D community, so please have a look at the following issues: In the first code example, the Go version returns 1 on failure and 0 on success, while the D version always returns 0. Also, the Go version correctly uses stderr for error messages while the D version uses stdout for everything. In the second example maybe you should print four lists to be equivalent of the Go code. I think it's misrepresentative to shorten the D example by making it do less work. auto text = source.byLine.join.to!(string); This is not safe as byLine reuses the same buffer for every line. It may or may not work depending on join's implementation. Also, it's idiomatic to omit parantheses when a template argument list consists of a single token: source.byLine.join.to!string; With all that said, I honestly think Go’s design a disservice to intelligent programmers. s/design a disservice/design is a disservice/ From my experience of using Go it’s just too simple to create useful abstractions. This sentence is ambiguous and could be taken to mean it's really simple to create useful abstractions in Go. The intended meaning is obvious with context, but it threw me off for a second... I guess by now Go programmers reading this will be frothing at the mouth shouting “Your doing it wrong!”. s/your/you're/ That could be misconstrued as a jab at the intelligence of Go programmers, which I don't think serves your cause. Well, there is another way of implementing generic functions and data types, and that is to completely break the type system! Didn't you just say there was simply no way around it? I know object-oriented programming is no silver bullet but it would of been nice to be able to abstract details away into types and provide better encapsulation. s/would of/would have/ Also, this statement just begs for responses pointing to Go's OOP features. It has both user-defined types and encapsulation features.
Re: NEW asm.dlang.org site
On Monday, 26 January 2015 at 23:46:24 UTC, Iain Buclaw wrote: All work is hosted on Github[3], and we are planning on moving it to part of the D-Programming-Language repositories. I really wish we would eat our own dog food and use D for these projects. Nazriel's dpaste is in friggin PHP and this one is in JavaScript... we've been emphasizing D on the web yet we don't have many real examples of it in practice. Oh well, I guess at least this project has the excuse that it's mostly client-side... but I still think it's a lost opportunity.
Re: Voting: std.logger
On Sunday, 17 August 2014 at 02:55:52 UTC, Dicebot wrote: Results: http://wiki.dlang.org/Review/std.logger#Voting_for_std.experimental The link to the team-phobos page doesn't work for me, so I'm not entirely sure what it is (list of users with commit rights?), but in any case, I don't think I'm on any such list (I don't have commit rights for Phobos).
Re: DConf 2014: SDC, a D Compiler as a Library
On Wednesday, 23 July 2014 at 16:07:44 UTC, Andrei Alexandrescu wrote: Last (but not least!) talk of DConf 2014. https://twitter.com/D_Programming/status/491977150694961152 https://www.facebook.com/dlang.org/posts/889844197695929 http://www.reddit.com/r/programming/comments/2bi79s/sdc_a_d_compiler_as_a_library/ Andrei Excellent talk! I'm really glad progress is being made. Maybe I'll probe around for an opportunity to contribute, from the looks of the talk, the code looks really nice and clean.
