July 15, 2011
On 2011-07-14 23:16, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:ivniga$2lt$1@digitalmars.com...
>> On 2011-07-14 08:48, Russel Winder wrote:
>>> On Wed, 2011-07-13 at 20:32 +0200, Jacob Carlborg wrote:
>>> [ . . . ]
>>>> I think that one of the problem with these language independent build
>>>> tools is that they don't make it as easy as it could, because they
>>>> usually don't know enough about a given language.
>>>
>>> This is generally due to incomplete support in the tools, this is not a
>>> problem with general build frameworks per se.  In systems such as Waf
>>> and SCons, the framework provides facilities for creating tools and for
>>> those tools to build DAGs that then get "resolved" in the second phase
>>> of activity.  The language specific tool does things as a first phase of
>>> activity -- i.e. building the DAG.  The tools should realize all the
>>> language specific things that that languages users needs and/or the
>>> language expects.  Anything that is not handled is a problem that should
>>> be fixed by the tool maintainer.
>>
>> Ok, I see, but it sounds complicated. And I basically give all my hope to
>> the tool maintainer to be willing to merge/implement the necessary
>> functionality/changes that the tool need to support D.
>>
>
> Personally, I normally prefer just giving the commandline myself. I never
> feel comfortable trusting some generalized thing to do what I want or to be
> flexible enough to let me reliably make all adjustments I might need to
> make.

Exactly.

-- 
/Jacob Carlborg
July 15, 2011
On 2011-07-15 00:06, Andrei Alexandrescu wrote:
> On 7/14/11 3:09 PM, Jacob Carlborg wrote:
>> On 2011-07-14 08:56, Russel Winder wrote:
>>> Nick,
>>>
>>> On Wed, 2011-07-13 at 17:41 -0400, Nick Sabalausky wrote:
>>> [ . . . ]
>>>> Yea, D is likely to be a little more verbose than what could be done
>>>> in Ruby
>>>> (or Python). Personally, I think that's well worth it, though. I
>>>> don't know
>>>> how many others would agree or not.
>>> [ . . . ]
>>>
>>> You might want to take a quick look at SBT -- the standard Scala build
>>> framework. It's advocates started it because Ant and Maven are XML hell
>>> and are generally problematic, and Gradle is build on Java and Groovy,
>>> and (as you might expect) Scala folk abhor all things dynamic (i.e.
>>> Groovy) and insist on static type checking. I have some doubts about
>>> the huge downloads they dump into each project hierarchy, but there is
>>> no doubt that they have made excellent use of a statically type language
>>> to create a DSL for building Scala things.
>>>
>>> If D can be used to go down this sort of road, and if it can support the
>>> build and install facilities of SCons and Waf, then it could be a
>>> winner.
>>
>> Scala have a lot of features making a DSL looking a lot better than one
>> written in D.
>
> Does it have something akin to string mixins?
>
> Andrei

I'm not very familiar with Scala but I found this: http://blog.darevay.com/2009/01/remedial-scala-interpreting-scala-from-scala/

-- 
/Jacob Carlborg
July 15, 2011
On 2011-07-15 05:31, Nick Sabalausky wrote:
> "Ulrik Mikaelsson"<ulrik.mikaelsson@gmail.com>  wrote in message
>> * The build-tool itself will need bootstrapping. A user that wants to
>> test some D-project, will first have to aquire (build) and install
>> some D-compiler with custom tools. Then install druntime with another
>> custom build-system. Then Phobos. Then drake. And THEN, the
>> application/library he/she was interested in. Shortening this path is
>> IMHO REALLY important to see more D adoption. From my personal
>> experience, convincing developers and testers to fight through this
>> path is HARD.
>
> It's not as complicated as you suggest. Suppose someone wants to try
> building FooApp:
>
> Step 1: D compilers already come prebuilt, with Phobos and Druntime already
> set up. So just install DMD. Done. Or users can install DVM and then install
> DMD with "dvm install {version}&&  dvm use -d (version)".
>
> Step 2: Install drake. Or, FooApp could even just include Drake. Or, FooApp
> could be installed with a package manager that sees FooApp depends on Drake
> and so auto-installs Drake first.
>
> Step 3: Run "drake all". That invokes a trivial one-line shell/batch script
> that will automatically compile drake and the buildscript (if they're not
> already built), and then run the buildscript.
>
> Or, when we get a good package manager, we could just offer pre-built
> versions of the package manager and then:
>
> Step 1: Install the package manager (which might even install DMD
> automatically, possibly via DVM).
>
> Step 2: Run "d-package-manager install FooApp". The package manager
> determines FooApp depends on DMD and Drake (and maybe DVM), and
> automatically installs all of that, then installs FooApp and invokes
> FooApp's post-install script which is "drake all", and thus builds FooApp.
>
> Step 3: Enjoy a nice latte, because you're done.

