Computação

__hg_ps1 – Nome da branche na linha de comando do bash

Nov 4th

Posted by Daniel Elias in Computação

No comments

Pra quem já usou git, sabe que existe o __git_ps1 que você pode usar para colocar na linha de comando do bash para lhe mostrar qual a branch atual de trabalho. Sem essa funcionalidade fica difícil trabalhar com as branches sem se perder de vez em quando. Procurando por algo similar no mercurial, achei o __hg_ps1.

Muito simples de instalar:

  1. baixe o tarball
  2. instale como qualquer aplicação python ( python setup.py install )
  3. configure PS1 no ~/.bashrc

wget -c http://bitbucket.org/krbullock/hg_ps1/get/tip.tar.gz

tar xvf tip.tar.gz

cd hg_ps1/

sudo python setup.py install

Coloque no ~/.bashrc o seguinte:

1
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;31m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[01;33m\] $(A=`__hg_ps1`  && echo "[$A]" ) \[\033[0m\] \[\033[00m\]$  '

Se você tiver também o git instalado, coloque este abaixo:

1
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;31m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[01;33m\]$(__git_ps1 " [%s]") $(A=`__hg_ps1` && echo "[$A]" ) \[\033[0m\] \[\033[00m\]$  '

Como pode ser visto no comando acima, tem também o __git_ps1, se você entrar em algum repositório git, também funciona, a melhor configuração para manter os dois foi essa acima. Isso é muito útil. :P

, , ,

Trabalhando com o Mercurial – HG

Nov 3rd

Posted by Daniel Elias in Computação

No comments

Introdução

Nos últimos tempos estou conscientizando os meus colegas de trabalho sobre os benefícios da utilização de um controle de código distribuído. Fiz uma análise nas vantagens e desvantagens do Git e HG (Mercurial) e escolhemos o Mercurial pois precisamos trabalhar em um ambiente heterogeneo e o suporte do Git ao windows  ainda é precário, até achamos algumas iniciativas como o MSysGit, porém ainda possuem um longo caminho pela frente para se tornar uma ferramenta que atenda as nossas necessidades(realidade). A comunidade do mercurial está mais evoluida neste sentido, e ao que estudamos o Mercurial disponibiliza todas as funcionalidades que almejamos em um gerenciador de código distribuído.

O objetivo deste post é mostrar o fluxo de trabalho com mercurial, comentando os comandos executados em um fluxo de trabalho escolhido por mim. Alguns devem se perguntar, “Por que escolhido por você ?”, porque com o gerenciador de código distribuído não existe um fluxo de trabalho obrigatório a ser seguido, as ferramentas oferecem recursos para você adaptar fácilmente o fluxo de trabalho, portanto uma vez que você entende os conceitos do gerenciador de código distribuído você nota que é você quem faz seu fluxo de trabalho.

Não se assuste com as sequências de códigos, logo abaixo segue os comentários sobre as operações efetuadas, uma das coisas legais do mercurial é que a maioria dos comandos são legíveis, portanto tente entender somenter ao ler os comandos, senão entender, leia os comentários e avalie novamente os comandos, tudo deve fazer sentido, pelo menos eu espero que faça sentido. :P

Como dito anteriormente o objetivo não é explicar os conceitos. Portanto para entender os conceitos por trás do que é um gerenciador de código distribuído recomendo a leitura dos seguintes textos:

Configuração

Para este post estou usando mercurial 1.3.1 instalado no ubuntu através do easy_install.

Recomendo configurar também o __hg_ps1, como nesse post.

Antes de começar configure seu .hgrc. Crie um arquivo no seu home:

touch ~/.hgrc

E então edite com seu editor favorito e coloque as seguinte informações sobre a aparência do hg:

[ui]

username = Seu Nome <seu@email.com.br>

style = compact

Antes de continuarmos, uma coisa que é muito legal no mercurial são as extensões. O mercurial já vem com uma série de extensões incluídas, para uma lista completa clique aqui, abaixo algumas que julgo essenciais, embora eu não vá explicar a utilização de todas nesse post, já deixe habilitado, não custa nada :-) com certeza explicarei nos posts seguintes.

  • mercurialqueue
  • rebase
  • graphlog

Para habilitar adicione ao arquivo ~/.hgrc também uma nova seção para as extensões: :-)

[extensions]

hgext.graphlog =

hgext.mq =

hgext.rebase =

Comandos básicos

Tendo em mente que você já sabe os conceitos, vamos fazer uma lista breve de comandos básicos que você deve saber na ponta do dedo.

hg clone <url>

faz uma cópia local do repositório informado

hg pull

faz download das mudanças no repositório de origem (pai)

hg push

faz upload das mudanças no repositório de origem (pai)

hg status

verifica se há alterações locais

hg tip

verifica qual a versão que está a frente no repositório, ou se preferir no topo(HEAD)

hg incoming

verifica o que tem de novo no repositório de origem, frequentemente usado antes de fazer um hg pull, para saber o que se esperar.

hg outgoing

verifica o que você tem de novo em relação ao repositório de origem, frequentemente usado antes de fazer hg push

hg merge

uni duas branches ou changeset transformando em uma.

Trabalhando

Vamos agora iniciar o trabalho, você vai codificar um projeto novo, então você cria uma pasta, inicia o repositório e adiciona inicialmente um arquivo de README com instruções ou informações sobre o projeto:

1
2
3
4
5
6
7
8
9
10
:~/src $  mkdir projetonovo
:~/src $  cd projetonovo/
:~/src/projetonovo $  ls
:~/src/projetonovo $  hg init
:~/src/projetonovo $  echo "Este projeto vai dominar o mundo" >> README
:~/src/projetonovo $  hg add README
:~/src/projetonovo $  hg ci -m "Adicionado arquivo de README com informações sobre o projeto"
:~/src/projetonovo $  hg tip
0[tip]   b65bb6ffc97c   2009-11-02 14:55 -0400   root
Adicionado arquivo de README com informações sobre o projeto

Agora temos uma pasta com o nosso projeto e que está sendo versionado pelo mercurial, adicionamos um arquivo com informações para ser rastreado, fizemos o commit e depois verificamos qual o tip(head) do repositório. Você pode verificar que a saída do hg tip foi algo bem resumido, isso por que configuramos no ~/.hgrc na seção [ui] , o estilo compacto style = compact . Se você deseja que o output dos comandos do mercurial sejam mais verbosos, basta comentar o style = compact ou remover do ~/.hgrc.

Dentro de uma equipe de desenvolvimento de software, existem pelo menos 2 ciclos básicos que ficam em loop olhando pela perspectiva de implementação e não de análise, eu chamo de ciclo implementativo e corretivo.

Abaixo apresento minha solução para os ciclos em um mundo ideal. Há quem diga que não vivemos em um mundo ideal, mas eu acho importante para entender e fixar os conceitos. :P

Ciclo implementativo

  1. Identicar nova funcionalidade e traçar funcionamento básico
  2. Abrir uma ramificação(branch) do projeto
  3. Codificar e testar na branch criada SOMENTE para esta feature
  4. Unir(merge) tip da branche da nova feature ao tip da mainline (branche default) e commitar
  5. Fechar a ramificação da branche da nova feature

Claro, aqui não é usado nenhuma formalidade nem nome bonito. É simplesmente como eu resumo minhas tarefas implementativas ao meu gosto. :P

Esse processo pode variar, o mercurial dá a liberdade de você fazer isso como quiser, abaixo eu demonstro como eu faço isso. Uma coisa interessante de ser mencionada é que as branchs são operações no repositório e portanto entram para o histórico do repositório, não esqueça que as branches precisam ser commitadas, dependendo do seu projeto você pode não querer saber como cada desenvolvedor criou a branch ou que nome deu para a branch, eu acho interessante e não vejo problema nisso, muito pelo contrário, temos um histórico fidedigno do desenvolvimento do projeto.

Então vou criar a branche para implementar a funcionalidade UltraMegaBoga de todos os tempos :P .

1
2
3
4
5
6
:~/src/projetonovo $  hg branch NovaFeature_UltraMegaBoga
marked working directory as branch NovaFeature_UltraMegaBoga
:~/src/projetonovo $  hg ci -m "Criado branch para implementar NovaFeature UltraMegaBoga"
:~/src/projetonovo $  hg branches
NovaFeature_UltraMegaBoga      1:7fc70f299283
default                        0:b65bb6ffc97c (inactive)

Dae você pode ver que usamos o hg branch para nomear a branche padrão atual (default) e depois criamos de fato através do commit (ci), e depois confirmamos usando o hg branches para verificar quais as branches que temos no repositório. E agora sim podemos codificar a funcionalidade. No commit automaticamente somos movidos para a branch nova que acabamos de criar.

Então, implementando uma nova feature:

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
:~/src/projetonovo $  touch teste.py
:~/src/projetonovo $  echo "print('Hellowww mercurial')" >> teste.py
:~/src/projetonovo $  python teste.py
Hellowww mercurial
:~/src/projetonovo $  hg status
? teste.py
:~/src/projetonovo $  hg add teste.py
:~/src/projetonovo $  hg status
A teste.py
:~/src/projetonovo $  hg ci -m "Criado arquivo da funcionalidade UltraMegaBoa"
:~/src/projetonovo $  hg glog
@  2[tip]   c192d84f042a   2009-11-02 17:16 -0400   root
|    Criado arquivo da funcionalidade UltraMegaBoa
|
o  1   7fc70f299283   2009-11-02 17:01 -0400   root
|    Criado branch para implementar NovaFeature UltraMegaBoga
|
o  0   b65bb6ffc97c   2009-11-02 14:55 -0400   root
Adicionado arquivo de README com informações sobre o projeto

:~/src/projetonovo $  echo "import this" >> teste.py
:~/src/projetonovo $  hg status
M teste.py
:~/src/projetonovo $  hg ci -m "Nova funcionalidade UltraMegaBoga implementada"
:~/src/projetonovo $  hg glog
@  3[tip]   f337dc212ea0   2009-11-02 17:19 -0400   root
|    Nova funcionalidade UltraMegaBoga implementada
|
o  2   c192d84f042a   2009-11-02 17:16 -0400   root
|    Criado arquivo da funcionalidade UltraMegaBoa
|
o  1   7fc70f299283   2009-11-02 17:01 -0400   root
|    Criado branch para implementar NovaFeature UltraMegaBoga
|
o  0   b65bb6ffc97c   2009-11-02 14:55 -0400   root
Adicionado arquivo de README com informações sobre o projeto

:~/src/projetonovo $  echo "print('Testando funcionalidade ultramegaboga...')" >> teste.py
:~/src/projetonovo $  hg status
hg M teste.py
:~/src/projetonovo $  hg ci -m "Implementado TesteUnitario e tudo funcionando como esperado"
:~/src/projetonovo $  hg glog
@  4[tip]   63ddafc85f03   2009-11-02 17:21 -0400   root
|    Implementado TesteUnitario e tudo funcionando como esperado
|
o  3   f337dc212ea0   2009-11-02 17:19 -0400   root
|    Nova funcionalidade UltraMegaBoga implementada
|
o  2   c192d84f042a   2009-11-02 17:16 -0400   root
|    Criado arquivo da funcionalidade UltraMegaBoa
|
o  1   7fc70f299283   2009-11-02 17:01 -0400   root
|    Criado branch para implementar NovaFeature UltraMegaBoga
|
o  0   b65bb6ffc97c   2009-11-02 14:55 -0400   root
Adicionado arquivo de README com informações sobre o projeto

Opa!, muita informação?… nada, só algumas sendo repitidas. :P

Linhas 1 ~ 10: Nestas linhas apenas criamos um arquivo, colocamos conteúdo dentro dele, executamos, verificamos o status do repositório e eles nos diz que o arquivo novo não foi adicionado e então o adicionamos ao projeto para ser rastreado e então commitamos. Simples hein ?!

Linhas 11: Na linha 11 há um comando novo que ainda não comentamos, o comando hg glog que mostra o log do repositório através de um grafo, o que facilita bastante a vida quando estamos trabalhando com branches(ramificações), para entender melhor veja bem que o glog traz a arvore de forma natural, ou seja,  da raiz até o topo ou nós. Na primeira coluna mostra os nós e aonde você está em relação aos nós da arvore, cada nó desse representa um commit, os nós são representados por o e onde você está através do @, na segunda coluna estão as revisões de números inteiros e sequencias que você pode usar para se direcionar ou situar na árvore ou histórico, o mercurial usa revisões sequencias e hashs para controlar o histórico e os changesets(conjuntos de mudanças).

E então esses procedimentos se repetem até o nó 4 ou changeset 63ddafc85f03, conforme pode ser visto localizando o @ no resultado do comando hg glog.

Vamos voltar para o branche default para fazer o merge e incorporar as modificações da branche UltraMegaBoga

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
:~/src/projetonovo $  hg update default
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
:~/src/projetonovo $  hg glog
o  4[tip]   63ddafc85f03   2009-11-02 17:21 -0400   root
|    Implementado TesteUnitario e tudo funcionando como esperado
|
o  3   f337dc212ea0   2009-11-02 17:19 -0400   root
|    Nova funcionalidade UltraMegaBoga implementada
|
o  2   c192d84f042a   2009-11-02 17:16 -0400   root
|    Criado arquivo da funcionalidade UltraMegaBoa
|
o  1   7fc70f299283   2009-11-02 17:01 -0400   root
|    Criado branch para implementar NovaFeature UltraMegaBoga
|
@  0   b65bb6ffc97c   2009-11-02 14:55 -0400   root
Adicionado arquivo de README com informações sobre o projeto

Outro comando novo, hg update, com esse comando você pode alternar entre as branches(ramificações) do seu projeto e nas revisões também bastando passar o parâmetro hg update -r REV, na linha 1 alternei para a branch default e você pode perceber na saída do comando hg glog que o @ voltou para revisão 0 que é onde a revisão default parou, certo ? os outros commits foram da branche NovaFeature_UltraMegaBoga.

Agora vamos fazer o merge das duas branches.

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
:~/src/projetonovo $  hg merge NovaFeature_UltraMegaBoga
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, dont forget to commit)
:~/src/projetonovo $  hg tip
4[tip]   63ddafc85f03   2009-11-02 17:21 -0400   root
Implementado TesteUnitario e tudo funcionando como esperado
:~/src/projetonovo $  hg glog
@  4[tip]   63ddafc85f03   2009-11-02 17:21 -0400   root
|    Implementado TesteUnitario e tudo funcionando como esperado
|
o  3   f337dc212ea0   2009-11-02 17:19 -0400   root
|    Nova funcionalidade UltraMegaBoga implementada
|
o  2   c192d84f042a   2009-11-02 17:16 -0400   root
|    Criado arquivo da funcionalidade UltraMegaBoa
|
o  1   7fc70f299283   2009-11-02 17:01 -0400   root
|    Criado branch para implementar NovaFeature UltraMegaBoga
|
@  0   b65bb6ffc97c   2009-11-02 14:55 -0400   root
Adicionado arquivo de README com informações sobre o projeto

:~/src/projetonovo $  hg ci -m "Incorporando branch NovaFeature_UltraMegaBoga a arvore principal de desenvolvimento"
:~/src/projetonovo $  hg glog
@    5[tip]:0,4   b270c2750162   2009-11-02 17:24 -0400   root
|\     Incorporando branch NovaFeature_UltraMegaBoga a arvore principal de desenvolvimento
| |
| o  4   63ddafc85f03   2009-11-02 17:21 -0400   root
| |    Implementado TesteUnitario e tudo funcionando como esperado
| |
| o  3   f337dc212ea0   2009-11-02 17:19 -0400   root
| |    Nova funcionalidade UltraMegaBoga implementada
| |
| o  2   c192d84f042a   2009-11-02 17:16 -0400   root
| |    Criado arquivo da funcionalidade UltraMegaBoa
| |
| o  1   7fc70f299283   2009-11-02 17:01 -0400   root
|/     Criado branch para implementar NovaFeature UltraMegaBoga
|
o  0   b65bb6ffc97c   2009-11-02 14:55 -0400   root
Adicionado arquivo de README com informações sobre o projeto

hg merge <nome_do_branch> e então a união é feita, mas você pode ver pela saída do hg glog da linha 7 que o @ aparece tanto na revisão 0 quanto na 4, porque faltou criar o nó que significa a união dos projetos e que será ponto de partida para novas alterações, e eles nos avisa ao fazer o merge não esqueça de fazer o commit. E então fizemos o commit informando que estamos incorporando a nova funcionalidade. e então você pode ver o resultado do glog novamente, gerou-se a revisão 5 e novo hash. Agora percebesse que o glog é realmente muito útil né ? :-)

