On 4/17/19 4:10 PM, JN wrote:
> "I find this to be D's biggest current stumbling block, even moreso than anything in the language or compiler" - really? The biggest D stumbling block is the fact that it's not easy to set up a mixed C/C++ project with D? 

Oh dear god that is not even *REMOTELY* in the ballpark of actual reality. Lets keep the blatant strawmen far away from this, please.

On Wed, Apr 17, 2019 at 02:57:05PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
[...]
> In response to suggestions from NaN and Russel, I'd like to move this to a Github project.  No code yet, just because I don't have any yet, but we can use the issues/PRs/wiki features to collaborate publicly in a more structured, less transient, way:
> 
> https://github.com/Abscissa/DPak

Awesome, let's see if we can actually get this thing off the ground.


> @H. S. Teoh: I forget your Github handle. Let me know and I'll add you as a collaborator.

@quickfur.


T

-- 
Famous last words: I *think* this will work...

On Wednesday, 17 April 2019 at 19:07:07 UTC, Nick Sabalausky (Abscissa) wrote:
> On 4/16/19 8:12 AM, Atila Neves wrote:
>> 
>> I'll take a look. In the meanwhile I started this:
>> 
>> https://github.com/kaleidicassociates/bud
>> 
>> It uses dub as a library to make sure that it works just as dub does, but bypasses what it can. The idea is to completely separate these disparate tasks:
>
> What is the current state of this tool?

In its infancy.

On Wed, 2019-04-17 at 20:32 +0000, Julian via Digitalmars-d wrote:
> 
[…]
> Is there no good C or C++ XML library that you could make a
> std.xml
> alternative out of? Maybe there'd be a dub package that you could
> just grab and use for now, that wrapped one, if this were an
> option
> for dub.
[…]

Isn't the current done thing just to make use of libxml2 ?

-- 
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, Apr 19, 2019 at 03:54:45PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> On 4/19/19 2:19 AM, Russel Winder wrote:
> > 
> > Looking at Gradle, Maven, Cargo, Go, Conan, the choice is for integrated dependency management and build. Dub it would seem has taken the right overall approach,
> 
> Well, it certainly seems to have taken a *popular* approach. I wouldn't necessarily take that as implying the "right" approach (for us).
[...]

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.

(Not to mention, I have a hard time justifying to myself installing a multi-GB program just to be able to compile a tiny bit of code. And the bare act of invoking Gradle soaks up GBs of RAM and takes forever and 64 days just to decide what it should be doing.  Perhaps I'm just a cranky old antiquated ape who needs to just get with the times, but I seriously cannot swallow that this is now the Accepted Way of Doing Things.  And with D compile times supposedly being one of its top selling points, I seriously cannot see how such an approach will work well in the long run.  (Though OTOH perhaps it will finally get rid of that cringe-inspiring fast-fast-fast motto.))

In any case, with all the work being poured into betterC and C++ interop, any proposed universal D build / package system MUST take into account interacting with C/C++ codebases, which generally do *not* use this integrated package/build approach.  At the very least, a D build system that has pretensions of being universal must allow easy integration of C/C++ codebases, and that means accepting the possibility of other build systems, and at least making an effort to work with them nicely.

This is why I proposed a standard "API" for the package manager to interact with arbitrary codebases with arbitrary build systems.  Rather than imposing arbitrary restrictions on how packages ought to be built, it should acknowledge that other build systems exist, and provide a simple, consistent way of interacting with them that will *still* work well with those who prefer the integrated approach.


T

-- 
If creativity is stifled by rigid discipline, then it is not true creativity.

On 4/19/19 5:58 PM, H. S. Teoh wrote:
> On Fri, Apr 19, 2019 at 03:54:45PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
>> On 4/19/19 2:19 AM, Russel Winder wrote:
>>>
>>> Looking at Gradle, Maven, Cargo, Go, Conan, the choice is for
>>> integrated dependency management and build. Dub it would seem has
>>> taken the right overall approach,
>>
>> Well, it certainly seems to have taken a *popular* approach. I
>> wouldn't necessarily take that as implying the "right" approach (for
>> us).
> [...]
> 
> 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.

No big surprise why a "my way or the highway philosophy" is more successful with a JVM audience than a D audience ;)

Like I alluded to: different language -> different audience -> different needs and requirements -> different "right" answers.

On Wednesday, 17 April 2019 at 08:50:31 UTC, Atila Neves wrote:
>> (For readers: this would lead the path to platform-based dependencies and configuration-based dependencies which are currently not doable, such as:
>>
>>     "dependencies-linux": { "x11": "~>1.0" }
>> )
>
> Yep!

I feel I've way overstated the soundness problems of DUB. Why "dependency-<platform>" and "dependency-<configuration>" is not supported is explained here, since two years... https://github.com/dlang/dub/wiki/FAQ

On Wednesday, 17 April 2019 at 20:32:28 UTC, Julian wrote:
> On Wednesday, 17 April 2019 at 20:10:08 UTC, JN wrote:
>
> Consider std.regex and https://github.com/jrfondren/topsender-bench
> The fastest std.regex option is more than 10x slower than libc
> regex, which is already too slow to seriously use for anything but
> once-off tasks.

Author of std.regex here. It's been awhile since I monitored its performance.
Still, let's drill down. Caveats emptor: I do not have your datafile, but I produced one by sampling example lines from the web.

First, your flags are a bit off for DMD, use the following:

dmd -release -inline -O

I know, not very intuitive. This more then doubles performance with dmd, std.regex is templated library (sadly) so it heavily depends on passing the right flags at the application level :(

For LDC I used the following (can't remember  if -O implies -release):

ldc2 -release -O

Second, if doing match per line regex it's best to use `matchFirst` instead of `match` which caches the engine in between calls. `match` is intended to plow through large chunks such as iterating over matches in memmory-mapped file and therefore creates new engine on each call to `match`.

With these two tweaks I get a respectful speed of 1.5x of PCRE/JIT.
IIRC PCRE_JIT option doesn't work for Unicode and std.regex supports Unicode by default.

In general I agree - std.regex needs more love, a casual look at disasembly shows some degradation compared to a couple years back. Truth is, code like that needs constant tweaking.

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.

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.

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.