When a standard build tool and package manager become available I will let DVM install it.

-- 
/Jacob Carlborg
July 15, 2011
On 2011-07-14 21:06, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:ivme1u$31i8$1@digitalmars.com...
>>
> [...snip...]
>> In D, with this syntax:
>>
>> target("foo.d", {
>>      buildflags ~=  "-L-ldwt";
>> });
>>
>> target("main.d" {
>>      buildflags ~=  "-release"
>> });
>>
>> "buildflags" would probably be a global function or an instance method. If
>> this should work "buildflags" needs to keep some data structure with
>> buildflags for each target. This seems quite complicated, making sure the
>> correct build flags are used with the correct target.
>
> That's an interestng idea. I think it could be done fairly easily by having
> Drake invoke the delegates indirectly like this:
>
> Target t; // global
> void invokeBuildStep(Target currTarget, {type} dg)
> {
>      t = currTarget;
>      dg();
>      t = null;
> }

The functions invoked in the delegate till use the global target? Seems this would work.

> Only thing though, is if there's any special members added to the Target
> subclass being used, the user would have to cast 't' to access them. Then
> again, that's an issue in the current design, too. I'll have to think about
> this...

Maybe in that case it's better to pass the target to the delegate. Just provide several overloads of the function taking the delegate.

-- 
/Jacob Carlborg
July 15, 2011
On 7/15/11 7:58 AM, Jacob Carlborg wrote:
> On 2011-07-15 00:06, Andrei Alexandrescu wrote:
>> On 7/14/11 3:09 PM, Jacob Carlborg wrote:
>>> On 2011-07-14 08:56, Russel Winder wrote:
>>>> Nick,
>>>>
>>>> On Wed, 2011-07-13 at 17:41 -0400, Nick Sabalausky wrote:
>>>> [ . . . ]
>>>>> Yea, D is likely to be a little more verbose than what could be done
>>>>> in Ruby
>>>>> (or Python). Personally, I think that's well worth it, though. I
>>>>> don't know
>>>>> how many others would agree or not.
>>>> [ . . . ]
>>>>
>>>> You might want to take a quick look at SBT -- the standard Scala build
>>>> framework. It's advocates started it because Ant and Maven are XML hell
>>>> and are generally problematic, and Gradle is build on Java and Groovy,
>>>> and (as you might expect) Scala folk abhor all things dynamic (i.e.
>>>> Groovy) and insist on static type checking. I have some doubts about
>>>> the huge downloads they dump into each project hierarchy, but there is
>>>> no doubt that they have made excellent use of a statically type
>>>> language
>>>> to create a DSL for building Scala things.
>>>>
>>>> If D can be used to go down this sort of road, and if it can support
>>>> the
>>>> build and install facilities of SCons and Waf, then it could be a
>>>> winner.
>>>
>>> Scala have a lot of features making a DSL looking a lot better than one
>>> written in D.
>>
>> Does it have something akin to string mixins?
>>
>> Andrei
>
> I'm not very familiar with Scala but I found this:
> http://blog.darevay.com/2009/01/remedial-scala-interpreting-scala-from-scala/

Interesting. What are the features that do make a DSL better looking in Scala than in D?


