Re: Dealing with language bindings for libraries.

[Catonano]

2018-05-09 17:21 GMT+02:00 Fis Trivial :

>
> Hi, Guixs.
>
> Recently I encountered some libraries that's written in c++ and have
> multiple language bindings, each of them has their corresponding build
> system, namely, R, Python, Java. And all the bindings are in
> tree. During the build process, One would first build the c++ part by
> cmake, then chdir into each language binding sub-directory and invoke
> its build system.
>
> For packaging them in guix, one way to deal with it is building each
> binding as an independent package, each package has it's own
> dependencies for the specific binding and common dependencies for C++
> part, that way, we will have N independent packages, for N language
> binding. But it will result in a huge waste of computing resource. I
> don't want to waste precious computing time of guix's build farm.
>

Maybe I'm being naive, but I don't understand why this would involve any
further overhead

You could have the c++ part as a dinamically linked library and the
bindings would have it as a dependency

What's the overhead in this ?

Re: Dealing with language bindings for libraries.

[Fis Trivial]

Catonano writes:

> 2018-05-09 17:21 GMT+02:00 Fis Trivial :
>
>>
>> Hi, Guixs.
>>
>> Recently I encountered some libraries that's written in c++ and have
>> multiple language bindings, each of them has their corresponding build
>> system, namely, R, Python, Java. And all the bindings are in
>> tree. During the build process, One would first build the c++ part by
>> cmake, then chdir into each language binding sub-directory and invoke
>> its build system.
>>
>> For packaging them in guix, one way to deal with it is building each
>> binding as an independent package, each package has it's own
>> dependencies for the specific binding and common dependencies for C++
>> part, that way, we will have N independent packages, for N language
>> binding. But it will result in a huge waste of computing resource. I
>> don't want to waste precious computing time of guix's build farm.
>>
>
> Maybe I'm being naive, but I don't understand why this would involve any
> further overhead
>
> You could have the c++ part as a dinamically linked library and the
> bindings would have it as a dependency
>
> What's the overhead in this ?

Thanks for the reply.

This is somehow like dealing with git submodules, people just include
submodules' directory in their build system, for example in cmake
script:

add_subdirectory(submodule_directory).

If you want to split it when packaging, you need to write a cmake config
script for that submodule and then patch the outer cmake file for
replacing `add_subdirectory` with `find_package`. I don't think there is
a shortcut for this. But doing so might be welcomed by upstream.


In the case of language binding, the build code for bindings would try
to find the shared object and other meta data required for build inside
build tree, not in system path. And by saying "try to find", it actually
tries to first invoke the c++ build tool(cmake, autotools etc.), then
walk through the build tree to check the shared object. I hope the
following listing can make it a bit clear what happens when building
without package manager:

1. Build the c++ part in project root /path-to-project/configure

   $ ./configure && make

2. Change dir into language binding subdirectory

   $ cd /path-to-project/python_binding

   a. Invoke build

  $ python setup.py build

   b. Build code for binding (setup.py in this example) invoke
  make in ../makefile first

   c. The c++ part has already been built manually at step 1,
   nothing needs to be done by make.

   d. Build code (setup.py) walk through the build tree to check
   the shared object built by make, and other required meta
   data.

   e. Build the binding part inside
   /path-to-project/python-binding.

3. repeat step 2 for other language bindings (replace setup.py
and directory name for their corresponding build script and
directory name).

So, to make the c++ part as shared object and let the bindings find it
at compile time, I need to rewrite all the build code for bindings,
which I don't consider necessary for either upstream nor packaging.

Re: Updating librsvg

[Marius Bakke]

Pierre Neidhardt  writes:

> Marius Bakke  writes:
>
>> Have anyone packaged any of these?  Or made a Rust importer?
>
> I know nothing about Rust, but "(guix) Invoking 'guix import'" mentions
> 'crate':
>
> --8<---cut here---start->8---
> ‘crate’
>  Import metadata from the crates.io Rust package repository
>  crates.io (https://crates.io).
> --8<---cut here---end--->8---

I had overlooked that, thanks!  Seems to work okay.


signature.asc
Description: PGP signature

Re: Updating librsvg

[Marius Bakke]

Ricardo Wurmus  writes:

> Hi Marius,
>
> thanks for working on this!
>
>> Our current version of librsvg is officially unmaintained, and the
>> latest version requires Rust.
> […]
>> * librsvg requires Cairo 1.15, which is not a "stable" release branch.
>
> Is there a maintained version of librsvg that depends on a stable
> release version of Cairo?

Unfortunately not.  The 2.42 series is the only maintained version of
librsvg, and depends on both Rust and the Cairo development branch.


signature.asc
Description: PGP signature

Re: next browser (was: Packaging a free Firefox)

[ajpatter]

Hi,

>
> Also your sbcl-iterate declaration uses "darcs-reference" which
> seems to be your own (unless I missed it).  Mind sharing it?  Thanks!
>

Right, I'll share this soon. In the mean time I think you should be able
to delete my definition of sbcl-iterate since one already exists in the
same file.

> --
> Pierre Neidhardt
>

Thanks,

--
Andy

Re: next browser (was: Packaging a free Firefox)

[ajpatter]

Hi Pierre,

>
> Hi Andy!
>
> Thanks for your help!  Wow, that's a lot of work!
> I hope you find time to commit it upstream, it would be a pity to let it
> go to waste :p
>
> Can you share the full definition of your freetype2 bindings?
> Thanks!
>
> sbcl-cffi-toolchain does not build for me:
>

[...]

> Any clue?

This looks like a problem with the asdf build system that I fixed, but
didn't finish getting pushed. I'll try to submit this again soon. You can
find the original patch here [1].


> --
> Pierre Neidhardt
>
> The sun never sets on those who ride into it.
>   -- RKO
>

--
Andy

[1] 

Re: next browser (was: Packaging a free Firefox)

[Pierre Neidhardt]

In the mean time, I figured that changing Alexandria's version from
"0.0.0-..." to "0.0.0" did the trick.

Now I'm stuck at packaging sbcl-cffi-gtk...

I'm fairly new to Common Lisp and I must say it's pretty overwhelming! :/
Any recommendation in terms of documentation to get me started?
I'll focus on the ASDF manual for now.

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature

Re: Dealing with language bindings for libraries.

[Catonano]

2018-05-10 11:27 GMT+02:00 Fis Trivial :

>
> Catonano writes:
>
> > 2018-05-09 17:21 GMT+02:00 Fis Trivial :
> >
> >>
> >> Hi, Guixs.
> >>
> >> Recently I encountered some libraries that's written in c++ and have
> >> multiple language bindings, each of them has their corresponding build
> >> system, namely, R, Python, Java. And all the bindings are in
> >> tree. During the build process, One would first build the c++ part by
> >> cmake, then chdir into each language binding sub-directory and invoke
> >> its build system.
> >>
> >> For packaging them in guix, one way to deal with it is building each
> >> binding as an independent package, each package has it's own
> >> dependencies for the specific binding and common dependencies for C++
> >> part, that way, we will have N independent packages, for N language
> >> binding. But it will result in a huge waste of computing resource. I
> >> don't want to waste precious computing time of guix's build farm.
> >>
> >
> > Maybe I'm being naive, but I don't understand why this would involve any
> > further overhead
> >
> > You could have the c++ part as a dinamically linked library and the
> > bindings would have it as a dependency
> >
> > What's the overhead in this ?
>
> Thanks for the reply.
>
> This is somehow like dealing with git submodules, people just include
> submodules' directory in their build system, for example in cmake
> script:
>
> add_subdirectory(submodule_directory).
>
> If you want to split it when packaging, you need to write a cmake config
> script for that submodule and then patch the outer cmake file for
> replacing `add_subdirectory` with `find_package`. I don't think there is
> a shortcut for this. But doing so might be welcomed by upstream.
>
>
> In the case of language binding, the build code for bindings would try
> to find the shared object and other meta data required for build inside
> build tree, not in system path.


Ah, now I see what you mean.

[...]
> So, to make the c++ part as shared object and let the bindings find it
> at compile time, I need to rewrite all the build code for bindings,
> which I don't consider necessary for either upstream nor packaging.
>

In my view, this is a form of bundling

Some projects bundle some libraries

This make life harder for packagers

It' s frown upon and considered a bad habit

In fact, in the Guix manual there' s a list of chacks to do when you review
a new package, submitted onto the mailing list

And one of the checks is to see if the packag _bundles_ anything and if it
doesm to try to unbundle and link to system provided resources instead

I think this case is similar

I understand it's boring but I think the right thing to do would be to
unbundle also in this case

Complicating the semantics of the packages (what a package is) is a risky
business.

Of course I'm the less competent system engineer and packager worldwide and
this is just my opinion 🙂

Re: Updating librsvg

[Mark H Weaver]

Marius Bakke  writes:

> Ricardo Wurmus  writes:
>
>> Hi Marius,
>>
>> thanks for working on this!
>>
>>> Our current version of librsvg is officially unmaintained, and the
>>> latest version requires Rust.
>> […]
>>> * librsvg requires Cairo 1.15, which is not a "stable" release branch.
>>
>> Is there a maintained version of librsvg that depends on a stable
>> release version of Cairo?
>
> Unfortunately not.  The 2.42 series is the only maintained version of
> librsvg, and depends on both Rust and the Cairo development branch.

There will be trouble if we try to link two different versions of
libcairo.so into the same process, so we cannot use the Cairo
development branch in librsvg while using the release branch of Cairo
elsewhere.  We would need to update our core Cairo package to 1.15.x.

So, I think the soonest we could consider doing this would be in
'core-updates-next'.  Even then, I would be quite nervous about doing
so, because Cairo is a core part of our graphics stack, and I don't
think librsvg is important enough to risk such a crucial component.

Hopefully Cairo 1.16 will be released soon, or perhaps the librsvg
developers could be persuaded to add support for Cairo 1.14.x.

What do you think?

In any case, thanks very much for your investigation.

  Mark

Re: a GUIX_PACKAGE_PATH / modules puzzle

[Nils Gillmann]

Okay, here's what I learned:

* except for source code, the modules itself in Guile aren't very
* detailed documented. The documentation is good, but...  ... it's
* nowhere mentioned that you can have a module (foo bar baz) and
* possibly also (foo bar baz kim) but (foo baz bar bar) will lead to
* the error I described.

So until I read into the core of Guile, I have 2 questions:

1. Is there a module name maximum length? -> So far I have encountered
very short module names in the wild, 3 the longest.

2. Is this really a module length problem? -> I have a functional set
of packages elsewhere, my non-core packages, named like (ports editors
foo foo) and so forth and they cause no problems. It's just weird to
me that the modules in ports and elsewhere work but in pkgs I can't
dissect the exact problem so far. I'm okay with any namespace, so
I'll simply remove the last element of the module names.

I'd like to improve documentations or other relevant places if
what I experienced is some kind of corner case in module naming,
be it in Guix or Guile... or just to note what to avoid with
regards to modules.

signature.asc
Description: PGP signature

Re: a GUIX_PACKAGE_PATH / modules puzzle

[Nils Gillmann]

Nils Gillmann transcribed 2.1K bytes:
> Okay, here's what I learned:
> 
> * except for source code, the modules itself in Guile aren't very
> * detailed documented. The documentation is good, but...  ... it's
> * nowhere mentioned that you can have a module (foo bar baz) and
> * possibly also (foo bar baz kim) but (foo baz bar bar) will lead to
> * the error I described.
> 
> So until I read into the core of Guile, I have 2 questions:
> 
> 1. Is there a module name maximum length? -> So far I have encountered
> very short module names in the wild, 3 the longest.
> 
> 2. Is this really a module length problem? -> I have a functional set
> of packages elsewhere, my non-core packages, named like (ports editors
> foo foo) and so forth and they cause no problems. It's just weird to
> me that the modules in ports and elsewhere work but in pkgs I can't
> dissect the exact problem so far. I'm okay with any namespace, so
> I'll simply remove the last element of the module names.
> 
> I'd like to improve documentations or other relevant places if
> what I experienced is some kind of corner case in module naming,
> be it in Guix or Guile... or just to note what to avoid with
> regards to modules.


Actually the problem is not really module names I just found out.

But I'm still curious about any possible guile module naming related limits
and hints from people working longer with Guile.

Re: GSoC project ``Syntax and semantics of systemd units in the Shepherd''

[Ioannis Panagiotis Koutsidis]

I installed the iso on my qemu without any issues. I was not aware about
the script, thanks for letting me know. Thankfully the installation was
easy enough not to require it.

Thank you for your help!

(resending the mail because I pressed "reply" instead of "reply all", sorry)

On 09/05/18 10:50, rek...@elephly.net wrote:
> 
> Hi Ioannis,
> 
> Ludovic Courtès  writes:
> 
>> Hello Ioannis,
>>
>> Ioannis Panagiotis Koutsidis  skribis:
>>
>>> I am Ioannis Panagiotis Koutsidis (Rukako on #guix) and I was selected
>>> for the ``Syntax and semantics of systemd units in the Shepherd'' GSoC
>>> 2018 project.
>>
>> Welcome on board!
>>
>> Now’s a good time to familiarize yourself with the Shepherd, presumably
>> by installing GuixSD.  Then please let us know about your first
>> impressions and how you feel about this GSoC project.
> 
> Did you get around to installing GuixSD yet?  Playing with the Shepherd
> really makes most sense on GuixSD.  You can also install Guix (note that
> we have an installer script, which makes this very easy) and then use
> Guix to build virtual machines with GuixSD.
> 
> --
> Ricardo
> 

Nairobi Guix talk

[Pjotr Prins]

First white hat GNU Guix talk in Africa (I think):

  
https://www.eventbrite.com/e/pjotr-prins-in-nairobi-on-functional-programming-hpcs-in-research-gnu-guix-tickets-45970402712

:)

Pj.

Re: next browser (was: Packaging a free Firefox)

[Andy Patterson]

Hi Pierre,

On Thu, 10 May 2018 16:36:11 +0200
Pierre Neidhardt  wrote:

> In the mean time, I figured that changing Alexandria's version from
> "0.0.0-..." to "0.0.0" did the trick.
> 
> Now I'm stuck at packaging sbcl-cffi-gtk...
> 
> I'm fairly new to Common Lisp and I must say it's pretty
> overwhelming! :/ Any recommendation in terms of documentation to get
> me started? I'll focus on the ASDF manual for now.

I'd also have a look at the manual page for the asdf build system,
which explains some of the quirks that exist with packaging common lisp
software. Unfortunately I don't have much advice to offer since my own
methods for package authoring and debugging are very unsophisticated.

Also, it looks like I forgot to CC the list when I replied with the
package definitions, so I'll attach them again here.

Feel free to let me know if you have any more questions about
packaging for common lisp.

Thanks,

--
Andy
>From 81b0547c40c20ef040e7bc0f2d0623b39bd38098 Mon Sep 17 00:00:00 2001
From: Andy Patterson 
Date: Thu, 10 May 2018 01:07:22 -0400
Subject: [PATCH] gnu: Add some lisp packages.

---
 gnu/packages/lisp.scm | 727 ++
 1 file changed, 727 insertions(+)

diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm
index 1f8e6ab42..17e709641 100644
--- a/gnu/packages/lisp.scm
+++ b/gnu/packages/lisp.scm
@@ -1433,3 +1433,730 @@ compressor.  It works on data produced by @code{parse-js} to generate a
  `(("sbcl" ,sbcl)
("sbcl-cl-uglify-js" ,sbcl-cl-uglify-js)))
 (synopsis "JavaScript compressor")))
+
+(define-public sbcl-closer-mop
+  (package
+(name "sbcl-closer-mop")
+(version "1.0.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "https://github.com/pcostanza/closer-mop";
+   "/archive/v" version ".tar.gz"))
+   (sha256
+(base32 "1pyc8lk2yxbjhycm57377vhxy0xrh2pmg0w89m7fifan6haiisbl"))
+   (file-name (string-append "closer-mop-" version ".tar.gz"
+(build-system asdf-build-system/sbcl)
+(home-page "https://github.com/pcostanza/closer-mop/";)
+(synopsis "Meta Object Protocol (MOP) compatibility layer")
+(description "Closer to MOP is a compatibility layer that rectifies many
+of the absent or incorrect CLOS MOP features across a broad range of Common
+Lisp implementations.")
+(license license:x11)))
+
+(define-public sbcl-trivial-types
+  (let ((commit "ee869f2b7504d8aa9a74403641a5b42b16f47d88")
+(revision "1"))
+(package
+  (name "sbcl-trivial-types")
+  (version (string-append "0.1-" revision "." (string-take commit 7)))
+  (source
+   (origin
+ (method git-fetch)
+ (uri (git-reference
+   (url "https://github.com/m2ym/trivial-types.git";)
+   (commit commit)))
+ (sha256
+  (base32 "1s4cp9bdlbn8447q7w7f1wkgwrbvfzp20mgs307l5pxvdslin341"))
+ (file-name (string-append "trivial-types-" version "-checkout"
+  (build-system asdf-build-system/sbcl)
+  (home-page "https://github.com/m2ym/trivial-types";)
+  (synopsis "Trivial type definitions")
+  (description "TRIVIAL-TYPES provides missing but important type
+definitions such as PROPER-LIST, ASSOCIATION-LIST, PROPERTY-LIST and TUPLE.
+By using these types, you can keep type declarations more accurate. For
+example, you may write a class definition like:
+
+@example
+(defclass person ()
+  ((name :type string))
+  ((age :type fixnum))
+  ((friends :type list)))
+@end example
+
+However, it is not obvious for anyone except you that FRIENDS slot has
+only a list of person. If you want declare FRIENDS slot more
+accurately, PROPER-LIST is the best for that:
+
+@example
+(defclass person ()
+  ((name :type string))
+  ((age :type fixnum))
+  ((friends :type (proper-list person
+@end example
+
+In addition, TRIVIAL-TYPES also provides standard designators defined
+in ANSI standard such as PACKAGE-DESIGNATOR. They are useful when you
+write a function that takes a package-oid argument like:
+
+@example
+(defun list-external-symbols (package)
+  (declare (package-designator package))
+  (loop for symbol being the external-symbol of package
+collect symbol))
+@end example
+")
+  (license license:lgpl2.0+
+
+(define-public sbcl-named-readtables
+  (let ((commit "4dfb89fa1af6b305b6492b8af042f5190c11e9fc")
+(revision "1"))
+(package
+  (name "sbcl-named-readtables")
+  (version (string-append "0.9-" revision "." (string-take commit 7)))
+  (source
+   (origin
+ (method git-fetch)
+ (uri (git-reference
+
+   (url "https://github.com/melisgl/named-readtables.git";)
+   (commit commit)))
+ (sha256
+  (base32 "083kgh5462iqbb4px6kq8s7sggvpvkm36hx4qi9rnaw53b6ilqkk"))
+ (file-name (string-append "named-readtables-" version "-checkout"
+  (build-system asdf-build-system/sbcl)
+  (home-p

Re: Dealing with language bindings for libraries.

[Konrad Hinsen]

On 09/05/2018 20:00, Julien Lepiller wrote:


We already have such a case: capstone and python-capstone. There is no
redundancy since python-capstone knows how to load the shared library
created in the capstone package. So we have two packages, with the same


My situation is a bit different. The package I am working on (OpenBabel, 
http://openbabel.org/wiki/Main_Page) has a monolithic build process 
based on CMake that builds the library plus bindings for all languages 
that it detects in its environment. There is no obvious way to build the 
language bindings to go with an already installed library.


It's almost trivial to package in Guix for any language combination you 
care about: just add the languages you need to the inputs. It's also 
straightforward to make each language binding a separate output of the 
package. But choosing this option makes building the package very expensive.


Konrad.