Agora para finalizar o ciclo, precisamos fechar a branch que criamos para desenvolver a feature, essa é uma funcionalidade que veio no mercurial 1.2, pois antes disso o mercurial não permite deletar branch, imagine a quantidade de branches que perduravam a vida toda no repositório ?!.

Encerrando as atividades da branch UltraMegaBoga.

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
:~/src/projetonovo $  hg update NovaFeature_UltraMegaBoga
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
:~/src/projetonovo $  hg ci -m "Fechando branch, feature implementada e incorporada a arvore principal" --close-branch
created new head
:~/src/projetonovo $  hg branches
default                        5:b270c2750162
:~/src/projetonovo $  hg glog
@  6[tip]:4   7992ab50038d   2009-11-02 17:26 -0400   root
|    Fechando branch, feature implementada e incorporada a arvore principal
|
| o  5:0,4   b270c2750162   2009-11-02 17:24 -0400   root
|/|    Incorporando branch NovaFeature_UltraMegaBoga a arvore principal de desenvolvimento
| |
o |  4   63ddafc85f03   2009-11-02 17:21 -0400   root
| |    Implementado TesteUnitario e tudo funcionando como esperado
| |
o |  3   f337dc212ea0   2009-11-02 17:19 -0400   root
| |    Nova funcionalidade UltraMegaBoga implementada
| |
o |  2   c192d84f042a   2009-11-02 17:16 -0400   root
| |    Criado arquivo da funcionalidade UltraMegaBoa
| |
o |  1   7fc70f299283   2009-11-02 17:01 -0400   root
|/     Criado branch para implementar NovaFeature UltraMegaBoga
|
o  0   b65bb6ffc97c   2009-11-02 14:55 -0400   root
Adicionado arquivo de README com informações sobre o projeto

