Re: How to make project with main application and cli application in the same folder?
On Sunday, 21 April 2024 at 08:44:38 UTC, alex wrote: Hi guys. Trying to play with vibe-d and want to create separate web app, and cli app which can add admin users. When I just keep both files app.d and cli.d in source folder, I get an error that I can't have more then 1 main function. You can do this using configurations. Whichever you list first will be the default. Then you can use `-c configName` or `--config=configName` to build the other one. You'll want to exclude one of the main functions when building the configuration to which it doesn't belong. You can do that with version specifications (e.g., add a `cli` version in the cli configuration, then `vesrion(cli) void main {...}` in the code). Alternatively, if the files the main functions are in are self-contained, then you can just exclude the one you don't need in each configuration with the `excludeSourceFiles` directive. Configurations: https://dub.pm/dub-guide/recipe/#configurations
Re: Boneheaded question regarding compilation...
On Monday, 1 April 2024 at 21:23:50 UTC, WhatMeWorry wrote: Huge fan of Mike Shah's YouTube videos regarding D and his latest for D conference: https://mshah.io/conf/24/DConf%20%20Online%202024%20_%20The%20Case%20for%20Graphics%20Programming%20in%20Dlang.pdf So I installed github desktop app and cloned his Talks repo. There is a build command commented out at the top of the main.d file which I've been trying to compile, via the command line: C:\Users\kheas\Documents\Talks\2024\dconf_online\hello_triangle>dmd -g -J. main.d ./glad/gl/*.d -L-L/usr/local/lib -L-lglfw3 -of=prog && ./prog Error: cannot find input file `.\glad\gl\*.d` import path[0] = C:\D\dmd2\windows\bin64\..\..\src\phobos import path[1] = C:\D\dmd2\windows\bin64\..\..\src\druntime\import I'm using a Windows 11 machine so I thought that maybe the syntax was for Linux environment. But replacing all the '/' with '\' did not work. An easier fix may be perhaps to just use 'dub' and install the glfw dependency. In my talk, I did everything from scratch (my preferred way), though I suspect using dub with glfw-d (https://code.dlang.org/packages/glfw-d) may provide less resistance.
Re: Best way to use large C library in D as of 2024
On Saturday, 30 March 2024 at 05:01:32 UTC, harakim wrote: @D Language Foundation - This is a HUGE selling point. I had to use cups the other day and I just copied some code from a d file and linked the library. It was so easy I was suspicious but it worked. Using C from D is pretty much as easy as using C from C and I think you should advertise that better! Though I appreciate the sentiment, it's much more effective and efficient for people actually using the feature, and who appreciate it, to write up a blog post about it somewhere and share that on Twitter/Reddit/HN, etc. Just a handful of people doing that would potentially reach a wider audience, they'd be able to show the feature in use in actual code, and their words will probably carry more weight as a language user than someone from the DLF. There's a world of difference between showing it in use in a real-world project vs. showing examples of how it can be used, which is all that I'd be able to do if I were to write about it. And that goes for anything that makes you think "the DLF should advertise this". I mean, when I had time to prioritize the blog, I was regularly writing articles about cool D features, and sometimes getting others to write guest posts about their projects or whatever. But that's pretty much like one person standing on a hilltop with a megaphone, periodically handing it off to someone else. How many other people from the D community were adding their voices? Now and then, someone would write something up somewhere, but it wasn't happening regularly or often. Anyone happy using D, who wants to see it continue to grow and improve, can help toward that end by telling the world about it. That said, if there's anyone out there who would like to take on management of the blog and make it more active, I'd love to hear from you.
Re: DIP 1036e not on the DIPs list?
On Friday, 23 February 2024 at 23:30:26 UTC, kdevel wrote: The DIP 1036e is not listed in https://github.com/dlang/DIPs/tree/master/DIPs is this intentional? The DIP process has been closed for a while now. Atila did write a proposal for Adam's implementation, and I'll add it to the repo after I open up the DIP process again (reopening very soon). It won't be 1036e, though.
Re: Would you recommend TDPL today?
On Tuesday, 16 January 2024 at 02:58:03 UTC, Jonathan M Davis wrote: On Monday, January 15, 2024 7:25:32 PM MST matheus via Digitalmars-d-learn wrote: [...] [...] that have since changed or which were never implemented (e.g. synchronized classes never became a thing; synchronized functions still exist, but TDPL talks about them being replaced with synchronized classes and that never happened - and likely will never happen). There's also an errata for it, but AFAIK, that just fixes some mistakes it; it doesn't update it. This wiki entry tries to list some of the differences, but I expect that it also is rather out-of-date at this point: https://wiki.dlang.org/Differences_With_TDPL So, TDPL is a good resource, but you have to take into account the fact that some of the details are wrong, which you may not want to do. In that respect, Ali's book would likely work better: http://ddili.org/ders/d.en/index.html It was written more recently, and I'm pretty sure that Ali has updated it on some basis. I fully expect that there are things that you'd get out of TDPL that you wouldn't get from Ali's book, so there's definitely something to said for reading both, but again, whether that makes sense largely depends on whether you want to deal with figuring out which parts of TDPL are still valid. - Jonathan M Davis I'll also add that Adam's Book (D Cookbook) and Mike Parkers Book (Learning D) are both excellent. Mike's is mostly up to date, minus I think the post-blit function calls. Adam's has lots of various samples (may be good to read alongside, or otherwise after Ali or Mike's book once you have a feel for the language).
Re: I Did It! Calling D Library from Objective C in XCode on OSX
On Thursday, 4 January 2024 at 14:17:01 UTC, pizza_dox_ wrote: On Monday, 14 December 2015 at 10:09:29 UTC, Mike McKee wrote: I finally managed to get it working, using some help from this forum and stackoverflow.com, and a little bit of random luck with tests. [...] Hello dlang forum, I tried to replicate the shown, but I failed at the dmd compile stage. The dmd compiler for windows only puts out .obj files and no .o files. Is there another flag to set that makes the dmd compiler behave differently? Or is there another way to produce .o files from dlang source code? Best regards pizza_dox_ I haven't tried, but ldc2 may also be an option if dmd does not support this functionality.
Re: anonymous structs within structs
On Monday, 4 December 2023 at 18:26:07 UTC, DLearner wrote: Suppose we need a construct like: ``` void main() { struct A { int I1; int I2; char X; } struct B { A Dummy; int Var1; int Var2; } } ``` But do not want to give an explicit name (like 'Dummy' above) to the A struct held within the B struct. Just removing 'Dummy' does not work (Error: no identifier for declarator `A`). Nor does replacing 'Dummy' with {} Suggestions? One possible solution is to use a 'mixin template' where you effectively 'copy and paste' in the 'struct' and access the symbols. Is something like this what you had in mind? ``` void main() { import std.stdio; mixin template A() { int I1; int I2; char X; } struct B { mixin A; int Var1; int Var2; } B someObject; writeln(someObject.I1); writeln(someObject.I2); } ```
Re: At D-Conf, Mike Shah's students presented a project. Is it in GitHub? Cant find it.
On Saturday, 23 September 2023 at 05:56:31 UTC, WhatMeWorry wrote: Wanted to study code. I watched the video talk. But i couldn't see any URL etc.. Believe it was called Draw. https://github.com/abstewart/DRaw
Re: pragma lib doesn't support static libraries?
On Sunday, 30 July 2023 at 05:28:32 UTC, ryuukk_ wrote: I should have explained exactly what i am doing.. Looks like it doesn't work when i compile in 2 step - compile with: ``dmd -c of=bin/game.o`` - link with: ``dmd bin/game.o`` When doing it this way, then it doesn't work However, when compiling/linking in one ``dmd`` invocation (without ``-c``), then it all works So it looks like the pragma is not passed on the linked when it was compiled with ``-c`` Is this a bug? should i report it?, or is that the expected behavior? It's expected behavior. There's no link step in the first command, so the pragma is meaningless there. And I'm unaware of any mechanism for embedding static library names in an object file for a linker to read later.
Re: Designated initializers to function argument
On Friday, 28 July 2023 at 21:07:47 UTC, bachmeier wrote: On Friday, 28 July 2023 at 17:07:37 UTC, IchorDev wrote: No shit, it felt like an eternity. But it's still not in the spec...? I'd expect it to appear in the spec after there's a real release. This is the first I've heard of it being supported, and it sounds like it's incomplete. https://github.com/orgs/dlang/projects/19 Dennis has been working on this in pieces rather than all at once, as it required modification to multiple parts of the compiler.
Re: having troubles with D and Vulkan.
On Friday, 21 July 2023 at 02:22:56 UTC, harakim wrote: On Thursday, 20 July 2023 at 06:27:13 UTC, Danni Coy wrote: ok found it, I am an idiot, (really not used to working with dynamic libraries). erupted needs a call to load device level functions. loadDeviceLevelFunctions(instance); On Thu, Jul 20, 2023 at 4:22 PM Danni Coy wrote: https://pastebin.com/Jc9ZaFFs Redid the code as an almost exact translation of the C code. should be easier to test and compare. Same issue is occurring. On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via Digitalmars-d-learn wrote: > [...] Good work! Now I can rest in peace tonight. :D Same for me :) Great to see folks working in Vulkan with D.
Re: having troubles with D and Vulkan.
On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote: https://pastebin.com/JxxJufNB What platform are you using, and how are you trying to build? I can try to replicate on my end.
Re: GDC Compilation wtih Directory Present
On Friday, 16 June 2023 at 06:38:17 UTC, Murloc wrote: Thanks! That works well. I thought that `module pack.file1` is implicitly there by default :') The compiler will use the file name as a default module name if you don't provide one, but that's *just* the module name. It doesn't take into account any directories for package names.
Re: GetInterfaceInfo function of win32 api
On Thursday, 8 June 2023 at 07:01:44 UTC, Benny wrote: I got something! thank you. now I need to understand how can I get the properties of the GetInterfaceInfo ``` import core.sys.windows.iphlpapi; import std.stdio; import core.stdc.stdlib; void main() { uint* i; i = cast(uint*) malloc(10); auto h = GetInterfaceInfo(null, i); writefln("%s", h); writeln("Hello, World!"); } ``` this got me 122 Alright. I've never used this function, so I referenced the documentation here: https://learn.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-getinterfaceinfo First, you don't need to allocate i with malloc. Just declare it as a uint and give the function a pointer to it. Second, the function is intended to be called twice. The first time with null for the first parameter as you've done here. After that call, the value in i should be the size of the memory you need to allocate for the first parameter on the second call. In the second call, the data you want will be stored in that pointer. Third, the first parameter is of type PIP_INTERACE_INFO, which in Windows lingo means "pointer to IP_INTERFACE_INFO". That's declared in the ipexport module. Here's a working example. I chose to use the GC rather than malloc. ```d import core.sys.windows.windows, // For the error codes core.sys.windows.iphlpapi, core.sys.windows.ipexport; import std.stdio, std.string; void main() { IP_INTERFACE_INFO* pinfo; uint buflen; // Get the size needed to alloc pinfo uint ret = GetInterfaceInfo(null, &buflen); if(ret == ERROR_INSUFFICIENT_BUFFER) { // Allocate pinfo, but let's not use malloc ubyte[] buf = new ubyte[](buflen); pinfo = cast(IP_INTERFACE_INFO*)buf.ptr; } // Call the function a second time to get the data ret = GetInterfaceInfo(pinfo, &buflen); if(ret == NO_ERROR) { writeln("Number of adapters: ", pinfo.NumAdapters); for(size_t i = 0; iwritefln("Adapter Index[%s]: %s", i, pinfo.Adapter[i].Index); writefln("Adapter Index[%s]: %s", i, fromStringz(pinfo.Adapter[i].Name)); } } else if(ret == ERROR_NO_DATA) { writeln("No network adapters found"); } else { writeln("GetInterfaceInfo failure: ", ret); } } ```
Re: GetInterfaceInfo function of win32 api
On Thursday, 8 June 2023 at 05:52:43 UTC, Benny wrote: ``` ``` app.obj : error LNK2019: unresolved external symbol GetInterfaceInfo referenced in function _Dmain app.exe : fatal error LNK1120: 1 unresolved externals Error: linker exited with status 1120 ``` That's a linker error telling you that you aren't linking anything that contains the symbol for `GetInterfaceInfo`. You need to link `Iphlpapi.lib`.
Re: unittest under betterC
On Monday, 5 June 2023 at 14:29:35 UTC, Richard (Rikki) Andrew Cattermole wrote: On 06/06/2023 2:25 AM, Mike Parker wrote: On Monday, 5 June 2023 at 14:16:39 UTC, ryuukk_ wrote: In my book this is broken and needs to be fixed, as a user i don't care about under the hood things, it's a you problem, user should be able to unit test The docs say it should work: https://dlang.org/spec/betterc.html#unittests So either the docs are wrong or the implementation is bugged. If there's no issue yet, could you please file one? Yes that is what I recommended earlier in the thread. But automatic running requires druntime. Ah, I see now. It's working as expected then.
Re: unittest under betterC
On Monday, 5 June 2023 at 14:16:39 UTC, ryuukk_ wrote: In my book this is broken and needs to be fixed, as a user i don't care about under the hood things, it's a you problem, user should be able to unit test The docs say it should work: https://dlang.org/spec/betterc.html#unittests So either the docs are wrong or the implementation is bugged. If there's no issue yet, could you please file one?
Re: How does D’s ‘import’ work?
On Saturday, 3 June 2023 at 09:04:35 UTC, Dom DiSc wrote: You can replace your whole makefile by calling the compiler with -I (not always, but if you don't do funny things in your makefile). That would be `-i`. - This ability of the D compiler was just recently discovered (after -I was implemented for other reasons), but it relies on the fact that we have imports. Jonathan Marler implemented it in 2017 after a discussion in the forums. https://github.com/dlang/dmd/pull/7099
Re: How static link dll msvcr120.dll?
On Thursday, 1 June 2023 at 15:05:40 UTC, Marcone wrote: I linked msvcr120.lib, but the executable still ask for msvcr120.dll not found. msvcr120.lib is a "link library", not a static library. On other systems, you pass shared libraries directly to the linker and it will pull the information it needs from there to set up the exectuable with what it needs for the system loader to load the shared library at runtime. Windows works differently. The compiler puts all that information in a link library when it creates the DLL, and you pass that to the linker instead of the DLL. Windows system libraries are not distributed as static libraries as far as I know.
Re: A Programmer's Dilema: juggling with C, BetterC, D, Macros and Cross Compiling, etc.
On Monday, 1 May 2023 at 09:17:14 UTC, Eric P626 wrote: This is a false dilemma: D has full C compatibility. From what I understand, D can use C, but C cannot use D? It's like C++: C++ can call C but C cannot call C++. 50% or more of my code will be put in re-usabled libraries. If I want people to use those libs, I would need to compile them in C or better C. Because betterC seems to create C libraries. If D can make C libraries, then indeed, I could do everything in D. D is ABI-compatible with C. BetterC has nothing to do with it. And if you're using BetterC just because you're linking with a C library, you're crippling your D code. That's not really a good use case for it. Any D function marked as `extern(C)` can be called from C. As long as you have a C header file defining the functions and the appropriate C declarations any custom types you have, the C code will have no idea it's calling into a D library. In your D library: ```D // This function can be called from C extern(C) void functionForTheCAPI(const(char)* str) { import std.conv : to; doSomething(to!string(str)); } // This is a D function that cannot be called from C void doSomething(string s) { ... } ``` In the corresponding C header: ```C extern void functionForTheCAPI(const char* str); ``` Just `#include` the C header in your C code, link with the D library, and you're good to go. Make sure to include a function somewhere in your D library's C API to initialize DRuntime: ```D import core.runtime; extern(C) int initialize() { return Runtime.initialize(); } ``` Add the declaration to a C header and you're good to go.
Re: A Programmer's Dilema: juggling with C, BetterC, D, Macros and Cross Compiling, etc.
On Monday, 1 May 2023 at 09:35:59 UTC, Dukc wrote: hard. Seems the C-linked functions in [core.runtime](https://dlang.org/phobos/core_runtime.html#.Runtime.initialize) ought to do the trick. If you're referring to `rt_init` and `rt_term` are the `extern(C)` functions in `core.runtime`. It's not necessary to call those from C. A D library with a C interface can provide an `extern(C)` initialization function that internally calls `Runtime.initialize`.
Re: Making a D library for a C executable
On Thursday, 27 April 2023 at 20:32:24 UTC, Jan Allersma wrote: ``` Apparently foo isn't found from the CPP source file. Anyone some ideas on how to solve this? :) That's a compilation error, not a linker problem. You need to tell the compiler about the function with a prototype: ```C++ #include int foo(); int main() { std::cout << "deede" << foo() << std::endl; } ```
Re: Cannot get this C++ example migrated to D
On Sunday, 16 April 2023 at 07:46:53 UTC, Skippy wrote: I wish D had value type classes as well. I like the distinction between class and struct in D. It encourages you to think harder about how you intend to use your types. In C++, there may as well only be one or the other; the distinction is so small as to be meaningless.
Re: Cannot get this C++ example migrated to D
On Sunday, 16 April 2023 at 05:58:39 UTC, Skippy wrote: These lines aren't necessary: // ?? int counter; // ?? static this() { counter = test.objCnt; } `t1` is default-initialized, so it's null. test t1, t2 = new test(); Ditto for t3. Classes are reference objects, not value objects, so you must explicitly instantiate instances if you want them to be non-null. test t3; The modified code: ```d class test { private: int objNo; static int objCnt; public: this() { objNo = ++objCnt; } ~this() { --objCnt; } void printObjNumber() { writefln("object number : %s", objNo); } static void printObjCount() { writefln("count: %s", objCnt); } } int main() { test t1 = new test(), t2 = new test(); test.printObjCount(); test t3 = new test; test.printObjCount(); t1.printObjNumber(); t2.printObjNumber(); t3.printObjNumber(); return 0; } ```
Re: Unresolvable dependencies to package
On Saturday, 15 April 2023 at 00:42:17 UTC, Mike Parker wrote: I also suggest you visit the issues page for bindbc-imgui and file an issue there: I meant to delete this line. I've filed the issue: https://github.com/BindBC/bindbc-imgui/issues/1
Re: Unresolvable dependencies to package
On Friday, 14 April 2023 at 20:30:56 UTC, el machine code wrote: so my question why am i'm getting this error and how do i fix this? The two listed packages depend on bindbc-sdl, and they do so in a way that is incompatible with each other. On your end, you can edit `dub.selections.json` in your project's root directory alongside your `dub.json` and specify the version of bindbc-sdl that dub should choose. In this case, it should be the same as inochi-creator since that's the latest version: ```json "dependencies": { "bindbc-sdl": "~>1.1.2" }, ``` That should resolve the conflict. This approach can cause issues when the conflicting versions of a library are incompatible (e.g., missing symbols), but in this case you should be fine. As far as I'm aware, there should be no incompatibilities betwen binbc-sdl 0.x and 1.x. I also suggest you visit the issues page for bindbc-imgui and file an issue there: https://github.com/BindBC/bindbc-imgui/issues The BindBC maintainer recently took over binbc-imgui and added it to the BindBC group (it was originally maintained independently of the BindBC group). The version of `dub.sdl` in master depends on bindbc-sdl 1.1.2, but that version has not been tagged as a new release. I'll file an issue there to prompt a new release, and I'll also file an issue with inochi-creator to use the new release once it's tagged. But for now, `dub.selections.json` should get your immediate problem sorted.
Re: How to setup D with SFML? (using bindbc-sfml)
On Sunday, 9 April 2023 at 09:54:26 UTC, Ki Rill wrote: Why can't it find these libraries? I tell where to look for them: ```D version(Windows) { import bindbc.loader; setCustomLoaderSearchPath("libs"); // tried using absolute path as well } ``` That is strange... I've tried your project out two ways, one that succeeds and one that fails. I'm guessing you've put your 'libs' directory is 'bin/libs'. Am I right? If so, then the following should help you. When dub runs the exectuable, it sets the current working directory to the project's root directory by default. `setCustomLoaderPath` passes whatever you give it directly to the system API unmodified. You've passed a relative path. By default, the system API associates relative paths with the current working directory. So given a project root directory of `$ROOT`, and your executable in `$ROOT/bin`, the system is looking for the libraries in `$ROOT/libs` and *not* in `$ROOT/bin/libs`. If the libs are in the former, everything loads. If they're in the latter, then it's going to fail. If you cd into `bin` and run the executable manually, then libs in `$ROOT/bin/libs` will load, as your current working directory is `bin`. The quick fix for this is to add `"workingDirectory" : "bin"` to your dub.json. Then your relative paths will be relative to `$ROOT/bin/`. Bear in mind that when using relative paths like this, any file reading is bound to break if someone runs your executable from outside its directory. You can test this by going into `$ROOT` from the command line and executing `bin/d-sfml-project-template`. Then you'll be doing the same thing dub does, i.e., your working directory will be `$ROOT`. The way to guarantee your relative paths are always relative to the executable are to either set the current working directory to the executable's path, or to prepend all relative paths with the executable's path before handing them off to the system. There are two ways you can get the full path to the executable in Phobos/DRuntime: via `std.file.thisExePath`, or `core.runtime.Runtime.args[0]`. (The former is failing to compile for me on Windows right now due to a bug in the Phobos Win32 API bindings. I'll look into it.) Strip the file name from the returned path, then you can use it as required.
Re: How to setup D with SFML? (using bindbc-sfml)
On Saturday, 8 April 2023 at 11:31:40 UTC, Ki Rill wrote: How do I set up a D and SFML project using the `bindbc-sfml` package? I tried following the instructions, it builds successfully, but fails to load the SFML library at runtime. In particular, `loadSFML, loadSFMLGraphics, loadSFMLXXX` fails. Here is [link](https://github.com/rillki/d-sfml-project-template) to the repo. I plan to create another how-to video, but I cannot find what's causing it to fail. Do you have any ideas? Not without error messages. The first thing you should do is use the error API in bindbc.loader to print them out. That should tell you what the problem is.
Re: #define-like behavior
On Tuesday, 14 March 2023 at 05:47:35 UTC, Jeremy wrote: Hi, in C and C++ you can use #define to substitute a value in place of an identifier while preprocessing. If you initialize a new string and don't change its value after that, will the compiler substitute the string identifier with its value, like #define in C, or will it make a string in memory and refer to that? Manifest constants in D have a similar effect as #defined values, e.g.: ```d enum someVal = 10; writeln(someVal); ``` Here, the effect is the same as if you'd written `writeln(10)`. The difference is that with the preprocessor, it's a text replacement on the source before the compiler gets ahold of it, but in D the compiler handles the substitution internally. The same is true for string literals: ```d enum str = "Hello"; writeln(str); ``` String literals get special treatment from the compiler in that they are "interned". ```d auto s1 = "What's up?"; auto s2 = "What's up?"; ``` The literal "What's up?" *should* be stored in the binary only once, so both s1 and s2 will point to the same location. Substitute a manifest constant and the effect should be the same: ```d enum greeting = "What's up?"; auto s1 = greeting; auto s2 = greeting; ``` Just be aware that there's a consequence for array literals: ```d enum vals = [1, 2, 3]; auto a1 = vals; auto a2 = vals; ``` This allocates two dynamic arrays, not one. Everywhere you use `vals` it's just like using the literal directly, which usually means an allocation.
Re: Code organization, dub, etc.
On Monday, 13 March 2023 at 13:20:21 UTC, Joe wrote: Yeah, it seems like it's *only* for libraries (and a few single-exe utilities). Looking at code.dlang.org, under "Stand-alone applications/Server software", the top rated item is "handy-httpd" which according to its dub.json builds a library! And the second place "voxelman" is builds three libraries and one executable, which appears to be a "launcher" to access the libraries as plugins. The package registry is full of libraries, yes. That's what it's primarily for. There aren't a lot of executables uploaded there because they're usually better distributed in other ways. But plenty of people are using dub to build them. One way to handle multiple executables is to write a simple script that makes multiple calls to dub with the configurations you need. And I haven't looked into it yet, but it may be possible to use `preBuildCommands` to do the same thing. E.g., add a default with a `preBuildCommands` entry calling dub on multiple configurations.
Re: Directly compiling a D program with other libraries
On Monday, 13 March 2023 at 05:05:27 UTC, Jeremy wrote: Hello, I am new to this forum and to D. I am trying to compile a basic D program with libraries (`requests` which requires `cachetools` and `automem`) without using dub. I have never used dub before, only a compiler. The folders containing the libraries are in the same folder as main.d, the file I am trying to compile, and the command I am using to compile is `ldc2 -I. main.d`. When I compile my program, I just get linker errors such as: ``` /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: main.o: in function `_Dmain': main.d:(.text._Dmain+0x2f): undefined reference to `_D8requests10getContentFNcAyaZSQBd7streams__T6BufferThZQk' ``` Does anyone have any advice on how to solve my problem? That's a linker error, meaning the missing symbol isn't available to link into the executable. You need to compile the source of all the libraries you use and make sure the resultant binaries are available for the linker to link into the executable. The -I switch you've passed tells the compiler where to find imported modules. The compiler needs parse them to know which symbols are available for you to use when it's compiling your code. (The current working directory is the default anyway, so you don't need to pass `-I.` for that.) By default, the compiler does not compile imported modules. If you add `-i` to the command line, then it will compile all of the modules you import (as long as they're in the `-I` path), excluding the DRuntime and Phobos modules. It will then also pass all of the compiled object files to the linker, so then your linker error should go away. However, when you choose not to use dub, you need to also ensure that you are accounting for any special compiler flags the libraries you use may require (for example, specific `-version` values). If they're configured to compile as static or shared libraries, it may be easier just to store the source for each of them outside of your project's source tree, use dub to build each of them, and then pass the compiled libraries to the compiler when you build your program. In that case, you wouldn't use `-i`. Just make sure that `-I` is correctly configured in that case.
Re: @nogc and Phobos
On Saturday, 11 March 2023 at 12:04:25 UTC, bomat wrote: So my question is: Is Phobos essentially incompatible to `@nogc`? Or is there a trick for mixing GC code with non-GC code that I don't know? I'm assuming the second, for if the first was true I'd say that D would be pretty much useless when combined with non-D libs... Any function annotated with `@nogc` can only call other `@nogc` functions, but they can be called by *any* function. So it won't affect your use of the GC or Phobos in that regard. Or is there a specific problem you've encountered?
Re: How to build a static lib properly?
On Monday, 6 March 2023 at 02:09:23 UTC, ryuukk_ wrote: dub should build a static library for the project i build, that includes each library it uses that are referenced as "library" since the default is "staticLibrary" according to rikki What you're asking for is a different use case. `staticLibrary` is for compiling a specific dub package as a static library. It does not imply that all of that package's dependencies should also be compiled into a single static library. Nor should it. You're asking for a package and its dependencies to be bundled for use outside of the dub ecosystem as a single static library. I won't say it's not a legitimate use case, it's just not one that dub currently supports, nor was it originally intended to (I wouldn't expect it to be a common one either, but then again common expectations are always changing). As a potential dub enhancement, e.g., `staticLibraryBundle`, I do agree it's worth exploring. I don't believe you can expect every package to "just work" in that environment. As Steve mentioned, there will always be link-time dependencies to any shared libraries on which those bundled libraries depend. And some packages may be set up in a way that causes issues, as Rikki noted when he said he had to make some tweaks on his successful build. But for the time being, dealing with static libraries in D is just the same as dealing with them in the C and C++ world. They always have been a PITA to deal with, and that's why the trend in recent years has been to move away from them. Build tools like dub hide them from you when used as intended. It's when you mix build systems that you run into trouble. Still, I suggest you send an email to soc...@dlang.org as part of the Gripes and Wishes campaign so that this gets added into the dataset. Anything that enhances dub's usability should be looked at.
Re: How to build a static lib properly?
On Monday, 6 March 2023 at 01:52:06 UTC, ryuukk_ wrote: 6B71D90\dparse.lib -g ``` Are you saying dub doesn't build a static dcd.lib? What to do to make it so i get a static dcd.lib file that contains all the code it needs? This comfort me in my desire to no longer use dub ever This is not dub's fault. When building a shared library, there's a link step, so any external dependencies are linked into the shared library just as they are with an executable. There is no link step with a static library. That means when you build your executable, you need to also link the static library's dependencies along with it. Most of the symbols in your list appear to come from the packages listed in the dependencies section of DCD's dub.json: https://github.com/dlang-community/DCD/blob/master/dub.json So if you want to do this manually, with DCD as a static library, then you also need to build all of those dependencies and link them with your executable.
Re: How can i find my LAN IP Address using std.socket?
On Tuesday, 4 February 2014 at 22:31:53 UTC, Dicebot wrote: On Tuesday, 4 February 2014 at 20:19:14 UTC, TheFlyingFiddle wrote: I'm setting up a simple local network enabling me to connect phones to the computer through the local wi-fi. The simplest way i could think of to make this work without relying on an external server was to simply broadcast the ip and port to all machines in the network.(Btw by server i mean my / my project groups windows boxes). So well the problem is that i need a way for the phones to find running servers on the LAN. I think it is close to impossible to do in portable way. Most reliable approach is to get list of all configured network interfaces via posix functions (or via `system` call as least resort), filter out "lo" and broadcast message for every such interface. I think you can also filter only wireless interfaces that way relatively easily too. Apologies that I am bumping a post that is 9 years old, but I recently had to do this and thought this may help beginners. In a way it's a hack as suggested from the second post, that you can connect to a known ip address (e.g. google) from a socket and then see the endpoints with the local and remote addresses. ``` import std.stdio; import std.socket; void GetIP(){ // A bit of a hack, but we'll create a connection from google to // our current ip. // Use a well known port (i.e. google) to do this auto r = getAddress("8.8.8.8",53); // NOTE: This is effetively getAddressInfo writeln(r); // Create a socket auto sockfd = new Socket(AddressFamily.INET, SocketType.STREAM); // Connect to the google server import std.conv; const char[] address = r[0].toAddrString().dup; ushort port = to!ushort(r[0].toPortString()); sockfd.connect(new InternetAddress(address,port)); // Obtain local sockets name and address writeln(sockfd.hostName); writeln("Our ip address: ",sockfd.localAddress); writeln("the remote address: ",sockfd.remoteAddress); // Close our socket sockfd.close(); } ```
Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 20 February 2023 at 06:26:34 UTC, FeepingCreature wrote: There have now been three pages produced by three people all agreeing with each other. At what point does it start being spam? Yes, it's all just noise now. Let's end it here. Further posts in this thread will be deleted.
Re: Dub is not finding the dynamic link library MSVCR120.dll...
On Sunday, 19 February 2023 at 21:05:33 UTC, WhatMeWorry wrote: and is abending with an error saying exactly this. How do I specify the path to this library? Can I use one of the environment variables in sc.ini, one of the Windows env variables, or one of the dub options? Btw, I'm bypassing on purpose the official D installation. Any error about a missing DLL is a run-time error that's unrelated to dub or the compiler. Normally, for end users, a missing MSVC runtime DLL means you have to install the MSVC Redistributable package. This version of the DLL you're missing is from MSVC 2013, so that's the version of the package you'd need. However, I wonder what's causing the problem in the first place. Do you have Visual Studio installed, or are you using the out-of-the-box libraries and linker that ship with DMD?
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote: Wrong. I'm arguing things: Geez. "I'm arguing 2 things:"
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide wrote: What Mike is arguing, is that I don't need a 'data hiding' mechanism for a user-defined type, because that is already provided to me by the 'data hiding' mechanism of the module. That is his argument. My argument is that I want 'data hiding' mechanism at the user-defined type level as well. Again, his argument is that i don't need it.. because... Wrong. I'm arguing things: 1. D has encapsulation (you say it doesn't). 2. We don't need a new protection attribute or a redefinition of private because D already provides the mechanism to give you what you want.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 09:51:41 UTC, zjh wrote: What if two classes in the module that are several meters apart make `mistakes` that change the privite variable of `another class`? No one can guarantee that after `a few months`, even if you are the author, you will not make mistakes, so as to misuse private variable, while `class level` private can be completely avoided it! There is no maintainability, because two `out-of-class` functions may quietly change your private `variables`. I referenced that in my post. The exact same problem exists *inside* the class when your class file is very long. You can easily manipulate the private member even when it's only supposed to be accessed by a specific function. A common recommendation in Java used to be (and probably still is) to always accessing private members by their setters even inside the class. And after all these years they haven't had a need to lock down single-method access to private members. It's the *exact* same thing in D: the private implementation is in the source file. The fact that the source file represents a module rather than a single class is irrelevant. We keep repeating the same arguments over and over and over again on this. I still haven't seen any convincing argument for changing things when it's already possible to do what you want to do. I repeat for the umpteenth time: if you care so much about who can touch your private parts, then put your classes and structs in their own modules and use D's package facilities to provide the public interface you want.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 08:56:00 UTC, Mike Parker wrote: If private were restricted to the class/struct, it would add anything more for encapsulation in D. I meant to say, it "wouldn't add more".
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 07:23:39 UTC, thebluepandabear wrote: Why is the unit of encapsulation the module though? Makes no sense. What is the purpose of encapsulation? To keep the implementation details hidden behind the public API, such that changing the implementation doesn't change the API. Consider this: ```d module gfx; struct Point { private int x, y; this(int x, int y) { this.x = x; this.y = y; } void move(Point to) { x = to.x; y = to.y; } } ``` Here, `move` is part of the public API. `x` and `y` are part of the implementation. Nothing outside the module can touch them. Now this: ```d module gfx; struct Point { private int x, y; this(int x, int y) { this.x = x; this.y = y; } } void move(ref Point from, Point to) { from.x = to.x; from.y = to.y; } ``` From the perspective of the public API, nothing has changed. The following works in both cases: ```d Point p; p.move(Point(10, 20)); writeln(p); ``` In both cases, the implementation is hidden behind the same public API. If private were restricted to the class/struct, it would add anything more for encapsulation in D. In practical terms, if you are editing the `gfx` module, you also have access to the implementation details of `Point`. Sure, if you have e.g., a special setter that does some extra work when a member variable is set, you want to ensure that only that setter is used to change the member variable. But that's true *inside the class/struct* as well. I mean, just consider this: ```d class C { private enum minX = -100; private int _x; void setX(int newX) { _x = newX > minX ? newX : minX } void doSomething(State s) { setX(_x + s.val); } } ``` vs. this: ```d class C { private enum minX = -100; private int _x; void setX(int newX) { _x = newX > minX ? newX : minX } } void doSomething(C c, State s) { c.setX(c._x + s.val); } ``` Ideologically, they are not the same. In practical terms, they are. Whether the closing brace of the class declaration is before or after `doSomething` matters not one bit. Yes, things can go wonky in a module that's many lines long and someone sets `_x` from outside of the class. So what? The same is true for a class that's many lines long when someone adds a new method that directly sets `_x` rather than going through the setter. D's modules are intended to be used for grouping related constructs. Everything in the module is part of the same private implementation. If the constructs aren't related, then put them in separate modules. And there's still a solution for anyone with a strict ideological preference regarding related constructs: they can put their classes and structs in individual modules under a common package. `package` protection can be used for cross-module access inside the package, and the entire set can be presented to the outside world as a single module with `package.d`. Our friend of many forum handles misses no opportunity to return to this putrid horse corpse to beat it some more, but the meaning of private isn't going to change. This is D's approach to encapsulation.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Wednesday, 15 February 2023 at 01:16:00 UTC, thebluepandabear wrote: I think what you could say is that D lacks _encapsulation_ which is also an OOP concept. So D is partially OOP but not fully OOP due to there being no encapsulation in the language. D does not lack encapsulation, it's just that the unit of encapsulation is the module. Everything private in a module is encapsulated from the perspective of the public API. If you really want to prevent anything inside a module from accessing the private parts of a class, you can put the class in its own module. Must we continue beating this horse?
Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 23 January 2023 at 00:36:36 UTC, thebluepandabear wrote: I haven't been programming for a long time, but most of the other languages I used had such a namespace feature. Kotlin has something called an `object` which is essentially a namespace and it is great. The benefits of adding a namespace-like feature outweigh its costs, imo. If you really want to, you can mostly force a namespace use like this: ``` // mylib/package.d module mylib; public static import mylib.impl.funcs; // mylib/impl/funcs.d module mylib.impl.funcs; void foo() { } ``` Now when users import mylib, the public static import means hey call mylib.foo. Just don't bother documenting the impl subpackage and only those who look at the source will even know it exists. I went through this same process when I first came to D years ago. D's modules *are* namespaces, and I wanted a way to force them. Eventually, I got over it. There's no reason to force a namespace. Namespaces are intended to disambiguate conflicting symbols. So let the users use them that way. There's no need to force them to type out the namespace all the time. It's certainly not an OOP vs. procedural issue, as namespaces have nothing to do with OOP.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 23 January 2023 at 00:11:17 UTC, thebluepandabear wrote: Sorry don't like that solution specifically. That's because it is a procedural implementation, not an OOP-style one. I don't know how much of the D community writes procedurally but I'm personally an OOP-type of guy. A class full of static methods is not OOP either.
Re: (Noob question) Should subclasses be defined in separate modules?
On Friday, 13 January 2023 at 05:17:59 UTC, thebluepandabear wrote: (Sorry if this is a duplicate.) If I have the following code inside of a module: ```D class Obj { private { string name = "Hi"; } } class ObjDerived : Obj { } ``` Is it best practice to define `ObjDerived` inside another module, since `ObjDerived` can still access the members of `Obj` (since `private` is only applied to modules), or does this go against the intended use of the language? As a beginner, I am having an extremely tough time understanding why you would want to place these two classes in the same module or even have this intended behavior of `private`. I am coming from Java/Kotlin which are both strictly OO language and have different ways of encapsulation. The short answer: just think of a module as a way of grouping related objects and functions. If it makes sense to you for `ObjDerived` to have access to the internals of `Obj`, then keep them in the same module. If it doesn't, then put it somewhere else. The long answer: there's no one-size-fits all here. For a short program, a script let's say, just dump everything in one module and be done with it. For a program you're writing for your own use, do whatever you feel comfortable with, even if you plan to open source it. For something you're writing for others to use, like a library, then the first priority is to think about what the public facing API should look like. From that perspective, does `ObDerived` belong in the same module, or is it unrelated enough to go into a different one? If it does fit in the same module, then that can be enough. It is for me. I'd stop there. But some people want to go one step further and ensure that `ObjDerived` can't access the internals of `Obj`. So in that case, you can put them in two separate modules and make a `package.d` file to act as the common module name for both. I think there are good reasons to do that, but most of the time it's just a matter of preference.
Re: Compile time vs run time -- what is the difference?
On Wednesday, 28 December 2022 at 02:31:45 UTC, thebluepandabear wrote: In Java and some other languages, during compile time the code gets executed into Java bytecode. This also happens for C#. I don't know if there is an equivalent 'intermediate' language for D that your code gets translated to. With statically compiled languages like D, C, and C++, the compiler ultimately translates your source code to what's referred to as "machine code". Compilers output object files, which are in turn linked into an executable file by a linker. Static compilers can use intermediate representations like Java bytecode. For example, compilation could consist of two steps handled by two different programs, one that translates the source to bytecode, and one that translates the bytecode to an object file. This is how LLVM-based compilers like Clang and LDC work. Clang translates C source to LLVM IR (Intermediate Representation). LDC translated C source to LLVM IR. Both pass the generated IR to the LLVM compiler, which outputs the object files that are then given to a linker. Static Java compilers do the same thing with Java bytecode. Java JIT compilers built into Java VMs translate Java bytecode to machine code while the program is running. So compilation is just the act of translating from one source format to another (e.g., raw source code to machine code, or raw source code to bytecode, or bytecode to machine code). In general, I have a very vague understanding of these concept.s I don't understand the basics of how compile time and run time works in D language, it wasn't really explained in the book so when I see terms like 'compile time' and 'run time' I only have a very vague idea of what these things mean and how the process works for D language when compared to other high level languages. Anything that happens at compile time means it happens while the compiler is translating the source. Anything that happens at run time happens while the compiled program is running. So take this example: ```d uint fourcc(char a, char b, char c, char d) { return (a << 0) | (b << 8) | (c << 16) | (d << 24); } // Here, fourcc is evaluated at compile time enum nv12 = fourcc('N', 'V', '1', '2'); void main() { writeln(nv12); // Here, fourcc is evaluated at runtime writeln(fourcc('Y', 'V', '1', '2')); } ``` When the compiler is processing this source code, it encounters the declaration of `nv12`. Since this is an `enum`, it's a compile-time constant that cannot be changed at run time. That means that any value used to initialize it must also be known at compile time. One way to do that would be to use a literal, but in this case it's initialized with a call to the `fourcc` function. So the compiler evaluates the fourcc function and uses the result as the initializer of `nv12`. In other words, the end result is just the same as if I had written `enum nv12 = 842094158`. The second call to `fourcc` in the main function is not in a compile-time context, so it does not happen at compile time. It happens at run time, i.e., when you double click the executable that the compiler and linker generated (or type its name on the command line). The general rule is: if a function call is in a context such that it *must* be evaluated at compile time, then the compiler will evaluate it. Otherwise, it's a normal run-time evaluation.
Re: Is there such concept of a list in D?
On Monday, 19 December 2022 at 22:22:11 UTC, thebluepandabear wrote: No worries, hopefully a mod will explain why. I don't like when posts get removed for no reason :| I received a report of a possible troll in the forums. Looking at the posts collectively, I agreed, so deleted all of them. Whenever we delete a post, we delete subsequent posts that quote them as well. Please take any further discussion on moderation policies to a new thread in the General forum and let's take this thread back on topic. Thanks!
Re: Is defining get/set methods for every field overkill?
On Thursday, 24 November 2022 at 03:49:16 UTC, []() {}() wrote: I broke a forum rule by critically analysing your blog? Wow. Criticize my blog posts all you want. Just stop please stop derailing threads. I'm going to delete further off topic posts in this thread.
Re: Is defining get/set methods for every field overkill?
On Wednesday, 23 November 2022 at 23:35:59 UTC, thebluepandabear wrote: Please stop, we get it... I'm not a moderator so I cannot enforce rules but there is NO need to continue this debate here. This software 'religiousness' is too much. I am a moderator and I can enforce the rules. So yes, let's please drop this tired old debate about private and get back on topic. Or just let the thread die. Thanks.
Re: Actual lifetime of static array slices?
On Tuesday, 15 November 2022 at 02:49:55 UTC, Mike Parker wrote: It's not the scope that matters here. It's the stack. Memory allocated in the inner scope uses the function stack, so it's all valid until the function exits. And that was just so, so wrong. Of course destructors get called when scopes exit, etc.
Re: Actual lifetime of static array slices?
On Tuesday, 15 November 2022 at 02:26:41 UTC, Elfstone wrote: I failed to find any documentation, except dynamic array slices will be taken care of by GC, but I assume it's not the case with static arrays. A slice is a view on the existing memory owned by the original array. No allocations are made for the slice. The GC will track all references to the memory allocated for a dynamic array, so as long as any slices remain alive, so will the original memory. Static arrays are allocated on the stack and become invalid when they leave a function scope. In turn, so would any slices or other pointers that reference that stack memory. But the code bellow doesn't behave as I expected. int[] foo() { int[1024] static_array; // return static_array[]; // Error: returning `static_array[]` escapes a reference to local variable `static_array` return null; } class A { this(int[] inData) { data = inData; } int[] data; } void main() { int[] arr; A a; { int[1024] static_array; arr = aSlice; // OK a = new A(aSlice); // OK arr = foo(); //arr = foo(); } } By assigning aSlice to arr or a, it seemingly escapes the scope, I thought there'd be errors, but the code compiles just fine. Is it really safe though? It's not the scope that matters here. It's the stack. Memory allocated in the inner scope uses the function stack, so it's all valid until the function exits.
Re: Using glibc headers with ImportC
On Sunday, 13 November 2022 at 09:15:39 UTC, qua wrote: I agree it was unexpected that it didn't, at least for newcomers. Almost everyone is a newcomer when it comes to ImportC.
Re: ImportC linking issue
On Saturday, 12 November 2022 at 10:02:12 UTC, confuzzled wrote: On Saturday, 12 November 2022 at 08:43:13 UTC, Mike Parker wrote: On Saturday, 12 November 2022 at 02:45:52 UTC, confuzzled wrote: The linker doesn't care if the libraries are C or D, and the compiler is only involved in that you can pass flags to the linker via the compiler command line. Mike, first of all, thanks for the in depth response. That all makes sense. The issue I'm having is this: having made sure the two dependencies are available and building the libxlsxio_reader.a from the source without errors, why would I need to hunt down all the dependencies from that library to include them in my program? I figured that importing the header and passing libxlsxio_read.a on the command line would be enough? Why would I have to search for libcrypto, libminizip, libexpat, and more that I haven't even figured out what library they are? I thought those dependencies would already be linked into libxlsxio_read.a which is a statically linked library. Static library dependencies are resolved at link time. Anything they need to link with, your binary must link with. It's shared libraries that have their static dependencies all baked in.
Re: ImportC linking issue
On Saturday, 12 November 2022 at 02:45:52 UTC, confuzzled wrote: It seems that every time I resolve one of these undefined symbols issues, the compiler finds more. So I keep copying lib files from locations that are a path, to my working directory and linking them to my script. Is that the norm? Do I need to configure DMD somehow to recognize C libraries that are already in the path? The linker doesn't care if the libraries are C or D, and the compiler is only involved in that you can pass flags to the linker via the compiler command line. These two things need to be true: * any link-time dependencies (object files, static libraries, shared libraries (link libraries on Windows)) need to be passed to the linker * the linker needs to know where to find libraries not on the default search path The only thing the compiler passes along automatically are the object files generated from the source and the standard library it's building a binary. Anything else (including separately compiled object files), you have to pass along explicitly. If you aren't explicitly passing any libraries along, then the linker won't know anything about them. The compiler doesn't know about them either, so can't pass them along for you. If you are passing them along but they aren't on the default lib path, then the linker won't be able to find them. Based on your description, it sounds like the last case is true for you. If so, if your libraries are in a common location, you can pass that path to the linker through dmd via `-L`. E.g., on Linux, `-L-L/path/to/libs`. On Windows, it depends on which linker you're using. For the Microsoft linker, it's `-L/LIBPATH path\\to\\libs`. You can also just pass the full path to each library.
Re: dmd as a library
On Tuesday, 8 November 2022 at 06:21:11 UTC, vushu wrote: So I do feel, that I am in need for some learning materials or guidance. You might find Lucian Danescu's DConf '22 presentation helpful: https://youtu.be/JYkb3PjIn4c
Re: What's the correct way of creating an instance of class in D?
On Thursday, 3 November 2022 at 06:02:13 UTC, Mike Parker wrote: are in C++. D enforces the distinction that C++ ...that C++ programmers often follow by convention.
Re: What's the correct way of creating an instance of class in D?
On Thursday, 3 November 2022 at 05:41:06 UTC, Siarhei Siamashka wrote: Thanks for the link and also thanks for confirming that you have no clue what's going on. I think that what actually That's not necessary. He does know what's going on and pointed you to the correct place. The second paragraph on the page says: Class objects are instantiated by reference only. Then further down the page: https://dlang.org/spec/class.html#class-instantiation Instances of class objects are created with a NewExpression: happens is that the D code ```D A a2; a2.foo(); ``` is roughly equivalent to C++ ```C++ A *a2 = NULL; a2->foo(); ``` That's correct. Classes in D are like Java classes. `a2` is a reference. Structs, on the other hand, are value types as they are in C++. D enforces the distinction that C++ I see two problems here. First, the D language documentation is incomplete and does not cover this particular syntax. And I think that it does. But given that you missed it, then it could potentially be improved. Perhaps a new entry in the instantiation section that makes clear a declaration without an initialization is default initialized to null. The documentation is maintained by the community. You can post about issues you find here in the forums, or better, report them at issues.dlang.org (we're moving our bug tracking to GitHub soon). second, D language is designed (intentionally or accidentally) to be hostile to the C++ developers trying to learn it. This particular issue is known as https://en.wikipedia.org/wiki/False_friend D is not C++. Nor is it Java, nor C, nor C#, nor Python, etc. There are similarities and differences. Any time you try out a language, you will view it through the lens of the language(s) you know, and you are going to encounter problems like this. I wouldn't call that hostility, intentional or accidental. But when you do encounter those differences in D, people here are willing to help you, so all you have to do is ask.
Re: Importing modules under DUB on Windows
On Thursday, 27 October 2022 at 16:40:20 UTC, DLearner wrote: I'm not getting on with DUB. Maybe fewer people use it under Windows, so Windows constructs don't get exercised so much. Is there a non-DUB way of arranging that `import arsd.terminal;` will use that module as held on GitHub? (DUB name: "arsd-official:terminal": "~>10.9.4"). OS: Windows 10. Compiler: DMD. This has nothing to do with Windows. The source path error you encountered is an assertion failure that tells you what's wrong: dub does not allow you to add absolute paths to the source path. I don't know why. If you disagree, then you can file an issue in the dub github repository. In the meantime, you'll need to work around the limitation. You could 1. Add the file to your source tree 2. Use a relative path in `sourcePaths` 2. Add arsd-official as a dub dependency All of these would solve the problem. If you aren't going to do any of these things, then you'll need a fourth option. The compiler (not dub) needs to know where to find imports, and the linker needs an object file to resolve symbols. So you should: 1. Compile /arsd/terminal.d as a static library with ldc (named e.g., "arsd-terminal.lib") and output the library to the path where you want it (e.g., C:\libs) 2. Add the parent directory of the arsd folder to your `importPaths` in dub. 3. Add linker flags to your dub project to tell the compiler where to find the library You have two options for #3. If this is the only external libs you're working with, then you can just add the full path to the library in an `libs` entry: ```json "libs": ["C:\\libs\\arsd-terminal"] ``` Note that you do not add the ".lib" extension here. Dub will do that for you. If you have multiple external libs, then it's better to add the library path like so: ```json "lflags": ["/LIBPATH:C:\\libs"], "libs": ["lib1", "lib2", "lib3"] ``` Note that `/LIBPATH` is specific to the Microsoft linker, which I assume LDC uses on Windows: https://learn.microsoft.com/en-us/cpp/build/reference/libpath-additional-libpath?view=msvc-170 If it's using the LLVM linker, then you'll need the appropriate flag for that. If you aren't planning to build on other platforms, then you'll want to make these dub directives platform specific, e.g., `libs-windows` rather than `libs`.
Re: dub ldc2 static linking
On Friday, 28 October 2022 at 01:37:50 UTC, Mike Parker wrote: This has nothing to do with dub and is not a D issue specifically. Enter your error message in Google and you'll get a long list of results. Maybe one of them can help you. Or do what kinke suggests :-)
Re: dub ldc2 static linking
On Thursday, 27 October 2022 at 08:08:38 UTC, Yura wrote: curl.d:(.text._D3std3net4curl7CurlAPI7loadAPIFZPv+0xd): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking and many other warnings like this. What am I doing wrong? Any way to fix it? This has nothing to do with dub and is not a D issue specifically. Enter your error message in Google and you'll get a long list of results. Maybe one of them can help you.
Re: Can someone tell me what the compiler thought I was trying to do?
On Wednesday, 19 October 2022 at 03:10:29 UTC, Mike Parker wrote: It's right there in the summary of the Final Review of the DIP that I linked above: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#final-review I meant to say the summary of the formal assessment. One of the conditions of acceptance was this one: develop rules for handling covariance and contravariance when applied to functions. Paul opted instead to do just have it apply to types for now. A future enhancement can take on extending it to functions. As he noted above, that's the approach Rust took as well.
Re: Can someone tell me what the compiler thought I was trying to do?
On Wednesday, 19 October 2022 at 01:34:54 UTC, mw wrote: On Wednesday, 19 October 2022 at 01:30:23 UTC, H. S. Teoh wrote: On Wed, Oct 19, 2022 at 01:15:37AM +, Adam D Ruppe via it only applies to types, not to functions. Wat... so what's the use of it then? So it's not possible to mark the return value of an int function @mustUse without making, in theory, *all* ints @mustUse? I must confess I'm baffled as to the purpose of this strange design. Same, can't believe it. Is there any (design) doc about this? It's right there in the summary of the Final Review of the DIP that I linked above: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#final-review
Re: How do I correctly install packages for use with Visual Studio?
On Sunday, 16 October 2022 at 11:09:31 UTC, Decabytes wrote: I'm confused at what/where exactly D expect files to be for them to considered "installed". D doesn't expect them to be anywhere. By default, the compiler will search relative to the current working directory, on any paths configured in dmd's config file, and on any paths you (or your IDE) give it via `-I` on the command line. I strongly recommend against keeping libraries in the dmd source directory. You'll have to copy them over again on every new compiler install. If Visual D doesn't yet support dub (I've not used it in a long while, so I don't know), then it's probably best to set up a common directory somewhere on your system. Just make sure not to put the package directory (e.g., in src/raylib, raylib is the package directory) on the import path, but the root source directory. You'll probably want to keep any compiled library binaries on a common path, too, so that you can configure that in the IDE settings.
Re: How do I correctly install packages for use with Visual Studio?
On Sunday, 16 October 2022 at 11:09:31 UTC, Decabytes wrote: Building x64\Debug\chip8.exe... chip8.d(4): Error: unable to read module `raylib` chip8.d(4):Expected 'raylib.d' or 'raylib\package.d' in one of the following import paths: import path[0] = C:\D\dmd2\windows\bin\..\..\src\phobos import path[1] = C:\D\dmd2\windows\bin\..\..\src\druntime\import import path[2] = C:\D\dmd2\windows\bin\..\..\src\gtkd import path[3] = C:\D\dmd2\windows\bin\..\..\src\raylib ``` But I do have a package.d located in C:\D\dmd2\src\raylib\package.d. Does anyone know what I did wrong? Your import paths are wrong. This, for example: import path[3] = C:\D\dmd2\windows\bin\..\..\src\raylib The path should be C:\D\dmd2\windows\bin\..\..\src\ Ditto for gtkd looks like.
Re: Can someone tell me what the compiler thought I was trying to do?
On Friday, 14 October 2022 at 22:17:52 UTC, H. S. Teoh wrote: Given that this particular trap crops up regularly, perhaps some sort of warning ought to be added. Once the @nodiscard DIP is accepted & implemented this should be easy to do. Seems like you're behind the times! The DIP was accepted and implemented with some changes: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#final-review The summary in full: --- The language maintainers accepted this DIP with a request for changes: * rename `@noDiscard`, as they want to avoid adding additional negative attributes to the language. * address issues that arise from the feature's interaction with inheritance when applied to classes. * develop rules for handling covariance and contravariance when applied to functions. The DIP author addressed these requests by renaming the attribute to @mustuse and allowing it only on structs and unions. His rationale for the latter is described in the section, Design Goals and Possible Alternatives. The maintainers approved the author's changes and accepted the revised version of the DIP. ---
Re: Can someone tell me what the compiler thought I was trying to do?
On Friday, 14 October 2022 at 21:51:54 UTC, WhatMeWorry wrote: I lost about a half an hour troubleshooting some code of mine which as it turned out to be resolved with just one line. // paths.remove(i); // compiles fine but does nothing paths = paths.remove(i); // works - what I erroneously thought the previous line was doing Is the first line nonsensical and should the compiler have at least issued a warning? At the moment, no. You should have read the documentation of the function :-) Note that remove does not change the length of the original range directly; instead, it returns the shortened range. If its return value is not assigned to the original range, the original range will retain its original length, though its contents will have changed: You ignored the return value of a function you shouldn't have ignored. It's not practical for the compiler to warn every time you do that, as it currently can't know that you're *supposed* to use it. `@mustuse` was added to the language in 2.100.0 as an attribute for `struct` or `union`, but not yet for functions, as explained in the DIP: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1038.md#mustuse-as-a-function-attribute If that ever gets expanded for use as a function attribute, then it can be used in situations like this so that you must use the return result. Until then, read the documentation!
Re: Visual D doesn't work, now Visual Studio Code / D doesn't work!!!! ....
On Sunday, 2 October 2022 at 11:00:06 UTC, Daniel Donnell, Jr wrote: I thought I set everything up correctly, and now: ``` Exception thrown at 0x7FF7D6E2E230 in metamath-d.exe: 0xC096: Privileged instruction. Unable to open natvis file 'c:\Users\fruit\.vscode\extensions\webfreak.code-d-0.23.2\dlang-debug\dlang_cpp.natvis'. ``` So what the hell do you D developers use to code with if A) Visual D doesn't work - it just ate my app.obj file and can't find it anymore no matter if I clean or re-order the executable paths in settings. B) VS Code doesn't work out-of-the-box. Every. Single. Time I get around to using D, there's always something that pops up and doesn't work right. And it never gets fixed. How the heck do you expect me to debug without a proper debugging IDE :| Plenty of people are using Visual D and VS Code with D. Whatever the source of your problem, it's surely fixable. Though if no one has encountered this particular issue, then it may take some doing to figure out the problem. I've emailed Rainer, the maintainer of Visual D, to notify him of this thread. He might have an idea of what's wrong, or at least will be in a position to ask more informed questions than I or others to help you solve the problem. In the future, when you encounter Visual D issues, please post in the IDEs forum. Rainer checks in there more regularly and will be more likely to see your posts. https://forum.dlang.org/group/ide
Re: D installer
On Sunday, 2 October 2022 at 11:33:47 UTC, Imperatorn wrote: I only have Visual Studio 2022. Will the installer be updated to support that or am I missing some components? ![Installer](https://i.ibb.co/sCZRFRf/installer.jpg) You should be fine. Select the bottom option since you already have it installed.
Re: Why I get delegate when passing address of function?
On Sunday, 11 September 2022 at 09:15:11 UTC, Mike Parker wrote: Pointers to non-static member functions always produce a delegate. Otherwise, you wouldn't be able to access the class instance's members. Reference: https://dlang.org/spec/function.html#closures
Re: Why I get delegate when passing address of function?
On Sunday, 11 September 2022 at 09:02:31 UTC, Injeckt wrote: I have a one class and two modificators, where in "public" function I'm calling CreateThread with address of the ClientThread function which stored in same class, but in "private" modificator. And i get this error: Error: cannot pass argument `&this.ClientThread` of type `extern (Windows) uint delegate(void* param)` to parameter `extern (Windows) uint function(void*) @system`. Pointers to non-static member functions always produce a delegate. Otherwise, you wouldn't be able to access the class instance's members.
Re: How I can pass the WndProc as a parameter?
On Saturday, 10 September 2022 at 10:39:12 UTC, Injeckt wrote: To elaborate on why you need the above... But I get these bugs: WndProc is a function, and you can't pass a function as a runtime function parameter, only pointers to functions. The first two errors tell you exactly what the problem is. server.d(29): Error: function `server.WndProc(void* hwnd, uint message, uint wParam, int lParam)` is not callable using argument types `()` Note the bit that says "not callable using argument types `()`". In D, functions that have an empty parameter list can be called without an argument list, i.e., `void foo()` can be called as `foo`, the compiler rewrites it to `foo()`. This error by itself tells you what's wrong. The compiler knows `WndProc` is a function, so it's trying to call `WndProc()` when it sees the `WndProc` in your argument list in the function call to `KK.CreateWindowClass` at line 29 of server.d. server.d(29): too few arguments, expected `4`, got `0` And this reinforces that: the `WndProc` function takes 4 arguments, but none were provided. When doing Win32 programming in D, it sometimes helps to search online for problematic types. Microsoft's Win32 API documentation is really good. For functions, that's the only reference you need. But for other types and aliases, it sometimes helps to go one step further: use the MS docs to find out which header the type is defined in, then go the DRuntime source to find the corresponding binding. In this case, searching for `WNDPROC` would turn up this page: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nc-winuser-wndproc At the bottom of which we see that it's defined in `winuser.h`. So then you can go to the DRuntime sorce directory (it's installed with the compiler) and open `core/sys/winuser.d`, in which a search for `WNDPROC` eventually leads to this: `alias LRESULT function(HWND, UINT, WPARAM, LPARAM) WNDPROC;` That tells you it's a function pointer, meaning your function call needs `&WndProc`, since that's how we get function pointers in D.
Re: How I can pass the WndProc as a parameter?
On Saturday, 10 September 2022 at 10:39:12 UTC, Injeckt wrote: And after all, I call it: KK_CreateWindowClass(WndProc); `KK_CreateWindowClass(&WndProc);`
Re: How include header file?
On Wednesday, 7 September 2022 at 20:23:03 UTC, Injeckt wrote: Convert it to D: extern(C) const(char)* inet_ntop(int af, const(void)* src, char* dst, socklen_t size); Win32 API functions need to be `extern(Windows)`. You probably also need: alias socklen_t = ...; https://github.com/dlang/dmd/blob/master/druntime/src/core/sys/windows/winsock2.d#L17 `alias socklen_t = int` It doesn't work. "Reference to an unresolved external symbol _inet_ntop". That's a linker error. You need to link with `ws2_32.lib`.
Re: How to link a msvcr120.dll in an inverse recursive way after a Windows .exe binary deployment
On Tuesday, 6 September 2022 at 04:36:55 UTC, ShadoLight wrote: True. In that case just distribute the DLL (taken from the DMD bin folder) alongside the HelloWorld EXE so that both reside in the same folder on the target computer. The proper way to do this is to ship the correct version of the Visual C++ redistributable installer and run it as part of the application install process: https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170
Re: This code completely breaks the compiler:
On Friday, 19 August 2022 at 04:25:25 UTC, Ruby The Roobster wrote: So that's why it compiled. Still, I believe that stuff like this ought to be detected at compile time, as supposed to in a unittest or, if someone forgot to write the tests, in production. If the template is never instantiated, it never makes it into the executable. It doesn't matter if it's in production or not, and has nothing to do with tests. It doesn't exist. How could the compiler catch any problems if it has no idea what `Mtypes` is? This is true for any template parameter. Consider this: ```d import std.stdio; T derp(T)(T val) { val += 10; return val; } void main() { writeln("Hello D"); } ``` `derp` obviously isn't going to work with every type. But this code compiles because `derp` is never instantiated. The compiler can't check if the code in `derp` is valid because it has no idea what `T` might be. If it's `int`, then no problem. If it's `string` then no way: ```d void main() { writeln(derp!string("No way")); } ``` Now you'll get this: ``` onlineapp.d(4): Error: slice `val` is not mutable onlineapp.d(10): Error: template instance `onlineapp.derp!string` error instantiating ```
Re: char* pointers between C and D
On Monday, 25 July 2022 at 09:04:29 UTC, pascal111 wrote: I have small C program that uses a pointer to change the start address of a string, and when I tried to do the same code but with D, the D code printed the address of the string after I increased it one step instead of printing the string the pointer pointing to. Is there a difference between "char *" pointers between C and D. No, no difference. Pointers are the same in both languages. What's different is the behavior of `%s` in `writeln` vs `printf`. See the documentation on format strings at: https://dlang.org/phobos/std_format.html Essentially, `%s` tells the formatter to output something appropriate for the given type. For an actual D string, you see the text. For an integral or floating point type, you see the number. For a pointer, you see the the address. And so on. Do in your case, to get `writefln` to print the text instead of the pointer address, you could import `std.string` and use `fromStringz`:`fromStringz(p)`. This will give you a D string without allocating any memory. Basically an immutable slice of the memory pointed at by `p`. That's fine for this use case, but if you wanted to hang on to the string beyond the lifetime of the pointer, you'd have to use `std.conv.to` instead (e.g., `to!string(p)`).
Re: dlang bug - accessing module variable from method segfaults only when using module reference directly
On Friday, 1 July 2022 at 13:44:20 UTC, Chris Katko wrote: It appears module access to a class is broken until the constructor finishes. No, it has nothing to do with the module. It's the reference itself. Until the constructor returns, the reference through which you're constructing the instance is null. It doesn't matter if it's at module scope, function scope, or wherever. If the constructor fails to complete (segfault, thrown exception, assertion failure, etc.), then the reference remains null. The reference is not the *instance*. It's a pointer to the instance. The instance is valid when the constructor is called, because the `this` reference has to be valid. Think of it in terms of a normal function call: ```D T newT() { T t = allocT(); t.construct(t); return t; } T g = newT(); ``` If `t.construct` throws or crashes, then `return t` is never executed, and `g` is never initialized.
Re: dlang bug - accessing module variable from method segfaults only when using module reference directly
On Friday, 1 July 2022 at 13:20:15 UTC, Mike Parker wrote: r. And that also looks like the source of your original segfault. You've got a circular reference going on in the constructors. In other words, you're constructing a global world instance, which in turn constructs an elf instance, which in turn accesses the global world reference whose constructor hasn't yet completed, so the global world reference is still null. Here's what it looks like in code: ```d import std.stdio : writeln; class Foo { Bar b; this() { b = new Bar; } void sayMyName() { writeln("I am Foo."); } } class Bar { this() { f.sayMyName(); } } Foo f; void main() { f = new Foo; } ```
Re: dlang bug - accessing module variable from method segfaults only when using module reference directly
On Friday, 1 July 2022 at 13:01:30 UTC, Chris Katko wrote: Forgot the last line. That's important because world MUST exist by time elf is called... because world... created and called elf. So it's not a memory issue, but some sort of linkage issue. world is null because the constructor didn't complete. The segfault happens inside its constructor. And that also looks like the source of your original segfault. You've got a circular reference going on in the constructors. In other words, you're constructing a global world instance, which in turn constructs an elf instance, which in turn accesses the global world reference whose constructor hasn't yet completed, so the global world reference is still null. If the objects world is constructing absolutely need to access it, then you could: 1. Initialize world with a do-nothing destructor, then call a `setup` method on it to do what its constructor currently is doing; 2. Pass `this` along to all the constructors that need it from inside the world constructor.
Re: Static Initialization of Structs syntax
On Wednesday, 22 June 2022 at 11:19:59 UTC, Antonio wrote: I see now: DIP 1033 will solve this (i.e., using named arguments in struct constructor... similar to how dart/flutter works) That would be DIP 1030: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1030.md Max Haughton was working on an implementation of it, but ran into trouble with template parameters, IIRC.
Re: Convering strings containing number
On Wednesday, 15 June 2022 at 04:26:44 UTC, Salih Dincer wrote: Hi, I've been interested in conversion possibilities for a while. I tried to convert a string containing numbers but with no success in single digits. The only solution I found is to subtract 48 from the result: ```d import std; void main() { string str = "abc123"; str[3..$].to!int.writeln; // 123 auto bar = str[3].to!int; assert(bar == 49); // 49 is value for ASCII. writeln(bar - 48); // 1 } ``` By indexing `str`, you're getting a `char`. So `to` is operating on that rather than on a string. Slicing will give you what you want, since then you'd have a `"1"` rather than a `'1'`: ```d str[3..4].to!int; ```
Re: ImportC: unresolved external symbol
On Tuesday, 14 June 2022 at 14:32:50 UTC, ryuukk_ wrote: ``` nk.obj : error LNK2019: unresolved external symbol test referenced in function _Dmain ``` Am i missing something important? (that is a dub project, created with: dub init) DMD: v2.100.0-dirty This works from the command line: ``` dmd -m64 app.d nk.c ``` It's possible dub isn't passing the C file to the compiler. Assuming everything's configured properly (e.g., both files are in the same source directory, or the paths are properly set if they aren't), you should do a verbose build and see what the compiler command line looks like.
Re: Can I create a package with friendly modules
On Sunday, 12 June 2022 at 23:29:29 UTC, forkit wrote: I don't get it. How does this enable one module to access the private parts of another module? It doesn't. But what you were describing in your post is package-level access. By keeping it the cross-module access in a subpackage, package is "private" to that subpackage. Isn't 'private' *always* private to the module? Yes, which is why it doesn't allow cross-module access. The idea I had, was to be able to spread a 'module' over more than one file - for the purpose of encapsulating this and that in different physical files, while *still* protecting the 'private is private to the module' concept. You can't spread modules across multiple files. But if D has a one-to-one mapping between a module and a file, and if private is always private to the one module, then this could never work. Not with private. But what I described is the same effect.
Re: Can I create a package with friendly modules
On Sunday, 12 June 2022 at 05:05:46 UTC, forkit wrote: Is it possible to create a package.d, consisting of (for example), two modules, where each module can access private declarations within each other. In essence, declaring 'a module level friendship', or a kind of 'extended module' if you want. I might still want to add another module to the package, that is NOT part of that friendship between those other two modules, but is otherwise related to the solution. - packagename -- package.d -- futuremodule.d --- subpackagename friend1.d friend2.d ``` // friend1.d module packagename.subpackagename.friend1; package void doSomethingFriendly(); /// // friend2.d module packagename.subpackagename.friend2; import packagename.subpackagename.friend1; void doSomething() { doSomethingFriendly(); } /// // package.d module packagename; public import packagename.subpackagename.friend1, packagename.subpackagename.friend2, packagename.futuremodule; ```
Re: Why allow initializers of non-static members that allocate?
On Saturday, 11 June 2022 at 10:37:30 UTC, Bastiaan Veelo wrote: So that’s why I used “why” in the title of this thread, which I haven’t seen an answer to yet. What is the practical case where that warning would be annoying? When would you actually want this behaviour? After actually stopping to think about it (my earlier responses were reflexive), I agree with your initial assessment that it should be an error. It really only makes sense to allow the dynamic allocation if the fields are immutable and, in the case of arrays, the initializer is a literal.
Re: Why allow initializers of non-static members that allocate?
On Saturday, 11 June 2022 at 01:14:06 UTC, matheus wrote: So, in the case of "int[] arr = new int[](5)", an array of length 5 of type int will be instantiated and its address will be shared among whoever instantiates "S" and be pointed and accessed through arr. In the second case, "int[2] arr2", 2 consecutive integer spaces in memory will be allocate independently for each "instantiation" of "S", so different address. I never saw this before (I mean I never wrote the first case), I'm used to the "int[2] arr2;" way of declaring it, but if I had looked this code without knowing this, I'd be certain that s1.arr and s2.arr would have different addresses. That's because static arrays are allocated as part of the instance: ```d struct Foo { int[] dyn; } struct Bar { int[10] stat; } assert(Foo.sizeof == 16); assert(Bar.sizeof == 40); ``` This is a bit weird (At least for a newbie like me), I really think the compiler should emit an warning about this. At it's core this is just a matter of knowing how two specific language features behave (allocation of static vs. dynamic arrays coupled with member field initialization). If you aren't aware of it and it bites you, then you learn about it and you know it. So would you then really want a warning every time you initialize a static array field? People getting bit by `new` in field initialization often enough that I think a warning would be helpful. But any such warnings need to be enabled by default to be useful, and must have an off switch for people who don't need them. So the question in each case would be, where's the line between helpful and annoying? The compiler should be as helpful as it can, but it has to be helpful without getting in the way. There's a significant amount of learning by trial and error in any programming language. So I think there has to be a distinction between things like "easy to do by accident even when you know the deal" and "once you learn it, you're unlikely to do it again".
Re: Why allow initializers of non-static members that allocate?
On Friday, 10 June 2022 at 14:56:24 UTC, Steven Schveighoffer wrote: Discovered circa 2009: https://issues.dlang.org/show_bug.cgi?id=2947 It should be illegal to declare a field this way that has mutable references without being `shared`. End of story. -Steve The docs do say that: The default initializers may not contain references to mutable data.
Re: Why allow initializers of non-static members that allocate?
On Friday, 10 June 2022 at 07:46:36 UTC, Mike Parker wrote: I think this is a case where having a warning that's on by default, and which can be explicitly disabled, is useful. "Blah blah .init blah blah. See link-to-something-in-docs. Is this what you intended?" And it *is* documented: Struct fields are by default initialized to whatever the Initializer for the field is, and if none is supplied, to the default initializer for the field's type. The default initializers are evaluated at compile time. https://dlang.org/spec/struct.html#default_struct_init
Re: Why allow initializers of non-static members that allocate?
On Friday, 10 June 2022 at 07:35:17 UTC, Bastiaan Veelo wrote: Is there a use case where this makes sense? I would have much appreciated the compiler slapping me on the fingers, but it doesn't. I understand that it is safe and that the compiler can allow this, but why would anyone want that? D-scanner does not check for this either. Any initialization of a member field is overriding the field's `.init` value for the type. If a dynamic allocation set a different value per instance, then you'd have inconsistent behavior with, e.g., `int a = 5`. I think a helpful error message would be: "Error: The initializer `A(5)` allocates memory that is shared among all instances of `S`. If you want that, make `S.a` `static`." I understand that it's not something that people expect, but making it an error can't be the answer. And making it a static field is not the same thing. I think this is a case where having a warning that's on by default, and which can be explicitly disabled, is useful. "Blah blah .init blah blah. See link-to-something-in-docs. Is this what you intended?"
Re: C-like static array size inference - how?
On Wednesday, 8 June 2022 at 00:43:24 UTC, Ali Çehreli wrote: Do I remember correctly that there were syntax proposals that used $ or _? int[$] arr = [ 1, 2 ]; int[_] arr = [ 1, 2 ]; But I can't find past discussions about that. https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1039.md Links to the discussion and feedback threads are in the review summary. The author withdrew the DIP, so anyone who would like to pick it up again is free to do so.
Re: dlang compilers & licenses.
On Saturday, 4 June 2022 at 14:13:08 UTC, Alain De Vos wrote: Do DMD , GDC , LDC have the same or different licenses in use ? DMD https://github.com/dlang/dmd/blob/master/LICENSE.txt LDC https://github.com/ldc-developers/ldc/blob/master/LICENSE GDC https://github.com/D-Programming-GDC/gcc/blob/ci/mainline/COPYING3 https://github.com/D-Programming-GDC/gcc/blob/ci/mainline/COPYING.RUNTIME
Re: Dynamic Arrays Capacity
On Thursday, 2 June 2022 at 08:24:51 UTC, Mike Parker wrote: And so, `&ts[0]` is the same as `&(*ts.ptr + 0)`, or simply `ts.ptr`. That should be the same as `&(*(ts.ptr + 0))`!
Re: Dynamic Arrays Capacity
On Thursday, 2 June 2022 at 08:14:40 UTC, Mike Parker wrote: More specifically, it points to the starting address of the allocated block of memory. I posted too soon. Given an instance `ts` of type `T[]`, array accesses essentially are this: ```d ts[0] == *(ts.ptr + 0); ts[1] == *(ts.ptr + 1); ts[2] == *(ts.ptr + 2); ``` Since the size of `T` is known, each addition to the pointer adds `N * T.sizeof` bytes. If you converted it to a `ubyte` array, you'd need to handle that yourself. And so, `&ts[0]` is the same as `&(*ts.ptr + 0)`, or simply `ts.ptr`.
Re: Dynamic Arrays Capacity
On Thursday, 2 June 2022 at 05:04:03 UTC, Salih Dincer wrote: Hi, Do I misunderstand? A dynamic array is allocated memory according to the `nextpow2()` algorithm(-1 lapse); strings, on the other hand, don't behave like this... ```d string str = "0123456789ABCDEF"; char[] chr = str.dup; assert(str.length == 16); assert(str.capacity == 0); import std.math: thus = nextPow2; //.algebraic assert(chr.capacity == thus(str.length) - 1); assert(chr.capacity == 31); You've initialized `str` with a string literal. No memory is allocated for these from the GC. They're stored in the binary, meaning they're loaded into memory from disk by the OS. So `str.ptr` points to a static memory location that's a fixed size, hence no extra capacity. `chr` is allocated from the GC using whatever algorithm is implemented in the runtime. That it happens to be any given algorithm is an implementation detail that could change in any release. ``` Also, `.ptr` keeps the address of the most recent first element, right? More specifically, it points to the starting address of the allocated block of memory.
Re: Odd construct idea. Splitting arguments inside a parameter list.
On Monday, 23 May 2022 at 08:34:21 UTC, Chris Katko wrote: D I'm curious if you can pass a struct of values (a 'tuple'?) with the right subfields, as if those fields occupied a function signature. (As I write this and try to explain it, it probably sounds impossible.) Right now you can use `.tupleof`: ```d myFunction(taco, p.tupleof, burrito); ```
Re: template? mixin? template mixins? for modifying a struct setup
On Friday, 20 May 2022 at 14:54:31 UTC, Christopher Katko wrote: So wait, that means if I have a module with extra stuff like D colors.d auto red = // grey and then in my other file D auto white = grey(1.0); It won't use CTFE? Why is there a local module requirement? I'm not sure what you mean by "local module requirement". The static storage class means that a variable will be around for the lifetime of the program (or more specifically in D's case, the lifetime of the thread). Module-scope variables are static by default.
Re: UI Library
On Friday, 20 May 2022 at 07:05:21 UTC, Tejas wrote: Maybe gtkd? https://code.dlang.org/packages/gtk-d And some corresponding tutorials: https://gtkdcoding.com/
Re: template? mixin? template mixins? for modifying a struct setup
On Friday, 20 May 2022 at 00:12:44 UTC, Chris Katko wrote: Yeah that occurred to me as I was falling asleep. Though, do I have to a specify ```D static auto myColor = grey(0.5); ``` to ensure it's done at compile time? It's not the end of the world, but ideally, these are static / hardcoded values that can be used thousands of times a second. If the declarations are at module scope, `static` has no effect, and CTFE will be used for initialization.
Re: Question on shapes
On Tuesday, 17 May 2022 at 05:08:30 UTC, matheus wrote: In D there would be a better way to do such thing? Nothing really specific to D, but for one or two properties, you might just add them as function parameters with default values: ```d void draw(float scale = 1.0f); ``` If you have a number of them (scale, color, blend state, etc.), then you might add them as members of the `Shape` class. You could then expand on that with a single draw function in the `Shape` class that handles the actual drawing, and the subclasses would then call that internally after, e.g., setting up any vertex buffers or whatever specific to the shapes. ```d class Shape { private: float scale; RGBA color; DrawBuffer buffer; // some API-specific vertex buffer or whatever protected: void drawImpl() { // get the shape on screen } public: abstract void draw(); } class Circle { override void draw() { // set up buffer ... drawImpl(); } ``` Or you could have a `DrawProperties` struct independent of the `Shape` hierarchy that you can fill out and pass to every draw call. Or set global properties in the renderer and draw objects that have the same properties all at once. There are several ways to go about it.