When mapcan backfires

While writing some elisp for clasker (still alpha), The destructive function mapcan backfired in a really strange way.

Calling mapcan on a list of really simple functions that just returned lists, worked ok, but just the first time.

The issue is a combination of different things, mainly Iterating through functions that return quoted lists.  When nconc does its thing, it uses the lists in place, so we're indeed modifying the defuns.

Here's the small code that exemplifies the issue, and a possible way to avoid it.

ELISP> (defun t1 () '("hola"))
t1
ELISP> (defun t2 () (list "adeu"))
t2
ELISP> (t1) 
("hola")

ELISP> (t2)
("adeu")

ELISP> (mapcan 'funcall '(t1 t2))
("hola" "adeu")

ELISP> (t1)
("hola" "adeu") ; => Oops, t1 has been modified

ELISP> (mapcan 'funcall '(t2 t1))
("adeu" "hola" "adeu")

ELISP> (t2)
("adeu")

ELISP> (defun t1 () '("hola")) ; Redefine t1 and t2 for sanity assurance
t1
ELISP> (defun t2 () (list "adeu"))
t2
ELISP> (mapcan 'funcall '(t2 t1))
("adeu" "hola")

ELISP> (t2) 
("adeu") ; => t2 is fine

Generating the lists with the (list ...) function solves the issue, because a new object is created every time, so we're not returning the literal object from the source.

Also,  (reduce 'append (mapcar ...)) will do "the right thing" (tm)

Learn javascript as a little schemer

I recently found a blogpost talking about javascript prototypes in a very funny and uncommon way. It was funny to read, easy to follow, and high on insights. Out of the sudden, something clicked in my brain, and I thought:

 - Aha!, I've seen this way of explaining things in some other place! It's like the Little Schemer (and all the schemers collection (which I haven't read (yet)))!

 Then, I checked other posts on the same blog, and most articles follow the same socratic experience of explaining things.

 Really, it's funny, and it builds up on you.

 Well, and here's the url of the blog. Kudos to AngusCroll (author), you have a new blog follower.


EDIT: I just found another instersting post for js wannabies like me. Simpler, but interesting read

"Chrome does UDP sockets" joke

Opening a new section, here's the first post in the new section irclog, where I'll just copypaste remarkable pearls that appear in one or other channel I'm usually logged. Be prepared for geek jokes. I can't promise to be involved in all :) And here's the first. with my 3scale coworkers

<a> http://blog.alexmaccaw.com/chrome-tcp-udp "Chrome supports TCP & UDP Sockets"
<a> you can do udp jokes in chrome now
<rgrau> I didn't get it
<a> I don't care
<rgrau> great!

erc-oops

Hi again emacsians.
Maybe you're familiar with this IRC log samples.

  15:54 [rgc] xb
  15:54 [rgc] ooops, C-fail

  12:02 [xyz] ls
  12:02 [xyz] oops

  00:21 [foo] cd
  00:22 [foo] wrong buffer :/

To avoid that, some time ago I wrote some elisp to make erc-buffers read-only, but I just came up with a better solution:

(defun rgrau-erc-oops (txt)
  (when (member txt '("ls" "xb" "cd"))
      (setq erc-send-this nil)))

(add-to-list 'erc-send-pre-hook 'rgrau-erc-oops)

It's too simple to make an erc module out of that(isn't it?), so I just put it in this blog entry.

erc-button fun

Erc is one of multiple irc clients bundled with emacs.  It's probably the most complex one, in fact, in #emacs you read that quite a few people left it in favour of simpler clients like rcirc. But I kind of like its complexity :)

One nice thing about erc that's not very known is erc-button.  Yeah, the thing that allows you to click on nicknames and kick them :).

At work, we use github issues to manage our stuff, and we wrote a super simple extension for our bot that whenever it sees #number it just pastes the url of the issue. I tried to use a more silent approach using erc-button, and here's the result.

It just highlights #123 like strings and make them clickable, linking to the appropiate issue in the appropiate repo.


Neat, no?

Well, if you happen to use other sites for your issues, you can work around that github-centric approach with something else, I just hacked an ugly solution on top of the previous one. Not very clean maybe, but working.

Probably, the most sensitive solution would be writing the whole urls for each one, but well... :D

The nice point here is the tight relation between emacs and all other tools and use case. In really few lines of code we solved a problem, and we did it flexibly enough to be used in multiple scenarios.

Btw, hi to all planet emacsers, that's my first post here since I signed in. I hope to contribute here some of my emacs tricks. Don't hesitate giving feedback and commenting.

Update: There are gists inlined in the post that aren't visible in planet emacsen.  Will try to change approach for the next one.

Lisp debugging, step by step. Step 1

Debugging lisp is not as straightforward as one might think at first.  Being a live environment I thought it would be a joy, like in smalltalk, racket, or elisp, which provides a quite decent tracer and stepper.  Smalltalk is another world, but I'm already getting used to it so it doesn't surprise me that much.

We all heard stories about lisp machines (genera), and eventually read some article or seen some talk about how awesome it's lisp to debug.. but for me it was not so straightforward.

I'm using SBCL for all my experimentation in CL, so the examples here are going to be all sbcl related.  First of all, some reasons on why there's not an easy mapping between your debugger on the language next door and lisp when debugging:

- Lisp normally compiles the source code to native code. Doing so, it runs lots of optimizations on your source, so the code executed has no direct mapping to your written code.
- Lisp is not line oriented, so the order of execution of code is not so easily mappable to the typical next-line, next-line... debugging.
- On the other side, you have 'trace' that lets you track all executions of a function, with params, and so. It's not so live, but with all the instrumentation that sbcl and slime provide, you can track down a fair amount of bugs just with trace.

To instrument a method to be debuggable more easily, my advice is to add this declarations.

  (declare (optimize (speed 0) (space 1) (compilation-speed 0) (debug
3)))

That'll keep sbcl out from doing optimizations that can make variables 'disappear' in runtime.

A little more info in:

http://www.rhinocerus.net/forum/lang-lisp/583943-sbcl-line-line-debugging-tracing.html


and obviously, in your nearest implementation manual http://www.sbcl.org/manual/Debugger.html

CompGuile. Compile guile in ubuntu

Guile is the Gnu Scheme implementation and official extension language for gnu apps. Let alone most gnu apps disregard this rule. I always found guile a good companion because it was easily instalable in all my linux boxes.

 The other day I tried to install a newer version to work with geiser (and because I had been reading some nice things related to new versions on Wingo's blog), but the installing process wasn't as simple as ./configure && make install. Mostly my fault, because I just needed many *-dev packages that were not present in my box. But after installing gmp and some other easy-to-find libs, I got stuck into "No package 'bdw-gc' found". As jao put in a mail in guile maillist,

"You can tell configure where BDW is located by setting the above
mentioned environment variables. With libgc-dev installed from a deb, i
routinely do (in a bash prompt):

  $ BDW_GC_CFLAGS=-L/usr/lib BDW_GC_LIBS=-lgc ./configure
"