Basicamente na saída acima, voltamos para a branch da funcionalidade UltraMegaBoga e fazemos um commit de encerramento, com o parâmetro –close-branch. Com isso damos fim ao Ciclo Implementativo.

Ciclo corretivo

No ciclo corretivo, existem 2 aspectos:

  1. Você encontrou o problemas durante o desenvolvimento, antes de lançar uma versão.
  2. Você encontrou ou encontraram pra você depois de ter lançado a versão.

Para primeira ocasião você pode usar o mesmo mecanismo do ciclo implementativo para fazer as correções. Agora na segunda ocasião eu sugiro uma abordagem diferente, o ideal é corrigir o problema e gerar patches para serem incorporados uma vez que o software já foi congelado(lançado a versão) e está apenas sofrendo correções esporádicas e não mais vivendo em um intenso processo de produção, para isso eu uso a extensão do mercurial chamada MercurialQueues, que é um conjunto de comandos para gerenciamentos de uma fila de patchs no estilo LIFO(Last-In / First-Out), o ciclo corretivo se divide em:

  1. Identificar a causa do problema
  2. Consertar o bug
  3. Gerar patch e exportar

Alguns devem ser perguntar o porque de eu sugerir MercurialQueues, pelo motivo de que os commits são maleáveis, no padrão os commits do mercurial são imutáveis, já com o MQ posso trabalhar em varios patches ao mesmo tempo somente manipulando a fila ao invés de ter que ficar importando e/ou exportando patches, posso também mesclar patches sem que isso interfira nos commits. IMHO, é mais conveniente. Você pode também usar o patch para aplicar a correção na versão que está em desenvolvimento

