PC Toledo

Prezados,

Estou com problema de "exaustão de memória" em um ERP que tenho rodando e que antes não apresentava problema algum. Vi algumas recomendações de uso do Blinker 7 e gostaria de estar colocando em parte tal solução. O problema é não tenho o referido linkeditor e nem sem aonde posso consegui-lo. Será que alguém pode me ajuda? Atualmente uso o Clipper 5.2b + Exospace.

Grato e aguardo qualquer ajuda.

qual versao ?

eu usei MUITO antiamente

posso procurar..

+ facil usar o xhb ou harbour rs


Paiva

Olá aprendiz_ce,

Quanto ao Blinker 7.0 não sei dizer, e não prometo passar porque não sei se já é domínio público.

Mas quanto ao Clipper, antes de mais nada você precisa atualizar para a versão 5.2e. Você pode baixar aqui: Clipper 5.2e.

Já disseram: seria mais interessante usar Harbour, mas não dá pra saber se vai ser rápido, só tentando.

Quanto ao blinker, convém lembrar detalhes dele.
Passar o que eu usava
blinker clipper symbol off
desativando o controle de símbolos do Clipper, aumenta um pouco o limite

blinker executable clipper F250
Isto embute a variável SET CLIPPER=F250 no EXE

blinker environment override
Se não me engano, isto permite que uma configuração na máquina altere a configuração embutida no EXE

blinker environment clipper jpa
Isto altera ao invés de SET CLIPPER, pra SET JPA, assim só você vai saber configurar diferente

blinker executable extended
Isto é importante. Sem isso fica pior do que com RTLINK ou EXOSPACE

blinker executable compress
Compactar o EXE

blinker incremental off
Linquedição incremental, ele é tão rápido, que melhor desativar pra não criar arquivos adicionais no disco

blinker procedure depth 120
blinker executable alignment 128
São equivalentes, pra aumentar a "pilha" de chamadas de módulos. Com SIXCDX isso acaba sendo obrigatório. Na dúvida sempre deixei os dois... rs

blinker extmem limit 8000
Isso limita uso de memória. Na época a gente pensava em economizar.... rs

blinker lowmem reserve 32
Já não lembro, talvez algo a ver com liberar memória abaixo de 32kb e causar problemas... rs

blinker message wink
Frescura, alguma coisa ver com o blinker piscar os olhos.... rs

file \cdrom\fontes\lib\apporign" // Maligno AppPath
O obj do Maligno pra pegar o nome do EXE

file \cdrom\fontes\lib\volsernr" // Maligno Vol.Serial
O obj do Maligno pra pegar o serial do HD

file \cdrom\fontes\lib\crc32clc" // Maligno CRC32
O obj do Maligno pra calcular CRC32 de um arquivo

lib \cdrom\fontes\lib\OsLib
A LIB pra liberar uso de CPU

search blxclp52
Este é importante, é de acordo com a versão do Clipper
Se usar FILE ao invés de SEARCH, vai poder executar DLL em Clipper, mas a estas alturas não acho que seja boa idéia. Basta search.

Os demais eram LIBs que eu usava.
Com o detalhe de SIX3 indicada por SEARCH.

Nota:
SEARCH é o mesmo que LIB, mas o que estiver indicado com SEARCH são as primeiras LIBs a serem pesquisadas na falta de alguma coisa.
E no caso de BLCLP52 e SIX3, elas obrigatoriamente são as primeiras, por isso o SEARCH

dbdc5554 escreveu:qual versao ?

eu usei MUITO antiamente

posso procurar..

+ facil usar o xhb ou harbour rs


Paiva

Eu gosto do Harbour e até uso. Agora, o xHarbour ainda não usei, mas quando tiver tempo verei isso.

O problema de usar o Blinker 7 é que seria algo mais IMEDIATO e resolveria o meu problema no momento. Mais que isso, terei que negociar valores com o usuário final e não é esse o meu interesse no momento.

O que exatamente o colega quis dizer como: "Qual versão?".

Jairo Maia escreveu:Olá aprendiz_ce,

Quanto ao Blinker 7.0 não sei dizer, e não prometo passar porque não sei se já é domínio público.

Mas quanto ao Clipper, antes de mais nada você precisa atualizar para a versão 5.2e. Você pode baixar aqui: Clipper 5.2e.

Beleza. Sem problemas.
Só o toque sobre o Clipper 5.2e, já ajuda.

Kapiaba escreveu: http://www.4shared.com/zip/oNV4luuuce/BLINKER7.html

Opa! Vou tentar baixar.

Grato.

JoséQuintas escreveu:Já disseram: seria mais interessante usar Harbour, mas não dá pra saber se vai ser rápido, só tentando.

