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: vibe.db.postgresql: Example not working in Windows
On Friday, 14 April 2023 at 17:06:36 UTC, Vino wrote: I was just trying the new package vibe.db.postgresql and the example provided is not working, can some one provide me an working example. Step performed ``` dub init dub add vibe-d-postgresql copy the example program to source/app.d dub run ``` I would like to draw your attention to this point: ```d #!/usr/bin/env dub /+ dub.sdl: dependency "vibe-d" version="~>0.9.0" +/ void main() { import vibe.d; listenHTTP(":8080", (req, res) { res.writeBody("Hello, World: " ~ req.path); }); runApplication(); } ``` Do you have a working vibe app? SDB@79
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? As far as I know imGUI works with SFML. First, please appear a Japanese flag on your screen: https://forum.dlang.org/post/apledbmyzlxsdaaow...@forum.dlang.org SDB@79
Re: How to setup D with SFML? (using bindbc-sfml)
On Friday, 14 April 2023 at 12:26:25 UTC, Ki Rill wrote: Yay! That worked! Now I have a working example. Though it's strange that it does not work with shared libs. Good luck, I'm really happy for you... Ki Rill, wait a minute! Actually, i've been very happy for the D community. Because I really appreciate what you've done. You are an idealistic person and please stay that way. We can do more things. SDB@79
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? You need to make those depends on the same version somehow. From what I've looked. Luna maintains its own fork of bindbc-imgui. You're probably taking from another repository i.e: Not the one inochi creator uses. You'll need to clone https://github.com/Inochi2D/bindbc-imgui somewhere Then you'll need to look into your dub.selections.json to point "bindbc-imgui" to this folder.
Re: Unresolvable dependencies to package
so my question why am i'm getting this error and how do i fix this?
Unresolvable dependencies to package
I just added dub add inochi-creator then dub run but got the error: ``` Unresolvable dependencies to package bindbc-sdl: bindbc-imgui 0.7.0 depends on bindbc-sdl ~>0.21.4 inochi-creator 0.7.4 depends on bindbc-sdl ~>1.1.2 ``` the dub.json looks like this: ``` { "authors": [ "root" ], "copyright": "Copyright © 2023, root", "dependencies": { "inochi-creator": "~>0.7.4" }, "description": "A minimal D application.", "license": "proprietary", "name": "foo" } ```
Re: Memory leak issue between extern (c) and D function
On Friday, 14 April 2023 at 11:15:59 UTC, Guillaume Piolat wrote: On Friday, 14 April 2023 at 04:43:39 UTC, Paul Backus wrote: If you want the GC to clean up your memory, use `new` to allocate it instead of `malloc`. Like this: ```d mystruct* getmystruct() { return new mystruct; } ``` That won't work because the C++ programm calling the D dynlib will not have its stack scanned, leading to that object being reclaimed early. OP could add another extern(C) D function to free the allocated object. Or another extern(C) D function to call GC.addRoot Thank you for your response. I added something like this in extern (c) function. ``` __delete(output); ``` When i debugged, it shows null to output after executing above line. however the memory is not releasing. Thank you.
vibe.db.postgresql: Example not working in Windows
Hi All, I was just trying the new package vibe.db.postgresql and the example provided is not working, can some one provide me an working example. Step performed ``` dub init dub add vibe-d-postgresql copy the example program to source/app.d dub run ``` Error ``` source\app.d(3,8): Error: unable to read module `d` source\app.d(3,8):Expected 'vibe\d.d' or 'vibe\d\package.d' in one of the following import paths: import path[0] = source import path[1] = C:\Users\vtest\AppData\Local\dub\packages\vibe-d-postgresql-3.1.3\vibe-d-postgresql\source import path[2] = C:\Users\vtest\AppData\Local\dub\packages\dpq2-1.1.5\dpq2\src import path[3] = C:\Users\vtest\AppData\Local\dub\packages\derelict-pq-4.0.0\derelict-pq\source import path[4] = C:\Users\vtest\AppData\Local\dub\packages\money-3.0.2\money\source import path[5] = C:\Users\vtest\AppData\Local\dub\packages\vibe-d-0.9.6\vibe-d\data import path[6] = C:\Users\vtest\AppData\Local\dub\packages\vibe-d-0.9.6\vibe-d\utils import path[7] = C:\Users\vtest\AppData\Local\dub\packages\stdx-allocator-2.77.5\stdx-allocator\source import path[8] = C:\Users\vtest\AppData\Local\dub\packages\vibe-core-2.2.0\vibe-core\source import path[9] = C:\Users\vtest\AppData\Local\dub\packages\eventcore-0.9.25\eventcore\source import path[10] = C:\Users\vtest\AppData\Local\dub\packages\taggedalgebraic-0.11.22\taggedalgebraic\source import path[11] = C:\D\dmd2\windows\bin64\..\..\src\phobos import path[12] = C:\D\dmd2\windows\bin64\..\..\src\druntime\import Error C:\D\dmd2\windows\bin64\dmd.exe failed with exit code 1. ``` From, Vino.B
Re: How to use @safe when a C library integration needed
On Friday, 14 April 2023 at 14:10:41 UTC, Leonardo wrote: Thanks. But this works only to one function per time. Is there any way to do this to an imported library at all? something like `@trusted import library` No, there isn't. C is an unsafe language, so if you want to call C from `@safe` code, you have to do the work to make sure that each individual call is `@safe`. If you are calling the same C function many times from `@safe` code, you can write a `@trusted` D wrapper function to avoid repeating the safety checks at every call site. For example, here's a `@trusted` wrapper for the standard C library function `puts`: ```d import core.stdc.stdio: puts; import std.exception: enforce; @trusted void safePuts(const(char)[] s) { // To safely call puts, we must pass it a valid C string // To be a valid C string, s must be non-empty and NUL-terminated enforce(s.length > 0, "An empty string is not a C string"); enforce(s[$-1] == '\0', "A C string must be NUL-terminated"); // If the checks above have passed, this call is safe puts(&s[0]); } ```
Re: How to use @safe when a C library integration needed
On Monday, 23 January 2023 at 16:46:48 UTC, Dom DiSc wrote: On Monday, 23 January 2023 at 16:36:21 UTC, Leonardo wrote: Hello. How to use @safe when a C library integration needed? Everything need a system function... ```d @safe fn() { // lot of safe stuff () @trusted { // in this block[*] @system function like extern C can be called. // you need to make sure the API is used correct @assert(/*C_Fun is safe to be used with param1*/); @assert(/*C_Fun is safe to be used with param2*/); C_Fun(param1, param2); }(); // more safe stuff } ``` [*] in fact, this is a lambda function that is directly called, because real trusted blocks are not allowed (yet). Thanks. But this works only to one function per time. Is there any way to do this to an imported library at all? something like `@trusted import library`
Re: How to setup D with SFML? (using bindbc-sfml)
On Friday, 14 April 2023 at 02:33:18 UTC, Salih Dincer wrote: On Friday, 14 April 2023 at 00:28:53 UTC, Ki Rill wrote: ``` LINK : fatal error LNK1104: cannot open file 'libucrt.lib' Error: linker exited with status 1104 ``` Why does it require this library and where can I find it? Since this library is a component of the Microsoft C Runtime (CRT) library, you may need to install this library. To install the CRT library, follow these steps: * Download and install the latest version of Microsoft Visual Studio. * In the Visual Studio installer, install the "C++ Universal CRT" component under "Workloads > Desktop development with C++". * Restart the build and check if the error is resolved. **Source:** https://stackoverflow.com/questions/44763817/link-fatal-error-lnk1104-cannot-open-file-ucrt-lib SDB@79 Yay! That worked! Now I have a working example. Though it's strange that it does not work with shared libs.
Re: What do you think about using Chat GPT to create functions in D?
On Monday, 3 April 2023 at 23:38:52 UTC, Marcone wrote: What do you think about using Chat GPT to create functions in D? I asked Chat-GPT to create a function in D that was similar to the rsplit() function in Python. It returned this code to me: import std.algorithm; import std.array; import std.string; string[] rsplit(string input, string separator, size_t maxsplit = size_t.max) { auto splitter = splitter(input, separator, SplitterFlag.all); auto results = splitter.array; if (maxsplit < results.length - 1) results = results[results.length - maxsplit - 1 .. $]; return results; } Recently, it helped me figure out an OpenGL task using d. This is the code it suggests after I provide some details to it about the case and the error I get: ```d Slice!(RCI!ubyte, 3LU, Contiguous) plot2imslice() @nogc nothrow { import mir.rc; Slice!(RCI!ubyte, 3LU, Contiguous) imgslice = rcslice!ubyte([height, width, 3], 0); glfwMakeContextCurrent(_glfwWindow); // create and bind framebuffer GLuint fbo; glGenFramebuffers(1, &fbo); glBindFramebuffer(GL_FRAMEBUFFER, fbo); // create and bind texture GLuint texture; glGenTextures(1, &texture); glBindTexture(GL_TEXTURE_2D, texture); glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, width, height, 0, GL_RGB, GL_UNSIGNED_BYTE, null); glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, texture, 0); // render scene to framebuffer glBindFramebuffer(GL_FRAMEBUFFER, fbo); // render your scene here // read pixel data from framebuffer glReadPixels(0, 0, width, height, GL_RGB, GL_UNSIGNED_BYTE, imgslice.ptr); // flip image vertically for (size_t y = 0; y < height / 2; y++) { for (size_t x = 0; x < width; x++) { // swap rows swap(imgslice[y][x], imgslice[height - y - 1][x]); } } // unbind framebuffer and cleanup glBindFramebuffer(GL_FRAMEBUFFER, 0); glDeleteTextures(1, &texture); glDeleteFramebuffers(1, &fbo); return imgslice; } ``` And this is the code after required modifications: ```d auto plot2imslice() @nogc nothrow { import mir.rc; Slice!(RCI!ubyte, 3LU, Contiguous) imgslice = rcslice!ubyte([height, width, 3], 0); glfwMakeContextCurrent(_glfwWindow); // create and bind framebuffer GLuint fbo; glGenFramebuffers(1, &fbo); glBindFramebuffer(GL_FRAMEBUFFER, fbo); // create and bind texture GLuint texture; glGenTextures(1, &texture); glBindTexture(GL_TEXTURE_2D, texture); glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, width, height, 0, GL_RGB, GL_UNSIGNED_BYTE, null); glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, texture, 0); // render scene to framebuffer glBindFramebuffer(GL_FRAMEBUFFER, fbo); // render scene here render(); // read pixel data from framebuffer glReadPixels(0, 0, width, height, GL_RGB, GL_UNSIGNED_BYTE, imgslice.ptr); import mir.utility : swap; // flip image vertically to correct generated image foreach (y; 0..height / 2) { each!swap(imgslice[y], imgslice[height - y - 1]); } // unbind framebuffer and cleanup glBindFramebuffer(GL_FRAMEBUFFER, 0); glDeleteTextures(1, &texture); glDeleteFramebuffers(1, &fbo); return imgslice; } ``` This comment of chatGPT saved the day :) // render your scene here
Re: Memory leak issue between extern (c) and D function
On Friday, 14 April 2023 at 11:15:59 UTC, Guillaume Piolat wrote: OP could add another extern(C) D function to free the allocated object. Or another extern(C) D function to call GC.addRoot Or simpler, add that object to a list of object in D DLL __gshared list, then clear the list (or set individual reference to null) if you want to reclaim space.
Re: Returning a reference to be manipulated
On Friday, 14 April 2023 at 10:31:58 UTC, kdevel wrote: But in fact it is returned unless it is `return ref`. When using `return ref`, `return scope`, `scope` etc., you should be using the latest compiler and annotate functions you want checked with `@safe`. In previous versions, the compiler would often conflate `return ref` and `return scope`, and it was also inconsistent in whether it would do checks in `@safe`, `@system`, and even 'default/unannotated' functions. Now, it is more consistent, performing checks in `@safe` code only. I don't get it! Is there any legitimate use of returning a ref such that it outlives the matching argument's lifetime? If not: Isn't this `return ref` completely redundant? The annotation is needed because the compiler can't always figure out what you're doing with a `ref` parameter: ```D ref int mysteryFunc(ref int x) @safe; // external implementation ref int escape() @safe { int local; // allocated on stack frame, should not escape this function return mysteryFunc(local); // is this safe? } ``` Is this indeed `@safe`? It is, provided that `mysteryFunc` doesn't return its parameter `x`. It can be implemented like this for example: ```D ref int mysteryFunc(ref int x) @safe { x++; return *(new int); } ``` But it wouldn't be safe if `x` were returned, so the compiler must know about that when it happens, hence `return ref`: ```D ref int mysteryFunc(return ref int x) @safe { return x; } ``` Now the compiler can catch that `return mysteryFunc(local)` is unsafe. Note that if `mysteryFunc` is a template function, nested function, or returns `auto`, then the compiler infers attributes automatically, including `return ref`. Then you can still write it as `mysteryFunc(ref int x)` and it will automatically be treated as `return ref`.
Re: Memory leak issue between extern (c) and D function
On Friday, 14 April 2023 at 04:43:39 UTC, Paul Backus wrote: If you want the GC to clean up your memory, use `new` to allocate it instead of `malloc`. Like this: ```d mystruct* getmystruct() { return new mystruct; } ``` That won't work because the C++ programm calling the D dynlib will not have its stack scanned, leading to that object being reclaimed early. OP could add another extern(C) D function to free the allocated object. Or another extern(C) D function to call GC.addRoot
Re: Returning a reference to be manipulated
On Friday, 14 April 2023 at 09:42:14 UTC, Bastiaan Veelo wrote: [...] Up to dmd v2.100.2 I am warned/get an error during compilation: ``` $ dmd returnref2.d returnref2.d(3): Deprecation: returning `i` escapes a reference to parameter `i` returnref2.d(1):perhaps annotate the parameter with `return` $ dmd -dip1000 returnref2.d returnref2.d(3): Error: returning `i` escapes a reference to parameter `i` returnref2.d(1):perhaps annotate the parameter with `return` ``` With later dmd versions (up to including v2.102.2) the code compiles without complaints. Is this intended? I think this is intended. Adding `@safe:` on top makes the complaint come back (in dmd 2.102 it is deprecated, in 2.103 it is an error). What irritates me is that only with `return ref int` ``` ref int foo (return ref int i) { return i; } [...] ``` dmd complains: ``` returnref2.d(9): Error: returning `foo(i)` escapes a reference to local variable `i` ``` The documentation [1] says that a `ref` parameter may not be returned unless it is `return ref`. But in fact it is returned unless it is `return ref`. Probably i get/got the meaning of the English modal verb "may" wrong. The documentation also says that `return ref` parameters are used to ensure that the returned reference will not outlive the matching argument's lifetime. I don't get it! Is there any legitimate use of returning a ref such that it outlives the matching argument's lifetime? If not: Isn't this `return ref` completely redundant? [1] https://dlang.org/spec/function.html
Re: Returning a reference to be manipulated
On Friday, 14 April 2023 at 00:50:31 UTC, kdevel wrote: ``` ref int foo (ref int i) { return i; } ref int bar () { int i; return foo (i); } void main () { import std.stdio; auto i = bar; i.writeln; } ``` Up to dmd v2.100.2 I am warned/get an error during compilation: ``` $ dmd returnref2.d returnref2.d(3): Deprecation: returning `i` escapes a reference to parameter `i` returnref2.d(1):perhaps annotate the parameter with `return` $ dmd -dip1000 returnref2.d returnref2.d(3): Error: returning `i` escapes a reference to parameter `i` returnref2.d(1):perhaps annotate the parameter with `return` ``` With later dmd versions (up to including v2.102.2) the code compiles without complaints. Is this intended? I think this is intended. Adding `@safe:` on top makes the complaint come back (in dmd 2.102 it is deprecated, in 2.103 it is an error). -- Bastiaan.