<lispmacs[work]>I want to be able to try to read a char from an input port, but if nothing is available (say, after 10ms) then return false or throw an error or something. I found section 6.12.13 Non-Blocking I/O but was wondering if that is the simplest way to do it <lispmacs[work]>I'm just trying to clear garbage out of an input stream before sending commands to the output stream <lispmacs[work]>I thought drain-input might be what I was looking for, but it doesn't work <dsmith>select with a timeout should work on a serial port, shouldn't it?' <dsmith>There are also some funky tty ioctls I think. From before sockets I imagine. <ft>Yeah, there's stuff like VTIME in termios. But I would rather use select. <ft>",d select" at the guile repl. <lispmacs[work]>I've read the description of `select' but am not understanding how to use it to be honest <lispmacs[work]>so, I could put the input port as the READS parameter, with a usecs timeout <ft>You give it lists of ports that you're interested in reading and writing, plus a timeout. When it returns either you can do one of those things with one of those ports, or the timeout triggered. <ft>lispmacs[work]: You can take a look at that io-read function I linked to. It basically does that. <ft>It returns an empty list. <lispmacs[work]>ft: could you send me the git clone url so I don't have to unblock the gitlab javascript? <ft>(that io-read is for a line based protocol, so it does ‘read-line’ to read) <dsmith>You can give it no fd's and then it behaves just like a pure timeout, or you can not pass in a timeout, and it can block forever. <ixmpp>is there a convenient tool for formatting guile? <ixmpp>but as a drive-by command line tool? <dsmith>I've not heard of one. I wonder if it's possible to batch emacs to do that. Iv'e heard vi people do org-mode stuff that way. <dsmith>I really suspect most lispers just use emacs. <ixmpp>maybe i'll see if i can pipeline vim then <dsmith>I've finally gotten used to paredit. Most of it anyway. <mfiano>I would check out smartparens. Switched from paredit like 6 years ago <dsmith>mfiano: What's the advantage over paredit? <mfiano>It does everything paredit does, plus more like allowing numeric prefices. It also works in other non-lisp modes, and pairs good with other packages like cleverparens, <mfiano>Mostly though, it just seems to be less buggy. I use a lot of structural editing commands and sometimes paredit can leave the tree in an inconsistent state. <mfiano>I guess another plus is that it's shipped with both Doom and Spacemacs, so likely has a lot more users...and is also actively maintained unlike paredit. <sneek>Not as far as I can remember. <sneek>str1ngs was in #guix 4 months ago, saying: hello daviid just going over your e-mail in regards to <gdk-event> LGTM. I just had to switch to the new !event-type method vs !type. I'll test some more with removing gdk as a dependency.. <sneek>I think I remember zzappie in #guix 20 days ago, saying: yesss. <dsmith>It does a think called metaphone matching. <dsmith>I'm guessing it's supposed to match thinks like dsmith dsmith_ dsmith` ... <dsmith>It also seems to fail miserably at times. <daviid>dsmith do we have to ask again then, when it 'fails' <dsmith>No. It will give the same results. <dsmith>For example, "sneek" and "seems" matched. <daviid>that the bot 'links' zzappie and spk121 is a bit of a mistery <daviid>to me, but then i am not a bot :):) <daviid>well at least i think i am not, but in // universes ... who knows ... <dsmith>(metaphone "zzappie") ;; -> "sp" <dsmith>So it actually saves by the metaphone... <dsmith>I would like to remove that, but then all that "seen" history would be inaccessible. <dsmith>I could just purge that table and start over. <daviid>dsmith oh, i didn't mean to give you any work, and history is very much 'needed' i think <dsmith>And it's working well enough for the most part... <daviid>i was just curious, and wanted to ask last time spk121 appeared here, but ok ... <dsmith>I think that metaphone thing is tuned for real words. <lispmacs[work]>on a loosely related subject: I've noticed that if I do a pretty small write to a file output port, like 16 bytes, that force-output and sync don't actually force the data to the file <lispmacs[work]>I was wondering if anybody had insight into that. I'm on a Guix Gnu/Linux system. <dsmith>SOunds like buffering, but force-output should handle that. <dsmith>lispmacs[work]: I forget, is there a way to disable buffering? You might (or might not!) want to. <lispmacs[work]>dsmith: I would say I don't need to in my use case, mainly just curious <dsmith>If so, maybe need to disable nagle? <lispmacs[work]>though the data does come down the chain from a file input port which is a FIFO *lispmacs[work] looks up what strace is on the internet... <dsmith>strace -e write or maybe -e file <dsmith>strace is kind of like wireshark for system calls. <lispmacs[work]>emacs seems to slow down a little once you have 273000 lines in a buffer <lispmacs[work]>in the strace, nothing gets written until I close the port, and then all 16 bytes are writting in one write call <lispmacs[work]>dsmith: I've read that, but it doesn't explain why force-output is not working here <dsmith>I *would* try setting the port to unbuffered though. <dsmith>Are you sending a byte at a time, or larger chunks? <dsmith>I know it's only about 16 bytes... <dsmith>Hmm. I would think if unbuffered that would be a write() for every byte. <dsmith>IF nothing else, it's a datapoint to help understand what's going on. <dsmith>Sometimes, you just have to poke it with a stick to see if moves or not. <dsmith>That metaphone thing does not do well with "funky" chars. Like non-alpha <dsmith>The old bot in #debian had a "nick-o-meter". And it would tell what percentage lame your nick was. <dsmith>"Your nick is 100% lame, ===!sam!=== <lispmacs[work]>dsmith: everything is immediately dumped if I do (setvbuf op 'none) first <dsmith>(not sure what "immediately dumped" means) <lispmacs[work]>dsmith: well, like I said, doesn't really make much practical difference in my case. I just was curious because I thought force-output was supposed to pull out things that are buffered <lispmacs[work]>immediately dumped means I didn't need to close the port to get the data to file <lispmacs[work]>if I watch strace, I can see that now it is calling one `write' for each byte <dsmith>Ok, just to make sure. You *are* calling force-output on the correct port, right? <lispmacs[work]>dsmith: yes. however, what I haven't tried yet was 'flush-all-ports'. I not 100% sure that buffering isn't happening further up the chain *dsmith shakes fist at usb <dsmith>The thing is, you should really be seeing a write after calling flush. <dsmith>And by "flush" I to mean "force-output" ***bandali_ is now known as bandali
***taylan2 is now known as taylan
<manumanumanu>I have a some guile code for generating permutations, and trying to generate it for (iota 11) (which is very very big, I know) guile just quits with a SIGKILL <emestee>if it's an out of memory issue you'd see that in dmesg <lampilelo>manumanumanu: do you need a list of permutations or just want to iterate over them? <lampilelo>because if you want to iterate, just like lloda suggested yesterday (although to someone else) you can use algorithms from knuth (they're mutating an array and visiting on every iteration) <taw10>Or, perhaps you need section 3.5.3 of SICP? <manumanumanu>I just wanted to see if I could make a faster version of my already pretty fast lexicographical permutations code <manumanumanu>so I implemented Heap's algorithm, and it is a little bit faster <manumanumanu>The one that generates lexicographical permutations is fast, and can easily be made as a generator <emestee>ahhh I get to implement a FSM in scheme ***Server sets mode: +ntz
***unCork is now known as Cork
***dongcarl7 is now known as dongcarl
***dsmith-w` is now known as dsmith-work
<ft>flatwhatson: Hehe, yeah I had this in a let: (fsm (lambda (input) (fold transition start input))) :) <lloda>using Guile from C++, in { X x; scm_error(...); } x isn't destroyed. How to fix this <lampilelo>lloda: that's because scm_error uses longjmp, c++ destructors won't run, what i do is use dynamic wind and a handler that calls them, of course the handler should be set up to run only on non-local exits <lloda>i've been avoiding the obvious cases by closing scopes early etc but probably i have leaks all over the place ***smartin1 is now known as smartin
***sneek_ is now known as sneek
<lampilelo>yeah, it's a pain, most of the time putting stuff in { ... } is enough, the problems arise when you call scm_* and c++ functions interchangeably <lampilelo>lloda: the code i posted is incorrect, you shouldn't use it <lampilelo>i had a feeling something was wrong so i tested it <lampilelo>it will work only if you use it once per dynamic wind <lampilelo>i don't know how i thought it will work, it worked fine with my small library i wrote a while back but i called scm_dynwind_cpp_destroy once per dynwind, the problem is this thread_local variable stores only one lambda at a timem which will get replaced on every subsequent call, i don't have a solution right away <stis>aret here a concept of programmers spreadsheet? <stis>well consider constructing a spread sheet program ontop of guile, how should onw do that!! <stis>Basically a framwoke of tables that allow you to filter/sort/rearrange(take-sellections etc <daviwil>Hey folks! I'm using (web client)'s `http-post' function to make a request to an HTTPS endpoint. My understanding is that `#decode-body?' is `#t' by default but for some reason I still receive a bytevector as the response body that is returned. The `Content-Type' header is `application/json' so I'd imagine this should be interpreted as text. Any idea what I might be doing wrong? <daviwil>Passing the bytevector through `utf8->string' gives the desired result, so I suppose that's good enough for now! <ft>I think that only happens if the content-type makes text-content-type? return #t. <ft>So if you want to decode for other content-types too, you'll have to do it yourself, as you are. <ft>daviwil: text-content-type? is (or (string-prefix? "text/" type) (string-suffix? "/xml" type) (string-suffix? "+xml" type)) <daviid>lampilelo: how about using a tor friendly paste service, debian, gnome ... "Your IP has been blocked for violating the dpaste.com Terms of Service...' well, happy it did, your (dpaste.com) are violating my privacy ... <lampilelo>no problem, i chose dpaste because other people on #emacs use it, i thought it was alright <lampilelo>i don't think std::function allocates but i'm not sure <lampilelo>if it doesn't this should be a safe way to destroy c++ objects on non-local exits <RhodiumToad>daviid: paste sites are heavily abused by malware, it's not at all surprising that they would block anon access <lampilelo>hmm... now that i think about it std::function always has the same size, so it will probably store the data attached to it on the heap <dsmith-work>Someone was asking about http-request the other day. Did you ever get that figured out? ***sneek_ is now known as sneek
<lampilelo>switched to lambdas since they store everything inside