System Crafters live stream today with a live exploration of Guile Hoot

Details here if you wanna tune in: https://fosstodon.org/@daviwil/111227316301869374

Re: readlink system calls

Op 22-08-2023 om 21:03 schreef Olivier Dion: On Tue, 22 Aug 2023, Christopher Baines wrote: When looking at strace for various Guile things, I'm seeing a lot of readlink system calls for directories in the load path, e.g. Is this not more a side effect of using Guix (the GNU store)

Re: readlink system calls

On Tue, 22 Aug 2023, Christopher Baines wrote: > When looking at strace for various Guile things, I'm seeing a lot of > readlink system calls for directories in the load path, e.g. Is this not more a side effect of using Guix (the GNU store) than Guile itself? -- Olivier Dion oldiob.dev

readlink system calls

When looking at strace for various Guile things, I'm seeing a lot of readlink system calls for directories in the load path, e.g. readlink("/gnu", 0x7fff8738f430, 1023) = -1 EINVAL (Invalid argument) readlink("/gnu/store", 0x7fff8738f430, 1023) = -1 EINVAL (Invalid argum

Re: How to capture pid of (system process?

Hi Jacob, Jacob Hrbek writes: >> If you want to do things asynchronuously, you can look at >> open-pipe. It should also be possible to build anything you want with >> the lower-level fork, execl, dup->fdes, ... primitives (assuming >> things are single-threaded). > > Can you elaborate? (I am noo

Re: How to capture pid of (system process?

Jacob Hrbek schreef op vr 17-12-2021 om 01:32 [+]: > Can you elaborate? (I am a noob in guile atm) These procedures are documented in the manual of Guile, you could look in the source code of Shepherd and Guix for examples. Most of these procedures are based on POSIX functions, so you could lo

Re: How to capture pid of (system process?

to be robust, but the project is designed for aviation and i want to do similar implementations later for more mission critical functions). So preferably i need a derivation that integrates with the system and is OS independent. > If you want to do things asynchronuously, you can look a

Re: How to capture pid of (system process?

; > (use-modules (ice-9 futures) >   (potato make)) > (initialize) > > (: "watch" '() >     (~ (do ((i 1 (1+ i))) >        ((> i 6)) >      (future (system >       "emacs")) >      ;;(let ((emacs_pid (getpid))) >       ;; (kill emacs_pid SIGTERM)))

Re: How to capture pid of (system process?

dules (ice-9 futures) >  (potato make)) > (initialize) > > (: "watch" '() >    (~ (do ((i 1 (1+ i))) >       ((> i 6)) >     (future (system >      "emacs")) >     ;;(let ((emacs_pid (getpid))) >      ;; (kill emacs_pid SIGTERM) > > (execute) &

How to capture pid of (system process?

(i 1 (1+ i)))       ((> i 6))     (future (system      "emacs"))     ;;(let ((emacs_pid (getpid)))      ;; (kill emacs_pid SIGTERM) (execute) #:SRC_END expecting to capture emacs's pid and kill it, but the issue is that using `getpid` gets me the PID of potato-make and `getpp

Re: Can system modify an environment variable in the current environment?

Il giorno gio, 02/09/2021 alle 22.06 +0200, Roel Janssen ha scritto: > > Or in this particular case, use the "add-to-load-path" procedure: > https://www.gnu.org/software/guile/manual/html_node/Load-Paths.html > An example usage of "add-to-load-path" is avalilable in Haunt, the static blog bu

Re: Can system modify an environment variable in the current environment?

On 02.09.2021 21:49, Mortimer Cladwell wrote: > Hi, > > Consider my file test.scm: > > (define (main args) > (let* ((myvar (string-append "export > GUILE_LOAD_PATH=/some/random/text:$GUILE_LOAD_PATH")) >(statement1 (system (string-append

Re: Can system modify an environment variable in the current environment?

Dear Mortimer, On Thu, 2021-09-02 at 15:49 -0400, Mortimer Cladwell wrote: > Hi, > > Consider my file test.scm: > > (define (main args) >   (let* ((myvar (string-append "export > GUILE_LOAD_PATH=/some/random/text:$GUILE_LOAD_PATH")) >    (statement1 (s

Can system modify an environment variable in the current environment?

Hi, Consider my file test.scm: (define (main args) (let* ((myvar (string-append "export GUILE_LOAD_PATH=/some/random/text:$GUILE_LOAD_PATH")) (statement1 (system (string-append "echo " myvar " >> $HOME/.bashrc"))) (statement2 (system

Re: build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)

Zelphir Kaltstahl writes: > Do you have an example for when one would bake in > system-specific data-paths? To satisfy distribution packaging standards your project files may end up in different directories and cannot assume that the relative relationship between files remains unchange

Re: build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)

Hello Arne! Thank you for that! Do you have an example for when one would bake in system-specific data-paths? Best wishes, Zelphir On 1/31/21 4:38 PM, Dr. Arne Babenhauserheide wrote: > Zelphir Kaltstahl writes: >> This may be short sighted or uninformed, but generally I don't

Re: build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)

ibutions in packaging it These 2 points could be true for the Guile build system too, I don't know Hope this helps

Re: build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)

ation - set specific optimization parameters (i.e. O3) - bake-in system-specific data-paths (i.e. images to load) Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature

Re: build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)

lz) writes: > >> Hi Ricardo, >> >> On Sat, Jan 30, 2021 at 10:15:20PM +0100, Ricardo Wurmus wrote: >>> If all you have are Guile modules and all you want is to package it for >>> Guix then you really don’t need to bother with Autotools. Use the >>> “gui

Re: build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)

pelzflorian (Florian Pelz) writes: > Hi Ricardo, > > On Sat, Jan 30, 2021 at 10:15:20PM +0100, Ricardo Wurmus wrote: >> If all you have are Guile modules and all you want is to package it for >> Guix then you really don’t need to bother with Autotools. Use the >> “g

build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)

Hi Ricardo, On Sat, Jan 30, 2021 at 10:15:20PM +0100, Ricardo Wurmus wrote: > If all you have are Guile modules and all you want is to package it for > Guix then you really don’t need to bother with Autotools. Use the > “guile-build-system”. It can be as simple as the “guile-srfi-89”

(system xref)

In system xref there are, among others, 2 procedures procedure-callees and procedure-callers I only get empty lists from them, anyway I call them Could anyone here provide me with an example of calling such procedures in a way that produces a list containing at least one value ? Thanks

Re: system command output different in guile than on command line

On Wed, Aug 05, 2020 at 11:27:30AM +, vapnik spaknik via General Guile related discussions wrote: [...] > OK... I was being stupid. We all are, most of us more often than not ;-) >Another strange thing is that if I use the pipeline procedure to do the same >thing, then I get an exit code

Re: system command output different in guile than on command line

s 215 >However when I run the following in guile: > >guile> (system "diff -ua /tmp/file1 /tmp/file2 | wc -c") > >it prints 243. OK... I was being stupid. The shell command that I actually ran was: diff -ua file1 file2 | wc -c i.e. without the directories in the paths since I

Re: system command output different in guile than on command line

However when I run the following in guile: > > guile> (system "diff -ua /tmp/file1 /tmp/file2 | wc -c") Have you actually tried to compare both results? There are a couple of things which could make a difference. The one which first comes to mind would be different environments

Re: New object system?

> On Jul 28, 2017, at 11:34 AM, Stefan Israelsson Tampe > wrote: > > Hi all. We have goops, but I wondered how a functional object system can look > like and after some thought I modeled together functional and python together > with scheme. you can find the result at

New object system?

Hi all. We have goops, but I wondered how a functional object system can look like and after some thought I modeled together functional and python together with scheme. you can find the result at http://www.c-lambda.se/functional-python.html If you want to discuss, continue with the email or on

Re: Bytestructures: a "type system" for bytevectors

rg to select which typedef references to preserve) 3) provides parser argument to choose which defines get expanded 4) provides utility to unwrap declarations There is still a lot to do to support FFI. E.g., what to do about system dependencies (e.g., is “int" 32 bits or 64 bits) My stuff i

Re: Bytestructures: a "type system" for bytevectors

rg to select which typedef references to preserve) 3) provides parser argument to choose which defines get expanded 4) provides utility to unwrap declarations There is still a lot to do to support FFI. E.g., what to do about system dependencies (e.g., is “int" 32 bits or 64 bits) My stuff i

Re: Bytestructures: a "type system" for bytevectors

> On Jun 21, 2016, at 12:50 AM, Taylan Ulrich Bayırlı/Kammer > wrote: > > Matt Wette writes: > >> nyacc is an all-guile implementation of yacc and comes with a c99 >> parser, available from www.nongnu.org. >> The parser outputs parse trees in sxml format. It is beta-level code. >> >> Matt >

Re: Bytestructures: a "type system" for bytevectors

Matt Wette writes: > nyacc is an all-guile implementation of yacc and comes with a c99 > parser, available from www.nongnu.org. > The parser outputs parse trees in sxml format. It is beta-level code. > > Matt Wow! That covers a big chunk of the task, if I implement it from scratch. In fact, g

Re: Bytestructures: a "type system" for bytevectors

> On Jun 20, 2016, at 3:05 PM, Taylan Ulrich Bayırlı/Kammer > wrote: > [SNIP] > Would I have to write a C parser in Scheme, or can we cheat somehow? scheme@(guile-user)> (use-modules (nyacc lang c99 parser)) scheme@(guile-user)> (use-modules (ice-9 pretty-print)) scheme@(guile-user)> (pretty-

Re: Bytestructures: a "type system" for bytevectors

Andy Wingo writes: > On Sun 30 Aug 2015 18:32, taylanbayi...@gmail.com (Taylan Ulrich > "Bayırlı/Kammer") writes: > >> https://github.com/taylanub/scheme-bytestructures >> >> (I don't endorse GitHub, but I gave in after Gitorious went down.) >> >> I had started working on this project around two

Re: Bytestructures: a "type system" for bytevectors

On Sun 30 Aug 2015 18:32, taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes: > https://github.com/taylanub/scheme-bytestructures > > (I don't endorse GitHub, but I gave in after Gitorious went down.) > > I had started working on this project around two years ago but it had a > prett

Re: failed make: "'aclocal-1.14' is missing on your system"

2016-05-21 22:13 GMT+02:00 : > Thomas Morley wrote: >> Hi all, >> >> I cloned the guile-git-repository in my home-directory and tried to >> compile a local branch called `my-v2-second-try` (derived from >> `remotes/origin/stable-2.0`). >> >> Following the steps listed in INSTALL I did >> ./c

Re: failed make: "'aclocal-1.14' is missing on your system"

Thomas Morley wrote: > Hi all, > > I cloned the guile-git-repository in my home-directory and tried to > compile a local branch called `my-v2-second-try` (derived from > `remotes/origin/stable-2.0`). > > Following the steps listed in INSTALL I did > ./configure The INSTALL instruction are

failed make: "'aclocal-1.14' is missing on your system"

)$ make CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /home/hermann/guile/build-aux/missing aclocal-1.14 -I m4 /home/hermann/guile/build-aux/missing: line 81: aclocal-1.14: command not found WARNING: 'aclocal-1.14' is missing on your system. You

Re: Bytestructures: a "type system" for bytevectors

r arrays. Unions aren't supported at all. Bytestructures imitates C's type system in full w.r.t. numeric, array (vector), struct, union, and pointer types. Though there are two main missing things now: tight packing and bit fields. Tight packing should be simple to implement by allowing

Re: Bytestructures: a "type system" for bytevectors

@gnu.org Subject: Re: Bytestructures: a "type system" for bytevectors taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes: > That's all there is to it, and you could populate those bytes directly, > one by one: > > the_struct_t my_struct = { a, b, c, d,

Re: system calls

Tomas By : > In a Guile program I am using (system ) to start a C binary > which I then communicate with over the network. > > I'm wondering if there is any way to get the process id of this binary? > > Have tried to call "ps -A|grep " using with-output-to-strin

system calls

Hi all, In a Guile program I am using (system ) to start a C binary which I then communicate with over the network. I'm wondering if there is any way to get the process id of this binary? Have tried to call "ps -A|grep " using with-output-to-string and with-error-to-str

Re: Bytestructures: a "type system" for bytevectors

ause I couldn't find precise information on what an FFI system should support wrt. data structure alignment. I read a little on Wikipedia and peeked into the documentation of Haskell's FFI and CL's CFFI. The struct constructor takes an `align?' argument now, which if true will enab

Bytestructures: a "type system" for bytevectors

ss to bytevector contents === Don't tell C-standard pedants, but the type system of C is nothing more than a thin layer over your computer memory: a huge sequence of bytes. Compilers are allowed some crazy things as per the strict standards language, but if you define a struct { uint16_t x;

Re: Guile 1.8 / Viper System Interface

;t anymore. > > Look at my violations of your broken concepts here: > https://code.launchpad.net/viper-system-interface > *and you better learn to behave*. > > Thank you for your support on this mailing list. I think I can still > smell your rum here. Shrug. With that communica

Re: Guile 1.8 / Viper System Interface

ncepts here: https://code.launchpad.net/viper-system-interface *and you better learn to behave*. Thank you for your support on this mailing list. I think I can still smell your rum here.

Re: Guile 1.8 / Viper System Interface

Michael Tiedtke writes: > On 29/06/2015 09:55, David Kastrup wrote: >> Marco Maggi writes: >> >>> Michael Tiedtke wrote: >>> >>>> Today the first successful clean room build of Viper's System >>>> Interface (still heavily recogni

Re: Guile 1.8 / Viper System Interface

oday the first successful clean room build of Viper's System > >>> Interface (still heavily recognizable as Guile 1.8) compiled > >>> successfully and ran for the first time. > >> Excuse me, I step in as a foreigner. If you do an unofficial fork of a > >&g

Re: Guile 1.8 / Viper System Interface

On 29/06/2015 09:55, David Kastrup wrote: Marco Maggi writes: Michael Tiedtke wrote: Today the first successful clean room build of Viper's System Interface (still heavily recognizable as Guile 1.8) compiled successfully and ran for the first time. Excuse me, I step in as a foreigner.

Re: Guile 1.8 / Viper System Interface

Marco Maggi writes: > Michael Tiedtke wrote: > >> Today the first successful clean room build of Viper's System >> Interface (still heavily recognizable as Guile 1.8) compiled >> successfully and ran for the first time. > > Excuse me, I step in as a foreigner.

Re: Guile 1.8 / Viper System Interface

Michael Tiedtke wrote: > Today the first successful clean room build of Viper's System > Interface (still heavily recognizable as Guile 1.8) compiled > successfully and ran for the first time. Excuse me, I step in as a foreigner. If you do an unofficial fork of a GNU project

Re: Guile 1.8 / Viper System Interface

Today the first successful clean room build of Viper's System Interface (still heavily recognizable as Guile 1.8) compiled successfully and ran for the first time. Right now it's source tree of C files is about 4,5 MB on the file system with the generated 1.1 MB linux-x86_64 binar

Re: Guile 1.8 / Viper System Interface

Today the first successful clean room build of Viper's System Interface (still heavily recognizable as Guile 1.8) compiled successfully and ran for the first time. Right now it's source tree of C files is about 4,5 MB on the file system with the generated 1.1 MB linux-x86_64 binar

Re: Guile 1.8 / Viper System Interface

klaus schilling writes: > Thien-Thi Nguyen writes: > >> [1:text/plain Hide] >> >> () David Pirotte >> () Fri, 26 Jun 2015 16:36:30 -0300 >> >>> Sorry, you got me wrong. This is an announcement thread for >>> those interested. >> >>None of us is interested in guile-1.8, please use gu

Re: Guile 1.8 / Viper System Interface

Thien-Thi Nguyen writes: > [1:text/plain Hide] > > () David Pirotte > () Fri, 26 Jun 2015 16:36:30 -0300 > >> Sorry, you got me wrong. This is an announcement thread for >> those interested. > >None of us is interested in guile-1.8, please use guile-2 > > I'm still interested. If th

Re: Guile 1.8 / Viper System Interface

bguile *** TODO Remove lang.doc references *** GNU libtool version match to system - 2.4 instead of 2.4.2 - revision 1.3293 instead 1.3337 - in aclocal.m4 and in configure - redo this everytime autconf is run *** libtool is missing (environment) variables "export tool_oldlib=.l

Re: Guile 1.8 / Viper System Interface

() David Pirotte () Fri, 26 Jun 2015 16:36:30 -0300 > Sorry, you got me wrong. This is an announcement thread for > those interested. None of us is interested in guile-1.8, please use guile-2 I'm still interested. If the new fork can handle all the stuff (w/o breakage) at:

Re: Guile 1.8 / Viper System Interface

On 26/06/2015 21:36, David Pirotte wrote: Hi Michael, Sorry, you got me wrong. This is an announcement thread for those interested. None of us is interested in guile-1.8, please use guile-2 Cheers, David Sorry, today I exterminated elisp and emacs support from my 1.8 branch. Libtool is my

Re: Guile 1.8 / Viper System Interface

Hi Michael, > Sorry, you got me wrong. This is an announcement thread for those > interested. None of us is interested in guile-1.8, please use guile-2 Cheers, David pgp3DcuFjbMY1.pgp Description: OpenPGP digital signature

Re: Guile 1.8 / Viper System Interface

On 26/06/2015 08:39, David Pirotte wrote: Hello, Please let me know when you're interested in a cleaned up Guile 1.8 and the clean and lean Scheme path. None of us is interested in guile-1.8, please use guile-2, and if oop, please use goops. David Sorry, you got me wrong. This is an an

Re: Guile 1.8 / Viper System Interface

Hello, > Please let me know when you're interested in a cleaned up Guile 1.8 and > the clean and lean Scheme path. None of us is interested in guile-1.8, please use guile-2, and if oop, please use goops. David pgpwte4tYjdwQ.pgp Description: OpenPGP digital signature

Guile 1.8 / Viper System Interface

on language that it was meant to be - but you could as well turn it around and say I'm using it as the system interface for my scheme application. My current goals are: - remove all traces of elisp completely: it's all over the place and not useful at all (will be finished today

Re: System Scheme (was Re: GOOPS Terminal Class - RnRS POSIX support)

Marko Rauhamaa skribis: > Eli Zaretskii : > > From: Marko Rauhamaa >>> I'd like to produce Guile code that works on Linux. As it stands, I >>> can't. >> >> Of course you can: write it in C and load it via FFI. > > Well, for that, I don't even need Guile; all I need is gcc. > > It's a bit of

Re: System Scheme (was Re: GOOPS Terminal Class - RnRS POSIX support)

;s a bit of a lame reason to have to escape out of Scheme; after all, Guile already incorporates most system facilities. Note that Python allows you to pass file descriptors over Unix domain sockets. Marko

Re: System Scheme (was Re: GOOPS Terminal Class - RnRS POSIX support)

>>> From: Marko Rauhamaa >>> Date: Tue, 23 Jun 2015 11:08:23 +0300 >>> Cc: guile-user@gnu.org >>> >>> Michael Tiedtke : >>>> POSIX isn't that important or useful anymore but "full access to >>>> POSIX system calls"

System Scheme (was Re: GOOPS Terminal Class - RnRS POSIX support)

On 23/06/2015 20:09, Marko Rauhamaa wrote: Eli Zaretskii : From: Marko Rauhamaa Date: Tue, 23 Jun 2015 11:08:23 +0300 Cc: guile-user@gnu.org Michael Tiedtke : POSIX isn't that important or useful anymore but "full access to POSIX system calls" it has never been. What I

system asyncs

Hi Folks, In the 2.0 Guile Reference Manual, Section 6.21.2.1 it says: The blocking level starts out at zero, and whenever a safe point is reached, a blocking level greater than zero will prevent the execution of queued asyncs. Can anyone elaborate on this a little? I don't understand this sta

Re: System commands with error escaping

, for instance relies on the obsolete (ice-9 optargs-kw). Didn't check further, anyhow couldn't build it... I've settled on the simple approach now: (let ((return (system command-string))) (if (not (eqv? 0 return)) (throw 'error))) Which stop fine if run like this. How

Re: System commands with error escaping

() "白熊 @相撲道" () Thu, 27 Nov 2014 00:18:22 +0300 The problem with this is, when configure fails for example due to an error, I don't catch the error and next command gets executed... But I need to catch the error and stop Guile from proceeding, so I see what happened. How can I bes

System commands with error escaping

Hello everyone: I'd like to ask for help with the following: I'm programming a Guile automation interface for GNU software compilation and need to issue system calls with error escaping. I have package recipes, which then issue mostly specific configure and make system calls a

Re: system

Taylan Ulrich Bayirli/Kammer skribis: > Tim Even writes: > > > I've been using Chez/Petite Scheme's system command as a sort of > > Scheme interface to Netpbm and other executables. Any information -- > > more than what is in the documentation -- on a Guile equ

Re: system

Tim Even writes: > I've been using Chez/Petite Scheme's system command as a sort of > Scheme interface to Netpbm and other executables. Any information -- > more than what is in the documentation -- on a Guile equivalent? Guile has a `system' procedure as well. Note th

system

Hello, I've been using Chez/Petite Scheme's system command as a sort of Scheme interface to Netpbm and other executables. Any information -- more than what is in the documentation -- on a Guile equivalent? Thanks -- Tim R. Even Alcott College Prep SECA II Technology Coordinat

Re: guile-2.0.11 installation on system with 2.0.5

Hello, > ... > OK, I've found out by using "apt-cache policy package-name": I need to > lower the default priorities of packages from testing other than guile > with > > Package: * > Pin: release o=Debian > Pin-Priority: 10 good to know, tx! > Now I do not get other packages with "aptitude full

Re: guile-2.0.11 installation on system with 2.0.5

Chris Vine writes: > But quite honestly, if you want to experiment with newer software don't > use an archaic distribution such as debian stable, which is out of date > even when first released. Umm, I think it's quite reasonable to run a distribution of older software that has gone through a lon

Re: guile-2.0.11 installation on system with 2.0.5

On Tue, Sep 16, 2014 at 1:09 PM, Federico Beffa wrote: > David Pirotte writes: > >> Hello, >> >>> As far as I inderstand the Debian package manager mantains a package >>> database. This is the place where it looks for installed packages. So, >>> if I have a newer version of guile which is not ins

Re: guile-2.0.11 installation on system with 2.0.5

David Pirotte writes: > Hello, > >> As far as I inderstand the Debian package manager mantains a package >> database. This is the place where it looks for installed packages. So, >> if I have a newer version of guile which is not installed through the >> package manager, the package manager will

Re: guile-2.0.11 installation on system with 2.0.5

Hello, > As far as I inderstand the Debian package manager mantains a package > database. This is the place where it looks for installed packages. So, > if I have a newer version of guile which is not installed through the > package manager, the package manager will not know about it. even if you

Re: guile-2.0.11 installation on system with 2.0.5

Chris Vine writes: > On Mon, 15 Sep 2014 13:46:07 +0200 > Federico Beffa wrote: > [snip] >> Your guess is correct: The distribution that I'm using (Debian wheezy) >> ships 2.0.5 as the newest guile version and I need to keep it to >> satisfy dependencies of other distribution supplied packages.

Re: guile-2.0.11 installation on system with 2.0.5

On Mon, 15 Sep 2014 13:46:07 +0200 Federico Beffa wrote: [snip] > Your guess is correct: The distribution that I'm using (Debian wheezy) > ships 2.0.5 as the newest guile version and I need to keep it to > satisfy dependencies of other distribution supplied packages. > However, I would like to exp

Re: guile-2.0.11 installation on system with 2.0.5

Neil Jerram writes: > On 2014-09-15 02:16, m...@netris.org wrote: >> Federico Beffa writes: >> >>> I notice that there is an /etc/ld.so.cache file. Do I somehow need >>> to update >>> it? >> >> Yes, you update it by running "ldconfig" as root. This needs to be >> done >> when installing librari

Re: guile-2.0.11 installation on system with 2.0.5

Chris Vine writes: > On Sun, 14 Sep 2014 21:16:39 -0400 > m...@netris.org wrote: >> Federico Beffa writes: >> >> > Neil Jerram writes: >> > >> >> >> >> This is just a guess, but what happens if you do this: >> >> >> >> $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile >> >> >> >> Regards, >

Re: guile-2.0.11 installation on system with 2.0.5

tup message. I would strongly advise you not to have two binary compatible versions of any given library on your system at the same time, unless you really know what you are doing. Otherwise you are at the mercy of the look-up order of the dynamic linker. It is much better simply to upgrade your sy

Re: guile-2.0.11 installation on system with 2.0.5

On Sun, 14 Sep 2014 21:16:39 -0400 m...@netris.org wrote: > Federico Beffa writes: > > > Neil Jerram writes: > > > >> > >> This is just a guess, but what happens if you do this: > >> > >> $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile > >> > >> Regards, > >> Neil > > > > With this it

Re: guile-2.0.11 installation on system with 2.0.5

On Mon, Sep 15, 2014 at 11:49 AM, Neil Jerram wrote: > On 2014-09-15 02:16, m...@netris.org wrote: >> >> Federico Beffa writes: >> >>> Neil Jerram writes: >>> This is just a guess, but what happens if you do this: $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile >>>

Re: guile-2.0.11 installation on system with 2.0.5

On 2014-09-15 02:16, m...@netris.org wrote: Federico Beffa writes: Neil Jerram writes: This is just a guess, but what happens if you do this: $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile Regards, Neil With this it works! I notice that there is an /etc/ld.so.cache file. D

Re: guile-2.0.11 installation on system with 2.0.5

Federico Beffa skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> It may be that, while /usr/local/bin/guile is indeed from the new >> version, it ends up loading .scm and .go files from the old version. >> >> You could check that by running: >> >> strace -o log /usr/local/bin/guile --versi

Re: guile-2.0.11 installation on system with 2.0.5

Federico Beffa writes: > Neil Jerram writes: > >> >> This is just a guess, but what happens if you do this: >> >> $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile >> >> Regards, >> Neil > > With this it works! > > I notice that there is an /etc/ld.so.cache file. Do I somehow need to up

Re: guile-2.0.11 installation on system with 2.0.5

sted that > the /etc/ld.so.cache file gets opened. Should I need somehow to > update it? If it is any use to you, to run guile-1.8 on a guile-2.0 system (which I rarely do) I set the following environmental variables in the script which starts guile and/or which compiles or loads anything which

Re: guile-2.0.11 installation on system with 2.0.5

l...@gnu.org (Ludovic Courtès) writes: > It may be that, while /usr/local/bin/guile is indeed from the new > version, it ends up loading .scm and .go files from the old version. > > You could check that by running: > > strace -o log /usr/local/bin/guile --version > > and grepping for .scm and .g

Re: guile-2.0.11 installation on system with 2.0.5

Neil Jerram writes: > > This is just a guess, but what happens if you do this: > > $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile > > Regards, > Neil With this it works! I notice that there is an /etc/ld.so.cache file. Do I somehow need to update it? Thanks, Fede

Re: guile-2.0.11 installation on system with 2.0.5

en, for instance, if there’s a GUILE_LOAD_PATH or GUILE_LOAD_COMPILED_PATH environment variable pointing to /usr/share/guile/... > Am I doing something wrong? Is it possible to have two guile versions > on the same system? Yes. Thanks, Ludo’.

Re: guile-2.0.11 installation on system with 2.0.5

n provided by the Debian package. > > Am I doing something wrong? Is it possible to have two guile versions > on the same system? This is just a guess, but what happens if you do this: $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/guile Regards, Neil

Re: guile-2.0.11 installation on system with 2.0.5

> Hi Federico, > That is odd, on my Debian "wheezy" system, the debian packaged guile > is a symbolic link /usr/bin/guile to > /etc/alternatives/guile, which in turn is a symbolic link to > /usr/bin/guile-2.0 . What returns from the command "which guile" o

Re: guile-2.0.11 installation on system with 2.0.5

Hi Federico, That is odd, on my Debian "wheezy" system, the debian packaged guile is a symbolic link /usr/bin/guile to /etc/alternatives/guile, which in turn is a symbolic link to /usr/bin/guile-2.0 . What returns from the command "which guile" on your system ? The method

guile-2.0.11 installation on system with 2.0.5

alled guile with $ /usr/local/bin/guile I was greeted with GNU Guile 2.0.5-deb+1-3 Copyright (C) 1995-2012 Free Software Foundation, Inc. ... which correspond to the version provided by the Debian package. Am I doing something wrong? Is it possible to have two guile versions on the same system? Re

Re: What is the output port of `system*'?

>> As an example of this behavior, I point to the following Racket program: >> >> #lang racket >> >> (define foo >> (with-output-to-string >> (lambda () >> (system* (find-executable-path "ls") "/tmp" > > I

Re: What is the output port of `system*'?

"Diogo F. S. Ramos" writes: >> "Diogo F. S. Ramos" writes: >> >>> The following program doesn't output to a string, which I expected. >>> >>> (define foo >>> (with-output-to-string >>> (lambda () >>&g

Re: What is the output port of `system*'?

> "Diogo F. S. Ramos" writes: > >> The following program doesn't output to a string, which I expected. >> >> (define foo >> (with-output-to-string >> (lambda () >> (system* "ls" "/tmp" > > A

Re: What is the output port of `system*'?

"Diogo F. S. Ramos" writes: > The following program doesn't output to a string, which I expected. > > (define foo > (with-output-to-string > (lambda () > (system* "ls" "/tmp" As the manual says about `system*': >

What is the output port of `system*'?

The following program doesn't output to a string, which I expected. --8<---cut here---start->8--- (define foo (with-output-to-string (lambda () (system* "ls" "/tmp" --8<---cut here---end--->8---

  1   2   >