Muitos programadores alegam que linguagens com python ou ruby são mais faceis de entender pois essas linguagens possuem nomes mais apropriados para comandos e etc. Uma vez li em um blog (até sei qual o post, mas Ética é Ética) que em python operações booleanas eram mais compreensíveis, pois usavam nomes mais intuitivos como and or xor ao contrario de && || ^ respectivamente.

Hoje em meus estudos sobre C eis que encontro um cabeçalho (header) chamado iso646.h localizado em /usr/include/. Olhando o seu pequeno conteúdo podemos ver algo parecido com isso:

1
2
3
4
5
6
7
8
9
10
11

#define	and	&&
#define	and_eq	&=
#define	bitand	&
#define	bitor	|
#define	compl	~
#define	not	!
#define	not_eq	!=
#define	or	||
#define	or_eq	|=
#define	xor	^
#define	xor_eq	^=

A dica é muito cuidado com o que você fala, principalmente se você não tem um profundo entendimento do assunto.

Se você conhece alguém que diz que sabe muito sobre C, duvide, pois é impressionante como a cada fim de semana mergulhando nas profundezas da linguagem aprendo mais e mais.

Para instalarmos o abnTex primeiramente precisamos ter o MacTex instalado no mac.

Depois basta executar o conjunto de comandos no Terminal.app.

1
2
3
4
5
6

wget http://codigolivre.org.br/frs/download.php/5337/abntex-0.9-beta2.tar.gz
# or
curl http://codigolivre.org.br/frs/download.php/5337/abntex-0.9-beta2.tar.gz -o abntex-0.9-beta2.tar.gz
tar -xzf abntex-0.9-beta2.tar.gz
sudo cp -r abntex-0.9/ /usr/local/texlive/2011/texmf-dist/tex/latex/
sudo texhash

Na primeira ou na terceira linha baixamos a versão mais recente do abnTex, que apesar de estar em uma versão Beta possui uma boa estabilidade. Na quarta linha descompactamos o arquivo baixado. Na quinta linha copiamos os arquivos necessários para a pasta padrão de instalação do MacTex. Na sexta linha atualizamos a base de pacotes do Tex.

Qual duvida, critica ou sugestão não deixe de comentar.

A primeira coisa a se fazer para começar a usar o Emacs é instalá-lo. De preferencia a versão mais recente 24, que apesar de estar em fases final de testes já é bem estável a algum tempo. O processo de instalação depende do seu sistema operacional.

No Mac OS X com homebrew:

1
2

brew install emacs --HEAD --use-git-head --cocoa
brew linkapps

A flag --cocoa faz com que um aplicativo Emacs.app seja criado, se desejar usar o Emacs apenas no terminal, basta remover essa flag.

No Mac OS X com os binários:

1
2
3

wget http://emacsformacosx.com/emacs-builds/Emacs-pretest-24.0.95-universal-10.6.8.dmg
open Emacs-pretest-24.0.95-universal-10.6.8.dmg
cp /Volumes/Emacs/Emacs.app /Applications/

No Ubuntu:

1
2
3

sudo add-apt-repository ppa:cassou/emacs
sudo apt-get update
sudo apt-get install emacs-snapshot

Compilando apartir dos fontes:

1
2
3
4
5
6
7
8

wget http://emacsformacosx.com/emacs-sources/emacs-24.0.95.tar.gz
tar -xzf emacs-24.0.95.tar.gz
cd emacs-24.0.95
mkdir build
cd build
../configure
make
sudo make install

Depois de instalado, para executá-lo você pode usar algum laucher, digitar emacs no terminal, ou clicar no link criado no lugar correspondente ao seu sistema operacional (por exemplo: ~/Applications/Emacs.app no Mac OS X).

Uma imagem da tela de inicio do Emacs apos ele terminar de ser iniciado em modo gráfico.

Já em modo texto a imagem deve ser semelhante a essa:

Depois da instalação e da execução do Emacs a primeira coisa a se fazer é iniciar o modo tutorial, para que você possa entender melhor as características do Emacs.

Para iniciar o tutorial basta pressionar as teclas Meta (Alt) + x ou na linguagem do Emacs M-x. Este é um dos principais atalhos do Emacs, pois a partir dele qualquer outro comando pode ser executado. Você deve perceber que na na barra inferior deve ser possível entra com algum comando. Então basta digitar help-with-tutorial-spec-language e digitar o seu idioma de sua preferencia, no nosso caso Brazilian Portuguese

Mais fácil do que isso só baixando o mesmo tutorial em pdf e em pt-br neste link.

Links Uteis

Abaixo estão alguns links uteis para quem estar começando com o Emacs

