On Tuesday, 1 December 2015 at 02:46:46 UTC, lobo wrote:
> Red started out as a Rebol 2 clone and last I checked (18 months ago) it was still is Rebol 2 compatible.
>
> http://www.red-lang.org/

Thanks!

On Tuesday, 1 December 2015 at 05:39:26 UTC, Craig Dillabaugh wrote:
> On Tuesday, 1 December 2015 at 04:54:23 UTC, James Hofmann wrote:
>> [...]
>
> Sorry, I think that most of what you said made good sense, but I am a bit confused by the quoted bit.  So you want the DUB config files written in full-blown JavaScript? Then DUB and the other tools would need a JavaScript compiler built-in.

You can use dub packages and write descriptions of how to build them in Javascript with reggae. Today.

Atila

On Tuesday, 1 December 2015 at 10:27:45 UTC, Atila Neves wrote:
> On Tuesday, 1 December 2015 at 05:39:26 UTC, Craig Dillabaugh wrote:
>> On Tuesday, 1 December 2015 at 04:54:23 UTC, James Hofmann wrote:
>>> [...]
>>
>> Sorry, I think that most of what you said made good sense, but I am a bit confused by the quoted bit.  So you want the DUB config files written in full-blown JavaScript? Then DUB and the other tools would need a JavaScript compiler built-in.
>
> You can use dub packages and write descriptions of how to build them in Javascript with reggae. Today.
>
> Atila

A example of this would be nice. Also... you can grab with dub a dependency package that is build with reggae ?

On Tuesday, 1 December 2015 at 09:43:24 UTC, Idan Arye wrote:
> Red is not Rebol2 compatible - it's outright impossible to have a single script file that'll run without errors on both Rebol2 and Red. The reason is that Rebol2 requires the first thing in the file to be a `REBOL` preamble, while Red requires it to be a `Red` preamble(though it's generous enough to allow a shebang before it). Since you can only have one preamble, and it can't be both `REBOL` and `Red`, I refuse to call them compatible even if every Rebol2 command can be copied to a Red script and run in there!
>

Meh, beyond s/Rebol/Red all my R2 code runs with Red.

> At any rate, please don't use any Rebol dialect in DUB(or for anything else, in that matter. Just - don't use it). Many languages have awkward quirks, but Rebol seems to be a collection of awkward quirks with a programming language somtimes accidentally hiding in between, created by someone who thought Perl is too readable and shell scripts have too strict type systems.

Actually I find Rebol has less quirks than most languages. It does have one alien looking syntax though.

bye,
lobo

On Mon, 2015-11-30 at 20:42 +0000, Suliman via Digitalmars-d wrote:
> Should we try to implement yet another language for writing building config? Maybe we should use any of existence language that may be very good for it, like Red. It have very small foot prints so it can be easy to embeded to build system.

Writing a build system in a languages such as Python, Scala, Java/Groovy or even D, is not writing a new language, it is writing an internal DSL in that language. Make and CMake are new languages, they are external DSLs with compilers, etc.

In all cases the DSL is a front to a constraint-based system with resolution: Make, SCons, CMake, Gradle, SBT are all the same in this respect. Maven is somewhat different but only somewhat.

What we currently have with Dub as I understand it is a constraint satisfaction engine with two front ends. I am not sure why this causes such warfare. Ant is a build engine with an XML and a Groovy front end, those that like XML use that, those that do not can use Groovy. I am unaware of any warfare in the Ant community about this choice.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, 2015-11-30 at 21:05 +0000, Ola Fosheim Grøstad via Digitalmars- d wrote:
> 
[…]
> No, I wasn't really talking about a build system for D, more like a hypothetic generic distributed build system for all languages. But I've read that Google uses a distributed build system for their big C++ applications. So people are working on such solutions already.

I think you are meaning Bazel here. http://bazel.io/

