IRC channel logs


back to list of logs

<galex-713>Anyone tried libao? the guile openscad-like cad stuff?
<avoine>it was mention here
<avoine>can't remember by who
<dsmith-work>{appropriate time} Greetings, Guilers
<daviid>dring dring
<daviid>wingo: I did this tiny change in repl-print (using truncated-print) and it does the job perfectly. I really really think this should be the default, because users may always reprint the obj using write in their repl, wdyt?
<daviid>meanwhile I could set the <repl> 'print option, but i need to grab the repl instance value that is running, might be blinf but I could not find the proc/var holding this info, anyone knows?
<daviid>* blind
<daviid>just grabbed the latest master,, but I still have this geiser/guile problem
<janneke>do %load-path, %load-compiled-path make any sense?
<daviid>janneke: are you talking to me? I dont think so, it works fine on my laptop and not on another machine, on both, I jst ,use (cv) and incrementatly develop ...
<daviid>janneke: on the machine it fails, it fails with /tmp/test.scm with this def: (define (plus a b) (+ a b)), then C-x C-e -> (compile (define (plus a b) (+ a b)) #:from _ #:to _ #:env _ #:opts _) ... (compute-translation-order scheme objcode #<struct:55afd82a4eb0 pwpw 55afd8338200 pr…>)
<daviid>In unknown file:
<daviid> 0 (scm-error misc-error #f "~A ~S" ("no such language" objcode) #f)
<janneke>daviid: hmm, if your paths are okay...weird
<daviid>anyone has an idea about what could cause this bug?
<daviid>janneke: you don't need a path to C-x C-e an s-epx in a /tmp file do you?
<daviid>geiser compiles the s-epr 'in the guile-user' env If I understood correctly
<janneke>daviid: i'm always fighting with geiser to get it find the correct load paths; great if it works for you
<daviid>janneke: I really don't undertand your statment, but I wish I did!
<daviid>janneke: (cv) modules are in %global-site-dir, so I don't need to do anything. but as I said, editing a file out of any %load-path and C-x C-e works, if all the s-epr needs is defined, no?
<janneke>daviid: sorry, i really don't know
<daviid>janneke: yes it works, as exected, touch /tmp/test.scm, fill it with this, (define (plus a b) (+ a b)) and try
<janneke>it looked to me as if guile cannot find some language, so i think: the load path is wrong, or the .go files are missing, or the .go files are wrong
<janneke>sorry if i'm not helping ;-)
<daviid>janneke: I apreciate you are trying to help, thanks!
<daviid>janneke: but on this machin where geiser is lost, note that I first ,use (cv) in the repl, which obviouly load .go files ...
<OrangeShark>daviid: ah, objcode is only in guile 2.0, it was removed in 2.2
<daviid>OrangeShark: I use 2.1.4 on both machines
<OrangeShark>it still somehow referring to 2.0 stuff
<daviid>you mean geiser is then? (I have both version installed on tboth machines
<daviid>ACTION is totally lost :)
<OrangeShark>objcode is one of the intermediate representations guile uses in 2.0 which was replaced with something else
<daviid>OrangeShark: ok, so how come guile-2.1.4 is trying to do something using 2.0 ? )on 1 machine and not on the other)
<daviid>here si the lado path on the macine that fails: %load-path
<daviid>$3 = ("/usr/share/emacs/24.5/site-lisp/elpa/geiser-0.8.1/scheme/guile/" "/opt2/share/guile/2.2" "/opt2/share/guile/site/2.2" "/opt2/share/guile/site" "/opt2/share/guile")
<OrangeShark>daviid: guile follows the specs to compile scheme code and somehow on that one machine it is using the specs from 2.0
<daviid>ok, how could this possible happen if I did this: git pull, git clean -dxf, ./; ./configure --prefix=/opt2, make -j 8; make install
<daviid>the only env var I have wrt guile is this: GUILE_WARN_DEPRECATED=detailed
<OrangeShark>find the module (language bytecode spec)
<OrangeShark>2.0 version has a compiler to objcode
<OrangeShark>while 2.2 version has a compiler to value
<daviid>OrangeShark: given my config, I still fail to explain why it tries to compile to objcoe, since geiser calls guile's compile function, load path are set to /opt2, which has no guile 2.0 anything ... so what could cause guike 2.2 to try something from 2.0? is geiser passing an arg that has to do with this
<OrangeShark>daviid: looking at geiser, it does seem to reference objcode or bytecode depending on guile version
<daviid>OrangeShark: ok, so I have to find out why it thinks it runs guile-2.0 then, wierd wierd
<daviid>M-x run-guile effectively runs 2.1.4-xxx so ... what a mess :)
<OrangeShark>what version of geiser do you have?
<daviid>the latest from git
<daviid>0.8.1 says %load-path
<OrangeShark>oh, guile-2.2 support was added in 0.9
<daviid>OrangeShark: this latest geiser on both machines by the way
<daviid>but I did git pull , and the complete danse ...
<OrangeShark>check the geiser file scheme/guile/geiser/evaluation.scm
<OrangeShark>there should be a cond-expand that mentions 2.2
<daviid>OrangeShark: many thanks! I found that geiser has been installed on that lab machine (and not on my laptop), will remove debian packages, probably that is the teriible problem :)
<OrangeShark>ah okay :)
<daviid>OrangeShark: tahnks a ton, I did not think about that possibility, and did not know the number (geiser .9 for guile 2.2 ...0 hence I would have spent days before to find out the source of the problem ... tnaks man!
<OrangeShark>no problem daviid
<wingo>civodul: wdyt about joining manual chapters on "simple data structures" and "compound data structures" into just "data structures"?
<civodul>wingo: the advantage of this sectioning is that it "structures" things a bit, makes them less intimidating maybe
<civodul>but no strong opinions
<wingo>i just feel weird with describing strings, bytevectors, etc as being simple somehow
<wingo>character sets :P
<civodul>yeah it's more arbitrary than it seems :-)
<wingo>ok, if no strong opinions then i join them and attempt to sort the sections from simple to complex
<wingo>which is mostly just concatenating api-data.texi and api-compound.texi
<wingo>civodul: does that sound fine?
<paroneayea>wingo: fwiw I support this action
<paroneayea>I don't find the breakdown particularly useful
<wingo>tx for feedback, it is appreciated
<paroneayea>isn't lambda technically a datastructure ;)
<paroneayea>ACTION goes on church-encoding rampage
<civodul>wingo: fine with me!
<wingo>lambda is not a data structure :)
<wingo>it is an abstraction that can have many concrete representations
<paroneayea>I guess you did publish a blogpost to that effect!
<wingo>indeed :)
<dsmith-work>lambda is the ultimate!