<marusich>Suppose I have two strings a and b, and I want to know if they are equivalent, where equivalent means they're the same length, and they contain the same characters in the same order. In this situation, do string=? and equal? always behave the same? <marusich>Apart from perhaps revealing the expectation that two variables are strings, I am not sure why I would ever want to use string=? instead of equal? in that case. <galex-713>compiling from git, how do you install headers? <galex-713>I did install libguile.h /usr/local/lib and mkdir /usr/local/lib/libguile and install libguile/* /usr/local/lib/guile but is this enough? should make install do that? <daviid>galex-713: make install does all that <galex-713>daviid: then why didn’t I have libguile.h and its directory in /usr/local/include? <daviid>galex-713: it is installed in $prefix/include/guile/2.x/ <galex-713>yes know i have to find why cpp can’t find it <daviid>when you compile something using guile, you need to pass the flags <daviid>there in pkg-config, try to find an example in the manual <daviid>or a repo that use libguile (I don't) <daviid>galex-713: oh no! you need to checkut stable-2.2, not to use master <daviid>master is indeed for 3.0, but not reommended unless you want to help <galex-713>so I passed all my night compiling for nothing :( <daviid>the tarball compiles a lot faster <daviid>then you'd need to pass these flags to compile: <daviid>here I have '-pthread -I/opt2/include/guile/2.2' <daviid>generally we do that using autoconf ... but that may be to much for you for nao <daviid>yes, but yout project needs to be compiled telling the compiler where to libguile includ an libs ... <daviid>to do that you query using pkg-config guile-2.2 --cflags and pkg-config guile-2.2 --libs <galex-713>ancient libao that evolved in ao then in libfive <daviid>and the answer, you copy on the line to compile yur project ... <galex-713>usually I just see CFLAGS += $(pkg-config direct-dependency --cflags) and LDLIBS += $(pkg-config direct-dependency --libs) <daviid>galex-713: so, you know you need to pass these otherwise the compiler won't find them ... i was trying to answer your first quiz above ... why does cpp does not find libguile.h ... <galex-713>no but I didn’t call cpp myself in fact, cpp was called by gcc called by the make configured by cmake <daviid>ok, let's see how it goes once you have 2.2 installed <galex-713>cmake that wasn’t even able to recognize where was guile 2.2 <daviid>i recommend to unintall the one you installed from the source first <galex-713>really one day configure scripts should be parallelized <galex-713>like they should autoconfigure themselves to check if shell does support parallelism and if so build multiple queues with a dependency system <galex-713>and also configure automake to use make parallelism if enabled <daviid>galex-713: let's keep talking about huile relted thing i don't have time for ther talks (neither am I competent anyway) <daviid>the #autotools have been very nice to me everytime I needed help ... <daviid>to talk to them on #autotools channel :) <galex-713>until then I only were an user with increasing interest in using them to deploy software in the future <daviid>so talk to them (but be nice with them to) <daviid>galex-713: most of us use autoconf/automake to deploy our projects yes <galex-713>and still happens only rarely to do stuff requiring makefiles longer than a screen <galex-713>I guesse there is already some binaries or bytecode already bootstrapped for this? <galex-713>sad it can’t use the system-wide guile already installed to bootstrap, the same way any C compiler usually does <galex-713>that may be quicker, as it wouldn’t have to bootstrap from C ***Raimondii is now known as Raimondi
***fibratio` is now known as fibration
***galex-713_ is now known as galex-713
<jcowan>Is there anything resembling a roadmap for Guile 3.0 yet, other than R7RS, native AOT compilation, and languages other than Scheme and Elisp? <daviid>jcowan: search the guile ML archives for 'Guile 3 update' (about 10 msg totl, so ok ...) <daviid>they are quite long emails though <daviid>jcowan: one of the last one says it will target a JIT instead, due to complication with ... I don't remember exactly the details <rain1>wow R7RS for guile? I like that! <daviid>I don't think that will happen anytime soon, not sure where jcowan got that info <OrangeShark>jcowan: well as the end of the paragraph, they ask for help to implement R7RS <OrangeShark>there is a R7RS branch, but I am not sure how much progress has been made <daviid>jcowan: I don't think it will be in 3.0, I don't thing there is even one guiler working on this <daviid>not that I have anything against it, but not to raise false hopes ... <jcowan>It would be nice to have a working r6/r7rs implementation <jcowan>current versions of sagittarius won't build, and larceny is limited to 32 bits only <dsmith-work>Hmm. I got the impression that R7 support will be spotty at best. <dsmith-work>Something like you can't be both R6 *and* R7 at the same time. <jcowan>There are only a few flat-out incompatibilities, especially with relaxed R6RS support (not necessarily signaling the precise condition that R6RS calls for). <jcowan>bytevector-copy! is one I remember, the order of arguments is incompatible (arguably a bug in R6RS) <jcowan>there are papers by Kato and Clinger on how their implementations were done <jcowan>also when to write out bytevectors with #u8 and when with #vu8 <jcowan>BTW, I found a documentation bug, should I send it to bug-guile or somewhere else? <rlb>FWIW, to demonstrate that locale test issue, you need to make sure your system has the fr_FR.iso88591 locale, i.e. on debian via "dpkg-reconfigure locales" or similar. <rlb>Then "check-guile i18n.test" should do it. <rlb>./check-guile, rather. <daviid>rlb: if you found a bug, I suggest you report it at bug-guile, our maintainers rarely answer here recently (unless it would be an 'immediate' answer, whch does not seem to be the case here...) <rlb>daviid: right - it'll be sent to bug-guile, and should be fixed in debian shortly.