<amz3>ArneBab: do you know which day the talks will happen? ***Guest76271 is now known as mikey
<artyom-poptsov>nalaginrut: By no reason aside from an insignificant fact that your name is mentioned in the copyright notices around Guile-PG sources. ;-) <nalaginrut>artyom-poptsov: oh, I believe I never get involved in this project, maybe they made some mistake ;-) <nalaginrut>artyom-poptsov: I don't see my name there, or maybe you didn't mean that? <nalaginrut>artyom-poptsov: anyway, guile-ssh is cool for me, thanks for working on it ;-) <wingo>ACTION landed unboxed u64 values <wingo>for some workloads it will be a speedup, for some a slowdown <wingo>but when we do native compilation it will never be a slowdown <rekado>are there some options I can pass to xml->sxml to make it deal with HTML (e.g. unclosed img tags)? <amz3>I don't think so, I use a snippet from haunt <amz3>I know about sxml->html only <rekado>yeah, I just noticed that haunt doesn't seem to have html->sxml. <wingo>tfw when you accidentally make clean :/ <rekado>wingo: thanks. That's in guile-lib? <rekado>bleh, I get a VM stack overflow trying to run an sxpath query over the large SXML. <rekado>this is enough to cause a stack overflow: ((sxpath '(// a)) sxml) <rekado>an explicit query like ((sxpath '(html body table tr)) sxml) works fine, but as soon as I go one level deeper I get a stack overflow. <wingo>on master you wouldn't get a stack overflow :) <wingo>but it could be that something isn't compiled in a good way <rekado>installing 2.1.1 via guile-next on Guix. <rekado>hmm, can't use 2.1.1. When I send expressions to the REPL via Geiser I get "ERROR: no such language objcode" <rekado>if I paste the expression directly I get a compilation error: ERROR: In procedure load-thunk-from-memory: not an ELF file <rekado>probably need to recompile all my modules. <wingo>yeah geiser doesn't work with master <rekado>back to regular expressions then... <amz3>wingo: do you know what the fix for geiser should be? <wingo>amz3: mostly. it needs to compile to 'bytecode instead of 'objcode and then use load-thunk-from-memory instead of objcode->program or whatever it's doing now <wingo>there might be more things, i don't know. <wingo>but that's the big one. more generally it should know whether it's working with guile 2.0 or 2.2 and be able to do different things. <wingo>rekado: the second error you give, is it because you installed guile-lib from guix and it was compiled against 2.0 ? <wingo>or if you installed guile-lib from git it sounds like you built it with guile 2.0 <davexunit>ACTION wrote a good start to guile-websocket's test suite <wingo>davexunit: i landed unboxed u64 values :) <davexunit>now if only geiser cooperated with 2.1.1 I could have more fun trying it out <davexunit>I filed a bug report since no one else has yet <wingo>the fix is not difficult to make, you just have to make geiser ask guile what version it is, and use load-thunk-from-objcode on the result of compiling to 'bytecode instead of 'objcode <davexunit>I threw in an excerpt from the channel logs about that <wingo>he might not feel like building 2.1.1 ;) <davexunit>I've poked around at almost all levels of guile hackery, I'm not afraid to dive into some elisp. <davexunit>artyom-poptsov: I may have asked you this before, but is it possible to read/write to a remote unix domain socket via ssh without explicit support for it from the server? <wingo>does redirecting input and output to a cat process on the file work? <davexunit>wingo: perhaps! I'll have to fumble around with it <davexunit>I'm still in that "I have no idea what I'm doing" phase :) <davexunit>I'm also drawn towards spending time on other projects like guile-websocket, not sure when I'll get around to the ssh stuff <wingo>so i am thinking of releasing a 2.1.2 sometime soonish, with the unboxing bits, once i document them <davexunit>I think websockets would be good to include in guile core, if it's actually any good. <wingo>just saying, in case anyone wants to commit to master, it will be released soon <wingo>davexunit: what is the relationship between websockets and http2 <wingo>doesn't http2 allow you to do similar things? <davexunit>well, http2 may effectively deprecates websockets <davexunit>but http2 will take quite some time to be ubiquitous <davexunit>but maybe it's not worth putting something with a limited lifespan in guile core, and maybe it's not worth me investing so much time in it. <wingo>yeah i dunno either, could go either way <wingo>so, another question :) guildhall has failed in a way <wingo>guix is more like what we should have and already solves the problem in a good way <wingo>is there a sensible way for guix to package guile modules, I wonder? <davexunit>with the caveat that OS X and BSD users cannot use it. <wingo>especially in a way that can work on systems that don't run guix <wingo>so i wonder whether there is a way to re-use guix things to make a better package manager for guile <davexunit>guildhall may still be worth it for this reason <wingo>perhaps with a different package root <davexunit>guix requires bootstrap binaries for each platform and architecture <davexunit>if we remove that, then we have to use utils from the host, and then we have guildhall. <wingo>i think it's reasonable to configure a guixhall to be --with-guile or something <wingo>so the base guile is out of the guix world <wingo>and only the "extra" modules are managed by guixhall <wingo>so there is no bootstrapping <davexunit>interested to see if someone can come up with something that works well enough <wingo>would be nice to be able to install extensions that need C libs :/ <wingo>that's what using full guix gives you, among other things <wingo>so an intermediate solution is a bit wonky <wingo>otoh guildhall explicitly limits itself to just guile modules <wingo>so a guixhall wouldn't need e.g. a c compiler, if it limited itself to the same scope <wingo>anyway it would be good if there were a nice answer that didn't make you feel like core was the right place for a websocket module <wingo>as it is i understand the feeling and i'm not against incorporating modules like that <davexunit>wingo: I guess I'm of the feeling that most cool stuff should get included in the core like emacs does <wingo>but that's just an opinion :) <davexunit>but as it is, I write my own third-party things and drop a 'guix.scm' file in the root of the source tree <davexunit>so guix folks can install git snapshots easily <davexunit>it might be best to just port Guix to the BSDs. <wingo>is there a bug open with the issues? ***xdje is now known as 32NAAD5PE
<artyom-poptsov>davexunit: OpenSSH supports forwarding of Unix sockets since version 6.7, if I'm not mistaken. <artyom-poptsov>That was my answer when you asked me the question some time ago. <davexunit>artyom-poptsov: problem is that there's more than openssh out there <davexunit>guixsd systems, the ones I want to work with, use GNU lsh typically <davexunit>so I was hoping there was something I could throw together that would work regardless of the server. <davexunit>like opening a guile process that can pipe the input from the ssh connection into the socket <davexunit>my guess is that process spawned by ssh would have its STDIN be the data coming over the ssh connection <artyom-poptsov>You could write a Scheme program that will pipe input from a local port into the Unix socket of guixsd. <artyom-poptsov>So you would have a process on a remote GuixSD host that listens a local port, and forward local connections to that port. <davexunit>is there a way to do this more automatically? <davexunit>I'd like the client program to be able to spawn the process <davexunit>I think I was confused by ssh in this regard before <artyom-poptsov>Sadly I have no complete answer to your question, haven't tried to implement that kind of functionality in Guile-SSH yet. <artyom-poptsov>You could transfer your forwarding program to the remote host using SFTP, for example. <artyom-poptsov>Or just execute some Scheme code that will forward your connections using 'with-ssh'. <davexunit>the pipe would only be a few lines of scheme <davexunit>and guile-ssh would give me a port object to work with <davexunit>from which I can create a guix daemon connection object <artyom-poptsov>All you'll need is to make sure that the spawned process won't be killed when 'with-ssh' exits. <davexunit>it would keep polling the file descriptor for more stuff to read <artyom-poptsov>It creates a new process group for which the process called 'setsid' becomes the leader. <artyom-poptsov>So the calling process will be effectively detached from a controlling terminal if it has one and won't stop when the parent process stop. <artyom-poptsov>Whant I mean is that you may want to deamonize the spawned process. <davexunit>GuixSD badly needs a NixOps equivalent, and guile-ssh is the perfect building block <davexunit>the distributed computing features will especially come in handy <amz3>immutable infrastructure through immutable code :) <amz3>I stumbled upon this term recently "immutable infrastructure" <amz3>the other interesting term is "infrastructure as code" <davexunit>"immutable infrastructure" seems to mean "throw the VM out when you make a change and build it again" <davexunit>because config management systems are all garbage. <amz3>immutable infrastructure means you can rollback to a previous version, with dependencies all setup <amz3>davexunit: at least from imperative people the VM are not rebuilt, they are stored <amz3>seems like tangled code to me, but I never dealt with it yet <davexunit>I think they are doing immutability at the wrong level to work around the lack of functional package/config management <unknown_lamer>davexunit: hey, propeller is pretty good config management ;) <unknown_lamer>I wish I had the mental capacity to transform domtool into something more useful too <davexunit>but propellor is still working within crazy Debian/Red Hat land. <unknown_lamer>if only I had realized the "competition" wasn't really any better when domtool was new... <amz3>guile-vm can host static languages? <unknown_lamer>t like the whole use a vm template and throw it away thing... <amz3>nalaginrut: I tried to port my nanoblog project to artanis, but failed at step 0 <amz3>nalaginrut: guile states that there is a syntax error with a macro I wrote <amz3>nalaginrut: but it works fine in my code without artanis :/ <amz3>I'm not sure how you can help. I'll paste the error <amz3>I don't think it's related to wiredtiger <amz3>when I comment the procedures that contains query* it works <amz3>It doesn't seem related to artanis actually <nalaginrut>amz3: if you use `match', I recommend you not use `else' but `_' for non-matching, this seems unreasonable and maybe a bug of (ice-9 match) <amz3>right now I only pasted the code from hypermove.scm in a nanoblog.scm file with artanis imports and server init and I (run) the server <amz3>I call match in the handler of the old guile server <amz3>if I comment it it continue to fail <amz3>how is this related to match? <amz3>I checked the fluid id, it's not mine <amz3>I mean it's not the fluid id I use, I don't know what it is <nalaginrut>hmm...but you haven't used any thing from Artanis, right? could you remove (init-server) <nalaginrut>amz3: seems may people dropped, are you still here? <amz3>yeah, that's what I've read <amz3>not sure why it's a target <nalaginrut>amz3: could you try to remove (init-server) then run it <amz3>nalaginrut: it doesn't do, but when I remove everything artanis it works <amz3>nalaginrut: do you define a query* macro? <amz3>I should have checked all that <amz3>there is not query* in your code <nalaginrut>how about just import artanis but use nothing from it <nalaginrut>amz3: could you try it in REPL, and paste a backtrace <nalaginrut>and btw2, I've encountered macro expanding bug in 2.1 before, but that bug is fixed now <amz3>because I use :where instead <nalaginrut>I thought you import artanis with a prefix, that's another approach <amz3>I replaced in the macro the extra keyword where by :where and updated the code properly <amz3>nalaginrut: good night thanks :) <amz3>now I can use artanis :) <amz3>nalaginrut: since you don't want to sleep for the real, does the cookie support works ?... <amz3>it's not covered in the tutorial <wingo>you'll have to do the make clean dance <roelj>Is there a database module I can use with Guile? (I'm most interested in PostgreSQL and/or SQLite) <paroneayea>there's also guile-squee but honestly it's pretty young <davexunit>it will be the preferred way to use postgresql from guile <roelj>Sorry for asking, but what is so bad about writing parts of Guile modules in C? <davexunit>they are harder to hack on and harder to install <davexunit>if you want to change a part of a C extension, you have to stop the program and recompile <roelj>Alright.. So instead you write wrapper functions in Guile to work with an existing C API? <davexunit>as opposed to writing wrapper functions in C to work with an existing C API <dsmith-work>And when (not if!) Guile has a native-machine compiler, it may be faster as well. <wingo>the thing for me is that having a significant part of your program in c means you have an unnatural discontinuity in your program <roelj>Yes, I can understand the feeling of an 'unnatural discontinuity'. <wingo>roelj: there is a cost for going back and forth between guile and c. if the c wrapper calls a scheme procedure for whatever reason, <wingo>that will be slower than if the wrapper were written in scheme <roelj>wingo: But I don't think a wrapper written in C should ever need to call a Scheme function. <artyom-poptsov>roelj: I needed such calls to implement callbacks that an underlying C library uses. <wingo>a lot of my code ends up needing to do that, it could be your libs are different <roelj>The reason I started writing stuff in Guile is because I knew that when I couldn't get something done quickly enough, I could write a C function instead (which I'm used to). I really think that is a great feature of Guile.. <dsmith-work>roelj: There are other reasons too. The compiler might be able to pass in native types, but the C wrapper will always need to convert from SCM -> C -> SCM. <wingo>dsmith-work: i think for the forseeable future, the calling convention in compiled scheme code will always be tagged values (SCM values) <wingo>maybe for well-known procedures we can relax that... <wingo>dsmith-work: that sounds unlikely to me fwiw <wingo>the one thing that we can do is have optimized calling conventions for primitives <wingo>well, it's not a bad idea :) <wingo>roelj: another way guile can be faster is because it can allocate off of a freelist that's closer to hand, so to speak <dsmith-work>wingo: make check is happy at work BTW (64bit 4-core) <roelj>But how do Guile primitives get processed by a processor? <wingo>using scm_gc_malloc et al will get to a freelist via a thread-local variable <wingo>roelj: not sure i understand your question, but i am getting sleepy, so talk to you tomorrow :) <roelj>wingo: Ok, sorry :) See you tomorrow <paroneayea>basically racket redid the way they did hygiene, theoretically making it conceptually cleaner <paroneayea>I don't know if it actually is or not, but thought you might find it inetersting