Feeds:
Posts
Comments

I’ve watched this yesterday and can stop to watch again and laugh a lot of this examples it shows. Of course that as a Pythonist the first thing I do was to try to reproduce some of the weird behaviors I saw there in Python, well till now I did get anyone.

Please take a look on the funniest talk about weirdness in programming languages  what here

I particularly have a  bunch of projects I follow/cloned from git, such as linux-kernel, kexec-tools, and so on. What happens is that I like to be tuned with those projects and their code. Once, twice or many times in a week I get into their git directory and give a pull to grab the freshest code. As I said before, I have a lot of projects I like to follow, digging in code, try to find bugs just for learn, fun and of course collaborate. It’s painful to type a git in all them one by one. So, why not to give a git pull in all them. Yep. That is why I just typed this Python code. A very simple, as Python always do, to exec a git pull in all my git repositories in my specific folder : Study or Collaborate, and so on.

Now I’m sharing it with you, and of course it’s already in my github that you can grab/see here.

How to run this?

$python pygitpull.py YOUR_GITS_DIR

Wait for it drinking a huge cup of coffee and get the new code.

There is long time since I wanted to type some vim plugin, but always I took a look in vim script codes think “oh boy, it’s so ugly script language” and so I lost my interest. Till days ago, when I figure out I could not only use just vim script language but also Python. Now, things becomes interesting.

As a product of my vim script plugin study I’ve decided to type two them. One is using a simple by pass that calls pep8 and check your current py script and you can fix and recheck it again just typing a command: [ESC]:PEP8. You can check its plugin here . The other  I just finished it right now and allows you to in visual mode select a piece of code and send it to the osuosl pastebin. This one you can check here vimpastebin.

As you see bellow, after press F5 in vmode plugins sends the piece of code to pastebin and returns you a beautiful url in bottom.

postpaste

Code is itself explained so I won’t write anything more detailed here about, just give a check there :)

If you use Rythmbox and you hate the way some plugins for music lyrics works and  are broken briging just piece of the lyric and not the whole one. Well, I just suggest you to use my plugin that uses AZLyric instead terra.com. AZlyric web site is,  for me, the best source of indie lyrics/bands/musics you can find :).

If you want to try, feel free trying my beautiful plugin :3 https://github.com/kirotawa/pluginsinpython/tree/master/rhythmbox/patches_rhythm_git. If you find some bug, please report me :). I’m already using this patch on my rythmbox. Unfortunatelly no one in rythm devel list seemed be interested in such thing. But well, I’m using, I’m taking advantage on this, and I’m happy :P.

Desenvolver software em C requer muita atenção, mas às vezes deixamos alguns descuidos. Em C um descuido pode ser grave, pode gerar bugs indesejados (não que haja algum desejado). Um dos erros comuns é não lidar corretamente com a alocação de recurso de memória. Em particular, alocar e esquecer de liberar ela para o sistema (memory leak).

Ao contrário de linguagens como Java, Python, C++ que possuem garbage collector, C é uma linguagem que espera de você a sabedoria de um Jedi na hora de lidar com recursos de baixo nível, tal como memória.

Quando um problema de memory leak acontece em user space (aplicações a nível de usuário)  a solução é partir para ferramentas bem conhecidas como Valgrind. Com ela é possível encontrar informações precisas sobre os memory leaks causados. Mas e se você programa em nível de Kernel, um driver/modulo por exemplo? Bem, o ponto é que você deve ser um mestre Jedi se chegou a esse nível e memory leaks não deveriam ser erros comuns no seu dia a dia. Mas somos humanos, certo?

Kmemleak foi introduzido no kernel 2.6.17-rc6. É nada mais que um mecanismo de memleak detector em kernel space. Tem lá o seu custo, já que a ideia por trás do kmemleak é varrer de tempos em tempos o kernel, descobrir quais memorias estão/foram alocadas e quais não foram liberadas, dessa forma sinalizando ou possíveis memleaks ou de fato um. 

Há uma discussão extensa sobre esse recurso. Se ele é realmente útil, se o custo dele não é um peso para quem quer usar. Principalmente em sistemas com muito recurso de memoria. Não por menos, quando se usa o kmemleak se percebe um certo acréscimo de tempo no boot do sistema.

Porém, considerações de lado, vamos imaginar que em algum momento você precisará usar este recurso. Então, como usá-lo?

Antes de tudo você irá precisar compilar o seu kernel com esse recurso selecionado  CONFIG_DEBUG_KMEMLEAK (kernel hacking -> kernel memory leak detector). Segundo, você irá precisar setar o tamanho do log que o kmemleak irá usar. O valor default é 400, aconselho usar o limite: 40000 assim você irá evitar surpresas (o recurso estourar o log e ficar desabilitado).

