On 6/17/11 11:15 PM, Jacob Carlborg wrote:
> On 2011-06-14 15:53, Andrei Alexandrescu wrote:
>> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
>>
>> Destroy.
>>
>>
>> Andrei
>
> Instead of complaining about others ideas (I'll probably do that as well
> :) ), here's my idea:
> https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D
>
> I'm working on both of the tools mentioned in the above link. The ideas
> for the package manager are heavily based on Rubygems.

Very nice :-)

I hope this wins, hehe...

On 2011-06-18 07:00, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:itgamg$2ggr$4@digitalmars.com...
>> On 2011-06-17 18:45, Jose Armando Garcia wrote:
>>> On Fri, Jun 17, 2011 at 1:15 PM, Jacob Carlborg<doob@me.com>   wrote:
>>>> On 2011-06-14 15:53, Andrei Alexandrescu wrote:
>>>> Instead of complaining about others ideas (I'll probably do that as well
>>>> :)
>>>> ), here's my idea:
>>>> https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D
>>>
>>>>  From website:
>>>> Spec and Config Files
>>>> The dakefile and the orbspec file is written in Ruby. Why?
>>>
>>> Why ruby and not D with mixin? I am willing to volunteer some time to
>>> this if help is needed.
>>>
>>> -Jose
>>
>> As I stated just below "The dakefile and the orbspec file is written in
>> Ruby. Why?". D is too verbose for simple files like these. How would it
>> even work? Wrap everything in a main method, compile and then run?
>>
>
> That would be better than forcing Ruby on people.

So you prefer this, in favor of the Ruby syntax:

version_("1.0.0");
author("Jacob Carlborg");
type(Type.library);
imports(["a.d", "b.di"]); // an array of import files

Or maybe it has to be:

Orb.create((Orb orb) {
    orb.version_("1.0.0");
    orb.author("Jacob Carlborg");
    orb.type(Type.library);
    orb.imports(["a.d", "b.di"]); // an array of import files
});

I think it's unnecessary verbose. BTW, DMD, Phobos and druntime is forcing makefiles on people (I hate makefiles). DSSS forced an INI-similar syntax on people.

If the config/spec files should be in D then, as far as I know, the tool needs to:

1. read the file
2. add a main method
3. write a new file
4. compile the new file
5. run the resulting binary

This seems very unnecessary to me. Unnecessary IO, unnecessary compilation, unnecessary processes (two new processes). The only thing this will do is slowing down everything.

-- 
/Jacob Carlborg

On 2011-06-18 08:09, Daniel Murphy wrote:
> One option that I see is to create a compiler plugin interface that lets a
> build tool/package manager hook the compiler's import resolution process.
>
> A very (very) basic implementation: (windows only)
> https://github.com/yebblies/dmd/tree/importresolve
>
> For those who don't want to read the source code:
> The user (or the build tool, or in sc.ini/dmd.conf) supplies a dll/so on the
> command line with:
> dmd -ih=mylib.dll
> Which exports a single function "_importhandler" that is called when a file
> is not found on the include path.  It passes the module name and the
> contents of the describing pragma, if any.
> eg.
> pragma(libver, "collection", "version", "hash")
> import xpackage.xmodule;
>
> calls
> filename = importhandler("xpackage.xmodule", "collection", "version",
> "hash")
>
> and lets the library download, update etc, and return the full filename of
> the required library.

That seems cool. But, you would want to write the pluing in D and that's not possible yet on all platforms? Or should everything be done with extern(C), does that work?

-- 
/Jacob Carlborg

On 2011-06-18 07:00, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:itgamg$2ggr$4@digitalmars.com...
>> On 2011-06-17 18:45, Jose Armando Garcia wrote:
>>> On Fri, Jun 17, 2011 at 1:15 PM, Jacob Carlborg<doob@me.com>   wrote:
>>>> On 2011-06-14 15:53, Andrei Alexandrescu wrote:
>>>> Instead of complaining about others ideas (I'll probably do that as well
>>>> :)
>>>> ), here's my idea:
>>>> https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D
>>>
>>>>  From website:
>>>> Spec and Config Files
>>>> The dakefile and the orbspec file is written in Ruby. Why?
>>>
>>> Why ruby and not D with mixin? I am willing to volunteer some time to
>>> this if help is needed.
>>>
>>> -Jose
>>
>> As I stated just below "The dakefile and the orbspec file is written in
>> Ruby. Why?". D is too verbose for simple files like these. How would it
>> even work? Wrap everything in a main method, compile and then run?
>>
>
> That would be better than forcing Ruby on people.

