chicken scheme

chicken scheme

[John J Foerch]

Hello,

I ran into some problems when installing CHICKEN Scheme on my new GuixSD
system.  After installing the chicken package, 'chicken-install' failed
because gcc was not found on the system.  In the package definition for
chicken, gcc is listed as a native-input, but from what I understand it
should either be a regular input or a propagated-input, because CHICKEN
uses gcc to compile scheme programs.

I installed gcc separately, and then a test of chicken-install produced
this error:

    linux/limits.h: No such file or directory #include <linux/limits.h>

I was testing chicken-install with this command:

    $ chicken-install matchable

--
John Foerch

Re: chicken scheme

[Ludovic Courtès]

Hi,

John J Foerch <jjfoerch@earthlink.net> skribis:

> I ran into some problems when installing CHICKEN Scheme on my new GuixSD
> system.  After installing the chicken package, 'chicken-install' failed
> because gcc was not found on the system.  In the package definition for
> chicken, gcc is listed as a native-input, but from what I understand it
> should either be a regular input or a propagated-input, because CHICKEN
> uses gcc to compile scheme programs.

Good point.  Perhaps CHICKEN should keep references to the GCC toolchain
that was used to build it, or propagate it.  OTOH, it can in theory use
whatever GCC that it finds in $PATH, and people using the interpreter
don’t need GCC, which would be an argument in favor of the status quo.

Thoughts?

> I installed gcc separately, and then a test of chicken-install produced
> this error:
>
>     linux/limits.h: No such file or directory #include <linux/limits.h>
>
> I was testing chicken-install with this command:
>
>     $ chicken-install matchable

Could you run:

  guix package -r gcc -i gcc-toolchain

and try again?

The ‘gcc-toolchain’ package provides GCC, Binutils, glibc, and a wrapper
around ‘ld’ (it makes sure every library linked against is added to the
RUNPATH.)

Thanks for reporting the issue,
Ludo’.

Re: chicken scheme

[John J Foerch]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> John J Foerch <jjfoerch@earthlink.net> skribis:
>
>> I ran into some problems when installing CHICKEN Scheme on my new GuixSD
>> system.  After installing the chicken package, 'chicken-install' failed
>> because gcc was not found on the system.  In the package definition for
>> chicken, gcc is listed as a native-input, but from what I understand it
>> should either be a regular input or a propagated-input, because CHICKEN
>> uses gcc to compile scheme programs.
>
> Good point.  Perhaps CHICKEN should keep references to the GCC toolchain
> that was used to build it, or propagate it.  OTOH, it can in theory use
> whatever GCC that it finds in $PATH, and people using the interpreter
> don’t need GCC, which would be an argument in favor of the status quo.
>
> Thoughts?
>
>> I installed gcc separately, and then a test of chicken-install produced
>> this error:
>>
>>     linux/limits.h: No such file or directory #include <linux/limits.h>
>>
>> I was testing chicken-install with this command:
>>
>>     $ chicken-install matchable
>
> Could you run:
>
>   guix package -r gcc -i gcc-toolchain
>
> and try again?
>
> The ‘gcc-toolchain’ package provides GCC, Binutils, glibc, and a wrapper
> around ‘ld’ (it makes sure every library linked against is added to the
> RUNPATH.)
>
> Thanks for reporting the issue,
> Ludo’.

Hello Ludovic,

Installing gcc-toolchain helped, and there are no more compilation
errors.  Another error came up in trying to install the built files.
Here is my log:

  $ chicken-install matchable
  retrieving ...
  connecting to host "chicken.kitten-technologies.co.uk", port 80 ...
  requesting "/henrietta.cgi?name=matchable&mode=default" ...
  reading response ...
  HTTP/1.1 200 OK
  Date: Thu, 30 Jun 2016 21:36:20 GMT
  Server: Apache/2.2.29 (Unix) DAV/2 SVN/1.8.10 PHP/5.4.32 mod_fastcgi/2.4.6
  Connection: close
  Transfer-Encoding: chunked
  Content-Type: text/plain
  reading chunks ...
  reading files ...
    ./match-simple.scm
    ./match.scm
    ./matchable-test.scm
    ./matchable.meta
    ./matchable.scm
    ./matchable.setup
   matchable located at /tmp/temp112c.2170/matchable
  checking platform for `matchable' ...
  checking dependencies for `matchable' ...
  install order:
  ("matchable")
  installing matchable:3.6 ...
  changing current directory to /tmp/temp112c.2170/matchable
    '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csi' -bnq -setup-mode -e "(require-library setup-api)" -e "(import setup-api)" -e "(setup-error-handling)" -e "(extension-name-and-version '(\"matchable\" \"3.6\"))" 'matchable.setup'
    '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csc' -feature compiling-extension -setup-mode    -s -O3 -d0 matchable.scm -j matchable
    '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csc' -feature compiling-extension -setup-mode    -s -O3 -d0 matchable.import.scm
    cp -r 'matchable.so' '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so'
  cp: cannot create regular file ‘/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so’: Read-only file system

  Error: shell command failed with nonzero exit status 256:

    cp -r 'matchable.so' '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so'


  Error: shell command terminated with nonzero exit code
  17920
  "'/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csi' -bnq -setu...

