IRC channel logs


back to list of logs

<davexunit>paroneayea: I think you might like this:
<davexunit>added X clipboard support to my password manager
<davexunit>'shroud show -c cwebbers-goblin-lair password'
<nalaginrut>morning guilers~
***michel_mno_afk is now known as michel_mno
***michel_mno is now known as michel_mno_afk
***michel_mno_afk is now known as michel_mno
<amz3>hélle guile
<amz3>did anyone stumble upon a bug where `pointer->string' did not return correct, and instead returns only the first charcter?
<nalaginrut>amz3: if you're using stable-2.0, maybe it's encoding issue?
<amz3>ACTION trying guile-2.2
<amz3>There is python project following the same path as ijp's work on javascript output for guile
<amz3>called batavia
<amz3> #javascript #guile
<amz3>it translates the bytecode to javascript
<amz3>but it's slow compared to my translator
<amz3>probably fast enough for the kind of things we want to do
<amz3>back to guile and wiredtiger
<amz3>I tried with guile-2.2 and wiredtiger master it segfault
<amz3>I'll try stable wiredtiger
<ArneBab>did anyone hear from ijp?
<dsmith-w`>Morning Greetings, Guilers
***dsmith-w` is now known as dsmith-work
<paroneayea>davexunit: cool :)
<paroneayea>davexunit: (I still think you should look at the way assword does it, which doesn't require copying to an x clipboard or any copy paste (which is a good way to accidentally leak passwords imo): it types it into the other window using X apis!)
<davexunit>I didn't know about that
<davexunit>sounds difficult
<davexunit>why would (setlocale LC_ALL "") throw an invalid argument error on certain machines?
<paroneayea>davexunit: not too hard, uses xdo:
<davexunit>what is xdo?
<paroneayea>davexunit: libxdo is the library version of xdo, which is a "command line x11 automation tool"
<paroneayea>so, interacting with foreign x11 windows and etc
<mark_weaver>davexunit: if (setlocale LC_ALL "") throws an invalid argument error, I guess that the invalid argument has to do with the locale-specifying environment variable settings.
<davexunit>paroneayea: thanks
<davexunit>sneek: botsnack
***michel_mno is now known as michel_mno_afk
<paroneayea>ACTION thinks about "what would a standard event loop for guile look like"
<paroneayea>maybe something that uses the ffi + libevent would be a nice option.
<davexunit>I don't understand. there are many different types of event loops.
<davexunit>and libevent looks it is specifically for file system events
<paroneayea>davexunit: that's true re: many types... I mean something more like how asyncio in python gives you a ready to use event loop out of the box for python, and the advantage of having something standard-ish
<paroneayea>libevent I think is not just for file system events? I thought asyncio used it for its main loop and also used it for selecting on network events
<paroneayea>but I know very little
<paroneayea>also I may be wrong on that
<davexunit>okay so this wouldn't be a generic event loop, but rather one for sockets and file operations.
<paroneayea>it looks like it's flexible, it provides a standard interface, but different event loops can be dropped in
<davexunit>what's the use-case?
<paroneayea>davexunit: I was looking at the guile builtin webserver and I thiiiink it's a loop that adjusts how long it waits to poll from how long it was since the last number of events happened
<paroneayea>davexunit: and also thinking about writing a replacement for pumpio and etc, and how that uses the same loop for websockets as for a web server with nodejs
<davexunit>yeah, the guile web server uses a 'select' loop, IIRC.
<paroneayea>similarly having a standard event loop in python finally has meant that people are now working on ways to build their libraries so that operations can happen in an asynchronous fashion.... eg postgres/sqlalchemy asyncio drivers, etc
<paroneayea>that seems like a win
<paroneayea>(sidenote(sidenode?): I've also been looking at node code recently and thinking "I sure look forward to when coroutines are widely adopted in node...")
<davexunit>yeah perhaps
<davexunit>I'm unsure about async stuff
<davexunit>callbacks everywhere sucks
<davexunit>but you mentioned coroutiness
<davexunit>and that could certainly help make it viable
<paroneayea>yeah, asyncio uses coroutines everywhere and it's *nice*
<paroneayea>the main problem is a) libraries for it are still young and b) python doesn't come with builtin immutable structures other than tuples (there is a pyrsistent library, but it has a small userbase)
<paroneayea>but using it is quite pleasant
<davexunit>how can asyncio use coroutines?
<davexunit>I didn't python had them
<davexunit>didn't think*
<paroneayea>davexunit: python has had coroutines for a few years
<paroneayea>"yield from"
<paroneayea>there's about to be new, nicer syntax too
<paroneayea>davexunit: my actor model stuff in XUDD uses coroutines
<paroneayea>and writing code in it is super readable because of it
<paroneayea>davexunit: but anyway yeah, python totally has coroutines, main downside is that for a long time they kind of akwardly grew out of the same syntax as generators, but that's being cleaned up shortly
<davexunit>I will read that later, gotta go afk for a meeting
<davexunit>thanks for insight
<daviid>eXtra Universal Destruction Deity ? :) what's that paroneayea, a science fiction movie i missed?
<daviid>paroneayea: how do you compare xudd to the actor model/coroutines davexunit implemented [with help from mark iirc] for sly ?
<amz3>IIUC asyncio doesn't do filesystem, it's only network
<paroneayea>btw davexunit provides a nice breakdown of the main details of asyncio
<paroneayea>davexunit: the asyncio docs are... not great, but here:
<paroneayea>well they're good for reference, but there's no good tutorial
<amz3>I did a little script recently that fires subprocess asynchronously
<daviid>rotty1: have a g-wrap guile-clutter related quizz, hope you can help, at least giving some hint. clutter's manual recommand initialization like this:
<daviid>int main (int argc, char *argv[]) { ... if (clutter_init (&argc, &argv) != CLUTTER_INIT_SUCCESS) return 1; ... clutter_main (); return EXIT_SUCCESS; }
<paroneayea>davexunit: and you can also see this has lead to a lot of libraries being written recently to work with this consistent interface
<daviid>rotty1: however, our wrapper though just calls "clutter_init (NULL, NULL);\\n", which leads to warnings i'd like to solve this:
<daviid>guile-gnome-gw-clutter.c:8356:1: warning: ignoring return value of 'clutter_init', declared with attribute warn_unused_result [-Wunused-result] clutter_init (NULL, NULL);
<davexunit>paroneayea: what's the big craze around this stuff?
<daviid>rotty1: do i have to write a special wrapper or is there a way to pass &argc, &argv that is part of g-wrap?
<paroneayea>davexunit: well... it's useful in a system where you have a lot of protocols working together and you don't want any polling...
<amz3>there is three reason for asyncio: 1) need a standard, 2) don't need callback 3) greenlets is considered harmful
<paroneayea>greenlets in python are def harmful :)
<davexunit>I don't totally see the use-case yet, but maybe with time I will.
<amz3>it propose an imperative style to write asynchronous code...
<paroneayea>davexunit: I think the combining websocket code with http code is maybe a good use case in guile-land, today?
<davexunit>amz3: but specifically tailored to networking?
<paroneayea>anyway, eventlet / stackless are definitely the *wrong* way to go in python land IMO :)
<paroneayea>monkeypatching sockets to add async stuff to them? YUCK!
<amz3>davexunit: I don't know the networking part enough, I know only there is standard for building protocols
<paroneayea>or maybe that's gevent, I always get confused between stackless / gevent / eventlet
<paroneayea>davexunit: it also comes with a general purpose scheduler and etc though
<paroneayea>so that's nice
<amz3>in the following snippet I wait for three commands to complete before doing the sum of exit codes
<davexunit>gotta go
<amz3>doing this in callback is not very nice