IRC channel logs

2016-01-16.log

back to list of logs

<zacts>hey bambams
<zacts>you are learning guile scheme?
<paron_remote>a few more updates to http://dustycloud.org/misc/guile-tutorial.html but plenty to go
<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> http://www.hyperdev.fr/notes/2015/08/06/sfx-template-language-for-scheme-guile/
<amz3>At the very core, sfx template is an abstraction between django or rail templates and templating via plain sxml and quote/unquote
<amz3>...
<amz3>I'm looking for ways to I11E http://www.hyperdev.fr/projects/front13re/v0/
<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>xd1le: the REPL is different.
<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>I don't quite understand.
<davexunit>are you saying that you want client applications to be written in Guile?
<xd1le>davexunit: ah right true
<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>zPlus: for the generator?
<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>zPlus: no, that's not write.
<davexunit>er, right.
<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.
<davexunit>not any other language.
<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>but not sure
<xd1le>as in lisp is great, macros and stuff
<xd1le>and being a minimal lisp
<xd1le>it's easy to learn
<xd1le>makes it a good candidate for configuration
<xd1le>langauge, i.e. extending
<xd1le>(i think?)
<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>zPlus: it can be viewed both ways.
<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
<xd1le>*why i
<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>zPlus: the first.
<davexunit>that's the embedding use-case.
<davexunit>it's better to flip things and write your program as an extension of Guile instead.
<davexunit> https://twistedmatrix.com/users/glyph/rant/extendit.html
<zPlus>why?
<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
<zacts>bambams: eventually you'll probably want to check out https://mitpress.mit.edu/sicp/full-text/book/book.html
<davexunit>zPlus: yes.
<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?
<davexunit>zPlus: yes
<xd1le>zPlus: pretty much
<zPlus>cool, that makes a huge difference :D
<xd1le>zPlus: wait, why?
<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
<davexunit>zPlus: no, that's not true.
<davexunit>libguile is a C library.
<xd1le>i think zPlus means a libguile wrapper at least?
<davexunit>I'm pretty lost.
<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
<xd1le>(i'm not sure though)
<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>(i think)
<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?
<xd1le>or something?
<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> > types <--> client
<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_>that could be useful, yes
<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>ArneBab_: davexunit: yeah you're probably right
<paron_remote>general direction seems good?
<davexunit>yes
<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 :)
<davexunit>that sounds good
<ArneBab_>sounds good, yes :)
<paron_remote>also I love Skribilo and also the Skribe syntax
<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>which is a bunch of work
<davexunit>but I'm not interested in implementing a ReST reader
<davexunit>format is too complicated
<paron_remote>davexunit: yeah I don't think I'd ever get a rst reader finished
<paron_remote>though
<paron_remote>one route could be to use the restructured text AST
<paron_remote>because at least the parsers out there are nice enough to give the programmer nice access to that
<paron_remote>yakkity yak
<davexunit>:)
<paron_remote>ArneBab_: davexunit: maybe the mutation should appear in the part two of the intro to procedures bit?
<paron_remote>er, the mutation explainatoin
<paron_remote>I feel like the explaination was not bad, but it was definitely cart before horse
<paron_remote>and it's nice to understand why set! yells at you ;)
<zPlus>davexunit: "Manuel Serrano can no longer maintain and develop Skribe. Skribe is thus looking for a new maintainer."
<paron_remote>zPlus: right, but Skribilo doesn't have that problem
<paron_remote>zPlus: and I think haunt borrows from guile-reader or skribilo's skribe