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([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, );
glBindFramebuffer(GL_FRAMEBUFFER, fbo);
// create and bind texture
GLuint texture;
glGenTextures(1, );
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, );
glDeleteFramebuffers(1, );
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, );
glBindFramebuffer(GL_FRAMEBUFFER, fbo);
// create and bind texture
GLuint texture;
glGenTextures(1, );
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, );
glDeleteFramebuffers(1, );
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.
