Re: Getting GtkD working with OpenGL
On Monday, 3 October 2016 at 18:00:53 UTC, Mike Wey wrote:
The signal functions can be found in the gobject.Signals module.
But you should use the GLArea.addOnCreateContext / addOnRender
/ addOnResize functions to attach a D delegate to the signal.
You will still need to link with the OpenGL libraries or use
someting like Derelict.
Hi Mike, thanks for your fast answer again!
I just read about this delegates and I liked the concept. I
experimented with it for a while and read a bit on the Internet,
but I still don't get it working...
My minimal example looks like this:
import gtk.Main;
import gtk.MainWindow;
import gtk.GLArea;
import glgdk.GLContext;
void main(string[] args)
{
bool render(GLContext context, GLArea area)
{
return true;
}
Main.init(args);
MainWindow win = new MainWindow("Hello World");
GLArea area = new GLArea();
area.addOnRender(,cast(GConnectFlags)0);
win.add(area);
win.showAll();
Main.run();
}
If I compile it, I get this error:
$ dmd main.d -I/usr/local/include/d/gtkd-3 -L-lgtkd-3
main.d(27):
Error: function gtk.GLArea.GLArea.addOnRender
(bool delegate(GLContext, GLArea) dlg, GConnectFlags connectFlags
= cast(GConnectFlags)0)
is not callable using argument types
(bool delegate(GLContext context, GLArea area), GConnectFlags)
I cant see, what I am doing wrong... Someone else sees the error?
Tomorrow I try to subclass the GLArea, if this works I am happy
:) But I'd like to use the handler stuff.
Ah, and I know now, that I have to link against the GL and GLU
library, but which module do I have to import, to make the
functions visible for the compiler? Or do I need another binding
therefore?
Re: How to make rsplit (like in Python) in D
On Saturday, 1 October 2016 at 18:33:02 UTC, TheFlyingFiddle wrote: On Saturday, 1 October 2016 at 16:45:11 UTC, Uranuz wrote: [...] There are two reasons why this does not compile. The first has to do with how retro() (and indeed most function in std.range) work with utf-8 strings (eg the string type). When working on strings as ranges, the ranges internally change the type of ".front" from 'char' into 'dchar'. This is done to ensure that algorithms working on strings do not violate utf-8. [...] Thanks for clarification. It seems that once upon a time I'll write my own string wrapper that will return just slice of `string` pointing to source multibyte sequence as .front and will use it, and be happy. When I looking more at other languages (like Python) then I more convinced that working with UTF-8 string as array of single bytes is not very good
Re: How to make rsplit (like in Python) in D
On Monday, 3 October 2016 at 19:25:59 UTC, Uranuz wrote: When I pass empty string to splitter in most of languages I expect to get list with 1 item (empty string) as a result, but I get error instead. And I see inconsistency in that .front behaves normally, but .back is not. Usually I access front of range directly without any check when I expect it to have exactly 1 item. But in this case it not working and is very strange. Hm, if front works but not back that is probably a bug. I think checking whether the range is empty before accessing the member should be a viable workaround.
Re: How to make rsplit (like in Python) in D
On Saturday, 1 October 2016 at 18:55:54 UTC, pineapple wrote:
On Saturday, 1 October 2016 at 17:55:08 UTC, Uranuz wrote:
On Saturday, 1 October 2016 at 17:32:59 UTC, Uranuz wrote:
On Saturday, 1 October 2016 at 17:23:16 UTC, Uranuz wrote:
[...]
But these example fails. Oops. Looks like a bug(
import std.stdio;
import std.algorithm;
import std.range;
import std.string;
[...]
I created bug report on this:
https://issues.dlang.org/show_bug.cgi?id=16569
This isn't a bug. It's illegal to access the front or back of
an empty range. (If anything is a bug, it's the
nondescriptiveness of the error.) You should write this instead:
void main()
{
string str = "";
auto split = str.splitter('.');
if(!split.empty) writeln(split.back);
}
When I pass empty string to splitter in most of languages I
expect to get list with 1 item (empty string) as a result, but I
get error instead. And I see inconsistency in that .front behaves
normally, but .back is not. Usually I access front of range
directly without any check when I expect it to have exactly 1
item. But in this case it not working and is very strange.
Re: Why using wrappers for D?
On Monday, October 03, 2016 18:05:47 Chalix via Digitalmars-d-learn wrote: > Ah great, now I understand it :) > I thought, import and include would work the same way (taking all > the code in the .h or .d file and pasting it into the other file). > But if import extracts only the definitions, it is clear, that > you have to link against the library, or to add all the .d files > to your source code. #include is a _very_ inefficient way to do things. It results in the same code being compiled over and over again, which is why pretty much every language post C/C++ has some sort of symbol import mechanism in attempt to compile everything only once. The way it works in D, you do end up with some amount of work being redone if you do incremental compilation, but even then, it minimizes how much it has to redo, and there are future improvements planned which will make it even better. There's a reason why D compiles so much faster than C/C++. :) You should probably read this article by Walter on why C/C++ compilation is so slow: http://www.digitalmars.com/articles/b54.html It's quite enlightening - and horrifying. - Jonathan M Davis
Re: Why using wrappers for D?
On 10/03/2016 07:19 PM, Chalix wrote:
On Monday, 3 October 2016 at 13:51:28 UTC, Mike Parker wrote:
// wrapfoo.d
import foo; // import the foo module from above
void myFunc(string s)
{
import std.string : toStringz;
my_func(s.toStringz());
}
Thank you for the example, Mike!
And thanks to all others who support me with their answers! I didn't
expect so much answers, the D community seems to be very helpful :)
But there still is one thing, which I don't get:
If I "import foo;" in my project, it will be compiled alongside. So
there is no need for an extra library. Same should be for wrapfoo.d. If
I "import wrapfoo;", I should just need the C-library "foo", and no
D-library "food" right?
To have a more practical example, I looked up the "header" of the GtkD
gtk/Main.d file. There are functions exactly like you described:
public static void init(ref string[] argv)
{
int argc = cast(int)argv.length;
char** outargv = Str.toStringzArray(argv);
gtk_init(, );
argv = Str.toStringArray(outargv, argc);
}
This function wraps the C-like gtk_init function to a D init function.
The gtk_init function is the function from the GTK+ library, which is
loaded in the gtkc/gtk.d file:
Linker.link(gtk_init, "gtk_init", LIBRARY.GTK);
Linker and link are defined in the gtkc/Loader.d
So, why is it not enough just to "import gtk.Main"? What kind of code is
inside the gtkd-3 library?
The gtkd-3 library contains for example the code you quoted above.
--
Mike Wey
Re: Why using wrappers for D?
On Monday, 3 October 2016 at 17:19:47 UTC, Chalix wrote:
If I "import foo;" in my project, it will be compiled
alongside. So there is no need for an extra library. Same
should be for wrapfoo.d. If I "import wrapfoo;", I should just
need the C-library "foo", and no D-library "food" right?
You do have some confusion here, which Jonathan's answer should
clear up (that is, importing a module does not cause it to be
compiled, only makes its symbols to the module in which the
declaration is made), however, there is one point I'd like to
make below.
This function wraps the C-like gtk_init function to a D init
function.
The gtk_init function is the function from the GTK+ library,
which is loaded in the gtkc/gtk.d file:
Linker.link(gtk_init, "gtk_init", LIBRARY.GTK);
Linker and link are defined in the gtkc/Loader.d
So, why is it not enough just to "import gtk.Main"? What kind
of code is inside the gtkd-3 library?
I don't know the details of the gtkd-3 library, but consider this
example:
```
// csay.c
#include
void sayHi() { puts("Hi\n"); }
// dsay.d
module dsay;
extern(C) void sayHi();
// hi.d
import dsay;
void main() { sayHi(); }
```
Assuming you have both dmd and dmc installed, you can easily do a
bit of experimentation like so:
First, use dmd to generate csay.obj.
dmc -c csay.c
Next, with dsay.d, hi.d and csay.obj all in the same directory,
build an executable.
dmd hi.d csay.obj
This should result in both a successful compile and a successful
link. But understand that dsay.d was *never* compiled in this
process. Importing dsay made the source symbol 'sayHi' available
to hi.d. The compiler emitted a call to sayHi in the generated
binary (hi.obj). Finally, the linker was able to match that call
to the C sayHi function and could perform the link to generate
the executable. Because the binary symbol for sayHi was already
present in csay.obj, you did not need to compile and link dsay.d.
Now, let's change it up a bit:
```
// csay.h
extern void sayHi();
#define sayHiTwice \
sayHi(); \
sayHi();
```
This is a horrible macro, but it serves its purpose as an
example. In order to provide sayHiTwice in D, it will have to be
implemented and not just declared:
```
// dsay.d
extern(C) void sayHi();
void sayHiTwice() {
sayHi();
sayHi();
}
```
Since the C version of sayHiTwice is a macro and not a function,
it need not be extern(C). However, no we have an implementation
and not simply a declaration. So this:
```
// hi.d
import dsay;
void main() { sayHiTwice(); }
```
dmd hi.d csay.obj
Is now going to generate a *linker* error. It will *compile* just
fine, since the import of dsay makes sayHiTwice visible during
compilation. However, since csay.obj does not contain a binary
symbol for sayHiTwice (as it's a macro and not a function), the
the linker will be unable to match the call to any existing
symbol and will produce an error. So you would have to do this:
dmd hi.d dsay.d csay.obj
Now, the binary symbol for sayHiTwice will be generated because
dsay.d is being compiled and linked into the program.
So, when you have a declarations-only module, with no function
implementations or template instantiations, then it need not
actually be compiled and linked into the program. In that you are
correct. But, no, importing a module does not automatically
compile it. And any function declarations still need an
implementation somewhere if they are used in the modules you do
compile.
Re: Why using wrappers for D?
On Monday, 3 October 2016 at 17:56:46 UTC, ag0aep6g wrote: When you do precompile to a library, you can skip the compilation later. That can save time. True, linking with this library instead of compiling it every time I changed my code will save me a lot of time :)
Re: Why using wrappers for D?
On 10/03/2016 05:47 AM, Chalix wrote:
> what do you mean
> by "turn C functions into classes"?
Many C APIs are object-oriented in that, they pass the most interesting
object as the first parameter:
// C struct
struct Foo {
// ...
};
// Factory method (or, "constructor")
Foo* make_foo(int i, double d);
void free_foo(Foo** foo);
int use_foo(Foo* foo, const char *str);
Instead of living with C's limitations, one can define a D struct Foo
and turn such function into member functions:
// D struct
struct FooD {
// ...
Foo* c_foo;
// other things that go with
// Factory method (or, "constructor")
this(int i, double d) {
c_foo = make_foo(i, d);// dispatch to C library
}
~this() {
free_foo(_foo);// dispatch to C library
}
void use(BarD bar) {
enforce(use_foo(c_foo, "hello");
}
}
That's how a D wrapper of a C library may look like, which should be
almost identical to how it could be done in C++.
> Also, I used the Qt library a lot with C++. But although it is a
> library, I have access to all the classes, like " QWidget w = new
> QWidget();". There is no factory method used. (This confuses me now a
> bit...)
'new QWidget()' does call the constructor automatically, which D cannot
do. (Although, with the recent changes in C++ interoperability, perhaps
even that's doable today.)
If D cannot create C++ object with the 'new' keyword, then they can use
a layer of a factory method to do it:
// A C++ layer
extern "C" QWidget* make_QWidget() {
return new QWidget();
}
extern "C" void free_QWidget(QWidget* p) {
delete p;
}
Since that function (i.e. not the "new expression" itself) is callable
from D, the D code can now use the library:
extern (C) {
// ...
QWidget* make_QWidget();
void free_QWidget(QWidget* p);
}
// D class
class QWidgetD
{
QWidget* cpp_widget;
this() {
cpp_widget = make_QWidget();
}
~this() {
free_QWidget(cpp_widget);
}
// ...
}
That's how I understand it anyway... :) Again though, this may be much
easier today with the recent and ongoing improvements to C++
interoperability.
Ali
Re: Why using wrappers for D?
On Monday, 3 October 2016 at 17:45:55 UTC, Jonathan M Davis wrote: The import statement just tells the D compiler to pull in declarations for the symbols that it needs from those modules. It doesn't actually compile those modules. You still have to give them to the compiler (either all together or separately to generate .o/.obj files) in order to actually compile them. And anything that's not D (like a C/C++ library) still needs to be linked in just like it would be in C/C++. In C/C++, #including is not enough to compile everything into your code unless everything is in the header files (which it rarely is). For the files in your project, you have to compile every .c/.cpp file to generate the .o or .obj files that the linker then links into your program, and for the 3rd party stuff that's in a library you need to link in the library. Simply #including doesn't actually bring something like curl or gtk into your program. You also have to link it when generating your executable. It's basically the same thing with D. Every .d file in your project needs to be compiled so that it gets linked into your executable, and if you want to use 3rd party stuff, you have to link in the libraries just like you would with C/C++. The separation is perhaps a bit less clear in D, because you usually just use .d files for everything, whereas C/C++ have .h and .c/.cpp as separate files. D does have .di files for the cases where you need to hide your code, but they don't get used often. But when you do use a .di file, that's what gets imported rather than the .d file which contains the actual definitions, so in that case, the separation is clearer. Ah great, now I understand it :) I thought, import and include would work the same way (taking all the code in the .h or .d file and pasting it into the other file). But if import extracts only the definitions, it is clear, that you have to link against the library, or to add all the .d files to your source code. A big thank-you to all repliers for making things clear :D
Re: Getting GtkD working with OpenGL
On 10/03/2016 01:50 PM, Chalix wrote: On Sunday, 18 September 2016 at 21:41:45 UTC, Mike Wey wrote: The demo still uses the old GtkGLExt binding, which usually isn't available in de distributions repositories. The newer GLArea is easier to use since it's part of GTK. As for the linker errors, you'll need to link with the OpenGL libraries: "-L-lGL -L-lGLU" Hey, thanks for your fast answer! I had a lot of other work to do, so I could only continue working on this project now. Yeah, that solved my problem :) Now it links. Although if I execute the program, it complains about the missing GtkGLExt library, like expected... Library load failed: libgdkglext-3.0.so.0 So I wanted to install this library from here: https://projects.gnome.org/gtkglext/download.html but the ./configure script tells me, No package 'pangox' found (pangox >= 1.0.0) I looked at the folder /usr/lib/x86_64-linux-gnu/ and there is a file called "libpangox-1.0.so.0.0.0". So I don't know, why this is not working... You will need the Gtk3 port of gtkglext: https://github.com/tdz/gtkglext Last time i tried compiling it i needed to remove the documentation generation from the make files. Anyway, I want to follow Mikes advice and use GLArea instead, so if there is not a quick fix available, lets skip the problems with the GtkGLExt library... But, sadly enough, I did not get GLArea working, too. The documentation https://developer.gnome.org/gtk3/stable/GtkGLArea.html says, I have to connect my render function to the widget like this: g_signal_connect (gl_area, "render", G_CALLBACK (render), NULL); But, my compiler can't find the g_signal_connect method (and the GL Methods...): main.d(22): Error: undefined identifier 'g_signal_connect' main.d(39): Error: undefined identifier 'glClearColor' main.d(40): Error: undefined identifier 'glClear' There might some include files (or import files, as you say in D) missing, but I could not figure out, where to find them for D... Could you tell me, where this g_signal_connect method can be found? And what I have to include for the GL functionality? Simply "import gtk.GLArea;" does not do the trick... The signal functions can be found in the gobject.Signals module. But you should use the GLArea.addOnCreateContext / addOnRender / addOnResize functions to attach a D delegate to the signal. You will still need to link with the OpenGL libraries or use someting like Derelict. Btw, is g_signal_connect a GTK method? I intend to use my program platform independent, so if this is dependent on gnome, it would not be good. It's a GLib/GObject method, it's available on any platform GTK runs on. Or is there any other way to get the GLArea working? I am used to the Qt Libraries, where you create a QGLWidget and simply override the init and render functions. Thanks for reading this far, would be great if we could solve this problem :D -- Mike Wey
Re: Why using wrappers for D?
On 10/03/2016 07:19 PM, Chalix wrote:
If I "import foo;" in my project, it will be compiled alongside.
Not necessarily. dmd won't compile foo unless you tell it to by putting
foo.d on the command line. If foo is only imported, dmd parses the file
but it doesn't compile it.
So
there is no need for an extra library.
You don't *need* the library. You can just compile the file together
with the rest of your program, yes.
When you do precompile to a library, you can skip the compilation later.
That can save time.
And you can shorten the distributed D source files to just the function
signatures, like with header files in C. For this, the compiler
recognizes the .di filename extension. This can be used to somewhat
protect closed source code.
And then there are shared libraries, which are loaded at run time. Their
code is not included in the executable, so you get a smaller file. Makes
sense with popular libraries that are used by many programs.
Same should be for wrapfoo.d. If
I "import wrapfoo;", I should just need the C-library "foo", and no
D-library "food" right?
If wrapfoo is really just a binding, i.e. it provides only function
signatures and no implementation, then there's no point in compiling it
to a library.
Otherwise, if wrapfoo actually implements something of its own, it can
make sense to compile it to a library. Just like with every other piece
of code.
To have a more practical example, I looked up the "header" of the GtkD
gtk/Main.d file. There are functions exactly like you described:
public static void init(ref string[] argv)
{
int argc = cast(int)argv.length;
char** outargv = Str.toStringzArray(argv);
gtk_init(, );
argv = Str.toStringArray(outargv, argc);
}
This function wraps the C-like gtk_init function to a D init function.
The gtk_init function is the function from the GTK+ library, which is
loaded in the gtkc/gtk.d file:
Linker.link(gtk_init, "gtk_init", LIBRARY.GTK);
Linker and link are defined in the gtkc/Loader.d
So, why is it not enough just to "import gtk.Main"? What kind of code is
inside the gtkd-3 library?
If the GtkD files contain all the implementations (not just signatures),
then you don't have to build/use the library. You can just compile the
GtkD source files along with your program, and link with the C library.
Re: Why using wrappers for D?
On Monday, October 03, 2016 17:19:47 Chalix via Digitalmars-d-learn wrote: > But there still is one thing, which I don't get: > > If I "import foo;" in my project, it will be compiled alongside. > So there is no need for an extra library. Same should be for > wrapfoo.d. If I "import wrapfoo;", I should just need the > C-library "foo", and no D-library "food" right? The import statement just tells the D compiler to pull in declarations for the symbols that it needs from those modules. It doesn't actually compile those modules. You still have to give them to the compiler (either all together or separately to generate .o/.obj files) in order to actually compile them. And anything that's not D (like a C/C++ library) still needs to be linked in just like it would be in C/C++. In C/C++, #including is not enough to compile everything into your code unless everything is in the header files (which it rarely is). For the files in your project, you have to compile every .c/.cpp file to generate the .o or .obj files that the linker then links into your program, and for the 3rd party stuff that's in a library you need to link in the library. Simply #including doesn't actually bring something like curl or gtk into your program. You also have to link it when generating your executable. It's basically the same thing with D. Every .d file in your project needs to be compiled so that it gets linked into your executable, and if you want to use 3rd party stuff, you have to link in the libraries just like you would with C/C++. The separation is perhaps a bit less clear in D, because you usually just use .d files for everything, whereas C/C++ have .h and .c/.cpp as separate files. D does have .di files for the cases where you need to hide your code, but they don't get used often. But when you do use a .di file, that's what gets imported rather than the .d file which contains the actual definitions, so in that case, the separation is clearer. - Jonathan M Davis
Re: Why using wrappers for D?
On Monday, 3 October 2016 at 13:51:28 UTC, Mike Parker wrote:
// wrapfoo.d
import foo; // import the foo module from above
void myFunc(string s)
{
import std.string : toStringz;
my_func(s.toStringz());
}
Thank you for the example, Mike!
And thanks to all others who support me with their answers! I
didn't expect so much answers, the D community seems to be very
helpful :)
But there still is one thing, which I don't get:
If I "import foo;" in my project, it will be compiled alongside.
So there is no need for an extra library. Same should be for
wrapfoo.d. If I "import wrapfoo;", I should just need the
C-library "foo", and no D-library "food" right?
To have a more practical example, I looked up the "header" of the
GtkD gtk/Main.d file. There are functions exactly like you
described:
public static void init(ref string[] argv)
{
int argc = cast(int)argv.length;
char** outargv = Str.toStringzArray(argv);
gtk_init(, );
argv = Str.toStringArray(outargv, argc);
}
This function wraps the C-like gtk_init function to a D init
function.
The gtk_init function is the function from the GTK+ library,
which is loaded in the gtkc/gtk.d file:
Linker.link(gtk_init, "gtk_init", LIBRARY.GTK);
Linker and link are defined in the gtkc/Loader.d
So, why is it not enough just to "import gtk.Main"? What kind of
code is inside the gtkd-3 library?
Re: Why using wrappers for D?
On Monday, 3 October 2016 at 12:08:54 UTC, Chalix wrote: Hi All! The documentation of D (https://dlang.org/overview.html#compatibility) says: "Direct Access to C API's Not only does D have data types that correspond to C types, it provides direct access to C functions. There is no need to write wrapper functions, parameter swizzlers, nor code to copy aggregate members one by one." D was inspired by Java, so wrappers meant here are probably JNI wrappers https://en.wikipedia.org/wiki/Java_Native_Interface
Re: Getting consistent behavour for class properties
I suppose that's https://issues.dlang.org/show_bug.cgi?id=8006
Re: Why using wrappers for D?
On Monday, 3 October 2016 at 12:47:48 UTC, Chalix wrote: Also, I used the Qt library a lot with C++. But although it is a library, I have access to all the classes, like " QWidget w = new QWidget();". There is no factory method used. (This confuses me now a bit...) Qt bindings is a major undertaking, it was tried a couple of times. As an alternative you can try Calypso https://github.com/Syniurge/Calypso which has a C++ language plugin so can read headers directly.
Re: Why using wrappers for D?
On Monday, 3 October 2016 at 12:08:54 UTC, Chalix wrote:
Furthermore, if there is an not very popular C library, where
no wrapper function exists, would it possible to include it
into a D project? Probably I have to transform all the .h to .d
files, so i can "import" them instead of "include" them. But
then, could I link against the C-library?
Yes, but here you're talking about a binding, not a wrapper.
I did not understand the concept of interaction between C and
D, and I am a bit confused about wrapper functions and bindings
for D now...
Would be great if someone could make it a bit more clear to me
:)
A binding is just the C function declared in D:
// foo.h
extern void my_func(const char *str);
// foo.d
extern(C) void my_func(const(char)* str) @nogc nothrow;
Now with the declaration in D, you can link directly to the C
library. But you also need foo.d to be linked into your program,
either by compiling it alongside your own source files or linking
it as a library (as you do with gtkd-3.lib).
A wrapper takes a C interface and makes it more D like.
// wrapfoo.d
import foo; // import the foo module from above
void myFunc(string s)
{
import std.string : toStringz;
my_func(s.toStringz());
}
Re: Why using wrappers for D?
On Monday, 3 October 2016 at 13:12:55 UTC, Chalix wrote: But I don't get, why I have a gtkd-3 lib. Why can't I just link against the gtk-3 lib then? I have now the headers to use the nice D stuff, but the linking should be done against the C-compiled library. If you don't use D-specific stuff like autogenerated comparison operators and big struct initializers, you would be able to link with C library alone.
Re: Why using wrappers for D?
On 04/10/2016 1:56 AM, Chalix wrote: On Monday, 3 October 2016 at 12:15:10 UTC, rikki cattermole wrote: To use any kind of function you must declare it, plain and simple. Any c or c++ function/class is the very much same way. Now C++ types such as classes are highly limited in D since it doesn't ugh cross over all that well (it does some weird things). I don't know if we understand each other. You have to declare each function in the language you are programming, that is clear to me. So if you write in D, you need "D-Headers" (which are not called headers in D, i know). What do you mean with "Now C++ types such as classes are highly limited in D"? Basically some features do not match up nicely like operators and constructors. They also do not share semantics e.g. value versus reference. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Why using wrappers for D?
On Monday, 3 October 2016 at 12:54:03 UTC, Adam D. Ruppe wrote: It is possible, you just need to match compilers with the library in C++, whereas C libraries don't need such an exact match. With your Qt library, you get a build of it that is compatible with the compiler you use to build your application (either compiling it yourself or getting it from an OS package repo where they did it for you for your OS version) Ah, so the Qt libraries are C++ libraries. And they have to be compiled with the same compiler (or at least with a compiler with the same specification) I use for my application? I didn't know that, but it makes sense to me. But if there would be 2 C++ compilers on my linux system which create 2 different API's, I would need the Qt library twice on my system? One for an application compiled with the one compiler, and the other library for an application compiled with the other compiler. Since I have only 1 Qt library on my system, all linux compilers must create compatible API's, right? Wrap the C functions inside D classes. So they write D code that calls the C functions, then you use their D code. Ok, this is the same what cym13 wanted to say, right? So you can use the advantages of D? But I don't get, why I have a gtkd-3 lib. Why can't I just link against the gtk-3 lib then? I have now the headers to use the nice D stuff, but the linking should be done against the C-compiled library.
Re: Why using wrappers for D?
On Monday, 3 October 2016 at 12:15:10 UTC, rikki cattermole wrote: To use any kind of function you must declare it, plain and simple. Any c or c++ function/class is the very much same way. Now C++ types such as classes are highly limited in D since it doesn't ugh cross over all that well (it does some weird things). I don't know if we understand each other. You have to declare each function in the language you are programming, that is clear to me. So if you write in D, you need "D-Headers" (which are not called headers in D, i know). What do you mean with "Now C++ types such as classes are highly limited in D"? Why don't they "just" support them you ask? Yeah, that a D compiler can't read .h files is obvious to me :)
Re: Why using wrappers for D?
On Monday, 3 October 2016 at 12:47:48 UTC, Chalix wrote: I read a bit about creating libraries in C++, and I found out, this is not possible, because there is no definition of the API. It is possible, you just need to match compilers with the library in C++, whereas C libraries don't need such an exact match. With your Qt library, you get a build of it that is compatible with the compiler you use to build your application (either compiling it yourself or getting it from an OS package repo where they did it for you for your OS version) you mean by "turn C functions into classes"? Wrap the C functions inside D classes. So they write D code that calls the C functions, then you use their D code.
Re: Why using wrappers for D?
On Monday, 3 October 2016 at 12:12:44 UTC, Adam D. Ruppe wrote: A lot of people like the wrappers as being prettier to use since you can turn C functions into classes and such. gtkd is an example of that. Thanks for your fast answers :) Hm, I thing I am missing some fundamentals... I read a bit about creating libraries in C++, and I found out, this is not possible, because there is no definition of the API. So you need some C "factory methods" to load C++ classes. So is it possible now by D to load a class directly, or what do you mean by "turn C functions into classes"? Also, I used the Qt library a lot with C++. But although it is a library, I have access to all the classes, like " QWidget w = new QWidget();". There is no factory method used. (This confuses me now a bit...) If its too much to explain within some sentences, maybe you know something where I could read more about it? I did not find anything myself. But I really want to understand what's going on. Of course, it is simple, just bring over the necessary struct, constant, and function prototypes and it just works. I have to try it :D
Re: Why using wrappers for D?
On Monday, 3 October 2016 at 12:08:54 UTC, Chalix wrote: Hi All! The documentation of D (https://dlang.org/overview.html#compatibility) says: "Direct Access to C API's Not only does D have data types that correspond to C types, it provides direct access to C functions. There is no need to write wrapper functions, parameter swizzlers, nor code to copy aggregate members one by one." So, if there is no need for wrapper functions, why are there a lot of them? For example, GTK+ is a C library, with C-include files. Now there exists the GtkD (http://gtkd.org/) library, which describes itself as a wrapper of GTK+. GtkD contains the .d files (which I need for import, of course) and a seperate library (libgtkd-3.so). If D has direct Access to C API's, why do we need this the gtkd-3 lib, and not just use the gtk-3 lib? Furthermore, if there is an not very popular C library, where no wrapper function exists, would it possible to include it into a D project? Probably I have to transform all the .h to .d files, so i can "import" them instead of "include" them. But then, could I link against the C-library? I did not understand the concept of interaction between C and D, and I am a bit confused about wrapper functions and bindings for D now... Would be great if someone could make it a bit more clear to me :) D provides ways to do things that C or C++ don't provide (otherwise we wouldn't be using it). C/C++ functions and structures are designed to fit well in C/C++, not in D. To make them easy to use and avoid code of mixed style we build up a facade : the wrapper. That's all.
Re: Why using wrappers for D?
On 04/10/2016 1:08 AM, Chalix wrote: Hi All! The documentation of D (https://dlang.org/overview.html#compatibility) says: "Direct Access to C API's Not only does D have data types that correspond to C types, it provides direct access to C functions. There is no need to write wrapper functions, parameter swizzlers, nor code to copy aggregate members one by one." So, if there is no need for wrapper functions, why are there a lot of them? For example, GTK+ is a C library, with C-include files. Now there exists the GtkD (http://gtkd.org/) library, which describes itself as a wrapper of GTK+. GtkD contains the .d files (which I need for import, of course) and a seperate library (libgtkd-3.so). If D has direct Access to C API's, why do we need this the gtkd-3 lib, and not just use the gtk-3 lib? Furthermore, if there is an not very popular C library, where no wrapper function exists, would it possible to include it into a D project? Probably I have to transform all the .h to .d files, so i can "import" them instead of "include" them. But then, could I link against the C-library? I did not understand the concept of interaction between C and D, and I am a bit confused about wrapper functions and bindings for D now... Would be great if someone could make it a bit more clear to me :) Ok lets get a few things straight. To use any kind of function you must declare it, plain and simple. Any c or c++ function/class is the very much same way. Now C++ types such as classes are highly limited in D since it doesn't ugh cross over all that well (it does some weird things). These kinds of declarations are called bindings. We must have them since the D compilers don't support reading header files. Why don't they "just" support them you ask? Well simple, that's a whole new frontend that we must support... Walter is quite opposed to the idea and rightly so. So the real interesting question, why do we have wrappers around e.g. c++ libs? Simple, the original C++ code was designed for C++ and we can simply do those interfaces better. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Why using wrappers for D?
On Monday, 3 October 2016 at 12:08:54 UTC, Chalix wrote: So, if there is no need for wrapper functions, why are there a lot of them? A lot of people like the wrappers as being prettier to use since you can turn C functions into classes and such. gtkd is an example of that. Furthermore, if there is an not very popular C library, where no wrapper function exists, would it possible to include it into a D project? Of course, it is simple, just bring over the necessary struct, constant, and function prototypes and it just works.
Why using wrappers for D?
Hi All! The documentation of D (https://dlang.org/overview.html#compatibility) says: "Direct Access to C API's Not only does D have data types that correspond to C types, it provides direct access to C functions. There is no need to write wrapper functions, parameter swizzlers, nor code to copy aggregate members one by one." So, if there is no need for wrapper functions, why are there a lot of them? For example, GTK+ is a C library, with C-include files. Now there exists the GtkD (http://gtkd.org/) library, which describes itself as a wrapper of GTK+. GtkD contains the .d files (which I need for import, of course) and a seperate library (libgtkd-3.so). If D has direct Access to C API's, why do we need this the gtkd-3 lib, and not just use the gtk-3 lib? Furthermore, if there is an not very popular C library, where no wrapper function exists, would it possible to include it into a D project? Probably I have to transform all the .h to .d files, so i can "import" them instead of "include" them. But then, could I link against the C-library? I did not understand the concept of interaction between C and D, and I am a bit confused about wrapper functions and bindings for D now... Would be great if someone could make it a bit more clear to me :)
Re: Getting GtkD working with OpenGL
On Sunday, 18 September 2016 at 21:41:45 UTC, Mike Wey wrote: The demo still uses the old GtkGLExt binding, which usually isn't available in de distributions repositories. The newer GLArea is easier to use since it's part of GTK. As for the linker errors, you'll need to link with the OpenGL libraries: "-L-lGL -L-lGLU" Hey, thanks for your fast answer! I had a lot of other work to do, so I could only continue working on this project now. Yeah, that solved my problem :) Now it links. Although if I execute the program, it complains about the missing GtkGLExt library, like expected... Library load failed: libgdkglext-3.0.so.0 So I wanted to install this library from here: https://projects.gnome.org/gtkglext/download.html but the ./configure script tells me, No package 'pangox' found (pangox >= 1.0.0) I looked at the folder /usr/lib/x86_64-linux-gnu/ and there is a file called "libpangox-1.0.so.0.0.0". So I don't know, why this is not working... Anyway, I want to follow Mikes advice and use GLArea instead, so if there is not a quick fix available, lets skip the problems with the GtkGLExt library... But, sadly enough, I did not get GLArea working, too. The documentation https://developer.gnome.org/gtk3/stable/GtkGLArea.html says, I have to connect my render function to the widget like this: g_signal_connect (gl_area, "render", G_CALLBACK (render), NULL); But, my compiler can't find the g_signal_connect method (and the GL Methods...): main.d(22): Error: undefined identifier 'g_signal_connect' main.d(39): Error: undefined identifier 'glClearColor' main.d(40): Error: undefined identifier 'glClear' There might some include files (or import files, as you say in D) missing, but I could not figure out, where to find them for D... Could you tell me, where this g_signal_connect method can be found? And what I have to include for the GL functionality? Simply "import gtk.GLArea;" does not do the trick... Btw, is g_signal_connect a GTK method? I intend to use my program platform independent, so if this is dependent on gnome, it would not be good. Or is there any other way to get the GLArea working? I am used to the Qt Libraries, where you create a QGLWidget and simply override the init and render functions. Thanks for reading this far, would be great if we could solve this problem :D
Re: bug, or is this also intended?
On 10/03/2016 01:40 PM, deed wrote: Unexpected auto-concatenation of string elements: string[] arr = ["a", "b" "c"];// ["a", "bc"], length==2 int[] arr2 = [[1], [2] [3]];// Error: array index 3 is out of bounds [2][0 .. 1] // Error: array index 3 is out of bounds [0..1] dmd 2.071.2-b2 Intended but on its way out. 2.072.0-b1 tells you it's deprecated.
bug, or is this also intended?
Unexpected auto-concatenation of string elements: string[] arr = ["a", "b" "c"];// ["a", "bc"], length==2 int[] arr2 = [[1], [2] [3]];// Error: array index 3 is out of bounds [2][0 .. 1] // Error: array index 3 is out of bounds [0..1] dmd 2.071.2-b2
Re: vibe.d Logger
On 2016-10-03 12:36, Chris wrote: Is this the preferred logging module for vibe.d: http://vibed.org/api/vibe.core.log/ There is also: http://vibed.org/api/vibe.http.log/ which is there for backwards compatibility? The second one is specific for HTTP. The first one is generic. -- /Jacob Carlborg
vibe.d Logger
Is this the preferred logging module for vibe.d: http://vibed.org/api/vibe.core.log/ There is also: http://vibed.org/api/vibe.http.log/ which is there for backwards compatibility?
Re: How to debug (potential) GC bugs?
If it's heap corruption, GC has debugging option -debug=SENTINEL - for buffer overrun checks. Also that particular stack trace shows that object being destroyed is allocated in bin 512, i.e. its size is between 256 and 512 bytes.
Re: Implicit casting of int enum members to int
On Sunday, October 02, 2016 18:31:11 Mike Bierlee via Digitalmars-d-learn
wrote:
> Consider the following code:
>
> enum StringTypeEnumOne : string {
> bla = "bla"
> }
>
> enum StringTypeEnumTwo : string {
> bleh = "bleh"
> }
>
> enum IntTypeEnumOne : int {
> bla = 1
> }
>
> enum IntTypeEnumTwo : int {
> bleh = 2
> }
>
> public void main() {
> string[] strings = [StringTypeEnumOne.bla,
> StringTypeEnumTwo.bleh];
> int[] ints = [IntTypeEnumOne.bla, IntTypeEnumTwo.bleh];
> }
>
> When compiled the following compilation error is thrown:
> src\app.d(19,16): Error: cannot implicitly convert expression
> (cast(IntTypeEnumOne)1) of type IntTypeEnumOne to IntTypeEnumTwo
>
> The string members are implicitly cast just fine, however I also
> expected the members of the int enum to be cast implicitly
> because I explicitly defined the base type of the enum.
>
> Is this a bug in D? Or is using an int as base type the same as
> having no base type at all?
It looks like a bug. In theory, when you create an array literal like that,
it should choose the common type of all of the values in it (and result in a
compilation error if that doesn't work), though I recall there being bugs
with that and classes (with it just selecting the type of the last value
IIRC), so it doesn't entirely surprise me if you're seeing bugs with it. If
both of the values were from the same enum, I would expect that the
resulting type would be a dynamic array of that enum type, and the
initialization of ints would then fail, but with them being different enum
types with the base type of int, it really should result in int[], which
would succeed. So, it does look like you've found a bug, and the fact that
it works with enum types with a base type of string but not int is
particularly bizarre.
- Jonathan M Davis
Re: How to debug (potential) GC bugs?
On Sunday, 25 September 2016 at 16:23:11 UTC, Matthias Klumpp wrote: For Ubuntu, some modifications on the code were needed, and apparently for them the code is currently crashing in the GC collection thread: http://paste.debian.net/840490/ Oh, wait, what do you mean by crashing?
Re: dmd -o- option meaning changed recently? Now not creating OBJ but also not creating EXE
On Sunday, 2 October 2016 at 21:05:25 UTC, A D dev wrote: One last point: If that was always the behavior (in all versions from 2010 - or earlier), i.e. -o- generates neither .OBJ nor .EXE, then what is the purpose of the option? does it act as just a syntax check? Purpose is to skip code generation and only do syntax/semantic validation. Very helpful when testing compiler because: a) it takes less time speeding up overall test suite b) doesn't require runtime static library to succeed, thus simplifying setup
Re: Usage of DDOC_KEYWORD and DDOC_TEMPLATE_PARAM macros
On 2016-09-27 22:21, Jacob Carlborg wrote: I'm working on a Ddoc theme and I have trouble figuring out when the DDOC_KEYWORD and DDOC_TEMPLATE_PARAM macros are used. Are the compiler outputting them or should the developer be using those directly? If the compiler is outputting them, then when is it doing that? Turns out DDOC_KEYWORD is only used for "true", "false" and "null". It looks like the implementation of DDOC_TEMPLATE_PARAM is broken. -- /Jacob Carlborg
Re: How to debug (potential) GC bugs?
On Saturday, 1 October 2016 at 00:06:05 UTC, Matthias Klumpp wrote: I do none of those things in my code though... `grep "~this" *.d` gives nothing? It can be a struct with destructor stored in a class. Can you observe the error? Try to set a breakpoint at onInvalidMemoryOperationError https://github.com/dlang/druntime/blob/master/src/core/exception.d#L559 and see what stack leads to it. Unfortunately for having deterministic memory management, I would essentially need to develop GC-less, and would loose classes. This means many nice features of D aren't available, e.g. I couldn't use interfaces (AFAIK they don't work on structs) or constraints. Not necessarily. You only need to dispose the resources in time, like in C#. But if you don't have destructors, you have nothing to dispose. Strangely after switching from the GDC compiler to the LDC compiler, all crashes observed at Ubuntu are gone. Sounds not good.
Re: Class attributes
On Sunday, 2 October 2016 at 17:22:57 UTC, Basile B. wrote:
On Sunday, 2 October 2016 at 15:54:38 UTC, Satoshi wrote:
Hello,
why
pure @safe nothrow @nogc struct Point {
}
isn't same as
struct Point {
pure: @safe: nothrow: @nogc:
}
??
This is not specified but attributes aren't applied to the
scope created by the declaration. Which is a good thing, for
example with the visibility attributes it would be a problem,
imagine the following declarations:
struct Foo(T)
{
private struct Range // imagine that private as a inner
"private:"
{
void popFront(); // would be private !!
bool empty(); // would be private !!
T front(); // would be private !!
}
}
So this is really not something anyone would want.
But shared or abstract attribute can be applied to scope created
by class so nothrow @safe @nogc or pure should be too.
It should follow same rules as in function declaration.
void test() @safe {
void thisFunctionIsSafeToo() {
}
}
