Fernando-Basso has quit [Remote host closed the connection]
libertyprime has quit [Quit: leaving]
orivej has quit [Ping timeout: 245 seconds]
Sgeo has joined #racket
Sgeo_ has joined #racket
Sgeo has quit [Ping timeout: 245 seconds]
pera has quit [Quit: leaving]
liberiga has joined #racket
travishinkelman has quit [Quit: travishinkelman]
<lavaflow>
so if I include a module using an except-in clause, those identifiers won't be loaded into the namespace of the parent module, however if the parent module then goes on to use namespace-attach-module and namespace-require in a new namespace and eval's code under that namespace, the identifier excluded by the except-in is still bound inside that new namespace?
<lavaflow>
I think that's what I'm seeing, unless I botched something. which happily is what I wanted in the first place
<lavaflow>
is it the namespace-require that does it, since that namespace-require isn't being given the except-in clause?
<ZombieChicken>
anyone have a suggestion on how one might go about testing charterm-related code? the REPL breaks and won't work with it
<ZombieChicken>
and I'm hoping I don't have to go through the "run in term, test, close, modify, run in term..." loop
liberiga has quit [Ping timeout: 260 seconds]
<ZombieChicken>
...weird. Apparently something isn't happy; in my user documentation page (~/.racket/7.3/doc/index.html) the section for charterm is listed as (park ("(lib charterm/charterm.scrbl)" "top")) instead of just a link to the charterm stuff
<lavaflow>
ZombieChicken: I'm not sure precisely how I'd go about doing it, but my instinct is to run it in the repl like normal but to have it connect to a different PTY, not the one the repl is under.
<ZombieChicken>
how the heck would I go about that?
<lavaflow>
hard to say, I've never done stuff with charterm, but back in the day I used to do a lot of C/ncurses
<lavaflow>
I'm pretty sure it should be possible, but I'm not precisely sure how it should be done
<ZombieChicken>
I'm going to assume that that is going to be more effort than just doing this the Long Way, and would likely take me longer to figure out than the rest of this would take for me to implement
<lavaflow>
problem is, opening /dev/tty won't work. that would give you the controlling pty, which would be the one the repl is under
<lavaflow>
somebody with fresher knowledge of pty stuff might be able to give you a quick solution, but I'm a bit too rusty on this stuff. I'd need to spend some time playing around with it again.
<ZombieChicken>
yeah. Ideally I think one should be able to easily open a REPL socket somewhere to talk to and have the main REPL thread just wait for input instead of closing
<lavaflow>
my guess is... get_pty(...) to create a new pty, then pipe it's inputs/outputs through to another terminal emulator maybe using some cheeky socat magic
<lavaflow>
but I think that wouldn't quite work, e.g I don't think you'd get SIGWINCH through that
<lavaflow>
you could try something like the remote repl thingy geiser-mode offers
<ZombieChicken>
except emacs is throughly useless for me
<ZombieChicken>
I like scribble/lp2, and NOTHING in emacs-land supports that syntax
<lavaflow>
incidentally, how do you find charterm to be? I've used ncurses bindings with guile before and that was alright. ncurses in general is kind of kludgy, but I have a soft spot in my heart for it.
<ZombieChicken>
I havn't done much with it
<ZombieChicken>
but it seems fairly straight forward
<ZombieChicken>
and vastly simpler than ncurses
<lavaflow>
nice. ncurses can be pretty rough
<ZombieChicken>
yeah
<lavaflow>
okay, so this _might_ work, I'm not sure. in a termnial emulator window where you want your character graphics to display, run `tty`. that should return the filename of the pty controlling that terminal emulator window
<lavaflow>
use that path as an argument to (open-charterm #:tty ...)
<lavaflow>
I'm not sure if that will work or not, I can't remember if you can have multiple programs connected to the same pty at once, but it might be worth trying
<lavaflow>
you might also want to suspend the shell in that terminal emulator, or otherwise put it into a state where it won't be printing stuff itself
<lavaflow>
setsid stuff or something might also be needed to change the controlling terminal.. not sure
<ZombieChicken>
Tried that and the other TTY didn't so much as flicker
<lavaflow>
drat
<ZombieChicken>
No worries. I have it setup so it can run as a shell script and it shouldn't be too rough trying to make use of it
<lavaflow>
socat has pty mode that I'm about 90% sure could be made to so what you want, but I've never used that part of socat before.
<ZombieChicken>
hmm
<lavaflow>
oh, got it
<lavaflow>
in your target terminal emulator, do: ` socat PTY,link=/tmp/mypty,openpty - `
<lavaflow>
then in your repl, use: (open-charterm #:tty "/tmp/mypty")
<ZombieChicken>
I got it
<ZombieChicken>
I have a procedure called (open-output-buffer ...) and I added an arguement to it to take the TTY. It works now as one would hope
<lavaflow>
nice
<ZombieChicken>
just have to check that I give it the right pty address
shwouchk has quit [Quit: Connection closed for inactivity]
<ZombieChicken>
hrm. Not working exactly how I had hoped, but it's a start
<ZombieChicken>
guess it's hung up on that 5 minute sleep
<ZombieChicken>
which, in retrospec, makes sense
<lavaflow>
I'm also not sure what if any signals will get through. ctrl-c kills socat instead of signaling the racket code over the pty, which I guess is to be expected. I'm not sure about SIGWINCH (e.g. handling the terminal emulator changing size)
<ZombieChicken>
I managed to get it to work through charterm
<ZombieChicken>
w/o socat
<lavaflow>
nice
<lavaflow>
that should work better I think. the - in the socat command means it only does stdin/stdout I think, so probably no sigwinch that way.
<ZombieChicken>
I havn't touched this code in a bit and forgot how it worked since I was lazy and didn't read it over
<lavaflow>
I know that feeling
<ZombieChicken>
sad thing is I don't think TTY/display stuff was ever meant to be easy to debug
<lavaflow>
it's all from the late 60s, early 70s. the interface to it is a total mess
<ZombieChicken>
yeah
<ZombieChicken>
but it still seems better than GUI writing
<ZombieChicken>
I've never seen something for that that didn't feel like it needed a degree /for that specific tech/
<lavaflow>
maybe. there are definite advantages to terminal programs over traditional gui applications for sure.
<lavaflow>
racket/gui is pretty easy to use though imho. perhaps not the best gui toolkit, but reasonable enough
<ZombieChicken>
Oh wow
<ZombieChicken>
drracket it taking 1.4 GB of RAM
<ZombieChicken>
that's a first
<lavaflow>
ouch
<ZombieChicken>
three clicks of the GC button and it's down around half a GB
libertyprime has joined #racket
<ZombieChicken>
well, there goes that
<ZombieChicken>
charterm-read-key straight up won't work like that
<lavaflow>
hmm, there migth be some `stty` incantation that would fix that, but I'm not sure. maybe putting the target terminal into raw mode or something like that.
<lavaflow>
does the socat method with - work? I think that should do both stdin and stdout if socat is doing it properly.
<ZombieChicken>
at this point I'm just going to run this as a shell script. I've spent more time messing with getting this to work in an ideal way than would likely have taken me to do something useful
<lavaflow>
aye
<ZombieChicken>
thanks for the help though
<lavaflow>
no problemo
<lavaflow>
I'll probbably take a serious stab at it sometime in the near future. I think I might have some uses of my own for charterm
<ZombieChicken>
at least we know you can pass a pty device via (open-charterm #:tty ...) and draw on another device, which is interesting
<lavaflow>
interesting and *maybe* even useful :)
<ZombieChicken>
yeah, for something like a monitor for something
jao has quit [Ping timeout: 245 seconds]
selimcan has quit [Ping timeout: 272 seconds]
libertyprime has quit [Ping timeout: 245 seconds]
pie_ has quit [Quit: pie_]
libertyprime has joined #racket
lockywolf has joined #racket
lose has quit [Ping timeout: 258 seconds]
lockywolf_ has joined #racket
lockywolf has quit [Ping timeout: 248 seconds]
endformationage has quit [Quit: WeeChat 2.5]
lockywolf_ has quit [Ping timeout: 248 seconds]
lockywolf has joined #racket
keep_learning has quit [Quit: Ping timeout (120 seconds)]
hasebastian has joined #racket
<ZombieChicken>
Just wanted to say; scribble/lp2 kinda sucks. It takes forever for the preprocessor to do it's thing before the program can run it seems
lockywolf_ has joined #racket
lockywolf has quit [Ping timeout: 245 seconds]
ubLIX has joined #racket
sagax has joined #racket
manualcrank has quit [Quit: WeeChat 1.9.1]
davidl has quit [Ping timeout: 245 seconds]
ZombieChicken has quit [Quit: WeeChat 2.5]
hasebastian has quit [Remote host closed the connection]
lockywolf__ has joined #racket
lockywolf_ has quit [Ping timeout: 272 seconds]
dddddd has quit [Remote host closed the connection]
<lavaflow>
"Racket’s file-stream ports, pipes, string ports, and TCP ports all support atomic writes;"
<lavaflow>
maybe a dumb question, but does "support atomic writes" mean that all writes to these are atomic, or that atomicity is available but perhaps not the default?
ziyourenxiang has joined #racket
ziyourenxiang_ has quit [Ping timeout: 268 seconds]
lockywolf_ has joined #racket
lockywolf__ has quit [Remote host closed the connection]