You can just pretend it's not Ruby and think of it as a custom format instead :)

-- 
/Jacob Carlborg

"Jacob Carlborg" <doob@me.com> wrote in message news:iti310$2r4r$1@digitalmars.com...
> On 2011-06-18 07:00, Nick Sabalausky wrote:
>> "Jacob Carlborg"<doob@me.com>  wrote in message news:itgamg$2ggr$4@digitalmars.com...
>>> On 2011-06-17 18:45, Jose Armando Garcia wrote:
>>>> On Fri, Jun 17, 2011 at 1:15 PM, Jacob Carlborg<doob@me.com>   wrote:
>>>>> On 2011-06-14 15:53, Andrei Alexandrescu wrote:
>>>>> Instead of complaining about others ideas (I'll probably do that as
>>>>> well
>>>>> :)
>>>>> ), here's my idea:
>>>>> https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D
>>>>
>>>>>  From website:
>>>>> Spec and Config Files
>>>>> The dakefile and the orbspec file is written in Ruby. Why?
>>>>
>>>> Why ruby and not D with mixin? I am willing to volunteer some time to this if help is needed.
>>>>
>>>> -Jose
>>>
>>> As I stated just below "The dakefile and the orbspec file is written in Ruby. Why?". D is too verbose for simple files like these. How would it even work? Wrap everything in a main method, compile and then run?
>>>
>>
>> That would be better than forcing Ruby on people.
>
> So you prefer this, in favor of the Ruby syntax:
>
> version_("1.0.0");
> author("Jacob Carlborg");
> type(Type.library);
> imports(["a.d", "b.di"]); // an array of import files
>
> Or maybe it has to be:
>
> Orb.create((Orb orb) {
>     orb.version_("1.0.0");
>     orb.author("Jacob Carlborg");
>     orb.type(Type.library);
>     orb.imports(["a.d", "b.di"]); // an array of import files
> });
>
> I think it's unnecessary verbose.

I'd probably consider something more like:

orb.ver = "1.0.0";
orb.author = "Jacob Carlborg";
orb.type = Type.library;
orb.imports = ["a.d", "b.di"]; // an array of import files

And yes, I think these would be better simply because they're in D. The user doesn't have to switch languages.

> BTW, DMD, Phobos and druntime is forcing makefiles on people (I hate makefiles).

I hate makefiles too, but that's not an accurate comparison:

