On 2011-06-18 21:38, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> That doesn't address the matter of needing to install Ruby.

No need for installing, it's embedded in the tool.

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

It's there if you need it, most people won't (I would guess).

-- 
/Jacob Carlborg

On 2011-06-18 22:02, Andrei Alexandrescu wrote:
> On 06/18/2011 02:35 PM, Nick Sabalausky wrote:
>> 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

Fair point. But I'm using the tools I think are best fitted for the job. If I don't think D is good enough for the job I won't use it. If it it shows that D is good enough I can use D instead. Note that the whole tool is written in D, it's just that config/spec files that uses Ruby.

-- 
/Jacob Carlborg

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

Looks good, and has a cool name too! I love the reference to the mars / phobos theme.

After 'cloning into orbit...', I think I'm missing a ruby ffi binding. Is it possible to build it already? Or is it too early for that?

If I'm not mistaken the dependency on ruby is nicely factored into a very small part of orbit and could easily be replaced if someone would be inclined to do so. I'd prefer this over ruby, but I prefer ruby over the dsss format. In the end, what matters is the value of the tool.

On 2011-06-19 15:32, Lutger Blijdestijn wrote:
> 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.
>>
>
> Looks good, and has a cool name too! I love the reference to the mars /
> phobos theme.
>
> After 'cloning into orbit...', I think I'm missing a ruby ffi binding. Is it
> possible to build it already? Or is it too early for that?
>
> If I'm not mistaken the dependency on ruby is nicely factored into a very
> small part of orbit and could easily be replaced if someone would be
> inclined to do so. I'd prefer this over ruby, but I prefer ruby over the
> dsss format. In the end, what matters is the value of the tool.

Oh yeah. I have the Ruby bindings on my computer only. I'll upload the bindings as well. The repository is not actually ready for the public yet. I just created the repository so I could easily access the code on all my computers and now I had use for the wiki as well.

-- 
/Jacob Carlborg

Lutger Blijdestijn wrote:
>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.
>> 
>
>Looks good, and has a cool name too! I love the reference to the mars / phobos theme.
>
>After 'cloning into orbit...', I think I'm missing a ruby ffi binding. Is it possible to build it already? Or is it too early for that?
>
>If I'm not mistaken the dependency on ruby is nicely factored into a very small part of orbit and could easily be replaced if someone would be inclined to do so. I'd prefer this over ruby, but I prefer ruby over the dsss format. In the end, what matters is the value of the tool.

I personally think that ruby is a good choice for the config format (lua, python, whatever would be fine too), as we definitely need a programming language for advanced use cases (debian uses makefiles, which are a pita, but together with bash and external tools they still count as a programming language)

It should be noted though that replacing the config syntax later on will
be difficult: even if it's factored out nicely in the code, we
could have thousands of d packages using the old format. In order not
to break those, we'd have to deprecate the old format, but still leave
it available for some time, which leads to more dependencies and
problems...

-- 
Johannes Pfau

Johannes Pfau wrote:

> Lutger Blijdestijn wrote:
>>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.
>>> 
>>
>>Looks good, and has a cool name too! I love the reference to the mars / phobos theme.
>>
>>After 'cloning into orbit...', I think I'm missing a ruby ffi binding. Is it possible to build it already? Or is it too early for that?
>>
>>If I'm not mistaken the dependency on ruby is nicely factored into a very small part of orbit and could easily be replaced if someone would be inclined to do so. I'd prefer this over ruby, but I prefer ruby over the dsss format. In the end, what matters is the value of the tool.
> 
> I personally think that ruby is a good choice for the config format (lua, python, whatever would be fine too), as we definitely need a programming language for advanced use cases (debian uses makefiles, which are a pita, but together with bash and external tools they still count as a programming language)
> 
> It should be noted though that replacing the config syntax later on will
> be difficult: even if it's factored out nicely in the code, we
> could have thousands of d packages using the old format. In order not
> to break those, we'd have to deprecate the old format, but still leave
> it available for some time, which leads to more dependencies and
> problems...
> 

For D programmers that need this kind of advanced functionality it means they have to learn ruby as well. Whereas it's pretty safe to assume they already know D :)

Another advantage of D is that built related scripts and extensions can be distributed easily with orbit itself.

I'm thinking that maybe it is possible for dakefile.rb and dakefile.d to coexist in the same tool? I'm not sure if that creates problems, or if such extra complexity is worth it.

However, those that really want to use D could try to convince Jacob Carlborg that D is a good alternative by implementing it, if he is open to that.

"Jacob Carlborg" <doob@me.com> wrote in message news:itko61$1qdm$1@digitalmars.com...
> On 2011-06-18 21:35, Nick Sabalausky wrote:
>>
>> 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.
>

That syntax should be doable in D.


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

But then the people who do such fancy things have to do it in Ruby instead of D.

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

Right. And D is a complete language.

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

That should be pretty quick.

