Re: How can I tell D that function args are @nogc etc.

2024-04-12 Thread John Dougan via Digitalmars-d-learn
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

2024-04-12 Thread Lance Bachmeier via Digitalmars-d-learn

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

2024-04-12 Thread Lance Bachmeier via Digitalmars-d-learn

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

2024-04-12 Thread Chris Piker via Digitalmars-d-learn

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

2024-04-12 Thread Chris Piker via Digitalmars-d-learn

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

2024-04-12 Thread Steven Schveighoffer via Digitalmars-d-learn

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.

2024-04-12 Thread Steven Schveighoffer via Digitalmars-d-learn

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