Guix Front End (GUI) and making it more mainstream, popular in scientific community.

Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Aniket Patil]

[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]

Hi all,

I am a researcher in the field of AI. Many of the people in the field of AI
are inclining towards GNU/Linux operating systems. Particularly I would say
they use Ubuntu. In general, they can also use LinuxMint or any other
GNU/Linux distro of their choice. What I noticed in these people
(researchers) they tend to be more focused on mathematical aspects and
scientific programming. If we build a GUI frontend then we can attract more
people who don't identify themselves with CLI users. As such there are many
people like writers, Graphic Designers, General users, etc. who don't
bother about CLI, will love to see such a package manager.  And considering
the fact GUIX lets rollback to the previous version of the package it will
be very helpful in the scientific community, to maintain and work with
different versions of packages.

For example, the LAMBDA ( consist of TensorFlow, PyTorch, Keras, NVIDIA
Cuda, Ubuntu) stack is very popular in the field of AI. Now if a person
with a fresh install of GNU/Linux wants to install the stack and work
immediately, through GUI he can search for the recipe of LAMBDA and install
it. Not only that if it doesn't exist, but they can also create and share
their own recipe with other guix users or to the main server/repo. E.g
Linus Torvalds shares the recipe of building a Linux kernel environment.
User finds it, installs it, and start working on the development of the
Linux kernel immediately.

P.S: I don't know whether GUI for Guix exists or not, to my knowledge it
doesn't. If I am mistaken please enlighten me on this topic.

Regards,
Aniket.

[-- Attachment #2: Type: text/html, Size: 1772 bytes --]

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[jbranso]

[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]

There is an Emacs interface in install Guix packages, but at present there is not a working GUI for installing packages with guix. :(

I think there may have been a web interface to install packages at some point? maybe?

For those interested in creating such a GUI, they might like to look at guile-gi, which will eventually let you build GUIs from guile code.

Thanks,

Joshua
https://gnucode.me

October 29, 2020 12:44 PM, "Aniket Patil" <aniket112.patil@gmail.com (mailto:aniket112.patil@gmail.com?to=%22Aniket%20Patil%22%20<aniket112.patil@gmail.com>)> wrote:
Hi all,
I am a researcher in the field of AI. Many of the people in the field of AI are inclining towards GNU/Linux operating systems. Particularly I would say they use Ubuntu. In general, they can also use LinuxMint or any other GNU/Linux distro of their choice. What I noticed in these people (researchers) they tend to be more focused on mathematical aspects and scientific programming. If we build a GUI frontend then we can attract more people who don't identify themselves with CLI users. As such there are many people like writers, Graphic Designers, General users, etc. who don't bother about CLI, will love to see such a package manager. And considering the fact GUIX lets rollback to the previous version of the package it will be very helpful in the scientific community, to maintain and work with different versions of packages. 
For example, the LAMBDA ( consist of TensorFlow, PyTorch, Keras, NVIDIA Cuda, Ubuntu) stack is very popular in the field of AI. Now if a person with a fresh install of GNU/Linux wants to install the stack and work immediately, through GUI he can search for the recipe of LAMBDA and install it. Not only that if it doesn't exist, but they can also create and share their own recipe with other guix users or to the main server/repo. E.g Linus Torvalds shares the recipe of building a Linux kernel environment. User finds it, installs it, and start working on the development of the Linux kernel immediately. 
P.S: I don't know whether GUI for Guix exists or not, to my knowledge it doesn't. If I am mistaken please enlighten me on this topic. 
Regards, 
Aniket.

[-- Attachment #2: Type: text/html, Size: 2698 bytes --]

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

Hi!

As part of the NLNet grant, I am planning on working on a (probably GTK
based) GUI for Guix.

The bad news: I had to put the grant on the side for the better part of
the year due to lack of time.

The good news: I recently got the opportunity to work on the internals
of the GUI.  Most of the work that remains to be done is to plug it to a
GTK interface in Guile, possibly using guile-gi or g-golf.

Stay tuned, more is coming, hopefully soon :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Ludovic Courtès]

Hi,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> The good news: I recently got the opportunity to work on the internals
> of the GUI.  Most of the work that remains to be done is to plug it to a
> GTK interface in Guile, possibly using guile-gi or g-golf.

This reminds me of Janneke’s Guimax:

  https://gitlab.com/janneke/guimax

It’s rather about providing a Guile UI, but perhaps it could also serve
as the basis of a Guix GUI?

Ludo’.

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 357 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> This reminds me of Janneke’s Guimax:
>
>   https://gitlab.com/janneke/guimax
>
> It’s rather about providing a Guile UI, but perhaps it could also serve
> as the basis of a Guix GUI?

I haven't heard about this, thanks for the hint, I'll look into it!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Jan Nieuwenhuizen]

Pierre Neidhardt writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> This reminds me of Janneke’s Guimax:
>>
>>   https://gitlab.com/janneke/guimax
>>
>> It’s rather about providing a Guile UI, but perhaps it could also serve
>> as the basis of a Guix GUI?
>
> I haven't heard about this, thanks for the hint, I'll look into it!

It's possibly more worthwile to look at Nomad; the interesting theme of
both is: fully guile-based gui with emacsy integration.  So, a
self-documenting gui program in Guile.

Janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[jbranso]

Can you link us to any code?  Or is it a bit too premature?

October 29, 2020 2:38 PM, "Pierre Neidhardt" <mail@ambrevar.xyz> wrote:

> Hi!
> 
> As part of the NLNet grant, I am planning on working on a (probably GTK
> based) GUI for Guix.
> 
> The bad news: I had to put the grant on the side for the better part of
> the year due to lack of time.
> 
> The good news: I recently got the opportunity to work on the internals
> of the GUI. Most of the work that remains to be done is to plug it to a
> GTK interface in Guile, possibly using guile-gi or g-golf.
> 
> Stay tuned, more is coming, hopefully soon :)
> 
> -- 
> Pierre Neidhardt
> https://ambrevar.xyz

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 226 bytes --]