Comandos básicos

hg qinit

hg qnew

hg qrefresh

hg qpop

hg qpush

hg qfinish

hg qimport

Abaixo um exemplo de como criar uma fila e desenvolver um patch usando mercurial queues.

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
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
:~/src/projetonovo $  hg qinit -c
:~/src/projetonovo $  hg qseries
:~/src/projetonovo $  hg qapplied
:~/src/projetonovo $  hg qnew fix_bug_01.patch
:~/src/projetonovo $  echo "print('fixing bug')" >> mat.py
:~/src/projetonovo $  hg qseries
fix_bug_01.patch
:~/src/projetonovo $  hg qapplied
fix_bug_01.patch
:~/src/projetonovo $  hg glog
@  9[fix_bug_01.patch,qtip,tip,qbase]   b3f8a3b6f155   2009-11-02 22:55 -0400   root
|    [mq]: fix_bug_01.patch
|
o  8[qparent]   709a2b46c4cd   2009-11-02 17:29 -0400   root
|    Implementada feature nova e fechando branche
|
o  7   cd5986a79612   2009-11-02 17:28 -0400   root
|    criando branche para feature nova
|
o  6:4   7992ab50038d   2009-11-02 17:26 -0400   root
|    Fechando branch, feature implementada e incorporada a arvore principal
|
| o  5:0,4   b270c2750162   2009-11-02 17:24 -0400   root
|/|    Incorporando branch NovaFeature_UltraMegaBoga a arvore principal de desenvolvimento
| |
o |  4   63ddafc85f03   2009-11-02 17:21 -0400   root
| |    Implementado TesteUnitario e tudo funcionando como esperado
| |
o |  3   f337dc212ea0   2009-11-02 17:19 -0400   root
| |    Nova funcionalidade UltraMegaBoga implementada
| |
o |  2   c192d84f042a   2009-11-02 17:16 -0400   root
| |    Criado arquivo da funcionalidade UltraMegaBoa
| |
o |  1   7fc70f299283   2009-11-02 17:01 -0400   root
|/     Criado branch para implementar NovaFeature UltraMegaBoga
|
o  0   b65bb6ffc97c   2009-11-02 14:55 -0400   root
Adicionado arquivo de README com informações sobre o projeto
:~/src/projetonovo $  hg qrefresh
:~/src/projetonovo $  echo "a = 1" >> teste.py
:~/src/projetonovo $  hg diff
diff -r 2ae8338b6a9c teste.py
--- a/teste.py    Mon Nov 02 23:04:04 2009 -0400
+++ b/teste.py    Mon Nov 02 23:07:04 2009 -0400
@@ -1,3 +1,4 @@
print('Hellowww mercurial')
import this
print('Testando funcionalidade ultramegaboga...')
+a = 1
:~/src/projetonovo $  hg qdiff
diff -r 709a2b46c4cd mat.py
--- a/mat.py    Mon Nov 02 17:29:50 2009 -0400
+++ b/mat.py    Mon Nov 02 23:07:07 2009 -0400
@@ -1,1 +1,2 @@
print(2+2)
+print('fixing bug')
diff -r 709a2b46c4cd teste.py
--- a/teste.py    Mon Nov 02 17:29:50 2009 -0400
+++ b/teste.py    Mon Nov 02 23:07:07 2009 -0400
@@ -1,3 +1,4 @@
print('Hellowww mercurial')
import this
print('Testando funcionalidade ultramegaboga...')
+a = 1

:~/src/projetonovo $  hg qapplied
fix_bug_01.patch
:~/src/projetonovo $  hg qpop
:~/src/projetonovo $  hg qseries
fix_bug_01.patch
:~/src/projetonovo $  hg qapplied

:~/src/projetonovo $  hg qcommit
:~/src/projetonovo $  hg tip
8[tip]   709a2b46c4cd   2009-11-02 17:29 -0400   root
Implementada feature nova e fechando branche

:~/src/projetonovo $  hg glog
@  8[tip]   709a2b46c4cd   2009-11-02 17:29 -0400   root
|    Implementada feature nova e fechando branche
|
o  7   cd5986a79612   2009-11-02 17:28 -0400   root
|    criando branche para feature nova
|
o  6:4   7992ab50038d   2009-11-02 17:26 -0400   root
|    Fechando branch, feature implementada e incorporada a arvore principal
|
| o  5:0,4   b270c2750162   2009-11-02 17:24 -0400   root
|/|    Incorporando branch NovaFeature_UltraMegaBoga a arvore principal de desenvolvimento
| |
o |  4   63ddafc85f03   2009-11-02 17:21 -0400   root
| |    Implementado TesteUnitario e tudo funcionando como esperado
| |
o |  3   f337dc212ea0   2009-11-02 17:19 -0400   root
| |    Nova funcionalidade UltraMegaBoga implementada
| |
o |  2   c192d84f042a   2009-11-02 17:16 -0400   root
| |    Criado arquivo da funcionalidade UltraMegaBoa
| |
o |  1   7fc70f299283   2009-11-02 17:01 -0400   root
|/     Criado branch para implementar NovaFeature UltraMegaBoga
|
o  0   b65bb6ffc97c   2009-11-02 14:55 -0400   root
Adicionado arquivo de README com informações sobre o projeto

Linhas 1 ~ 10: É iniciada uma fila através do comando hg qinit -c , -c significa que a fila será versionada e portanto poderá ser usado o comando hg qcommit. Depois verificamos se está tudo zerado usando os comandos hg qseries e hg qapplied , o qseries nos permite verificar quais patchs estão na fila e o qapplied quais patchs estão aplicados efetivamente no repositório. Para criar um novo patch basta executar o hg qnew <nome_do_patch> que no exemplo acima atribui o nome fix_bug_01.patch. Alteramos o arquivo e podemos ver com o glog que ao criar o patch, já é aplicado automaticamente no repositório e por padrão coloca como msg do commit [mq]:  nome_do_patch.

Linhas 40 ~ 51: É incluídas as alterações feitas no patch atual através do comando hg qrefresh. É feita uma alteração no arquivo teste.py  e pra ver a diferença entre hg diff e hg qdiff é executado hg diff que é a última alteração que o repostório reconhece, quando executamos o hg qrefresh ele pega as alterações e armazena internamente no patch e as alterações não ficam mais no repositório comum e sim no patch que está sendo desenvolvido com mercurial queue. O hg qdiff mostra todas as alterações incluídas(através do qrefresh) no patch.

