Rakudo * is next door

Yes.
Rakudo *, the first official distribution of stable (yet incomplete) perl6 interpreter rakudo. Devs haven't focused on optimizations but features, and it's quite useful as it is IMHO. It brings lots of the crazy Perl 6 features announced in the synopsis like hyperoperators, metaoperators, lazyness, junctions, introspectable OOP, and regex and grammars as first class citizens in the language. That last thing means you can plug a new parser for your program in lexical scope. Welcome DSL world. Early adopters, language geeks, perl hackers, you have no excuse now not to try rakudo :) .

Myself I haven't toyed enough with Perl 6 to do anything useful, but I have done quite a few conceptual tests, and, although I'm still baby-talking Perl 6, it's quite nice to hang around at #perl6 and see perl6 heroes stressing rakudo's features till the unthought limits.

More good news: Audrey Tang appeared a few days ago on #perl6 (I think thanks to masak's post), and started hacking on niecza (sorear's perl6 implementation focused on compiler and interpreter optimization techniques).

I tried to solve one of moritz's perl6 Challenge, implementing Str.trans (á la p5 tr// ) in perl6. Mine, is the (really incomplete babyperly) submitted on a gist pastie. I didn't win the rakudo T-shirt.

More on Perl6. A couple of perl6 related posts reached HN and reddit top page and stayed more than 1 day there. buzz buzz buzz buzz :)

And last but not least, Barcelona Perl Mongers are living a celebration, on July 29th of July, the R* Day (and being the last thursday of the month, which is the usual meeting day) will join at UPC Campus Nord, and Alex Muntada will give a Perl6 introductory talk. Of course, you're all invited. Unfortunately, I won't be able to be there as I'll be in Malta. O HAI Holidays!

Happy 1st anniversary

Back to the future?

9:00
Llego al currele, y mientras estoy haciendo mi navegacion de
reconocimiento, encuentro porahí un link interesante: Google’s
Do-It-Yourself App Creation Software. Alguna frikada de google
labs... ya verás. Total, que empiezo el articulo y leo que el
proyecto esta liderado por un tal "Harold Abelson". H.Abelson en
google? (pues se ve que se ha pillao un sabático del MIT). Bueno, el
proyecto va encaminado a que todo el mundo pueda ser programador de
sus miniaplicaciones.

17:00
Recibo un mail en una maillist Que pone "se nos acabóo el trabajo".
Coño! Esto es scratch!!!
Reflexión: Los Schemers chupando de smalltalk? Bueno, puede ser,
entre comunidades pioneras... pero en google, hacen algo en
scheme/smalltalk? Bueno, de hecho, scratch tambien sale del MIT, creo.

17:30
Llego a la pagina oficial del proyecto y efectivamente al final de la pagina.
(...) Open Blocks visual programming is closely related to the Scratch
programming language, a project of the MIT Media Laboratory's Lifelong
Kindergarten Group.

The compiler that translates the visual blocks language for
implementation on Android uses the Kawa Language Framework and Kawa's
dialect of the Scheme programming language, developed by Per Bothner
and distributed as part of the Gnu Operating System by the Free
Software Foundation. (...)

18:00
Me pregunto si contestar al mail de la maillist contando de donde
viene todo esto, quien es Abelson, y entro en otra
batalla épica? Respondo con un : "joer, estos de google son la ostia,
estas cosas, solo las pueden inventar ellos...", me callo?.


En fin... Esta claro que poco a poco van alcanzándonos, pero la
verdad es que me encanta estar en este mundillo (pionero después de
casi 30 años), y estas aproximaciones que hacen 'los grandes' le dan a
uno la confirmación de la sospecha: "yeah, voy un paso por delante,
que se jodan" :D

Wasn't there a command to do XYZ?...

At $work, many times I'm asked about ways to optimize little annoying processes of other people (I'm a kind of office enabler).

There's a typical dialog of some $coworker, and $self.

- Hey Rai, I've got a little question for you.
- Ok, go on.
- Wasn't there a linux command to put lines of two files in one file, one line after the other? Like a columnwise join.
- M... yeah... I think so. Was it 'join'? Nah, man doesn't seem to say anything about it... Well, you can use Perl, you know, the swiss knife.
- Yeah, but I don't think a script is needed, For now, I'm doing it with excel, you can copypaste each file in different columns, and then save as CSV, then you just have to remove the commas, using vim.
- ¬_¬ .... Gimme 30 secs.

echo 'a' >a
echo 'a' >>a
echo 'a' >>a
echo 'b' >b
echo 'b' >>b
echo 'b' >>b
perl -e 'open $a,shift;open $b,shift; while(chomp($_=<$a>)){print $_, scalar(<$b>)}' a b

output:
ab
ab
ab

Redirect STDOUT to file in Perl 5

Every now and then, I need to write little scripts (or not so little) that output *lots* of lines of text. Those lines belong to a single file, so my common idiom is printing the output to STDOUT, and tell the user to redirect the output to a file if he wants it toasted into a file.

But there's a more elegant way to do it that doesn't rely on shells, and works more consistently. In fact TIMTOWTDI.

One way is fill the code with:

if ($outputInFile) { print $file "foo";}
else{print "foo"}

/me shivers ...

I found a way to do it quite elegantly redirecting a file handler where I'll be printing to STDOUT, using Typeglobs. I'm not too confident managing typeglobs, but it seems to work :)



I asked at #barcelona.pm and alexm (O HAI! president) told me I could think it the other way around, and overwrite STDOUT to an opened filehandle in case I needed the redirection. I didn't know I could handle STDOUT like any other fh. It's nice to know it.



I think Casiano taught me (back in university times) another way to do it (maybe it was using tee, or some IO::Handle funky stuff).

Is there any cpan module that does that kind of Stdout vs file output? I haven't found it, but it MUST be there. Or maybe the code to do it is so small it doesn't make sense writing a module for that

Algo pasa...

Cuando tu bandeja de entrada esta llena del mismo nombre.

Kill Buffers Illustrated (emacs)

A side effect of using emacs intensively is that you end with lots (I mean *LOTS*) of open buffers scattered on your emacs.

This is not necessarily a problem (provided you use ido/iswitchb/icicles modes), but it kind of gets on my nerves having 30+ buffers opened knowing that I don't need them anymore. Most of them are temporary buffers like dired-mode ones, or perldoc ones. Like most things in emacs world, someone has already thought of it and there is already a function to do what you want.

For example, scattered dired-mode buffers.

(defun kill-all-dired-buffers()
 "Kill all dired buffers."
 (interactive)
 (save-excursion
   (let((count 0))
     (dolist(buffer (buffer-list))
       (set-buffer buffer)
       (when (equal major-mode 'dired-mode)
         (setq count (1+ count))
         (kill-buffer buffer)))
     (message "Killed %i dired buffer(s)." count ))))

And you're done.

great, isn't it?

What if you want to purge some buffers, that have no name in common, nor mode? You can kill them one at a time with kill-buffer (c-x k) but if you want to do it faster, you can use Buffer List buffer.

c-x c-b will open a buffer with a list of all buffers. That's not a normal (Fundamental) buffer, but a 'Buffer Menu' buffer. If you press 'd', the buffer that has the point (cursor) will be marked for deletion. Once you have the list of buffers to kill, just press 'x', and buffers will be killed.

If you press 'x', 3 erc buffers will be killed. Mnd you, once a buffer has been killed, it cannot be unkilled. :)

That's all for now.