gmt no gêBR

[Bianchi]

Ola Lista,

Gostaria de saber se alguem já tentou encapsular o GMT (Generic
mapping tools) na gêBR ?

Ontem vendo a palestra do portugal na usp e depois de conversar com
ele fui mexendo um pouco com a interface e estou começando a achar que
seria inviável ou mesmo impossível encapsular o gmt na geBR como ela
esta hoje, será que alguem já teve esse problema ?

um grande abraço,

bianchi

[Bráulio Barros de Oliveira]

Olá Bianchi,

Na última palestra que teve na USP, conversei com um rapaz que mexia com o GMT, e ele me mostrando os scripts de exemplos do gmt nos fez pensar que seria possível colocar-lo dentro da gêbr, com algumas adaptações, as quais eu não lembro.

Qual foi os problemas que você teve ou cogitou?

abs,
bráulio

2008/9/12 Bianchi <m.tc...@gmail.com>

[Marcelo Bianchi]

Olá Bráulio,

Vou tentar explicar o problema que encontrei ao tentar adaptar o gmt para a gêBR. O problema que a gêBR aparentemente define 1 arquivo de entrada, e um arquivo de saida para todo o fluxo, enquanto que no gmt podemos ter mais de um arquivo de entrada e normalmente um arquivo de saida, que é a figura ou mapa em questão !!

Além do mais, os programas do GMT embora de certa forma trabalhem um complementando o trabalho do outro a saida de um não é utilizada pelo outro, ou seja, cada comando do gmt roda de forma independente e cada um vai colocando a sua saida atras da saida do comando anterior no mesmo arquivo de saida ..... tentando explicar melhor ... pelo que vi a geBR funciona assim ....

ENTRADA > P1 | P2 | P3 | ... | Pn > SAIDA

enquanto que o gmt funciona ....

entrada1 > P1 > SAIDA
entrada2 > P2 >> SAIDA (note o >> como no sheel a saida do P2 e adicionada na saida)
P3 >> SAIDA
Pn >> SAIDA

Nos exemplos acima tentei ser +- fiel aos redirecionadores como utilizado no SHELL script.

Eu tentei implementar esse tipo de execução como mostrado acima na gêBR ontem e não fui feliz, voce acredita que possa haver um modo de fazer isso do modo como esta escrita a gêBR ??

abraços

bianchi

2008/9/12 Bráulio Barros de Oliveira <brau...@gmail.com>

--
Seismology Student, University of São Paulo/IAG
Find me @ http://www.foo4fun.net/

[roso...@gmail.com]

Pessoal,

Vou dar o meu palpite.

A minha impressão é que o jeito do GMT trabalhar não é um fluxo tal
qual
definimos na GêBR. O exemplo que o Marcelo mostra muito bem a
diferença. Porém eu resolvi fazer o seguinte teste:

$ suplane > lixo1 | suplane npl=2 > lixo2

Essa linha de comando (que tem um pipe fake) acabou gerando dois
arquivos,
lixo1 e lixo2. Depois os visualizaei com suximage e pareceu tudo
certo.
O pipe parece que serviu como o separador (;) ...

Então o que acho que acontece é que o pipe passa algo do tipo null
para o
comando seguinte e tudo funciona bem. Então o que proponho é
entendermos
com profundidade os redirecionadores ( >, <, >>, << e |)

Por causa desse experimento acima, eu acho que se fizermos
algo do tipo

$ P1 > saida1 | P2 > saida2 | .... | Pn > saidan
$ cat saida1 saida2 .... saidan > saida_final

deve dar certo e, se não me engano, os comandos acima são compatíveis
com a GêBR.

E o que vocês acham? Marcelo, vc pode testar a linha de comando
com os pipes fakes, para ver se o GMT funciona assim ?

Portugal

> 2008/9/12 Bráulio Barros de Oliveira <brauli...@gmail.com>

>
>
>
> > Olá Bianchi,
>
> > Na última palestra que teve na USP, conversei com um rapaz que mexia com o
> > GMT, e ele me mostrando os scripts de exemplos do gmt nos fez pensar que
> > seria possível colocar-lo dentro da gêbr, com algumas adaptações, as quais
> > eu não lembro.
>
> > Qual foi os problemas que você teve ou cogitou?
>
> > abs,
> > bráulio
>

