Re: Binding Nested C Structs
On Friday, 10 July 2015 at 03:38:49 UTC, Craig Dillabaugh wrote:
I am trying to bind to a C union with a number of nested
structs declared as follows:
typedef union {
int Integer;
struct {
int nCount;
int *paList;
} IntegerList;
struct {
int nCount;
GIntBig *paList;
} Integer64List;
} OGRField;
According to
http://wiki.dlang.org/D_binding_for_C#Nested_Structs
I should attempt to write something like (last example shown):
extern(C) union OGRField
{
int Integer;
struct {
int nCount;
int* paList;
}
struct {
int nCount;
GIntBig* paList;
}
}
But that is obviously not going to work. Does anyone know the
right way
to handle nested C structs of that form.
OK Found the answer elsewhere on the same page:
extern(C) union OGRField
{
int Integer;
struct _IntegerList
{
int nCount;
int* paList;
}
_IntegerList IntegerList;
struct _Integer64List
{
int nCount;
GIntBig* paList;
}
_Integer64List Integer64List;
}
Binding Nested C Structs
I am trying to bind to a C union with a number of nested structs
declared as follows:
typedef union {
int Integer;
struct {
int nCount;
int *paList;
} IntegerList;
struct {
int nCount;
GIntBig *paList;
} Integer64List;
} OGRField;
According to http://wiki.dlang.org/D_binding_for_C#Nested_Structs
I should attempt to write something like (last example shown):
extern(C) union OGRField
{
int Integer;
struct {
int nCount;
int* paList;
}
struct {
int nCount;
GIntBig* paList;
}
}
But that is obviously not going to work. Does anyone know the
right way
to handle nested C structs of that form.
Re: Fixed Length Array Syntax in extern(C) Function Signatures
On Thursday, 9 July 2015 at 17:42:33 UTC, Alex Parrill wrote: On Thursday, 9 July 2015 at 17:11:36 UTC, Per Nordlöw wrote: On Thursday, 9 July 2015 at 16:12:27 UTC, Timon Gehr wrote: No. You'll need explicit pass by reference on the D side. So, how should I modify my call to `image_copy` with respect to the four first parameters? In C, array parameters are the same as pointers; i.e. `foo(T[] arg)` is the same as `foo(T* arg)` [1]. You should just be able to replace `[4]` with `*` in the arguments. [1]: http://stackoverflow.com/a/5573741/646619 Static arrays in C function parameter lists should be declared as ref on the D side. See "Passinbg D Array Arguments to C Functions" at [1]. So the function declaration above in D should be: void av_image_copy(ref ubyte *[4] dst_data, ref int[4] dst_linesizes, ref const ubyte *[4] src_data, ref const int[4] src_linesizes, AVPixelFormat pix_fmt, int width, int height) [1]http://dlang.org/interfaceToC.html
Re: Import module
On Friday, 10 July 2015 at 00:53:38 UTC, codenstuff wrote:
The path is ${HOME}/d_apps/steering/steering/game_object.d
Compile command is
dmd map/map.d main_visual.d -ofmain_visual -H -gc -unittest
-L-lDgame -L-lDerelictUtil -L-lDerelictGL3 -L-lDerelictSDL2
-L-ldl -I/home/real/d_apps/dgame/source
-I/home/real/d_apps/derelict_util/source
-I/home/real/d_apps/derelict_gl3/source
-I/home/real/d_apps/derelict_sdl2/source
-I/home/real/d_apps/steering
Compiler message is same
First, because you are importing sterring.game_object, then you
can't pass -I/home/real/d_apps/steering to the compiler -- this
will cause it to look for
/home/real/d_apps/steering/sterring/game_object.d. You have to
pass the parent of the steering directory, i.e. -I/home
real/d_apps. Then it will be able to find the import.
Second, the above will only solve your immediate problem. The
next problem is that you are going to run into linking errors.
The -I switch only affects how the compiler can find which
symbols are available in a module. It does not affect which
modules get compiled. You will still need compile game_object.d,
and all of the files from Dgame, DerelictUtil, DerelictGL3 and
DerelictSDL2. The latter all have dub configurations that allow
you to easily compile them into libraries. Then you can pass all
of those on the command line, along with game_object.d (as Adam
already recommended).
Since all of the projects you are using have dub packages, it
will be much easier for you to use dub to manage your own
project. Then building becomes this:
dub build
Much less hassle.
Re: Import module
On Friday, 10 July 2015 at 00:24:44 UTC, anonymous wrote:
On Thursday, 9 July 2015 at 22:05:23 UTC, codenstuff wrote:
I am trying to import module and compile.
The compiler produces message
map/map.d(9): Error: module game_object is in file
'steering/game_object.d' which cannot be read
import path[0] = /usr/include/dmd/phobos
import path[1] = /usr/include/dmd/druntime/import
make: *** [main] Error 1
This error message doesn't mention the import path you add
below with "-I${HOME}/d_apps/steering". It should. Looks like
you copied the output of a different command.
How can I compile? Is it possible to modify import path?
Modules are set up as
${HOME}/d_apps/steering (contains steering/game_object.d)
Is that
"${HOME}/d_apps/steering/steering/game_object.d" or is it
"${HOME}/d_apps/steering/game_object.d"?
${HOME}/d_apps/path_find (contains map/map.d)
In map.d I import as
import steering.game_object;
The compile command
dmd map/map.d main_visual.d -I${HOME}/d_apps/steering
If the file is
"${HOME}/d_apps/steering/steering/game_object.d", then this
import path should be ok.
If the file is "${HOME}/d_apps/steering/game_object.d", then
that import is wrong, and you'd have to pass the import path as
"-I${HOME}/d_apps" instead.
(Adam D. Ruppe already said the following, but maybe he wasn't
verbose enough.)
Even when the import path is fixed, this can't compile because
you're not passing game_object.d to the compiler. You have
multiple options:
You can pass all source files to dmd. You don't need to tinker
with the import paths then.
Or you can use rdmd instead of dmd (or rather on top of it).
rdmd takes a single source file, discovers the imported
modules, and passes everything to dmd. It needs proper import
paths to work its magic, of course.
The path is ${HOME}/d_apps/steering/steering/game_object.d
Compile command is
dmd map/map.d main_visual.d -ofmain_visual -H -gc -unittest
-L-lDgame -L-lDerelictUtil -L-lDerelictGL3 -L-lDerelictSDL2
-L-ldl -I/home/real/d_apps/dgame/source
-I/home/real/d_apps/derelict_util/source
-I/home/real/d_apps/derelict_gl3/source
-I/home/real/d_apps/derelict_sdl2/source
-I/home/real/d_apps/steering
Compiler message is same
Re: Import module
On Thursday, 9 July 2015 at 22:05:23 UTC, codenstuff wrote:
I am trying to import module and compile.
The compiler produces message
map/map.d(9): Error: module game_object is in file
'steering/game_object.d' which cannot be read
import path[0] = /usr/include/dmd/phobos
import path[1] = /usr/include/dmd/druntime/import
make: *** [main] Error 1
This error message doesn't mention the import path you add below
with "-I${HOME}/d_apps/steering". It should. Looks like you
copied the output of a different command.
How can I compile? Is it possible to modify import path?
Modules are set up as
${HOME}/d_apps/steering (contains steering/game_object.d)
Is that
"${HOME}/d_apps/steering/steering/game_object.d" or is it
"${HOME}/d_apps/steering/game_object.d"?
${HOME}/d_apps/path_find (contains map/map.d)
In map.d I import as
import steering.game_object;
The compile command
dmd map/map.d main_visual.d -I${HOME}/d_apps/steering
If the file is "${HOME}/d_apps/steering/steering/game_object.d",
then this import path should be ok.
If the file is "${HOME}/d_apps/steering/game_object.d", then that
import is wrong, and you'd have to pass the import path as
"-I${HOME}/d_apps" instead.
(Adam D. Ruppe already said the following, but maybe he wasn't
verbose enough.)
Even when the import path is fixed, this can't compile because
you're not passing game_object.d to the compiler. You have
multiple options:
You can pass all source files to dmd. You don't need to tinker
with the import paths then.
Or you can use rdmd instead of dmd (or rather on top of it). rdmd
takes a single source file, discovers the imported modules, and
passes everything to dmd. It needs proper import paths to work
its magic, of course.
Re: Import module
On Thursday, 9 July 2015 at 22:10:53 UTC, Adam D. Ruppe wrote: The best thing to do is to pass all the modules in the project to the compiler at once, so like: dmd map/map.d steering/game_object.d The import path could be changed to not include the steering/ folder - give it the folder that contains steering - but that still won't actually link without an extra step (you'd still have to compile the other module). Passing it all at once just works. Alternatively, you might be able to run rdmd map/map.d if the folders are predictable enough too. This does not work for larger projects (when import is from multiple other projects). Any other way to import modules?
Re: Import module
The best thing to do is to pass all the modules in the project to the compiler at once, so like: dmd map/map.d steering/game_object.d The import path could be changed to not include the steering/ folder - give it the folder that contains steering - but that still won't actually link without an extra step (you'd still have to compile the other module). Passing it all at once just works. Alternatively, you might be able to run rdmd map/map.d if the folders are predictable enough too.
Import module
I am trying to import module and compile.
The compiler produces message
map/map.d(9): Error: module game_object is in file
'steering/game_object.d' which cannot be read
import path[0] = /usr/include/dmd/phobos
import path[1] = /usr/include/dmd/druntime/import
make: *** [main] Error 1
How can I compile? Is it possible to modify import path?
Modules are set up as
${HOME}/d_apps/steering (contains steering/game_object.d)
${HOME}/d_apps/path_find (contains map/map.d)
In map.d I import as
import steering.game_object;
The compile command
dmd map/map.d main_visual.d -I${HOME}/d_apps/steering
Re: I'm getting NAN out of nowhere
On 7/9/15 1:04 PM, bachmeier wrote: On Thursday, 9 July 2015 at 15:18:18 UTC, Adam D. Ruppe wrote: On Thursday, 9 July 2015 at 15:14:43 UTC, Binarydepth wrote: float prom; You didn't initialize this variable. Set it to 0.0 and it will work. Like how pointers are initialized to null automatically in D, floats are auto initalized to NaN in D. The idea is to make use of an uninitialized variable obvious quickly so you are encouraged to initialize it. Is there a reason the compiler doesn't identify this as an error? prom+=nums[nem]; doesn't make sense if prom hasn't been initialized. prom has been initialized, to NaN by the compiler. It's not an accident. All data is default initialized in D unless specifically initialized to void. -Steve
Re: Fixed Length Array Syntax in extern(C) Function Signatures
On Thursday, 9 July 2015 at 17:11:36 UTC, Per Nordlöw wrote: On Thursday, 9 July 2015 at 16:12:27 UTC, Timon Gehr wrote: No. You'll need explicit pass by reference on the D side. So, how should I modify my call to `image_copy` with respect to the four first parameters? In C, array parameters are the same as pointers; i.e. `foo(T[] arg)` is the same as `foo(T* arg)` [1]. You should just be able to replace `[4]` with `*` in the arguments. [1]: http://stackoverflow.com/a/5573741/646619
Re: Fixed Length Array Syntax in extern(C) Function Signatures
On Thursday, 9 July 2015 at 16:12:27 UTC, Timon Gehr wrote: No. You'll need explicit pass by reference on the D side. So, how should I modify my call to `image_copy` with respect to the four first parameters?
Re: I'm getting NAN out of nowhere
On Thursday, 9 July 2015 at 17:04:43 UTC, bachmeier wrote: Is there a reason the compiler doesn't identify this as an error? The compiler just doesn't really try to trace if variables have actually been initialized or not. It punts it to runtime for simplicity of compiler implementation.
Re: I'm getting NAN out of nowhere
On Thursday, 9 July 2015 at 15:18:18 UTC, Adam D. Ruppe wrote: On Thursday, 9 July 2015 at 15:14:43 UTC, Binarydepth wrote: float prom; You didn't initialize this variable. Set it to 0.0 and it will work. Like how pointers are initialized to null automatically in D, floats are auto initalized to NaN in D. The idea is to make use of an uninitialized variable obvious quickly so you are encouraged to initialize it. Is there a reason the compiler doesn't identify this as an error? prom+=nums[nem]; doesn't make sense if prom hasn't been initialized. I'm not seeing how treating it as NaN is a solution. Since it's possible that an NaN value is legitimate, you'd either have to litter your code with assertions, or take a chance that something that a problem will show up at a later date.
Re: How to get value of enum without casting
On Thu, 09 Jul 2015 16:20:56 +, tcak wrote: > Is there any way to get the type of enum without interacting with its > items? std.traits.OriginalType > Is there any way to get string representation of an item of enum without > casting? I think casting to the OriginalType and then using to!string is the correct way to do this.
How to get value of enum without casting
[code]
const enum FieldLength: uint{
Title = 64
}
const string SQL1 = "title CHAR(" ~ std.conv.to!string(
FieldLength.Title ) ~ ")";
void main() {
writeln( FieldLength.Title );
writeln( SQL1 );
}
[/code]
Result is
---
Title
Char(Title)
I can do cast(uint)( FieldLength.Title ) to fix this, but then I
am repeating the type of `enum`.
Is there any way to get the type of enum without interacting with
its items?
Is there any way to get string representation of an item of enum
without casting?
Re: Fixed Length Array Syntax in extern(C) Function Signatures
On 07/09/2015 05:19 PM, "Nordlöw" wrote:
Given
extern(C):
struct AVFrame
{
uint8_t*[AV_NUM_DATA_POINTERS] data;
int[AV_NUM_DATA_POINTERS] linesize;
int width, height;
...
}
void av_image_copy(ubyte *[4] dst_data, int[4] dst_linesizes,
const ubyte *[4] src_data, const int[4]
src_linesizes,
AVPixelFormat pix_fmt, int width, int height)
will `dst_data` will be C-ABI-fed to `image_copy()` as a C-style single
pointer in constrast to what happens in D which calls it as fixed-size
(4) array of ubyte-pointers?
No. You'll need explicit pass by reference on the D side.
Re: Fixed Length Array Syntax in extern(C) Function Signatures
On Thursday, 9 July 2015 at 15:19:41 UTC, Nordlöw wrote: uint8_t*[AV_NUM_DATA_POINTERS] data; int[AV_NUM_DATA_POINTERS] linesize; Forgot enum AV_NUM_DATA_POINTERS = 8;
Re: I'm getting NAN out of nowhere
On Thursday, 9 July 2015 at 15:18:18 UTC, Adam D. Ruppe wrote: On Thursday, 9 July 2015 at 15:14:43 UTC, Binarydepth wrote: float prom; You didn't initialize this variable. Set it to 0.0 and it will work. Like how pointers are initialized to null automatically in D, floats are auto initalized to NaN in D. The idea is to make use of an uninitialized variable obvious quickly so you are encouraged to initialize it. Thank you very much!! :D
Re: I'm getting NAN out of nowhere
On Thursday, 9 July 2015 at 15:14:43 UTC, Binarydepth wrote: float prom; You didn't initialize this variable. Set it to 0.0 and it will work. Like how pointers are initialized to null automatically in D, floats are auto initalized to NaN in D. The idea is to make use of an uninitialized variable obvious quickly so you are encouraged to initialize it.
Fixed Length Array Syntax in extern(C) Function Signatures
Given
extern(C):
struct AVFrame
{
uint8_t*[AV_NUM_DATA_POINTERS] data;
int[AV_NUM_DATA_POINTERS] linesize;
int width, height;
...
}
void av_image_copy(ubyte *[4] dst_data, int[4] dst_linesizes,
const ubyte *[4] src_data, const int[4]
src_linesizes,
AVPixelFormat pix_fmt, int width, int
height)
will `dst_data` will be C-ABI-fed to `image_copy()` as a C-style
single pointer in constrast to what happens in D which calls it
as fixed-size (4) array of ubyte-pointers?
Further, is it correct to use it in D as
void copyVideo(const AVFrame* source,
AVFrame* target)
{
av_image_copy(target.data[0 .. 4], target.linesize[0 ..
4],
source.data[0 .. 4], source.linesize[0 ..
4],
format, source.width, source.height);
}
?
It compiles without warnings, at least. I haven't been able to
test it yet, though.
I'm getting NAN out of nowhere
This is my code :
import std.stdio : writeln, readf;
void main() {
int[3] nums;
float prom;
foreach(nem; 0..2) {
writeln("input a number : ");
readf(" %d", &nums[nem]);
prom+=nums[nem];
}
writeln(prom/3.0);
}
I get prompted two times for a number and I then get NAN out of
nowhere.
Re: Wrapping a C-style Array (Pointer + Length) in a Range Interface
On Tuesday, 7 July 2015 at 12:26:33 UTC, Per Nordlöw wrote: I'm currently developing a high-level wrapper for FFMPEG at https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d My question now becomes how to most easily wrap the iteration over streams at https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d#L150 https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d#L152 in a nice D-style range interface. Do I have to allocate a new D array and copy the `AVStream*` elements into that or is there a convenience wrapper for constructing a lazy range from a C style Array-pointer plus array-length? Note that the elements of the C array are pointers to structs, in this case instances of `AVStream`. This, of course, complicates the matter with regard to GC-safety. Comments on that please :) I think a wrapper is quite easy to do, isn't it? You just need to implement front popFront and empty and you're done. So you avoid slice-related problems...
Re: Understanding Safety of Function Pointers vs. Addresses of Functions
On 7/9/15 4:44 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " wrote: On Wednesday, 8 July 2015 at 21:04:27 UTC, jmh530 wrote: On Wednesday, 8 July 2015 at 18:31:00 UTC, Steven Schveighoffer wrote: You can use a function lambda: auto fp = (real a) => cos(a); Note, I had to put (real a) even though I would have expected "a => cos(a)" to work. Interesting. You have to put real because there is also a float and double version of cos. Even if there are no overloads, you'd still need to specify the type. That's because `a => cos(a)` is not a function, but a function template, and therefore can't be store in a variable. I didn't know this! I thought it would infer the type if there wasn't any overloads (or in this case, I thought there was a weird issue with the fact that cos is intrinsic). This is good to know. -Steve
Re: How to keep executed shell running after program exits
On Thursday, 9 July 2015 at 02:33:23 UTC, tcak wrote: BTW, as a tutorial to demonstrate use of gnuplot with D, is there any place I can write an article? http://wiki.dlang.org/Tutorials
Re: How to keep executed shell running after program exits
On Thursday, 9 July 2015 at 02:33:23 UTC, tcak wrote:
I have written a code to run gnuplot.
[code]
...
auto script = std.stdio.File("/tmp/waveletscript.gnuplot", "w");
script.writeln("set term wxt 1; plot '/tmp/wavelet1.dat';");
script.writeln("set term wxt 2; plot '/tmp/wavelet2.dat';");
script.writeln("set term wxt 3; plot '/tmp/wavelet3.dat';");
script.close();
std.process.executeShell("gnuplot /tmp/waveletscript.gnuplot");
...
[/code]
I can see that gnuplot creates windows and plots, but then it
closes immediately. Anyway to execute the shell code in that
way that it detaches from running process? I do not want window
to be closing.
-
BTW, as a tutorial to demonstrate use of gnuplot with D, is
there any place I can write an article?
I believe the reason is not because the parent exits, but that by
default gnuplot exits as soon as it has finished executing its
script. It has a `--persist` option that should prevent that.
Re: Understanding Safety of Function Pointers vs. Addresses of Functions
On Wednesday, 8 July 2015 at 21:04:27 UTC, jmh530 wrote: On Wednesday, 8 July 2015 at 18:31:00 UTC, Steven Schveighoffer wrote: You can use a function lambda: auto fp = (real a) => cos(a); Note, I had to put (real a) even though I would have expected "a => cos(a)" to work. -Steve Interesting. You have to put real because there is also a float and double version of cos. Even if there are no overloads, you'd still need to specify the type. That's because `a => cos(a)` is not a function, but a function template, and therefore can't be store in a variable.
