On Wed, 31 Jan 2018 00:34:48 +0000, Benny wrote:

> https://crates.io/categories

Thanks. I wish that was easier to find though. I still don't see how to get there without knowing it already exists.


> The issue is that a lot of D's packages are even less maintained then Rust, mostly because Rust being newer and attracting more active crowds. And it does not help when Dmd having constant deprecating functions and regressions ( what happens WAY too often ) that break packages.
> 
> Its a long term weakness. Depending on 3th party packages is always dangerous but even more so when the compiler forces people to use older versions, just to stay safe.

Yeah, I'm not sure how cruft should be handled; maybe move anything that hasn't had a single commit in 4 years to an Archive category which is hidden by default... at the rate D changes, even the simplest libraries that haven't been touched in four years likely have a deprecation or error to handle (or documentation that could be improved), and if the registry could create an issue as a warning first, nobody should be surprised by their project being archived.

I wonder if the Dub registry could read a CI configuration file to grab the tested D compilers in a repo, and display them on the package's page as supported compilers. I don't know if people would interpret that to imply that the package is incompatible with anything not listed though.

On Tue, 2018-01-30 at 17:26 +0000, Ola Fosheim Grøstad via Digitalmars-
d wrote:
[…]
> Grounded Theory cannot be used for trend analysis though.
[…]

Quite right, good point.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Tue, 2018-01-30 at 11:55 +0000, rjframe via Digitalmars-d wrote:
> On Tue, 30 Jan 2018 10:38:31 +0000, Russel Winder wrote:
> 
[…]
> 
> Are you sure? Every project on my PC places the build files in $PROJECTDIR/.dub/build; the source is in ~/.dub/packages.

I see the source of the dependencies both in ~/.dub/packages and in the project .dub directory, but I see the compilation products in ~/.dub/packages. There are every compiled version in obscure named sub- directories and the last compiled (unknown compiler and options) in the dependency directory.

Compilation seems to be only of .a and not (.so|.dll).

> That said, the name of the compiler is kept in the directory
> structure (as
> well as architecture and OS), which means there could be advantages
> to
> placing build artifacts globally, since compiler changes would still
> be
> separated, we get a reduction in disk usage and (sometimes) compile
> speed
> for already-built libraries.

In which case, why is there anything in the project directory at all.

Also the OS/compiler/options is all encoded in a very long and obscure naming directory name, rather than a nice directory hierarchy. Chapel made this switch and it improved everything a lot.

