Harbour 3.4 arquivado

por **asimoes** » 29 Abr 2018 19:39

Não considero o fim do harbour não, ainda tem projeto vivo hmg, minigui ex, hwgui, letdbf etc... e agente (rs), ainda não morremos por enquanto.

por **asimoes** » 29 Abr 2018 20:49

Outra coisa que eu achei interessante é que o harbour 3.2 também ficou congelado, coincidência ?

por **marcosgambeta** » 30 Abr 2018 06:34

asimoes escreveu:Outra coisa que eu achei interessante é que o harbour 3.2 também ficou congelado, coincidência ?

Acho que é reflexo da estabilidade do Harbour. Ele atingiu seu objetivo: um Clipper Open Source e Multiplataforma. Se não surgirem bugs no core, dá para ir usando sem problemas por muito tempo ainda.

E nem tudo ocorre no próprio projeto. Tem os projetos que circulam em torno do Harbour, mas não fazem parte do projeto propriamente dito. Podem até passar desapercebidos.

por **asimoes** » 30 Abr 2018 06:44

Eu também concordo que dá pra ir usando, apenas uma observação, se o Viktor deixou o projeto, o ideal seria fazer um Merge da 3.2 e 3.4
Dessa fusão sair a versão 4, posso tá viajando, rs

por **marcosgambeta** » 30 Abr 2018 07:07

asimoes escreveu:Eu também concordo que dá pra ir usando, apenas uma observação, se o Viktor deixou o projeto, o ideal seria fazer um Merge da 3.2 e 3.4

Antes do Viktor criar seu fork, me recordo de ele ter apresentado as ideias dele na lista de desenvolvedores do Harbour, mas muitos desenvolvedores não mostraram gostar das ideias. Depois, surgiu o Harbour 3.4 onde o Viktor tinha toda a liberdade para implementar suas ideias. Agora temos esta situação, onde o fork dele se encontra arquivado.

Seria preciso analisar os commits do fork e ver o que seria aproveitável no Harbour oficial e o que poderia ser descartado. Tem muita coisa relacionada com organização do código-fonte, formatação, etc... que na prática não faria muita diferença. Exemplo: um código bonito é melhor que um código feio, mas se ambos funcionarem corretamente, qual usuário do projeto ligaria para isso ?

Pessoalmente, eu começaria por correção de bugs. Se o Viktor corrigiu bugs na versão 3.4, mas eles não foram corrigidos na versão 3.2, então seria algo para se levar para a lista de desenvolvedores do Harbour. Naturalmente, dando preferência para bugs no core.

Infelizmente, são poucos os desenvolvedores aptos à mexerem no núcleo do Harbour. A maior parte dos usuários programa em xBase mesmo, com pouco ou nenhum conhecimento de C/C++.

por **JoséQuintas** » 30 Abr 2018 11:23

asimoes escreveu:Outra coisa que eu achei interessante é que o harbour 3.2 também ficou congelado, coincidência ?

Aonde viu isso?
A coisa mais difícil é ter alteração no Harbour 3.2, continua igual.
Raramente tem coisa nova, e muita novidade que tem é copiada do Harbour 3.4.

asimoes escreveu:Não considero o fim do harbour não, ainda tem projeto vivo hmg, minigui ex, hwgui, letdbf etc... e agente (rs), ainda não morremos por enquanto.

São outros que copiam do Harbour pra poder usar no XHarbour, e acabam afastando do Harbour original. Até compatibilidade com Xharbour obrigam a usar.

Seria preciso analisar os commits do fork e ver o que seria aproveitável no Harbour oficial e o que poderia ser descartado. Tem muita coisa relacionada com organização do código-fonte, formatação, etc... que na prática não faria muita diferença. Exemplo: um código bonito é melhor que um código feio, mas se ambos funcionarem corretamente, qual usuário do projeto ligaria para isso ?

Pois é... Com certeza XHarbour e LIBs vão preferir não mexer em nada.

Pessoalmente, eu começaria por correção de bugs. Se o Viktor corrigiu bugs na versão 3.4, mas eles não foram corrigidos na versão 3.2, então seria algo para se levar para a lista de desenvolvedores do Harbour. Naturalmente, dando preferência para bugs no core.

É exatamente esse o problema: copiar só o que interessa, fivewin, xharbour.com e LIBs fazem isso pra usar no XHarbour.
Pra que melhorar o Harbour 3.4, se copiam tudo pra usar no que derruba o Harbour 3.4

por **asimoes** » 30 Abr 2018 17:45

JoséQuintas escreveu:São outros que copiam do Harbour pra poder usar no XHarbour, e acabam afastando do Harbour original. Até compatibilidade com Xharbour obrigam a usar.

Eu não mencionei xHarbour, nem uso, faço questão de não usar.

JoséQuintas escreveu:Aonde viu isso?