--
John Foerch

Re: chicken scheme

[John J Foerch]

ludo@gnu.org (Ludovic Courtès) writes:
>
> Good point.  Perhaps CHICKEN should keep references to the GCC toolchain
> that was used to build it, or propagate it.  OTOH, it can in theory use
> whatever GCC that it finds in $PATH, and people using the interpreter
> don’t need GCC, which would be an argument in favor of the status quo.
>
> Thoughts?
>

I don't have enough experience with guix to give definite advice on
this, but chicken does present a couple of unique issues.  I think that
having gcc available is essential to chicken's purpose, as one is not
likely to only use the interpreter.  Installing extensions requires C
compilation, and if one is not installing extensions and not using
chicken's compiler, then one might as well be using any old scheme off
the street ;-)

If the gcc-toolchain were kept in reference (but not in the profile),
that may be enough.  The chicken compiler has options (and/or
environment variables) to use another gcc if desired, so people who want
to use another gcc than the one used to build chicken can still do so.

Some chicken extensions install executable programs (for example
hyde).  On other OSes they would normally be installed to
/usr/local/bin.  Obviously this would be different for guix.

--
John Foerch

Re: chicken scheme

[Ludovic Courtès]

John J Foerch <jjfoerch@earthlink.net> skribis:

> Installing gcc-toolchain helped, and there are no more compilation
> errors.  Another error came up in trying to install the built files.
> Here is my log:
>
>   $ chicken-install matchable
>   retrieving ...
>   connecting to host "chicken.kitten-technologies.co.uk", port 80 ...
>   requesting "/henrietta.cgi?name=matchable&mode=default" ...
>   reading response ...
>   HTTP/1.1 200 OK
>   Date: Thu, 30 Jun 2016 21:36:20 GMT
>   Server: Apache/2.2.29 (Unix) DAV/2 SVN/1.8.10 PHP/5.4.32 mod_fastcgi/2.4.6
>   Connection: close
>   Transfer-Encoding: chunked
>   Content-Type: text/plain
>   reading chunks ...
>   reading files ...
>     ./match-simple.scm
>     ./match.scm
>     ./matchable-test.scm
>     ./matchable.meta
>     ./matchable.scm
>     ./matchable.setup
>    matchable located at /tmp/temp112c.2170/matchable
>   checking platform for `matchable' ...
>   checking dependencies for `matchable' ...
>   install order:
>   ("matchable")
>   installing matchable:3.6 ...
>   changing current directory to /tmp/temp112c.2170/matchable
>     '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csi' -bnq -setup-mode -e "(require-library setup-api)" -e "(import setup-api)" -e "(setup-error-handling)" -e "(extension-name-and-version '(\"matchable\" \"3.6\"))" 'matchable.setup'
>     '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csc' -feature compiling-extension -setup-mode    -s -O3 -d0 matchable.scm -j matchable
>     '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csc' -feature compiling-extension -setup-mode    -s -O3 -d0 matchable.import.scm
>     cp -r 'matchable.so' '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so'
>   cp: cannot create regular file ‘/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so’: Read-only file system
>
>   Error: shell command failed with nonzero exit status 256:
>
>     cp -r 'matchable.so' '/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/var/lib/chicken/8/matchable.so'
>
>
>   Error: shell command terminated with nonzero exit code
>   17920
>   "'/gnu/store/avfhy6zgqmxgbvjrava16qyh60y6xwzv-chicken-4.11.0/bin/csi' -bnq -setu...

I think we need to build CHICKEN such that it uses /var/lib instead of
/gnu/store/…-chicken/var/lib (the latter is immutable.)  I suppose
that’s how it works on other distros, right?  (With this approach only
root can install software, though.)

Do you know how to make this change?

Thanks,
Ludo’.

Re: chicken scheme

[Ludovic Courtès]

