IRC channel logs

2013-08-02.log

back to list of logs

<mark_weaver>though I suppose it's possible that you might get it to work by disabling the graphical interface, by passing --with-x-toolkit=no to ./configure.
*PuercoPop nods
<mark_weaver>the deps/dispnew.d error is probably happening because the 'deps' directory didn't get created for some reason. not sure why.
<PuercoPop>reasons to wipe out Mac OS X with linux keep piling up!
<mark_weaver>hehe :)
<mark_weaver>one of my friends, who has been an Apple lover since he was a kid, recently got fed up with Apple's increasingly bad policies, and switched to GNU/Linux.
<mark_weaver>I was also an Apple lover once, but I made the switch back in 1993.
<taylanub>.oO( The year I was born ... )
<mark_weaver>hehe
*jao was about to re-tweet mark_weaver and just realized this is IRC :)
<mark_weaver>huh? I'm confused :)
<mark_weaver>I don't really know what it would mean to re-tweet me, I guess.
<jao>mark_weaver, i read twitter using emacs (via bitlebee), so it looks like this IRC channel
<mark_weaver>ah, I see :)
<jao>mark_weaver, it's usual to "echo" twitter messages one likes
<mark_weaver>*nod*
<PuercoPop>mark_weaver: the only like is their keyboard layout sans the left right control
<PuercoPop>Mac OS X is just emacs Chrome and games
<mark_weaver>"sans the left right control"? I can't make sense of that.
<mark_weaver>Anyway, you can configure the keyboard layout on GNU/Linux however you like.
<mark_weaver>(only the most commonly desired options are available in the usual GUI configuration dialogs, but if you're willing to edit some text files you can do almost anything you like with the layout)
<mark_weaver>Apple keyboards also work on GNU/Linux, though I'm not sure I'd recommend that.
<PuercoPop>So there is no right control key in the MacBook Pro which I think is retarded
<PuercoPop>yeah, I was happy linux user since 2004 until I got this Mac. I've been procrastination the return.
<mark_weaver>For my friend, it was GNOME 3 that finally got him excited enough to make the switch.
<mark_weaver>I like having the control key to the left of 'A'. I have a lot of trouble using any keyboard that's not configured that way.
<mark_weaver>The other thing is, it's getting much easier to switch because so many things are now being some in web browsers, where it doesn't matter what platform you're on anyway.
<mark_weaver>s/some/done/
<PuercoPop>Gnome 3 is not as bad as they paint it. I prefered KDE 3 though
<mark_weaver>KDE 3 was very nice. I used it for a long time myself.
<PuercoPop>I want to give xmonad a try though
<mark_weaver>ah yes, I've never tried that but it sounds interesting.
<mark_weaver>I'd like to write a Haskell front-end for Guile at some point.
<dsmith>mark_weaver, Oooo!
<mark_weaver>beware: "at some point" could be anywhere between 1 year and never :)
<dsmith>mark_weaver, Is the guile vm capable of doing haskelly things?
<mark_weaver>I don't see why not. Most of the magic of Haskell happens at compile time anyway.
<mark_weaver>If we had a Haskell front end, it's possible that we'd want to add a few VM instructions to optimize common Haskell ops, but that shouldn't be a problem.
<mark_weaver>The main thing is that our runtime system is based on latent types, so every value has type tags. That would add needless overhead for Haskell, which is statically typed.
<mark_weaver>but we'll probably have native compilation long before I get around to this anyway, at which point it should be possible to pass the static type information to the compiler and avoid the runtime tags.
<jaaso>Carmack talking about functional programming (lisp and haskell) http://www.twitch.tv/bethesda :)
<taylanub>That web-site seems messed up, requiring Flash and all.
<mark_weaver>yeah, I can't access that website at all.
<mark_weaver>It seems to require Adobe Flash Player. I run only free software.
<jaaso>It seems they are only streaming on twitch
<nalaginrut>morning guilers~
<nalaginrut>jaaso: seems it's end?
<jaaso>nalaginrut: yup, live streaming. but you can watch it here http://www.twitch.tv/bethesda/b/439369577?t=1h32m
<nalaginrut>thanks
<jaaso>np
***jaaso is now known as jaaso_afk
<nalaginrut>well, zero commits these days?
<mark_weaver>huh?
<mark_weaver>it's been 11 days since the last push, but both wingo and I have a bunch of patches in the works.
<nalaginrut>maybe I should throw some dirty patch to make the atmosphere more exciting ;-)
***jaaso_afk is now known as jaaso
<lloda>how do I do this 'sneek later tell' thing?
<nalaginrut> http://www.web-artanis.com/about.html
<nalaginrut>sneek: later tell lloda use it like this ;-P
<sneek>Got it.
<lloda>thanks :)
<sneek>Welcome back lloda, you have 1 message.
<sneek>lloda, nalaginrut says: use it like this ;-P
<lloda>sneek: later tell bubu (--1--) Guile arrays are by default row-major (C order, last index fastest) not column-major (Fortran order, first index fastest). This shouldn't matter if you operate at a high level, but ops that traverse the array in order (e.g. array-for-each) always do it in C order. (--2--) Guile has a single slicing operation, make-shared-array. It's THE operation you want if you can only have one. However, it's very slow
<lloda>and inconvenient to use for the more common rectangular slicings. So I've written a wrapper around it called 'from'. You can find it in gitorious.org/guile-ploy. Take a column with (from A #t column-index) or a row with (from A row-index #t) or simply (from A row-index). This is actual slicing, i.e. no copies. You can use it for more general operations such as (from A #t `#(,index0 ,index1 ...)) to pick any set of columns, in which case
<lloda>it does make a copy. There's also a (reshape) op and other utilities. Many things are missing to have a complete array library, but please give it a try. (--3--) The idea is that Guile will eventually provide either less general but faster slicing operations, or direct access to the dope vector from Scheme. Then I could rebase (from) on top of that. (--4--) Thanks for reading!
<sneek>Will do.
<nalaginrut>lloda: I wonder if sneek could eat such a long sentence ;-DD
<taylanub>It probably just got the first line ... IRC limitations.
<lloda>Ah, that's too bad :(
***sneek_ is now known as sneek
***sneek_ is now known as sneek
<dsmith-work>Happy Friday, Guilers!!
<dsmith-work>lloda: Yeah, sneek only got up to ""However, it's very slow". You can give sneek multiple tell messages, they come out in order.
<lloda>thanks, I'll try again if he's here before I'm gone
<lloda>I wouldn't want to spam such a busy channel
<mark_weaver>sneek: later tell bubu lloda went on the say: "However, it's very slow and inconvenient to use for the more common rectangular slicings. So I've written a wrapper around it called 'from'. You can find it in gitorious.org/guile-ploy. Take a column with (from A #t column-index) or a row with (from A row-index #t) or simply (from A row-index). This is actual slicing, i.e. no copies."
<sneek>Got it.
<mark_weaver>sneek: later tell bubu lloda: "You can use it for more general operations such as (from A #t `#(,index0 ,index1 ...)) to pick any set of columns, in which case it does make a copy. There's also a (reshape) op and other utilities."
<sneek>Got it.
<mark_weaver>sneek: later tell bubu lloda: "Many things are missing to have a complete array library, but please give it a try. (--3--) The idea is that Guile will eventually provide either less general but faster slicing operations, or direct access to the dope vector from Scheme. Then I could rebase (from) on top of that. (--4--) Thanks for reading!"
<sneek>Will do.
<mark_weaver>sneek: botsnack
<sneek>:)
<lloda>ha, thanks mark_weaver, you are too nice. Well now I know how to do it.
<mark_weaver>lloda: np :)
<dsmith-work>lloda: busy channel?
<lloda>sorry, bad joke
<dsmith-work>heh
<wackonline>Hi, ask the guile library currently does not contain encryption?
<amirouche>is there anything like docstrings in guile ?
<dsmith-work>Yes!
<dsmith-work>There is.
<dsmith-work>They are exactly docstrings.
<amirouche>sorry didn't STW
<dsmith-work>Try ,h cons
<dsmith-work>or (help cons)
<dsmith-work>SOrry, should be ,d cons
<dsmith-work>(for an example)
<amirouche>help and ,d don't give the same output
<amirouche>how do you retrieve a docstring from a script ?
<amirouche>I mean it works from repl but not from standalone script
<davexunit>amirouche: use procedure-documentation http://www.gnu.org/software/guile/manual/html_node/Procedure-Properties.html#index-procedure_002ddocumentation
<mark_weaver>amirouche: 'object-documentation' from (ice-9 documentation) is what ,d uses. it supports more types of objects.
<amirouche>ok... anyway this was just curiosity, somewhat, I really like sphinx from python http://sphinx-doc.org I though that I would start by contributing something similar
<amirouche>to guile
<amirouche>I mean learn guile and write a sphinx clone ^^
<mark_weaver>it would be great to improve the self-documenting abilities of guile. in core guile, we use texinfo markup for procedures defined in C. We'd like to support texinfo markup for procedures defined in Scheme as well. We already have a fairly functional texinfo parser written in Scheme, but it hasn't all been hooked together yet.
<amirouche>overview of sphinx: it can build two sides documentation, Reference API autogenerated (optional) from source/docstrings and prose like documentation
<amirouche>I think skribilo can generate texi files
<dsmith-work>Currently, Guile does NOT generate docs from the docstrings. There was some effort to do that in the past, but the current maintiner don't like it for several reasons.
<dsmith-work>Mainy, I think, it's because the online help and what you need to read in a manual are two very different things.
<davexunit>dsmith-work: I made the mistake of thinking that I could generate texinfo docs from docstrings before. :(
<dsmith-work>It's an attractive idea.
<dsmith-work>I like that it keeps the docs and the code in close proximity.
<taylanub>I'd just follow what Emacs does, wrt. documentation.
<dsmith-work>So there is a better (hah!) chance of keeping them synced.
<davexunit>if I want to generate texinfo docs from scheme files, can I do a comment block above a procedure or something?
<dsmith-work>davexunit: yeah, there is code to do that.
<davexunit>I've been meaning to learn how to do this properly so I can write some semi-decent documentation for my project.
<dsmith-work>Or there used to be.
*dsmith-work looks
<dsmith-work>module/scripts/doc-snarf.scm I think.
<dsmith-work>Yeah, that looks like it.
<dsmith-work>Only for Scheme code (not C)
<amirouche>API reference is *not* documentation, it's a reference
<amirouche>I mean, relying only on documentation and avoiding reference is not a solution
<dsmith-work>How would you say they are different?
<davexunit>so docs in the form of comments for a reference manual, and then docstrings for when at the repl and want to describe something?
<amirouche>docstrings are meant for reference
<amirouche>in my experience at least
<dsmith-work>davexunit: Look at the source for that file. The usage is documented in there.
<amirouche>documentation is broader subject which more or less describe how things feet together
<davexunit>amirouche: I am now confused about what you mean by documentation and reference
<amirouche>reference is the documentation extracted from docstrings
<dsmith-work>Hmm.. I would use those words somewhat differently.
<mark_weaver>amirouche: one issue is that we'll want core guile to be able to parse its own doc strings without relying on external tools.
<amirouche>for instance this is a reference documentation http://www.gnu.org/software/guile/manual/html_node/Procedure-Properties.html#index-procedure_002ddocumentation
<mark_weaver>parse them, and format them as well.
<mark_weaver>(at least a basic text formatting)
<mark_weaver>amirouche: having said that, I wholeheartedly agree that Guile could use some work in the self-documentation department. It would be good to discuss this on the mailing list though, since neither of the maintainers are here right now.
<dsmith-work>davexunit: That file is dogfooding it. The doc on how to use it are also an example of it's use.
<davexunit>dsmith-work: I will take a look
<davexunit>mark_weaver: I was poking around in (system repl repl) and noticed that the before-eval-hook is run, but not the after-eval-hook
<davexunit>there's quite a lot of nested error handlers and whatnot around the code that performs the actual evaluation. I can't quite determine where an after-eval-hook *should* go.
<mark_weaver>davexunit: one issue is that you'd need to unlock the mutex even if the evaluated expression raised an exception.
<davexunit>mark_weaver: yes.
<mark_weaver>there's the question of whether the after-eval-hook should be run after an exception is thrown or not. that's an API question, and it depends on how it has worked in the past.
<mark_weaver>and on the typical use cases.
<mark_weaver>I don't know the answer, but it's something worth thinking about.
<davexunit>I was also wondering about that.
<davexunit>for now, I'm working with tweaked versions of (system repl repl) and (system repl server)
<mark_weaver>a more flexible API would be to optionally provide a procedure that accepts a thunk, where the thunk evaluates the expression.
<mark_weaver>so then the REPL would create the thunk (which I think happens anyway, as part of compilation), and then pass that thunk to the user-provided procedure to run it.
<davexunit>that sounds nice.
<mark_weaver>that way, the user could decide for themselves how to handle things like exceptions, continuations exiting/reentering, etc.
<davexunit>for my case, I would probably need to use dynamic wind to make sure that I still unlock the mutex if an exception is thrown.
<mark_weaver>heck, you could even do things like queue the thunk to be run in a different thread, with such an API.
<davexunit>that would be ideal, actually.
<mark_weaver>btw, I saw in the logs that you had to put a usleep in between the unlock and lock.
<mark_weaver>I thought that our "fat mutexes" were supposed to be fair, so that might be considered a bug.
<mark_weaver>I'll have to investigate that at some point. (my TODO list runneth over)
<davexunit>it might be a bug. I could have also done something else wrong, but without the usleep the repl would just hang when I tried to eval something.
<davexunit>I am sleeping the main thread now anyway, so as not to use excess CPU time in a busy loop.
<davexunit>so I unlock the mutex, sleep for the leftover frame time, and then lock it again.
<mark_weaver>yeah, kernels tend to penalize processes that never sleep.
<mark_weaver>I was thinking that instead of doing the unlock+lock thing in the main loop, you could use your scheduler to make that happen a few times per second.
<mark_weaver>that way, you could lower the overhead of mutex operations to as low as you want, the only tradeoff being responsiveness of the REPL.
<mark_weaver>davexunit: condition variables might be another approach worth considering. see 'wait-condition-variable', which accepts a timeout.
<mark_weaver>(and 'signal-condition-variable')
<mark_weaver>though I guess that would go hand-in-hand with passing a thunk from the REPL thread to the main thread.
<mark_weaver>I dunno, just another random idea. I thought the mutex idea was simple and ideal, but that idea assumed that the mutexes were fair.
<mark_weaver>well, really I still think the mutex method is the way to go. I just need to look into why they're not as fair as they are supposed to be.
<taylanub>Are variable-set!, set-car!, and set-cdr! atomic ?
<davexunit>mark_weaver: I really liked the idea of receiving a thunk that I could just add to a queue to be executed, since I already have a task queue.
<mark_weaver>sure, that's also a fine strategy.
<mark_weaver>though keep in mind that this also involves mutexes. either your task queue needs to be thread safe, or you need something that periodically checks a thread-safe queue from the REPL, and moves those jobs over to your real task queue.
<mark_weaver>anyway, I have to go afk for a while. ttyl, and happy hacking!
<davexunit>thanks mark_weaver. later! have a good weekend and such.
<davexunit>I'm leaving too
<sprinky>Does much discussion of guile-emacs take place here?
<taylanub>sprinky: Here is fine I'd say.
<taylanub>Although, there's mainly one person working on it, and that person is rarely here.
<mark_weaver>sometimes, yes. bipt, who hangs out on this channel, is the primary guile-emacs hacker these days, although he's often afk.
<sprinky>Neat. I'm curious because it seems like a really exciting project, and is already fairly usable, from what I hear
<taylanub>(I play around with it a lot and, am often in this channel, so I'll respond when I can ...)
<sprinky>Do you use it regularly?
<taylanub>It seems to be slightly less stable than stable Emacs, and doesn't really have an advantage yet, so no.
<taylanub>It doesn't compile Elisp yet.
<taylanub>Although a couple data-types are unified between Elisp and Scheme, and I have a tiny patch that lets you import procedures from Guile and call them as Elisp functions, so essentially all Guile libraries are already Elisp libraries now.
<sprinky>I'm fairly new to programming, and even newer to the Lisp family, but I've come to love both Emacs and Scheme (does Racket still count?), and guile-emacs sounds really exciting to me
<taylanub>Racket is mainly Scheme, yeah ..
<taylanub>Well, they have a *lot* of non-Scheme stuff, but if you write Scheme in Racket, that's Scheme, obviously ..
<sprinky>The MOOC I am taking deals with writing in bsl/isl (the little HtDP languages), with a pretty big emphasis on recursion
<sprinky>Aside from hacking on guile-emacs, do you do much else with Guile?
<sprinky>I think that was poorly phrased: What else do you do with Guile? :)
<taylanub>I'm usually too tired in my free time but I just see what I can contribute ...
<taylanub>I think that's what most free software contributors do. :P
<taylanub>Can't use it in my job, sadly, doing iOS development. (Gotta change that eventually.)
<sprinky>would it be possible for you to write (via macro magicks) a program that exports Guile code to Obj-C? Or would that not be worth the time? :P
<taylanub>Yeah, I'm mostly getting paid to write bad, rushed code that just makes the client happy in one way or another; no time for such fancy things. :(
<taylanub>Otherwise I can imagine extending Guile to wrap the ObjC run-time, which itself is just a C library, and Guile can wrap C libraries well ...
<taylanub>Although compiling for iOS would be another problem.
<sprinky>I dream of being able to write Scheme/Lisp for mobile apps. I kind of dream of writing everything in Scheme or Lisp. I think that'd be swell :P
<taylanub>There's I think at least two Scheme implementations for the JVM, so Android should be covered ..
<amirouche>there is currently a thread about clojure on the JVM
<amirouche>in clojure ML
<taylanub>You mean on Android ? Because it's always been on the JVM, hasn't it ?
<amirouche>no really
<amirouche>*not
<amirouche>actually android implements the same intermediate language as the JVM
<amirouche>through a dedicated project
<amirouche>I mean bytecode
<amirouche>here is the thread https://groups.google.com/forum/#!topic/clojure/69tZB2Wh6Tg
<amirouche>also gambit-c compiles to android https://play.google.com/store/apps/details?id=org.keithflower.gambit&hl=en
<amirouche>there is also a recent thread about it in Gambit C ML
<amirouche> https://github.com/kivy/ a NewUI Python framework compiles both for android and ios
<amirouche>erk
<amirouche>it's a bit more complicated than what I read before
<amirouche> http://en.wikipedia.org/wiki/Dalvik_%28software%29
<mark_weaver>amirouche: Clojure was built upon the JVM from the beginning.
<dsmith-work>Someone was asking about sarahbot the other day?
<dsmith-work> http://sisc.cvs.sourceforge.net/sisc/contrib/irc/scheme/sarah/
<mark_weaver>sprinky: there are several schemes available that run on Javascript.
<shanecelis>I've been writing this big application in Guile for doing virtual robot stuff, and I have a bunch of modules, one for physics, one for display, etc. I'm splitting them off into separately compilable Guile modules, which is good, but there's a still a lot autotools ceremony required.
<mark_weaver>it's actually kind of ridiculous how many there are :)
<mark_weaver> http://ceaude.twoticketsplease.de/js-lisps.html
<sprinky>I wonder why there are so many...
<shanecelis>mark_weaver: I might need one soon. Any idea which ones are good?
<mark_weaver>probably the same reason there are so many scheme implementations (even not on JS): because it's a simple enough language that lots of people are tempted to write one from scratch :)
<mark_weaver>shanecelis: I haven't looked closely at them, so I don't know.
<mark_weaver>it probably depends on the details of your use case.
<dsmith-work>Have a great weekend, Guilers
<taylanub>mark_weaver: Eventually we should compile to asm.js. :P
<taylanub>Both server- and client-side Guile, yummy!
<mark_weaver>dsmith-work: are you going away this weekend?
<mark_weaver>taylanub: I'd definitely like to get Guile running on JS at some point.
<mark_weaver>taylanub: The main difficulty is that we have so much C code that would have to be rewritten.
<mark_weaver>ijp has been toying with the idea of making an implementation of the Guile VM in JS.
<mark_weaver>so that it could run our .go files as-is.
<mark_weaver>but maybe some kind of compilation would be better.