On Monday, 11 November 2019 at 13:44:28 UTC, Robert Schadek wrote:
> So dub has some problems, and personally I find its code base very hard to get
> into.
> At Symmetry we are a very heavy user of dub, resulting in many wasted hours.
>
> So I started to write dud [1]. I kept some boring/nice parts from dub, but most
> code so far is a complete rewrite.
>
> The goal of dud is mostly do what dub does, but more understandable.
> dud will/does aim for a tasteful subset of dub's features.
> Meaning, most dub files should be good with dud.
> If they are not, you will/should get an error message telling you whats wrong.
> The bigger goal, at least personally, is to have a code base of pure functions
> that is "trivial" to understand and debug.
> The rules of thumb is: "When your line gets longer than 80 characters,
> restructure your code!", "Branch statements are code smells."
>
> So what can dud do right now.
>
> $ dud convert
>
> works.
> IMO that is an important step, as this involves ingesting dub.(json|sdl) into
> a common representation.
>
> I use dubproxy [2] to get all ~1.6k packages from code.dlang.org and create a
> git working tree for all the versions of all the packages.
> Currently, that results in ~60k (package|dub).(json|sdl) files.
> Then, I run dud on those and see what breaks.
> Only a few percent are not ingestable by dud, and those are in IHMO not valid
> anyway (to be fair, there is some strange 💩 out there).
>
> Now that dud can parse dub files, the next step will be a semantic phase,
> checking the input for errors.
> After that, path expansion and dependency resolution.
>
> PR's are always welcome.
>
> Destroy!
>
> [1] https://github.com/symmetryinvestments/dud
> [2] https://github.com/symmetryinvestments/dubproxy

Is there any chance you can be convinced to join our force to improve Dub?
A lot of developers invested their time to either improve Dub in general
or to get their needed scenarios running.

My gut feeling is, it would take years to rebuild the same set of functionality
starting from the green field.

The code base of Dub isn't that bad. I also invested time and there are some
parts you can easily get into. Of course there are also some parts which are quite
complex but I would say this is caused by their nature (Dependency resolution
is a quite complex topic).
But really the other parts are straightforward.

The biggest issue with Dub is to find out whether some specific parts a bugs
or intended feature. But this issue you will also face if you rebuild the
functionality of Dub. You never know whether it was intended or it is a bug,
or you should it work.

Every effort which is put into Dub is immediately available for the whole
D community, free developers and also companies from small size to the biggest size.

(In no way I want to say you should not work on Dud, it is just my hope we can
win you to help working on Dub).

Kind regards
André

On Monday, 25 November 2019 at 11:59:11 UTC, Andre Pany wrote:
> Is there any chance you can be convinced to join our force to improve Dub?
> A lot of developers invested their time to either improve Dub in general
> or to get their needed scenarios running.
>
> My gut feeling is, it would take years to rebuild the same set of functionality
> starting from the green field.

The distinction seems academic at this stage, because nothing stops anyone blessing dud as dub 2.0 when it's in a good enough state to be used in production, and nothing stops dub devs and contributors from offering feedback and code to help out with dud.  And even if Robert were to work inside the dub repo, the basic tasks -- going bottom-up to rewrite core data structures and algorithms, etc. -- would still be mostly the same.

That's why I strongly recommend that at this stage, the focus should be on the behaviours we want from our build system, and how they should interact and overlap.

What's currently broken or impossible in DUB?  What parts of that can be fixed without changing the config or CLI?  And what improvements are most efficiently made via breaking changes?

Please, let's bring our focus on that.

On Monday, 25 November 2019 at 12:15:42 UTC, Joseph Rushton Wakeling wrote:
> What's currently broken or impossible in DUB?  What parts of that can be fixed without changing the config or CLI?  And what improvements are most efficiently made via breaking changes?
>
> Please, let's bring our focus on that.

The biggest thing for me would be incremental compilation. As well as a dub build and test 'watch' mode to avoid scanning the dependencies every time.

On Monday, 25 November 2019 at 13:14:09 UTC, Sebastiaan Koppe wrote:
> The biggest thing for me would be incremental compilation. As well as a dub build and test 'watch' mode to avoid scanning the dependencies every time.

