IRC channel logs

2013-07-30.log

back to list of logs

*davexunit sucks at automake
<davexunit>I grabbed an automake file that builds .go files, and now I'm trying to expand it to build a shared library as well. not going so well.
<davexunit>I'm writing a macro. I pass it a 'name' argument, for example: foo. I want that macro to expand to calling the %foo procedure. how do I do this?
<mark_weaver>sneek: later tell davexunit (define-syntax foo (lambda (x) (syntax-case x () ((foo name) (with-syntax ((%name (datum->syntax #'name (symbol-append '% (syntax->datum #'name))))) #'(%name))))))
<sneek>Got it.
<mark_weaver>sneek: botsnack
<sneek>:)
<ozzloy>is sneek an irc bot written in guile?
<mark_weaver>yes
<brendyn>nalaginrut: I found Skribilo, it looks cool. i wonder if its usable for blogs too
<add^_>Hi davexunit
<davexunit>Hi add^_
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, mark_weaver says: (define-syntax foo (lambda (x) (syntax-case x () ((foo name) (with-syntax ((%name (datum->syntax #'name (symbol-append '% (syntax->datum #'name))))) #'(%name))))))
<add^_>Good, you got the message :-D
<davexunit>mark_weaver: thank you. I was looking at syntax->datum but just couldn't put the pieces together. slowly but surely I'll conquer these tricky macros.
<ft>Hm, Guile doesn't support changing serial-line properties, yet. Right? Like configure number of stop-bits, baud rate or parity generation?
<ft>...at least "git grep termios" doesn't produce any hits. Bummer.
*taylanub doesn't know what Guile has to do with serial terms ?
<taylanub>ft: Do you mean e.g. the REPL changing properties of the serial term over which it's running ?
<ft>Well, in this case, I'm talking to a microcontroller board via a USB link. The USB link looks like a serial link to the OS. And I'd like guile to set the links baud rate etc. before it talks the ASCII protocol the microcontroller understands.
<ft>I mean, I can use `system' and call stty on the device file... but I'd rather not. :)
<taylanub>I see.
<ozzloy>mark_weaver, where's the code for sneek?
<dsmith-work>ozzloy: It's not generally avaliable.
<ozzloy>oic
<dsmith-work>ozzloy: The bot is bobot++
<dsmith-work>Which is C++ extended with guile.
<dsmith-work>ozzloy: Basically, its a really crude port of the old sarahbot from #scheme
<add^_>I wonder what I've done to mess up my environvent this much :-/ And I also wonder how to fix it...
<dsmith-work>ozzloy: Also sneek currently lives in a raspberry-pi in my basement.
<add^_>For some reason it seems as though guildhall has taken over the role of being the directory where every guile package is, even though it isn't.
<add^_>I shouldn't have to wipe the system, but I guess I will have to if I can't get this fixed...
<tupi>dsmith-work: is it not free software ? [the bot i mean]
<dsmith-work>tupi: The bobot++ code certainly is. The sarahbot code was available at one time.
<dsmith-work>And do you *really* want to see my crummy code?
<tupi>:) i was just curious, i have never seen any bot code [should i be ashamed :)]
<tupi>why is it not pure scheme [guile] ? resource [man power] i guess
<dsmith-work>tupi: At the time, I just wanted to get something happening quickly. unknown_lamer suggested bobot++, which he maintians.
<tupi>where is sarahbot code, still available somewhere?
<dsmith-work>Ya
<dsmith-work>The scheme it's implemnted in is java based.
<tupi>dsmith-work: i understand. unknown_lamer is a good schemer isne'the? should ask him why not in scheme ...
<dsmith-work>Well, the bot already existed. It was extended with guile.
<add^_>tupi: you could check out fbs's irc thingy in scheme
<dsmith-work>tupi: I started messing with a sneek2 some time ago, but I just don't have the energy to put into it.
<dsmith-work>Pure guile this time.
<tupi>dsmith-work: yes, i guess it's quite a job to write a bot ...
<tupi>add^_: tx
<taylanub>Depends .. I wrote a simple one in POSIX sh once. :P
<add^_>Finally! I might have fixed the problem :-D
<add^_>Hard to say yet though..
<add^_>Uh, guildhall still complains about some R6RS error, but guile-figl builds now..
<dsmith-work>tupi: bobot++ is really a channel bot. Kicking users, ops-ing people, etc.
<davexunit>add^_: yay for figl building!
<dsmith-work>Not using any of that.
<add^_>davexunit: yeah, now I just need to do that on the other computer too :-/
<add^_>And now for unknown reason, your configure.ac (which is basically identical to guile-figl's) doesn't work? When configuring it says that GUILE_PROGS isn't a found command... Wait a minute..
<add^_>What the heck
<tupi>dsmith-work: i don't understand your last sentence 'Not using any of that'
<add^_>tupi: he doesn't use those functions
<add^_>tupi: kicking, oping and so on.
<add^_>tupi: for the bot
<tupi>you mean sneek ?
<add^_>What else?
<tupi>wel i would have writen it :)
<add^_>What?
<tupi>forget it, i have to concentrate on something else actually
<add^_>davexunit: apparently I just had to copy the acinclude.m4 to your guile-2d dir
<add^_>To make it configure..
<davexunit>oh? perhaps I forgot to VC that file.
<davexunit>I always get mixed up with autotools. :/
<davexunit>I tried figuring out how to add a shared library build task to my Makefile.am last night
<davexunit>I gave up
<add^_>Ah
<add^_>I think I did something like that in guile-irc..
<add^_>I don't know if that was the exact problem
<add^_>Now I've run make and make install!
<add^_>Wiee
<add^_>Let's try an example then..
<davexunit>cd examples; guile -L .. simple.scm
<add^_>Hm
<add^_>Segfault
<davexunit>oh? that's bad. but good in a way. let's see if we can get this working.
<dsmith-work>tupi: .. of that stuff that bobot++ usually used for.
<davexunit>add^_: any other info along with that segfault?
<davexunit>my guess is that loading an image failed and blew up.
<add^_>Nope, I'll try to rebuild sdl, because it might have been an "newer" version that was configured there before..
<add^_>Nope
<davexunit>perhaps we can make guile-2d crash gracefully first?
<add^_>Hm
<add^_>segfaults are not very nice since it's hard to get any output from them.. maybe I could use gdb or something?
<davexunit>dump some display statements in to start with
<davexunit>find out what procedure is crashing this
<dsmith-work>davexunit: By "shared library" do you mean something you link with -l or a something that is dynamically loaded well after the program starts?
<add^_>wut
<add^_>Probably one of the modules, it doesn't even get to the first display
<davexunit>dsmith-work: I want to write parts of my library in C. so, I need to not only compile my guile files, but compile the C stuff and build a shared library from it.
<add^_>Yeah, module
<add^_>I put a display before the inclusions of modules
<davexunit>dsmith-work: so I guess, to answer your question, something that is loaded after the program starts.
<add^_>Not telling me which one though :-P Not that I'd expect that to happen though.
<davexunit>add^_: start adding display statements to the modules
<dsmith-work>davexunit: Ok, I had lot's of trouble figuring our how to do that with automake too. This might help: http://gitorious.org/guile-sqlite/guile-sqlite/blobs/master/Makefile.am#line16
<davexunit>thanks!
<add^_>davexunit: it seems to be the window module
<davexunit>add^_: makes sense
<add^_>Well
<davexunit>dsmith-work: where does GUILE_CFLAGS come from?
<davexunit>I had to use pkg-config to get mine
<add^_>Might be somewhere in the game loop too, since the segfault is after game-loop
<add^_>Yeah, game-loop. Sorry
<davexunit>good progress. let's find this bug.
<davexunit>do you see a window open briefly? or is the problem when importing a module?
<add^_>Nope, it's in game-module, it's the handle-event function it seems..
<add^_>Might be because of SDL?
<add^_>Weird, I thought the cleanup, reconfigure and make would do it..
<davexunit>so it breaks when running handle-event ?
<dsmith-work>davexunit: No idea!
<add^_>Yeah
<dsmith-work>davexunit: Probably pkg-config
<davexunit>dsmith-work: okay! that works for me.
<davexunit>I was able to write a plain old Makefile that worked, but adding in the automake stuff is a headache.
<davexunit>I guess because I just don't grok m4
<dsmith-work>davexunit: Yep. I had like a 20 line makefile.
<davexunit>I understand the utility of autotools, but it is fair that is referred to as autohell a lot.
<dsmith-work>It just seem wrong to have your final makefile be 100x the size of your C code.
<dsmith-work>(or whaever times)
<davexunit>yeah...
<davexunit>but on the other hand, I don't like other build systems either.
<davexunit>so autohell it is.
<dsmith-work>I've got a bit better grasp of it than I used to.
<dsmith-work>But it's still somewhat bewildering
<davexunit>I tried reading the manual and it was still really confusing.
<youlysses>shanecelis: o/
<add^_>Waaat, this is really confusing
<add^_>I built sdl one more time, now the segfault is earlier? -.-
<davexunit>why did you build SDL from source anyway?
<davexunit>it's a quick apt-get away (or whatever package manager you use)
<add^_>Not sdl
<add^_>guile-sdl
<davexunit>ohhhh
<youlysses>add^_: What's the problem?
<add^_>Actually, now it's back to "normal"
<add^_>-.-
<add^_>Gosh, I need a break soon
<add^_>Ooh, that's why.. Because I installed guile-2d
<add^_>That's why my changes aren't always going through
<add^_>I'm such a dumbass
<add^_>So anyway, it's the call to SDL:make-event or something along those lines that seems to be the problem
<davexunit>a-ha! that makes sense
<add^_>?
<youlysses>Guile-2d is in a more-or-less "properly installable" state already?
<add^_>Yes, but not usable just yet
<davexunit>since that is executed upon module load.
<add^_>Well
<add^_>Kinda
<davexunit>yeah, it's usable... by myself only. :
<davexunit>:P
<davexunit>add^_ is helping me fix that.
<youlysses>Yah! Progress, is progress. :^)
<shanecelis>youlysses: Hello
<davexunit>add^_: do you have SDL 1.2 installed?
<add^_>Yeah
<davexunit>hmmm
<add^_>Otherwise I wouldn't be able to build guile-sdl
<davexunit>I don't know if there's anything that I can do about a guile-sdl command failing.
<davexunit>that's true.
<add^_>No, that's annoying
<add^_>Foiled again, these lib-writers are truly scheming up something in the darkness (pun intended)
<add^_>:-P
<davexunit>there's gotta be *some* reason
<add^_>Maybe just my system sucks
<add^_>Ah, I needed to do all that crap on this computer too..
<davexunit>can you use guile-sdl from a repl without any guile-2d nonsense?
<add^_>The other computer is the workstation, where I usually do the fun stuff
<add^_>Why?
<davexunit>just an idea
<youlysses>shanecelis: So, I was making another go at installing Emacsy again on my Debian Stable box -- and even commenting out 'AM_EXTRA_RECURSIVE_TARGETS' leaves me with a possibly undefined macro and a failing error message on autoreconf: /usr/bin/autoconf with a status of 1. :^P
<davexunit>I think guile-sdl comes with examples. try running one?
<add^_>davexunit: good idea
<add^_>I tried running make check
<add^_>EVERYTHING failed
<add^_>Dunno why
<add^_>that didn't occur to me before
<add^_>Good call
<add^_>Oooh
<add^_>This problem again
<add^_>Maybe it'll work after this
<add^_>Yay, check goes through!
<add^_>davexunit: now it works!
<add^_>guile-2d that is
<add^_>Awesome
<add^_>guile-sdl is such a pain sometimes though..
<add^_>Oh well
<add^_>Break time for me
<add^_>:-)
<add^_>Thanks davexunit
<shanecelis>youlysses: hmm...
<davexunit>add^_: how did you get it to work!?
<shanecelis>youlysses: Have you tried doing it from the 0.1.1 release?
<davexunit>also, yay you can *finally* use guile-2d
<youlysses>shanecelis: Oh, must have slipped by me. Nah -- I'm on latest git.
<shanecelis>youlysses: Yeah, it's tougher to do from source just because the automake version differs.
<youlysses>shanecelis: Where's the 0.1.1 release being hosted?
<davexunit>youlysses: github
<shanecelis>youlysses: https://github.com/shanecelis/emacsy/releases
<add^_>davexunit: it worked when I got guile-sdl to work
<add^_>So it wasn't your fault
<davexunit>yay!
<add^_>It's just a annoying thing in guile-sdl that usually bugs out, one of the .c files
<add^_>And apparently it's still not fixed
<add^_>Oh well
<add^_>Good job davexunit :-)
<add^_>Now, I'll have that break xD
<shanecelis>davexunit: Holy shit, I'm just looking at guile-2d. This is great! I love the colambda!
<ozzloy>dsmith-work, icic, cool
<dsmith-work>sneek: version
<sneek>Sneeky bot running on Guile version 2.0.9 using bobot++ 2.3.0-darcs
<dsmith-work>!uname
<sneek>Linux berry 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux
<youlysses>shanecelis: I'm assuming it's purely an issue with a disparity between the build-tools on both systems. Same issue on the release version. :^P
<davexunit>shanecelis: thanks!!
<davexunit>glad you like it.
<shanecelis>youlysses: I don't understand. With the release, you shouldn't have to even run autogen or autoconf. Just try to run ./configure && make
<youlysses>davexunit: Don't know of what'd you have to do in-terms of crediting, but I thought it'd be cool to have a live-rendered "moognu" as an example. :^)
<davexunit>youlysses: great idea! the /g/ board on 4chan made that.
<davexunit>I'm a known entity there in some small way.
<shanecelis>davexunit: It's cool. I started with delimited continuations and accidentally re-implemented coroutines for Emacsy, but I think it'd be better if I just set them on a proper coroutine foundation, and your code looks like a good foundation possibly.
<youlysses>shanecelis: You know what... I accidently grabbed the source-release and not the actual package. :^U
<davexunit>shanecelis: it's based upon some code from the mailing list. I just added some abstractions around it to make it super simple to use.
<shanecelis>youlysses: :)
<shanecelis>davexunit: Man, come the next Ludum Dare, I think I'll want to use guile-2d. :)
<davexunit>shanecelis: haha. I'll need to really get working, then!!
<davexunit>I have some performance issues to deal with.
<shanecelis>davexunit: LOL, yes, youlysses is making me work too. ;P
<davexunit>I need to come up with a solution to my live-coding woes, as well.
<youlysses>Yah, I'm serving some purpose in the little free-time I've had the past month or-so. :^)
<shanecelis>live-coding woes? Do tell. I had a dream of editing and reloading, but I've kind of worked myself back into a edit-run-compile loop again.
<youlysses>Today might be the last-time I'm online till the 2nd or 3rd though. Move-in extremely soon! :^)
<davexunit>shanecelis: I'm stuck in the edit-run-compile loop, also.
<davexunit>the issues are because of multithreading
<davexunit>to work around them, you can't program at the repl you would when doing the edit-run-compile thing.
<davexunit>I consider that a bug for guile-2d.
<davexunit>the game loop is constantly chugging, and doing something like loading an image from another thread causes things to blow up.
<shanecelis>davexunit: Yeah, it's more like a read-only REPL or sometimes pokable REPL.
<davexunit>I can update code just fine, it seems.
<davexunit>but doing things that require SDL function calls is trouble.
<davexunit>I really hope to find a solution to this problem, but it's been frustrating thus far.
<shanecelis>youlysses: any luck?
<youlysses>shanecelis: It seems to have built ... but when I try to go to the example directory and build them, it's telling me pkg-config couldn't find it.
<shanecelis>davexunit: I had a similar issue. It seems like the right way to do it is to have some kind of execution context be it (thread, or render-portion) and ferry your expressions _somehow_ from the REPL, execute them there, then return the results.
<shanecelis>youlysses: that should be OK. If you run ./configure from the emacsy top-level only, those warnings are fine. What happens if you do 'make run'?
<youlysses>shanecelis: It's having problems in emacs-webkit-gtk. Maybe I don't have the needed depends on my end?
<shanecelis>youlysses: Hmm... I'm thinking the pkg-config error for not finding Emacsy is fine. Perhaps you're getting a different pkg-config error?
<davexunit>shanecelis: I'm thinking the same thing, but I also don't know how to do it. It would be nice if there was a remote repl that just stored things in a queue for another thread to pick up and execute.
<davexunit>but I think that would be problematic, because the environment that the evaluation is happening in is differnet.
<youlysses>shanecelis: If it's not due to a lack of depends, I'll respond back with the error message.Give me a few.
<davexunit>I'm just not sure how to resolve the problem.
<shanecelis>davexunit: guile-lib has a nice thread-safe queue (like channels from Go) http://www.nongnu.org/guile-lib/doc/ref/container.async-queue/
<davexunit>shanecelis: that's one piece of the puzzle... now... how to do the REPL part? :P
<shanecelis>davexunit: Hooks into Guile REPL is EMPTY :( http://www.gnu.org/software/guile/manual/guile.html#REPL-Hooks
<tupi>davexunit: manual 6.17.12, any use for you ?
<davexunit>let's check.
<davexunit>does my basic design premise sound... sound: the repl server running in a thread of its own enqueues code to be executed into an async queue. a worker in another thread dequeues and does the evaluation.
<mark_weaver>you can do it more simply by having a global mutex.
<mark_weaver>in the main game thread, the mutex is held almost all the time, but periodically in its loop it unlocks it briefly.
<mark_weaver>in the repl, run the code while the lock is held.
<davexunit>mark_weaver: I was hoping you would chime in :)
<mark_weaver>that should ensure that the code is only run at the right time.
<shanecelis>OH, smart!
<youlysses>shanecelis: http://paste.lisp.org/display/138268
*shanecelis loves #guile
<davexunit>how do I ensure that the repl only runs the code when the mutex is locked? make my own repl server?
<davexunit>which would be a small modification of (system repl server) ?
<mark_weaver>good question. I'm not sure if we have a hook that would allow that, but yeah, in the worst case you could make a copy of the relevant REPL code and slightly modify it.
<davexunit>I could unlock the mutex a few times per second. I'm not sure how much overhead the mutex will add. I have some performance issues already and don't want to add more with this mutex.
<davexunit>mark_weaver: that would work for me. I'll have to try that next time I have some free time.
<mark_weaver>speaking of performance, I've been working hard at making immediate floats a reality for guile.
<mark_weaver>the idea of reduced-precision floats was a can of worms though, so I did one better: NaN-boxing for guile-master.
<mark_weaver>(on 64-bit platforms only)
<davexunit>mark_weaver: oh wow. that's awesome.
<youlysses>On only a tangentially related note, I'd be cool/nice if Emacsy could have some emacsclient like functionality -- which one could leave open an active server-like system which a user could leave running and connect to. Too you wouldn't need the gui to be left open to send messages to it; Like sending a "play next" to a media-player, or something.
<shanecelis>youlysses: hmm... ok. I think I know what's going wrong. So the top-level emacsy ./configure will set the appropriate flags and run the example ./configure scripts. However, if you run ./configure in the examples, it won't know where to find Emacsy. Can you try from the top-level running, './configure && make && make run'
<mark_weaver>basically it takes advantage of the fact that current 64-bit platforms only have a 48-bit address space, which fits in the payload of a NaN.
<davexunit>mark_weaver: that could alleviate many of my performance issues, I think.
<davexunit>I don't know anything about NaN-boxing
<davexunit>I guess not many people are running non-64 bit platforms these days.
<shanecelis>youlysses: Yes, I definitely want some kind of emacsclient thing. I just don't know quite which IPC technology to hitch myself to.
<mark_weaver>it's a decreasing set of people anyway :)
<davexunit>so it will be a little unfortunate for guile-2d to run poorly on 32 bit machines, but I suppose once a native compiler lands that situation will be much better anyway?
<mark_weaver>davexunit: wingo wrote about NaN-boxing a couple of years ago here: http://wingolog.org/archives/2011/05/18/value-representation-in-javascript-implementations
<davexunit>mark_weaver: thanks
<mark_weaver>in many ways, NaN boxing is just a stop-gap measure until we have a compiler that can "unbox" values in performance critical code.
<shanecelis>davexunit: I will be interested in this REPL you make.
<youlysses>shanecelis: http://paste.lisp.org/display/138269
<davexunit>shanecelis: it will be the first thing I'm going to work next time I'm at a computer that isn't at work.
<davexunit>hopefully tomorrow.
<shanecelis>youlysses: oh, so close!
<mark_weaver>we should probably add some kind of hooks to guile's repl that would allow this sort of thing to be done (assuming there isn't already one; I'm not sure)
<shanecelis>mark_weaver: could be. might just lack documentation.
<davexunit>mark_weaver: interesting. so, given enough time, floating point operations will perform much better than they do currently. I will continue to fight my urge to write C. :)
<mark_weaver>the ability to wrap the evaluation of each expression seems generally useful.
<davexunit>if there's not then maybe I could add it?
<mark_weaver>patches welcome! :)
<davexunit>I'll see what I can do. I would love to contribute a patch to my favorite programming language. :)
<mark_weaver>performance will definitely improve a great deal once we have native compilation.
<shanecelis>youlysses: ok. In hello-emacsy/src, try running: GUILE_LOAD_PATH=../../../src ./hello-emacsy
<mark_weaver>hi wingo!
<wingo>heya mark_weaver :)
<wingo>how goes?
<youlysses>shanecelis: "error:Unable to load module (emacsy emacsy). Try setting the GUILE_LOAD_PATH environment variable."
<mark_weaver>FYI, I have a new NaN-boxing patch for master.
*wingo working on cps things
<mark_weaver>only for 64-bit platforms though.
<wingo>interesting
<mark_weaver>improves floating point math by a factor of over 5.
<wingo>i tried nan boxing a while ago but decided it was a bad idea
<wingo>that's a pretty nice improvement though :)
<mark_weaver>I recently re-read your post on the subject: http://wingolog.org/archives/2011/05/18/value-representation-in-javascript-implementations
<wingo>uf, that thing; trying to do too much in c :P
<mark_weaver>I definitely think 64-bit SCM values are a bad idea unless you're already on a 64-bit platform.
<shanecelis>youlysses: Weird. Try: GUILE_LOAD_PATH=../../../src guile -c "(use-modules (emacsy emacsy))"
<mark_weaver>as for the GC interactions, I still put tags in the low bits. Basically, the code is changed as little as possible.
<wingo>btw i have cps compiling to rtl now; currently cleaning up the prompt things
<mark_weaver>that's great news! :)
<wingo>mark_weaver: what is the integer range?
<wingo>fixnum range i mean
<mark_weaver>in the current implementation, -2^49 to 2^49-1
<mark_weaver>that could be improved of course.
<mark_weaver>right now I'm using only 50 bits of the payload, because it simplifies some things.
<wingo>do you think the patch is a good idea?
<mark_weaver>I'm only using half of the negative signaling NaN range.
<mark_weaver>I think it will probably be a win, yes.
<wingo>hummmm
<youlysses>shanecelis: http://paste.lisp.org/display/138271
<mark_weaver>at least until platforms with virtual address spaces more than 50 bits start to appear.
<wingo>you think the cost of having two different representations will pay off?
<mark_weaver>the patch isn't that bad, since the representations are so similar.
<shanecelis>youlysses: Thank you, youlysses, you've helped me remember there is indeed another dependency. guile-lib. Install this. I shall work to fix this problem and update the docs. http://www.nongnu.org/guile-lib/
<mark_weaver>basically, the representation of everything but flonums stays the same as before, except that some high bits must always be the same as the highest usable bit.
<mark_weaver>so tag checks get slightly more expensive: the general method is to add 1<<N-1 to the SCM value, where N is the number of usable bits (50 here)
<wingo>well, maybe it is worth it
<wingo>consless floating point ops would be nice
<mark_weaver>and that changes the high bits to all zeroes.
<mark_weaver>(for non-flonums)
<wingo>still, i wonder; a lot of floats are made inside procedures
<mark_weaver>and then when masking out the tag bits, I have to include the high bits in the mask.
<wingo>and inside a procedure you can do a lot of tricks (i.e. raw values)
<wingo>so i wonder if the benefit wouldn't go down over time; and the cost could go up as we do more native code generation
<youlysses>shanecelis: Oh, yep -- here we go. :^)
<wingo>but perhaps that is not a significant concern
<mark_weaver>so for example, SCM_ITAG3(x) becomes: ((SCM_CELL_TYPE (x) + SCM_I_TAG_CHECK_OFFSET) & (SCM_I_HIGH_BITS_MASK ^ 7))
<mark_weaver>here SCM_I_TAG_CHECK_OFFSET is 1<<(N-1) (mentioned above)
<mark_weaver>so that basically turns the high bits into all zeroes if it's a non-flonum.
<youlysses>shanecelis: Also -- np, I'm just glad I didn't gloss over anything and in-the-end was just wasting you're time. :^)
<mark_weaver>and then you have to include those bits in the mask.
<wingo>mark_weaver: would be nice to make a tc3 for conses, so we don't have to do the strange tc3 things in the car of a pair
<wingo>just a thing to mention
<shanecelis>Is there a good autoconf way to check that a guile module is available?
<mark_weaver>ah, good point. we could change the way that's done with NaN boxing.
<wingo>a tc3 for structs would also be nice
<wingo>wip-retagging has some of those ideas
<davexunit>tc3?
<wingo>davexunit: a type tag
<mark_weaver>anyway, I'm not sure that NaN boxing will be a good idea in the far future. it might just be a stop-gap measure for the next few years.
<shanecelis>youlysses: Nope. I appreciate you putting up with the kinks to try this thing out.
<wingo>taking 3 bits, in the pointer instead of the memory
<wingo>mark_weaver: it might be a great idea for now; dunno
<mark_weaver>but my current patch is relatively unobstrusive, so it doesn't seem to be something we have to commit to long term.
<wingo>mark_weaver: well if that's the case then we can give it a try
<wingo>i haven't looked at the list recentl
<wingo>y
<wingo>did you send it there?
<mark_weaver>not yet, still tweaking it a bit. but maybe I should just post what I have for early reviews.
<wingo>well, post whenever you're ready
<wingo>no urgency
<wingo>but you know my ongoing concern about maintenance cost :)
<mark_weaver>it's a good thing to worry about, definitely!
<youlysses>shanecelis: I'm easily excitable -- and this (at least to me) is very exciting and relevant tech to-me in-general... So no-problem by any-means here. :^)
<wingo>did you ever read that hofstadter book, "i am a strange loop"?
<mark_weaver>I hope to post something in the next couple of days.
<shanecelis>youlysses: :) Let me know when/if the examples work for you.
<mark_weaver>wingo: no
<shanecelis>wingo: I have.
<wingo>i guess you probably read GEB
<youlysses>shanecelis: Well, hello-emacsy does. It seems to run automatically with "make run" -- still need to see/try emacsy-webkit (or however it's named).
<mark_weaver>I'm embarrassed to say I haven't read much Hofstadter at all. I have a copy of metamagical themas somewhere, but I got distracted before getting very far. and of course I know GEB but haven't read it.
<shanecelis>youlysses: Oh, when you quit hello-emacsy, C-x C-c, it'll run that next.
<wingo>shanecelis: i was struck by his image of these resonant echos other people can have in a brain, that to some very real extent even his deceased wife had a kind of real consciousness in his mind
<youlysses>shanecelis: Then -- yup. :^)
<wingo>anyway i think when you work with someone enough they grow an alternate self in your mind
<wingo>so there is a little mark in my mind, chiding me on my patches ;)
<shanecelis>wingo: I think that's some truth to that. How often are we accosted by those we know even when they're not around?
<shanecelis>wingo: LOL
<mark_weaver>hehe. I can relate to that. I think we all build little models of other people in our heads. I have a Ludovic in my head that helps me avoid gross hacks.
<mark_weaver>and I think I have a little ijp in my head that helps me resist the temptation to build my own scheme implementation from scratch :)
<wingo>:-)
<add^_>mark_weaver: heh
<shanecelis>youlysses: Woohoo! So you see both examples?
<mark_weaver>wingo: btw, although I haven't yet posted about it, I have mixed feelings about getting rid of the struct field annotations (mutability and SCM/primitive). Those seem potentially useful for garbage collection in the future, if we ever allow an (optional) precise moving collector.
<mark_weaver>though of course I agree that the API (e.g. using strings to specify the field types) should be taken out and shot.
<wingo>heh
<wingo>yeah, dunno
<wingo>in the meantime i don't feel the need to do anything about it
<mark_weaver>regarding the pain of initializing the struct fields: maybe the VM instruction should not do immutability checking internally, but instead that should be done at a higher level? dunno.
<youlysses>shanecelis: Can one do anything besides a basic viewer of the comic, in the 0.1.1 release of the webkit browser?
<mark_weaver>even the optional tail seems useful to me.
<shanecelis>youlysses: yeah, M-x goto
<wingo>mark_weaver: regarding the tail, there you are just wrong ;-)
<wingo>'tis a nasty, nasty hack
<youlysses>shanecelis: There might be an error of some-sort then? Any-time I press M-x or any-other bindings really -- the screen just flashs black for o brief second.
<shanecelis>youlysses: Oh, weird. Not sure what that's about.
<youlysses>Oh, it seems to work -- maybe there's a rendering problem.
<shanecelis>youlysses: The whole screen, window, or just the text portion?
<youlysses>shanecelis: It's not even the whole screen, just random chunks -- mostly on the right and bottom of the actual canvas/content holder on-screen.
<shanecelis>youlysses: Strange. I'm probably doing something terribly inefficient. Classic me! ;)
<mark_weaver>wingo: I'd like bignums to be allocated within a single block. adding an extra level of indirection means more cache misses, and more GC allocation overhead.
<wingo>allocating objects of varying sizes is fine; structs simply aren't the mechanism though
<mark_weaver>if not structs, then what mechanism would you suggest?
<wingo>you need a low-level abstraction for fixed-size allocations with type descriptors
<wingo>and structs should be tht
<wingo>*that
<wingo>mark_weaver: since bignums are implemented in C, using a separate type tag would seem to be appropriate -- as is currently the case
<youlysses>shanecelis: I'm just going to assume it didn't build correctly -- I tried closing it and starting again, but when I closed hello-emacsy, it didn't pull back up. :^P
<mark_weaver>wingo: well, sure, but the same issues apply to scheme code. I dunno, I suppose that it wouldn't be *that* bad to use vectors or bytevectors for variable-length structures in scheme, and use hacky ways to access the initial fields.
<wingo>or prepare vtables for the sizes you expect, for example
<wingo>the extra length word in structs with tails is irritating
<mark_weaver>that's not a workable method for something like bignums or bigfloats.
<wingo>e.g. you might make three or four vtables for bignums
<wingo>nums with two words, with three words, etc
<mark_weaver>then how do you check that something's a bignum?
<mark_weaver>and how do you access the initial fields, regardless of which vtable is being used?
<wingo>class precedence lists for example...
<mark_weaver>ugh
<wingo>anyway the concrete operation being compiled will depend on the specific representation
<wingo>if you are usually working on two-word bignums, best to compile a version for that representation
<mark_weaver>it would also mean that every inline cache has to build up separate entries for each vtable, right?
<wingo>it could, yes -- but that's not necessarily expected behavior, nor necessarily a bad thing
<mark_weaver>the problem is, the binary operations have to handle every combination of representations. it becomes unworkable very quickly.
<mark_weaver>numbers.c is already on the edge of being unmaintainable, from all the combinations.
<wingo>call sites only see a small subset of the world of specific types, however.
<wingo>yes, i see that point
<mark_weaver>in fact, I'm looking at ways to unify some of the cases in numbers.c.
<wingo>anyway, think about it -- i really think most problems solved with tail arrays are better solved in other ways
<shanecelis>youlysses: Yay! This is a big win! It works on someone else's machine!
<davexunit>shanecelis: it's a great feeling, isn't it?
<shanecelis>davexunit: Yeah, it is!
<add^_>:-)
<mark_weaver>wingo: I agree that tail arrays are seldom used, but it seems to me that there are cases where they are the right solution.
<mark_weaver>of course, I appreciate that you are trying to simplify some code. I'd like to hear more about that, maybe in email.
<mark_weaver>maybe there's a way to refactor things so it's not so bad, dunno.
<mark_weaver>going afk for a bit...