www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Module import failing after $ dub add mypackage

reply Scotpip <geoff variosoft.co.uk> writes:
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!
Jul 16 2021
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 17/07/2021 3:31 AM, Scotpip wrote:

 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"
      }
 }
 ```



Okay, its been added to your dub project. So far so good.


 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
 ```


This should be in source/app.d


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


dmd and rdmd do not understand dub packages or anything else. They are 
the compiler. Only use dub and if you want to change compiler you tell 
dub this.


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


msgpack-d doesn't have a file named msgpack.d. It does have a package.d 
file inside its msgpack directory which functions as this.

You should find it under %APPDATA%/dub

``$ dub build`` inside of ``myproject`` should work.
Jul 16 2021
parent reply Scotpip <geoff variosoft.co.uk> writes:
On Friday, 16 July 2021 at 15:42:32 UTC, rikki cattermole wrote:


 ``$ dub build`` inside of ``myproject`` should work.


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.
Jul 16 2021
parent Mike Parker <aldacron gmail.com> writes:
On Friday, 16 July 2021 at 16:44:31 UTC, Scotpip wrote:


 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.


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
         }
     }
Jul 16 2021
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 16 July 2021 at 15:31:49 UTC, Scotpip wrote:



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


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.
Jul 16 2021
parent reply Scotpip <geoff variosoft.co.uk> writes:
On Friday, 16 July 2021 at 16:42:50 UTC, Mike Parker wrote:


  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.


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...
Jul 16 2021
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 16 July 2021 at 16:54:18 UTC, Scotpip 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...


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 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...


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

https://wiki.dlang.org/Serialization_Libraries
Jul 16 2021
parent Mike Parker <aldacron gmail.com> writes:
On Friday, 16 July 2021 at 17:14:12 UTC, Mike Parker wrote:


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

 https://wiki.dlang.org/Serialization_Libraries


Also:

https://code.dlang.org/search?q=serialization
Jul 16 2021
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 16, 2021 at 04:54:18PM +0000, Scotpip via Digitalmars-d-learn wrote:
[...]

 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...


If your struct contains only POD types (no indirections), and you do not
need to share it across machines, then you could just write the raw
bytes to disk and read them back:

	struct Data { ... }

	// To write:
	File myFile = ...;
	// write number of items to disk somewhere
	foreach (Data item; myList) {
		myFile.rawWrite((&item)[0 .. 1]);
	}

	// To read:
	File myFile = ...;
	int numItems = /* read number of items from disk somewhere */;
	foreach (i; 0 .. numItems) {
		Data item;
		myFile.rawRead((&item)[0 .. 1]);
		appendToList(item);
	}

If your data is in an array, it's even easier:

	Data[] myData;
	// write myData.length to disk somewhere
	myFile.rawWrite(myData);

	myData.length = /* read number of items from disk */;
	myFile.rawRead(myData);

Note that the above only works if your data contains no indirections.
(Beware that strings *do* contain indirection unless you're using
fixed-length buffers.)  If there are indirections you'll need to do
something smarter.


T

-- 
The irony is that Bill Gates claims to be making a stable operating system and
Linus Torvalds claims to be trying to take over the world. -- Anonymous
Jul 16 2021