PC Toledo

Boa noite

Estou vendo que alguns estão migrando para do xharbour para o harbour.
Não tenho acompanhado o harbour a muito tempo.

Alguem poderia por favor indicar quais os motivos/vantagens de utilizar o harbour e não o xharbour?

Não quero gerar nenhum conflito, apenas ficar por dentro das melhoras no harbour.

Desde já, obrigado.

Caro, o harbour foi criado e n houve evolucao entaum foi criado o xharbour q seria (e eh) a envolucao do harbour, acontece que recentemente um membro do xharbour saio do projeto e estah agora no harbour, por esse motivo o harbour estah caminhando agora. Mas n acredito q o xharbour estacione ou mesmo fique atras do harbour.

Eu n tenho muitos detalhes. Inclusive c eu estiver escrevendo besteira por gentileza me desculpem.
Marcos Roberto

Olá,

Eu fui um dos que migraram de xharbour pra harbour. Houveram alguns fatores pessoais, mas o técnico foi o motivo mais forte. No desenvolvimento da xhgtk (biliboteca gráfica eu usa GTK e [x]Harbour) encontramos alguns problemas ao usá-la com Harbour, isso não foi de todo ruim, pois decobrimos problemas de memória que só eram detectados no harbour e não no xharbour, segundo o Przemek, isto se devia a estrutura interna do harbour que é mais otimizada, aliás, foi um dos motivos da saída dele do xharbour, pois o Ron Pinkas achava que do jeito que estava tava legal e o Przemek não.

Um outro fator que também contribui, foi a entrada do Przemek no time da xhgtk, e que nos ajudou a resolver estes probleminhas e sempre dado dicas pra melhorar o codigo e até mesmo colocando a mão na massa.

Existe uma lista muito grande de novas features, contribs novas, etc. Ao meu ver, está bem estável (Não que o xharbour não seja, não é essa a comparação). Já tivemos dois RC e agora está indo pra versão final.

Um outro ponto que pega, é a estabilidade do MT do xharbour, infelizmente não funciona bem, eu tive que parar com o desenvolvimento da xmlrpc no lado servidor, pq não funcionava bem (falhava em muitas requisicoes e testes de stress), mas isso não tem no harbour. O que eles estão planejando é usar Process ao invés de threads, algo que já é usado a muito tempo com o Oracle e Postgres, eles usam Process. O Oracle, apenas na versão windows usa threads.

Aqui segue uma lista das novidades na RC1
http://harbour-project.svn.sourceforge. ... iew=markup

Aqui segue uma lista das novidades na RC2
http://harbour-project.svn.sourceforge. ... iew=markup

Aos amantes do xHarbour, por favor não me entendam mal. Apenas pra lembrar, nós ainda continuamos dando suporte ao xharbour na xhgtk.

[]'s
Rodrigo Moreno

Olá Rodrigo Moreno,

Você recebeu meio email ontem ?

Obrigado,

Rossine.

Olá,

Respondido.

[]'s
Rodrigo

Para nós, simples usuários, qual a diferença hoje do Harbour e do xHarbour ??

att.

Olá,

Tirando o fato do xharbour ter o MT há mais tempo e no harbour está sendo implementado, diria que muito pouca coisa para o usuário final. Existem questões internas, como a forma como Garbage Collector trabalha, mas no xharbour tem uma série de novas features, que não sei se todas já foram implementadas no harbour. Mas não tem muito o que se preocupar, o que vc faz em um vc faz no outro também.

O que eu percebo, que no harbour a coisa é mais organizada, nas questões de compilação, mesmo no SVN, dificilmente vc pega um Warning, os makes parecem ser bem melhor escritos, como ficou organizada a contrib, vc pode por exemplo, lsitar quais libs vc quer compilar, etc.

Um outro exemplo de como as coisas fluem melhor, eu acho, no harbour. Um tempo atrás, eu disse que estava com problemas pra rodar o xharbour com mingw e outras pessoas reportaram o mesmo, daí eu postei o problema no forum e a resposta que obtive foi "Aqui tá tudo ok", aí depois de um tempo, um dos caras mais conceituados la dentro, disse que estav ocorrendo o "tal" problema, daí sim foram corrigi-lo.

