Harbour 3.4 arquivado

[asimoes]

Itamar,

Vai tomar uma cerveja hoje é domingo! (rs)

[MSDN]

Itamar, lendo tudo o que vc escreveu, realmente, não tem como discordar, eu mesmo já havia lido em outras épocas (anos atrás), várias brigas e discussões sobre quem sabe mais, o que é "bom", o que não serve, e por ai vai, principalmente relacionado a um desenvolvedor brasileiro que trabalhava para xHarbour.com.
Agora uma coisa que estou pensando (enquanto gero o Harbour 3.4 para recompilar a MiniGUI), é pq Harbour, com o potencial que tem, virou um desconhecido, pois se for fazer uma analogia com Java, Python, JavaScript por exemplo, Harbour tem muita coisa em comum, porém, esses que citei foram apoiados por grandes empresas e seguiram melhorando e tendo entrada no mercado de desenvolvimento, e olha que até um tempo atrás muita coisa era na unha, via código para desenvolver, não tinha IDE boa, as vezes nem tinha IDE. Então, não seria o caso de discutir com quem realmente desenvolve o Harbour, sobre a possibilidade de conseguir vender a ideia para uma empresa de tecnologia, que tenha alcance mundial ?
Como vc mesmo citou o FreePascal e sua IDE Lazarus, no começo era tudo exatamente igual ao Harbour, mas se organizaram e evoluíram, agora saiu a versão 1.8 com diversas melhorias inclusive, e no caso do Lazarus, eles "brigam" contra uma empresa grande, a Embarcadero, que tem o Delphi, e mesmo assim vai adiante, imagina o Harbour que não tem um Delphi para concorrer.

[MSDN]

Aproveitando o assunto, a TOTVS, uma das maiores empresas do mundo em desenvolvimento de software, sempre usou xBase em seus produtos, até que na morte do Clipper, ela desenvolveu o compilador ADVPL, e até onde sei continua até hoje com ele, então pode-se dizer que o xBase é muito bom, temos um caso bem concreto, mas ai vem a dúvida, pq até hoje TOTVS e Harbour não se cruzaram Eu mesmo fiz um curso da TOTVS, e quando falei em Harbour durante uma aula, nem o professor sabia se era de comer ou beber !!!
Alguém explica isso ?!

[MSDN]

Quando vejo o trabalho que é fazer certas coisas em xBase, não por ele não ter recursos, mas por não ter exemplos, vejo isso :
http://www.alberteije.com/livros/lazarus_nfce/
http://www.alberteije.com/livros/lazarus_paf/
http://www.alberteije.com/livros/lazarus_sped/
http://www.alberteije.com/livros/lazarus_ios/
http://t2ti.com/erp2/
A única coisa que vem a cabeça é....houve muito esforço e união.
Não estou dizendo que não nos esforçamos, isso fazemos e muito, mas não conseguimos nos unir e nos organizar de tal forma a conseguir gerar algo nesse nível.

[JoséQuintas]

principalmente relacionado a um desenvolvedor brasileiro que trabalhava para xHarbour.com.

Acho que muitos já comentaram sobre isso. Tem muitas correções para o XHarbour, mas não atualiza nenhuma, deixa só pra uso particular.

[Itamar M. Lins Jr.]

Ola!
Para vc ver como são as coisas. O livro de implantação da NFCe com Lazarus, usa SOAP.
Pode ver que no Harbour a visão do pessoal está mais a frente usando RESTFUL que é considerado mais moderno, usando o HTTPd do Harbour, o Rafa Carmona "The Full" tem até uma aula dele sobre isso https://github.com/rafathefull/restful
Mas ai vem outro pega essa ideia, invés de ajudar ele, faz outra para vender com os códigos ou ideia dele.
O Viktor modificou lá no 3.4 o HTTPD com umas solicitações dele: https://medium.com/harbour-magazine/res ... 5e59335cf7

Código: Selecionar todos

