Re: std.format doesn't want to work
On Saturday, 16 October 2021 at 22:47:09 UTC, solidstate1991
wrote:
When I make this call
```
format(" %3.3f"w, avgFPS);
```
my program immediately crashes with an access violation error.
The debugger out is different between x86 and x86-64.
I've made all sanity checks, so I need some other suggestions.
what is the type of avgFPS?
Re: Can we use "ImportC" used yet?
On Sunday, 17 October 2021 at 04:45:26 UTC, data pulverizer wrote:
I ended up defining `typedef struct __float128__ {unsigned long
long x[2];} __float128__;` and doing a find and replace for
`__float128` which is totally overkill since I won't be using
it and according to the documentation, the D compiler doesn't
support 128-bit floats yet though it has reserved keywords for
it.
Many thanks.
Decided the best idea to just to comment it out altogether.
Re: Can we use "ImportC" used yet?
I ended up defining `typedef struct __float128__ {unsigned long
long x[2];} __float128__;` and doing a find and replace for
`__float128` which is totally overkill since I won't be using it
and according to the documentation, the D compiler doesn't
support 128-bit floats yet though it has reserved keywords for it.
Many thanks.
Re: Obtaining type and value of a variable named in another variable
On Sunday, 17 October 2021 at 02:42:54 UTC, Tejas wrote:
Doesn't solve the compile-time only problem though :(
The only solution I can think of is something with `variant`s,
but it'll be messy.
Well, the fundamental issue is that in a language like D that
compiles to machine code, variable names only exist at compile
time. At runtime, the only thing you have is memory addresses
(pointers).
If you want to look something up by name at runtime, you will
have to use a data structure like an associative array:
```d
void main()
{
int[string] vars = ["fooVar": 4];
string strVar = "fooVar";
writeln(typeof(vars[strVar]).stringof);
writeln(vars[strVar]);
}
```
Of course, in this example, the associative array can only store
`int`s. If you want to store multiple types of data, you will
need to use a data type that supports runtime polymorphism, like
a class, a sum type, or a variant.
Re: std.format doesn't want to work
On Saturday, 16 October 2021 at 22:47:09 UTC, solidstate1991
wrote:
When I make this call
```
format(" %3.3f"w, avgFPS);
```
my program immediately crashes with an access violation error.
The debugger out is different between x86 and x86-64.
I've made all sanity checks, so I need some other suggestions.
I think it would be helpful to know what type avgFPS is and what
you do with the output of format(). Access violation is mostly an
access to a null pointer.
Re: Can we use "ImportC" used yet?
On Sunday, 17 October 2021 at 03:38:43 UTC, data pulverizer wrote: 2. Run the commands: ``` gcc -E -P test_og.c > test_c.c dmd test.d test_c.c && ./test ``` which works. Now I've tried the same thing with library `fftw3` and getting: ``` Error: undefined identifier `__float128` ``` Which I guess I have to define somehow in the original c directives? Yep, you have to look at test_c.c and fine the line with that error and decide what to do about it.
Re: Can we use "ImportC" used yet?
Okay I'm definitely trying to use `importC` rather than the regular `extern(C)` way. I can see where I went wrong. The steps for importC for header files are: 1. Prepend the following directives to `test_og.c` or whatever your interface c script is: ``` #define __restrict restrict #define __asm__ asm #define __extension__ #define __inline #define __builtin_bswap16 #define __builtin_bswap32 #define __builtin_bswap64 ``` 2. Run the commands: ``` gcc -E -P test_og.c > test_c.c dmd test.d test_c.c && ./test ``` which works. Now I've tried the same thing with library `fftw3` and getting: ``` Error: undefined identifier `__float128` ``` Which I guess I have to define somehow in the original c directives?
Re: Can we use "ImportC" used yet?
On Sunday, 17 October 2021 at 02:45:03 UTC, data pulverizer wrote:
While we're on this subject, I've been having similar issues
now tried compiling @rempas's example file with:
```
gcc test_og.c -c -o test_og.o
dmd test.d test_og.o
```
and get the response:
```
test_og.c(1): Error: identifier or `(` expected
test_og.c(6): Error: identifier or `(` expected
```
You're not doing this with the files in the thread, or you'd get
```
test.d(1): Error: module `test_c` is in file 'test_c.d' which
cannot be read
```
as test.d is still importing test_c.c, a different file from
test_og.o
I get your error if the original test_og.c is used but test.d is
modified to import test_og.c:
```d
import test_og;
void main() {
hello_world();
}
```
In this case, your compilation to test_og.o doesn't matter; D is
still trying to import test_og.c, and since that file has CPP
`#include` directives which importC doesn't support, it's
erroring out on those.
To link in a C object rather than use importC, you'd need this
test.d:
```d
extern (C) void hello_world();
void main() {
hello_world();
}
```
With which:
```
$ gcc test_og.c -c -o test_og.o
$ dmd test.d test_og.o
$ ./test
Hello world!!!
```
Re: Can we use "ImportC" used yet?
On Saturday, 16 October 2021 at 08:19:41 UTC, rempas wrote: On Saturday, 16 October 2021 at 07:09:16 UTC, jfondren wrote: If I understand correctly you mean compile the original file with gcc (`gcc test_og.c -o test_og.o`) and then link it with DMD (`dmd test.d test_og.o`)? ... While we're on this subject, I've been having similar issues now tried compiling @rempas's example file with: ``` gcc test_og.c -c -o test_og.o dmd test.d test_og.o ``` and get the response: ``` test_og.c(1): Error: identifier or `(` expected test_og.c(6): Error: identifier or `(` expected ``` Platform is Ubuntu 20.04 gcc version 9.30 and dmd version v2.098.0. At first I tried compiling a script with fftw3 and thought it was something wrong with my script but when I tried it with your example, the same thing happened.
Re: Obtaining type and value of a variable named in another variable
On Sunday, 17 October 2021 at 02:31:04 UTC, Paul Backus wrote:
On Saturday, 16 October 2021 at 23:07:22 UTC, DLearner wrote:
```d
void main() {
import std.stdio;
int fooVar = 4;
string strVar;
strVar = "fooVar";
writeln(typeof(mixin(strVar)));
writeln(mixin(strVar));
}
```
Failed with 2x "Error: variable `strVar` cannot be read at
compile time".
You can fix this by making `strVar` a [manifest constant][1]:
```d
enum strVar = "fooVar";
writeln(typeof(mixin(strVar)).stringof);
writeln(mixin(strVar));
```
[1]: https://dlang.org/spec/enum.html#manifest_constants
Doesn't solve the compile-time only problem though :(
The only solution I can think of is something with `variant`s,
but it'll be messy.
Re: Obtaining type and value of a variable named in another variable
On Saturday, 16 October 2021 at 23:07:22 UTC, DLearner wrote:
```d
void main() {
import std.stdio;
int fooVar = 4;
string strVar;
strVar = "fooVar";
writeln(typeof(mixin(strVar)));
writeln(mixin(strVar));
}
```
Failed with 2x "Error: variable `strVar` cannot be read at
compile time".
You can fix this by making `strVar` a [manifest constant][1]:
```d
enum strVar = "fooVar";
writeln(typeof(mixin(strVar)).stringof);
writeln(mixin(strVar));
```
[1]: https://dlang.org/spec/enum.html#manifest_constants
Re: Obtaining type and value of a variable named in another variable
On Saturday, 16 October 2021 at 23:07:22 UTC, DLearner wrote:
On Saturday, 16 October 2021 at 19:29:59 UTC, Dennis wrote:
On Saturday, 16 October 2021 at 19:28:04 UTC, DLearner wrote:
How does one obtain from strVar:
1. The type of fooVar;
`typeof(mixin(strVar))`
2. The value of fooVar?
`mixin(strVar)`
```
void main() {
import std.stdio;
int fooVar = 4;
string strVar;
strVar = "fooVar";
writeln(typeof(mixin(strVar)));
writeln(mixin(strVar));
}
```
Failed with 2x "Error: variable `strVar` cannot be read at
compile time".
I don't know how to do it with a string, but are you willing to
do it with an `alias` instead? You won't be able to change it
later, but then I don't know of any other way.
```d
void main() {
import std.stdio;
int fooVar = 4;
//string strVar;
alias strVar = fooVar;
writeln(typeid(strVar));
writeln(strVar);
}
```
Re: Obtaining type and value of a variable named in another variable
On Saturday, 16 October 2021 at 19:29:59 UTC, Dennis wrote:
On Saturday, 16 October 2021 at 19:28:04 UTC, DLearner wrote:
How does one obtain from strVar:
1. The type of fooVar;
`typeof(mixin(strVar))`
2. The value of fooVar?
`mixin(strVar)`
```
void main() {
import std.stdio;
int fooVar = 4;
string strVar;
strVar = "fooVar";
writeln(typeof(mixin(strVar)));
writeln(mixin(strVar));
}
```
Failed with 2x "Error: variable `strVar` cannot be read at
compile time".
std.format doesn't want to work
When I make this call
```
format(" %3.3f"w, avgFPS);
```
my program immediately crashes with an access violation error.
The debugger out is different between x86 and x86-64.
I've made all sanity checks, so I need some other suggestions.
Re: Parameter forwarding
On Friday, 15 October 2021 at 17:22:52 UTC, Tejas wrote: On Friday, 15 October 2021 at 06:52:41 UTC, Kostiantyn Tokar wrote: On Thursday, 14 October 2021 at 17:53:57 UTC, Tejas wrote: Maybe DIP 1040 will automatically solve that? last use of objects that is a copy gets elided into a move That is what it states, so maybe this one time, the problem will go away just by waiting? It would be great, but still, if I understand correctly, it is not perfect solution for lvalue arguments. Consider, e.g., `Tuple` construction from an lvalue. With this DIP and current state of constructor it will be 1 copy (from argument to constructor's parameter) and 1 blit (from parameter to the field). With `auto ref` and forwarding it would be 1 copy from parameter to the field and no blits. Forwarding saves one blit per indirection, i.e., for `tuple` it would be 2 blits vs. 0. Yeah blitting as a concept will go away from D(will only stay for backwards-compatibility) Copy constructors already made blits obselete, move constructors will remove the need for post-blits and finish the job and the second case that you talked about will become the default Now I get it. If this DIP will be accepted, I just have to provide move constructor/assignment for my types and forwarding would work. It sounds really great. If so, there is no need to rewrite half of Phobos to support forwarding. And it even covers last use of a field of an aggregate! Hope it will be accepted. Paul, Tejas, thank you for answers.
Re: Obtaining type and value of a variable named in another variable
On Saturday, 16 October 2021 at 19:28:04 UTC, DLearner wrote: How does one obtain from strVar: 1. The type of fooVar; `typeof(mixin(strVar))` 2. The value of fooVar? `mixin(strVar)`
Obtaining type and value of a variable named in another variable
Hi Suppose string variable strVar has value "fooVar". fooVar is a valid variable name used elsewhere in the program. How does one obtain from strVar: 1. The type of fooVar; 2. The value of fooVar? Best regards
Re: Threading challenge: calculate fib(45) while spinning
On Friday, 15 October 2021 at 03:35:44 UTC, jfondren wrote:
The book, "The Go Programming Language" has this simple
goroutine example:
[...]
Here is a similar implementation using the concurrency library:
```d
import concurrency;
import concurrency.stream;
import concurrency.sender : justFrom;
import concurrency.operations : via, race;
import concurrency.thread : ThreadSender;
import core.time : msecs;
import std.stdio : writef, writefln, stdout;
import core.thread : Thread;
void main() @safe {
enum chars = `-\|/`;
auto spinner = infiniteStream(0)
.scan((int acc, int _) => acc + 1, 0)
.collect((int i) shared @trusted {
writef("\r%c", chars[i % chars.length]);
stdout.flush();
Thread.sleep(100.msecs);
})
.via(ThreadSender());
enum n = 45;
auto work = justFrom(() => fib(n));
auto result = race(spinner, work).syncWait.value;
writefln("\rFibonacci(%d) = %d", n, result.get);
}
int fib(int x) pure @safe @nogc {
if (x < 2)
return x;
return fib(x - 1) + fib(x - 2);
}
```
Go has language support so it is a bit unfair to compare it.
But this code will properly handle errors (in case `writef` or
`flush` throws), and as well as having an explicit
synchronization point so that the final `writeln` is always after
the spinner is done.
Re: Can we use "ImportC" used yet?
On Saturday, 16 October 2021 at 11:03:06 UTC, jfondren wrote:
I came up with those `#define`s by looking at test_c.c as d
complained about it. It includes these functions in the final
result:
```c
static __uint16_t
__bswap_16 (__uint16_t __bsx)
{
return (__bsx);
}
static __uint32_t
__bswap_32 (__uint32_t __bsx)
{
return (__bsx);
}
static __uint64_t
__bswap_64 (__uint64_t __bsx)
{
return (__bsx);
}
```
initially those were defined in terms of compiler intrinsics
that d doesn't know about, and since they're not needed for
your use, I fixed this in the direction of making them no-ops.
They're part of stdlib.h, probably. What they do is endian
swaps, like the stuff in std.bitmanip
Cool! It now makes sense now.
importC is a new option, but it doesn't make old options go
away, and in this specific case an older option would've been
less trouble. That's all I'm saying.
Yeah agree, new options are a lot of times not there to make old
options obsolete and not used. Tho in this case, I think ImportC
will always makes sense against the old way of doing things. Even
if you have to do a little bit of work, it will still be nothing
compared if you had to make manual binding yourself...
Thanks a lot for the help, have an amazing day!!
Re: Can we use "ImportC" used yet?
On Saturday, 16 October 2021 at 08:19:41 UTC, rempas wrote:
On Saturday, 16 October 2021 at 07:09:16 UTC, jfondren wrote:
This test_og.c works (while obviously breaking some bswap
functions):
I don't know if I should have known that but what is "bswap"?
I came up with those `#define`s by looking at test_c.c as d
complained about it. It includes these functions in the final
result:
```c
static __uint16_t
__bswap_16 (__uint16_t __bsx)
{
return (__bsx);
}
static __uint32_t
__bswap_32 (__uint32_t __bsx)
{
return (__bsx);
}
static __uint64_t
__bswap_64 (__uint64_t __bsx)
{
return (__bsx);
}
```
initially those were defined in terms of compiler intrinsics that
d doesn't know about, and since they're not needed for your use,
I fixed this in the direction of making them no-ops.
They're part of stdlib.h, probably. What they do is endian swaps,
like the stuff in std.bitmanip
It would be less annoying to compile the original test_og.o
with gcc and then link it in.
If I understand correctly you mean compile the original file
with gcc (`gcc test_og.c -o test_og.o`) and then link it with
DMD (`dmd test.d test_og.o`)? Then what's the point of doing
that? Isn't this how we did that all this time and why ImportC
was created so we don't have to manually do the bindings? I'm
confused...
importC is a new option, but it doesn't make old options go away,
and in this specific case an older option would've been less
trouble. That's all I'm saying.
Re: std.zip expand: memory allocation failed
On Friday, 15 October 2021 at 20:41:36 UTC, Selim Ozel wrote: I am simply trying to unzip a compressed zip file slightly over 1GB. The de-compressed size is about 4 GB. The code is very similar to what's explained in the documentation [1] and it works for smaller files. Anyone has a solution? Memory mapping [2] previously solved some part of my issue but expand is still throwing memory allocation failure. Selim [1] https://dlang.org/phobos/std_zip.html [2] https://forum.dlang.org/thread/mfnleztnwrbgivjvz...@forum.dlang.org Did you try the MmFile workaround?
Re: How to make a function that accepts optional struct but can accept struct literal too
On Friday, 15 October 2021 at 20:33:33 UTC, JN wrote: Is there some nice way of achieving something like this C99 code in D? [...] The [literal](https://www.ibm.com/docs/sr/xl-c-and-cpp-aix/13.1.0?topic=operators-compound-literal-expressions) in the C version creates an alloca too but it's hidden.
Re: Can we use "ImportC" used yet?
On Saturday, 16 October 2021 at 07:09:16 UTC, jfondren wrote: This test_og.c works (while obviously breaking some bswap functions): I don't know if I should have known that but what is "bswap"? It would be less annoying to compile the original test_og.o with gcc and then link it in. If I understand correctly you mean compile the original file with gcc (`gcc test_og.c -o test_og.o`) and then link it with DMD (`dmd test.d test_og.o`)? Then what's the point of doing that? Isn't this how we did that all this time and why ImportC was created so we don't have to manually do the bindings? I'm confused...
Re: Can we use "ImportC" used yet?
On Saturday, 16 October 2021 at 06:39:46 UTC, rempas wrote:
```
// Filename: test.d
import test_c;
void main() {
hello_world();
}
// Filename: test_og.c
#include
#include
void hello_world() {
puts("Hello world!!!");
}
```
After that, I'm using: `gcc -E -P test_og.c > test_c.c` to
preprocess just like you shown and then I'm using the final
command with DMD: `dmd test.d test_c.c` and I'm getting the
following error message:
```
/usr/include/stdio.h(246): Error: found `__filename` when
expecting `,`
```
These are __restrict errors again, but then I get a bunch of
others as well. This test_og.c works (while obviously breaking
some bswap functions):
```c
#define __restrict restrict
#define __asm__ asm
#define __extension__
#define __inline
#define __builtin_bswap16
#define __builtin_bswap32
#define __builtin_bswap64
#include
#include
void hello_world() {
puts("Hello world!!!");
}
```
It would be less annoying to compile the original test_og.o with
gcc and then link it in.
Re: Can we use "ImportC" used yet?
On Friday, 15 October 2021 at 20:45:35 UTC, jfondren wrote:
There's no option, you just use a normal import statement when
the module is named .c instead of .d
I say 'just' but typical C uses the C preprocessor and can't be
imported as-is.
[ ... ]
First of all, I see you answering questions (not only mine) very
often so thanks ;). Now, I tried to do what you said but I'm
getting an error. Now I'm just give you the code so you can also
check it (if you want of course) and see what's going on. Let's
see:
```
// Filename: test.d
import test_c;
void main() {
hello_world();
}
// Filename: test_og.c
#include
#include
void hello_world() {
puts("Hello world!!!");
}
```
After that, I'm using: `gcc -E -P test_og.c > test_c.c` to
preprocess just like you shown and then I'm using the final
command with DMD: `dmd test.d test_c.c` and I'm getting the
following error message:
```
/usr/include/stdio.h(246): Error: found `__filename` when
expecting `,`
/usr/include/stdio.h(247): Error: found `__modes` when expecting
`,`
/usr/include/stdio.h(252): Error: found `__filename` when
expecting `,`
/usr/include/stdio.h(253): Error: found `__modes` when expecting
`,`
/usr/include/stdio.h(254): Error: found `__stream` when expecting
`,`
/usr/include/stdio.h(304): Error: found `__stream` when expecting
`,`
/usr/include/stdio.h(304): Error: found `__buf` when expecting `,`
/usr/include/stdio.h(308): Error: found `__stream` when expecting
`,`
/usr/include/stdio.h(308): Error: found `__buf` when expecting `,`
/usr/include/stdio.h(314): Error: found `__stream` when expecting
`,`
/usr/include/stdio.h(314): Error: found `__buf` when expecting `,`
/usr/include/stdio.h(326): Error: found `__stream` when expecting
`,`
/usr/include/stdio.h(327): Error: found `__format` when expecting
`,`
/usr/include/stdio.h(332): Error: found `__format` when expecting
`,`
/usr/include/stdio.h(334): Error: found `__s` when expecting `,`
/usr/include/stdio.h(335): Error: found `__format` when expecting
`,`
/usr/include/stdio.h(341): Error: found `__s` when expecting `,`
/usr/include/stdio.h(341): Error: found `__format` when expecting
`,`
/usr/include/stdio.h(347): Error: found `__format` when expecting
`,`
/usr/include/stdio.h(349): Error: found `__s` when expecting `,`
```
Checking the actual source code, it seems like a parsing error.
Any ideas?
The next inconvenient thing is: what about when you want a c
`#define` in d? Say, fstat's potential errors. You have to
smuggle those as well, and because the C preprocessor fights
you, you have to not just stuff those people in a box but also
prepare new names for them. (And if platforms vary in errors?
More build system work.)
```c
// sys_stat_wrapper.c, continued
#include
enum errors {
ebadf = EBADF,
eio = EIO,
eoverflow = EOVERFLOW,
};
```
```d
// fstat.d, continued
import sys_stat : errors, ebadf;
writeln(ebadf);
writeln(errors.eoverflow);
}
```
Of course you can rename when importing as usual, or have a
separate .d module that cleans this interface up where the C
preprocessor can't interfere.
For function-like `#defines`, perhaps you'll want to write a C
function that uses it.
In conclusion, ImportC exists and you can use it, and
complications like smuggling structs are discussed in that
page. If you're going to wrap a new C library especially, it
can take on 99% the tedium for you. If you're going to burn
down an importc-by-hand work that you have already and replace
it with ImportC, it might be better to wait for dub and gdc to
catch up. As annoying as it might be to have C constants in
your code, they do compile with fewer build steps.
Agree, having to do it manually will just be a pain in the ass...
