Hi Leo, On Mon, 02 Nov 2020 14:51:42 +0100 Leo Prikler wrote: > As much as I rant about nomad in IRC now and then, it is still a rather > sophisticated program, and as a user I have not yet encountered any > problem similar in effect to what is described here. Thanks. That is good to know! I've now gotten guile-gi to work okay for me, too. For me, there were many reasons why it didn't work before--some of them follow: (1) I originally built guile-gi from source using guix environment --pure guile-gi --ad-hoc guile autoconf automake gettext texinfo (2) I originally used the following to run guix-gui guix environment -l ${HOME}/src/guile-gi/guile-gi-dannym/guile-gi/guix.scm --preserve=XAUTHORITY --preserve=DISPLAY --preserve=G_MESSAGES_DEBUG --ad-hoc guile gdk-pixbuf adwaita-icon-theme shared-mime-info guix gtk+ guile-readline -- ${HOME}/src/guile-gi/guile-gi-dannym/guile-gi/tools/uninstalled-env guix repl -L . "$@" (3) gobject-introspection refers to cairo-gobject, but does not embed the store path to it (it would cause a cycle). There was (an old) cairo-gobject in my user profile, which was picked up (4) Additionally (in parallel), gtk+ in guix environment refers to a newer gtk than I had in my profile. Furthermore, guix environment entries depend on glib-with-documentation and similar. Adding "--pure" to my "guix environment" invocation DID NOT fix the problem. In any case, using guix environment --pure -l guix.scm --preserve=XAUTHORITY --preserve=DISPLAY --preserve=G_MESSAGES_DEBUG --ad-hoc guile adwaita-icon-theme shared-mime-info guix guile-readline -- guix repl -L . "$@" (note: "-l guix.scm") seems to have fixed most of the problems. (There is no automated diagnostic--so who knows whether it did fix them for real?) I rate the development experience on Guix in this case at about -15 of 10 points :P The following bad diagnostics conspired: (1) guix environment --pure picked up TWO different glib. Even though both packages are named the same ("glib") and one is hidden and one is not hidden and both were used in the environment anyway, no warning was emitted. That is very bad! (2) Even though GNOME does not like having two different gobjects loaded, it did so anyway and caused difficult-to-diagnose problems. gobject-introspection is not built such that it dlopens libraries in a way that if there are duplicate global symbols, it fails. Therefore, there was not even a failure caused at dlopen time. Additionally, there was no high-level failure being caused at any point. It just did the wrong things and continued running until eventually crashing because of a low-level failure (memory allocation, runtime C glib type checking etc). Before all this, I know that weird things like that could happen so I tried using something like guix environment --ad-hoc pkg1 pkg2 -e '(@ (gnu packages foo) pkg3)' pkg4 in the very beginning--and that didn't work either because this way of using "-e" is not supported. > I am not sure, whether the Nomad devs have encountered a problem > similar to Guile-GI#96 (I myself am not one), but the Guile-GI devs > speculate, that the problem is somewhat specific to their > implementation. guile-gi seems to think that it's their fault--but I disagree. Changing it in guile-gi would fix nothing, because gobject-introspection does the exact same thing. In fact, let me tell them again. This was both my fault, and guix's fault for being VERY obtuse. > They also mention, that you should still be able to prototype your > application by using "--no-grafts" for the development environment. If I pass --no-grafts, I cannot read any letters anymore (they are boxes). See attachment. So I cannot use that. Also, it is unsafe to do that. Grafts are there for a reason, namely security updates. > Do you still encounter Guile-GI#96 after packaging? I've not finished packaging it yet (I tried--but that's pretty difficult, too! Help wanted--see README and guix.scm in the guix-gui repo). > Sure, but that's only if either of them ends up using a different > version. It's easy for this to happen. I did not go out of my way to make it happen--quite the opposite. > > If a library A has an input Q, and library B has the same input Q, > > and you > > use A and B in your program, and then you (guix-) update just B to > > use Q' > > (for example a newer version of Q) and recompile your program, then > > you have > > both Q and Q' in your process address space! > > > > Q is an internal dependency of A, and by coincidence it's an internal > > dependency of B, too. Just because the internal dependency of B > > changed > > shouldn't change the internal depenency of A--that's what "internal" > > means. > Sure, but that's only if either of them ends up using a different > version. That should not be the case for Guix' GNOME stack apart from > some bootstrap shenanigans, that don't really matter at the point of > application packages. > > In order to make use of any GI in Guix, you need > - the GI bindings (one of python-gobject, g-golf, guile-gi, gjs, etc.), > - *and* the packages of the libraries themselves > as inputs to your package. So the resulting graph for your package > will always be complete and should only contain one relevant package > per library. It is good to know that guix guarantees to only have one libgobject (i.e. "glib" package derivation) in this case. I therefore withdraw the propagated-input proposal. > [having two different libgobject in the same process] should not be the case > for Guix' GNOME stack apart from [bootstrapping] When using guix environment, it is easy for this to happen in Guix's GNOME. Grafting, different glib-with-or-without-documentation packages and propagated inputs in profiles propagating cairo-gobject into my user profile (not to mention stuff in the SYSTEM profile) and guix environment being obtuse not only make this possible, but make it a regular occurence when using guix environment. I think the first step in fixing this is actually automatically diagnosing this problem, which Guix (and gobject-introspection) do not do right now. As it is now, often there are two different libgobjects being loaded at the same time, and those register their types in the respective type registry. Depending on who talks to which registry, they get different actual implementers back. Which registry you talk to also determines whether you will get "the type doesn't exist" back or not (which is how it should be (!), and fine if people talked to the correct respective registry--which they don't). So the current (and maybe perpetual) state is that GNOME does not support this (and they really don't need to support it), so somebody (possibly gobject-introspection) should be catching it, if necessary at runtime. They don't. > > Does anyone know how to make dlopen fail on duplicate global > > variables? > No, but I don't think that is too relevant here. See my earlier point > on how it *is* possible to handle this with the methods GLib provides. (1) This would make it extremely easy to find problems like this now. So it's relevant in the sense of it could have spared both me and the guile-gi devs a LOT of time. (2) It would make it possible to find problems of this kind in the future. I do not want to keep fixing the same thing over and over again. I want there to be an automated check in place so if there are problems, they are automatically detected. In this case I want dlopen to fail in this case and not be able to load a second libgobject in the first place--neither directly nor indirectly. (Evidently, programs and *GNOME's own libraries* are not designed for the alternative of two libgobject libraries loaded in the same process--so gobject-introspection should not allow it in the first place) > Am Donnerstag, den 29.10.2020, 20:34 +0100 schrieb Danny Milosavljevic: > > Or I could just use Gtk in C and use popen("guix ..."). > You're probably joking, but you should know, that I had moderate > success passing around just data from Guile to Gtk while not using g- > golf or guile-gi. You could either do all your conversions in C like I > did back then or declare your own data models as C structs and then > fill them from guile using e.g. guile-bytestructures. > Obviously, it would be nicer if one could program the GUI itself in > Guile, but you are free to make the choices you feel are fitting. I don't want to maintain data structure marshallers that add no value to anything. One of the touted advantages of using guix as a package manager is that you don't need to do that anymore--you just use guile as a general-purpose programming language and not keep manually translating back and forth between different incompatible environments, with all the impedance mismatch, slowness, different semantics, protocol versioning and bugs that that entails. Using gtk on guile also already makes me sometimes force a square peg into a round hole--that should be enough. > [expose guix via dbus] You should keep in mind for this approach: impedance mismatch, slowness, different semantics, protocol versioning, and bugs in dbus (the latter of which I also regularily experience in guix--dbus bus hangs etc). The advantages you listed of better and easier privilege checking are valid, though. (In addition, I don't want a hard dependency to gtk+ in the guix package manager. But that can be avoided in other ways, too). I should note that I'm on regular guix master with no custom patches. If I do patches, it's always in a ./pre-inst-env, never on the system I use. The following is historical and not current anymore: $ guix environment --pure -l ${HOME}/src/guile-gi/guile-gi/guix.scm --preserve=XAUTHORITY --preserve=DISPLAY --preserve=G_MESSAGES_DEBUG --ad-hoc guile gdk-pixbuf adwaita-icon-theme shared-mime-info guix gtk+ guile-readline -- ${HOME}/src/guile-gi/guile-gi/tools/uninstalled-env guix repl -L . guix-gui.in (see "run" in repository below) (note: I do not preserve any GI environment variables) using https://gitlab.com/daym/guix-gui/-/tree/002e931232c818f9100b5ea622a52bd6b20b9a0e and https://github.com/spk121/guile-gi/commit/b454a99b65f927e947faab17d25bd3499829c1b4 as guile-gi I incessantly encounter this: Frequent runtime problems at different points in time while the program is running, that has been traced (in an automated way) to two different libgobject being used at the same time.