> > 2008/9/12 Bianchi <m.tch...@gmail.com>

[Ricardo Biloti]

Em primeiro lugar, seja bem-vindo ao grupo Marcelo.

Sobre o esquema de fluxos do GMT tenho uma proposta, Na lista de
desenvolvedores há um documento com idéias que coletamos para o
futuro. Uma delas é:

"Seleção de arquivos de entrada/saída
Não fica claro para alguns usuários que o input/output/error do fluxo
seja definido na aba de fluxos e não na edição do fluxo em si. Minha
sugestão é que na aba de edição de fluxos, na treeview que exibe os
componentes de um fluxo, sempre haja dois "meta-componentes", o input
e o output/error. Eles ficariam fixos no topo e no pé da treeview. E
um double click em qualquer um deste dois "meta-componentes" evocaria
uma widget para preenche-los. Caso o fluxo em edição não aceite input,
o meta-componente input poderia ser exibidido em cinza-claro e ter o
double-click desligado, e da mesma forma para o output. Além disso, no
log de um job, umas das informações que poderia aparecer em destaque
no início do job são os arquivos de input/output/error. Hoje para
verificar com que input um job foi executado, apenas procurando na
linha de comando."

Esta sugestão não visava resolver o problema que o Marcelo apresentou,
mas acho que pode ser adaptada para isto. Segue então a sugestão:

Entrada (E) e saída (S), assim como a saída de erro (L), poderiam ser
meta-componentes, sempre fixos no início e fim de um fluxo, porém
(aqui está a novidade) poderiam também ser inseridos, a critério do
usuário, no meio de fluxos. Desta forma um fluxo padrão da GêBR seria
algo como

E > P1 2>L | P2 2>>L | P3 2>>L | ... | Pn > S 2>> L

e um fluxo do GMT poderia ser implementado como

E > P1 >S 2>L ; E > P2 >>S 2>>L; E > P3 >>S 2>>L; E > P4 >>S 2>>L

Para isso o meta-componente S (saída) tería apenas como opção o nome
do arquivo e se o arquvio deve ser sobre-escrito ou acrescido.
Com isto atacaria resolveríamos outro problema apontado anteriormente,
que era a execução de dois fluxos consecutivamente.

Fluxo 1: E > P1 | ... | Pn > S
Fluxo 2: E > Q1 | ... | Qm > S

Fluxos consecutivos: E1 > P1 | ... | Pn > S1; E2 > Q1 | ... | Qm > S2

Isto implica uma mudança séria nas víceras da GêBR mas pode ser feita
(que acha Bráulio).

Abs,
Biloti

> 2008/9/12 Bráulio Barros de Oliveira <brauli...@gmail.com>

>
>
>
> > Olá Bianchi,
>
> > Na última palestra que teve na USP, conversei com um rapaz que mexia com o
> > GMT, e ele me mostrando os scripts de exemplos do gmt nos fez pensar que
> > seria possível colocar-lo dentro da gêbr, com algumas adaptações, as quais
> > eu não lembro.
>
> > Qual foi os problemas que você teve ou cogitou?
>
> > abs,
> > bráulio
>

> > 2008/9/12 Bianchi <m.tch...@gmail.com>

[Marcelo Bianchi]

Portugal

Essa sua solução realmente foi criativa. Só de curiosidade eu tentei e realmente funciona para os comandos mais simples, mas acontece que essa solução não iria acomodar os comandos do gmt que podem ser "alimentados" com arquivos na entrada padrao (|). Acho que iria causar um pouco de pânico. Embora criativa a solução não é prática, alem de ter o potencial de confundir o usuário e ensinar "maus" habitos para os usuários unix.

bom, só por graça eu tentei ...

psbasemap -R0/100/0/100 -JX10 -B50/15 -K > saida1.ps | psbasemap -R -JX -O -G200 > saida2.ps
cat saida1.ps saida2.ps > saida.ps
gv saida.ps

e se alguem tentar vai ver que funciona, embora seja uma solução lusitana. Esse comando psbasemap do gmt nao le nenhum arquivo de entrada, ele só plota o mapa base.

abraços

bianchi

2008/9/13 <roso...@gmail.com>

