gmane.lisp.guile.gtk

Re: guile-gnome . problems getting started

Andy Wingo — 2008-09-24T14:07:14

(use-modules (oop goops) (gnome-2) (gnome gobject)) should be sufficient to start the demo. Andy

Re: guile-gnome . problems getting started

tantalum — 2008-09-23T18:32:29

> I assume you mean (gnome gobject), right? yes. but now i cant be sure what modules i _really need at which point in the doc since my (gnome-2) version is not correcly initializing. but if you can fix something of the like i mentioned, that would be nice. thanks. im using a x86_64 (amd64) linux (arch linux)

Re: guile-gnome . problems getting started

Andy Wingo — 2008-09-22T17:35:40

Hi, On Thu 18 Sep 2008 23:20, 53 gmx.de> writes: Uf, I'm sorry that it's so difficul to install. I assume you mean (gnome gobject), right? I fixed this in bzr, will push new docs when I push a new version. How is this going? Using (gnome-2) or running as guile-gnome-2 should set up your environment correctly. What platform are you on, is it a BSD? Cheers, Andy

Re: guile-gnome . problems getting started

tantalum — 2008-09-20T13:19:01

thanks for the reply. ok. "(gnome-2)" was loaded, and using "guile-gnome-2" or manually setting LD_LOAD_PATH to "/usr/lib" or "/usr/lib/guile-gnome-2" gives the same result. i tried recompiling guile because i was a bit unsure if its install really went correctly, and now have issues recompiling. i will try to get this working first. regards

Re: guile-gnome . problems getting started

Patrick Bernaud — 2008-09-19T08:13:03

Hi, 53 writes: > [...] > previously exporting 'GUILE_LOAD_PATH' with '/usr/lib/guile-gnome-2/' > doesnt help That's because GUILE_LOAD_PATH is not the correct variable to set. You have to add this path to LD_LIBRARY_PATH instead. The (gnome-2) module should do that for you: include it before any other guile gnome module. Or use the guile-gnome-2 script in place of simple guile (see the comment at the beginning of this file). HTH, Patrick

guile-gnome . problems getting started

53 — 2008-09-18T21:20:52

hi everybody, im currently trying to use guile-gnome. guile-gnome 2.16.1 guile 1.8.5 after a day work to get all the dependencies installed, i now fail getting through this gobject tutorial: http://www.gnu.org/software/guile-gnome/docs/gobject/html/gnome-gobject.html btw, whoever is responsible, please dont let needed modules be mentioned in the explanation text; show it like other code snippets. i have a hard time with this inconsistency. if it even is one. heres what i get. after loading "(gnome gobject)" and "(gnome gtk)", mentioned in the explanations, it breaks with: --- WARNING: (gnome gtk): imported module (gnome gobject generics) overrides core binding `connect' WARNING: (gnome gtk): `re-export-modules' imported from both (gnome gobject utils) and (gnome gw support modules) Backtrace: In unknown file: ?: 47* (if (or # #) (try-load-module name)) ?: 48 [try-load-module (gnome gw gdk)] ?: 49 (or (begin (try-module-linked name)) (try-module-autoload name) ...) ?: 50* [try-module-au

Re: Just in case...

Rob Browning — 2008-08-12T23:26:13

Yes, though I'll have to find out what's appropriate since changes to some control fields can require a manual review by the ftpmasters. As it stands now, I don't think this will affect guile with respect to lenny. Note that if I recall correctly, m68k isn't a release critical architecture for lenny, so although I think it would be good to fix this, it may not affect guile's inclusion in lenny. Thanks for the help.

Re: Just in case...

Rob Browning — 2008-08-11T01:47:36

It looks like that (ia64) didn't go well at all... http://buildd.debian.org/fetch.cgi?pkg=guile-1.8;ver=1.8.5%2B1-3;arch=ia64;stamp=1218417608 Though I haven't had a chance to really look at it yet.

Re: Just in case...

Rob Browning — 2008-08-11T01:08:53

I've uploaded guile-1.8 1.8.5+1-3. Let me know if there are remaining issues. Thanks

Re: Just in case...

Rob Browning — 2008-08-08T01:35:40

OK, I'll try to have a new upload within the next few days. Thanks for the help

Re: Just in case...

Neil Jerram — 2008-08-07T21:58:14

2008/8/5 Rob Browning defaultvalue.org>: Thanks, I asked there, and someone pointed out my (rather silly) mistake. Fix is here: http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=adacd2dac5ad1c80a8faf8933c228533fb82cc80 If you could try a new upload with both this and the ia64 fix, hopefully we'll then have all architectures building. Thanks, Neil

Re: Just in case...

Rob Browning — 2008-08-05T07:15:00