John J Foerch <jjfoerch@earthlink.net> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
> I don't have enough experience with guix to give definite advice on
> this, but chicken does present a couple of unique issues.  I think that
> having gcc available is essential to chicken's purpose, as one is not
> likely to only use the interpreter.  Installing extensions requires C
> compilation, and if one is not installing extensions and not using
> chicken's compiler, then one might as well be using any old scheme off
> the street ;-)

Right, makes sense.  :-)

> If the gcc-toolchain were kept in reference (but not in the profile),
> that may be enough.  The chicken compiler has options (and/or
> environment variables) to use another gcc if desired, so people who want
> to use another gcc than the one used to build chicken can still do so.

OK.  Then I guess we should adjust our ‘chicken’ package so that it
hard-codes the absolute file name of ‘gcc’ and ‘ld’.  Would you like to
give it a try?

> Some chicken extensions install executable programs (for example
> hyde).  On other OSes they would normally be installed to
> /usr/local/bin.  Obviously this would be different for guix.

This part doesn’t sound Guix-dependent.  It’s more about whether
non-root users can install to, say, ~/.local, or whether only root can
install (to /usr/local/bin or similar.)  WDYT?

Thanks,
Ludo’.

Re: chicken scheme

[John J Foerch]

ludo@gnu.org (Ludovic Courtès) writes:

> John J Foerch <jjfoerch@earthlink.net> skribis:
>
>> Installing gcc-toolchain helped, and there are no more compilation
>> errors.  Another error came up in trying to install the built files.
>> Here is my log:
>>
>>  <SNIP>
>
> I think we need to build CHICKEN such that it uses /var/lib instead of
> /gnu/store/…-chicken/var/lib (the latter is immutable.)  I suppose
> that’s how it works on other distros, right?  (With this approach only
> root can install software, though.)
>
> Do you know how to make this change?
>
> Thanks,
> Ludo’.

First a question about /var/lib, and please excuse the newbie question.
If chicken extensions were installed to /var/lib, wouldn't that go
against the spirit of guix of keeping every program isolated?  Isn't
/var/lib global state?

I have just learned about 'guix import', and have the thought that a
package importer would be the better way to go.  Eventually I would like
to package software that I've written in CHICKEN for GuixSD, and only a
package importer would make that feasible.

I will definitely give it a try to add such a feature to guix, and will
follow whatever advice you may have.  In some ways I am still learning
the very basics of guix, so it may take me a bit to get up to speed.

Thank you,

--
John Foerch

Re: chicken scheme

[John J Foerch]

ludo@gnu.org (Ludovic Courtès) writes:

> John J Foerch <jjfoerch@earthlink.net> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>> I don't have enough experience with guix to give definite advice on
>> this, but chicken does present a couple of unique issues.  I think that
>> having gcc available is essential to chicken's purpose, as one is not
>> likely to only use the interpreter.  Installing extensions requires C
>> compilation, and if one is not installing extensions and not using
>> chicken's compiler, then one might as well be using any old scheme off
>> the street ;-)
>
> Right, makes sense.  :-)
>
>> If the gcc-toolchain were kept in reference (but not in the profile),
>> that may be enough.  The chicken compiler has options (and/or
>> environment variables) to use another gcc if desired, so people who want
>> to use another gcc than the one used to build chicken can still do so.
>
> OK.  Then I guess we should adjust our ‘chicken’ package so that it
> hard-codes the absolute file name of ‘gcc’ and ‘ld’.  Would you like to
> give it a try?
>

Sure!

>> Some chicken extensions install executable programs (for example
>> hyde).  On other OSes they would normally be installed to
>> /usr/local/bin.  Obviously this would be different for guix.
>
> This part doesn’t sound Guix-dependent.  It’s more about whether
> non-root users can install to, say, ~/.local, or whether only root can
> install (to /usr/local/bin or similar.)  WDYT?
>

Sorry, I don't really understand the issues at hand well enough yet to
comment.  I have been looking at 'guix import', as I said in my other
message, and I now wonder if a package importer is the best way forward,
in accordance with the guix spirit.

--
John Foerch

Re: chicken scheme

[Thompson, David]

On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch <jjfoerch@earthlink.net> wrote:

> First a question about /var/lib, and please excuse the newbie question.
> If chicken extensions were installed to /var/lib, wouldn't that go
> against the spirit of guix of keeping every program isolated?  Isn't
> /var/lib global state?

Yes, but this program is not Guix. It's a completely separate package
manager, and it should work as intended.

- Dave

Re: chicken scheme

[Ludovic Courtès]

John J Foerch <jjfoerch@earthlink.net> skribis:

