IRC channel logs

2015-12-04.log

back to list of logs

***32NAAD5PE is now known as xdje
<nalaginrut>amz3: what error did you encounter? ;-)
<amz3>the server can't resolve my Ident and/or hostname
<amz3>I'm writing something to wrap my ideas
<amz3>request feedback
<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>etc... ;)
<nalaginrut>amz3: is it solved now?
<amz3>nalaginrut: I it working with telnet
<amz3>héllo btw :)
<nalaginrut>nice
<amz3>héllo nl2
<amz3>nalaginrut: bot is here!
<amz3>but is mute
<amz3>bye bye nl2
<nalaginrut>hmm
<turbopape>morning !
<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: thanks!
<iyzsong>sepi: you're welcome :-)
<sepi>iyzsong: is there a nice scheme function reference online that includes srfis?
<iyzsong>sepi: it seems the Guile manual have some documented parts of srfis, the full is on http://srfi.schemers.org.
<sepi>iyzsong: thanks!
<amz3> https://www.gnu.org/software/guile/manual/html_node/Procedure-Index.html
<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>Happy Friday, Guilers!!
<davexunit>happy friday!
<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.
<dsmith-work>something to do wih hash statistics?
<wingo>i wonder what that would be
<taylan>I'd love some input on http://srfi-email.schemers.org/srfi-126/msg/3160609 from anyone who has experience implementing weak references (e.g. in hash tables)
<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?
<taylan>roelj: with-output-to-string
<davexunit>(call-with-output-string (lambda (port) (sxml->sxml sxml port)))
<taylan>that might be better indeed. maybe there's other output.
<davexunit>your way works too
<davexunit>I just prefer this more explicit approach that doesn't use fluids
<amz3>at last I know what fluids are :)
<amz3>next step parameters
<amz3>i guess
<roelj>Thanks
<roelj>I'm screwing up on both given solutions
<amz3>it's sxml->xml, not sxml->sxml
<roelj>Yeah, that works
<roelj>Thanks
<amz3>«you shall undestand what you copy/paste» the elders said ;)
<davexunit>sorry for typos
<dsmith-work>wingo: Sorry for the lame "it don't work" report.
<wingo>np :)
<wingo>ACTION generating assembly with luajit's dynasm. fun stuff!
<davexunit>neat
<davexunit>need to get all of luajit's goodness in guile :)
<davexunit>so, I found this Let's Encrypt client written in ~200 lines of Python https://github.com/diafygi/acme-tiny/blob/master/acme_tiny.py
<davexunit>would be great to have a guile port
<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>that's orthogonal to this point
<davexunit>it's *easy* to snarf the modules from industria
<davexunit>no problem there.
<davexunit>but I think guile should include these commonly needed algorithms
<nalaginrut>yes, but we can't do it in 200 lines ;-)
<amz3>what is industria?
<nalaginrut>oh, you should know it, as a Schemer
<amz3>(:
<amz3>got it
<davexunit>amz3: it's a cool R6RS library full of good crypto algorithms
<davexunit>pure Scheme
<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>IMO
<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>that stuff is good, too
<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
<amz3>+1 GSLS
<davexunit>guile in many ways already has a rich standard library
<davexunit>web modules, all the SRFIs, texinfo, xml, ice-9
<davexunit>we just need more :)
<amz3>imap/smtp/pop3
<amz3>irc
<nalaginrut>we all know that is not enough, guilers are so hungry for that ;-D
<amz3>for what?
<nalaginrut>for more modules
<nalaginrut>or you may call it libs
<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
<davexunit>there's already a bunch
<amz3>this is an easier life cycle for libs
<davexunit>all of the ones I use are there
<amz3>yes, but always more!
<amz3>which one do you use?
<amz3>I use only artanis so far
<nalaginrut>amz3: then you use many of them as well ;-)
<amz3>yes, I use also ice-9 json, but the project is not production at all
<nalaginrut>they're integrated in Artanis for easier life
<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
<paron_remote>hello *
<amz3>hi!
<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.
<amz3>s/their/there
<paron_remote>hey amz3, interested in reading it :)
<paron_remote>amz3: btw should-read-char returning when it can't read is intentional
<paron_remote>in irc.scm
<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
<amz3>something like that
<paron_remote>amz3: ah
<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>but will become a no-op
<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>amz3: I think generally it's not needed in most cases
<paron_remote>and thus it shouldn't be built into the scheduler
<paron_remote>it can be handled entirely within the callback itself anywya
<paron_remote>so might as well do it there
<amz3>which callback
<amz3>?
<paron_remote>amz3: the callback being passed in. Imagine you did something like this:
<paron_remote>sorry, got distracted
<paron_remote>(define should-still-run #t)
<paron_remote>(%8sync-run (lambda () (if should-still-run (primary-proc foo))))
<paron_remote>then you can do
<paron_remote>(set! should-still-run #f)
<paron_remote>actually with 8sync it's easier than what I did
<paron_remote>(%8sync-run (if should-still-run (primary-proc foo)))
<paron_remote>since it already wraps it in a thunk
<paron_remote>so presumably you can pass around some method for canceling it using that above
<artyom-poptsov>Hello Guilers.
<artyom-poptsov>Got remote pipes working in Guile-SSH; now, for example, I can read 'top' output from a remote machine in my Scheme program: https://gist.github.com/artyom-poptsov/bfdf3acb5cc453c14cd5
<davexunit>artyom-poptsov: that's awesome!
<artyom-poptsov>davexunit: Thanks.
<artyom-poptsov>And the code is pretty compact and clean, which is nice.
<davexunit>double goodness :)
<daviid>artyom-poptsov: super!
<artyom-poptsov>:-)
<artyom-poptsov>It would be harder to do such things without amenability of Scheme.
<davexunit>artyom-poptsov: now, can you write to that pipe?
<artyom-poptsov>Yes, it works in both directions.
<davexunit>awesome
<artyom-poptsov>Thanks to libssh.
<artyom-poptsov>I tried to make API similar to 'open-pipe' from (ice-9 popen).
<davexunit>yeah I noticed that. very nice. :)
<artyom-poptsov>Indeed, I'm learning to make APIs from good examples.
<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>like 'pipe' does
<mark_weaver>although it might be better to return two values instead of a pair
<davexunit>yeah, I prefer multiple return values
<davexunit>I wonder how the pipe API can be fixed :/
<davexunit>it's important
<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.
<paron_remote>mark_weaver: it also doesn't return error ports right?
<mark_weaver>paron_remote: indeed, it does not.
<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>you can close one side without closing the other
<mark_weaver>operations on one side do not affect the state of the other side.
<davexunit>mark_weaver: yes, that's true.
<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.
<davexunit>it's one of those API consistency things
<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>Because changes on one Scheme channel will affect another one.
<artyom-poptsov>s/libssh port/libssh channel/
<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.
<mark_weaver>but anyway, use your best judgment :)
<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>or you could trace the 'load' call itself.
<mark_weaver>anyway, I have to go afk now. good luck!
<JohnnyonFlame>ty
<mark_weaver>JohnnyonFlame: 'call-with-trace' is the procedure underlying the ,trace REPL command
<paron_remote>o/
<paron_remote>ACTION gave a demo of 8sync to ceo and employee of tech company he contracts with and they were super impressed
<daviid>paron_remote: fantastic!
<paron_remote>(ceo there is more technical than average ceo, was one of the primary Subversion authors)
<paron_remote>they asked how soon they could use it
<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
<paron_remote>is friends with one of the former guile maintainers
<paron_remote>(jim blandy)
<daviid>but he is not using it yet right? I men for 'industry' usage
<paron_remote>daviid: corect, not yet, is just interested
<davexunit>paron_remote: cool!
<davexunit>I still need to try out 8sync
<paron_remote>davexunit: yeah, I'm looking forward to your feedback :)
<paron_remote>speaking of, time to work on a little web demo in it
<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))))
<JohnnyonFlame>mark_weaver, weird... for me it prints nothing
<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
<mark_weaver>sorry, now I really need to go afk for a while.
<JohnnyonFlame>alrite, thanks a bunch
<daviid>i fixed guile-gnome's webpages because it does not work if compiled using gcc >= 5.0 https://www.gnu.org/software/guile-gnome/download.html do you think it is clear enough ? Or should I also add the symptom of a failure if it was cmpiled against gcc >= 5.0 ?
<daviid>dito Guile-Clutter, here: https://www.gnu.org/software/guile-gnome/clutter/download.html