Re: D future ...
On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote: I split this from the "Re: A betterC modular standard library?" topic because my response is will be too much off-topic but the whole thread is irking me the wrong way. I see some of the same argument coming up all the time, with a level of frequency. Five stars of five! Regards, Ozan
Re: Red Hat's issues in considering the D language
On 2016-12-21 00:08, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b I had a suggestion [1] to do something about the current state of unit tests but that was quickly shot down or went (slightly) off topic. [1] http://forum.dlang.org/thread/npptbk$2mk0$1...@digitalmars.com -- /Jacob Carlborg
Re: CTFE Status
On Tuesday, 20 December 2016 at 20:30:43 UTC, Nordlöw wrote: On Tuesday, 20 December 2016 at 16:53:21 UTC, Stefan Koch wrote: I hope that my reports give a little insight into what issues I am facing, and why it is taking so long. There's a left parenthesis too much on line 3320 in ctfe_bc.d ;) You're right. I was sleepy when committing that, so I forgot to check if it compiles. It had flags to allow stack pointers for integers to make slice handling cheaper in the interpreter, but it turns out that this decision hurt performance overall, and now I am removing it. This unmatched paren was part of the i32Ptr check :)
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On Tuesday, 20 December 2016 at 20:51:54 UTC, Andrei Alexandrescu wrote: I've asked Joakim about this via email just now, likely other folks also know the answer: 1. I found these PRs related to local imports: https://github.com/dlang/phobos/pull/4361 https://github.com/dlang/phobos/pull/4365 https://github.com/dlang/phobos/pull/4370 https://github.com/dlang/phobos/pull/4373 https://github.com/dlang/phobos/pull/4379 https://github.com/dlang/phobos/pull/4392 https://github.com/dlang/phobos/pull/4467 Are there more? Is there a central point for them (such as a bugzilla issue)? Ilya lists a lot more above, he did most of the work. No central point that I know of. 2. I see you've done a bunch of work in the area. Where, in your estimate, are we on the spectrum of making imports local without a major reorganization? Any low-hanging fruit to look at, or have Joakim, Ilya, Jack and others made a pass through most/all modules already? There is more to be done, but my guess would be 80-90% done for Phobos. Ilya scoped a lot, but usually left druntime imports alone. Top-level module imports mostly don't use selective imports yet, because Martin wanted to hold off till he was sure the symbol leak bug was fixed. On Tuesday, 20 December 2016 at 22:08:38 UTC, Andrei Alexandrescu wrote: On 12/20/2016 03:46 AM, Joakim wrote: I didn't just say "eh:" I gave evidence for why I think the problem is minimal and asked why it's so important to scope those last 3-4 imported modules too, which you didn't answer. You have asked for a smoking gun, and one has been found. I have just uploaded a major update that carefully analyzes the improvements brought about by switching to local imports in the D Standard Library. Please refer to the section "Workaround: Are Local Imports Good Enough?" and Appendix A: https://github.com/dlang/DIPs/pull/51/files https://github.com/dlang/DIPs/blob/91baecedcfe7cb75ac22e66478722ec797ebb901/DIPs/DIP1005.md Thanks for this analysis of the remaining dependency graph, it is worth looking at. Allow me to poke some holes in it. To begin with, the amount of scoping that has been done is overstated, if you simply count scoped imports and compare it to module-level imports. Each module-level import has to be replicated multiple times for each local scope, especially in unittest blocks. A better number is more like 20-30%, as I pointed out 4 out of 13 modules remain at top-level in std.array. Using that metric, a 3-4X reduction in top-level imports has led to at least a 2.2x improvement in imported files, so the effort has been more meaningful than you conclude. Second, as I noted above, most top-level imports have not been made selective yet, because of the symbol leak bug that was recently fixed by Martin. You will see in my PRs that I only list those symbols as a comment, because I could not turn those into selective imports yet. If the compiler is doing its job right, selective imports should greatly reduce the cost of importing a module, even if your metric would still show the module being imported. Third, checking some of the output from the commands you ran in your script shows that up to half of the imported modules are from druntime. I noted earlier that Ilya usually didn't bother scoping top-level druntime imports, because he perceived their cost to be low (I scoped them too in the handful I cleaned up, just for completeness). As far as I know, nobody has bothered to spend any time scoping druntime, so it would be better if you filtered out druntime imports from your analysis. Finally, while it's nice to know the extent of the dependency graph, what really matters is the _cost_ of each link of the graph, which is what I keep hammering on. If the cost of links is small, it doesn't matter how entangled it is. If minimizing the dependency graph through scoping alone, ie without implementing this DIP, removes most of the cost, that's all I care about. I have noted one example above, where _a single DCD in phobos_, ie a scoped, selective import, had gigantic costs in terms of executable size, where entire modules were included because of it. If that's the case more generally, then _no_ amount of dependency disentangling will matter, because the cost of single DCDs is still huge. Perhaps that's just an isolated issue however, it needs to be investigated. My point is that the dependency graph matters, but now that we're getting down to the last entanglements, we need to know the cost of those last links. Your dependency analysis gives us some quantitative idea of the size of the remaining graph, but tells us nothing about the cost of those links. That's what I'm looking for. I will spend some time now investigating those costs with sample code. My request all along has been that you give us some idea of those costs, if you know the answer already.
Re: Improvement in pure functions specification
On Wednesday, 21 December 2016 at 02:27:02 UTC, Andrei Alexandrescu wrote: If it's elidable, it's as good as a bug in the program. Must be either a compile-time error or a special case. -- Andrei I can't see it ending well to make it this kind of special case. For example, one day someone will take one of these not-really-pure-by-any-definition-but-labelled-pure-for-some-reason-and-treated-as-a-special-case functions and make it return, I don't know, an int, and then be surprised that the compiler now elides the function call. If users rely on this special case behaviour, eventually someone will need a way to make a "pure"-with-side-effects function return values without being treated like a pure function. On the other hand, making it a compilation error might get in the way of generic programming, so that's worth considering.
Re: Improvement in pure functions specification
On 12/20/16 8:54 PM, H. S. Teoh via Digitalmars-d wrote: On Tue, Dec 20, 2016 at 08:16:36PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: On 12/20/16 8:02 PM, H. S. Teoh via Digitalmars-d wrote: Isn't that impure by definition?! How can tracing execution even be remotely considered pure? That's why the compiler is required compulsively to call it. -- Andrei I don't follow. The question was how can a function with side-effects (even given D's relaxed definition of pure, i.e., allowing mutation via arguments) can be considered pure. What has that got to do with the compiler being required to call it? I'd say a pure void function should be equivalent to no-op and elidable. If it's elidable, it's as good as a bug in the program. Must be either a compile-time error or a special case. -- Andrei
Re: Improvement in pure functions specification
On Tue, Dec 20, 2016 at 08:16:36PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 12/20/16 8:02 PM, H. S. Teoh via Digitalmars-d wrote:
> > Isn't that impure by definition?! How can tracing execution even be
> > remotely considered pure?
>
> That's why the compiler is required compulsively to call it. -- Andrei
I don't follow.
The question was how can a function with side-effects (even given D's
relaxed definition of pure, i.e., allowing mutation via arguments) can
be considered pure. What has that got to do with the compiler being
required to call it?
I'd say a pure void function should be equivalent to no-op and elidable.
If you want to call a function with side-effects from pure code for
debugging purposes, call it via the debug statement, e.g.:
void impureDebugger(...) { ... } // N.B.: NOT pure
pure void noop() {}
pure auto pureFunc(A...)(A args) {
...
noop(); // may be elided
...
debug impureDebugger(1,2,3); // won't be elided
...
}
I don't see any good reason why we should bend the definition of pure to
allow pure void functions with side effects.
T
--
Beware of bugs in the above code; I have only proved it correct, not tried it.
-- Donald Knuth
Re: Improvement in pure functions specification
On 12/20/16 8:02 PM, H. S. Teoh via Digitalmars-d wrote: Isn't that impure by definition?! How can tracing execution even be remotely considered pure? That's why the compiler is required compulsively to call it. -- Andrei
Re: Improvement in pure functions specification
On 12/20/16 8:10 PM, Meta wrote: The compiler will have to be changed for this part. Currently it's a warning (or maybe it was an error, can't remember) to call a strongly pure function returning void without doing `cast(void)fun()`. Interesting. As soon as the spec change is merged, we get to file an issue :o). -- Andrei
Re: Improvement in pure functions specification
On Wednesday, 21 December 2016 at 00:58:38 UTC, Andrei Alexandrescu wrote: On 12/20/16 7:40 PM, Timon Gehr wrote: On 20.12.2016 23:49, Andrei Alexandrescu wrote: https://github.com/dlang/dlang.org/pull/1528 -- Andrei Good, except: "$(P `pure` functions returning `void` will be always called even if it is strongly `pure`. The implementation must assume the function does something outside the confines of the type system and is therefore not allowed to elide the call, even if it appears to have no possible effect.)" I think this makes no sense. What is the idea behind this paragraph? A function that traces execution via a debug statement, for example. -- Andrei The compiler will have to be changed for this part. Currently it's a warning (or maybe it was an error, can't remember) to call a strongly pure function returning void without doing `cast(void)fun()`.
Re: Improvement in pure functions specification
On Tue, Dec 20, 2016 at 07:58:38PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: > On 12/20/16 7:40 PM, Timon Gehr wrote: > > On 20.12.2016 23:49, Andrei Alexandrescu wrote: > > > https://github.com/dlang/dlang.org/pull/1528 -- Andrei > > > > Good, except: > > > > "$(P `pure` functions returning `void` will be always called even if > > it is strongly `pure`. The implementation must assume the function > > does something outside the confines of the type system and is > > therefore not allowed to elide the call, even if it appears to have > > no possible effect.)" > > > > I think this makes no sense. What is the idea behind this paragraph? > > A function that traces execution via a debug statement, for example. > -- Andrei Isn't that impure by definition?! How can tracing execution even be remotely considered pure? I understand that debug statements are a kind of backdoor to facilitate debugging... but still. I'd expect we wouldn't bend the definition of pure just for the sake of debugging -- that just sounds backwards. If a function has side-effects outside of what's passed as arguments, I can't see any way of justifying it being marked as pure. T -- They pretend to pay us, and we pretend to work. -- Russian saying
Re: Improvement in pure functions specification
On Tuesday, December 20, 2016 19:58:38 Andrei Alexandrescu via Digitalmars-d wrote: > On 12/20/16 7:40 PM, Timon Gehr wrote: > > On 20.12.2016 23:49, Andrei Alexandrescu wrote: > >> https://github.com/dlang/dlang.org/pull/1528 -- Andrei > > > > Good, except: > > > > "$(P `pure` functions returning `void` will be always called even if it > > is strongly `pure`. The implementation must assume the function does > > something outside the confines of the type system and is therefore not > > allowed to elide the call, even if it appears to have no possible > > effect.)" > > > > I think this makes no sense. What is the idea behind this paragraph? > > A function that traces execution via a debug statement, for example. -- > Andrei Well, ultimately, strongly pure functions that return void are either doing something that works around the type system (e.g. using debug statements to do operations which aren't pure), or they arguably shouldn't even compile, because they can't possibly do anything that has any effect on the program beyond eating up CPU time. So, as far as I can tell, we should either make an exception for them (as the PR currently does) or make them illegal. - Jonathan M Davis
Re: Improvement in pure functions specification
On 12/20/16 7:40 PM, Timon Gehr wrote: On 20.12.2016 23:49, Andrei Alexandrescu wrote: https://github.com/dlang/dlang.org/pull/1528 -- Andrei Good, except: "$(P `pure` functions returning `void` will be always called even if it is strongly `pure`. The implementation must assume the function does something outside the confines of the type system and is therefore not allowed to elide the call, even if it appears to have no possible effect.)" I think this makes no sense. What is the idea behind this paragraph? A function that traces execution via a debug statement, for example. -- Andrei
Re: Improvement in pure functions specification
On 20.12.2016 23:49, Andrei Alexandrescu wrote: https://github.com/dlang/dlang.org/pull/1528 -- Andrei Good, except: "$(P `pure` functions returning `void` will be always called even if it is strongly `pure`. The implementation must assume the function does something outside the confines of the type system and is therefore not allowed to elide the call, even if it appears to have no possible effect.)" I think this makes no sense. What is the idea behind this paragraph?
Re: Red Hat's issues in considering the D language
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b Thanks, Andrei It's always the same thing, isn't it ? DMD isn't free software (as non redistribuable), poor integration with existing tools and file format (here deps files, but generally almost everything use its own format rather than industry standard), non standard command line flags/syntax, and unittest are kind of weird.
Re: Red Hat's issues in considering the D language
On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b Pretty cool. One of the DUB issues is: There is no default "release-build-with-debug-symbols" target. Seems like a documentation bug, because: dub -b release-debug does exist. Now: https://github.com/dlang/dub/issues/1025
Red Hat's issues in considering the D language
Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well. https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b Thanks, Andrei
Improvement in pure functions specification
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On 12/20/2016 05:08 PM, Andrei Alexandrescu wrote: On 12/20/2016 03:46 AM, Joakim wrote: I didn't just say "eh:" I gave evidence for why I think the problem is minimal and asked why it's so important to scope those last 3-4 imported modules too, which you didn't answer. You have asked for a smoking gun, and one has been found. I have just uploaded a major update that carefully analyzes the improvements brought about by switching to local imports in the D Standard Library. Please refer to the section "Workaround: Are Local Imports Good Enough?" and Appendix A: https://github.com/dlang/DIPs/pull/51/files https://github.com/dlang/DIPs/blob/91baecedcfe7cb75ac22e66478722ec797ebb901/DIPs/DIP1005.md Eh, looks like http://dillinger.io/ and github don't agree on table rendering... Fixed URL for nice viewing: https://github.com/dlang/DIPs/blob/249b28ddd784220e44e343e78e5ea7a65c4c7bde/DIPs/DIP1005.md Andrei
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On 12/20/2016 05:08 PM, Andrei Alexandrescu wrote: On 12/20/2016 03:46 AM, Joakim wrote: I didn't just say "eh:" I gave evidence for why I think the problem is minimal and asked why it's so important to scope those last 3-4 imported modules too, which you didn't answer. You have asked for a smoking gun, and one has been found. I have just uploaded a major update that carefully analyzes the improvements brought about by switching to local imports in the D Standard Library. Please refer to the section "Workaround: Are Local Imports Good Enough?" and Appendix A: https://github.com/dlang/DIPs/pull/51/files https://github.com/dlang/DIPs/blob/91baecedcfe7cb75ac22e66478722ec797ebb901/DIPs/DIP1005.md I've also added a supporting script that creates the table in Appendix A: https://github.com/andralex/DIPs/blob/9e9ebc8738ce04b2d85a92feafacc7ef81e59811/DIPs/DIP1005-countlines.zsh -- Andrei
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On 12/20/2016 03:46 AM, Joakim wrote: I didn't just say "eh:" I gave evidence for why I think the problem is minimal and asked why it's so important to scope those last 3-4 imported modules too, which you didn't answer. You have asked for a smoking gun, and one has been found. I have just uploaded a major update that carefully analyzes the improvements brought about by switching to local imports in the D Standard Library. Please refer to the section "Workaround: Are Local Imports Good Enough?" and Appendix A: https://github.com/dlang/DIPs/pull/51/files https://github.com/dlang/DIPs/blob/91baecedcfe7cb75ac22e66478722ec797ebb901/DIPs/DIP1005.md Andrei
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On 19.12.2016 06:31, deadalnix wrote: On Sunday, 18 December 2016 at 23:18:27 UTC, Andrei Alexandrescu wrote: Great, thanks. Please take a look at the accuracy of the discussion. I expanded the "Workaround" section and moved it near the top. https://github.com/dlang/DIPs/pull/51 https://github.com/dlang/DIPs/blob/dd46252e820dce66df746540d7ab94e0b00a6505/DIPs/DIP1005.md Andrei What's wrong with the parentheseless version ? The DIP says it looks "out of place" but that doesn't strike me as a very good argument. IMO the version without ";" is the way to go, as it doesn't require to add a new syntax for imports. Identical things looking identical is valuable. +1.
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On Tuesday, 20 December 2016 at 20:51:54 UTC, Andrei Alexandrescu wrote: I've asked Joakim about this via email just now, likely other folks also know the answer: 1. I found these PRs related to local imports: https://github.com/dlang/phobos/pull/4361 https://github.com/dlang/phobos/pull/4365 https://github.com/dlang/phobos/pull/4370 https://github.com/dlang/phobos/pull/4373 https://github.com/dlang/phobos/pull/4379 https://github.com/dlang/phobos/pull/4392 https://github.com/dlang/phobos/pull/4467 Are there more? Is there a central point for them (such as a bugzilla issue)? 2. I see you've done a bunch of work in the area. Where, in your estimate, are we on the spectrum of making imports local without a major reorganization? Any low-hanging fruit to look at, or have Joakim, Ilya, Jack and others made a pass through most/all modules already? Thanks! This is 95% of my PRs for local imports. Few of them moves codes between files. https://github.com/dlang/phobos/pull/2658 https://github.com/dlang/phobos/pull/2659 https://github.com/dlang/phobos/pull/2661 https://github.com/dlang/phobos/pull/2665 https://github.com/dlang/phobos/pull/2666 https://github.com/dlang/phobos/pull/2667 https://github.com/dlang/phobos/pull/2669 https://github.com/dlang/phobos/pull/2670 https://github.com/dlang/phobos/pull/2671 https://github.com/dlang/phobos/pull/2672 https://github.com/dlang/phobos/pull/2673 https://github.com/dlang/phobos/pull/2675 https://github.com/dlang/phobos/pull/2678 https://github.com/dlang/phobos/pull/2679 https://github.com/dlang/phobos/pull/2680 https://github.com/dlang/phobos/pull/2681 https://github.com/dlang/phobos/pull/2686 https://github.com/dlang/phobos/pull/2691 https://github.com/dlang/phobos/pull/2694 https://github.com/dlang/phobos/pull/2695 https://github.com/dlang/phobos/pull/2696 https://github.com/dlang/phobos/pull/2705 https://github.com/dlang/phobos/pull/2706 https://github.com/dlang/phobos/pull/2707 https://github.com/dlang/phobos/pull/2708 https://github.com/dlang/phobos/pull/2709 https://github.com/dlang/phobos/pull/2710 https://github.com/dlang/phobos/pull/2711 https://github.com/dlang/phobos/pull/2712 https://github.com/dlang/phobos/pull/2713 https://github.com/dlang/phobos/pull/2714 https://github.com/dlang/phobos/pull/2715 https://github.com/dlang/phobos/pull/2716 https://github.com/dlang/phobos/pull/2717 https://github.com/dlang/phobos/pull/2718 https://github.com/dlang/phobos/pull/2719 https://github.com/dlang/phobos/pull/2720 https://github.com/dlang/phobos/pull/2721 https://github.com/dlang/phobos/pull/2722 https://github.com/dlang/phobos/pull/2725 https://github.com/dlang/phobos/pull/2726 https://github.com/dlang/phobos/pull/2727 https://github.com/dlang/phobos/pull/2728 https://github.com/dlang/phobos/pull/2729 https://github.com/dlang/phobos/pull/2754 https://github.com/dlang/phobos/pull/2755 Ilya
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
I've asked Joakim about this via email just now, likely other folks also know the answer: 1. I found these PRs related to local imports: https://github.com/dlang/phobos/pull/4361 https://github.com/dlang/phobos/pull/4365 https://github.com/dlang/phobos/pull/4370 https://github.com/dlang/phobos/pull/4373 https://github.com/dlang/phobos/pull/4379 https://github.com/dlang/phobos/pull/4392 https://github.com/dlang/phobos/pull/4467 Are there more? Is there a central point for them (such as a bugzilla issue)? 2. I see you've done a bunch of work in the area. Where, in your estimate, are we on the spectrum of making imports local without a major reorganization? Any low-hanging fruit to look at, or have Joakim, Ilya, Jack and others made a pass through most/all modules already? Thanks!
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On 12/20/2016 09:31 AM, Dmitry Olshansky wrote: On 12/13/16 11:33 PM, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei Just a thought but with all of proliferation of imports down to each declaration comes the pain that e.g. renaming a module cascades to countless instances of import statements. This is true of local imports as well but the problem gets bigger. Good point, I'll integrate it in the document. -- Andrei
Re: ModuleInfo, factories, and unittesting
On 12/20/2016 11:05 AM, Dicebot wrote: Yes, pretty much. What ways do you have in mind? I am only aware of two: 1) ModuleInfo 2) https://dlang.org/spec/traits.html#getUnitTests Put pointers to them in a special segment.
Re: CTFE Status
On Tuesday, 20 December 2016 at 16:53:21 UTC, Stefan Koch wrote: I hope that my reports give a little insight into what issues I am facing, and why it is taking so long. There's a left parenthesis too much on line 3320 in ctfe_bc.d ;)
Re: D future ...
On Tuesday, 20 December 2016 at 08:20:32 UTC, LiNbO3 wrote: On Tuesday, 20 December 2016 at 06:42:10 UTC, lobo wrote: On Tuesday, 20 December 2016 at 04:38:03 UTC, Jerry wrote: On Tuesday, 20 December 2016 at 04:14:33 UTC, Andrei Alexandrescu wrote: On 12/19/2016 11:12 PM, Andrei Alexandrescu wrote: [...] https://issues.dlang.org/show_bug.cgi?id=16991 Another issue onto the list of thousands, to collect dust for the next few years til someone decides they want to use their personal time to fix it. Just to highlight another problem, there's a lot of trivial to fix issues. Just maintenance really, like that one you posted. But there is no one going through fixing them. Well that one might end up getting fixed cause of the extra exposure. Maybe you could fix one or two? As you say they're trivial and apparently no one else is doing it. bye, lobo And have the patch wait in the PR queue until the end of time, not even acknowledged at all ? The lack of focus goes hand in hand with the lack of manpower with some not-so-great results like we're seeing right now, at least IMO. The perceived lack of focus is another matter, which I agree is disconcerting. I say perceived because I'm sure there is focus and a plan but it isn't visible from the outside. The core dev team seem to jump from one thing to the next with nothing going pushed thought the last 10% to completion so it all feels 90% complete. bye, lobo
Re: CTFE Status
On Tuesday, 20 December 2016 at 16:53:21 UTC, Stefan Koch wrote: On a different note. Thanks for your continued moral support. It is nice to know that my work is eagerly awaited by people. As always I am sorry for the long time it takes. I hope that my reports give a little insight into what issues I am facing, and why it is taking so long. I find it all very interesting. Keep up the good work.
Re: D future ...
On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote: I split this from the "Re: A betterC modular standard library?" topic because my response is will be too much off-topic but the whole thread is irking me the wrong way. I see some of the same argument coming up all the time, with a level of frequency. D has not market: - It has market, a broad one. Just like C++, depends on your use case. Go: Its is a "simple" language. People are swayed by popular stuff. D is C++ but improved/simplified. Its not to hard to get into, its more easy for anybody from a C background. True. Every guy I showed says that. But setting up development environment for D is not a straight forward thing (Undocumented stuff, huge blocker for new users). Take it from a guy that spend a large part of his life in PHP. I feel more at home with D, then with all the other languages. The moment you get over a few hurdles, it becomes a very easy language. My point is that D does fit in a specific market. It fits in between C++ and scripting languages like PHP ( that has a more C background ). IMO Walter/Andrea cannot do much about these stuff. "Car engineers are not the best riders". Its not going to convert a lot of C++ people. Sorry but its true. C++ has been evolving, the people who invested into C++ have very little advantage of going to D. The whole focus on C++ people marketing is simply wrong! Every time this gets mentioned in external forums, the language gets a pounding by people with the same argumentation. Why go for D when C++ 20xx version does it also. Because most people here are working on proprietary/production code that has something to do with C/C++ or they were much into them before D. Requests/complains here are *mostly* either selfish or are assumptions on what they think will make D shine (of course, from their own head). Community: -- But it feels like everybody is doing there own thing. IMO, they do what will help their own workflow (what they get paid for). It makes sense. However, the number of potentially helpful Dub packages is growing. But the incomplete/I-came-with-this-during-a-project packages are problematic. They are usually not well documented and do not tackle more use cases. This is bad for the ecosystem. They should be marked as incomplete/not-to-be-inproved I see a lot of people arguing a lot about D and sorry to say I think people argue on things they care about, directly or indirectly. I do too ;) Its good, as long as it's not selfish. Documentation: -- Documentation is a really hard/time consuming task to do. Unless we have a lot of hands on deck. I do not use it. Its such a mess to read with long paragraphs and a LOT of stuff not even documented. Like the whole C wrappers etc. My personal bible is simple: Google search for examples and Ali's book for some rare cases. Yeah. Difficult to see this issue if you are too/very technical. Editor support: --- Will help to specify what exactly is missing (linting?, easy debugging?). Future: You want D to have traction. My little experience tells me the future is attributed to SO MANY factors. Walter / Andrei: Hire Steve Jobs End Rant: - GC is not a blocker for me. Most people complain about GC in D but thats for their use case. Don't speak for everyone or say D will NEVER gain traction (its only in your head). Marketing Suggestion Go for startups/students/newbies. So many startups are establish everyday. They don't have huge C/C++ code base.
Re: CTFE Status
On Tuesday, 20 December 2016 at 16:53:21 UTC, Stefan Koch wrote: At this point it might take another month until function calls are working. I admire your endurance.
Re: D future ...
On Tuesday, 20 December 2016 at 19:15:37 UTC, Chris M. wrote: On Tuesday, 20 December 2016 at 19:11:11 UTC, Chris M. wrote: Seb just made a giant post listing all the things that could be done to help improve D, that could to be pinned somewhere so that everyone can see it. Maybe something like that should be made every time a new high-level vision is made, so that people know where and how they can focus their efforts. Well, maybe not so giant Wish posts could be edited Remember that this is not a forum, it's a NG interface. Edition would mean that the email received could be potentially invalid and conversation would become confuse. If you're too ashamed by your errors, post an erratum...
Re: Multiple return value as requirements for safety and performance
On 20.12.2016 14:47, Ilya Yaroshenko wrote:
One good thing for safety and CTFE is allow multiple return value. In
combination with `auto ref` it is _very_ powerful:
auto ref front()
{
// Returns 2 values, each value is returned by reference if possible
return (a.front, b.front);
}
...
There is already syntax for something similar to this (for the
auto-expanding version).
auto ref seq(T...)(return auto ref T args){
return args;
}
auto ref front(){
return seq(a.front, b.front);
}
However, DMD will reject this at the moment.
Mir libs will use pointers for now. This is one of reasons why `zip` is
slow.
The new feature also significantly extends std.range and std.algorithm
functionality.
This thread was forked from
http://forum.dlang.org/post/acdwfbirvoxzrsfyl...@forum.dlang.org
I am not good in DIPs and hope someone is interested in this feature too
This will likely be added as soon as the comma operator has finished its
deprecation cycle. (I might give this a shot after finally polishing the
static foreach DIP.)
Re: D future ...
On Tuesday, 20 December 2016 at 19:11:11 UTC, Chris M. wrote: Seb just made a giant post listing all the things that could be done to help improve D, that could to be pinned somewhere so that everyone can see it. Maybe something like that should be made every time a new high-level vision is made, so that people know where and how they can focus their efforts. Well, maybe not so giant Wish posts could be edited
Re: D future ...
On Tuesday, 20 December 2016 at 18:01:23 UTC, jmh530 wrote: It's a fair point, but people only know that all these rants have come up a million times if they've been following the newsgroup for a while. It's the kind of thing where most forums have a read me that says something like, yes we already know about all these things and thread about them are considered spam. Seb just made a giant post listing all the things that could be done to help improve D, that could to be pinned somewhere so that everyone can see it. Maybe something like that should be made every time a new high-level vision is made, so that people know where and how they can focus their efforts.
Re: ModuleInfo, factories, and unittesting
On 12/20/2016 08:33 PM, Walter Bright wrote: > On 12/20/2016 12:01 AM, Dicebot wrote: >> We rely on ModuleInfo for custom test runner in ocean >> (https://github.com/sociomantic-tsunami/ocean/blob/v2.x.x/src/ocean/core/UnitTestRunner.d). >> >> Static introspection can't provide same functionality in general case >> (even if all bugs will be fixed) because it requires either maintaining >> list of all modules or ensuring everything is imported from some root >> module. Former is inconvenience, latter is simply not true for libraries >> (though can be worked around by build system). > > Does that simply need to find all the unit tests? (There are ways to do > that without ModuleInfo, it's just that it's convenient and portable > with ModuleInfo.) Yes, pretty much. What ways do you have in mind? I am only aware of two: 1) ModuleInfo 2) https://dlang.org/spec/traits.html#getUnitTests signature.asc Description: OpenPGP digital signature
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 15:47:38 UTC, Nordlöw wrote: On Tuesday, 20 December 2016 at 15:40:57 UTC, Nordlöw wrote: DIP-32 has been dormant since 2013. I've been waiting for builtin tuples ever since I started using D. I wonder if it might be possible to add the tuple syntax incrementally into DMD? It's always easier to approve something less complex. Could the comma expression be contextually removed? Specifically in return expressions as discussed initially in this post? Back in May a change was introduced to issue a deprecation message for uses of the comma operator outside of a for statement. Not sure which dmd version it got introduced into but it's surely in there by now. https://github.com/dlang/dmd/pull/5737
Re: ModuleInfo, factories, and unittesting
On 12/20/2016 01:15 PM, Atila Neves wrote: On Monday, 19 December 2016 at 18:29:13 UTC, Andrei Alexandrescu wrote: On 12/19/16 12:25 PM, Atila Neves wrote: On Monday, 19 December 2016 at 17:11:38 UTC, Adam D. Ruppe wrote: [...] I'd forgotten about separate compilation. The issue there is the algorithm for naming unittest blocks gives different results depending on how the code is compiled, so __traits(getUnitTests) unfortunately currently only works with "compile all the things!". I'd forgotten I wanted to change the compiler code responsible for the naming. Interesting, could you please add a detailed issue to bugzilla? Thanks! -- Andrei https://issues.dlang.org/show_bug.cgi?id=16995 Gracias! -- Andrei
Re: ModuleInfo, factories, and unittesting
On 12/20/2016 12:01 AM, Dicebot wrote: We rely on ModuleInfo for custom test runner in ocean (https://github.com/sociomantic-tsunami/ocean/blob/v2.x.x/src/ocean/core/UnitTestRunner.d). Static introspection can't provide same functionality in general case (even if all bugs will be fixed) because it requires either maintaining list of all modules or ensuring everything is imported from some root module. Former is inconvenience, latter is simply not true for libraries (though can be worked around by build system). Does that simply need to find all the unit tests? (There are ways to do that without ModuleInfo, it's just that it's convenient and portable with ModuleInfo.)
Re: ModuleInfo, factories, and unittesting
On Monday, 19 December 2016 at 18:29:13 UTC, Andrei Alexandrescu wrote: On 12/19/16 12:25 PM, Atila Neves wrote: On Monday, 19 December 2016 at 17:11:38 UTC, Adam D. Ruppe wrote: [...] I'd forgotten about separate compilation. The issue there is the algorithm for naming unittest blocks gives different results depending on how the code is compiled, so __traits(getUnitTests) unfortunately currently only works with "compile all the things!". I'd forgotten I wanted to change the compiler code responsible for the naming. Interesting, could you please add a detailed issue to bugzilla? Thanks! -- Andrei https://issues.dlang.org/show_bug.cgi?id=16995 Atila
Re: D future ...
On Tuesday, 20 December 2016 at 15:44:03 UTC, Dicebot wrote: I am really tired of this recurring bullshit of random guys coming up and acting as if they have any right to demand anything. You distract those few that are willing to do the work from focusing on it, you are not capable of saying anything not widely known and you have no desire to contribute yourself. My opinion? Fuck off. It's a fair point, but people only know that all these rants have come up a million times if they've been following the newsgroup for a while. It's the kind of thing where most forums have a read me that says something like, yes we already know about all these things and thread about them are considered spam.
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On Tuesday, 20 December 2016 at 01:06:01 UTC, Andrei Alexandrescu wrote: Pushed again, now with the syntax using "with" proposed by Hatem Oraby and others. https://github.com/dlang/DIPs/pull/51 https://github.com/dlang/DIPs/blob/71bde077488b566fba7603de6095b45984d9294a/DIPs/DIP1005.md Andrei "In addition, we propose the statement and declaration with (import ImportList). ImportList is any syntactical construct currently accepted by the import declaration. The with (import ImportList) obeys the following rules: - Inside any function, with (Import ImportList) is a statement that introduces a scope. Inside the with, lookup considers the import local to the declaration (similar to the current handling of nested imports). - Everywhere else, with (Import ImportList) is always a declaration and does not introduce a new scope. Lookup of symbols is the same as for the statement case." I must've somehow missed this when reading through for the first time after your changes as I thought this was a glaring omission. Glad to see that this was covered as this rightly makes it turtles all the way down. Actually, you could completely replace import statements with this new construct, having the `import std.range` at the top level replaced with a module-wide attribute `with (import std.range):`. In that light my only real criticism is that it's kind of redundant having both this new form *and* local imports, and it's not clear which is better and why to a new user.
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On Tuesday, 20 December 2016 at 14:31:38 UTC, Dmitry Olshansky wrote: On 12/13/16 11:33 PM, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei Just a thought but with all of proliferation of imports down to each declaration comes the pain that e.g. renaming a module cascades to countless instances of import statements. This is true of local imports as well but the problem gets bigger. Dmitry Olshansky Could you not have the old module just be empty and publicly import the new one, and also deprecate it so people have time to change their code? Also having special syntax makes finding every occurrence of an inline import a fairly simple search.
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 17:28:49 UTC, Stefan Koch wrote: On Tuesday, 20 December 2016 at 17:15:53 UTC, Ilya Yaroshenko wrote: Are they already CTFEable? I have not seen an anounce, sorry They have been for years now. Of course only pointers from a CTFE context are valid at ctfe. The new engine will support them as well, (as it will eventually support everything with the exception of 80bit reals) Thanks! Sorry for the noise!
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 17:15:53 UTC, Ilya Yaroshenko wrote: Are they already CTFEable? I have not seen an anounce, sorry They have been for years now. Of course only pointers from a CTFE context are valid at ctfe. The new engine will support them as well, (as it will eventually support everything with the exception of 80bit reals)
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 17:05:03 UTC, Stefan Koch wrote: On Tuesday, 20 December 2016 at 16:57:34 UTC, Ilya Yaroshenko wrote: On Tuesday, 20 December 2016 at 16:34:04 UTC, Walter Bright wrote: On 12/20/2016 6:08 AM, Ilya Yaroshenko wrote: No, tuples stores either value or pointer. If it stores pointer then it is not safe and it is not CTFE. You can make it safe by using an array rather than a pointer. Ranges a and b may not be arrays. They just have Range API and return front by reference.How this can be handled for CTFE, safe code? Would the solution be fast? What are you even talking about ? Making a Tuple is fine. Pointers can also be perfectly safe and CTFEable if you do not Are they already CTFEable? I have not seen an anounce, sorry
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 16:57:34 UTC, Ilya Yaroshenko wrote: On Tuesday, 20 December 2016 at 16:34:04 UTC, Walter Bright wrote: On 12/20/2016 6:08 AM, Ilya Yaroshenko wrote: No, tuples stores either value or pointer. If it stores pointer then it is not safe and it is not CTFE. You can make it safe by using an array rather than a pointer. Ranges a and b may not be arrays. They just have Range API and return front by reference.How this can be handled for CTFE, safe code? Would the solution be fast? What are you even talking about ? Making a Tuple is fine. Pointers can also be perfectly safe and CTFEable if you do not try to mess with them. For a Range you have to pass some form of context regardless so there will always be a quite small price to be payed. -- Performance is not something you just get. Work is required if you want good performance and no library or language is going to change that.
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 16:34:04 UTC, Walter Bright wrote: On 12/20/2016 6:08 AM, Ilya Yaroshenko wrote: No, tuples stores either value or pointer. If it stores pointer then it is not safe and it is not CTFE. You can make it safe by using an array rather than a pointer. Ranges a and b may not be arrays. They just have Range API and return front by reference.How this can be handled for CTFE, safe code? Would the solution be fast?
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 15:42:52 UTC, Ilya Yaroshenko
wrote:
This thread is about mutiple values returned by _reference_.
Tuples can not do it, only pointers, but they are not ctfeable
and safe
The way to make this useful, if I'm understanding correctly,
would not be a more concise way to express `return tuple(a, b);`
where `tuple` is the function defined in typecons, but to make
expressions like `return tuple(a, b).expand;` become valid and
using a syntax like `return (a, b);` to represent them. (For
which I would suggest also making the parentheses optional, but
that's minutiae.)
The syntax for assigning the returned values would likely not
look like `auto x = {return (a, b);}(); assert(x[0] == a);`. This
because `x` would not be a tuple in the sense of
std.typecons.Tuple, but a tuple in the sense of what you get when
you `expand` such a type. The assignment syntax should be more
like `auto x, y = {return (a, b);}(); assert(x == a);`. Where the
intent is to store the two values in the same variable, I expect
a struct like Tuple should continue to be used.
And because in these examples `a` and `b` would not be members of
a tuple struct, it would become possible to return some or all of
them by reference, as can currently be done for a single returned
value.
Re: CTFE Status
Hey Guys I wanted to give a quick update. I recently fixed an interesting bug that happened de-referencing null pointers to the heap. That would cause arrays to be overwritten, when passed as arguments. That bug had me stuck for a few hours. Getting Function-Calls right will be impossible, if the ABI issues remain. Currently it's about the handling of pointers. My architecture forbids pointers to the stack, therefore every time you take the address of something it needs to be pushed onto the heap. And then the heap-value and the stack-value needs to be kept in sync with each other. This is rather complicated, so it will take a while to get right. At this point it might take another month until function calls are working. -- On a different note. Thanks for your continued moral support. It is nice to know that my work is eagerly awaited by people. As always I am sorry for the long time it takes. I hope that my reports give a little insight into what issues I am facing, and why it is taking so long.
Re: Multiple return value as requirements for safety and performance
On 12/20/2016 6:08 AM, Ilya Yaroshenko wrote: No, tuples stores either value or pointer. If it stores pointer then it is not safe and it is not CTFE. You can make it safe by using an array rather than a pointer.
Re: D future ...
On 12/20/2016 7:44 AM, bachmeier wrote: On Tuesday, 20 December 2016 at 11:52:05 UTC, Walter Bright wrote: If you don't want to fix anything, ok. But you can still file bugzilla issues for things that you find. This is a valid point. I just did that for some std.datetime functions that need improved documentation. Thank you. Many people look for things to help with, and this makes it easy for us to direct them to bugzilla to look for something they can do. It also helps ensure that issues don't scroll away on the n.g. and get lost.
Re: D future ...
On 12/20/2016 7:17 AM, Benjiro wrote: I do not recall seeing on the C++ and other forums this constant attitude from fix it yourselves or put it in the libraries or ... Oh, it's certainly there. If you want to change C++ or the C++ Standard Library, you are told to submit a proposal paper to the C++ Committee, which is a quite formal and arduous process and takes years. There is no such thing as posting a complaint on comp.lang.c++ and legions of people jump in to take care of it for you. D is quite a bit less formal, but still, if you want action consider that you aren't going to get it with any organization unless you're willing to: 1. pay others to do it 2. convince others that your important issues are more important than everyone else's important issues that they are already working on 3. put some effort into it yourself This includes C, C++, Java, Go, Rust, basically every language in existence. --- Note that pretty much every day in the D forums, people post lists of their most important issues they want other people to work on. And the lists are always different. When people invest time into solving the problems they complain about, that's evidence that those issues are more important. It's the same in C++ land - a common sentiment among the C++ stars is that if someone isn't willing to make an effort to write a proposal to the C++ Committee, it isn't an issue worth their time, either. It really can't be any other way.
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 16:06:49 UTC, Ilya Yaroshenko wrote: On Tuesday, 20 December 2016 at 15:50:03 UTC, Nordlöw wrote: On Tuesday, 20 December 2016 at 15:42:52 UTC, Ilya Yaroshenko wrote: This thread is about mutiple values returned by _reference_. Tuples can not do it, only pointers, but they are not ctfeable and safe Do pointers worsen performance aswell? Even when using LDC? Tuples of pointers are faster then tuples of values. Hypothetical tuples of references have the same performance as tuples of references. EDIT: as tuples of pointers.
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 15:50:03 UTC, Nordlöw wrote: On Tuesday, 20 December 2016 at 15:42:52 UTC, Ilya Yaroshenko wrote: This thread is about mutiple values returned by _reference_. Tuples can not do it, only pointers, but they are not ctfeable and safe Do pointers worsen performance aswell? Even when using LDC? Tuples of pointers are faster then tuples of values. Hypothetical tuples of references have the same performance as tuples of references.
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 15:40:57 UTC, Nordlöw wrote: DIP-32 has been dormant since 2013. I've been waiting for builtin tuples ever since I started using D. I wonder if it might be possible to add the tuple syntax incrementally into DMD? It's always easier to approve something less complex. Could the comma expression be contextually removed? Specifically in return expressions as discussed initially in this post?
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 15:42:52 UTC, Ilya Yaroshenko wrote: This thread is about mutiple values returned by _reference_. Tuples can not do it, only pointers, but they are not ctfeable and safe Do pointers worsen performance aswell? Even when using LDC?
Re: D future ...
On Tuesday, 20 December 2016 at 11:52:05 UTC, Walter Bright wrote: If you don't want to fix anything, ok. But you can still file bugzilla issues for things that you find. This is a valid point. I just did that for some std.datetime functions that need improved documentation.
Re: D future ...
On 12/20/2016 05:17 PM, Benjiro wrote: > On Tuesday, 20 December 2016 at 14:09:45 UTC, Dibyendu Majumdar wrote: >> >> Apologies for being one of those who offers advice but no action. > > Don't be Dibyendu ... > > We "ranters" are actually D's "client base". There seem to be the wrong > impression by the D-Team, that the "clients" are also the people who > need to help grow D. Just how much exactly are paying to D Foundation for support to call yourself a client? What are your support contract terms? > I do not recall seeing on the C++ and other forums this constant > attitude from fix it yourselves or put it in the libraries or ... Its > mostly on the smaller languages where they lack people. And at the same > time, that is a very scary though for companies who want to use a language. Yes, D is small language with no developers and no funds and C++ is huge one with enormous corporate involvement, enough to afford big crowd of free riders. Your point? > Anyway, enough "ranting" for me, back to work. I am really tired of this recurring bullshit of random guys coming up and acting as if they have any right to demand anything. You distract those few that are willing to do the work from focusing on it, you are not capable of saying anything not widely known and you have no desire to contribute yourself. My opinion? Fuck off. signature.asc Description: OpenPGP digital signature
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 15:36:27 UTC, jmh530 wrote:
On Tuesday, 20 December 2016 at 14:56:37 UTC, Ilya Yaroshenko
wrote:
As you can see the output should be 1000, but it is 1.
I was a little confused by what you meant, but the following
main is a little more obvious to me
void main()
{
auto c = front();
c[0] = 1000;
import std.stdio;
writeln(c[0]); //prints 1000
writeln(a[0]); //prints 1
}
c is value. You can modify it with tuples. Tuples can be returned.
This thread is about mutiple values returned by _reference_.
Tuples can not do it, only pointers, but they are not ctfeable
and safe
Re: D future ...
On Tuesday, 20 December 2016 at 15:17:56 UTC, Benjiro wrote: I do not recall seeing on the C++ and other forums this constant attitude from fix it yourselves or put it in the libraries or ... Its mostly on the smaller languages where they lack people. And at the same time, that is a very scary though for companies who want to use a language. I think it's important to be realistic. One of D's limitations is that it does not have the money of Microsoft or Intel behind it, and it does not have hundreds of billion-dollar corporations depending on it for critical business operations. Volunteer organizations will be run differently from outfits that have large budgets to pay people to do the ugly work. This is not an excuse, it is simply the current state of affairs.
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 13:47:50 UTC, Ilya Yaroshenko
wrote:
One good thing for safety and CTFE is allow multiple return
value. In combination with `auto ref` it is _very_ powerful:
auto ref front()
{
// Returns 2 values, each value is returned by reference if
possible
return (a.front, b.front);
}
I'd love to have this syntax aswell.
I am not good in DIPs and hope someone is interested in this
feature too
DIP-32 has been dormant since 2013. I've been waiting for builtin
tuples ever since I started using D. I believe the community
agrees upon that we want the Python-style syntax to be used. But
in order for this to be integrated we must wait out the
deprecation of the C-inherited comma expression to become an
error. Correct me if I'm wrong.
See:
- https://wiki.dlang.org/DIP32
- http://forum.dlang.org/post/kj44fs$2iil$1...@digitalmars.com
Didn't Kenji Hara implement one of his proposals in DMD?...I
might remember wrong.
Re: D future ...
On Tuesday, 20 December 2016 at 10:46:28 UTC, bachmeier wrote: I realized a while back that this community is incapable of understanding what is wrong with Dub's documentation. Many of the top folks don't use it, but I recall Andre commenting on trying to use it and getting frustrated. It's better than than it was 6 months ago, but still could be improved.
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 14:56:37 UTC, Ilya Yaroshenko
wrote:
As you can see the output should be 1000, but it is 1.
I was a little confused by what you meant, but the following main
is a little more obvious to me
void main()
{
auto c = front();
c[0] = 1000;
import std.stdio;
writeln(c[0]); //prints 1000
writeln(a[0]); //prints 1
}
Re: D future ...
On Tuesday, 20 December 2016 at 14:09:45 UTC, Dibyendu Majumdar wrote: Apologies for being one of those who offers advice but no action. Don't be Dibyendu ... We "ranters" are actually D's "client base". There seem to be the wrong impression by the D-Team, that the "clients" are also the people who need to help grow D. I do not recall seeing on the C++ and other forums this constant attitude from fix it yourselves or put it in the libraries or ... Its mostly on the smaller languages where they lack people. And at the same time, that is a very scary though for companies who want to use a language. Like you stated, the focus seems to be spread out compared to the needs. Its nice that a lot of the features of D, ended up in the new revisions of C++. But D is not a proving ground for C++ ideas. At some moment one needs to say slow down with the new language features and focus on the core. Take for example the recent DIP 1005 proposal. Is it really needed now? Can people not work with D without this feature? If there is one thing that still scares people today, is hearing how D split the community with the D1/D2 version. And yet, even more features seems to be added to the language while the rest seems to be more or less low priority. Lets face it, its not exactly sexy doing boring documentation updates, creating examples, creating more std classes etc. Its way more fun to enhance a language ( its a trap too often seen in new languages. Its almost like language developers are in a arms race, to outdo each other but sometimes as the expensive of other area's ). Anyway, enough "ranting" for me, back to work.
Re: D future ...
On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote: I split this from the "Re: A betterC modular standard library?" topic because my response is will be too much off-topic but the whole thread is irking me the wrong way. I see some of the same argument coming up all the time, with a level of frequency. D has not market: - A lot of times people complain that D has no real audience / market. Is D the perfect system. No... But lets compare to those other languages shall we? Now this is my opinion, so take it with a bit of salt. Go: Its is a "simple" language. But its forced restrictions at times are so annoying its saps all the fun out of the coding. Its not really C. Its more Basic on steroids. Unfortunately while Go has huge amount of traction and packages ( 70k from my count ), the quality is also... It has a few real gems those gems are a result of the mass amount of packages. It has its own market. A scripting replacement market mostly. Crystal: Is pure Ruby focused. Again, it draws in a lot of people with a Ruby background. Interesting language that is already splitting away from Ruby comparability. Nim/Julia/Numpy/Numba: Are very Python like focused. Nim will disagree but its very clear. Again, the focus seems to draw in more scripting language orientated people, mostly from the Python area. Rust: Promotes itself to be better C but its simply a more complex language design. A over active amount of fans, that do not understand its complex. Less fun to get into. Reminds me too much of Perl. D is C++ but improved/simplified. Its not to hard to get into, its more easy for anybody from a C background. Take it from a guy that spend a large part of his life in PHP. I feel more at home with D, then with all the other languages. The moment you get over a few hurdles, it becomes a very easy language. My point is that D does fit in a specific market. It fits in between C++ and scripting languages like PHP ( that has a more C background ). Its not going to convert a lot of C++ people. Sorry but its true. C++ has been evolving, the people who invested into C++ have very little advantage of going to D. The whole focus on C++ people marketing is simply wrong! Every time this gets mentioned in external forums, the language gets a pounding by people with the same argumentation. Why go for D when C++ 20xx version does it also. Trusting a person with C like scripting language ( like PHP/Java ) background into C++, well that is fun . People always seem to say that D has no real advantage but it has. Its easier C++ for people who do not come from C/C++. Maybe i am downplaying this but for love of the gods, the focus is wrong. I am the same guy that complained a while ago about the website its examples being too "advanced" and it scares a big potential group of people away. Community: -- But community wise there is a real issue. People are friendly and help out. But it feels like everybody is doing there own thing. I see a lot of people arguing a lot about D and sorry to say but at times it sounds like a kindergarten. Walter/Andrei are right that updates and changes need to be focused on the standard library. Maybe its because people who use D are more into proprietary software, that there is less community response with work going into the library. But ... see below in Walter / Andrei section. Library ( and runtime bloat ): -- But it also does not diminish some of the requests. When i write a simple program that uses the socket, standard, string and conv library. All it does is open a TCP socket and send a response back. This is not supposed to take 2.4MB in memory, with a 1.2MB compiled executable ( 450kb o file ). Full blown Nginx uses only one MB more for its core in memory. For something so simple, its a little bit crazy. When i make a plugin in Go 1.8, it uses 10KB. A plugin ( shared C library ) in D uses almost 200KB. Using C++ it results into another 10KB file. Maybe i am a total noob but some things make no sense. It gives me the impression that some massive run times are getting added or there is some major library bloat. Library Standardization: Some of the proposals sounds very correct. The library needs to be split. Every module needs its own GIT. People need to be able to add standard modules ( after approval ). No offense but where is the standard database library for D? There is none. That is just a load of bull. Anybody who wants to program in any language expect the language to have a standard database library! Not that you need to search the packages for a standard library. I have seen one man projects that have more standard library support then D. Its one of the most basic packages. How about a simple web server? A lot of languages offer this by default. It gets people going. vibe.d is not a simple web server. It's not
Re: Multiple return value as requirements for safety and performance
Walter Bright via Digitalmars-d napsal
Út, pro 20, 2016 v 3∶47 :
On 12/20/2016 5:47 AM, Ilya Yaroshenko wrote:
One good thing for safety and CTFE is allow multiple return value. In
combination with `auto ref` it is _very_ powerful:
auto ref front()
{
// Returns 2 values, each value is returned by reference if
possible
return (a.front, b.front);
}
http://dlang.org/phobos/std_typecons.html#.tuple
auto ref front() {
return tuple(a.front, b.front);
}
https://github.com/dlang/phobos/blob/master/std/typecons.d#L1686
I do not see any auto ref at code, so I do not belive this will work
Re: A betterC modular standard library?
On Tuesday, 20 December 2016 at 12:49:53 UTC, Walter Bright wrote:
I don't propose forcing anyone to use Druntime.
Perhaps this is not part of Ilya's concern, but druntime is
required to get a build.
//test.d-
module test;
void main() { }
dmd -m64 -defaultlib= -debuglib= -conf= test.d
Error: cannot find source code for runtime library file
'object.d'
dmd might not be correctly installed. Run 'dmd -man' for
installation
instructions.
config file: (null)
Specify path to file 'object.d' with -I switch
There's nothing here that really requires druntime, unless you
want to count the plumbing required to call DMain. In that case,
we can just call CMain directly:
module test;
extern(C) void main() { }
Same Error:
Error: cannot find source code for runtime library file
'object.d'
Try with the -betterC switch:
dmd -m64 -defaultlib= -debuglib= -conf= -betterC test.d
Same Error:
Error: cannot find source code for runtime library file
'object.d'
Ok, fine, let's add an empty object.d
//object.d
module object;
//test.d
module test;
extern(C) void main() { }
dmd -m64 -defaultlib= -debuglib= -conf= -betterC object.d test.d
Error: undefined identifier 'Error'
Error: undefined identifier 'Error'
Ok, now I need something called 'Error'. I don't see anywhere in
my code where that's necessary, but it must be important because
it told me twice.
//object.d
module object;
class Throwable { }
class Error : Throwable { }
//test.d
module test;
extern(C) void main() { }
dmd -m64 -defaultlib= -debuglib= -conf= -betterC object.d test.d
object.d(3): Error: class object.Throwable missing or corrupt
object.d
Ok, that's weird. I just added it. Luckily I've done this
before, so I know what to do.
//object.d
module object;
class Object { }
class Throwable { }
class Error : Throwable
{
this(string x) { }
}
//test.d
module test;
extern(C) void main() { }
dmd -m64 -defaultlib= -debuglib= -conf= -betterC object.d test.d
Error: no constructor for Error
Error: no constructor for Error
Hmm. Again with the double error messages. Ok, let's add a
constructor.
//object.d
module object;
class Object { }
class Throwable { }
class Error : Throwable
{
this(string x) { }
}
//test.d
module test;
extern(C) void main() { }
dmd -m64 -defaultlib= -debuglib= -conf= -betterC object.d test.d
object.d(9): Error: undefined identifier 'string'
At least its only telling me once. Easy fix.
//object.d
module object;
alias immutable(char)[] string;
class Object { }
class Throwable { }
class Error : Throwable
{
this(string x) { }
}
//test.d
module test;
extern(C) void main() { }
dmd -m64 -defaultlib= -debuglib= -conf= -betterC object.d test.d
Error: TypeInfo not found. object.d may be incorrectly
installed or corrupt,
compile with -v switch
I could go on, but I'm not going to. The final result to get a
build looks like this, but you have to link with --gc-sections to
avoid having to implement a buch of other stuff.
module object;
extern(C) void __dmd_personality_v0() { }
extern(C) void _d_dso_registry() { }
alias immutable(char)[] string;
class Object { }
class TypeInfo { }
class TypeInfo_Class : TypeInfo
{
ubyte[136] ignore;
}
alias TypeInfo_Class ClassInfo;
class Throwable { }
class Error : Throwable
{
this(string x) { }
}
//test.d
module test;
extern(C) void main() { }
dmd -m64 -defaultlib= -debuglib= -conf= -betterC object.d
test.d -L=--gc-sections
If you add structs or classes to your code, you have to add even
more druntime stuff.
The point I'm trying to make here is druntime is required just to
get a build, even though your code doesn't need it.
Mike
Re: D future ...
On 12/20/2016 05:53 AM, Dicebot wrote: On 12/20/2016 12:48 PM, Benjiro wrote: Actually, i did not vent any anger until this morning when i noticed the wiseass response. All the points i wrote yesterday are items that actually bother a lot more people. But those same people who complain about it, always get shutdown with that typical: Do it yourself response / Improve the standard library / ... Can you list specific list of actions/events you would have wanted to see as a result of your post? Literally "person X does Y". That would be very helpful. -- Andrei
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 14:47:28 UTC, Walter Bright wrote:
On 12/20/2016 5:47 AM, Ilya Yaroshenko wrote:
One good thing for safety and CTFE is allow multiple return
value. In
combination with `auto ref` it is _very_ powerful:
auto ref front()
{
// Returns 2 values, each value is returned by reference if
possible
return (a.front, b.front);
}
http://dlang.org/phobos/std_typecons.html#.tuple
auto ref front() {
return tuple(a.front, b.front);
}
Tuples can not work with auto ref. This is a reason for this
thread.
Proof:
-
import std.typecons: tuple;
int[] a = [1,2,3];
int[] b = [1,2,3];
auto ref front() {
import std.range: front;
return tuple(a.front, b.front);
}
void main()
{
front()[0] = 1000;
import std.stdio;
writeln(front()[0]);
}
-
Output: 1
-
As you can see the output should be 1000, but it is 1.
It can be solved with pointers, and Mir will have their own
tuples which use pointers. But it is not good because:
1. Pointers are not CTFE-able.
2. Pointers are not safe.
Re: D future ...
On Tuesday, 20 December 2016 at 14:18:38 UTC, Mike Parker wrote: On Tuesday, 20 December 2016 at 11:17:19 UTC, Guillaume Piolat wrote: Michael Parker is working on that from last I heard. Yes, he is, though slowly. I can give it more priority after the New Year. As I recall, you made your announcement in response to one of my previous complaints, and I'm excited that you are doing it. This is going to be a very important document for D adoption.
Re: Multiple return value as requirements for safety and performance
On 12/20/2016 5:47 AM, Ilya Yaroshenko wrote:
One good thing for safety and CTFE is allow multiple return value. In
combination with `auto ref` it is _very_ powerful:
auto ref front()
{
// Returns 2 values, each value is returned by reference if possible
return (a.front, b.front);
}
http://dlang.org/phobos/std_typecons.html#.tuple
auto ref front() {
return tuple(a.front, b.front);
}
Re: A betterC modular standard library?
On 12/20/2016 5:35 AM, Ilya Yaroshenko wrote: On Tuesday, 20 December 2016 at 12:49:53 UTC, Walter Bright wrote: I don't see the need to rewrite cpuid because its sole dependency on other object files in Druntime is the static constructor, because the static constructor can be adjusted to not rely on anything else in Druntime. If there are other issues with cpuid, please elucidate. 1. https://issues.dlang.org/show_bug.cgi?id=16028 2. The code is very hard to maintain, fix, extend. This is a reason why mir-cpuid was written from scratch without any copy-pasting. 3. Library is x86 oriented. Some OSs has interface to fetch unified CPU information. 4. No TLB information provided. 5. Number of CPUs per cache is not know. ARM CPUs may have complex topology (plus 3.) Thank you, but I meant issues that would require it to be separate from druntime, not bug fixes or enhancements to account for ever more things being added to the CPUID instruction. BTW, of course it is x86 oriented. Any use of cpuid must be. After all, what does "SSSE3.1" mean on ARM?
Re: Simple tasks to get involved
On 12/20/2016 02:33 AM, Seb wrote: However, as most of them might require a lot of time or expertise, here are a couple of ideas from the H2 vision that have been semi-automated and could be a good start for everyone to get involved: [snip] This is awesome stuff! I'm a huge fan of automation, and this is really appreciated. Can you offer an opt-out for documentation and Params:/Returns:? If so, we should make these tests part of the requirements for all PRs starting with a blacklist. -- Andrei
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On 12/13/16 11:33 PM, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei Just a thought but with all of proliferation of imports down to each declaration comes the pain that e.g. renaming a module cascades to countless instances of import statements. This is true of local imports as well but the problem gets bigger. Dmitry Olshansky
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 13:47:50 UTC, Ilya Yaroshenko
wrote:
One good thing for safety and CTFE is allow multiple return
value. In combination with `auto ref` it is _very_ powerful:
auto ref front()
{
// Returns 2 values, each value is returned by reference if
possible
return (a.front, b.front);
}
Nested Voldemort structs? Horcruxified, to work around the symbol
name length explosion. I always imagined allowing for multiple
values (in multiple fields) was part of the point behind them.
For instance, consider the several discrete pieces of data you
get from the Result of std.regex matching. (Not all of it is via
opIndex.)
Re: D future ...
On Tuesday, 20 December 2016 at 14:18:38 UTC, Mike Parker wrote: On Tuesday, 20 December 2016 at 11:17:19 UTC, Guillaume Piolat wrote: Michael Parker is working on that from last I heard. Yes, he is, though slowly. I can give it more priority after the New Year. Thanks for doing this!
Re: D future ...
On Tuesday, 20 December 2016 at 11:17:19 UTC, Guillaume Piolat wrote: Michael Parker is working on that from last I heard. Yes, he is, though slowly. I can give it more priority after the New Year.
Re: D future ...
On Tuesday, 20 December 2016 at 12:43:38 UTC, Andrei Alexandrescu wrote: On 12/20/16 3:41 AM, Benjiro wrote: [snip] Thanks for the rant. Though it was pretty awesome, I too feel the focus was missing in the sense that I'm unclear on what steps we can take to alleviate your pain points. Do you want more or less in the language and the standard library? Do you want me to get on things like editor integration I have no expertise in? Hi, As a long time D observer and someone who tried to use D earlier this year, I hope following is constructive. D's reason for existence I think the landscape of programming languages has changed somewhat in recent years - we have new languages like Go, Swift, Rust, and even an existing language like C# is becoming cross platform. It seems that D started out as better C++ but C++ is also evolving and taking many of the ideas from D. So I think that D has to have a clear charter similar to say the charter for C (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2021.htm). And this needs to clarify how D is different from its competition and which use cases it is best for. Is it better C? Is it better C++? Is it better some other language? Project Management - It is a bit painful to watch how D's development is managed. In my view, the whole of the D team (including volunteers) need to be very narrowly focussed on very small set of defined priorities. Secondly the goal has to be a measurable delivery within strict timescales. It seems that too many avenues are being chased while there are too few people to handle the workload. Why not have a much more restricted scope and focus everyone on that. And when this is achieved move to the next scope. It is also important to keep the scope small and achievable in a short time (3-6 months). Real world needs - As a potential user of D, here are the things I looked at: 1) Can I successfully build my project? 2) Can I expose my D modules as reusable C ABI compatible shared libraries for use in a heterogenous environment? 3) Can I debug my programs easily? 4) Is there an IDE I can use for development? 5) Is the performance going to match C or C++? 6) Will the third party libraries I need to use work with D? Note that in all of above, language features and D libraries did not count! In production usage being able to deliver counts most. D fell short in these areas compared to a combination of C++ and C#. Final thoughts -- I wish I could help, as I really like D as a language. But unfortunately I have to focus on getting my own work done (survival reasons), and I chose to use C++ and C# for my project (after giving up the idea of using D). I could potentially help in project management in my spare time ... but feel that it needs a mind set change in the D team ... and I fear this is unlikely. Apologies for being one of those who offers advice but no action. Regards Dibyendu
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 14:04:26 UTC, Nicholas Wilson
wrote:
On Tuesday, 20 December 2016 at 13:47:50 UTC, Ilya Yaroshenko
wrote:
One good thing for safety and CTFE is allow multiple return
value. In combination with `auto ref` it is _very_ powerful:
auto ref front()
{
// Returns 2 values, each value is returned by reference if
possible
return (a.front, b.front);
}
Mir libs will use pointers for now. This is one of reasons why
`zip` is slow.
The new feature also significantly extends std.range and
std.algorithm functionality.
This thread was forked from
http://forum.dlang.org/post/acdwfbirvoxzrsfyl...@forum.dlang.org
I am not good in DIPs and hope someone is interested in this
feature too
Do tuples work for this?
No, tuples stores either value or pointer. If it stores pointer
then it is not safe and it is not CTFE.
Re: Multiple return value as requirements for safety and performance
On Tuesday, 20 December 2016 at 13:47:50 UTC, Ilya Yaroshenko
wrote:
One good thing for safety and CTFE is allow multiple return
value. In combination with `auto ref` it is _very_ powerful:
auto ref front()
{
// Returns 2 values, each value is returned by reference if
possible
return (a.front, b.front);
}
Mir libs will use pointers for now. This is one of reasons why
`zip` is slow.
The new feature also significantly extends std.range and
std.algorithm functionality.
This thread was forked from
http://forum.dlang.org/post/acdwfbirvoxzrsfyl...@forum.dlang.org
I am not good in DIPs and hope someone is interested in this
feature too
Do tuples work for this?
Re: Simple tasks to get involved
On Tuesday, 20 December 2016 at 11:54:08 UTC, Walter Bright wrote: On 12/19/2016 11:33 PM, Seb wrote: However, as most of them might require a lot of time or expertise, here are a couple of ideas from the H2 vision that have been semi-automated and could be a good start for everyone to get involved: Thanks for posting a nice summary of how to help! This should be pinned topic
Multiple return value as requirements for safety and performance
One good thing for safety and CTFE is allow multiple return
value. In combination with `auto ref` it is _very_ powerful:
auto ref front()
{
// Returns 2 values, each value is returned by reference if
possible
return (a.front, b.front);
}
Mir libs will use pointers for now. This is one of reasons why
`zip` is slow.
The new feature also significantly extends std.range and
std.algorithm functionality.
This thread was forked from
http://forum.dlang.org/post/acdwfbirvoxzrsfyl...@forum.dlang.org
I am not good in DIPs and hope someone is interested in this
feature too
Re: A betterC modular standard library?
On Tuesday, 20 December 2016 at 12:45:13 UTC, Guillaume Piolat wrote: On Tuesday, 20 December 2016 at 12:33:27 UTC, John Colvin wrote: * D used to have 2 standard libraries. That was not a happy time for the community. People are wary partly because of that. To bring some cool to the discussion, let's remember that they also weren't compatible. Of course it's a concern but this case is different and deserve full consideration. let's say the thread title was "A runtime-less modular library?" Thanks! Good point
Re: A betterC modular standard library?
On Tuesday, 20 December 2016 at 12:49:53 UTC, Walter Bright wrote: I don't see the need to rewrite cpuid because its sole dependency on other object files in Druntime is the static constructor, because the static constructor can be adjusted to not rely on anything else in Druntime. If there are other issues with cpuid, please elucidate. 1. https://issues.dlang.org/show_bug.cgi?id=16028 2. The code is very hard to maintain, fix, extend. This is a reason why mir-cpuid was written from scratch without any copy-pasting. 3. Library is x86 oriented. Some OSs has interface to fetch unified CPU information. 4. No TLB information provided. 5. Number of CPUs per cache is not know. ARM CPUs may have complex topology (plus 3.)
Re: A betterC modular standard library?
On Tuesday, 20 December 2016 at 12:33:27 UTC, John Colvin wrote:
Mir uses deprecated native complex numbers because we can not
spend days explaining why they are better then std.complex (in
short: std.complex breaks compiler optimization logic, function
inlining works, but it breaks optimization logic). I have already
spend 4 hours for forum discussions and PRs about this issue
without any result.
We are doing the best things we can do with current D. If
something will be improved in future we will upgrade codebase.
P.S. a good example of the sort of statement that needs more
explanation, at least for me:
The betterC
std.range and std.algorithm analogs would be released with new
ndslice
implementation. Mir's algorithm would be faster then Phobos
and will
generate less template bloat."
How? Why? Is ndslice actually capable of the same level of
flexibility as std.algorithm and std.range? You're effectively
saying "all that stuff that Andrei (and others) designed and
wrote, I can do better" without really showing anyone why they
should believe that.
The explanation of new idioms will appear after its code.
I did not say "better". I said "betterC" plus "faster".
Yes, i can say that for DCV library new idioms are much better
then Phobos.
But new idioms have another issues, for example D language is not
capable to infer their safety for many of them. Other issues is
that there a lot of fast non CTFE-able types and their CTFE-able
analogs.
One good things for safety and CTFE is allow multiple return
value. In combination with `auto ref` it is _very_ powerful:
auto ref front()
{
// Returns 2 values, each value is returned by reference if
possible
return (a.front, b.front);
}
This would be interesting to discuss and to have it in D in CTFE
and @safe mode. But I am not good in DIPs.
This sorts of features is very desirable.
Re: A betterC modular standard library?
On 12/20/2016 4:30 AM, Ilya Yaroshenko wrote: This is true for application but not for libraries. mir-glas depends on mir-cpuid. If I want GLAS to be ported for a new target then I will release a new CPUID version and will be able to use it the same day. With DRuntime (as solid project), I need to wait up to 6 months before it will be released with DMD and then with LDC. Workaround are possible, but they requires more efforts, more time, more code. Please do not force Mir to use DRuntime. We need a solid solution I do not force anyone to drop DRuntime: Mir libraries can be used with DRuntime/Phobos. We have full backward compatibility. DRuntime does not satisfy portability requirements (which was repeated multiple times in this thread). DRuntime (at least for now and future few years) is a big constraint for betterC libs to replace existing C analogs. Here's how anyone can override druntime's cpuid for their application without touching druntime: dmd -c mycpuid dmd myapp mycpuid.o I.e. the way linkers work is if the symbol's definition exists, it is not pulled in from the library. > Please do not force me to use DRuntime. I don't propose forcing anyone to use Druntime. What I do propose is reducing interdependencies among the object files in Druntime. Druntime is not a monolithic chunk of code, it is a library of object files. I don't see the need to rewrite cpuid because its sole dependency on other object files in Druntime is the static constructor, because the static constructor can be adjusted to not rely on anything else in Druntime. If there are other issues with cpuid, please elucidate.
Re: A betterC modular standard library?
On Tuesday, 20 December 2016 at 12:33:27 UTC, John Colvin wrote: * D used to have 2 standard libraries. That was not a happy time for the community. People are wary partly because of that. To bring some cool to the discussion, let's remember that they also weren't compatible. Of course it's a concern but this case is different and deserve full consideration. let's say the thread title was "A runtime-less modular library?"
Re: D future ...
On 12/20/16 3:41 AM, Benjiro wrote: [snip] Thanks for the rant. Though it was pretty awesome, I too feel the focus was missing in the sense that I'm unclear on what steps we can take to alleviate your pain points. Do you want more or less in the language and the standard library? Do you want me to get on things like editor integration I have no expertise in? What would be Cliff's notes of this post? Maybe you want to freaking ask the authors of for instants std.database etc why they feel unwilling to add it to the standard library git. Erik Smith has been on board with adding his work to the standard library from day one, and he has our full support. He gave a talk at DConf. As sadly it sometimes happens with volunteers, time is a precious commodity for us all and volunteer projects are the first to be dropped in a crunch. Framing this politically is not quite helpful. Are you thinking of a different database package? Thanks, Andrei
Re: A betterC modular standard library?
On Tuesday, 20 December 2016 at 09:56:34 UTC, Ilya Yaroshenko wrote: Of course you can bundle your own Phobos. If you put a std.* module in your path your build will be working against that instead. If you don't mess around with sc.ini it will override the default for that compilation. CPUID should be precompiled. So this does not work. If GLAS do not need anything but CPUID, what the reason to depend on DRuntime? Please stop to force me to use DRuntime because you think it is better for Mir projects. This looks like DRuntime religion. A betterC library can be used with DRuntime. So I do not force anyone to drop DRuntime. Please do not force me to use it. GLAS already works without DRuntime and I am happy about that. What does "you can bundle your own phobos" have to do with that? No one's forcing you to do anything. You're suggesting something radical*, other people are suggesting that maybe there are good compromises where everybody wins, avoiding fragmentation. Then you say that "looks like DRuntime religion" and claim you're being forced to modify your code to add extra dependencies. It doesn't make sense. Your technical arguments have good content, in my opinion everyone would benefit from you writing them up with sufficient context for people who don't know what you know and without hyperbole (none of that "D will fail if we don't do X" or "phobos is bloated and useless" stuff, it doesn't help communicate your points). Developing the case study / thought experiment of getting two libraries (blas and fft) in to a traditional linux distro would be a great central point. See https://github.com/dlang/DIPs/pull/51 where Andrei describes not only how he thinks things should be, but also explains in detail why other approaches won't work. Now consider that what you're talking about is a lot more important and different/disruptive than a new import syntax, so it deserves at least comparably good description. * D used to have 2 standard libraries. That was not a happy time for the community. People are wary partly because of that. P.S. a good example of the sort of statement that needs more explanation, at least for me: The betterC std.range and std.algorithm analogs would be released with new ndslice implementation. Mir's algorithm would be faster then Phobos and will generate less template bloat." How? Why? Is ndslice actually capable of the same level of flexibility as std.algorithm and std.range? You're effectively saying "all that stuff that Andrei (and others) designed and wrote, I can do better" without really showing anyone why they should believe that.
Re: A betterC modular standard library?
On Tuesday, 20 December 2016 at 12:00:43 UTC, Walter Bright wrote: On 12/18/2016 1:02 PM, Ilya Yaroshenko wrote: I need to understand how it is can be done because I did not find a valid solution. mir-cpuid has global symbols, they are accessed using extern(C) API. If multiple libraries trying to initialize it than it will be initialized only once. extern C API does not solve a problem with DRuntime because current DRuntime is not a betterC library and it is huge. A huge betterC library is a problem too because it is less portable. cpuid can be written in a manner that it is self-contained. If so, it doesn't matter how large druntime is, as it won't have references to any of the rest of it and so the rest won't be pulled in by the linker. This is true for application but not for libraries. mir-glas depends on mir-cpuid. If I want GLAS to be ported for a new target then I will release a new CPUID version and will be able to use it the same day. With DRuntime (as solid project), I need to wait up to 6 months before it will be released with DMD and then with LDC. Workaround are possible, but they requires more efforts, more time, more code. Please do not force Mir to use DRuntime. We need a solid solution I do not force anyone to drop DRuntime: Mir libraries can be used with DRuntime/Phobos. We have full backward compatibility. DRuntime does not satisfy portability requirements (which was repeated multiple times in this thread). DRuntime (at least for now and future few years) is a big constraint for betterC libs to replace existing C analogs. Please do not force me to use DRuntime.
Re: D future ...
On 12/19/16 11:38 PM, Jerry wrote: https://issues.dlang.org/show_bug.cgi?id=16991 Another issue onto the list of thousands, to collect dust for the next few years til someone decides they want to use their personal time to fix it. That's changing because we're starting to have permanent collaborators. I've kindly asked Razvan, one of our scholarship students, to take a look. Generally they will be focused on larger projects but fixing trivial bugs is a simple background activity. Just to highlight another problem, there's a lot of trivial to fix issues. Just maintenance really, like that one you posted. But there is no one going through fixing them. Well that one might end up getting fixed cause of the extra exposure. I've just added the "trivial" keyword. If any concrete bug comes to mind please ascribe the keyword to it. Thanks, Andrei
Re: A betterC modular standard library?
On 12/18/2016 1:02 PM, Ilya Yaroshenko wrote: I need to understand how it is can be done because I did not find a valid solution. mir-cpuid has global symbols, they are accessed using extern(C) API. If multiple libraries trying to initialize it than it will be initialized only once. extern C API does not solve a problem with DRuntime because current DRuntime is not a betterC library and it is huge. A huge betterC library is a problem too because it is less portable. cpuid can be written in a manner that it is self-contained. If so, it doesn't matter how large druntime is, as it won't have references to any of the rest of it and so the rest won't be pulled in by the linker. https://github.com/dlang/druntime/blob/master/src/core/cpuid.d Currently, core.cpuid has no imports. It does have a static constructor, though, which references the startup code in druntime. This can be changed so it uses the static construction support in the C runtime library. Then it will be independent of druntime.
annotating (object/library files) with compilation metadata to avoid incompatible libraries
Could dmd/ldc/gdc produce user defined attributes embedded (eg as json
string) embedded in some section of the object file/static/shared library,
eg:
```
{"compiler" : "dmd", "version" : "2.072", "flags" : "-O -debug"}
```
with some way to write and read those attributes, so that tooling can give
informative warnings or errors when attempting to link together several
libraries whose attributes don't match (user defined function can decide
what matches based on those attributes), or to select which libraries to
link if there are several choices
NOTE: posted a more general question here [1] beyond just D usage
[1]
http://stackoverflow.com/questions/41240093/how-to-annotate-a-compilation-output-object-library-file-with-compiler-annotat
quote from that question:
Use cases:
-
either the linker ld or some other user defined tool could use this
metadata to give informative warnings or errors when attempting to link
together several libraries whose attributes don't match (eg when linking
libraries compiles with -std=c++11 with others compiled without this)
-
this would provide much more user friendly error messages compared to
the usual hard to debug undefined symbol errors, eg: undefined reference to
llvm::Twine::str[abi:cxx11]()
https://github.com/ldc-developers/ldc/issues/1928 or other errors that
are due to compilation flag mismatches (eg missing -debug from
https://github.com/rejectedsoftware/vibe.d/issues/740#issuecomment-268039416
)
-
make it possible for tools to read the embedded metadata and find the
most appropriate matching libraries to link when multiple ones are available
NOTE: the only thing I could find was
https://gcc.gnu.org/onlinedocs/gccint/LTO-object-file-layout.html but not
sure if that's relevant or how I would write (and later read) such user
defined attributes:
Command line options (.gnu.lto_.opts): This section contains the command
line options used to generate the object files
Re: Simple tasks to get involved
On 12/19/2016 11:33 PM, Seb wrote: However, as most of them might require a lot of time or expertise, here are a couple of ideas from the H2 vision that have been semi-automated and could be a good start for everyone to get involved: Thanks for posting a nice summary of how to help!
Re: D future ...
On 12/20/2016 3:12 AM, bachmeier wrote: Heck, just pick *one* thing that grinds your gears, like the quotation above, and fix it. But I don't use Dub or Git submodules. I use R's package manager, which is both well-documented and does not require the user to write a configuration file to use the package. Of course that is not an option for very many D users. I guess the bigger problem is that Dub is allowed to be the official package manager even though nobody bothered to write real documentation. In other communities, contributions have to meet standards for both code and documentation. If you don't want to fix anything, ok. But you can still file bugzilla issues for things that you find.
Re: D future ...
On Tuesday, 20 December 2016 at 10:46:28 UTC, bachmeier wrote: On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote: Documentation: -- I realized a while back that this community is incapable of understanding what is wrong with Dub's documentation. Michael Parker is working on that from last I heard.
Re: D future ...
On Tuesday, 20 December 2016 at 11:00:02 UTC, Walter Bright wrote: On 12/20/2016 2:46 AM, bachmeier wrote: Dub's documentation is simply atrocious *and it's the official package manager*. Throw around things terms like "you can use Git submodules for that" as if it's a trivial thing. But I'm not going to say more. I realized a while back that this community is incapable of understanding what is wrong with Dub's documentation. We do accept pull requests, though. Heck, just pick *one* thing that grinds your gears, like the quotation above, and fix it. But I don't use Dub or Git submodules. I use R's package manager, which is both well-documented and does not require the user to write a configuration file to use the package. Of course that is not an option for very many D users. I guess the bigger problem is that Dub is allowed to be the official package manager even though nobody bothered to write real documentation. In other communities, contributions have to meet standards for both code and documentation.
Re: D future ...
On 12/20/2016 2:46 AM, bachmeier wrote: Dub's documentation is simply atrocious *and it's the official package manager*. Throw around things terms like "you can use Git submodules for that" as if it's a trivial thing. But I'm not going to say more. I realized a while back that this community is incapable of understanding what is wrong with Dub's documentation. We do accept pull requests, though. Heck, just pick *one* thing that grinds your gears, like the quotation above, and fix it.
Re: D future ...
On 12/20/2016 12:48 PM, Benjiro wrote: > Actually, i did not vent any anger until this morning when i noticed the > wiseass response. All the points i wrote yesterday are items that > actually bother a lot more people. But those same people who complain > about it, always get shutdown with that typical: Do it yourself response > / Improve the standard library / ... Can you list specific list of actions/events you would have wanted to see as a result of your post? Literally "person X does Y". Trying to write it down is very likely to make obvious why no other reaction than one you have got is possible. signature.asc Description: OpenPGP digital signature
