Re: Dub and GtkD
On 12/23/13 19:30, Mike Wey wrote: > On 12/22/2013 10:00 PM, Artur Skawina wrote: >> On 12/22/13 20:21, Mike Wey wrote: >>> On 12/22/2013 03:36 PM, Russel Winder wrote: Python now uses the reflection approach to providing a Python binding to the API: PyGTK has given way to PyGobject. Has the PyGobject approach been rejected for GtkD staying with the PyGtk approach? >>> >>> I don't think that would be a good approach with D, you either need a whole >>> lot of compile time magic, or loose type safety and do everything at >>> runtime. >> >> It's not that bad; no compile time magic and zero runtime overhead is >> possible: http://repo.or.cz/w/girtod.git/tree/gtk2:/gtk2 >> >> While I haven't updated those bindings in ~ two years, they should >> still work; may just need some tweaks, to deal with recent d language >> changes and to support newer lib features. The biggest remaining issue >> is lack of integrated Cairo bindings. > > Those are generated from the gir files beforehand like GtkD is generated from > the documentation (Moving to a gir based generator is on the TODO list, but > time currently doesn't permit it). While with the PyGobject approach the > bindings aren't generated beforehand but everything is done at runtime. Didn't realize that. It kind of makes sense for a scripting language which does not care about performance at all[1]. It doesn't for a compiled language like D, where the equivalent would be to extract the gi/typelib data at /compile-time/. Which could be done via CTFE and mixins. But, as the lib i/f is very stable, it's much better to pay the conversion cost once and use a cached, pre-built version. The only advantage of parsing the introspection data at run-time would be that you could use a compiled D binary to access libs that it didn't know about at build time. Writing programs that use dlls w/o having any idea about the interface that those libs provide isn't exactly common. All checks would have to be done at runtime, which is what "loose type safety" meant, i guess. It didn't occur to me that somebody might want this functionality in a compiled statically typed language. Something that /was/ on my to-do list is a binary gtk-server like approach, that would allow decoupling the gui parts from the "core" application. In D this could be done transparently, with full type safety and negligible runtime cost (might still be cheaper than using gtkd). artur [1] If it did, it could just build (and cache) a bindings-dll on first use, avoiding ffi etc. Probably only matters in practice if you're already JITting the code anyway, as dealing with the args will be expensive.
Re: Dub and GtkD
On 12/22/2013 10:00 PM, Artur Skawina wrote: On 12/22/13 20:21, Mike Wey wrote: On 12/22/2013 03:36 PM, Russel Winder wrote: Python now uses the reflection approach to providing a Python binding to the API: PyGTK has given way to PyGobject. Has the PyGobject approach been rejected for GtkD staying with the PyGtk approach? I don't think that would be a good approach with D, you either need a whole lot of compile time magic, or loose type safety and do everything at runtime. It's not that bad; no compile time magic and zero runtime overhead is possible: http://repo.or.cz/w/girtod.git/tree/gtk2:/gtk2 While I haven't updated those bindings in ~2 two years, they should still work; may just need some tweaks, to deal with recent d language changes and to support newer lib features. The biggest remaining issue is lack of integrated Cairo bindings. artur Those are generated from the gir files beforehand like GtkD is generated from the documentation (Moving to a gir based generator is on the TODO list, but time currently doesn't permit it). While with the PyGobject approach the bindings aren't generated beforehand but everything is done at runtime. -- Mike Wey
Re: Dub and GtkD
On 12/22/13 20:21, Mike Wey wrote: > On 12/22/2013 03:36 PM, Russel Winder wrote: >> >> Python now uses the reflection approach to providing a Python binding to >> the API: PyGTK has given way to PyGobject. Has the PyGobject approach >> been rejected for GtkD staying with the PyGtk approach? > > I don't think that would be a good approach with D, you either need a whole > lot of compile time magic, or loose type safety and do everything at runtime. It's not that bad; no compile time magic and zero runtime overhead is possible: http://repo.or.cz/w/girtod.git/tree/gtk2:/gtk2 While I haven't updated those bindings in ~2 two years, they should still work; may just need some tweaks, to deal with recent d language changes and to support newer lib features. The biggest remaining issue is lack of integrated Cairo bindings. artur
Re: Dub and GtkD
On 12/22/2013 03:36 PM, Russel Winder wrote:
On Sun, 2013-12-22 at 12:58 +0100, Mike Wey wrote:
On 12/21/2013 11:19 PM, qznc wrote:
[…]
For some reason GtkD uses some unreleased version of Gtk with some
OpenGL features.
This is because the released version of GtkGLext doesn't support Gtk+ 3.x.
OK so that is why it isn't in Debian.
Does Fedora 20 or RPM Fusion have the pre-release as a package?
Not as far as i know.
You can use the "normal/stable" variant by adapting
your dependency a little:
"dependencies": { "gtk-d:gtkd": "~master" }
Just depending on the subpackage you need will stop dub from including
the other parts of GtkD in your app. So this should fix your problem.
OK, that can work for me.
Python now uses the reflection approach to providing a Python binding to
the API: PyGTK has given way to PyGobject. Has the PyGobject approach
been rejected for GtkD staying with the PyGtk approach?
I don't think that would be a good approach with D, you either need a
whole lot of compile time magic, or loose type safety and do everything
at runtime.
I am currently rewriting a gtkmm application I had in GtkD and once a
few problems of connectSignals is solved I am going to be loving it,
thanks for keeping it going.
--
Mike Wey
Re: Dub and GtkD
On Sun, 2013-12-22 at 12:58 +0100, Mike Wey wrote:
> On 12/21/2013 11:19 PM, qznc wrote:
[…]
> > For some reason GtkD uses some unreleased version of Gtk with some
> > OpenGL features.
>
> This is because the released version of GtkGLext doesn't support Gtk+ 3.x.
OK so that is why it isn't in Debian.
Does Fedora 20 or RPM Fusion have the pre-release as a package?
> > You can use the "normal/stable" variant by adapting
> > your dependency a little:
> >
> > "dependencies": { "gtk-d:gtkd": "~master" }
>
> Just depending on the subpackage you need will stop dub from including
> the other parts of GtkD in your app. So this should fix your problem.
OK, that can work for me.
Python now uses the reflection approach to providing a Python binding to
the API: PyGTK has given way to PyGobject. Has the PyGobject approach
been rejected for GtkD staying with the PyGtk approach?
I am currently rewriting a gtkmm application I had in GtkD and once a
few problems of connectSignals is solved I am going to be loving it,
thanks for keeping it going.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Dub and GtkD
On 12/21/2013 11:19 PM, qznc wrote:
On Saturday, 21 December 2013 at 14:52:08 UTC, Russel Winder wrote:
I just created a new vibe.d project using dub, all fine. Well once I had
solved the libevent problem. Then, as the project is to be a GUI client,
I added a gtk-d dependency. I tried building the empty project and the
binary comes out at 42MB. Not only that there are two copies of it one
in . and one in ./.dub/build. I was gobsmacked, this isn't Go, there
should be dynamic linking by default. Is this something I have missed?
There ought to be a clean target for dub as well as a build and run
target for dub, or have I missed something?
Re GtkD, when I run the "Hello World" vibe.d web server with GtkD doing
nothing, I get:
|> dub
Checking dependencies in
'/home/users/russel/Repositories/Git/Masters/ArcamClient_D'
Target is up to date. Skipping build.
Running ./arcamclient
Listening for HTTP requests on ::1:8080
Listening for HTTP requests on 127.0.0.1:8080
Please open http://127.0.0.1:8080/ in your browser.
object.Exception@../../../../.dub/packages/gtk-d-master/src/gtkc/Loader.d(127):
Library load failed: libgtkglext-3.0.so.0
Error: Program exited with code 1
In an earlier thread here, Mike Wey's response was "download libgtkglext
and build it yourself". I am not sure this is the right approach. Debian
packages GNOME 3 quite well but they do not have this
libgtkglext-3.0.so.0 and yet things work. I think mayhap GtkD should
have this as an optional dependency rather than a mandatory one. Or am I
missing something?
For some reason GtkD uses some unreleased version of Gtk with some
OpenGL features.
This is because the released version of GtkGLext doesn't support Gtk+ 3.x.
You can use the "normal/stable" variant by adapting
your dependency a little:
"dependencies": { "gtk-d:gtkd": "~master" }
Just depending on the subpackage you need will stop dub from including
the other parts of GtkD in your app. So this should fix your problem.
Not sure, why GtkD does this. There are also no versions, just "~master".
--
Mike Wey
Re: Dub and GtkD
On Saturday, 21 December 2013 at 14:52:08 UTC, Russel Winder
wrote:
I just created a new vibe.d project using dub, all fine. Well
once I had
solved the libevent problem. Then, as the project is to be a
GUI client,
I added a gtk-d dependency. I tried building the empty project
and the
binary comes out at 42MB. Not only that there are two copies of
it one
in . and one in ./.dub/build. I was gobsmacked, this isn't Go,
there
should be dynamic linking by default. Is this something I have
missed?
There ought to be a clean target for dub as well as a build and
run
target for dub, or have I missed something?
Re GtkD, when I run the "Hello World" vibe.d web server with
GtkD doing
nothing, I get:
|> dub
Checking dependencies in
'/home/users/russel/Repositories/Git/Masters/ArcamClient_D'
Target is up to date. Skipping build.
Running ./arcamclient
Listening for HTTP requests on ::1:8080
Listening for HTTP requests on 127.0.0.1:8080
Please open http://127.0.0.1:8080/ in your browser.
object.Exception@../../../../.dub/packages/gtk-d-master/src/gtkc/Loader.d(127):
Library load failed: libgtkglext-3.0.so.0
Error: Program exited with code 1
In an earlier thread here, Mike Wey's response was "download
libgtkglext
and build it yourself". I am not sure this is the right
approach. Debian
packages GNOME 3 quite well but they do not have this
libgtkglext-3.0.so.0 and yet things work. I think mayhap GtkD
should
have this as an optional dependency rather than a mandatory
one. Or am I
missing something?
For some reason GtkD uses some unreleased version of Gtk with
some OpenGL features. You can use the "normal/stable" variant by
adapting your dependency a little:
"dependencies": { "gtk-d:gtkd": "~master" }
Not sure, why GtkD does this. There are also no versions, just
"~master".
Re: Dub and GtkD
On 2013-12-21 15:51, Russel Winder wrote: I just created a new vibe.d project using dub, all fine. Well once I had solved the libevent problem. Then, as the project is to be a GUI client, I added a gtk-d dependency. I tried building the empty project and the binary comes out at 42MB. Not only that there are two copies of it one in . and one in ./.dub/build. I was gobsmacked, this isn't Go, there should be dynamic linking by default. Is this something I have missed? There ought to be a clean target for dub as well as a build and run target for dub, or have I missed something? I don't know if this is the issue in this case but Dub build everything at once. The correct solution in this case would be to build GtkD separate from the application. This is planed in a future release of Dub, hopefully the next release. Have a look at this thread: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/652/ -- /Jacob Carlborg
Dub and GtkD
I just created a new vibe.d project using dub, all fine. Well once I had solved the libevent problem. Then, as the project is to be a GUI client, I added a gtk-d dependency. I tried building the empty project and the binary comes out at 42MB. Not only that there are two copies of it one in . and one in ./.dub/build. I was gobsmacked, this isn't Go, there should be dynamic linking by default. Is this something I have missed? There ought to be a clean target for dub as well as a build and run target for dub, or have I missed something? Re GtkD, when I run the "Hello World" vibe.d web server with GtkD doing nothing, I get: |> dub Checking dependencies in '/home/users/russel/Repositories/Git/Masters/ArcamClient_D' Target is up to date. Skipping build. Running ./arcamclient Listening for HTTP requests on ::1:8080 Listening for HTTP requests on 127.0.0.1:8080 Please open http://127.0.0.1:8080/ in your browser. object.Exception@../../../../.dub/packages/gtk-d-master/src/gtkc/Loader.d(127): Library load failed: libgtkglext-3.0.so.0 Error: Program exited with code 1 In an earlier thread here, Mike Wey's response was "download libgtkglext and build it yourself". I am not sure this is the right approach. Debian packages GNOME 3 quite well but they do not have this libgtkglext-3.0.so.0 and yet things work. I think mayhap GtkD should have this as an optional dependency rather than a mandatory one. Or am I missing something? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
