IRC channel logs

2017-07-23.log

back to list of logs

<reepca>A program started with system* should have the same input/output as the program that started it, right?
<daviid>reepca: but, if you want to get your hands on the results you should use (ice-9 popen) instead
<daviid>reepca: see 7.2.10 Pipes
<reepca>I'm wondering because I'm in a rather strange situation where I can run programs but can't see their output. Probably has something to do with file descriptors in this chroot thingy that I haven't fully comprehended yet.
<reepca>but good to know it's not a guile issue
<daviid>reepca: well you cn try this in a repl: (system "ls") and see it displays the results of the ls command on guile's standard output port, but you can't 'use' these results, such as getting a math value to process it i gule after the command is executed ... that requires (ice-9 popen)
<reepca>slightly off-topic, but are symlinks resolved lazily? That is, if I symlink from A to B, and B is a symlink to C, and I later change B to symlink to D instead, will accessing A give me C or D?
<reepca>daviid: ah, that's just the problem, though - (system "ls") doesn't show me any output at all.
<daviid>reepca: in a repl? that means somwhow you redefined the dtandard output prt I guess, not sure
<reepca>(current-output-port) => #<input-output: socket 21>
<reepca>I'm connecting from geiser, could that have anything to do with it?
<daviid>reepca: for advanced system programming, you really want to define and use your input output ports, imo at least
<daviid>it seems you connected to a spawn server rather then M-x run-guile
<reepca>yep, I needed to run guile in a certain environment
<reepca>hm, outside of the chroot madness, (system "ls") produces output in the shell running the listener
<reepca>but I just need the output for debugging anyway - I'll just write a wrapper around system that uses a pipe and prints the output.
<reepca>err, not a wrapper around system - something that mimicks system.
<daviid>reepca: yes, in that case it will display the output of system/system* in the shell where you launched guile
<ShedDweller>Does Guile have an equivalent to "defstruct"?
<amz3`> https://github.com/fantasyland/fantasy-land \\cc davexunit
<rekado_>Is it possible to “dump an image” of an environment in Guile?
<rekado_>I’d like to be able to serialise a closure of a Guix package to a small binary and deserialise it at a later point.
<rekado_>I’ve played around with “read-and-compile”, but the resulting binary is dynamically linked, i.e. it still depends on having all referenced modules on the load path.
<rekado_>in most cases I’ll probably not need the full module, however; just a subset.
<paroneayea>rekado_: I imagine that various C-based structures may make that hard, esp from third party libraries?
<paroneayea>I dunno though!
<amz3`>rekado_: that would be nice
<didi>taylan: ping
<rekado_>paroneayea: I only want to serialize Scheme code.
<rekado_>Guile compiles each module to its own ELF file, so maybe the answer is to use smaller modules and install all of them that are needed.
<rekado_>but that’s not quite what I had in mind.
<rekado_>I’m not entirely sure what I want, though.
<reepca>I don't suppose anyone would happen to know what might cause "apply-smob/1" to fail in guile 2.0?
<daviid>reepca: why are you using 2.0? (as in why not 2.2 I mean?)
<reepca>daviid: because it's what the guix bootstrap guile uses.
<rekado_>reepca: do you have more context?
<rekado_>because that’s a really low level error message
<reepca>rekado_: that's the frustrating part, the error message is extremely minimal. http://paste.lisp.org/display/351519
<daviid>reepca: fair enough :) then I was going to ask the same quizz as rekado_, though probably I won't be of any help, maybe others can... if more info ...
<daviid>reepca: can you try a full backtrace mybe
<reepca>I happen to know thanks to good old print-statement debugging that it's triggered by starting the "set-paths" phase of gnu-build-system
<daviid>reepca: and/or running under strace if you can, to try to get more debug info
<reepca>daviid: and that's the second frustrating part, I can't actually interactively do anything with this. In the build environment I can get a guile 2.2 REPL, and from there I can try using system* to run guile-2.0, but starting it with no arguments causes it to start up, print the usual "no warranty" message... and immediately exit
<reepca>the entire situation is really bizarre. I can copy the failing builder into a -c argument, and put a catch around it that will print something when an error is reached, but that just silences all output for some reason.
<reepca>and when I copy+paste the builder into my 2.2 REPL it works just fine
<daviid>reepca: it could be that you need very carefull path and GUILE_* env var seting prio to launch 2.0 from using system* from 2.2, because probably what happens is guile 2.0 will try to load go from 2.2 ... or vice e versa...
<taylan>sneek: later tell didi I can be better accessed through email, via taylanbayirli at google mail
<sneek>Okay.
<yegortimoshenko>how do i run emacs lisp using guile?
<taylan>yegortimoshenko: in the REPL, ",language elisp"
<taylan>yegortimoshenko: and the 'compile' procedure has a keyword argument #:from, IIRC, with which one can set the source language
<random-nick>but you should note that guile doesn't have elisp-the-library, only elisp-the-language
<yegortimoshenko>thanks! i've found the cli option after that you mentioned it
<yegortimoshenko>thanks
<rekado_>reepca: what are the contents of the builder?
<rekado_>reepca: and as daviid suggests: do check the GUILE_LOAD_PATH and GUILE_COMPILED_LOAD_PATH. No mixing of 2.2 paths with 2.0.
<reepca>rekado_: http://paste.lisp.org/display/351521
<yegortimoshenko>random-nick: that's a very subtle distinction. so it just emulates elisp semantics and i can't even use defun?
<random-nick>you can use defun
<random-nick>but not buffers
<yegortimoshenko>oh, definitely
<yegortimoshenko>no buffers
<reepca>side-note, do we have any tools for insta-prettifying automatically generated builders?
<daviid>reepca: i have both installed here as well, let me try to launch 2.0 from 2.2
<daviid>in the paste you have (unsetenv "GUILE_LOAD_COMPILED_PATH")
<daviid>and unset LD_... as well
<daviid>reepca: it works fine here
<daviid>but I'm not using guix, I can launch 2.0 from 2.2 from geiser and I'm using debian buster (for info), so env var are probaly totlly diff from what you get in guix
<daviid>reepca: http://paste.lisp.org/+7J8I
<reepca>it works for me to launch 2.0 from 2.2 as well normally, but for some reason not in the build environment.
<daviid>reepca: can you patch the script guile-2.0 has to ru so it prints env vars?
<daviid>reepca: have to go, bbl, good luck, I would try, from 2.2: (system* "strace -o strace.out guile-2.0 -s <yourguixscript>")
<daviid>ACTION will release Guile-CV version 0.1.5 tonight
<reepca>also, does system* automatically make the executable name the first argument?
<reepca>these are the environment variables the failing builder is run with, according to environ: http://paste.lisp.org/display/351523
<reepca>when I remove GUILE_AUTO_COMPILE=0, the --no-auto-compile argument is completely ignored
<reepca>scratch that question about system*, rereading the manual makes it clear
<yegortimoshenko>does guile (emacs lisp flavor) have an http client/server and if the answer is yes, how to access that?
<ArneBab>yegortimoshenko: you can call regular scheme from emacs lisp — I’ll test it
<yegortimoshenko>ArneBab: thanks!
<ArneBab>yegortimoshenko: I don’t get stuff imported right now — guile-emacs provides a richer set of elisp functionality, so you might need to use that
<ArneBab>yegortimoshenko: so it’s there in theory — if you find the way to call it, please highlight me with it!