IRC channel logs


back to list of logs

<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>cli utilities...
<zacts>crocket: depends
<crocket>Is it good as a replacement for bash scripts?
<zacts>crocket: I don't think guile is the best replacement for bash scripts
<crocket>What is?
<zacts>hm... well.
<crocket>Shell scripts are clumsy.
<zacts>it depends on what your goals are
<zacts>indeed they can be
<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>Compilation is not requirement.
<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
<zacts>^ more like this
<crocket>guile emacs could replace emacs next year.
<zacts>crocket: says who?
<crocket>I don't know
<crocket>But, it's close
<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>^ so something like this
<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>Ruby is the king of mutation.
<zacts>ah yeah
<crocket>I wrote some cli utilities in node.js before.
<zacts>ruby is totally OOP
<crocket>And, it sucked.
<zacts>hm.. let me link the Haskell scripting stuff
<crocket>Well... I'm going to learn haskell, though.
<crocket>Haskell scripts?
<crocket>Is it natively supported?
<zacts>ah wow
<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>oh crocket let me link scsh
<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>because that would be cool
<zacts>crocket: well guix is written in guile too
<zacts>and, other things...
<crocket>Is guile ok for cli utilities?
<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>it could be possible
<crocket>find the time?
<zacts>crocket: you would likely be implementing many things from scratch
<zacts>you would be on your own in a sense
<zacts>if that makes any 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)
<crocket>What is guile's package manager?
<zacts>but I'm planning on returning back to scheme soon for SICP
<crocket>MIT Scheme
<crocket>Somebody rewrote SICP examples in Racket.
<zacts>ah yeah
<zacts>crocket: chicken also has had some active development in implementing SICP examples
<zacts>CHICKEN scheme
<zacts>I really love CHICKEN too
<crocket>It seems Racket is more appropriate for standalone programs.
<zacts>ah ok
<zacts>try racket then
<crocket>Guile for embedded...
<zacts>embedded into C apps
<zacts>not embedded hardware
<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.
<crocket>Does guile have module repository?
<zacts>^ this is a cool scheme for things like microcode / firmware
<zacts>crocket: guile has libraries
<zacts>goops, and things
<crocket>Does it have a project manager like leiningen?
<zacts>see this
<zacts>crocket: I don't think guile has anything like leiningen
<zacts>but I'm not 100% sure
<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?
<crocket>adhoc, ^^
<adhoc>crocket: don't know
<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>Lack of package management.
<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.
<crocket>As says, guile is meant to be embedded.
<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.
<crocket>This is not acceptable for me.
<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>ArneBab, guildhall is discontinued.
<artyom-poptsov>crocket, ArneBab: Ah, sure, it called "guildhall", not "guild".
<crocket>The last commit was done on Apr 11, 2013.
<crocket>not a single bug fix done after then.
<ArneBab>crocket: it works.
<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>crocket: for my take on what Guile can do well, have a look at py2guile:
<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.
<crocket>I could happen next year.
<crocket>ArneBab, I downloaded it.
<ArneBab>ok, it’s deleted again.
<ArneBab>it’s the second beta of the text
<crocket>What is this?
<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: let me upload it again ☺
<ArneBab>muep: I’m currently doing the second line of corrections (I have a printed version here)
<muep>ArneBab: thank you
<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
<civodul>Hello Guilers!
<_amz3_>héllo :)
<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>wleslie, Doing so wastes time
<crocket>Build tools like leiningen would help
<crocket>muep, Do distro package managers have lots of guile modules?
<crocket>I doubt
<wleslie>well yes. leiningen is cool.
<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?
<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.
<crocket>Does guix make it easier?
<muep>I mostly use only distros where I know the packaging tools well enough that it is not very difficult to package something
<crocket>like what
<muep>fedora currently
<crocket>Do you publish the packages to the official repositories?
<muep>fedora uses rpm packages, yes
<crocket>Or, do you keep them privately?
<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>A few guile libs on ubuntu
<civodul>crocket: Guix has some of the useful Guile packages, see
<civodul>Debian as well, of course
<crocket>This is not ideal.
<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.
<crocket>What is it?
<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_>yes but it works, no?
<crocket>I don't know.
<crocket>ArneBab says it works.
<_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
<crocket>What is gnu build system?
<ArneBab>crocket: guildhall works for me
<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
<ArneBab>crocket: it’s easy to install.
<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_>crocket: here is a recipe for guile json:
<_amz3_>source is here:
<_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.
<crocket>systems programming
<crocket>system utilities
<crocket>like iotop
<_amz3_>Guile compared to C? I'm not a good advocate anyway, but I think what lakes Guile is libraries/users not features
<crocket>iotop was written in python.
<_amz3_>also backtrace are difficult to decypher
<crocket>guile could be used to write system utilities.
<crocket>like cp
<_amz3_>iotop, that's nice I need that
<_amz3_>there is (copy-recursively) in guix
<_amz3_>(python is my primary language)
<ijp>crocket: any non-toy language could be used to write cp
<ijp>even most toy ones
<_amz3_>that's an opinion :)
<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)
<_amz3_>ijp: prolog also
<crocket>muep, Most distros have a few guile packages....
<crocket>Hardly a good argument.
<ijp>_amz3_: prolog does have io
<crocket>Can you make do with a few guile packages?'
<ijp>write a program and find out
<crocket>Also, distros come and go.
<crocket>This leads to loss of packages.
<_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.
<crocket>Guix could serve as one.
***dje is now known as xdje
<_amz3_>crocket: btw iotop only opening files in /proc, this doable in guile
<ArneBab>mark_weaver: I found that match does not work in wisp when executed as script. Could you have a look at this example and see whether you see what goes wrong:
<_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.
<ArneBab>it worked nicely for me in Gentoo
<_amz3_>I think that more and more user will user guix or guixsd
<_amz3_>guile user
<davexunit>crocket: guile has a POSIX API, making it suitable for systems programming.
<crocket>Is windows POSIX-compatible?
<ijp>it's complicated
<davexunit>I don't use Windows, but I think a compatibility layer can be used
<davexunit>cygwin or something?
<davexunit>I prefer to just use a more sane OS to begin with and avoid all of that trouble.
<ijp>saner, not sane
<davexunit>yes, "more sane"
<davexunit>I know that UNIX is still insane ;)
<_amz3_>crocket: you can install guixsd on an external hard disk
<_amz3_>and dual boot
<crocket>What is unix?
<crocket>Is ubuntu UNIX?
<crocket>Is archlinux?
<_amz3_>a slang ;)
<_amz3_>yes kind of
<crocket>As far as I know, linux distros are UNIX-like.
<crocket>Is Mac OS insane?
<_amz3_>it's an old OS and a family of OS
<crocket>Apple's policies are insane.
<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>so weird
<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.
<ijp>write one
<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.
<davexunit>for which prescribes a cure.
<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.
<davexunit>which naturally has the best intregratin.
<crocket>I do not see better alternatives to language package managers yet.
<davexunit>guix and nix are two alternatives.
<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.
<davexunit>what does that mean?
<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.
<davexunit>okay, so like bundler?
<davexunit>I use that every day.
<davexunit>guix/nix can do that, but better.
<_amz3_>like properly handling system dependencies
<crocket>The potential problem of guix is that it contains everything.
<_amz3_>why is it a problem?
<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
<_amz3_>what do you mean by everything
<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?
<_amz3_>it works already
<_amz3_>ijp: !
<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>So, I might be wrong about guix.
<_amz3_>(I'm too lazy)
<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>Want to try it
<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
<crocket>Does guix require me to know guile?
<_amz3_>python-zmq is in the repository so you won't need pip/easy_install
<_amz3_>crocket: no
<_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
<_amz3_>crocket: there might be helpful thread to follow in guix mailling list if you want to install guix on ubuntu
<dsmith-work>Monday Greetings, Guilers
***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.
<crocket>guild -> guile
<crocket>davexunit, _amz3_ : ^^
<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.
<ArneBab>it’s a nice learning environment
<crocket>For a starter, I joined the mailing list.
<crocket>But, it's not a binary decision.
<_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
<_amz3_>crocket: let's move to guix
<ArneBab>ijp: here’s a first try at a guildhall package for the newbase60 stuff I wrote today:
<paron_remote>hello #guile
<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>_amz3_: yes-ish
<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
<_amz3_>it's + activitystream ?
<paron_remote>_amz3_: well was already activitystreams 1.0, this is AS 2.0
<paron_remote>the draft in progress
<paron_remote> but I am starting here, making nice guile interfaces for activitystreams stuff
<paron_remote>it's mostly experimental stuff that eventually congeals into something useful
<paron_remote>wingo: ijp: I'm not convinced though by that
<wingo>why not? :)
<paron_remote>I think a couple of (request-body request) and (response-body response) methods simplify things
<paron_remote>and tacking it onto the structure
<paron_remote>the reason being
<wingo>what would (request-body ...) return?
<paron_remote>wingo: the body :)
<wingo>as a what? :)
<paron_remote>so pack the body into the request
<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>I mean
<paron_remote>how much worse is that than having to pass in two values to every function
<paron_remote>and do multiple value returns everywhere :)
<paron_remote>and when do you really want a body disconnected from the head?
<paron_remote>the headers
<wingo>good question :)
<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
<paron_remote>wingo: I dunno, have a promise? :)
<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
<paron_remote>so I was surprised
<paron_remote>and curious as to the rationale
<wingo>i thought that wsgi separated them
<paron_remote>does it?
<wingo>i could be wrong there
*paron_remote looks again
<paron_remote>wingo: I always immediately transform the wsgi into a higher level request object, I guess ;)
<paron_remote>wingo: seems you're right
<paron_remote>wingo: ijp: thanks for the clarification
<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
*paron_remote nods
<_amz3_>something like that
<paron_remote>cool well
<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>seems to be
<davexunit>I have implemented the handshake for websockets... just need to do the hard part now :)
<wingo>hoo, 1851 bindings in (guile-user)
<ijp>big news, (warning: very big, will not fontify in emacs) runs boot9 and psyntax (in a very hacky manner) and runs
<ijp>wingo: that is a lot
<stis__>heya ijp: great progress!!
<wingo>ijp: woooo!
<ijp>on the downside, dynamic-wind is currently broken, but you don't see that because there are no winders
<davexunit>very cool!
<wingo>i have never used delete! i don't think
<wingo>in all these years
<wingo>also delete1!, lol
<wingo>delv1! whee
<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>here's the gc:
<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?
*ijp looks
<civodul>see 'loaded-modules'
<ijp>hmm, I don't see it
<civodul>well that's in 2.0
<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>er, yes?
<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
<zacts>I can find it though
<zacts>ijp + emacs web search
<zacts> ?
<zacts>cool I see
<ijp>shift-reset is my site, yes
<zacts>this is sweet man
<ijp>please don't run it yet
<ArneBab>ijp: did you see my guildhall pull-request?
<zacts>ijp: ah ok
<zacts>I won't
<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: here’s a pull request for the README and quickstart
<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
<ijp>ArneBab: kind of
<ArneBab>I tried it, but I only see it as library (via guild show-bundle .)
<ijp>oh right, guildhall, not guile
<ijp>er, dunno
<_amz3_>I have some graph datastructure that is stored on disk that seems to work if anybody is interested:
<_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>in terms of complexity?
<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?