Quanto ao blinker, convém lembrar detalhes dele.
Passar o que eu usava

Código: Selecionar todos

   IF Proj_Compiler == "C"
      ? "blinker clipper symbol off" // 20/06
      ? "blinker executable clipper F250"
      ? "blinker environment override"
      ? "blinker environment clipper jpa"
      ? "blinker executable extended"
      ? "blinker executable compress"
      ? "blinker incremental off"
      ? "blinker procedure depth 120"
      ? "blinker executable alignment 128"
      ? "blinker extmem limit 8000"
      ? "blinker lowmem reserve 32"
      ? "blinker message wink"
   ENDIF
      ? "file \cdrom\fontes\lib\apporign" // Maligno AppPath
      ? "file \cdrom\fontes\lib\volsernr" // Maligno Vol.Serial
      ? "file \cdrom\fontes\lib\crc32clc" // Maligno CRC32
      ? "lib \cdrom\fontes\lib\OsLib"
      ? "lib Super"
      IF Proj_Compiler == "C"
         // ? "file blxclp52" // no caso de rodar DLL
         ? "search blxclp52"
         ? "search six3"
         ? "file \cdrom\fontes\lib\sixuk"
         // ? "file \cdrom\fontes\lib\sixcdx" // usa somente sixcdx
      ENDIF

blinker clipper symbol off
desativando o controle de símbolos do Clipper, aumenta um pouco o limite

blinker executable clipper F250
Isto embute a variável SET CLIPPER=F250 no EXE

blinker environment override
Se não me engano, isto permite que uma configuração na máquina altere a configuração embutida no EXE

blinker environment clipper jpa
Isto altera ao invés de SET CLIPPER, pra SET JPA, assim só você vai saber configurar diferente

blinker executable extended
Isto é importante. Sem isso fica pior do que com RTLINK ou EXOSPACE

blinker executable compress
Compactar o EXE

blinker incremental off
Linquedição incremental, ele é tão rápido, que melhor desativar pra não criar arquivos adicionais no disco

blinker procedure depth 120
blinker executable alignment 128
São equivalentes, pra aumentar a "pilha" de chamadas de módulos. Com SIXCDX isso acaba sendo obrigatório. Na dúvida sempre deixei os dois... rs

blinker extmem limit 8000
Isso limita uso de memória. Na época a gente pensava em economizar.... rs

blinker lowmem reserve 32
Já não lembro, talvez algo a ver com liberar memória abaixo de 32kb e causar problemas... rs

blinker message wink
Frescura, alguma coisa ver com o blinker piscar os olhos.... rs

file \cdrom\fontes\lib\apporign" // Maligno AppPath
O obj do Maligno pra pegar o nome do EXE

file \cdrom\fontes\lib\volsernr" // Maligno Vol.Serial
O obj do Maligno pra pegar o serial do HD

file \cdrom\fontes\lib\crc32clc" // Maligno CRC32
O obj do Maligno pra calcular CRC32 de um arquivo

lib \cdrom\fontes\lib\OsLib
A LIB pra liberar uso de CPU

search blxclp52
Este é importante, é de acordo com a versão do Clipper
Se usar FILE ao invés de SEARCH, vai poder executar DLL em Clipper, mas a estas alturas não acho que seja boa idéia. Basta search.

Os demais eram LIBs que eu usava.
Com o detalhe de SIX3 indicada por SEARCH.

Nota:
SEARCH é o mesmo que LIB, mas o que estiver indicado com SEARCH são as primeiras LIBs a serem pesquisadas na falta de alguma coisa.
E no caso de BLCLP52 e SIX3, elas obrigatoriamente são as primeiras, por isso o SEARCH

Entendido. Estarei vendo todos esses detalhes.

Grato.

Prezados colegas,

Com o uso do Blinker 7, vou realmente acabar de veze com o meu problema?

Só quero ter certeza de não estar fazendo algo em vão.

Grato.

Olá aprendiz_ce,

Na minha humilde opinião vale tentar, mas creio que não. Penso que você vai resolver em definitivo quando resolver colocar a mão na massa e migrar para Harbour.

Outrossim, atualizando seu Clipper e usando o Blinker 7 vai ter uma melhora muito grande.

Depende de qual problema está enfrentando.
Ultrapassar os limites do Clipper+exospace não é fácil.

tem que ver se não está fazendo besteira na hora de compilar, por exemplo, usando arquivos CLP.
Ou gerando um OBJ de tamanho acima do limite, o que seria resolvido dividindo o fonte em duas partes.

Lembrei também, de um problema com máquinas muito rápidas....