> I have just learned about 'guix import', and have the thought that a
> package importer would be the better way to go.  Eventually I would like
> to package software that I've written in CHICKEN for GuixSD, and only a
> package importer would make that feasible.

"Thompson, David" <dthompson2@worcester.edu> skribis:

> On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch <jjfoerch@earthlink.net> wrote:
>
>> First a question about /var/lib, and please excuse the newbie question.
>> If chicken extensions were installed to /var/lib, wouldn't that go
>> against the spirit of guix of keeping every program isolated?  Isn't
>> /var/lib global state?
>
> Yes, but this program is not Guix. It's a completely separate package
> manager, and it should work as intended.

Agreed.  So I think there are two issues at hand:

  1. How to arrange our ‘chicken’ package so that ‘chicken-install’
     works as intended.

  2. How to import Eggs so that they can be first-class Guix packages.

#2, which means writing an importer, is definitely the most profitable
approach: It’s best as a user to have all the packages managed by the
same tool, especially if that provides isolation, transactional upgrades
and rollbacks, etc.

#1 is useful for CHICKEN users who are used to ‘chicken-install’
(similarly pip, npm, etc. are supposed to work.)  It should work in the
same way as on other distros.  I’ve never used it though, so I can’t
give precise advice.

Thanks,
Ludo’.

Re: chicken scheme

[John J Foerch]

ludo@gnu.org (Ludovic Courtès) writes:

> John J Foerch <jjfoerch@earthlink.net> skribis:
>
>> I have just learned about 'guix import', and have the thought that a
>> package importer would be the better way to go.  Eventually I would like
>> to package software that I've written in CHICKEN for GuixSD, and only a
>> package importer would make that feasible.
>
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
>> On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch <jjfoerch@earthlink.net> wrote:
>>
>>> First a question about /var/lib, and please excuse the newbie question.
>>> If chicken extensions were installed to /var/lib, wouldn't that go
>>> against the spirit of guix of keeping every program isolated?  Isn't
>>> /var/lib global state?
>>
>> Yes, but this program is not Guix. It's a completely separate package
>> manager, and it should work as intended.
>
> Agreed.  So I think there are two issues at hand:
>
>   1. How to arrange our ‘chicken’ package so that ‘chicken-install’
>      works as intended.
>
>   2. How to import Eggs so that they can be first-class Guix packages.
>
> #2, which means writing an importer, is definitely the most profitable
> approach: It’s best as a user to have all the packages managed by the
> same tool, especially if that provides isolation, transactional upgrades
> and rollbacks, etc.
>
> #1 is useful for CHICKEN users who are used to ‘chicken-install’
> (similarly pip, npm, etc. are supposed to work.)  It should work in the
> same way as on other distros.  I’ve never used it though, so I can’t
> give precise advice.
>

It installs all extensions to a single system-wide directory, with one
path component that gives the binary version.  On my debian machine,
that is /var/lib/chicken/7 (for chicken 4.10.0).  In that way, it is
simpler than something like npm.

--
John Foerch

Re: chicken scheme

[Ludovic Courtès]

John J Foerch <jjfoerch@earthlink.net> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> John J Foerch <jjfoerch@earthlink.net> skribis:
>>
>>> I have just learned about 'guix import', and have the thought that a
>>> package importer would be the better way to go.  Eventually I would like
>>> to package software that I've written in CHICKEN for GuixSD, and only a
>>> package importer would make that feasible.
>>
>> "Thompson, David" <dthompson2@worcester.edu> skribis:
>>
>>> On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch <jjfoerch@earthlink.net> wrote:
>>>
>>>> First a question about /var/lib, and please excuse the newbie question.
>>>> If chicken extensions were installed to /var/lib, wouldn't that go
>>>> against the spirit of guix of keeping every program isolated?  Isn't
>>>> /var/lib global state?
>>>
>>> Yes, but this program is not Guix. It's a completely separate package
>>> manager, and it should work as intended.
>>
>> Agreed.  So I think there are two issues at hand:
>>
>>   1. How to arrange our ‘chicken’ package so that ‘chicken-install’
>>      works as intended.
>>
>>   2. How to import Eggs so that they can be first-class Guix packages.
>>
>> #2, which means writing an importer, is definitely the most profitable
>> approach: It’s best as a user to have all the packages managed by the
>> same tool, especially if that provides isolation, transactional upgrades
>> and rollbacks, etc.
>>
>> #1 is useful for CHICKEN users who are used to ‘chicken-install’
>> (similarly pip, npm, etc. are supposed to work.)  It should work in the
>> same way as on other distros.  I’ve never used it though, so I can’t
>> give precise advice.
>>
>
> It installs all extensions to a single system-wide directory, with one
> path component that gives the binary version.  On my debian machine,
> that is /var/lib/chicken/7 (for chicken 4.10.0).  In that way, it is
> simpler than something like npm.

