IRC channel logs


back to list of logs

<kurohin>what happens if scm_from_locale_string(n) is called in a thread that has not been initialized for guile? I have called scm_boot_guile, but this thread is started after scm_boot_guile.
<davexunit>hello guilers.
<davexunit>I have a confusing issue and I'm hoping someone can educate me.
<davexunit>I am in a situation where, at the REPL, (foo) does the right thing but (define bar (foo)) does not.
<davexunit>in particular, an OpenGL call is failing.
<davexunit>I'm not sure what is happening in the define form to cause such a thing to fail.
<davexunit>to make things weirder, if this is run as a script, (define bar (foo)) does the right thing.
<adhoc>davexunit: you are writing OpenGL apps ?
<davexunit>adhoc: yes.
<davexunit>I am building a 2d game development framework.
<davexunit>one of its goals is for the user to build games at the REPL interactively.
<adhoc>very nice
<davexunit>but right now defining new textures is failing.
<adhoc>can't help with that =/ i'm still learning basic stuff at the moment
<davexunit>good luck. guile is a lot of fun.
<adhoc>=) ta
<adhoc>davexunit: so what is the differnce between the REPL and scripting environment ?
<adhoc>are there different configs parsed ?
<adhoc>is there are more strict mode in the REPL or something ?
<davexunit>I don't really know how to explain it.
<davexunit>I don't usually notice differences.
<davexunit>but this is one of those times.
<adhoc>is there a way you can list the modules loaded?
<davexunit>at the REPL, anyway.
<davexunit>there's a difference. the REPL has these neat metacommands you can use.
<davexunit>to inspect things.
<adhoc>er, so how do you use that?
<adhoc>i get ABORT: (unbound-variable)
<davexunit>just type guile in your terminal.
<davexunit>and you're at the REPL
<adhoc>do you need to print or format the ,import
<davexunit>try: ,help module
<davexunit>see if ,import shows up in that list
<adhoc>standard input:1:1: In expression (unquote help):
<adhoc>standard input:1:1: Unbound variable: unquote
<adhoc>ABORT: (unbound-variable)
<adhoc>$ guile --version
<adhoc>Guile 1.8.7
<adhoc>is this a recent thing?
<davexunit>whoa, guile 1.8.7.
<davexunit>that's an old version.
<davexunit>over 2 years old in fact.
<adhoc>this box is that old i suppose
<adhoc>probably more
<davexunit>you'll want to get yourself a 2.0.x version of guile.
<davexunit>preferably 2.0.9
<davexunit>guile 2.0 brought major upgrades.
<adhoc>dang, i'm going to have build one then
<adhoc>or upgrade from squeeze =D
<davexunit>you definitely should upgrade.
<davexunit>at least to wheezy.
<davexunit>I use testing, personally.
<adhoc>yeah, its time isn't it
<adhoc>i have wheezy and jessie on boxes at home, but this desktop at work needs to be uip and running all the time
<davexunit>ah okay.
<davexunit>wheezy has guile 2.0.5, but I would strongly recommend the latest release, 2.0.9
<davexunit>I think my issue has to do with the modifications I made to the REPL server.
<davexunit>actually, wait. I think I misunderstand something about geiser.
<davexunit>this is very interesting.
<davexunit>whatever geiser-eval-last-sexp is doing is different than what's happening when I type at the REPL prompt.
<nalaginrut>morning guilers~
<zacts>I want to try guilemacs sometime
<zacts>and guile-wm
<nalaginrut>I tried guilemacs
<civodul>Hello Guilers!
<kurohin>hi civodul
<nalaginrut>I think fastCGI may not necessary for Scheme, although it cuts down the data during TCP forwarding, the speed of processing depends on business-logic in the web-backend.
<nalaginrut>no mention Guile has fluid to do Thread-local-store
<nalaginrut>But it's just my guessing..
<civodul>hello jemarch
<ArneBab_>I just realized that call/cc can describe the ability of one of the character-classes in the PnP RPG we write - by being called in a function which takes the state of the whole world as state ☺ — main problem: The program executing that will need some memory mechanism which represents the saved arguments as difference to the global world-state (which nicely describes how the cost of the power rises the longer you hold the continuation)
<ArneBab_>(they can jump back in time when they prepare it beforehand - but the effects on them do not get reversed)
<davexunit>I use continuations in guile-2d for coroutines. they are a good tool for writing games.
<ArneBab_>what do you do with them - practically? (I only understood what they do right now…)
<ArneBab_>(for a quite strict measure of understood)
<civodul>use delimited continuations, not call¢c
<davexunit>I was going to get to that point, eventually. thanks civodul. :)
<ArneBab_>what’s the difference betwen both?
<davexunit>I use delimited continuations to easily describe tasks that take more than one unit of game time.
*ArneBab_ reads delimited continuations on wikipedia
<civodul>ArneBab_: see "Prompts" in the manual, it's even better :-)
<davexunit>ArneBab_: (define (contrived-example) (move-right npc) (wait 60) (move-left npc))
*ArneBab_ is trying to understand the contrived-example…
<ArneBab_>where do you use abort-to-prompt? In wait?
<ArneBab_>I think I understand call/ec: That’s like using return anywhere in a function in Python, with the difference, that only the given thunk of code returns, not some larger special construct.
<davexunit>ArneBab_: yes, within there.
<davexunit>I built an abstraction on top of delimited continuations.
<davexunit>it uses a scheduler to run continuations at a later time.
<ArneBab_>so there you can abort-to-prompt, count 60 ticks and then continue?
<davexunit>abort to prompt, add continuation to scheduler, tick scheduler 60 times and then the continuation is run.
<davexunit>the game loop ticks the scheduler.
<ArneBab_>that sounds quite nice!
<ArneBab_>davexunit: and after running the continuation, you just throw it away, right?
<ggrant>davexunit: Did you ever find the bug in Guile-WM, where if you resize a window no be non-visible and attempt to expand it in the opposite direction that you shrank, crashes the xsesion?
<davexunit>ggrant: I actually haven't encountered that bug
<add^_>ggrant: that's a bug in X, not guile
<davexunit>ggrant: the bug I've encountered is trying to move/resize the root window.
<add^_>I've seen that in serveral x-based programs..
<davexunit>that explodes.
<davexunit>and I've fixed it.
<davexunit>but it's not merged yet.
<ggrant>add^_: Is is avoidable, in guile-wm though?
<davexunit>perhaps I should nudge mark witmer again via email
<ggrant>Happens with xterm, conkeror, and emacs -- that I've tested thusfar.
<add^_>I don't know if it's avoidable, I don't run guile-vm (that's why I can say that it's not the origin of the problem)
<add^_>Maybe are some other, more stable uses of x that some just don't use?
<add^_>For example, the use of glut is apparently one of those things, many do, but (apparently) it's quite unstable because of those bugs you just described..
<add^_>Maybe I should just shut up.
<davexunit>one thing that guile-wm desperately needs is an abstraction layer over xcb
<davexunit>I wanted to write code to resize a window to fill half the screen, but I have to be concerned with the inner workings of X and xcb to do it.
<davexunit>if we abstract that away then not only will extending guile-wm be easier, it will be easy to port to wayland.
<davexunit>all the extensions should theoretically still work.
*ggrant knows very little about the Free Software graphics stack, but yeah -- I'd for one be much more interested getting educated en the realm of Wayland, that Xorg.
<ggrant>Damn, 3rd person.
<ggrant>But yeah, right now -- interfacing with xcb, seems needlesly complex. Some of that might be fueled by my ignorance, but still.
<davexunit>it needs to be done, but it needs to be done only *once* for any given operation.
<davexunit>it needs to get abstracted away at that point.
*ggrant really needs to work getting his Schemefu up-to-snuff, so he can start getting further involved into some of these projects -- which are certianly on his radar. To SICP, again I suppose. :^)
<davexunit>ArneBab_: here's a guile-2d example with coroutines
<ArneBab_>(sorry, I got sidetracked - only returned here now)
<davexunit>actually, it isn't really using a coroutine at the moment, so it's a misnomer, but you could *pretend* it is.
<davexunit>schedule-interval is the key here.
<davexunit>that says every 60 ticks, run this thunk.
<davexunit>so it really shows off the scheduler more than anything else.
<ggrant>davexunit: Oh yah! I thought you were just taking a break from guile-2d, not that you moved to gitorious.
<ArneBab_>davexunit: ok
<davexunit>ArneBab_: the readme has a bit more info
<davexunit>ggrant: yeah I moved. I have a branch off master that I will merging in shortly.
<davexunit>a few more problems to tackle before guile-2d 0.2 release.
<ggrant>davexunit: Well, I'm excited to check it out again. :^)
<davexunit>cool. :)
<ArneBab_>davexunit: so in the walk-up-and-down example, the scheduler executes the continuation and throws it away, but the continuation registers a new continuation
<ArneBab_>that’s then how you can step through the function.
<davexunit>yeah basically, the agenda is actually ignorant of continuations.
<ArneBab_>that’s a very, very distributed approach - I like it: keeps the agenda simple.
<davexunit>it just schedules thunks.
<ArneBab_>and each thunk can know whether it wants to run again - and if one stops running, you know that the error is inside the thunk
<davexunit>yeah, you'll see that in the backtrace.
<davexunit>I didn't do anything special there. that's just guile doing its things.
<ArneBab_>even if there is no error, you know that the thunk must have failed to register a new continuation
<davexunit>there's 2 key modules that you could read: coroutine.scm and agenda.scm
<ArneBab_>davexunit: where does the coroutine actually use the thunk?
<davexunit>line 42
<davexunit>43, rather.
<ArneBab_>ah - I did not spot that the function continues after the empty line
<ArneBab_>(code review: I did not spot that the function continues after the empty line ☺ )
<ArneBab_>(all your other definitions in the file have no empty lines, so you might want to kill the empty line there, too)
<davexunit>yeah that might be a good idea.
<ArneBab_>also this will make your coroutine-function end in line 42 ;)
<ArneBab_>(code-review: It took me some time to see codefine as co-define and not as code-fine)
<ArneBab_>so what you do is calling the thunk. Do I understand it right, that the continuation *requires* a callable as first argument?
<ArneBab_>(i.e. a function?)
<civodul>jemarch: recutils 1.6 no longer accepts hyphens in field names, right?
<civodul>1.5 was fine with that
<jemarch>hyphens in identifiers don't mix well with infix arithmetic expressions :)
<jemarch>(I know, I know)
<civodul>who cares about infix arithmetic expression! ;-)
<civodul>wingo: excellent work on the manual & blog post
<civodul>the reflections are very interesting
<civodul>i think it's unusual to have good insight on this kind of design decisions
<wingo>thanks, glad you enjoyed them
<wingo>the manual is still a bit rough; there are things to do there...
*civodul heads home
<kurohin>good day/night/morning/whatever guilers
<taylanub>Good moment!
<kurohin>guile: uncaught throw to unbound-variable: (#f Unbound variable: ~S (myextension-my-hook) #f)
<kurohin>if I scm_c_define a hook in my init function for the extension should it not be accessable from another thread?
<wingo>kurohin: which guile version?
<wingo>there was a bug about that a long time ago
<kurohin>2 0 9
<wingo>that shouldn't exhibit the bug :)
<kurohin>I think I might be doing things wrong, If in one thread do scm_make_hook in my C extension init function and then after starts another thread and does scm_guile_init() followed by run_hook,
<wingo>check the current module in the main thread where you defined the thing, and in the auxiliary thread
<wingo>the problem is probably that the module is not the same
<kurohin>it was a typo, dash instead of slash
<mark_weaver>happy new year, wingo! :)
<mark_weaver>I've been meaning to ask you a question about bytevectors, namely why #u8(1 2 3) is not equal to #vu8(1 2 3). it's causing problems for my R7RS work.
<mark_weaver>(thanks for the truncation cleanups, btw! :)
<mark_weaver>Is there a reason not to unify the U8 and VU8 element types into one?
<mark_weaver>R6RS specifies the #vu8(1 2 3) syntax for bytevectors. R7RS specifies #u8(1 2 3) syntax. Most of our bytevector procedures return #vu8(...). It's going to be a mess if we can't unify them.
<wingo>happy new year mark_weaver !
<wingo>the $kreceive thing took much longer than expected :)
<mark_weaver>I'm not surprised. I'm glad you found the energy to get it done :)
<wingo>regarding #vu8 and #u8, let me see if I recall correctly.
<mark_weaver>there are still a lot of optimizations that turn 'call-with-values' into 'let' or even simpler, thus introducing a truncation that wasn't in the original code. but we can track those down later.
<wingo>yes those erroneous optimizations are in peval
<wingo>scheme@(guile-user)> (use-modules (srfi srfi-9) (rnrs bytevectors))
<wingo>scheme@(guile-user)> (u32vector? #vu8()) (bytevector? #u32())
<wingo>$2 = #f
<wingo>$3 = #t
<wingo>so i think the thing is that all srfi-9 uniform vectors are distinguishable between themselves
<wingo>and they are all bytevectors
<wingo>but not all bytevectors are (e.g.) u32vectors
<mark_weaver>so bytevector is sort of like a superclass of all the SRFI-4 vector types.
<wingo>or u8vectors, for that matter
<wingo>yes i think that was the intention
<mark_weaver>that makes sense.
<wingo>evening, civodul
<civodul>hey wingo
<mark_weaver>wingo: would it be possible to get rid of U8 as a distinct subclass of bytevector, and instead make it the superclass?
<wingo>mark_weaver: it would, yes; let me think on the possible implications...
<mark_weaver>so all the other SRFI-4 types would still be subclasses, but U8 would be the general bytevector type?
<mark_weaver>okay, thanks!
<wingo>so one thing that would cause would be (u8vector? #u32())
<wingo>=> #t
<wingo>which is not the cas now
<mark_weaver>hmm, yeah.
<wingo>seems like a regression in some ways... otoh this is a space of compromises without perfect solutions...
<mark_weaver>if you can think of a better compromise to deal with R7RS, I'm open to suggestions :)
<wingo>did r7rs standardize #u8() ?
<wingo>silly people
<civodul>but not #vu8, of course :-)
<mark_weaver>yeah, one of those gratuitous incompatibilities with R6RS that they introduced :-(
<mark_weaver>actually, they listed "compatibility with SRFI-4" at the rationale for using the #u8 syntax.
<wingo>do we know the shape of the more generic interface they are proposing? are they proposing to adopt srfi-4 wholesale, or something else?
<wingo>srfi-4 is a silly api for a generic blob facility
<mark_weaver>I don't know off-hand.
<wingo>seems to me you really want to be able to access a mixed blob of different types
<wingo>like elf files, for example
<mark_weaver>yeah, I certainly agree.
*wingo should burn his r7rs draft printouts ;)
<mark_weaver>I like the fact that you unified bytevectors and SRFI-4.
<wingo>heh, glad you liked that ;) i did too but it does have downsides
<wingo>e.g. an optimizer has to assume that a u32vector can alias an f32vector, etc
<wingo>oh well
<mark_weaver>does SRFI-4 require that all of the types are distinct?
<wingo>good question!
<mark_weaver>it says "analogous to the Scheme vector type, but they are distinct datatypes", which isn't entirely clear to me.
<mark_weaver>but maybe I'm trying too hard to see what I want to see :)
<mark_weaver>anyway, if we want to support R7RS (and I think we do), then I think we have to unify U8 and VU8.
<wingo>right, distinct from vector?, but do they have to be mutually distinct?
<mark_weaver>(there's an r7rs-wip branch in guile-git that supports most of R7RS, btw)
<wingo>i feel like a weasel reading this way ;)
<mark_weaver>exactly :)
<wingo>could we unify #vu8 and #u8 without breaking r6rs? sounds a bit nasty but i guess we could do it
<mark_weaver>hmm, good question. does R6RS specify that bytevectors are a distinct type from SRFI-4 U8 vectors?
<wingo>(u8vector? #u32(1 2 3)) is a definite down-side though
<wingo>mark_weaver: r6rs says nothing about srfi-4
<mark_weaver>there is also the issue of print syntax. we could have a print option for that, I suppose.
<wingo>seems to me r7rs just made a bad decision in this area
<wingo>srfi-4 u8vectors are not suitable as a fundamental data type
<wingo>i was sure that when i was interested in the topic, #vu8() was the decision
<wingo>i guess that changed at some point
<civodul>#vu8 has the advantage that it can coexist with SRFI-4
<civodul>if we end up having read and write options for all these things, that may become unmanageable
<mark_weaver>I suppose the other option would be to keep them separate, but consider them 'equal?' and 'bytevector=?' anyway.
<civodul>think of R8RS and its #xu8
<mark_weaver>yeah, the read+write options are definitely a serious problem.
<mark_weaver>however, if we keep them separate, then I think we need for the R7RS bytevector procedures to produce U8 vectors instead of VU8 vectors.
<mark_weaver>but it's a bit of a mess :-(
<civodul>actually that would be the easiest thing, no?
<mark_weaver>of course, I'd like for R6RS and R7RS code to coexist in the same system and operate on the same data, as smoothly as possible.
<civodul>just map R7RS bytevectors to SRFI-4 u8vectors
<mark_weaver>civodul: well, it means duplicating a bunch of bytevector procedures, and I suspect there would be problems with programs that mix R6RS and R7RS libraries together.
<mark_weaver>really, we should be aiming for a unified data model whereever possible.
<mark_weaver>or so it seems to me, anyway... WDYT?
<civodul>mark_weaver: if R7-bytevector = SRFI-4-u8, then there's nothing to duplicate, AFAICS
<civodul>because an u8 is already usable with the R6-bytevector API
<civodul>we'd need a 2nd 'string->utf8' procedure, that uses the u8 tag instead of vu8
<civodul>but that's easy
<mark_weaver>the R7RS test suite calls bytevector-returning procedures and compared them with expected values like #u8(...), which fails.
<mark_weaver>and if I convince myself that this was only a test-suite problem, then I'd just fix the tests, but I think not.
<mark_weaver>*if I could
<civodul>if R7-bytevector is implemented in terms of SRFI-4 there's no problem, is there?
<mark_weaver>here's the problem, in my mind: R6RS and standard Guile code that specified to recieve a bytevector will reasonably assume that it's a VU8.
<mark_weaver>now if a R7RS procedure produces a bytevector and passes it to a procedure written in R6RS or standard Guile, it's violating the contract, effectively, without it being obvious.
<civodul>if R7-bytevector = SRFI-4-u8, then it just works no?
<civodul>what am i missing?
<civodul>that is, a u8 can be passed to an R6RS program that expects an R6 bytevector
<wingo>what if we make make-bytevector and similar produce a #u8() object which is nevertheless a subtype of #vu8() ?
<civodul>that's even better
<wingo>we keep all the existing read and write syntax, and don't change srfi-4 or bytevector code at all
<wingo>only we make r6rs bytevector procs return objects that don't print as #vu8
<wingo>they print as #u8
<wingo>it's a little incompatible but it's not terrible
<mark_weaver>well, they'd have to be considered 'bytevector=?', and thus 'equal?', as well.
<wingo>we can hack bytevector=? of course ;)
<wingo>we can even add a new bytevector element type
<wingo>if needed
<wingo>dunno, just brainstorming
<civodul>i know i shouldn't say that, but: how popular is R7?
<civodul>(just brainstorming ;-))
<wingo>as-is the difference between u8 and vu8 is silly
<mark_weaver>in terms of being able to understand contracts, I'm a little concerned with their being confusion about how type contracts of the form "a bytevector is expected" or "a bytevector is returned" will be interpreted.
<wingo>civodul: i care about it to the extent that it allows us to share code with chicken, and not much farther
<wingo>mark_weaver: currently "a bytevector is expected" means any uniform vector is expected
<wingo>and "is returned" means a vu8 is returned
<mark_weaver>civodul: heh, I suppose we could just try to keep R7RS from going anywhere, heh.
<wingo>hah, it's an option ;)
<wingo>dunno if it's a healthy thing to do tho ;)
<mark_weaver>we'd have to change those contracts, such that "is returned" means that a U8 is returned.
<mark_weaver>oh, sorry, maybe not. hmm.
<wingo>well we could do that
<wingo>r6rs wouldn't be able to tell -- except it would print as #u8()
<wingo>that would be the only difference
<mark_weaver>I guess I'm worried about code that is tested against VU8, and so they think it works, but then it fails if given a U8.
<wingo>mark_weaver: i don't think there is any code like that
<wingo>all vu8 code works on u8's.
<wingo>unless you care about the external representation
<mark_weaver>well, are U8 vectors accessible using the larger element type accessors?
<mark_weaver>I assumed that VU8 was more flexible.
<wingo>from c, yes
<mark_weaver>but not from Scheme?
<wingo>ah you mean (u32vector-ref #u8(0 1 2 3) 0)
<wingo>yes that also works, for better or for worse :)
<wingo>yeah, kinda sketchy
<wingo>but ok, it's what we have
<mark_weaver>so type predicates like u32vector? are the only potential difference between U8 and VU8?
<wingo>yep, that and the external representation
<mark_weaver>well, that makes me think they should just be unified, then.
<wingo>they are not unified currently precisely because of the external representation
<wingo>and also so that (u8vector? #u32()) => #f
<mark_weaver>if the type predicates are the only way to tell the difference, that almost seems silly.
<wingo>well the type predicates were the only thing available in srfi-4 and pre-2.0 guile
<wingo>also array-type i think
<wingo>i'm not justifying the thing, just explaining :)
<mark_weaver>understood :)
<davexunit>hey guilers. I have a question about the REPL server.
<mark_weaver>I'm nervous about keeping them separate with only such a slight difference. I think it could lead to subtle bugs, where code handles one correctly but not the other one.
<mark_weaver>I'm less worried about the dangers of (u32vector? #u8(...))
<mark_weaver>but maybe we should all mull this over for a bit :)
<mark_weaver>davexunit: what's your question?
<davexunit>I was using Geiser yesterday and I noticed a difference in behavior between evaluating code at the REPL prompt and evaluating code via geiser-eval-last-sexp.
<davexunit>as you know, mark_weaver, I'm using a tweaked REPL server that deposits thunks to be run in another thread.
<civodul>davexunit: what difference?
<davexunit>well, evaling code at the REPL worked as expected.
<davexunit>my custom code within run-repl was hit.
<davexunit>I inserted a little display statement in there just to be certain.
<davexunit>however, when evaling with C-x C-e, I saw no such debugging statement.
<mark_weaver>I don't know much about how Geiser works. it might have swallowed your debugging output, or maybe it sent the command to a different REPL?
<wingo>mark_weaver: yeah, for mulling -- i guess my only concern is old code, potentially non-guile srfi-4-using code that uses the predicates to discriminate between different srfi-4 data types
<wingo>that would be the thing that would break
<mark_weaver>that's a potential issue, certainly.
<wingo>perhaps it's not a big deal tho
<wingo>anyway, to think about :)
<davexunit>mark_weaver: perhaps it was run elsewhere, but the code would have thrown an exception I think.
<davexunit>the code worked, but had one issue that I've only seen when the compiled thunk is wrong in the wrong thread.
<davexunit>an OpenGL call failed and returned 0 when the result should be > 0 on success.
<davexunit>s/is wrong/is run/
<davexunit>I'm going to do more investigation later, but I figured I'd mention here to see if I could figure out more possible culprits.
<mark_weaver>You could replace the OpenGL call with (current-thread), and try running it both ways.
<mark_weaver>davexunit: are you using the one that runs the thunk in a different thread, or the later version that does the _reading_ in a different thread?
<davexunit>mark_weaver: the former. I'm not using a custom version of guile.
<mark_weaver>ah, right.
<davexunit>it couldn't have been the wrong REPL now that I think about it.
<davexunit>I was redefining a variable that was being drawn to the screen.
<davexunit>I tried to change an image that was being drawn.
<davexunit>I can do that from the REPL prompt and it works. yay.
<davexunit>but when I do it via C-x C-e in a scheme buffer it just draws a white box. boo.
<civodul>does that buffer have an associated module?
<mark_weaver>I have to go offline for a while. happy hacking, all!
<davexunit>civodul: no.
<davexunit>it's a just a quick script that doesn't belong to a module.
<davexunit>this also fails when the buffer is associated with a module.
<davexunit>I checked that, too.
<davexunit>the problem is that my custom code is being bypassed entirely.
<davexunit>and I'm not sure how.
<davexunit>reading the REPL server code, it seems that there's only one way to read user input.
<davexunit>and only one place to apply the compiled thunk.
<civodul>when a buffer has no associated module, C-x C-e evaluates in whatever module is current in the associated REPL, i think
<civodul>so you'd have to make sure it gets evaled in the right module
<davexunit>civodul: I'm confident that it's being evaled in the right module, but it's not the real issue.
<davexunit>it's as if I had 2 different REPL serve-client threads running.
<davexunit>one using my custom code, and one not.
<davexunit>but it seems that there's only one connected client: geiser.
<civodul>do you have debugging statements in the REPL server?
<davexunit>well, every time a compiled thunk is run via a procedure that I wrote, a string is printed to stdout for me to read. I haven't done any more sophisticated debugging.
<civodul>perhaps you could print something in Geiser's Scheme-side evaluation code
<civodul>(i realize this isn't ground-breaking advice)
<davexunit>I dug around in the the geiser source, I'll try inserting some debugging there.
<davexunit>I just figure that no matter how geiser works, the input *has* to get read within run-repl, which I've modified to do my evil bidding.
<civodul>ah, right
<davexunit>I'll try to inspect more sometime later when I get home from work.
<davexunit>I just want to solve this problem so I can joyfully write games at the REPL.
<civodul>cbip cbip cbip
<civodul>our custom-binary-input-ports are flawed, grrr