Re: How can I tell D that function args are @nogc etc.
On Friday, 12 April 2024 at 15:08:50 UTC, Steven Schveighoffer
wrote:
On Friday, 12 April 2024 at 03:57:40 UTC, John Dougan wrote:
What is the procedure for bug reporting? I'm looking at the
issues tracker and have no clue how to drive the search to see
if this is already there.
https://issues.dlang.org
While entering the bug title, it does a fuzzy search for
existing open and closed issues.
The typical problem with issue/bug database searches is you have
to know the important discriminating keywords that projects
evolve over time. When you are new to a system, as I am with D,
you end up looking manually through a lot of possibles. Another
barrier to noobs that project long timers may not notice.
Any rate, it appears
https://issues.dlang.org/show_bug.cgi?id=22046 is the same issue.
And I'm not sure how to interpret it, as a noob I don't have
enough context. It appears to be deliberate and also afflicts var
declarations. Since 2014.
From my point of view, either it's still a bug and needs to be
written up in a best practices list with all the other long term
stuff you need to work around until it can be fixed (eg. "in
alias and var function declarations, put attributes as a suffix
because...", https://dlang.org/dstyle.html *might* be a place),
or it has aged in to become the effective intended behavior and
should be documented other places and have a compiler error or
warning ("@safe in prefix position in alias, is ignored"). Or of
course, it could get fixed but my experiences have shown me that
after 10 years that is low probability with most projects.
I'm not trying to be a dick here. I've managed projects and know
what unintentional dumb stuff can happen. But, at the moment, I'm
evaluating D for a project (porting 30,000 lines of very old C
with strict timing requirements) and I've got some time to build
impressions of system language candidates. There appears to be a
lot of talk from time to time over in General about luring new
people in to work with D, and this kind of issue is relevant.
-Steve
--john
Re: Best way to use large C library in D as of 2024
On Friday, 12 April 2024 at 18:36:13 UTC, Chris Piker wrote: On Saturday, 30 March 2024 at 07:11:49 UTC, Mike Parker wrote: 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. I would, but I'm just not a social media person. I pretty much only post online content here and at github.com. You may have the problem that D doesn't attract "very-online" personality types. I do mention D in work presentations, but those are not visible to the public. If you put your writeup in a markdown file on your Github account and then post a link in the announce group, others will post it to the D subreddit and elsewhere I'm sure.
Re: Best way to use large C library in D as of 2024
On Friday, 12 April 2024 at 18:45:21 UTC, Chris Piker wrote: Even though DMD can't compile some C code, that's pretty much a non-issue for me anyway. In my environment the servers are all Linux so "apt-get" (or equivalent) typically provides a pre-compiled dependency. Being able to list a package as a system dependency and then just call it from D with no interface code is a Big Freaking Deal! Compared to Python interfaces this is a huge improvement. It makes D an even better replacement for the mixed mode python + C development I was doing before switching to D for new projects. I agree that it's really good, but the issues I listed were just examples of the things I came across, and I know there are a decent number of other open issues for ImportC. What I'd prefer to avoid is having people try it out and concluding that it's not ready. Kind of like when I tried out Zig. Everyone was saying it's this great language but my trial was brief and I haven't been tempted to try it since. Header files are a different story. They really should "just work" based on my experience. Other things like compiling large libraries or translating C code to D should probably be more in the camp of "experience reports" posted on individual blogs, and they should talk about both the successes and the edge cases.
Re: Best way to use large C library in D as of 2024
On Monday, 1 April 2024 at 02:08:20 UTC, Lance Bachmeier wrote: On Saturday, 30 March 2024 at 05:01:32 UTC, harakim wrote: It works well if you only need to work with a header. There are still a few rough edges that get in the way if you're compiling the full C sources (I filed bugs for all of them): - Can't handle va_arg - Can't cast to a pointer of a struct that's typedef'd - Can't use complex numbers with the ternary operator ... Once these final odds and ends are working, we have a killer language feature. Even though DMD can't compile some C code, that's pretty much a non-issue for me anyway. In my environment the servers are all Linux so "apt-get" (or equivalent) typically provides a pre-compiled dependency. Being able to list a package as a system dependency and then just call it from D with no interface code is a Big Freaking Deal! Compared to Python interfaces this is a huge improvement. It makes D an even better replacement for the mixed mode python + C development I was doing before switching to D for new projects.
Re: Best way to use large C library in D as of 2024
On Saturday, 30 March 2024 at 07:11:49 UTC, Mike Parker wrote: 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. I would, but I'm just not a social media person. I pretty much only post online content here and at github.com. You may have the problem that D doesn't attract "very-online" personality types. I do mention D in work presentations, but those are not visible to the public.
Re: "Error: `TypeInfo` cannot be used with -betterC" on a CTFE function
On Friday, 12 April 2024 at 00:04:48 UTC, Liam McGillivray wrote:
Here's what I wanted to do.
In the library I'm working on, there are various declarations
for functions defined in an external C library following the
line `extern (C) @nogc nothrow:`. Here are some examples of
such declarations which have a `const(char)*` parameter:
```d
void InitWindow(int width, int height, const(char)* title);
void SetWindowTitle(const(char)* title);
Shader LoadShader(const(char)* vsFileName, const(char)*
fsFileName);
```
I wanted to generate definitions of overloads of these
functions using strings as parameters instead of
`const(char)*`. For the `InitWindow` function shown above, the
overload should be defined like this:
```d
void InitWindow(int width, int height, ref string title) {
InitWindow(width, height, cast(const(char)*)title);
}
```
This is invalid, a string may not be zero-terminated. You can't
just cast.
or alternatively, like the following:
```d
void InitWindow(int width, int height, string title) {
InitWindow(width, height, title.toStringz);
}
```
This will allocate from the GC.
So there are a few things to consider:
1. Is the string *transiently used*. That is, does the function
just quickly use the string and never refers to it again? Given
that this is raylib, the source is pretty readable, so you should
be able to figure this out.
2. If 1 is false, will it be saved in memory that is scannable by
the GC? This is one of the most pernicious issues with using C
libraries from D. In this case, you will need to either allocate
the memory with C `malloc` or pin the GC memory.
For transiently used strings, I would point you at the function
[`tempCString`](https://github.com/dlang/phobos/blob/0663564600edb3cce6e0925599ebe8a6da8c20fd/std/internal/cstring.d#L77), which allocates a temporary C string using malloc or a stack buffer, and then frees it when done with it.
The obvious problem in all this is to avoid accepting string
literals (which are magic and automatically convert to const char
*). This is currently impossible with function overloading, and
so you need a separate function name, or put them in a different
module.
-Steve
Re: How can I tell D that function args are @nogc etc.
On Friday, 12 April 2024 at 03:57:40 UTC, John Dougan wrote: What is the procedure for bug reporting? I'm looking at the issues tracker and have no clue how to drive the search to see if this is already there. https://issues.dlang.org While entering the bug title, it does a fuzzy search for existing open and closed issues. -Steve
