<ArneBab_>davexunit: nice! With the change I at first didn’t even realize that the scheme wasn’t html given how similar it looked) <ArneBab_>(and I think that’s a huge asset for a templating language) <paroneayea>davexunit: btw that's a nice bootstrapping post with I hope more posts to come, eg: how to go from there to a running web application? :) <paroneayea>davexunit: and yes I hope you submit a patch to guile to get this in to guile 2.3 or so <davexunit>I don't know, but I anticipate one more release of the 2.0.x series before 2.2 graces us <ArneBab_>also the draft time of SRFI-119 should be up by now, so it should soon go final. <paroneayea>ArneBab_: have you written an emacs mode for it? <paroneayea>btw ArneBab_ the top of that page has a huuuuuuuuuuuge link <ArneBab_>some highlighting and mediocre to bad indenting <ArneBab_>I need to redo the flattr-button, but I had to postpone that for months now <ArneBab_>paroneayea: I wish I had a better emacs mode. Something to provide really nice indentation support would help a lot. <ArneBab_>But I’m actually pondering to let wisp rest for some time and check out paredit with regular scheme <paroneayea>ArneBab_: paredit is nice. I like smartparens even more. <paroneayea>it's like paredit but can be used for not just parens, and it also has a less-strict mode <paroneayea>I use smartparens in the less strict mode, letting me choose how much AST editing strictness I want for the moment :) <ArneBab_>does it otherwise provide the same features? <ArneBab_>ok, next step: deciding which AST parsing system to try next ☺ <paroneayea>ArneBab_: I still think occasionally, it might be fun to try to write some sort of not-aiming-for-compatibility language on top of guile that tries to be very guile-like, but with a syntax similar to dylan or julia <paroneayea>not-aiming-for-compatibility sity julia or dylan, I mean. <davexunit>if it's named julian, the project's logo better be a glass of rum and coke <paroneayea>davexunit: I actually was thinking Julian Bashir from DS9 ;) <davexunit>his character *always* has a rum and coke in his hand <paroneayea>davexunit: it's good if you start with TNG season 2 and then watch that till the end, then watch DS9 *davexunit pokes at a static site generator <paroneayea>davexunit: ooooh are you going to make one in guile? :O *paroneayea bbiab, dinner <davexunit>read posts, pass to user-defined procedures to generate html pages, write to disk. <davexunit>of course, this won't be nice to use until we have a markdown parser or something <paroneayea>davexunit: well, it could still be nice with a pelican "html" style support <paroneayea>pelican has .html file support also and I really like it. <davexunit>my plan was to use sxml as the intermediate representation of everything <davexunit>so it should work, provided the html doesn't have errors. <davexunit>sxml will not forgive you like a browser will. <davexunit>I swear I've seen something along those lines somewhere... <paroneayea>python has a great "forgiving" html parser, two actually <mark_weaver>scheme has htmlprag for a permissive html parser that converts to sxml iirc <ArneBab>it sounds like the parallel programming features in Julia could be pretty useful. Does Scheme offer something similar? <ArneBab>“You can configure Julia to run several instances across a cluster, and use them in a quite straightforward way” <ArneBab>(but it does not have shared memory) <ArneBab>“This is a guile interpreter with an extension that allows manipulating <ArneBab>process groups (MPI communicators) and basic inter-process <ArneBab>I don’t like the “end”, but the rest looks pretty good. <ArneBab>refined question: could their code be reused/ported? <ArneBab>…hm, I think I misread. I thought it was based on racket… ***koz__ is now known as koz_
<sneek>Welcome back davexunit, you have 1 message. <sneek>davexunit, rekado says: I still think it's a good idea to substitute all literal strings passed to "require" with full store paths to avoid having to propagate *all* inputs. This won't work for dynamic requires, but I suppose that's not quite as common as regular requires with string literals. <bernalex>halol. guile newbie here. I'm trying to use guile-www but am getting an (to me) obscure error msg. *davexunit hasn't heard of guile-www <davexunit>yeah, looks like a lot of overlap with guile's built-in (web ...) modules <mark_weaver>the one that's built in to guile is the one that most of us here are familiar with <bernalex>mark_weaver: oh. in my package manager 2.0.0 is masked for some reason. I am running 1.8.8-r1. maybe that's why I didn't find any web-modules. <mark_weaver>it's so terrible that gentoo is holding its users back to a version of guile that hasn't been maintained for several years <bernalex>davexunit: please don't hold the rest of us responsible for the lisp herd's mistakes. ;) <mark_weaver>and here I thought gentoo was supposed to be cutting edge. <bernalex>do any of you know why they have masked 2? <davexunit>but guile 2.0 and 1.8 can both be installed to a system <mark_weaver>probably because lilypond doesn't yet support guile 2. it's being worked on. <bernalex>mark_weaver: hm. maybe if you run ~ARCH. regular ARCH is not especially cutting edge. it's not debian sta(b)le, but quite stable. <bernalex>I'll try updating to 2.0 and see what happens, heh. <mark_weaver>bernalex: if you don't need lilypond or texmacs, I would unmask guile-2 <bernalex>I don't know what lilypond is, and I don't use emacs. <davexunit>another gentoo user here pointed out an overlay for lisp stuff, that includes an up-to-date guile <bernalex>oh right I just checked and realised my mistake. <davexunit>I can't remember what it was called, though. <bernalex>there's an overlay called lisp at least. <bernalex>not that we have overlays any more. (the name is sticking around out of habit.) <bernalex>I'm adding the lisp overlay to check it out. <mark_weaver>although they branched off from each other about 35 years ago or so <bernalex>yes, I know the history of the lisp family. <mark_weaver>but yeah, make sure you have the latest release (2.0.11) <bernalex>I haven't written scheme or cl for years though. <bernalex>I have only ever written it as part of exercises. like for SICP and land of lisp. <bernalex>overlay has 2.0.9-r1 unmasked, and 2.0.11 masked. dunno why. <bernalex>is the former OK, or should I unmask the latter? <mark_weaver>I really have no idea why anyone would prefer 2.0.9 over 2.0.11 <bernalex>apropos gentoo: I like it when I meet people who think I'm a crazy person because I run/develop gentoo. :D I mean, I get it, a lot of Gentooers are kind of crazy people. like the lisp herd, apparently. but we're loosely affiliated at best, heh. <mark_weaver>there's a lot to like about gentoo. I find the concept very appealing <nalaginrut>maybe 2.0.11 need newer libgc? But I can't remember, IIRC there's no such need <sneek>nalaginrut, you have 1 message. <bernalex>I find it to be the least terrible distro all things considered. being a dev is useful too since I can put stuff I need for my dev servers into the tree. :) <bernalex>btw, for some reason, guile 1, 2.0.9 & 2.0.11 are all in different slots. meaning they can be installed at the same time. so I assume they are rather different? heh. <bernalex>I was at FOSDEM. it impressem me a lot more than NixOS actually -- and I was expecting it to be the other way around. <nalaginrut>davexunit: yeah, it saves my time to explain each time, now I just throw your post to them, or reference on my future post <bernalex>my main problem with NixOS is that they don't take us compilers seriously enough from what I've seen. i.e. there's not enough customisation (akin to USE flags). <mark_weaver>yeah, NixOS has more packages but IMO Guix has made some major improvements on the implementation. <bernalex>then there's things like no GPG signing/verification of their stuff etc. <bernalex>NixOS has almost all of Hackage, which appeals to me, as I use mostly haskell for everything both at work and at home. <bernalex>(not that there's much a difference between work & home -- I am basically paid a monthly stipend regardless of what I do) <mark_weaver>we don't have USE flags, but it's easy to make arbitrary modifications to any part of guix by keeping one's own private branch in git. <davexunit>bernalex: someone is currently working quite hard on getting haskell stuff packaged. <davexunit>like writing a hackage importer to make the job easier <bernalex>davexunit: but don't you have a system for specifying what to "compile in"? NixOS makes it possible to express something like USE flags -- but the package writers don't actually use that to its full potential. <bernalex>davexunit: what we do in gentoo is use our tool that generates ebuilds (our package format) from cabal files. <bernalex>BTW I think nix & guix are both fantastic. I'm one of the lead devs of the gentoo pm, and you guys are leaving us in the dust. :) <davexunit>bernalex: well yeah, you can write a package expression that enables/disables whatever, but there's no notion of global on/off flags <mark_weaver>in guix, packages are first-class objects in scheme. it is easy to write procedures that take arguments (even other packages) and use them to create packages on the fly. <mark_weaver>and then we have a caching system so that if you run that procedure with the same arguments more than once, you don't have to rebuild, etc. <mark_weaver>so our foundations make it easy to support something like USE flags, but we don't actually do it in the packages we've created. <bernalex>I quite like the idea of using scheme more than the DSL of nix <bernalex>I was sad to see that development of hsnix (or whatever it was called) halted though <davexunit>bernalex: was that nix rewritten in haskell? <mark_weaver>we should probably move this discussion to #guix though *davexunit almost has a static site generator prototype working <bernalex>BTW anyone in here use weechat & happen to have a weechat plugin guide? heh <bernalex>the reason I'm using guile right now is because it's (to me) the least offensive choice of language for a weechat plugin lol <davexunit>I haven't used weechat, but I like that you can extend it with guile <bernalex>it also supports ruby, python, perl and maybe a few others. *mark_weaver didn't know that weechat supported guile extensions. nice! <bernalex>so guile is the obvious choice for me then. :) <mark_weaver>although for my purposes, it's most important to have my IRC client in emacs for more convenient cutting and pasting between other buffers, etc. <davexunit>from what I hear, it's a nice pice of software. <mark_weaver>but since guile-emacs is making such progress, I may be able to have both in a year or two :) <bernalex>that makes it a bit more challenging to get into lisps <bernalex>whenever I tried starting out, I would go to some chan on IRC and ask for advice, and everyone would just swear at me for not using slime. :) <mark_weaver>for a long time I went back and forth between emacs and vim. for several years vim was my primary editor. <bernalex>VI VI VI editor of the beast is my choice, yes. <bernalex>I hate vimscript though. so I'm waiting for neovim or yi to be useful. :) <mark_weaver>probably mainly because its support for lisp syntax is so much better <mark_weaver>I don't know how I'd live without paredit, for example. <bernalex>yes if I had to use lisp, I would use emacs too. vim doesn't even get close. <davexunit>emacs is what got me into lisp in the first place. <bernalex>but being a haskeller, the plugin support for vim is almost as good as for emacs. and I like the vim model for text editing better. <davexunit>Yukihiro Matsumoto (creator of ruby) gave a talk at LibrePlanet 2012 called "How Emacs Changed My Life" <mark_weaver>it was quite painful to learn paredit, but now that I have, I don't know how I ever lived without it. <mark_weaver>anyway, I imagine it would be possible to adapt these ideas into vim. <bernalex>vimscript is quite terrible imo. I would love an editor that used haskell for plugins. or even elm or some other language like that. a lisp would be a huge improvement over vimscript too for me. <bernalex>hell, javascript would be an improvement, but don't tell anyone I said that. <davexunit>learned a lot from that language for my Guile FRP implementation <mark_weaver>javascript may not be ideal, but it's definitely better than vimscript... <bernalex>I don't *really* like elm. but compared to its competitors, I quite enjoy it. :p <davexunit>I don't want to actually use it, but I want to take many of its ideas. <davexunit>people always talk about Elm's FRP not being "real" <bernalex>it's not. FRP is very clearly defined, and elm just isn't it. heh. <davexunit>and every time "real" FRP is described to me, it sounds completely useless. <davexunit>FRP is anything but clearly defined, if you ask me. <bernalex>FRP is a term coined by one specific paper that defines it very clearly. <bernalex>it was originally going to be called functional reactive *animation*, but that made people think too much about graphics, so it became FRP instead. <bernalex>I'm backing up conal 100% in his crusade, so I'm probably not the best person to talk to if you disagree with him. ;) <mark_weaver>it's been too long since I looked closely as Haskell. I really need a refresher. <davexunit>what Elm does is functional, it's reactive, and it's programming. <davexunit>so I say: broaden the definition, Conal's is useless. <bernalex>wel then javascript and c++ could just as well be called FRP languages. :) if we use broad definitions, they at some point become useless beyond categorisation purposes. <davexunit>you don't write C++ in a purely functional style <bernalex>purely functional != functional. and while we're at it, what's functional? another ill-defined word not more useful than "rock music". :) peter landin otoh defined "denotative programming" very clearly in a paper, so it's a far more useful term imo. haskell then becomes a denotative programming language... but even here it's a bit vague, since haskell is also quite capable of imperative programming. <mark_weaver>davexunit: I haven't studied FRP, but in general you can't break a term up into words and say that if all of the words applies to X, then the whole term applies to X. <bernalex>mark_weaver: I agree with that, but didn't bother arguing it since davexunit & I clearly disagree. :p <bernalex>it's OK. I disagree with evan (elm designer) all the time. we can all still be friends. ;) <bernalex>functional is so ill-defined that it can be used to mean most things, heh. it's just "programming with functions rather than variable state changes" really. most languages fit that bill if you want them to. <mark_weaver>it is not uncommon for the same word to have different definitions depending on context and what community you're working with. I think it's kind of silly to argue over such differences. <bernalex>mark_weaver: I just think FRP has a clear definition, so picking a different term for elm would be useful to avoid the case in point confusion. I know some people find this pedantic. but for me it is important. the way we talk about programs ultimately affects how we write them imo. :) <mark_weaver>well, agreed. maybe I'd agree with you if I knew the details, dunno! <davexunit>I'd love to see another term that could possibly describe Elm's "stuff" better. <bernalex>davexunit: I'd accept the broad term "reactive" fine. it is a "denotative and reactive programming language for authoring declarative web browser graphical user interfaces". <bernalex>davexunit: the main difference from real FRP is that elm is discrete not continuous. <davexunit>so maybe we can just slap discrete onto it, then? <mark_weaver>it might be less contentious to call it "Conal's FRP" than "real FRP" <bernalex>mark_weaver: well. really it's just FRP. :p <davexunit>I think the continuous is impractical, so I choose a discrete implementation. <bernalex>davexunit: as a pessimistic (for me) note, I think what will happen is just FRP will be another semi-meaningless term like "functional". <mark_weaver>from where I stand (admittedly ignorant of the details) this looks like a turf war. <mark_weaver>a battle over "ownership" of words and terms by one camp <bernalex>mark_weaver: I wouldn't go that far. some of us prefer referring to elm etc as reactive but not frp. others think "meh close enough" and favour watering down what used to be a precise definition. <davexunit>why not just distinguish continuous FRP from discrete FRP? <bernalex>if it's a war, it's on hacker news or somesuch site I don't read. on the elm ML and talking to conal, there hasn't been any "wars". :) <bernalex>davexunit: FRP *is* continuous by definition. :) <bernalex>mark_weaver: the definition that coined the phrase in the first place, yes. <mark_weaver>okay, but I don't accept as a general rule that the first paper to introduce a term gets to own it forever. <bernalex>mark_weaver: FRP was coined by a paper with that in the name. it was a precise definition for years before rx and elm came about. :) <bernalex>davexunit: well it would be a bit confusing at best. what's wrong with just "reactive programming with discrete events"? <bernalex>davexunit: "functional and reactive programming with discrete events" then :) <davexunit>*all* of the modeling is done using pure functions and immutable data <bernalex>though I'd rather say declarative or denotative, since "functional" doesn't say too much. <davexunit>to me, it says that the model uses pure functions and persistent data <bernalex>davexunit: ah, well most languages called "functional" are not "purely functional" at all. "purely functional" by itself is kind of hard to define -- did you know that C is purely functional? <davexunit>a "pure function" has a well accepted meaning, at least in the Scheme community. <bernalex>mark_weaver: when you write C, you are programming in the purely functional language CPP. so it is actually "technically pure" in the exact same sense as haskell + the IO type is "techincally pure". <bernalex>davexunit: the alternative then becomes that no language is purely functional at all -- which also has no benefit. :) <davexunit>Scheme isn't purely functional, but I can write pure functions. <bernalex>davexunit: BTW: I think we completely agree on what purely functional means. I'm just illustrating that words are powerful and important in programming. <davexunit>(define (double x) (* x x)) is clearly a pure function <bernalex>and to me C isn't purely functional, wheras haskell is. <bernalex>i.e. haskell minus oddities like unsafePerformIO etc. <mark_weaver>bernalex: I guess it may be true that the C preprocessor is purely functional, but to claim that this implies that C itself is purely functional seems bogus to me. <bernalex>mark_weaver: it is purely functional by the rhethoric often used to claim that haskell + the IO type is purely functional. <bernalex>mark_weaver: to me the IO type in haskell is actually purely functional though, not just via trolling to illuminate a point. ;) <mark_weaver>obviously you can write a imperative program in a purely functional language, and so it's a question of where you draw the line between the different "levels" (?) of compilation/execution. <mark_weaver>anyway, if one of the key differences between Conal's FRP and elm's FRP is that in Conal's FRP the relationships are continuously maintained, whereas in elm the relationships are maintained by discrete events or updates, then I guess I would tend to agree that the elm way is a rather poor rendition of the original concept. <mark_weaver>but I'm reluctant to say much without knowing the details. <mark_weaver>though it may be that the elm way is far more practical today. <bernalex>mark_weaver: that is one of the key differences yes. <bernalex>mark_weaver: sure, but it's a very different concept. <mark_weaver>based on that, I suspect I would agree that a different term should be used to describe elm's approach <mark_weaver>bernalex: so what is the difference in how these two approaches are implemented in practice? <mark_weaver>obviously a traditional computer is not capable of keeping everything updated continuously <bernalex>mark_weaver: a few things. in elm for instance, you have a signal, which couples a behaviour and an event. in FRP these are different types. <bernalex>then there's the difference between push and pull <bernalex>frp can be changed in response to events, and evaluation is separated from reacting. event-driven discrete reactive programming is just "signals" that have a current value that changes discretely. <bernalex>if you want essay length explanations, /msg conal ;) <mark_weaver>bernalex: where does Racket's FrTime fit in to all this? <bernalex>I do not know frtime. I am not a frontend/web dev. <bernalex>oh. I don't know racket either. apart from its design in being able to enable/disable subsets of the language, since that's something I'm looking into for a programming language we're designing at work if funded. :) <mark_weaver>FrTime is described by its primary developer as "inspired and informed by work on functional reactive programming" <mark_weaver>I need to find some time to look into this more closely. I find the ideas very compelling. *davexunit obviously likes the discrete, event-driven approach <mark_weaver>I think the last time I looked (> 10 years ago), I was of the impression that is was more of a research topic and not yet very practical for developing large scale systems. <paroneayea>mark_weaver: btw we never got to meet up in all the chaos around libreplanet... maybe next time I'm in boston, we should see about having a mini-guilers meetup <paroneayea>so I'm now at the point in opstimal where I have the fundamental infrastructure down, and I need to start writing usable tasks <paroneayea>maybe I should just look at what ansible/salt do <davexunit>(zero? (system* "apt-get" "install" package-name)) :) <paroneayea>maybe I should just do that for now and test "does it work okay enough", and tack on complexity as I go <davexunit>whatever it takes to make it run non-interactively <paroneayea>I want to do a copy-file type task that checks if the hash is the same first <paroneayea>is the best way to do that in guile to call out to shell? <mark_weaver>paroneayea: debian stores the information on the status of each package in /var/lib/dpkg/status <davexunit>paroneayea: you could write guile procedures that compute the hash <mark_weaver>I'd say that you should probably just use 'apt-get' to install a package that's not yet installed, but reading /var/lib/dpkg/status directly might be reasonable for just looking at the current state of the system. <paroneayea>davexunit: I guess I could, that would require me learning how to do that or borrowing from guix :) <mark_weaver>paroneayea: and /var/lib/dpkg/available is a text file with information on all packages that are available to install. <mark_weaver> /var/lib/dpkg/status doesn't include all available packages. it certainly includes all packages that are installed, and might also include packages that were installed in the past and have since been removed. I don't know all the details though. <paroneayea>heh, here's how salt determines that a package was installed after running apt-get <mark_weaver>I suppose in theory using /var/log/dpkg.log could be complicated by the possibility of rotating logs at the wrong time. <paroneayea>mark_weaver: I guess another way is to hash /var/lib/dpkg/status, see if it changed after install <paroneayea>that should give a clear indication if it did anything right? because if it stays the same, nothing should happen to the file. <mark_weaver>paroneayea: are you just trying to determine the 'apt-get' succeeded? <paroneayea>mark_weaver: so I have a few states for each "result" from each task <paroneayea>since you really need to know whether or not the task ran and changed something, ran but nothing changed, or failed <paroneayea>eg, if you imagine make-like rules, you want to know whether something changed or not. <paroneayea>skipped was originally in case a user gave a condition that said maybe skip this task conditionally, but I've been thinking there's little need to separate that out <mark_weaver>just because that changes doesn't mean that the entire operation succeeded. <mark_weaver>in general, when installing a package that has many dependencies, it is quite possible for some of the dependencies to be installed and then one of the post-install scripts fails. <paroneayea>that's true, but maybe the return code can tell whether it failed or succeeded <mark_weaver>you really need to look up the status the package(s) that you asked to install. <mark_weaver>sure, the result code from 'apt-get' would hopefully be sufficient <mark_weaver>you probably need to pass some option to 'apt-get' to suppress interactive questions. <paroneayea>yeah I've figured out what those are by reading the salt source :) *mark_weaver is in the process of moving from Debian to GuixSD, and have already moved all my machines except for my server. ***Carisius is now known as Carisius_
***Carisius_ is now known as Carisius
<bernalex>lovely. newest guile fails to compile here. I assume someone has dun goofd. bunch of './.libs/libguile-2.0.so: undefined reference to's related to threads. <mark_weaver>maybe try just downloading our tarball and compiling it manually? <paroneayea>davexunit: it looks like the hash functions call out to libgcrypt in guix <davexunit>it's just nice to call out to libraries rather than have to go through the shell <bernalex>mark_weaver: currently recompiling it without threads, because I don't need them anyway. I'll file a bug to the overlay or whatever. <davexunit>really opens up the possibilities of what you can do with guile <mark_weaver>there are also pure scheme implementations of several hash functions in weinholt's industria library <paroneayea>looks like the guix modules call other guix modules <mark_weaver>though for hashing large files it might not be fast enough, dunno <paroneayea>so I'll have to modify them to consolidate, not super exciting for long-run maintainance, hm <paroneayea>mark_weaver: yeah I think an efficient implementation probably matters here <bernalex>seems to compile fine without threads so far. <davexunit>that I want to package in guix for use with guile <davexunit>we need to make it easier for guile folks to use it <paroneayea>davexunit: the userops conversatiosn are making me consider more about language packaging <paroneayea>because relying on language packaging kinda has gotten us into a mess, on the other hand we can't really expect everyone to be running guix right now, esp non gnu/linux users <davexunit>language packaging has a use-case, and I want the guildhall to be good. <davexunit>I just don't want to rely on language packaging for anything important :) <paroneayea>so I think for opstimal initially I'm going to use Sphinx with texinfo export support like we do in mediagoblin, but maybe when I have more time or if someone volunteers, maybe we could use texinfo by default <paroneayea>there's some advantage to using sphinx in that it has good default html export and I don't have to learn how to do anything special to get it :) <paroneayea>I do love having good texinfo support though. I don't think there's a way to get nice indexing in sphinx that's comparable <bernalex>mark_weaver: the author of the ebuild doesn't know how slots work. I think. <mark_weaver>it's almost comical how bad the guile packages are in gentoo <bernalex>"oh you have guile 1.8. so 2.1.1 has file collisions. so let's delete a few of those files making 1.8 useless. but I can't delete all of them. oh. ok. so I'll delete the program I just spent 20 minutes compiling. and then recompile guile 1.8 since I broke that." <mark_weaver>delete what program that [I] spent 20 minutes compiling? <bernalex>preparing to install guile without threads and without 1.8 present. I'm glad I have a very fine wit beer here. <bernalex>mark_weaver: I was speaking as if I were the package manager. it compiled guile 2, discovered file collisions, tried to fix them, broke guile 1.8, was unable to fix them entirely, deleted guile 2 which it just had compiled, then proceeded to rebuild guile 1.8 since it broke that when trying to fix file collisions. <bernalex>I don't even. I remember sbcl was a nightmare too. maybe the lisp herd is clueless, maybe all lisp upstreams are clueless, maybe the lisp ecosystem is really difficult to manage, or whatever. I don't know enough about it other than how unpleasant it is to use on gentoo. :p <mark_weaver>all the other major distros have guile-2.0.x packages that are painless to install <bernalex>but do they rely on downstream hacks to do it? gentoo has a very strict "stick to upstream" regime, so I could almost forgive this if upstream sucked. <paroneayea>(with-output-to-string (lambda () (system* "sha256sum" "/home/cwebber/org/life.org"))) <bernalex>I would *asssume* it's not upstream's fault here though. guile is quite popular/well-known after all. <paroneayea>but I guess it doesn't write stdout to the current output port <mark_weaver>bernalex: there are some caveats to the "guile-2.0 is co-installable with guile-1.8", so that requires some managing. ***karswell` is now known as karswell
<mark_weaver>but if you don't have 1.8 installed at all, then upstream 2.0 should compile out of the box on any reasonable GNU/Linux system <davexunit>paroneayea: you'd need to use a pipe for that <bernalex>mark_weaver: I'm installing 2 without 1.8 now, heh. <davexunit>paroneayea: one of the reasons why using a library is nicer. no subprocesses. <mark_weaver>in brief, the libraries for 2.0 and 1.8 have different names, and store their files in different directories. however, the programs have the same names by default, and the C header files are in the same place. <bernalex>mark_weaver: I don't need 1.8 really, but I didn't think to uninstall it, because if something is slotted, it's slotted because, well, it's supposed to actually work and stuff... lol <mark_weaver>so for binary distros that have separate *-dev packages for C includes etc, you can't have guile-2.0-dev and guile-1.8-dev installed at the same time. <mark_weaver>but you can install the non-dev packages simultaneously, and iirc debian manages this by adding suffixes to the names of the programs and installing symlinks without the suffixes using their "alternatives" system. <mark_weaver>but yeah, in a distro like gentoo, I suspect they are not really co-installable. <bernalex>mark_weaver: something similar is sometimes done in gentoo too. we have a tool for managing "active" versions of software. i.e. we'd install python2.6, python2.7 and python3.1. binaries, and then you'd have python2 and python3 as symlinks, and finally python as another symlink. then you select which version to have active. something like this shouldn't be impossible for guile either. I suspect the real issue <bernalex>here is that the slotted guile2s in the overlay are not at all compatible with the slotted guiles in the main tree. which is a big no-no for an overlay. <bernalex>mark_weaver: OK I finally have guile2. so uhm howto? I thought (http-post "http://9m.no/create" "url=test") was right, but evidently not <mark_weaver>wow, did you build it with POSIX disabled or something? <bernalex>doubt that's possible. seems I need to build it with networking? <bernalex>at least that's my guess. doing that now. <bernalex>mark_weaver: in any event, how am I supposed to pass args to my POST? <mark_weaver>but if you don't have getaddrinfo then you're already hosed. <bernalex>mark_weaver: I didn't check. I'm assuming I need the networking USE flag for networking interfaces. <bernalex>given that regex & threads is enabled by default, it seems a bit nonsensical to not enable networking by default. <mark_weaver>I really don't know why anyone would want to build guile without these features. <mark_weaver>it's almost as if the author of this ebuild wanted to make guile look as bad as possible. <mark_weaver>I think you should ditch this ebuild and build from upstream source. what's the advantage to using the ebuild? <mark_weaver>or, since you're a gentoo dev, maybe you could write your own ebuild to replace that crap? <bernalex>I don't have to pay attention to updates. <bernalex>I don't really write ebuilds. I find the format horrible. :p I just work on tools. <paroneayea>it's a little bit too bad I don't think opstimal will be as easy for users to install if I included guix as a dependency <paroneayea>because there are a lot of guix things that would be nice to use <paroneayea>but installing opstimal to, say, a vanilla debian system... probably not so easy to install that and guix <paroneayea>unless guix were already packaged on most distros <wingo>so is there a worse name for "functional vector" than "fector" <mark_weaver>it's not as though adding network support to guile requires any additional libraries, and the extra compile time would probably be too small to measure with a stopwatch. <paroneayea>Uncle Fector was a good character in The Addams Family <bernalex>mark_weaver: in general I am in favour of minimalistic defaults. but if regex is on by default, I don't see why networking wouldn't be. <mark_weaver>really, the only reason we even allow disabling those things is to improve portability to non-POSIX systems. <mark_weaver>although at this point, gnulib gives us what we need to support those things on windows anyway. <bernalex>mark_weaver: yes it strikes me as a feature that doesn't make sense to have toggleable in the first place, but for portability like you describe it's probably reasonable. <mark_weaver>bernalex: does the gentoo python package build without networking by default? <ijp>wingo: I didn't coin that for my package, I took it from dvanhorn <ijp>who probably took it from somewhere else <wingo>ijp: i had no idea you had such a package already! <wingo>i just looked at your pfds and didn't see fector <ijp>fector is separate because it isn't technically persistent <ijp>sequences is the closest analogue <bernalex>mark_weaver: how do I use both headers & body? <paroneayea>which would expand into "/home/cwebber/org/life.org" <davexunit>paroneayea: you'd need to write a procedure that substitutes "~" for (getenv "HOME") <davexunit>~ is a special thing your shell processes, like * <bernalex>(http-post "http://9m.no/create" #:headers '((Content-Type . "application/x-www-form-urlencoded")) #:body "url=test") ; apparently you don't use body like this. how do I use it properly? the response I get is "param url not found" <davexunit>paroneayea: did you implement 'absolute-file-name' yourself? <paroneayea>which is to say, every other I've run into that with ;) <davexunit>I imagine there's a case or two I didn't handle <bernalex>mark_weaver: web/http.scm:188:11: Bad uri header component: /show/é«á£® <bernalex>mark_weaver: www-client doesn't understand unicode <bernalex>mark_weaver: it actually returns what I want <bernalex>web client (no hyphen) to be even more correct <bernalex>mark_weaver: this returns a header with an URL. the URL has unicode. I need that URL. <bernalex>http.scm:188:11: In procedure read-header: web/http.scm:188:11: Bad uri header component: /show/é«á£® <mark_weaver>understood, but I'm not sure bare unicode is allowed in HTTP headers, is it? *wingo pretty sure bare unicode usually not allowed in headers <bernalex>I'm not sure if it's allowed or not. I still need it, heh. <wingo>e.g. if a header is specified as a url, the url needs to be url-escaped <wingo>bernalex: it's possible to define a custom header parser but in this situation it sounds like the server is producing garbage <bernalex>wingo: no, what the server produces is perfectly reasonable and usable. <wingo>bernalex: can you paste.lisp.org the raw response from a successful post? <bernalex>wingo: I don't know what you mean by "raw response" <wingo>i mean if you telnet to the server, make your post, what do you get back <wingo>the raw http response as a sequence of ascii bytes. <bernalex>wingo: I don't have telnet installed, heh. <wingo>(non-ascii bytes are not allowed in http headers.) <wingo>then sorry, you don't have a valid bug report :) <mark_weaver>bernalex: wget --save-headers might be sufficient for this <bernalex>I think I can do it with curl too, let me try <wingo>yeah the server should be escaping non-ascii characters <bernalex>I'll look into fixing the server, I guess. <wingo>heh, sounds like a drag, sorry for the terrible answer :) <bernalex>it's OK. at least it's haskell, so I can fix it. :p <bernalex>mark_weaver: web/http.scm:188:11: Bad uri header component: /show/%E8%82%8B%F0%93%8D%85 <mark_weaver>bernalex: guile's parsing of Location headers was based on the now obsolete RFC 2616 section 14.30, which required it to be an absolute URI. However, RFC 7231 section 7.1.2 allows it to be any URI reference, which can include relative URIs. <mark_weaver>it's already fixed in our stable-2.0 branch, which will be in guile-2.0.12 <mark_weaver>but giule-2.0.11 requires that it be an absolute URI. <bernalex>mark_weaver: riiiight. how can I circumvent this then? lol <mark_weaver>I think what happened is that servers didn't follow the RFCs, most clients are very permissive, and the practice became widespread enough that the RFCs were changed to allow it. <mark_weaver>we have code in Guix to resolve those redirections and automatically follow them as well. we should integrate that code into Guile. <bernalex>mark_weaver: do you? my next step here is to just print the location URL <bernalex>$22 = #<<response> version: (1 . 1) code: 302 reason-phrase: "Found" headers: ((transfer-encoding (chunked)) (date . #<date nanosecond: 0 second: 22 minute: 56 hour: 21 day: 11 month: 4 year: 2015 zone-offset: 0>) (server . "Warp/2.1.5.2") (location . #<<uri> scheme: #f userinfo: #f host: #f port: #f path: "/show/%E8%82%8B%F0%93%8D%85" query: #f fragment: #f>)) port: #<closed: file 0>> <bernalex>I need to print that /show/%E8%82.... path