1. On windows, DMD comes with the make needed, and on linux everyone already has GNU make. With Orb/Ruby, many people will have to go and download Ruby and install it.`

2. People who *use* DMD to build their software *never* have to read or write a single line of makefile. *Only* people who modify the process of building DMD/Phobos/druntime need to do that. But anyone (or at least most people) who uses Orb to build their software will have to write Ruby. It would only be comparable if Orb only used Ruby to build Orb itself.


> DSSS forced an INI-similar syntax on people.
>

INI-syntax is trivial. Especially compared to Ruby (or D for that matter, to be perfectly fair).

> If the config/spec files should be in D then, as far as I know, the tool needs to:
>
> 1. read the file
> 2. add a main method
> 3. write a new file
> 4. compile the new file
> 5. run the resulting binary
>

More like:

1. compile the pre-existing main-wrapper:

    // main_wrapper.d
    void main()
    {
        mixin(import("orbconf.d"));
    }

like this:

    $ dmd main_wrapper.d -J{path containing user's "orbconf.d"}

If the user specifies a filename other than the standard name, then it's still not much more:

    // main_wrapperB.d
    void main()
    {
        mixin(import("std_orbconf.d"));
    }

Then write std_orbconf.d:

    // std_orbconf.d
    mixin(import("renamed_orbconf.d"));

$ dmd main_wrapperB.d --J{path containing user's "renamed_orbconf.d"} -J{path containing "std_orbconf.d"}


Also, remember that this should only need to be rebuilt if renamed_orbconf.d (or something it depends on) has changed. So you can do like rdmd does: call dmd to *just* get the deps of the main_wrapper.d+orbconf.d combination (which is much faster than an actual build) and only rebuild if they've changed - which won't be often. And again even this is only needed when the user isn't using the standard config file name.

2. run the resulting binary


> This seems very unnecessary to me. Unnecessary IO, unnecessary compilation, unnecessary processes (two new processes). The only thing this will do is slowing down everything.
>

1. The amount of extra stuff is fairly minimal. *Especially* in the majority of cases where the user uses the standard name ("orbconf.d" or whatever you want to call it).

2. Using Ruby will slow things down, too. It's not exactly known for being a language that's fast to compile&run on the level of D.

"Jacob Carlborg" <doob@me.com> wrote in message news:iti3bf$2r4r$4@digitalmars.com...
> On 2011-06-18 07:00, Nick Sabalausky wrote:
>> "Jacob Carlborg"<doob@me.com>  wrote in message news:itgamg$2ggr$4@digitalmars.com...
>>> On 2011-06-17 18:45, Jose Armando Garcia wrote:
>>>> On Fri, Jun 17, 2011 at 1:15 PM, Jacob Carlborg<doob@me.com>   wrote:
>>>>> On 2011-06-14 15:53, Andrei Alexandrescu wrote:
>>>>> Instead of complaining about others ideas (I'll probably do that as
>>>>> well
>>>>> :)
>>>>> ), here's my idea:
>>>>> https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D
>>>>
>>>>>  From website:
>>>>> Spec and Config Files
>>>>> The dakefile and the orbspec file is written in Ruby. Why?
>>>>
>>>> Why ruby and not D with mixin? I am willing to volunteer some time to this if help is needed.
>>>>
>>>> -Jose
>>>
>>> As I stated just below "The dakefile and the orbspec file is written in Ruby. Why?". D is too verbose for simple files like these. How would it even work? Wrap everything in a main method, compile and then run?
>>>
>>
>> That would be better than forcing Ruby on people.
>
> You can just pretend it's not Ruby and think of it as a custom format instead :)
>

That doesn't address the matter of needing to install Ruby.

It also throws away this stated benefit: "When the files are written in a complete language you have great flexibility and can take full advantage of [a full-fledged programming language]".

On 06/18/2011 02:35 PM, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:iti310$2r4r$1@digitalmars.com...
>> On 2011-06-18 07:00, Nick Sabalausky wrote:
>>> "Jacob Carlborg"<doob@me.com>   wrote in message
>>> news:itgamg$2ggr$4@digitalmars.com...
>>>> On 2011-06-17 18:45, Jose Armando Garcia wrote:
>>>>> On Fri, Jun 17, 2011 at 1:15 PM, Jacob Carlborg<doob@me.com>    wrote:
>>>>>> On 2011-06-14 15:53, Andrei Alexandrescu wrote:
>>>>>> Instead of complaining about others ideas (I'll probably do that as
>>>>>> well
>>>>>> :)
>>>>>> ), here's my idea:
>>>>>> https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D
>>>>>
>>>>>>    From website:
>>>>>> Spec and Config Files
>>>>>> The dakefile and the orbspec file is written in Ruby. Why?
>>>>>
>>>>> Why ruby and not D with mixin? I am willing to volunteer some time to
>>>>> this if help is needed.
>>>>>
>>>>> -Jose
>>>>
>>>> As I stated just below "The dakefile and the orbspec file is written in
>>>> Ruby. Why?". D is too verbose for simple files like these. How would it
>>>> even work? Wrap everything in a main method, compile and then run?
>>>>
>>>
>>> That would be better than forcing Ruby on people.
>>
>> So you prefer this, in favor of the Ruby syntax:
>>
>> version_("1.0.0");
>> author("Jacob Carlborg");
>> type(Type.library);
>> imports(["a.d", "b.di"]); // an array of import files
>>
>> Or maybe it has to be:
>>
>> Orb.create((Orb orb) {
>>      orb.version_("1.0.0");
>>      orb.author("Jacob Carlborg");
>>      orb.type(Type.library);
>>      orb.imports(["a.d", "b.di"]); // an array of import files
>> });
>>
>> I think it's unnecessary verbose.
>
> I'd probably consider something more like:
>
> orb.ver = "1.0.0";
> orb.author = "Jacob Carlborg";
> orb.type = Type.library;
> orb.imports = ["a.d", "b.di"]; // an array of import files
>
> And yes, I think these would be better simply because they're in D. The user
> doesn't have to switch languages.

Just to add an opinion - I think doing this work in D would foster creative uses of the language and be beneficial for improving the language itself and its standard library.

Andrei

"Jacob Carlborg" <doob@me.com> wrote in message news:iti35g$2r4r$2@digitalmars.com...
>
> That seems cool. But, you would want to write the pluing in D and that's not possible yet on all platforms? Or should everything be done with extern(C), does that work?
>

Yeah, it won't be possible to do it all in D until we have .so's working on linux etc, which I think is a while off yet.  Although this could be worked around by writing a small loader in c++ and using another process (written in D) to do the actual work.  Maybe it would be easier to build dmd as a shared lib (or a static lib) and just provide a different front...

My point is that the compiler can quite easily be modified to allow it to
pass pretty much anything (missing imports, pragma(lib), etc) to a build
tool, and it should be fairly straightforward for the build tool to pass
things back in (adding objects to the linker etc).  This could allow single
pass full compilation even when the libraries need to be fetched off the
internet.  It could also allow seperate compilation of several source files
at once, without having to re-do parsing+semantic each time.  Can dmd
currently do this?
Most importantly it keeps knowledge about urls and downloading files outside
the compiler, where IMO it does not belong.

On 6/18/11 6:38 PM, Jacob Carlborg wrote:
> On 2011-06-18 07:00, Nick Sabalausky wrote:
>> "Jacob Carlborg"<doob@me.com> wrote in message
>> news:itgamg$2ggr$4@digitalmars.com...
>>> On 2011-06-17 18:45, Jose Armando Garcia wrote:
>>>> On Fri, Jun 17, 2011 at 1:15 PM, Jacob Carlborg<doob@me.com> wrote:
>>>>> On 2011-06-14 15:53, Andrei Alexandrescu wrote:
>>>>> Instead of complaining about others ideas (I'll probably do that as
>>>>> well
>>>>> :)
>>>>> ), here's my idea:
>>>>> https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D
>>>>>
>>>>
>>>>> From website:
>>>>> Spec and Config Files
>>>>> The dakefile and the orbspec file is written in Ruby. Why?
>>>>
>>>> Why ruby and not D with mixin? I am willing to volunteer some time to
>>>> this if help is needed.
>>>>
>>>> -Jose
>>>
>>> As I stated just below "The dakefile and the orbspec file is written in
>>> Ruby. Why?". D is too verbose for simple files like these. How would it
>>> even work? Wrap everything in a main method, compile and then run?
>>>
>>
>> That would be better than forcing Ruby on people.
>
> So you prefer this, in favor of the Ruby syntax:
>
> version_("1.0.0");
> author("Jacob Carlborg");
> type(Type.library);
> imports(["a.d", "b.di"]); // an array of import files

Lol!

I was going to write exactly the same answer...

On 2011-06-18 21:35, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:iti310$2r4r$1@digitalmars.com...
>> On 2011-06-18 07:00, Nick Sabalausky wrote:
>>> "Jacob Carlborg"<doob@me.com>   wrote in message
>>> news:itgamg$2ggr$4@digitalmars.com...
>>>> On 2011-06-17 18:45, Jose Armando Garcia wrote:
>>>>> On Fri, Jun 17, 2011 at 1:15 PM, Jacob Carlborg<doob@me.com>    wrote:
>>>>>> On 2011-06-14 15:53, Andrei Alexandrescu wrote:
>>>>>> Instead of complaining about others ideas (I'll probably do that as
>>>>>> well
>>>>>> :)
>>>>>> ), here's my idea:
>>>>>> https://github.com/jacob-carlborg/orbit/wiki/Oribt-Package-Manager-for-D
>>>>>
>>>>>>    From website:
>>>>>> Spec and Config Files
>>>>>> The dakefile and the orbspec file is written in Ruby. Why?
>>>>>
>>>>> Why ruby and not D with mixin? I am willing to volunteer some time to
>>>>> this if help is needed.
>>>>>
>>>>> -Jose
>>>>
>>>> As I stated just below "The dakefile and the orbspec file is written in
>>>> Ruby. Why?". D is too verbose for simple files like these. How would it
>>>> even work? Wrap everything in a main method, compile and then run?
>>>>
>>>
>>> That would be better than forcing Ruby on people.
>>
>> So you prefer this, in favor of the Ruby syntax:
>>
>> version_("1.0.0");
>> author("Jacob Carlborg");
>> type(Type.library);
>> imports(["a.d", "b.di"]); // an array of import files
>>
>> Or maybe it has to be:
>>
>> Orb.create((Orb orb) {
>>      orb.version_("1.0.0");
>>      orb.author("Jacob Carlborg");
>>      orb.type(Type.library);
>>      orb.imports(["a.d", "b.di"]); // an array of import files
>> });
>>
>> I think it's unnecessary verbose.
>
> I'd probably consider something more like:
>
> orb.ver = "1.0.0";
> orb.author = "Jacob Carlborg";
> orb.type = Type.library;
> orb.imports = ["a.d", "b.di"]; // an array of import files

That would be doable in Ruby as well. I though it would be better to not have to write "orb." in front of every method. Note the following syntax is not possible in Ruby:

ver = "1.0.0"
author = "Jacob Carlborg"
type = Type.library
imports = ["a.d", "b.di"]

The above syntax is what I would prefer but it doesn't work in Ruby, would create local variables and not call instance methods. Because of that I chose the syntax I chose, the least verbose syntax I could think of.

> And yes, I think these would be better simply because they're in D. The user
> doesn't have to switch languages.
>
>> BTW, DMD, Phobos and druntime is forcing makefiles on people (I hate
>> makefiles).
>
> I hate makefiles too, but that's not an accurate comparison:
>
> 1. On windows, DMD comes with the make needed, and on linux everyone already
> has GNU make. With Orb/Ruby, many people will have to go and download Ruby
> and install it.`