Bom, daí eu começo a converter minha aplicação pra harbour, e claro, tem diferenças de libs, funções que existem no xharbour e não no harbour. Enfim, como no harbour existe uma lib chamada xhb.lib, que é de compatibilidade com o xharbour, postei as diferenças, e em menos de 10 minutos TODAS as rotinas que postei já estavam no SVN...

[]'s
Rodrigo

Mostrar organização e boa vontade só traz confiança para o cliente.

Curiosidade: quem está no "comando" do Harbour, por assim dizer, ainda é o Antonio Liñares?

Olá Maligno,

Não, aliás O Antonio não tem feito nenhuma contribuição há vários anos.

Os cabeças são o Przemyslaw e o Szakáts Viktor. O Przemek era o cara que mantinha ordem no código do xharbour, mas por diferenças de filosofia entre ele e o Ron Pinkas, ele abandonou o xHarbour.

[]'s
Rodrigo

Rodrigo, voce tem usado o MINGW ? notou alguma difereça de performance com o BCC ? e stá usando o que harbour ou xharbour agora ?

Olá,

Não notei diferenças não, mas acredito que o gcc gere um código maior e talvez um pouco mais lento, mas imperceptível. Só que é mais fácil trabalhar com o MinGW se usado com o Msys. Mas em termos de velocidade, o melhor mesmo é usar o MSVC. Até o postgres pra windows abandonou o MinGW e agora é compilado com o MSVC. Este gera códigos menores, 50% menor que o MinGW.

Quanto ao xharbour/harbour, uso apenas o harbour, estou gostando.

[]'s
Rodrigo

1-st Harbour and xHarbour use different MT implementation and they should not be confused.

...

Xbase++ Steffen
In other words, Xbase++ is playing in the Multithreading ballpark since a decade.
Harbour is still finding its way into the MT ballpark while xHarbour is in that context at a dead-end.
I would bet that Xbase++ will play in the multicore ballpack while the Harbours are still with their MT stuff.

Przemek:

And it’s highly possible that it will happen. But Harbour is free project and if we decide that adding full item protection with the cost of speed is valuable feature then maybe we implement it.
It’s also possible that we add such functionality as alternative VM library. Just like now we have hbvm and hbvmmt we will have hbvmpmt (protected mt).


Xbase++ Steffen
In a more theoretical sense, it is important to understand that a programming language and its infrastructure shall not adapt any technical feature, requirement or hype. Because then the language and infrastucture are getting more and more complicated up to an point of lost control.

Also backward compatibility and therefore protection of existing investments becomes more and more a mess with Q&A costs going through the roof.

Przemek:

_FULLY_AGREE_. Things should be as simple as possible. Any hacks or workarounds for single features in longer terms create serious problems and blocks farther developing. For me it was the main of xHarbour problem when I was working on this project.

Tirando o fato do xharbour ter o MT há mais tempo e no harbour está sendo implementado,

Mas segundo um de seus criadores, não funciona.
Para saber mais, é só ler toda a conversa.

http://cch4clipper.blogspot.com/search/label/Przemek

Saudações,
Itamar M. Lins Jr.

Outra importante informação.
Toda a parte referente ao linux do xHarbour era Przemek que cuidava.
Não sei quem pode ou irá substituir ele no xHarbour ou se compensa, se for trabalho voluntário, porque essa "nova pessoa" não irá para o Harbour ?
Pela leitura do texto acima, trocando em miudos eu entendi que o xHabour tem ecesso de gambiarras.

Saudações,
Itamar M. Lins Jr.

Itamar

Itamar M. Lins Jr. escreveu: Pela leitura do texto acima, trocando em miudos eu entendi que o xHabour tem ecesso de gambiarras.

Pura verdade. O Przemek detesta workarouns. Nós tínhamos alguns workarounds na xhgtk e ele escreveu um conjunto completo de Api's Items substituindo os hb_parptr/hb_retptr, etc só pra evitar qualquer problema de alocação de memória nao liberada pela gtk e assim gerenciada pelo GC do harbour. No lugar, tínhamos uns workarounds pra cuidar disso caso um ponteiro nao fosse liberado pelos callbacks da Gtk.

[]'s
Rodrigo