DIP11: Automatic downloading of libraries

[Jacob Carlborg]

On 2011-06-18 21:35, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob at me.com>  wrote in message
> news:iti310$2r4r$1 at digitalmars.com...
>> On 2011-06-18 07:00, Nick Sabalausky wrote:
>>> "Jacob Carlborg"<doob at me.com>   wrote in message
>>> news:itgamg$2ggr$4 at digitalmars.com...
>>>> On 2011-06-17 18:45, Jose Armando Garcia wrote:
>>>>> On Fri, Jun 17, 2011 at 1:15 PM, Jacob Carlborg<doob at 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