• Emacs Tour
• Emacs Wiki Novatos
• WikEmacs
• MasteringEmacs

Qualquer duvida, critica ou sugestão por favor comentem. Principalmente sobre melhorias, pois senti uma dificuldade muito grande ao escrever este post introdutório.

Não importa apenas use. Essa seria a resposta mais curta para esta pergunta que gera tantas brigas e discussões bobas. A quase um mês atras Giancarlo Lionetti publicou um post interessante no blog da Atlassian com o seguinte título: Mercurial vezes Git: Porque Mercurial (do inglês Mercurial vs Git: Why Mercurial?). Em Resumo ele tenta explicar a pergunta do porque usar Mercurial. Ele prometeu escrever um outro post sobre do porque usar Git. Minha ideia inicial era publicar este post apenas depois disto, mas como já se passou quase um mês e nada, resolvi me antecipar.

Mercurial vs Git: Why Mercurial? ele mostra uma tabela (abaixo) muito interessante sobre como ambos os sistemas de controle de versão (scm) usam uma interface de uso muito parecida.

Podemos perceber que apesar de cada scm possuir características completamente diferentes o modo como trabalhamos em ambos são muito semelhantes. É claro que existem muitos outros comandos, e é exatamente neste ponto onde cada scm vai realmente mostrar seu valor. Mas na maioria dos projetos não usamos mais do que os comandos descritos na tabela acima. Então não pense que você é melhor ou pior por usar qualquer scm disponível. Procure entender qual o funcionamento as vantagens e desvantagens e quando usar cada um.

Então, era isso que eu tinha para falar, qualquer duvida, critica ou sugestão é só comentar, até o próximo domingo.

Infelizmente por problemas políticos (acredito eu) a Apple deixou de distribuir o GCC (deste a versão 4.2 do Xcode), e passou a adotar como compilador padrão o Clang mais o llvm-gcc (desde a verão 4.1 do Xcode) que é uma interface entre o GCC e o LLVM.

Em muitos cenários isso não causaria nenhum problema, mas a interface do llvm-gcc usa a versão 4.2 do GCC. Atualmente a versão corrente do GCC é a 4.7 (estável) e 4.8 (desenvolvimento) e em se tratando de GCC uma pequena mudança de versão (minor) incluem muitas modificações/correções/novas funcionalidades. Outro problema existente é que infelizmente muitas bibliotecas e binários úteis no dia a dia dos programadores, possuem uma forte dependência com o GCC. Depois de encontrar o post do Solarian Programmmer resolvi instalar a versão mais nova do GCC.

Aproveitando a instalação criei um script em bash para baixar, extrair, compilar e instalar todos as bibliotecas necessárias bem como o próprio GCC. Eu fiz umas pequenas modificações na hora de executar o ../configure, onde altero o prefix da instalação de /usr/local para /usr/local/gcc e adiciono um sufixo ao nome final do binário do GCC que passara a se chamar gcc-4.7 ao invés de gcc.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79

#! /bin/bash

PREFIX=/usr/local/gcc
BUILD_FOLDER=gcc_build

if [ $UID -ne 0 ] ; then
    echo "Root Please"
    exit 1
fi

mkdir -p $BUILD_FOLDER

cd $BUILD_FOLDER

echo "Download need files"

wget ftp://ftp.gmplib.org/pub/gmp-5.0.4/gmp-5.0.4.tar.bz2 -c
wget http://www.mpfr.org/mpfr-current/mpfr-3.1.0.tar.bz2 -c
wget http://www.multiprecision.org/mpc/download/mpc-0.9.tar.gz -c
wget ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302/gcc-4.7.0-RC-20120302.tar.bz2 -c

echo "Compiling gmp"

tar xfz gmp-5.0.4.tar.bz2
cd gmp*
mkdir build
cd build

../configure --prefix=$PREFIX
make
make check
make install

cd ../../

echo "Compiling mpfr"

tar xfz mpfr-3.1.0.tar.bz2
cd mpfr*
mkdir build
cd build

../configure --prefix=$PREFIX --with-gmp=$PREFIX
make
make install

cd ../../

echo "Compiling mpc"

tar xfz mpc-0.9.tar.gz

cd mpc*
mkdir build
cd build
../configure --prefix=$PREFIX --with-gmp=$PREFIX --with-mpfr=$PREFIX
make
make install

cd ../../

echo "Compiling GCC"

tar xfz gcc-4.7.0-RC-20120302.tar.bz2

cd gcc*
mkdir build
cd build
../configure --prefix=$PREFIX --enable-checking=release --with-gmp=$PREFIX --with-mpfr=$PREFIX --with-mpc=$PREFIX --program-suffix=-4.7
make -j 2
make install