Linhas 67 ~ 75: É verificado que o patch continua aplicado (através do qapplied) e já que o patch está completo está na hora de armazena-lo e retirá-lo da lista de aplicados através do comando hg qpop que remove do topo da fila o patch e como o único e no topo é o fix_bug_01.patch não retorna nada o comando hg qapplied e então o patch é commitado através do hg qcommit essa fila de patchs é um outro repositório interno do mercurial, se você quiser confirmar é só entrar no .hg/patches do se repositório e rodar o comando hg glog para constatar o sub-repositório de patches criado pelo MercurialQueue.

Para exportar o patch pode usar o comando hg export <nome_do_patch> e para importar para o repositório normal use hg import ou se quiser importar para uma outra lista de patches hg qimport e então o patch será adicionado ao hg qseries.

Enfim as possibilidades são enormes com o MercurialQueue, e isso foi só uma demonstração básica do uso de MercurialQueues.

Ufa! Espero que alguém tenha paciência pra ler. Essa tá longe de ser a versão final desse post. Publiquei logo para ter um norte. Portanto agradeceria bastante as sugestões de melhoria, críticas, correções e etc.

Próximos posts(Aguardem) :P :

  • Trabalhando com o Mercurial – Mais sobre MercurialQueues
  • Trabalhando com o Mercurial – Rebaseando
  • Trabalhando com o Mercurial – Resolvendo Conflitos
:-)
,

Download da palestra de GIT – Debian Day Amazonas

Aug 25th

Posted by Daniel Elias in Computação

No comments

No DebianDay 09 Ministrei a palestra Git: Economize Dorflex!

Por vários fatores eu já esperava que a minha palestra fosse atrair poucos interessados, mas gostei muito dos participantes que estavam lá, pois como eram poucos foi possível fazer uma espécie de bate-papo e troca de experiências sobre o conteúdo.

Também não posso deixar de agradecer ao André Felipe Dias por permitir o uso das imagens do seu artigo Conceitos Básicos De Controle de Versão de Código: Centralizado e Distribuído.

Como prometido, segue aqui o link para download da palestra.

Críticas construtivas são sempre bem vindas, comente!

, , ,
cartaz

Debian Day 09 – Amazonas

Aug 18th

Posted by Daniel Elias in Computação

1 comment

Debian Day é um evento realizado anualmente por vários grupos de Software Livre em todo o mundo. Também conhecido por Dia Debian e Dia D, este evento comemora o aniversário da distribuição GNU/Linux Debian, que neste ano (2009) completa 16 anos de existência.

Em Manaus, o Debian Day é realizado pelo Grupo de Usuários Debian do Amazonas, conhecido por Debian-AM, sendo patrocinado pela UniLaSalle e com o apoio do Projeto Zagaia, AIT Technologies e Gráfica Silva.

Neste ano, teremos um I Desafio DebianDay de Programação:

cartaz

E também um convidado especial, o criador e mantenedor do site Viva o Linux (http://vivaolinux.com.br), Fábio Berbert de Paula.

Convidamos todos a participarem deste evento.
Data: 22 de Agosto de 2009.
Local: UniLaSalle, Dom Pedro I, em frente à praça de alimentação do Dom Pedro I.
Horário: 9h – 17:30h, credenciamento de 8h – 9h.
Entrada: 2Kg de alimentos não perecíveis, exceto sal.

Para saber como participar do desafio de programação, visite o site de evento.

Site: http://diadebian.org/am/2009

, , ,
flisol-manaus-logo

Flisol – Manaus – Amazonas

Apr 27th

Posted by Daniel Elias in Computação

3 comments

flisol-manaus-logoO flisol em manaus foi um sucesso na minha opnião, graças ao comprometimento dos “pigs” da comunidade de software livre em manaus, pessoas como Antônio Junior, Davyd Smelk, Marcelo Mendes entre outros e a estes pigs deixo aqui postado meus parabéns. houve uma quantidade razoável de participantes, todas as palestras estavam cheias e as oficinas foram também bastante frequentadas.

Tirei algumas fotos do evento apartir do meu E71, a câmera não é boa mas como estava de dia até que as fotos ficaram boas. Segue abaixo algumas fotos.

Oficina de D-Bus

A foto acima é da oficina de D-Bus.

25/04/2009

Coordenação do Flisol indo almoçar.

Mais fotos no meu flickr.

Também não pude deixar de contribuir e fiz uma palestra sobre Python com EFL e ajudei em algumas oficinas. Como prometi na minha palestra que iria postar a minha apresentação no blog, cá estou eu postando.

Slides Python e EFl

Segue abaixo os códigos que fiz de exemplo, mas faltou tempo para comentar linha a linha. Para quem quiser estudar segue código.

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
#!/usr/bin/env python2.5
# -*- coding: utf-8 -*-
# Copyleft
#
# @author: Daniel Martins

import ecore
from ecore.evas import SoftwareX11
import evas
import edje

X_DIRECTION, Y_DIRECTION = range(2)


w, h = 800, 480
ee = ecore.evas.SoftwareX11(w=w, h=h)
canvas = ee.evas

states = 0
anime = False
anime_max = 0


bg = canvas.Rectangle(color=(255, 255, 255, 255), size=ee.size)
bg.show()


def change_object(o, e):
    global w, h, states, anime_max
    im_w, im_h = o.image_size
    if states == 0:
        o.pos_set(w-im_w, 0)
    elif states == 1:
        (x, y) = o.pos_get()
        o.pos_set(x, h-im_h)
    elif states == 2:
        (x, y) = o.pos_get()
        o.pos_set(0, y)
    elif states == 3:
        (x, y) = o.pos_get()
        o.pos_set(0, 0)
        states = 0
        return
    states += 1
   


ball_object = canvas.Image(file="Generic_football.png", geometry=(0, 0, 66, 65))
im_w, im_h = ball_object.image_size
ball_object.fill_set(0,0, im_w, im_h)
ball_object.on_mouse_up_add(change_object)
ball_object.show()


# Load and setup UI
ee.title = "Exemplo de Python EFL"


ee.show()
ecore.main_loop_begin()

Exemplo animado:

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
80
81
82
83
84
85
86
87
88
89
90
#!/usr/bin/env python2.5
# -*- coding: utf-8 -*-
# Copyleft
#
# @author: Daniel Martins


import ecore
from ecore.evas import SoftwareX11
import evas
import edje

X_DIRECTION, X_DIRECTION_NEGATIVE, Y_DIRECTION, Y_DIRECTION_NEGATIVE = range(4)


w, h = 800, 480
ee = ecore.evas.SoftwareX11(w=w, h=h)
canvas = ee.evas

states = 0
anime = False
anime_max = 0


bg = canvas.Rectangle(color=(255, 255, 255, 255), size=ee.size)
bg.show()

def anime_ball(img_obj, direction):
    global anime_max
    (x,y) = img_obj.pos_get()    
    if direction == X_DIRECTION:
        img_obj.pos_set(x+5,y)
        img_obj.pass_events_set(True)
        if x > anime_max:
            img_obj.pass_events_set(False)
            return False
    if direction == X_DIRECTION_NEGATIVE:
        img_obj.pos_set(x-5,y)
        img_obj.pass_events_set(True)
        if x < anime_max:
            img_obj.pass_events_set(False)
            return False
    elif direction == Y_DIRECTION:
        img_obj.pos_set(x,y+5)
        img_obj.pass_events_set(True)
        if y > anime_max:
            img_obj.pass_events_set(False)
            return False
    elif direction == Y_DIRECTION_NEGATIVE:
        img_obj.pos_set(x,y-5)
        img_obj.pass_events_set(True)
        if y < anime_max:
            img_obj.pass_events_set(False)
            return False
    return True
     


def change_object(o, e):
    global w, h, states, anime_max
    im_w, im_h = o.image_size
    if states == 0:
        anime_max = w-im_w
        ecore.animator_add(anime_ball, o, X_DIRECTION)
    elif states == 1:
        anime_max = h-im_h
        ecore.animator_add(anime_ball, o, Y_DIRECTION)
    elif states == 2:
        anime_max = 0
        ecore.animator_add(anime_ball, o, X_DIRECTION_NEGATIVE)
    elif states == 3:
        anime_max = 0
        ecore.animator_add(anime_ball, o, Y_DIRECTION_NEGATIVE)
        states = 0
        return
    states += 1


ball_object = canvas.Image(file="Generic_football.png", geometry=(0, 0, 66, 65))
im_w, im_h = ball_object.image_size
ball_object.fill_set(0,0, im_w, im_h)
ball_object.on_mouse_up_add(change_object)
ball_object.show()


# Load and setup UI
ee.title = "Exemplo de Python EFL Animado"

ee.show()
ecore.main_loop_begin()

Link para baixar tudo, inclusive a imagem. Só não esqueça que para executar é preciso ter instalado as EFL e os python bindings.Para a instalação tenho um post sobre. Confira.

Espero que tenham gostado do evento tanto quanto eu gostei. Qualquer dúvida, crítica e/ou sugestão pode colocar nos comentários.

Até a próxima.

Lançamento do grupo Web2.0 Manaus com Harald Kirschner

Sep 15th

Posted by Daniel Elias in Computação

No comments

Na sexta (12/09/08) foi o lançamento do grupo Web2.0 Manaus com o apoio do INdT e contou com um desenvolvedor do core do mootools falando sobre web2.0 e mostrando casos de uso do mootools.

O Evento ocorreu no auditório da UniLasalle de manaus e contou com auditório cheio, eu inclusive que cheguei 15 minutos atrasado tive que sentar no chão :-) .

