On Wednesday, 6 February 2013 at 22:25:03 UTC, Brad Anderson wrote:
> Reading more, it looks like Dub is his attempt to make VPM less Vibe.d specific and more for general D use.  It even generates VisualD project files.
>
> Cool stuff.
>
> BA

Yeah, I'm leaning towards DUB for a few reasons.

The implementation is written in idiomatic D2; it's much more likely to attract contributors this way.

The online package registry is already up and is entirely powered by vibe.d and its ecosystem: we're eating our own dog food throughout.

Also, using a data format (JSON, in this case) over a scripting language has its advantages. With DUB, there is only one piece of software you need to trust (which is DUB itself), as the package description file is not software. It's possible to do things like automatically building packages without having to vet a build script's quality. I'm not sure how sound this point really is, but it feels right (for what little it's worth...).

On 02/07/2013 03:58 AM, deadalnix wrote:
> ... my cod break at any new dmd release (and right now compile with none released one).

+1. (I keep reporting regressions though, dustmite works quite well.)

On 2013-02-07 09:19, Jacob Carlborg wrote:
> That's way I originally chose Ruby, because it can look just like JSON:
>
> foo = {
>    a: 3,
>    b: 4
> }

This looks like JSON but doesn't look like Ruby. :)

Am Thu, 07 Feb 2013 05:19:56 +0100
schrieb "Vladimir Panteleev" <vladimir@thecybershadow.net>:

> On Wednesday, 6 February 2013 at 21:07:24 UTC, Walter Bright wrote:
> > On 2/6/2013 12:15 AM, Jonathan M Davis wrote:
> > > I don't think that it's generally worth trying to rearrange the modules that we already have. So, adding std.halffloat
> > would be bad, but I'm
> > > not sure that it's worth doing something like moving std.uri
> > into std.net.
> > > Even if we did, we'd be forced to leave std.uri around for
> > quite some time
> >
> > At least the contents of std.uri can be nothing more than:
> >
> >   module std.uri;
> >   public import std.net.uri;
> 
> Just throwing in an idea, in case no one mentioned it yet:
> 
> To avoid cluttering the Phobos directory structure, documentation, makefiles, etc. with redirect modules, the redirect modules can be placed in a completely separate directory (which would also have a "std" subdirectory), which would be added to sc.ini/dmd.conf's include path.

That's cool. Together with the other proposals I think we have enough infrastructure ready to solve all problems with module updates and moves. You can also remove that line from dmd.conf and add it only to project configurations with 'legacy' code. Since IDEs like Mono-D already scan available modules in the include paths for imports, this would reduce the noise a bit.

-- 
Marco

Am Thu, 07 Feb 2013 04:02:29 +0100
schrieb "deadalnix" <deadalnix@gmail.com>:

> Well if JSON syntax is better than D's why D don' use JSON syntax in the first place ?

JSON is a well known format. The benefit is, parsers exist for every practical language and developers know by heart the syntax and can start editing. And mixing a data definition language with a programming language doesn't work here. Maybe if this was the LISP news group... :)

-- 
Marco

Am Wed, 06 Feb 2013 23:06:06 -0500
schrieb Chad Joan <chadjoan@gmail.com>:

> I just want to say "PLEASE YES".  Phobos' module hierarchy is currently confusing at best, especially with various important elements being scattered across std.range, std.algorithm, std.array, and maybe another I'm forgetting.  Although I can sort of see the logic behind this convention, it is very hard to think of a function that operates on ranges and automatically know which module to look in.  I'm rambling, sorry.
> 
> PLEASE YES!

It is true.
I've had the same discussion on IRC a while ago. After
letting off some steam, I had the idea to make a map of
Phobos by functionality instead of module.

Sometimes simple stuff confuses me: is .empty in std.array or std.range? And why is it not a standard property of arrays? The module borders seem washy in std.rangorithray.

String formatting is another example with functions spread
over conv/string/format for: 'xformat' (std.string),
'text' (std.conv) or 'formattedWrite' (std.format).
Add manipulation to the list and the function you look for may
even be generalized in std.algorithm, like 'startsWith'.

