Re: type suffix for character literal
On Monday, 7 December 2020 at 22:26:52 UTC, Ben Jones wrote:
Are there suffices (suffixes?) for character literals?
nope.
Is there a more succinct of writing "the literal 'x' as a
dchar" than dchar('x')?
You should rarely need to since there's implicit casting. but I
think that is the best way if you do need to.
Re: Request assistance initializing struct instance at global scope
On 12/7/20 10:56 PM, Adam D. Ruppe wrote:
On Monday, 7 December 2020 at 04:13:16 UTC, Andrew Edwards wrote:
Given:
===
extern(C):
char*[] hldr;
Why is this extern(C)? A D array ere is probably wrong.
To stay as close to the original implementation as possible. This will
all change when the entire code base compiles in D.
In C, a `char*[] hldr = {...}` is actually represented in D as a static
length array, like `char*[1] = [null];`
Thanks. Because I was having issues I didn't know how to resolve, I
actually defined it as `string ft` instead and passed around `ft.ptr`
when calling
It should also generally be __gshared if it was declared in C (C
defaults to global, D defaults to thread-local), and if declared in C,
an additional extern may be required.
Noted. I'll keep that in mind when trying to link to C in the future.
So, if you are trying to *link* to C code that has this:
I'm porting it. All of the code is available from the D source file.
You'd bind to it in D with
---
// D
extern(C) extern __gshared char*[1] hldr; // matches the C. Make sure
the length matches too
Ok, got it.
S[] s = [S(cast(char*) "c", [0])]; // that cast is super iffy
though. Should S have `const(char)* ft` instead?
Probably. I just did a direct port. They had char* so I just kept it
that way. I'll change it to string once the initial port is complete.
But I'll remember that when I come across it in the future.
In that thing:
extern(C) - tells it it has a C name.
extern - tells it the actual variable is declared externally. This
second one makes the linker pull the variable's address from the C code
instead of declaring a new variable in D that can be used from C.
__gshared - turn off D's thread local default to match C's global.
Learning has occurred. Thanks.
Now if you are translating C code to D, that might be different,
certainly the second extern is wrong then, and you need to copy over the
initial value but the rest still works:
This.
```
// no more second extern, D is now creating a new variable, then it
needs to know the value too
extern(C) __gshared char*[1] hldr = [null];
Okay. I'll need to be mindful of this in the future. But to resolve the
issue this time around, I just used a string[] since that's the end
state anyway.
// rest is the same
// including
S[] s = [S(cast(char*) "c", [0])]; // since it is a gshared static
array, this still works
```
Yup... got this to compile with main() and static this() in the correct
location.
But there's a few other contexts that might change this, then you
probably do want the static constructor, or maybe you can make some
things immutable and make it work that way. All depends on a bit more
information than your code gives on its own
Thanks for the lesson... I've learned quite a lot.
Re: Request assistance initializing struct instance at global scope
On 12/7/20 10:12 PM, Jacob Carlborg wrote:
On Monday, 7 December 2020 at 04:13:16 UTC, Andrew Edwards wrote:
You can either use `extern(C) char*[] hldr` to make only `hldr` have C
linkage. Use `extern(C) {}` to group several symbols which should have C
linkage or rearrange the code so that `static this` is above `extern(C):`.
--
/Jacob Carlborg
Thanks Jacob. The extern(C) is temporary. I'm doing a direct port of the
code to D using -betterC. Wanted to keep it as close to the original as
possible until everything compiles.
I noticed that static this() does not work if either it or main() (or
both) is marked extern(C). To fix the issue, I simply moved the static
this() and main() above the extern(C) and the deprecation error disappears.
Andrew
type suffix for character literal
Are there suffices (suffixes?) for character literals?
Is there a more succinct of writing "the literal 'x' as a dchar"
than dchar('x')?
I didn't see anything
https://dlang.org/spec/lex.html#characterliteral but figured I'd
ask the community
Re: Calling executable generated by dub with sudo
On Monday, 7 December 2020 at 20:34:36 UTC, Selim Ozel wrote:
Let's say I build my package using dub run from an Ubuntu
terminal. How can I add sudo as the executable is being run? I
tried adding preRunCommands to my dub.sdl as described in [1]
but that just runs sudo and terminal throws an error.
Best,
Selim
[1] https://dub.pm/package-format-sdl
Something like this, I guess:
import core.sys.posix.unistd: getuid;
import std.process: execv;
void main(string[] args)
{
if (getuid() != 0) {
execv("sudo", args);
return 1; // failed to exec
}
// The rest of your code goes here
}
Calling executable generated by dub with sudo
Let's say I build my package using dub run from an Ubuntu terminal. How can I add sudo as the executable is being run? I tried adding preRunCommands to my dub.sdl as described in [1] but that just runs sudo and terminal throws an error. Best, Selim [1] https://dub.pm/package-format-sdl
Re: Static on free functions
On Monday, 7 December 2020 at 17:07:20 UTC, Adam D. Ruppe wrote:
On Monday, 7 December 2020 at 17:01:45 UTC, Dave P. wrote:
Does `static` on a free function definition do anything?
Nope, D allows a lot of useless attributes so it doesn't
complain if you do certain things out of habit (or it is just a
lazy implementation, I'm not sure which explanation applies
here)
static int foo(){
return 3;
}
int foo(){
return 3;
}
but both the same.
Thanks for the answer!
Re: Static on free functions
On Monday, 7 December 2020 at 17:01:45 UTC, Dave P. wrote:
Does `static` on a free function definition do anything?
Nope, D allows a lot of useless attributes so it doesn't complain
if you do certain things out of habit (or it is just a lazy
implementation, I'm not sure which explanation applies here)
static int foo(){
return 3;
}
int foo(){
return 3;
}
but both the same.
Static on free functions
Does `static` on a free function definition do anything?
I know the meaning of it in C, but I can’t find an equivalent
definition (or
any definition of it at all) when applied to free functions in
the spec.
Are the two below any different or is it just for ease of porting
from C?
static int foo(){
return 3;
}
int foo(){
return 3;
}
Re: how to print progress of a long running parallel() loop?
On 12/7/20 4:48 AM, Dukc wrote: On Monday, 7 December 2020 at 08:16:50 UTC, mw wrote: r = Parallel(n_jobs=2, verbose=10)(delayed(sleep)(.2) for _ in range(10)) to print out the progress. How to do this in D's parallel loop? thanks. Allocate a `shared int` before the foreach loop. In the loop when, let's say `!(i & 0xFFF)`, atomically increment the shared variable and print it's number. Disclaimer: no experience about using `shared`, but this is what I'd try. Yes, that would be the way but I don't know the effect of using shared or not. But because the progress needs to be somehow reported, an atomic variable may not be sufficient (unless a separate thread is reading it, etc.) This issue came up during one of my recent presentations at this point: https://www.youtube.com/watch?v=dRORNQIB2wA=youtu.be=1527 I used a synchronized block in that code because it did not affect performance in my use case. Ali
Re: Request assistance initializing struct instance at global scope
On Monday, 7 December 2020 at 04:13:16 UTC, Andrew Edwards wrote:
Given:
===
extern(C):
char*[] hldr;
Why is this extern(C)? A D array ere is probably wrong.
In C, a `char*[] hldr = {...}` is actually represented in D as a
static length array, like `char*[1] = [null];`
It should also generally be __gshared if it was declared in C (C
defaults to global, D defaults to thread-local), and if declared
in C, an additional extern may be required.
So, if you are trying to *link* to C code that has this:
---
// C
char* hldr[] = {0};
---
You'd bind to it in D with
---
// D
extern(C) extern __gshared char*[1] hldr; // matches the C. Make
sure the length matches too
// rest for your code the same:
enum I = (1<<0);
struct S { char* ft; char** fm; int f; }
S[] s = [S(cast(char*) "c", [0])]; // that cast is super
iffy though. Should S have `const(char)* ft` instead?
void main(){}
---
In that thing:
extern(C) - tells it it has a C name.
extern - tells it the actual variable is declared externally.
This second one makes the linker pull the variable's address from
the C code instead of declaring a new variable in D that can be
used from C.
__gshared - turn off D's thread local default to match C's global.
Now if you are translating C code to D, that might be different,
certainly the second extern is wrong then, and you need to copy
over the initial value but the rest still works:
```
// no more second extern, D is now creating a new variable, then
it needs to know the value too
extern(C) __gshared char*[1] hldr = [null];
// rest is the same
// including
S[] s = [S(cast(char*) "c", [0])]; // since it is a gshared
static array, this still works
```
But there's a few other contexts that might change this, then you
probably do want the static constructor, or maybe you can make
some things immutable and make it work that way. All depends on a
bit more information than your code gives on its own
Re: how to access record[0] of a csv row? Error: no [] operator overload for type CsvRecord!(int, cast(Malformed)1, string, dchar)
On Monday, 7 December 2020 at 06:18:33 UTC, mw wrote: Now, how to convert it to a native array: double[] row = record; Error: cannot implicitly convert expression record of type Tuple!(double, double, double, ..., double) to double[] (I know for tuple, we can do: double[] arr = [record];) double[] row = [record.expand];
Re: Request assistance initializing struct instance at global scope
On Monday, 7 December 2020 at 04:13:16 UTC, Andrew Edwards wrote:
Given:
===
extern(C):
char*[] hldr;
enum I = (1<<0);
struct S { char* ft; char** fm; int f; }
void main(){}
===
// Error Deprecation: static constructor can only be of D
linkage
S[] s;
static this() {
s = [ S(cast(char*)"c", [0], I) ];
}
This is the correct way to do it. The problem is that you have
added `extern(C):` at the top. This means that ever symbol below
will have C linkage. As the error message says, `static this` can
only have D linkage. `static this` is transformed into a function
which is automatically called by the runtime. When you add
`extern(C):` at the top, this function will also get the C
linkage. A simple way to make sure that there are not multiple C
functions with the same name (caused by multiple `static this`,
in the same file or another file) is to mangle the function name
the same way as a D function.
You can either use `extern(C) char*[] hldr` to make only `hldr`
have C linkage. Use `extern(C) {}` to group several symbols which
should have C linkage or rearrange the code so that `static this`
is above `extern(C):`.
--
/Jacob Carlborg
Re: how to print progress of a long running parallel() loop?
On Monday, 7 December 2020 at 08:16:50 UTC, mw wrote: r = Parallel(n_jobs=2, verbose=10)(delayed(sleep)(.2) for _ in range(10)) to print out the progress. How to do this in D's parallel loop? thanks. Allocate a `shared int` before the foreach loop. In the loop when, let's say `!(i & 0xFFF)`, atomically increment the shared variable and print it's number. Disclaimer: no experience about using `shared`, but this is what I'd try.
how to print progress of a long running parallel() loop?
https://dlang.org/phobos/std_parallelism.html#.parallel
auto logs = new double[1_000_000];
foreach (i, ref elem; parallel(logs))
{
elem = log(i + 1.0);
}
In Python, using joblib, I can use `verbose` level like this:
r = Parallel(n_jobs=2, verbose=10)(delayed(sleep)(.2) for _ in
range(10))
to print out the progress.
How to do this in D's parallel loop?
thanks.
