***32NAAD5PE is now known as xdje
<amz3>the server can't resolve my Ident and/or hostname <amz3>I'm writing something to wrap my ideas <amz3>I'm very happy, it's like grand discovery for me <amz3>2 days ago I though, that I was on an impossible trip to the north face <amz3>nalaginrut: I it working with telnet <amz3>nalaginrut: bot is here! <sepi>What's the ideomatic way to sum up the mapped elements of a list in scheme? <iyzsong>sepi: what is 'mapped'? I do the sum of elements of a list by '(reduce + 0 '(1 2 3)), it's from srfi-1. <sepi>iyzsong: I have a list (0 2 3) then map it with (lambda (x) (expt 2 (- x))) and then I want the sum of all <sepi>iyzsong: but reduce is what I was looking for <sepi>iyzsong: is there a nice scheme function reference online that includes srfis? <amz3>I find this sentence funny: 'delay: ... ready to be evaluated by a later force.' <sepi>amz3: ahh, that's very convenient. Thank you! <dsmith-work>wingo: Sorry to report that the lastest master has a make check failure on a 32bit system <dsmith-work>wingo: Forgot to mention it this morning. I'm not there now. <taylan>TL;DR: even if your hash table is weak-keyed, it should hold symbol, character, and number keys strongly, because they can be recreated at any time even if GC'd, so it's probably undesirable to have their association in a table ever dropped. <roelj>How can I capture the resulting XML of sxml->xml in a string? <davexunit>(call-with-output-string (lambda (port) (sxml->sxml sxml port))) <taylan>that might be better indeed. maybe there's other output. <davexunit>I just prefer this more explicit approach that doesn't use fluids <amz3>at last I know what fluids are :) <roelj>I'm screwing up on both given solutions <amz3>it's sxml->xml, not sxml->sxml <amz3>«you shall undestand what you copy/paste» the elders said ;) <wingo>ACTION generating assembly with luajit's dynasm. fun stuff! <davexunit>need to get all of luajit's goodness in guile :) <davexunit>unfortunately, guile's standard library doesn't include the convenient things that acme_tiny uses like base64 and sha256 hashes. <davexunit>does anyone else think that guile should either snarf the relevant modules from Industria (Expat licensed) or snarf the necessary C algorithms and write wrappers with libguile? <nalaginrut>it's so easy if we have good pkg-manager and repos, hmm... <nalaginrut>but anyway, we may use pipe to call base64/sha256 from shell <davexunit>it's *easy* to snarf the modules from industria <davexunit>but I think guile should include these commonly needed algorithms <davexunit>amz3: it's a cool R6RS library full of good crypto algorithms <davexunit>nalaginrut: the 200 lines was in reference to acme_tiny <amz3>maybe industria is the easiest to do <davexunit>it's so short because Python has built-in functions for these things <davexunit>python's rich standard library is something to copy <davexunit>the minimalists may disagree, but the minimalists probably don't like Guile anyway. <nalaginrut>and other modules, so it's related to pkg-manager and repos <davexunit>but I'm more interested in what guile provides out-of-the-box <nalaginrut>if we have good module management, we may keep minimalism as well <davexunit>python has a package manager, yet there's still tons of great stuff in the standard library <amz3>ACTION is late to the free certificate party #LetsEncrypt <davexunit>I'm not interested in a minimalist guile. I think guile should have as much good stuff packed into it as possible, within reason. <amz3>davexunit: I agree with you, the thing is that the release cycle of a language is different from the software <nalaginrut>well, maybe we should push SRFI further, or we should make a Guile standard lib spec <davexunit>guile in many ways already has a rich standard library <davexunit>web modules, all the SRFIs, texinfo, xml, ice-9 <nalaginrut>we all know that is not enough, guilers are so hungry for that ;-D <nalaginrut>anyway, it's great appreciated for all exist libs, or there won't be Artanis anyway, it takes advantage of many libs <amz3>not every project is like that <amz3>I think what we need is more guile package in guix <amz3>this is an easier life cycle for libs <amz3>I use only artanis so far <amz3>yes, I use also ice-9 json, but the project is not production at all <amz3>I mean, it's just a script of mine <amz3>I hear little complains myself about Guile. <amz3>but yeah it's missing some modules compare to Python stdlib <amz3>but this must be done step by step <amz3>I find the same thing missing in Python and Guile <amz3>something like wiredtiger, I eventually found it <amz3>and drawing bezier curves in 2D apps <amz3>which is now available in guile clutter <amz3>personnaly I have two aim: a) continue the project(s) I am interested in, without caring much about making Guile awesome b) blogging about it <amz3>there is 23 packages in let's encrypt! And i complain about guile-clutter x) <amz3>hey paron_remote I sent a write up about 8sync, about what I understand, etc... but it's not their yet. <paron_remote>amz3: btw should-read-char returning when it can't read is intentional <paron_remote>that's telling whether or not it should continue reading for now <paron_remote>since 8sync is non-blocking in the same event-loop when something has nothing to do it shouldn't wait <amz3>yeah, I finally understood the char-ready. <amz3>TIL: that (display text port) is different from (write text port) <amz3>paron_remote: I tried to look up the commits that implement schedule and queue in asyncio, but the history is truncated <amz3>the maintainer told me, it's an optmisation regarding the fact that some task/async-request can be cancelled <paron_remote>amz3: my plan for making cancelable events is to wrap them in a thunk that can be latter triggered to not run <paron_remote>so it'll still be hit by the scheduler if already scheduled <paron_remote>that requires no changes to the scheduler, and no complex questions of identity <amz3>at my last job we were using a pure python event loop, but it has using a single queue <amz3>paron_remote: I'm not sure of the purpose of cancelling events <amz3>I mean, I don't have a usecase <paron_remote>it can be handled entirely within the callback itself anywya <paron_remote>amz3: the callback being passed in. Imagine you did something like this: <paron_remote>(%8sync-run (lambda () (if should-still-run (primary-proc foo)))) <paron_remote>so presumably you can pass around some method for canceling it using that above <artyom-poptsov>It would be harder to do such things without amenability of Scheme. <davexunit>artyom-poptsov: now, can you write to that pipe? <mark_weaver>artyom-poptsov: there's actually a serious flaw in the 'open-pipe' API: it does not provide a way to close the write side of the pipe while leaving the read side open. <mark_weaver>and also, the method it uses to create a bidirectional port is very inefficient <mark_weaver>IMO, the best solution to these problems is to return two ports instead of a single port. <mark_weaver>although it might be better to return two values instead of a pair <artyom-poptsov>Hmm, I need to think about it. Currently a channel port works in both directions, no matter how it was created. 'open-remote-pipe' is no exception. <mark_weaver>I think the read and write sides of the connection should be different ports. <mark_weaver>unlike a file that's open for reading and writing, there is no fundamental relationship between the two sides of a pipe or socket. <artyom-poptsov>In case of Guile-SSH channels, you can switch a channel port between stdout and stderr. <davexunit>mark_weaver: don't you read/write from the same socket as well? <mark_weaver>davexunit: it's true that POSIX combines the read and write sides of a socket into a single file descriptor. however, I still maintain that there is no fundamental relationship between the two directions of a socket. <mark_weaver>operations on one side do not affect the state of the other side. <mark_weaver>in general, there will be a lot of machinery between the two directions of a socket or pipe, and the two data streams are not inherently related to each other <davexunit>I guess my comment was more about the Guile API <artyom-poptsov>I may be wrong, but to my understaning to separate input and output channels in case of pipes I'll need either to share a libssh channel object between two ports or wrap a channel in two Scheme ports somehow. <artyom-poptsov>Otherwise I won't be able to provide a procedure that will open and return both input and output pipe. <davexunit>sockets use a single port object, 'pipe' returns 2 ports <mark_weaver>artyom-poptsov: I guess the individual ports should refer to their shared channel object. <mark_weaver>having said all of this, a reasonable person might decide to combine the two sides of a socket or ssh channel into a single port, for the sake of consistency with the underlying C APIs. I think it's probably a mistake, but I can understand why someone would want to do it. <mark_weaver>however, there's a practical problem at the moment, namely that Guile does not provide a robust and efficient API for creating custom bidirectional ports. <mark_weaver>partly because there is no relevant scheme standard that provides this <artyom-poptsov>mark_weaver: I think if a channel is wrapped in a plain Scheme port, regular channel procedures won't work with it. <artyom-poptsov>On the other hand, if I arrange things in a such way that a libssh port will be shared between two channels, it'll likely lead to horrible side effects. <artyom-poptsov>mark_weaver: Indeed, your comments look reasonable to me, but the question is whether it is feasible with the existing API of the underlying libssh library. <artyom-poptsov>Anyways, thanks for input. Now I have some more food for thought. <mark_weaver>artyom-poptsov: I'm a bit confused by your comments, probably because you were sometimes using "channel" where you meant to write "port" and vice versa, and also my knowledge of SSH internals and the libssh API is very weak. <JohnnyonFlame>Hello. I tried reading the manual to understand how to trace calls, but I didn't quite get it. anyone got an example at hand? <mark_weaver>JohnnyonFlame: for example, type the following at the REPL: ,trace (map + '(1 2 3) '(4 5 6)) <artyom-poptsov>mark_weaver: Sorry, I messed up the terminology a bit. Currently there's one-to-one relationship between a libssh channel object in C world and a Guile-SSH channel object (a Guile port) in Scheme world. <JohnnyonFlame>mark_weaver, thanks. Is there any way to call it from -s? (im running it from bash, using #!<...>/guile -s) <mark_weaver>JohnnyonFlame: I would use 'load' to load the script from the REPL and then ,trace individual procedure calls to debug. <mark_weaver>JohnnyonFlame: 'call-with-trace' is the procedure underlying the ,trace REPL command <paron_remote>ACTION gave a demo of 8sync to ceo and employee of tech company he contracts with and they were super impressed <paron_remote>(ceo there is more technical than average ceo, was one of the primary Subversion authors) <paron_remote>though were worried when they heard that we're still waiting on tls proper in guile. We gotta get that in! :) <JohnnyonFlame>mark_weaver, "(display (call-with-trace read-token))" prints absolutely nothing <paron_remote>though barring that, once I get some web demos in there, they seemed like they might be interested in being early adopters for some smaller projects <daviid>paron_remote: do they use guile already? <paron_remote>daviid: the CEO has been interested in guile since the late 90s / early 2000s <daviid>but he is not using it yet right? I men for 'industry' usage <paron_remote>davexunit: yeah, I'm looking forward to your feedback :) <daviid>me too [need to try 8sync], and guile-ssh as well, but no time now :( <mark_weaver>JohnnyonFlame: this works for me: (call-with-trace (lambda () (map + '(1 2 3) '(4 5 6)))) <mark_weaver>no need to call 'display' on the result. call-with-trace prints the trace directly, it doesn't return a string. <JohnnyonFlame>oh. I'm not trying to print its return, I'm trying to simply trace read-token