Com o kernel compilado com as opções de kmemleak é só instalar e rebootar a máquina. Feito isso partimos para a montagem do debugfs, pois é lá que o sysfs para o kmemleak estará presente para ser usado.  Para tal: mount -t debugfs nodev /sys/kernel/debug/.  Pronto, seu kmemleak detector está pronto para ser usado.

Como usá-lo:

  • echo clear > /sys/kernel/debug/kmemleak (limpa o log atual e talvez você queira fazer isso antes de buscar pelos leaks do seu módulo)
  • echo scan > /sys/kernel/debug/kmemleak (força um scan nesse instante, uma vez que por default o scan é realizado de 10 em 10 minutos. Este é o valor default e você poderá alterá-lo)
  • cat /sys/kernel/debug/kmemleak (irá listar os possíveis memory leaks encontrados)

Para saber mais sobre como usar o kmemleak dê uma olhada na documentação link [1]

Para testar como ele funciona você pode escrever um simples módulo hello world e provocar um memory leak.

  #include <linux/kernel.h>                                                                                                                                                                                                       
  #include <linux/module.h>
  #include <linux/init.h>
  #include <linux/vmalloc.h>

  void causing_memleak(void)
  {
          char *ptr;
          ptr = vmalloc(1024);
  }

  static int __init hello_init(void)
  {
          causing_memleak();
          pr_debug(KERN_DEBUG "Hello World!\n");
          return 0;
  }
  
  static void hello_cleanup(void)
  {
          pr_debug(KERN_DEBUG "Cleaning up\n");
  }
  
  module_init(hello_init);
  module_exit(hello_cleanup);

No código acima a função “causing_memleak” aloca um dado recurso de memória, mas nunca o libera. Se você carregar este módulo e depois liberar ele, por fim usar kmemleak: cat /sys/kernel/debug/kmemleak, você verá que ele foi detectado.

Finalizando, é um recurso útil, mas o mais esperado é que você saiba o que tá fazendo e que jamais deixe que situações como esta ocorra em kernel space :). Mas se um dia precisar usar kmemleak, go ahead.

Referências:
[1] https://www.kernel.org/doc/Documentation/kmemleak.txt

[2] http://lwn.net/Articles/187193/

[3] http://psankar.blogspot.com.br/2010/11/detecting-memory-leaks-in-kernel.html

[4]  https://lwn.net/Articles/187979/

Você que está brincando com o eudpytula, essa é pra você.

  • Compila: make localmodconfig (assim ele vai selecionar os módulos que realmente importam para sua distro)
  • yes “” | make localmodconfig (dê yes pra todo mundo)
  • make -j42 (substitua 42 pelo seu número de cores, ou deixe o 42 e ele usará o máximo)
  • make modules (construindo seus módulos)
  • make modules_install
  • make install
  • Reboot, teste, chore se o seu kernel bugar.
  • Hora da limpeza, você terá que deletar do /boot, na mão, o que você não quer. Depois, grub-mkconfig -o <<caminho do grub.cfc).

 

Done =)

Para aqueles que começaram a programar em Python agora, encontrar regras de indentação, e mais importante, quebrar elas e receber erros no shell, não deve ser algo muito interessante.
Eu particularmente gosto das regras do Python, elas agregam valor as boas práticas de coding. Tudo para que seu código seja mais legível e outros possam lê-lo um dia, em um futuro, sem precisar te xingar.

Como auxílio as boas práticas é possível encontrar alguns cheats e ferramentes que podem ajudar.
Primeiro, os cheats (e infelizmente essa é apenas para usuários vim/vi).

  • Nada mais que 80 colunas: essa ideia não poderia ser melhor, já que nem todo mundo usa um monitor wide screen, certo. Basta por essa linha no seu .vimrc silent match ErrorMsg /\%>80v/
  • 4 espaços: essa vem direto do PEP08. Diferente do Kernel que usa 8 espaços ou GNU style. Python usa 4 espaços (nada de tab!). Basta setar as seguintes linha no seu .vimrc e tudo funcionará perfeitamente.
set smartindent
set tabstop=4
set softtabstop=4
set shiftwidth=4
set expandtab
  • Retab: útil se o seu arquivo está zoneado por tabs. Basta digitar ESC: %retab no vim. Ele vai arrumar seu .py de acordo com a configuração anterior de espaços.
  • Removendo espaços no final da linha ou traling white spaces: autocmd BufWritePre *.py :%s/\s\+$//e.

Bacana, certo?

Para auxiliar ainda mais, que tal usar uma ferramenta chamada pep8 que vai te ajudar a checar se o seu arquivo está de acordo com o pep08 e de quebra usar o Pylint para analisar estaticamente o seu código?

Ambas são incrivelmente fáceis de se usar. Então, espero que essas dicas tenham sido úteis =)

Follow

Get every new post delivered to your Inbox.