IRC channel logs


back to list of logs

<nalaginrut>morning guilers~
<nalaginrut>The network policy became tight in China, maybe I have to find/build a new mailing list rather than googlegroup...
<nalaginrut>oh, my blog is down, inside...
<slucx>nalaginrut: Are you chinese?
<nalaginrut>slucx: yes
<civodul>Hello Guilers!
<davexunit>hey civodul
<davexunit>someone wrote a little blog post about their first guile script and it made it to the front page of hacker news.
<davexunit>oh hey, it's from 2012.
<davexunit>just realized that.
<civodul>to anyone looking for a cool hack:
<civodul>in short we'd need a way to add the contents of select .go files to the 'guile' binary
<davexunit>so I wrote a very simple static file web server the other day. has anyone else written such a thing for guile? it's quite short, but I'd like to release it in some form for others to use/improve.
<civodul>davexunit: wasn't there one in the examples wingo wrote back then?
<civodul>it's certainly useful anyway
<civodul>oh no there wasn't
<davexunit>civodul: there could be and I overlooked it.
<civodul>would be worth adding it to examples/web
<davexunit>the only external requirement of my server is the 'file' program, in order to guess at mime types.
<civodul>ok, that's reasonable
<davexunit>okay, so submitting it as an example would be the right thing to do, cool.
<davexunit>I wanted a replacement for 'python -m SimpleHTTPServer' that I use frequently.
<civodul>or maybe that could even be a module under (web ...)?
<civodul>so one can do guile -c '(@ (web server simple) serve)'
<davexunit>yes, that would be great.
*davexunit adds to TODO list
<nalaginrut>davexunit: Artanis could handle static files and the MIMEs properly
<davexunit>thanks civodul
<davexunit>nalaginrut: artanis is far more robust than what I'm after. ;)
<davexunit>I am curious at how you do mime type detection. it seemed to me to not be worth it to write myself, and let 'file' do it.
<davexunit>file actually inspects the contents of a file. I was just doing regexp matches on file extensions before.
<nalaginrut>davexunit: I generated a list from /etc/mime.types, then generate a hash table when init Artanis server
<nalaginrut>anyway, you man copy the list in mime.scm
<nalaginrut>don't write it yourself, it's terrible ;-P
<davexunit>nalaginrut: thanks
<nalaginrut>np ;-P
<davexunit>civodul: that sounds like a really cool hack for the hurd
<nalaginrut>although there's way to query from /etc/mime.types, I think my approach is faster
<nalaginrut>oh, I should update my Hurd these days
<nalaginrut>I haven't played it for a while ;-D
<davexunit>nalaginrut: I think I will take this table and make some tweaks so I can remove the dependency on 'file'
<davexunit>though 'file' is still more robust so I'm tempted to continue to use it, but eliminating a point of failure is more worth it.
<davexunit>civodul: so some of the compiled guile source files need to be shoved into the guile binary because the hurd bootstrap doesn't have a file system to read from?
<nalaginrut>davexunit: take it as you will ;-P
<davexunit>nalaginrut: nice looking manual!
<davexunit>ah, it's an org file.
<nalaginrut>davexunit: Thanks! I'm fighting for it these days, my wife band my PS4 unless I released Artanis first ;-(
<nalaginrut>org-mode is very nice, I love it
<nalaginrut>till now, all the related things are build with Scheme, except and Makefile
<nalaginrut>the site is built with Hyde of Chicken Scheme, a very cool static page generator
<davexunit>I want to write a guile version of that. :)
<davexunit>too many projects!
<nalaginrut>and the manual is built with org-mode
<nalaginrut>after Artanis-0.0.1 released, I'll concentrate on compiler hacking, guile-lua
<davexunit>nalaginrut: I see that you an experimental sexp->sql converter?
<nalaginrut>davexunit: yes, SSQL
<davexunit>you have*
<davexunit>what are your feelings about it? I'm having trouble reconciling the differences in sql syntax amongst the various databases, and the handling on infix, postfix, prefix syntax.
<civodul>davexunit: exactly; but that would also be helpful for Guix, in fact
<nalaginrut>well, it brings better indentation in editors
<davexunit>civodul: what would we use it for in guix/
<nalaginrut>if you write literal SQL, it's a string
<davexunit>yes. I want an sexp represtation of SQL so that I can use quasiquote and automatic escaping of input to prevent SQL injection.
<nalaginrut>yes, but there's extra tools to prevent SQL-injection in SQL-mapping
<nalaginrut>hmm...I haven't done the part of manual
<davexunit>what more could you need?
<nalaginrut>and it could let you define your function for detecting/eliminating SQL-injection issue
<nalaginrut>well, if you ask it seriously, I confess there'd be a powerful server-core in Artanis, it's in TODO
<nalaginrut>but, there're so many things in TODO now...alas
<nalaginrut>I guess it could be done in 0.1 or 0.2
<davexunit>TODO lists can only grow, not shrink.
<davexunit>I'm personally stuck on one problem that blocks sly 0.1 from being released.
<nalaginrut>davexunit: I want to write a MMO game with sly when there's new server-core
<davexunit>sly would be a good choice for the client. :)
<nalaginrut>I mean Artanis server-core
<nalaginrut>it'll be async and not only for http
<davexunit>I need a release so that I can start seeking contributors. I need lots of help optimizing, for one thing.
<nalaginrut>nowadays, we have websocket in HTML5, so a pure http server is not enough in Artanis
<nalaginrut>it has to be more flexible
<nalaginrut>HTML5 brings too many things...
<nalaginrut>davexunit: yeah, you're on the road ;-D
<civodul>davexunit: for the bootstrap procedure; currently we have to have a complete Guile tarball available to begin with (info "(guix) Bootstrapping")
<davexunit>civodul: so instead, we could have a minimal guile?
<nalaginrut>civodul: I'd love to see scheme@(guile-user)> when bootup ;-D
<nalaginrut>in principle, we may implement Bash front-end in Guile, but maybe a sexpr-sh is better, hmm...
<nalaginrut>last time I asked about minimal Guile is 2010, IIRC, the answer is "impossible" at that time
<nalaginrut>guile -c "(use-modules(artanis artanis))(init-server)(run)" you'll get a simple HTTP static page server
*nalaginrut should add this simple HTTP server to "hello world" chapter...
<civodul>davexunit: more precisely, a Guile that doesn't need to access the file system
<civodul>nalaginrut: that's already possible when booting the Guix distro :-)
<nalaginrut>civodul: nice!
<nalaginrut>I wish Hurd could be run on ARM, respberryPI, dunno, I should ask
<mark_weaver>porting gnumach to a new architecture will be a pain
<davexunit>if developing for hurd could be made easier by using guile for the bootstrap and such, it just might attract some new devs.
<mark_weaver>they're not even on x86_64 yet, just i686
<mark_weaver>civodul: what's the use case you have in mind? (for guile that needs no filesystem)
<nalaginrut>mark_weaver: are you saying gnumach only? or any kind of BSP?
<nalaginrut>but we could write a binding for Hurd libfs
<nalaginrut>so we could have filesystem when bootup
<civodul>mark_weaver: see :-)
<mark_weaver>nalaginrut: I don't understand your question. I'm just saying that porting gnumach to a new architecture is by far the biggest difficulty in porting hurd.
<civodul>we need to displace TinyScheme
***Guest52575 is now known as Fuuzetsu
<nalaginrut>mark_weaver: I know it's painful to port a kernel to a new platform. But I guess you mean it's especially hard for gnumach? or I misunderstood
<nalaginrut>civodul: it's better to get rid of prerequisite of POSIX lib function for minimal mode
<nalaginrut>so that the game using Guile as scripting could be ported to M$ platform easier
<nalaginrut>I convinced a friend to write his new game with Guile, but then he found he has to use cygwin on Win, so he picked tiny-scheme
<mark_weaver>nalaginrut: I didn't mean to imply that gnumach would be harder to port than any other kernel. but porting _any_ kernel is probably non-trivial.
<nalaginrut>if it's possible to replace tiny-scheme with Guile-minimal-mode, it's better not to let users use cygwin
<nalaginrut>mark_weaver: alright ;-)
<slucx>nalaginrut: Is there a book about datestruct descript by scheme?
<nalaginrut>data structure for FP?
<slucx>nalaginrut: yeah
<slucx>nalaginrut: learn datastruct and scheme at same time
<nalaginrut>you have to read the papers it mentioned
<slucx>nalaginrut: yeah, I have a book
<nalaginrut>slucx: but maybe you just want to learn data structure in Scheme, no especially for FP data structure
<mark_weaver>"Purely Functional Data Structures" by Chris Okasaki is quite good.
<mark_weaver>the book has ML and Haskell code, but it can be adapted to Scheme easily enough.
<slucx>I write a simple qsort like this,
<davexunit>I need to learn haskell just so I can adapt the code in these papers to scheme.
<mark_weaver>slucx: merge sort is better suited to functional programming, and also far more efficient on large inputs.
<nalaginrut>IIRC I have that book... (searching in docs...)
<jmd>mark_weaver: But a merge sort depends upon qsort
<slucx>mark_weaver: I just try to write it with scheme
<mark_weaver>in general, it's better to avoid 'set!' when practical
<jmd>(or some other kind of sort)
<slucx>mark_weaver: I just begin learn scheme.
<mark_weaver>jmd: why do you say that?
<jmd>Well that is how merge sort works.
<mark_weaver>jmd: the base case can be: a singleton list is already sorted.
<slucx>mark_weaver: do not use 'set! ? why?
<nalaginrut>hmm...seems I just have <<Algorithms, a functional programming apporach>>...
<mark_weaver>jmd: I've written merge sort several times without using any other sort.
<mark_weaver>it may be common to use some other sort for lists below a certain size, as an optimization, but it's certainly not required.
<jmd>mark_weaver: Well, yes it can be, but then you loose some of the advantages that the merge sort might bring.
<mark_weaver>slucx: well, it's much easier for both the compiler and humans to reason about programs when the value of a variable doesn't depend on what time it is.
<jmd>In your implementation, the singleton sort is the special case of the qsort.
<mark_weaver>jmd: well, that's seems a strained way of looking at it.
<mark_weaver>jmd: a quick glance at seems to favor my view
<nalaginrut>oh, I have it! (so long long reading list...)
<mark_weaver>jmd: that page calls your method "tiled merge sort", mentioned in the "Optimizing merge sort" section.
<jmd>That's the way most implementations I have seen work.
<mark_weaver>that page happens to mention that perl switched to using merge sort as the default in version 5.8.
<mark_weaver>(previously they used quick sort)
<mark_weaver>slucx: fwiw, guile's compiler is able to optimize much better when most local variables are never 'set!'.
<nalaginrut>davexunit: indeed, we should have Scheme version for it
<davexunit>nalaginrut: I've been having a tough time figuring out how to implement a data structure called the "relaxed radix balanced tree". reading the paper about it and trying to decipher haskell/ocaml snippets makes my head hurt.
<slucx>mark_weaver: (set! bigger (cons x bigger)) , how not to use set! ?
<nalaginrut>davexunit: I face the similar pain, many papers about FP compilers are in Ocaml/ML/haskell
<nalaginrut>it's not the worst case, they like to use Ocaml dialects
<nalaginrut>when God created lambda, I don't know why people don't use it as the meta language
<davexunit>I think I need to grok finger trees and write an implementation before I can understand rrb-trees.
<mark_weaver>slucx: well, there's no reasonable way to write 'quicksort' without 'set!', but in general, the usual approach is to make a recursive procedure, and pass the new values to the recursive call, instead of using 'set!'.
<nalaginrut>davexunit: I want to implement bunch of data structures for practical usage, but it's undone
<slucx>mark_weaver: ok, i get it
<nalaginrut>davexunit: please post something on your blog when you done your rrb-tree
<nalaginrut>I want to read ;-)
<mark_weaver>slucx: this depends on the fact that in scheme, calls in "tail position" are really GOTOs with arguments.
<slucx>yeah, i know tail-recursive
<dsmith-work>Monday Greetings, Guilers
<mark_weaver>greetings, dsmith-work!
<nalaginrut>davexunit: btw, I found it's wrong implementation in rb-tree in guildhall when I'm writing rbtree
<nalaginrut>in deletion, but it's ok since people often use insertion
<mark_weaver>slucx: also, I recommend looking at 'match' from (ice-9 match). It can be used to replace most uses of 'car' and 'cdr', and could also be used to more efficiently check whether the list as 2-or-more elements.
<nalaginrut>dsmith-work: heya
<nalaginrut>each time I see dsmith I thought it's Friday today...
<nalaginrut>unfortunately it's not... terrible
<slucx>mark_weaver: yeah, I will lean the library of scheme soon
<slucx>mark_weaver: I just learned the base syntax of scheme
<davexunit>nalaginrut: I tried to write a persistent b-tree implementation, but I got stuck.
<mark_weaver>slucx: sounds good. I just wanted to point out 'match' because it's relatively new and not mentioned in most scheme documentation, and yet it has been a great help in our efforts to make code more readable.
<nalaginrut>davexunit: I would recommend not try to be functional first time ;-D
<davexunit>match changed my life.
<davexunit>I really like destructuring record types with it.
<slucx>mark_weaver: I am searching the documents of it.
<nalaginrut>davexunit: it's complicated structure, so not easy to be functional
<nalaginrut>davexunit: yeah, I use record-type too
<slucx>I have to go sleep now, night, mark_weaver nalaginrut
<nalaginrut>davexunit: for handling record-types, it's nice to use 'match'
<nalaginrut>slucx: night
<mark_weaver>slucx: good night!
<davexunit>nalaginrut: then maybe I should just go straight to finger trees. afaict, they are the basis for the immutable vectors you see in clojure.
<davexunit>and by using a branching factor of 32, they achieve something called "amorized constant time" access to elements.
<nalaginrut>sounds nice
<nalaginrut>davexunit: do you need it in sly?
<mark_weaver>davexunit: hmm, I didn't expect to do better than log(n)
<davexunit>the rrb-tree builds from that to improve the time complexity of other operations like appending.
<mark_weaver>but log base 32 (n) is close enough to constant for most purposes :)
<davexunit>mark_weaver: it is log(n), but the large branching factor makes it effectively constant time access. a vector with 1 billion elements only requires 6 hops down the tree to fetch any given element.
<nalaginrut>hah, I know why you dropped the name guile-2d, since it support 3d now ;-D
<mark_weaver>still, they shouldn't use the term "amortized constant time", which has a precise meaning.
<davexunit>I think I've misread. they say "effectively constant time" in the rrb-tree paper.
<mark_weaver>ah, okay :)
<davexunit>and then "2-3 finger trees achieve a lgN time for indexing and update
<davexunit>while at the same time maintaining an amortized constant time
<davexunit>for adding items to the vector."
<davexunit>thanks for the correction. :)
<davexunit>nalaginrut: yeah, I want persistent vectors for sly.
<davexunit>vlists are good, but the data structure that clojure uses has some additional advantages, from what I've read.
<nalaginrut>davexunit: alright!
<nalaginrut>vlists could be used in prototype
<mark_weaver>one word of warning: in my experience, improvements in asymptotic time complexity usually come with a significant increase in the constant factor.
<davexunit>so many games are based on a 2d grid that I would like a persistent array that performs adequately.
<mark_weaver>it's tempting to go for the algorithm or data structure that has the best O(...) on as many operations as possible, but the next result if often slow as molasses in practice.
<davexunit>I shall heed your warning.
<mark_weaver>this is why GMP uses something like 6 different multiplication algorithms, depending on the size of the numbers.
<davexunit>though I think that clojure's persistent vector is a good example of it being a good solution in practice.
<mark_weaver>davexunit: yes, probably so!
<davexunit>but perhaps the rrb-tree is a bridge too far.
<nalaginrut>well, when the code is down to fancy engineering for performance, it's not elegant anymore...
<mark_weaver>that too :)
<davexunit>the Elm language has an rrb-tree implementation
<davexunit>this blog post also helped me understand what these papers were going on about in simple terms.
<davexunit>(I've stolen a bunch of things from Elm for use in Sly)
<nalaginrut>is it a new language? I think it's haskell
<davexunit>it is haskell-like, but it's a new language.
<davexunit>with a javascript runtime.
<nalaginrut>seems it binds DOM in language level?
<mark_weaver>davexunit: fwiw, I think that learning some Haskell would be time well spent for anyone who's interested in purely functional programming. most of the relevant papers assume knowledge of Haskell, and besides it's a beautiful and elegant language.
<nalaginrut>I think I got its point, it generate js as backend with common HTML5 operations
<nalaginrut>a popular direction ;-)
<davexunit>mark_weaver: yeah, I should. I just don't really like Haskell...
<davexunit>but for reading papers, it will be useful.
<davexunit>it's hard for me to like any language that isn't a Lisp.
<daviid>same here :)
<dsmith-work>davexunit: I share that sentiment. Howver, haskell really is elegant.
<nalaginrut>me too ;-)
<davexunit>I also like dynamic languages, not static ones.
<nalaginrut>I could fall in love with C, but no more, for static imperative lang
<nalaginrut>not C++
<dsmith-work>I'm liking detecting errors as early as possible, like at compile time. We use a lot a python, and there can be a blatant horrible bug that you will never see unless you eactually try to execute it.
<davexunit>yeah, that's a nice advantage to static typing, but I don't like the programming environment that it creates.
<dsmith-work>The usual answer is "more testng" "code coverage"
<davexunit>those answers suck. :)
<nalaginrut>dsmith-work: I've heard that new python will add type annotation, but I don't think types solve all problems ;-P
<dsmith-work>Probably not.
*dsmith-work is ever so slowly learning Haskell
<nalaginrut>"more testing" is similar to "write it better", we often write accurate test when we encountered problems
<nalaginrut>IMO, more testing is useful to avoid introduce new bugs
<dsmith-work>A lot of this python code is in an embeedded environment. We usually have to go through something like a "Compile" cycle, as we need to build a filesystem and boot the device to run the code.
<daviid>folks, anyone of you is on debian and could help me with this .la missing files i reported ?
<dsmith-work>daviid: Hmm. Found this:
<daviid>dsmith-work: thank you. will read now. while trying hard by myself, i started a chat on #autotools, but so far they can not help me either
<dsmith-work>daviid: Which points to this
<daviid>dsmith-work: many thanks, I'm reading now
<dsmith-work>Looks like Debian and Fedora remove .la files.
<daviid>dsmith-work: it's been years now here is what i don't understand, and therfore don't know how to fix, both for guile-gnome and guile-clutter:
<daviid>when i "git clean -dxf",, then search for
<daviid>so, "make" creates a file, let's call it, within which i can read "dependency_libs=... /usr/lib/x86_64-linux-gnu/ ..." _but_ before running "make", i can not find, in any file of the guile-gnome tree, 1 occurrence of the word "libcairo". so, which file of the autotool chain and which variable/command will tah tfile run to create that dependency ?
<daviid>Here is the content of the generated, by libtool, file, which has the 'false' dependency toward "/usr/lib/x86_64-linux-gnu/", which does not exists:
<daviid>if i manually change to, it will proceed and fail in pango, then manually changing in pango, proceddees and fails in gtk ... until i can compile
<daviid>it must be g-wrap, will look to it, have to go afk for a while, bbl