IRC channel logs


back to list of logs

<mark_weaver>I have to go afk very soon.
<bernalex>np. thanks for yr help so far. :)
<mark_weaver>but basically use 'response-headers' to get the header alist, then 'assv-ref' to look up the location header, and then 'uri-path' to get the path from the uri object.
<mark_weaver>and 'uri-decode' to decode it.
<mark_weaver>sorry, not 'uri-decode'. use 'split-and-decode-uri-path'
<mark_weaver>gotta go!
<mark_weaver>happy hacking
<bernalex>thanks :)
<bernalex> (assv-ref "path" (response-headers (http-post "http://localhost:7000/create?url=test" #:headers '((Content-Type . "application/x-www-form-urlencoded"))))) ; is this right? it gives me #f
<bernalex>but this fails: (uri-path (assv-ref "path" (response-headers (http-post "http://localhost:7000/create?url=test" #:headers '((Content-Type . "application/x-www-form-urlencoded")))))) ; wrong type argument in position 1 (expecting struct): #f
<mark_weaver>more like (assv-ref (response-headers ...) 'location) to get the uri object
<mark_weaver>and then 'uri-path' to get the path portion of the uri object
<bernalex>oh derp
<bernalex>of course
<bernalex>ah yes! wonderful!
<mark_weaver>I'll try to look here every once in a while, but I have to be mostly afk for a while...
*davexunit has a working, barebones static site generator
<davexunit>example config:
<davexunit>of course, all of the actually useful stuff is yet to be written: markdown reader, robust blog generation, js/css/image asset support, atom feeds, etc.
<paroneayea>davexunit: there seems to be tools for expanding filenames in scsh
<davexunit>oh cool
<davexunit>makes sense
<davexunit>it is a shell, after all.
*paroneayea nods
<davexunit>nice. steal that sucker.
<paroneayea>maybe I should reformat this and submit it as a patch to guile?
<paroneayea>seems like something guile should have.
<paroneayea>plus, maybe it's something I could actually accomplish :p
<davexunit>I think many people would like that
<davexunit>my static site generator can create atom feeds now. :)
<paroneayea>davexunit: :D !
<davexunit>if I can add static asset support and a basic blog theme, things will be pretty decent.
<paroneayea>oh hey look davexunit
<paroneayea>that copying header is a bit strange though
<paroneayea>*checkout*/guile/guile-scsh/COPYING?root=guile seems to imply it's free though
<davexunit>Olin Shivers is quite the character
<mark_weaver>we'd have to some of that license text to our documentation and such... certainly doable, but given how simple the job is, I'm not sure it's worth it for just this one procedure.
<mark_weaver>what jobs does it do? there's not much to expanding a filename.
<paroneayea>mark_weaver: lists all the jobs it does
<paroneayea>quite a few it seems
*mark_weaver looks
<paroneayea>it might be worth it. I could see myself using most of these.
<paroneayea>python has analogues of most of these functions
<paroneayea>oh, he worked on T with JAR
<mark_weaver>I'd be curious to see the implementation. is it built upon things we already have in guile, or would we have to bring in a bunch of other libraries? e.g. when it looks up home directories for ~ expansion, how does it do it?
<mark_weaver>also, I'm not sure I agree with 'file-name-absolute?' returning #t when the filename starts with ~
<mark_weaver>filenames can contain ~
<mark_weaver>they are only special if you intend to apply tilde expansion to the filename
<paroneayea> well I guess it depends, has ice-9 receive, srfi-13, stayed the same? the two scsh ones seem to be let-opt and syscalls as libraries
<paroneayea>I'd be happy to have a more guile-specific one but when considering ./foo/ vs ../foo vs ~/foo/ vs ~foo/foo
<paroneayea>seems like a lot to consider to get it "right"
<paroneayea>also, haha
<paroneayea>;;; Ugh.
<paroneayea>(define (substitute-env-vars str)
<mark_weaver>hmm, looking at the copyright notice, I think it's not free software.
<mark_weaver>"as long as you don't charge money for it|
<paroneayea>that's my concern
<paroneayea>the COPYING file seems free
<paroneayea>but maybe the header is "bad enough"
<mark_weaver>the COPYING file doesn't matter. what matters is the copying permission notice on the file itself.
<paroneayea>the scsh official source (which I have open, not the guile port)
<paroneayea>doesn't say this.
<paroneayea>it says more simply:
<mark_weaver>honestly, I don't think it's worth it. it's just not that hard to write these procedures
<paroneayea>;;; Code for processing Unix file names.
<paroneayea>;;; Copyright (c) 1992 by Olin Shivers (
<paroneayea>;;; See file COPYING
<paroneayea>which is fine
<paroneayea>mark_weaver: you are probably right
<mark_weaver>interesting, so who added that bizarre copying permission notice to the guile port?
<paroneayea>I'm not sure.
<paroneayea>not all of them have it.
<paroneayea> maybe ghuouston? I don't know.
<paroneayea>but anyway, hum.
<mark_weaver>I recently wrote code to resolve the .. and . components of a path
<mark_weaver>it's in guix
<mark_weaver>let me dig it up..
<mark_weaver>see the inner procedure 'remove-dot-segments' in
<mark_weaver>feel free to snarf it
*davexunit will probably snarf it for a project, as well
<mark_weaver>it takes a list of path components (strings), not a single string
<paroneayea>mark_weaver: aha great thanks!
<mark_weaver>and returns the same.
<mark_weaver>to convert a string into a list of path components, just use (string-split <path> #\\/)
<mark_weaver>for a filename starting with /, the first element of the list will be "", which is what 'remove-dot-segments' expects.
<mark_weaver>actually, there is one rather odd aspect of that procedure, but it's what RFC 3986 section 5.2.2 mandated:
<mark_weaver>for relative paths, the leading '..' components are simply removed
<mark_weaver>but that weirdness is easy enough to remove
<mark_weaver>just change the (or "." "..") to "."
<mark_weaver>it might also turn a single "." into the empty string
<mark_weaver>it precisely follows the algorithm specified in the RFC, but may need a few tweaks to be appropriate for this purpose
<mark_weaver>hmm, I guess leading .. components need to be removed before running the loop and then added back at the end
<mark_weaver>well, it's a start anyway :)
<civodul>Hello Guilers!
<wingo>morning civodul :)
<ijp>are those the same as clojure vectors? the shifting/masking looks familiar
<wingo>they are
<wingo>it's an optimization of intmaps for push/pop workload and packed vectors
<wingo>the same threadsafety model as clojure too
<davexunit>wingo: it's... glorious!
<davexunit>wingo: is this one more like clojure's vector, as opposed to the intmap?
<paroneayea>oooooooh exciting
<davexunit>wingo: also, do you anticipate this going into guile core anytime soon?
<paroneayea>"yes please" :)
<paroneayea>it would be great to have more immutable types builtin to guile core.
<wleslie>also available over https.
<paroneayea>so out of curiosity I looked at how long expand-file-name is in emacs' code. Granted, it's C
<paroneayea>675 lines long :)
<paroneayea>granted, plenty of #ifdef but
<davexunit>wingo: a couple of procedures to make using fectors easier
<wingo>davexunit: dunno, need to compare more to vlists and know tradeoffs, but it could go in yeah
<davexunit>list->fector and fector
<wingo>davexunit: tx :)
<davexunit>transients are cool
<davexunit>thanks mr. hickey
<wingo>seems to cost 129 ns per add!, on transients
<wingo>er, push! i mean
<wingo>400 ns per push! on persistents
<wingo>at least on master
<wingo>on stable-2.0, 280ns / 530ns
<wingo>vlist insertion appears to be faster (112ns)
<davexunit>hmm, interesting
<wingo>well, it's the case vlists are optimized for, so it makes sense
<davexunit>oh okay
<davexunit>then nvm, not suprising :)
<wingo>i am showing that vlist-ref is faster too, on a vector of 1e6 elements
<wingo>76ns vs 160ns
<wingo>160ns for a ref seems like a lot
<davexunit>another simple addition: fector->list
<wingo>better to (fector-fold-right (lambda (n val tail) (cons val tail)) fector '())
<davexunit>wingo: oh okay
<wingo>probably faster too because it do smarter things
<davexunit>I see that now
<davexunit>thanks a bunch
<davexunit>this is fun to play with
*wingo goes out to play in the garden
<paroneayea>davexunit: maybe a fun thing to do in haunt
<paroneayea>would be to call emacs with -nw -q and some arguments to export html from orgmode to a very minimalist html file, pull out the body and title and things you need, then insert that into the theme you have
<paroneayea>that way blogposts could be written in org
<davexunit>paroneayea: I'll give it a shot
<paroneayea>in the glorious future when bipt merges guile-emacs you could maybe call the orgmode exporter from guile directly ;)
<paroneayea>davexunit: cool!
<davexunit>oh, actually, I had some issues last time I had considereed the org-mode html export option
<davexunit>it exports a full document
<davexunit>in my case, a full document doesn't cut it. I suppose I could re-parse the HTML and only keep the body
<davexunit>I haven't yet tested sxml's ability to parse HTML
<davexunit>I also don't know to how to handle metadata
<paroneayea>aha :)
<davexunit>I currently have a pure SXML file format, where the post is just scheme code that evaluates to an alist with metadata and sxml content
<davexunit>and a raw html format
<davexunit>where the metadata is in "key: value" format at the top, with a "---" line to mark the start of the content
<paroneayea>davexunit: you could look at ox-html.el
<paroneayea>davexunit: much could be used of the top org-export-define-backend 'html
<paroneayea>and make a 'minimal-html that just overrides the "template" key in the alist
<paroneayea>with a function that does less
<paroneayea>I believe, anyway!
<paroneayea>look at org-html-template for the current function, but you could make a version that replaces that with something simpler
<davexunit>paroneayea: oooh neat
<davexunit>that might do the trick
<davexunit>well, time to go for a long drive to visit my parents.
<paroneayea>davexunit: glhf
<daviid>mark_weaver: hi! why do you drop, the last component of the base-path in merge-paths, in guix? i would understand drop if "", but it seems you drop no matter what: just curious
<daviid>guilers, in the manual, i read, string-join, infix: ... "An empty string will produce an empty list."
<daviid>should it not be "... An empty list will produce an empty string."?
<mark_weaver>daviid: the base-path is the pathname part of the base URL, so something like
<mark_weaver>and then rel-path might be something like bar.html
<mark_weaver>so obviously I need to drop the foo.html to form
<daviid>ah or, i was assuming linux path...
<mark_weaver>and if the base-path is something like
<mark_weaver>then the last component is ""
<mark_weaver>so it still should be dropped
<mark_weaver>actually, in the example i gave, the base-path would be something like /philosophy/foo.html
<daviid>if it is though it will drop philosophy, or is it mandatory to have the trailing "/"
<mark_weaver>by this point, the / will be there
<mark_weaver>if is truly the URL, then dropping the philosophy would be the right thing
<mark_weaver>but actually that URL would redirect to
<mark_weaver>also, I should mention that I simply followed the algorithm specified in the RFC.
<mark_weaver>well, I emulated it, anyway. I did it a bit differently but with the same results (assuming I made no mistake)