Re: Mars Drafting Library - Official community driven library
On Tuesday, 3 February 2015 at 02:38:57 UTC, Zach the Mystic wrote: I'm arguing from the perspective that the approval must come first, and the piloting second. Who would want to develop a module in the pre-pilot phase, without having any idea of whether they were developing it finally for phobos or just 3rd-party use, then wait months or years to find out if the leadership is even *interested* in what they're doing? Why would people try to meet high standards without knowing if those standards are actually going to be required or not? It's like an unpaid internship: Work for us for free, and we'll let you know at the end whether we want your work or not. Al least the module will be available in draft namespace until controversy is resolved. I don't think there would be any blocking campaign without providing sane requirements to move on. BTW. I tried to publish the DIP but got into the following issue: http://forum.dlang.org/post/yoqwuqhtlpifgwude...@forum.dlang.org It looks the DIP will be delayed at least by day. Piotrek
Re: Mars Drafting Library - Official community driven library
On Monday, 2 February 2015 at 06:07:29 UTC, Zach the Mystic wrote: Therefore, I think std.experimental is for all in flux APIs, from the drafting stage to the later less in flux stages. Definitely this is what I thought initially. But, IMO, it can be really hard or impossible to carry out, as you pointed one of the issues in the following part: The danger is that the phobos management will want to have their cake and eat it too, as the saying goes. You simply can't promise users both stability and a perfectly designed API at the same time, tempting as it is. Hence the *proposal* of the drafting library. Piotrek
Re: Mars Drafting Library - Official community driven library
On Monday, 2 February 2015 at 20:09:42 UTC, Piotrek wrote: On Monday, 2 February 2015 at 06:07:29 UTC, Zach the Mystic wrote: Therefore, I think std.experimental is for all in flux APIs, from the drafting stage to the later less in flux stages. Definitely this is what I thought initially. But, IMO, it can be really hard or impossible to carry out, as you pointed one of the issues in the following part: The danger is that the phobos management will want to have their cake and eat it too, as the saying goes. You simply can't promise users both stability and a perfectly designed API at the same time, tempting as it is. Hence the *proposal* of the drafting library. Piotrek I think std.experimental should essentially be its own library, with its own slot next to phobos on the github repo. I'm open to changing the name or something... but if we have both std.experimental *and* your new mars, what do you think is the real difference? How can std.experimental be sort of experimental, but really not, whereas mars is really actually experimental? Where is the cutoff line? How would anyone know whether they reached it or not? My attitude is that any given module in std.experimental should simply indicate its current level stability at the top of its documentation - full disclosure about where it is from, say, 0 to 95%, (with anything above that already assumed qualified for std proper). I'd even make one more point, that all current phobos modules known to be in need of revamping be copied wholesale in their current forms to std.experimental, with the top documentation saying, This is the experimental version of the old std.xxx, which needs *your* help with its redesign and implementation. Feel free to break the current API by improving it. This is *not* currently considered a stable module.
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 23:22:55 UTC, Dicebot wrote: Newbie confusion? In what way? What library to use between Phobos and Mars, why those are separate, why those have different stability guranatees, where to submit new contributions, why bother - it all would need to be written down and explained over and over again. And this alone is huge -. IMO, there is no more confusion than using std.experimental vs other modules. Drafting modules are for developing functionality not present in Phobos, but build upon Phobos foundation. I admit I don't understand where confusion may come from. I will pay more attention to it as you described it as a huge problem. Piotrek
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 23:21:36 UTC, Dicebot wrote: As per latest agreement everything in std.experimental is considered subject to any change so is perfectly flexible. - new drafting modules won't disturb usual users of the standard library That statements needs some hard data that current situation is disturbing to be considered as a rationale. If you put to many uncompleted modules in the std.experimental it can influence stable part of the Phobos. - binary size - pull request with more experimental stuff etc. IMO, std.experimental is not for the drafting stage of the SW development. Depends on your definition of draft. Anything that is good enough to be actually used in real app is good enough for std.experimental - and anything less is of no use to end user anyway. I agree that all is a matter of definition. I still doubt that fast evolving drafts would be possible in std namespace. 2) what would it give over code.dlang.org ? - community driven as opposed to individual driven - out of the box readiness - minimal fragmentation and controversy code.dlang.org is actually much more community driven because it is naturally decentralized. Controversy is inevitable anyway (hello std.json). I used the community driven in contrast to individually driven. The key property of the proposal is to minimize the controversy by community (common) drafting process. Fragmentation is a thing though - but I yet to be convinced that is a bad thing that needs to be fixed. I consider fragmentation a major problem for standards. 3) what problems are you trying to solve and why do you think this is suitable solution? Adding new modules (replacing the deprecated ones) in more robust and quicker manner. It is as quick as it can be for standard library - and code.dlang.org takes care of everything else. I have non-trivial modules in mind like gui, json, database, etc. Any library that risks quick removal of deprecated modules / API is not acceptable for standard stamp. The drafting lib is a proposition of standard not a standard itself. And I didn't said anything about removal. I was referring to: Warning: This module is considered out-dated and not up to Phobos' current standards. It will remain until we have a suitable replacement, but be aware that it will not remain long term. So far this does not seem a proposal that pulls own weight to me. I can put the burden on my shoulders. I'm in the middle of DIP creation. Unfortunately I have a regular job and other duties. Still, I hope to finish it as soon as promised. Piotrek
Re: Mars Drafting Library - Official community driven library
On Monday, 2 February 2015 at 21:19:01 UTC, Zach the Mystic wrote: I think std.experimental should essentially be its own library, with its own slot next to phobos on the github repo. I'm open to changing the name or something... but if we have both std.experimental *and* your new mars, what do you think is the real difference? How can std.experimental be sort of experimental, but really not, whereas mars is really actually experimental? Where is the cutoff line? How would anyone know whether they reached it or not? Hard to admit but I thought about removal of std.experimental ;), then I tried to find a better solution (not sure I did). After all I don't want to make more enemies than I have. So I got an idea that std.experimental can be adopted for the piloting new modules into Phobos when approved to be a standard. After Wikipedia: A pilot project refers to an initial roll-out of a system into production My attitude is that any given module in std.experimental should simply indicate its current level stability at the top of its documentation - full disclosure about where it is from, say, 0 to 95%, (with anything above that already assumed qualified for std proper). Yes, the drafting stage can have many sub-stages, but I didn't want to complicate the initial proposal too much and risk both low chance of the approval and later, inability of proper implementation. I learned that there can be taken only limited steps at once. I'd even make one more point, that all current phobos modules known to be in need of revamping be copied wholesale in their current forms to std.experimental, with the top documentation saying, This is the experimental version of the old std.xxx, which needs *your* help with its redesign and implementation. Feel free to break the current API by improving it. This is *not* currently considered a stable module. Haha, let's not lose our nerves :) It's not that bad. Moreover. I can barely find the equivalent level of code awesomeness as it is in D libraries. We just need to speed up the progress and reduce work fragmentation. Piotrek
Re: Mars Drafting Library - Official community driven library
On Monday, 2 February 2015 at 22:18:59 UTC, Piotrek wrote: On Monday, 2 February 2015 at 21:19:01 UTC, Zach the Mystic wrote: I think std.experimental should essentially be its own library, with its own slot next to phobos on the github repo. I'm open to changing the name or something... but if we have both std.experimental *and* your new mars, what do you think is the real difference? How can std.experimental be sort of experimental, but really not, whereas mars is really actually experimental? Where is the cutoff line? How would anyone know whether they reached it or not? Hard to admit but I thought about removal of std.experimental ;), then I tried to find a better solution (not sure I did). After all I don't want to make more enemies than I have. So I got an idea that std.experimental can be adopted for the piloting new modules into Phobos when approved to be a standard. I'm arguing from the perspective that the approval must come first, and the piloting second. Who would want to develop a module in the pre-pilot phase, without having any idea of whether they were developing it finally for phobos or just 3rd-party use, then wait months or years to find out if the leadership is even *interested* in what they're doing? Why would people try to meet high standards without knowing if those standards are actually going to be required or not? It's like an unpaid internship: Work for us for free, and we'll let you know at the end whether we want your work or not. I'd even make one more point, that all current phobos modules known to be in need of revamping be copied wholesale in their current forms to std.experimental, with the top documentation saying, This is the experimental version of the old std.xxx, which needs *your* help with its redesign and implementation. Feel free to break the current API by improving it. This is *not* currently considered a stable module. Haha, let's not lose our nerves :) It's not that bad. Moreover. I can barely find the equivalent level of code awesomeness as it is in D libraries. We just need to speed up the progress and reduce work fragmentation. It occurred to me that when copying a module to std.experimental, the documentation at the top of the original std module should say, This module has been feature frozen while work on the new one continues at std.experimental.. The API for this module will not break, nor will it be improved. Please consider using std.experimental. and giving feedback for its design, since eventually this module will be replaced with that one. I do realize that this is kind of what happened with D1 and D2, of course. Now you're going to have competing modules, and some people won't want to give up on the old one. So you will have to deprecate every change that breaks the old API first before finally replacing it with the new one. Well, it's a hard problem, and yet, Most D code has yet to be written. But then again, I'm not the one who has to take fire for breaking people's old code, and I don't know if my attitude would change if I were.
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 20:47:43 UTC, ZombineDev wrote: I like the idea of having an additional library that we would ship alongside Phobos with every release. There of course some obvious pros and cons for having 'Mars' (or whatever is called) as a DUB packages vs included in the standard library: Thanks for comments:) I'm going to address most of them. Pros being included alongside Phobos: + Better testing because more people can/will use it + Potentially better code, because of code review during pull requests and generally high standards for new stuff (like with std.experimental.logger). + More stable, because people may care more for backwards comparability (though the points is that this will not be guaranteed). + People new to the language will feel more comfortable using 'standard' libraries. + etc... Cons: - Extremely slow release cycle. There can be nightly/weekly builds if really needed. But in general, yes, release cycle would be the same as DMD package. - Hard to get new stuff (controversial like GUI) in. The key aspect of the proposal it to have that kind of functionality go through a processes of eliminating controversy as much as possible during developing stage. - Not being able to have external dependencies than druntime and Phobos (like bindings for C libraries) - etc... Being a part of official packet it is actually advantage. As an opposite example I couldn't get curl module working under Ubuntu in sensible time. I think a good compromise would be the following: 1. Include DUB with DMD. We don't need a stable DUB as a library API to just use it to get other packages. 2. Make 'Mars' a DUB package and use semantic versioning to tag new releases. 3. Move it to github.com/D-Programming-Language/. 4. Include last known 'well working' with every DMD release. (Of course other implementations are free to decide whether to include it). Or we can have some post-installation script which would call DUB. 5. Afterwards if a new version of 'Mars' is released users can just do a 'dub upgrade' to update the one that's already included, or wait for a new official release. Another good idea is to separate Phobos from DMD and also put it on DUB. As you can see[2] many of the integral parts of.NET are provided as packages and people have no problem using them as such (you can see by the large download numbers). [1]: http://blogs.msdn.com/b/dotnet/p/nugetpackages.aspx [2]: https://www.nuget.org/packages This proposal's aim is to be the least intrusive so that kind of changes are out of the scope. DMD and Phobos are often coupled in terms of changes (bug fixes etc). I'm against moving standard library to DUB. Piotrek
Re: Mars Drafting Library - Official community driven library
Possible initial prerequisites: - User awareness about the usage consequences - Library placed at https://github.com/D-Programming-Language/ - Only well recognized community members have pull rights - design decision made on the best known sw engineering patterns used in D - New module should be functional with D/Phobos standards applied - API and implementation allowed to change any time in order to make a progress - no external dependencies beside OS services - draft as the root module name e.g. module draft.gui Advantages: - community driven process which ensures the lowest level of controversy - fast path for modules like GUI to be standardized Disadvantages: - additional effort for the sw release process Ready to be destroyed ;) Piotrek Approximately a half year ago I have similar idea and suggestion. This is my idea: * make new feature in dub, that it can place some libraries in common namespace. For example CyberShadow's ae will be placed in something like advancex.image, or logger (lucky it is in std.experimental already, but as alternative history) is placed in stdx.logger. But they are not part of phobos in that time but usual dub package on dub registry. * create namespaces advance (or any other) for useful but not so common components (e.g. proposal windowing, image processing an so on), bind for Deimos. Phobos is std already :). And also create their experimental counterpart like advancex, bindx and stdx. (It can be other name but I prefer one worded stdx than two worded std.experimental in other level of hierarchy). * make new feature in dub and dub register that counts download, likes and bugs. When some package receives essential feedback it can be started pull request process. * all packages in special namespaces can't be orphan. Experimental version must have at least one active maintainer. More approved namespace require two responsible maintainer one of which at least someone from trusted user. If package became orphan it will be dropped out. In this manner we can create stair like development. To place simple package in dub registry you have the same condition as for now. If you want place it in experimental namespace you must complete some easy condition (more complicated in case of stdx and perhaps bindx), and you package must go through full review process in case of phobos. You can see on archlinux as example of such package management. For now I drive two interesting project, but I also try to find forces for this one.
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 20:55:11 UTC, Jonathan Marler wrote: On Saturday, 31 January 2015 at 14:06:20 UTC, Piotrek wrote: Hi, The history of std.(experimental.)logger and the latest thread about gui functionality inclusion into Phobos made me think about how to solve the problem of adding new modules. I came up with the idea (maybe not new) to create a additional library(along druntime and Phobos) delivered with dmd package and named Mars (Deimos is unfortunately already taken ). The library itself would be driven by community (not individual library developer) in order to be... the standard. The process would be something similar to that other committees use (e.g http://www.iec.ch/standardsdev/how/processes/development/) where before the standard is approved it goes through a draft stage. Still a draft can be used to create a working product (e.g. some Wi-Fi solutions based on IEEE 802.11 drafts) Possible initial prerequisites: - User awareness about the usage consequences - Library placed at https://github.com/D-Programming-Language/ - Only well recognized community members have pull rights - design decision made on the best known sw engineering patterns used in D - New module should be functional with D/Phobos standards applied - API and implementation allowed to change any time in order to make a progress - no external dependencies beside OS services - draft as the root module name e.g. module draft.gui Advantages: - community driven process which ensures the lowest level of controversy - fast path for modules like GUI to be standardized Disadvantages: - additional effort for the sw release process Ready to be destroyed ;) Piotrek I approve :) +1 Thanks for your vote. If there is no official veto to the proposal, I will create a DIP in a day or two. Meanwhile, we can still discuss unclear or problematic issues. Piotrek
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 23:03:52 UTC, Piotrek wrote: On Saturday, 31 January 2015 at 20:34:32 UTC, Zach the Mystic wrote: The most important thing about a standard library is decisiveness in the leadership about what *kinds* of things should be in it. When it's been made clear that a given task is worthy of inclusion in the standard library, there will be enough incentive for contributors to put in the time and effort required to meet its high standards. The intention of creating draft modules would be the inclusion in Phobos. In simplistic way, the following stages of development will be applied: 1. Proposal (DIP, NG discussion, DUB package showcase, local meet-up events etc) 2. Draft module creation and development 3 Approval for Phobos merge, i.e. draft - std I really can't see the difference between `std.experimental` and this. If `std.experimental` doesn't get used for this, `std.experimental` will end up a marginalized experiment itself. I think `std.experimental` runs the huge risk of not being recognized as what it is - i.e. a shop for building things (from scratch if necessary, IMO). If you're not worried about the name Mars, why are you worried about `std.experimental`? But there are so many tasks that aren't quite up to that bar, either because they serve too specific a niche, or because there are two or more good, but conflicting ways to implement solutions, and no good way to decide between them. For any such task that doesn't meet those high standards, the library's development is best left to the community. But there is a place for the official recognition of existing libraries which have reached a level of quality that can be safely recommended. This is what is currently missing. To be clear. I treat current DMD and Phobos library development as community driven as well. The reason, the title includes community driven is that modules can't be made by independent developer, i.e. without community approval. As an example DUB packages don't fulfill this requirement. This is more of a second-party library system, for which idea I am indebted to this article: http://www.jfbillingsley.com/blog/?p=206 Suggestions for implementation? I briefly read the article and some parts are similar. However the difference is that Curiosity/Mars would form some kind of trinity with Druntime and Phobos. See also my answer to weaselcat's post (http://forum.dlang.org/post/mtqjtavxzjucixuyc...@forum.dlang.org). Piotrek Yes, we're basically talking about the two categories I mentioned to begin with. You're focusing on those libraries which can be pre-approved as worthy of phobos. The way I figure it, only Andrei and Walter can ultimately give pre-approval for such libraries. But I think the second kind I mentioned -- high-quality libraries which aren't suited for phobos -- also need official, or at least prominent, recognition. It's really important for people not to have to investigate every program listed on code.lang.org in order to find high-quality existing code. I would even argue that such recognition is more important than the library you're proposing here (which already seems to exist with `std.experimental`). Meeting the pre-approval standards for phobos is a very high bar, and it certainly won't be the majority of high-quality libraries.
Re: Mars Drafting Library - Official community driven library
Things are never quite the same, but it is still interesting to remind oneself of experience in other languages. History of numpy /scipy here: http://wiki.scipy.org/History_of_SciPy Would it have made the cut if it had had to meet an std.experimental level of quality in its earlier days ? And the fact that it didn't allowed also for greater flexibility of development and for exploring multiple approaches (eventually recombined). New growth often comes from the fringes and so won't be recognised until so many people are using it it can no longer be ignored. It is important then to have less regulated interstices where such things can prove themselves. So it might be worth asking directly the leading library authors what they think, since if people have no interest in filling out DIPs then it is good to know what the trade off might be (rigour versus creative work).
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 14:40:17 UTC, Zach the Mystic wrote: The intention of creating draft modules would be the inclusion in Phobos. In simplistic way, the following stages of development will be applied: 1. Proposal (DIP, NG discussion, DUB package showcase, local meet-up events etc) 2. Draft module creation and development 3 Approval for Phobos merge, i.e. draft - std I really can't see the difference between `std.experimental` and this. If `std.experimental` doesn't get used for this, `std.experimental` will end up a marginalized experiment itself. I think `std.experimental` runs the huge risk of not being recognized as what it is - i.e. a shop for building things (from scratch if necessary, IMO). If you're not worried about the name Mars, why are you worried about `std.experimental`? I initially thought about the std.experimental, but came up to the conclusion that when modules are in drafting stage they shouldn't pollute the Phobos. Basically because the final standard is not defined. A simple distinction can be seen as follows: draft - drafting std.experimental - piloting The Drafting library can be omitted during DMD installation without any harm for Druntime and Phobos. I briefly read the article and some parts are similar. However the difference is that Curiosity/Mars would form some kind of trinity with Druntime and Phobos. See also my answer to weaselcat's post (http://forum.dlang.org/post/mtqjtavxzjucixuyc...@forum.dlang.org). Piotrek Yes, we're basically talking about the two categories I mentioned to begin with. You're focusing on those libraries which can be pre-approved as worthy of phobos. The way I figure it, only Andrei and Walter can ultimately give pre-approval for such libraries. I don't treat Walter and Andrei as a blocking point. I think they will do anything is good for the language. Many time the D community initiated successful campaigns seconded by the key designers. But I think the second kind I mentioned -- high-quality libraries which aren't suited for phobos -- also need official, or at least prominent, recognition. It's really important for people not to have to investigate every program listed on code.lang.org in order to find high-quality existing code. I would even argue that such recognition is more important than the library you're proposing here (which already seems to exist with `std.experimental`). I truly agree that there are many valuable DUB packages needing the advertisement. However this is out of the scope of the proposal. Piotrek
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 21:54:13 UTC, Dicebot wrote: Just few quick questions: Hi 1) what would it give over std.experimental ? - draft modules will be more flexible for changes than in the ones in standard library - new drafting modules won't disturb usual users of the standard library IMO, std.experimental is not for the drafting stage of the SW development. 2) what would it give over code.dlang.org ? - community driven as opposed to individual driven - out of the box readiness - minimal fragmentation and controversy 3) what problems are you trying to solve and why do you think this is suitable solution? Adding new modules (replacing the deprecated ones) in more robust and quicker manner. IMO, this is a change in the direction how standards are made. Piotrek
Re: Mars Drafting Library - Official community driven library
Just few quick questions: 1) what would it give over std.experimental ? 2) what would it give over code.dlang.org ? 3) what problems are you trying to solve and why do you think this is suitable solution?
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 09:28:42 UTC, HaraldZealot wrote: Approximately a half year ago I have similar idea and suggestion. Thanks for your input. Yes, there are similarities, but there are also some differences. See some of my comments below: This is my idea: * make new feature in dub, that it can place some libraries in common namespace. For example CyberShadow's ae will be placed in something like advancex.image, or logger (lucky it is in std.experimental already, but as alternative history) is placed in stdx.logger. But they are not part of phobos in that time but usual dub package on dub registry. * create namespaces advance (or any other) for useful but not so common components (e.g. proposal windowing, image processing an so on), bind for Deimos. Phobos is std already :). And also create their experimental counterpart like advancex, bindx and stdx. (It can be other name but I prefer one worded stdx than two worded std.experimental in other level of hierarchy). This differ from the Drafting Library proposal in the following points: - modules/packages are owned/driven by one developer - dub packages are not inclined to work out of the box with dmd release package * make new feature in dub and dub register that counts download, likes and bugs. When some package receives essential feedback it can be started pull request process. By the pull request process you mean inclusion in Phobos? Then, in result, wouldn't it just mean: make the most popular dub package in some category a standard? For now I drive two interesting project, but I also try to find forces for this one. The important thing about the proposal is to provide a process so one can be a part in creating the standard. You could contribute to drafts for the modules related to areas of your expertise. Piotrek
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 22:57:07 UTC, Piotrek wrote: On Sunday, 1 February 2015 at 22:45:32 UTC, Dicebot wrote: came up to the conclusion that when modules are in drafting stage they shouldn't pollute the Phobos This is does not seem a strong enough point to warrant extra maintenance effort and extra newbie confusion. Newbie confusion? In what way? What library to use between Phobos and Mars, why those are separate, why those have different stability guranatees, where to submit new contributions, why bother - it all would need to be written down and explained over and over again. And this alone is huge -.
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 22:54:51 UTC, Piotrek wrote: On Sunday, 1 February 2015 at 21:54:13 UTC, Dicebot wrote: Just few quick questions: Hi 1) what would it give over std.experimental ? - draft modules will be more flexible for changes than in the ones in standard library As per latest agreement everything in std.experimental is considered subject to any change so is perfectly flexible. - new drafting modules won't disturb usual users of the standard library That statements needs some hard data that current situation is disturbing to be considered as a rationale. IMO, std.experimental is not for the drafting stage of the SW development. Depends on your definition of draft. Anything that is good enough to be actually used in real app is good enough for std.experimental - and anything less is of no use to end user anyway. 2) what would it give over code.dlang.org ? - community driven as opposed to individual driven - out of the box readiness - minimal fragmentation and controversy code.dlang.org is actually much more community driven because it is naturally decentralized. Controversy is inevitable anyway (hello std.json). Fragmentation is a thing though - but I yet to be convinced that is a bad thing that needs to be fixed. 3) what problems are you trying to solve and why do you think this is suitable solution? Adding new modules (replacing the deprecated ones) in more robust and quicker manner. It is as quick as it can be for standard library - and code.dlang.org takes care of everything else. Any library that risks quick removal of deprecated modules / API is not acceptable for standard stamp. So far this does not seem a proposal that pulls own weight to me.
Re: Mars Drafting Library - Official community driven library
came up to the conclusion that when modules are in drafting stage they shouldn't pollute the Phobos This is does not seem a strong enough point to warrant extra maintenance effort and extra newbie confusion.
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 22:45:32 UTC, Dicebot wrote: came up to the conclusion that when modules are in drafting stage they shouldn't pollute the Phobos This is does not seem a strong enough point to warrant extra maintenance effort and extra newbie confusion. Newbie confusion? In what way? Piotrek
Re: Mars Drafting Library - Official community driven library
On Monday, 2 February 2015 at 03:58:44 UTC, Tofu Ninja wrote: One thing that would definitely help with the situation is a better code.dlang.org site with ratings, tags, categories, and comments. Also it would be great to advertise some of the better packages by putting them on a more prominent display in something like a featured section. I think this is much better approach in the long-term. CI result integration fits the same purpose. This is one task where getting some paid help from professinal web devs may be important.
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 14:40:17 UTC, Zach the Mystic wrote: Yes, we're basically talking about the two categories I mentioned to begin with. You're focusing on those libraries which can be pre-approved as worthy of phobos. The way I figure it, only Andrei and Walter can ultimately give pre-approval for such libraries. But I think the second kind I mentioned -- high-quality libraries which aren't suited for phobos -- also need official, or at least prominent, recognition. It's really important for people not to have to investigate every program listed on code.lang.org in order to find high-quality existing code. I would even argue that such recognition is more important than the library you're proposing here (which already seems to exist with `std.experimental`). Meeting the pre-approval standards for phobos is a very high bar, and it certainly won't be the majority of high-quality libraries. I tend to agree with this. I am not sure how another library with phobos level requirements would actually help. To me is seems like std.experimental, just with a different name. The problems with code.dlang.org seem to be a more important thing to focus on. One thing that is a downside of code.dlang.org is that it is hard to tell which libraries are good, which are bad, and it is hard to find what does what. One thing that would definitely help with the situation is a better code.dlang.org site with ratings, tags, categories, and comments. Also it would be great to advertise some of the better packages by putting them on a more prominent display in something like a featured section. I really wish I knew website design, then I could help with some of this stuff rather than just talking about it.
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 22:54:51 UTC, Piotrek wrote: On Sunday, 1 February 2015 at 21:54:13 UTC, Dicebot wrote: 1) what would it give over std.experimental ? - draft modules will be more flexible for changes than in the ones in standard library - new drafting modules won't disturb usual users of the standard library IMO, std.experimental is not for the drafting stage of the SW development. I don't see the return on investment for making a big distinction between a draft and a more polished, but still not guaranteed library. The big line that needs to be drawn is whether any given task is or is not an appropriate target for the standard library. Once something passes that stage, it needs to be decided whether the API is in flux (e.g. std.experimental) or stable (e.g. std proper). An additional distinction between more in flux (your idea) and less in flux (std.experimental) is both less useful and quite possibly dangerous: The big temptation for software developers is to *promise* stability in order to attract the users they need in order to get the feedback they need in order to create the best possible design, and then break stability with the new design. By dividing libraries into the hazy more in flux and less in flux categories, one is simply deferring the hard choice between stable and not stable, and likely to start making promises one cannot -- or worse, does not even intend to -- keep as a result. Therefore, I think std.experimental is for all in flux APIs, from the drafting stage to the later less in flux stages. The danger is that the phobos management will want to have their cake and eat it too, as the saying goes. You simply can't promise users both stability and a perfectly designed API at the same time, tempting as it is.
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 14:06:20 UTC, Piotrek wrote: and named Mars (Deimos is unfortunately already taken ). BTW, Mars is the name of the language, before people started calling it D (which stuck).
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 14:33:35 UTC, Vladimir Panteleev wrote: On Saturday, 31 January 2015 at 14:06:20 UTC, Piotrek wrote: and named Mars (Deimos is unfortunately already taken ). BTW, Mars is the name of the language, before people started calling it D (which stuck). I know that, but the naming is the least important aspect of the proposal. We can refarm the unused Mars name or choose another one, maybe Curiosity, or anything suitable ;) Piotrek
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 18:11:48 UTC, Laeeth Isharc wrote: This has the advantage over existing situation where you have the official library where things need to go through exacting and time consuming process and then dub. Within dub every project is at the same level and it is not obvious which projects are the ones to use, and there is not necessarily coherence in the different ways things are done, and the only one motivated to work on supplementary features like documentation is the project author. So you have very useful, well written libraries that have no docs. What i hate about dub is that no every library is ready to use. Some require additional steps/resources in order to get them to work. Dub does not have any indication of that because the library authors dont usually include that information. What is good about this extra community driven standard library is that everything will be included in one place and will be at the ready when it is needed.
Re: Mars Drafting Library - Official community driven library
This has the advantage over existing situation where you have the official library where things need to go through exacting and time consuming process and then dub. Within dub every project is at the same level and it is not obvious which projects are the ones to use, and there is not necessarily coherence in the different ways things are done, and the only one motivated to work on supplementary features like documentation is the project author. So you have very useful, well written libraries that have no docs.
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 18:45:13 UTC, Israel wrote: On Saturday, 31 January 2015 at 18:11:48 UTC, Laeeth Isharc wrote: This has the advantage over existing situation where you have the official library where things need to go through exacting and time consuming process and then dub. Within dub every project is at the same level and it is not obvious which projects are the ones to use, and there is not necessarily coherence in the different ways things are done, and the only one motivated to work on supplementary features like documentation is the project author. So you have very useful, well written libraries that have no docs. What i hate about dub is that no every library is ready to use. Some require additional steps/resources in order to get them to work. Dub does not have any indication of that because the library authors dont usually include that information. What is good about this extra community driven standard library is that everything will be included in one place and will be at the ready when it is needed. Well, I certainly do appreciate that all these libraries exist and, as D matures, better documentation a and a general tidying up will surely be part of that process, as has already begun with phobos. There is something of a hacker disdain for docs - they are not fun to write (for most people), and one thinks that a few pointers should be enough for someone to figure it out. And that's true, for someone like the author of the code. But it is hard to imagine what it is like not to have the skillset and experience one has. And so it is a very different experience for the new user coming from python than what he experienced when he learnt python, even though if you have the basic ability D need not be intrinsically harder. The division of labour makes sense - the people who like and are good at writing docs are not necessarily those who like and are good at writing code. But its harder to recruit helpers for a personal project than a shared library.
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 14:06:20 UTC, Piotrek wrote: Hi, The history of std.(experimental.)logger and the latest thread about gui functionality inclusion into Phobos made me think about how to solve the problem of adding new modules. I came up with the idea (maybe not new) to create a additional library(along druntime and Phobos) delivered with dmd package and named Mars (Deimos is unfortunately already taken ). The library itself would be driven by community (not individual library developer) in order to be... the standard. The process would be something similar to that other committees use (e.g http://www.iec.ch/standardsdev/how/processes/development/) where before the standard is approved it goes through a draft stage. Still a draft can be used to create a working product (e.g. some Wi-Fi solutions based on IEEE 802.11 drafts) Possible initial prerequisites: - User awareness about the usage consequences - Library placed at https://github.com/D-Programming-Language/ - Only well recognized community members have pull rights - design decision made on the best known sw engineering patterns used in D - New module should be functional with D/Phobos standards applied - API and implementation allowed to change any time in order to make a progress - no external dependencies beside OS services - draft as the root module name e.g. module draft.gui Advantages: - community driven process which ensures the lowest level of controversy - fast path for modules like GUI to be standardized Disadvantages: - additional effort for the sw release process Ready to be destroyed ;) Piotrek The most important thing about a standard library is decisiveness in the leadership about what *kinds* of things should be in it. When it's been made clear that a given task is worthy of inclusion in the standard library, there will be enough incentive for contributors to put in the time and effort required to meet its high standards. But there are so many tasks that aren't quite up to that bar, either because they serve too specific a niche, or because there are two or more good, but conflicting ways to implement solutions, and no good way to decide between them. For any such task that doesn't meet those high standards, the library's development is best left to the community. But there is a place for the official recognition of existing libraries which have reached a level of quality that can be safely recommended. This is what is currently missing. There needs to be a page for this. The existing Wiki page: http://wiki.dlang.org/Libraries_and_Frameworks ... suffers from exactly the same problem as code.dlang.org. It contains everything in existence. This is more of a second-party library system, for which idea I am indebted to this article: http://www.jfbillingsley.com/blog/?p=206 Suggestions for implementation?
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 19:03:55 UTC, Laeeth Isharc wrote: On Saturday, 31 January 2015 at 18:45:13 UTC, Israel wrote: the people who like and are good at writing docs are not necessarily those who like and are good at writing code. This is exactly how i feel.
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 14:06:20 UTC, Piotrek wrote: ... +1, basically boost for D. I heavily agree that the libraries should complement Phobos and never be orthogonal to phobos lest we have another tangos/phobos situation.
Re: Mars Drafting Library - Official community driven library
On 1/31/2015 7:10 AM, Piotrek wrote: I know that, but the naming is the least important aspect of the proposal. I agree. Let's not have endless posts bikeshedding the name, no matter how tempting.
Re: Mars Drafting Library - Official community driven library
I like the idea of having an additional library that we would ship alongside Phobos with every release. There of course some obvious pros and cons for having 'Mars' (or whatever is called) as a DUB packages vs included in the standard library: Pros for being a DUB package: + faster release cycles (push a new version any time). + semantic versioning (instead of dmd 2.0xx). + can depend on other DUB packages (doesn't need to include everything it uses beside Phobos, ofc). + can have different configurations / build types, be split in DUB subpackages and all the other nice things that the DUB package format provides. + can include other binaries (eg. C libs). + etc... Cons: - Probably not so well tested, because it won't get as wildly used as Phobos. - Third-party with zero guarantees. (You have to trust the author(s) that it is not malicious or anything like that). - Not everybody is comfortable with having DUB as a dependency on their project. - Can be a bit of an inconvenience if you only want to write a small script. - DUB doesn't have first class support in the major IDEs, AFAIK (for people that prefer them over the terminal). Actually I thing it's extremely simple to use on the command-ling and I have no problem with Mono-D or dub generate visuald, but it's not like the NuGet support in VS for .NET projects (AFAIR you can now have language plugins/analyzers based on Roslyn (linting, DSLs, etc.) which are NuGet packages that you download from their gallery). - etc... Pros being included alongside Phobos: + Better testing because more people can/will use it + Potentially better code, because of code review during pull requests and generally high standards for new stuff (like with std.experimental.logger). + More stable, because people may care more for backwards comparability (though the points is that this will not be guaranteed). + People new to the language will feel more comfortable using 'standard' libraries. + etc... Cons: - Extremely slow release cycle. - Hard to get new stuff (controversial like GUI) in. - Not being able to have external dependencies than druntime and Phobos (like bindings for C libraries) - etc... With all that said I still think that it is a good idea to have another library shipping alongside Phobos with every DMD release (or GDC, LDC, etc.). I think a good compromise would be the following: 1. Include DUB with DMD. We don't need a stable DUB as a library API to just use it to get other packages. 2. Make 'Mars' a DUB package and use semantic versioning to tag new releases. 3. Move it to github.com/D-Programming-Language/. 4. Include last known 'well working' with every DMD release. (Of course other implementations are free to decide whether to include it). Or we can have some post-installation script which would call DUB. 5. Afterwards if a new version of 'Mars' is released users can just do a 'dub upgrade' to update the one that's already included, or wait for a new official release. I really do thing that this would be a step in the right direction. For example Microsoft has been been using their package manager NuGet as a .NET Framework release vehicle quite successfully for the last couple of years. Here[1] you can see that they are providing quite large and heavily used parts of .NET. Another good idea is to separate Phobos from DMD and also put it on DUB. As you can see[2] many of the integral parts of.NET are provided as packages and people have no problem using them as such (you can see by the large download numbers). [1]: http://blogs.msdn.com/b/dotnet/p/nugetpackages.aspx [2]: https://www.nuget.org/packages
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 14:06:20 UTC, Piotrek wrote: Hi, The history of std.(experimental.)logger and the latest thread about gui functionality inclusion into Phobos made me think about how to solve the problem of adding new modules. I came up with the idea (maybe not new) to create a additional library(along druntime and Phobos) delivered with dmd package and named Mars (Deimos is unfortunately already taken ). The library itself would be driven by community (not individual library developer) in order to be... the standard. The process would be something similar to that other committees use (e.g http://www.iec.ch/standardsdev/how/processes/development/) where before the standard is approved it goes through a draft stage. Still a draft can be used to create a working product (e.g. some Wi-Fi solutions based on IEEE 802.11 drafts) Possible initial prerequisites: - User awareness about the usage consequences - Library placed at https://github.com/D-Programming-Language/ - Only well recognized community members have pull rights - design decision made on the best known sw engineering patterns used in D - New module should be functional with D/Phobos standards applied - API and implementation allowed to change any time in order to make a progress - no external dependencies beside OS services - draft as the root module name e.g. module draft.gui Advantages: - community driven process which ensures the lowest level of controversy - fast path for modules like GUI to be standardized Disadvantages: - additional effort for the sw release process Ready to be destroyed ;) Piotrek I approve :) +1
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 18:45:13 UTC, Israel wrote: On Saturday, 31 January 2015 at 18:11:48 UTC, Laeeth Isharc wrote: This has the advantage over existing situation where you have the official library where things need to go through exacting and time consuming process and then dub. Within dub every project is at the same level and it is not obvious which projects are the ones to use, and there is not necessarily coherence in the different ways things are done, and the only one motivated to work on supplementary features like documentation is the project author. So you have very useful, well written libraries that have no docs. What i hate about dub is that no every library is ready to use. Some require additional steps/resources in order to get them to work. Dub does not have any indication of that because the library authors don't usually include that information. What is good about this extra community driven standard library is that everything will be included in one place and will be at the ready when it is needed. Thanks. I wanted to mention the DUB packages but the post would be too long. DUB can be seen as a repository of special purpose packages without the burden of standardization process and out of the box properties. In general, this proposal assumes DUB repository will serve the same role as it does now. Piotrek
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 20:34:32 UTC, Zach the Mystic wrote: The most important thing about a standard library is decisiveness in the leadership about what *kinds* of things should be in it. When it's been made clear that a given task is worthy of inclusion in the standard library, there will be enough incentive for contributors to put in the time and effort required to meet its high standards. The intention of creating draft modules would be the inclusion in Phobos. In simplistic way, the following stages of development will be applied: 1. Proposal (DIP, NG discussion, DUB package showcase, local meet-up events etc) 2. Draft module creation and development 3 Approval for Phobos merge, i.e. draft - std But there are so many tasks that aren't quite up to that bar, either because they serve too specific a niche, or because there are two or more good, but conflicting ways to implement solutions, and no good way to decide between them. For any such task that doesn't meet those high standards, the library's development is best left to the community. But there is a place for the official recognition of existing libraries which have reached a level of quality that can be safely recommended. This is what is currently missing. To be clear. I treat current DMD and Phobos library development as community driven as well. The reason, the title includes community driven is that modules can't be made by independent developer, i.e. without community approval. As an example DUB packages don't fulfill this requirement. This is more of a second-party library system, for which idea I am indebted to this article: http://www.jfbillingsley.com/blog/?p=206 Suggestions for implementation? I briefly read the article and some parts are similar. However the difference is that Curiosity/Mars would form some kind of trinity with Druntime and Phobos. See also my answer to weaselcat's post (http://forum.dlang.org/post/mtqjtavxzjucixuyc...@forum.dlang.org). Piotrek
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 20:44:38 UTC, weaselcat wrote: On Saturday, 31 January 2015 at 14:06:20 UTC, Piotrek wrote: ... +1, basically boost for D. I heavily agree that the libraries should complement Phobos and never be orthogonal to phobos lest we have another tangos/phobos situation. Several points from prerequisites was intensionally chosen to prevent Phobos/Tango fiasco. The general rule is that the draft module should be treated as a potential Phobos module. Piotrek
Re: Mars Drafting Library - Official community driven library
On Saturday, 31 January 2015 at 20:48:01 UTC, Walter Bright wrote: On 1/31/2015 7:10 AM, Piotrek wrote: I know that, but the naming is the least important aspect of the proposal. I agree. Let's not have endless posts bikeshedding the name, no matter how tempting. Yeah, lets just call it Tango and get it over with.
