On Fri, Apr 26, 2019 at 12:18:54AM +0000, aberba via Digitalmars-d wrote: [...]
> By the way, there are some people who consistently bash Dub at any opportunity they get. They just don't like Dub.

Because I tried using it and discovered that it wouldn't let me do what ought to be easy to do.  If it works fine for you, then good for you. It doesn't do what I need it to do, so I'd rather not use it, but it's forced upon me because without dub it's impractical to use code from code.dlang.org.  That's why I feel a lot of frustration with it -- it's something I can't avoid if I want to use code.dlang.org, but it also works very poorly for what I do.  I often feel like I'm up the proverbial creek without a paddle when I'm using dub.  It seems to work fine up your creek, but I need to be on *this* creek and dub refuses to give me a paddle to work with.


T

-- 
A linguistics professor was lecturing to his class one day. "In English," he said, "A double negative forms a positive. In some languages, though, such as Russian, a double negative is still a negative. However, there is no language wherein a double positive can form a negative." A voice from the back of the room piped up, "Yeah, yeah."

On Friday, 26 April 2019 at 00:18:54 UTC, aberba wrote:
> On Monday, 15 April 2019 at 18:31:01 UTC, Andre Pany wrote:
>> On Monday, 15 April 2019 at 17:17:49 UTC, Atila Neves wrote:
>>>> Integration of dub with LDC is working fine. I created a tutorial (german) here:
>
>> My assumption is, there are a lot of developers which uses dub without any issue and for them replacing Dub would be a major pain.
>>
> Dub works great for me too. I could  use some build speed though.
>
> By the way, there are some people who consistently bash Dub at any opportunity they get. They just don't like Dub.

As I've said on more than one occasion, for simple usage dub works fine. Slowly, but fine.

It just doesn't scale. Anything non-trivial is hard to do and has to be hacked together. I liked dub too when I used it for personal projects but then I had to use it to do "real work" and it quickly broke down.

On Friday, 26 April 2019 at 10:01:26 UTC, Atila Neves wrote:
> On Friday, 26 April 2019 at 00:18:54 UTC, aberba wrote:
>> On Monday, 15 April 2019 at 18:31:01 UTC, Andre Pany wrote:
>>> On Monday, 15 April 2019 at 17:17:49 UTC, Atila Neves wrote:
>>>>> Integration of dub with LDC is working fine. I created a tutorial (german) here:
>>
>>> My assumption is, there are a lot of developers which uses dub without any issue and for them replacing Dub would be a major pain.
>>>
>> Dub works great for me too. I could  use some build speed though.
>>
>> By the way, there are some people who consistently bash Dub at any opportunity they get. They just don't like Dub.
>
> As I've said on more than one occasion, for simple usage dub works fine. Slowly, but fine.
>
> It just doesn't scale. Anything non-trivial is hard to do and has to be hacked together. I liked dub too when I used it for personal projects but then I had to use it to do "real work" and it quickly broke down.

I fully agree with you on the current state while I have another idea on consequences.
Dub is no fully sophisticated build tool but that is OK. It is intended for the simple cases and it does a good job on that.

Use Dub for simple cases. Integrate Dub into existing Build tools for complex cases.

We may have to work on the integration cases to make them more smooth.

I also use Dub integrated into a Xmake implementation and that is working fine.

Kind regards
Andre

On Fri, 2019-04-26 at 13:06 +0000, Andre Pany via Digitalmars-d wrote:
> 
[…]
> Use Dub for simple cases. Integrate Dub into existing Build tools for complex cases.
> 
[…]

I started trying to use Dub purely for package fetch in SCons, but I stopped using SCons so stopped work on it. Also Dub has a weird way of managing package build products which was beginning to become a mountain over which is was rather difficult to climb.

If Dub was a library with a Python binding life would be a lot easier.

-- 
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 Fri, 2019-04-19 at 14:58 -0700, H. S. Teoh via Digitalmars-d wrote:
> 
[…]
> Yes. I for one dumped Gradle shortly after starting my Android project, because it just didn't let me do what I need to do, or at least not easily.  Gradle expects your typical Java codebase with standard source tree structure.  I needed D codegen and cross-compilation as integral parts of my build.  The two ... let's just say, don't work very well together.  It's the "my way or the highway" philosophy all over again. Yes it hides away a lot of complexity, and does a lot of nice things automatically -- when what you need to do happens to match the narrow use case Gradle was designed to do.  But when you need to do something *other* than the One Accepted Way, you're in for a long uphill battle -- assuming it's even possible in the first place.  To that, I say, No Thank You, I have other tools that fit better with how I work.
> 

Gradle is definitely not rigid as implied in the above: it can work with any source structure. True there is a default, and "convention over configuration" is the main philosophy, but this can be easily overiden by those who need to.

