IRC channel logs

2014-03-13.log

back to list of logs

***dje is now known as xdje
<Madsy>mark_weaver: Where can I find the latest snapshot?
***siel_ is now known as siel
<Madsy>mark_weaver: When you have the time, 2.0.9.239-21a7b gives me this: https://gist.github.com/Madsy/9519947
<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>to*
<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>Madsy: oh, I think I know what changed.
<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 :)
<mark_weaver>good night!
<mark_weaver>2
<nalaginrut>morning guilers~
<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>nice to know that ;-)
<mark_weaver>nice!
<mark_weaver> https://firstlook.org/theintercept/article/2014/03/12/nsa-plans-infect-millions-computers-malware/
<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
<zacts>there is ARM TI
<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
<mark_weaver>any particular reason you mentioned ARM TI now?
<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.
<mark_weaver>surely it would help to use less C.
<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.
<mark_weaver>oh, I'm not giving up.
<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>I want to help when I can..
<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>cool
<mark_weaver>last year there was emacsy and guile-emacs, iirc.
<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. =)
<mark_weaver>that would be very helpful!
<mark_weaver>it would be especially good to try the latest tarball http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest and see if there are any problems with it on freebsd.
<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..
<zacts> http://zacts-blog.herokuapp.com/
<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..
<mark_weaver>are there any articles yet?
<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.
<mark_weaver>that's good!
<zacts>also, I will add more stuff to my gitorious as I work on various projects.
<mark_weaver>I like your site's admirably concise HTML code :)
<zRecursive>join #suckless
<zacts>mark_weaver: ah thanks!
<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.
<mark_weaver>(and CSS)
<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.
<mark_weaver> http://stallman.org/civillibertiesminute is static, but generated by a guile program I wrote for RMS, using SXML.
<mark_weaver>(it mirrors an MP3 podcast)
<mark_weaver>okay, good night!
<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.
<mark_weaver>yeah, that's how guix works.
<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
<cluck>:)
<Madsy>Always-smiling cluck
*mark_weaver suspects cluck has his client rigged to send that automatically upon joining.
<Madsy>Heh, yeah
<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>s/built/cross-built/
<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>That's the cause
<mark_weaver>thanks!
<Madsy_>mark_weaver: I timed out after answering you. I said that it only happens with c-tokenize.c
<mark_weaver>I got your replies, thanks!
<mark_weaver>much appreciated
<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)
<mark_weaver>ah, okay :)
<cluck>still beats writing Hello
<cluck>=)
<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>no thanks :)
<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.
<mark_weaver>(no hard feelings about that, btw, just saying :)
<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?)
<dje42>yeah. that's what gcc does.
<mark_weaver>I think we probably need to do something similar in guile.
<dje42>Sounds like it alright.
<dje42>gcc's been doing it for awhile, I can't think of a downside.
<mark_weaver>roughly how is that done?
<dje42>[except a marginally slower configure, but that's life]
<mark_weaver>(pointers to docs are fine)
<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.
<mark_weaver>okay, thanks!
***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 ?
<mark_weaver>ldconfig warns about it
<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_>Ah, great
<civodul>mark_weaver: yes, that's intended
<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?
<mark_weaver>civodul: okay, just checking :)
<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 ;-)
<mark_weaver>:)
<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.
<mark_weaver>civodul: ah yes, so do I.
<Madsy_>In that case you need to pass DGC_NOT_DLL to guile's CFLAGS
<Madsy_>Err.. -DGC_NOT_DLL
<mark_weaver>Madsy_: interesting. I wonder why that's needed.
<tupi>i wonder why match was not define with a syntax à la receive, (match (a b c d) my-list my-code) ?
<tupi>s/define/defined
<tupi>just curious really
<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
<mark_weaver>if so, that's a bug that should be fixed.
<mark_weaver>I'll try without.
<mark_weaver>ah, indeed, I hit it.
<tupi>ijp: mark_weaver, tx
<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.
<Madsy_>It probably does
<mark_weaver>gc.h only includes gc_pthread_redirects.h if GC_PTHREADS is defined.
<tupi>taylanub: yes indeed
<mark_weaver>it's defined in gc_config_macros.h, which defines it if GC_WIN32_THREADS is not defined.
<Madsy_>So gc.h includes pthreads.h?
<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
<mark_weaver>I think I need to use CFLAGS=-DGC_WIN32_THREADS
<mark_weaver>will try now.
<Madsy_>When compiling guile?
<mark_weaver>yes, but that's just a guess.
<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>I think that wouldn't work.
<mark_weaver>gc_config_macros.h automatically defines GC_PTHREADS if GC_WIN32_THREADS is not defined (among others).
<Madsy_>aha
<Madsy_>So it's either or
<Madsy_>No threading isn't defined then
<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_>Right
<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.
<Madsy_>aha
<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".
<mark_weaver>oh, it's because 'ld' is crashing. ugh.
<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)
<mark_weaver>yeah, they do.
<mark_weaver>okay, I'll try
<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
<Madsy_>I mean the prefix
<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_>My bad. Sorry about that
<mark_weaver>no worries
<Madsy_>I make mistakes too :/
<mark_weaver>we all do :-/
<Madsy_>So to be clear. What I got working is 32-bit guile on 32-bit and 64-bit Windows without threads and sockets
<mark_weaver>okay
<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>makes sense
<mark_weaver>Madsy_: did you use the mingw-w64 package, or mingw32 ?
<Madsy_>i686-w64-mingw32-gcc
<mark_weaver>and did you use --host=i686-w64-mingw32 or --host=i586-mingw32msvc ?
<mark_weaver>okay, thanks.
<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?
<ijp>concatenate
<tupi>tx