[…]
> This would be nice. I wonder though if the community is too small for
> this
> right now; remove the necessity of the central repository and it may
> die
> (I would say it's somewhat struggling as it is) -- and when it comes
> to
> finding libraries there are advantages to it that Github doesn't
> have.

I think not. The Rust experience is that the mixed economy of central released and actively curated (though Rust hasn't quite got to that yet sadly, there is a build up of crap just as happens with PyPI) and use of Git repository HEADs works very well. The Go experience of not having a central place, just the Git/Mercurial/Bazaar/Breezy repositories leads to a lot of hassle, and thence to vendoring. Ceylon as well as D only has the central repository and it can be very annoying.

Having the central repo is a good thing, but having access to DVCS is as well.

> 
> > The Cargo repository is just nicer than the Dub repository.
> 
> 
> […]

Clearly there is debate to be had about the Cargo vs. Dub repositories, I agree and disagree with the points you made, but that is for the Dub forum I guess.

(I hate forums without email support, but I guess I could look at the
Dub forum from time to time.)

> 
> > Cargo uses TOML project specifications, Dub uses JSON or SDL. Cargo wins, Dub doesn't.
> 
> Agreed.

Sadly I suspect there is no future in this point, the JSON/SDL fight
seems to have used up everyone's energy and moving to an actually good
format is not on the cards.

> […]
> Have you opened issues on the dub repository for the various problems
> you
> see?

Not as yet, but I guess I will have to overcome my abhorrence of forums, and post to the Dub forum.

(Did I mention I really hate forums with no email interface. Probably.)

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Monday, 29 January 2018 at 11:48:07 UTC, Russel Winder wrote:
> I am less convinced by this argument. Go, Rust, and especially Java have shown the power of tribalism and belonging to the one true tribe eschewing all others. Java is a superb example of this: the JVM is now a polyglot platform, and yet Java programmers, especially enterprise ones, will only contemplate using Java and refuse to be educated about Kotlin, Ceylon, Groovy, JRuby, etc. However when a feature inspired (many years later) by the innovations in other JVM-based languages gets shoehorned into Java then, eventually, the Java folk are prepared, reluctantly, to learn about it. And maybe a few years later actually use it.

I thought this was a killer anecdote about maybe the first programming language war... over assembly language:

"Margaret Hamilton, a celebrated software engineer on the Apollo missions—in fact the coiner of the phrase 'software engineering'—told me that during her first year at the Draper lab at MIT, in 1964, she remembers a meeting where one faction was fighting the other about transitioning away from 'some very low machine language,' as close to ones and zeros as you could get, to 'assembly language.' 'The people at the lowest level were fighting to keep it. And the arguments were so similar: ‘Well how do we know assembly language is going to do it right?’'

'Guys on one side, their faces got red, and they started screaming,' she said. She said she was 'amazed how emotional they got.'

Emmanuel Ledinot, of Dassault Aviation, pointed out that when assembly language was itself phased out in favor of the programming languages still popular today, like C, it was the assembly programmers who were skeptical this time."
https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/

Good to see things haven't changed in a half-century. ;) Not that I'm saying assembly was the obvious choice: maybe their assemblers were buggy or slow or whatever, it all depends on the details.

On 2018-02-01 13:19, Russel Winder wrote:

> I see the source of the dependencies both in ~/.dub/packages and in the
> project .dub directory, but I see the compilation products in
> ~/.dub/packages. 

I'm wondering if this might be different versions of Dub behaving differently. I have 79 packages in ~/.dub/packages and only three object files in two different projects.

$ ls -l ~/.dub/packages | wc -l
      79

$ cd ~/.dub/packages && find . -name '*.o'
./dfmt-0.4.4/.dub/build/application-debug-posix.osx-x86_64-dmd_2069-EEECF44B144F658EA70D0E82862DE408/dfmt.o
./dfmt-0.4.4/.dub/build/application-debug-posix.osx-x86_64-dmd_2070-5AD8691A40E4B0418752E48F1E27075F/dfmt.o
./unit-threaded-0.7.15/unit-threaded/.dub/build/gen_ut_main-debug-posix.osx-x86_64-dmd_2072-5674F70F27B1DC65A685FF95F866B7F7/gen_ut_main.o

> There are every compiled version in obscure named sub-
> directories and the last compiled (unknown compiler and options) in the
> dependency directory.

It's just a cache, it's not something that the user need to look at.

-- 
/Jacob Carlborg

On Thursday, 1 February 2018 at 12:19:48 UTC, Russel Winder wrote:
> On Tue, 2018-01-30 at 11:55 +0000, rjframe via Digitalmars-d wrote:
>> On Tue, 30 Jan 2018 10:38:31 +0000, Russel Winder wrote:
>> 
> […]
>> 
>> Are you sure? Every project on my PC places the build files in $PROJECTDIR/.dub/build; the source is in ~/.dub/packages.
>
> I see the source of the dependencies both in ~/.dub/packages and in the project .dub directory, but I see the compilation products in ~/.dub/packages. There are every compiled version in obscure named sub- directories and the last compiled (unknown compiler and options) in the dependency directory.
>
> Compilation seems to be only of .a and not (.so|.dll).

Whether it's .a or .so depends on the dependent package being `staticLibrary` or `dynamicLibrary`. It's possible for a package to be both if it has a configuration for each.

Personally I don't even see the point - just link all the .o files. In a traditional build system static libraries might be useful to specify that multiple targets link to this particular binary blob. With dub there's only ever one binary anyway.

And at this point in time I think shared libraries are mostly a mistake. The only time I use them is when I have to, as in when developing Python extensions.

Atila

On Fri, 2018-02-02 at 10:03 +0000, Atila Neves via Digitalmars-d wrote:
> 
[…]
> Whether it's .a or .so depends on the dependent package being `staticLibrary` or `dynamicLibrary`. It's possible for a package to be both if it has a configuration for each.

I think that is one of my points, the package source downloaded from the Dub repository should not be determining whether a .a or ,so is produced, it should be determined by the receiver of the downloaded package.

> Personally I don't even see the point - just link all the .o files. In a traditional build system static libraries might be useful to specify that multiple targets link to this particular binary blob. With dub there's only ever one binary anyway.

But a static library is just a collection of .o files so I think it fits with "link all the .o together".

It is clear that there is a move in the Go, Rust, D communities to rejecting the concept of shared library, and that 100MB executables are acceptable.

> And at this point in time I think shared libraries are mostly a mistake. The only time I use them is when I have to, as in when developing Python extensions.

The single biggest argument for shared libraries in D is GtkD. Linking an executable with a static GtkD library takes ages, and when developing you do a lot of linking. Fast turnaround, and thus reasonable development times, requires use of a shared library for GtkD.


-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Friday, 2 February 2018 at 14:04:09 UTC, Russel Winder wrote:
> On Fri, 2018-02-02 at 10:03 +0000, Atila Neves via Digitalmars-d wrote:
>> 
> […]
>> Whether it's .a or .so depends on the dependent package being `staticLibrary` or `dynamicLibrary`. It's possible for a package to be both if it has a configuration for each.
>
> I think that is one of my points, the package source downloaded from the Dub repository should not be determining whether a .a or ,so is produced, it should be determined by the receiver of the downloaded package.
>
>> Personally I don't even see the point - just link all the .o files. In a traditional build system static libraries might be useful to specify that multiple targets link to this particular binary blob. With dub there's only ever one binary anyway.
>
> But a static library is just a collection of .o files so I think it fits with "link all the .o together".

Not quite. There's an extra step and when linking with a static library unused symbols are thrown away by default. That hid a dmd bug in 2.078.0 that only manifests when linking with the object files themselves.

>
> It is clear that there is a move in the Go, Rust, D communities to rejecting the concept of shared library, and that 100MB executables are acceptable.

On a desktop, 100MB executables are, at least to me. Shared libraries aren't going to magically make 100MB executables disappear, it depends on how much code is actually shared.

>
>> And at this point in time I think shared libraries are mostly a mistake. The only time I use them is when I have to, as in when developing Python extensions.
>
> The single biggest argument for shared libraries in D is GtkD. Linking an executable with a static GtkD library takes ages, and when developing you do a lot of linking. Fast turnaround, and thus reasonable development times, requires use of a shared library for GtkD.

That's a fair point.

Atila