LogicParser 0.4

Mais um release do LogicParser, agora a aba “Graph (Image)” é atualizada com imagem representando a árvore parseada da expressão lógica.

LogicParser 0.4

Duas funções muito boas da GLib me ajudaram:

  • g_file_set_contents: escreve todo conteúdo de uma string para um arquivo. Simples e rápida.
  • g_spawn_sync: dispara um processo de forma síncrona, para chamar o dot, do GraphViz.

Juntanto com outras facilidades da GLib, programar em C fica fácil demais. 😛

Outra coisa muito útil era o Google Code Search, a referência da GLib é muito boa, mas às vezes você quer ver o código sendo usado, e o code search ajudou bastante. Por exemplo, a especificação do g_spawn_sync tem muitos parâmetros, assustadores numa primeira olhada. “Como devo setar esses parâmetros?” Como todo mundo! No código do eog que achei nessa busca: lang:c g_spawn_sync

Sobre o futuro, o código precisa de mais “polish” e certamente preciso aprender CMake ou Autotools pra fazer um build system de respeito e não meu seboso Makefile. Por ser um projeto pequeno, pode valer à pena aprender Autotools.

Lembrando:

Update: OMG! Agora o Google Hosting disponibiliza uma wiki! Vejam a minha: http://code.google.com/p/logicparser/wiki/LogicParser

Anúncios

LogicParser 0.3

Neste release o LogicParser ganha uma interface gráfica:

LogicParser, tree view
A primeira aba é a árvore parseada da expressão inserida, a segunda um grafo na linguagem DOT e a terceira aba será a imagem do grafo gerada pelo GraphViz.

Ah, e os grafos agora são coloridos:

p1->(f | (!p3)), agora em Technicolor

LogicParser 0.2

Segundo release do LogicParser. Está sendo bem divertido voltar a programar em C, ainda mais com a GLib facilitando as coisas. No começo é estranho usar g_print no lugar de printf, e outras coisas, mas quando penso que boa parte da portabilidade estará garantida quando for compilar esse treco em Win32… 🙂

Neste release adicionei um componente para gerar grafos no no formato da linguagem DOT, processados pela ferramenta homônima do pacote GraphViz.

Aqui está uma expressão na sintaxe compreendida pelo LogicParser:

p1->(f | (!p3))

O grafo gerado:

digraph ParsedTree {
if_then_0 [label=if_then];
if_then_0 -> P1_1;
if_then_0 -> or_2;
P1_1 [label=P1];
or_2 [label=or];
or_2 -> False_3;
or_2 -> not_4;
False_3 [label=False];
not_4 [label=not];
not_4 -> P3_5;
P3_5 [label=P3];
}

A linha de invocação do dot, e a figura gerada:
dot -Tpng grafo.dot -o grafo.png

p1->(f | (!p3))

Além disso tudo está documentado na sintaxe do Doxygen.

Update: ah! O comando mágico para criar um tag no subversion:
svn copy https://logicparser.googlecode.com/svn/trunk \
https://logicparser.googlecode.com/svn/tags/release-0.2 \
-m "Release 0.2 of the 'LogicParser' project."

LogicParser

Fiz o primeiro commit do LogicParser, um programinha que ‘parseia’ expressões lógicas do tipo “!(p1 -> ( p2 & p3))“, que comecei a fazer logo após quase ter desistido da cadeira de Lógica. No período seguinte o professor começou a pedir um projeto do tipo pra galera, embora eu nunca tenha mostrado pra ele. Originalmente tinha uma interface GTK+, mas resolvi fazer um refactor e também aprender coisas básicas sobre projetos de software livre, como, por exemplo, aqueles arquivos README, ChangeLog, etc.
Já fiz o primeiro release, contando com o parser e um exemplo que roda na linha de comando.
Os planos para o futuro são:

  • interface GTK+
  • build com o CMake
  • saída da árvore como PNG e SVG, com o GraphViz
  • internacionalização
  • atribuição de valores e avaliação de expressões (possivelmente 2.0)

Ainda estou definindo uma política de numeração de versões, por hora estabeleci objetivos que quero alcançar e atribuí uma versão para cada um. Fico em dúvida se mudanças menos visíveis ao usuário final, como passar a usar CMake, deveriam entrar como 0.x ou 0.x.y, ou seja, considerar como uma alteração menor.
Dois documentos me ajudaram:

Projeto LogicParser no Google Hosting: http://code.google.com/p/logicparser

Update: mudei de idéia sobre o CMake. Autotools ruleia.

Tracker

A nova versão do Tracker passa a usar o SQLite, deixando de lado a versão embutida do MySQL.

Ah, sim, a apresentação! Segundo o site oficial:

Tracker é uma base de dados de objetos de primeira classe, base de dados extensível de tags/metadados, ferramenta de busca e indexação.

E com um daemon escrito em C que ocupa apenas 4Mb de memória. Muito bom saber que existe uma opção melhor que o Beagle para Desktop Search. Nada contra Mono/C#, acho muito legal e tudo mais, mas não é muito popular como candidato a componente de busca universal para ir no Freedesktop.org.

Alguns screenshots mostrando a performance do bicho, e o post com as novidades do Tracker.