Thanks,

Andrei

July 15, 2011
On 7/14/11 3:00 PM, Jacob Carlborg wrote:
> On 2011-07-14 04:37, Andrei Alexandrescu wrote:
>> On 7/13/11 5:32 PM, Ulrik Mikaelsson wrote:
>>> Not trying to be argumentative, but what exactly do you see as the
>>> gains in having a D-buildtool built in D (or D-specific build-tool in
>>> any language, for that matter)?
>>
>> I think it's a matter of positioning D and eating one's dogfood. If D is
>> inconceivable for the kind of tasks that Python or Ruby are adept at,
>> then sure, we could and should use either. On the other hand, if we
>> advocate D as a good tool for short scripts, using the competition would
>> hurt its brand.
>>
>> Personally I believe D is plenty adequate for short scripts, of which
>> I've written a ton of. So the path of least resistance for a package
>> manager or for a build tool is D, not any other language. I'd question
>> much harder the decision of using another language (D is, however, not a
>> competitor for the likes of bash or make).
>
> Isn't it a competitor for make in this case?

What I meant here is that it's reasonable for a build tool for D to require make without impacting its brand.

>> I see no NIH here. D is an ample language scaling up to large programs
>> and down to scripts. If the question is to build a tool from scratch, D
>> is the obvious choice and any other choice is just odd. It's like some
>> tools I've seen (none successful) that required the competition's
>> product to be installed in order to work.
>>
>>
>> Andrei
>
> I though we were talking about what language the build scripts should
> use, not the language the actual build tool should be written in. I
> think these are two separate issues and all tools mentioned (Drake,
> Orbit, Dake) in this thread are implemented in D.
>
> My tools, using Ruby as the scripting language, have Ruby embedded in
> the tool and requires no installation of Ruby.

I believe use of Ruby for scripting is a strategic mistake for a small benefit. The users your tools should not need to learn any amount of Ruby (or Scala for that matter) in order to build D programs. What we need is, if necessary, to improve D to better address the needs for scripting a build tool. That way your work would be pushing D's state of the art in addition to adding value on its own. I suggest you reconsider.


Thanks,

Andrei
July 15, 2011
On 2011-07-15 17:16, Andrei Alexandrescu wrote:
> On 7/15/11 7:58 AM, Jacob Carlborg wrote:
>> I'm not very familiar with Scala but I found this:
>> http://blog.darevay.com/2009/01/remedial-scala-interpreting-scala-from-scala/
>>
>
> Interesting. What are the features that do make a DSL better looking in
> Scala than in D?
>
>
> Thanks,
>
> Andrei

