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.

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

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

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

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/mtqjtavxzjucixuycnlf@forum.dlang.org).

Piotrek

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.

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

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

>
> 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.

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/mtqjtavxzjucixuycnlf@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.