[PATCH] gnu: graphviz: Enable Guile library.

[PATCH] gnu: graphviz: Enable Guile library.

[Roel Janssen]

Dear Guix,

I would like to add graphviz's Guile interface to the package
definition.  This introduces two new (top-level) dependencies to the
graphviz package: guile and swig.

An example of the Guile interface:
(load-extension (string-append (getenv "HOME") "/.guix-profile/lib/graphviz/guile/libgv_guile.so") "SWIG_init")

;; Define the graph's nodes and edges.
(define my-graph (graph "G"))
(edge
  (node my-graph "A")
  (node my-graph "B"))

;; Set a lay-out and render it to a file.
(layout my-graph "dot")
(render my-graph "svg" "/home/roel/my-graph.svg")

The patch is fairly straightforward, since all that is needed is include
the dependencies to the inputs:

From 8e93c01a9c0909f49c4b644c965824fd5f74527a Mon Sep 17 00:00:00 2001
From: Roel Janssen <roel@gnu.org>
Date: Mon, 9 May 2016 11:26:18 +0200
Subject: [PATCH] gnu: graphviz: Enable Guile library.

gnu/packages/graphviz.scm (graphviz): Add inputs to enable the Guile library.
---
 gnu/packages/graphviz.scm | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/gnu/packages/graphviz.scm b/gnu/packages/graphviz.scm
index 09f475b..ddb3e67 100644
--- a/gnu/packages/graphviz.scm
+++ b/gnu/packages/graphviz.scm
@@ -25,6 +25,7 @@
   #:use-module (gnu packages gtk)
   #:use-module (gnu packages xml)
   #:use-module (gnu packages glib)
+  #:use-module (gnu packages guile)
   #:use-module (gnu packages bison)
   #:use-module (gnu packages image)
   #:use-module (gnu packages autotools)
@@ -32,6 +33,7 @@
   #:use-module (gnu packages fontutils)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages gd)
+  #:use-module (gnu packages swig)
   #:use-module ((guix licenses) #:select (lgpl2.0+ epl1.0)))
 
 (define-public graphviz
@@ -75,6 +77,8 @@
        ("libX11" ,libx11)
        ("gts" ,gts)
        ("gd" ,gd)                                 ; FIXME: Our GD is too old
+       ("guile" ,guile-2.0)
+       ("swig" ,swig)
        ("pango" ,pango)
        ("fontconfig" ,fontconfig)
        ("freetype" ,freetype)
-- 
2.7.4


Thank you for your time.

Kind regards,
Roel Janssen

Re: [PATCH] gnu: graphviz: Enable Guile library.

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> I would like to add graphviz's Guile interface to the package
> definition.  This introduces two new (top-level) dependencies to the
> graphviz package: guile and swig.
>
> An example of the Guile interface:
> (load-extension (string-append (getenv "HOME") "/.guix-profile/lib/graphviz/guile/libgv_guile.so") "SWIG_init")

Doesn’t Graphviz provide a module that does this?  Would be more
convenient.

> ;; Define the graph's nodes and edges.
> (define my-graph (graph "G"))
> (edge
>   (node my-graph "A")
>   (node my-graph "B"))
>
> ;; Set a lay-out and render it to a file.
> (layout my-graph "dot")
> (render my-graph "svg" "/home/roel/my-graph.svg")

Indeed, I wonder why we didn’t try before.  :-)

> The patch is fairly straightforward, since all that is needed is include
> the dependencies to the inputs:

Could you check the output of ‘guix size’ before and after the change?

Thanks!

Ludo’.

Re: [PATCH] gnu: graphviz: Enable Guile library.

[Roel Janssen]

Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> I would like to add graphviz's Guile interface to the package
>> definition.  This introduces two new (top-level) dependencies to the
>> graphviz package: guile and swig.
>>
>> An example of the Guile interface:
>> (load-extension (string-append (getenv "HOME") "/.guix-profile/lib/graphviz/guile/libgv_guile.so") "SWIG_init")
>
> Doesn’t Graphviz provide a module that does this?  Would be more
> convenient.

Not that I'm aware of (and I looked for it..).  I think this is because
it is automatically generated using SWIG.  I had to experiment a bit to
find out that the functions exposed in Guile did not have a namespace (gv.).

I could create a module for it, and then move libgc_guile.so to
lib/guile/2.0/extensions/.

There are functions called "rm" and "write" which are obviously already
used for other purposes in Scheme.  These functions will have to be
renamed or just left out of the Scheme module.  I must look again in the
Guile manual to find out more about exporting a function as a different
name.

>> ;; Define the graph's nodes and edges.
>> (define my-graph (graph "G"))
>> (edge
>>   (node my-graph "A")
>>   (node my-graph "B"))
>>
>> ;; Set a lay-out and render it to a file.
>> (layout my-graph "dot")
>> (render my-graph "svg" "/home/roel/my-graph.svg")
>
> Indeed, I wonder why we didn’t try before.  :-)

There's also a function to read a string in the dot language format.
Would it be desired to have something like:
  guix graph gcc --format=pdf

>> The patch is fairly straightforward, since all that is needed is include
>> the dependencies to the inputs:
>
> Could you check the output of ‘guix size’ before and after the change?

I will do that.

Thanks for your time.

Kind regards,
Roel Janssen

Re: [PATCH] gnu: graphviz: Enable Guile library.

[Danny Milosavljevic]

Hi,

On Mon, 09 May 2016 22:54:00 +0200
Roel Janssen <roel@gnu.org> wrote:

> it is automatically generated using SWIG.  I had to experiment a bit to
> find out that the functions exposed in Guile did not have a namespace (gv.).

