***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. <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? <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>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>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 <davexunit>that's a nice little snippet there, mark_weaver <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 :-( <nalaginrut>yeah~seems times bug on hurd is solved, all the tests of Guile2 passed~ <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>but braunr has some concern about hardcoded TIME_UNITS_PER_SECOND <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/libgv_guile.so") works on guile 1.8 but not on guile 2.0 (file not found) <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>adding /usr/local/lib/graphviz/guile to SYSTEM_EXTENSIONS_PATH doesn't help also <haole>/usr/local/lib/graphviz/guile/libgv_guile.so <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? <haole>open("/usr/local/lib/graphviz/guile/libgv_guile.so", O_RDONLY|O_CLOEXEC) = 13 <mark_weaver>it must be failing for some other reason, even though it has found the file. <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 libgv_guile.so, 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>looks like my fake installation directory (in my $HOME) was compiled inside guile for some reason <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>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>me too... here is the version installed here: 2.0.9+1-1 <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/libgv_guile.so" ... <mark_weaver>my guess is that some library that libgv_guile.so depends on is not being found. <haole>also, the only open calls that are failing are: <haole>/usr/share/locale/pt/LC_MESSAGES/libc.mo <haole>/usr/share/locale/en/LC_MESSAGES/libc.mo <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. <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/libltdl.so.7.3.0" tells me "libltdl7" <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>I'm installing guile-1.8 at the same time <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 :) <haole>what was the name of the function in dynl.c? <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 <mark_weaver>so does (dynamic-link ...) work properly when linked with the debug version of libltdl? <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 <mark_weaver>so when you say "the handle is not null", you mean when lt_dlopenext is called by guile-1.8, right? <haole>same environment for both, except guile <haole>minor correction: I've tested with guile-2.0.9 and 2.1.0.172-c9693 <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>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>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>if you're saying that the library might need to be ported to libguile2: yes, that's a possibility. <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 libgv_guile.so' 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. <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 <mark_weaver>one easy way to make sure it's not using the guile 1.8 headers is to remove 'guile-1.8-dev' <haole>I did have guile-1.8-dev installed <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 <mark_weaver>after removing 'guile-1.8-dev', did you rerun the ./configure in graphviz? <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. <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 <haole>2 AM here... no time to do regexes lol <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 <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. <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 <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>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>initializing argument 5 of 'scm_unused_struct* scm_c_define_gsubr(const char*, int, int, int, scm_t_subr) <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>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. <haole>there are lots of errors... maybe it's easy to port, don't know <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>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/libgv_guile.so") in guile 2.0.9 <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 <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. <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 <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>that's measuring a guile -c '(sleep 100)' <wingo>so that's the minimum memory usage <haole>wingo: how do I read that? lol <wingo>those are four numbers, they add up <wingo>shared clean, shared dirty, private clean, private dirty <haole>does guile have some options to ease concurrency implementation? <wingo>that script is wingolog.org/pub/mem_usage.py <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 :) <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>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 <nalaginrut>wingo: I guess guile-master is faster than python, no? <nalaginrut>alas~it's no good, since I boasted that everywhere ;-P <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>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 <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
*wingo finishing up compiler things for review <wingo>a rebased branch with some cleanups <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>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>nalaginrut: you can swap that already <wingo>in gnome you can choose to do that from some menu <wingo>otherwise whatever your DE is i think there is an option <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. <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 <davexunit>I'm interested in small keyboards like the happy hacker, choc mini, and kbc poker <wleslie>I want a kinesis, although I would probably remap half of the keys under the thumb <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>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 <wingo>i think jao had one at one point <add^_>Is that the kinesis thingies? <wleslie>it's not fancy and curved, it's pretty minimal <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_>when my wife saw what HHKB looks like, the order was canceled, so forget about it... <wleslie>the extra redundancy could maybe improve typing speed <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_>alright, if we have single-hand-keyboard, maybe break Emacs, we could put hand on mouse <shanecelis>davexunit: Kudos! You've been putting in the time for guile-2d. <sneek>Welcome back mark_weaver, you have 1 message. <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) <mark_weaver>well, it wasn't until the end when I really learned something. I like the contification algorithms :) <wingo>yep, and now you see the problem with ours :) <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>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) <davexunit>shanecelis: going pretty well. got my first contributor and bug tickets this week. <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. <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. <davexunit>developers using OS X typically use soemthing called Homebrew as a package manager, and it installs software into /usr/local/Cellar <mark_weaver>The new qemu-1.6.0 apparently now supports MacOS X (PPC) guests. <mark_weaver>so it's mostly portability problems in guile-sdl, looks like... ***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. <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>(you keep saying that you're going to put this hack down for a while, but apparently it's a bit addictive :) <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