<amz3>dsmith-work: yeah, some is working on a REPL using ncurses <lloda>guile 2.2, f I connect to the port that Guile opens with --listen I see %default-port-enconding = "ANSI_X3.4-1968" even though the default at the Guile REPL is "UTF-8". setting the fluid does nothing. how do I fix this? <lloda>--listen calls (spawn-server) and that calls (make-tcp-server-socket) and that port has ASCII encoding, but if I call (make-tcp-server-socket) at the REPL I do get UTF-8. I don't see where the ASCII encoding comes from :-| <dsmith-work>amz3: I've never heard of one. Why bother since readline is available? <dsmith-work>amz3: You could probably use rlwrap, but that just uses readline. <cmaloney>I have a quick question about paren matching in the repl: only one of my machines seems to want to do it <cmaloney>same .guile config on all machines (copied from my main machine, which doesn't do paren matching) <cmaloney>Where's the best place to see why the one machine is behaving how I want (paren matching) and the others aren't. <dsmith-work>cmaloney: Just a guess. ISTR some recent improvement for paren matching at the repl. Basically, DON'T do it while pasting. Maybe the code that detects if it's a paste is deciding wrongly. <dsmith-work>So somewhere there is some code that figures out if it's a paste or not, and disables paren matching if it is. (cause paren matching really screws up in a paste). <dsmith-work>If that code is broken and is *always* assuming "pasting" .... <cmaloney>Is there a config param that I can pass to the repl to see what it thinks? <dsmith-work>cmaloney: Also need to have "vi" in your readline keymap (whatever that is!) <dsmith-work>cmaloney: Also, is can be configured through te bracketed-paste guile readline option. <dsmith-work>cmaloney: So that depends on your readline library on that system. <cmaloney>This is in my .inputrc set editing-mode vi <cmaloney>I added those to the environment of the machine that is doing the paren matching and it now behaves like the other machines <cmaloney>It looks like if editing-mode is set to vi then it no longer does paren matching <cmaloney>trying to debug it with gdb and finding that setting a breakpoint is maddening. ;) <cmaloney>Not able to break on guile-readline/readline.c::429. <dsmith-work>Hm. I wonder if those rl_bind_key's will work when in vi mode. That modal stuff might get in the way. <cmaloney>I'm trying to make some test code to see what gets returned and I'm about as stuck as I can get <cmaloney>I'm not sure what I'm doing wrong where it's not linking ***dsmith-w` is now known as dsmith-work
<cmaloney>OK, figured out what i was doing wrong (-lreadline needed to be at the end) <cmaloney>it looks like this is dead code on my system <cmaloney>since it shows up as emacs, even with the .inputrc file setting the mode to vi <stis>yeehaa, starting to be able to compile python defs to guile :-) <amz3`>so it seems like indeed call-with-continuation makes all things more terrible at compiling scheme to javascript <amz3`>dsmith-work: apparently that's a REPL that support sexp editing like paredit does <amz3`>I don't do paredit myself yet <stis>amz3`: im exploring what python+guile means, not the same as python if you ask me but very similar <stis>plus I want to play with an extension for funcitonal objects <stis>python style oop but interoperating with goops nicely <amz3`>stis: I lost faith I think regarding python, scheme is much more powerful even if exception handling in python is rather nice <amz3`>stis: yes, a layer on top of goops for using goops like python oop will be nice <stis>true, you can use the python object system from scheme if you like as well and not use python syntax <amz3`>stis: I am writing yet another time my parser combinator ^^ <amz3`>I'd like to improve error handling somehow <amz3`>I discovered that megaparsack also, which does some of the thing I would like to have <stis>yes i've been thinking likewise <stis>some way to say that when you come so far you should succceed is the most lowest hanging fruit <stis>in the more complex case there is a tree of reasons for failing the parser <amz3`>I have written parser with two layers: first layer does tokenization and another which does build the ast <amz3`>both use the parser combinators <stis>okey, yes that's what I do as well <stis>if you are interested folks <stis>I think that I will add the following syntax <stis>meaning that x.a.b is updated functionally and we will create a new object returned to x <stis>e.g. f might update x1 and hence return a new object <stis>x1.f(10) - will call the same function but perhaps mutate x1 <dsmith-work>amz3: Yeah, I havne't taken the plunge into paredit yet. Played with it a few times. But it's not under my fingers. <janneke>i found #:canonicalization 'absolute on compile-file <janneke>*finally* have emacs jump to error locations again...*HAPPY!* <sneek>Welcome back civodul, you have 2 messages. <sneek>civodul, ng0 says: A check for shell support before I continue working on it: would you accept new introduced files especially for tcsh/csh and fish to get their environment variables from? Those are so far the 2 major shells which differ from the way zsh/*ksh*/bash sets them. In (guix search-path) I just need to add 2 variations which will then be used in (guix build profiles) to generate the <sneek>civodul, ng0 says: etc/csh.profile and one other thing for fish i haven't looked into yet <civodul>i've had a couple of issues with Geiser since 2.2 i think