2017-10-30 14:31 UTC Viktor Szakats (vszakats users.noreply.github.com)
  * contrib/hbhttpd/core.prg
    ! stop displaying certain, hardcoded, object variables in the
      error handler
      (based on Teo's fork)
    + allow to customize error handler
      Implements https://github.com/vszakats/harbour-core/issues/189

2017-10-30 14:11 UTC Viktor Szakats (vszakats users.noreply.github.com)
  * contrib/hbhttpd/core.prg
  * contrib/hbhttpd/tests/eshop.prg
    + add a "PostProcessRequest" server propert, which is a callback
      called after processing a request. It's only called when the
      request was actually handled.
      Previously a hardcoded 'dbCloseAll()' was called in this case.
      It was even called when the request was unhandled and state
      could not changed, also meaning it was called twice on each
      processed request, this update fixes this.
      If you rely on this functionality, server configuration should
      be udpated like eshop.prg was in this commit.
      [INCOMPATIBLE]
      (idea based on Teo's fork, but resolved differently)

2017-10-30 14:02 UTC Viktor Szakats (vszakats users.noreply.github.com)
  * contrib/hbhttpd/core.prg
    + add support for server-global hash of custom headers to add to
      responses: server[ "ADD_HEADERS" ]
      (based on Teo's fork, with cleanups - not compatible)
    + add server[ "BODY_RAW" ]
      (based on Teo's fork)
    * remove unnecessary 'MEMVAR->' prefix

2017-10-30 13:55 UTC Viktor Szakats (vszakats users.noreply.github.com)
  * contrib/hbhttpd/core.prg
    * genericize token delimiters ("{{"/"}}") internally

http://www.guj.com.br/t/qual-a-diferanc ... t/194608/3 Leia as respostas !

Código: Selecionar todos

Você pode ou não estar ciente de que há um debate acontecendo sobre o modo "certo" de implementar comunicação heterogênea de aplicação-para-aplicação: Embora o mainstream atual claramente incide sobre serviços web baseados em SOAP, WSDL e o universo das especificações WS-* , uma pequena, mas notável minoria reivindica que há uma forma melhor: REST, abreviação de "REpresentational State Transfer". Neste artigo, eu tentarei dar uma introdução pragmática ao REST e à integração de aplicações HTTP RESTful sem entrar neste debate. Eu entrarei em maiores detalhes quando for explicar sobre aqueles aspectos que, na minha experiência, causam mais discussão quando alguém é exposto a essa abordagem pela primeira vez.

Essas informações, esses debates não é fácil ver em ambientes/empresas que usam códigos privados, por isso fico sempre com o pé atrás quando o produto é privado. O fato é que método SOAP já é considerado obsoleto.
Por isso essas modificações no tal JSON do Harbour porque o REST usa ele. O pessoal nem acompanha isso, mas logo, logo vai precisar usar.

Código: Selecionar todos

2017-11-15 11:32 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
  * include/hbjson.h
  * src/rtl/hbjson.c
    * changed 3-rd parameter 'HB_BOOL fHuman' in hb_jsonEncode() and
      hb_jsonEncodeCP() C functions to 'int iIndent'
         char * hb_jsonEncode( PHB_ITEM pValue, HB_SIZE * pnLen,
                               int iIndent );
         char * hb_jsonEncodeCP( PHB_ITEM pValue, HB_SIZE * pnLen,
                                 int iIndent, PHB_CODEPAGE cdp );
      Positive iIndent value defines number of spaces used for indenting,
      0 disables indenting and  -1 means TAB ( ASCII:9 ) indenting.
      This modification is binary compatible though in C code using HB_TRUE
      as 3-rd parameter it changes indenting from 2 spaces to 1 so please
      update the code if it's significant.

    + added optional support for numeric value in 2-nd parameter of
      hb_jsonEncode() PRG function. Current syntax is:
         hb_jsonEncode( <xValue>, [ <lHuman> | <nIndent> ], [ <cDestCP> ] )
               -> <cJSONString>

O pessoal tem que se ligar mais, para não ficarmos dependendo de A ou de B. E fortalecermos o Harbour que é o mais importante.

Saudações,
Itamar M. Lins Jr.

[MSDN]

Concordo com vc Itamar, mas além de querer, precisamos fazer algo concreto para que isso aconteça.
Temos que formar um grupo e unir forças, com quem realmente quer participar no desenvolvimento, seja programando ou testando, eu toparia essa ideia, mas lembrando, tem que ser algo que inclua os programadores do Harbour e outros programadores COMPROMETIDOS, senão não vai.
Se depois de tudo isso, surgir um Harbour 4.0, talvez formas de monetizar esse esforço também apareçam, haja visto o exemplo do Lazarus.
Resumindo, não estou propondo uma utopia, mas algo plausível, claro que no começo tem que dar sem receber, mas depois pode-se pensar em algo !

[JoséQuintas]

O problema é que tudo no xbase resulta em mais um grupo isolado.

Usar HBMK2 que trás até melhoras pra XHarbour, até isso é difícil de padronizar, porque os usuários não se interessam.
E se bobear, nem as LIBs ajudam nisso, obrigam aos BATs de merd.

[MSDN]

Problema é o que mais tem, concordo.
O que falei, é o que enxergo, muitos de nós aqui no fórum, temos uma lista de reclamação, uma lista de sugestões, uma lista disso e daquilo, mas é cada um no seu quadrado, a questão é que cada 1 isolado, é bom em algo que o outro não é, se junta, todos ficam bom em tudo, e consegue-se uma base para evoluir, abre a cabeça e por ai vai, é nesse sentido !

OBS : a questão que vc falou de mais um grupo, isolar, etc, eu entendo seu posicionamento, mas, para conseguir uma evolução, não tem como fazer algo aberto, é impraticável, também não estou defendendo um grupo se unir, fazer um Harbour 4.0 fechado e cobrar uma fortuna por ele, mas sim ganhar de forma honesta com isso, curso, treinamento, literatura, classes, etc, como é nas outras linguagens.

[JoséQuintas]

É começar usando o que existe.
Eu acho que usar HBMK2 é uma das poucas coisas que podemos iniciar a padronização.

Mudar de XHarbour pra Harbour já vai complicar um pouco mais, e talvez mudar de compilador C também complique.
Neste ponto, já existirão LIBs que obrigam o uso de um determinado compilador.

Nem adianta ficar falando de Harbour 3.2, Harbour 3.4, que o ponto maior é o XHarbour, é o que mais sai do padrão, e é o que mais vai ficar preso a LIB.

Então é começar padronizando o que dá... pra começar a termos pontos comuns.

[JoséQuintas]

Esquecemos de mencionar:

Aqui tenho o git do Harbour 3.2 e 3.4

c:\github\harbour32
c:\github\harbour34

Há algumas formas diferentes de atualizar o Harbour 3.4:

1) Supondo que seja o original, baixado do link original

git pull

2) Supondo que seja um FORK, que não atualiza automático do original

git pull https://github.com/vszakats/harbour-core

3) Supondo que queira integrar futuras atualizações do Harbour 3.2 no seu 3.4

git pull https://github.com/harbour/core

4) Supondo que queira fazer isso localmente