jbranso@dismail.de writes:

> Can you link us to any code?  Or is it a bit too premature?

Too premature, sorry! :)  But stay tuned, I'll come back to it as soon
as I can.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[zimoun]

Hi,

On Thu, 29 Oct 2020 at 21:55, Aniket Patil <aniket112.patil@gmail.com> wrote:

> P.S: I don't know whether GUI for Guix exists or not, to my knowledge it
> doesn't. If I am mistaken please enlighten me on this topic.

For sure, a GUI front-end will be nice.  Today, the most GUI-like is
provided by the package ’emacs-guix’, and as the name indicates, it
uses… Emacs.  Well for the worst and the better. :-)

Recently, we discussed with Pierre and Mathieu about this.  And even if
some GTK front-end would be nice to have, from my point of view, the
good direction would be a “web-app frontend”, similarly to
git-annex-assistant [1].  This design is more flexible because it could
be used locally *and* could also be the front-end of some servers (e.g.,
build farms).

For example, let imagine that one user is running Guix on their own
machine and they locally generates a Docker image (guix pack -f docker)
via the front-end.  Another user who does not run Guix on their own
machine (but instead some Apple product), they could go to the front-end
served by one shared machine and so click, generates the Docker image
and get back one link usable by “docker pull“ or whatever.

The same code could run the 2 use cases.  Well, command by command,
these are sharable between the 2 use cases: describe, search, show,
time-machine, weather, part of system and package and pack; at least for
a start.

1: <https://git-annex.branchable.com/videos/git-annex_assistant_lan/>


Just my opinion if I would be starting a GUI front-end. :-)

All the best,
simon

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Lars-Dominik Braun]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

Hi,

> […] from my point of view, the good direction would be a “web-app frontend”,
> similarly to git-annex-assistant [1].  This design is more flexible because
> it could be used locally *and* could also be the front-end of some servers
> (e.g., build farms).
I have something like this on my todo list as well. It would probably be more
of a manifest file editor though, since we use manifest files for
reproducibility.

Cheers,
Lars


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Ludovic Courtès]

Hi,

Lars-Dominik Braun <ldb@leibniz-psychology.org> skribis:

>> […] from my point of view, the good direction would be a “web-app frontend”,
>> similarly to git-annex-assistant [1].  This design is more flexible because
>> it could be used locally *and* could also be the front-end of some servers
>> (e.g., build farms).
> I have something like this on my todo list as well. It would probably be more
> of a manifest file editor though, since we use manifest files for
> reproducibility.

Long ago Dave Thompson wrote guix-web, which allowed you to install
packages (you’d run it as your user):

  https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://gitorious.org/guix-web/guix-web.git

It’s an interesting approach with several advantages (in particular it
can be quickly developed), though I must say I remain unenthusiastic
about using web browsers for local GUIs.

