[Pr�via] [Pr�xima] [Pr�via por assunto] [Pr�xima por assunto]
[�ndice cronol�gico] [�ndice de assunto]

[SOD] RE: Padroniza��o



Oi Peter

acho que tem um problema pior ainda....

cada um de nos tempos um Repositorio associado ao NS
Um repositorio tem associado a ele todas as parts que lhe pertence.

Mas eu, por exemplo, dou um BIND nao soh no repositorio, mas tambem dou
nos Parts (para facilitar a pesquisa por code, dava para fazer o EP sem
BINDar as Parts).

Se todo mundo BINDar as Parts usando a string de codigo de cada part,
havera conflito (tentativa de rebind) quando a part de mesmo codigo for
BINDada por repositorios diferentes. Por isso estou BINDando minha part
em "nome_do_repositorio/part_code"...

Mas todas essas coisas a gente pode resolver facilmente se tivermos de
fazer a comunicacao.

------------------------
Paulo Silveira
http://www.paulo.com.br/
http://www.guj.com.br/
 

> -----Original Message-----
> From: Peter Kreslins Junior [mailto:pkj@linux.ime.usp.br] 
> Sent: segunda-feira, 14 de abril de 2003 13:42
> To: Lista SOD
> Subject: Padroniza��o
> 
> 
> Pessoal e Professor!
> 
> Conversando com colegas, descobri que n�o est� havendo uma 
> padroniza��o muito efetiva nas normas do projeto. Por 
> exemplo, antes do professor esclarecer, muitos n�o estavam 
> levando em conta a quantidade de pe�as na hora de fazer a 
> totaliza��o. No entanto, o que me deixou mais preocupado, foi 
> um problema detectado pelo F�bio Nishihara, quanto a uma 
> hierarquia de pe�as.
> 
> Observem:
> Raiz cont�m {Galho[2], Folha[5]}
> Galho cont�m {Folha[3]}
> 
> Quantas pe�as primitivas a raiz tem?
> A minha implementa��o considera 8 pe�as. No entanto, segundo 
> apontou nosso colega, deveriam ser 2x3+5=11. Pois temos 2 
> Galhos, cada um com 3 folhas.
> 
> Bem, assim podemos ver duas abordagens que causariam um 
> problema enorme no futuro. Digo isso, pois como o professor 
> mencionou, no final dever�amos fazer com que implementa��es 
> de diferentes grupos funcionassem em conjunto. Mas vejam o 
> problema que isso causaria. A tal distribui��o de 
> reposit�rios n�o permitiria que, a priori, consegu�ssemos 
> detectar quem est� errado!
> 
> Outro problema seria como implementar a opera��o subparts com 
> esse novo crit�rio. Na verdade ter�amos que colocar a �rvore 
> de subpartes num vetor, para que ficasse coerente com a 
> contagem. Mas isso n�o seria nada pr�tico pois in�meras 
> repeti��es apareceriam!
> 
> Bem, acho que para esta fase, pelo menos o meu grupo, n�o 
> ter� condi��es de adotar esse outro crit�rio.
> 
> 
> Abra�os,
> 
> Peter
> 
>