Another newbie question I'm afraid.

Trying to import and use my first package from the registry.

I installed D from the Windows dmd-2.097.0.exe

I created the project with $ dub init myproject

In the project root I've run:

$ dub add msgpack-d
  Adding dependency msgpack-d ~>1.0.3

In dub.sdl I see: dependency "msgpack-d" version="~>1.0.3"

In dub.selections.json I see:

{
	"fileVersion": 1,
	"versions": {
		"msgpack-d": "1.0.3"
	}
}

When I try to import the msgpack into my app.d main file, I get the error:

$ Error: module `msgpack` is in file 'msgpack.d' which cannot be read
  import path[0] = C:\D\dmd2\windows\bin64\..\..\src\phobos
  import path[1] = C:\D\dmd2\windows\bin64\..\..\src\druntime\import

I get similar errors whether I build with dub, dmd or rdmd.

The file msgpack.d which the build is searching for doesn't appear to be on my system.

I'm on Windows 10 Pro, if that's relevant. Importing my own local modules and modules from std is working fine.

I've looked at the docs and a couple of books but there's nothing to suggest how I can fix this. The official dub docs are sparse, to say the least and don't say anything about how dub works or where it stores its resources...

I've used many package managers without running into a roadblock like this. Am I doing something stupid?

I'm completely stuck till I can get this fixed, so any help would be very much appreciated!

On Friday, 16 July 2021 at 15:31:49 UTC, Scotpip wrote:

I used the example from the readme at:

https://code.dlang.org/packages/msgpack-d

which I pasted into the generated app.d. And all the command lines were:

dub init myproject
cd myproject
dub add msgpack-d
dub

Compiled fine. I did encounter some missing symbols, though (ntohl and ntohs) as msgpack-d isn't linking with Ws2-32.lib. I added pragma(lib, "Ws2_32") to the top of the file to resolve it. (And I filed an issue: https://github.com/msgpack/msgpack-d/issues/120).

Once the linker issues were resolved, all was well.

On Friday, 16 July 2021 at 15:42:32 UTC, rikki cattermole wrote:

Thanks - that was helpful.

For anyone else with this issue I've figured out what went wrong.

I had more than one main() function in the project - I was using the others as sandboxes to play with code.

I was building with dub .\source\myfile.d.

But you need to run dub without a filepath to build the whole project, including any 3rd party packages.

No doubt this is blindingly obvious to people used to working with compilers, but it would be helpful to newbies if this was a bit more explicit in the dub docs.

Again, if this helps anyone my current setup is to have a single main() in app.d. I changed the main() in my sandboxes to runSandbox(), and I import and run from app.d rather than directly. Or with a couple of keystrokes I can switch to running the full app. This seems to be a practical workflow that plays properly with the build system.

If anyone has a better suggestion, I'd appreciate your tips.

On Friday, 16 July 2021 at 16:42:50 UTC, Mike Parker wrote:

Yup - I have it running now but the code does seem to be a bit neglected and I'm seeing a depreciation warning too. I chose it because it's much the most downloaded serialisation package and is used in a couple of other popular packages. But it seems to be moribund...

I simply need a fast binary serialisation lib to read and write a large list of structs to local disk - it's not for inter-app communication. The struct is simple and only contains primitive D data types. If you are aware of any package that would be a better bet I'd appreciate your advice. Or is there a more direct way to dump a list from memory to disk and read it back again? This is the kind of low-level stuff that's rather new to me...

On Friday, 16 July 2021 at 16:44:31 UTC, Scotpip wrote:

You might look into dub configurations. The first configuration that matches the current platform is the default, and other can be specified on the command line with dub -cConfigName (or --config=ConfigName).

Here's are two configurations in SDLang format from one of my projects:

// Default library config.
configuration "dolce" {
    targetType "staticLibrary"
    targetPath "lib"
    targetName "dolce"
    excludedSourceFiles "source/dolce/dev/*"
}

// Development config for testing/experimenting.
configuration "dolceDev" {
    targetType "executable"
    targetPath "bin"
    targetName "dolceDev"
}

Files for the executable are in source/dolce/dev, so I just exclude them from the library builds. In your case, you might have two mains and do something like this:

targetType "executable"

configuration "default" {
    excludedSourceFiles "source/sandbox/*"
}
configuration "sandbox" {
    exludedSourceFiles "source/app.d"
}

Or maybe the sandbox config could just add a version:

configuration "sandbox" {
    versions "Sandbox"
}

Then you can conditionally compile as needed:

void main()
{
    version(Sandbox) {
        import sandbox : runSandbox;
        runSandbox();
    } else {
        // Normal main stuff here
    }
}

On Friday, 16 July 2021 at 16:54:18 UTC, Scotpip wrote:

The deprecation message is from the most recent dmd release:

https://dlang.org/changelog/2.097.0.html#body-deprecation

It's been a year since the last commit (which actually involved linking with winsock...), but I wouldn't write it off as near death just yet.

I haven't had occasion to make use of any serialization libraries myself, but you can start here:

https://wiki.dlang.org/Serialization_Libraries

On Friday, 16 July 2021 at 17:14:12 UTC, Mike Parker wrote:

Also:

https://code.dlang.org/search?q=serialization