Hi D

I've writing little test scripts using rdmd to understand what various functions are really doing (ex: .take(5)).  I'm up to the point where I need to write sample code to understand mir-algorithm a little better, but of course the library is not installed on my system.  So two related questions:

1) After a "git clone" and "dub build" I'm left with redistributables
   that need to be put ... somewhere. But where?  I tried this:

    cp -r -p source/mir /usr/local/include
    cp -p libmir-algorithm.a /usr/local/lib

   but no joy.  So where can I install libs so that rdmd will find
   them?

2) On a related topic, is there an environment variable I can set (similar
   to PYTHONPATH, MATLABPATH, IDL_PATH, etc.) or a config file I can alter
   that will add to the module include path?  I tried:

    #!/usr/bin/env DFLAGS="-I/usr/local/include" rdmd

   at the top of the file, but that just hung rdmd and nothing ran.

Note: I'm aware of dub.  This isn't a question about dub.  I'm making scripts for local use, not redistributable binaries, so I would like to "install" mir-algorithm and similar libraries for my rdmd scripts to use.

Thanks for the help,

On Wednesday, 17 March 2021 at 03:43:22 UTC, Chris Piker wrote:

> Note: I'm aware of dub.  This isn't a question about dub.  I'm making scripts for local use, not redistributable binaries, so I would like to "install" mir-algorithm and similar libraries for my rdmd scripts to use.

Sorry to reply to myself, but I found something that will run
the scripts, though it still doesn't make use of local libraries.

   #!/usr/bin/env dub
   /+ dub.sdl:
       dependency "mir-algorithm" version="~>1.0"
   +/

   import mir.ndslice
...

