20.07.2023 05:37, Chris Piker пишет:
> Hi D
> 
> One of my jobs is to release and maintain public data archives from long-running scientific instruments.  In order to help people understand how to process the data, sample code is often included with the archive. Recently this has been in the form of short programs that generate a plot of a representative time period.  Python works well for this task as matplotlib support is pretty much universal.  Matlab is also a reasonable choice for many.
> 
> Were I to also provide sample code in D, what library would you recommend for scientific plotting, especially for dynamic power spectral densities generated from time-series data (basically heatmaps)?
> 
> Since dub can pull down dependencies easily enough and since it supports single file projects it seems that D would be well suited to this task, but I've never plotted any data directly from a D program.  Many GUI libraries I see for D are wrappers around external C or C++ based libraries that would need to be installed separately.  I'd like to avoid such complications if that's possible.
> 
> Thanks for any advice,

https://code.dlang.org/packages/ggplotd

On Thursday, July 20, 2023 10:57:22 PM MDT Chris Piker via Digitalmars-d-learn wrote:
> (Warning, possible ill-informed opinions ahead...)
>
> In a way there is a need to reinvent the wheel.  With python I can run `pip install matplotlib` and get whatever binaries I need to get the job done.  D runs on dub, which I only see handling source code, and as far as I can tell, only D source code at that.  So unless it's D code, it can't be packaged and delivered easily within the D ecosystem.
>
> If dub supports either pre-built binaries, or C code (such as libcairo2), I'd be interested in seeing how that's done.  With the wizardry I've see around here, it's probably easy, I just don't know about it.

Well, dub is certainly designed around building projects that are pure D without anything fancy going on, but with effort, it's possible to do far more complicated stuff (though it's certainly far more of a pain than would be desirable). That being said, if the C libraries are already on your system, it's trivial to have a dub project just use them via bindings in the D code. And there are libraries on code.dlang.org which are basically just bindings for C libraries.

Regardless though, dub really isn't designed with packaging anything in mind. Rather, it's designed to build your code as well as pull in D libraries that it usees and build those too. Anyone looking to actually package stuff would create a package from what was built with dub (e.g. with deb, rpm, flatpacks, etc.).

> Going waaaay out on a limb for a minute, I think D shines as a scripting language replacement.  Most of my programs are single file projects these days with dub set as the interpreter.  Also Rust seems to be crowding the system level space and so focusing on it's "compiled scripts" capability avoids that competition.
>
> (If any of the statements above are faulty, I invite correction.)

D does work quite well as a scripting language replacement for a lot stuff. In fact, the compiler and standard library have largely replaced their Makefiles with D scripts. It's definitely worse if you want to write a script that needs to pull in dependencies that aren't part of the standard library, but if Phobos has what you need, it works quite well - and of course, you can always run other shell commands from within a D program.

- Jonathan M Davis

On Friday, July 21, 2023 1:03:47 AM MDT Chris Piker via Digitalmars-d-learn wrote:
> On Friday, 21 July 2023 at 06:15:10 UTC, Jonathan M Davis wrote:
> > On Thursday, July 20, 2023 10:57:22 PM MDT Chris Piker via Digitalmars-d-learn wrote:
> >
> > Regardless though, dub really isn't designed with packaging anything in mind. Rather, it's designed to build your code as well as pull in D libraries that it usees and build those too. Anyone looking to actually package stuff would create a package from what was built with dub (e.g. with deb, rpm, flatpacks, etc.).
>
> So as far as I can tell, python pip originally only dealt with
> python code, but eventually wheels were added for binary support.
>   Just as a wild guess, do you see dub ever evolving in that
> direction?  All the reasons for not supporting pre-compiled
> binaries in pip apply to dub, but yet support was added anyway,
> and it's been wildly successful.
>
> I know it's hard to make predictions (especially about the future), but I'd be interesting in your opinion on the matter.

I'd be very surprised if dub added support for pre-compiled binaries - particularly since D isn't generally binary compatible across releases - but I really don't know what the folks working on dub want to do with it.

- Jonathan M Davis