You can add a prefix when importing, so the symbols of the module shouldn't have a prefix - the user would end up with two prefixes (or would have to cut the other prefix out and replace it or something).

     (use-modules ((gdb) #:renamer (symbol-prefix-proc 'gdb:)))

See also <http://www.swig.org/Doc2.0/Guile.html>.

> There are functions called "rm" and "write" which are obviously already
> used for other purposes in Scheme.  These functions will have to be
> renamed or just left out of the Scheme module.  

The user can specify which symbols to import (and also rename stuff there if needed) so I'd do nothing of the sort.

     (use-modules ((ice-9 popen)
                   #:select ((open-pipe . pipe-open) close-pipe)
                   #:renamer (symbol-prefix-proc 'unixy:)))

It's true that people still use the form

   (use-modules (xxx))

without specifying what the final imported symbols are, but that's something I consider bad practise in most cases (in any language - hey let's import random stuff into my namespace and have which module it gets each function from change on each package update. How about no?).

For example, let's say you have two modules "a" and "b".
Let module "a" contain "select".
Let module "b" contain "write".

Let's say you use it as

(use-modules (a) (b))

; main program
(write ...)
(select ...)

Then it will use b's write, a's select in your program, repectively. Say you release it and people use it. 

Now let's say someone devious (not really, it can make sense to him) adds "select" to module "b". Suddenly your program will use b's select *even though you didn't change anything in it*. 

Bad.

A complete set to try this:

$ export GUILE_LOAD_PATH=.

;;; a.scm
(define-module (a) #:export (select))
(define (select) (display "a.select") (newline))

;;; b.scm
(define-module (b) #:export (write select))
(define (write) (display "b.write") (newline))
(define (select) (display "b.select") (newline))

;;; main.scm
(use-modules (a) (b))
(write)
(select)

Note that you do get warnings by guile

WARNING: (guile-user): imported module (a) overrides core binding `select'
WARNING: (guile-user): `select' imported from both (a) and (b)
b.select
WARNING: (guile-user): imported module (b) overrides core binding `write'
b.write

... which is nice.

Re: [PATCH] gnu: graphviz: Enable Guile library.

[Roel Janssen]

Hello Danny,

Thank you for your elaborate response.  This makes it quite easy for me
to write the module file.  I added "write" and "rm" to the module, which
should make it complete.

What is the preferred way to include the module file to the package?
Should I create another package with this file alone, and use it as a
propagated input for graphviz?

Kind regards,
Roel Janssen


Danny Milosavljevic writes:

> Hi,
>
> On Mon, 09 May 2016 22:54:00 +0200
> Roel Janssen <roel@gnu.org> wrote:
>
>> it is automatically generated using SWIG.  I had to experiment a bit to
>> find out that the functions exposed in Guile did not have a namespace (gv.).
>
> You can add a prefix when importing, so the symbols of the module shouldn't have a prefix - the user would end up with two prefixes (or would have to cut the other prefix out and replace it or something).
>
>      (use-modules ((gdb) #:renamer (symbol-prefix-proc 'gdb:)))
>
> See also <http://www.swig.org/Doc2.0/Guile.html>.
>
>> There are functions called "rm" and "write" which are obviously already
>> used for other purposes in Scheme.  These functions will have to be
>> renamed or just left out of the Scheme module.  
>
> The user can specify which symbols to import (and also rename stuff there if needed) so I'd do nothing of the sort.
>
>      (use-modules ((ice-9 popen)
>                    #:select ((open-pipe . pipe-open) close-pipe)
>                    #:renamer (symbol-prefix-proc 'unixy:)))
>
> It's true that people still use the form
>
>    (use-modules (xxx))
>
> without specifying what the final imported symbols are, but that's something I consider bad practise in most cases (in any language - hey let's import random stuff into my namespace and have which module it gets each function from change on each package update. How about no?).
>
> For example, let's say you have two modules "a" and "b".
> Let module "a" contain "select".
> Let module "b" contain "write".
>
> Let's say you use it as
>
> (use-modules (a) (b))
>
> ; main program
> (write ...)
> (select ...)
>
> Then it will use b's write, a's select in your program, repectively. Say you release it and people use it. 
>
> Now let's say someone devious (not really, it can make sense to him) adds "select" to module "b". Suddenly your program will use b's select *even though you didn't change anything in it*. 
>
> Bad.
>
> A complete set to try this:
>
> $ export GUILE_LOAD_PATH=.
>
> ;;; a.scm
> (define-module (a) #:export (select))
> (define (select) (display "a.select") (newline))
>
> ;;; b.scm
> (define-module (b) #:export (write select))
> (define (write) (display "b.write") (newline))
> (define (select) (display "b.select") (newline))
>
> ;;; main.scm
> (use-modules (a) (b))
> (write)
> (select)
>
> Note that you do get warnings by guile
>
> WARNING: (guile-user): imported module (a) overrides core binding `select'
> WARNING: (guile-user): `select' imported from both (a) and (b)
> b.select
> WARNING: (guile-user): imported module (b) overrides core binding `write'
> b.write
>
> ... which is nice.

Re: [PATCH] gnu: graphviz: Enable Guile library.

[Roel Janssen]

Hello there,

I now have a graphviz-guile package with a graphviz.scm module file.

Where should I link/copy/move libgv_guile.so?

I tried:
$PACKAGE_OUTPUT/lib/
$PACKAGE_OUTPUT/lib/guile/2.0/
$PACKAGE_OUTPUT/lib/guile/2.0/extensions/

But it seems my system only looks in:
/lib
/gnu/store/...-gcc-4.9.3-lib/lib/
/gnu/store/...-glibc-2.22/lib/
/gnu/store/...-guile-2.0.11/lib/

Kind regards,
Roel Janssen


Roel Janssen writes:

> Hello Danny,
>
> Thank you for your elaborate response.  This makes it quite easy for me
> to write the module file.  I added "write" and "rm" to the module, which
> should make it complete.
>
> What is the preferred way to include the module file to the package?
> Should I create another package with this file alone, and use it as a
> propagated input for graphviz?
>
> Kind regards,
> Roel Janssen
>
>
> Danny Milosavljevic writes:
>
>> Hi,
>>
>> On Mon, 09 May 2016 22:54:00 +0200
>> Roel Janssen <roel@gnu.org> wrote:
>>
>>> it is automatically generated using SWIG.  I had to experiment a bit to
>>> find out that the functions exposed in Guile did not have a namespace (gv.).
>>
>> You can add a prefix when importing, so the symbols of the module shouldn't have a prefix - the user would end up with two prefixes (or would have to cut the other prefix out and replace it or something).
>>
>>      (use-modules ((gdb) #:renamer (symbol-prefix-proc 'gdb:)))
>>
>> See also <http://www.swig.org/Doc2.0/Guile.html>.
>>
>>> There are functions called "rm" and "write" which are obviously already
>>> used for other purposes in Scheme.  These functions will have to be
>>> renamed or just left out of the Scheme module.  
>>
>> The user can specify which symbols to import (and also rename stuff there if needed) so I'd do nothing of the sort.
>>
>>      (use-modules ((ice-9 popen)
>>                    #:select ((open-pipe . pipe-open) close-pipe)
>>                    #:renamer (symbol-prefix-proc 'unixy:)))
>>
>> It's true that people still use the form
>>
>>    (use-modules (xxx))
>>
>> without specifying what the final imported symbols are, but that's something I consider bad practise in most cases (in any language - hey let's import random stuff into my namespace and have which module it gets each function from change on each package update. How about no?).
>>
>> For example, let's say you have two modules "a" and "b".
>> Let module "a" contain "select".
>> Let module "b" contain "write".
>>
>> Let's say you use it as
>>
>> (use-modules (a) (b))
>>
>> ; main program
>> (write ...)
>> (select ...)
>>
>> Then it will use b's write, a's select in your program, repectively. Say you release it and people use it. 
>>
>> Now let's say someone devious (not really, it can make sense to him) adds "select" to module "b". Suddenly your program will use b's select *even though you didn't change anything in it*. 
>>
>> Bad.
>>
>> A complete set to try this:
>>
>> $ export GUILE_LOAD_PATH=.
>>
>> ;;; a.scm
>> (define-module (a) #:export (select))
>> (define (select) (display "a.select") (newline))
>>
>> ;;; b.scm
>> (define-module (b) #:export (write select))
>> (define (write) (display "b.write") (newline))
>> (define (select) (display "b.select") (newline))
>>
>> ;;; main.scm
>> (use-modules (a) (b))
>> (write)
>> (select)
>>
>> Note that you do get warnings by guile
>>
>> WARNING: (guile-user): imported module (a) overrides core binding `select'
>> WARNING: (guile-user): `select' imported from both (a) and (b)
>> b.select
>> WARNING: (guile-user): imported module (b) overrides core binding `write'
>> b.write
>>
>> ... which is nice.

Re: [PATCH] gnu: graphviz: Enable Guile library.

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> What is the preferred way to include the module file to the package?
> Should I create another package with this file alone, and use it as a
> propagated input for graphviz?

Could you first submit it upstream?

> I now have a graphviz-guile package with a graphviz.scm module file.
>
> Where should I link/copy/move libgv_guile.so?
>
> I tried:
> $PACKAGE_OUTPUT/lib/
> $PACKAGE_OUTPUT/lib/guile/2.0/
> $PACKAGE_OUTPUT/lib/guile/2.0/extensions/
>
> But it seems my system only looks in:
> /lib
> /gnu/store/...-gcc-4.9.3-lib/lib/
> /gnu/store/...-glibc-2.22/lib/
> /gnu/store/...-guile-2.0.11/lib/

‘load-extension’ searches for shared objects in the extension directory:

--8<---------------cut here---------------start------------->8---
scheme@(guix gexp)> (assoc-ref %guile-build-info 'extensiondir)
$14 = "/home/ludo/soft/lib/guile/2.0/extensions"
--8<---------------cut here---------------end--------------->8---

… and in whatever ‘LTDL_LIBRARY_PATH’ points to
(info "(libtool) Libltdl interface").

HTH!

Ludo’.

Re: [PATCH] gnu: graphviz: Enable Guile library.

[Roel Janssen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: 0001-gnu-graphviz-Enable-Guile-library.patch --]
[-- Type: text/x-patch, Size: 2331 bytes --]

From 704d5eba566af8d90ec7f53e7fc11d989f85c5e6 Mon Sep 17 00:00:00 2001
From: Roel Janssen <roel@gnu.org>
Date: Tue, 10 May 2016 15:54:01 +0200
Subject: [PATCH 1/2] gnu: graphviz: Enable Guile library.

* gnu/packages/graphviz.scm (graphviz): Compile with Guile support.
---
 gnu/packages/graphviz.scm | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/graphviz.scm b/gnu/packages/graphviz.scm
index 09f475b..489a71c 100644
--- a/gnu/packages/graphviz.scm
+++ b/gnu/packages/graphviz.scm
@@ -25,6 +25,7 @@
   #:use-module (gnu packages gtk)
   #:use-module (gnu packages xml)
   #:use-module (gnu packages glib)
+  #:use-module (gnu packages guile)
   #:use-module (gnu packages bison)
   #:use-module (gnu packages image)
   #:use-module (gnu packages autotools)
@@ -32,6 +33,7 @@
   #:use-module (gnu packages fontutils)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages gd)
+  #:use-module (gnu packages swig)
   #:use-module ((guix licenses) #:select (lgpl2.0+ epl1.0)))
 
 (define-public graphviz
@@ -69,12 +71,24 @@
                              (rename-file (string-append out "/share/graphviz/doc")
                                           (string-append doc "/share/graphviz/doc"))
                              #t))
-                 %standard-phases))))
+                  (alist-cons-after
+                   'move-docs 'create-gv-guile-link
+                   (lambda* (#:key outputs #:allow-other-keys)
+                     (let* ((out (assoc-ref outputs "out"))
+                            (lib (string-append out "/lib"))
+                            (guile-lib-dir (string-append lib "/guile/2.0")))
+                       (mkdir-p guile-lib-dir)
+                       (system* "ln" "--symbolic"
+                                (string-append lib "/graphviz/guile/libgv_guile.so")
+                                (string-append guile-lib-dir "/libgv_guile.so"))))
+                   %standard-phases)))))
     (inputs
      `(("libXrender" ,libxrender)
        ("libX11" ,libx11)
        ("gts" ,gts)
        ("gd" ,gd)                                 ; FIXME: Our GD is too old
+       ("guile" ,guile-2.0)
+       ("swig" ,swig)
        ("pango" ,pango)
        ("fontconfig" ,fontconfig)
        ("freetype" ,freetype)
-- 
2.7.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-gnu-graphviz-Add-graphviz-guile.patch --]
[-- Type: text/x-patch, Size: 3312 bytes --]

From a73293cb66f3978e60e1244124cd28b623d6c30c Mon Sep 17 00:00:00 2001
From: Roel Janssen <roel@gnu.org>
Date: Tue, 10 May 2016 15:55:52 +0200
Subject: [PATCH 2/2] gnu: graphviz: Add graphviz-guile.

* gnu/packages/graphviz.scm (graphviz): New variable.
---
 gnu/packages/graphviz.scm | 48 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/graphviz.scm b/gnu/packages/graphviz.scm
index 489a71c..f9c49ef 100644
--- a/gnu/packages/graphviz.scm
+++ b/gnu/packages/graphviz.scm
@@ -20,7 +20,9 @@
 (define-module (gnu packages graphviz)
   #:use-module (guix packages)
   #:use-module (guix build-system gnu)
+  #:use-module (guix build-system trivial)
   #:use-module (guix download)
+  #:use-module (gnu packages base)
   #:use-module (gnu packages xorg)
   #:use-module (gnu packages gtk)
   #:use-module (gnu packages xml)
@@ -34,7 +36,7 @@
   #:use-module (gnu packages compression)
   #:use-module (gnu packages gd)
   #:use-module (gnu packages swig)
-  #:use-module ((guix licenses) #:select (lgpl2.0+ epl1.0)))
+  #:use-module ((guix licenses) #:select (gpl3+ lgpl2.0+ epl1.0)))
 
 (define-public graphviz
   (package
@@ -111,6 +113,50 @@ software engineering, database and web design, machine learning, and in visual
 interfaces for other technical domains.")
     (license epl1.0)))
 
+(define-public graphviz-guile
+  (package
+    (name "graphviz-guile")
+    (version "1.0")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append
+                    "https://github.com/roelj/graphviz-guile/archive/v"
+                    version ".tar.gz"))
+              (sha256
+               (base32 "1ccmr4isj85j7djg9m56n54rqq1z94bjmrrs6vv4qdcp6ihv3c3r"))
+              (file-name (string-append name "-" version ".tar.gz"))))
+    (build-system trivial-build-system)
+    (arguments
+     `(#:modules ((guix build utils))
+       #:builder
+       (begin
+         (use-modules (guix build utils))
+         (let ((tar (string-append (assoc-ref %build-inputs "tar") "/bin/tar"))
+               (PATH (string-append (assoc-ref %build-inputs "gzip") "/bin"))
+               (dest-dir (string-append %output "/share/guile/site/2.0"))
+               (gv (string-append (assoc-ref %build-inputs "graphviz")
+                                  "/lib/guile/2.0")))
+           (setenv "PATH" PATH)
+           (mkdir-p dest-dir)
+           (system* tar "xvf" (assoc-ref %build-inputs "source"))
+           (chdir "graphviz-guile-1.0")
+           ;; Use the absolute path to the graphviz library so that
+           ;; Guix can find it.
+           (substitute* "graphviz.scm"
+             (("libgv_guile.so") (string-append gv "/libgv_guile.so")))
+           (copy-file "graphviz.scm"
+                      (string-append dest-dir "/graphviz.scm"))))))
+    (native-inputs
+     `(("tar" ,tar)
+       ("gzip" ,gzip)))
+    (propagated-inputs
+     `(("graphviz" ,graphviz)))
+    (home-page "https://github.com/roelj/graphviz-guile")
+    (synopsis "Graphviz module for Guile")
+    (description "This package provides a Graphviz module file for Guile.  It
+uses the library provided by the Graphviz package.")
+    (license gpl3+)))
+
 (define-public gts
   (package
     (name "gts")
-- 
2.7.4


[-- Attachment #3: Type: text/plain, Size: 1995 bytes --]


Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> What is the preferred way to include the module file to the package?
>> Should I create another package with this file alone, and use it as a
>> propagated input for graphviz?
>
> Could you first submit it upstream?

Do you think they would be interested in this?  I kind of get the
feeling that the language bindings are something generated
automatically, and manually adding things is not desired (for upstream).

>> I now have a graphviz-guile package with a graphviz.scm module file.
>>
>> Where should I link/copy/move libgv_guile.so?
>>
>> I tried:
>> $PACKAGE_OUTPUT/lib/
>> $PACKAGE_OUTPUT/lib/guile/2.0/
>> $PACKAGE_OUTPUT/lib/guile/2.0/extensions/
>>
>> But it seems my system only looks in:
>> /lib
>> /gnu/store/...-gcc-4.9.3-lib/lib/
>> /gnu/store/...-glibc-2.22/lib/
>> /gnu/store/...-guile-2.0.11/lib/
>
> ‘load-extension’ searches for shared objects in the extension directory:
>
> --8<---------------cut here---------------start------------->8---
> scheme@(guix gexp)> (assoc-ref %guile-build-info 'extensiondir)
> $14 = "/home/ludo/soft/lib/guile/2.0/extensions"
> --8<---------------cut here---------------end--------------->8---
>
> … and in whatever ‘LTDL_LIBRARY_PATH’ points to
> (info "(libtool) Libltdl interface").

So I concluded that it is best to use an absolute path instead.  I
substituted the path in the graphviz-guile.

The differences in size:

With patches:
store item                                                       total    self
/gnu/store/r5rfvwpswgy271m3i03wy2pwwsk386k7-graphviz-2.38.0        292.2    61.9  21.2%

Without patches:
store item                                                       total    self
/gnu/store/bc0qnp182ffi5p680na7kwhbyxkjaz3m-graphviz-2.38.0        266.0    61.8  23.3%

I could also attach the full output of `guix size graphviz`, before and
after.

Hopefully, my patches are fine..

Thank you for your time.

Kind regards,
Roel Janssen

Re: [PATCH] gnu: graphviz: Enable Guile library.

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> From 704d5eba566af8d90ec7f53e7fc11d989f85c5e6 Mon Sep 17 00:00:00 2001
> From: Roel Janssen <roel@gnu.org>
> Date: Tue, 10 May 2016 15:54:01 +0200
> Subject: [PATCH 1/2] gnu: graphviz: Enable Guile library.
>
> * gnu/packages/graphviz.scm (graphviz): Compile with Guile support.

Cool, applied with minor changes.

> From a73293cb66f3978e60e1244124cd28b623d6c30c Mon Sep 17 00:00:00 2001
> From: Roel Janssen <roel@gnu.org>
> Date: Tue, 10 May 2016 15:55:52 +0200
> Subject: [PATCH 2/2] gnu: graphviz: Add graphviz-guile.
>
> * gnu/packages/graphviz.scm (graphviz): New variable.

[...]

> +    (name "graphviz-guile")
> +    (version "1.0")
> +    (source (origin
> +              (method url-fetch)
> +              (uri (string-append
> +                    "https://github.com/roelj/graphviz-guile/archive/v"
> +                    version ".tar.gz"))
> +              (sha256
> +               (base32 "1ccmr4isj85j7djg9m56n54rqq1z94bjmrrs6vv4qdcp6ihv3c3r"))
> +              (file-name (string-append name "-" version ".tar.gz"))))

I think this is cheating a bit.  :-)

> Do you think they would be interested in this?  I kind of get the
> feeling that the language bindings are something generated
> automatically, and manually adding things is not desired (for upstream).

If it’s a single file, it’s worth trying IMO.

Thank you!

Ludo’.

Re: [PATCH] gnu: graphviz: Enable Guile library.

[Roel Janssen]

Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> From 704d5eba566af8d90ec7f53e7fc11d989f85c5e6 Mon Sep 17 00:00:00 2001
>> From: Roel Janssen <roel@gnu.org>
>> Date: Tue, 10 May 2016 15:54:01 +0200
>> Subject: [PATCH 1/2] gnu: graphviz: Enable Guile library.
>>
>> * gnu/packages/graphviz.scm (graphviz): Compile with Guile support.
>
> Cool, applied with minor changes.
>
>> From a73293cb66f3978e60e1244124cd28b623d6c30c Mon Sep 17 00:00:00 2001
>> From: Roel Janssen <roel@gnu.org>
>> Date: Tue, 10 May 2016 15:55:52 +0200
>> Subject: [PATCH 2/2] gnu: graphviz: Add graphviz-guile.
>>
>> * gnu/packages/graphviz.scm (graphviz): New variable.
>
> [...]
>
>> +    (name "graphviz-guile")
>> +    (version "1.0")
>> +    (source (origin
>> +              (method url-fetch)
>> +              (uri (string-append
>> +                    "https://github.com/roelj/graphviz-guile/archive/v"
>> +                    version ".tar.gz"))
>> +              (sha256
>> +               (base32 "1ccmr4isj85j7djg9m56n54rqq1z94bjmrrs6vv4qdcp6ihv3c3r"))
>> +              (file-name (string-append name "-" version ".tar.gz"))))
>
> I think this is cheating a bit.  :-)

Just a bit :-).

Other than getting it upstream, I don't see how else I could've done this.

>> Do you think they would be interested in this?  I kind of get the
>> feeling that the language bindings are something generated
>> automatically, and manually adding things is not desired (for upstream).
>
> If it’s a single file, it’s worth trying IMO.

Alright.  At the moment, their website seems to be down (graphviz.org),
and their IRC channel very quiet.  Do you know the mailing list address
for graphviz?

Thanks for your time.

Kind regards,
Roel Janssen

Re: [PATCH] gnu: graphviz: Enable Guile library.

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> Ludovic Courtès writes:
>
>> Roel Janssen <roel@gnu.org> skribis:
>>
>>> From 704d5eba566af8d90ec7f53e7fc11d989f85c5e6 Mon Sep 17 00:00:00 2001
>>> From: Roel Janssen <roel@gnu.org>
>>> Date: Tue, 10 May 2016 15:54:01 +0200
>>> Subject: [PATCH 1/2] gnu: graphviz: Enable Guile library.
>>>
>>> * gnu/packages/graphviz.scm (graphviz): Compile with Guile support.
>>
>> Cool, applied with minor changes.
>>
>>> From a73293cb66f3978e60e1244124cd28b623d6c30c Mon Sep 17 00:00:00 2001
>>> From: Roel Janssen <roel@gnu.org>
>>> Date: Tue, 10 May 2016 15:55:52 +0200
>>> Subject: [PATCH 2/2] gnu: graphviz: Add graphviz-guile.
>>>
>>> * gnu/packages/graphviz.scm (graphviz): New variable.
>>
>> [...]
>>
>>> +    (name "graphviz-guile")
>>> +    (version "1.0")
>>> +    (source (origin
>>> +              (method url-fetch)
>>> +              (uri (string-append
>>> +                    "https://github.com/roelj/graphviz-guile/archive/v"
>>> +                    version ".tar.gz"))
>>> +              (sha256
>>> +               (base32 "1ccmr4isj85j7djg9m56n54rqq1z94bjmrrs6vv4qdcp6ihv3c3r"))
>>> +              (file-name (string-append name "-" version ".tar.gz"))))
>>
>> I think this is cheating a bit.  :-)
>
> Just a bit :-).
>
> Other than getting it upstream, I don't see how else I could've done this.
>
>>> Do you think they would be interested in this?  I kind of get the
>>> feeling that the language bindings are something generated
>>> automatically, and manually adding things is not desired (for upstream).
>>
>> If it’s a single file, it’s worth trying IMO.
>
> Alright.  At the moment, their website seems to be down (graphviz.org),
> and their IRC channel very quiet.  Do you know the mailing list address
> for graphviz?

I don’t!  Hopefully the web site will come back soon.

Ludo’.

Re: [PATCH] gnu: graphviz: Enable Guile library.

[Roel Janssen]

Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> Ludovic Courtès writes:
>>
>>> Roel Janssen <roel@gnu.org> skribis:
>>>
>>>> From 704d5eba566af8d90ec7f53e7fc11d989f85c5e6 Mon Sep 17 00:00:00 2001
>>>> From: Roel Janssen <roel@gnu.org>
>>>> Date: Tue, 10 May 2016 15:54:01 +0200
>>>> Subject: [PATCH 1/2] gnu: graphviz: Enable Guile library.
>>>>
>>>> * gnu/packages/graphviz.scm (graphviz): Compile with Guile support.
>>>
>>> Cool, applied with minor changes.
>>>
>>>> From a73293cb66f3978e60e1244124cd28b623d6c30c Mon Sep 17 00:00:00 2001
>>>> From: Roel Janssen <roel@gnu.org>
>>>> Date: Tue, 10 May 2016 15:55:52 +0200
>>>> Subject: [PATCH 2/2] gnu: graphviz: Add graphviz-guile.
>>>>
>>>> * gnu/packages/graphviz.scm (graphviz): New variable.
>>>
>>> [...]
>>>
>>>> +    (name "graphviz-guile")
>>>> +    (version "1.0")
>>>> +    (source (origin
>>>> +              (method url-fetch)
>>>> +              (uri (string-append
>>>> +                    "https://github.com/roelj/graphviz-guile/archive/v"
>>>> +                    version ".tar.gz"))
>>>> +              (sha256
>>>> +               (base32 "1ccmr4isj85j7djg9m56n54rqq1z94bjmrrs6vv4qdcp6ihv3c3r"))
>>>> +              (file-name (string-append name "-" version ".tar.gz"))))
>>>
>>> I think this is cheating a bit.  :-)
>>
>> Just a bit :-).
>>
>> Other than getting it upstream, I don't see how else I could've done this.
>>
>>>> Do you think they would be interested in this?  I kind of get the
>>>> feeling that the language bindings are something generated
>>>> automatically, and manually adding things is not desired (for upstream).
>>>
>>> If it’s a single file, it’s worth trying IMO.
>>
>> Alright.  At the moment, their website seems to be down (graphviz.org),
>> and their IRC channel very quiet.  Do you know the mailing list address
>> for graphviz?
>
> I don’t!  Hopefully the web site will come back soon.

I found the mailing list address with a bit of Ducking around:
https://duckduckgo.com/?q=graphviz-devel+mailing+list

Unfortunately, this list doesn't seem to exist anymore, because my
e-mail bounced.

I cannot download the source code, because that is/was hosted on
graphviz.org as well.  The header files do not contain contact
information of a developer, so I guess we have to wait until it comes
back online.

Or do you think we can move along now and update the graphviz-guile
package whenever we get it in upstream?  I am definitely interested in
adding an option to directly output an SVG in the graph subcommand, for
which graphviz-guile is a prerequisite.

Thanks for your time!

Kind regards,
Roel Janssen

Re: [PATCH] gnu: graphviz: Enable Guile library.

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> Ludovic Courtès writes:
>
>> Roel Janssen <roel@gnu.org> skribis:
>>
>>> Ludovic Courtès writes:
>>>
>>>> Roel Janssen <roel@gnu.org> skribis:
>>>>
>>>>> From 704d5eba566af8d90ec7f53e7fc11d989f85c5e6 Mon Sep 17 00:00:00 2001
>>>>> From: Roel Janssen <roel@gnu.org>
>>>>> Date: Tue, 10 May 2016 15:54:01 +0200
>>>>> Subject: [PATCH 1/2] gnu: graphviz: Enable Guile library.
>>>>>
>>>>> * gnu/packages/graphviz.scm (graphviz): Compile with Guile support.
>>>>
>>>> Cool, applied with minor changes.
>>>>
>>>>> From a73293cb66f3978e60e1244124cd28b623d6c30c Mon Sep 17 00:00:00 2001
>>>>> From: Roel Janssen <roel@gnu.org>
>>>>> Date: Tue, 10 May 2016 15:55:52 +0200
>>>>> Subject: [PATCH 2/2] gnu: graphviz: Add graphviz-guile.
>>>>>
>>>>> * gnu/packages/graphviz.scm (graphviz): New variable.
>>>>
>>>> [...]
>>>>
>>>>> +    (name "graphviz-guile")
>>>>> +    (version "1.0")
>>>>> +    (source (origin
>>>>> +              (method url-fetch)
>>>>> +              (uri (string-append
>>>>> +                    "https://github.com/roelj/graphviz-guile/archive/v"
>>>>> +                    version ".tar.gz"))
>>>>> +              (sha256
>>>>> +               (base32 "1ccmr4isj85j7djg9m56n54rqq1z94bjmrrs6vv4qdcp6ihv3c3r"))
>>>>> +              (file-name (string-append name "-" version ".tar.gz"))))
>>>>
>>>> I think this is cheating a bit.  :-)
>>>
>>> Just a bit :-).
>>>
>>> Other than getting it upstream, I don't see how else I could've done this.
>>>
>>>>> Do you think they would be interested in this?  I kind of get the
>>>>> feeling that the language bindings are something generated
>>>>> automatically, and manually adding things is not desired (for upstream).
>>>>
>>>> If it’s a single file, it’s worth trying IMO.
>>>
>>> Alright.  At the moment, their website seems to be down (graphviz.org),
>>> and their IRC channel very quiet.  Do you know the mailing list address
>>> for graphviz?
>>
>> I don’t!  Hopefully the web site will come back soon.
>
> I found the mailing list address with a bit of Ducking around:
> https://duckduckgo.com/?q=graphviz-devel+mailing+list
>
> Unfortunately, this list doesn't seem to exist anymore, because my
> e-mail bounced.
>
> I cannot download the source code, because that is/was hosted on
> graphviz.org as well.  The header files do not contain contact
> information of a developer, so I guess we have to wait until it comes
> back online.

Bah.  :-/

> Or do you think we can move along now and update the graphviz-guile
> package whenever we get it in upstream?

The problem is relying on something which zero other distros, including
upstream’s source distro, provide.  I’m uncomfortable with that.

> I am definitely interested in adding an option to directly output an
> SVG in the graph subcommand, for which graphviz-guile is a
> prerequisite.

It’s definitely tempting, but on the downside, note that we’d have to
support the case where the Graphviz Guile bindings are missing, provide
additional command-line options to tweak the output, etc. when in fact,
the only visible benefit would be that one can type:

  guix graph --format=pdf foo > foo.pdf

instead of:

  guix graph foo | dot -Tpdf > foo.pdf

(The latter is one character shorter, even!  ;-))

So, thinking more about it, I think that in the case of ‘guix graph’,
it’s a bit of trouble for little in return.

WDYT?  :-)

Ludo’.

Re: [PATCH] gnu: graphviz: Enable Guile library.

[Roel Janssen]

Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> Ludovic Courtès writes:
>>
>>> Roel Janssen <roel@gnu.org> skribis:
>>>
>>>> Ludovic Courtès writes:
>>>>
>>>>> Roel Janssen <roel@gnu.org> skribis:
>>>>>
>>>>>> From 704d5eba566af8d90ec7f53e7fc11d989f85c5e6 Mon Sep 17 00:00:00 2001
>>>>>> From: Roel Janssen <roel@gnu.org>
>>>>>> Date: Tue, 10 May 2016 15:54:01 +0200
>>>>>> Subject: [PATCH 1/2] gnu: graphviz: Enable Guile library.
>>>>>>
>>>>>> * gnu/packages/graphviz.scm (graphviz): Compile with Guile support.
>>>>>
>>>>> Cool, applied with minor changes.
>>>>>
>>>>>> From a73293cb66f3978e60e1244124cd28b623d6c30c Mon Sep 17 00:00:00 2001
>>>>>> From: Roel Janssen <roel@gnu.org>
>>>>>> Date: Tue, 10 May 2016 15:55:52 +0200
>>>>>> Subject: [PATCH 2/2] gnu: graphviz: Add graphviz-guile.
>>>>>>
>>>>>> * gnu/packages/graphviz.scm (graphviz): New variable.
>>>>>
>>>>> [...]
>>>>>
>>>>>> +    (name "graphviz-guile")
>>>>>> +    (version "1.0")
>>>>>> +    (source (origin
>>>>>> +              (method url-fetch)
>>>>>> +              (uri (string-append
>>>>>> +                    "https://github.com/roelj/graphviz-guile/archive/v"
>>>>>> +                    version ".tar.gz"))
>>>>>> +              (sha256
>>>>>> +               (base32 "1ccmr4isj85j7djg9m56n54rqq1z94bjmrrs6vv4qdcp6ihv3c3r"))
>>>>>> +              (file-name (string-append name "-" version ".tar.gz"))))
>>>>>
>>>>> I think this is cheating a bit.  :-)
>>>>
>>>> Just a bit :-).
>>>>
>>>> Other than getting it upstream, I don't see how else I could've done this.
>>>>
>>>>>> Do you think they would be interested in this?  I kind of get the
>>>>>> feeling that the language bindings are something generated
>>>>>> automatically, and manually adding things is not desired (for upstream).
>>>>>
>>>>> If it’s a single file, it’s worth trying IMO.
>>>>
>>>> Alright.  At the moment, their website seems to be down (graphviz.org),
>>>> and their IRC channel very quiet.  Do you know the mailing list address
>>>> for graphviz?
>>>
>>> I don’t!  Hopefully the web site will come back soon.
>>
>> I found the mailing list address with a bit of Ducking around:
>> https://duckduckgo.com/?q=graphviz-devel+mailing+list
>>
>> Unfortunately, this list doesn't seem to exist anymore, because my
>> e-mail bounced.
>>
>> I cannot download the source code, because that is/was hosted on
>> graphviz.org as well.  The header files do not contain contact
>> information of a developer, so I guess we have to wait until it comes
>> back online.
>
> Bah.  :-/
>
>> Or do you think we can move along now and update the graphviz-guile
>> package whenever we get it in upstream?
>
> The problem is relying on something which zero other distros, including
> upstream’s source distro, provide.  I’m uncomfortable with that.

I understand.  In the meantime, the website is back online so I can attempt
to add it to upstream.

>> I am definitely interested in adding an option to directly output an
>> SVG in the graph subcommand, for which graphviz-guile is a
>> prerequisite.
>
> It’s definitely tempting, but on the downside, note that we’d have to
> support the case where the Graphviz Guile bindings are missing, provide
> additional command-line options to tweak the output, etc. when in fact,
> the only visible benefit would be that one can type:
>
>   guix graph --format=pdf foo > foo.pdf
>
> instead of:
>
>   guix graph foo | dot -Tpdf > foo.pdf
>
> (The latter is one character shorter, even!  ;-))

Well, we could go for:

  guix graph foo --file=foo.pdf

Even shorter! ;-)  The default can stay the same, so one can still tweak
using the dot program.

More importantly, by using the graphviz library we don't need the user
to install dot to convert it to a graphics format.  However, at that
point the graphviz library becomes a dependency of Guix.  Making it a
dependency of Guix opens the possibility of moving the Guile module file
into guix/graphviz.scm and make it part of Guix.

> So, thinking more about it, I think that in the case of ‘guix graph’,
> it’s a bit of trouble for little in return.
>
> WDYT?  :-)
>
> Ludo’.

I think it depends on whether it would be a problem to add the graphviz
library as a dependency to Guix.  The return is not so much the shorter
(or longer ;-)) command, but more the completeness of Guix to produce a
graphical output rather than a text file that can be used by another
program to generate graphical output.

If you think I should put my energy elsewhere on the project, I can and
will respect that ;-).

Kind regards,
Roel Janssen

Re: [PATCH] gnu: graphviz: Enable Guile library.

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> Ludovic Courtès writes:
>
>> Roel Janssen <roel@gnu.org> skribis:

[...]

>>> I am definitely interested in adding an option to directly output an
>>> SVG in the graph subcommand, for which graphviz-guile is a
>>> prerequisite.
>>
>> It’s definitely tempting, but on the downside, note that we’d have to
>> support the case where the Graphviz Guile bindings are missing, provide
>> additional command-line options to tweak the output, etc. when in fact,
>> the only visible benefit would be that one can type:
>>
>>   guix graph --format=pdf foo > foo.pdf
>>
>> instead of:
>>
>>   guix graph foo | dot -Tpdf > foo.pdf
>>
>> (The latter is one character shorter, even!  ;-))
>
> Well, we could go for:
>
>   guix graph foo --file=foo.pdf
>
> Even shorter! ;-)  The default can stay the same, so one can still tweak
> using the dot program.
>
> More importantly, by using the graphviz library we don't need the user
> to install dot to convert it to a graphics format.

Currently Graphviz is a “soft dependency” of Guix: the ‘guix graph’
command is always built and installed, and it’s up to the user to
install Graphviz if they want to pipe things through ‘dot’.

If we use-modules (graphviz), then we’ll have to write a bunch of code
that still allows ‘guix graph’ to build and run even when the (graphviz)
module is missing, etc.  That’s always kind of boring and occasionally
fragile.

In both cases, the user needs to install Graphviz to get PDFs and such.
However, this is more work for us if we add an optional dependency on
the (graphviz) module, and not much better from the user’s viewpoint.

> However, at that
> point the graphviz library becomes a dependency of Guix.  Making it a
> dependency of Guix opens the possibility of moving the Guile module file
> into guix/graphviz.scm and make it part of Guix.

I think we should refrain from adding such a module in Guix; it should
be part of Graphviz itself.

>> So, thinking more about it, I think that in the case of ‘guix graph’,
>> it’s a bit of trouble for little in return.
>>
>> WDYT?  :-)
>>
>> Ludo’.
>
> I think it depends on whether it would be a problem to add the graphviz
> library as a dependency to Guix.

It would be a problem to depend on a (graphviz) module that is in fact
no distributed as part of Graphviz.

> The return is not so much the shorter (or longer ;-)) command, but
> more the completeness of Guix to produce a graphical output rather
> than a text file that can be used by another program to generate
> graphical output.
>
> If you think I should put my energy elsewhere on the project, I can and
> will respect that ;-).

Maybe it’s a good idea indeed, but I’ll let you judge that.  :-)

Thanks,
Ludo’.