Thanks,
Ludo’.

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Taylan Kammer]

On 01.11.2020 22:53, Ludovic Courtès wrote:
> Hi,
> 
> Lars-Dominik Braun <ldb@leibniz-psychology.org> skribis:
> 
>>> […] from my point of view, the good direction would be a “web-app frontend”,
>>> similarly to git-annex-assistant [1].  This design is more flexible because
>>> it could be used locally *and* could also be the front-end of some servers
>>> (e.g., build farms).
>> I have something like this on my todo list as well. It would probably be more
>> of a manifest file editor though, since we use manifest files for
>> reproducibility.
> 
> Long ago Dave Thompson wrote guix-web, which allowed you to install
> packages (you’d run it as your user):
> 
>    https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://gitorious.org/guix-web/guix-web.git
> 
> It’s an interesting approach with several advantages (in particular it
> can be quickly developed), though I must say I remain unenthusiastic
> about using web browsers for local GUIs.
> 
> Thanks,
> Ludo’.
> 

While I empathize with concerns about web browsers, I have to admit that 
I'm absolutely blown away by Vue.js + BootstrapVue.  (Using node & npm.)

My other GUI development experiences include iOS, Android, and C#.NET. 
I found Vue.js with Bootstrap to be on a completely different level.


Just wanted to throw this out there, even though I know it's heresy!

- Taylan

Gtk via the web

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

Hi Ludo,

On Sun, 01 Nov 2020 22:53:26 +0100
Ludovic Courtès <ludo@gnu.org> wrote:

> Lars-Dominik Braun <ldb@leibniz-psychology.org> skribis:
> 
> Long ago Dave Thompson wrote guix-web, which allowed you to install
> packages (you’d run it as your user):
> 
>   https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://gitorious.org/guix-web/guix-web.git
> 
> It’s an interesting approach with several advantages (in particular it
> can be quickly developed), though I must say I remain unenthusiastic
> about using web browsers for local GUIs.

You can use Gtk applications in the web using Broadway.  That's why I enabled
Broadway in our gtk+ package a long time ago.

Try it:

broadwayd :1 &
GDK_BACKEND=broadway BROADWAY_DISPLAY=:1 gedit &
icecat http://localhost:8081/

(broadwayd is in gtk+'s "bin" output)

Not saying we have to do that--but it's possible.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Gtk via the web

[aviva]

On 11/2/20 5:24 AM, Danny Milosavljevic wrote:
> You can use Gtk applications in the web using Broadway.  That's why I enabled
> Broadway in our gtk+ package a long time ago.

I haven't seen a reference to Broadway in 30 years

Re: Gtk via the web

[Ludovic Courtès]

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> You can use Gtk applications in the web using Broadway.  That's why I enabled
> Broadway in our gtk+ package a long time ago.
>
> Try it:
>
> broadwayd :1 &
> GDK_BACKEND=broadway BROADWAY_DISPLAY=:1 gedit &
> icecat http://localhost:8081/
>
> (broadwayd is in gtk+'s "bin" output)

Woow, impressive!

It doesn’t really help here though, because if we have a GTK+ app, then
we definitely don’t need the browser.  :-)

Ludo’.

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

Hello everyone,

On Thu, 29 Oct 2020 21:55:10 +0530
Aniket Patil <aniket112.patil@gmail.com> wrote:

>If we build a GUI frontend then we can attract more
> people who don't identify themselves with CLI users. As such there are many
> people like writers, Graphic Designers, General users, etc. who don't
> bother about CLI, will love to see such a package manager.  And considering
> the fact GUIX lets rollback to the previous version of the package it will
> be very helpful in the scientific community, to maintain and work with
> different versions of packages.

I've got one at https://gitlab.com/daym/guix-gui/ .

As of commit 978f7d92b4486829fd4f5030baf2d42c001b0890 (current master),
guix-gui works well enough that you can see the current profile, you have
(slow) tooltips, you can type to search, you can view the previous generation,
and you can get a list of all installable packages in Guix.

Not much more works yet because I've hit this (design) bug in Guix and/or GNOME:

* https://github.com/spk121/guile-gi/issues/96

I hadn't noticed before just how bad a match Guix's private dependencies (which
I think are a good thing) and GNOME's object system is (see link above).

> P.S: I don't know whether GUI for Guix exists or not, to my knowledge it
> doesn't. If I am mistaken please enlighten me on this topic.

It does kinda exist--but working on GUIs in Guile is like pulling teeth.

I'm used to seamless integration like PyGTK is in Python--PyGTK feels
EXACTLY like a native Python library.  You can't tell that it's implemented
in C at all.

The way it is in Guile is not seamless.  Furthermore, there are fundamental
problems in how the package "gobject-introspection" is designed (see link
above)--so I can't see how this can be resilient or consistent at all.

(Also, I've used Delphi before--that's basically the holy grail of GUI
development.  That doesn't help making me less grumpy using this contraption
string-and-duct-tape barely-holding-together contraption instead)

In any case, with all the involuntary yak-shaving I have to do it's gonna
take a while.

Or I could just use Gtk in C and use popen("guix ...").

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Ludovic Courtès]

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> I've got one at https://gitlab.com/daym/guix-gui/ .

