IRC channel logs


back to list of logs

***ijp`` is now known as ijp
<mjiig>is there anyway to surpress the copyright and warranty information guile prints when launched in interactive mode?
<mark_weaver>not really. of course, you could make your own REPL.
<mark_weaver>out of curiosity, why do you want to suppress it?
<mjiig>i've set up vim with a command to pipe to guile in interactive mode when i ask it to
<mjiig>which is useful for when i'm just trying things, so just want everything to print it's value when it runs etc.
<mjiig>and the copyright information adds a lot of visual noise to the screen everytime i run the command
<mark_weaver>even if you suppressed the copyright/warranty info, you'd still get the prompts.
<mark_weaver>Using "guile -c <command>" might be better for that use case.
<mark_weaver>well, you'd also have to wrap the command in (display ...) to print the value.
<mjiig>for whatever reason, the prompts don't appear to be showing in the output
<mjiig>but even if they were, i wouldn't mind them anywhere near as much
<mjiig>and guile -c is for single commands, rather than a few chained commands, is it not?
<mark_weaver>you can pass multiple commands to -c
<mjiig>hmm, i'll take a look
<mjiig>though the point of this exercise is largely me trying to avoid having to wrap display around things
<mark_weaver>well, there might be a (relatively small) one-time cost to get a nice Guile interaction system for vim. Once that's done, you don't have to think about it anymore. We already have a very nice system for interaction with Emacs.
<mark_weaver>for example, you could write a little guile script that works exactly how you like (by piping commands to it) if you prefer.
<mark_weaver>and I doubt it would be more than a few lines.
<mark_weaver>I'm willing to help you write it, if you tell me exactly how you'd like it to work.
<mjiig>ideally it would take in a file (either stdin or a file named on the cmd line would be fine), and execute it, printing the result of each top level expression when it was evaluated
<mjiig>essentially the REPL, without the extra output
<mark_weaver>I'll cook something up
<mark_weaver>give me a few minutes please
<mark_weaver>mjiig: it could have been a lot simpler, but I wanted to use the compiler (as the REPL does), and to print multiple values and error nicely.
<mjiig>mark_weaver: thanks very much, that's perfect i think
<mark_weaver>glad to help :)
<davexunit>that's a nice little snippet there, mark_weaver
<mark_weaver>Thanks. I'm working on an improved version now.
<davexunit>I did a little playing around with the REPL server tonight, trying to get the compiled thunks to run in the main thread.
<davexunit>all I've managed to do is crash it thus far.
<mark_weaver>damn, that little snippet doesn't handle top-level definitions properly. oops. and now mjiig has already left :-(
<mark_weaver>hmm, how to handle multiple-valued expressions properly...
<mark_weaver>okay, I posted a much improved version that actually works this time :)
<mark_weaver>handling multiple values is definitely more of a pain than it should be.
<mark_weaver>this version is also careful not to pollute the 'guile-user' module, nor to be broken by redefining things like 'receive', 'lambda', etc.
<mark_weaver>unfortunately, this code will probably not work in Guile 2.2 either :-(
<mark_weaver>hmm. maybe I'll post about this.
<nalaginrut>morning guilers~
<nalaginrut>yeah~seems times bug on hurd is solved, all the tests of Guile2 passed~
<nalaginrut>it's the first step for guile-on-hurd
<mark_weaver>nalaginrut: that's good news!
<mark_weaver>nalaginrut: where's the patch that fixes the problem?
<nalaginrut>mark_weaver: I just got the news from <braunr>, but he just give me a repo and a test result
<nalaginrut>I haven't seen the patch yet
<mark_weaver>do you know if the fix was to guile or to the hurd?
<nalaginrut>I think it's only about eglibc of hurd
<nalaginrut>but braunr has some concern about hardcoded TIME_UNITS_PER_SECOND
<nalaginrut>in guile
<nalaginrut>in spite of TIME_UNITS_PER_SECOND, I think everything is OK for guile2, nothing worried
<haole>in my Debian box, calling (dynamic-link "/usr/local/lib/graphviz/guile/") works on guile 1.8 but not on guile 2.0 (file not found)
<haole>any ideas why?
<nalaginrut>haole: it seems work for me
<haole>nalaginrut: I just downloaded guile's sources (I think they are guile 2.1), compiled a vanilla version and tried the same thing: same error
<haole>might have something to do with Debian's libltdl, I don't know
<nalaginrut>well, I only have debian/Hurd for testing, maybe there's difference
<haole>I'll debug with gdb and try to pinpoint what is going wrong
<haole>I'm recompiling guile with the debugging flags, but the GUILEC steps are really slow
<mark_weaver>haole: I think you're not supposed to include ".so" in the argument to dynamic-link.
<mark_weaver>(as I recall, that's what libltdl wants, and not under our control)
<mark_weaver>I'm not sure off hand why it would work with guile 1.8 though.
<mark_weaver>haole: as for the slow compiling: it's only that slow near the beginning of the compile. the problem is, the compiler itself has not yet been compiled, so it has to compile itself using a very slow interpreter that's only used during bootstrap.
<haole>mark_weaver: thanks... the slow compile time is not an issue for me
<haole>lt_dlopenext fails to find the functions... guile mentions something about SYSTEM_EXTENSIONS_PATH... is this an envvar?
<mark_weaver>but if you're passing an absolute filename, that should be irrelevant.
<haole>omitting .so doesn't help
<mark_weaver>what is the name of the file that actually exists?
<haole>adding /usr/local/lib/graphviz/guile to SYSTEM_EXTENSIONS_PATH doesn't help also
<mark_weaver>have you tried running it with strace and seeing what it's trying to open/stat?
<haole>no, never done that... just strace guile?
<mark_weaver>strace -o trace.out <command>
<haole>ok... wait a minute
<mark_weaver>grep in trace.out for libgv_guile
<haole>open("/usr/local/lib/graphviz/guile/", O_RDONLY|O_CLOEXEC) = 13
<mark_weaver>it must be failing for some other reason, even though it has found the file.
<mark_weaver>i.e. lt_dlopenext must be returning an error.
<mark_weaver>the relevant function in Guile is sysdep_dynl_link in libguile/dynl.c
<haole>there is something strange... it seems to be looking for some libs (like libcrypt) in a directory in my home folder that I use to make some installs from times to time
<haole>but LD_LIBRARY/RUN_PATH are empty
<haole>yeah, I was reading just this function... lt_dlopenext returns a null handle
<mark_weaver>I suspect that there are some additional library dependencies, needed by, that it's failing to find.
<mark_weaver>we did make a change in how things were handled recently.
<haole>hmm I hope I can help solving a bug :)
<haole>(if this is a bug and not my fault)
<mark_weaver>previously, Guile would actually set some environment variables (maybe LD_LIBRARY_PATH ?) to include the directories where guile expects to find its libraries.
<mark_weaver>it was pointed out that this was a very bad idea, because it affects subprocesses launched by guile.
<haole>I'll be right back... I'll reboot in a clean environment (my $HOME/.profile was weird)
<mark_weaver>so now, we no longer set any environment variables relating to shared libraries. instead, we manually search for dynamic libraries in the Guile-specific directories, if lt_dlopenext fails.
<mark_weaver>I don't know off-hand if this env-var setting behavior went as far back as Guile 1.8 or not.
<haole>I'm back
<haole>looks like my fake installation directory (in my $HOME) was compiled inside guile for some reason
<haole>does this look strange to you? trace.out:
<haole>I'll have to recompile to check and this will take a long while
<haole>but seems to me that having a LD_LIBRARY/RUN_PATH set during the compilation and installation of guile could break this
<mark_weaver>that's happening before Guile code is even run.
<mark_weaver>it might have been part of an rpath that got compiled into Guile..
<mark_weaver>I'm fuzzy on the details, but yes, there are environment variables and linker flags that can cause that kind of behavior.
<haole>let me do this with debian's package
<mark_weaver>RUN_PATH in particular sounds likely to be the cause of that.
<mark_weaver>yes, indeed, if LD_RUN_PATH was set when you linked Guile, that would cause that behavior.
<haole>Debian's guile won't look for my fakeinstall dir but won't work either
<haole>do you use Debian?
<mark_weaver>yes, I'm running wheezy
<mark_weaver>search for LD_RUN_PATH in for more on that.
<haole>me too... here is the version installed here: 2.0.9+1-1
<haole>for guile-2.0
<mark_weaver>so, in the strace, I would look for other libraries that it tries to find after the successful open("/usr/local/lib/graphviz/guile/" ...
<mark_weaver>my guess is that some library that depends on is not being found.
<mark_weaver>here's a recent change that's relevant to this:;a=commitdiff;h=fc32c44995dacb2c3f2fb9d1eafec59c44787c32;hp=c04c11846127d481afc56a1d4e7f657460cd4f21
<haole>but guile-1.8 works
<haole>also, the only open calls that are failing are:
<haole>nothing else :(
<haole>yeah, I saw this diff in the code
<haole>it gets through to the next if, where it notifies the user that it failed
<mark_weaver>I'm going to look at the Guile 1.8 sources to see how things worked back then.
<haole>I'll download a tarball of guile 1.8 and debug in this same region
<haole>this doesn't seem guile's fault, because lt_dlopenext fails, but how come that guile 1.8.8 succeeds? though guy! :)
<mark_weaver>yeah, I don't know. I think the next step is to use a version of libltdl compiled with debugging symbols, and step through it to find out why it's returning NULL.
<haole>debian doesn't seem to provide this... I think I'll have to recompile the package and install a custom version
<haole>please, don't break my system :D
<mark_weaver>I recommend that you install your custom-built libltdl into a different prefix, not used by anything else.. and then set LD_LIBRARY_PATH while running Guile cause it to link to the custom version.
<haole>good call
<mark_weaver>make sure it's the same version of libltdl that debian uses though..
<haole>do you know what is this package? libguile-ltdl-1
<mark_weaver>btw, no need to "make clean" in the entire Guile build directory in cases like this. just "make clean" in the "libguile" directory only.
<mark_weaver>you'll save yourself loads of compilation time that way.
<mark_weaver>in general, you can find the package associated with a file in debian using "dpkg -S". In this case, "dpkg -S /usr/lib/x86_64-linux-gnu/" tells me "libltdl7"
<mark_weaver>and the corresponding source package is "libtool".
<mark_weaver>in wheezy, it's libtool 2.4.2
<mark_weaver>btw, do you have the "libltdl-dev" package installed?
<mark_weaver>I would also do "apt-get build-dep libtool" before building libtool from source.
<haole>yeah, done that already! it's compiling with DEB_BUILD_OPTIONS="nostrip noopt" fakeroot apt-get -b source libltdl7
<haole>(it redirects to libtool)
<haole>I'm installing guile-1.8 at the same time
<mark_weaver>sounds good
<mark_weaver>if you didn't have guile-1.8 installed, how do you know it works?
<haole>I mean the version with debug symbols and with the source files so I can debug it :)
<mark_weaver>ah, okay :)
<haole>what was the name of the function in dynl.c?
<haole> sysdep_dynl_link
<haole>the handle is not null!!
<haole>how come?
<haole>same path, same libltdl
<haole>I mean: lt_dlopenext returns a valid handle
<haole>does libtool require some kind of initialization?
<mark_weaver>yes, 'lt_dlinit' must be called.. and it it's called by sysdep_dynl_init in dynl.c
<haole>hmm... well, next step: see why it fails with a proper debugging environment
<haole>and then go to sleep :)
<mark_weaver>so does (dynamic-link ...) work properly when linked with the debug version of libltdl?
<haole>not done compiling yet
<haole>all the tests were done with the current debian package
<haole>dynamic-link only work properly with guile 1.8
<haole>in guile 1.8, lt_dlopenext return a valid handle for the same path
<haole>sorry if I wasn't clear
<mark_weaver>so when you say "the handle is not null", you mean when lt_dlopenext is called by guile-1.8, right?
<mark_weaver>and it _is_ null when called by guile-2.0.9, right?
<haole>same environment for both, except guile
<haole>minor correction: I've tested with guile-2.0.9 and
<haole>same result
<mark_weaver>note that libltdl allows programs to configure a "user-defined search path", by calling the functions 'lt_dlsetsearchpath', 'lt_dladdsearchdir' or 'lt_dlinsertsearchdir'.
<mark_weaver>but I searched for "lt_dl" in the guile-1.8.8 upstream sources, and didn't find any calls to those functions.
<mark_weaver>the other places it searches are based on the LTDL_LIBRARY_PATH and LD_LIBRARY_PATH env vars.
<haole>oh, libtool's compilation failed... damn
<mark_weaver>I don't suppose any of those variables are getting set within guile-1.8?
<haole>no idea... they are not set in my system
<mark_weaver>maybe try running guile-1.8 and evaluating (getenv "LTDL_LIBRARY_PATH") and (getenv "LD_LIBRARY_PATH")
<haole>and /usr/local/lib/graphviz/guile is not very "standard" :)
<haole>both guile 1.8 and 2.x return false for both getenv calls
<mark_weaver>oh, I have an idea.
<mark_weaver>what is the content of libgv_guile ?
<mark_weaver>based on the name, it sounds like it's a library that accesses Guile's API.
<haole>yeah, it's a wrapper for Graphviz
<haole>I noticed that sysdep_dynl_init are very different between those versions
<mark_weaver>well, Guile 2.0 is not ABI-compatible with Guile 1.8. you'll have to rebuild that library against the Guile 2.0 headers.
<haole>hmmm that must be it! how do I do that? just recompile with guile 2.0 installed?
<mark_weaver>almost certainly, the problem is that the library is trying to link with Guile 1.8 symbols that aren't present in Guile 2.0.
<mark_weaver>so the link fails and lt_dlopenext fails.
<mark_weaver>I'm not familiar with that library, so I don't know anything about its build system.
<mark_weaver>but somehow, you have to ensure that it's #include'ing the headers from Guile 2.0 and linking against the libguile 2.0 library.
<haole>ok... I'm rebuilding it now, gonna check the logs
<haole>the library uses autotools as well
<mark_weaver>I would abort any attempts to build a debugging libltdl.. this is almost certainly the problem.
<nalaginrut>well, I suspect it could be compiled with libguile2, since the interface was changed much
<mark_weaver>nalaginrut: I don't understand that sentence.
<mark_weaver>if you're saying that the library might need to be ported to libguile2: yes, that's a possibility.
<nalaginrut>I mean recompile Graphviz binding with guile2
<nalaginrut>yes, that's what I mean
<mark_weaver>well, let's cross that bridge when we come to it.
<haole>ldd on
<haole>I don't see libguile there
<mark_weaver>I don't know the details of what 'ldd' shows and doesn't show in this case. if it's a Guile binding, it almost certainly needs symbols from libguile.
<haole>would 'nm' help?
<mark_weaver>the internal data representation has changed as well. there's no way a Guile binding built using Guile 1.8 headers will work on Guile 2.0.
<mark_weaver>just trust me that the library needs to be rebuilt.
<haole>also, by checking the build log of graphviz, it doesn't seem to be linking with guile in any moment
<haole>I trust you, I just compiled it again and the error is still there
<haole>however, I don't know if it is linked with guile and, if it is, if I managed to link with the newest guile
<haole>it links with lots of 'scm_*' symbols
<haole>are those guile's?
<mark_weaver>one easy way to make sure it's not using the guile 1.8 headers is to remove 'guile-1.8-dev'
<mark_weaver>yes, those are guile's.
<haole>I did have guile-1.8-dev installed
<haole>gonna retry without those
<mark_weaver>also make sure that guile-2.0-dev is installed, of course.
<haole>in fact I'm relying on my custom install in /usr/local
<mark_weaver>both guile-1.8-dev and guile-2.0-dev include the same file: /usr/bin/guile-config
<mark_weaver>I wonder how they can both be installed at the same time.
<mark_weaver>guile-config is usually what build systems use to find the guile headers and libraries.
<haole>no... still no good, but I might be messing something up
<haole>gonna check some stuff
<mark_weaver>after removing 'guile-1.8-dev', did you rerun the ./configure in graphviz?
<mark_weaver>do you have a /usr/local install of guile-1.8?
<haole>and I don't see any -lguile in the build logs
<mark_weaver>libraries that are meant to be loaded as guile extensions don't need to be linked against -lguile
<mark_weaver>libguile will always be loaded before the extension is loaded.
<mark_weaver>it would be nice if we could get libltdl to give an error message about which symbol it's trying to link that's not there.
<haole>hmm I just confirmed that graphviz was using the wrong headers
<haole>let me try to compile it again
<haole>that would be awesome! instant case closure :)
<mark_weaver>if guile-1.8-dev was removed, how could it have been using the wrong headers?
<haole>hmm you are right... it's just that I've extracted the tarball again for graphviz, rerun the configure and now it complained about not finding guile's headers
<mark_weaver>ah, okay. maybe some stale autoconf cache or something.
<mark_weaver>or some .o files that weren't cleaned.
<haole>the regex to get the version out of guile --version in graphviz is broken
<haole>I guess it doesn't support guile-2.0 anyway
<haole>I've hardcoded the correct version... last shot, or else it's guile-1.8 for me
<mark_weaver>well, try fixing the regexp. maybe it'll work.
<haole>2 AM here... no time to do regexes lol
<haole>not a time*
<mark_weaver>but using guile-1.8 is not a long-term solution. since a few years now, we haven't been updating it or supporting it.
<mark_weaver>I could look into graphviz. are you building from upstream sources, or from a debian package?
<haole>yeah, but graphviz also needs a serious version bump in debian
<haole>upstream: 2.32
<haole>debian is 2.26 I think
<mark_weaver>okay, I'll give it a try.
<mark_weaver>please do check in here again, so I can let you know how it goes, and maybe give you patches to get graphviz working with 2.0.9.
<haole>great news! thanks, mark
<mark_weaver>wow, the graphviz site won't even let me download the tarball without agreeing to a license agreement. how obnoxious.
<haole>heh but graphviz is really useful
<haole>I'm beginning to mess up with guile to see if it's VM fits my company's needs
<haole>we are in the set-top boxes field
<haole>and some systems use a very legacy proprietary vm to be able to change applications during runtime
<haole>I was thinking about using Lua, Mono or Guile VM
<haole>Mono seems too heavy, Lua seems to fit and I don't know yet about Guile
<haole>but it would rock to have a lisp there :)
<haole>set-top high level applications are usually really verbose and repetitive in the code
<haole>lisp macros would be a great feature
<mark_weaver>well, I've got a lot of legalese to read before I can even get the code. *grump*
<haole>maybe the graphviz devs hate this too, but have to do it for some reason
<haole>license stuff is usually like this
<mark_weaver>well, normally with free software, you need to agree to a license only if you *distribute* the software.
<haole>please tell me what this license is about after you read it
<haole>I'm curious :)
<mark_weaver>heh :)
<mark_weaver>the FSF claims that the eclipse public license is a free software license, which means that others must be able to redistribute the code without forcing users to agree to any agreement.
<mark_weaver>so maybe there's somewhere else I can get the code.
<mark_weaver>ah good.
<mark_weaver>a web search managed to get me a download URL on the graphviz site that bypassed the click-through agreement.
<haole>ha! graphviz won't compile while guile 2.0
<haole>heh nice one
<mark_weaver>now I have the source
<haole>it has errors like this:
<haole>initializing argument 5 of 'scm_unused_struct* scm_c_define_gsubr(const char*, int, int, int, scm_t_subr)
<haole>looks like ABI breakage
<haole>ops, I mean, API
<mark_weaver>nah, that function hasn't changed. it's probably something very minor.
<haole>error: invalid conversion from 'swig_guile_proc {aka scm_unused_struct* (*)()}' to 'scm_t_subr {aka void*}
<mark_weaver>yeah, that's a trivial type-checking issue.
<mark_weaver>it might be as simple as removing something like a -Werror compile flag.
<mark_weaver>converting an arbitrary function pointer to a void* should be possible. there's probably some strict compiler flag that's turning that into an error.
<mark_weaver>running configure now in graphviz.
<haole>there are lots of errors... maybe it's easy to port, don't know
<haole>ok... I'll back in 5
<mark_weaver>interesting, the ./configure output for graphviz includes: "checking for guile2... no". so it seems to actually be looking for guile 2.
<mark_weaver>anyway, despite that message, it seemed to find guile in a later test. building now.
<mark_weaver>all of the errors I got are of the same nature. that function pointer that it doesn't want to implicitly cast to a void*.
<mark_weaver>haole: well, a workaround for now is to simply add "-fpermissive" to CXXFLAGS in tclpkg/gv/Makefile
<mark_weaver>that allows it to compile
<mark_weaver>presumably, that could have been passed to ./configure
<mark_weaver>and fwiw, I'm able to successfully (dynamic-link "/home/mhw/build/graphviz-2.32.0/tclpkg/gv/.libs/") in guile 2.0.9
<mark_weaver>I see no reason why it shouldn't work.
<haole>I'm using my custom guile and I get some errors like:
<haole>gv_guile.cpp:2028:27: error: 'scm_must_free' was not declared in this scope
<haole>that won't be helped by the -fpermissive flag
<haole>I'll try with debian's guile-2.0
<mark_weaver>haole: that might be because you're trying to use guile-2.1
<mark_weaver>that code uses several APIs that are deprecated in 2.0, and probably removed in 2.1
<mark_weaver>hi wingo!
<haole>mark_weaver: thanks for your great support and patience
<haole>last question: do you think guile is ready for embedded devices?
<haole>usually this means reasonable memory and space footprints and nice performance
<haole>I'll do my own tests this week, btw
<mark_weaver>it depends what you're doing with it, and how small "embedded" is. but I'd think that a set-top box is not too tiny.
<mark_weaver>how much RAM will this box have?
<wingo>that situation will get better with 2.2 as more code and data is mapped in directly, and debugging things become strippable
<haole>usually 512 MB, with 100MB already being used
<haole>our embedded usually have lots of RAM, but are "pretty embedded" on everything else heh
<haole>poor CPU and FLASH space
<haole>usually MIPS
<mark_weaver>that should be plenty, but again, it depends on how much heavy lifting you expect guile to do.
<mark_weaver>it's like asking "will a C program fit in 100 MB of RAM" ? it depends on the program :)
<haole>I know, it's more like common sense... I don't expect Ruby to do well there, for example
<haole>having other people doing it usually help, too
<haole>don't know if guile is usually used in embedded devices
<haole>might be... having a bytecode VM is really nice in this regard
<mark_weaver>but on my x86-64 system, guile usually uses around 60 megs or so.
<wingo>i think minimum use is much less
<mark_weaver>well, that's when compiling things. if you don't need to use the compiler, then much less.
<mark_weaver>guile 2 compiles ahead-of-time to bytecode. so once you've got everything compiled, then you need only the VM.
<haole>mark_weaver: you are the man! solved
<haole>your idea of pointing out the symbol that failed to load is good, though
<haole>might save someone's time in the future
<haole>I might try to do it if I get some time this week
<mark_weaver>so I just ran my program that computes 1000 digits of pi, and it uses 42 megs.
<mark_weaver>haole: excellent, glad to help! good luck choosing a VM :)
<wingo>haole: guile memory usage ^
<wingo>that's measuring a guile -c '(sleep 100)'
<wingo>on x86-64
<wingo>so that's the minimum memory usage
<haole>wingo: how do I read that? lol
<wingo>that's in kilobytes
<haole>that's pretty low
<wingo> total 1056 0 1804 3012
<wingo>those are four numbers, they add up
<haole>well, 5Kb of RAM is nothing
<wingo>shared clean, shared dirty, private clean, private dirty
<haole>oh, right
<haole>even though
<haole>does guile have some options to ease concurrency implementation?
<wingo>that script is
<nalaginrut> ;-/
<wingo>guile has a low-level pthread interface, some high-level things, but no coherent story...
<wingo>nalaginrut: i just rewrote it in scheme for a project but need to fix something :)
<nalaginrut>how much minumum mem for python?
<haole>have you guys ever heard of termite, for gambit-c?
<haole>I'm willing to play with it for a while, now
<wingo>nalaginrut: total 956 0 1844 3540
<wingo>that's python3.3 -c 'import time; time.sleep(100)'
<nalaginrut>haole: there's a termite port, under working
<mark_weaver>haole: someone just recently started working on a port of termite to guile, but at this point I think it's very preliminary.
<nalaginrut>when it is based on pthread, I've lost my interest...
<haole>nice! exciting times for lisp programmers
<haole>well, gotta go... thanks for the help
<haole>see you, guys
<nalaginrut>wingo: I guess guile-master is faster than python, no?
<wingo>nalaginrut: no idea :)
<nalaginrut>alas~it's no good, since I boasted that everywhere ;-P
<mark_weaver>okay, happy hacking haole!
<nalaginrut>haole: bye
<wingo>nalaginrut: you can test it easily enough :)
<nalaginrut>maybe write the code for benchmarksgame is better?
<wingo>maybe, but make sure it's good code :)
<nalaginrut>well, if I really do that, I'll definitely send the code to Guile community for review...
<nalaginrut>what's interesting is regexdna test of C used tcl...
<nalaginrut>well, seems benchmarksgame doesn't accept new languages, the only way is to download their benchmark-framework&site then test&pub it on my own
<nalaginrut>sneek: later tell mark_weaver here is the patch to fix times-bug-on-hurd, which makes Guile2 pass time test, but this fix is only affect eglibc:
<sneek>Got it.
<nalaginrut>wingo: and <braunr> from Hurd talked to me his concern about hardcoded TIME_UNITS_PER_SECOND, but there's no problem yet, just the potential portable issue, anyway, it's just a message not a request or blame ;-)
<wingo>the TIME_UNITS_PER_SECOND is a guile thing, not meant to reflect the system
<nalaginrut>well ;-)
<wingo>i haven't followed this discussion though :)
<nalaginrut>you don't have to spend time on it, it's solved ,and the bug is unrelated to Guile
***janneke1 is now known as janneke
<civodul>Hello Guilers!
<wingo>heya civodul :)
*wingo finishing up compiler things for review
<wingo>a rebased branch with some cleanups
<wingo>not pushed yet
<nalaginrut_>wingo: out of topic, what keyboard are you using ;-)
<wingo>currently a thinkpad usb keyboard, but i want to get one of those kinesis keyboards :)
<wingo>on my list
<wingo>i've seen those but they are very small, it seems to me
<nalaginrut_>my little finger is tired for Emacs, I found HHKB's ctrl is in CapsLK place, seems a good one
<wingo>i want one of
<wingo>nalaginrut: you can swap that already
<wingo>i have them swapped
<wingo>in gnome you can choose to do that from some menu
<wingo>otherwise whatever your DE is i think there is an option
<nalaginrut_>yes, it's a way
<nalaginrut_>well, red stem
<nalaginrut_>wingo: you swapped to which? CapsLK?
<wingo>i swapped control and caps lock, yes
<nalaginrut_>so it's a very reasonable design, I'll consider HHKB
<lloda>I used a hack that changes the Enter key to right Ctrl on chords. Together with Caps, that gives symmetric Ctrl keys. It's not totally transparent though, so I stopped using it. It was called keydouble.
<davexunit>I've been using a mechanical keyboard with cherry mx brown keyswitches.
<nalaginrut_>I have a cherry black stem
<davexunit>people talk about the "emacs pinky" problem, but I don't get that pain since I have ctrl/caps lock switched.
<davexunit>I do however, get pinky pain in my right hand from hitting the enter key a lot
<nalaginrut_>look! that design is reasonable (echo)
<davexunit>perhaps I need a wrist wrest or something?
<nalaginrut_>anyway, the layout is not the case
<nalaginrut_>I like a small keyboar
<davexunit>I'm interested in small keyboards like the happy hacker, choc mini, and kbc poker
<davexunit>but I can't find any reasonably priced ones
<wleslie>I want a kinesis, although I would probably remap half of the keys under the thumb
<wleslie>thumbs are very useful
<civodul>never tried this kind of keyboards
<davexunit>I would try the kinesis if I ever get some horrible rsi
<nalaginrut_>yes, HHKB is too expensive, the common keyboard is 0.6$ for us
<davexunit>I'll probably just get a regular tenkeyless mechanical
<davexunit>unless I can find a reasonably priced mini keyboard (66/61 keys) with mx brown switches
<nalaginrut_>but when I saw kinesis wingo said, HHKB seems not so expensive...
<wingo>hehe, indeed
<wingo>i heard of a friend that got one used for $50
<wingo>but that was in san francisco, they must grow on trees there
<davexunit>yeah the kinesis is worth it if you need it to save your wrists
<nalaginrut_>I need a no-label-keyboard, then I could try other layout easier
<wleslie>hhkb looks pretty cool
<nalaginrut_>yeah, except price
<wingo>i think jao had one at one point
<add^_>Is that the kinesis thingies?
<add^_>Or something else?
<wleslie>happy hacking
<wleslie>it's not fancy and curved, it's pretty minimal
<add^_>Ah ok
<lloda>there are two versions of the hhkb. I have tried both. The cheaper one has average or poor key feel. The expensive one has glorious key feel, but it's really really expensive.
<lloda>the layout of the kinesis looks great, pity that's so big. I wish somebody made compact keyboards with that layout. In two pieces if possible.
<wleslie>they have fancy curved left/right handed dvorak keyboards, getting two of those would make for ammusement
<nalaginrut_>lloda: wow
<nalaginrut_>when my wife saw what HHKB looks like, the order was canceled, so forget about it...
<wingo>nalaginrut: ;-))
<wleslie>if I had money to burn, I'd get one each of these:
<wleslie>the extra redundancy could maybe improve typing speed
<nalaginrut_>well, it's for wearable computer ;-P
<wleslie>so it has to look good?
<nalaginrut_>I saw the show in a lab, the typing speed is cool, beyond my expectation
<nalaginrut_>but it worth $30,000 at that time, maybe much cheaper now
<nalaginrut_>anyway, users need to be trained
<nalaginrut_>alright, if we have single-hand-keyboard, maybe break Emacs, we could put hand on mouse
<nalaginrut_>any scm->tex project?
<shanecelis>davexunit: Kudos! You've been putting in the time for guile-2d.
<mark_weaver>hello guilers!
<nalaginrut_>mark_weaver: heya
<sneek>Welcome back mark_weaver, you have 1 message.
<sneek>mark_weaver, nalaginrut says: here is the patch to fix times-bug-on-hurd, which makes Guile2 pass time test, but this fix is only affect eglibc:
*mark_weaver looks
<wingo>heya mark_weaver
<shanecelis>That reminds me. I found a bug in guile-readline.
<mark_weaver>hi wingo! I finally read that kennedy paper! (well, I skipped the bits about ANF and Monadic languages, since I didn't need to be convinced)
<wingo>how did you like it?
<mark_weaver>well, it wasn't until the end when I really learned something. I like the contification algorithms :)
<davexunit>shanecelis: thanks man!
<wingo>yep, and now you see the problem with ours :)
<davexunit>shanecelis: how is emacsy going?
<mark_weaver>I understand now the bug you mentioned (about contifying a function out of the scope of the common continuation)
<shanecelis>davexunit: Good. I finally got down to fixing some early mistakes yesterday. Felt good.
<mark_weaver>and also see how we'll need good SCC.. though I still have yet to read and understand the contifier code in wip-cps-bis.
<mark_weaver>that's my next task in this thread.. (I also have some stable-2.0 threads active atm)
<wingo>i have cps rebased locally, and i reworked how function entries work a bit, to give a label to the function entry and to bind self and tail in that continuation
<wingo>that took a while to adapt :P
<mark_weaver>sounds good! I have nothing brewing on that branch now, so this is a good time to rebase :)
<mark_weaver>I decided that I need to read the code more carefully, rather than making guesses about how to fix prompts, heh.
<mark_weaver>I guess I need to see if I can make my SCC code look nicer. Unfortunately, it was made more gross by the limitations of our stack size.
<wingo>that is an unfortunate limitation
<mark_weaver>speaking of which: what's the difficulty with segmenting the stack?
<mark_weaver>it seems to me that it could be done by introducing a special frame with special code that does something like a dynamic wind, where every time in passes in our out, the code manually moves the stack pointer to the next or previous segment.
<davexunit>shanecelis: that's good to hear. glad development is going well.
<mark_weaver>s/in passes in our out/control passes in or out/
<mark_weaver>but admittedly, my knowledge of how the control features work is too weak to say for sure if something like this would be workable.
<mark_weaver>(since we're re-working how a lot of things work, now seems like a good time to consider this)
<shanecelis>davexunit: How's guile-2d going?
<stis>evening guilers!
<mark_weaver>hi stis!
<davexunit>shanecelis: going pretty well. got my first contributor and bug tickets this week.
<davexunit>well, last week.
<shanecelis>davexunit: Nice!
<mark_weaver>davexunit: that's great news!
<davexunit>people are having trouble with guile-sdl on OS X which is preventing them from using guile-2d. trying to resolve it.
<davexunit>but I feel that I need to sit down at someone's OS X machine and work through it.
<davexunit>right now it's just been back and forth with the users having problems and ttn.
<mark_weaver>what are the symptoms of the problem?
<shanecelis>That's one of the toughest things with maintaining software, I find. Bugs that I can't analyze locally.
<davexunit>mark_weaver: guile-sdl was assuming that SDL header files were in /usr/include was the first major problem.
<dsmith-work>shanecelis: Ya, that's near impossible sometimes.
<davexunit>developers using OS X typically use soemthing called Homebrew as a package manager, and it installs software into /usr/local/Cellar
<mark_weaver>what problem are you stuck at now?
<mark_weaver>The new qemu-1.6.0 apparently now supports MacOS X (PPC) guests.
<davexunit>mark_weaver: here's the issue
<davexunit>there was an issue finding libguile.h, too
<davexunit>not sure what's going on there.
<davexunit>stepping out for lunch, bbl.
<mark_weaver>so it's mostly portability problems in guile-sdl, looks like...
<mark_weaver>okay, ttyl!
***skaby is now known as anderson
***anderson is now known as Guest11316
***Guest11316 is now known as goto
<wingo>mark_weaver: wip-cps-for-merge
<wingo>$kclause is what $kentry was
<wingo>$kentry now contains $kclauses
<wingo>i incorporated your patches but should have somehow listed joint authorship, not sure how to do that
<mark_weaver>no worries; my changes were all fairly small anyway.
<mark_weaver>wingo: looks like you failed to incorporate;a=commitdiff;h=4003e6668b3cf48980414ba3a9075f1e573b4aee
<mark_weaver>or was that fix incorrect?
<wingo>i think i incorporated it?
<mark_weaver>well,;a=commitdiff;h=22960d3b6d15f5ce12f6b9bf810ba531bba1bc02 introduces the errors that I fixed.
<wingo>ah, it seems i squished the patches the wrong way
<wingo>the next patch fixes that error
<wingo>will fix before posting to the list
<mark_weaver>ah, okay.
<mark_weaver>thanks for working on this!
<mark_weaver>(you keep saying that you're going to put this hack down for a while, but apparently it's a bit addictive :)
<mark_weaver>not that I'm complaining :)
<mark_weaver>wingo: btw, there's a problem with the computation of 'factor' in:;a=blob;f=libguile/stime.c;h=78539d9cd9f5c84d18b274528fc1230f24425469;hb=stable-2.0#l230
<mark_weaver>on the Hurd, where 'ticks_per_second' is 1000000 and TIME_UNITS_PER_SECOND is 1000, factor becomes 0.
***sneek_ is now known as sneek
***fangism1 is now known as fangism
<davexunit>anyone here attending the gnu 30th event at MIT?
<ijp>not unless there happens to be a worm hole from scotland to massachusetts on the day :)
<shanecelis>I am unfortunately doing a Maker Fair; otherwise I would totally go.
***ijp is now known as gnu-ijp
***gnu-ijp is now known as ijp
<davexunit>shanecelis: awwww shucks.
<davexunit>would be cool to meet some guilers irl