<fangism>the above guile seg-fault on snarf-check-and-output-texi does NOT occur on powerpc-darwin8 (apple-gcc-4.0.1 -O2 -g) <fangism>but, it still does occur with clang-release-3.3 on x86_64-darwin11 (not Apple's) ***mario-go` is now known as mario-goulart
<davexunit>If you scroller down to the implementation of "adder", you'll see that it is implemented using some primitive dispatching method. <davexunit>since I have not encountered Guile code written in this manner ever, I'm wondering how this would be done in a more "modern" style. <davexunit>My inclination would be to use a SRFI-9 record type. <ZombieChicken>Is there a webpage that covers good schemes for Lisp formatting? <davexunit>ZombieChicken: probably, but that's a *the* style guide that I see cited. <ZombieChicken>I see it has a listing of rational. That is always good to see. Thank you for the link <cky>I agree with davexunit that that's pretty much as official as it gets. <davexunit>looks like I let a stray "a" into my sentence back ther.e <ZombieChicken>That makes two of us. It takes me three tries to get a capital letter <systemovich>hi guys, the guile interpreter does not allow me to use the arrow keys. do you also experience this? <systemovich>instead moving the cursor backwards when I press the left arrow, it prints ^[[D. <madsy>systemovich: Happens when you don't build guile with readline support, I believe <cky>madsy: That's not enough. You also have to load the readline module. <madsy>I'm happily ignorant about that and use Geiser ;-) <cky>systemovich: In your ~/.guile file, add these two lines: (use-modules (ice-9 readline)) (activate-readline) <madsy>systemovich: Or you can use Geiser in emacs. Which is 1000% better than the vanilla REPL <systemovich>thanks, guys. I added those lines to ~/.guile. Now arrows work. I will also check out Geiser. <nalaginrut>systemovich: you may try guile-colorized & (ice-9 readline) if you don't want to launch heavy Emacs ;-P <wingo>systemovich: you might want jao; he usually wakes up later, in a few hours *TaylanUB spontaneously becomes curious as to what happened to the unboxed-floats idea ... <ksinkar>what is equivalent of trace from Common Lisp in Guile? <TaylanUB>Maybe ,trace in the REPL, I'm not sure what trace in CL is. <ksinkar>TaylanUB: in CL if you are tracing a procedure, you can see the step by step execution of your procedure in the REPL as the procedure is executed <ksinkar>trace seems to be like a special-form operator like defun, if, or etc <ksinkar>you call it by (trace procedure name) <ksinkar>wingo, TaylanUB: the ,trace is not similar to the CL trace at all <wingo>ksinkar: please see the manual, there are many things there :) <ksinkar>wingo: I am using the info guile reference, if that is what you mean by the manual <systemovich>finally got geiser installed. autoindenting and paren highlighting is indispensable. <wingo>indentation and paren highlighting are part of base emacs, fwiw <wingo>systemovich: you should try paredit, if you haven't already <systemovich>wingo, I tried installing paredit, but there were some compile errors. <TaylanUB>fangism: I'm on OS X 10.7 and just built a freshly pulled stable-2.0, yielding 2.0.9.97-b1fe <TaylanUB>No fancy options at all, just ./autogen.sh && ./configure --prefix="$HOME_USR" && gmake && gmake install <TaylanUB>(The OS X native make, which is some gmake version.) <TaylanUB>I have environment variables PKG_CONFIG_PATH and LD_LIBRARY_PATH set explicitly to pathes I know I want, and CPPFLAGS and LDFLAGS set such that they have -I and -L flags for the relevant pathes too, but none of that should be relevant to the segfaults you mention. ***add^_`` is now known as add^_
<TaylanUB>I'm using boehmgc 7.2d, libffi 3.0.13, libunistring 0.9.3, and gmp 5.0.5, all from MacPorts. Tell me if I forgot any big dependencies that could be relevant. <wingo>TaylanUB: your compiler version is relevant, and which compiler you are using <TaylanUB>I don't have CC or so set so it'd be the OS X 10.7 default one. "cc --version" says "Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)" "Target: x86_64-apple-darwin11.4.2" "Thread model: posix". I'm on some iMac model with a 3.1 GHz i5, I think it's the fore-last iMac version. <TaylanUB>(And model identifier 12.2 when I dig around some more. Should really be irrelevant though I suppose.) <wingo>i suspect we are doing something undefined with the tortoise-and-hare thing <ksinkar>wingo: this is what I am talking about. The documentation says that I should be able to use trace, but in reality I am not able to use it. <wingo>if that is the case you may have found a bug. <wingo>but you would have to be much more specific. <ksinkar>wingo: sure, I would not only like to be specific about my bug, but would want to resolve it as well. I want to get started on guile development, but am not confident of my capabilities. Some mentoring might help. <wingo>i don't have the time to mentor, sorry -- the best i can do is write documentation and fix bugs; my best attempt at that is in the manual. <wingo>if something doesn't behave like the manual says it does, then you have found a bug, either in the code or in the manual. <wingo>you should make sure you are looking at the version of the manual that corresponds to your guile, fwiw <wingo>and that version should be 2.0.9 <ksinkar>wingo: the particular entry that I linked has been removed in the 2.0 docs but exists in the 1.8 docs <wingo>ksinkar: in that case you should be reading the 2.0 docs :) <wingo>there are equivalents there, but things have been moved around <wingo>in general the tracing support is better in 2.0, not worse... <cky>nalaginrut: Is guile-2d a frontend for SDL? Because the name just suggests it's a framebuffer interface. <davexunit>nalaginrut: guile-2d can do it. but you get an entire engine and need an X window open to do it. <davexunit>cky: it's a layer over SDL, OpenGL, FreeImage, and other such libraries. <mark_weaver>there may be other options as well, but that's the one I know of. <davexunit>^ ah yes, forgot about this. that would be more suitable. <davexunit>sound stuff is *really* primitive right now, in guile-2d. haven't given it much love. <mark_weaver>bananagram: well, the other thing is you can always use 'system' to run an external command. <mark_weaver>wingo: what version of gstreamer are the guile binding for? <wingo>there was never a stable release corresponding to 0.10 iirc <wingo>i think i last worked on those bindings in 2005 or so :/ <wingo>and now 1.0 is the new thing, with a new abi, after ~8 years of stable 0.10 <mark_weaver>to my mind, keeping things like these bindings up to date is probably more important for average users than the RTL compiler is. <wingo>imo it's the most important thing i can be working on right now, guile-wise <mark_weaver>yes, especially since you're the only one who'd be likely to get it done. <mark_weaver>we're all volunteers here, and we do what we want, as it should be. <mark_weaver>but that said, based on my conversations with guile users here, it's far more common that people are stuck because of lack of good bindings than because guile 2.0 is not fast enough. <mark_weaver>I hope I can write these things without anyone feeling guilty about what they're doing or not doing, because that's really not intended at all. <nalaginrut>what's the hackers way is "if you want something, go for it" <nalaginrut>like I need a lisp-machine board, then I raised a project around my whole hackerspace to build one, plus the industrial guys <wingo>nalaginrut: did you really? :) <nalaginrut>blame it when you paid for it, the seller won't reject your blaming for the sake of your money <nalaginrut>wingo: we're busy for that project these days, because it's very hard to make it all free, especially WIFI chip <nalaginrut>even there's only confidential datasheet, we can release the detailed info into the driver code, which is the best way to open the info ***FractalF1ve is now known as FractalFive
<mark_weaver>nalaginrut: atheros makes wireless chips that can be used with free software. <mark_weaver>I'm not sure that's the case for all of their chips, but some of them are okay at least. <nalaginrut>mark_weaver: nice taste, but we do pick Atheros AR6003 <nalaginrut>but interesting is we still lack of the opcode datasheet <mark_weaver>nalaginrut: anyway, it might be better to just provide a USB port with the intention of plugging wireless into USB. <mark_weaver>because who knows how often you'll be able to produce new versions of your boards. <nalaginrut>we have to choose a SDIO interface, but it seems ath9l which uses USB <mark_weaver>this way, when your boards are old, you'll still be able to plug in a more recent wireless chip. <mark_weaver>I say this as someone who has tried to keep using some very old hardware. <nalaginrut>mark_weaver: we'll provide USB on extensional board <nalaginrut>but we have to deal with core board at this time <nalaginrut>but if you try it for manufacture, there're less choice and many things are not control by engineers <nalaginrut>anyway, this is the interesting point when you hack industry <mark_weaver>well, if I were doing it, I'd probably put USB on the main board instead of built-in wireless, but it's your project :) <nalaginrut>mark_weaver: yes, I can understand, but there're too much similar design <nalaginrut>we want a very tiny core board, and provide various shields <mark_weaver>okay, but now anyone who wants USB will need to buy a second board. and pretty much everyone wants USB, because it opens up a huge array of cheap possibilities. <nalaginrut>there's only a scheme-VM on a very compacted hardware, so please not imagine it as powerful Linux, maybe the USB driver needs to be done in the next step <nalaginrut>so all the design around the core board has to be selected carefully <mark_weaver>a single USB port would allow people to cheaply add almost anything: wireless, wired, mass storage, sound I/O, serial I/O, etc, etc. <nalaginrut>and we're under the suggestions from hardware engineers ;-) <nalaginrut>well, just buy the extra board, it may contain everything ;-P <nalaginrut>and you could hide it every where if you drop the extra board <mark_weaver>so, basically you intend to create both the hardware and software for a new computer system from scratch? <mark_weaver>well, the CPU and the OS, developed together from scratch. <wingo>sounds like a learning experience :) <nalaginrut>others just think it's interesting to be involved with their good at <nalaginrut>well, unfortunately I can't design CPU, maybe years later, I have to swallow the things I've learned these years <nalaginrut>wingo: well, I'm not going to do every things, I just think about the architecture and find out proper guys for it <nalaginrut>I call it 'hack the industry', about how to create a new computer system from scratch <nalaginrut>nowadays we can try things with nearly zero cost <wingo>dsmith-work: not much, my bootstrap mostly worked but there are some primcalls that i need to fix <wingo>and clean up a bunch of things <wingo>been busy though, hacking on firefox today <davexunit>small rant: I just can't get over the fact that both the standard ruby and python implementations have a global interpreter lock. thank you, guile, for being better than this. <wingo>true, but we do have some nasty races as well... <wingo>we need to do better in that regard <wingo>davexunit: you've never run into them? <wingo>it's easy to hork your system from a --listen repl <davexunit>well yeah, but that's the nature of multi-threaded applications isn't it? <wingo>i wish we had a better story there <wingo>better data types, better concurrency, ... <davexunit>the problem with the --listen repl is when the main thread is running some sort of long operation, in my case an unbounded update/render loop. <davexunit>so, I wrote a cooperative repl server with mark_weaver's help. <ijp>civodul: stis has something like that, but I can't say I've used it <ijp>think pre-post argument checking, but only done at module boundaries ***wingo_ is now known as wingo
<fangism>if you suspect undefined behaviorisms of compiler optimizations, I wonder if ubsan might be able to catch it <fangism>has anyone built guile-2.0.9 with a recent clang on x86_64-!darwin? <ijp>I think people always get the wrong idea about why it fails there <ijp>it's nothing to do with doc generation per se, it's just the first place the build guile is used <fangism>right, the stacktrace in the paste shows where things really go wrong <dsmith-work>heh. Might be good to have make spit out an info message at that point. "If the build fails here, it's probably becuse ..." <wingo>maybe we should run a quick guile -c 1 before going on <ijp>echo "1" > sanity-check.test <anddam>is there a configuration option to set the paths in which libraries are searched? <ijp>or at least, not from within guile <saul>anddam, check out out the man page for 'ld.so'. <ijp>anddam: try setting your LD_LIBRARY_PATH <anddam>I'm having issues with guile in macports, since all libraries are in a prefix that isn't /usr or /usr/local gschem from gEDA-gaf cannot load the library <anddam>I'd rather patch the guile build <ijp>saul: man page? info page! <anddam>IIRC info is the preferred way to access documentation in GNU, is that correct? <saul>anddam, it is not preferred by me. :) <ijp>(info "(libtool) Libltdl interface") ld_dlopen searches a user defined search path (which I suppose guile could expose) followed by LTDL_LIBRARY_PATH and then LD_LIBRARY_PATH <saul>Nonetheless, I believe MacOS uses ELF binaries and uses ld.so . <civodul>i don't think it's called ld.so, is it? <ijp>saul: guile uses libltdl, which says it provides this interface. How the platfrom handles that is none of our concern <ijp>I suppose I should correct what I said earlier, LD_LIBRARY_PATH is only on gnu systems <anddam>no dyld has similare variables as well <mark_weaver>anddam: as ijp said, guile lets libltdl search for the libraries. On most POSIX systems, libltdl consults $LD_LIBARY_PATH and $LTDL_LIBRARY_PATH, but I'm not sure off hand if it does something different on OSX. <mark_weaver>However, recent versions of Guile also manually search in $GUILE_SYSTEM_EXTENSIONS_PATH, if that's set. <mark_weaver>though using that variable would be kind of a hack, and it's not documented. <mark_weaver>anddam: a quick perusal in the libltdl sources suggest that on Darwin, the $DYLD_LIBRARY_PATH variable is consulted. that's probably your best bet. <mark_weaver>anddam: the other thing you can do is to provide an absolute pathname, in which case it won't search at all. <anddam>DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH were the "similar varibles" I was referring to <anddam>I don't know libltdl, would a variable set at guile's build time be then hardcoded or are you suggesting to set the DYLD_* at runtime of the program that is being linked to libguile? <mark_weaver>I don't see "DYLD_FALLBACK_LIBRARY_PATH" anywhere in the libtool-2.4.2 sources, but maybe a newer version has it, dunno. <mark_weaver>when using the Guile Dynamic FFI, the DYLD_LIBRARY_PATH should be consulted at runtime. <mark_weaver>specifically, it's consulted when 'dynamic-link' is called. <mark_weaver>well, another option is to pass an absolute pathname to 'dynamic-link'. <ijp>can you not setenv it from within your .guile (or rather the global equivalent whose name I forget) <anddam>the point is that in the whole geda-gaf source (that is providing gschem that is having the linking issue) I cannot even find a "dynamic-link" instance <anddam>that along with my blatantly ignorance about Scheme doesn't make this easy <ijp>are you sure geda is using the system foreign stuff? <mark_weaver>anddam: maybe it's being linked from C. maybe search for scm_dynamic_link? <anddam>searched both dynamic-link and dynamic_link <anddam>actually I just grepped the source tree, I assume that would be in plain text, is that right? <mark_weaver>or perhaps it's calling lt_dlopen (from libltdl) directly. <anddam>due to the three calls I guess the "culprit" is line sys_lib_dlsearch_path_spec='/usr/local/lib /lib /usr/lib' in configure script, it's in darwin section <mark_weaver>ah, okay, so that's guile itself looking for one of its libraries. <mark_weaver>guile hardcodes the pathname where its extensions should be found directly in its own executable. <mark_weaver>also: what --prefix are you passing to its configure script? and where are the dynamic libraries actually ending up? <anddam>prefix is /opt/local, libraries are in /opt/local/lib <mark_weaver>well, none of us here use guile 1.8 anymore. it's no longer maintained. guile 2.0.x has been out for over 2.5 years. I'm not surprised that 1.8 doesn't support modern OSX well. <mark_weaver>granted, I don't know for sure if geda supports 2.0.x yet or not. <mark_weaver>do you have your guile-1.8.8 build directory around? <anddam>just wiped it while building 2.0.9 but I can build again in a couple minutes <mark_weaver>anddam: I looked at the guile-1.8.8 code, and it doesn't appear to do anything but call libltdl. it makes no attempt to make sure that the guile install location is in the paths that libltdl look at. <mark_weaver>so basically, with guile 1.8.8, you're at the mercy of libltdl's default behavior. <mark_weaver>the relevant bit is in libtool/libltdl/configure. search for DYLD_LIBRARY_PATH <mark_weaver>basically, the default system path is: /usr/local/lib /lib /usr/lib <mark_weaver>well, I guess what I'm wondering is: are you just looking for a way to install a working geda on your OSX box, or are you working on an OSX installer for geda, or something like that? <mark_weaver>(I ask because it will affect the advice I give you) <anddam>mark_weaver: yes, I just noticed the darwin* stanza in libtool configure, it's reading shlibpath_var=DYLD_LIBRARY_PATH <anddam>I'm willing to fix the gEDA port in macports <mark_weaver>okay. do macports install pretty much all libraries in /opt/local/lib ? <anddam>yes, in fact it has a policy of using only libraries provided by macports itself <mark_weaver>because an expedient solution that comes to mind is to change the macports recipe for libtool, that patches that part of the configure script, to change that line to: sys_lib_dlsearch_path_spec='/opt/local/lib /usr/local/lib /lib /usr/lib' <anddam>I'm rebuilding after patching it in the portfile <anddam>I did that in guile as well but it didn't affected the behavior <anddam>then you told me guile was doing what libtool was doing so I jumped on that <mark_weaver>okay, sounds good. fwiw, I'd leave "/usr/local/lib /lib /usr/lib" there too, just in case someone is depending on that too. <anddam>actually I was trying to have the configure script catch it from the env variable <mark_weaver>it might be that there's a better way than patching 'configure', but I'm not an autoconf expert. <mark_weaver>but the fact that it's not even the top-level configure script might make it trickier. <mark_weaver>(the one in libltdl is probably the relevant one here) <anddam>rebuilding guile on the new libtool, just in case <photon>anddam: glad you found help here. :) <mark_weaver>anddam: btw, looking more closely at the code, this line in libltdl/configure is the important one: #define LT_DLSEARCH_PATH "$sys_dlsearch_path" <mark_weaver>anddam: can you search for LT_DLSEARCH_PATH in libltdl/confdefs.h ? <anddam>and I suppose confdefs.h is generated by configure <mark_weaver>there might be a way to do this by passing an argument to configure, which would be a more future-proof solution. <anddam>mark_weaver: I wish that was in configure --help <mark_weaver>well, I'll have to look at this later. but at least you have a solution that works for now :) <mark_weaver>sorry, I have to afk for a while. but it would only be there after libltdl/configure runs, which might not be until after the toplevel make runs (not sure off hand) <mark_weaver>oh, hmm, I don't see it either in my built libtool dir.