<crocket>Is guile suitable for command line programs and general purpose programming? <zacts>crocket: can you be more specific what you mean? <zacts>do you mean a guile version of a UNIX shell, like bash? <zacts>or do you mean just a programming language, like python or perl, for scripting your own cli utilities? <zacts>indeed guile is good for general purpose programming <zacts>but note that guile is interpreted and not compiled <crocket>Is it good as a replacement for bash scripts? <zacts>crocket: I don't think guile is the best replacement for bash scripts <zacts>it depends on what your goals are <zacts>Perl is often used for many system tasks <zacts>I've heard python / ruby being used too <crocket>I heard Racket was fine for cli utilities. <zacts>there is a scsh, but it isn't really totally usable as a 100% bash replacement <zacts>and it relies on scheme48 currently <crocket>I used python for cli utilities before. <zacts>but I've heard chatter here before about how it would be cool to port scsh, or implement something like this, in guile <zacts>crocket: well, let me show you a book <zacts>also, Haskell has produced some scripting DSL's to replace bash scripts <zacts>but they aren't full interactive shells <zacts>bash-$ <-- the Haskell DSL's are not this <crocket>guile emacs could replace emacs next year. <zacts>(although, that kind of progress would be great) <crocket>Guile emacs implemented emacs lisp engine 100%. <crocket>If guile emacs takes off, emacs will also be able to run guile scripts as extension modules. <zacts>you may be able to skim the table of contents of that, and index <zacts>and find some ideas for using ruby and things for cli scripting <zacts>or it may lead you to other solutions <crocket>Actually, I'm looking for a functional programming language. <crocket>I wrote some cli utilities in node.js before. <zacts>hm.. let me link the Haskell scripting stuff <crocket>Well... I'm going to learn haskell, though. <zacts>a new Haskell module was released this year <zacts>(the last I looked into this was early last year) <zacts>I also dislike bash / unix shell scripting from an aesthetic standpoint <crocket>It seems you don't recommend guile for anything for now. <crocket>guile emacs is going to make guile a scripting language. <zacts>^ I think that shelly was the one I looked into before <zacts>if you are interested in guile and emacs <zacts>then perhaps you could personally help towards the goal of porting or re-implementing scsh for guile scheme <crocket>If emacs is going to adopt guile, guile may be worth learning. <zacts>crocket: well guix is written in guile too <zacts>gnu lilypond (but it still is lagging on updating to guile-2.0 from guile-1.8 due to technical reasons) <zacts>crocket: if you can find the time to implement them yes <zacts>(although, I can't guarantee you won't have headaches from it) <zacts>if you want to make a cat / ls / mv / cp clone in guile <zacts>crocket: you would likely be implementing many things from scratch <zacts>you would be on your own in a sense <crocket>Does it mean racket is better for my purpose? <zacts>crocket: well racket may provide libraries / modules already out of the box, that guile doesn't have <zacts>but guile may have some too, I personally have been away from scheme lately <zacts>(Haskell has stole my attention temporarily) <zacts>but I'm planning on returning back to scheme soon for SICP <crocket>Somebody rewrote SICP examples in Racket. <zacts>crocket: chicken also has had some active development in implementing SICP examples <crocket>It seems Racket is more appropriate for standalone programs. <zacts>for that there is microscheme <zacts>for like microcode and firmware <crocket>I can't believe that guile doesn't have cp module. <crocket>It is one of the fundamental building blocks. <zacts>^ this is a cool scheme for things like microcode / firmware <zacts>crocket: guile has libraries <crocket>Does it have a project manager like leiningen? <zacts>crocket: I don't think guile has anything like leiningen <zacts>as I said I'm just getting back into scheme <zacts>others here will be able to better answer guile specific details <adhoc>i think a lot of that packaging focus is happening in guix <adhoc>although thats more about OS level packaging <crocket>Does guile have a package repository? <adhoc>lots of things i've been looking at recently are in github <crocket>It seems guile is not really convenient for standalone programs yet. <crocket>Guile looks promising as an embedded script language. <artyom-poptsov>crocket: IIRC there's package management system for Guile called "guild", but I personally haven't tried it yet. <crocket>"Guile is a library designed to help programmers create flexible applications. Using Guile in an application allows the application's functionality to be extended by users or other programmers with plug-ins, modules, or scripts." <crocket>artyom-poptsov, guild is discontinued. <ArneBab>crocket: I’d say you can build cool command line applications with Guile. I build my helper tools with it. <crocket>Not really a good fit for standalone cli utilities. <ArneBab>crocket: you might not have all the clean support libraries you’d like to have, but most things are pretty easy to do. <crocket>ArneBab, Yet, you will have to manually build and install extra modules. <adhoc>crocket: if there isn't something you need, write it. <ArneBab>crocket: guile also has guildhall as package manager <muep>I think guile is just fine for standalone programs <crocket>adhoc, I don't think I can justify the cost. <crocket>The last commit was done on Apr 11, 2013. <crocket>not a single bug fix done after then. <crocket>When the core abandons the concept of package management, I am not willing to invest my time to do that. <crocket>ArneBab, If I start using guildhall, I'll have to maintain it myself due to lack of support. <ArneBab>I’m using guildhall, and others do so too <crocket>As the acronym says, it is an extension language and is best used as such. <ArneBab>(grab it while it’s there - I’d have linked you the link on my website, but that’s down since my Drupal was breached) <crocket>I'm excited to use guile on emacs after guile emacs takes over emacs. <ArneBab>crocket: that’s my impression of Guile coming from Python <ArneBab>crocket: it wouldn’t have become a book if that impression hadn’t been pretty good <ArneBab>crocket: it compares Guile against the strengths of Python, shows it’s weaknesses and where it allows you to go far beyond. <muep>ArneBab: I'd like a copy of that text, if you wish to share it to me, too <ArneBab>muep: I’m currently doing the second line of corrections (I have a printed version here) <ArneBab>I’ll leave it there for a bit longer in case someone else here wants to get the current version :) <ArneBab>it’s in beta, though, known issues included ☺ ***heroux_ is now known as heroux
<crocket>How do people use third party guile packages without guildhall? <crocket>The standard library is not an issue. <muep>my preference would be to use the package manager provided by the distro <wleslie>drop them into your project directory <crocket>Build tools like leiningen would help <crocket>muep, Do distro package managers have lots of guile modules? <wleslie>mostly because maven happens to be a very good package layout system. <muep>crocket: it was fairly easy to provide such a package when I needed a module that was not already packaged <muep>but I have not lately done much with guile <crocket>muep, How was it easy? Can you describe it? <muep>crocket: pretty same as packaging something else <crocket>On ubuntu, packaging something is not easy. <crocket>On slackware, it's moderately difficult. <muep>I mostly use only distros where I know the packaging tools well enough that it is not very difficult to package something <crocket>Do you publish the packages to the official repositories? <muep>fedora uses rpm packages, yes <muep>the guile module I packaged was guile-sqlite3. that I packaged for exherbo, and I did publish the packaging <muep>exherbo goes somewhat out of their way to make it easy for users to share their packages <crocket>Let me check if ubuntu contains guile packages. <crocket>I'm more comfortable with installing packages locally in a project with a build tool. ***michel_mno is now known as michel_mno_afk
***michel_mno_afk is now known as michel_mno
<ArneBab>crocket: for that you might want to check the guix-env stuff. I did not test it myself, but others here reported quite cool results. <ArneBab>it gives you an instant environment with exactly the packages you need <ArneBab>something like virtualenv for Python, but supporting all kinds of dependencies <_amz3_>crocket: what is the problem with guildhall? <crocket>_amz3_, not being maintained at all... <crocket>Since Apr 2013, it has been dormant. <_amz3_>if I'm not mistaken most guile packages use gnu build system, and it's easy to create guix recipes for that kind of packages <ijp>no-one was using it, and no-one was packing for it, so when guix started to build steam, I had no reason to "maintain" it <ijp>not that I did much maintaining <crocket>Does it mean guix is going to serve as a guile package manager? <ArneBab>I have some ideas for features I’d like to see in guildhall (and which I’d like to implement) <ijp>crocket: maybe, who knows <ArneBab>crocket: these are different use cases. for getting the dependencies of a project, guix is likely a better choice. <ArneBab>crocket: for just installing some packages locally, guildhall is pretty good. <ArneBab>because it does far less - much simpler <_amz3_>I'm using guix because it has good support for guile, much less troubles than debian <_amz3_>and much less troubles than debian in general if you don't need GNOME <_amz3_>I never did debian packagin, guix recipes are nicer than gentoo's ebuilds. less bash. <_amz3_>(and don't require non-free packages) <crocket>It seems GuixSD is going to make guile a system programming language. <_amz3_>I'm not sure what system program means. <_amz3_>Guile compared to C? I'm not a good advocate anyway, but I think what lakes Guile is libraries/users not features <_amz3_>also backtrace are difficult to decypher <crocket>guile could be used to write system utilities. <_amz3_>there is (copy-recursively) in guix <ijp>crocket: any non-toy language could be used to write cp <crocket>How did people live without a proper package manager? <ijp>_amz3_: about the only exception to this was javascript prior to node <muep>most users of guile already have a nice package manager from the distro <_amz3_>there was not as much updates and package sas today (for a start) <crocket>muep, Most distros have a few guile packages.... <ijp>_amz3_: prolog does have io <crocket>Can you make do with a few guile packages?' <ijp>write a program and find out <_amz3_>ijp: I was said by the creator that it started without ui and was a pure logic language without io, it was an io "afterthough" that's why io has bizar syntax (at least in the dialect I was using) <ijp>a lot of things were an afterthought <_amz3_>crocket: there few sugar libraries, but from my point of view, you can do a lot same as in Python. It takes more time though, but you can do it <crocket>In my opinion, there should be a repository of packages independent of a distro. ***dje is now known as xdje
<_amz3_>crocket: btw iotop only opening files in /proc, this doable in guile <_amz3_>crocket: my humble recommendation, is to use guix first over a debian or something, also I never tried it, but I think it's better to have some .guix-bashrc file to source when you want to work on guile things. Otherwise guix works great over debian. <_amz3_>I think that more and more user will user guix or guixsd <davexunit>crocket: guile has a POSIX API, making it suitable for systems programming. <davexunit>I don't use Windows, but I think a compatibility layer can be used <davexunit>I prefer to just use a more sane OS to begin with and avoid all of that trouble. <_amz3_>crocket: you can install guixsd on an external hard disk <crocket>As far as I know, linux distros are UNIX-like. <_amz3_>it's an old OS and a family of OS <crocket>_amz3_, Is guix the future of guile package management? <crocket>I could install guix right now on ubuntu. <_amz3_>I'm not a wizard to know the future, but like I tried to explain it's easy to create recipes for guix, so I assume that the answer is kind of yes <_amz3_>I think I'm not mistaken to say that contributors of guile are also contributors of guix, so it's easy to do the math <crocket>That's why guile has failed to accumulate hundreds or thousands of packages so far... <_amz3_>nah... guile is not its packages ;) <crocket>Without packages, it is hard to do useful things. <davexunit>does the world really need yet another language package manager? <davexunit>besides, I think guildhall can be that, but ultimately I think the proliferation of package managers is due to the weaknesses of traditional systems package managers. <crocket>guix tries to be independent of distros. <davexunit>the package manager can be used independently of any one distro, but guix provides a distro as well. <crocket>I do not see better alternatives to language package managers yet. <crocket>Since guix also contains system packages and tries to integrate with guixSD, I doubt its efficacy as a language package repository. <davexunit>unfortuantely, even if guix/nix catch on, language package managers, in all of their mediocrity, will continue to exist for a good while due to Windows and OS X. <crocket>davexunit, I like local package installation. <crocket>maven and leiningen does local installation. <crocket>This is the cleanest method I've seen. <ijp>davexunit: it means you should stop talking <ijp>because crocket either isn't listening, or comprehending <crocket>ijp, If you have a better idea, spit it out. <davexunit>what does "local package installation" mean? <crocket>davexunit, Have you ever used leiningen or maven? <crocket>ant, sbt, gradle, leiningen, maven, et al. <ijp>you were the exact same on #racket yesterday, only with nil <crocket>davexunit, Ruby projects have a local project configuration file that specifies dependencies. <_amz3_>like properly handling system dependencies <crocket>The potential problem of guix is that it contains everything. <crocket>My gut feeling tells me that it could lead to complexities in the future. <_amz3_>not sure, guix is a package manager, just like portage or apt. I think it's simpler than apt <crocket>guix is a general purpose system package manager which is a different concept from a language package repository. <crocket>When you pull guile modules from guix, it may also pull unexpected system dependencies outside guile. <davexunit>when you need to use 4 package managers to do your job, you'll understand why the general purpose package manager is better in the long run. <ijp>language package managers also do this <crocket>Thus, when you try to delete it, it may end up deleting unwanted packages as well. <_amz3_>not that much, python's setuptools can also compile programs, except guix does it better and has access to the packages of the build system (gcc, make) and understand them which is not the case of language packge managers <crocket>_amz3_, Will python play nicely with guix in the foreseeable future? <ijp>how about the foreseeable present? <crocket>This comes from my experiences with apt-get. <_amz3_>(I have to admit I use virtualenv. because I'm too lazy to package everything) <crocket>By the way, does guix work well already? I want to install guile emacs from guix on ubuntu. <_amz3_>crocket: what do you mean with apt-get? I never pip install things in the global site-packages with guix, you can't anyway. I use venv. <crocket>_amz3_, ubuntu has some python packages with system dependencies. <crocket>pyzmq depends on zeromq, which is not a python module. <_amz3_>yes obviously. I install them with guix and then I install the package in venv using the --with-system-package option <_amz3_>python-zmq is in the repository so you won't need pip/easy_install <_amz3_>crocket: if you install guix on ubuntu go to #guix to have guidance, it's probably a better place if it's quiet enough ***michel_mno is now known as michel_mno_afk
<ArneBab>ijp: when I package something for guildhall, how do I send it to you? <ijp>I don't have a system as you would be the first person to do it <ijp>well, aside from me and rotty <crocket>I realize that package manager could house multiple repositories. <ArneBab>then I’ll be the third to do it ☺ (I’m currently going through the packaging.texi) <crocket>In theory, python people could submit python packages to a python guix repository although it is unlikely for them to do so. <crocket>Since the main guix repository is also used for GuixSD, it may make sense for guile modules to be hosted on a separate guix repository for guild modules. <ArneBab>ijp: I realized that I did not have guildhall for this computer yet, so I installed it. <ArneBab>ijp: it complains that the config file /home/arne/.config/guildhall/config.scm does not exist <ArneBab>ah, yes, I did not follow the quickstart <crocket>ArneBab, How do you think of creating another guix repository for housing guile modules? <ArneBab>ijp: that adds installation instructions to the README <ArneBab>crocket: why don’t you join the existing guix team? <crocket>ArneBab, I have no knowledge of guile yet. <crocket>For a starter, I joined the mailing list. <_amz3_>crocket: guix is not something fat, but lean, you only have what you need. So it doesn't make sens to have a separate repository. <crocket>_amz3_, That doesn't make sense to me. <ArneBab>ijp: can I use a scheme file as a program *and* as library? <_amz3_>non-guile packages (system dependencies for instance) might be useful for guile modules. Like zmq for guile-zmq, or sqlite for guile-sqlite <ArneBab>crocket: it’s just a git repo. Clone it, add a package and file a pull-request <crocket>_amz3_, The problem is that guix is going to serve the needs of GuixSD. <crocket>For guix to serve multiple OSes, it shouldn't be dictated by the needs of GuixSD. <_amz3_>crocket: if such thing happens, it won't happen overnight, nor will it happen in the forseeable future, because some guix contributor use guix over other distros <_amz3_>I don't think it's in the interest of anybody to do so <paron_remote>wingo: I think you wrote most of the web request/response code right? <paron_remote>I'm starting some guile webdev stuff, one thing I really don't understand the motivation of is, why separate out the request and response objects from their bodies? <ijp>because the first thing a person is likely to do with a body is turn it into a port <ijp>most scheme parsers/readers operate on that rather than on strings or bytevectors <ijp>sorry, I may have just given you a lot of bull <ijp>wait no, this is fine for requests / responses themselves. The (web client) api is different as it does return a bytevector <_amz3_>paron_remote: are you working on a pumpio server? <wingo>paron_remote: yeah what ijp said <wingo>also you can read a request header and then decide how to read the port <wingo>and the request header is pretty much stateless but a port is not <wingo>people say nice things about the python requests lib, probably things to learn from there (and elsewhere) <ijp>wingo: since I spoke to you I redid parts of my js-il, and wrote a better inliner <paron_remote>I'm working on an "activitystuff" repo full of experiments which I hope to gradually evolve into an activitypump server :) <paron_remote>activitypump is the next iteration of the pump protocol we're working on for the w3c social wg <paron_remote>_amz3_: well pump.io was already activitystreams 1.0, this is AS 2.0 <paron_remote>it's mostly experimental stuff that eventually congeals into something useful <paron_remote>I think a couple of (request-body request) and (response-body response) methods simplify things <wingo>what would (request-body ...) return? <wingo>as a port, as a string (what encoding?), as a bytevector <wingo>and what if it's too big to fit into memory? <wingo>and would it read off the body always, or just sometimes, or lazily, or what? <paron_remote>wingo: why not let it be all the things body can currently be <wingo>and could you parse it into some other data type as you read? <paron_remote>how much worse is that than having to pass in two values to every function <paron_remote>and when do you really want a body disconnected from the head? <paron_remote>wingo: I see the value of being able to support ports and etc sometimes <wingo>but what happens if you call request-port twice? <wingo>like right now requests have no state <wingo>but can you actually get access to the port? if not you need some parsing and memoizing mechanism <wingo>if so.... dunno, where would I find the body? <paron_remote>wingo: so the flip side of this, if the body can vary so much <paron_remote>how much boilerplate of matching different possible forms do we expect web users to make use of? <paron_remote>I guess we need more high level frameworks on top of this that abstract away some of that, is one possible response <wingo>well for example, you can make a request without a body <wingo>that's the usual state of things <paron_remote>wingo: sure, but you could do that if (make-request) had body as a keyword argument too :) <wingo>but as for the format of the body, it depends on the encoding of the port that the request will be sent on <wingo>dunno, i've never felt it to be an issue but perhaps i'm wrong <paron_remote>wingo: anyway it's interesting reasons. I've just never encountered separating the request/response from the body in any web environment before <wingo>i thought that wsgi separated them *paron_remote looks again <paron_remote>wingo: I always immediately transform the wsgi into a higher level request object, I guess ;) <wingo>i think i was inspired by wsgi and didn't think much more about it <_amz3_>yes it separates header and body <_amz3_>if I'm not mistaken long polling is not possible otherwise, I mean websocket <_amz3_>even if wsgi doesn't support websocket <davexunit>there's other complications around websocket right now ;) <davexunit>though, I think I should just make a dedicated websocket server rather than try to turn an http server into one after the handshake <_amz3_>I think the most popular way to do it, is to have a separate server <davexunit>I have implemented the handshake for websockets... just need to do the hard part now :) <wingo>hoo, 1851 bindings in (guile-user) <ijp>wingo: that is a lot <ijp>on the downside, dynamic-wind is currently broken, but you don't see that because there are no winders <wingo>i have never used delete! i don't think <wingo>i've been hacking on a new scheme impl staged from guile that compiles to microcontrollers and i have to select the bindings available to syntax transformers <davexunit>too many procs in the namespace (too many procs) <wingo>so i have an excuse to see all these things :P <davexunit>wingo: I'd love to try out your scheme on one of my arduinos. <davexunit>I was interested in microscheme, but it's not actually Scheme. <wingo>this thing ain't done tho :P <davexunit>there's an implicit "when it's ready" at the end of that sentence ;) <dsmith-work>wingo: So does this "new scheme implementation" share any guile code or compiler tower? <wingo>dsmith-work: yep, but copied and hacked instead of really shared <dsmith-work>Cool! What kind/class of microcontrollers? Will it be on top of bare metal or expect Linux or something like a microkernel? <wingo>am currently looking at atmega328p <wingo>32KB flash, 2KB ROM, 8-bit, no os <wingo>everything will be in a big letrec, including gc <wingo>so you get tree-shaking for free <davexunit>I will want to rewrite the firmware for my arcade stick controller using this :) <wingo>interrupts will be tricky, i don't know if i'll be able to do register allocation or just pull things from stack <wingo>unless interrupts are async; dunno <dsmith-work>wingo: Ooo! And no memcopy/setjmp/longjmp for call/cc and friends? <wingo>dsmith-work: i could, but that would mean heap allocation of stack frames, which makes the cost of a procedure call less predictable <wingo>since i'm using guile's compiler i'm going to just make heap and stack grow towards each other <wingo>tbh i don't care a whole lot about call/cc :P <ijp>how can I get a list of all the modules loaded? <civodul>ijp: (system vm coverage) does something nasty to achieve that <ijp>my guess is to recursively search through imports? <stis__>ijp: I got people asking about running guile ontop of sbcl, when I mentioned tyour js work, is it doable? <ijp>right, looking i gitweb <ijp>stis__: I don't see why not <stis__>cool! I guess one could use your work as a boilerplate then. <ijp>civodul: yeah, that code is about what I'd expect <stis__>ijp: I think I want to take a break from guile-log development. When your code settles I could probably do that work, seams fun! <ijp>stis__: the compiler itself is relatively straightforward; the runtime is where you put in most of the work <ijp>of course, everyone who has ever written a compiler knows that <stis__>But it's good to have a checklist to check out all the runtime components one by one. <ijp>well, simple ones, not the optimizing beasts <zacts>ijp: did your guile-->JS project go through this summer? <ijp>and I thought I was talking about it too much <ijp>stis__: somewhat conversely, when this summer over I want to switch gears and try reimplementing guile's macros using racket's scope-sets ideas <zacts>ijp: I haven't followed guile for a while recently <zacts>ijp: I forgot your blog link <ijp>shift-reset is my site, yes <ijp>please don't run it yet <ArneBab>ijp: did you see my guildhall pull-request? <zacts>I'm just curious to follow the commit short-logs mainly <zacts>like as an RSS feed kind of thing <zacts>(in fact /me is checking if I can use actual RSS to track shortlogs) <ijp>and I wonder how force pushing interacts with that <ijp>ArneBab: yeah, I've just pulled it just now <ArneBab>I hope that this will make it easier for people to test it <ijp>that was what the wiki page was for, but I suppose I should have added it to the readme as well <ArneBab>or maybe a link to the wiki in the readme <ArneBab>You’ll shortly get a pull-request for the quickstart file - your current repository instead of the dead one <ijp>re: your package, there is no ice-9 package, so you don't need to add that to your depends list <ArneBab>ijp: ah, yes - guile can’t easily not provide ice-9 :) <ijp>there is a separate srfi collection which is why they are mentioned <ArneBab>ah, ok, so I don’t need them either, because the SRFIs I use are provided in guile, right? <ijp>strictly speaking, yes <ijp>dorodango was meant to be implementation neutral, so that's why other packages do <ArneBab>can I use a file both as library and as program? <ijp>huh, I forgot I'd packaged syntax parse <ArneBab>I tried it, but I only see it as library (via guild show-bundle .) <ijp>oh right, guildhall, not guile <_amz3_>this makes me think I could try guidhall :) <amz3>there is another one which is memory based on guix mailling list, I'm too lazy to paste it. anyway I will put everything together at some point <ArneBab>amz3: that sounds interesting. How efficient is it? <amz3>there is no algorithm, it's just the data structure <ArneBab>both: in terms of complexity and in throughput <amz3>dunno, it's just a plain backend, bsdm backend would be better <amz3>I've done the same thing in Python, the test suite runs faster with file based backend <amz3>but there is no transactions, no ACID no flush nothing just files <amz3>file based backend is only intersting for maybe doing a git based database or something <amz3>it's not meant to do computations <ArneBab>so it’s currently a persistent store for graphs? ***siel_ is now known as siel
<amz3>yes, I'm working toward using wiredtiger <amz3>it would be more useful then. <ArneBab>ijp: 88k lines for boot9, that’s quite big <ArneBab>amz3: what do you want to do with it?