Vamos ao principal: baseado em que diz que é "exaustão de memória" ?
Ou mais informações: qual o tamanho do EXE?

Nota:
Independente de qualquer coisa, com blinker é muuuito melhor.

Jairo Maia escreveu:Olá aprendiz_ce,

Na minha humilde opinião vale tentar, mas creio que não. Penso que você vai resolver em definitivo quando resolver colocar a mão na massa e migrar para Harbour.

Outrossim, atualizando seu Clipper e usando o Blinker 7 vai ter uma melhora muito grande.

Olá Jairo,

O meu problema (exausted memory) se dá devido ao volume de registros em algumas tabelas (DBF), pois sempre que a quantidade de registros passa de 700.000 a coisa acontece mais cedo ou mais tarde. O que posso fazer nesse caso? Atualmente apago os registros mais antigos, mas confesso que não gosto.

Migração:
Penso que mesmo migrando para o Harbour essa questão não se encerrará, pois a questão são as tabelas e não o aplicativo em sí. O que você me diz?

Eu quero migrar, e até já tenho uma versão do mesmo todo em Harbour, mas como o usuário final não quer pagar nada pelo trabalho, fico esperando o momento certo para disponibilizar essa nova versão compilada. E tem mais, para que a coisa fique 100%, eu tenho que ter uma versão para Linux também, e que já está pronta, só que todos os caracteres ASCII estão malucos e eu nunca consegui resolver isso. VocÊ tem como me orientar sobre isso?

Outra coisa:
Você saberia me dizer se depois dessa nova compilação (Clipper 5.2e + Blinker 7) o aplicativo rodará no DOSEMU (Emulador Linux)? Atualmente ele roda sem problema algum.

Muito obrigado pela sua atenção e aguardo pelos seus comentários.

JoséQuintas escreveu:Depende de qual problema está enfrentando.
Ultrapassar os limites do Clipper+exospace não é fácil.

tem que ver se não está fazendo besteira na hora de compilar, por exemplo, usando arquivos CLP.
Ou gerando um OBJ de tamanho acima do limite, o que seria resolvido dividindo o fonte em duas partes.

Lembrei também, de um problema com máquinas muito rápidas....

Vamos ao principal: baseado em que diz que é "exaustão de memória" ?
Ou mais informações: qual o tamanho do EXE?

Nota:
Independente de qualquer coisa, com blinker é muuuito melhor.

Olá Jose Quintas,

O meu problema mesmo é só o "EXAUSTED MEMORY", pois fora isso não tenho problema algum.

Sobre o tamanha do executável, O mesmo tem 1.524 KB compilado com /M /L, assim crio o OBJ para cada PRG do aplicativo e linko tudo no final. Uso assim a mais de 20 (anos) com Exospace e nunca tive problemas. Também uso bolsa de indices desce quando surgui e sempre me sai bem, as vezes acontece aqui e acolá um quebrazinha de indice, mas é raro.

E aí, mediante o exposto por mim, o que o colega poderia estar me recomendando fazer?

Muito obrigado pela sua atenção e aguardo seu comentário.

Olá Apendiz,

aprendiz_ce escreveu:Penso que mesmo migrando para o Harbour essa questão não se encerrará, pois a questão são as tabelas e não o aplicativo em sí. O que você me diz?

Há relatos nesse fórum de um colega e acabou sendo confirmado por outros que um sistema Clipper puro estava rodando em rede e sem problemas com mais de 1.200.000 (um milhão e duzentos mil) registros. A documentação do Clipper, fala que o limite de registros de um DBF em Clipper é de 1 milhão. Veja, mesmo em Clipper foi superado e sem problemas.

Quanto a Harbour, não existe limite. O limite tanto de memória quanto de capacidade do banco de dados é a máquina e Sistema Operacional. Ele está pronto para romper barreiras. Mão na massa...

Sobre as questões com Linux não tenho nenhum conhecimento para responder.

Muito estranho o erro, parece relacionado ao que comentei de pilha pra SIXCDX, STACKS pra ser mais exato.
Tamanho de arquivo, que eu saiba, não faz diferença pra memória.

Tive um problema que ocorria internal error, devido a usar campo MEMO, não sei se pode estar relacionado ao seu caso.

O Blinker 7 é bem mais moderno que o Exospace, está mais preparado pras máquinas atuais do que Exospace.
De qualquer jeito é vantagem trocar, mesmo que não resolva seu problema.

Então, eu trocaria.

Se o problema não for resolvido, então é partir pra Harbour.
É melhor brigar com algo que resolve de vez seu problema, do que brigar com algo que talvez só vá quebrar o galho.
O Blinker ainda é uma alternativa a se tentar, porque não vai precisar mexer em nada nos fontes.