I haven't had chance to play with it as yet, and it changes massively every day – though I suspect it is the internal of the satisfaction engine that change not the specification notation (which looks a bit like a Python/SCons/Waf type thing). I will be playing with it over the next few weeks, so more news later.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 1 December 2015 at 12:07:51 UTC, Russel Winder wrote:
> I think you are meaning Bazel here. http://bazel.io/
>
> I haven't had chance to play with it as yet, and it changes massively every day – though I suspect it is the internal of the satisfaction engine that change not the specification notation (which looks a bit like a Python/SCons/Waf type thing). I will be playing with it over the next few weeks, so more news later.


That's interesting, I didn't know they were going to make it publicly available. The FAQ says it supports Java, Objective-C and C++ out of the box. So I guess that means there is infrastructure for adding other languages too.

On Tuesday, 1 December 2015 at 12:03:35 UTC, Russel Winder wrote:
> I am not sure why this causes such warfare. Ant is a build engine with an XML and a Groovy front end, those that like XML use that, those that do not can use Groovy. I am unaware of any warfare in the Ant community about this choice.

For me the only valid reason to drop SDL would be the IDE integration. This is not what had triggered the "war" but anyway...It seems that most of the D people don't use an IDE, so they don't get the problem. But they should (use an IDE and get why two formats is a problem).

Do you want to see the problem with people who don't use an IDE:

https://github.com/D-Programming-Language/phobos/pull/3821/files#diff-52580fb75b304ba7b04a6b178fe6cdf4L3085

with completion, the author would not import a module that does not exist: std -> dot -> list popup...

;)

On Tuesday, 1 December 2015 at 10:33:05 UTC, Luis wrote:
> On Tuesday, 1 December 2015 at 10:27:45 UTC, Atila Neves wrote:
>> On Tuesday, 1 December 2015 at 05:39:26 UTC, Craig Dillabaugh wrote:
>>> On Tuesday, 1 December 2015 at 04:54:23 UTC, James Hofmann wrote:
>>>> [...]
>>>
>>> Sorry, I think that most of what you said made good sense, but I am a bit confused by the quoted bit.  So you want the DUB config files written in full-blown JavaScript? Then DUB and the other tools would need a JavaScript compiler built-in.
>>
>> You can use dub packages and write descriptions of how to build them in Javascript with reggae. Today.
>>
>> Atila
>
> A example of this would be nice. Also... you can grab with dub a dependency package that is build with reggae ?

Modulo bugs, it's no different than writing it in D. The git repository has documentation, and the JS-specific part is handled by reggae-js.

Atila

On Tue, 01 Dec 2015 12:22:32 +0000, Ola Fosheim Grøstad wrote:

> On Tuesday, 1 December 2015 at 12:07:51 UTC, Russel Winder wrote:
>> I think you are meaning Bazel here. http://bazel.io/
>>
>> I haven't had chance to play with it as yet, and it changes massively every day – though I suspect it is the internal of the satisfaction engine that change not the specification notation (which looks a bit like a Python/SCons/Waf type thing). I will be playing with it over the next few weeks, so more news later.
> 
> 
> That's interesting, I didn't know they were going to make it publicly available. The FAQ says it supports Java, Objective-C and C++ out of the box. So I guess that means there is infrastructure for adding other languages too.

So they open sourced Blaze. Interesting, but not very useful.

Bazel, like Blaze, wants to keep a very granular build unit with explicit dependencies. It aims to keep very little per-language logic in the build system. The tradeoff is that humans have to supply it all.

DUB aims to have very tight integration with D, and build granularity isn't a large goal. This means it's nearly useless for building any other language, and it would probably die if you tried to build a project with a million lines of code with it. But on the other hand, I can write a build file that just contains the project name and what dependencies it has and I'm off to the races.

Amazon internally has a build system called Brazil. (My information is probably four years out of date now.) It's basically a multilanguage Maven, hampered by an ugly web interface and a concept of "version sets" -- which is essentially the same as dub.selections.json, but you have to maintain it manually. That model, minus the web interface and manually curating version selections, would work much better with most small to medium projects in the wild. Add a source distribution option (to avoid having to build N versions of the same library; we're not all on JIT) and Bob's your uncle.