***dje is now known as xdje
<Madsy>mark_weaver: Where can I find the latest snapshot? ***siel_ is now known as siel
<mark_weaver>Madsy: interesting. those should have been defined in config.h, which is generated by configure. <mark_weaver>I'm not sure what has changed since your last test that would have caused that to break. <Madsy>Maybe I'll look through config.log tomorrow <Madsy>I still need til get any guile to work again though <Madsy>I wonder what I did to break everything <mark_weaver>civodul is probably the best person to ask about this. My knowledge of the build system is rather weak. <mark_weaver>it's a change that civodul just recently made, to not include config.h in the native programs. <mark_weaver>he did it to fix the problem you had with c-tokenize <mark_weaver>but he also did it for gen-scmconfig while he was at it. I guess that was a mistake. I'll let him know. <Madsy>Getting specifcally 21a7b to work isn't a high priority for me. Getting any version working is though. <mark_weaver>Madsy: thanks very much for bringing this to my attention. <Madsy>I'll try old 2.0.9 stable tomorrow <mark_weaver>Madsy: well, it's helpful for us to produce a better 2.0.10. <Madsy>I wonder if I built libpthread in a specific way before. <Madsy>I know I linked with it statically at least <mark_weaver>I think you had the most functional guile-2-on-mingw that I've heard of. it's a shame if we lost that recipe. <Madsy>Oh well. More options to try tomorrow <Madsy>Going to bed. See you tomorrow :) <zacts>ok, apparently guile-2.0.9 is already included in the base slackware distro. <zacts>so no need to port it to that platform. /me is about to create a FreeBSD vm to test the latest guile-2.0.10 pre-build <nalaginrut>now that they've injected CPU, why bother to hack software ;-/ <mark_weaver>when I read stuff like that, it almost makes me want to stop using computers altogether. <turbofail>we could always go back to wiring together relays <mark_weaver>zacts: what is ARM TI? does this relate to the massive malware attacks? <zacts>Texas Instruments, ARM cpu. Like the cpu included in the beagle bone black. <zacts>I haven't had a chance to read the entire article <zacts>oh, I wonder if TI/alternative CPUs are less vulnerable to malware. <zacts>but maybe I fundamentally misunderstand the article. was it at the CPU level that the malware was injected? <mark_weaver>for an agency as powerful as the NSA, there are so many ways to get into our computers, they are almost beyond counting. <turbofail>the article doesn't seem to mention CPU compromises <mark_weaver>our systems are too complex, and we don't know how to write software on this level of complexity that isn't like swiss cheese. <zacts>also, with quantum supercomputers, and things, I become a bit concerned with weak crypto + the fact that data is saved on the net forever. <mark_weaver>but using proprietary hardware, including CPUs, is also a very serious problem. building our own computers from raw materials, using 100% free designs, is probably a prerequisite to keeping the NSA out, but even that is only part of the problem. <zacts>mark_weaver: don't give up, it's a fight we need to fight until the end. <turbofail>yeah there's still van eyck emissions, acoustic hacks, etc. <mark_weaver>of the areas that I have strong qualifications in, I'm not sure there's anything more important for me to be working on. <zacts>mark_weaver: I need to continue where I left off in my Scheme and the Art of Programming book. <zacts>but I'm also going to be busy with college, does guile participate in GSoC? <mark_weaver>yes, we usually do. we didn't get ourselves together this year, but probably next year, especially if there's interest. <zacts>guile-emacs looks neat, I hope they make more progress. I would be interested in that also. Although, I really like my vim/evil-mode key-bindings. I've almost switched entirely to evil, but I need to patch a few things here and there. <zacts>but, for now. let's get this FreeBSD port finished and tested. =) <zacts>mark_weaver: oh, I'm working on a tech blog. I hope to post more soon. I would paste it here, but this channel is logged, and I don't want DDoS of my server. <zacts>well, I guess heroku has good safeguards.. hm.. <mark_weaver>fwiw, I've posted URLs to my private server several times on channel, and never had any problems. <zacts>I would like to add some more scheme stuff eventually, and tutorials / blogs.. <zacts>but I would like to get community review, before I post tutorials. <zacts>mark_weaver: heh, not yet.. I've been a bit busy. <mark_weaver>no worries, I just wanted to make sure it wasn't because of my unusual browser (without javascript) <zacts>but hopefully within the next few wees, or so. <zacts>mark_weaver: there is currently no javascript on that site. I'm trying to make it standards compliant and accessible to any browser. <zacts>also, I will add more stuff to my gitorious as I work on various projects. <zacts>there is one bug with the navbar, but it's a simple fix. <mark_weaver>on the very few sites I've worked on, I try to make the HTML source look as simple and readable as I can. my references have always been the HTML standards documents themselves. <zacts>indeed, my goal with this is KISS <zacts>I'm eventually going to connect markdown + org-mode somehow. <zacts>with the same kind of theme/style. I'm currently hosting the site on heroku, with perl's mojolicious::lite <zacts>actually, a guile server version of a page would be sweet, eventually. <zacts>anyway, laters.. homework and stuff. I'll let you know within the next day or two how guile builds on FreeBSD. <zacts>thanks, gn. also, I hope to do some ports on guix. I'm kind of getting tired of FreeBSD ports.. I'm also running Gnu/Linux again (slackware). but guix sounds fun! =) <zacts>one last question. but will the guix be a rolling release distro? <mark_weaver>I think Guix is too different from traditional distros to be easily categorized, but essentially yes. <zacts>oh yeah it was nalaginrut who made a guile webserver.. I'll have to have to check it out. <mark_weaver>you never have to reinstall. it's always on the cutting edge, but without the risk, because you can always roll-back.. <zacts>mark_weaver: good, I like to install once, and just continuously upgrade without ever needing to reinstall. <nalaginrut>zacts: if you're talking about Ragnarok, it'll be rewritten in the future, because it's just a regular thread-based server <nalaginrut>zacts: I'll do some job to make it compatible with guile inner server interface <nalaginrut>zacts: If you want to play web with Guile, I suggest you try Artanis <nalaginrut>Although Artanis haven't released an official version, it fine to play. I'm writing some part to make it more serious. It more likes a toy before ;-) ***_zxq9_ is now known as zxq9
*mark_weaver suspects cluck has his client rigged to send that automatically upon joining. <mark_weaver>Madsy: when you built e1bb, you had to remove the "#include <config.h>" from c-tokenize.c, iirc. Did you have any similar problem with gen-scmconfig.c? <mark_weaver>(you wouldn't have been able to fix that one by simply removing the #include, if that helps. <mark_weaver>I know that you had a problem with gen-scmconfig.c in 21a7b, but I'm asking if you ever had problems with gen-scmconfig before that. <Madsy>mark_weaver: Nope. Only c-tokenize.c <Madsy>gen-scmconfig.c probably doesn't include stdlib.h after config.h <Madsy_>mark_weaver: I timed out after answering you. I said that it only happens with c-tokenize.c <cluck>mark_weaver: initially that was the plan, in order to further my laziness, but with a shaky internet uplink the defun grew to ugly proportions in order to handle all sorts of special cases so one day i just said "to heck with it" and now do it manually (been sending it manually for years) <cluck>with that said, one could rig emacs to not just send repetitive messages but hold full blown conversations if one wishes to. if nothing else having erc channel eliza is a one liner <mark_weaver>My emacs modeline tells me whenever someone writes a message in #guile, so I can take a look. Your smileys cause me to look for no good reason. I'm already close to putting you in a filter so that I don't get notified of your messages. <cluck>mark_weaver: that's a bad filter if it considers punctuation as activity. in any case i can stop the manual greeting if that helps ***cluck` is now known as cluck
<mark_weaver>dje42: were you the one who mentioned that in some project, you ran the autoconf tests twice when cross-compiling: once for the build machine and once for the host machine? (or something to that effect?) <mark_weaver>I think we probably need to do something similar in guile. <dje42>gcc's been doing it for awhile, I can't think of a downside. <dje42>[except a marginally slower configure, but that's life] <dje42>Check the gcc sources. I think they create a temp directory, run autoconf for the build system there, and then copy the resultant config.h to where they want it to be. ***jao is now known as Guest97126
<mark_weaver>civodul: was it your intention that libguile-2.0.so.22.7.0-gdb.scm would be installed in $prefix/lib ? <Madsy_>Ah, heh. I was wondering about that file too :D <mark_weaver>Madsy_: I'm trying my own mingw cross-compile of Guile, btw. <Madsy_>Maybe you'll succeed where I have failed <civodul>mark_weaver: that's where gdb looks for it <mark_weaver>Madsy_: apart from the recent breakage with gen-scmconfig, where did you run into problems? <Madsy_>mark_weaver: Apart from guile crashing here for some weird reason, I didn't run into any other build problems but the c-tokenize.c build error <civodul>mark_weaver: that's a good idea: these days i often do unintended things, ahem ;-) <civodul>on my system i have ~/.guix-profile/lib/libstdc++.so.6.0.18-gdb.py, for instance <Madsy_>mark_weaver: I'm fairly sure you have to build and link libgc as a static library. I haven't tested it as a shared library, but according to its manual, it is a bad idea. <Madsy_>In that case you need to pass DGC_NOT_DLL to guile's CFLAGS <tupi>i wonder why match was not define with a syntax à la receive, (match (a b c d) my-list my-code) ? <ijp>it's pretty common to want to perform multiple tests <Madsy_>Whether or not to use w32-pthreads as a shared library, I'm unsure. A shared library there sounds reasonable, to make sure libgc and guile uses the same instance of the library <ijp>that's less common with multiple values <ijp>(you can do it with call-with-values and case-lambda, and even write a nice case-values if you want) <mark_weaver>tupi: you could use 'match-lambda' as the second argument to 'call-with-values'. <mark_weaver>it would be easy to write a macro to make it look nicer, but yeah, it's not very commonly needed. <Madsy_>mark_weaver: When you link against a static library, you need a macro to remove the dllexport specifiers or something. That's what GC_NOT_DLL turns on <mark_weaver>Madsy_: I'm not bothering with w32-pthreads, since we've given up on supporting threads on mingw for 2.0.10 anyway. <Madsy_>mark_weaver: Even when compiling with null threads, guile looks for pthread.h and fails if it doesn't find it <Madsy_>Let me know if you get a different behavior <taylanub>tupi: You can think of `match' as a hyper-`cond'. <Madsy_>mark_weaver: You can probably just download the w32-pthread sources and copy over <mark_weaver>Madsy_: well, I'm afraid that solution will paper over a problem. <mark_weaver>gc.h only includes gc_pthread_redirects.h if GC_PTHREADS is defined. <mark_weaver>it's defined in gc_config_macros.h, which defines it if GC_WIN32_THREADS is not defined. <mark_weaver>I see the libgc was compiled with win32 threads. it chose that automatically without me saying anything about threads. <mark_weaver>gc.h includes gc_pthread_redirects.h which includes pthreads.h <Madsy_>When building libgc, you can specify no threads with --enable-threads=no, I think <Madsy_>Still, that made no difference here when I tested it yesterday <mark_weaver>gc_config_macros.h automatically defines GC_PTHREADS if GC_WIN32_THREADS is not defined (among others). <Madsy_>I'm pretty sure I built libgc with windows threads when it was working <Madsy_>I.e --enable-threads=win32, not using w32-pthreads <mark_weaver>it has to be added to CPPFLAGS actually, or else the snarfing fails (which uses the preprocessor directly) <mark_weaver>Madsy_: I didn't even specify anything about threads when configuring libgc, and it chose win32 threads. <Madsy_>How can snarfing fail just by adding a define? <mark_weaver>snarfing runs the C preprocessor, and when things are defined a certain way it tries to include pthreads.h, which fails. <Madsy_>Right. But you wanted to define GC_WIN32_THREADS to make it not include pthreads.h. So how can defining it in CFLAGS make snarfing fail? <mark_weaver>the problem wasn't that it was defined in CFLAGS. the problem was that is was _not_ defined in CPPFLAGS. <mark_weaver>civodul: what's the best way to override some autoconf checks when cross-compiling? there are lots of checks for libgc features in Guile's configure script, and they all report "no". <civodul>mark_weaver: users can run ./configure ac_cv_foo=yes ac_cv_bar=no <civodul>or are you saying that the configure checks get it wrong? <mark_weaver>*** glibc detected *** /usr/bin/x86_64-w64-mingw32-ld: free(): invalid pointer: 0x00000000010d8cd8 *** <mark_weaver>civodul: thanks! the reason the checks are getting it wrong is because the mingw linker (from debian wheezy) is crashing. <Madsy_>mark_weaver: Woah.. the bad luck keeps coming <civodul>mark_weaver: i guess w32 would be less troublesome <civodul>perhaps you should give up on w64 and try w32 instead? <civodul>(assuming Debian has toolchains for both) <Madsy_>mark_weaver: Oh yeah, I forgot to tell you I only built 32-bit binaries. But I tested the binary on 32-bit and 64-bit Windows <mark_weaver>Madsy_: oh. I thought you said they were 64-bit before. <Madsy_>I *thought* I was using 64-bit MinGW but I wasn't. I got confused over the w64 compiler suffix <mark_weaver>I reported a bunch of things on the mailing list that turned out to be false: I reported that you had made a 64-bit build with thread support. oh well :-( <Madsy_>So to be clear. What I got working is 32-bit guile on 32-bit and 64-bit Windows without threads and sockets <Madsy_>And for guile to not crash during startup, you have to set the search paths as environment variables <Madsy_>Passing them as arguments does not work afaik <mark_weaver>Madsy_: did you use the mingw-w64 package, or mingw32 ? <mark_weaver>and did you use --host=i686-w64-mingw32 or --host=i586-mingw32msvc ? <mark_weaver>well, I'm going to have to pick this up later. gotta go afk for a while... <tupi>i forgot the best way to flaten a list of list into a list?