Bom, o evento foi composto por 2 palestras:

  • Palestra 1:
    • WEB 2.0 Oportunidades, e novas tendências. Álvaro Mota Gonçalves, INdT
    • Open-WEB. Harald Kirschner, WEB 2.0 developer and co-developer Mootools project
  • Palestra 2
    • WEB 2.0 v Overview de Tecnologias WEB 2.0. Harald Kirschner, front-end web developer specialist, core developer of MooTools project

O Álvaro Mota Gonçalves começou falando da estratégia da Nokia que mudou, e agora tem um foco mais aberto para o provimento de serviços web e levar a mesma experiência encontrada no uso de serviços web no pc com browser só que através do celular de forma móvel(mobile), o que é uma tendência hoje em dia de fato. Uma tecnologia que corresponde a este incentivo da Nokia para com a melhor experiencia de serviços web no celular é o WebRunTime(WRT). No quesito provimento de serviços a gente pode ver a investida da Nokia com o lançamento do Ovi.

Foi dito também que o mercado de trabalho estão a procura por profissionais de desenvolvimento web2.0, não lembro qual foi o site que o Álvaro mostrou onde ele fez uma pesquisa e retornou mais de 2000 empregos em aberto para se trabalhar com web2.0, ou seja, oportunidade.

A palestra mais esperada(pelo menos por mim), era a do Harald a qual pode ser encontrada aqui , achei que ele iria se aprofundar mais na explicação de web2.0 falando sobre microformats, WRT e outros conceitos e tecnologias que ainda não parei para estudar, mais o foco da palestra dele era falar de web2.0 para pessoas que não sabiam ou sabiam pouco o que é web2.0.

O Harald falou um pouco desse “compra-compra” que vemos hoje em dia de grandes empresas comprando as menores que oferecem algum serviço interessante, e ele até comentou “Quer ficar milhionário ? É só fazer um serviço inovador e publicar na web..” e logo depois complementou “só não é tão fácil fazer um..” :-) . Um fato que me chamou atenção foi a compra do GrandCentral pelo google, o qual eu nem fazia idéia que existia, trata-se de um serviço de gerenciamento de ligações, tem muitas funcionalidades interessantes, vale a pena dá uma olhada, é uma pena que o serviço ainda não está disponí­vel para o Brasil, mas vocé pode solicitar uma notificação quando o serviço estiver disponí­vel.

Além disso ele mostrou uma tabela de serviços comparativos, de 1.0 para 2.0

Como por exemplo:

1.0 2.0
DoubleClick

Google AdSense
Ofoto

Flickr
Mp3.com

last.fm
Britannica On line

Wikipedia
Personal Websites

Blogging

E outros como pode ser visto na apresentação dele.

Falou que os princípios da Web2.0 são:

Open Source – Liberação das informações
Communication – Usuários
Design – Nova arquitetura de interfaces com o usuário

Pra mim ficou meio misturado a afirmação de que o relacionamento do OpenSource com a web2.0 seja a liberação de informações no sentido de Content Syndication, Web Feed(RDF, Atom e etc), WebServices e APIs na minha opnião isso tem haver com OpenData e não com OpenSource, de fato há muita semelhança no modelo colaborativo de projetos OpenSource de código aberto para com serviços OpenData de compartilhamento de informações e não dúvido que a web2.0 com a semântica de OpenData tenha se baseado no modelo colaborativo do OpenSource. Eu acredito que um termo melhor seria OpenData.

Mostrou 1 exemplo de como ganhar dinheiro com a web2.0, usando o Amazon Web Service, o qual a cada livro vendido que você indicou em seu site/blog você ganha dinheiro.(O qual estarei botando em breve no meu blog :-P ).

Dando continuidade no quesito oportunidades, segundo Harald o que você precisa saber para arrumar um bom emprego no mercado de web2.0:

  • Content Syndication
  • Web feeds
  • RDF
  • Atom
  • Web services and APIs
  • Communication with XML or JSON
  • REST
  • SOAP(WSDL)

