February 02, 2015
On Monday, 2 February 2015 at 03:50:10 UTC, Joakim wrote:
> C and C++ are very general-purpose, but they can still be considered as a "niche" of performance languages.  What's wrong with D aiming for that "niche?"

Most uses of C & C++ that haven't migrated to well-supported garbage-collected languages by now are those that cannot work with a garbage collector and/or are heavily tied to an existing C++ code base. Offering something much better for that niche/domain would be a great opportunity, and not a small niche.

The point is to focus efforts for one release on fully addressing what that domain requires. The next release can focus on another domain. And so on.
February 02, 2015
"Vladimir Panteleev"  wrote in message news:viqwfixznbdbdwvhavuk@forum.dlang.org...

> I don't use Dub

You really should!  I put it off for months and months but I'm quite happy with it now. 

February 02, 2015
On Mon, 02 Feb 2015 16:24:00 +1100, Daniel Murphy wrote:

> "Vladimir Panteleev"  wrote in message news:viqwfixznbdbdwvhavuk@forum.dlang.org...
> 
>> I don't use Dub
> 
> You really should!  I put it off for months and months but I'm quite happy with it now.

dub is very limited tool. first: it can't do separate compilation. some of my modules, for example, do alot of CTFE things (including parsing disk files) and eating memory like crazy. there is simply no way to to batch compiles for me. besides, batch compile means that if i'll change one line in one module, dub will recompile them all, so i forced to group modules to libraries by size, not by intent.

second: dub can't compile code in other languages. some of my projects includes several C modules, for example, and my build tool has no problems building that and automatically tracking dependencies.

