Re: compile: link dynamic OR static library in Windows
On Monday, 6 February 2023 at 06:59:09 UTC, Richard (Rikki) Andrew Cattermole wrote: On other platforms the -Lfile I think would work. On Windows you have to link against the import library not DLL directly. You can pass it to the compiler: $ dmd -i "-L/LIBPATH:C:\Program Files\PostgreSQL\15\lib" pq.lib app.d Should work. Sorry, I should have revisted this from the get go, rather than just tinkering with what others were posting. It doesn't work anyway... Is it possible to collect all this from under mingw so that the linker is not Microsoft, but `ld'?
Re: compile: link dynamic OR static library in Windows
On other platforms the -Lfile I think would work. On Windows you have to link against the import library not DLL directly. You can pass it to the compiler: $ dmd -i "-L/LIBPATH:C:\Program Files\PostgreSQL\15\lib" pq.lib app.d Should work. Sorry, I should have revisted this from the get go, rather than just tinkering with what others were posting.
ImportC "no include path set"
I'm trying out ImportC, but I can't get even the "Quick Example" running. > dmd -v .\source\foobar.c predefs DigitalMars LittleEndian D_Version2 all Windows Win32 CRuntime_Microsoft CppRuntime_Microsoft D_InlineAsm D_InlineAsm_X86 X86 assert D_PreConditions D_PostConditions D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo D_HardFloat binaryC:\D\dmd2\windows\bin\dmd.exe version v2.102.0-dirty configC:\D\dmd2\windows\bin\sc.ini DFLAGS-IC:\D\dmd2\windows\bin\..\..\src\phobos -IC:\D\dmd2\windows\bin\..\..\src\druntime\import include C:\D\dmd2\windows\bin\..\..\src\druntime\import\importc.h C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.34.31933\bin\HostX64\x86\cl.exe /P /Zc:preprocessor /PD /nologo .\source\foobar.c /FIC:\D\dmd2\windows\bin\..\..\src\druntime\import\importc.h /Fifoobar.i .\source\foobar.c(1): fatal error C1034: stdio.h: no include path set Error: C preprocess command C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.34.31933\bin\HostX64\x86\cl.exe failed for file .\source\foobar.c, exit status 2 So how am I supposed to set the include path? When ran on VS' Command Prompt it spits a link error instead. foobar.obj : error LNK2019: unresolved external symbol __va_start referenced in function _fwprintf_l foobar.exe : fatal error LNK1120: 1 unresolved externals Error: linker exited with status 1120 What am I missing?
Re: compile: link dynamic OR static library in Windows
On Monday, 6 February 2023 at 05:45:35 UTC, Richard (Rikki) Andrew Cattermole wrote: Ah doh, MSVC link doesn't use -L. $ dmd -i "-L/LIBPATH:C:\Program Files\PostgreSQL\15\lib" -Llpq app.d I think that is the option you want. Worst case scenario just copy the files to your working directory and it should find it without the additional search path. He doesn't want to anyway. I have already put the library in the source code folder. But it still pulls up the `*.obj` format for some reason. ```sh C:\sources\pxe-restore\source>ls app.d app.obj arsd azh libpq.lib pkg C:\sources\pxe-restore\source>dmd -i "-L/LIBPATH:C:\Program Files\PostgreSQL\15\lib" -Llpq app.d LINK : fatal error LNK1181: не удается открыть входной файл "lpq.obj" Error: linker exited with status 1181 C:\sources\pxe-restore\source>dmd -i "-L/LIBPATH:C:\sources\pxe-restore\source" -Llpq app.d LINK : fatal error LNK1181: не удается открыть входной файл "lpq.obj" Error: linker exited with status 1181 ```
Re: compile: link dynamic OR static library in Windows
Ah doh, MSVC link doesn't use -L. $ dmd -i "-L/LIBPATH:C:\Program Files\PostgreSQL\15\lib" -Llpq app.d I think that is the option you want. Worst case scenario just copy the files to your working directory and it should find it without the additional search path.
Re: compile: link dynamic OR static library in Windows
On 06/02/2023 6:16 PM, Alexander Zhirov wrote: C:\sources\pxe-restore\source>dmd -i app.d -L'-LC:\Program Files\PostgreSQL\15\lib' -Llpq Source files go after flags. $ dmd -i -L'-LC:\Program Files\PostgreSQL\15\lib' -Llpq app.d
Re: compile: link dynamic OR static library in Windows
On Monday, 6 February 2023 at 05:20:33 UTC, Richard (Rikki) Andrew Cattermole wrote: Source files go after flags. $ dmd -i -L'-LC:\Program Files\PostgreSQL\15\lib' -Llpq app.d For some reason, the `obj` file is link instead of the library. ```sh C:\sources\pxe-restore\source>dmd -L'-LC:\Program\ Files\PostgreSQL\15\lib' -Llpq -i app.d Error: cannot find input file `Files\PostgreSQL\15\lib'.d` import path[0] = C:\D\dmd2\windows\bin64\..\..\src\phobos import path[1] = C:\D\dmd2\windows\bin64\..\..\src\druntime\import C:\sources\pxe-restore\source>dmd -L'-L"C:\Program\ Files\PostgreSQL\15\lib"' -Llpq -i app.d LINK : fatal error LNK1104: не удается открыть файл "'-LC:\Program\ Files\PostgreSQL\15\lib'.obj" Error: linker exited with status 1104 ```
Re: compile: link dynamic OR static library in Windows
On Sunday, 5 February 2023 at 13:37:16 UTC, user1234 wrote: try ``` dmd -i app.d -L'-LC:\Program Files\PostgreSQL\15\lib' -Llpq ``` the first linker command gives a search path, the second a libname. It doesn't work ```sh C:\sources\pxe-restore\source>dmd -i app.d -L'-LC:\Program Files\PostgreSQL\15\lib' -Llpq Error: cannot find input file `Files\PostgreSQL\15\lib'.d` import path[0] = C:\D\dmd2\windows\bin64\..\..\src\phobos import path[1] = C:\D\dmd2\windows\bin64\..\..\src\druntime\import C:\sources\pxe-restore\source>dmd -i app.d -L'-L"C:\Program Files\PostgreSQL\15\lib"' LINK : fatal error LNK1104: не удается открыть файл "'-LC:\Program Files\PostgreSQL\15\lib'.obj" Error: linker exited with status 1104 C:\sources\pxe-restore\source>dmd -i app.d -L-L'C:\Program Files\PostgreSQL\15\lib' Error: cannot find input file `Files\PostgreSQL\15\lib'.d` import path[0] = C:\D\dmd2\windows\bin64\..\..\src\phobos import path[1] = C:\D\dmd2\windows\bin64\..\..\src\druntime\import ```
Re: SFML D bindings: libsfml-system.so.2.5: cannot open shared object file:
Thanks. update: just set up a Manjaro vm and it seems to work, I guess I'll have no choice but to switch to Manjaro then if I want to use sfml
Re: Non-ugly ways to implement a 'static' class or namespace?
I do not agree, that a compiler that allows a programmer to misuse a type, should be seen as 'a feature'. If that's the kind of 'power' D programmers want, then D is not for me. Eh, I don't think I would _quit_ D because of this issue, but it's definitely something that bothers me (more so the lack of an ecosystem) especially since I come from a .NET/JVM background. I'm pretty shocked this isn't a feature tbh.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Sunday, 5 February 2023 at 23:53:35 UTC, Ali Çehreli wrote: On 2/5/23 14:40, ProtectAndHide wrote: > On Sunday, 5 February 2023 at 10:51:51 UTC, thebluepandabear wrote: >> >> It's not a terrible workaround to be honest. >> > > The 'terrible' part is this: > > - the compiler will allow you to declare a variable of type Algo > - the compiler will allow you to declare an array with elements of type > Algo > - the compiler will allow you to use Algo as a type argument > - the compiler will allow you to use Algo as a parameter > - the compiler will allow you to use Algo as a return type I understand disabling the programmer to do certain things are beneficial e.g. to prevent bugs but those above can all be seen as features. What is so terrible about giving the programmer those powers? Ali I do not agree, that a compiler that allows a programmer to misuse a type, should be seen as 'a feature'. If that's the kind of 'power' D programmers want, then D is not for me.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Sunday, 5 February 2023 at 23:53:35 UTC, Ali Çehreli wrote: On 2/5/23 14:40, ProtectAndHide wrote: > On Sunday, 5 February 2023 at 10:51:51 UTC, thebluepandabear wrote: >> >> It's not a terrible workaround to be honest. >> > > The 'terrible' part is this: > > - the compiler will allow you to declare a variable of type Algo > - the compiler will allow you to declare an array with elements of type > Algo > - the compiler will allow you to use Algo as a type argument > - the compiler will allow you to use Algo as a parameter > - the compiler will allow you to use Algo as a return type I understand disabling the programmer to do certain things are beneficial e.g. to prevent bugs but those above can all be seen as features. What is so terrible about giving the programmer those powers? Ali I don't see why you'd want to expose a static class/namespace as a variable, or any of such similar things. That would give no benefits to the programmer?
Re: Non-ugly ways to implement a 'static' class or namespace?
On Sunday, 5 February 2023 at 23:50:35 UTC, Ali Çehreli wrote: On 2/5/23 02:57, thebluepandabear wrote: > When dealing with contexts, or for when you want a clear context in your > codebase, namespaces can be a life saver Can you give an example of a D problem that namespaces could solve? I have been with D for 14 years and haven't missed namespaces from C++ ever. The reason I ask is, mentioning lack of features of other programming languages is not the right way to go. We have to understand what problem they were trying to solve with that feature and then see how D already tackels it. In this case, it is namespacing and D solves it with the following feature and perhaps others that I can't think of: - modules - structs - classes - templates I don't consider myself a maintainer of D but I don't agree that yet another feature for namespacing is needed. I feel that it would bring complications. I don't think it is practical to bring all features of all languages into D or any other language. > we've seen it used in the D > library, so there's no excuse for why this shouldn't be added, in my > opinion. If I'm not mistaken you've counted five such instances. Were they really necessary? Could they be coded in a different way? What is the cost of missing namespaces? I think you are the first person raising this issue. You must have a strong case for this feature; so, I recommend you write a DIP for it. It is likely that the mere act of doing that will expose hidden costs and usage problems. Ali I'm not going to create a DIP when I've hardly even touched the surface of the language, this is a beginners forum. I would need to wait 3-5 years until I'd feel comfortable doing so. Right now, it's not my place to be doing such things; this is just an observation from a beginner (aka me).
staticMap but with two arguments
I have two AliasSeqs: one containing a function's parameters
(SourceSeq), the other containing the types I want to convert
said parameters to (TargetSeq). I'd use something like staticMap
to call the conversion function with both a parameter from
SourceSeq and a type from TargetSeq, and return an AliasSeq of
converted values which will be forwarded to another function.
staticMap's "fun" can only be instantiated with a single
argument, while I need it to work with two.
E.g.:
```
template toTarget(alias source, Target) {
static if (is(typeof(source) == int) && is(Target == string))
// for example, convert int to string
}
alias TargetSeq = Parameters!targetFunc;
auto wrapperFunc(A...)(A) {
alias SourceSeq = __traits(parameters);
return targetFunc(staticMap!(toTarget, SourceSeq)); // How
would I call staticMap (or something similar) with SourceSeq
*and* TargetSeq?
}
```
I could build the list of converted values manually but I wanted
something smart (like staticMap) to do it inline. I thought
ApplyLeft/Right could help but couldn't get my head around it.
Re: Non-ugly ways to implement a 'static' class or namespace?
On 2/5/23 14:40, ProtectAndHide wrote: > On Sunday, 5 February 2023 at 10:51:51 UTC, thebluepandabear wrote: >> >> It's not a terrible workaround to be honest. >> > > The 'terrible' part is this: > > - the compiler will allow you to declare a variable of type Algo > - the compiler will allow you to declare an array with elements of type > Algo > - the compiler will allow you to use Algo as a type argument > - the compiler will allow you to use Algo as a parameter > - the compiler will allow you to use Algo as a return type I understand disabling the programmer to do certain things are beneficial e.g. to prevent bugs but those above can all be seen as features. What is so terrible about giving the programmer those powers? Ali
Re: Non-ugly ways to implement a 'static' class or namespace?
On 2/5/23 02:57, thebluepandabear wrote: > When dealing with contexts, or for when you want a clear context in your > codebase, namespaces can be a life saver Can you give an example of a D problem that namespaces could solve? I have been with D for 14 years and haven't missed namespaces from C++ ever. The reason I ask is, mentioning lack of features of other programming languages is not the right way to go. We have to understand what problem they were trying to solve with that feature and then see how D already tackels it. In this case, it is namespacing and D solves it with the following feature and perhaps others that I can't think of: - modules - structs - classes - templates I don't consider myself a maintainer of D but I don't agree that yet another feature for namespacing is needed. I feel that it would bring complications. I don't think it is practical to bring all features of all languages into D or any other language. > we've seen it used in the D > library, so there's no excuse for why this shouldn't be added, in my > opinion. If I'm not mistaken you've counted five such instances. Were they really necessary? Could they be coded in a different way? What is the cost of missing namespaces? I think you are the first person raising this issue. You must have a strong case for this feature; so, I recommend you write a DIP for it. It is likely that the mere act of doing that will expose hidden costs and usage problems. Ali
Re: Non-ugly ways to implement a 'static' class or namespace?
On Sunday, 5 February 2023 at 22:40:09 UTC, ProtectAndHide wrote:
..
module test;
import std;
static final class Algo
{
@disable this();
static this()
{
Message = "Hello!";
}
static:
string Message;
void drawLine() {};
}
void main()
{
Algo foo1 = null; // the compiler should not allow you to
declare a variable of static type
Algo[] foo2 = null; // the compiler should not allow you to
declare an array with elements of static type
List[Algo] foo3; // the compiler should not allow you to use
static types as type arguments
writeln(foo1);
writeln(foo2);
writeln(foo3);
}
void Method1(Algo x) {} // the compiler should not allow you to
use static types as parameters
Algo Method2() { return null; } // the compiler should not allow
you to use static types as return types
struct List {}
Re: Non-ugly ways to implement a 'static' class or namespace?
On Sunday, 5 February 2023 at 10:51:51 UTC, thebluepandabear wrote: It's not a terrible workaround to be honest. The 'terrible' part is this: - the compiler will allow you to declare a variable of type Algo - the compiler will allow you to declare an array with elements of type Algo - the compiler will allow you to use Algo as a type argument - the compiler will allow you to use Algo as a parameter - the compiler will allow you to use Algo as a return type
Re: betterC DLL in Windows
On 05/02/2023 10:01 PM, Tamas wrote: On the surface, betterC seems to be perfect for this case. How would YOU do it (Adam, Richard)? BtW, gstreamer also has D bindings, and maybe in the future I'll use those. I suspect that Adam's suggestions have a stronger relevance to that case, right? So LDC with druntime and yes GC turned on is good enough right now that you can probably make it work without too much effort. You don't necessarily have to limit yourself to -betterC. In fact if you don't, you have access to PyD[0] which can handle the interop stuff for you. I haven't personally used it, but it might work for your use case :) The main thing is no matter what flags you pass, you'll need to be careful about memory ownership between the language divide and the ownership therein. You have already got a hang of that though from the C version! Just gotta be extra careful with GC memory that its pinned on the D side and won't get free'd elsewhere. But yeah if you can avoid having to create bindings for stuff (such as glib which we have bindings for), or wrappers ext. do so. That way you can do more of the fun things! [0] https://github.com/ariovistus/pyd
Re: compile: link dynamic OR static library in Windows
On Sunday, 5 February 2023 at 11:52:01 UTC, Alexander Zhirov wrote: On Saturday, 4 February 2023 at 15:56:41 UTC, Richard (Rikki) Andrew Cattermole wrote: [...] I don't understand why the compiler doesn't see the library. ```sh User@WIN-D3SHRBHN7F6 MINGW64 /home/user/pxe-restore/source # ls -la "C:\Program Files\PostgreSQL\15\lib\libpq.lib" -rw-r--r-- 1 User Отсутствует 37002 Nov 9 06:45 'C:\Program Files\PostgreSQL\15\lib\libpq.lib' User@WIN-D3SHRBHN7F6 MINGW64 /home/user/pxe-restore/source # dmd -i app.d -L'C:\Program Files\PostgreSQL\15\lib\libpq.lib' lld-link: error: could not open 'pq.lib': no such file or directory Error: linker exited with status 1 ``` try ``` dmd -i app.d -L'-LC:\Program Files\PostgreSQL\15\lib' -Llpq ``` the first linker command gives a search path, the second a libname.
Re: compile: link dynamic OR static library in Windows
On Saturday, 4 February 2023 at 15:56:41 UTC, Richard (Rikki) Andrew Cattermole wrote: On Windows you don't link directly against a DLL. You link against a static library (.lib) of the same name. The binding doesn't change between a static library and a shared library as long as you're linking during the compilation sequence and not during runtime. I don't understand why the compiler doesn't see the library. ```sh User@WIN-D3SHRBHN7F6 MINGW64 /home/user/pxe-restore/source # ls -la "C:\Program Files\PostgreSQL\15\lib\libpq.lib" -rw-r--r-- 1 User Отсутствует 37002 Nov 9 06:45 'C:\Program Files\PostgreSQL\15\lib\libpq.lib' User@WIN-D3SHRBHN7F6 MINGW64 /home/user/pxe-restore/source # dmd -i app.d -L'C:\Program Files\PostgreSQL\15\lib\libpq.lib' lld-link: error: could not open 'pq.lib': no such file or directory Error: linker exited with status 1 ```
Re: Non-ugly ways to implement a 'static' class or namespace?
On Sunday, 5 February 2023 at 10:51:51 UTC, thebluepandabear
wrote:
{
@disable this();
static this()
{
Message = "Hello!";
}
static:
string Message;
void drawLine() {};
}
It's not a terrible workaround to be honest.
`static class` does have a use when it's nested, so it might
create some conflicts if such a feature (like C# `static
class`) were added.
Due to the mindset of the current maintainers of the language,
I doubt we will see such a thing. Maybe in 10-20 years
something will change and the language will add a static class
or namespace feature, for now we'll have to deal with modules
or using your way of creating a `static class`.
I don't like it when people see modules as a replacement for a
namespace/static class, when that's not the case.
Rust has modules. It also has namespaces.
C++ will be getting modules, it also has namespaces.
When dealing with contexts, or for when you want a clear context
in your codebase, namespaces can be a life saver, we've seen it
used in the D library, so there's no excuse for why this
shouldn't be added, in my opinion.
Re: Non-ugly ways to implement a 'static' class or namespace?
{
@disable this();
static this()
{
Message = "Hello!";
}
static:
string Message;
void drawLine() {};
}
It's not a terrible workaround to be honest.
`static class` does have a use when it's nested, so it might
create some conflicts if such a feature (like C# `static class`)
were added.
Due to the mindset of the current maintainers of the language, I
doubt we will see such a thing. Maybe in 10-20 years something
will change and the language will add a static class or namespace
feature, for now we'll have to deal with modules or using your
way of creating a `static class`.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 30 January 2023 at 21:54:49 UTC, thebluepandabear
wrote:
...
Interesting, so maybe there is a use case for a purely static
type or namespace?
The standard library as well uses `final abstract class` a
couple of times, which can also be thought as a type of
namespace.
All these 'hacks' to workaround a namespace-like feature are
... interesting... So maybe such a feature would help the
language?
Just askin questions!
Yes, a C# like static class would be nice in D:
(i.e. you mark it as static, or whatever, and all the following
then applies:
- Is sealed
- Cannot be instantiated or contain Instance Constructors.
- must contain only static members.
btw, it seems 'static' applied to class at the module level, in
D, means nothing at all??
btw. Discovered that D has support for static constructors, which
I didn't know.
Below is not that 'ugly', really, but I certainly prefer the
clean, C# way (i.e. just mark it as static, and that's that).
// cannot inherit from, since it is final.
// cannot instantiate it with 'new', since it is annotated with
@disable
//
// NOTE: static here is meaningless and can be removed.
static final class Algo
{
@disable this();
static this()
{
Message = "Hello!";
}
static:
string Message;
void drawLine() {};
}
Re: betterC DLL in Windows
On Sunday, 5 February 2023 at 00:27:19 UTC, Richard (Rikki) Andrew Cattermole wrote: On 05/02/2023 1:20 PM, Adam D Ruppe wrote: Even module imports can fail because betterC disables outputting the module data info, even if it would otherwise be required by language rules, despite it not using the druntime. This only affects you if you use full D to interact with -betterC code. Even then it is very easy to work around. https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/moduleinfostubs.d -betterC DLL's do work with full D executables. If all you need it for is gluing some stuff together don't listen to Adam about it not working, because it absolutely does and quite usable if you're not expecting there to be a GC. I'm repeating myself, but I'm very happy to see so many helpful responses to my newbie question. It gives me a good feeling about the community here. As I wrote, I'd like to use D only in a limited way, for now. My project actually interfaces Python and glib/gstreamer, the glue being provided by my C code. What I'd like to do is to improve on my C code, inspired by [this interview](https://dlang.org/blog/2017/08/23/d-as-a-better-c/). I don't want to introduce another GC or runtime into the picture, and I probably don't need to call any D libraries. Python -> my C code -> glib/gstreamer C libs to Python -> C improved by betterC -> glib/gstreamer C libs On the surface, betterC seems to be perfect for this case. How would YOU do it (Adam, Richard)? BtW, gstreamer also has D bindings, and maybe in the future I'll use those. I suspect that Adam's suggestions have a stronger relevance to that case, right?
Re: betterC DLL in Windows
On Sunday, 5 February 2023 at 00:20:24 UTC, Adam D Ruppe wrote: There's a lot of things described in the documentation that don't actually work. D can be an *extremely* productive language if you know which parts to focus on, but most the newer hyped features just don't deliver. The table of contents on the left side of the site is in roughly chronological order. The things near the top are pretty reliable, [...]. The things near the bottom are not reliable. [...] and so on I appreciate all of this... however, as a newcomer, I wish the docs were simply more honest, instead of representing wishful thinking. I guess in any programming language, experience reveals things not present in the docs, but it seems to apply much more acutely here.
Re: betterC DLL in Windows
On Saturday, 4 February 2023 at 19:44:15 UTC, bachmeier wrote: On Saturday, 4 February 2023 at 18:29:41 UTC, Tamas wrote: What's the reason to prefer LDC over DMD? Anyone that cares about performance will use LDC rather than DMD. It's hard to imagine a case where someone would want betterC to avoid the GC, but they wouldn't want to use LDC. When I started using D many years ago, LDC was behind DMD, so you needed to use DMD to have a current compiler. That's no longer true. The only reason I use DMD today is the faster compilation speed when I'm doing a lot of write-compile-debug iterations. Good to know, thank you. The posts I've seen so far online suggesting to start with DMD must've been outdated, then.
