[Pr�via] [Pr�xima] [Pr�via por assunto] [Pr�xima por assunto]
[�ndice cronol�gico]
[�ndice de assunto]
[SOD] RE: Padroniza��o
- Subject: [SOD] RE: Padroniza��o
- From: "Paulo Silveira" <paulo@xxxxxxxxxxxx>
- Date: Mon, 14 Apr 2003 20:57:15 -0300
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
>
>