Right.  So to address #1, we should make sure it uses /var/lib, as
discussed earlier.

Thanks,
Ludo’.

Re: chicken scheme

[John J Foerch]

ludo@gnu.org (Ludovic Courtès) writes:

> John J Foerch <jjfoerch@earthlink.net> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> John J Foerch <jjfoerch@earthlink.net> skribis:
>>>
>>>> I have just learned about 'guix import', and have the thought that a
>>>> package importer would be the better way to go.  Eventually I would like
>>>> to package software that I've written in CHICKEN for GuixSD, and only a
>>>> package importer would make that feasible.
>>>
>>> "Thompson, David" <dthompson2@worcester.edu> skribis:
>>>
>>>> On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch <jjfoerch@earthlink.net> wrote:
>>>>
>>>>> First a question about /var/lib, and please excuse the newbie question.
>>>>> If chicken extensions were installed to /var/lib, wouldn't that go
>>>>> against the spirit of guix of keeping every program isolated?  Isn't
>>>>> /var/lib global state?
>>>>
>>>> Yes, but this program is not Guix. It's a completely separate package
>>>> manager, and it should work as intended.
>>>
>>> Agreed.  So I think there are two issues at hand:
>>>
>>>   1. How to arrange our ‘chicken’ package so that ‘chicken-install’
>>>      works as intended.
>>>
>>>   2. How to import Eggs so that they can be first-class Guix packages.
>>>
>>> #2, which means writing an importer, is definitely the most profitable
>>> approach: It’s best as a user to have all the packages managed by the
>>> same tool, especially if that provides isolation, transactional upgrades
>>> and rollbacks, etc.
>>>
>>> #1 is useful for CHICKEN users who are used to ‘chicken-install’
>>> (similarly pip, npm, etc. are supposed to work.)  It should work in the
>>> same way as on other distros.  I’ve never used it though, so I can’t
>>> give precise advice.
>>>
>>
>> It installs all extensions to a single system-wide directory, with one
>> path component that gives the binary version.  On my debian machine,
>> that is /var/lib/chicken/7 (for chicken 4.10.0).  In that way, it is
>> simpler than something like npm.
>
> Right.  So to address #1, we should make sure it uses /var/lib, as
> discussed earlier.
>

I'm finally getting back to this.  One point about chicken is that it
does not support multiple extension directories, only one.  They go into
<VARDIR>/chicken/<BINARY-VERSION>.  This introduces a difficulty because
if VARDIR is /var/lib, then the default extensions (that come with
chicken) get installed to a global directory.  The chicken-install
system will then work, but in the future when we add a package importer,
imported packages would also go into this global directory.

If on the other hand, VARDIR is (string-append out "/var/lib") the
default extensions and imported extensions go to the right place, but
manual chicken-install cannot write to that location.

Any further thoughts on this, given that information?

-- 
John Foerch

Re: chicken scheme

[Ludovic Courtès]

Hello!

John J Foerch <jjfoerch@earthlink.net> skribis:

> I'm finally getting back to this.  One point about chicken is that it
> does not support multiple extension directories, only one.  They go into
> <VARDIR>/chicken/<BINARY-VERSION>.  This introduces a difficulty because
> if VARDIR is /var/lib, then the default extensions (that come with
> chicken) get installed to a global directory.  The chicken-install
> system will then work, but in the future when we add a package importer,
> imported packages would also go into this global directory.
>
> If on the other hand, VARDIR is (string-append out "/var/lib") the
> default extensions and imported extensions go to the right place, but
> manual chicken-install cannot write to that location.
>
> Any further thoughts on this, given that information?

Ouch, that’s a problem.

Nixpkgs uses VARDIR=OUT/var/lib, meaning that chicken-install does not
work.

However, it also contains an optional patch that allows extensions to be
searched for elsewhere:

  https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/chicken/0001-Introduce-CHICKEN_REPOSITORY_EXTRA.patch

I think the best course of action would be to submit this change
upstream, if it hasn’t been done already.  It’s useful beyond Nix and
Guix, so it probably makes sense to include it.

In the meantime, I would (temporarily) sacrifice chicken-install in
favor of an Egg importer.

WDYT?

Thanks,
Ludo’.