Certainly. Just wish I'd done it sooner. In any case, I've notified debian-release, and presuming we can work out the remaining issues, I think things may be OK. OK, I'll install this in a new upload, perhaps tomorrow. One place to ask questions would probably be debian-hppa (http://www.debian.org/ports/hppa), and there's also the build log. In addition, I may be able to run some code on an hppa machine if we can figure out something appropriate. The patches should have made it. You can see the exact patch in the new source package in debian/patches/improve-stack-direction-test.diff. It should be very close to the upstream version. Hmm, I didn't know either, but here's a description: http://www.debian.org/devel/buildd/wanna-build-states Thanks

Re: Just in case...

Rob Browning — 2008-08-01T06:13:49

OK, I should be uploading packages that include Neil's two patches this weekend, if not sooner. Thanks

Re: the hue of death: setting color property crashes application

Andy Wingo — 2008-07-29T19:03:25

Hi, On Mon 28 Jul 2008 17:43, "gregory benison" gmail.com> writes: Wow, that's a nasty one. Good catch. As you say it probably affects GdkRectangle as well, and perhaps also GtkTreeIter. Your patch is good, will apply. Andy

the hue of death: setting color property crashes application

gregory benison — 2008-07-28T15:43:51

In the latest guile-gnome, setting a "color" property can cause a crash: G_SLICE=debug-blocks guile-gnome-2 GSlice: MemChecker: attempt to release non-allocated block: 0x81a50a8 size=12 Aborted Without 'debug-blocks', the crash is delayed, but will happen eventually because the heap is corrupted. The cause is a GdkColor* being allocated with g_new0(), but freed with g_slice_free1() rather than g_free(): - scm_scm_to_gdk_color() allocates a GdkColor* using g_new0(). - The new GdkColor* is packaged into a GValue* - g_object_set_property() is called - scm_set_gobject_property calls g_value_unset() on the GValue* - g_value_unset() calls gdk_color_free() which calls g_slice_free1() gdk_color_free() switched from using g_free() to g_slice_free1() with gtk+-2.10. Changing scm_scm_to_gdk_color() to use g_slice_new0() makes the bug go away, but I don't like that solution because it sets things up for another bug if future versions of GDK switch to use g_frobnitz_free() or whatever. It would be better to use a

Re: Just in case...

Neil Jerram — 2008-07-28T09:31:47

2008/7/25 Jon Wilson wilsonjc.us>: Thanks for the reminder. For core Guile I already had this in mind, and I hope that we will be able to release a 1.8.6 that builds on all architectures, and which is in time for the Lenny freeze. But on the other hand... - It shouldn't be the end of the world if we miss the freeze. There is backports, after all. - I worry slightly that we are ignoring the other distros! If users of other distros would like to pass on their freeze dates, please do so. Regards, Neil

Re: Just in case...

Andy Wingo — 2008-07-26T15:49:17

Hey Jon, On Fri 25 Jul 2008 17:23, Jon Wilson wilsonjc.us> writes: Adding Andreas to the Cc: -- Andreas, do you want help with guile-gnome packages? Andy

Just in case...

Jon Wilson — 2008-07-25T15:23:18

...anyone missed the announcement, Debian is going to freeze packages for Lenny quite soon. So, I humbly request that those responsible for such things get the latest and greatest of everything packaged up for Lenny before that happens. It is much easier to use various things, and to get others to accept their use, when they are included in a disto, so that they can be installed the "official" way. If there is anything I can do to help, let me know. My Debian packaging know-how is practically nil, but I learn fast. Regards, Jon

Re: guile-gnome-glib build error

Andy Wingo — 2008-07-24T10:49:15

Hi Andre, On Sat 19 Jul 2008 12:23, Andre Kuehne gmx.net> writes: version.texi is created by automake, if you're compiling from vc, but only in maintainer mode -- so try --enable-maintainer-mode, or update from bzr where I removed AC_MAINTAINER_MODE from the configure.ac. Cheers, Andy

Re: completion on guile-gnome symbols

Andy Wingo — 2008-07-24T10:46:29

Hi, On Mon 21 Jul 2008 14:27, "Neil Jerram" googlemail.com> writes: Sorry for the late reply. I agree this is the suck. Late-bound variables are stored in a hash, %gw-latent-variables-hash. The classes are stored in the g-wrap modules corresponding to the wrapsets, and the generics are stored in (gnome gw generics) -- there are some docs about this general strategy in guile-gnome-glib's docs. To force creation of all of those variables, just reference them in the modules. So for example to programmatically force creation of all symbols in some modules, try this: (define (force-bindings . modules) (for-each (lambda (sym) (let ((mod (resolve-module `(gnome gw ,sym)))) (for-each (lambda (k) (module-ref (module-public-interface mod) k)) ;; copy list of syms because the module binder mutates the hash (hash-map->list (lambda (k v) k) (module-ref mod '%gw-latent-variables-hash))))) modules)) ;; use like this (force-bindings '

Re: completion on guile-gnome symbols

Neil Jerram — 2008-07-21T12:27:24

2008/7/18 Andre Kuehne gmx.net>: +1. I've had exactly this problem in the past too. Neil