git pull c:\github\harbour32

Na maior parte dos casos basta isso, mas eventualmente uma alteração pode exigir algo mais.


Nota:
O Harbour 3.4 está congelado.... ok....
Mas o 3.2 não tem alteração desde antes desse congelamento...
Então.... O fato de não ter mais atualizações, pelo menos por enquanto, não é motivo de alarme ou de parar de usá-lo.

[asimoes]

Concordo com o Quintas.

Pensa que o pior foi o clipper ter ficado do ms-dos, daqui a pouco o Viktor volta, deixar ele curtir as férias, nenhum sistema vai parar enquanto ele aprecia a polinésia francesa

[JoséQuintas]

Esta última atualização deu conflito, mas não verifiquei.
Conflito é quando o github não consegue atualizar sozinho, e precisa ajuste manual.
Na dúvida, desfiz o merge.

atualizando 3.2

d:\github>cd harbour32

d:\github\harbour32>git pull
remote: Counting objects: 19, done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 19 (delta 18), reused 19 (delta 18), pack-reused 0
Unpacking objects: 100% (19/19), done.
From https://github.com/harbour/core
f960a5ccda..2b4c4b3b5f master -> origin/master
Updating f960a5ccda..2b4c4b3b5f
Fast-forward
ChangeLog.txt | 49 ++
contrib/hbnf/fttext.c | 1327 ++++++++++++++++++++++++-------------------------
contrib/hbnf/hbnf.hbx | 2 +
include/harbour.hbx | 1 +
include/hbapi.h | 65 +--
src/harbour.def | 4 +
src/rtl/itemseri.c | 87 ++--
src/vm/arrays.c | 9 +
src/vm/codebloc.c | 9 +
src/vm/hashes.c | 9 +
src/vm/hvm.c | 21 +
11 files changed, 833 insertions(+), 750 deletions(-)

tentando puxar pro 3.4 localmente

d:\github\harbour32>cd..

d:\github>cd harbour34

d:\github\harbour34>git pull ..\harbour32
remote: Counting objects: 19, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 19 (delta 18), reused 0 (delta 0)
Unpacking objects: 100% (19/19), done.
From ..\harbour32
* branch HEAD -> FETCH_HEAD
Auto-merging src/vm/hvm.c
Auto-merging src/vm/arrays.c
Auto-merging src/harbour.def
Auto-merging include/hbapi.h
Auto-merging include/harbour.hbx
Auto-merging contrib/hbnf/fttext.c
CONFLICT (content): Merge conflict in contrib/hbnf/fttext.c
Auto-merging ChangeLog.txt
CONFLICT (content): Merge conflict in ChangeLog.txt
Automatic merge failed; fix conflicts and then commit the result.

e resetando

d:\github\harbour34>git reset --hard HEAD
HEAD is now at 42c5985be4 2017-11-27 13:02 UTC Viktor Szakats (vszakats users.noreply.github.com)

d:\github\harbour34>

O ajuste manual é olhar os arquivos com conflito, onde o github já coloca no próprio fonte o(s) bloco(s) que precisam revisão.
Resolvendo o conflito, só salvar o resultado.

[JoséQuintas]

Tipos de conflito: por exemplo observação alterada.

Mas em fonte C é complicado, porque pode desfazer algo que já foi feito.
E como todos sabem... fonte C eu não mexo.

Ainda resta a opção de adicionar as alterações que puderam entrar automaticamente, basta salvar esses fontes que deram certo.
Após salvar, resetar, mas vai ficar sem as alterações em fttext.c

Na próxima tentativa, esse novamente vai aparecer como conflito.

Pelo menos as demais alterações já vão entrar...

[JoséQuintas]

As que dão certo...
Por exemplo neste fonte foi adicionada uma nova rotina.

Nota:
na imagem, os arquivos de cima são os que precisam ajuste manual, e os de baixo os que puderam/podem ser atualizados automaticamente.