<nisstyre>amz3: I looked into fibers briefly for something and it sounded like if I wanted to integrate it with C code, it wouldn't be appropriate <nisstyre>e.g. I wanted to do some GTK based stuff (webkit) in one thread <daviid>nisstyre: you should look at/possibly use guil-asunc2, it is the only library we have that integrates with the glib main-loop (gtk is single thrded by design) <daviid>fibers and 8sync are glib main loo 'unaware' <nisstyre>daviid: oh thank you, that might help a lot <nisstyre>daviid: can it do any sort of message passing / channels ? <daviid>"See the documentation mentioned below for further details, and the docs/example.scm and docs/example-glib.scm files" - so, docs/example-glib.scm will give you an idea <daviid>nisstyre: i'm not the author and don't use it, so i'll let other answer that queston ... <nisstyre>this sounds like it's exactly what I need <daviid>but it is the only async lib we have that you can use in the cotext of a glib main-loop <amz3>nisstyre: other ways: a) make fibers compatible with gtk event loop b) run fibers in another thread (channels can work across fibers and posix threads) <daviid>nisstyre: you can't make fibers 'compatible with glib main-loop' <daviid>unless the fibers author provide that of course, but i douvbt this wiil eve happen <soda__hobart>I'm trying to install guile-ncurses for guile-2.2 on Linux Mint and it is failing to compile--I get "Makefile:1042: recipe for target 'curses.go' failed" when I run make. <soda__hobart>any ideas? am I missing some dependency or something? It worked just fine on my Debian machine... <soda__hobart>is it because I have libncurses5? Do I need a newer one? I bet that's it. I remember seeing something about needing ncurses >= 6 <nisstyre>amz3: do you know of an example of using channels with pthreads? <amz3>nisstyre: mind the fact that is in pratice, as simple as sharing a channel between two threads. That is you can (define channel (make-channel)) then (call-with-new-thread (lambda () use-channel-here-probably-in-loop)) <amz3>soda__hobart: I think the missing "command" is `compile` <amz3>/bin/bash: compile: command not found <soda__hobart>but why's that one missing, I mean the C compiler is definitely there, haha! <amz3>soda__hobart: can you give me link to the sources of guile-ncurse I look around. <amz3>soda__hobart: compile might be defined as an alias in the autotools files... try to: grep -R compile . <amz3>soda__hobart: I have the same error, <amz3>soda__hobart: look into build_aux/compile <soda__hobart>hm, build_aux/compile looks like a shell script for parsing args and paths or something? I'm not real familiar with autotools. <amz3>soda__hobart: I found a fix <soda__hobart>oh yeah? What's the cause of the error? I'm on Linux Mint, but building guile-ncurses from source worked fine on my Debian machine. <amz3>really? yeah, it seems to work on guix too. any i have the problem with ubuntu. <amz3>soda__hobart: ./src/ncurses/Makefile:322:GUILD = /usr/bin/guild <amz3>soda__hobart: look at line 322 in ./src/ncurses/Makefile and add /usr/bin/guild after the '=' <amz3>soda__hobart: btw, you will be better prepared to code using guile if you install guix on top of mint. <amz3>soda__hobart: then re-run make <amz3>soda__hobart: I don't know what the proper fix is, but I successfuly compiled guile-ncurses <nisstyre>maybe closer to virtualenv, but still not really <amz3>soda__hobart: there is no equivalent in python. <amz3>soda__hobart: guix allows to install system dependencies. <nisstyre>also I don't think virtualenv or pipenv will do any sort of deduplication of dependencies <amz3>to some extend you can configure setup.py to compile .c or even maybe c++ libraries but that is not comparable to guix <amz3>guix is a superset of pip or pipenv <amz3>soda__hobart: also you should know that python packaging is broken... <nisstyre>the absolute worst is when projects will say `sudo pip install blah` <nisstyre>boto3 has that in their docs, and I opened an issue about it and they shrugged it off <amz3>nisstyre: sorry, there is worse than that. setup.py that execute 'sudo'. <nisstyre>actually it was awscli, not boto3 but yeah <amz3>I am not inventing that stuff. I wanted to build a dataset of python dependencies, so I ran thousands of setup.py via pipenv but the processus was crashing because some (among top20k packages) do sudo in setup.py <amz3>I was doing that in cloud vm. do not execute setup.py from non trusted sources. <amz3>my coworker in a previous $WORK were not happy by the fact that I was reviewing code of the dependencies we were relying on "wast of time" they said. The only problem is that even popular software can be hacked. <nisstyre>amz3: my first instinct when there's a problem with some third party code (that isn't trivially solvable from the documentation) is to grep through the source <nisstyre>that's how I was figuring out how to use the Guile C api actually <nisstyre>easier to read header files than search the web <amz3>true, it took me time to figure this. Similarly, man pages are very helpful. <nisstyre>also, don't ever read the source of Ansible, you'll cry <amz3>at last someone who agree with me. <nisstyre>I know at least one other person who agrees with me on that <amz3>I mean, I did not read ansible code, I just read their varaible scoping documentation. <nisstyre>and he basically rewrote the entire networking layer of ansible <amz3>when I see this kind of stuff supported by dozens of people, I loose hope. <nisstyre>I started an attempt to port it to Scheme, but lost interest <amz3>yeah, there guile-ssh now which can help <amz3>anyway, all this stuff i startup nation way of life. I dream in peer-to-peer nowadays. I think there is no point of having tools like fabric or ansible in p2p world. <nisstyre>amz3: actually part of my idea was that it would be possible to run code on multiple systems, and they would use some kind of system to communicate with each other, so you run code on system A, and it has a way to synchronize with system B <nisstyre>but that's more distributed and not really decentralized (like p2p) <nisstyre>I'm moving more towards the idea that decentralized by default is good <jcowan>Simple pipes-over-TCP are the basic mechanism for a nice and well-understood kind of distributed programming. <amz3>nisstyre: thanks for the link, I read some stuff about it, but I do not understand it very well for the time being. <amz3>nc is valuable anytime you network things. <amz3>nc is valuable anytime you +do+ network things. <jcowan>Capability-based security tl;dr: You can't take an action A on an object B unless you have an object capability(A, B). You can't create this capability yourself by default: someone has to explicitly give it to you and not revoke it. <jcowan>if you "own" B, you can hand out capabilities to people; if you only have a capability to do A on B, that may or may not allow you to hand that capability to someone else. <nisstyre>amz3: the most common example of that is unix file descriptors. Your process can't access file descriptors that it doesn't already own, but it can give them to other processes (via unix sockets), and then those processes can use them without needing to have the privileges of the other process <nisstyre>you can even have a process that can only read from a socket and no other files in theory, and then give it a set of fds for doing stuff through that <amz3>I was under the impression that passing fd to other processes was not "legal" <nisstyre>which would effectively limit it to only the files it needs to do its job <amz3>that prolly the part I was missing. <jcowan>Local domain sockets aren't Posix <amz3>I am not sure what to think of ocaps. So far, ACL, trust, auth et al. have been topics I luckily avoided. I read some stuff about it, even tried to imagine how things would / could work as part of my work on property graphs (graphdb) because ACL can become very complex in "entreprise" setting and normal acl approach do not work (afaiu) <jcowan>RBAC is much simpler than pure ACL to administer <jcowan>at $FORMER_EMPLOYER, the whole security state was written in Prolog (but executed by a bespoke engine, not a general Prolog engine) <jcowan>resources had hierarchical names, so granting action on a resource grants on the resources below it in the tree unless explicitly switched off <amz3>that is what I was thinking about. RBAC and also Prolog-kind of things. <jcowan>there were groups alongside roles <jcowan>the difference was that groups had a "distinguished member" such that if the rule compiler found that the distinguished member was no longer in fact a member, it was a compile-time fatal error. <jcowan>Roles were hierarchically named for convenience in creating them, but did not inherit <amz3>"compile-time fatal error" this is a way to speak, the system was computing access control every time, no? <jcowan>No, only when the rules were changed by a human being. <jcowan>I'm not sure what compiling actually did, maybe just wrote the rules into a secure "active place". <amz3>so it was like a mix of miniadapton and minikanren? <amz3>miniadapton, in the sense it was recomputing _only_ when rules changed. <jcowan>Just so, although it couldn't have compiled a rule for *every* resource, there were zillions of them <jcowan>but just having a skeleton hierarchy and having to figure out where a resource's pathname falls in it would be relatively little runtime computation. ***wingo_ is now known as wingo
<manumanumanu>Ahoy! My computer works again! No more editing SRFI drafts on SSH from my phone to my raspberry pi! <wingo>a funny thing, i was going to implement with-exception-handler and raise in core guile, but guile already has a raise binding, wrapping the syscall :P <wingo>raise-exception it is then :P