Neat!

> Or I could just use Gtk in C and use popen("guix ...").

That’d be cheating.  :-)

Ludo’.

Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> I've got one at https://gitlab.com/daym/guix-gui/ .

Cool, thanks for sharing! 

> As of commit 978f7d92b4486829fd4f5030baf2d42c001b0890 (current master),
> guix-gui works well enough that you can see the current profile, you have
> (slow) tooltips, you can type to search, you can view the previous generation,
> and you can get a list of all installable packages in Guix.
>
> Not much more works yet because I've hit this (design) bug in Guix and/or GNOME:
>
> * https://github.com/spk121/guile-gi/issues/96

Have you tried g-golf?  The Nomad browser uses it, it may not suffer
from the aforementioned issue.
Thoughts on that?

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

GNOME in Guix

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 3162 bytes --]

Hi,

On Mon, 02 Nov 2020 08:44:29 +0100
Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> Danny Milosavljevic <dannym@scratchpost.org> writes:
> > Not much more works yet because I've hit this (design) bug in Guix and/or GNOME:
> >
> > * https://github.com/spk121/guile-gi/issues/96  
> 
> Have you tried g-golf?  The Nomad browser uses it, it may not suffer
> from the aforementioned issue.
> Thoughts on that?

It really depends on what you mean.  If it also uses gobject-introspection, it
will have the same problem.

Even gobject-introspection links to glib internally, then registers a class in
that, THEN opens (potentially another) glib at runtime using dlopen in the same
address same.
I'm pretty sure that GNOME is not designed for that.  If you then use the
dlopened glib to use the first-mentioned class, good luck with that.

The only reason it didn't fall onto the head of users of other distributions
is because those don't support internal dependencies of packages at all--so
you always have to update all in lockstep.  So the following can only happen
in Guix:

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.

Otherwise the modules aren't really modular (because they then don't isolate
from each other).

I think that the gobject type registry does not consider that it can happen
to have to classes with the same class name, registered in respective
internal dependencies.  The objects of the internal dependency shouldn't
be available to the outside program in the first place.

That means actually we should propagate a lot of GNOME inputs, which means
in practice what a regular user has in his profile will be very much like
in other distributions, and internal dependencies will become a weird corner
feature nobody uses.

Does anyone know how to make dlopen fail on duplicate global variables?

I tried to make it fail but I can't get it to work:

I tried:

File d1.c contains:
int x;

File d2.c contains:
int x;

File a.c contains:

#include <stdio.h>
#include <dlfcn.h>

// https://stackoverflow.com/questions/43582165/handling-global-variables-in-shared-object

int main() {
        if (!dlopen("./d1.so", RTLD_NOW | RTLD_GLOBAL /*| RTLD_DEEPBIND*/)) {
                fprintf(stderr, "dlerror: %s\n", dlerror());
                return 1;
        }
        if (!dlopen("./d2.so", RTLD_NOW | RTLD_GLOBAL /*| RTLD_DEEPBIND*/)) {
                fprintf(stderr, "dlerror: %s\n", dlerror());
                return 2;
        }
        return 0;
}

Then I do:

$ gcc -fPIC -shared -Wl,--export-dynamic -o d1.so d1.c
$ gcc -fPIC -shared -Wl,--export-dynamic -o d2.so d2.c
$ gcc a.c -ldl
$ ./a.out
$ echo $?
0

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: GNOME in Guix

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 303 bytes --]

Hi Danny,

So if I got it right from the GitHub issue and the discussion with Leo,
this issue here mostly targets developers.

But if the guix-gui (or Nomad) package has the right inputs, then there
should be no grafting issue.

Is this correct?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]