String slicing/concatenation: 'stripRight' (std.string),
'startsWith' (std.algorithm), 'join' (std.array)

Text I/O: 'readText' (std.file), 'byLine' (std.stdio)

Temporary files: 'tmpfile' (std.stdio), 'tempDir' (std.file)

Charsets: 'toMBSz' (std.windows.charset),
'transcode' (std.encoding), 'toUTF16' (std.utf)

Memory streams: 'MemoryStream' (std.stream),
'OutBuffer' (std.outbuffer)

... and so on ...

-- 
Marco

On Wednesday, 6 February 2013 at 07:56:26 UTC, Don wrote:
> In the "Implementing Half Floats in D" thread, we seemed to have reached a consensus on two important points:
> (a) Phobos should have a broad scope (rather than being small like the C standard library).
> (b) The current flat structure of Phobos (every module in the root) does not scale to hundreds of modules.
>
> It's not quite unanimous on (a), but seems to be close enough.
>
> Together, (a) and (b) mean we need a plan. The sooner we can do it, the less painful it will be. But, on the other hand, it's something that we really don't want to get wrong.
>
> Personal taste plays a huge role in this (Practically any structure can work, but we're looking for an arrangement which is intuitive and aesthetically pleasing to as many people as possible). It'll be most productive to stick to uncontroversial facts as long as possible.
>
> It would be great if people with extensive experience in other languages could give a brief description of the structure of the corresponding libraries. (Also include pseudo-standard libraries, for example boost in C++).
>
> 1. How many total modules are there? How old is the library? What is the recent growth rate of the library (Percentage increase in size per year, over whatever time interval is reasonable for that library)?
> 2. How deep is the hierarchy? How many top-level branches are there?
> 3. How has the library dealt with obsolete functions and modules? Eg, are there entire top-level branches which are obsolete? How many stupid names are there (eg, "std.algorithm2") which were forced by the original design becoming obsolete?
> 4. How much of the library is successful/convincing? To make it a bit less subjective: how much of the library is commonly ignored, in favour of using third-party libraries instead? Which areas are failures in this way (eg, GUI, database, ...)? Which areas are the most often praised?
>
> Maybe such a survey already exists, but I haven't been able to find an existing one.

Java Standard Library:

Total of 209 packages.

3 top-level packages:
  java  ( 56 packages, 13 top level within java)
  javax (117 packages, 20 top level within javax)
  org   ( 36 packages,  4 top-level within org)

Max depth of package tree:

  5

Duplicated Names:

  java.io and java.nio (new io)
  java.net and javax.net
  java.lang and javax.lang

Note that javax was initially intended to be an experimental library where its packages would get moved to the java library eventually. But the first time they tried to move a package from javax to java there were a lot of complaints. Too much broken code. So the experimental library become an addition to the standard library.

Paul

On Thursday, February 07, 2013 13:17:20 Jacob Carlborg wrote:
> On 2013-02-06 18:22, Andrei Alexandrescu wrote:
> > I understand. The way I see this is as an motivation and opportunity to add the necessary functionality to Phobos. I may be uninformed, but the way I see it basic package management doesn't have to be very demanding on library functionality.
> 
> No it doesn't need to have a demanding library functionality. But I have creating these libraries because they contain common code I use in several of my tools and libraries. I think duplicating that code just to avoid having any library dependencies would be quite foolish.
> 
> The reason why I use Tango is that it contains functionality that is either missing or not good enough in Phobos. Also, remember that I started this project several years ago.

All of which is fine as long as it's a 3rd party project. I think that Andrei's point is that if you have any interest in it being D's official package manager, it needs to be changed to use Phobos only, even if that requires adding or improving functionality in Phobos. An official package manager can't rely on 3rd party libraries or tools.

So, either Orbit needs to be updated to not depend on anything beyond D's standard library, or it should stop being presented as a possible official package manager. That's not saying anything bad about the project or the work that you've done. It's just saying that it does not currently fit the requirements for an official project.

- Jonathan M Davis

On Wednesday, 6 February 2013 at 18:47:35 UTC, Brad Anderson wrote:
> On Wednesday, 6 February 2013 at 11:38:31 UTC, Dicebot wrote:
>> AFAIR there was proposal of a "future" meta package for introducing new modules with time to adapt, similar to how it is done in few other languages.
>
> I really like the idea of an experimental section of phobos. I've been thinking lately that the phobos review might be improved by doing something more like this:
>
> 1. Proposal
> 2. Review and vote of overall usefulness and whether it meets a certain quality requirement.
> 3. Module is placed in experimental section of phobos with strong warnings that it is a trial module and could be removed in a future update.
> 4. Following a set period of time after the module has been in a public release another vote is held for actual inclusion.
> 5. If yea, move to its final resting place, if nay remove it for the experimental section.
>
> People are much more likely to actually test something if it's right at their fingertips and they don't have to download it and set up module paths and all of that. This isn't particularly hard with D but I think the easier it is for people to do, the better the reviews and module quality will be. Also, giving a hard time period within which the module can be modified freely because nobody expects it to be set in stone would help a lot.
>
> BA

Just one last idea I had I'd like to share before I forget about it.  I think module reviews should, in part, come in the form of pull requests. High level reviews need discussion so they would still be done here on the forums but simple documentation fixes and other tweaks would be better handled by pull requests on the module's home repo.  Seems silly that people will type up all of their suggestions and then the module author will slowly go through the review responses looking for changes he should be making when actually making the changes and sending a pull request would take less time and as well as some of the huge burden off of the author of the module.

BA

On 2013-02-06 23:00, Andrei Alexandrescu wrote:

I'll start with some top posting and summarize. I use what works. If that means using some third party library I have no problem with that. Why should I reimplement something and hope for inclusion into Phobos when there already exist a perfectly good and working implementation.

> I think one demotivating factor for both Jacob and the loosely-defined
> core D team is that we quickly reach irreducible positions on
> fundamental matter. It took literally two years for Jacob to decide to
> do away with Ruby. (Two years for real:
> https://github.com/jacob-carlborg/orbit/issues/1)

I don't understand the hate about Ruby. People have just suggested to use JSON in this thread. Ruby can use the same syntax:

foo = {
  a: 3,
  b: 4
}

Now we have
> dependencies on https://github.com/jacob-carlborg/dstack and
> https://github.com/jacob-carlborg/mambo. I took a look. This codebase is
> entirely neat and I'm glad a combination of author's talent and D makes
> the code so easy on the eyes, but there's no way we can ever make this
> part of the official distribution. It's parallel to the canon and some
> of it dedicates hundreds of lines to duplicating Phobos functionality
> with minor distinctions in functionality.

Some of these modules go back to 2007, back when I was using D1. Some are just different names for functions in Phobos which I understand what you're not thrilled about including. Some are/were missing functions that I included in my own library instead of contributing to Phobos. I don't have time to wait five months for hoping something is included into Phobos.

> I'm looking at e.g.
> https://github.com/jacob-carlborg/mambo/blob/master/mambo/arguments/Arguments.d
> which I bet money does some cool things with command-line arguments, but
> I see no reason for using it over std.getopt.

This is a wrapper around the arguments parser in Tango which and some syntax sugar. It also helps integrating Formatter, mentioned below.

Similarly
> https://github.com/jacob-carlborg/mambo/blob/master/mambo/arguments/Formatter.d
> is yet another std.format. Then,
> https://github.com/jacob-carlborg/mambo/blob/master/mambo/core/Array.d
> seems to be in the midst of a retrofitting to use std.algorithm as much
> of what it does now is do algorithm-y work with slightly changed names.

Since you wrote that comment I assume you haven't even looked at it, just the name. This module is specifically designed to automatically generate a usage/help text from the Arguments module above. I can see no such functionality in std.format, am I wrong?

> Again, this is all fine and I'm not criticizing. If the purpose is to
> build a package manager for one's own use and to amass a community of
> users around it, great. But if the purpose is to make Orbit _the_
> official package manager of the D programming language, there's no
> equivalent but distinct libraries for command-line arguments, no
> beginsWith that does what startsWith does, etc. etc. etc.

Yes, this contains new names for functions already available in std.algorithm. It also contains some tweaks here and there, convenient functions and new functionality that is missing from Phobos.

> There are three ways I see out of this: (a) Jacob goes full bore and
> ports Orbit to Phobos, and proposes the generally useful parts of his
> library for inclusion in Phobos; (b) Jacob agrees for someone else to do
> a clean room implementation of his package manager design; (c) we agree
> with the status quo with the understanding there's no more dangling of
> Orbit as a possible official package manager.

Doing some renames and similar is one thing but I have no intention of reimplementing a lot of code that is working perfectly fine and hoping for a inclusion into Phobos that most likely won't happen.

I've tried to get a review of my serialization library for several years, sure it was a form or pre-review with the promise of removing any Tango and D1 related code if it was accepted. Nobody was interested. Sure I got the usual comments, I got real feedback from a single person here, but no formal review. Thank god I didn't remove the Tango and D1 stuff, that would be been a lot of unnecessary work and wasted time. I tried to get a review several times, but I've lost interested now, since no one else was interested.

I'm also using a high level testing framework called Cucumber (uses Ruby). I'm 99% sure that you have no interest in this. It's a perfect framework to do this kind of testing I'm using it for. It's already available, working good and are supported by editors. Running tests, syntax highlighting and so on. Why should I give up that?

I'm also not a fan of putting unit tests inline. I prefer to have a completely separate directory structure for my tests. My unit tests also uses a simple unit testing library that allows to continue after a assertion failure and gives summary at the end if any tests failed. I'm pretty sure you don't want this either. It's already there, it's working fine. Why should I give up that?

I've compiled a list below of things used in Orbit (directly or indirectly) that Phobos is lacking in. Please tell me if I'm wrong:

* DStack - Is a library for helping structuring applications. It includes:
  * Handling of command line arguments
  * Components
  * Commands
  * Starting and initializing of the application
  * Configuration
I plan to add more stuff here when needed

* Serialization - Does not exist
* ConfigMap -  Does not exist. An associative array with opDispatch added to it. Allows to do things like:

auto config = ConfigMap();
config.foo = "asd";
config.bar.foo.baz = "foobar";

assert(config.foo == "asd");

* XML - The XML module is slow and has a cumbersome API

* Zip - I don't exactly remember what was wrong here. It either didn't work or I had to reimplement a lot of functionality already available in Tango.

* Net - std.curl is probably a good module but it wasn't available when I started. I also adds another dependency.

* std.process - I have not used it myself but I've heard it's not optimal

* std.getopt - Doesn't support the following:
  * Required arguments
  * Restricting the values of a given argument
  * No way to automatically create a help/usage list out of the arguments
  * Handling positional arguments
  * No support for commands/action. That is "git commit", "commit" would be the command/action
  * Handle multiple command lines
  * Validation of the arguments

Various convince functions:

* any - Opposite of empty
* last - Returns the last element of an array
* map, find and any for associative arrays
* Utility functions for handling UDA's

* isBlank - Check if a value if blank. If it's a string it's blank if it's only contains whitespace. If it you can call .empty return that. If it's a value type it's not empty. If it's a reference type and it's null it's empty

* isPresent - The opposite of isBlank

* pluralize - Takes a string and a count. If the count is greater than 1 it converts the word in the string to plural

CTFE:

* format - A simple formatting function
* indexOf
* contains
* hasField - Returns true if the given type has the given field
* fieldsOf - Returns all the fields of the given type
* TypeOfField - Returns the type of a field
* nameOfFieldAt - Returns the name of the field at the given position
* set/getValueOfField - Sets/gets the value of a field
* newInstance - Returns a new instance based on the class name or ClassInfo. Can handle any class regardless of constructors

* A couple of traits

In the end it's all about what's working.

-- 
/Jacob Carlborg