Re: Program logic bugs vs input/environmental errors (checked exceptions)
On 06/10/14 20:26, Andrei Alexandrescu wrote: Then scope them. We already have scoping rules built in to the language. Why should we invent a new way and set of rules for this. -- /Jacob Carlborg
Re: Algebraic data types
On Monday, 6 October 2014 at 16:48:32 UTC, Jonathan wrote:
Resurrecting this topic, does D have ADTs yet for enums/structs?
Here's a proof of concept:
http://www.infognition.com/blog/2014/recursive_algebraic_types_in_d.html
struct Const(T) { ... }
class Add(T) { ... }
alias Exp = Either!(Add, Const);
int eval(Exp!int e) {
return e.match(a => a.l + a.r,
i => i.x);
}
string show(Exp!string e) {
return e.match(a => "(" ~ a.l ~ " + " ~ a.r ~ ")",
i => i.x.text);
}
Re: Program logic bugs vs input/environmental errors
On Mon, Oct 06, 2014 at 07:55:23PM -0700, Walter Bright via Digitalmars-d wrote: > On 10/6/2014 10:09 AM, Dicebot wrote: > >It is only in undefined state because language handles Errors that > >way. At the point of throwing the Error state was perfectly defined > >and 100% recoverable. This is the typical case for assertion failure > >in contract - it detects some program flaw like inability to handle > >specific data combination from other process but it does not mean > >memory is corrupted or program is inherently broken. Just killing the > >fiber and continuing with other requests (which don't trigger that > >unexpected code path) is absolutely fine unless compiler kicks in and > >optimizes something away in surprising fashion. > > What you're describing sounds like using asserts to validate input > data. This is not what asserts are for. Using assertions in contracts in D currently has some design issues, one of the foremost being that in-contracts of derived classes are allowed to be more relaxed than base classes, which means that the effective contract is (baseClassContract || derivedClassContract). However, since in-contracts are allowed to be arbitrary statements, the only way to implement this is to catch AssertErrors and continue running if at least one of the contracts didn't assert. But that means we're technically in an undefined state after that point. :-( (If the in-contract calls a nothrow function that asserts, for example, dtors may have been skipped, cleanups not performed, etc., and yet we blindly barge on because the other contract didn't assert.) T -- LINUX = Lousy Interface for Nefarious Unix Xenophobes.
Re: scope() statements and return
On 10/6/14, 7:25 PM, deadalnix wrote: On Monday, 6 October 2014 at 13:48:07 UTC, Andrei Alexandrescu wrote: It's one of those designs in which there's little room to turn. We wanted to (a) allow destructors to throw, (b) conserve information. Offering access to all exceptions caught was a natural consequence. -- Andrei Note that if we reverse the chaining (like java does), then the loop problem mostly disappear. It is still possible to create it, you you got to actively look for it. I knew Python has chaining but not Java. Got a reference handy? My searches suggest that in Java that's a manual technique only. -- Andrei
Re: Program logic bugs vs input/environmental errors
On 10/6/2014 10:09 AM, Dicebot wrote: It is only in undefined state because language handles Errors that way. At the point of throwing the Error state was perfectly defined and 100% recoverable. This is the typical case for assertion failure in contract - it detects some program flaw like inability to handle specific data combination from other process but it does not mean memory is corrupted or program is inherently broken. Just killing the fiber and continuing with other requests (which don't trigger that unexpected code path) is absolutely fine unless compiler kicks in and optimizes something away in surprising fashion. What you're describing sounds like using asserts to validate input data. This is not what asserts are for.
Re: scope() statements and return
On Monday, 6 October 2014 at 17:12:00 UTC, Jakob Ovrum wrote:
On Monday, 6 October 2014 at 16:55:39 UTC, monarch_dodra wrote:
For the sake of argument, do you have any examples where a
program has used chaining?
I use explicit chaining in a couple of my libraries, i.e. code
like:
---
try foo();
catch(FooException e)
{
throw new BarException("foobar", e);
}
---
However, the whole point is implicit chaining, which is where
the language and runtime kicks in. Look through your own
scope(exit|failure) blocks and struct destructors - are they
all nothrow?
If not, you are using exception chaining.
I think this is supposed to chain the other way around.
Re: scope() statements and return
On Monday, 6 October 2014 at 13:48:07 UTC, Andrei Alexandrescu wrote: It's one of those designs in which there's little room to turn. We wanted to (a) allow destructors to throw, (b) conserve information. Offering access to all exceptions caught was a natural consequence. -- Andrei Note that if we reverse the chaining (like java does), then the loop problem mostly disappear. It is still possible to create it, you you got to actively look for it.
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On 10/6/14, 4:46 PM, Jeremy Powers via Digitalmars-d wrote: On Mon, Oct 6, 2014 at 7:50 AM, Andrei Alexandrescu via Digitalmars-d I'm thinking a simple key-value store Variant[string] would accommodate any state needed for differentiating among exception kinds whenever that's necessary. And 'kinds' is a synonym for 'types' - You can have different kinds of problems, so you raise them with different kinds of exceptions. s/kind/type/g and the question is: why not leverage the type system? I've used "kinds" intentionally there. My basic thesis here is I haven't seen any systematic and successful use of exception hierarchies in 20 years. In rare scattered cases I've seen a couple of multiple "catch"es, and even those could have been helped by the use of a more flat handling. You'd think in 20 years some good systematic use of the feature would come forward. It's probably time to put exception hierarchies in the "emperor's clothes" bin. For a consumer-of-something-that-throws, having different types of exceptions for different things with different data makes sense. You have to switch on something to determine what data you can get from the exception anyway. Oh yah I know the theory. It's beautiful. It's commonly accepted that the usability scope of OOP has gotten significantly narrower since its heydays. However, surprisingly, the larger community hasn't gotten to the point to scrutinize object-oriented error handling, which as far as I can tell has never delivered. Maybe, but what fits better? Errors/Exceptions have an inherent hierarchy, which maps well to a hierarchy of types. When catching an Exception, you want to guarantee you only catch the kinds (types) of things you are looking for, and nothing else. Yah, it's just that most/virtually all of the time I'm looking for all. And nothing else :o). Andrei
Re: Who pays for all this?
On 2014-10-06 22:28:52 +, Andrei Alexandrescu said: On 10/6/14, 12:59 PM, Shammah Chancellor wrote: I'm willing to put in the work if Walter is on board also. I don't want to do all that work to end up being a DPL Foundation in name only. That's very generous of you, thanks! We'll discuss this. From what I read at http://lwn.net/Articles/561336/, my understanding is that we'll need significant ongoing expenses in additional to the initial setup expenditure of time and money. Anyone who knows more about this please chime in. -- Andrei I'll start doing some research. To be forward, I am 100% ignorant of the process at the moment as well. -S.
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On Mon, Oct 6, 2014 at 7:50 AM, Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 10/6/14, 7:01 AM, H. S. Teoh via Digitalmars-d wrote: > >> On Mon, Oct 06, 2014 at 06:46:31AM -0700, Andrei Alexandrescu via >> Digitalmars-d wrote: >> >>> On 10/5/14, 11:39 PM, Dmitry Olshansky wrote: >>> It's obvious to me that one hierarchy is way to limiting for exceptions, simply because there could be many ways to categorize the same set of error conditions. >>> >>> Well put. -- Andrei >>> >> >> What's the alternative, though? I can't think of any solution that >> (1) isn't far more complicated than the current state of things and >> (2) is easier to use. >> > > I'm thinking a simple key-value store Variant[string] would accommodate > any state needed for differentiating among exception kinds whenever that's > necessary. > > And 'kinds' is a synonym for 'types' - You can have different kinds of problems, so you raise them with different kinds of exceptions. s/kind/type/g and the question is: why not leverage the type system? For a consumer-of-something-that-throws, having different types of exceptions for different things with different data makes sense. You have to switch on something to determine what data you can get from the exception anyway. > It's commonly accepted that the usability scope of OOP has gotten > significantly narrower since its heydays. However, surprisingly, the larger > community hasn't gotten to the point to scrutinize object-oriented error > handling, which as far as I can tell has never delivered. > Maybe, but what fits better? Errors/Exceptions have an inherent hierarchy, which maps well to a hierarchy of types. When catching an Exception, you want to guarantee you only catch the kinds (types) of things you are looking for, and nothing else.
Re: Program logic bugs vs input/environmental errors
On Sunday, 5 October 2014 at 20:37:18 UTC, Nick Sabalausky wrote: forbidden from advancing at their own level (thus boring the shit out of them and seeding quite a few additional problems). Yeah, I've always wondered if the motivation for keeping kids locked up in schools is to prevent them from doing mischief in the streets and teach them to accept hours of pointless boredom so that they will eventually accept doing boring pointless stuff when they later join the workforce as bureaucrats. :-/ Obviously US teachers have no idea what the word "fair" actually means. But then, in my experience, there's a LOT that US teachers don't know. The status of teaching has gone downhill. It used to be viewed as highly skilled work, then you got some idealistic teachers of the 1968-generation, but after the yuppie period in the 80s it has become the easy path to higher-education when you don't know what you want to do except that you aren't good with theory and you want to work with people. I think the same can be said about psychology, the field you enter if you don't know what to study and find science too difficult… (or am I being unfair?) statement on unions in general, BTW) and the complete and total lack of "logic" being part of the curriculum *they* were taught as kids (which is still inexcusably absent from modern curriculums). "logic" is theory. Theory does not belong in schools. Too difficult. You are only supposed to learn things that you don't have to figure out, otherwise finding qualified teachers will become impossible. US has a few of those too. They're constantly ridiculed (leave it to the US to blast anything that isn't group-think-compatible), but from what I've seen Montesorri's are at least less god-awful than US public schools. We have a few Montesorri and a few more Rudolph Steiner schools. Which I believe are better at motivating kids and at least not killing the fun of learning. Learning that figuring things out and doing things your own way is fun is a very important lesson. The government says that the public school system has changed and is kind of incorporating those methodologies too, but that is not what I see. And how can a single teacher handle 27 kids in a class, with only 2 minutes per kid per hour and a rigid plan for what you are supposed to teach? Btw, did you know that the majority in Norway voted against joining EU, so we did not, but since the majority of politicians were pro EU they got us in the backdoor by signing away our freedom in treaties instead? And even when the treaties do not apply we "harmonize our laws to EU" because we "just have to". So thanks to bureaucratic maneuvers we are now 99% EU regulated, have shittier consumer laws than we used to, have next to no control on the borders and are flooded by romanian beggars and criminals from every corner of Europe and beyond, in return we get no vote in the EU decision making process since we are "independent"… You gotta love democracy… On a positive note: the IOC managed to demand that the norwegian King ought to hold a party for the IOC leaders and additionally demanded that he should pay their drinks. It was part of their 7000 page olympics qualification requirements document. It is so heavily regulated that it explicitly specifies that the personnel in the hotels MUST SMILE to the IOC leaders when they arrive. I kid you not, even games and past times are heavily bureaucratic down to minuscule details these days. So, due pressure from the newspapers/grassroots and the royal insult the politicians eventually had to turn down the ~$10.000.000.000 winter olympics budget proposal. Good riddance. Live monarchy! I am personally looking forward to Beijing hosting the winter olympics 2022. I am sure they will mange to fake a smile after the politicians have demolished their homes to make space for the ski-jumping event. In the meantime Norway should not even think about hosting any sporting event until we can avoid being ranked as the worlds most expensive country: http://www.numbeo.com/cost-of-living/rankings_by_country.jsp 'Cause, we all know that a $10 billion budget turns into at least a $30 billion budget before the games are over. That would have been $6000 per capita. I'd say that royal insult paid off. Was this off-topic?
Re: Who pays for all this?
On 10/6/14, 12:59 PM, Shammah Chancellor wrote: I'm willing to put in the work if Walter is on board also. I don't want to do all that work to end up being a DPL Foundation in name only. That's very generous of you, thanks! We'll discuss this. From what I read at http://lwn.net/Articles/561336/, my understanding is that we'll need significant ongoing expenses in additional to the initial setup expenditure of time and money. Anyone who knows more about this please chime in. -- Andrei
Re: RFC: moving forward with @nogc Phobos
Am Wed, 01 Oct 2014 02:21:44 -0700 schrieb Andrei Alexandrescu : > On 9/30/14, 9:49 AM, Johannes Pfau wrote: > > I guess my point is that although RC is useful in some cases output > > ranges / sink delegates / pre-allocated buffers are still necessary > > in other cases and RC is not the solution for _everything_. > > Agreed. > > > As Manu often pointed out sometimes you do not want any dynamic > > allocation (toStringz in games is a good example) and here RC > > doesn't help. > > > > Another example is format which can already write to output ranges > > and uses sink delegates internally. That's a much better > > abstraction than simply returning a reference counted string > > (allocated with a thread local allocator). Using sink delegates > > internally is also more efficient than creating temporary > > RCStrings. And sometimes there's no allocation at all this way > > (directly writing to a socket/file). > > Agreed. > > >>> What if I don't want automated memory _management_? What if I > >>> want a function to use a stack buffer? Or if I want to free > >>> manually? > >>> > >>> If I want std.string.toStringz to put the result into a temporary > >>> stack buffer your solution doesn't help at all. Passing an ouput > >>> range, allocator or buffer would all solve this. > >> > >> Correct. The output of toStringz would be either a GC string or an > >> RC string. > > > > But why not provide 3 overloads then? > > > > toStringz(OutputRange) > > string toStringz(Policy) //char*, actually > > RCString toStringz(Policy) > > > > The notion I got from some of your posts is that you're opposed to > > such overloads, or did I misinterpret that? > > I'm not opposed. Here's what I think. > > As an approach to using Phobos without a GC, it's been suggested that > we supplement garbage-creating functions with new functions that use > output ranges everywhere, or lazy ranges everywhere. > > I think a better approach is to make memory management a policy that > makes convenient use of reference counting possible. So instead of > garbage there'd be reference counted stuff. > > Of course, to the extent using lazy computation and/or output ranges > is a good thing to have for various reasons, they remain valid > techniques that are and will continue being used in Phobos. > > My point is that acknowledging and systematically using reference > counted types is an essential part of the entire approach. > > > Andrei > > OK then I got you wrong and I agree with everything you wrote above. Thanks for clarifying.
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 19:08:24 UTC, Andrei Alexandrescu wrote: On 10/6/14, 12:00 PM, Dicebot wrote: On Monday, 6 October 2014 at 18:57:04 UTC, H. S. Teoh via Digitalmars-d wrote: Or, if you'll allow me to paraphrase it, pay the one-time cost of broken code now, rather than incur the ongoing cost of needing to continually workaround language issues. Don in this very thread. Multiple times. He made a few good and very specific points that subsequently saw action. This is the kind of feedback we need more of. -- Andrei And here we go again for the multiple alias this: I'm pleased to have seen that it will be merged sooner than later. Just to clarify, taking as an example our company: - TDPL is a very good training book for C++/Java minions, and turns them in, well, not-so-good-but-not-so-terrible D programmers. It solve the "boss" perplexity about "there's basically no markets for D language programmers: how can we hire them in the future?". For the chronicle, the next lecture is the EXCELLENT "D Templates: a tutorial", of Philippe Sigaud, an invaluable resource (thank Philippe for that!). - TDPL is exactly what Dicebot wrote: a plan! Having to bet on something, a CTO like me *likes* to bet on a good plan (like the A-Team!) - Being a good plan, and an ambitious one, as a company we scrutiny the efforts devoted to complete it, and that set the bar for future evaluation of the reliability of _future_ plans and proposal. As an example, the *not resolution* of the shared qualifier mess, has a costs in term of how reliable we judge other proposed improvements (I know, that may be not fare, but that's it). I'm not telling that the language must be crystallised, and I also understand that as times goes by, other priorities and good ideas may come up. As a company, we don't mind if we are discussing about ARC, GC, or C++ interop, but we care about the efforts and time placed on the _taken_ decision, especially for the _past_ plans, and we judge that care as strictly correlated to language maturity for business adoption. Just my 2c... again, no pun intended! ;-P --- /Paolo
Re: Who pays for all this?
On 2014-10-06 04:09:26 +, Andrei Alexandrescu said: On 10/5/14, 7:28 PM, Shammah Chancellor wrote: There are many languages which have grown more quickly than D (despite being less interesting) because they have a foundation where people can donate, or some company, which provides for the core developers. I'm not saying that having a non-profit will magically generate money, but there are a few companies who use D out there who just might be willing to donate non-trivial sums of money to further development if there was a non-profit to see that the money was put to good use. Just to name a few: Python: https://www.python.org/psf-landing/ Node.JS: http://www.joyent.com/ Perl: http://www.perlfoundation.org Linux Core Developers: http://en.wikipedia.org/wiki/Linux_Foundation Ruby Core Developers: https://www.heroku.com (A subsidiary of Salesforce) C++ also has a foundation since 2012: http://pocoproject.org/blog/?p=671. It paid for CppCon 2014, which was very successful. I believe a foundation would help D. Unfortunately, setting one up is very laborious, and neither Walter nor I know anything about that - from what I understand it takes a _lot_ of work. If anyone is able and willing to embark on creating a foundation for D, that would be a great help to the language and its community. Andrei I'm willing to put in the work if Walter is on board also. I don't want to do all that work to end up being a DPL Foundation in name only. -Shammah
Re: What are the worst parts of D?
On 10/6/14, 12:00 PM, Dicebot wrote: On Monday, 6 October 2014 at 18:57:04 UTC, H. S. Teoh via Digitalmars-d wrote: Or, if you'll allow me to paraphrase it, pay the one-time cost of broken code now, rather than incur the ongoing cost of needing to continually workaround language issues. Don in this very thread. Multiple times. He made a few good and very specific points that subsequently saw action. This is the kind of feedback we need more of. -- Andrei
Re: What are the worst parts of D?
On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Oct 06, 2014 at 06:13:41PM +, Dicebot via Digitalmars-d wrote: On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote: [...] It would be terrific if Sociomantic would improve its communication with the community about their experience with D and their needs going forward. How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what can be done to make communication more clear. I don't remember who it was, but I'm pretty sure *somebody* at Sociomantic has stated clearly their request recently: Please break our code *now*, if it helps to fix language design issues, rather than later. More particulars would be definitely welcome. I should add that Sociomantic has an interesting position: it's a 100% D shop so interoperability is not a concern for them, and they did their own GC so GC-related improvements are unlikely to make a large difference for them. So "C++ and GC" is likely not to be high priority for them. -- Andrei
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 18:57:04 UTC, H. S. Teoh via Digitalmars-d wrote: Or, if you'll allow me to paraphrase it, pay the one-time cost of broken code now, rather than incur the ongoing cost of needing to continually workaround language issues. Don in this very thread. Multiple times.
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On 10/6/14, 11:13 AM, Jacob Carlborg wrote: Then you'll always catch all exceptions. If error code doesn't match you need to rethrow the exception. Or make a language change that allows to catch based on the error code. Either solution is fine here because that's the rare case. -- Andrei
Re: What are the worst parts of D?
On Mon, Oct 06, 2014 at 06:13:41PM +, Dicebot via Digitalmars-d wrote: > On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote: [...] > >It would be terrific if Sociomantic would improve its communication > >with the community about their experience with D and their needs > >going forward. > > How about someone starts paying attention to what Don posts? That > could be an incredible start. I spend great deal of time both reading > this NG (to be aware of what comes next) and writing (to express both > personal and Sociomantic concerns) and have literally no idea what can > be done to make communication more clear. I don't remember who it was, but I'm pretty sure *somebody* at Sociomantic has stated clearly their request recently: Please break our code *now*, if it helps to fix language design issues, rather than later. Or, if you'll allow me to paraphrase it, pay the one-time cost of broken code now, rather than incur the ongoing cost of needing to continually workaround language issues. T -- Too many people have open minds but closed eyes.
Re: Program logic bugs vs input/environmental errors (checked exceptions)
Jacob Carlborg wrote: > On 2014-10-06 17:07, Andrei Alexandrescu wrote: > >> I don't. On the contrary, I do consider proliferating types to the >> multiplicity of possible errors an obvious design sin. -- Andrei > > You loose the ability to have exception specific data. And no, I don't > want to see an associative array of Variants, that's even worse hack then > error codes. You'll run in to problems with unique keys and will most > likely need to "scope" all keys. Then scope them.
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote: I'm confused. Why would anyone who just comes to dlang.org see unformed ideas and incomplete designs? Wouldn't newcomers be more attracted by e.g. stuff coming in the next release? Because he is interested in language development direction but does not want to actively participate? It can be someone with bad early D experience wondering if anything has changed in last year. Or it can be developer from some company using D wanting to get quick overview what to expect from the language for the next year or so. For example I don't have time to follow Rust mail lists or GitHub commits but I do read blog posts of its developers regularly (including speculative ones) to see where it is heading. It is both interesting and educating and helps to spread the image among wider audience as well. The fact that you don't seem to have a consensus with Walter on some topic (auto-decoding, yeah) doesn't help either. Language marketing is not about posting links on reddit, it is a very hard work of communicating your vision so that it is clear even to random by-passer. I think one good thing we can do is approach things in private before discussing them publicly. Agreed. I don't propose to stop paying attention to forums or drop all discussions but to put a bit more efforts into popularizing resulting decisions and plans. So that someone can safely ignore some of discussions without fearing that it will surprisingly appear in next release catching one off guard. We now have Martin Nowak as the point of contact. And what if he gets busy too? :) Maybe you'll volunteer. I have already considered that and can be pretty sure this won't ever happen (at least not while this implies paying to Apple a single cent) Let's get it straight - I don't care much about D success in general. It is a nice language to use here and there, I got an awesome job because of it but this is pretty much all the scope. There is no way I will ever work on something that is not needed to me only because it is important for language success in general. This is pretty much the difference between language author / core developer and random contributor and why handling releases is safer in the hands of former. No doubt its design could be done better. But inout was not motivated theoretically. It came from the practical need of not duplicating code over qualifiers. I don't mean feature itself was "theoretical". I mean that it was implemented and released before it got at least some practical usage in live projects with relevant feedback and thus have missed some corner cases. Sean proposed that. In fact that's a very good success story of sharing stuff for discussion sooner rather than later: he answered a Request For Comments with a great comment. Well when I have initially asked the same question (why not user-controllable policies?) you straight out rejected it. I must be very bad at wording questions :( Again: I don't have a complete design, that's why I'm asking for comments in the Request For Comments threads. Would you rather have me come up alone with a complete design and then show it to the community as a fait accompli? What part of "let's do this together" I need to clarify? "let's do this together" implies agreeing on some base to further work on. When I come and see that proposed solution does not address a problem I have at all I can't do anything but ask "how is this supposed to address my problem?" because that is _your_ proposal and I am not gifted with telepathy. Especially because you have stated that previous proposal (range-fication) which did fix the issue _for me_ is not on the table anymore. You risk balkanization by keeping the things as they are. We do have talks at work sometimes that simply forking the language may be a more practical approach than pushing necessary breaking changes upstream by the time D2 port is complete. Those are just talks of course and until porting is done it is all just speculations but it does indicate certain level of unhappinness. It would be terrific if Sociomantic would improve its communication with the community about their experience with D and their needs going forward. How about someone starts paying attention to what Don posts? That could be an incredible start. I spend great deal of time both reading this NG (to be aware of what comes next) and writing (to express both personal and Sociomantic concerns) and have literally no idea what can be done to make communication more clear. Have you ever considered starting a blog about your vision of D development to communicate it better to wider audience? :) Yah, apparently there's no shortage of ideas of things I should work on. Perhaps I should do the same. Dicebot, I think you should work on making exceptions refcounted :o). As soon as it becomes a priority issue for me
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On 2014-10-06 18:03, Regan Heath wrote: Why? It gives us the benefits of error code return values: - ability to easily/cheaply check for/compare them using "switch" on code value (vs comparing/casting types) - ability to pass through OS level codes directly Without any of the penalties: - checking for them after every call. - losing the return value "slot" or having to engineer multiple return values in the language. - having to mix error codes in with valid return values (for int() functions). We also get: - no type proliferation. - no arguments about what exception types are needed, or the hierarchy to put them in. Seems like a win to me. Then you'll always catch all exceptions. If error code doesn't match you need to rethrow the exception. Or make a language change that allows to catch based on the error code. -- /Jacob Carlborg
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On 2014-10-06 17:07, Andrei Alexandrescu wrote: I don't. On the contrary, I do consider proliferating types to the multiplicity of possible errors an obvious design sin. -- Andrei You loose the ability to have exception specific data. And no, I don't want to see an associative array of Variants, that's even worse hack then error codes. You'll run in to problems with unique keys and will most likely need to "scope" all keys. -- /Jacob Carlborg
Re: GC behavior
On Monday, 6 October 2014 at 17:46:34 UTC, Jonathan wrote: Kiith-Sa, thanks for the info! I started to check out your entity project and love how your incorporating threads and syncing new/old state. You did state that your cleaning up things, but my initial reaction is that entitymanager is performing too many roles. I'd remove the heavy game state and threading into another class to make it cleaner, imho. https://github.com/kiith-sa/tharsis-core/blob/master/source/tharsis/entity/entitymanager.d Yeah, the threading is currently the most work-in-progress thing (basically, I'm dealing with tradeoffs between trying to get the best average performance and least latency from non-realtime OS scheduling). EntityManager is pretty much the kitchen-sink class where things exist until they are refactored away (most of Tharsis code used to be there at some point in the past). It will probably end up just as a shell delegating to all internals regarding entit/component management and process execution. However, EntityManager API itself is more complicated than needed for most users (and needs to be used together with other classes which add to the complexity) - it, together with other 'low-level' API classes will probably eventually be hidden behind a more user-friendly facade (yeah, I hate design patterns, but that's pretty much what it will be), with the ability to access EntityManager/others for more advanced users.
Re: On exceptions, errors, and contract violations
On 2014-10-06 16:36, Steven Schveighoffer wrote: This is the thing I have been arguing. Inside a library, the idea of input to the function being user defined or program-defined is not clear. It means that any user-defined input has to be double checked in the same exact way, to avoid having an error thrown in the case that the library function throws an error on such input. The other side, any program-caused errors that end up triggering exceptions (a misnamed filename for opening a config file, for instance), needs to treat this exception as an error and halt the program with an appropriate stack trace. I kind of agree with Walter. In an ideal world all environmental errors would throw an exception, i.e. a file cannot be found. Any other errors would be asserts, i.e. passing null to a function not expecting it. But I can understand that that behavior would most likely cause problems. -- /Jacob Carlborg
Re: GC behavior
Kiith-Sa, thanks for the info! I started to check out your entity project and love how your incorporating threads and syncing new/old state. You did state that your cleaning up things, but my initial reaction is that entitymanager is performing too many roles. I'd remove the heavy game state and threading into another class to make it cleaner, imho. https://github.com/kiith-sa/tharsis-core/blob/master/source/tharsis/entity/entitymanager.d
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 15:05:31 UTC, Andrei Alexandrescu wrote: On 10/6/14, 7:36 AM, Wyatt wrote: D is going to have C++ support. That's cool and compelling as a bare statement, but in what manner? We don't know yet, we're designing it The exact list is in the air. We're looking e.g. for the best policy on exceptions. Possible vs. impossible is btw a matter of scale, for example wrapping everything you need from C++ in C functions is possible in the small but impossible at scale. Ah, I see what happened now! The way you've been pushing it, I was given to believe you had something resembling a "grand vision" of how you wanted "C++ interoperability" to work with some proposed syntax and semantics. If not something so grandiose, at least a pool of ideas written down? Or even just a mental list of things you think are important to cover? Regardless, these things ARE important to communicate clearly. This was discussed already: we should be able to pass an std::vector by reference/pointer from C++ into D and use it within D directly, with no intervening marshaling. Awesome, this is a start. It seems this is a simple misunderstanding. You're looking for a virtually finished product It really is a misunderstanding. Heck, I think it still is one because all we're really looking for is some inkling of what's on your agenda at a granularity finer than "C++ and GC". If nothing else, a list like that gets people thinking about a feature ahead of the dedicated thread to discuss it. -Wyatt PS: Come to think of it, I may have been expecting a DIP?
Re: What are the worst parts of D?
On 10/6/14, 9:58 AM, H. S. Teoh via Digitalmars-d wrote: It would be*very* nice if once in a while (say once a week, or once a month) you and/or Walter can do a little write-up about the current status of things. Say a list of top 5 projects currently being worked on, a list of the top 5 current priorities, a short blurb about "progress this past week/month" (which could be as simple as "we've been swamped with fixing regressions, haven't been able to work on anything else", or "Facebook has me on a short leash, I haven't been able to work on D", etc.). This should be in its own thread, titled something like "Weekly [or monthly] status update", not buried underneath mountains of posts in one of our infamous interminable threads about some controversial topic, like to autodecode or not to autodecode. Of course, who am I to tell you what to do... but IMO a periodical high-level status update like the above would go a*long* way in dispelling complaints of "lack of direction" or "unclear/unknown priorities". It doesn't have to be long, either. Even a 1 page (OK, OK, *half* a page), bullet-point post is good enough. That's a really nice idea. -- Andrei
GSoC 2015 has been announced
http://www.google-melange.com/gsoc/homepage/google/gsoc2015 Per http://forum.dlang.org/thread/lem88d$2r4d$1...@digitalmars.com Craig Dillabaugh (cc'd) volunteered to be our GSoC 2015 czar. Craig, if you're still up for it, please start your czardom by adding yourself to wiki.dlang.org/People. Thanks, Andrei
Re: GC behavior
On Monday, 6 October 2014 at 16:23:41 UTC, Jonathan wrote: If I pool all unused objects such that no object needs to be GC'ed, does it still perform scanning? What are other good ways to avoid its overhead? As you might tell, I know rather little how D's garbage collection works. I'm working on a game engine and trying to be as resource efficient as possible. FYI, I've been using Rust for the last three months and decided to take a break from it. The documentation is far from the quality that D has and managing explicit lifetimes becomes a serious pain during mid project, especially in cases that you know are already safe. Suggestion (may or may not be useful depending on your game): use an ECS (http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/) approach with big, manually allocated arrays of structs in the implementation. I'm working on something but it's not documented enough/API is butt-ugly/not nearly stable-enough yet: https://github.com/kiith-sa/tharsis-core Some people are working on other ECS's too, see code.dlang.org (some are very efficient, some are not... don't remember which). And (very simplistic advice, but...) if ECS doesn't fit your needs or you do use GC to allocate a lot of stuff anyway, reuse dead objects and control the GC by disable()ing/reenabling and explicitly fullCollect()ing.
Re: scope() statements and return
On Monday, 6 October 2014 at 16:55:39 UTC, monarch_dodra wrote:
For the sake of argument, do you have any examples where a
program has used chaining?
I use explicit chaining in a couple of my libraries, i.e. code
like:
---
try foo();
catch(FooException e)
{
throw new BarException("foobar", e);
}
---
However, the whole point is implicit chaining, which is where the
language and runtime kicks in. Look through your own
scope(exit|failure) blocks and struct destructors - are they all
nothrow?
If not, you are using exception chaining.
Re: Program logic bugs vs input/environmental errors
On Sunday, 5 October 2014 at 23:01:48 UTC, Walter Bright wrote: On 10/5/2014 2:51 PM, Dicebot wrote: On Sunday, 5 October 2014 at 20:41:44 UTC, Walter Bright wrote: On 10/5/2014 8:35 AM, Dicebot wrote: I am fine with non-default being hard but I want it to be still possible within legal language restricions. D being a systems language, you can without much difficulty do whatever works for you. Yes but it shouldn't be in undefined behaviour domain. In other words there needs to be a confidence that some new compiler optimization will not break the application completely. Relying on program state after entering an unknown state is undefined by definition. I don't see how a language can make a statement like "it's probably ok". It is only in undefined state because language handles Errors that way. At the point of throwing the Error state was perfectly defined and 100% recoverable. This is the typical case for assertion failure in contract - it detects some program flaw like inability to handle specific data combination from other process but it does not mean memory is corrupted or program is inherently broken. Just killing the fiber and continuing with other requests (which don't trigger that unexpected code path) is absolutely fine unless compiler kicks in and optimizes something away in surprising fashion. If destructors are ignored those must be always ignored and defined in spec. Same for scope(exit) or any similar affected feature. Currently it may or may not attempt cleanup and that is the problem when trying to circumvent the semantics. I think this is the only important concern I have as long as power user stuff remains possible without re-implementing whole exception system from scratch. You can catch an Error. But what is done from there is up to you - and to do more than just log the error, engage the backup, and exit, I cannot recommend. Killing whole process is unacceptable in many cases, it will effectively shut down the whole service if faulty request happens at least one in a few seconds. To do more, use an Exception. But to throw an Exception when a logic bug has been detected, then try and continue based on it "probably" being ok, is something I cannot recommend and D certainly cannot guarantee anything. If the program does anything that matters, that is. Assertions / contracts use Error. Do you think it is a better approach to prohibit using `assert` and throw custom exceptions from contracts?
Re: scope() statements and return
On 10/6/14, 9:55 AM, monarch_dodra wrote:
On Monday, 6 October 2014 at 14:54:21 UTC, Andrei Alexandrescu wrote:
On 10/6/14, 7:24 AM, monarch_dodra wrote:
If your "catch" throws an exception, then the new exception simply
"squashes" replaces the old one:
//
catch (Exception e)
{
thisMightThrow(); //Lose "e" here
throw e;
}
//
That's code under library/user control, I'm talking about the
responsibility of the language. -- Andrei
Right. but if correct usage is so cumbersome no one does it right, then
it is 's/the responsibility/a flaw/' of the language.
Are we advocating then that code under user control should
systematically look like this?
catch (Exception e)
{
try
{
thisMightThrow(); //Lose "e" here
}
catch(Exception ee)
{
findLast(e).next = ee; //because e.next might
}
throw e;
}
Only if it needs to save that information. As far as the core language
is concerned, once an exception has been caught and made available to
the user, it's up to the user what to do with it. The point of chaining
is to not render information inaccessible to user no matter what they
do. This is a fairly basic remark.
Honestly, a good middle ground is to ditch chaining, but allow multiple
exceptions thrown at once. Subsequent Exceptions/Errors will just be
lost (sorry), with the exception that an Error will override an Exception.
If I redesigned D's exceptions, I'd change a bunch of stuff before that.
For the sake of argument, do you have any examples where a program has
used chaining?
Whenever an exception is converted to a string, the chained exceptions
should be part of it too.
Andrei
Re: What are the worst parts of D?
On Mon, Oct 06, 2014 at 09:39:44AM -0700, Andrei Alexandrescu via Digitalmars-d wrote: > On 10/6/14, 9:16 AM, eles wrote: > >On Monday, 6 October 2014 at 14:53:23 UTC, Andrei Alexandrescu wrote: > >>On 10/6/14, 7:05 AM, Paolo Invernizzi wrote: > >>>On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote: > On 10/6/14, 12:44 AM, Paolo Invernizzi wrote: > >On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: > >> > > > >>To interpret my lack of time politically is really amusing. You guys > >>have too much time on your hands :o). > > > >At least give such an explanation from time to time. Silence is the > >worst. > > Wait, are we too active in the forums or too silent? -- Andrei It would be *very* nice if once in a while (say once a week, or once a month) you and/or Walter can do a little write-up about the current status of things. Say a list of top 5 projects currently being worked on, a list of the top 5 current priorities, a short blurb about "progress this past week/month" (which could be as simple as "we've been swamped with fixing regressions, haven't been able to work on anything else", or "Facebook has me on a short leash, I haven't been able to work on D", etc.). This should be in its own thread, titled something like "Weekly [or monthly] status update", not buried underneath mountains of posts in one of our infamous interminable threads about some controversial topic, like to autodecode or not to autodecode. Of course, who am I to tell you what to do... but IMO a periodical high-level status update like the above would go a *long* way in dispelling complaints of "lack of direction" or "unclear/unknown priorities". It doesn't have to be long, either. Even a 1 page (OK, OK, *half* a page), bullet-point post is good enough. T -- In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.
Re: scope() statements and return
On Monday, 6 October 2014 at 14:54:21 UTC, Andrei Alexandrescu
wrote:
On 10/6/14, 7:24 AM, monarch_dodra wrote:
If your "catch" throws an exception, then the new exception
simply
"squashes" replaces the old one:
//
catch (Exception e)
{
thisMightThrow(); //Lose "e" here
throw e;
}
//
That's code under library/user control, I'm talking about the
responsibility of the language. -- Andrei
Right. but if correct usage is so cumbersome no one does it
right, then it is 's/the responsibility/a flaw/' of the language.
Are we advocating then that code under user control should
systematically look like this?
catch (Exception e)
{
try
{
thisMightThrow(); //Lose "e" here
}
catch(Exception ee)
{
findLast(e).next = ee; //because e.next might
}
throw e;
}
Honestly, a good middle ground is to ditch chaining, but allow
multiple exceptions thrown at once. Subsequent Exceptions/Errors
will just be lost (sorry), with the exception that an Error will
override an Exception.
For the sake of argument, do you have any examples where a
program has used chaining?
Re: GC behavior
"Jonathan" wrote in message news:hsdxglmqtcnhskwzr...@forum.dlang.org... If I pool all unused objects such that no object needs to be GC'ed, does it still perform scanning? What are other good ways to avoid its overhead? As you might tell, I know rather little how D's garbage collection works. I'm working on a game engine and trying to be as resource efficient as possible. A GC collection will run when you allocate with 'new' and there is not enough memory already reserved by the gc. So if you don't use 'new' then it won't run a collection, otherwise it might. You can disable all collections by importing 'core.memory' and calling 'GC.disable()'.
Re: Algebraic data types
NM, I found this:
http://www.digitalmars.com/d/archives/digitalmars/D/Algebraic_Data_Types_in_D_239039.html
"D's Algebraic needs some work, but it's okay for basic usage."
+1 agree
import std.stdio;
import std.variant;
struct Red {}
struct Green{}
struct Blue {}
struct RGB
{
int r;
int g;
int b;
}
alias Color = Algebraic!(Red, Green, Blue, RGB);
void main()
{
auto r = Color(RGB(64, 128, 255));
r.visit!(
(Red r) => writeln("Red"),
(Green g) => writeln("Green"),
(Blue b) => writeln("Blue"),
(RGB rgb) => writefln("RGB(%s, %s, %s)", rgb.r, rgb.g, rgb.b),
);
}
Re: Algebraic data types
Resurrecting this topic, does D have ADTs yet for enums/structs?
Re: What are the worst parts of D?
Am 06.10.2014 10:12, schrieb eles: On Monday, 6 October 2014 at 06:28:58 UTC, eles wrote: On Monday, 6 October 2014 at 06:28:02 UTC, eles wrote: On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote: On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote: On 10/5/14, 3:08 PM, eles wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: I like the safety that a GC guarantees, but is a too big price to be paid for that... Just look at this abomination from here: http://agilology.blogspot.com/2009/01/why-dispose-is-necessary-and-other.html sqlConnection.Close(); sqlConnection.Dispose(); sqlConnection = null; Is this your idea about releasing a resource? Why is this better than writing delete/dispose sqlConnection? If you ask to use structs for RAII, I am afraid that you will receive a DFront proposal. This abomination tends to be written by developers that don't care to learn how to use properly their tools. It is quite easy to just use "using" on every IDisposable resource. As for setting something to null just to let the GC know about it, a sign of premature optimization and a sign of not neither knowing how a GC works nor how to use a memory profiler. -- Paulo
Re: What are the worst parts of D?
On 10/6/14, 9:14 AM, eles wrote: On Monday, 6 October 2014 at 13:55:05 UTC, Andrei Alexandrescu wrote: On 10/6/14, 6:18 AM, ketmar via Digitalmars-d wrote: We will accept multiple "alias this". -- Andrei = IgorStepanov commented 6 days ago Please, someone, add label "Needs Approval" to this PR. We need discuss a conflict resolving, and determine right algorithm, if implemented algorithm isn't right. Thanks. yebblies added Enhancement Needs Approval labels 6 days ago = Please grand approval there. Will do, thanks. -- Andrei
Re: What are the worst parts of D?
On 10/6/14, 9:16 AM, eles wrote: On Monday, 6 October 2014 at 14:53:23 UTC, Andrei Alexandrescu wrote: On 10/6/14, 7:05 AM, Paolo Invernizzi wrote: On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote: On 10/6/14, 12:44 AM, Paolo Invernizzi wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: To interpret my lack of time politically is really amusing. You guys have too much time on your hands :o). At least give such an explanation from time to time. Silence is the worst. Wait, are we too active in the forums or too silent? -- Andrei
GC behavior
If I pool all unused objects such that no object needs to be GC'ed, does it still perform scanning? What are other good ways to avoid its overhead? As you might tell, I know rather little how D's garbage collection works. I'm working on a game engine and trying to be as resource efficient as possible. FYI, I've been using Rust for the last three months and decided to take a break from it. The documentation is far from the quality that D has and managing explicit lifetimes becomes a serious pain during mid project, especially in cases that you know are already safe.
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 14:53:23 UTC, Andrei Alexandrescu wrote: On 10/6/14, 7:05 AM, Paolo Invernizzi wrote: On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote: On 10/6/14, 12:44 AM, Paolo Invernizzi wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: To interpret my lack of time politically is really amusing. You guys have too much time on your hands :o). At least give such an explanation from time to time. Silence is the worst.
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote: On 10/6/14, 12:44 AM, Paolo Invernizzi wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: I did comment in this group. -- Andrei == IgorStepanov commented 17 days ago Ping === quickfur commented 14 days ago Wow. I have been waiting for this feature for a long time! Can't wait to see this merged. Ping @WalterBright ? == IgorStepanov commented 13 days ago @andralex Ping. Please comment the tests and conflict resolving semantic. === IgorStepanov commented 8 days ago @andralex ping ==
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 13:55:05 UTC, Andrei Alexandrescu wrote: On 10/6/14, 6:18 AM, ketmar via Digitalmars-d wrote: We will accept multiple "alias this". -- Andrei = IgorStepanov commented 6 days ago Please, someone, add label "Needs Approval" to this PR. We need discuss a conflict resolving, and determine right algorithm, if implemented algorithm isn't right. Thanks. yebblies added Enhancement Needs Approval labels 6 days ago = Please grand approval there.
Re: What are the worst parts of D?
On 10/5/14, 9:14 AM, Dicebot wrote: On Sunday, 5 October 2014 at 15:38:58 UTC, Andrei Alexandrescu wrote: 1. C++ support is good for attracting companies featuring large C++ codebases to get into D for new code without disruptions. 2. Auto-decoding is blown out of proportion and a distraction at this time. 3. Ref counting is necessary again for encouraging adoption. We've framed GC as an user education matter for years. We might have even been right for the most part, but it doesn't matter. Fact is that a large potential user base will simply not consider a GC language. No need to explain it here. When I speak about vision I mean something that anyone coming to dlang.org page or GitHub repo sees. Something that is explained in a bit more details, possibly with code examples. I know I am asking much but seeing quick reference for "imagine this stuff is implemented, this is how your program code will be affected and this is why it is a good thing" could have been huge deal. I'm confused. Why would anyone who just comes to dlang.org see unformed ideas and incomplete designs? Wouldn't newcomers be more attracted by e.g. stuff coming in the next release? Right now your rationales get lost in forum discussion threads and it is hard to understand what really is Next Big Thing and what is just forum argument blown out of proportion. There was a go at properties, at eliminating destructors, at rvalue references and whatever else I have forgotten by now. It all pretty much ended with "do nothing" outcome for one reason or the other. Let's see. We have properties, which indeed need some work done but don't seem to prevent people from getting work done. The discussion on eliminating destructors concluded with "we don't want to do that for good reasons". For binding rvalues Walter has a tentative design that's due for an RFC soon. The fact that you don't seem to have a consensus with Walter on some topic (auto-decoding, yeah) doesn't help either. Language marketing is not about posting links on reddit, it is a very hard work of communicating your vision so that it is clear even to random by-passer. I think one good thing we can do is approach things in private before discussing them publicly. 2) reliable release base I think this is most important part of open-source infrastructure needed to attract more contributions and something that also belongs to the "core team". I understand why Walter was so eager to delegate is but right now the truth is that once Andrew has to temporarily leave all release process has immediately stalled. And finding replacement is not easy - this task is inherently ungrateful as it implies spending time and resources on stuff you personally don't need at all. We now have Martin Nowak as the point of contact. And what if he gets busy too? :) Maybe you'll volunteer. 3) lack of field testing Too many new features get added simply because they look theoretically sound. What would those be? Consider something like `inout`. It is a very look feature to address an issue specific to D and it looked perfectly reasonable when it was introduces. And right now there are some fishy hacks about it even in Phobos (like forced inout delegates in traits) that did come from originally unexpected usage cases. It is quite likely that re-designing it from scratch based on existing field experience would have yielded better results. No doubt its design could be done better. But inout was not motivated theoretically. It came from the practical need of not duplicating code over qualifiers. Policy-based design is more than one decade old, and older under other guises. Reference counting is many decades old. Both have been humongous success stories for C++. Probably I have missed the point where new proposal was added but original one was not using true policy-based design but set of enum flags instead (no way to use user-defined policy). Sean proposed that. In fact that's a very good success story of sharing stuff for discussion sooner rather than later: he answered a Request For Comments with a great comment. Reference counting experience I am aware of shows that it is both successful in some cases and unapplicable for the others. But I don't know of any field experience that shows that chosing between RC and GC as a policy is a good/sufficient tool to minimize garbage creation in libraries - real issue we need to solve that original proposal does not mention at all. That's totally fine. A good design can always add a few innovation on top of known territory. In fact we've done some experimenting at Facebook with fully collected PHP (currently it's reference counted). RC is well understood as an alternative/complement of tracing. Anyhow, discussion is what the Request For Comments is good for. But please let's focus on actionable stuff. I can't act on vague doubts. No need to trust me or anyone, but at some point decisions will be made. Most decis
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 13:42:35 UTC, Andrei Alexandrescu wrote: On 10/5/14, 11:23 PM, eles wrote: On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote: On 10/5/14, 3:08 PM, eles wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: It doesn't because they need to be allocated dynamically. That's why there's a need for the likes of unique_ptr and shared_ptr in C++. Yes, or that delete. And AFAIS not only C++ needs unique_ptr and shared_ptr, this ARC thing is the same in D. The intermediate type between struct and class is struct. D with classes, anyone?
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On Mon, 06 Oct 2014 15:48:31 +0100, Jacob Carlborg wrote: On 06/10/14 15:45, Andrei Alexandrescu wrote: Knowledge doesn't have to be by type; just place data inside the exception. About the only place where multiple "catch" statements are used to make fine distinctions between exception types is in sample code showing how to use multiple "catch" statements :o). This whole notion that different exceptions need different types is as far as I can tell a red herring. What do you suggest, error codes? I consider that an ugly hack. Why? It gives us the benefits of error code return values: - ability to easily/cheaply check for/compare them using "switch" on code value (vs comparing/casting types) - ability to pass through OS level codes directly Without any of the penalties: - checking for them after every call. - losing the return value "slot" or having to engineer multiple return values in the language. - having to mix error codes in with valid return values (for int() functions). We also get: - no type proliferation. - no arguments about what exception types are needed, or the hierarchy to put them in. Seems like a win to me. Of course.. it would be nicer still if there was a list of OS/platform agnostic error codes which were used throughout phobos and could be re-used by client code. And.. (for example) it would be nice if there was a FileNotFound(string path) function which returned an Exception using the correct code allowing: throw FileNotFound(path); and so on. I do not know a lot about how exceptions are thrown and caught at the compiler/compiled code level, but perhaps there is even a performance benefit to be had if you know that only 2 possible types (Exception and Error) can/will be thrown.. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: What are the worst parts of D?
On Mon, 06 Oct 2014 08:39:54 -0700 Andrei Alexandrescu via Digitalmars-d wrote: > I appeal to you and others to keep language and attitude in check. i'm doing my best, rewriting my posts at least three times before sending. i bet noone wants to read the first variants. ;-) but this thread is a good place to show some emotions. i believe that we need such "emotional ranting" threads, so people can scream here and then calm down. sure it's very flammable; we must keep fire extinguishers at hand. ;-) signature.asc Description: PGP signature
Re: What are the worst parts of D?
On 10/6/14, 8:08 AM, Joakim wrote: You and Walter do a good job of answering questions on Reddit and there's certainly a lot of discussion on the forum where the two of you chip in, but what's missing is a high-level overview of the co-BDFLs' priorities for where the language is going, including a list of features you'd like to see added, ie that are pre-approved (that doesn't mean _any_ implementation would be approved, only that feature in principle). Aye, something like that might be helpful. I'll keep it in mind. Most users or wannabe contributors aren't going to go deep-diving through the forums for such direction. I'm not so sure that's a problem. It takes some connection to the language milieu before making a major contribution of the kind to be on a "vision" list. And once that connection is present, it's rather clear what the issues are. That's the case for any language. Manu and others recently wrote that the traffic on the forum has gone up, making it tougher for them to keep up. Yah, there's been some growing pains. Traffic is on the rise and unfortunately the signal to noise ratio isn't. Converting the existing passion and sentiment into workable items is a present challenge I'm thinking of ways to approach. It would help if the two co-BFDLs did a better job articulating and communicating their vision in a public place, like a page on the wiki or dlang.org website, rather than buried in the haystack of the forums or reddit. That's sensible. Andrei
Re: What are the worst parts of D?
On 10/6/14, 8:35 AM, ketmar via Digitalmars-d wrote: On Mon, 06 Oct 2014 15:22:17 + Joakim via Digitalmars-d wrote: People in this thread are emotional because they care yes. i don't think that anybody (including me ;-) wants to directly insult someone here. I appeal to you and others to keep language and attitude in check. We all are well intended here, all we need to do is convert heat into work, which should be possible per the first and second principle of thermodynamics. All we need is some cooling :o). Andrei
Re: What are the worst parts of D?
On Mon, 06 Oct 2014 15:22:17 + Joakim via Digitalmars-d wrote: > People in this thread are emotional because they care yes. i don't think that anybody (including me ;-) wants to directly insult someone here. D is good, that's why "not-so-good" features are so annoying that we are writing such emotional postings. signature.asc Description: PGP signature
Re: Who pays for all this?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/10/14 12:19, Joseph Rushton Wakeling via Digitalmars-d wrote: […] > By "foundation", do you mean "non-profit organization"? Would it > be any simpler as far as you are concerned to set up an > organization without initially worrying about its non-profit > status? Indeed D Foundation would be a non-profit company. The non-profit status is, I believe, somewhat important since without it the organization is required to be driven by increasing shareholder value, this is not entirely consistent with being holder of IP for a FOSS project and handling donations from other organization (profit, non-profit, or other). The legal issues are minor compared to the marketing ones: donors want to know that their donations are going to be used to move the projects forward not profit. Obviously though creating a company and then going for non-profit status is a resonable strategy. But the role as custodian of the project should only be taken on once the non-profit status is in place. - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQytl4ACgkQ+ooS3F10Be8htACfYFfli/FRSjLYPahifzxXoHLF OkUAn3hPn5zXjN9i3Cdaa7JaGSNgZfa8 =aK18 -END PGP SIGNATURE-
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 15:13:59 UTC, Nicolas F. wrote: On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote: What do you think are the worst parts of D? The fact that its community, when faced with the question "What do you think are the worst parts of D?", will readily have a 35 page verbal fistfight over what the worst parts of D are. Don't get me wrong, I'm happy that discussion is happening about such things, but I think it may be better to have it in a more structured manner in the future, and with a little less emotional investment. Heh, I think such self-criticism by the community is great, for example, I loved that I recently stumbled across this page on the wiki: http://wiki.dlang.org/Language_issues How many other languages can boast such a page of problems on their own wiki? :) Thanks to Vlad and Mike for writing it. People in this thread are emotional because they care: I don't think it's gone overboard given the real concerns they're stating. When the D community starts hiding its problems and stops critiquing its own efforts, sometimes passionately if that's what you truly feel, is when it starts going downhill.
Re: On exceptions, errors, and contract violations
On Monday, 6 October 2014 at 13:11:25 UTC, Marco Leise wrote: Ok, I get it. You are asking for a change in paradigms. But it is way outside my comfort zone to say yes or no to it. I will just go on duplicating the error checking through input validation. I think D, Go, Rust and C++ struggle with high-level vs low-level programming. It is a difficult balancing act if you want to keep the language/libraries reasonably simple and uniform. Go has more or less kicked out the low-level aspect and are now spending effort on getting acceptable response times in a high concurrency, memory safe niche. Useful, but limited. Rust is too young to be evaluated, but kind of attempt to get safety through wrapping up unsafe stuff in unique_ptr boxes. Immature and at the moment inconvenient, but they are at least clear on keeping a razor sharp fence between unsafe and safe code. C++ struggles with their high level effort and will do so forever. Primarily useful if your needs for high level support is limited and use C++ as a "better C". Cost efficient web programming requires expressive high level programming frameworks where things are caught at runtime by a rich semantic system and turned into appropriate HTTP responses. There is usually little incentive to turn off safety features. Engine/kernel/DSP/AI programming requires low level programming frameworks where you get to treat all data in their binary representation or close to it. Safety features are too expensive, but useful during debugging. D tries to cover both, but the priorities are unclear and it isn't suitable for either out-of-the-box. Which is natural when you don't want to give up performance and still want to have convenience. I guess the current focus is to take the performance-limiting aspects of convenience out of the language/runtime and put it into libraries so that you can more easily configure according to the application domain. The question is if you can do that without sacrificing ease of use, interoperability, performance and convenience. It will be interesting to see how D without GC plays out, though.
Re: What are the worst parts of D?
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote: What do you think are the worst parts of D? The fact that its community, when faced with the question "What do you think are the worst parts of D?", will readily have a 35 page verbal fistfight over what the worst parts of D are. Don't get me wrong, I'm happy that discussion is happening about such things, but I think it may be better to have it in a more structured manner in the future, and with a little less emotional investment. That being said, the second worst part of D for me is the current state of documentation, which is something that is often mentioned. I'd be happy to take part in a "docs initiative" where some of us sit together and talk about how we can improve the documentation of the language, collect input from outside, and then implement the changes that are found to be necessary. This would make it easier for people who don't wish to set up the entire build environment for the documentation on their side to participate in documentation adjustments by giving feedback, while a somewhat dedicated group of people then focus on making decisions reality.
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 13:54:05 UTC, Andrei Alexandrescu wrote: On 10/6/14, 5:42 AM, Wyatt wrote: On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote: No need to explain it here. When I speak about vision I mean something that anyone coming to dlang.org page or GitHub repo sees. Something that is explained in a bit more details, possibly with code examples. I know I am asking much but seeing quick reference for "imagine this stuff is implemented, this is how your program code will be affected and this is why it is a good thing" could have been huge deal. Right now your rationales get lost in forum discussion threads Jerry Christmas, this right here! Andrei, I know you keep chanting "C++ and GC", and that's cool and all, but its also kind of meaningless because we can't read minds. I understand. What would be a good venue for discussing such topics? I thought the D language forum would be most appropriate. -- Andrei Answer: On Friday, 26 September 2014 at 10:22:50 UTC, Joakim wrote: It needs to be a page on the wiki or the main site, which you or any user can link to anytime people want to know the plan. some sort of public plan of where you want the language to go. All I'm asking for is a public list of preapproved and maybe rejected features that the two of you maintain. Dfix might be on the preapproved list, ARC might be on the rejected. ;) You could also outline broad priorities like C++ support or GC improvement on such a webpage. You and Walter do a good job of answering questions on Reddit and there's certainly a lot of discussion on the forum where the two of you chip in, but what's missing is a high-level overview of the co-BDFLs' priorities for where the language is going, including a list of features you'd like to see added, ie that are pre-approved (that doesn't mean _any_ implementation would be approved, only that feature in principle). Most users or wannabe contributors aren't going to go deep-diving through the forums for such direction. Manu and others recently wrote that the traffic on the forum has gone up, making it tougher for them to keep up. It would help if the two co-BFDLs did a better job articulating and communicating their vision in a public place, like a page on the wiki or dlang.org website, rather than buried in the haystack of the forums or reddit.
Re: What are the worst parts of D?
On 10/6/14, 7:36 AM, Wyatt wrote: To be succinct: how about an article? An article would be great once we have done something we can show. We're not asking for a discussion in this case so much as some frank sharing. Is there anything dishonest about sharing intent about the D programming language in the public forum of the D programming language? D is going to have C++ support. That's cool and compelling as a bare statement, but in what manner? We don't know yet, we're designing it - to wit, we're looking for help regarding exception interoperability. What kinds of things will this allow that were impossible before? The exact list is in the air. We're looking e.g. for the best policy on exceptions. Possible vs. impossible is btw a matter of scale, for example wrapping everything you need from C++ in C functions is possible in the small but impossible at scale. How, specifically, do you envision that to look? What is "that"? Can you give example code that you would expect to work when it's "done"? This was discussed already: we should be able to pass an std::vector by reference/pointer from C++ into D and use it within D directly, with no intervening marshaling. What are the drawbacks you believe forward engineers will have to watch out for? What's a forward engineer? It's okay to not have all the answers and explain that there are parts that may not make it because of various reasons. I somewhat feel that you're approaching this situation as if it that were all quite obvious. Maybe it is to you? I don't know. But I do know I'm not alone in the dark here. Please bring a lamp. It seems this is a simple misunderstanding. You're looking for a virtually finished product (article documenting how it works; analysis; design; projected impact) whereas we're very much at the beginning of all that. What's clear to me is we need better interop with C++, so I've put that up for discussion as soon as reasonable. You're asking for things that are months into the future. Andrei
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On 10/6/14, 7:48 AM, Jacob Carlborg wrote: On 06/10/14 15:45, Andrei Alexandrescu wrote: Knowledge doesn't have to be by type; just place data inside the exception. About the only place where multiple "catch" statements are used to make fine distinctions between exception types is in sample code showing how to use multiple "catch" statements :o). This whole notion that different exceptions need different types is as far as I can tell a red herring. What do you suggest, error codes? I consider that an ugly hack. I don't. On the contrary, I do consider proliferating types to the multiplicity of possible errors an obvious design sin. -- Andrei
Re: scope() statements and return
On 10/6/14, 7:24 AM, monarch_dodra wrote:
If your "catch" throws an exception, then the new exception simply
"squashes" replaces the old one:
//
catch (Exception e)
{
thisMightThrow(); //Lose "e" here
throw e;
}
//
That's code under library/user control, I'm talking about the
responsibility of the language. -- Andrei
Re: scope() statements and return
On 10/4/14 2:45 PM, Shammah Chancellor wrote:
int main()
{
scope(exit) return 0;
assert(false, "whoops!");
}
The above smells to me like it should be invalid. Specifically, the
scope(exit) line by itself.
If you want to catch and not propagate an error, you need to use
try/catch directly.
scope(exit|success|failure) is for cleaning up resources, not returning
from the function.
-Steve
Re: What are the worst parts of D?
On 10/6/14, 7:05 AM, Paolo Invernizzi wrote: On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote: On 10/6/14, 12:44 AM, Paolo Invernizzi wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: TDPL was an absolutely awesome book because it expained "why?" as opposed to "how?". Such insight into language authors rationale is incredibly helpful for long-term contribution. Unfortunately, it didn't cover all parts of the language and many new things has been added since it was out. I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998 I did comment in this group. -- Andrei I'm missing something? If you are _only_ meaning that one [1] I keep being scared ;-) No pun intended, really. http://forum.dlang.org/thread/mxpfzghydhirdtltm...@forum.dlang.org?page=3#post-lvhoic:2421o4:241:40digitalmars.com I understand the necessity for further scrutiny of that work. Even before that I owe Sönke Ludwig a review for std.data.json. There's a large list of things I need to do at work, mostly D-related, not all of which I am not at liberty to make public. On top of that I have of course other obligations to tend to. To interpret my lack of time politically is really amusing. You guys have too much time on your hands :o). Andrei
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On 06/10/14 15:45, Andrei Alexandrescu wrote: Knowledge doesn't have to be by type; just place data inside the exception. About the only place where multiple "catch" statements are used to make fine distinctions between exception types is in sample code showing how to use multiple "catch" statements :o). This whole notion that different exceptions need different types is as far as I can tell a red herring. What do you suggest, error codes? I consider that an ugly hack. -- /Jacob Carlborg
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On 10/6/14, 7:01 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Oct 06, 2014 at 06:46:31AM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 10/5/14, 11:39 PM, Dmitry Olshansky wrote: It's obvious to me that one hierarchy is way to limiting for exceptions, simply because there could be many ways to categorize the same set of error conditions. Well put. -- Andrei What's the alternative, though? I can't think of any solution that (1) isn't far more complicated than the current state of things and (2) is easier to use. I'm thinking a simple key-value store Variant[string] would accommodate any state needed for differentiating among exception kinds whenever that's necessary. It's commonly accepted that the usability scope of OOP has gotten significantly narrower since its heydays. However, surprisingly, the larger community hasn't gotten to the point to scrutinize object-oriented error handling, which as far as I can tell has never delivered. Andrei
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 13:54:05 UTC, Andrei Alexandrescu wrote: On 10/6/14, 5:42 AM, Wyatt wrote: On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote: No need to explain it here. When I speak about vision I mean something that anyone coming to dlang.org page or GitHub repo sees. Something that is explained in a bit more details, possibly with code examples. I know I am asking much but seeing quick reference for "imagine this stuff is implemented, this is how your program code will be affected and this is why it is a good thing" could have been huge deal. Right now your rationales get lost in forum discussion threads Jerry Christmas, this right here! Andrei, I know you keep chanting "C++ and GC", and that's cool and all, but its also kind of meaningless because we can't read minds. I understand. What would be a good venue for discussing such topics? I thought the D language forum would be most appropriate. -- Andrei Sure, the newsgroup is a great place to discuss the minutiae of specific features and figure out how they might be implemented and what design tradeoffs need to be made. I think we've shown we can disagree about the colour of any bikeshed of any shape and construction at this point! But in what venue do you feel comfortable holding the easily-accessible public record of your intent for C++ support so anyone wondering about this new mantra can get the summary of what it means for them _as an end user_ without scouring the NG and partially-piecing-it-together-but-not-really from a dozen disparate posts? To be succinct: how about an article? We're not asking for a discussion in this case so much as some frank sharing. D is going to have C++ support. That's cool and compelling as a bare statement, but in what manner? What kinds of things will this allow that were impossible before? How, specifically, do you envision that to look? Can you give example code that you would expect to work when it's "done"? What are the drawbacks you believe forward engineers will have to watch out for? It's okay to not have all the answers and explain that there are parts that may not make it because of various reasons. I somewhat feel that you're approaching this situation as if it that were all quite obvious. Maybe it is to you? I don't know. But I do know I'm not alone in the dark here. Please bring a lamp. -Wyatt
Re: On exceptions, errors, and contract violations
On 10/3/14 1:40 PM, Sean Kelly wrote: Setting aside exceptions for the moment, one thing I've realized about errors is that in most cases, an API has no idea how important its proper function is to the application writer. This is the thing I have been arguing. Inside a library, the idea of input to the function being user defined or program-defined is not clear. It means that any user-defined input has to be double checked in the same exact way, to avoid having an error thrown in the case that the library function throws an error on such input. The other side, any program-caused errors that end up triggering exceptions (a misnamed filename for opening a config file, for instance), needs to treat this exception as an error and halt the program with an appropriate stack trace. What makes sense to me is: 1. If you send in an obvious programming error (i.e. null instead of an expected target address), throw an error. This can be done in contract precondition scopes. Such things could NOT be generated by user. 2. If you send in something that doesn't make sense, but could be user-generated, throw an exception. User-generated is a very fuzzy thing, but we should conservatively assume the input is user-generated. 3. If anything happens internally to the function, treat it as an error. If an input causes an exception, but the input was program generated, don't catch it in the calling scope! Just let the runtime handle it as an error, and exit the program. Any uncaught exceptions should be treated as errors anyway. It might be a good idea to have an umbrella exception type that means "input invalid." This gives some easy way to catch all such exceptions and print them properly in the case where it's user-defined input. -Steve
Re: Request for review - std.serialization (orange)
On 06/10/14 12:24, "Daniele Bondì" " wrote: Any news on this? No, I'm currently working on D/Objective-C [1]. [1] http://wiki.dlang.org/DIP43 -- /Jacob Carlborg
Re: scope() statements and return
On Monday, 6 October 2014 at 13:48:07 UTC, Andrei Alexandrescu
wrote:
On 10/6/14, 12:27 AM, Walter Bright wrote:
On 10/5/2014 10:09 AM, Dicebot wrote:
On Sunday, 5 October 2014 at 17:03:07 UTC, Andrei
Alexandrescu wrote:
On 10/5/14, 9:42 AM, Dicebot wrote:
On Sunday, 5 October 2014 at 16:30:47 UTC, Ola Fosheim
Grøstad wrote:
Does D have exception chaining?
Yes. http://dlang.org/phobos/object.html#.Throwable.next
Though it seems to do more harm then good so far.
What harm does it do? -- Andrei
Good chunk of issues with pre-allocated exceptions (and
possible
cycles in
reference counted ones) comes from the chanining possibility.
At the
same time I
have yet to see it actively used as a feature.
Doesn't mean it is bad thing, just not used wide enough to
compensate for
trouble right now.
FWIW, I'm skeptical as well of the value of chaining relative
to its
cost in complexity.
It's one of those designs in which there's little room to turn.
We wanted to (a) allow destructors to throw, (b) conserve
information. Offering access to all exceptions caught was a
natural consequence. -- Andrei
Well, then again, even that promise isn't really held.
If your "catch" throws an exception, then the new exception
simply "squashes" replaces the old one:
//
catch (Exception e)
{
thisMightThrow(); //Lose "e" here
throw e;
}
//
I've seen literally no-one ever chain exceptions once one has
been caught. Not even druntime does it. For example, if an
exception occurs during a static array construction, this
triggers the destruction of already constructed items. If one of
*those* fails, then the cleanup loop terminates (without cleaning
the rest of the items mind you). And the user is greeted with a
"Object destruction failed", even though the array was never
constructed to begin with!
There's merit in the goal, but I don't think the current design
has achieved it.
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote: On 10/6/14, 12:44 AM, Paolo Invernizzi wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: TDPL was an absolutely awesome book because it expained "why?" as opposed to "how?". Such insight into language authors rationale is incredibly helpful for long-term contribution. Unfortunately, it didn't cover all parts of the language and many new things has been added since it was out. I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998 I did comment in this group. -- Andrei I'm missing something? If you are _only_ meaning that one [1] I keep being scared ;-) No pun intended, really. http://forum.dlang.org/thread/mxpfzghydhirdtltm...@forum.dlang.org?page=3#post-lvhoic:2421o4:241:40digitalmars.com --- /Paolo
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On Mon, Oct 06, 2014 at 06:46:31AM -0700, Andrei Alexandrescu via Digitalmars-d wrote: > On 10/5/14, 11:39 PM, Dmitry Olshansky wrote: > > > >It's obvious to me that one hierarchy is way to limiting for > >exceptions, simply because there could be many ways to categorize the > >same set of error conditions. > > Well put. -- Andrei What's the alternative, though? I can't think of any solution that (1) isn't far more complicated than the current state of things and (2) is easier to use. T -- "Holy war is an oxymoron." -- Lazarus Long
Re: What are the worst parts of D?
On 10/6/14, 12:44 AM, Paolo Invernizzi wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: TDPL was an absolutely awesome book because it expained "why?" as opposed to "how?". Such insight into language authors rationale is incredibly helpful for long-term contribution. Unfortunately, it didn't cover all parts of the language and many new things has been added since it was out. I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998 I did comment in this group. -- Andrei
Re: What are the worst parts of D?
On 10/6/14, 6:18 AM, ketmar via Digitalmars-d wrote: and now for multiple "alias this"... as you can see this will not help c++ interop, and it will not help gc, so it can lay rotting on github. not a word, not even "will not accept this" or "it's interesting, please keep it up-to-date while you can, we are little busy right now, but will look at it later". second-class citizens will not run away. We will accept multiple "alias this". -- Andrei
Re: What are the worst parts of D?
On 10/6/14, 5:42 AM, Wyatt wrote: On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote: No need to explain it here. When I speak about vision I mean something that anyone coming to dlang.org page or GitHub repo sees. Something that is explained in a bit more details, possibly with code examples. I know I am asking much but seeing quick reference for "imagine this stuff is implemented, this is how your program code will be affected and this is why it is a good thing" could have been huge deal. Right now your rationales get lost in forum discussion threads Jerry Christmas, this right here! Andrei, I know you keep chanting "C++ and GC", and that's cool and all, but its also kind of meaningless because we can't read minds. I understand. What would be a good venue for discussing such topics? I thought the D language forum would be most appropriate. -- Andrei
Re: Who pays for all this?
On 10/6/14, 4:19 AM, Joseph Rushton Wakeling wrote: On Monday, 6 October 2014 at 04:09:11 UTC, Andrei Alexandrescu wrote: I believe a foundation would help D. Unfortunately, setting one up is very laborious, and neither Walter nor I know anything about that - from what I understand it takes a _lot_ of work. By "foundation", do you mean "non-profit organization"? Would it be any simpler as far as you are concerned to set up an organization without initially worrying about its non-profit status? I don't know. -- Andrei
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On 10/5/14, 11:39 PM, Dmitry Olshansky wrote: It's obvious to me that one hierarchy is way to limiting for exceptions, simply because there could be many ways to categorize the same set of error conditions. Well put. -- Andrei
Re: Program logic bugs vs input/environmental errors (checked exceptions)
On 10/5/14, 11:31 PM, Jacob Carlborg wrote: On 05/10/14 18:18, Andrei Alexandrescu wrote: Exceptions are all about centralized error handling. How, and how often, would you handle FileNotFoundException differently than PermissionDeniedException? Probably not that often. But I don't think it's up to "File" to decide that. I think "File" should throw a specific error as possible containing all details it has. Sure, but that can be distinguished by payload, not type. Then it's up to the user of "File" how to handle the exception. If you're not interested in the differences between FileNotFoundException and PermissionDeniedException, then catch the base class instead. The details provided between these two exception could be different as well. FileNotFoundException should contain the path of the file that wasn't found. PermissionDeniedException should contain some information about if it was the source or target that caused the exception to be thrown. Think of a copy or move operation. How would one localize error messages if the specific exception is not known? Knowledge doesn't have to be by type; just place data inside the exception. About the only place where multiple "catch" statements are used to make fine distinctions between exception types is in sample code showing how to use multiple "catch" statements :o). This whole notion that different exceptions need different types is as far as I can tell a red herring. Andrei
Re: scope() statements and return
On 10/6/14, 12:27 AM, Walter Bright wrote: On 10/5/2014 10:09 AM, Dicebot wrote: On Sunday, 5 October 2014 at 17:03:07 UTC, Andrei Alexandrescu wrote: On 10/5/14, 9:42 AM, Dicebot wrote: On Sunday, 5 October 2014 at 16:30:47 UTC, Ola Fosheim Grøstad wrote: Does D have exception chaining? Yes. http://dlang.org/phobos/object.html#.Throwable.next Though it seems to do more harm then good so far. What harm does it do? -- Andrei Good chunk of issues with pre-allocated exceptions (and possible cycles in reference counted ones) comes from the chanining possibility. At the same time I have yet to see it actively used as a feature. Doesn't mean it is bad thing, just not used wide enough to compensate for trouble right now. FWIW, I'm skeptical as well of the value of chaining relative to its cost in complexity. It's one of those designs in which there's little room to turn. We wanted to (a) allow destructors to throw, (b) conserve information. Offering access to all exceptions caught was a natural consequence. -- Andrei
Re: What are the worst parts of D?
On 10/5/14, 11:23 PM, eles wrote: On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote: On 10/5/14, 3:08 PM, eles wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: The main distinction between structs and classes in D is the former are monomorphic value types and the later are polymorphic reference types. -- Andrei Why hack them with scoped? The need exists, since you provide a hack for it. Reference classes in C++ are polymorphic & reference, but their destructor/disposer gets called. It doesn't because they need to be allocated dynamically. That's why there's a need for the likes of unique_ptr and shared_ptr in C++. There is a delete that triggers that or a smart pointer. I don't care if the delete or the destructor really frees the memory, but I would like it to get called, to release other resources that the object might have locked and to mark the object as "invalid". Later access to it shall triger an exception: "invalidObject". Call it dispose if you like, because delete is too much like freeing memory. Is there an intermediate type between structs and classes? The intermediate type between struct and class is struct. Andrei
Re: What are the worst parts of D?
On Mon, 06 Oct 2014 12:48:28 + Meta via Digitalmars-d wrote: > On Monday, 6 October 2014 at 07:51:41 UTC, ketmar via > Digitalmars-d wrote: > > On Mon, 06 Oct 2014 07:44:56 + > > Paolo Invernizzi via Digitalmars-d > > wrote: > > > >> I would also add that it's scaring not having seen a single > >> comment of Andrej here: > >> https://github.com/D-Programming-Language/dmd/pull/3998 > > it's not about c++ interop or gc, so it can wait. existing D > > users will > > not run away, they are used to be second-class citizens. > > That's a bit unfair of you. that's what i see. even when people praying for breaking their code to fix some quirks in language, the answer is "NO". why no? 'cause some hermit living in far outlands may wrote some code years ago and that code will break and hermit will be unhappy. unhappiness of active users doesn't matter. and about writing autofixing tool... silence is the answer. "so will you accept that changes if we'll write dfix tool to automatically fixing source code?" silence. "play your little games, we don't care, as we don't plan to change that anyway, regardless of the tool availability". Walter once said that he is against "dfix", and nothing was changed since. "ah, maybe, we aren't interested..." there is little motivation of doing work on "dfix" if it's not endorsed by leading language developers. and now for multiple "alias this"... as you can see this will not help c++ interop, and it will not help gc, so it can lay rotting on github. not a word, not even "will not accept this" or "it's interesting, please keep it up-to-date while you can, we are little busy right now, but will look at it later". second-class citizens will not run away. signature.asc Description: PGP signature
Re: On exceptions, errors, and contract violations
Ok, I get it. You are asking for a change in paradigms. But it is way outside my comfort zone to say yes or no to it. I will just go on duplicating the error checking through input validation. -- Marco
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 07:51:41 UTC, ketmar via Digitalmars-d wrote: On Mon, 06 Oct 2014 07:44:56 + Paolo Invernizzi via Digitalmars-d wrote: I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998 it's not about c++ interop or gc, so it can wait. existing D users will not run away, they are used to be second-class citizens. That's a bit unfair of you.
Re: What are the worst parts of D?
On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote: No need to explain it here. When I speak about vision I mean something that anyone coming to dlang.org page or GitHub repo sees. Something that is explained in a bit more details, possibly with code examples. I know I am asking much but seeing quick reference for "imagine this stuff is implemented, this is how your program code will be affected and this is why it is a good thing" could have been huge deal. Right now your rationales get lost in forum discussion threads Jerry Christmas, this right here! Andrei, I know you keep chanting "C++ and GC", and that's cool and all, but its also kind of meaningless because we can't read minds. Judging by the recent thread where someone (Ola?) asked what "C++ support" actually means and received precisely zero useful guidance, no one else does either. (This isn't to say I don't think it's important, but the scope of what you're doing right now and how it materially helps end users isn't really clear.) There was a go at properties SALT. -Wyatt
Re: scope() statements and return
On Monday, 6 October 2014 at 07:28:22 UTC, Walter Bright wrote: FWIW, I'm skeptical as well of the value of chaining relative to its cost in complexity. Python 3 has two fields: "__cause__" and "__context__". The cause field is used for explicit chaining on re-throws. Can be useful for diagnostics and is trouble free. The context field is used for preserving exceptions that are unfortunately overruled by subsequent throws. Which can lead to missed clean-up handling. :-/
Re: What are the worst parts of D?
Dne 6.10.2014 v 12:15 ketmar via Digitalmars-d napsal(a): > On Mon, 06 Oct 2014 10:22:01 +0200 > Martin Drašar via Digitalmars-d wrote: > > as i said this is the very first version of cmdcon, not the one i'm > using now. i'm not able to publish the current version yet. > >> That is, how do you use this console interactively? >> In your previous mail you wrote that you use a telnet. >> Do you have another mixin that at some specific point inserts a code >> that pauses the execution of surrounding code and starts listening >> for telnet commands? > it depends of event loop, actually. i have my own event loop code, and > there is hook for telnet channel. that hook collects line to execute, > calls cmdcon executor and outputs cmdcon output. maybe i'll publish > some std.socket-based sample later. > >> Also, how do you make your console work in multithreaded programs? > you should register only shared and global vars (and i'm really missing > __trait(isGShared) here!), there is no sense to register thread locals > in multithreaded program. > > but you can register free functions and execute 'em. that free > functions should take care of threading. > > really, i have to revisit that code and write some samples. i'll try to > do that soon. and maybe i'll update public versino of cmdcon a little > too. ;-) > Ok, thanks for your answers. If you get your code to publishable state, I am sure a lot of people will be interested. Cheers, Martin smime.p7s Description: Elektronicky podpis S/MIME
Re: Who pays for all this?
On Monday, 6 October 2014 at 04:09:11 UTC, Andrei Alexandrescu wrote: I believe a foundation would help D. Unfortunately, setting one up is very laborious, and neither Walter nor I know anything about that - from what I understand it takes a _lot_ of work. By "foundation", do you mean "non-profit organization"? Would it be any simpler as far as you are concerned to set up an organization without initially worrying about its non-profit status?
Re: What are the worst parts of D?
On Thursday, 25 September 2014 at 00:52:25 UTC, Walter Bright wrote: On 9/24/2014 7:56 AM, Don wrote: For example: We agreed *years* ago to remove the NCEG operators. Why haven't they been removed yet? They do generate a warning if compiled with -w. What change in particular? I've got a nasty feeling that you misread what he wrote. Every time we say, "breaking changes are good", you seem to hear "breaking changes are bad"! It would be helpful having a list of what breaking changes you had in mind. Perhaps it would be a good idea to have a themed update? Currently you and Andrei are busy with the C++ changes, when that is settling down maybe the community could focus on a cleaning house update. With clear update themes (which does not preclude the usual mixture of things also going on) people can air issues and get it ye or nay'd clearly. Combining the previously discussed auto-update code tool with a set of breaking changes would make sense.
Re: Who pays for all this?
On Monday, 6 October 2014 at 02:24:45 UTC, Shammah Chancellor wrote: On 2014-10-05 03:33:36 +, Walter Bright said: We're not really limited by lack of funds, but more by lack of focussed effort. If anyone wants to contribute funds, probably the best use would be to add bug bounties for bugzilla issues that they find to be neglected. The bounties don't really compensate at professional rates, but they do work as a nice "thanks" to those who donate their valuable time. I've placed a couple of anonymous bounties, but I personally think it's a bad way to get directed focused effort. A democracy of people trying to get what they individually want done through small donations? Yes, that is the way democracy works, what is the problem? The only benefit from a foundation is that they can make decisions for the community that individual donors may not have the information to make, including a co-BFDL like Andrei with his specific expertise. Well, if you want to follow Andrei, just add on to each of his bountysource bounties, and if you want to follow the community, just randomly add to existing D bountysource bounties or to all of them. It would be nice if the wiki had links to the D bountysource projects though: https://www.bountysource.com/trackers/383571-d-programming-language https://www.bountysource.com/trackers/283332-ldc https://www.bountysource.com/trackers/455080-gdc I notice that the top issue is at $1k now, not bad. There are many languages which have grown more quickly than D (despite being less interesting) because they have a foundation where people can donate, or some company, which provides for the core developers. I'm not saying that having a non-profit will magically generate money, but there are a few companies who use D out there who just might be willing to donate non-trivial sums of money to further development if there was a non-profit to see that the money was put to good use. Just to name a few: Python: https://www.python.org/psf-landing/ Node.JS: http://www.joyent.com/ Perl: http://www.perlfoundation.org Linux Core Developers: http://en.wikipedia.org/wiki/Linux_Foundation Ruby Core Developers: https://www.heroku.com (A subsidiary of Salesforce) I agree with you that a company would help, though I don't see much gain from a non-profit, especially if it's as much work to set up as Andrei says. If you want your money "put to good use," I don't see how your bounties on bountysource would be abused. Those bounties or individually contacting Andrei or Iain about funding the project expenses they've detailed strikes me as a far more direct way to contribute to the community than throwing money at a foundation and forgetting about it. Yes, you won't get to deduct tax from your contribution, but that's the least of our concerns.
Re: Request for review - std.serialization (orange)
Any news on this?
Re: What are the worst parts of D?
On Mon, 06 Oct 2014 10:22:01 +0200 Martin Drašar via Digitalmars-d wrote: as i said this is the very first version of cmdcon, not the one i'm using now. i'm not able to publish the current version yet. > That is, how do you use this console interactively? > In your previous mail you wrote that you use a telnet. > Do you have another mixin that at some specific point inserts a code > that pauses the execution of surrounding code and starts listening > for telnet commands? it depends of event loop, actually. i have my own event loop code, and there is hook for telnet channel. that hook collects line to execute, calls cmdcon executor and outputs cmdcon output. maybe i'll publish some std.socket-based sample later. > Also, how do you make your console work in multithreaded programs? you should register only shared and global vars (and i'm really missing __trait(isGShared) here!), there is no sense to register thread locals in multithreaded program. but you can register free functions and execute 'em. that free functions should take care of threading. really, i have to revisit that code and write some samples. i'll try to do that soon. and maybe i'll update public versino of cmdcon a little too. ;-) signature.asc Description: PGP signature
Re: GDC & Pandaboard/QEMU & Framebuffer
On Monday, 6 October 2014 at 04:39:03 UTC, John A wrote: Not sure where to post this; it's not a question, just some info. I have created a set of pages here: http://arrizza.org/wiki/index.php/Dlang with instructions which include: - how to create a GDC cross-compiler using crosstool-ng - how to create some sample applications to test out GDC - how to create a sample app that writes to the framebuffer via GDC - how to set up and run these apps on QEMU - how to run the same apps on a Pandaboard There is nothing new here. Others have written it already, some of which worked as advertised for me, some didn't. I've just gathered it up, tried it out and wrote down very specific instructions about what I needed to do to get it to work. Hopefully it works well for you. Note I use Ubuntu 12.04 for everything, so these pages won't help Windows folks. John Nice, I have ldc working at pretty much the same level on linux/arm, tested on a Cubieboard2. Have you tried running any of the druntime/phobos unit tests? All but two modules of druntime, as of the dmd 2.066 release, pass for me, while only three modules pass from phobos. I'll put up instructions for cross-compiling with ldc once I have more of it working, as cross-compiling with ldc is easier.
Re: Who pays for all this?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/10/14 09:12, Edwin van Leeuwen via Digitalmars-d wrote: […] > An alternative is to join an umbrella organisation that has > experience setting up foundations for open source projects. To name > a couple: Software Freedom Conservancy (Boost), Software in the > Public Interest, and the Outercurve Foundation. As far as I > understand it these organisations will help you with the paperwork, > but you have full autonomy outside of that. > > See http://lwn.net/Articles/561336/ for some more > suggestions/ideas. SCons used to have a USA-based foundation, but it lapsed. The various opinions sought indicate that reapplying would be too costly and too much of a burden. The current plan is to follow Buildbot and be a foundation under the umbrella of Software Freedom Conservancy. Thus this might be the best route for a D Foundation. I am writing this from memory rather than consulting the various email threads, so details lacking: there are some significant downsides to the Software Freedom Conservancy route, but the Buildbot folk decided it was worth it and this is a significant factor for SCons. I suspect SCons will be a member as soon as a couple of legal issues are resolved wrt cash and copyrights. - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQyW7wACgkQ+ooS3F10Be+dZwCghCdRKbW6MmgEN2plDzx0a3Fg eDgAoKa10Jl/6aJUZNx3RbBBiMYostyZ =Naq/ -END PGP SIGNATURE-
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 06:28:58 UTC, eles wrote: I like the safety that a GC guarantees, but is a too big price to be paid for that... What if you only had precise GC on class objects and nothing else? That believe could be done in a performant manner.
Re: What are the worst parts of D?
Dne 3.10.2014 v 16:42 ketmar via Digitalmars-d napsal(a): > alas, only very old and rudimentary module is available. basically, > it's the core of the full-featured console, but... only the core, and > not very well written. i'm planning to opensource fully working thingy > with bells and whistles eventually, but can't do it right now. :-( > > anyway, here it is: > http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/cmdcon.d > > please note that this is not very well tested. i'm keeping it just for > nostalgic reasons. > > ah, and you can ignore the license. consider that code as public > domain/WTFPL. > > there is no struct/class support there, only variables and free > functions. yet free functions supports various types of arguments and > understands default agrument values. Thanks a lot. I just briefly gone through the code and I have a question about the console use: That code is able to register functions and variables with some annotations and execute them by string commands. How do you generally use it for debugging purposes? That is, how do you use this console interactively? In your previous mail you wrote that you use a telnet. Do you have another mixin that at some specific point inserts a code that pauses the execution of surrounding code and starts listening for telnet commands? Also, how do you make your console work in multithreaded programs? Thanks, Martin smime.p7s Description: Elektronicky podpis S/MIME
Re: Who pays for all this?
On Monday, 6 October 2014 at 04:09:11 UTC, Andrei Alexandrescu wrote: I believe a foundation would help D. Unfortunately, setting one up is very laborious, and neither Walter nor I know anything about that - from what I understand it takes a _lot_ of work. If anyone is able and willing to embark on creating a foundation for D, that would be a great help to the language and its community. An alternative is to join an umbrella organisation that has experience setting up foundations for open source projects. To name a couple: Software Freedom Conservancy (Boost), Software in the Public Interest, and the Outercurve Foundation. As far as I understand it these organisations will help you with the paperwork, but you have full autonomy outside of that. See http://lwn.net/Articles/561336/ for some more suggestions/ideas. Edwin
Re: What are the worst parts of D?
On Monday, 6 October 2014 at 06:28:58 UTC, eles wrote: On Monday, 6 October 2014 at 06:28:02 UTC, eles wrote: On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote: On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote: On 10/5/14, 3:08 PM, eles wrote: On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: I like the safety that a GC guarantees, but is a too big price to be paid for that... Just look at this abomination from here: http://agilology.blogspot.com/2009/01/why-dispose-is-necessary-and-other.html sqlConnection.Close(); sqlConnection.Dispose(); sqlConnection = null; Is this your idea about releasing a resource? Why is this better than writing delete/dispose sqlConnection? If you ask to use structs for RAII, I am afraid that you will receive a DFront proposal.
Re: What are the worst parts of D?
On Mon, 06 Oct 2014 07:44:56 + Paolo Invernizzi via Digitalmars-d wrote: > I would also add that it's scaring not having seen a single > comment of Andrej here: > https://github.com/D-Programming-Language/dmd/pull/3998 it's not about c++ interop or gc, so it can wait. existing D users will not run away, they are used to be second-class citizens. signature.asc Description: PGP signature
Re: What are the worst parts of D?
On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote: TDPL was an absolutely awesome book because it expained "why?" as opposed to "how?". Such insight into language authors rationale is incredibly helpful for long-term contribution. Unfortunately, it didn't cover all parts of the language and many new things has been added since it was out. I would also add that it's scaring not having seen a single comment of Andrej here: https://github.com/D-Programming-Language/dmd/pull/3998 Right now I have no idea where the development is headed and what to expect from next few releases. I am not speaking about wiki.dlang.org/Agenda but about bigger picture. Unexpected focus on C++ support, thread about killing auto-decoding, recent ref counting proposal - all this stuff comes from language authors but does not feel like a strategic additions. It feels like yet another random contribution, no different from contribution/idea of any other D user. +1 on all. I am disturbed when Andrei comes with proposal that possibly affects whole damn Phobos (memeory management flags) and asks to trust his experience and authority on topic while rejecting patterns that are confirmed to be working well in real production projects. Don't get me wrong, I don't doubt Andrei authority on memory management topic (it is miles ahead of mine at the very least) but I simply don't believe any living person in this world can design such big change from scratch without some extended feedback from real deployed projects. +1000 --- /Paolo
Re: scope() statements and return
On 10/5/2014 10:09 AM, Dicebot wrote: On Sunday, 5 October 2014 at 17:03:07 UTC, Andrei Alexandrescu wrote: On 10/5/14, 9:42 AM, Dicebot wrote: On Sunday, 5 October 2014 at 16:30:47 UTC, Ola Fosheim Grøstad wrote: Does D have exception chaining? Yes. http://dlang.org/phobos/object.html#.Throwable.next Though it seems to do more harm then good so far. What harm does it do? -- Andrei Good chunk of issues with pre-allocated exceptions (and possible cycles in reference counted ones) comes from the chanining possibility. At the same time I have yet to see it actively used as a feature. Doesn't mean it is bad thing, just not used wide enough to compensate for trouble right now. FWIW, I'm skeptical as well of the value of chaining relative to its cost in complexity.
Re: scope() statements and return
On Monday, 6 October 2014 at 02:35:52 UTC, Shammah Chancellor wrote: It doesn't "catch" the error. Propigation should continue as normal. Right, it only "intercepts, cleanups, and rethrows". But the argument is that even that shouldn't happen, as you aren't sure the cleanup code is still relevant. At least, I don't think it should be doing cleanup unless you go out of your way to say: "do this, *even* in case of errors". I mean, your RAII has already failed anyways. Your memory has leaked, your ref counts are of the counter, your transactions are open, your file handles are open... The only thing you should be doing is trying to die gracefully, and maybe salvage user data. Your program is in *ERROR*. Cleanup really shouldn't be the priority, especially if it can potentially add more corruption to your state.
