MCSTU

Sugestão de editor Markdown online: https://stackedit.io/

Seguindo a orientação do Luiz Flávio, pode-se baixar o arquivo https://svn.cptec.inpe.br/mcstu/documentos/padroes/Padrao_de_Codificacao_para_o_Modelo_Comunitario_do_Sistema_Terrestre_Unificado.md (link direto) e abril-lo para edição no editor onine StackEdit.

Flávio, Luiz escreveu:

O Padrão até agora pensado foi colocado no controle de versões aqui no Redmine. Para baixá-lo usem o subversion (checkout) em
https://svn.cptec.inpe.br/mcstu/documentos/padroes

Luiz Flávio, é possível criarmos aqui um branch remoto próprio já com as sugestões de alterações e incluindo novo conteúdo, certo?

Luiz Flávio e Roberto,

Uma sugestão: como o documento foi incluído no SVN para versionamento, eu sugiro criar os ramos branch, trunk e tag. A revisão atual pode ser movida para o trunk; quando qualquer um de nós iniciar uma revisão, esta deve ser feita em um branch. Podemos organizar da seguinte forma:

trunk/
-- doc.md
branch/
-- carlos.bastarz/
-- -- doc.md
-- luiz.flavio/
---- doc.md
-- roberto.souto/
---- doc.md
etc
tag/

Na tag, armazenaremos apenas a versão final e as revisões de cada um ficam nos nossos branches. À medida em que estas revisões individuais terminarem, um de nós fica incumbido de fazer o merge com o trunk e depois consolida a versão final na tag.

Olá, Carlos.

Eu concordo e acho boa a sua sugestão de organização do projeto nos ramos trunk, branch e tag.
Seria uma estrutura similar a esta abaixo, por exemplo?
/mcstu/trunk/documentos/padroes
/mcstu/branch/nome.sobrenome/documentos/padroes
/mcstu/tag/documentos/padroes

Obs.: Pode ser somente um detalhe, mas no projeto do BRAMS usa-se 'branches' e 'tags' para o nome dos ramos.
Caso virmos a organizar o projeto desta forma, talvez fosse o caso de seguir o mesmo padrão de nomes também aqui no MCSTU.

Olá Roberto,

Isso mesmo. Os nomes que utilizamos nos nossos projetos são também "branches" e "tags" e a organização dos branches da forma como você citou.

Prezados,

Realizei uma primeira revisão do documento https://projetos.cptec.inpe.br/projects/mcstu/repository/entry/branches/carlos.bastarz/documentos/padroes/Padrao_de_Codificacao_para_o_Modelo_Comunitario_do_Sistema_Terrestre_Unificado.md. Para isso, criei os ramos trunk, branches e tags. Realoquei o diretório 'documentos' para dentro do ramo trunk e no diretório branches, criei o diretório carlos.bastarz. Copiei o trunk/documentos para o branches/carlos.bastarz e realizei minha revisão no branch criado. Se todos estiverem de acordo, sugiro que este seja o procedimento a ser adotado, enquanto os documentos estiverem sendo versionados aqui.

Como estamos utilizando o SVN, para a referência dos colegas, vou deixar registrada a sequência de comandos utilizados para criar o meu branch:

svn mkdir https://svn.cptec.inpe.br/mcstu/branches/carlos.bastarz -m "Criando branch carlos.bastarz" 
svn cp https://svn.cptec.inpe.br/mcstu/trunk/documentos https://svn.cptec.inpe.br/mcstu/branches/carlos.bastarz -m "Copiando trunk/documentos para o branch carlos.bastarz" 

Depois disso, baixei o meu branch, fiz as modificações e depois o commit de volta para o meu branch:

cd branches/carlos.bastarz
alterações
svn ci 

Sobre o documento, tenho as seguintes dúvidas:

• No item 4.31, o simbolo "[]" (parece com um par de colchetes), é padrão no estilo de documentação do Ford? Vide linha 287
• No item 4.33, o símbolo "[]" está corrreto na atribuição da licença? Vide linha 310
• Ainda no item 4.33, o símbolo de copyright pode ser renderizado em qualquer editor, especialmente quando não está sendo utilizada a codificação UTF-8? Vide a linha 312
• Há uma proposta do uso de aspas simples ou duplas para as mensagens de print, write, stop, file, status etc?

Abs,

Carlos

Muito obrigado, Carlos.

Irei criar também o branch com meu nome para incluir minhas sugestões de edição no documento.
Luiz Flávio, o merge dos branches para o trunk pode ser feito por você e por mim, certo?
Para resolução de conflitos no merge, pode-se utilizar com o SVN uma ferramenta visual de comparação, tal como o Meld?

Abraço,

Roberto.

PS.: Por favor, como eu faço para receber por e-mail notificação de novas mensagens aqui do fórum?

Roberto,

