Jacob Carlborg wrote:
> On 2013-02-06 15:03, Andrei Alexandrescu wrote:
> >Thoughts?
> 
> I was thinking having basically the same syntax. One syntax I'm not sure what to do about is the hash literal syntax Ruby uses.
> 
> orb "dwt", git: "git://github.com/jacob-carlborg/dwt.git"
> 
> https://github.com/jacob-carlborg/orbit/wiki/Integration
> 
> The above could be translated to:
> 
> orb("dwt", ["git" : "git://github.com/jacob-carlborg/dwt.git");
> 
> That doesn't look very nice.

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

Jens

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

On Wednesday, 6 February 2013 at 13:42:36 UTC, Jacob Carlborg wrote:
> On 2013-02-06 13:02, Robert wrote:
>> 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.
>>
>> Instead we should offer a central place for D libraries, like CPAN for
>> perl or http://pypi.python.org/pypi for python.
>
> Here you go:
>
> https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
>
> I will replace the Ruby code with D.

I have a dream that someday phobos will just be a metapackage in a package manager that installs a set of core modules.

What is needed to get Orbit off the ground (Kepler's law, I guess, would be the joke answer)?

BA

+1 from me. As long as we don't have a central repository, where we could have a separate phobos-staging package or something. At the moment I don't think that additions to phobos were tested much in real world before being adopted. Such an experimental section could really help and we should try to get things in there quickly, to boost the whole process a bit.

Best regards,

Robert

On Wed, 2013-02-06 at 19:47 +0100, Brad Anderson wrote:
> 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.

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;

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?

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?)

On Wednesday, 6 February 2013 at 18:56:49 UTC, Brad Anderson wrote:
> What is needed to get Orbit off the ground (Kepler's law, I guess, would be the joke answer)?

Somebody actually working on it.

No offense, Jacob, but to me it seems like you have quite a few interesting projects (DVM, DStep, Orbit, …), and although you are usually quick to advertise them here, it seems that none of them is quite ready for prime time.

Maybe concentrating your efforts on one of them would be a good idea? Otherwise, you'll inevitably leave behind a trail of broken expectations as you cannot realistically expect to support all of them at the same time…

David

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

On 2/6/13 4:24 PM, David Nadlinger wrote:
> On Wednesday, 6 February 2013 at 18:56:49 UTC, Brad Anderson wrote:
>> What is needed to get Orbit off the ground (Kepler's law, I guess,
>> would be the joke answer)?
>
> Somebody actually working on it.
>
> No offense, Jacob, but to me it seems like you have quite a few
> interesting projects (DVM, DStep, Orbit, …), and although you are
> usually quick to advertise them here, it seems that none of them is
> quite ready for prime time.
>
> Maybe concentrating your efforts on one of them would be a good idea?
> Otherwise, you'll inevitably leave behind a trail of broken expectations
> as you cannot realistically expect to support all of them at the same time…
>
> David

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

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

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.

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.


Andrei