Re: win32 api & lib issue
On Thursday, 2 November 2023 at 17:38:33 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 13:40:14 UTC, Peter Hu wrote: [...] I put it on dub now so you can just do "dub add dfl". In Entice designer you can then change your compile command to cd.. && dub (if you're in the source folder, otherwise just dub). I might add the ability to create event handlers by clicking on objects. We'll see. That would be great.
Re: Keyword "package" prevents from importing a package module "package.d"
On Fri, Nov 03, 2023 at 12:19:48AM +, Andrey Zherikov via
Digitalmars-d-learn wrote:
> On Thursday, 2 November 2023 at 19:43:01 UTC, Adam D Ruppe wrote:
> > On Thursday, 2 November 2023 at 19:30:58 UTC, Jonathan M Davis wrote:
> > > The entire reason that it was added to the language was to be able
> > > to split up existing modules without breaking code. And it does that
> > > well.
> >
> > No, it doesn't do that well at all. In fact, it does that so extremely
> > poorly that (as you might recall) there were a very large number of
> > support requests shortly after Phobos started using it about broken
> > builds, since it would keep the old file and the new file when you
> > updated and this stupid, idiotic design can't handle that situation.
> >
> > This only subsided because enough time has passed that nobody tries
> > using it to break up existing modules anymore.
> >
> > It is just a *terrible* design that never should have passed review. It
> > is randomly inconsistent with the rest of the language and this
> > manifests as several bugs.
> >
> > (including but not limited to:
> >
> > https://issues.dlang.org/show_bug.cgi?id=14687 doesn't work with .di
> > https://issues.dlang.org/show_bug.cgi?id=17699 breaks if you try to use
> > it for its intended purpose
> > https://issues.dlang.org/show_bug.cgi?id=20563 error messages hit random
> > problems
> > all-at-once vs separate compilation of package
> > leads to inconsistent reflection results
> >
> > im sure the list went on if i spent a few more minutes looking for my
> > archives)
> >
> >
> > > package.d is indeed completely unnecessary for creating a module
> > > that publicly imports other modules in order to be able to import a
> > > single module and get several modules.
> >
> > Yeah, it is a terrible feature that is poorly designed, hackily
> > implemented, and serves no legitimate use case.
>
> Is there any guide how one can refactor single-module package into
> multi-module package with distinction between public and private
> modules?
Supposedly you can do this:
/* Original: */
// pkg/mymodule.d
module mymodule;
... // code here
// main.d
import mymodule;
void main() { ... }
/* Split */
// pkg/mymodule/pub_submod.d
module mymodule.pub_submod;
... // code here
// pkg/mymodule/priv_submod.d
module mymodule.priv_submod;
... // code here
// pkg/mymodule/package.d
module mymodule;
public import priv_submod;
// main.d
import mymodule;
void main() { ... }
Barring the issues listed above, of course.
T
--
"The number you have dialed is imaginary. Please rotate your phone 90 degrees
and try again."
Re: Keyword "package" prevents from importing a package module "package.d"
On Thursday, 2 November 2023 at 19:43:01 UTC, Adam D Ruppe wrote: On Thursday, 2 November 2023 at 19:30:58 UTC, Jonathan M Davis wrote: The entire reason that it was added to the language was to be able to split up existing modules without breaking code. And it does that well. No, it doesn't do that well at all. In fact, it does that so extremely poorly that (as you might recall) there were a very large number of support requests shortly after Phobos started using it about broken builds, since it would keep the old file and the new file when you updated and this stupid, idiotic design can't handle that situation. This only subsided because enough time has passed that nobody tries using it to break up existing modules anymore. It is just a *terrible* design that never should have passed review. It is randomly inconsistent with the rest of the language and this manifests as several bugs. (including but not limited to: https://issues.dlang.org/show_bug.cgi?id=14687 doesn't work with .di https://issues.dlang.org/show_bug.cgi?id=17699 breaks if you try to use it for its intended purpose https://issues.dlang.org/show_bug.cgi?id=20563 error messages hit random problems all-at-once vs separate compilation of package leads to inconsistent reflection results im sure the list went on if i spent a few more minutes looking for my archives) package.d is indeed completely unnecessary for creating a module that publicly imports other modules in order to be able to import a single module and get several modules. Yeah, it is a terrible feature that is poorly designed, hackily implemented, and serves no legitimate use case. Is there any guide how one can refactor single-module package into multi-module package with distinction between public and private modules?
Re: What are the best available D (not C) File input/output options?
On Thursday, 2 November 2023 at 15:46:23 UTC, confuzzled wrote: I've ported a small script from C to D. The original C version takes roughly 6.5 minutes to parse a 12G file while the port originally took about 48 minutes. In my experience I/O in D is quite slow. But you can try to improve it: Try to use std.outbuffer instead of writeln. And flush the result only in the end. Also check this article. It is showing how manual buffers in D could speed up the processing of files significantly: https://tech.nextroll.com/blog/data/2014/11/17/d-is-for-data-science.html
Re: Keyword "package" prevents from importing a package module "package.d"
On Thursday, 2 November 2023 at 19:30:58 UTC, Jonathan M Davis wrote: The entire reason that it was added to the language was to be able to split up existing modules without breaking code. And it does that well. No, it doesn't do that well at all. In fact, it does that so extremely poorly that (as you might recall) there were a very large number of support requests shortly after Phobos started using it about broken builds, since it would keep the old file and the new file when you updated and this stupid, idiotic design can't handle that situation. This only subsided because enough time has passed that nobody tries using it to break up existing modules anymore. It is just a *terrible* design that never should have passed review. It is randomly inconsistent with the rest of the language and this manifests as several bugs. (including but not limited to: https://issues.dlang.org/show_bug.cgi?id=14687 doesn't work with .di https://issues.dlang.org/show_bug.cgi?id=17699 breaks if you try to use it for its intended purpose https://issues.dlang.org/show_bug.cgi?id=20563 error messages hit random problems all-at-once vs separate compilation of package leads to inconsistent reflection results im sure the list went on if i spent a few more minutes looking for my archives) package.d is indeed completely unnecessary for creating a module that publicly imports other modules in order to be able to import a single module and get several modules. Yeah, it is a terrible feature that is poorly designed, hackily implemented, and serves no legitimate use case.
Re: Keyword "package" prevents from importing a package module "package.d"
On Thursday, November 2, 2023 7:04:37 AM MDT Adam D Ruppe via Digitalmars-d- learn wrote: > On Thursday, 2 November 2023 at 12:52:35 UTC, BoQsc wrote: > > Therefore the need to import `package.d` is needed and I can't > > see a solution, which means > > tbh package.d should never be used. It is a poorly designed, > buggy misfeature of the language with plenty of better working > alternatives (it is no different than making a `module > yourthing.all;` people can import execpt with more limitations > and bugs.) The entire reason that it was added to the language was to be able to split up existing modules without breaking code. And it does that well. It was never intended to be used for anything else, but of course, some people always find ways to misuse a feature. package.d is indeed completely unnecessary for creating a module that publicly imports other modules in order to be able to import a single module and get several modules. Either way, personally, I don't think that that's something that should typically be done (with package.d or with any module name), but for whatever reason, some folks seem to love the idea. - Jonathan M Davis
Re: Keyword "package" prevents from importing a package module "package.d"
On Thursday, 2 November 2023 at 12:52:35 UTC, BoQsc wrote: Therefore the need to import `package.d` is needed and I can't see a solution, which means that D Language might have to introduce a way to import `package.d` from inside the package, if there is a need to further improve experience of having a self-testing packages in both `dub` and `package modules`. It's perfectly legal to write `import packagename;` in a file that's inside the `packagename/` directory. You just have to make sure that *the current directory in your terminal window* is outside the `packagename/` directory when you run the compiler. The D compiler *always* looks up files *relative to your terminal's current directory*. It does not care at all where the files are relative to each other.
Re: win32 api & lib issue
On Thursday, 2 November 2023 at 13:40:14 UTC, Peter Hu wrote: On Thursday, 2 November 2023 at 12:47:11 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 12:43:01 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 12:22:29 UTC, Peter Hu wrote: On Thursday, 2 November 2023 at 10:58:51 UTC, Imperatorn wrote: [...] Yes,exactly. That was developed with D+iupD. Under windows,I use PoseidonD with Entice Designer+DFL: Entice Designer: http://www.dprogramming.com/entice.php DFL for D2 :https://github.com/Rayerd/dfl Wow, it's great seeing this is still being used Would be nice to continue development of Entice Designer Yes,it is C# code style,supports compiling command setting.There are more features than it looks in the Form Property Window.It is a pity the source editor does not support Chinese characters input(but can paste in) . Since the DFL library gets maintained,hope Entice designer gets maintained as well.Source is available in the website( http://www.dprogramming.com/entice.php). I put it on dub now so you can just do "dub add dfl". In Entice designer you can then change your compile command to cd.. && dub (if you're in the source folder, otherwise just dub). I might add the ability to create event handlers by clicking on objects. We'll see.
Re: What are the best available D (not C) File input/output options?
On Thursday, 2 November 2023 at 15:46:23 UTC, confuzzled wrote: I tried std.io but write() only outputs ubyte[] while I'm trying to output text so I abandoned idea early. Just specifically to answer this, this is so you understand this is what is going into the file -- bytes. You should use a buffering library like iopipe to write properly here (it handles the encoding of text for you). And I really don't have a good formatting library, you can rely on formattedWrite maybe. A lot of things need to be better for this solution to be smooth, it's one of the things I have to work on. -Steve
Re: What are the best available D (not C) File input/output options?
On Thursday, 2 November 2023 at 15:46:23 UTC, confuzzled wrote:
I've ported a small script from C to D. The original C version
takes roughly 6.5 minutes to parse a 12G file while the port
originally took about 48 minutes. My naïve attempt to improve
the situation pushed it over an hour and 15 minutes. However,
replacing std.stdio:File with core.stdc.stdio:FILE* and
changing my output code in this latest version from:
outputFile.writefln("%c\t%u\t%u\t%d.%09u\t%c", ...)
to
fprintf(outputFile, "%c,%u,%u,%llu.%09llu,%c\n", ...)
reduced the processing time to roughly 7.5 minutes. Why is
File.writefln() so appallingly slow? Is there a better D
alternative?
First, strace your program. The slowest thing about I/O is the
syscall itself. If the D program does more syscalls, it's going
to be slower almost no matter what else is going on. Both D and C
are using libc to buffer I/O to reduce syscalls, but you might be
defeating that by constantly flushing the buffer.
I tried std.io but write() only outputs ubyte[] while I'm
trying to output text so I abandoned idea early.
string -> immutable(ubyte)[]: alias with
std.string.representation(st)
'alias' meaning, this doesn't allocate. If gives you a byte slice
of the same memory the string is using.
You'd still need to do the formatting, before writing.
Now that I've got the program execution time within an
acceptable range, I tried replacing core.stdc.fread() with
std.io.read() but that increased the time to 24 minutes. Now
I'm starting to think there is something seriously wrong with
my understanding of how to use D correctly because there's no
way D's input/output capabilities can suck so bad in comparison
to C's.
Re: Function Overloading
On Thursday, 2 November 2023 at 11:17:42 UTC, Salih Dincer wrote:
On Wednesday, 1 November 2023 at 20:04:52 UTC, Basile B. wrote:
Yes. D constructors are not named but the current
implementation adds a name that is `__ctor`, so add
```d
alias add = __ctor;
```
to you struct.
Yeah, it works! Thanks...:)
SDB@79
I'm no sure how this could be used IRL but keep well in mind that
**this is not nice code**.
My answer should be more interepreted as "yes that is technically
possible". ("can do" -> yes VS "should do" -> no).
You also have the `opCall()` option btw.
What are the best available D (not C) File input/output options?
I've ported a small script from C to D. The original C version takes
roughly 6.5 minutes to parse a 12G file while the port originally took
about 48 minutes. My naïve attempt to improve the situation pushed it
over an hour and 15 minutes. However, replacing std.stdio:File with
core.stdc.stdio:FILE* and changing my output code in this latest version
from:
outputFile.writefln("%c\t%u\t%u\t%d.%09u\t%c", ...)
to
fprintf(outputFile, "%c,%u,%u,%llu.%09llu,%c\n", ...)
reduced the processing time to roughly 7.5 minutes. Why is
File.writefln() so appallingly slow? Is there a better D alternative?
I tried std.io but write() only outputs ubyte[] while I'm trying to
output text so I abandoned idea early. Now that I've got the program
execution time within an acceptable range, I tried replacing
core.stdc.fread() with std.io.read() but that increased the time to 24
minutes. Now I'm starting to think there is something seriously wrong
with my understanding of how to use D correctly because there's no way
D's input/output capabilities can suck so bad in comparison to C's.
Re: win32 api & lib issue
On Thursday, 2 November 2023 at 12:47:11 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 12:43:01 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 12:22:29 UTC, Peter Hu wrote: On Thursday, 2 November 2023 at 10:58:51 UTC, Imperatorn wrote: [...] Yes,exactly. That was developed with D+iupD. Under windows,I use PoseidonD with Entice Designer+DFL: Entice Designer: http://www.dprogramming.com/entice.php DFL for D2 :https://github.com/Rayerd/dfl Wow, it's great seeing this is still being used Would be nice to continue development of Entice Designer Yes,it is C# code style,supports compiling command setting.There are more features than it looks in the Form Property Window.It is a pity the source editor does not support Chinese characters input(but can paste in) . Since the DFL library gets maintained,hope Entice designer gets maintained as well.Source is available in the website( http://www.dprogramming.com/entice.php).
Re: Keyword "package" prevents from importing a package module "package.d"
On 02.11.23 14:15, Arafel wrote: You simply can't expect to do `import waffle.foo` from within `waffle/` itself (unless you have another `waffle` folder in it, which is often the case). Sorry, this is wrong. It should read: You simply can't expect to do `import waffle.foo` **when invoking the compiler** within `waffle/` itself (unless you have another `waffle` folder in it, which is often the case). You are actually perfectly fine to import other parts of the same package, as long as you run the compiler from right outside the package, or adjust the import paths accordingly.
Re: Keyword "package" prevents from importing a package module "package.d"
On 02.11.23 13:52, BoQsc wrote: Well the whole thread is about importing `package.d` while being inside package to provide runnable working example which contains debug information of the package. Sorry, but I have never seen a package that includes examples within the package directory itself, nor am I able to imagine why anybody would want that. It would just be polluting the package folder with unnecessary files. Examples are usually distributed in a separate directory, usually at the highest level of the distributable. As for tests, there are `unittest` blocks, and if necessary, they are placed in yet another separate directory. Anyway, your point is moot, because even if you were able to import `package.d`, it would still fail at: ``` public import waffle.testing1; public import waffle.testing2; ``` and for exactly the same reason: the compiler would look for `waffle/testing1.d` and it wouldn't find it withing `waffle/`. You simply can't expect to do `import waffle.foo` from within `waffle/` itself (unless you have another `waffle` folder in it, which is often the case). You always invoke the compiler from the outside the package structure, that's also how it works in java.
Re: Keyword "package" prevents from importing a package module "package.d"
On Thursday, 2 November 2023 at 12:52:35 UTC, BoQsc wrote: Therefore the need to import `package.d` is needed and I can't see a solution, which means tbh package.d should never be used. It is a poorly designed, buggy misfeature of the language with plenty of better working alternatives (it is no different than making a `module yourthing.all;` people can import execpt with more limitations and bugs.)
Re: Keyword "package" prevents from importing a package module "package.d"
Well the whole thread is about importing `package.d` while being inside package to provide runnable working example which contains debug information of the package. Sidenote: This is essentially useful when distributing over many machines/platforms via `dub` package manager. You would want to have a source file inside the project that imports package.d and is runnable with well tested example behaviour. Therefore the need to import `package.d` is needed and I can't see a solution, which means that D Language might have to introduce a way to import `package.d` from inside the package, if there is a need to further improve experience of having a self-testing packages in both `dub` and `package modules`.
Re: win32 api & lib issue
On Thursday, 2 November 2023 at 12:43:01 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 12:22:29 UTC, Peter Hu wrote: On Thursday, 2 November 2023 at 10:58:51 UTC, Imperatorn wrote: [...] Yes,exactly. That was developed with D+iupD. Under windows,I use PoseidonD with Entice Designer+DFL: Entice Designer: http://www.dprogramming.com/entice.php DFL for D2 :https://github.com/Rayerd/dfl Wow, it's great seeing this is still being used Would be nice to continue development of Entice Designer
Re: win32 api & lib issue
On Thursday, 2 November 2023 at 12:22:29 UTC, Peter Hu wrote: On Thursday, 2 November 2023 at 10:58:51 UTC, Imperatorn wrote: [...] Yes,exactly. That was developed with D+iupD. Under windows,I use PoseidonD with Entice Designer+DFL: Entice Designer: http://www.dprogramming.com/entice.php DFL for D2 :https://github.com/Rayerd/dfl Wow, it's great seeing this is still being used
Re: win32 api & lib issue
On Thursday, 2 November 2023 at 12:01:18 UTC, ryuukk_ wrote: On Thursday, 2 November 2023 at 10:17:37 UTC, Peter Hu wrote: On Thursday, 2 November 2023 at 10:02:29 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 09:58:21 UTC, Peter Hu wrote: [...] I'm not sure why, it works for me, but I think it could be something dmd does different. The pragma lib is inserted into the generated object file, or otherwise passed to the linker, so the linker automatically links in that library. I'm guessing dmd for some reason does not see it in the submodule, but I have no proof that's the issue, I'm just guessing. Really appreciated for the help.I am learning to understand. Not using these two pragma in the source,other in the commandline:dmd -m64 user32.lib comdlg32.lib test.d compiled.But--- In an IDE say PoseidonD it still failed to compile even if I provided the library path to the compiler,I just can't understand how come my other small programs ( based on gui libslike DFL2,iup4D,dwt,NAppGui4D ) works fine without having to provide pragma in the source before compiling. It's probably because these libraries already have the symbols Just tried to compile winsamp.d (dmd package folder--dmd/samples/d),exactly the same issue.Many many years ago I once played with this winsamp.d for testing win32 api (configuration ok or not) and it get passed without those two pragma.I am thinking whether it is related to MS VC lib path or MS VS path.
Re: win32 api & lib issue
On Thursday, 2 November 2023 at 10:58:51 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 10:17:37 UTC, Peter Hu wrote: [...] I'm sorry, I don't know. I have just observed that when using LDC the libraries gets forwarded from submodules but not with DMD. So what I usually do is to add them in my dub.json "libs" property as shown before. Oh my, I didn't know poseidon still existed :D Is this what you're using? https://bitbucket.org/KuanHsu/poseidond I currently use vscode and Visual D, they both work good. But it's always fun to see other IDEs Yes,exactly. That was developed with D+iupD. Under windows,I use PoseidonD with Entice Designer+DFL: Entice Designer: http://www.dprogramming.com/entice.php DFL for D2 :https://github.com/Rayerd/dfl
Re: Keyword "package" prevents from importing a package module "package.d"
On 02.11.23 12:57, BoQsc wrote: The current major problem is that it does not work on Windows operating system with either `rdmd` or `dmd`. While it does work on run.dlang.io. The problem is with your import path. If you say: ```d import waffles; ``` The compiler would search for either `waffles.d` or `waffles/package.d` **in your current working directory**. So you have three options: 1. You can compile from the parent directory, most likely what run.dlang.io does: `dmd -i -run waffles/program.d` 2. You can explicitly add all the files to the dmd invocation (I think this is what dub does), although that likely defeats the purpose of `rdmd` and `dmd -i`. 3. You can add `..` (the parent directory) to your search path: `dmd -I.. [..]` Actually, the cleanest (and in my view proper) solution would be to create a new `waffles` directory with the "package" itself, and take the main function out of it, so you'd have: ``` waffles | +-- program.d | +-- waffles | +-- package.d | +-- testing1.d | +-- testing2.d ```
Re: Keyword "package" prevents from importing a package module "package.d"
On Thursday, 2 November 2023 at 11:12:58 UTC, BoQsc wrote: Weirdly enough it does not work on Windows operating system. [...] ``` program.d(1): Error: unable to read module `waffles` program.d(1):Expected 'waffles.d' or 'waffles\package.d' in one of the following import paths: import path[0] = . import path[1] = C:\D\dmd2\windows\bin\..\..\src\phobos import path[2] = C:\D\dmd2\windows\bin\..\..\src\druntime\import Failed: ["C:\\D\\dmd2\\windows\\bin\\dmd.exe", "-v", "-o-", "program.d", "-I."] C:\waffles>dmd -i -run program.d program.d(1): Error: unable to read module `waffles` program.d(1):Expected 'waffles.d' or 'waffles\package.d' in one of the following import paths: import path[0] = C:\D\dmd2\windows\bin64\..\..\src\phobos import path[1] = C:\D\dmd2\windows\bin64\..\..\src\druntime\import ``` The problem is the directory you're running the command from. You need to run `dmd` from the parent directory of `waffles`.
Re: Keyword "package" prevents from importing a package module "package.d"
On Thursday, 2 November 2023 at 11:57:57 UTC, BoQsc wrote:
On Thursday, 2 November 2023 at 11:32:40 UTC, Imperatorn wrote:
On Thursday, 2 November 2023 at 11:12:58 UTC, BoQsc wrote:
On Thursday, 2 November 2023 at 10:53:12 UTC, Arafel wrote:
On 02.11.23 11:45, BoQsc wrote:
[...]
```d
--- waffles/program.d
import waffles;
void main()
{
import std;
writeln(num);
}
--- waffles/package.d
module waffles;
public import waffles.testing1;
public import waffles.testing2;
--- waffles/testing1.d
int num = 5;
--- waffles/testing2.d
int num2 = 9;
```
`num` and `num2` was never a problem.
The current major problem is that it does not work on Windows
operating system with either `rdmd` or `dmd`. While it does
work on run.dlang.io.
That's not all I changed. It works for me on Windows.
Re: win32 api & lib issue
On Thursday, 2 November 2023 at 10:17:37 UTC, Peter Hu wrote: On Thursday, 2 November 2023 at 10:02:29 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 09:58:21 UTC, Peter Hu wrote: On Thursday, 2 November 2023 at 09:13:11 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 09:08:02 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 08:31:41 UTC, Peter Hu wrote: Greetings! From time to time I encountered issues on the subjected after I upgraded my dmd package.Given below code : [...] If it still doesn't work try adding this: ```d pragma(lib, "user32"); pragma(lib, "comdlg32"); ``` Another alternative if you're using dub is to add this in your dub.json instead: ```json "libs": ["user32", "comdlg32"] ``` This seems be something related to DMD vs LDC. Because if I change the compiler to DMD I also get unresolved external symbols, but not with LDC. It seems the forwarding of directives from submodules are different. Thank you. Below two pragma solved the isse but am confused as they are already in the system path.This is the first time I have to include lib files here.How come other gui programs don't have to do this. pragma(lib,"user32"); pragma(lib,"comdlg32"); I'm not sure why, it works for me, but I think it could be something dmd does different. The pragma lib is inserted into the generated object file, or otherwise passed to the linker, so the linker automatically links in that library. I'm guessing dmd for some reason does not see it in the submodule, but I have no proof that's the issue, I'm just guessing. Really appreciated for the help.I am learning to understand. Not using these two pragma in the source,other in the commandline:dmd -m64 user32.lib comdlg32.lib test.d compiled.But--- In an IDE say PoseidonD it still failed to compile even if I provided the library path to the compiler,I just can't understand how come my other small programs ( based on gui libslike DFL2,iup4D,dwt,NAppGui4D ) works fine without having to provide pragma in the source before compiling. It's probably because these libraries already have the symbols
Re: Keyword "package" prevents from importing a package module "package.d"
On Thursday, 2 November 2023 at 11:32:40 UTC, Imperatorn wrote:
On Thursday, 2 November 2023 at 11:12:58 UTC, BoQsc wrote:
On Thursday, 2 November 2023 at 10:53:12 UTC, Arafel wrote:
On 02.11.23 11:45, BoQsc wrote:
Edit incorrect link to example:
[Extensive run.dlang.io
example](https://run.dlang.io/is/f3jURn)
Correct link:
https://run.dlang.io/is/Zbrn75
```d
--- waffles/program.d
import waffles;
void main()
{
import std;
writeln(num);
}
--- waffles/package.d
module waffles;
public import waffles.testing1;
public import waffles.testing2;
--- waffles/testing1.d
int num = 5;
--- waffles/testing2.d
int num2 = 9;
```
`num` and `num2` was never a problem.
The current major problem is that it does not work on Windows
operating system with either `rdmd` or `dmd`. While it does work
on run.dlang.io.
Re: bigEndian in std.bitmanip
On Thursday, 2 November 2023 at 11:29:05 UTC, Salih Dincer wrote: On Tuesday, 31 October 2023 at 14:43:43 UTC, Imperatorn wrote: It might make sense to change since little endian is the most common when it comes to hardware. But big endian is most common when it comes to networking. So I guess it depends on your view of what is most common. Interacting with your local hardware or networking. I realized that I had to make my prefer based on the most common. But I have to use Union. That's why I have to choose little.Endian. Because it is compatible with both Union and HexString. My test code works perfectly as seen below. I'm grateful to everyone who helped here and [on the other thread](https://forum.dlang.org/thread/ekpvajiablcfueyip...@forum.dlang.org). Nice to hear you found a solution. Little endian is *most common* in hardware but big endian is *most common* in networking, so defining a default endianness can be tricky.
Re: Keyword "package" prevents from importing a package module "package.d"
On Thursday, 2 November 2023 at 11:12:58 UTC, BoQsc wrote:
On Thursday, 2 November 2023 at 10:53:12 UTC, Arafel wrote:
On 02.11.23 11:45, BoQsc wrote:
Edit incorrect link to example:
[Extensive run.dlang.io
example](https://run.dlang.io/is/f3jURn)
Correct link:
https://run.dlang.io/is/Zbrn75
```d
--- waffles/program.d
import waffles;
void main()
{
import std;
writeln(num);
}
--- waffles/package.d
module waffles;
public import waffles.testing1;
public import waffles.testing2;
--- waffles/testing1.d
int num = 5;
--- waffles/testing2.d
int num2 = 9;
```
Re: bigEndian in std.bitmanip
On Tuesday, 31 October 2023 at 14:43:43 UTC, Imperatorn wrote:
It might make sense to change since little endian is the most
common when it comes to hardware. But big endian is most common
when it comes to networking. So I guess it depends on your view
of what is most common. Interacting with your local hardware or
networking.
I realized that I had to make my prefer based on the most common.
But I have to use Union. That's why I have to choose
little.Endian. Because it is compatible with both Union and
HexString. My test code works perfectly as seen below. I'm
grateful to everyone who helped here and [on the other
thread](https://forum.dlang.org/thread/ekpvajiablcfueyip...@forum.dlang.org).
```d
enum sampleText = "Hello D!"; // length <= 8 char
void main()
{
//import sdb.string : UnionBytes;
mixin UnionBytes!size_t;
bytes.init = sampleText;
import std.digest: toHexString;
auto hexF = bytes.cell.toHexString;
assert(hexF == "48656C6C6F204421");
import std.string : format;
auto helloD = sampleText.format!"%(%02X%)";
assert(hexF == helloD);
import std.stdio;
bytes.code.writeln(": ", helloD); /* Prints:
2397076564600448328: 48656C6C6F204421 */
import std.conv : hexString;
static assert(sampleText == hexString!"48656C6C6F204421");
//import sdb.string : readBytes;
auto code = bytes.cell.readBytes!size_t;
assert(code == bytes.code);
bytes.init = code;
code.writeln(": ", bytes); /* Prints:
2397076564600448328: Hello D! */
assert(bytes[] == [72, 101, 108, 108, 111, 32, 68, 33]);
//import sdb.string : HexString
auto str = "0x";
auto hex = HexString!size_t(bytes.code);
hex.each!(chr => str ~= chr);
str.writeln; // 0x48656C6C6F204421
}
```
My core template (UnionBytes) is initialized like this, and
underneath I have the readBytes template, which also works with
static arrays:
```d
// ...
import std.range : front, popFront;
size_t i;
do // new version: range support
{
char chr; // default init: 0xFF
chr &= str.front; // masking
code |= T(chr) << (i * 8); // shifting
str.popFront; // next char
} while(++i < size);
}
auto opCast(Cast : T)() const
=> code;
auto opCast(Cast : string)() const
=> this.format!"%s";
auto toString(void delegate(in char[]) sink) const
=> sink.formattedWrite("%s", cast(char[])cell);
}
UnionBytes bytes; // for mixin
}
template readBytes(T, bool big = false, R)
{// pair endian version 2.1
import std.bitmanip;
static if(big) enum E = Endian.bigEndian;
else enum E = Endian.littleEndian;
import std.range : ElementType;
alias ET = ElementType!R;
auto readBytes(ref R dat)
{
auto data = cast(ET[])dat;
return read!(T, E)(data);
}
}
```
SDB@79
Re: Function Overloading
On Wednesday, 1 November 2023 at 20:04:52 UTC, Basile B. wrote: Yes. D constructors are not named but the current implementation adds a name that is `__ctor`, so add ```d alias add = __ctor; ``` to you struct. Yeah, it works! Thanks...:) SDB@79
Re: Keyword "package" prevents from importing a package module "package.d"
On Thursday, 2 November 2023 at 10:53:12 UTC, Arafel wrote: On 02.11.23 11:45, BoQsc wrote: Edit incorrect link to example: [Extensive run.dlang.io example](https://run.dlang.io/is/f3jURn) Correct link: https://run.dlang.io/is/Zbrn75 ``` --- waffles/program.d import waffles; ``` See https://dlang.org/spec/module.html#package-module Weirdly enough it does not work on Windows operating system.  ``` program.d(1): Error: unable to read module `waffles` program.d(1):Expected 'waffles.d' or 'waffles\package.d' in one of the following import paths: import path[0] = . import path[1] = C:\D\dmd2\windows\bin\..\..\src\phobos import path[2] = C:\D\dmd2\windows\bin\..\..\src\druntime\import Failed: ["C:\\D\\dmd2\\windows\\bin\\dmd.exe", "-v", "-o-", "program.d", "-I."] C:\waffles>dmd -i -run program.d program.d(1): Error: unable to read module `waffles` program.d(1):Expected 'waffles.d' or 'waffles\package.d' in one of the following import paths: import path[0] = C:\D\dmd2\windows\bin64\..\..\src\phobos import path[1] = C:\D\dmd2\windows\bin64\..\..\src\druntime\import ```
Re: win32 api & lib issue
On Thursday, 2 November 2023 at 10:17:37 UTC, Peter Hu wrote: On Thursday, 2 November 2023 at 10:02:29 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 09:58:21 UTC, Peter Hu wrote: On Thursday, 2 November 2023 at 09:13:11 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 09:08:02 UTC, Imperatorn wrote: [...] Another alternative if you're using dub is to add this in your dub.json instead: ```json "libs": ["user32", "comdlg32"] ``` This seems be something related to DMD vs LDC. Because if I change the compiler to DMD I also get unresolved external symbols, but not with LDC. It seems the forwarding of directives from submodules are different. Thank you. Below two pragma solved the isse but am confused as they are already in the system path.This is the first time I have to include lib files here.How come other gui programs don't have to do this. pragma(lib,"user32"); pragma(lib,"comdlg32"); I'm not sure why, it works for me, but I think it could be something dmd does different. The pragma lib is inserted into the generated object file, or otherwise passed to the linker, so the linker automatically links in that library. I'm guessing dmd for some reason does not see it in the submodule, but I have no proof that's the issue, I'm just guessing. Really appreciated for the help.I am learning to understand. Not using these two pragma in the source,other in the commandline:dmd -m64 user32.lib comdlg32.lib test.d compiled.But--- In an IDE say PoseidonD it still failed to compile even if I provided the library path to the compiler,I just can't understand how come my other small programs ( based on gui libslike DFL2,iup4D,dwt,NAppGui4D ) works fine without having to provide pragma in the source before compiling. I'm sorry, I don't know. I have just observed that when using LDC the libraries gets forwarded from submodules but not with DMD. So what I usually do is to add them in my dub.json "libs" property as shown before. Oh my, I didn't know poseidon still existed :D Is this what you're using? https://bitbucket.org/KuanHsu/poseidond I currently use vscode and Visual D, they both work good. But it's always fun to see other IDEs
Re: Keyword "package" prevents from importing a package module "package.d"
On 02.11.23 11:45, BoQsc wrote: Edit incorrect link to example: [Extensive run.dlang.io example](https://run.dlang.io/is/f3jURn) Correct link: https://run.dlang.io/is/Zbrn75 ``` --- waffles/program.d import waffles; ``` See https://dlang.org/spec/module.html#package-module
Re: Keyword "package" prevents from importing a package module "package.d"
Edit incorrect link to example: [Extensive run.dlang.io example](https://run.dlang.io/is/f3jURn) Correct link: https://run.dlang.io/is/Zbrn75
Keyword "package" prevents from importing a package module "package.d"
 Source File **package.d** is a [package module][1] which contains import statements to import other modules. How would one import a **package.d** module when [**keyword "package"**][2] is preventing that? [1]: https://dlang.org/spec/module.html#package-module [2]: https://dlang.org/spec/attribute.html#visibility_attributes Example: ``` import package; ``` Error: ``` datatypes.d(1): Error: identifier expected following `import` datatypes.d(1): Error: `;` expected ``` --- [Extensive run.dlang.io example](https://run.dlang.io/is/f3jURn) Expected correct result if `package.d` was possible to import: ``` waffles/program.d(6): Error: `num` matches conflicting symbols: waffles/testing1.d(1):variable `testing1.num` waffles/testing2.d(1):variable `testing2.num` ```
Re: win32 api & lib issue
On Thursday, 2 November 2023 at 10:02:29 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 09:58:21 UTC, Peter Hu wrote: On Thursday, 2 November 2023 at 09:13:11 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 09:08:02 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 08:31:41 UTC, Peter Hu wrote: Greetings! From time to time I encountered issues on the subjected after I upgraded my dmd package.Given below code : [...] If it still doesn't work try adding this: ```d pragma(lib, "user32"); pragma(lib, "comdlg32"); ``` Another alternative if you're using dub is to add this in your dub.json instead: ```json "libs": ["user32", "comdlg32"] ``` This seems be something related to DMD vs LDC. Because if I change the compiler to DMD I also get unresolved external symbols, but not with LDC. It seems the forwarding of directives from submodules are different. Thank you. Below two pragma solved the isse but am confused as they are already in the system path.This is the first time I have to include lib files here.How come other gui programs don't have to do this. pragma(lib,"user32"); pragma(lib,"comdlg32"); I'm not sure why, it works for me, but I think it could be something dmd does different. The pragma lib is inserted into the generated object file, or otherwise passed to the linker, so the linker automatically links in that library. I'm guessing dmd for some reason does not see it in the submodule, but I have no proof that's the issue, I'm just guessing. Really appreciated for the help.I am learning to understand. Not using these two pragma in the source,other in the commandline:dmd -m64 user32.lib comdlg32.lib test.d compiled.But--- In an IDE say PoseidonD it still failed to compile even if I provided the library path to the compiler,I just can't understand how come my other small programs ( based on gui libslike DFL2,iup4D,dwt,NAppGui4D ) works fine without having to provide pragma in the source before compiling.
Re: win32 api & lib issue
On Thursday, 2 November 2023 at 09:58:21 UTC, Peter Hu wrote: On Thursday, 2 November 2023 at 09:13:11 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 09:08:02 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 08:31:41 UTC, Peter Hu wrote: Greetings! From time to time I encountered issues on the subjected after I upgraded my dmd package.Given below code : [...] If it still doesn't work try adding this: ```d pragma(lib, "user32"); pragma(lib, "comdlg32"); ``` Another alternative if you're using dub is to add this in your dub.json instead: ```json "libs": ["user32", "comdlg32"] ``` This seems be something related to DMD vs LDC. Because if I change the compiler to DMD I also get unresolved external symbols, but not with LDC. It seems the forwarding of directives from submodules are different. Thank you. Below two pragma solved the isse but am confused as they are already in the system path.This is the first time I have to include lib files here.How come other gui programs don't have to do this. pragma(lib,"user32"); pragma(lib,"comdlg32"); I'm not sure why, it works for me, but I think it could be something dmd does different. The pragma lib is inserted into the generated object file, or otherwise passed to the linker, so the linker automatically links in that library. I'm guessing dmd for some reason does not see it in the submodule, but I have no proof that's the issue, I'm just guessing.
Re: win32 api & lib issue
On Thursday, 2 November 2023 at 09:13:11 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 09:08:02 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 08:31:41 UTC, Peter Hu wrote: Greetings! From time to time I encountered issues on the subjected after I upgraded my dmd package.Given below code : [...] If it still doesn't work try adding this: ```d pragma(lib, "user32"); pragma(lib, "comdlg32"); ``` Another alternative if you're using dub is to add this in your dub.json instead: ```json "libs": ["user32", "comdlg32"] ``` This seems be something related to DMD vs LDC. Because if I change the compiler to DMD I also get unresolved external symbols, but not with LDC. It seems the forwarding of directives from submodules are different. Thank you. Below two pragma solved the isse but am confused as they are already in the system path.This is the first time I have to include lib files here.How come other gui programs don't have to do this. pragma(lib,"user32"); pragma(lib,"comdlg32");
Re: win32 api & lib issue
On Thursday, 2 November 2023 at 09:08:02 UTC, Imperatorn wrote: On Thursday, 2 November 2023 at 08:31:41 UTC, Peter Hu wrote: Greetings! From time to time I encountered issues on the subjected after I upgraded my dmd package.Given below code : [...] If it still doesn't work try adding this: ```d pragma(lib, "user32"); pragma(lib, "comdlg32"); ``` Another alternative if you're using dub is to add this in your dub.json instead: ```json "libs": ["user32", "comdlg32"] ``` This seems be something related to DMD vs LDC. Because if I change the compiler to DMD I also get unresolved external symbols, but not with LDC. It seems the forwarding of directives from submodules are different.
Re: win32 api & lib issue
On Thursday, 2 November 2023 at 08:31:41 UTC, Peter Hu wrote: Greetings! From time to time I encountered issues on the subjected after I upgraded my dmd package.Given below code : [...] If it still doesn't work try adding this: ```d pragma(lib, "user32"); pragma(lib, "comdlg32"); ```
Re: win32 api & lib issue
On Thursday, 2 November 2023 at 09:01:06 UTC, Imperatorn wrote:
On Thursday, 2 November 2023 at 08:31:41 UTC, Peter Hu wrote:
[...]
Works for me.
This is all you need
```d
import core.sys.windows.commdlg;
import core.sys.windows.winuser;
void main()
{
wchar[256] fileName;
OPENFILENAMEW ofn;
ofn.lStructSize = OPENFILENAMEW.sizeof;
ofn.lpstrFilter = "Text Files\0*.txt\0 D
files\0*.d;*.di\0\0"w.ptr;
ofn.lpstrFile = fileName.ptr;
ofn.nMaxFile = fileName.length;
if (GetOpenFileNameW())
{
MessageBoxW(null, ofn.lpstrFile, "File Selected:"w.ptr, 0);
}
}
```
Re: win32 api & lib issue
On Thursday, 2 November 2023 at 08:31:41 UTC, Peter Hu wrote:
Greetings!
From time to time I encountered issues on the subjected after I
upgraded my dmd package.Given below code :
import core.sys.windows.windows;
import core.sys.windows.commdlg;
import core.sys.windows.winuser;
extern(Windows) BOOL GetOpenFileNameW(LPOPENFILENAMEW);
extern(Windows) int MessageBoxW(HWND,LPCWSTR,LPCWSTR,UINT);
void main()
{
wchar[256] fileName;
fileName[0]=0;
OPENFILENAMEW ofn;
ofn.lStructSize=OPENFILENAMEW.sizeof;
ofn.lpstrFilter=
"Text Files\0*.txt\0 D files\0*.d;*.di\0\0"w.ptr;
ofn.lpstrFile=fileName.ptr;
ofn.nMaxFile=fileName.length;
if(GetOpenFileNameW())
{
MessageBoxW(null,ofn.lpstrFile,"File Selected:"w.ptr,0);
}
}
The compiler failed to build this small program.It complains
GetOpenFileNameW & MessageBoxW are unresolved external symbol.
DMD 2.103+VS Community 2015+Win10 64bit.
estwinapi.obj : error LNK2019: 无法解析的外部符号
_GetOpenFileNameW@4，该符号在函数 __Dmain 中被引用
testwinapi.obj : error LNK2019: 无法解析的外部符号
_MessageBoxW@16，该符号在函数 __Dmain 中被引用
testwinapi.exe : fatal error LNK1120: 2 个无法解析的外部命令
Error: linker exited with status 1120
Appreciated any help on figuring me out what the issue is and
how to fix it.
Works for me.
But you don't need to declare the functions, they are already
declared in commdlg and winuser.
```d
import core.sys.windows.windows;
import core.sys.windows.commdlg;
import core.sys.windows.winuser;
void main()
{
wchar[256] fileName;
fileName[0]=0;
OPENFILENAMEW ofn;
ofn.lStructSize=OPENFILENAMEW.sizeof;
ofn.lpstrFilter=
"Text Files\0*.txt\0 D files\0*.d;*.di\0\0"w.ptr;
ofn.lpstrFile=fileName.ptr;
ofn.nMaxFile=fileName.length;
if(GetOpenFileNameW())
{
MessageBoxW(null,ofn.lpstrFile,"File Selected:"w.ptr,0);
}
}
```
win32 api & lib issue
Greetings!
From time to time I encountered issues on the subjected after I
upgraded my dmd package.Given below code :
import core.sys.windows.windows;
import core.sys.windows.commdlg;
import core.sys.windows.winuser;
extern(Windows) BOOL GetOpenFileNameW(LPOPENFILENAMEW);
extern(Windows) int MessageBoxW(HWND,LPCWSTR,LPCWSTR,UINT);
void main()
{
wchar[256] fileName;
fileName[0]=0;
OPENFILENAMEW ofn;
ofn.lStructSize=OPENFILENAMEW.sizeof;
ofn.lpstrFilter=
"Text Files\0*.txt\0 D files\0*.d;*.di\0\0"w.ptr;
ofn.lpstrFile=fileName.ptr;
ofn.nMaxFile=fileName.length;
if(GetOpenFileNameW())
{
MessageBoxW(null,ofn.lpstrFile,"File Selected:"w.ptr,0);
}
}
The compiler failed to build this small program.It complains
GetOpenFileNameW & MessageBoxW are unresolved external symbol.
DMD 2.103+VS Community 2015+Win10 64bit.
estwinapi.obj : error LNK2019: 无法解析的外部符号
_GetOpenFileNameW@4，该符号在函数 __Dmain 中被引用
testwinapi.obj : error LNK2019: 无法解析的外部符号 _MessageBoxW@16，该符号在函数
__Dmain 中被引用
testwinapi.exe : fatal error LNK1120: 2 个无法解析的外部命令
Error: linker exited with status 1120
Appreciated any help on figuring me out what the issue is and how
to fix it.
