sabato 24 giugno 2017

Ulteriori considerazioni sul planet PostgreSQL italiano

Qualche mese fa avevo espresso brevemente alcune considerazioni sul futuro dell'aggregatore di blog dell'associazione ITPUG, ovvero il Planet PostgreSQL Italiano.
La mia preoccupazione era dovuta al fatto che nei primi mesi dell'anno corrente non vi erano stati post relativi all'associazione e al mondo PostgreSQL in generale, e infatti facevo notare come solo io avessi pubblicato 13 post fra Gennaio e Aprile.


Ad oggi, giro di boa della metà anno, la situazione non è migliorata, e ancora una volta pare che il planet sia utilizzato solo per aggregare i miei post:



Ancora una volta sento la necessità di sollecitare l'associazione e il consiglio a valutare l'utilizzo di questo strumento di aggregazione e informazione, che risulta ormai evidentemente abbandonato a se stesso e in rapido declino di contenuti (a differenza del sempre aggiornato Planet PostgreSQL.

Perl _ filehandle

Leggendo la documentazione di :Find mi sono accorto di una frase nella sezione di esempio:


the "_" is a magical filehandle
that caches the information from the preceding "stat()", "lstat()", or
filetest.

e così incuriosito sono andato subito ad approfondire nella documentazione di stat:


If "stat" is passed the special filehandle consisting of an
underline, no stat is done, but the current contents of the stat
structure from the last "stat", "lstat", or filetest are returned.

Diciamo che _, a differenza della variabile topic non è una vera variabile ma un segnaposto particolare che viene interpretato come accesso alla cache dell'ultima operazione stat effettuata. E' facile costruire un esempio che mostri questi:



#!env perl

use v5.20;

my $file_name = $0; # myself

my @stat_values   = stat $file_name;
my @cached_values = stat _;

say "Same values for $file_name!" if ( $stat_values[1] == $cached_values[1] # inode
           && $stat_values[7] == $cached_values[7] # size
           && $stat_values[8] == $cached_values[8]  ); # atime

Lo stesso utilizzo non può essere effettuato con File::stat, che infatti riporta nella documentazione:


As of Perl 5.8.0 after using this module you cannot use the implicit $_ or
the special filehandle "_" with stat() or lstat(), trying to do so leads
into strange errors.

venerdì 23 giugno 2017

Secondary Selection & Emacs

Una discussione sulla mailing list Perl6 mi ha portato a fare una rapida ricerca e scoprire che, ovviamente, Emacs supporta anche
la Secondary Selection. Questa è una modalità nativa di X11 (che in realtà supporta fino a 4 clipboard coesistenti) che funziona un po'
come il kill-ring di Emacs stesso, ma che nella sua implementazione non si appoggio al kill-ring.
In sostanza è possibile copiare e incollare testo indipendentemente dalla regione selezionata e senza modificare il contenuto del kill-ring,
consentendo quindi ad Emacs di gestire fino a due clipboard contemporanee, una delle quali gestita tramite un ring e collegata
alla clipboard principale di sistema.

domenica 18 giugno 2017

Non usate :wq! per uscire da vi!

Una cosa che non capisco di Vi(m) e dei suoi utenti è la costante ed errata abitudine di usare il comando q! per uscire dall'editor.
Ho già scritto in precedenza riguardo questo soggetto, ma sono incappato in una innocente immagine di un minicorso del linguaggio C che, ancora una volta, insegna a chi è alle prime armi ad uscire da Vi con la combinazione mortale :wq! (qui l'immagine del post).


Vediamo di approfondire ancora una volta.
Anzitutto cosa suggerisce l'aiuto in linea di Vi? Eseguendo :help si ottiene qualcosa del genere:


*help.txt*      For Vim version 7.4.  Last change: 2016 Mar 31

                        VIM - main help file
                                                                         k
      Move around:  Use the cursor keys, or "h" to go left,            h   l
                    "j" to go down, "k" to go up, "l" to go right.       j
Close this window:  Use ":q<Enter>".
   Get out of Vim:  Use ":qa!<Enter>" (careful, all changes are lost!).

Andiamo bene! L'help in linea suggerisce di uscire dall'editor con :qa!, in sostanza l'equivalente di una kill -9!


Eppure ci sono alcuni modi molto piu' furbi di uscire da Vi senza rischiare di perdere i dati, e il mio preferito è quello di usare ZZ che esce salvando se necessario le modifiche. Perché questa cosa è importante? Perché forzare un aggiornamento del file ad ogni  uscita ne cambia il timestamp e potrebbe creare conflitti con strumenti di controllo delle versioni e di build automatico.
Ma non solo, se si digita :help :x si scopre che:


*:x* *:xit*
                        Like ":wq", but write only when changes have been
                        made.

ZZ                      Write current file, if modified, and quit (same as
                        ":x").  (Note: If there are several windows for the
                        current file, the file is written if it was modified
                        and the window is closed).

Mettiamo ora a confronto le varie modalità:


comando caratteri rischio di perdita modifiche
:qa! 4 si
:wq! 4 no
ZZ 3 (contando SHIFT) no
:x 2 no


Quindi perché non istruire gli utenti da subito ad usare modalità di uscita smart, visto che risultano perfino piu' compatte (in termini di caratteri) rispetto a quelle brutali?

venerdì 16 giugno 2017

Perl and regexps are too much verbose (!)

A colleague asked me a quick Perl way to check if a string contains only a predefined set of chars excluding a few ones.
Easy pal!
Regexp to the rescue!

Then I was asked for a way that did no use a regular expression, because "you know, regular expression can be somehow verbose".
Gosh!
My answer was simply "you don't use regexps a lot!".

I don't believe I have to explain to any (Perl) programmer that regexps have been designed to express in short a whole set of choices,
more in general an alphabet (in the most wider concept).

But let's move on, and after showing a quick and dirty one liner such as:


perl -E 'say "Wrong $_" unless ( /^[0-9]+$/ ); ' -F

I got another strange sentence as "yeah, but I don't like Perl too much, it is somehow verbose as a language".
And again, my answer was: "you don't use it regularly!".

It is clear Perl was seen in the wrong way, since both the language as well as regular expressions can be really short, as well as
a one liner…
No other comments required!

Distanza fra date "note" in Perl

Come si può fare a conoscere se una serie di date note si trovano ad una distanza interessante l'una dall'altra?
Facile con un po' di Perl!


Anzitutto la definizione: per distanza interessante intendo un numero di giorni multiplo di 10, anzi meglio, potenza di 10, ovvero 100, 1000, ecc.
Detto questo, costruiamo la struttura base:



#!env perl

use v5.20;
use DateTime;

my $begin = DateTime->new( year => ..., month => .., day => .. );
my $now = $begin->clone();
my $dates = [
    { day => 4, month => 7 }
    , { day => 19, month => 7 }
   ...
    ];

push @$dates, { day => $begin->day, month => $begin->month };
my $base = 10;

Con $begin si indica la data di partenza, mentre in $dates si inseriscono giorno e mese di alcune date a voi significative.
Per capirsi, $begin potrebbe essere la data di nascita di vostro figlio e $dates contenere il vostro matrimonio, laurea, ecc.
Da notare che inserisco automaticamente la data di partenza nell'array delle date da cercare, così da valutare la data contro se stessa
spostata chiaramente di alcuni anni.
Fino a qui, nulla di sorprendente. Beh, anche il resto è abbstanza noioso:



for ( 1 .. 100 ){
    $now->add( years => 1 );
    for my $when ( @$dates ){
 $now->set( day => $when->{ day }, month =>  $when->{month} );
 my $delta = ( $now->epoch - $begin->epoch ) / ( 60 * 60 * 24 );
 next if ( $delta % $base != 0 );
 say "La data " . $now->dmy . " si trova a $delta giorni da " . $begin->dmy 
           if ( ( log( $delta )/log( $base ) ) =~ /^\d+$/ );
    }
}

In un ciclo di 100 anni (perché oltre diventa poco interessante, almeno per voi visto che non ci sarete piu') si processa un anno alla volta
sommandolo alla data di partenza $now (clone della vera data). Contro tale "annata" si testano tutte le date ricercate per vedere se
la distanza in giorni $delta è multiplo di 10 ($base) e piu' precisamente se è un logaritmo in base 10.
Solo di quelle date si effettua una stampa a video.

lunedì 12 giugno 2017

Cosa sono gli Emacs mode? Major mode, minor mode, oh my...

Uno dei concetti chiave di Emacs che mi pare sia molto spesso sottovalutato da chi non lo utilizza è quello dei mode.
Emacs è un editor multi-mode, ovvero è possibile attivare piu' modi contemporaneamente.
A loro volta i mode si suddividono in due categorie principali:

  • major mode rappresentano il contesto di un buffer;
  • minor mode forniscono funzioni trasversali fra uno o piu' buffer.

Molto spesso la differenza non viene colta, ma è importante perché l'uso combinato dei mode può personalizzare tantissimo il comportamento
di Emacs.
Anzitutto Emacs ammette un solo major mode per buffer, mentre virtualmente infiniti minor mode possono essere attivati su ogni buffer.


Un major mode definisce il "contesto" di utilizzo del buffer, nonché le funzioni principali fornite in quel buffer. Ad esempio
se si sta editando un buffer che contiene uno script Perl, il relativo major mode fornirà funzioni legate a Perl. Analogamente, se
si sta visualizzando il contenuto di una directory, il relativo major mode (es. dired) fornirà le funzioni principali
per interagire con il buffer. Un major mode può anche "rimappare" alcuni tasti funzione per rendere piu' facile l'utilizzo all'interno
di tale buffer.


Un minor mode fornisce sottofunzioni specifiche all'interno del buffer, e magari a livello globale su tutti i buffer. L'esempio classico
è quello del correttore ortografico (es. flyspell) che agisce sul testo indipendentemente questo sia codice o testo o una chat.


Per meglio comprendere questi concetti, mi si passi un blasfemo paragone con Eclipse.
In Eclipse è possibile editare progetti Java, C/C++, Perl, PHP, Python (e altri). A seconda del tipo di progetto Eclipse carica funzioni
differenti e fornisce refactoring e renaming in modo differente, e questo è esattamente quello che fa un major mode Emacs. Ecco perché poco
sopra ho parlato di "contesti" del buffer.
Tornando ad Eclipse, i commenti e le parole chiave vengono evidenziate in modo analogo fra i vari linguaggi, come pure i marker degli errori
e dei problemi, e questo è quello che fa il minor mode Emacs (ok, per i font c'è la fontify, ma non scendiamo a questo livello).
E i template del codice? Eclipse fornisce template per, ad esempio, i get e set (getter e setter), cosa che in realtà richiede due passaggi: uno di
front-end e uno di backend. Il front-end mostra la UI all'utente, il back-end scrive il codice contestualizzato. Questa operazione può essere
fatta in Emacs tramite un altro minor mode (es. yas).


Per riassumere si tenga sempre presente che il major mode stabilisce cosa è possibile fare con un buffer, sia in termini di contenuti, che di tasti funzioni,
che di funzioni stesse, mentre un minor mode stabilisce quali arricchimenti si possono fornire al contenuto del buffer.
La linea di separazione non è così marcata, perché come è noto Emacs è un ecosistema che si piega su stesso e si espande, ma per avvicinarsi a questo
strumento quanto sopra dovrebbe bastare.