No need to download and install Ruby, it's embedded in the tool.

> 2. People who *use* DMD to build their software *never* have to read or
> write a single line of makefile. *Only* people who modify the process of
> building DMD/Phobos/druntime need to do that. But anyone (or at least most
> people) who uses Orb to build their software will have to write Ruby. It
> would only be comparable if Orb only used Ruby to build Orb itself.

Ok, fair enough.

>> DSSS forced an INI-similar syntax on people.
>>
>
> INI-syntax is trivial. Especially compared to Ruby (or D for that matter, to
> be perfectly fair).

I was thinking that the Ruby syntax was as easy and trivial as the INI-syntax if you just use the basic, like I have in the examples. No need to use if-statements, loops or classes. That's just for packages that need to do very special things.

To take the DSSS syntax again as an example:

# legal syntax
version (Windows) {
}

# illegal syntax
version (Windows)
{
)

I assume this is because the lexer/parser is very simple. You don't have this problem if you use a complete language for the config/spec files.

>> If the config/spec files should be in D then, as far as I know, the tool
>> needs to:
>>
>> 1. read the file
>> 2. add a main method
>> 3. write a new file
>> 4. compile the new file
>> 5. run the resulting binary
>>
>
> More like:
>
> 1. compile the pre-existing main-wrapper:
>
>      // main_wrapper.d
>      void main()
>      {
>          mixin(import("orbconf.d"));
>      }
>
> like this:
>
>      $ dmd main_wrapper.d -J{path containing user's "orbconf.d"}
>
> If the user specifies a filename other than the standard name, then it's
> still not much more:
>
>      // main_wrapperB.d
>      void main()
>      {
>          mixin(import("std_orbconf.d"));
>      }
>
> Then write std_orbconf.d:
>
>      // std_orbconf.d
>      mixin(import("renamed_orbconf.d"));
>
> $ dmd main_wrapperB.d --J{path containing user's
> "renamed_orbconf.d"} -J{path containing "std_orbconf.d"}
>
>
> Also, remember that this should only need to be rebuilt if renamed_orbconf.d
> (or something it depends on) has changed. So you can do like rdmd does: call
> dmd to *just* get the deps of the main_wrapper.d+orbconf.d combination
> (which is much faster than an actual build) and only rebuild if they've
> changed - which won't be often. And again even this is only needed when the
> user isn't using the standard config file name.
>
> 2. run the resulting binary
>
>
>> This seems very unnecessary to me. Unnecessary IO, unnecessary
>> compilation, unnecessary processes (two new processes). The only thing
>> this will do is slowing down everything.
>>
>
> 1. The amount of extra stuff is fairly minimal. *Especially* in the majority
> of cases where the user uses the standard name ("orbconf.d" or whatever you
> want to call it).

OK, I guess you can get away without the IO, but you still need the extra processes.

> 2. Using Ruby will slow things down, too. It's not exactly known for being a
> language that's fast to compile&run on the level of D.

Yeah, I know. Ruby is one of the slowest language. But I was still hoping it would be faster than compile and run a D application. Also note that since I've embedded Ruby in the tool it's not creating a new process (at least I don't think it does).

-- 
/Jacob Carlborg