I think there are two levels to incremental compilation (IC).

1. File level IC. Meaning, if you have one file change, you only recompile
all files that depend on that directly or transitively. Finally, you relink.

2. Symbol level IC. Meaning, the compiler becomes a daemon, and you track
dependency on a symbol basis.

For 1. my goal with dud is to do that. My first target is to emit ninja files.
So IC is going to be the default, at least at first.

For 2. dud is build as a library first, meaning should the compiler
become a daemon at some point, libdud can be used to pull in packages from
code.dlang.org and resolve dub packages dependencies.

On Mon, Nov 25, 2019 at 12:15:42PM +0000, Joseph Rushton Wakeling via Digitalmars-d-announce wrote: [...]
> What's currently broken or impossible in DUB?

I'm probably not the intended audience here, but just so it's out there, here's a list of dub showstoppers for me:

- lack of support for multi-language projects.  E.g., a mixed C++/D
  codebase, or a Java/D codebase.  (I didn't check, but supposedly this
  can be done as a pre/post action, but it's hacky and not
  well-integrated into the dependency resolution system).

- lack of support for build-time code generation (i.e., build a subset
  of files into an executable, run the executable to generate .d files,
  compile output .d files plus other existing .d files into final
  product).

- lack of support for cross-compilation (e.g., cross-compile to Android
  from a Linux x86 host, or cross-compile from Linux host to Windows
  executable via wine / cygwin).

- lack of support for multiple targets (i.e., from given subsets of
  source files (with overlapping core files), build one executable for
  Linux/X11, build another executable in APK form for Android target).

- unfriendly towards integration with other existing build systems
  (e.g., build a sub-project with cmake, then integrate products into
  current D project with dub).

Probably some (all?) of these will require breaking changes because of the way dub is designed, so I'm not expecting this list will be met anytime in the near future. Though I'd love to be pleasantly surprised!


--T

On Monday, 25 November 2019 at 18:28:55 UTC, H. S. Teoh wrote:
> On Mon, Nov 25, 2019 at 12:15:42PM +0000, Joseph Rushton Wakeling via Digitalmars-d-announce wrote: [...]
>> [...]
>
> I'm probably not the intended audience here, but just so it's out there, here's a list of dub showstoppers for me:
>
> [...]


I am interested in D/java project. Can you help me with material or link on that. I Will be happy to use javafx as front end and D as back end for a desktop App.

I have looking on GraalVm but no luck yet. Just need a good tutorial for a start-up

On Mon, Nov 25, 2019 at 07:48:46PM +0000, GreatSam4sure via Digitalmars-d-announce wrote: [...]
> I am interested in D/java project. Can you help me with material or link on that. I Will be happy to use javafx as front end and D as back end for a desktop App.
> 
> I have looking on GraalVm but no luck yet. Just need a good tutorial for a start-up

So far, my only experience with interfacing Java with D is my Android project, that involves Java code talking to Android's Java GUI APIs, communicating with D code via JNI.

If you wish to go this route, I'd recommend reading up on JNI. The docs are mostly geared for interfacing with C/C++ code, but it should be relatively easy to interface with D code the same way.  You just need to declare JNI methods in a D module so that D code can call it. Also, need to be aware of JNI quirks to avoid runtime crashes.  With D's compile-time introspection capabilities, I was able to come up with a quite-nice wrapper for the JNI API, that saves a lot of typing (JNI is notoriously verbose to setup per call across the JNI boundary).

In a nutshell, you declare native methods in your Java class(es), then
write a D module with appropriately-named functions according to JNI
naming convention, and compile that into an .so (or .lib), then use
System.loadLibrary() to load the methods at runtime, then call away.

This assumes the main program is started in Java, of course.  I haven't tried doing it the other way (having main() in D, and calling Java from there), but I imagine it'd be pretty similar: link with a JVM, and in D's main() call whatever methods it takes to create the VM, then use JNI to call Java methods in that VM instance.


Compiling a mixed-language project is a separate issue.  Dub is, sad to say, of no help here. You're better off using something like CMake, or something of that sort. I use SCons, but it's not as well-known and does require a bit of an initial learning curve.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher

On Monday, 25 November 2019 at 18:28:55 UTC, H. S. Teoh wrote:
> - lack of support for cross-compilation (e.g., cross-compile to Android
>   from a Linux x86 host, or cross-compile from Linux host to Windows
>   executable via wine / cygwin).

You're not up to speed, this has been solved with latest dub and LDC. No need for any Wine/Cygwin/MinGW/... either.

On Monday, 25 November 2019 at 19:48:46 UTC, GreatSam4sure wrote:
> On Monday, 25 November 2019 at 18:28:55 UTC, H. S. Teoh wrote:
>> On Mon, Nov 25, 2019 at 12:15:42PM +0000, Joseph Rushton Wakeling via Digitalmars-d-announce wrote: [...]
>>> [...]
>>
>> I'm probably not the intended audience here, but just so it's out there, here's a list of dub showstoppers for me:
>>
>> [...]
>
>
> I am interested in D/java project. Can you help me with material or link on that. I Will be happy to use javafx as front end and D as back end for a desktop App.
>
> I have looking on GraalVm but no luck yet. Just need a good tutorial for a start-up

I once got a php/D bridge proof of concept, that should have worked with Java as well:
- create some D utility code,
- make an extern (C) API,
- write the C headers of the API,
- use swig (http://www.swig.org/) to wrap the C API to the language of choice.
- Once loaded, the module has to initialize the D runtime, by a call to core.runtime.rt_init() or core.runtime.Runtime.initialize() (https://dlang.org/phobos/core_runtime.html).

Swig generates shared objects. This worked well on Linux. I am not sure how the dll support is on Windows though: it could get more difficult.

Back then, the extern (C++) wasn't as extensive as it is now, so today it might be more pertinent to create an extern (C++) API to conveniently wrap extern (C++) D classes/interfaces to Java classes/interfaces.

These pages of the documentation detail how to interface with C and C++:
https://dlang.org/spec/interfaceToC.html
https://dlang.org/spec/cpp_interface.html

Maybe the extern (C/C++) API approach can be used with GraalVM, I haven't researched that yet. When I tried GraalVM (for ahead of time native compilation) I got into difficulties with libraries using the java reflection API. One need to get the "pro" GraalVM distribution if I recall correctly. It seemed too much of a hurdle for what I was evaluating. I did eventually did fine without GraalVM.

The C/C++ API from D process is quite involving. If I were to get Java and D together I would explore a D server communicating with a Java client over a TCP socket or HTTP, maybe using json:
- Adam D. Ruppe wrote a D socket tutorial not long ago: https://forum.dlang.org/post/ciiiskgfeyhqfkfuxdai@forum.dlang.org
- I used asdf (http://code.dlang.org/packages/asdf) for JSON serialization and deserialization with success. There is also std.json already available in phobos.
- Maybe a small http server with vibe.d could be started with even less code.

For a desktop app, I would rather use dlangui (http://code.dlang.org/packages/dlangui). There are other maintained GUI libraries for D.

Ron Tarrant has written many tutorials an GtkD on his blog page:
- https://gtkdcoding.com/
- http://code.dlang.org/packages/gtk-d

There is also DWT, a D port of the SWT Java GUI library: http://code.dlang.org/packages/dwt

TKD is a binding over the Tcl/Tk toolkit:
- http://code.dlang.org/packages/tkd

On Mon, Nov 25, 2019 at 09:51:31PM +0000, kinke via Digitalmars-d-announce wrote:
> On Monday, 25 November 2019 at 18:28:55 UTC, H. S. Teoh wrote:
> > - lack of support for cross-compilation (e.g., cross-compile to
> >   Android from a Linux x86 host, or cross-compile from Linux host to
> >   Windows executable via wine / cygwin).
> 
> You're not up to speed, this has been solved with latest dub and LDC. No need for any Wine/Cygwin/MinGW/... either.

Oooh very nice!!  That's wonderful to hear.  So you're saying LDC out-of-the-box can cross-compile from Linux to Windows directly?  How to do this?  I'm *very* interested!


T

-- 
What did the alien say to Schubert? "Take me to your lieder."