Acho que o Meld é uma boa opção para isso. Podemos invocá-lo pela linha de comando também, o que é conveniente:

Sobre as notificações eu clico no botão "Observar" (no meu caso está marcado como "Parar de observar", pois já estou seguindo) dentro do fórum, onde os tópicos são criados:

Abs,

Carlos

Oi, Carlos.

Obrigado.

Eu já havia clicado no botão "Observar", mas mesmo assim não tenho recebido notificações de atividades aqui no fórum.
Mesmo que nas configurações em 'Minha conta', as notificações constem com habilitadas:

Abraço,

Roberto.

Olá Roberto,

Fiz uma solicitação para o nosso helpdesk verificar. Eu também não estou sendo notificado das mensagens no fórum, apenas quando novas tarefas são abertas dentro do Redmine.

Abs,

Carlos

Muito obrigado, Carlos

Bastarz, Carlos Frederico escreveu:

Luiz Flávio e Roberto,

Uma sugestão: como o documento foi incluído no SVN para versionamento, eu sugiro criar os ramos branch, trunk e tag. A revisão atual pode ser movida para o trunk; quando qualquer um de nós iniciar uma revisão, esta deve ser feita em um branch. Podemos organizar da seguinte forma:

[...]

Na tag, armazenaremos apenas a versão final e as revisões de cada um ficam nos nossos branches. À medida em que estas revisões individuais terminarem, um de nós fica incumbido de fazer o merge com o trunk e depois consolida a versão final na tag.

Excelente ideias. Vamos fazer assim!

Bastarz, Carlos Frederico escreveu:

Olá Roberto,

Isso mesmo. Os nomes que utilizamos nos nossos projetos são também "branches" e "tags" e a organização dos branches da forma como você citou.

Pessoal. Concordo com as sugestões.

Pinto Souto, Roberto escreveu:

Muito obrigado, Carlos.

Irei criar também o branch com meu nome para incluir minhas sugestões de edição no documento.
Luiz Flávio, o merge dos branches para o trunk pode ser feito por você e por mim, certo?
Para resolução de conflitos no merge, pode-se utilizar com o SVN uma ferramenta visual de comparação, tal como o Meld?

Abraço,

Roberto.

PS.: Por favor, como eu faço para receber por e-mail notificação de novas mensagens aqui do fórum?

Roberto. O Merge pode ser feito por nos dois sim. Mas está aberto a todos os developers.

Pinto Souto, Roberto escreveu:

Muito obrigado, Carlos

Carlos. Acho que vale uma conversa direta com o Luiz Coura. POde mandar email a ele?

Olá Luiz Flávio,

Vi que você já mandou email para o Luiz Coura, então vamos aguardar o retorno dele. Ainda não obtive retorno do helpdesk.

Abs.

Flávio, Luiz escreveu:

Pinto Souto, Roberto escreveu:

Muito obrigado, Carlos.

Irei criar também o branch com meu nome para incluir minhas sugestões de edição no documento.
Luiz Flávio, o merge dos branches para o trunk pode ser feito por você e por mim, certo?
Para resolução de conflitos no merge, pode-se utilizar com o SVN uma ferramenta visual de comparação, tal como o Meld?

Abraço,

Roberto.

PS.: Por favor, como eu faço para receber por e-mail notificação de novas mensagens aqui do fórum?

Roberto. O Merge pode ser feito por nos dois sim. Mas está aberto a todos os developers.

Prezados,

Como minhas correções no documento foram tipográficas e algumas poucas sugestões, fiz o merge do meu branch com o trunk da seguinte forma:

svn co https://svn.cptec.inpe.br/mcstu
cd trunk/documentos/padroes
svn merge --reintegrate ^/branches/carlos.bastarz/documentos/padroes
svn ci

Att.

Obrigado, Carlos.

Prezados,

Apenas para dar um retorno sobre a solicitação feita ao helpdesk para a verificação das notificações do fórum; fui informado de que já estão verificando e que devemos aguardar a solução do problema. O Luiz Coura também respondeu a solicitação do Luiz Flávio e acredito que em breve teremos uma atualização sobre esse problema.

Abs.

Prezados,

Como minhas correções no documento foram tipográficas e algumas poucas sugestões, fiz o merge do meu branch com o trunk da seguinte forma:

[...]

Att.

Olá a todos.

Acabei de sincronizar meu branch com o trunk:

cd branches/roberto.souto/documentos/padroes/
svn merge ^/trunk/documentos/padroes
svn commit -m "Merge of trunk changes to roberto.souto branch." 

Assim que eu inserir minhas sugestões no documento, posto no fórum para discussão e, se houver consenso entre nós, eu faço então o merge do meu branch para o trunk, da maneira que o Carlos mostrou.

Abs,

Roberto.

Prezados,