[Marcelo Bianchi]

2008/9/13 Ricardo Biloti <bil...@gmail.com>

Em primeiro lugar, seja bem-vindo ao grupo Marcelo.

Obrigado Biloti !! (... continua em baixo)
 

Olhem só, estive penssando nesses dois dias desde que começei a mexer com o gmt na geBR em uma solução não exatamente como essa, mas parecida. La vou eu tentar me explicar novamente.

A idéia acho que seria a seguinte:

1. Na aba de fluxos (flow) como propriedade de cada fluxo poderiam ser definidos inumeros arquivos que estariam relacionados ao fluxo em si + um arquivo especial que seria onde os erros deveriam ir (stderr 2> e 2|), como opção poderia ser definido que o erro deve ser redirecionado para o stdout, ou seja 2>&1 (em bash language).

2. Na edição de fluxo é que aconteceria realmente  a associação, o usuário realizaria o "binding" do arquivo com o menu, ou célula ;) ou lego (a decidir), dizendo se aquele arquivo para aquela celula seria entrada ou acumularia a saída.

Além dessas associações padrão teria um flag para linkar a saida desta célula com o próxima célula (|), dessa forma acho que seria resolvida de uma forma elegante e garantindo versatilidade suficiente para no futuro não seja necessário re-escrever essa parte do gêBR já que eu acredito que isso va ser uma mudança realmente grande e imagino que vai necessitar muitas e muitas horas de programação.

2'. Uma segunda opção seria definir logo na aba do fluxo que tipo de fluxo que estariamos trabalhando, se é um fluxo linkado (|) ou um fluxo com acoes independentes para cada comando. Eu acho que essa solução pode ser viavel mas prefiro a que eu dei antes, da decição ser tomada na edição de fluxo.

Bom, são sugestões para irmos maturando, e acho que agora seria o momento de pensar nisso pois realmente acredito que envolve uma mudança meio que grande na filosofia da geBR mas que pode garantir o seu sucesso ! Penssemos ....

abraços

bianchi
 

[Bráulio Barros de Oliveira]

Oi Marcelo,

Depois de uma provinha enjoada de física, volto ao assunto.

O assunto desse seu email, pelo que entendi, basea-se na independização das partes do fluxo. Isso de fato já é feito na gebr, simplesmente considerando a opção 'read from standard input'. Se o próximo programa não precisa de entrada, então não usamos o pipe e sim o separador ';'.
Agora, tem o problema que o programa anterior pode querer escrever na saída padrão, e aí o fluxo se quebra, o que atualmente não é permitido na GeBR e necessário para o GMT.

Sobre o item 1) acho que ele pode ser confuso, pois ficaria na interface separado os arquivos de entrada de seus respectivos programas. Por isso, acho que a solução do biloti é inevitável.

Mas realmente acho que pode fazer o usuário a fazer gambiarras. Como isso seria usado para construir fluxos avançados ou específicos para gmt, a gebr esconderia esse comportamento e explicitaria somente a entrada do primeiro programa (caso esse a necessite) e a saída do ultimo programa (caso esse a necessite). Nos nossos popups colocariamos então opções para entrada e saída de cada programa. Por padrão, se o próximo programa necessita de entrada e o atual "cospe" saída, usariamos o pipe, mas se o usuário seleciona a saída do atual ou a entrada do próximo, usuaríamos o ';'. É claro que teríamos que tratar alguns casos de erros, mas nada complexo (eu acho).

Já entrando nos termos técnicos, simplesmente transferiamos o elemento 'io' do fluxo para o programa. Assim cada programa especifica seu arquivo de entrada, saída e saída de erro. Uma implicação disso é que os elementos 'input', 'output' e 'error' poderiam receber ao invés do elemento 'program' as flags 'stdin', 'stdout' e 'stderr', que indicam se o programa permite cada uma dessas entradas e saídas.
A conversão dos fluxos antigos para esse novo padrão também não é complicada. Poderia ser nosso fluxo 0.3.1 (ou até mesmo 0.3). O mais trabalhoso seria fazer as mudanças correspondentes na interface.

Deu pra entender?

Abraço a todos,
bráulio

2008/9/13 Marcelo Bianchi <m.tc...@gmail.com>