Algumas passagens me chamaram atenção como a do Tim O’Reilly sobre web2.0, resumindo significa que a inteligência coletiva é a base da web2.0, concordo em gênero e grau, você não ?

Houve também slides sobre Folksonomia[1], Comunicação, melhoramento de Design de interfaces com os novos conceitos RIA(Rich Internet Application) e RUE(Rich User Experience). Essa questão de trazer a experiência de uso de softwares desktop para web entre outras coisas.

Não deixou de falar dos padrões e a acessibilidade o que geralmente é ignorada em detrimento a funcionalidades “eye-candy” o que julgo muito importante e que nunca deve ser esquecida, ou seja, sua palestra também incluiu Web standards, W3C, leitores de tela, SEO e o funcionamento de softwares web, como estrutura(xhtml), apresentação(css) e etc.

Casos de uso do uso de JavaScript .

  • Melhorias na interação com os forms;
  • Melhorias na colaboração entre os usuários;
  • Filtros e manipulação de dados
  • Autocomplete (Como o google suggests)

Entrando mais na parte técnica, falou sobre o desenvolvimento, que com essa onda de informações e novos conceitos, por onde se basear , citou padrões utilizados e criados pelo yahoo, o YPatterns e das alternativas como o Ajax Pattern.

Não deixou de falar também para as pessoas com perfil empreendedor, falou sobre modelo de negócios:

  • Vender API
  • Vender serviços
  • Vender informações

Estratégias de expansão para quem já possui serviços:

  • Criar API
  • Distribuir como OpenSource (Citou também meios de o fazer, através do google code)

Vendeu um pouco de jabá falando sobre o MooTools e falou um pouco sobre o porque de frameworks.

Nessa hora tomei a liberdade de lhe fazer uma pergunta tendo em vista que o que ele mostrou de exemplo nada foram diferente dos exemplos encontrados utilizando JQuery , YUI e Ext-js os quais são os que eu uso nos meus projetos.

P: Perguntei quais eram as principais diferenças entre MooTools e Jquery/YUI ?
R: Ele disse que Mootools é melhor para projetos grandes. Disse também JQuery tem mais classes prontas e que o YUI tem uma estrutura menor do que a MooTools. Na opnião dele YUI é para projetos que precisem de namespaces.

O Evento foi de importância para região, quase não se ver eventos desse tipo por aqui em Manaus. Com certeza desenvolvedores web(como eu) sentem falta.

À coordenação, meus parabéns.

[1] Recomendo a leitura deste post sobre Folksonomia pelo Revolução Etc

Estudando python EFL – parte 1

Aug 23rd

Posted by Daniel Elias in Computação

8 comments

Bom, nos últimos tempos tenho estudado o Maemo, que utiliza o GTK como base dos widgets e de expansão da plataforma, mas vendo aplicações como canola que usa EFL, acredito que para uma aplicação mais interativa e eye-candy realmente vale a pena considerar o EFL como tecnologia para o desenvolvimento de aplicações para maemo, imaginei que a instalação do ambiente fosse algo mais trivial (e é depois que aprendi), com a ajuda do Gustavo Barbiery consegui finalizar a configuração do ambiente. E agora estou escrevendo um how-to para complementar o aprendizado.

A idéia é escrever um conjunto de posts para compartilhar os conhecimentos adquiridos, ajudando os mais novos (assim como eu) entrar no desenvolvimento de aplicações para maemo ou desktop utilizando esta tecnologia. Pretendo nos posts ter 2 seções uma com resumo e outra explicando com mais detalhes para os que não possuem muita experiência com linux possam entender e aprender.

Para constar, estou usando o Ubuntu 8.10.

Resumido:

  1. Instalar os pacotes build-essential libpng12-dev libjpeg62-dev python-setuptools librsvg2-dev python2.5-dev subversion autoconf automake autotools-dev m4 libtool cvs git-core libdbus-1-dev
  2. Fazer o checkout do código do trunk do svn do enlightenment dos seguintes pacotes: eina eet evas ecore embryo edje etk edje_editor.
  3. Compilar os códigos na seguinte ordem: eina eet evas ecore embryo edje etk edje_editor.
  4. Fazer checkout dos bindings do efl para python do SVN: cython python-efl-utils python-evas python-ecore python-edje python-etk.
  5. Instalar os pacotes na seguinte ordem: python-efl-utils python-evas.
  6. Após instalar o python-evas, você precisa instalar os headers para compilar o python-ecore, então: python setup.py install_headers
  7. Continuar a instalação dos pacotes dos bindings: python-ecore, python-edje e python-etk

Detalhado:

Instalar os pacotes essenciais para compilar os códigos, usando apt-get ou aptitude:

$ apt-get install build-essential libpng12-dev libjpeg62-dev python-setuptools librsvg2-dev python2.5-dev subversion autoconf automake autotools-dev m4 libtool cvs git-core libdbus-1-dev

Após instalar esses pacotes é preciso fazer o checkout do repositório do enlightenment, você pode criar uma pasta no seu home e entre no diretório:

$ mkdir $HOME/e_src

$ cd $HOME/e_src

entrar na pasta e fazer o checkout dos códigos eina eet evas ecore embryo edje etk edje_editor:

$ svn co https://svn.enlightenment.org/svn/e/trunk/eina eina

$ svn co https://svn.enlightenment.org/svn/e/trunk/eet eet

$ svn co https://svn.enlightenment.org/svn/e/trunk/evas evas

$ svn co https://svn.enlightenment.org/svn/e/trunk/ecore ecore

$ svn co https://svn.enlightenment.org/svn/e/trunk/embryo embryo

$ svn co https://svn.enlightenment.org/svn/e/trunk/edje edje

$ svn co https://svn.enlightenment.org/svn/e/trunk/etk etk

$ svn co https://svn.enlightenment.org/svn/e/trunk/edje_editor edje_editor

$ svn co https://svn.enlightenment.org/svn/e/trunk/e_dbus e_dbus

após ter feito o checkout do código, você precisar exportar os códigos para não mexer no código que veio pelo svn assim você pode aproveitar sempre as alterações do código, para atualizar sua cópia do svn basta:

$ svn up

crie uma pasta onde conterá o código exportado para compilação e entre na diretório:

$ mkdir $HOME/e_src_exported

$ cd $HOME/e_src_exported

exportando:

$ svn export $HOME/e_src/eina eina

$ svn export $HOME/e_src/eet eet

$ svn export $HOME/e_src/evas evas

$ svn export $HOME/e_src/ecore ecore

$ svn export $HOME/e_src/embryo embryo

$ svn export $HOME/e_src/edje edje

$ svn export $HOME/e_src/e_dbus e_dbus

após exportar, precisamos compilar, começaremos pelo eina e estes comandos devem ser repetidos para cada diretório:

$ cd eina