Since dub seems to work a bit better as the "interpreter" then
rdmd (assuming you're connected to the Internet) why is this not
promoted here:

https://tour.dlang.org/tour/en/welcome/run-d-program-locally

instead of rdmd?

Thanks,

On Wednesday, 17 March 2021 at 04:34:07 UTC, Chris Piker wrote:
> On Wednesday, 17 March 2021 at 03:43:22 UTC, Chris Piker wrote:
>
>> Note: I'm aware of dub.  This isn't a question about dub.  I'm making scripts for local use, not redistributable binaries, so I would like to "install" mir-algorithm and similar libraries for my rdmd scripts to use.
>
> Sorry to reply to myself, but I found something that will run
> the scripts, though it still doesn't make use of local libraries.
>
>    #!/usr/bin/env dub
>    /+ dub.sdl:
>        dependency "mir-algorithm" version="~>1.0"
>    +/
>
>    import mir.ndslice
> ...
>
> Since dub seems to work a bit better as the "interpreter" then
> rdmd (assuming you're connected to the Internet)

You can use local a specific local version too, for example the git repository

  #!/usr/bin/env dub
  /+ dub.sdl:
        dependency "mir-algorithm" path="/home/x/repositories/mir/mir-algorithm"
  +/

In addition with --nodeps, no internet is required.

On Wednesday, 17 March 2021 at 06:07:01 UTC, user1234 wrote:

> You can use local a specific local version too, for example the git repository
>
>   #!/usr/bin/env dub
>   /+ dub.sdl:
>         dependency "mir-algorithm" path="/home/x/repositories/mir/mir-algorithm"
>   +/
>
> In addition with --nodeps, no internet is required.

Very handy example.  Unfortunately it means that paths are embedded
in scripts, which is usually a bad idea.

I'm still looking for environment variables or config files that affect
dub's module include path.  Is there dub variable to give a general path
for all dependencies?  Since dub can read environment variables, this
may be a way to get a top-level module directory known to scripts without
hard coding paths.

Also, what do people do when generating .deb or .rpm packages for D
libraries?  They must reference some local library path in a general
fashion (I would think).

The only module paths I see referenced in:

  /etc/dmd.conf

are for phobos and the runtime import.  I guess I could just add another
one there.  Not sure if gdc also uses that file.

On Wednesday, 17 March 2021 at 07:13:31 UTC, Chris Piker wrote:
> On Wednesday, 17 March 2021 at 06:07:01 UTC, user1234 wrote:
>
>> [...]
>
> Very handy example.  Unfortunately it means that paths are embedded
> in scripts, which is usually a bad idea.
>
> [...]

You can use a local registry too. That should work but ten the dep version must be set to "*". See https://dub.pm/commandline.html#add-local

On Wednesday, 17 March 2021 at 07:13:31 UTC, Chris Piker wrote:
> Very handy example.  Unfortunately it means that paths are embedded
> in scripts, which is usually a bad idea.

The ability to use D source modules “script style” is something that has grown organically over time largely as a convenience. I doubt anyone is using it heavily enough to have tested the boundaries, In your exploration of those boundaries, please take note of what you discover so they can potentially be expanded where possible.

On Wednesday, 17 March 2021 at 09:34:21 UTC, Mike Parker wrote:
> On Wednesday, 17 March 2021 at 07:13:31 UTC, Chris Piker wrote:
>> Very handy example.  Unfortunately it means that paths are embedded
>> in scripts, which is usually a bad idea.
>
> The ability to use D source modules “script style” is something that has grown organically over time largely as a convenience. I doubt anyone is using it heavily enough to have tested the boundaries, In your exploration of those boundaries, please take note of what you discover so they can potentially be expanded where possible.

Sure will, thanks for the invite to contribute in a specific way.

D looks to be a good replacement for split Python/C development though I don't want to drag all my python baggage in here.  I'm trying to understand the D way of doing things before suggesting changes.

Interpreted languages like Python MATLAB, IDL are the norm in my field.  So anything that makes D easier to use for "quick-and-dirty" data analysis tasks would make it more palatable to the casual programmers I interact with.

I general dub seems fantastic!  I was stunned yesterday by a three-line vibe.d test script I ran that produced a compiled running web-server.

So, if I could do the equivalent of:

  dub add-path

via an environment variable (not a permanent change under ~/.dub), or have some environment variable that tells dub where to read a "system-level" local-packages.json file and merge it's paths in with any personal settings, that would likely handle our internal code sharing needs.

On Wednesday, 17 March 2021 at 19:33:26 UTC, Chris Piker wrote:
> On Wednesday, 17 March 2021 at 09:34:21 UTC, Mike Parker wrote:
>> [...]
>
> Sure will, thanks for the invite to contribute in a specific way.
>
> [...]

You probably already know this, just sharing:

https://atilaoncode.blog/2020/02/19/want-to-call-c-from-python-use-d/

On Wednesday, 17 March 2021 at 19:33:26 UTC, Chris Piker wrote:
> So, if I could do the equivalent of:
>
>   dub add-path
>
> via an environment variable (not a permanent change under ~/.dub), or have some environment variable that tells dub where to read a "system-level" local-packages.json file and merge it's paths in with any personal settings, that would likely handle our internal code sharing needs.

For scripts this could be a good way, but it does not really work with
most dub packages:

1. put all your dependencies into a single location, like /home/<you>/dstuff
2. add -I /home/<you>/dstuff to your call to rdmd/dmd (or put into /etc/dmd.conf
3. add -i (lowercase) to your call of rdmd/dmd
4. profit

-i automatically adds all modules that are imported to the compilation, i.e. all your dependencies are compiled together with your code, when they are needed. It searches for them where -I points to.

To make this work the dependencies must have the correct project layout, e.g. sources should be in the top-level project directory and not in a subdirectory source. This rules out most dub packages :/

On Wednesday, 17 March 2021 at 20:13:49 UTC, Imperatorn wrote:
> On Wednesday, 17 March 2021 at 19:33:26 UTC, Chris Piker wrote:
>> On Wednesday, 17 March 2021 at 09:34:21 UTC, Mike Parker wrote:
>>> [...]
>>
>> Sure will, thanks for the invite to contribute in a specific way.
>>
>> [...]
>
> You probably already know this, just sharing:
>
> https://atilaoncode.blog/2020/02/19/want-to-call-c-from-python-use-d/

Hey, that looks nice.  I'm trying to get away from python as the
front end language, but I do have a fair bit of C code running around
and there are a lot of python users.

Thanks for the tip :)