On 2011-06-19 19:15, Johannes Pfau wrote:
> Lutger Blijdestijn wrote:
>> 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.
>>>
>>
>> Looks good, and has a cool name too! I love the reference to the
>> mars / phobos theme.
>>
>> After 'cloning into orbit...', I think I'm missing a ruby ffi binding.
>> Is it possible to build it already? Or is it too early for that?
>>
>> If I'm not mistaken the dependency on ruby is nicely factored into a
>> very small part of orbit and could easily be replaced if someone would
>> be inclined to do so. I'd prefer this over ruby, but I prefer ruby
>> over the dsss format. In the end, what matters is the value of the
>> tool.
>
> I personally think that ruby is a good choice for the config format
> (lua, python, whatever would be fine too), as we definitely need a
> programming language for advanced use cases (debian uses makefiles,
> which are a pita, but together with bash and external tools they still
> count as a programming language)

I completely agree. I key feature for why I chose Ruby is because it allows you to call a method with out parentheses, don't know about the other above mentioned languages.

> It should be noted though that replacing the config syntax later on will
> be difficult: even if it's factored out nicely in the code, we
> could have thousands of d packages using the old format. In order not
> to break those, we'd have to deprecate the old format, but still leave
> it available for some time, which leads to more dependencies and
> problems...

Yes, that would be a big problem. But, the advantage we have is that we can change the language when developing the tool, if necessary. I mean before we get any more packages than just test packages.

-- 
/Jacob Carlborg

On 2011-06-19 19:37, Lutger Blijdestijn wrote:
> Johannes Pfau wrote:
>
>> Lutger Blijdestijn wrote:
>>> 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.
>>>>
>>>
>>> Looks good, and has a cool name too! I love the reference to the
>>> mars / phobos theme.
>>>
>>> After 'cloning into orbit...', I think I'm missing a ruby ffi binding.
>>> Is it possible to build it already? Or is it too early for that?
>>>
>>> If I'm not mistaken the dependency on ruby is nicely factored into a
>>> very small part of orbit and could easily be replaced if someone would
>>> be inclined to do so. I'd prefer this over ruby, but I prefer ruby
>>> over the dsss format. In the end, what matters is the value of the
>>> tool.
>>
>> I personally think that ruby is a good choice for the config format
>> (lua, python, whatever would be fine too), as we definitely need a
>> programming language for advanced use cases (debian uses makefiles,
>> which are a pita, but together with bash and external tools they still
>> count as a programming language)
>>
>> It should be noted though that replacing the config syntax later on will
>> be difficult: even if it's factored out nicely in the code, we
>> could have thousands of d packages using the old format. In order not
>> to break those, we'd have to deprecate the old format, but still leave
>> it available for some time, which leads to more dependencies and
>> problems...
>>
>
> For D programmers that need this kind of advanced functionality it means
> they have to learn ruby as well. Whereas it's pretty safe to assume they
> already know D :)
>
> Another advantage of D is that built related scripts and extensions can be
> distributed easily with orbit itself.

That's true. It would be possible to write extensions in D even when the config language is Ruby, although it would be more complicated.

> I'm thinking that maybe it is possible for dakefile.rb and dakefile.d to
> coexist in the same tool? I'm not sure if that creates problems, or if such
> extra complexity is worth it.

I don't think it's worth it. It also depends on how much the complexity increases.

> However, those that really want to use D could try to convince Jacob
> Carlborg that D is a good alternative by implementing it, if he is open to
> that.

I'm always open to suggestions.

-- 
/Jacob Carlborg

On 2011-06-19 20:41, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:itko61$1qdm$1@digitalmars.com...
>> On 2011-06-18 21:35, Nick Sabalausky wrote:
>>>
>>> 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.
>>
>
> That syntax should be doable in D.
>
>
>>>> 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.
>>
>
> But then the people who do such fancy things have to do it in Ruby instead
> of D.
>
>> 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.
>>
>
> Right. And D is a complete language.
>
>>>
>>> 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.
>>
>
> That should be pretty quick.

Ok, for now I will continue with Ruby and see how it goes. One thing I do think looks really ugly in D are delegates. For the Dake config file, I'm thinking that it would allow several targets and tasks (like rake), which would looks something like this (in Ruby):

target "name" do |t|
    t.flags = "-L-lz"
end

In D this would look something like this:

target("name", (Target t) {
    t.flags = "-L-lz"
});

Or with operator overload abuse:

target("name") in (Target t) {
    t.flags = "-L-lz"
};

I would so love if this syntax (that's been suggested before) was supported:

target("name", Target t) {
    t.flags = "-L-lz"
}

If anyone have better ideas for how this can be done I'm listening.

One other thing, syntax below can be thought of like a compile time eval:

void main ()
{
    mixin(import("file.d"));
}

Does anyone have an idea if it would be possible to do the corresponding to instance eval that is available in some scripting languages?

-- 
/Jacob Carlborg