***silmakuoppanen is now known as w3schoolsfan
<paroneayea>ACTION wonders why Sussman is "Panasonic (formerly Matsushita) Professor of Electrical Engineering" ***karswell` is now known as karswell
***karswell` is now known as karswell
<peterbrett_work>mark_weaver: Unfortunately I ran out of time to try that patch last night, sorry <b4283>i was just looking at the srfi-41 implementation of guile <b4283>why doesn't it use a standard cons cell instead of a 2-slot record named `stream-pare' ? <b4283>is it because that guile will try to reveal the structure of the entire list, once it's evaluated ? <davexunit>b4283: because a stream pair is not a cons cell. <b4283>davexunit: doesn't a cons cell fit in the purpose of stream pairs ? <davexunit>if a stream pair was a regular cons cell, how would you answer the question "is X a stream pair?" <b4283>i can't, they are just cons with a car of delayed expression <davexunit>does my question make it clear why there is a special data type for a stream pair? <davexunit>it's important to be able to identify a stream pair. <davexunit>if it were just a cons cell then you couldn't do that. <davexunit>and you also couldn't do things like give stream pairs a special printed representation. <b4283>does the question also imply that otherwise a cons cell and a stream pair would've been the same? <b4283>i noticed that the module used (srfi-9 gnu) to give a special printing <davexunit>b4283: they would be the same with respect to 'pair?' <davexunit>they would both be pairs, but these pairs are different! <mark_weaver>of course, a stream library could, in theory, use cons cells, but that was simply not an option for a SRFI-41 implementation because of the specification of SRFI-41's 'stream-pair?' predicate. <b4283>i also noticed that the library used a peculiar style of designing by contract <b4283>which included a series of macros consisting of `must-xxx' and et cetera <b4283>very cool actually, never thought a procedure could be written in this manner <stis>tantalum_: did you get any further in compiling guile-syntax-parse? <tantalum_>no. i think you wrote the install procedure is similar to guile-log. that would mean autoreconf etc. autoreconf fails though, even after --add-missing <tantalum_>it looks as it does not need much compiling with configure/make because it is mostly scheme. but would be nice if the intended install process would work. <stis>huh even after --add-missing. for guile-syntax-parse <stis>I spend time getting the order right in the compilation script <stis>I think that is failing for you when oyu just load the code <stis>therefore it would be better to compile <tantalum_>i did autoreconf, then got some error about missing files, then automake --add-missing, then autoreconf again and configure.ac:10: error: required file 'build-aux/ltmain.sh' not found <stis>tantalum_: check this out! <tantalum_>alright, that worked. (some deprecated "Unescaped left brace in regex" but a good exit status anyway) <tantalum_>./configure now wrote configure: error: Guile 2.2 required, but 2.1.1 found <stis>yeah, this with guile 2.1 is a bit tricky, let me check my guile installation. <stis>do you have /usr/local/lib/pkgconfig/guile-2.2.pc or similar? <stis>ok can you mail me that one? <stis>tantalum_: time for dinner, I'll come back later! <stis>tantalum_: in configure.ac try remove this line? and autoreconf again > PKG_CHECK_MODULES(GUILE, [guile-2.0 >= 2.0.0]) <stis>it checks for guile-2.0 and it has been present in all system i know of <tantalum_>can not find the exact line in configure.ac or other files in guile-syntax-parse <stis>ah guile-syntax-parse this is for guile-log. <tantalum_>for guile-log now i made the line commented and reran autoreconf (and autoreconf --force on other tries) but interestingly get configure: error: Guile 2.2 required, but 2.1.1 found. definitely less explanatory message at the end of configure output. <stis>I remember doing some nasty thing to fix this, im searching ***dje is now known as xdje
<stis>I read the script for the testfunction in configure.ac <stis>guile is supposed to be version 2.2 but reports 2.1 <stis>yes but then you should have a guile-2.1.pc <stis>It looks like the scripts used for validation needs to be fixed. Let me try that. <stis>The script used is in aclocal.ac I just mailed you a version to try out, please report back if it successes <stis>report if it fails as well <tantalum_>looks like it ran successful now after i changed a "minor-version" part in acincluded that was giving an wrong type error for +. (display (+ 1 (string->number (minor-version)))) <tantalum_>unify.c:3724:23: fatal error: guile-2.2.c: No such file or directory <tantalum_>Makefile:676: recipe for target 'unify.x' failed <stis>it's my c code make autotools that are weak <stis>go to logic/guile-log/src <stis>extlibdir is probably wrong <stis>tantalum_: You are still on head, you needed a file that I did not check in. You can pull now from the repo. But better to use a tag where this file is not needed I think <stis>ok I'm offline for half an hour tty <tantalum_>looks like extlibdir actually is wrong. changed the 2.0->2.2 in makefile., but got new uni* errors <civodul>davexunit: for some value of beautiful ;-) <davexunit>civodul: where beautiful means "this is the first time that a machine readable GLSL spec has been available" :) <davexunit>ACTION plans to write a sexp->GLSL compiler for Sly <peterbrett>mark_weaver: What should I be trying to apply the w64-support patch against? <stis>tantalum_: fatal error: guile-2.2.c is reporting that this file is missing. I added it to HEAD so if you are on head try pulling <stis>If other errors remain please report <stis>this file should not be needed if you are on a tag are you? <tantalum_>i got a little further with the newest version and previously discussed fixes, it was creating .go files, then it ended with ice-9/boot-9.scm:781:26: In procedure #f: ice-9/boot-9.scm:781:26: no code for module (compat racket misc) <tantalum_>Makefile:1362: recipe for target 'logic/guile-log/guile-log-pre.go' failed <stis>Did you make install in guile-syntax-parse? <peterbrett>mark_weaver: Thanks. Was a bit confused because it didn't apply cleanly against 2.0.11, but I'll grab the latest stable-2.0 branch from git and have another crack at it. <tantalum_>no make install in guile-syntax-parse, the state there is currently "no rule to make target install". the no code for module error came from guile-log <stis>yes, it tries to reach a file that should be installed when you do sudo make install in the guile-syntax-parse directory <tantalum_>ic. currently making progress on guile-syntax-parse (removed guile version checks from configure.ac). it creates .go files <daviid>davexunit: guile-json git repo [savannah non gnu] has no autogen.sh and no configure [pre ready script], so one can not configure ... for info: not sure if th guile-json author is here [?], but i see in the log you commited some so ... <mthl>daviid: `autoreconf -vfi` ? <daviid>mthl: I know, I mentionned so davexunit may correct this little inconvenience ... <davexunit>in fact, I wrote an entirely new JSON implementation for Guile core. <davexunit>that will be incorporated someday when I stop being lazy and fix the issues with it. <mthl>daviid: sorry I didn't read log. <daviid>oh! where is that version? is it good enough to be used [I'm trying guile-words actually ....] <daviid>davexunit: ok, I'll look at it, thanks <davexunit>daviid: no, because I haven't put my guile fork up there yet. <davexunit>the original patch is on the guile-devel mailing list archives <davexunit>it's not a separate library. it's intended to be shipped with guile itself. <daviid>right, I was willing to checkout the source 'as is' till inclusion, np. <daviid>how far are we from having a guile official json module then ? <davexunit>daviid: not very far. it likely will not end up in the next guile release, though. <daviid>davexunit: I'm using git [stable and master], I'd be happy if we had it there, let me know when it goes in ... <daviid>I'm a bit confused about where should I get the (gnutls) module? <daviid>davexunit: gnutls is installed here [debian] maybe missing a package? <daviid>any debian guile gnutls aware here? <davexunit>daviid: yeah, debian probably separates the guile bindings into another package <jyc>I've been trying to find out a way to disable the 'note: source file ... is newer than compiled file' banner <mthl>jyc: You have to do ‘make clean-go’ before compiling if you them to disappear <mthl>jyc: oops wrong channel (I thought it's was #guix) <jyc>mthl: oh, I see. cool, thanks for the info! <civodul>ACTION thinks we should question auto-compilation <paroneayea>davexunit: I'd really like ice-9 json to get merged into guile proper <paroneayea>is I felt I learned that we really, really ought to do sxml style association-ish lists rather than proper alists for the parameters <paroneayea>since it looks like (@ ("foo" "bar" "1" "2" "3")) <paroneayea>and when you have enough nested json things, like you do in the stuff I was working with <davexunit>alists have the distinct advantage of having a number of procedures that already work with them. <davexunit>in SXML you never have an attribute whose value is a list <davexunit>so you never see the thing you are talking about <daviid>civodul: why did you not create a separate git repo just for guile-gnutls? here is what I had to do: install debian package, which installs guile, copy the files, and purge everythig again since I don't want the 'debian' guile ... it would be so much better to git clone guile-gnutls, imo :) <davexunit>daviid: because it's better to maintain the gnutls guile bindings directly with the C library. <daviid>davexunit: then how do i clone the all thing but just install guile-gnutls? <daviid>see what I had to do, quite annoying really <davexunit>you just needed to install the Debian package! <daviid>davexunit: and it installs pack i don't want <davexunit>guile-gnutls needs the gnutls shared library to work at all, and it needs the *correct version* of gnutls.so. if they are maintained and built together, then it's assured that you get a compatible gnutls.so and guile modules. <daviid>as any other lib binding, it depends on a lib version >= or even =, it still should be a separate git repo imo <daviid>davexunit: in this case you won't dave sorry: it makes absolutely no sence not to have a separate guile-gnutls git repo and tarball. I had to loose much time and perform an error prone, I will never be sure I have the right version ... it's all wrong to me, sorry <davexunit>if you understand why Linux maintains the kernel *and* the modules in one place, then you will understand why a project might maintain a C library and bindings to that library in one place. <daviid>davexunit: I've jsut shown why it does not work, unless I would use debian the all way down .. and then, we should do that for all lib, guile-gnome, clutter, absolutely all bindings ... which is impossible of course, so why just gnutls? non sense sorry <davexunit>you haven't shown why it doesn't work. you've shown that you don't use packages provided by Debian. <daviid>davexunit: so, I can't install gnutls if I don't use debian [or another distro...]? so all guilers who, like me, use guile source are unable to safely instll guile-gnutls, is that your demonstration ? <civodul>daviid: what Debian or other distros do should not really influence this kind of choice, IMO <civodul>the idea was simply to provide Guile bindings along with that library, which was then part of GNU <civodul>i also find it convenient to have both in one, as a user <daviid>civodul: it's unfortunate, I still did get it right yet, terrible. I will, but it would be so much better precisly _not_ to have them together. I guess we relly have a diffierente oinion on how to structure things here. I guess I have to clone the all gnutls lib, despite it is already on my mcahine ... too bad, imo it really is too bad, but hey, we dont' need to agree on everythig <civodul>if you're using a distro you can install it from there <civodul>i guess i don't understand the problem <daviid>civodul: as I said, then it imposes guile-2.0 [the distro package] and I don't want that ... <daviid>civodul: so the only solution I have, because I use guile from source, is to clone gnutls, 80MB, compile install ... for a couple of Kb of scheme code, think about it... by the way gnutls git repo does not have autogen.sh either'for info <civodul>i understand this specific problem, but i'm not sure whether it generalizes well :-) <daviid>civodul: it is as if we imposed on our [rare] users to use a complete specific gnome stack to be able to use guile-gnome ... while we just check if the lib we depend on is there and in an adequate version. I sincerely don't understand how we come to desagree here :) <daviid>then the git repo gives me anerror now <daviid>onfig.status: error: cannot find input file: `src/libopts/Makefile.in' <daviid>civodul: I'll try using the tarball then 2h and I still can't use gnutls, which is installled on my system ... think about it <daviid>civodul: for info, the latest stable url from the gnutls download page fails: he site at “ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4” seems to be unavailable. The precise error was: URL cannot be shown <daviid>that's strange, doesn't work here I tried several times, inclunding now again <daviid>I'll try a specific branch from the git repo instead <civodul>it's certainly easier to build from a tarball than from Git <daviid>I can't get a tarball. the configure step still fails for branch gnutls_3_4_x: config.status: error: cannot find input file: `src/libopts/Makefile.in' <mark_weaver>daviid: what error message is given by: wget ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.8.tar.xz ?