<mark_weaver>wingo: hi! I'm around now, but I guess it's late for you. ***zxq9 is now known as _zxq9_
<wingo>sometimes i think the long-term portability story for guile is to have the bytecode interpreter be like risc-v or something <wingo>apart from other native backends <wingo>so the compiler pipeline always bottoms out to something with a limited number of registers <wleslie>I'm more than a little impressed that you're still on the register-vm path. did it make implementing your leaf-compiler easier? <wingo>it did make that compiler possible for me to write, mentally, but that compiler is bitrotten now <wingo>as the compiler has changed. oh well :) <wingo>there was a bit of a dialectic there, starting with the register vm let me make compost, which let me do type and range inference, which fed back into guile... <wleslie>I haven't had a look at your range inference, I kind of need to implement one too. <wleslie>have been working from 'multivariate chains of recurrences' <wingo>it's a fairly simple implementation; just solves a flow problem with intervals <wingo>would be nice to include more symbolic ranges like "always equal to the range of V" or "twice V" or whatever <wingo>i needed something absolute to be able to specialize scheme's numbers to int64 etc though <wleslie>right. it's a sufficiently different problem to mine (detecting affinity/relevance of vector items); especially given `x = xs[j]; ... xs[i] = x` <paroneayea>hey wingo, so does the wip-port-refactor branch take over the wip-ethreads eports stuff? <paroneayea>(and what does it mean for the epoll bit? I assume nothing on that one) <wingo>yeah i mean to respond on the ml <wingo>i think it will eventually take over the bits corresponding to the port implementation <wingo>i don't know how far up the stack to go though <paroneayea>wingo: cool, thanks (and sorry for pre-empting your reply on list) :) <wingo>i don't want to include a broken or ugly concurrency abstraction in guile <wingo>so while we can still hack up a thing and get it in, we have to be confident about it in some way <paroneayea>wingo: one advantage to having the actual event loop stuff externally, I've been thinking, is that's one thing that can remain in "alpha" experimental stage more easily than something in guile itself <wingo>my end goal is to expose port buffers to scheme, to allow scheme procedures to muck about in those buffers, and to allow the read/write procedures to also be implemented in scheme <paroneayea>because if it's in guile itself people will depend on th einterface <wingo>that would be the minimum to allow an existing function like a recursive descent parser built on read-char/peek-char to become suspendable <paroneayea>(I mean they will for the external one too, but that can release on a different schedule than guile) <wingo>also, to allow nonblocking read/write from those buffers <wingo>so, all those pieces. that's what i would like to have in guile 2.2.0. a scheduler etc can come later, even later in the 2.2.x series <wingo>i.e. within the stable branch <wingo>so it's still super-useful to work in parallel, to know what kind of abstractions we should have <wingo>and to have implementations of important pieces like schedulers, like sleep functions that suspend to the scheduler, etc <davexunit>my game engine uses a global scheduler + coroutines to do asyncrhonous tasks. <wingo>davexunit: with explicit suspends? <wingo>and no i/o i guess? or you assume that i/o doesn't block too long <davexunit>wingo: explicit suspends via a 'yield' procedure. 'wait', built on top of yield, suspends and puts "thread" in the scheduler. event loop ticks the scheduler at some interval. <davexunit>any i/o would block unless rewritten specially <wingo>for network services it would be pretty great <davexunit>anyway, just wanted to chime in that I have my own async programming system that my overlap a bit with what you're doing <wingo>i can imagine other possible systems for network services too <Jookia>are there any effects systems for guile, for limiting IO? <wingo>ACTION very ignorant about effects systems :) <Jookia>me too, but i come from haskell-land of safe DSLs <Jookia>a better question, is there a way to restrict myself to a subset of guile? <wingo>at the most basic level, capability limits in guile depend on the bindings available to a piece of code <davexunit>in general, I want to be as un-haskell as possible. <Jookia>like, aside from haskell being confusing <wingo>you can restrict the bindings available to a piece of code with modules i think is the story. not a great story but that's what's there :) <wingo>guile doesn't have much in the way of being able to grant access to certain capabilities only if larger static properties hold (the kind of properties a type system could enforce) <wingo>though again i guess you could introduce such operators; i hear people have implemented "eff" in guile <davexunit>Jookia: the age-old static vs. dynamic argument, basically. <Jookia>i'd like to write my own DSLs for stuff but i don't want code in the DSLs to be able to run non-whitelisted internal functions + modules <davexunit>I think trying to limit what code someone may write is a bad idea. <wingo>davexunit: i don't think so, to me this is firmly in the scheme tradition <wingo>e.g. rees's "security kernel based on the lambda calculus" <Jookia>I'm not sure how to write fault-tolerant/secure code if I can't limit what it can do <Jookia>For instance, client-side code being sent from a server <wingo>so there, you need to write an interpreter :) <Jookia>A guile interpreter written in guile? <wingo>if the code is written in guile, well... i dunno <Jookia>I wonder if there's any schemes that can do this <wingo>i usually define little languages if the interface is more narrow <wingo>often associated with limited state transitions etc <wingo>but if you (eval ...) code that comes across the wire, I don't think we have a great sandbox solution currently <Jookia>this isn't to say haskell solves this issue <wingo>there are pure modules to which you can only add safe bindings, there are some memory limits but they are less reliable than we would like, cpu time can be limited via timers etc but you'd have to ensure that the code inside couldn't prevent your timers from running... <wingo>and then the question of what is a safe binding is tricky, you have to be very careful <wingo>i've never implemented a sandbox. <Jookia>is there documentation on those features? <wingo>such as they are, yes -- but not organized in a nice way <wingo>but there is no standard sandbox implementation <wingo>in this regard racket is much better <Jookia>i wouldn't expect there to be, sandboxing is a complicated topic <wingo>they have a defined sandbox interface, semantics, implementation, etc <wingo>i try to steal from racket as often as i can ;) <Jookia>maybe it'd be nice to think about this <wingo>but for memory limits i think i need some help from gc, which I don't really have; and it gets tricky when passing objects between "ownership domains" or whatever <Jookia>well i don't really intend to run untrusted code <Jookia>untrusted code would get an OS sandbox <Jookia>it's more to ensure semantics of DSLs/code <Jookia>i'm not sure if this is more of a linting issue <Jookia>perhaps it'd be best to use a test suite that will flip out if semantics are broken by replacing underlying functions <wingo>if it's really dsl's, then consider defining that language in a more limited way and writing an interpreter for it. ymmv etc <Jookia>an interpreter? wouldn't that require a parser and other scheme stuff? <davexunit>evaluating arbitrary code from some random user is always a bad idea <davexunit>so yes, you need your own completely separate language <davexunit>I don't think it makes sense to attempt to take a language that can do anything and try to make it do nothing. <Jookia>is there an easy way to do that? <ijp>writing an interpreter is not really a big deal, you've probably done it a million times already and not called it that <Jookia>ijp: well, i haven't written a scheme parser or a macro system <ijp>e.g. the length function is an interpreter for lists <ijp>parsing isn't a big deal, you just call read, and process that <Jookia>ah, you mean like having something parse it to data then read it + eval stuff selectively? <ijp>macros are more interesting <Jookia>are there any tutorials on this? <ijp>wingo and davexunit are probably trying to get you to limit the language to the extent these wouldn't be included <ijp>certainly I would not recommend writing an expander. it's not as bad as writing a garbage collector, but it's up there <davexunit>I would just never expose a system that allows someone evaluate arbitrary code, but only arbitrary code that i like. <Jookia>davexunit: how do you define what you like? perhaps a web of trust? <ijp>assuming we are talking about a "reasonable" macro system. defmacro is stupidly simple to implement which is why people implement it <davexunit>people bring this up wrt to video game scripts <davexunit>they want some magical sandboxed safe place to evaluate aribtrary code from some rando on the internet <davexunit>isolation can be achieved by your operating system <ijp>except that people expect to be able to run arbitrary code, so they have to do what they can <wingo>ACTION doesn't like this answer :) 'operating system' is an abstraction that can exist on many levels <wingo>we should be able to create such abstractions inside guile <davexunit>I just don't like sandboxes. freedom or bust. <wingo>this from the guix environment --container person ;-) <ijp>I remember when I thought like that, back in noughts <ijp>I remember samth predicted my change of heart <wingo>samth is good at being right :) <davexunit>I've considered making an online guile repl for people to try stuff out. I would run client repls within new linux namespaces <wingo>ACTION terrified of linux namespaces <davexunit>arbitrary code evaluation without worry of exploitation <davexunit>I don't even know how guile could possibly enforce certain restrictions <davexunit>all sorts of operations require file system access <Jookia>i suppose solution is both? basic interpreter + trusted code for more <ijp>Jookia: so to summarise. We don't have a good sandboxing situation, although there are a few things which wingo mentioned. Maybe consider the OS to help sandbox. Maybe consider limiting your input, and "interpreting" it appropriately <davexunit>a random number generator could read from /dev/urandom <Jookia>and find what most people use untrusted code for, merge it, expose to interpreter <davexunit>I guess the sandbox just seems like reinventing the wheel, but hey this is Scheme after all, we do it all the time. <ijp>I don't trust myself to work on sandboxing, maybe mark_weaver :) <davexunit>but my pessism isn't productive, so nvm me. :) <davexunit>wingo: will you be talking about guile at polyconf? <Jookia>davexunit: I think you're right, actually. My time as modding was being mad at engine restrictions and hold I couldn't send clientside GUIs to people. But I've also heard other communities having issues with viruses. Maybe the solution is to have the engine/game be free and developed on modder's needs, and expose a way to send executable code that's trusted to clients. This way server admins get all they want with no limits, and a clientside GUI API in that ex <wingo>maybe a 2.2.0 release by then? who knows <davexunit>Jookia: I guess I have such an allergic reaction to this stuff because the same basic premise is used when people say that Guix has a bad design *because* we don't use a limited DSL, the exact thing we were trying to avoid. <davexunit>to them, their YAML is safe and simple and Guile is "too powerful" <ijp>YAML isn't that simple. it has two syntaxes for everything <Jookia>davexunit: I suppose it's clouded from bad experience for me where I use to mod without being able to modify the engine or client <davexunit>ijp: right, and not to mention that software in a similar space as Guix often *adds* things on top <paroneayea>wingo: Jookia: davexunit: yes I'm strongly interested in a Rees Thesis style capability system in Guile. <paroneayea>lexical scope as capabilities is still deeply appealing to me. <rain1>are you talking about SHILL? <rain1>I really wish we could have such a thing on linux <paroneayea>rain1: I'll queue it as a future thing to watch! <rain1>the seccomp setup you need to sandbox syscalls is reallly hairy <rain1>these guys hacked the freebsd kernel to support capabilities <rain1>ah that would be wonderful, i don't know anyting about hurd yet <jerryj>Can someone nudge me in the right direction? I'd like write an application that uses guile's interactive REPL -- right now I'm using scm_boot_guile(...) to successfully get the REPL going and register functions. Is it possible to extend the REPL commands, E.g. add a ',help <my-app>' command? <ArneBab_>this is what already works in the standard setup of the Hurd <rain1>this is so cool, i'll definitely keep an eye on Hurd for the future <rain1>I've really wished for the features time and time again on linux