Caso não use ainda, convém também usar por exemplo a OSLIB.
Numa explicação simples: Isso melhora o relacionamento entre o Clipper e o Windows, senão os dois ficam brigando pelo uso do computador, e sobrecarregam tudo.

Jairo Maia escreveu:Olá Apendiz,

aprendiz_ce escreveu:Penso que mesmo migrando para o Harbour essa questão não se encerrará, pois a questão são as tabelas e não o aplicativo em sí. O que você me diz?

Há relatos nesse fórum de um colega e acabou sendo confirmado por outros que um sistema Clipper puro estava rodando em rede e sem problemas com mais de 1.200.000 (um milhão e duzentos mil) registros. A documentação do Clipper, fala que o limite de registros de um DBF em Clipper é de 1 milhão. Veja, mesmo em Clipper foi superado e sem problemas.

Quanto a Harbour, não existe limite. O limite tanto de memória quanto de capacidade do banco de dados é a máquina e Sistema Operacional. Ele está pronto para romper barreiras. Mão na massa...

Sobre as questões com Linux não tenho nenhum conhecimento para responder.

Jairo,

Acredito sim, que existam tabelas com mais de um milhão de registros aonde o sistema não causa erros, pois o meu aplicativo também tem tabelas nessa condição... só que eventualmente/raramente isso ocorre (exausted memory), e quando ocorre é dose! Daí quero resolver isso de uma vez por todas.

Mediante a tudo que você expôs, penso que a solução seria mesmo partir para o Harbour, pois já que o mesmo rompe todas a barreiras... não vejo solução melhor! Como já mencionei, tenho o referido aplicativo todo convertido tanto para Win32/64 e Linux, mas como ainda não consegui resolver a questão do ASCII (dentro do Linux), vou ter que aguardar mais um pouco para colocar o mesmo em ambiente de produção.

Dúvida:
A comunidade Harbour está ativa, em pleno desenvolvimento? Se sim, isso será duradouro ou pode parar a qualquer momento? Pergunto devido ao fato deu não querer apostar em algo que amanhã pode parar de existir.

Só pra constar:
Esqueci de comentar que o erro de "Exausted Memory" só ocorre quando o sistema é indexado, se ocorre durante o uso, nenhum usuário me relatou.

JoséQuintas escreveu:Muito estranho o erro, parece relacionado ao que comentei de pilha pra SIXCDX, STACKS pra ser mais exato.
Tamanho de arquivo, que eu saiba, não faz diferença pra memória.

Tive um problema que ocorria internal error, devido a usar campo MEMO, não sei se pode estar relacionado ao seu caso.

O Blinker 7 é bem mais moderno que o Exospace, está mais preparado pras máquinas atuais do que Exospace.
De qualquer jeito é vantagem trocar, mesmo que não resolva seu problema.

Então, eu trocaria.

Se o problema não for resolvido, então é partir pra Harbour.
É melhor brigar com algo que resolve de vez seu problema, do que brigar com algo que talvez só vá quebrar o galho.
O Blinker ainda é uma alternativa a se tentar, porque não vai precisar mexer em nada nos fontes.

Caso não use ainda, convém também usar por exemplo a OSLIB.
Numa explicação simples: Isso melhora o relacionamento entre o Clipper e o Windows, senão os dois ficam brigando pelo uso do computador, e sobrecarregam tudo.

José Quintas,

Se o problema for SIXDCX, STACKS, como faço para verificar isso? Eu só me preocupava com STACKS na época no MS-DOS.

Quanto a campo MEMO, acho que não seja o caso, pois as tabelas que os possuem MEMOs tem poucos registros e as mesmas não dão erro.

Nunca utilizei esse OSLIB. O mesmo serve para o que exatamente?

Dúvida:
A comunidade Harbour está ativa, em pleno desenvolvimento? Se sim, isso será duradouro ou pode parar a qualquer momento? Pergunto devido ao fato deu não querer apostar em algo que amanhã pode parar de existir.

Pode ir na FÉ que café não costuma faiá... Abs.

Harbour ou xHarbour, this is the best,

Kapiaba escreveu:

Dúvida:
A comunidade Harbour está ativa, em pleno desenvolvimento? Se sim, isso será duradouro ou pode parar a qualquer momento? Pergunto devido ao fato deu não querer apostar em algo que amanhã pode parar de existir.

Pode ir na FÉ que café não costuma faiá... Abs.

Harbour ou xHarbour, this is the best,

Olá Kapiaba,

Se for assim, fico mais tranquilo.

Grato.