There are hooks for doing pre-compilation code generation, though I suspect whilst there is support for C++, there is no ready made support for D.

That you chose to ditch Gradle and go another way is entirely fine, but to denigrate Gradle as above based on what appears to be a single episode quickly abandoned, is a bit unfair to Gradle.

> 
[…]

The elided comments on Gradle requiring JVM and thus lots of memory and relatively slow startup is very fair. Much better grounds for your ditching of Gradle than not finding the Gradle way of doing things you needed to do.

I feel Gradle is probably not a good choice for D builds now, but it could be. This is because no-one is using for that purpose and so the easy to use, D oriented tools are not available, everything has to be done with the base Gradle tools.

-- 
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 Thursday, 25 April 2019 at 20:13:02 UTC, Bastiaan Veelo wrote:
> On Thursday, 25 April 2019 at 16:49:27 UTC, Dmitry Olshansky wrote:
>> P.S. I lack time or energy to improve on regex esp. in std proper. I hope to get back to my experiments on rewind-regex though. JIT compilation is on the list, mostly to avoid reliance on compiler + being more aggressive on low-level tricks.
>
> Hey Dmitry, nice to see you again!
>
> Bastiaan.

Thanks, I look forward to your DConf talk ;)

Recently, Nick & some others (including myself) created a Github project to discuss the possibility of a dub replacement that has a better architecture. In the course of analysing our current situation and where we'd like to be, Nick pointed out something that immediately strikes me as low-hanging fruit that could potentially improve dub's performance significantly.

According to Nick, every dub package carries its own description file (sdl/json) that encodes, among other things, its version and dependencies.  Apparently, this information resides per-package on code.dlang.org, and so every time dub has to resolve dependencies for a particular package, it has to download the description files of *every version* of the package??  Can somebody confirm whether or not this is really the case?

Because if this is true, that means dub is making N network roundtrips *per dependency* just to obtain dependency information from each package.  This is obviously extremely inefficient, and I'll bet that it's a significant source of dub's perceived slowness.

But this also immediately suggests a simple solution: upon uploading a package to code.dlang.org, the server should collect the description files of all versions of that package, and make that available somewhere in a per-package global description file.  It doesn't need to contain everything in dub.{sdl/json}; all it needs is version information and per-version dependency lists.  This way, whenever dub needs to resolve dependencies on that package, it can obtain all of the information it needs on that package with a single HTTP roundtrip.  Of course, it will still need to make more roundtrips in order to obtain information for sub-dependencies and other dependencies, but if what Nick says is true, this should significantly cut down on the total number of roundtrips required (O(n) as opposed to O(n*v), where n = #packages, v = #versions-per-package).


--T

On Fri, Apr 26, 2019 at 08:28:37PM +0000, H. S. Teoh via Digitalmars-d wrote: [...]
> According to Nick, every dub package carries its own description file (sdl/json) that encodes, among other things, its version and dependencies.  Apparently, this information resides per-package on code.dlang.org, and so every time dub has to resolve dependencies for a particular package, it has to download the description files of *every version* of the package??  Can somebody confirm whether or not this is really the case?
[...]

Actually, nevermind that.  Dub already combines the descriptions into a single file.  So the bottleneck(s) must lie elsewhere...


T

-- 
2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.

On Friday, 26 April 2019 at 22:33:50 UTC, H. S. Teoh wrote:
> On Fri, Apr 26, 2019 at 08:28:37PM +0000, H. S. Teoh via Digitalmars-d wrote: [...]
>> According to Nick, every dub package carries its own description file (sdl/json) that encodes, among other things, its version and dependencies.  Apparently, this information resides per-package on code.dlang.org, and so every time dub has to resolve dependencies for a particular package, it has to download the description files of *every version* of the package??  Can somebody confirm whether or not this is really the case?
> [...]
>
> Actually, nevermind that.  Dub already combines the descriptions into a single file.  So the bottleneck(s) must lie elsewhere...
>
>
> T

Also with recent Dub version a major performance optimization was done
https://dlang.org/changelog/2.086.0.html#single-api-requests

In addition Sebastian is also working on parallel dependencies download.

Kind regards
Andre

On Friday, 26 April 2019 at 20:28:37 UTC, H. S. Teoh wrote:
> Recently, Nick & some others (including myself) created a Github project to discuss the possibility of a dub replacement that has a better architecture. In the course of analysing our current situation and where we'd like to be, Nick pointed out something that immediately strikes me as low-hanging fruit that could potentially improve dub's performance significantly.
>
> [...]

https://dlang.org/changelog/2.086.0.html#single-api-requests

Though tere are still a ton of other easy low-hanging fruits which is why I started this thread.