$ sh autogen.sh

$ make

$ sudo make install

$ sudo ldconfig

$ cd ..

depois o eet:

$ cd eet

$ sh autogen.sh

$ make

$ sudo make install

$ sudo ldconfig

$ cd ..

depois evas:

$ cd evas

$ sh autogen.sh

$ make

$ sudo make install

$ sudo ldconfig

$ cd ..

depois ecore:

$ cd ecore

$ sh autogen.sh

$ make

$ sudo make install

$ sudo ldconfig

$ cd ..

depois o embryo:

$ cd embryo

$ sh autogen.sh

$ make

$ sudo make install

$ sudo ldconfig

$ cd ..

depois e por último o edje:

$ cd edje

$ sh autogen.sh

$ make

$ sudo make install

$ sudo ldconfig

$ cd ..

depois o etk:

$ cd etk

$ sh autogen.sh

$ make

$ sudo make install

$ sudo ldconfig

$ cd ..

depois o edje_editor:

$ cd edje_editor

$ sh autogen.sh

$ make

$ sudo make install

$ cd ..

depois o e_dbus:

$ cd e_dbus

$ sh autogen.sh

$ make

$ sudo make install

$ cd ..

Antes de instalar os bindings é preciso instalar algumas dependências:

$ wget -c http://www.cython.org/Cython-0.10.3.tar.gz

$ git clone git://git.profusion.mobi/users/ulisses/python-dispatcher.git

E após, instale o Cython:

$ tar -zxvf Cython-0.10.3.tar.gz

$ cd Cython-0.10.3

$ sudo python setup.py install

$ cd ..

e o Python-Dispather:

$ cd python-dispatcher

$ sudo python setup.py install

$ cd ..

Após ter compilado e instalado os componentes essenciais do EFL, você precisa compilar e instalar os bindings para python, baixando os pacotes dentro do mesmo diretório pra onde exportou o código do svn:

$ svn co https://svn.enlightenment.org/svn/e/trunk/BINDINGS/python/python-evas

$ svn co https://svn.enlightenment.org/svn/e/trunk/BINDINGS/python/python-ecore

$ svn co https://svn.enlightenment.org/svn/e/trunk/BINDINGS/python/python-edje

$ svn co https://svn.enlightenment.org/svn/e/trunk/BINDINGS/python/python-etk

$ svn co https://svn.enlightenment.org/svn/e/trunk/BINDINGS/python/python-e_dbus

Exportando:

$ cd $HOME/e_src_exported

$ svn export $HOME/e_src/python-evas python-evas

$ svn export $HOME/e_src/python-ecore python-ecore

$ svn export $HOME/e_src/python-edje python-edje

$ svn export $HOME/e_src/python-etk python-etk

depois o python-evas:

$ cd python-evas

$ sudo python setup.py install

$ sudo python setup.py install_headers

$ cd ..

depois o python-ecore:

$ cd python-ecore

$ sudo python setup.py install

$ cd ..

depois o python-edje:

$ cd python-edje

$ sudo python setup.py install

$ cd ..

depois o python-etk:

$ cd python-etk

$ sudo python setup.py install

$ cd ..

depois o python-e_dbus:

$ cd python-e_dbus

$ sudo python setup.py install

$ cd ..

Pronto! você possui uma instalação funcional.

Para testar, você pode o exemplo que o Gustavo Barbiery fez, você precisa fazer o checkout:

$ mkdir $HOME/efl_demo

$ cd $HOME/efl_demo

$ svn co https://svn.enlightenment.org/svn/e/trunk/BINDINGS/python/python-edje/examples/evas-demo/01-app_launcher 01-app_launcher

$ cd 01-app_launcher

$ edje_cc 01-app_launcher.edc

$ python 01-app_launcher.py

Se tudo funcionar, pronto você realmente tem uma instalação funcional do python efl. :-)

Fontes:

http://wiki.enlightenment.org/

Basicamente, não tem muita referência de instalação do efl e esse é um dos motivos de eu estar escrevendo o post.

Qualquer coisa comenta ai! :-)

Update 24/01/09: Adicionado compilação do e_dbus e python-e_dbus.

Update 01/09/08: Considerando uma instalação inicial inclui mais alguns pacotes para instalar antes de iniciar a compilação: autoconf automake autotools-dev m4 libtool

Update 14/10/08: Houve mudanças nos repositórios do EFL, e agora é preciso compilar também o pacote EINA. Incluído Eina e correções na hora de instalar os bindings

Update 22/12/08: Esse modo de instalação que fiz funcionava bem com a versão antiga do efl, antes do eina. Atualizei para a versão do SVN e inclui a instalação de mais 2 pacotes do EFL, 1 binding e um utilitário(python-dispatcher) e a remoção do python-efl-utils. E tudo feito no ubuntu 8.10.

Qual SO você é ?

Aug 23rd

Posted by Daniel Elias in Computação

No comments


You are OS X. You tend to be fashionable and clever despite being a bit transparent. Now that you've reached some stability you're expecting greater popularity.

Which OS are You?

YUI + widget DataTable + Ordenação Customizada

Jul 3rd

Posted by Daniel Elias in Computação

3 comments

Eu tenho utilizado exaustivamente a biblioteca de componentes YUI (Yahoo User Interface) para re-redesenhar a interface dos sistemas web que desenvolvo no meu atual local de trabalho.

Acredito que há muitas opniões sobre esta nova abordagem de web2.0, desenvolvedores nacionais renomados ja se expressaram sobre esta questão, a web2.0 é boa para diversas situações, mas não tudo. Um exemplo é o Yahoo Mail Beta, é legal e bonito mas é lento demais, sem falar que no firefox qualquer ação o processamento vai para 100% e isso é caos!. É tudo uma questão de bom senso, usar web2.0 para dá um turbinada na aplicação com validações e chamadas assíncronas, melhorar a usabilidade ou ainda aplicar um comportamento para um determinado componente na tela é uma boa opção. Mas usar web2.0 para emular sistemas que rodam no desktop é complicado, por que são muitos eventos, muitos widgets, muitas regras de css(posicionamento, imagens e etc) e acaba que a aplicação fica extremamente lenta e de difícil manutenção, com certeza não é o que queremos.

More >

Recuperando arquivos deletados + Reiserfs

May 2nd

Posted by Daniel Elias in Computação

No comments

Ontem, minha esposa deletou por acidente seus 3.3GB de mp3…

Procurando no google achei o seguinte link: http://antrix.net/journal/techtalk/reiserfs_data_recovery_howto.html

Testei e funcionou, consegui recuperar os arquivos deletados, então decidir escrever uma dica rápida passo de como fazer a recuperação de seus arquivos tendo em vista que não achei nada ainda em português que podesse satisfazer minha dúvida.

More >

12»