IRC channel logs


back to list of logs

<nalaginrut>morning guilers~
<wleslie>zacts: tubular!
<zacts>guile hey
<zacts>wleslie: hey
<zacts>oh you are on #python too
<wleslie>both awesome languages
<wleslie>these are the public freenode channels I join, lots of awesome languages
<zacts>oh nice!
<wleslie>oh oasis is not a language, actually that channel is dead
<zacts>isn't that what coyotos used?
<zacts>is it still around?
<wleslie>it was originally created for coyotos, but coyotos was written in C anyway
<zacts>oh interesting
<wleslie>bitc pushes forward, slowly
<amz3>héllo nalaginrut and everybody
<amz3>I've looked around to implement a markdown parser in guile, I think the quickest safest thing to do is to bind the original markdown parser shipped with debian
<amz3>I tried parser combinators, but this requires more time to get right
<amz3>anyway, we can't improve that later
***michel_mno_afk is now known as michel_mno
<amz3>or we can use the outline mode of skribillo
<amz3>there is not much text right now (except the manual) so I will go with what haunt provides and see next
<nalaginrut>amz3: well, that's a need, markdown parser
***michel_mno is now known as michel_mno_afk
<zacts>^ perhaps you could reference this one from racket?
<zacts>but it's a BSD license and not GPL
<ArneBab_>most BSDs (2-clause and 3-clause) are GPL-compatible
<ArneBab_>it’s a 2-clause:
***michel_mno_afk is now known as michel_mno
<amz3>thx zacts
<davexunit>"The Promise of Relational Programming" with William Byrd
<davexunit>ACTION thought about writing guile-yaml, but is grossed out by the yaml specification
<dsmith-w`>Happy Friday, Guilers!!
***dsmith-w` is now known as dsmith-work
<paron_remote>davexunit: oooooooooooooooh
<paron_remote>davexunit: watching
<davexunit>I'm not going to do it. YAML is too terrible.
<davexunit>someone else can do it.
<davexunit>why YAML is so widespread is beyond me.
<paron_remote>davexunit: because sexps scare people and json doesn't allow comments and it's better than .ini files and less work than proper xml? :)
<davexunit>maybe that's it ;)
<davexunit>this specification is *massive*
<davexunit>the parsing rules are insane.
<taylanub>why isn't there an amendment to the JSON spec for comments yet? that would solve a big part of the issue...
<davexunit>why not just sexps while we're at it! :)
<paron_remote>taylanub: every time I say this people say BUT JSON IS FOR DATA
<davexunit>just use*
<davexunit>what I've learned is that people are hostile towards "code is data, data is code"
<wleslie>"comment" : "this object smells like garlic",
<wleslie>if you're really duck typing, that will pass by in many places unnoticed.
<davexunit>and that's how we end up with jinja2 YAML templates in Ansible.
<paron_remote>davexunit: yup
<paron_remote>davexunit: to be fair, I understand that when serializing state (as opposed to config), you might not want the state stuff to be serialized in a turing complete language, or things with reader macros, etc
<paron_remote>so as to avoid people hiding viruses in your state, etc
<paron_remote>so having a subset of scheme that's data-only, it makes sense
<paron_remote>but for config at least
<dsmith-work>wleslie: Such a sad thing that dsssl went away. xslt is ugly
<wleslie>and css is even worse.
<daviid>mark_weaver: are you a member of the g-wrap-dev mailing list ?
<mark_weaver>daviid: hi! I don't believe so.
<daviid>ok, because dak responded, see here:
<mark_weaver>I don't have time to look at this right now, but I'll try to do so later.
<daviid>sure, just wanted to let you know. i should also inform civodul, or maybe you can?
<mark_weaver>yes, civodul is the one who changed guile to use bdwgc, so he's the relevant expert on this issue.
<daviid>sneek: later tell civodul did you see this
<sneek>Will do.
<daviid>mark_weaver: ok, i see yu've been involved quite a lot in the thread dak refrs to, so ... but now civodul [who i don't know if he's following g-wrap either] will be informed. i was a bit reluctant to foward his mal to guile-devel ...
***michel_mno is now known as michel_mno_afk
***cluck_ is now known as cluck
<davexunit>paron_remote: figure we should continue talking about parsing org-mode with guile here.
<davexunit>wingo wrote something that parses a subset of org-mode awhile ago, and I hear that Skribilo has an outline-mode style parser, so we've got something to work with.
<davexunit>time to reiterate my desire for parser combinators. I should just upload the thing I hacked together and have people tell me what's wrong with it. :)
<paron_remote>davexunit: oh cool
<amz3>I'm trying to figure guile-log parser combinators, the api is nice. For instance, you don't have to manage line/column (for debug), it's done by the library
<amz3>the markdown parser proposed earlier use combinators
<dsmith-work>org-mode is wonderful, but I've heard that it's really nasty to parse.
<amz3>it's written for racket, the article is an easy step into the topic
<amz3>it explains how to code the grammar/parser
<davexunit>amz3: where is this implementation?
<davexunit>the guile-log thing
<amz3>there is a dependency
<davexunit>I'll have to upload my simple parser combinator library.
<amz3>I yes, I'm interested, so far what I've read about it is pretty simplisitic in terms of implementation
<amz3>seems like a powerful thing that can be expressed simply (with naive implementation)
<davexunit>there's some really hard stuff to implement to handle certain types of grammars
<davexunit>my implementation doesn't deal with them
<davexunit>not sure if it even should.
<davexunit>I wonder how terribly mine performs since I use srfi-41 streams
<amz3>compared to raw parsing it easier to implement, it's just a feeling
<davexunit>it's way easier
<davexunit>it makes parsing make sense to me.
<davexunit>I use port->stream when parsing from a port to remove any logic having to deal with backtracking in a file
<davexunit>the library just accepts any stream
<amz3>I lost my sens a long time ago ; )
<amz3>you don't backtrack ?
<amz3>amz3 | I lost my sens a long time ago ; ) >> especially regarding parsing LL thing and stuff was the most difficult course I've done
<davexunit>well, I *do* backtrack, but it doesn't require rewinding the port that's being read from
<davexunit>I just turn the port into a lazy stream of characters
<davexunit>makes things pure.
<amz3>I did not know it was possible to backtrack streams
<davexunit>a stream is like a list
<amz3>it's a list that read lazily with a cache, that's it?
<davexunit>in the case of port->stream, yeah.
<amz3>hmm, I see
<davexunit>backtracking is simply holding onto the stream-cons cell that you want to backup to
<amz3>I did not see the intereset of that the "memoization" feature of streams
<amz3>before you explain that
<davexunit>streams allow to you represent infinite series in an elegant way, too.
<amz3>I'm used to generators, which forget about past values (by default)
<davexunit>(stream-cons 0 (stream-cons 1 (stream-map + fib (stream-cdr fib))))
<davexunit>fibonacci series
<amz3>is it memory bound?
<davexunit>well, you can only calculate so many before your system runs out of ram.
<davexunit>but of course values no longer referenced can be GC'd
<amz3>I think it's called lazy-seq in clojure
<amz3>I use
<amz3>(define multiples-of-three
<amz3> (let next ((n 3))
<amz3> (lambda ()
<amz3> (values n (next (+ n 3))))))
<davexunit>different languages use different names
<davexunit>but yeah, it's all the same stuff
<amz3>the above construct to create infinte lists without memoization
<davexunit>a list whose tail is lazily evaluated
<davexunit>amz3: that's caching values, too, a.k.a memoization
<amz3>multiple-of-three doesn't cache values
<amz3>In python, I like to use it to simplify complex loops
<amz3>loops where components must be computed every iteration, like enumerate but more advanced
<mark_weaver>davexunit: amz3 is correct, 'multiples-of-three' doesn't do memoization
<mark_weaver>amz3: fwiw, if you don't hold a reference to the head of a stream, then the earlier elements can be freed.
<davexunit>then what's the thunk for?
<mark_weaver>davexunit: to delay the evaluation
<davexunit>ok nvm
<davexunit>yes i know
<davexunit>okay so it doesn't hold onto the computed values
<mark_weaver>but it will be recomputed every time. there is no memoization.
<davexunit>obvious now
<davexunit>not sure what I was thinking
<mark_weaver>don't worry about it, we all make thinkos :)
<mark_weaver>I certainly do, anyway :)
<mark_weaver>okay, gotta go afk...
<davexunit>I do it constantly, as you can see.
<amz3>davexunit: :)
<amz3>davexunit: there is also
<amz3>but I did no manage to run it
<amz3>even guile-log I had to ask stis for help
<amz3>I think he fixed the issue with guile log
<amz3>mark_weaver: multiple-of-three construct is meant to be simpler than streams to manipulate (avoid streams-cons and friends)
<amz3>I think it's simpler
<mark_weaver>amz3: on the other hand, there is a major advantage to standardizing on one stream type, so that all code that produces/consumes streams can interoperate
<mark_weaver>it's not obvious to me that your way is simpler, but if it is, it is only marginally so. the interoperability issue is far more important, IMO.
<amz3>I agree