Re: D Article: Memory Safety
On Thu, Jan 21, 2016 at 04:59:01AM +, Basile B. via Digitalmars-d-announce wrote: [...] > Altgough one thing, attributes are not the easy part of D. I've > recently encountered a case were in the library attributes were > allright, test OK, and then suddently when I've started to use the > library in a real life context I had to remove them from the > library...@safe was unsustainable. Phobos/druntime still has some ways to go before using it from @safe code will be painless. Some pretty fundamental functionality still isn't @safe (mainly some stuff in object.di that basically interacts with too many other things that marking one thing as @safe will percolate throughout pretty much everything, breaking a whole bunch of stuff at once). I once tried writing a @safe program, and it didn't take very long before I threw that idea out the window. Once main() is @safe, you're so straitjacketed that you basically can't write anything too much more complex than Hello World. (Well, you *could* just slap @trusted on whatever it is that's holding you back, but then that breaks the promise of @safe, which defeats the purpose of the entire exercise.) There's also still a good number of @safe-related bugs on Bugzilla, several of which involve built-in language constructs that break @safe-ty outright. Things have improved a bit since I last checked, but it seems to me that @safe is still not quite ready to live up to its promise just yet. Maybe in a few more years' time... > Dealing with attributes is the hardest part of D IMO. No one is > forced to btw, there are plenty of other cool things in D but to > follow the D safety is hard... [...] I think Walter has mentioned before that attribute inference is the way to go, and I agree. Once you start writing carefully-attributed code, you'll quickly find that your declarations become painfully verbose, which is never a good sign (it encourages people not to use attributes). However, attribute inference on templates and auto functions (proposed last year, don't know if it's implemented yet) alleviates a lot of the verbosity. Hopefully the scope of attribute inference will increase until it makes attribute use more widespread in your everyday D code. T -- MS Windows: 64-bit rehash of 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand 1-bit of competition.
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: Walter on his experience as a dev, on running an open source project and D
On Wednesday, 20 January 2016 at 11:07:16 UTC, Rikki Cattermole wrote: From what Walter said, they all knew c. So not really too low level for them. To me it looked like: Walter: "You all write in C, right?" Audience silent with expression on their faces "What is C? We've only heard about JavaScript". ;)
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 } ();`
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.
Re: D Article: Memory Safety
On Thursday, 21 January 2016 at 04:59:01 UTC, Basile B. wrote: On Wednesday, 20 January 2016 at 14:04:53 UTC, Jakob Ovrum wrote: 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. Good work. Someone has to re-edit-it if not yet reeddited. Altgough one thing, attributes are not the easy part of D. I've recently encountered a case were in the library attributes were allright, test OK, and then suddently when I've started to use the library in a real life context I had to remove them from the library...@safe was unsustainable. Dealing with attributes is the hardest part of D IMO. No one is forced to btw, there are plenty of other cool things in D but to follow the D safety is hard... congrats nice article. I mean '@safe' at too low level is a handicap. It's like 'const'. They are hard to use, mostly because of transitivness. These attributes are never a noop.
Re: Walter on his experience as a dev, on running an open source project and D
On Wednesday, 20 January 2016 at 21:38:55 UTC, Walter Bright wrote: On 1/20/2016 12:41 PM, epsilomish wrote: Actually, the 'alias this' is probably not that much a problem. In their shoes I would even ask myself: mmh what is this obscure feature, let's have a deeper look to D...Anyway the technical part of the talk is small, there is the thing about lexical D t_h_i_n_g_s, the octal template and half-floats...It globally works. I wanted a mix of trivial and advanced stuff, so there was something for everyone. That's well reflected, despite of my first comment. One thing I'd like to say in reaction the first part: noise and fan. Personally I can't live without noise anymore. I used to be obsessional about silence but now I think it's very relaxing to have a fan turning again and again, by fan I mean: http://www.cinni.com.au/images/pedestalFans.jpg They produce a LF vibe which is very relaxing. For example now, here, where I live: https://www.google.fr/maps/@48.5591464,7.7793422,9z?hl=fr It's 21.2 F° outside, but I still have the good vibes from the low frequency generator in my computer room. a steady purr.
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 14:04:53 UTC, Jakob Ovrum wrote: 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. Good work. Someone has to re-edit-it if not yet reeddited. Altgough one thing, attributes are not the easy part of D. I've recently encountered a case were in the library attributes were allright, test OK, and then suddently when I've started to use the library in a real life context I had to remove them from the library...@safe was unsustainable. Dealing with attributes is the hardest part of D IMO. No one is forced to btw, there are plenty of other cool things in D but to follow the D safety is hard... congrats nice article.
Re: D Article: Memory Safety
On Thu, Jan 21, 2016 at 05:09:48AM +, Basile B. via Digitalmars-d-announce wrote: [...] > I mean '@safe' at too low level is a handicap. It's like 'const'. They > are hard to use, mostly because of transitivness. These attributes are > never a noop. Transitivity also makes const really painful to use in a widespread way. I've tried writing const-correct code before too, but gave up because it quickly became too unwieldy to work with. I started spending more time hunting down missing const attributes than actually writing useful code, so I decided it was time to give up. Generally, though, const is still useful in lower-level code (i.e., near the leaf nodes of your function call tree), to prevent silly mistakes. Knowing how to use const is also helpful in utility functions that need to accept both immutable and mutable, etc.. Just like with (the current state of) @safe, though, pervasive use of const is still too onerous currently. Transitivity really makes it painful, especially when important chunks of Phobos still isn't fully const-correct (or at least const-compatible) yet. A lot of progress has been made, but, const being transitive, all it takes is for one small Phobos function to be non-const when it should be const, and your entire call tree can no longer be const. Encounter this a handful of times, and it's hard not to just throw in the towel instead of spending all of your time working around const issues rather than writing useful code. (Recently I'm slowly moving towards writing *all* my code as template functions, and letting the compiler do the tedious work of attributing my code instead of typing them out myself. My secret wish is that one day, the compiler's attribute inference will be good enough that I could just slap one or two const's (or @safe, etc.) on top of my modules and everything will Just Work.) T -- Only boring people get bored. -- JM
Re: D Article: Memory Safety
On Wednesday, 20 January 2016 at 14:04:53 UTC, Jakob Ovrum wrote: 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. my experience with @safe: 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
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 14:04:53 UTC, Jakob Ovrum wrote: 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. Nice article! Feeling like I have a much better grasp on the whole attribute system now that I read it, thanks! :-)
Re: Walter on his experience as a dev, on running an open source project and D
On 1/20/2016 12:41 PM, epsilomish wrote: Actually, the 'alias this' is probably not that much a problem. In their shoes I would even ask myself: mmh what is this obscure feature, let's have a deeper look to D...Anyway the technical part of the talk is small, there is the thing about lexical D t_h_i_n_g_s, the octal template and half-floats...It globally works. I wanted a mix of trivial and advanced stuff, so there was something for everyone.
Re: Dates on Website [was Using D with IntelliJ]
[…] > http://wiki.dlang.org/IDEs […] Can someone convert the dates to proper ISO8601 format. Whilst the current form is neither traditional USA nor traditional (almost) rest of the world, it is a bit of a mess. Covnerting to IS8601 would be the best solution. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Airfares to Berlin for DConf 2016
I saw on the news this evening that air fares for the next 3 weeks will be at a 3 year low. It's a good time to book the flights to Berlin!
Re: Beta D 2.070.0-b2
On Tuesday, 19 January 2016 at 13:07:50 UTC, Nordlöw wrote: I'm still missing entries for - https://github.com/D-Programming-Language/phobos/pulls?utf8=%E2%9C%93=is%3Apr+is%3Aclosed++author%3Anordlow - https://github.com/D-Programming-Language/phobos/pull/3288 Well, please write them (targeting stable). Changelog entries should nowadays be part of pull requests. https://github.com/D-Programming-Language/phobos/blob/ca3b4c839770a02f2414b20aa11c38f79419871b/changelog.dd#L9
Re: Airfares to Berlin for DConf 2016
On 01/20/2016 10:04 AM, Walter Bright wrote: > I saw on the news this evening that air fares for the next 3 weeks will > be at a 3 year low. It's a good time to book the flights to Berlin! Though subway tickets were increased in 2015 and reached an all-time high of 2,70€ ;). It's great to have the conference in Berlin, looking forward to see all of you.
Re: Walter on his experience as a dev, on running an open source project and D
On 21/01/16 12:22 AM, epsilomish wrote: On Wednesday, 20 January 2016 at 11:07:16 UTC, Rikki Cattermole wrote: On 20/01/16 11:58 PM, Joakim wrote: On Wednesday, 20 January 2016 at 03:13:38 UTC, deadalnix wrote: https://www.reddit.com/r/programming/comments/41sdzj/walter_bright_on_being_a_developer_running_an/ Thanks for the link, just watched all four parts. I'm not sure Walter is the right speaker for those kids, like having Yoda lecture a bunch of young padewan. His half-float example was likely too low-level for that audience, better to show something you'd do in ruby or python and explain how it'd run _much_ faster in D, while not much more difficult to write. From what Walter said, they all knew c. So not really too low level for them. But half-float uses the 'alias this' trick, furthemore on a getter function. Without a bit of D knowledge you can't get how it's subtle. Yeah I agree, alias this was definitely too much for them. But half float wasn't an issue IMO.
Re: Walter on his experience as a dev, on running an open source project and D
On Wednesday, 20 January 2016 at 11:07:16 UTC, Rikki Cattermole wrote: On 20/01/16 11:58 PM, Joakim wrote: On Wednesday, 20 January 2016 at 03:13:38 UTC, deadalnix wrote: https://www.reddit.com/r/programming/comments/41sdzj/walter_bright_on_being_a_developer_running_an/ Thanks for the link, just watched all four parts. I'm not sure Walter is the right speaker for those kids, like having Yoda lecture a bunch of young padewan. His half-float example was likely too low-level for that audience, better to show something you'd do in ruby or python and explain how it'd run _much_ faster in D, while not much more difficult to write. From what Walter said, they all knew c. So not really too low level for them. But half-float uses the 'alias this' trick, furthemore on a getter function. Without a bit of D knowledge you can't get how it's subtle.
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: Logo for D
On Monday, 18 January 2016 at 22:48:52 UTC, Brad Anderson wrote: On Monday, 18 January 2016 at 10:28:48 UTC, Guillaume Piolat wrote: On Saturday, 16 January 2016 at 17:55:13 UTC, karabuta wrote: I've long wished the D and moons were what was considered the logo[1]. The current one has three borders, a drop shadow, and gradients up the wazoo. Anything tacked on beyond the iconic shape should just be done based on context (like using red or white for the logo, a background color, etc.) http://i.imgur.com/RSBLFDJ.png Doesn't it look so much better: http://i.imgur.com/QlrbCou.png Waw!! I never new the thing at the top was a moon when I was doing my version :) Is that a moon on the "D" and Mars below the D? :) I now get it. I agree it should be simple. You cannot embroid the depth and shadow in the current logo.
