IRC channel logs
2025-08-15.log
back to list of logs
<rlb>dpk: do you know of any further developments wrt "noncharacter" error handling? Mostly I'm wondering if that's where we're likely to end up. <dsmith>ArneBab, I rememeber reading the article rms wrote in Dr Dobbs. <Kyuvi>Are there any resources for making new languages on guile, other than language source code? i.e tutorials, blog posts etc? <Kyuvi>these two are not working..... <mange>Where did you get those links from? <Kyuvi>copilot, why did it invent them? <mange>I can see no evidence of either ever existing. <dpk>rlb: well, the system as we have it works as far as we know, and we have basic consensus for it, but that part of the spec proper is still in the future. i can a move formal discussion or vote up the priority list if you want a more definitive answer sooner <dpk>rlb: it would be helpful to have a real implementation of it being used for its intended purpose before getting to a formal decision, fwiw! <mwette>Kyuvi: basically, you need to put a spec.scm file under language/ under path which exists in GUILE_LOAD_PATH; spec.scm provides a name, reader, compiler and writer. <mwette>examples/language/calc examples/nyacc/lang/calc is very simple one <mwette>examples/language/nx-javascript is more complex <old>anyone knows how I can tell geiser to use a unix socket for connecting to Guile? <old>it seems it only support port number <old>any variable I configure to set the default of the path? <identity>it just reads a path with ‘read-file-name’, which defaults to the current directory <old>the REPL seems broken tho hmf <old>I get no prompt found <old>and got something like: <old>^A^Bscheme^A^B^A^B@(^A^B^A^Bguile-user^A^B^A^B)^A^B^A^B^A^B^A^B> ^A^B <old>hm seems to be related to my .guile <ArneBab>dsmith: I was almost 3 when that article was released ☺ -- free software brings generations together :-) <rlb>dpk: was just considering our path there -- if I knew that was the future, then I'd be inclined to focus on that for guile, but I wouldn't want to add something complex that we'd then be committed to, if there's a chance the standard's going to settle elsewhere. <rlb>Though for now, I've about finished a sample implementation of a proposal for one of the ways we can add bytevector support in the relevant places, e.g. (getcwd 'bytes) -> bytevector. That, coupled with the srfi-207 bytestring support and perhaps wingo's suggested "bytestring flavored bytevectors" might be sufficient, whether we also add the nonprinting support eventually too, or not. <Kyuvi>mwette Sorry I completely missed your comment <Kyuvi>Funnily enough, I ended up looking at nyacc for completely different reasons and found your languages and calc lang a minute ago <rlb>And of course there are plenty of variants of the bytevector support api we might choose -- I've just implemented one of each of the main cases for one particular approach to show what it looks like. Then if no one's opposed, and we can settle on a variant, I'll finish it out. <Kyuvi>I will explore calc, but I feel I am just taking shots in the dark maybe it am approaching it wrong but there are some strange issues and I was hoping someone had mad a blog post about how to go about it right <rlb>(It ended up needing to be at the tree-il level.) <Kyuvi>When I tried the brainfk example, I realised that I could not just use the lang from the command line (with --language=x) , I had to go in and switch to the lang to compile it the first time and then it worked from the command-line. It is things like that that I am hoping too save time on as obviously it works <Kyuvi>rlb I have seen lokke and it is a bit too complex <rlb>While I don't recall the details, unfortunately, I do recall spending a good bit of time trying to figure things out and/or work around some behaviors I didn't quite undertand, i.e. things that I thought would work that didn't. <rlb>I did get it more or less working, but not sure I did it "right" -- hence potentially "confusing". <Kyuvi>I was actually just trying to extend the basic scheme, but I just kept getting errors <rlb>yep, for better or worse :) <rlb>dpk: in any case, if some variant of the bytevector support is acceptable, and we're not fairly sure about noncharacters, then I imagine we might want bytevector support anyway, and I'm happy to add it soon. <dpk>what do you mean by bytevector support? <dpk>(i mean, Guile already has bytevectors, i’m currently staring at a file of code which uses them and it works in Guile, so i assume you mean some specific context :D) <rlb>Adding support in all the places that matter so that you work with bytevectors instead of strings, e.g. (with one approach) (getcwd 'bytes) -> bvec, and (unlink #u8"foo\xb5;") etc. <dpk>that would probably be a good basis on which to build whatever we end up going for in WG2, even <mwette>Kyuvi: can you summarize what you've done. Are you using language/scheme/* as a starting point? <rlb>My current proposal, where I've implemented one of each "case", might not be the variant of possible approaches we want, but I'm hoping it'll provide the impetus for us to choose one, and then I'll do it. <rlb>"variant of the possible approaches that we want" <Kyuvi>rlb I think I was automatically logged off for your earlier comments, that is why I missed them. Lokke is quite a project what I am doing is a lot simpler but there seems to be a lot of unexpected/unexplainde behaviour that I was hoping someone had witten about, nyaccs examples are interesting but I feel I am missing something about initializing <rlb>Not sure which comments you mean, but I did say that yes, I recall hitting some things that took me a while to figure out, for some version of "figure out". <rlb>I think some of it may have been around initializing the "the environment". <Kyuvi>@mwette nothing much, I tried to "inject" some functions into language/scheme, but I just kept getting "language not recognized" (or something like that) when I tried to start with --language=x even after it stated it was compiled, so I tried out the brainfk example and that kept failing till I realized I had to start guile and laod the language <Kyuvi>I think my main question is how do i test the language incermentally without having to ether close guile, restart and load each time? can I just swithch back to scheme and then into the language again? Baically how can I test what I am doing incrementally <identity>Kyuvi: i would expect that reloading the modules (with ,reload) would do the trick <Kyuvi>I want to add a few modules into the guile scheme start up so I can use the language directly without having to load the modules all the time, I also want to experiment with a different module system. I tried putting module-use! in the default environment code, but that didn't work. <mwette>Kyuvi: if your language is "foo" then you have a file language/foo/spec.scm under one of the paths in $GUILE_LOAD_PATH ? If not, you need that. <Kyuvi37>identity which modules the (language lang spec) module? can I load it from within the language or do i have to switch to guile load it and switch back? in which case quoting and restarting would be easier I tihink. if there is the a way to relaud and compile from the command line. <Kyuvi37>mwette (sorry I got logged out again) I uderstand the loading system part I was hoping for a less repetive way to test the language as I work on it (like ,reload , as identity sugested) <identity>i would expect REPL commands to be available regardless of the language, you probably need to reload the modules you made changes to <Kyuvi37>,identity ok that might work (hopefully ) <Kyuvi37>Thanks though I just hoped some advice gotchas might be documented somewhere. Will ask here begin to feel really stuck (y) <Kyuvi>mwette I have another question about nyacc, when using "define-ffi-module" (I literally just read the ffi-helper docs). is the header file always needed how do I know if the header file is already on the system? I am trying to use it on libwnck and make a guile replacement for devilspie <Kyuvi>I keep getting disconnected form here for some reason <ieure>Kyuvi, Because your connection is timing out. <ieure>*** Kyuvi37 (~Kyuvi@mobile-access-b0484d-71.dhcp.inet.fi) has quit: Ping timeout: 250 seconds <ieure>The IRC server got no response from your client for >4 minutes. <ieure>(This is not the same as "you didn't send a message for >4 minutes") <Kyuvi>ieure even when I am typing that is a bit strange (though my connection is a bit loaded) <ieure>Kyuvi, Could be that your local machine is under load and both increasing latency of keypresses and network I/O, but these things are otherwise unrelated. IRC is line-oriented, it doesn't send characters as you type them, so that's not directly related to any network issues. <rlb>Kyuvi: often just "make -j5 check", so I might not be the best resource there :) Though I also work a lot from the command line with some example file. i.e. I'm often more in the "banging on it with rocks" end of the spectrum, as compared to "language server, dynamic reloading, etc.". <rlb>(or run a single test directly, since I set all of them up so you can) <rlb> I *sometimes* do dynamic/relading/etc., but I've also been frustrated often enough by various languages, arrangements, etc., and the time consumed by the stack's complexity, or changes thereto, that I fall back to the more direct approach :) <rlb>(Also has the advantage of never being fooled/confused by accumulated state.) <Kyuvi>rlb but you were reloading from the command line (compiling each time) ? even when only working on the lisp side of things? <Kyuvi>rlb by "dynaming relaoding" you mean form within the language? <rlb>I mean I may often just have a file or test that exercises the thing I'm currently concerned with and hten "up-arrow return" in bash is pretty fast most of the time :) <rlb>But I also know how that sounds compared to "what's possible", hence maybe "not the best resource" :) <Kyuvi>rlb aha but I guess you had a working language at that point. I need to get mine to actually load first... <Kyuvi>will just try ,reload with fingers crossed <rlb>And sometimes I do follow the fancier path, though for some things, like perhaps this, where you're messing with lower level bits, like multiple languages/contexts in guile, the simpler approach might have more merit. <rlb>Oh, well depending on what you mean, I might just make a test .scm that has explicit code to load the language related modules and call eval in that language manually to get started. <rlb>then "guile start-somewhere.scm" :) <rlb>But you also probably have to be fine with "printf" style debugging (format, write, etc.) some of the time. <Kyuvi>no worries will poke around some more <Kyuvi>I am ok with print style debbuging, :] <ieure>I love print debugging. Proper debuggers are fickle, if your program can't print, you got way bigger problems. <rlb>...I got used to it back in c/c++ when gdb didn't yet have real/solid thread support. Not too many other options at that point :) <Kyuvi>I am going away for a couple of hours, if I get disconnected and mwette responds please let me know, thanks. if I can get the devilspie thing to work, I might need another language for that.... :]