echo "GCC Build Complete in " $PREFIX

cd ../../../

read -p "Erase your build directories (y/n)?"
[ "$REPLY" == "y" ] || rm -rf $BUILD_FOLDER

Para testar o novo GCC bastar adicionar a pasta /usr/local/gcc/bin no PATH do seu Terminal e digitar: $ gcc-4.7 -v

A saída deve se parecer com isso:

1
2
3
4
5
6
7

  $ gcc-4.7 -v
  Using built-in specs.  COLLECT_GCC=gcc-4.7
  COLLECT_LTO_WRAPPER=/usr/local/gcc/libexec/gcc/x86_64-apple-darwin11.3.0/4.7.0/lto-wrapper
  Target: x86_64-apple-darwin11.3.0
  Configured with: ../configure --prefix=/usr/local/gcc --enable-checking=release --with-gmp=/usr/local/gcc --with-mpfr=/usr/local/gcc --with-mpc=/usr/local/gcc --program-suffix=-4.7
  Thread model: posix
  gcc version 4.7.0 20120302 (prerelease) (GCC)

Dica, como o processo de compilação leva algumas horas vale a pena testar os pacotes distribuídos no High Performance Computing for Mac OS X. A instalação dele é super simples mas é por sua conta e risco =P.

1
2
3
4

  $ wget 'http://prdownloads.sourceforge.net/hpc/gcc-lion.tar.gz?download'
  $ gunzip gcc-bin.tar.gz
  $ tar xfz gcc-lion.tar.gz
  $ sudo tar -xvf gcc-bin.tar -C 

Então é isso, qualquer problema, critica ou sugestão é só comentar ou enviar um email para dannluciano at gmail dot com.

Ate hoje eu sincronizava meus arquivos de configuração (.zshrc, .bash_profile, .emacs.d) utilizando somente o git. Estava tudo indo muito bem, mas depois que passei a usar vários computadores (macbook e imac em casa, 2 pcs na ufrn), ficou um tanto chato ter que sincronizar (git pull) manualmente toda vez antes de fazer alguma operação. O maior problema nem era sincronizar e sim resolver os conflitos que sempre apareciam. Na maioria das vezes os conflitos eram simples, pois boa parte eram apenas afinamentos na configuração (ajuste de tema, fonte etc), mas mesmo assim causavam um stress enorme.

Então depois de muitos stress resolvi acabar com esse problema. A solução que encontrei e que vou apresentar não é nada inédita mas resolve que é uma beleza (e isso é o que importa). Acredito que todos os leitores conheçam o Dropbox né? Se não conhece corre e clicka no link porque você esta perdendo muita coisa. Vamos deixar de papo e ir para solução.

Basicamente eu criei uma pasta dentro da pasta do Dropbox que será responsável por guardar todos os arquivos de configuração.

1

$ mkdir ~/Dropbox/dotfiles

Depois eu movi todos os meus arquivos de configuração para o diretório criado. Você pode também criar novos arquivos. Fica a sua escolha. Vou mostrar apenas um exemplo.

1

$ mv .emacs.d ~/Dropbox/dotfiles/emacs.d

Em seguida criei um script em Ruby para criar links simbólicos para estes arquivos.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#! /usr/bin/env ruby

require 'fileutils'

include FileUtils

user_dir = Dir.home
src_path = "#{user_dir}/Dropbox/dotfiles"
dest_path = "#{user_dir}"

files = %w( bash_profile emacs.d gitattributes gitignore
install_dotfiles oh-my-zsh bashrc gemrc gitconfig gitignore_global
irbrc zshrc)

files.each do |file|
  ln_s "#{src_path}/#{file}", "#{dest_path}/.#{file}", :force => true
  puts "ln -s #{src_path}/#{file} #{dest_path}/.#{file}"
end

Depois basta executar o script em ambas as maquinas que se pretende usar. Não se esqueça de instalar e configurar o Dropbox em cada uma das maquinas. Com essa solução ate o presente momento consegui reduzir o esforço de sincronizar meus arquivos a quase zero. Pois o único problema que tenho agora com que me preocupar é em criar configurações que funcionem em ambas as maquinas e sistemas operacionais (Mac OS X e Linux).

Meus arquivos de configuração estão no Github MyDotFiles e .emacs.d, mas não pretendo ficar comitando pequenas modificações, apenas adições de funcionalidade, plugins e libs.

Então é isso, espero ter ajudado. Qualquer problema dica ou sugestão é só comentar ou enviar um email (dannluciano@gmail.com) =p.