mir-random v2.1.0
Mir Random v2.1.0 has been released. https://github.com/libmir/mir-random The release comes with optional Mir Algorithm dependency and can be used without it except some algorithms and ND-variables. The release allows using Mir Runtime in security and web libraries, the API and dependencies are quite stable now. Set of improvements were added by Nathan Sashihara. Best regards, Ilya
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Thu, 01 Nov 2018 22:37:59 +, unprotected-entity wrote: > On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote: >> >> 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. > > How does one determine, whether a 10,000 line module, is tightly coupled > and cohesive? You can get a pretty accurate result by just saying "no". 10KLOC in one module is almost always a problem. Failing that, you can do a code review. Which will take a very long time. The solution to that is to submit less code at a time, review as you go, and keep modules smaller. For instance, Phobos keeps most modules below 3000 lines of code, including unittests. The largest module, std.datetime.systime, has about 6000 lines of code -- but if you exclude unittests and test-only code, it's more like 1000. > Only the author can make that statement - which they naturally will, > even if it's not true. I think a lot of programmers are well aware of the failings of their code. > As soon as you see a class interface in a module, in D, you have to > assume their is other code in the module, perhaps down around line > 9,900, that is bypassing its interface, and doing who knows what to > it And so you have a rule against casting from an interface to a concrete type, if that's a thing that worries you. It's something you can check rather easily in a reasonably sized code review. > In the age of 'lock-down-everything', increased modularity is becoming > more important. A monolithic module approach, is already outdated, and > risky, in terms of developing secure, maintainable software That statement could be taken as being against an approach that recommends structuring a project as a monolithic module, or against an approach that treats modules as a monolith in terms of protection. > I think providing an additional tool, to those who seek to use D, > such as 'strict private' (syntax can be argued about), would aid better > design - it can't make it any worse, that's for sure). It would be more language complexity in order to make it easier to have large modules. But you already said that large modules are a problem. > Is that really such a bad idea? Are there no programmers out there in > the D world that might think this could be a good, additional tool, to > give programmers, so they can better architect their solution? The use case is when you don't want to break up a module and you don't trust yourself not to modify private members from the wrong parts of the module. That's not useless. It's also not obviously so useful as to merit inclusion. A lot of languages do without any notion of private. A lot, like the entire ALGOL family up to Oberon-2, Go, Rust, Lua, Haskell, and Node.js, use exported and unexported symbols instead, and that's per module. A fair number just don't have a notion of public and private symbols. > The amount of push back in the D community on this idea, is really odd > to me. I'm still trying to understand why that is. Are D programmers > just hackers, insterested in getting their code to work, no matter what? > Are their not enough Java/C# programmers coming to D - and bringing > their design skills with them? There are plenty of language designers that didn't think it obvious. Might be better to consider why instead of implying that no D programmers are familiar with or care about good design. I mean, if there are popular languages from the 1960s through the 2010s that do things the same way as D, that sounds like a pretty good indication that it's not an obviously bad idea. It's not rock-solid; actual evidence from the industry would be superior. But I think you would have presented that evidence already.
Re: usable @nogc Exceptions with Mir Runtime
On Thursday, 1 November 2018 at 10:17:25 UTC, bauss wrote:
On Wednesday, 31 October 2018 at 13:56:56 UTC, 9il wrote:
~ 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.
I see what your argument is now for it, BUT I would still have
left it out because it's not idiomatic D and an alternative
would have been better if you absolutely had to rely on ~ being
used within the expression to combine both.
Ex.
try throw new MirException(stringBuf().append("Hi D", 2, "!",
getData);
Would have been a much better approach similar to how
write/writeln etc. work from std.stdio.
Well, added at v0.0.8 [1].
Mir Runtime formatting and exceptions are CTFE-able if a msg fits
into a local buffer and support user-defined types formatting.
Note, that toString function must be scope const.
mir.parse was added in v0.0.7. Currently, only integer types are
supported.
1. https://github.com/libmir/mir-runtime/pull/2
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Thursday, 1 November 2018 at 23:58:15 UTC, H. S. Teoh wrote: Having said that, though, there are some here who *do* want something like what you describe... IIRC Manu has voiced this before, and there may be others. (I myself don't consider it a big enough issue to be worth agonizing over.) So far, there has yet to be a strong enough argument for per-aggregate private to convince Walter & Andrei. It's them you have to convince, not the rest of us. Even if we were to all agree with you, it doesn't mean squat if Walter and Andrei won't budge on the issue. Again, I feel it's Walter and Andrei that should be doing the convincing.. they are always silent on this matter, which is a real shame,as I think their insights might actually be useful ;-) If it's simply not practical, from a language design, to consider this further, then I'd like to know that - I work at a higher leve of abstraction and have no idea about this. So not hearing from Walter or Andrei, is really unhelpful, as to whether it's an idea worth pursuing, or an idea that Walter and Andrei would never accept - which is it? Anyway, the real 'problem' (in my opinion), is not the idea. The idea is sound (or at least, it's not unsound), and it's represented in all major langauges, already. The real problem, is that whenever this idea pops up (as it has, and will continue to do so), far too many people on this forum attempt to divert the discussion from 'what is the usefulness of this new idea' to 'what's the difficulty of finding ways to avoid any change.' The discussion can never move forward under those circumstances. I would like the discussion to move forwards, and people start to think about how such a change could be adopted, how difficult it would be to implement, how will it play with other features in the langauge..etc It's a real shame we can't get beyond "No. We don't like your idea, and even if we did, we don't want to do it".
Re: Release D 2.083.0
On Friday, 2 November 2018 at 00:12:29 UTC, Martin Nowak wrote: Glad to announce D 2.083.0, ♥ to the 51 contributors. This release comes with betterC support in dub, new CppRuntime_* version identifiers, an isZeroInit trait, and an exported environment variable DUB_PACKAGE_VERSION during dub build steps. http://dlang.org/download.html http://dlang.org/changelog/2.083.0.html - -Martin I got mentioned twice in contributors list.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Fri, Nov 02, 2018 at 12:25:21AM +, unprotected-entity via Digitalmars-d-announce wrote: [...] > "Encapsulation is sometimes referred to as the first pillar or > principle of object-oriented programming. According to the principle > of encapsulation, a class or struct can specify how accessible each of > its members is to code outside of the class or struct. Methods and > variables that are not intended to be used from outside of the class > .. can be hidden to limit the potential for coding errors or malicious > exploits." > > https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/ That is a narrow definition of encapsulation that is very OO-centric, and IMO, it sorta misses the larger point behind encapsulation, focusing instead on the mechanics of it, and that the specific implementation of it in the OO paradigm. The concept of encapsulation goes beyond OO and classes; it has to do with modularity and well-defined interfaces between modules (or units of encapsulation -- this is not necessary the same thing as a D module). It's fine to explain how OO's concept of classes and methods implement encapsulation, but to *define* encapsulation in terms of classes and methods is IMO missing the forest for the trees. If *that's* your basis for understanding encapsulation, it would it explain a lot of your reactions to this thread. But there is more to the world than the narrow realm of the OO paradigm, and in a multi-paradigm language like D, it doesn't seem to make sense to be handicapped by a definition of encapsulation that really only makes sense in the context of an OO language. What encapsulation is really about, is the ability to modularize your code into self-contained units which have well-defined interfaces, with private code and data that cannot be accessed outside of that unit. In OO languages, this unit would be the class. But in D, it's the module. That doesn't make D non-encapsulated; it just means we're using a different unit than an OO language. It's just a difference between pounds and dollars, not some fundamental discrepancy. You just have to convert one currency to another, that's all. > D simply has *zero* support for encapsulation of classes or structs, > within the module (only encapsulation from code that is outside the > module). > > Any programmers interested in enforcing encapsulation in D (the first > pillar of OOP), are *forced* (because the language doesn't provide the > tool to do anything else) to use the one class, one struct, per file > solution. Which seems really silly to me. D forces you into Java like > programming - just to encapsulate a little class or struct. > > Speaking of 'structs', I don't see anyone in the D community, telling > others to use 'one struct per module'. Because we love UFCS, and structs just lend themselves very well to that sort of usage. And along that line, recent wisdom is that it's better to move things *out* of classes (and structs) if they don't need access to private members. (Sorry, I wanted to include a link for this, but I couldn't find the article -- the title eludes me and google isn't turning up anything useful.) Class and struct APIs should be as minimal as possible -- just enough to do what needs to be done and no more, and the rest of the syntactic sugar (that makes it more palatable to your users) belongs outside as optional convenience functions. T -- There is no gravity. The earth sucks.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 10:48:24 UTC, Sebastien Alaiwan
wrote:
"Encapsulation" is about implementation hiding and access
control ("public/private"), and requires programming language
support (e.g most dynamic languages don't have it).
"Encapsulation is sometimes referred to as the first pillar or
principle of object-oriented programming. According to the
principle of encapsulation, a class or struct can specify how
accessible each of its members is to code outside of the class or
struct. Methods and variables that are not intended to be used
from outside of the class .. can be hidden to limit the potential
for coding errors or malicious exploits."
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/
D simply has *zero* support for encapsulation of classes or
structs, within the module (only encapsulation from code that is
outside the module).
Any programmers interested in enforcing encapsulation in D (the
first pillar of OOP), are *forced* (because the language doesn't
provide the tool to do anything else) to use the one class, one
struct, per file solution. Which seems really silly to me. D
forces you into Java like programming - just to encapsulate a
little class or struct.
Speaking of 'structs', I don't see anyone in the D community,
telling others to use 'one struct per module'.
Release D 2.083.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Glad to announce D 2.083.0, ♥ to the 51 contributors. This release comes with betterC support in dub, new CppRuntime_* version identifiers, an isZeroInit trait, and an exported environment variable DUB_PACKAGE_VERSION during dub build steps. http://dlang.org/download.html http://dlang.org/changelog/2.083.0.html - -Martin -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlvblmgACgkQsnOBFhK7 GTm6Aw//U1fOrhpP7PS9SJ+ZUHZFZV2m7bXZcyWrRCgJ+hYQvPuBrxpYM74gKYqk SvCcdjQ1oSUpSfRs4DU0Li5HYRv7VaiCsen3cIiGpryUDgdvJ0l4sl3quB2nnn+J xxahSqnboESHlCxYe3K21QuRqRrtDY7qYFCOm7eCR+wWr8hnoWifABUuHx3UBwSA tj6zs/LQPzOEzQusfCCa85zubH6BkGpitQbIm+XdimAFK7I6CHAW2M3D+lrgThl7 ENkyxRPxDclXUDejuoZwLEsAf+f0dHdzMleNekfcY79Mp61DTJ2Im3xUIkCW2aBT BNFyXEw2Gxn7Hi2q0gFb5BRfx6v5N1LzoHwlVv6j4kZvS7IGK9vQ42rEkki4+77Q 63wps6KGmogS9KeBLVdZpaEbf/9Ph+xG5qtY0ZSTAv9e9/pAEIHO/ATW9trsBJX8 2jefm7bkvvUqr0ARdTgGoajnI8ZOPiqyTm76ZAwCw3kI+7YVGqhKPzUrX6Aj9GF5 jj9rzoxedR2Vr7z97jV/WLWwPlVjNfDRzg+Fmm8GwYAKZJFe6n0mw7I+sFFyHESa M3vzfUzvdJwoWAoYKXAvpb59BQeKrr7ZQ5b2c82jBs1o/3m3Y+/eZ5ZB3OEw9vpi z9raWkSuzhJ4t0TTWGOwr78FizkCqFGQPW1cYsnIgSgAXu4vMl0= =t2eY -END PGP SIGNATURE-
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Thu, Nov 01, 2018 at 10:37:59PM +, unprotected-entity via Digitalmars-d-announce wrote: > On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote: > > > > 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. > > How does one determine, whether a 10,000 line module, is tightly > coupled and cohesive? > > Only the author can make that statement - which they naturally will, > even if it's not true. > > An outsider, seeking to verify that statement, has a hell of a job on > their hands...(I for one, think code smell immediately). The code reviewer can reject a 10,000-line module off the bat as being too large. It's up to the project to enforce such conventions. > As soon as you see a class interface in a module, in D, you have to > assume their is other code in the module, perhaps down around line > 9,900, that is bypassing its interface, and doing who knows what to > it > > Sure, the author might be happy, but an auditor/code reviewer, will > likely have a different view, when a 10,000 line module is shoved in > front of them, and they know, that 'anything goes', 'all bets are > off', inside the D module Yes, and this is when you, or the project manager, puts down the foot and say this is unacceptable, break this module up into smaller submodules or else it doesn't go into the master repository. Simple. [...] > I don't use a particular language. I'm more interested in design and > architecture. > > In the age of 'lock-down-everything', increased modularity is becoming > more important. A monolithic module approach, is already outdated, and > risky, in terms of developing secure, maintainable software I don't understand what D's approach to modules has to do with being monolithic. Why can't you just write smaller modules if private being module-wide bothers you so much? D has package.d that can make a set of smaller submodules appear as a larger module to outside code. Use it. > I think providing an additional tool, to those who seek to use D, such > as 'strict private' (syntax can be argued about), would aid better > design - it can't make it any worse, that's for sure). > > Although. I don't mean strict private like freepascal, but strict > private, as in it inherits everything that private already does, but > additionally, become private within the module too. > > Is that really such a bad idea? Are there no programmers out there in > the D world that might think this could be a good, additional tool, to > give programmers, so they can better architect their solution? It's not a bad idea. In fact, if I were in charge of designing D, I'd probably do the same. But D chose to do it differently -- and part of the rationale, if I understand it correctly, is to eliminate the need for `friend` declarations like in C++. But maybe Andrei or whoever it was that made this decision can step up and explain why it was designed this way. All we're saying is that it's not the end of the world if private is module-wide rather than aggregate-wide. You can still have your encapsulation by splitting up your code into smaller files, which, given what you said above, you want to be doing anyway since the idea of a 10,000-line source file is so abhorrent to you. The fundamental issue here is that there needs to be some kind of unit of encapsulation. Java and C# chose to make the class that unit; D chose the module. If the Java/C# unit of encapsulation is what you want, all you have to do is to make the module equivalent to the class, problem solved. It's not as though there is no encapsulation at all and you're left out in the wild west of C's global namespace, or that the workaround is too onerous to be practical. > The amount of push back in the D community on this idea, is really odd > to me. I'm still trying to understand why that is. Are D programmers > just hackers, insterested in getting their code to work, no matter > what? Are their not enough Java/C# programmers coming to D - and > bringing their design skills with them? It's not so much push back, as being worn out from every other newcomer clamoring for the same thing year after year without ever having tried to do it the D way. Not saying that you're doing that, but it just becomes a sort of knee-jerk reaction after X number of newcomers barge in repeating the same old complaints that has the same old answers that everyone is tired of repeating. Having said that, though, there are some here who *do* want something like what you describe... IIRC Manu has voiced this before, and there may be others. (I myself don't consider it a
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote: 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. How does one determine, whether a 10,000 line module, is tightly coupled and cohesive? Only the author can make that statement - which they naturally will, even if it's not true. An outsider, seeking to verify that statement, has a hell of a job on their hands...(I for one, think code smell immediately). As soon as you see a class interface in a module, in D, you have to assume their is other code in the module, perhaps down around line 9,900, that is bypassing its interface, and doing who knows what to it Sure, the author might be happy, but an auditor/code reviewer, will likely have a different view, when a 10,000 line module is shoved in front of them, and they know, that 'anything goes', 'all bets are off', inside the D module 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 I don't use a particular language. I'm more interested in design and architecture. In the age of 'lock-down-everything', increased modularity is becoming more important. A monolithic module approach, is already outdated, and risky, in terms of developing secure, maintainable software I think providing an additional tool, to those who seek to use D, such as 'strict private' (syntax can be argued about), would aid better design - it can't make it any worse, that's for sure). Although. I don't mean strict private like freepascal, but strict private, as in it inherits everything that private already does, but additionally, become private within the module too. Is that really such a bad idea? Are there no programmers out there in the D world that might think this could be a good, additional tool, to give programmers, so they can better architect their solution? The amount of push back in the D community on this idea, is really odd to me. I'm still trying to understand why that is. Are D programmers just hackers, insterested in getting their code to work, no matter what? Are their not enough Java/C# programmers coming to D - and bringing their design skills with them?
Re: Beta 2.082.0
On Wednesday, 17 October 2018 at 15:59:17 UTC, JN wrote: BTW, title says Beta 2.082.0 :) Just automated the template for the beta announcement so this doesn't happen again. https://gist.github.com/MartinNowak/a471fe7ddbfeef205cdf04c93a94c6d0/revisions#diff-e55bb7573f1110c8b2a6922fe8cccf48
Re: usable @nogc Exceptions with Mir Runtime
On Thursday, 1 November 2018 at 10:17:25 UTC, bauss wrote:
On Wednesday, 31 October 2018 at 13:56:56 UTC, 9il wrote:
~ 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.
I see what your argument is now for it, BUT I would still have
left it out because it's not idiomatic D and an alternative
would have been better if you absolutely had to rely on ~ being
used within the expression to combine both.
Ex.
try throw new MirException(stringBuf().append("Hi D", 2, "!",
getData);
Would have been a much better approach similar to how
write/writeln etc. work from std.stdio.
https://github.com/atilaneves/nogc/blob/ed4663558ceea1f5dc2634d6f01cc6ce6967adc1/tests/ut/exception.d#L49
Beta 2.083.0 [was: Re: Beta 2.082.0]
On Wednesday, 17 October 2018 at 12:14:55 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.083.0 release, ♥ to the 48 contributors for this release. Just noted the incorrect subject when searching for the beta thread of the last release.
Re: smile.amazon.com Promotion
On Thursday, 1 November 2018 at 03:18:44 UTC, SealabJaster wrote: 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 There is nothing stopping the community from doing things like raising money for improving the user experience and marketing the language. Walter and Andrei do not have to be involved in anything outside of the core language development. No vision document is needed. Neither Walter or Andrei is a CEO. We should be realistic and act accordingly. Don't get me wrong, it would be great if the DLF did these things, but it's not happening now and it's not happening ever. The question is who will provide the leadership to move things forward. To this point, nobody has stepped up.
Re: smile.amazon.com Promotion
On Thursday, 1 November 2018 at 05:26:06 UTC, Joakim wrote: [snip] 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 pay attention to the Vision document, and I contribute a little money out of every paycheck to the D foundation that my company matches. IMO, not updating the vision document comes off as very unorganized.
Re: usable @nogc Exceptions with Mir Runtime
On Wednesday, 31 October 2018 at 13:56:56 UTC, 9il wrote:
~ 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.
I see what your argument is now for it, BUT I would still have
left it out because it's not idiomatic D and an alternative would
have been better if you absolutely had to rely on ~ being used
within the expression to combine both.
Ex.
try throw new MirException(stringBuf().append("Hi D", 2, "!",
getData);
Would have been a much better approach similar to how
write/writeln etc. work from std.stdio.