third (it's an extension of second, actually): track arbitrary dependencies and exec arbitrary tools to generate some files based on that dependencies.

dub is good, but only in limited use cases. so it's almost no sense in using dub if some use cases are not suitable for it: it's way better to adapt build tool that one already using (or write his own) instead of use TWO build tools for different projects.

February 02, 2015
On Monday, 2 February 2015 at 05:57:27 UTC, ketmar wrote:
> On Mon, 02 Feb 2015 16:24:00 +1100, Daniel Murphy wrote:
>
>> "Vladimir Panteleev"  wrote in message
>> news:viqwfixznbdbdwvhavuk@forum.dlang.org...
>> 
>>> I don't use Dub
>> 
>> You really should!  I put it off for months and months but I'm quite
>> happy with it now.
>
> dub is very limited tool. first: it can't do separate compilation. some
> of my modules, for example, do alot of CTFE things (including parsing
> disk files) and eating memory like crazy. there is simply no way to to
> batch compiles for me. besides, batch compile means that if i'll change
> one line in one module, dub will recompile them all, so i forced to group
> modules to libraries by size, not by intent.
>
> second: dub can't compile code in other languages. some of my projects
> includes several C modules, for example, and my build tool has no
> problems building that and automatically tracking dependencies.
>
> third (it's an extension of second, actually): track arbitrary
> dependencies and exec arbitrary tools to generate some files based on
> that dependencies.
>
> dub is good, but only in limited use cases. so it's almost no sense in
> using dub if some use cases are not suitable for it: it's way better to
> adapt build tool that one already using (or write his own) instead of use
> TWO build tools for different projects.

You can do separate compilation (--build-mode=singleFile).
It was implemented, quick and dirty (my bad), for one purpose: compile Vibe.d on a very limited machine (512 Mbs of RAM).
It has, however, no tracking of module dependency ATM, so it'll recompile everything, everytime. This is a known issue which, either no one is interested in, or no one has the time to. I also remember facing DMD bugs when I gave it a shot, but they may be fixed by now (one of them is for sure), so maybe this feature needs a second chance.

I will not disagree on the other points (support for other languages is what I'm missing most ATM).

If you wish to contribute patches, contact me, and I'll be the strawman (geod24/gmail).
February 02, 2015
On 2015-02-02 06:57, ketmar wrote:

> dub is good, but only in limited use cases. so it's almost no sense in
> using dub if some use cases are not suitable for it: it's way better to
> adapt build tool that one already using (or write his own) instead of use
> TWO build tools for different projects.

Dub should have been two tools, one for package management and one for building.

-- 
/Jacob Carlborg
February 02, 2015
On Mon, 02 Feb 2015 08:35:07 +0100, Jacob Carlborg wrote:

> On 2015-02-02 06:57, ketmar wrote:
> 
>> dub is good, but only in limited use cases. so it's almost no sense in using dub if some use cases are not suitable for it: it's way better to adapt build tool that one already using (or write his own) instead of use TWO build tools for different projects.
> 
> Dub should have been two tools, one for package management and one for building.

i agree with you. the best thing of dub -- package management and dependency management -- should be easily accessible. something like "pkg- config", but with ability to download/install/uninstall/upgrade packages. i.e. pkg manager like "apt" ;-), plus "pkg-config" functionality to allow using in various build tools.

but i think that it's too late now to separate this dub parts. :-(

February 02, 2015
On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy wrote:
> "Vladimir Panteleev"  wrote in message news:viqwfixznbdbdwvhavuk@forum.dlang.org...
>
>> I don't use Dub
>
> You really should!  I put it off for months and months but I'm quite happy with it now.

Replied in a new thread here:

http://forum.dlang.org/post/ysnfzpvrcvmjdekulfnq@forum.dlang.org
February 02, 2015
On Sun, 2015-02-01 at 22:46 +0100, Andrej Mitrovic via Digitalmars-d-announce wrote:
> On 2/1/15, Andrei Alexandrescu via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:
> > http://wiki.dlang.org/Vision/2015H1
> 
> - Create the D Language Foundation
> 
> What exactly is this idea about, can you elaborate a bit?

Given involvement with SCons (which used to have a foundation, but it seems to have lapsed, but we need it), and Groovy (never had one but almost certainly needs one now), I see three main issues:

— A centralized organization supporting the distributed FOSS project, giving other organizations a generalized single point of contact. Also having an organization, not just a collection of individuals, given other organizations confidence in support, continuity and development.

— A legally established foundation can be the holder of IP. It makes any debates about licencing, etc. easier if there is a single entity to deal with. Really though this is more to keep other organizations happy and confident.

— A foundation can be a funds collection and redistribution entity.
Again stuff can happen without a central "not for profit"
organization, but it generates confidence in other organizations if
there is one. Strong rather than small intermittent funded activity is
more likely with a foundation than without.

Then you get the questions of where (in which jurisdiction), and who
are the "directors" and how do they get changed.

There are many "off-the-shelf" organizational structures so it is "pick one". The problem of jurisdiction is more difficult these days. The usual knee-jerk reaction is "create a 'not for profit' in the USA". (Actually for D, like SCons, this is probably the most sensible start point; for Groovy it is far more difficult and less the right choice.) Unofficial legal opinion is that the USA government is currently very anti any new software language foundations. If true, that makes the Python Software Foundation model not viable. This would leave joining Eclipse or Apache (not really viable for D or SCons I suspect), or the Software Conservancy. A number of projects have gone this route, SCons is considering it since re-establishing a fully independent SCons Foundation is seeming an up-hill struggle.

I am not a lawyer.
-- 
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

February 02, 2015
On Mon, 2015-02-02 at 07:59 +0000, ketmar via Digitalmars-d-announce wrote:
> […]
> 
> but i think that it's too late now to separate this dub parts. :-(

Far from it. Now is the time to do it. There has been enough use of it that there is genuine practical experience of the workflows and the ups and downs. Now is the time to harness that experience and create the right system. Assuming it cannot change now would be a disservice.

All the new languages are doing package management effectively the same way, D, Rust, Ceylon. The Python egg → wheel shows it is possible to change.

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

February 02, 2015
KDE is a german e.V. (eingetragener Verein, registered association [1] ). Maybe that's an option for D, too.


[1] http://en.wikipedia.org/wiki/Eingetragener_Verein