Faço git pull todos os dias, sei que não tem nada mas mesmo assim faço, vai que ....

por **JoséQuintas** » 30 Abr 2018 19:46

asimoes escreveu:Faço git pull todos os dias, sei que não tem nada mas mesmo assim faço, vai que ..

No 3.2 é assim mesmo, devagar quase parando, só o estritamente necessário.

por **JoséQuintas** » 30 Abr 2018 23:19

No Harbour 3.2... a correção vai completar quase 1 mês que está por lá pra ser incluída...
Pra quem não sabe, seria olhar e confirmar, e nada mais.

No 3.4....
Continua congelado, mas teve uma pequena alteração há dois dias.

por **asimoes** » 01 Mai 2018 07:28

Uma diferença que eu notei porque precisei compilar o meu sistema com a versão 3.2, nada muito importante, mas tem essa diferença não me perguntem o porque:

harbour 3.2 -vcshead=compdatetime.ch

harbour 3.4 -bldhead=compdatetime.ch

É isso que eu estou falando sobre essas diferenças e outras que possam existir.

Usar a 3.2 e 3.4 é agora uma questão de gosto, pelo menos por enquanto as duas versões compilam com o mingw gcc 7.30 e funcionam no windows 10, se sair um build que mude o comportamento de alguma API do windows ai pode ter a famosa frase:

Houston, temos um problema?

por **marcosgambeta** » 01 Mai 2018 07:45

JoséQuintas escreveu:No Harbour 3.2... a correção vai completar quase 1 mês que está por lá pra ser incluída...
Pra quem não sabe, seria olhar e confirmar, e nada mais.

José,

É apenas um ponto de vista meu, mas acho que pode ocorrer isto: os desenvolvedores que tem acesso ficam esperando pelo 'pai da criatura' ou um desenvolvedor com mais experiência e conhecimento fazer a mudança.

Pode ser receio de mexer num código que não dominam bem ou que não foi criado por eles e acabarem introduzindo bugs ou fazer alguma coisa 'desandar'. A responsabilidade não é apenas fazer a mudança, mas também garantir que vai compilar corretamente nos 'n' compiladores, sistemas operacionais e arquiteturas. Enfim, é assumir uma responsabilidade perante os usuários do projeto.

Ou pode ser falta de tempo mesmo. Mas tempo se compra de outras atividades. Sacrifica-se um filme na TV e já se tem cerca de duas horas ou até mais para usar em outra(s) atividade(s).

Vamos ver quanto tempo esta situação vai perdurar. Quem precisa do Harbour, precisa e vai acabar achando um caminho para contornar a situação.

por **asimoes** » 01 Mai 2018 08:36

Só para informar, a modificação recente que o Viktor fez, não é do código harbour e sim de google analytics que ele removeu só isso.

: 2018-05-01 08_38_59-O que é Google Analytics.png (10.04 KiB) Visualizado 4177 vezes

por **JoséQuintas** » 01 Mai 2018 09:36

marcosgambeta escreveu:os desenvolvedores que tem acesso ficam esperando pelo 'pai da criatura' ou um desenvolvedor com mais experiência e conhecimento fazer a mudança.

É uma rotina EM PRG, pra extrair a COR da string: W/R,N/W,,,W/R
E também esqueceram das cores 1/0, 0/1, usando números.

Não é uma rotina que exige conhecimento a fundo, é apenas a forma de separar a string das cores.

Exatamente esse tipo de coisa que comento sobre LIBs.
Centralizar no Harbour pra ter manutenção, ao invés de deixar isolado em LIBs.
O mesmo vale pra funções de API.

por **MSDN** » 03 Mai 2018 16:03

O Harbour estabilizou...
O Harbour tem seus "donos" que gostam do jeito que tudo está...
O Harbour está perdendo os poucos "sonhadores" que queriam fazer algo a mais...
Com certeza, se parar onde está, ainda vai muito tempo de uso do Harbour, o problema é que para aplicações futuras, ficamos a deriva...e até hoje mesmo, basta olhar algumas postagens de programadores aqui do fórum, perguntando como conectar e usar MongoDB, algo que deveria ser simples, mas...
Particularmente, depois de muito analisar, e levando em consideração algumas postagens do Itamar (não recordo onde agora), onde se falava sobre o que realmente importa em programação, eu vou investir meu tempo em Lazarus https://www.lazarus-ide.org/ para aplicações desktop (32/64 bits) Windows, Linux e Mac, e Flutter https://flutter.io/ para mobile.

por **JoséQuintas** » 03 Mai 2018 18:31

MSDN escreveu:basta olhar algumas postagens de programadores aqui do fórum, perguntando como conectar e usar MongoDB, algo que deveria ser simples, mas...

Está se referindo a isto?

https://github.com/tfonrouge/hbmongoc

Quem está online