IRC channel logs
2016-01-16.log
back to list of logs
<zacts>you are learning guile scheme? <bambams>zacts: I'm trying to. :) Just another attempt at becoming practical with a Lisp. :\\ <davexunit>yay, my syntax highlighter works acceptably again. <amz3>I'm reading my article about sfx, it looks as if I did not write the thing <amz3>I don't manage to explain how it works actually <amz3>among other things, there is sentences like: <amz3>«Instead of requiring the nesting of (attribute-name attribute-value) sfx use the char short syntax :keyword to write keywords and use that to visually cue to read attribute names and attribute values.» <amz3>At the very core, sfx template is an abstraction between django or rail templates and templating via plain sxml and quote/unquote <davexunit>weee now I have a decent enough C syntax highlighter. <zPlus>hi everyone (from a Guile novice)! I'm interested to know if Guile could be used for an interprocess (local machine specifically) RPC mechanism. Briefly, I'm making a C service and I would like an arbitrary client application (not written by me, and in any language) to call routines implemented by my service, and receive results asynchronously. I thought that applications could perhaps "import"(?) a Guile file, that they can use to call remote routines and <zPlus>get results. The idea is that if this were possible, every language with a Guile lib could easily connect to my service... but as I said I'm new to Guile, so I'm not even sure if my question makes sense :) <davexunit>zPlus: Guile is very general-purpose, so I think it could do what you want. <davexunit>though I'm not exactly sure where you think Guile would fit in. <amz3>zPlus: you want to expose your library over RPC using Guile? <zPlus>davexunit: just to get a better understanding of Guile, can I think of it as "an interpreted language such as Python, with the added benefit that I can write "lower-level" modules for it"? <davexunit>zPlus: primarily, Guile is not an interpreted language. it uses a virtual machine and a compiler. <zPlus>amz3: I think something like that yes, but not a library, it's a service, and I'd like to have some RPCs that can be called <davexunit>but yes, you can write extensions in both C and Scheme. <xd1le>zPlus: it *does* have an interpreter/repl though. <xd1le>but that's mainly to help debug/play and stuff i think <davexunit>code typed at the REPL still goes through the compiler. <davexunit>(Guile also has an interpreter, but out-of-the-box you're using the compiler) <zPlus>davexunit: would it make sense to use Guile as "glue code" between my C service and a client application, in such a way that the client can use classical method calls and transparently use my service? (for example add(1, 2) ) <davexunit>are you saying that you want client applications to be written in Guile? <zPlus>davexunit: nope. Usually with RPC there is some code automatically generated for a target language, starting from an interface defined with some IDL (for example it could be XML, from which C/Python/... code is generated. You import the new files in your code, and implement the interface. Then you can just call those methods and everything is taken care of). I was wondering if Guile could be used like this <davexunit>it's a general purpose programming language, so sure. <davexunit>guile has nice modules built-in for parsing XML. <zPlus>davexunit: sorry if my questions are not precise, but it reflects the fact that I don't know Guile very well :) Let's say that I have my service. Then I write another C library with only a function, int r = add(int a, int b), and add Guile to it. So, if I'm right I've made a new Guile module with a new function, add(). Now, can I use this module from another program, for example from a Python/Java/C++ application, and call this routine on the module? <amz3>zPlus: there is nothing stopping you doing that via RPC <davexunit>if you made a C file that used libguile to expose a C function to Guile, you could use that function from Scheme in Guile. <xd1le>zPlus: aren't you just talking about FFI? <zPlus>xd1le: pretty much :) but I think all FFIs are language specific, that is you have to make a new interface for each language, whereas I thought that I could just load a Guile file and have the same functionality <xd1le>ah right I see what you mean <zPlus>Guile is described as a language to extend ones' program capabilities, but wouldn't it be more appropriate to say that the purpose of Guile is to extend the capabilities of other Guile/Scheme programs? <xd1le>zPlus: it has an excellent FFI <xd1le>and it's scheme, which is sort of a minmal lisp <xd1le>so i think that's what's meant by extensible <xd1le>as in lisp is great, macros and stuff <xd1le>makes it a good candidate for configuration <zPlus>xd1le: I actually see it the other way around. Once you "guile" your program, your program becomes a reusable component; but the main program, the one you run, is the one you write in Guile; your program is just a module... anyway, that's just how I see it <xd1le>ah i didn't think about it like that <xd1le>now i can see why you thought that <zPlus>basically I could use any other language, and it will be the same thing. The main advantage that I see (from what I can understand about Guile), is that it has an excellent FFI... but again, I'm just a noob with Guile and I'm probably wrong :P <xd1le>and that it's likely a better language ;) <xd1le>but yes, i think you're right <zPlus>davexunit: can you please comment on ^^ <davexunit>zPlus: so, you're contrasting using Guile + FFI with other languages and their FFIs? <davexunit>earlier, I thought there was some confusion around thinking that Guile extensions could be used in other language environments, which is not the case. <zPlus>davexunit: the problem for me is that Guile is described as an extension to my program, whereas it seems to me that my program is actually extending Guile <davexunit>one use-case is embedding Guile into an existing application <davexunit>for example, a video game written in C could embed Guile for handling game scripts <davexunit>the other, IMO better, use-case is writing your program as an extension to Guile. <zPlus>davexunit: could you please elaborate more on the game example? What would be the use case in practice? How would Guile help my game? I add Guile, then how would users take advantage of it? <davexunit>zPlus: they would be able to write scripts in Guile, rather than C. <davexunit>which means fast prototyping and not needing to stop and rebuild the game every time they make a change. <davexunit>Lua is used a lot for this purpose, but Guile serves this use-case as well. <xd1le>zPlus: that's why said, likely a better language :p <zPlus>davexunit: when you say "a video game written in C could embed Guile for handling game scripts", does it mean that I run my game, and the game loads these Guile scripts? Or viceversa, I run these Guile scripts, which in turn load my game? <davexunit>it's better to flip things and write your program as an extension of Guile instead. <davexunit>the above article does a good explaining why <davexunit>they are talking about Python, but the same things apply to Guile <zPlus>davexunit: correct me if I'm wrong: I write a Guile script with 1 single echo function "string echo(string s)" which returns the same string. Do you mean that I can actually load this Guile script from my C program and execute the function? <zPlus>or at least that's what I got from your reply "the first." <madsy>zPlus: It's a question of who calls the entrypoint and has the main loop. If you write your application in C and it has the main loop, then it embeds guile <zPlus>davexunit: so if I embed that Guile script in my C program, I can call echo(..) directly? <davexunit>zPlus: I should point out that you don't write Guile code like "echo(...)" <davexunit>but if you have a Guile script in a file called "foo.scm", your C program could link against libguile and use its API to evaluate "foo.scm" <zPlus>davexunit: let's say foo.scm is the file definig the echo function (and only that function is in that file), can I use libguile to call that specific function and get a return value? <zPlus>cool, that makes a huge difference :D <xd1le>can't you do that with other languages as well? <zPlus>xd1le: because I can define a function add(int, int) in Guile (syntax aside). I can make the function transparently (to the user) connect to my service and get the result, which is then returned to the program who called add() originally. This means that *any* language with a libguile library, can load the scm and call the the add() function (with no need for me to write bindings for all other languages) <-- to the best of my understanding <xd1le>i think zPlus means a libguile wrapper at least? <xd1le>as a libguile c wrapper for the language <davexunit>it seems that zPlus is confused, but I can't figure out how to clear it up. <xd1le>so to interface with guile from another language, can just go through c <zPlus>wait... is there a libguile for C only? <xd1le>but tbf, that's not really revolutionary <xd1le>zPlus: well it's a C library. <davexunit>zPlus: yes, it's very specifically a C library. <zPlus>davexunit: ok, I assumed there was a "libguile" for other languages as well <xd1le>zPlus: usually when a library is called "lib" something, it's probably a c library <xd1le>so c is really like the glue here <xd1le>davexunit: isn't guile written in scheme? <xd1le>and the compiler is bootstrapped via libguile? <davexunit>libguile provides the low-level parts of Guile, and an interface to the C world. <zPlus>davexunit: but there would be nothing wrong with a libguile for, say, Java... right? If I can embed a Guile script in C using libguile, I could as well embed it in Java with an hypothetical libguile-java, right? <xd1le>zPlus: if you can write the library <xd1le>so you're back to "the need to write bindings" <zPlus>xd1le: it will still be worth it though, you write the bindings once, and then you can share scheme scripts among languages :) <davexunit>zPlus: Java provides a way to link against C shared libraries, so sure. it wouldn't make much sense, but sure. <davexunit>I have no idea what problem you are trying to solve with such a convoluted approach. <davexunit>if you want people across many languages to use something of yours, write a C library and let them use their FFI to access it. <zPlus>davexunit: RPC... in order to communicate with other processes I could use Guile to offer methods calls instead of pipes/sockets <zPlus>so, like, I write a Guile script and everybody can share it and have a new set of functions (that are executed on a separate process) <xd1le>well you would still need for guile to be able to talk with other languages <xd1le>why not just go lower, or just use the language you want to use yourself? <zPlus>because I write the service, but other people write many clients in different languages <zPlus>C service <--> Guile scripts: exchanges JSON (or other serialization) data with service, then unpacks arguments into proper types <--> client <zPlus>but I was wrongly assuming that there was a "libguile" already for many languages, and not C only <davexunit>we want more people to use Scheme, not other languages. <davexunit>the Guile VM is also a general platform for languages beyond Scheme. we have an Emacs Lisp implementation, for example. <xd1le>> C service <--> Guile scripts: exchanges JSON (or other <xd1le> > serialization) data with service, then unpacks arguments into proper <xd1le> yeah but that's my point, guile necessarily isn't doing something special <xd1le> here that other languages cannot <xd1le>but also, scheme is probably the better language anyway <xd1le>(bar other types of specific libraries you may want to use that are only <xd1le>available in other languages) <ArneBab_>paron_remote: first impression for the tutorial: A not-yet-programmer will not understand what imperative, … means. <davexunit>I read the WIP tutorial. I like the direction a lot, but I do think that discussion about mutation should be avoided for a bit. <ArneBab_>zPlus: sor essentially you’d use guile as a local server which provides access to your library to anything which can send JSON? <ArneBab_>and Guile would make it cheaper to write that server (as opposed to implementing it in C)? <zPlus>ArneBab_: the backlog is a bit longer than my last message :) However, I assumed that there was a guile library for many more languages than just C, and that if I can use libguile to call a function from a .scm file, I would have a rudimentary RPC mechanism using Guile (and immediately available to any language with a libguile available) <ArneBab_>you can fake it by using commandline utilities as service <ArneBab_>(I recently used python as plotting backend for guile by simply opening a socket to a python process :)) <paron_remote>I feel like as long as the general direction is good, I should keep writing, then cut things out / simplify / clean up after more content is there :) <paron_remote>makes me wish I could convert all my pelican using sites over to haunt / skribilo <paron_remote>would be a big task without a good way to make a restructured text reader though... <davexunit>paron_remote: I chipped away a bit more at my own migration <davexunit>I'm gonna rewrite everything in skribe format <davexunit>but I'm not interested in implementing a ReST reader <paron_remote>davexunit: yeah I don't think I'd ever get a rst reader finished <paron_remote>because at least the parsers out there are nice enough to give the programmer nice access to that <paron_remote>ArneBab_: davexunit: maybe the mutation should appear in the part two of the intro to procedures bit? <paron_remote>I feel like the explaination was not bad, but it was definitely cart before horse <zPlus>davexunit: "Manuel Serrano can no longer maintain and develop Skribe. Skribe is thus looking for a new maintainer." <paron_remote>zPlus: and I think haunt borrows from guile-reader or skribilo's skribe