On 2011-06-18 21:35, Nick Sabalausky wrote:
"Jacob Carlborg"<d...@me.com>  wrote in message
news:iti310$2r4r$1...@digitalmars.com...
On 2011-06-18 07:00, Nick Sabalausky wrote:
"Jacob Carlborg"<d...@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<d...@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

Reply via email to