Ha! Great, I missed that. I thought it was vibe.d specific.

Thanks!
On Wed, 2013-02-06 at 22:15 +0100, Jakob Ovrum wrote:
> There is a competing project doing just that:
> 
> https://github.com/rejectedsoftware/dub

On Wednesday, 6 February 2013 at 21:55:53 UTC, Brad Anderson wrote:
> On Wednesday, 6 February 2013 at 21:16:01 UTC, Jakob Ovrum wrote:
>> On Wednesday, 6 February 2013 at 21:10:06 UTC, Walter Bright wrote:
>>> On 2/6/2013 6:03 AM, Andrei Alexandrescu wrote:
>>>> This is in a way worse because there's a tidbit of syntax for each element. I'm
>>>> thinking:
>>>>
>>>> spec = "orange";
>>>> version = "1.0.0";
>>>> author = "Jacob Carlborg";
>>>> type = "library";
>>>> files = ["a.d", "b.di"]; // an array of source files
>>>
>>> That's close enough to JSON to suggest: why not use JSON syntax?
>>
>> There is a competing project doing just that:
>>
>> https://github.com/rejectedsoftware/dub
>>
>> (doesn't look like it's been posted yet?)
>
> I asked Sönke about possibly proposing this as the official D package manager awhile back when Dub was called VPM. You can find his answer here:
>
> http://news.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/7/
>
> BA

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

On Wednesday, February 06, 2013 15:12:59 Joseph Rushton Wakeling wrote:
> On 02/06/2013 08:56 AM, 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.
> 
> Possibly naive question -- assuming that one has a package of multiple modules, how does one go about importing the whole package? Seems relevant if Phobos is to become nested.

There are a couple of DIPS which relate to that (15 and 16 IIRC), but I would point out that in languages which _do_ permit that (e.g. Java), it's fairly common to consider it bad practice and insist on importing every module explicitly.

- Jonathan M Davis

On Wednesday, 6 February 2013 at 11:33:20 UTC, Jonathan M Davis wrote:
> On Wednesday, February 06, 2013 12:06:18 deadalnix wrote:
>> Andrei made a proposal to allow transforming a module into a
>> package. It seems to me like the way to go for this.
>
> Yes, but that's a different issue. It's one thing to take std.algorithm or
> std.datetime and turn them into packages while still allowing you to import
> std.algorithm or std.datetime as before. It's quite another to completely
> replace a module with another module. To do that, you need a new module.
> Anything else will break code. The question then is what to name the new
> module.
>

If we use the package trick as proposed, a possible solution is :

std/datetime/v1.d :
// Datetime version 1

std/datetime/v2.d :
// Datetime version 2

std/datetime.d or std/datetime/package.d (or whatever) :
version(DATETIME_V1) {
    public import std.datetime.v1;
} else {
    public import std.datetime.v2;
}

> You could replace the entire module in-place, but doing so will break code,
> and Walter in particular is very much against that in general. Whatever we did
> would require allowing people to transition from one to the other and we might
> even have to leave the old one around permanently (which I don't like, but I'm
> sure that Walter would favor). Simply changing it with a new version of Phobos
> wouldn't cut it.
>

Well Walter seems very worried about breaking code, but seems unable to adopt any practice the reduce its effect, and in the facts, my cod break at any new dmd release (and right now compile with none released one).

On Wednesday, 6 February 2013 at 21:10:06 UTC, Walter Bright wrote:
> On 2/6/2013 6:03 AM, Andrei Alexandrescu wrote:
>> This is in a way worse because there's a tidbit of syntax for each element. I'm
>> thinking:
>>
>> spec = "orange";
>> version = "1.0.0";
>> author = "Jacob Carlborg";
>> type = "library";
>> files = ["a.d", "b.di"]; // an array of source files
>
> That's close enough to JSON to suggest: why not use JSON syntax?

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

On 02/06/2013 02:56 AM, 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.
>
> ...

You ask for a lot of thorough research that I don't have time to provide at the moment.

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!

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.

Am Wed, 06 Feb 2013 13:02:29 +0100
schrieb Robert <jfanatiker@gmx.at>:

> On Wed, 2013-02-06 at 08:56 +0100, Don wrote:
> > Eg, are there entire top-level branches which are obsolete? How many stupid names are there (eg, "std.algorithm2") which were
> 
> Well in order to avoid such "stupid" names, I think it would be a good idea to keep the standard library small. Include only the things that are important to be "standard" in order to ensure interoperability between libraries.

I think the opposite. When we think about more concepts in Phobos, like gui, serialization, cryptography and so on, we will be able to create the right amount of hierarchy with distinguishable names. I'm in favor of a big batteries included library.

> The benefits:
> - The base installation stays small, which might be important for
>   everything that is not a PC.

That's why we have modules and minimize dependencies between them. Years ago when Java was introduced to mobile phones the big library was no problem, because non-essential parts could be removed.

-- 
Marco

On 2013-02-06 18:35, Jens Mueller wrote:

> How about using YAML/JSON?
> name: dwt
> source: git://github.com/jacob-carlborg/dwt.git

The reason is that it will come a need for having conditions, variables and similar in the YAML/JSON file. So instead of creating a new format, or extending YAML/JSON with conditions and similar it's just easier to use a fully fledged language instead.

DSSS is a perfect example of that it's a bad idea to invent a new format. DSSS build scripts are basically an extended variant INI files. It do support some kind of conditions:

[main.d]
buildflags += -L-L.
version (Windows) {
    # do stuff
}

It just happens that if you but the first brace on its own line, or skips the space between the closing parenthesis and the opening brace it can't parse the file. That's that things I like to avoid by using a fully fledged language.

That's way I originally chose Ruby, because it can look just like JSON:

foo = {
  a: 3,
  b: 4
}

With Ruby you can get a syntax that is declarative, just like JSON/YAML.

-- 
/Jacob Carlborg

On 2013-02-06 22:09, Walter Bright wrote:

> That's close enough to JSON to suggest: why not use JSON syntax?

See: http://forum.dlang.org/thread/ugmacrokqghrrwpfovam@forum.dlang.org?page=4#post-kevo37:241gcn:241:40digitalmars.com

-- 
/Jacob Carlborg