Re: smile.amazon.com Promotion
On Thursday, 1 November 2018 at 03:18:44 UTC, SealabJaster wrote: On Monday, 29 October 2018 at 16:40:20 UTC, FooledDonor wrote: On Monday, 29 October 2018 at 16:01:38 UTC, Mike Parker wrote: One of the easiest ways to support the D Language Foundation is using smile.amazon.com when you make a purchase. Until Nov 2, they're running a special where they're donating 5% (10 times the usual amount) you buy through AmazonSmile. smile.amazon.com/ch/47-5352856 Perhaps a fundamental principle is not clear enough at the foundation: transparency. Where is the vision of the third and fourth quarter? Where are the deliveries of things in the pipeline? What is the progress of the various jobs started? Which people is funding, with how much money and for what expected results? Where is the newCTFE? Was the work on this point financed by the foundation? I've never seen a report on the state of affairs, neither from the president, nor from Andrei, nor from Walter. How do you hope to obtain trust and funding, if NO one even deigns to give the least development plan or feedback on past developments? It seems that everyone has locked up in their ivory tower ... It's kind of discouraging to see that your post, as well as another thread asking something similar regarding the vision document[1] have gone unanswered... Maybe the people who could answer these things just don't see them, or maybe they're purposefully being quiet. It would be nice to know what's going on at the very least ;( [1] https://forum.dlang.org/thread/qmwovarkjgvxyibsl...@forum.dlang.org My guess, and this is purely a guess, is that they got discouraged by how few people paid attention to the Vision document or donated to the foundation on Opencollective and haven't bothered with this stuff since. I think that's a mistake, as you may need to do this stuff for awhile before it picks up. In any case, I don't care that it isn't happening, as I always said that it's better to have decentralized bounties, like we had on bountysource, rather than centralized funding through the D Foundation. Maybe the upcoming targeted campaigns will be a good middle ground, in that you will be able to directly contribute to specific targets: https://dlang.org/blog/2018/07/13/funding-code-d/
Re: smile.amazon.com Promotion
On Monday, 29 October 2018 at 16:40:20 UTC, FooledDonor wrote: On Monday, 29 October 2018 at 16:01:38 UTC, Mike Parker wrote: One of the easiest ways to support the D Language Foundation is using smile.amazon.com when you make a purchase. Until Nov 2, they're running a special where they're donating 5% (10 times the usual amount) you buy through AmazonSmile. smile.amazon.com/ch/47-5352856 Perhaps a fundamental principle is not clear enough at the foundation: transparency. Where is the vision of the third and fourth quarter? Where are the deliveries of things in the pipeline? What is the progress of the various jobs started? Which people is funding, with how much money and for what expected results? Where is the newCTFE? Was the work on this point financed by the foundation? I've never seen a report on the state of affairs, neither from the president, nor from Andrei, nor from Walter. How do you hope to obtain trust and funding, if NO one even deigns to give the least development plan or feedback on past developments? It seems that everyone has locked up in their ivory tower ... It's kind of discouraging to see that your post, as well as another thread asking something similar regarding the vision document[1] have gone unanswered... Maybe the people who could answer these things just don't see them, or maybe they're purposefully being quiet. It would be nice to know what's going on at the very least ;( [1] https://forum.dlang.org/thread/qmwovarkjgvxyibsl...@forum.dlang.org
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Thu, Nov 01, 2018 at 02:45:19AM +, unprotected-entity via Digitalmars-d-announce wrote: [...] > Another thing to look for, is signs of code smell. I would include in > this, unit tests calling private methods (which seems to be a popular > thing for D programmers to do). Some will disagree that this is a code > smell, but I have yet to see a good argument for why it is not. White-box testing. In principle, I agree with you that if your unittests are doing black-box testing, then they should definitely not be calling private methods. However, limiting yourself to black-box testing means your private functions can be arbitrarily complex and yet it's not thoroughly tested. Sometimes you really do want a unittest to ensure the private method is doing what you think it's doing, and this requires white-box testing. This is especially important to prevent regressions, even if it seems redundant at first. Only doing black-box testing means a later code change in the private method can subtly introduce a bug that's not caught by the unittest (because it cannot call a private method directly to verify this). > Forget LOC. Look for good architecture, decoupling, modularity, > encapsulation, information hidingetc..etc... again, sadly, these > concepts are not directly promoted when writing modules in D, since > the module exposes everything to everything else in the module - and > programmers will surely make use of any convenient hack that avoids > them having to think about good architecture ;-) [...] Actually, code within a module *should* be tightly coupled and cohesive -- that's the whole reason to put that code inside a single module in the first place. If two pieces of code inside a module are only weakly coupled or completely decoupled, that's a sign that they should not be in the same module at all. Or at the very least, they should belong in separate submodules that are isolated from each other. But besides all this, D's philosophy is about mechanism rather than policy. The goal is to give the programmer the tools to do what he needs to do, rather than a bunch of red tape to dictate what he cannot do. That's why we have @trusted, @system, and even asm. The programmer is responsible for making sane architectural decisions with the tools he is given, rather than being told what (not) to do within the confines of his cell. If you're looking for policy, maybe Java would suit you better. :-P T -- Nobody is perfect. I am Nobody. -- pepoluan, GKC forum
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote: On 01/11/2018 2:25 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole wrote: On 01/11/2018 2:16 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson wrote: Running into such problems is a sign that your module is too large, and should become a package. I seen modules with more then thousand lines of code in the Phobos library. What exactly consist a module of being "too large"? If having two classes in a module with around 200-300 lines of code "too large"? We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive. That's nice. Again what consist of a module of being "too large"? That seems to me that more of a art then a science. Because it is. My rules (which tend to be a little stricter than most peoples) are: Soft split 1k LOC, hard split 3k LOC without a very good reason not to. But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split. I really do disagree. It's is not at all, about LOC. It is about clean architecture. D module's do not promote clean architecture. Why? Because private state is exposed to all code within a module. What will happen to clean architecture, when you make that available to programmers? Well.. we get phobos like architecture. Another thing to look for, is signs of code smell. I would include in this, unit tests calling private methods (which seems to be a popular thing for D programmers to do). Some will disagree that this is a code smell, but I have yet to see a good argument for why it is not. Forget LOC. Look for good architecture, decoupling, modularity, encapsulation, information hidingetc..etc... again, sadly, these concepts are not directly promoted when writing modules in D, since the module exposes everything to everything else in the module - and programmers will surely make use of any convenient hack that avoids them having to think about good architecture ;-)
Re: A facebook group for D programmers
On Sunday, 16 September 2018 at 23:36:16 UTC, Steven Schveighoffer wrote: This seems pretty... spamish. Apologies if that's not true, but the original message is so fill-in-the-blank-with-target-topic that it's hard to take seriously. Also the "Already has 55 members" seems weird too. Especially if it's never been announced before. -Steve It is serious, here goes a link to the group https://www.facebook.com/groups/662119670846705/
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 20:23:21 UTC, Walter Bright wrote: On 10/31/2018 6:25 AM, 12345swordy wrote: Again what consist of a module of being "too large"? That seems to me that more of a art then a science. If you're looking for a rigid rule, you won't find one. But a good indicator is if it contains more than one abstraction that has nothing particular in common with each other. Sure thing, however I wonder why "protected package" doesn't exist for classes, seems to me a missing opportunity there.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 20:24:36 UTC, 12345swordy wrote: This is an counter argument how? It isn't a counter argument (at least not to you). Just saying that I wrote a 14,000 line module, and maintain a contributed 15,000 line one. It works for me! lol
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On 10/31/2018 6:25 AM, 12345swordy wrote: Again what consist of a module of being "too large"? That seems to me that more of a art then a science. If you're looking for a rigid rule, you won't find one. But a good indicator is if it contains more than one abstraction that has nothing particular in common with each other.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 13:24:10 UTC, Adam D. Ruppe wrote: On Wednesday, 31 October 2018 at 13:16:45 UTC, 12345swordy wrote: I seen modules with more then thousand lines of code in the Phobos library. $ wc simpledisplay.d nanovega.d dom.d cgi.d 14152 54984 443111 simpledisplay.d 15289 63707 573986 nanovega.d 7159 24473 187572 dom.d 4132 16727 128299 cgi.d This is an counter argument how?
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 13:39:25 UTC, rikki cattermole wrote: On 01/11/2018 2:35 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote: On 01/11/2018 2:25 AM, 12345swordy wrote: [...] Because it is. My rules (which tend to be a little stricter than most peoples) are: Soft split 1k LOC, hard split 3k LOC without a very good reason not to. But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split. Ok, you agree that it is subjective. Why is having more then one class per file "too large"? It doesn't. It is a group of related symbols. If it doesn't have function bodies (e.g. extern(C++) or COM) I would call that module to have too small of a scope. Why do anyone have to create a file for every class if they wanted them to be encapsulated then? Why can't we put them in the same file if they are relativity small?
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On 10/31/2018 3:48 AM, Sebastien Alaiwan wrote: I think there might be some confusion between "leaky abstraction" and "insufficient encapsulation". Thanks for the excellent description of the difference.
Re: Release D 2.082.1
On Wednesday, 31 October 2018 at 19:38:54 UTC, Walter Bright wrote: It appears to be identified as malware by Windows Defender: https://issues.dlang.org/show_bug.cgi?id=18786#c10 and on hackernews: https://news.ycombinator.com/item?id=18347138 I thought that was the point of signed binaries? https://dlang.org/changelog/2.082.0.html#signed_windows_binaries
Re: Release D 2.082.1
It appears to be identified as malware by Windows Defender: https://issues.dlang.org/show_bug.cgi?id=18786#c10 and on hackernews: https://news.ycombinator.com/item?id=18347138
Re: usable @nogc Exceptions with Mir Runtime
On Wednesday, 24 October 2018 at 10:57:27 UTC, 9il wrote: Release v0.0.5 comes with - mir.exception - @nogc MirException - mir.format - @nogc formatting Fantastic!
Re: usable @nogc Exceptions with Mir Runtime
On Wednesday, 31 October 2018 at 09:13:14 UTC, Uknown wrote: On Wednesday, 31 October 2018 at 08:34:08 UTC, 9il wrote: The C++ format style is simpler to implement and it is much faster to run. D's style came from C and Boost's format. Also, the C++ style is more low level then format strings, so they can be built on top of it. I think they meant why use the `<<` operator instead of the `~` operator? ~ is used for string concatenation in D including string compile time constant concatenation. It is better not to override it because both << and ~ can be used in the same expression.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On 01/11/2018 2:42 AM, Stanislav Blinov wrote: Well, yes, it can be a litmus test, I guess. I meant to say that it isn't per se a deciding factor. It is a deciding factor for me. Because it seems to be almost always correct. As I said, my rules are stricter than what most people have. My preferences may or may not be applicable for others tho.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 13:37:07 UTC, rikki cattermole wrote: On 01/11/2018 2:33 AM, Stanislav Blinov wrote: On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote: But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split. Yup. LOC aren't a particulalry informative metric. Documentation, comments, unit tests, blanks, all contribute to it. Split by scope, by concept, by responsibility, by any implementation-relevant metric, not by LOC. As the joke goes, your word processor is doomed to fail once it also starts sending out emails... Actually it is quite informative. As a code smell it does tell you pretty decently in my experience if your scope is too large or if you are in need of refactoring. Well, yes, it can be a litmus test, I guess. I meant to say that it isn't per se a deciding factor.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On 01/11/2018 2:35 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote: On 01/11/2018 2:25 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole wrote: On 01/11/2018 2:16 AM, 12345swordy wrote: [...] We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive. That's nice. Again what consist of a module of being "too large"? That seems to me that more of a art then a science. Because it is. My rules (which tend to be a little stricter than most peoples) are: Soft split 1k LOC, hard split 3k LOC without a very good reason not to. But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split. Ok, you agree that it is subjective. Why is having more then one class per file "too large"? It doesn't. It is a group of related symbols. If it doesn't have function bodies (e.g. extern(C++) or COM) I would call that module to have too small of a scope.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote: On 01/11/2018 2:25 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole wrote: On 01/11/2018 2:16 AM, 12345swordy wrote: [...] We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive. That's nice. Again what consist of a module of being "too large"? That seems to me that more of a art then a science. Because it is. My rules (which tend to be a little stricter than most peoples) are: Soft split 1k LOC, hard split 3k LOC without a very good reason not to. But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split. Ok, you agree that it is subjective. Why is having more then one class per file "too large"?
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On 01/11/2018 2:33 AM, Stanislav Blinov wrote: On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote: But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split. Yup. LOC aren't a particulalry informative metric. Documentation, comments, unit tests, blanks, all contribute to it. Split by scope, by concept, by responsibility, by any implementation-relevant metric, not by LOC. As the joke goes, your word processor is doomed to fail once it also starts sending out emails... Actually it is quite informative. As a code smell it does tell you pretty decently in my experience if your scope is too large or if you are in need of refactoring.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 13:28:54 UTC, rikki cattermole wrote: But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split. Yup. LOC aren't a particulalry informative metric. Documentation, comments, unit tests, blanks, all contribute to it. Split by scope, by concept, by responsibility, by any implementation-relevant metric, not by LOC. As the joke goes, your word processor is doomed to fail once it also starts sending out emails...
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole wrote: On 01/11/2018 2:16 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson wrote: Running into such problems is a sign that your module is too large, and should become a package. I seen modules with more then thousand lines of code in the Phobos library. What exactly consist a module of being "too large"? If having two classes in a module with around 200-300 lines of code "too large"? We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive. That's nice. Again what consist of a module of being "too large"? That seems to me that more of a art then a science.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On 01/11/2018 2:25 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 13:22:28 UTC, rikki cattermole wrote: On 01/11/2018 2:16 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson wrote: Running into such problems is a sign that your module is too large, and should become a package. I seen modules with more then thousand lines of code in the Phobos library. What exactly consist a module of being "too large"? If having two classes in a module with around 200-300 lines of code "too large"? We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive. That's nice. Again what consist of a module of being "too large"? That seems to me that more of a art then a science. Because it is. My rules (which tend to be a little stricter than most peoples) are: Soft split 1k LOC, hard split 3k LOC without a very good reason not to. But at the end of the day, it just depends on the scope of the module. Is it getting to large? If so, split.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 13:16:45 UTC, 12345swordy wrote: I seen modules with more then thousand lines of code in the Phobos library. $ wc simpledisplay.d nanovega.d dom.d cgi.d 14152 54984 443111 simpledisplay.d 15289 63707 573986 nanovega.d 7159 24473 187572 dom.d 4132 16727 128299 cgi.d lol
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On 01/11/2018 2:16 AM, 12345swordy wrote: On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson wrote: Running into such problems is a sign that your module is too large, and should become a package. I seen modules with more then thousand lines of code in the Phobos library. What exactly consist a module of being "too large"? If having two classes in a module with around 200-300 lines of code "too large"? We have been splitting Phobos modules up: std.algorithm and most recently std.datetime They were MASSIVE as in 30k+ LOC massive.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 05:42:26 UTC, Nicholas Wilson wrote: Running into such problems is a sign that your module is too large, and should become a package. I seen modules with more then thousand lines of code in the Phobos library. What exactly consist a module of being "too large"? If having two classes in a module with around 200-300 lines of code "too large"?
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 05:00:12 UTC, myCodeDontSmell
wrote:
in D, once your write your abstraction, say a class, with it's
public interface, all the code below it can do whatever it
likes to that class, making it a leaky abstraction.
I think there might be some confusion between "leaky abstraction"
and "insufficient encapsulation".
Here's the Wikipedia definition of leaky abstractions:
"In software development, a leaky abstraction is an abstraction
that *requires* knowledge of an underlying complexity* to be able
to know how to use it. This is an issue, as the whole point of an
abstraction is to be able to abstract away these details from the
user. "
Why would imply that: as long as the user of your class isn't
*required* to know about the underlying implementation specifics,
this isn't a "leaky abstraction".
My understanding is that:
"Leaky abstractions" are about the interface design, and how one
component is meant to be used. Those are unrelated to the
programming language (e.g translating the code to another
language doesn't make the leaky abstraction disappear).
For example, a shared directory can be a leaky abstraction, if
the network is unstable (because then, the client code, which
only sees file descriptors, now has to deal with disappearing
files).
"Encapsulation" is about implementation hiding and access control
("public/private"), and requires programming language support
(e.g most dynamic languages don't have it).
Re: usable @nogc Exceptions with Mir Runtime
On Wednesday, 31 October 2018 at 09:13:14 UTC, Uknown wrote: On Wednesday, 31 October 2018 at 08:34:08 UTC, 9il wrote: The C++ format style is simpler to implement and it is much faster to run. D's style came from C and Boost's format. Also, the C++ style is more low level then format strings, so they can be built on top of it. I think they meant why use the `<<` operator instead of the `~` operator? This. Please don't do that.
Re: usable @nogc Exceptions with Mir Runtime
On Wednesday, 31 October 2018 at 08:34:08 UTC, 9il wrote: The C++ format style is simpler to implement and it is much faster to run. D's style came from C and Boost's format. Also, the C++ style is more low level then format strings, so they can be built on top of it. I think they meant why use the `<<` operator instead of the `~` operator?
Re: usable @nogc Exceptions with Mir Runtime
On Tuesday, 30 October 2018 at 16:25:12 UTC, Oleg wrote:
Thanks for your work!
Example
===
///
@safe pure nothrow @nogc
unittest
{
import mir.exception;
import mir.format;
try throw new MirException(stringBuf() << "Hi D" << 2 <<
"!" << getData);
catch(Exception e) assert(e.msg == "Hi D2!");
}
===
I don't understand why you choose C++ format style instead of
D-style format?
The C++ format style is simpler to implement and it is much
faster to run.
D's style came from C and Boost's format. Also, the C++ style is
more low level then format strings, so they can be built on top
of it.