This is just what I think (I've thrown in Ruby and CoffeeScript as well)

Scala:

* Delegate syntax - Scala allows passing a delegate to a syntax like this:

loop {
   // code
}

This allows to create, what look likes, new statements. I don't recall how the "loop" function should be implemented but it was quite complex and had something do with partial functions.

Scala also has this nice delegate syntax:

foo(a => a + a)

* Infix operators - Allows to call any method that takes one argument without parentheses and without the dot:

object.func("asd")

Can be called like this:

object func "asd"

* Naming methods - In Scala you can name a method "+", "-", "*" and similar. You are not limited to A-Za-z_0-9. Together with infix operators this is how Scala implements operator overloading. This also allows to add new operators.

* No semicolons
* Is in general very good at inferring types, including return types
* Almost everything is an expression
* The constructor is built-in the class declaration:

class Foo
{
    // this is the constructor
    def foo = "foo"
}

Ruby:

* Methods can be called without parentheses
* Class bodies can execute code
* Not limited to top level declarations
* No semicolons
* Delegate/block syntax - In Ruby you passes blocks to methods after the regular arguments:

foo(3, 4) do |a|
   # do something with a
end

Or the one-line syntax:

foo(3, 4) { |a| }


* Simplified hash literal syntax - The standard hash syntax in Ruby is:

a = { key => value }

But if you call a method with hash literal you can most of the times omit the braces:

foo(key => value)

* Almost everything is an expression - This is possible

b = if a == 3
    4
else
    5
end

* Trailing if statements

foo(3) if a == 4

CoffeeScript:

* Methods can be called without parentheses (if they take at least on argument)
* Almost everything is an expression
* Trailing if statements
* No semicolons
* Class bodies can execute code
* Not limited to top level declarations
* Keywords for "or", "and", "yes", "no" and "not".
* Delegate/functoin syntax - Example:

foo (a, b) -> a + b

* Hash/object syntax - Example:

hash =
    foo: 1
    bar: 2

hash = foo: 1, bar: 2

CoffeeScript: http://jashkenas.github.com/coffee-script/

-- 
/Jacob Carlborg
July 15, 2011
On 2011-07-15 18:13, Andrei Alexandrescu wrote:
> I believe use of Ruby for scripting is a strategic mistake for a small
> benefit. The users your tools should not need to learn any amount of
> Ruby (or Scala for that matter) in order to build D programs. What we
> need is, if necessary, to improve D to better address the needs for
> scripting a build tool. That way your work would be pushing D's state of
> the art in addition to adding value on its own. I suggest you reconsider.
>
>
> Thanks,
>
> Andrei

I have very difficult in believing that features from Ruby, Scala or some other language that I think make it possible to create good looking DSL will end up in D. I've listed (some of) these features in another reply to you.

On the other hand if it is possible that some of these features end up in D then that's great, and will be a very big step in conniving me to switch to D for the build scripts.

-- 
/Jacob Carlborg
July 15, 2011
"Jacob Carlborg" <doob@me.com> wrote in message news:ivp0oa$3lq$1@digitalmars.com...
> On 2011-07-14 21:15, Nick Sabalausky wrote:
>
> Ah, now I see. I'm hoping the user never needs to write import statements in the build script. It's just these little things that I don't like about using D for the build scripts. Imports and no top level code.
>

I agree that the default imports should be sufficient for most typical uses. But it should be possible to create and share a Drake add-on in the form of a simple module to be imported. An import would be needed for that. Plus, even without Drake add-ons, it's reasonable to think that some people may have reason to import something from Phobos, or something from their own project, that wouldn't normally be used in most other buildscripts.


July 15, 2011
"Jacob Carlborg" <doob@me.com> wrote in message news:ivpfoa$uu7$1@digitalmars.com...
> On 2011-07-14 21:06, Nick Sabalausky wrote:
>> "Jacob Carlborg"<doob@me.com>  wrote in message news:ivme1u$31i8$1@digitalmars.com...
>>>
>> [...snip...]
>>> In D, with this syntax:
>>>
>>> target("foo.d", {
>>>      buildflags ~=  "-L-ldwt";
>>> });
>>>
>>> target("main.d" {
>>>      buildflags ~=  "-release"
>>> });
>>>
>>> "buildflags" would probably be a global function or an instance method.
>>> If
>>> this should work "buildflags" needs to keep some data structure with
>>> buildflags for each target. This seems quite complicated, making sure
>>> the
>>> correct build flags are used with the correct target.
>>
>> That's an interestng idea. I think it could be done fairly easily by
>> having
>> Drake invoke the delegates indirectly like this:
>>
>> Target t; // global
>> void invokeBuildStep(Target currTarget, {type} dg)
>> {
>>      t = currTarget;
>>      dg();
>>      t = null;
>> }
>
> The functions invoked in the delegate till use the global target? Seems this would work.
>

That's the idea, yes.

>> Only thing though, is if there's any special members added to the Target
>> subclass being used, the user would have to cast 't' to access them. Then
>> again, that's an issue in the current design, too. I'll have to think
>> about
>> this...
>
> Maybe in that case it's better to pass the target to the delegate. Just provide several overloads of the function taking the delegate.
>

Perhaps. Something to think about anyway. Although, IIRC, I think already I ran into some trouble with IFTI, type inference, overloading, etc. when trying to do something like that... But anyway, all stuff to think about...