<rlb>sneek: tell daviid that loop fails too after a while. <sneek>daviid, rlb says: that loop fails too after a while. <rlb>sneek: later tell daviid that loop fails too after a while. <zv>does anyonw know a good way to *just* run a termcap command? (without guile-ncurses) <zv>(e.g get the number of cols) <artyom-poptsov1>zv: Hi. I'd probably use 'open-input-pipe' from (ice-9 popen) for that. <zv>thanks artyom-poptsov1 , I ended up just looking at the guile repl source :) <zv>also, does anyone know why I'm getting "?" instead of ─ ? <zv>(thats a box drawing char) <zv>(it works just fine in the guile repl however ... ) <artyom-poptsov1>zv: My guess is that probably your program does not handle UTF-8 symbols right, Try to add '(setlocale LC_ALL "")' before you reading data from ports and let's see how it will go. <zv>artyom-poptsov1: add to where? <zv>ohh, I see, *run* (setlocal LC_ALL "") <artyom-poptsov1>I meant to say that you should try to add this to your Scheme program. <zv>artyom-poptsov1: I get an error, setlocal undefined <zv>artyom-poptsov1: oh wow, sorry, I deleted the 'e', thank you so much, that totally worked! <civodul>quite a bit of code "just" to get the number of columns, i admit <zv>also, since you guys are on, what is the name of the function for duplicating a character again? <zv>like (make-string \\#a 5) => "aaaaa" <zv>oh, holy shit, it's actually called "make-string" and it works exactly like that! <zv>thanks ft, I think I would rather use your library if possible <ft>zv: Don't know how to get terminal sizes with that, though. You may need to use the FFI to access tgetnum() from libtermcap for that. <ft>And then look for the li and co attributes. <rlb>depending on what you need. <rlb>ACTION wonders if sneek is on a break... <rlb>sneek: later tell daviid that loop fails too after a while. <rlb>I don't believe you now ;> <dsmith-work>rlb: Yeah, he is still around. Lives in a beaglebone black these daya <rlb>Nice - just seemed to forget my "later tell" from last night. <dsmith-work>I think it may have been to communicate with someone you has you on /ignore <rlb>oh, well I suppose a general "later tell" might be handy too. <rlb>I think it may "just run debian", but not sure. <rlb>as in, "without ceremony" <rlb>Right, but possibly OK for sneak-ish jobs. <rlb>Anyway, was somewhat just curious, but may not spend the time; we'll see. <dsmith-work>And I had reliabilty issues with using an SD card (sneek lived in one for a while) <rlb>you don't have to tell me twice - unfortunately familiar with their wireless chips... <dsmith-work>We have a dual PHY in one of our products. Never could get the LEDs to work right. Support from them is basically non-existant. Ugh. <sneek>Welcome back daviid, you have 2 messages. <sneek>daviid, rlb says: that loop fails too after a while. <sneek>daviid, rlb says: that loop fails too after a while. <daviid>ah, ok will try and let it run then <daviid>civodul: I've just push a series of [admin] patches to guile-lib, devel branch <daviid>if anyone has a bit of time, please checkout and run the autotool danse, make check [distcheck] pass here, for stable, 1 failure when using master <daviid>then unless egative feedback i will release monday or thuesday <daviid>rlb: indeed after a while it fails here too <daviid>FAIL: 00-repl-server.test: repl-server: simple expression - arguments: (expected-value "scheme@(repl-server)> $1 = 42\\n" actual-value "$1 = 42\\n") <paroneayea>> The ‘write!’ procedure must return an integer indicating the number of bytes actually written; when it is passed ‘0’ as the number of bytes to write, it should behave as though an end-of-file was sent to the byte sink. <paroneayea>I'm not sure how a write! procedure *should* act on custom-binary-output-port if it gets an end-of-file-object <wingo>flush the output if it's buffered i guess <wingo>or for terminals you can make it seem like it received C-d <wingo>anyway guile will never call the write function with zero as the argument i don't think <paroneayea>wingo: so I guess it wouldn't have any effect on a tls-wrapped tcp/ip port? <lloda>ice-9/format.scm:1525:37: In procedure format:fn-round: <lloda>ice-9/format.scm:1525:37: In procedure string-ref: Value out of range: 18446744073709551615 <lloda>I'm on 8622344a6b435f1e95cf3e84da3607ba3299cdf0, can anyone try the latest master? <amz3>hey lloda, so you also program in guile, I tho you were mainly a pypy hacker <amz3>what's up for the week end #guile? <amz3>I plan to advance the git bindings and maybe convert my stackoverflow offliner to guile <amz3>also I finally settled on not doing a do-it-all app wiht culturia, I will focus (for the time being) on building a solid search engine in a single node setting <amz3>sneek: what is culturia? <sneek>Someone once said culturia is a search engine for GNU system <amz3>the good news is that I still need to create a (good) web ui for managing the index <lloda>hi amz3, I not in pypy, that must be someone else. I've been a Guile user for 12 or 13 years <amz3>I am in dire need to code some frontend stuff, my day job doesn't deliver... <amz3>lloda: on what are you working on? <lloda>I use Guile at work, nothing public atm :-/ <amz3>OrangeShark: if you need some help regarding the design, let me know <amz3>lloda: it's under NDA? is something about math? <lloda>yeah, it's mostly numerical, FEM, that kind of thing <OrangeShark>amz3: alright :) I am not that great at design tbh. I should be able to take what you have so far and make it work <amz3>OrangeShark: I can work on a more white theme <lloda>I have published some generic libraries, but nothing 'topical' <lloda>if anyone could test (use-modules (ice-9 format)) (format #f "~2f" 9.95) on their Guile that would be great <lloda>I mean specifically about the subject I work on <OrangeShark>amz3: it is fine for now, we should focus on one design first and then we can easily add more themes <amz3>I am exicted that at last I can code and that I can code whatever I want but I can't focus... <amz3>obv. it's not on IRC that I will get focused but heh <OrangeShark>so many things I want to code but not enough time :( <amz3>right now, I hate google inbox, I hope there was an easy way out of this mess <amz3>actually, it might no be as difficult as I was thinking... <amz3>anyway, I need to stop piling up half backed project! <dsmith-work>wingo: Just curious: was all that recent async stuff for a specific problem, or just a general cleanup? <wingo>dsmith-work: good question and i don't really know <wingo>partly it is, i want to be able to point people to docs and not feel ashamed about it <wingo>part is that some things are just terrible and pre-2.2 is a good time to fix them <wingo>part is that i want to solve multicore scheduling in fibers in a nice way and i want to be able to rely on the primitives <wingo>i would also like guile to be preemption-ready <wingo>and that means adding support for async interrupts to the vm (i.e. don't recurse out of the vm) <wingo>and so i think that was what led me to start <wingo>but really for many years i have felt uneasy recommending people to do threading things in guile <wingo>partly because things have just accreted and there is no plan, no story, no design <wingo>so, a good thorough documentation-focused visit seemed the thing... <wingo>api-scheduling is still terrible but maybe i can implement srfi-18 in scheme only <wingo>so our core primitives can remain simple <wingo>and we can point people to other facilities for higher-level parallelism and concurrency constructs <wingo>i think we should consider threads, mutexes, conds, interrupts as primitives for building proper abstractions like futures, fibers/channels, etc <wingo>but we shouldn't recommend the primitives for user-focused needs <random-nick>will guile have a futex-like concurrency primitive or did you give up on that? <wingo>heh good q ;) i think no, not directly. a mutex is already at least a word so we can't have e.g. byte-sized mutexes. and, we want to be able to <wingo>interrupt an attempt to lock a mutex, which means we have to use some other strategy (in our case a lock and a cond) <wingo>at the same time we can make a webkit-like parking lot for waiting mutexes <wingo>but that would be a thing for the future <paroneayea>I'm recompiling guile 2.2 because I switched back to stable-2.0 to test some stuff, but I thiiiiink I have the tls stuff wrapped appropriately in a custom-binary-input/output-port <paroneayea>we'll find out when I have a working guile again :) <random-nick>wingo: but futexes can be used to implement primitives which guile does not have <wingo>random-nick: i'm sympathetic but my effort is focused towards fibers right now i think <dsmith-work>wingo: I think I agree that there needs to be better higher level interface. Working with threads feels like having to mess with carry bits. <dsmith-work>Like having to mess with loop index variables.. Better interfaces don't require mucking with the details. <rlb>Not that I'm advocating guile directly include anything specific, I will say that working with parallelism in clojure has provided a lot less drama than experiences with pthreads, etc. (I know, low bar...). Though some of that is due to java.util.concurrent's facilities (that are really easy to use). <rlb>(Just wrt java.util.concurrent, things like the countdown-latch, atomic-long, cyclic-barrier, ... are handy.) <rlb>a cyclic-barrier (CyclicBarrier) is just a way for multiple threads to meet up with each other at the "same point" repeatedly. <rlb>countdown-latch just lets you block any number of waiters until a certain number of calls to count-down, have been made, etc. <rlb>there are much fancier bits in concurrent, but those are some straighforward examples. <rlb>I imagine atomic-long is obvious, but I also imagine it's been designed to be able to be fast on "typical" architectures. <rlb>Of course clojure itself has a much more opinionated position with respect to concurrency, but the java classes can be taken as complementary. <rlb>wrt clojure itself, immutability by default, and bits like atoms, etc. help. <rlb>(with of course, attendant trade-offs) <rlb>wingo: I'm sure you're probably already well aware, but core.async is a "deal" (as an augmentation) as well. <tger>How do I send ctrl-d when in the debugger repl using Geiser? <rlb>might be more in line with your current direction. <wingo>i think i need to read that book doug lea wrote about concurrency <wingo>but yeah core.async is where i'm going with fibers <wingo>tricky bit is managing the multicore aspect -- i don't feel the need to solve that right now but i would like to have a story in mind <rlb>you thinking along the same "thread pool" lines? <wingo>right now fibers are effectively pinned to the core they start out on, though the impl supports multiple cores of fibers exchanging messages over channels, and channels are threadsafe <wingo>yeah, one scheduler per core <wingo>good for i/o-oriented concurrency <wingo>not so much for data parallelism of course <rlb>one issue with core.async is that there's no simple way (like there is in other parts of the jvm) to specify more localized pools to core.async, which may or may not be an issue when you starting thinking about a multi-tenant jvm (perhaps less an issue for guile). <rlb>yeah, thanks - I think I have an open tab for that (i.e. my reading list ;>) <rlb>I'm not super-experienced with core.async myself, but it's used in various places "around me" right now. <wingo>i wish i had more experience with these things. i get too much in the builder mode vs user mode sometimes :P <tger>,q is too long, and Geiser seem to shadow C-c C-d... <wingo>tger: C-c C-c or something? not sure. it's a general comint question <wingo>if geiser shadows C-c C-d that should be documented :) <rlb>wingo: I've worked on some clojure-esque bits for guile, but haven't finished anything enough to really talk about yet. <rlb>wingo: build for now on pfds. <wingo>tger: i break my guile too often to use geiser unfortunately :P <wingo>rlb: the new compiler is built on clojure-like data structures :) <wingo>with persistent and transient variants <wingo>that was last year's "wow" moment <wingo>this year's has been concurrent ml <wingo>i wonder what next will be :) <rlb>wingo: oh, I know, I've been blog-stalking you. <tger>on another note, what is guile's position vis-a-vis R7RS? <dsmith-work>tger: I think mark_weaver has a git repo with some guile r7 stuff in it. <tger>dsmith-work: OK, so it is endorsed somehow <dsmith-work>tger: ISTR some people saying that it's not possible to support both r6 and r7. There are conflicts. <dsmith-work>tger: I can't speak for the Guile devs, but I get the impression that there won't be much r7 support. <wingo>paroneayea: always be breakin' guile :) <wingo>dsmith-work: dunno, seems possible to me <wingo>we should add --r6rs to enable all the r6rs things <wingo>once people implement the r7rs bits anyway <tger>could even use the --language option perhaps <tger>r7rs seems based on SRFI:s so should probably be easy once r7rs small is in place <wingo>there are some syntactic differences (read/write options) <wingo>so people will want a global setting <rlb>civodul, mark_weaver: fwiw looks like daviid can reproduce that repl-server test failure too after running the loop for a while. <paroneayea>YAY, ok, I got HTTPS stuff working using the wrapped custom-binary-input/output-port ! <civodul>i'm trying to see how the "scheme@(repl-server)>" string could be missing from what's read <paroneayea>weirdly I'm able to get it to work with guile-next from guix like "guix environment --ad-hoc gnutls-with-guile-next guile-next", but I can't yet figure out how to get the guile I built myself to be able to import gnutls <paroneayea>but... using geiser I'm able to compile the client.scm using the guile-next from guix and verify that it's working there <rlb>civodul: yeah, I haven't delved deeply yet, but it did seem odd. As I may have mentioned, I found that adding a sleep-for 2 before the (proc client-socket) made the problem unreproducible. <rlb>civodul: I tried that because I wondered if there was a chance that the client was reading "too soon", but still can't really provide a reason why that should produce those results atm. <civodul>i found a way to make it faster to reproduce :-) ***dcs is now known as Guest56182
<paroneayea>that way my guile load path would have 2.2 in it :) <wingo>civodul: so you think making srfi-18 mutexes, condition vars, and threads disjoint from guile primitives of the same name is ok? <wingo>if so i can implement srfi-18 entirely in scheme <civodul>wingo: the choice is between dropping support for "weird" srfi-18 semantics and using disjoint types, right? <zv>does anyone know if there are methods for folding over alists/hts that have a signature of (lambda (key value))? <rlb>Without knowing much about the real issues - wonder if there might also be a possibility of efficient, mostly-srfi-18 types, and then perhaps later, disjoint fully-serfi-18 types that are added if/when there's demand? <rlb>People who really want the latter can use those and pay the price. <wingo>rlb: i think people wanting to take advantage of guile whatever will be fine using just guile interfaces; people wanting standard interfaces will always want to pay the price <wingo>the perf price is low, it's just an interoperability price <wingo>which i suspect both sides are willing to pay, but i dunno <paroneayea>I don't know enough to give a super informed opinion, but implementing more interfaces in guile *sounds* like a worthwhile price to pay... <rlb>wingo: I think mostly I'd just like to have *some* way to write things that are as efficient as is reasonable in guile, even if it's guile specific, whatever else is available. <rlb>That said, I spend a good chunk of time on a python project these days, and get by, and I suspect guile's likely to remain much better on that front, regardless. <civodul>wingo: so yes, probably best to have a "standard-compliant" srfi-18, at the cost of making it disjoint from the rest of Guile <civodul>none is ideal obviously, but we don't have much of a choice <civodul>rlb: there's no open bug for 00-repl-server.test, right? <rlb>or rather, reporting to bug-guile created one. <civodul>hmm i can't find it in M-x debbugs-gnu <civodul>and i only have private messages from you <wingo>well we could keep what we have <wingo>which is gnarly complicated but compliant and not disjoint <wingo>i am willing to pay instead for simple and disjoint <rlb>civodul: #24819 I think? <civodul>yes, simpler core mutexes sounds like a worthy goal <civodul>rlb: ooh indeed, but it shows up with a different author <rlb>civodul: I merged it with another report. <rlb>civodul: and excellent - thanks much. Hopefully I can get that into sid this weekend and we can get 2.0.13 into stretch soon. <spk121>ft: I never noticed the termios lib before. Cool stuff.