Confirmando o funcionamento das notificações por email a partir das mensagens do fórum do MCSTU no portal de projetos do CPTEC.

Abs.

Olá a todos.

Foi criada uma tarefa/issue pai denominada Padrão de Codificação, com o mesmo nome do respectivo fórum .
A sugestão aqui é de criar uma sub-tarefa para registrar a alteração efetuada no texto.

Por exemplo, foi criada a sub-tarefa Sugestão para alocação e desalocação de memória, vinculada a tarefa pai Padrão de Codificação.
Esta sub-tarefa refere-se também a trilha de mesmo nome no fórum Padrão de Codificação.

Por favor, o que acham?
Podemos fazer desta maneira?

Abraço,

Roberto.

Olá Roberto,

É uma boa ideia. Eu alterei o status da tarefa pai para "In Progress", visto que já estamos nas discussões. Você poderia, por favor, incluir o João Gerd como observador destas tarefas também? Acho que devido aos problemas de notificações do fórum ele acabou não vendo a troca de mensagens por aqui. Ele tem muitas boas ideias e as contribuições dele são importantes também.

Abs,

Carlos

Olá a todos,

Estava revisando o texto e surgiram algumas dúvidas e/ou sugestões. Preferi colocar aqui visto que são sobre itens distintos do texto. Caso entendam que devo criar um subtópico para a discusão de cada um, faço isso:

• Item 4.23: Este item torna mandatório que módulos não podem utilizar o USE de outros módulos externos à ele. Mas por exemplo se for criado um módulo modString.F90, que manipula strings, por exemplo, com funções do tipo upperCase e lowerCase, e temos um outro módulo em que é necessário utilizar alguma instrução do tipo upperCase e/ou lowerCase, como deve ser o procedimento? Isso realmente me deixou confuso. Eu entendo que o USE pode ser incluido no Driver, mas isso não faz com que mais código seja necessário? Não seria então um item Recomendado ao invés de Mandatório

• Item 4.32: Geralmente o uso maiúsculo da extensão invoca automaticamente o pré-processador, a não ser que se use uma opção desabilitando essa característica. Não seria mais conveniente deixar o uso de extensão em maiúscula com uma regra deste tipo? Compiladores como Gfortran e intel fortran usam esta característica de chamar o preprocessador por padrão quando o código fonte possui extenções do tipo .F, .F90, .FOR, .F03 ...

• Item 5.11: do meu ponto de vista este deveria ser madatório. o GOTO já é considerado obsoleto, e torna o código bastante confuso, por exemplo, com o goto pode-se pular para qualquer parte do código tornado o código "macarrônico"

• Item 5.13: Este é um ponto que acho que devemos discutir um pouco mais. Acredito que existam vantagens e desvantagens no uso de NetCDF. Seria bastante apropriado pensar no uso de grib2 também. A principal vantagem que vejo no formato NetCDF está relacionada à grande variedade de usuários do formato, o que leva há uma gama de ferramentas no mercado. É um formato bastante consolidado, com uma documentação consideravelmente boa.
  Já o formato Grib tem sua principal vantagem no armazenamento, especialmente o formato GRIB2, que é ainda mais compacto do que o GRIB2, e bem mais compacto do que o NetCDF. Além disso é o formato oficial da WMO. Também é uma formato consolidado e com ampla documentação. O aspecto "tamanho" é algo importante a ser considerado, visto que espaço em disco é sempre limitante e um problema recorrente no INPE, então vejo que é algo que devemos levar em consideração. Acredito que deveríamos discutir um pouco mais antes de inclui-lo como recomendado e penso que o GRIB2 também deveria ser recomendado, mas é importante pensar em somente um formato.
  Acredito que esse item 5.13 poderia ser aberto um forum para a discussão.

abraço
João Gerd

João.

Sobre o item 4.23: Existem duas opções para a gente pensar. Funções genéricas de uso comum podem ficar fora de módulos e serem linkadas ao fim da compilação. OU podemos permitir o uso de módulos apenas para procedures. Aberto para discutir.

Sobre o 4.32: isso mesmo. A ideia é que sempre o pre-processador seja invocado. A razão para isso é que, caso uma mudança futura no código peça pre-operadores como #IFDEF por exemplo não será preciso alterar toda a estrutura de nomes de arquivos e makefiles.

SObre o 5.11: COncordo com você nesse ponto. Entretanto pode ser um problema para código antigos. Em alguns procedures que já trabalhamos não foi possível "desenrolar" os "gotos/continues" que puseram no código. O que os demais acham? Mandatório?

Sobre o 5.13: grib e grib2 são muito ruins para usar dentro do código (na escrita). Os descritores não fazem parte do arquivo e há um movimento nos demais centros para abandonarem esses padrões. É uma questão de escolha. Se alguém souber de uma forma simples de escrever grib2 eu aceito. Para ser discutido!