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 <address@hidden> 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.