qiinfo Posted June 26, 2008 Report Share Posted June 26, 2008 Olá, Ao entrar em uma tela de cadastro e ao sair, esta havendo perca de memoria. Veja os testes que fiz: #include "hbmemory.ch"function CADASMSGSTOP( "0 = Free Variable Space (KB) " + str( memory( HB_MEM_CHAR ) )...entra na tela do cadastro...ao sairMSGSTOP( "0 = Free Variable Space (KB) " + str( memory( HB_MEM_CHAR ) )return NIL[ENDCODE]1a execução: 0 = Free Variable Space (KB) 8574402a execução: 0 = Free Variable Space (KB) 8461723a execução: 0 = Free Variable Space (KB) 8415884a execução: 0 = Free Variable Space (KB) 8350245a execução: 0 = Free Variable Space (KB) 830716...etc.Vejam que estou perdendo em media 5Kb por execução de cadastro :-(Porque está acontecendo isto e como resolver isto ?Obrigado,RossineFW 2.2c + @say + Clipper 5.2e + libs 5.3b / FWH 2.7 + @say + xHarbour Divinópolis/ MG Quote Link to comment Share on other sites More sharing options...
qiinfo Posted June 26, 2008 Author Report Share Posted June 26, 2008 Olá, Ao entrar em uma tela de cadastro e ao sair, esta havendo perca de memoria. Veja os testes que fiz: #include "hbmemory.ch"function CADASMSGSTOP( "0 = Free Variable Space (KB) " + str( memory( HB_MEM_CHAR ) )...entra na tela do cadastro...ao sairMSGSTOP( "0 = Free Variable Space (KB) " + str( memory( HB_MEM_CHAR ) )return NIL[ENDCODE]1a execução: 0 = Free Variable Space (KB) 8574402a execução: 0 = Free Variable Space (KB) 8461723a execução: 0 = Free Variable Space (KB) 8415884a execução: 0 = Free Variable Space (KB) 8350245a execução: 0 = Free Variable Space (KB) 830716...etc.Vejam que estou perdendo em media 5Kb por execução de cadastro :-(Porque está acontecendo isto e como resolver isto ?Obrigado,RossineFW 2.2c + @say + Clipper 5.2e + libs 5.3b / FWH 2.7 + @say + xHarbour Divinópolis/ MG Quote Link to comment Share on other sites More sharing options...
dablys Posted June 26, 2008 Report Share Posted June 26, 2008 Oi amigo, eu sou um frequentante aqui do fórum a algum tempo. Sou mais Clippeiro do que outra coisa, mas, pelo que tenho de experiência do clipper, o Fivewin se comporta de forma similar em questão de memória... então... use os comandos para liberar memória da própria linguagem ... assim... quando declarar e usar variáveis LOCAIS de uso só de uma tela de CADASTRO ou RELATÓRIO,,, no final libere as no return/return(.t.) libere variáveis com RELEASE VAR1, VAR2, VAR3 ... etc... use comandos ou funções que limpem a memória para reutilizar ao fazer chamadas a DLLs ... libere ao final da rotina... gerencie o uso de memória do seu sistema, pois estamos mal acostumados a ir programando, declarando variáveis e não realizar seu tratamento relativo a memória... um padrão bom de programar é declarar as variáveis em rotinas subordinadas como STATIC ou LOCAL, fazendo com que estas sejam descarregadas automaticamente ao final da PROCEDURE ou FUNCTION(). Espero ter ajudado em alguma coisa. T+ Governador Valadares - Minas Gerais Dablys Duarte Andrade Programação / Análise Clipper 5.2/5.3, Fivewin, xMate, xHarbour MSN: lucklogan@msn.com EMAIL: dablysandrade@yahoo.com.br Quote Link to comment Share on other sites More sharing options...
alex2002 Posted June 26, 2008 Report Share Posted June 26, 2008 Olá Rossine (sumido) Estamos com um problema parecido em um determinado sistema. Inexplicavelmente o sistema "ATOLA" e chega a travar o micro. Pra vc ter idéia tive que colocar uma mensagem para o usuário fechar o sistema após certo contador que implantei. Usamos todas as definições corretamente de variáveis (herança do pascal), e em versões anteriores do fivewin/xharbour este problema não acontecia. Ou seja, estamos crendo que o problema é neste conjunto (xHarbour + FiveWin). Pq principalmente este sistema não mexemos tanto assim. Também estamos estudando o que fazer pra solucionar de vez esta questão. Um abraço, Alexandre Pereira fwh 7.04, xharbour, .9971, MyMake, xDev, SqlLib msn: alexpdasilva6@hotmail.com atualmente em Rondônia Quote Link to comment Share on other sites More sharing options...
qiinfo Posted June 26, 2008 Author Report Share Posted June 26, 2008 Olá Dablys e Alexandre, Por enquanto tambem não sei como resolver isto. A memoria nunca volta ao que era anteriormente a execução de alguma função. Muito estranho isto. Aà vai as perguntas dolorosas e que suas soluções valem ouro: 1) Será que isto é um problema do xharbour ? 2) Será que isto é um problema do fivewin ? 3) O que fazer para solucionar este SÉRIO problema ??? Mesmo um simples programa sempre vai consumindo mais e mais memoria. Acho que muitos nunca se deram conta deste GRAVE problema (consumo de memoria GALOPANTE). Se alguém já passou por isto e soube como solucionar, por favor mostre-nos o caminho (hehe) Obrigado, Rossine FW 2.2c + @say + Clipper 5.2e + libs 5.3b / FWH 2.7 + @say + xHarbour Divinópolis/ MG Quote Link to comment Share on other sites More sharing options...
Guest johnson Posted June 26, 2008 Report Share Posted June 26, 2008 pode ser q ajudar: Tip sobre VARIABLES por Hernán Diego Ceccarelli Dejo un truco que quizá muchos de ustedes conozcan pero otros quizás no. Se trata de la optimización del sistema. Esto debido a que un amigo de Brasil me preguntaba sobre por que de sus GPF en una gran aplicación ???... y estaba desesperado........y bueno pensé que alguno de ustedes tendrÃa este problema quizá.... El problema estaba en las STATIC. El amigo utilizaba muchas variables STATIC por PRG, cosa que FW soporta en menor cantidad respecto al MSDOS. Igualmente JAMÃS seria necesario escribir mas de 1 variable por modulo PRG, veamos el ejemplo: No es conveniente hacer esto !!!!!!!! STATIC aVar STATIC bVar STATIC cVar STATIC dVar Se debe hacer esto !!!!!!! STATIC aArrayVars:= {Nil,Nil,Nil,Nil} #xtranslate aVar => aArrayVars\[1\] #xtranslate bVar => aArrayVars\[2\] #xtranslate cVar => aArrayVars\[3\] #xtranslate dVar => aArrayVars\[4\] En realidad con esto definimos 1 variable STATIC y consumimos menos los recursos del sistema, y esta solución EVITA modificar el código del PRG, excepto la definición inicial, y lo mas importante EVITA GPF !!! Algunos dirán que es lo mismo poner #define, PERO NO ES LO MISMO !!!!!!!!, dado que estos defines no se resuelven cuando se incorporan en COMANDOS, cosa que si resuelve #xtranslate. :-) Ahora respecto a las PUBLIC. También es conveniente usar 1 (UNA) variable en todo el sistema.......Siiiiiiiiiiii seamos bien amarretes y avaros para el uso de estas también, y evitaremos dolores de cabeza y conflictos !!!!! Supongamos que tenemos las siguientes variables: PUBLIC cSistema:= "Sistema Pepe" PUBLIC cPath:= "\Datos" PUBLIC cCopyright:= "Topo Gigio Sistemas" ....... NO NO Y NO !!!!! NO DEBEMOS HACER ESTO !!!!! Deberiamos hacer esto otro: Function Main() PUBLIC oApp:= TApplication() ....... return nil CLASS TApplication DATA cSistema INIT "Sistema Pepe" DATA cPath INIT "\Datos" DATA cCopyright INIT "Topo Gigio Sistemas" ........... y asi todas las que quisieramos !!!!! :-) ENDCLASS ........... y como es un objeto publico podremos modificar sus variables de instancia cuando se nos de la regalada gana !!!!! y tenemos 1 sola public, o sea oApp en forma de objeto y accederÃamos asà Alert( oApp:cCopyright ) !!!!!!!!!! es bien fácil !!!!!!!!!!!!!!!!! Llega el turno de las PRIVATE, es conveniente NO USARLAS usemos siempre las LOCAL y paseémoslas por referencia. También podrÃamos usar una LOCAL objeto TARRAY y esta nos sirve para pasar argumentos cientos de variables en 1 sola. OLVIDÉMONOS que existen las PRIVATE !!!!! CONCLUSIÓN: Si optimizamos el código de una aplicación lograremos: Mayor rapidez Mayores disponibilidad de recursos Menores errores GPF (serán casi imposibles de visualizar) Un código mas legible Salu2 y espero que les sirva de algo !!! Información del Autor Nombre del AutorHernán Diego Ceccarelli Descripción del documentoTip sobre VARIABLES Fecha de actualización20-09-2000 e-mail de contactochecanet@tutopia.com Johnson Fwh-2.5 xHarbour 0.99.3 - VeRCEv4 Quote Link to comment Share on other sites More sharing options...
kapiaba Posted June 27, 2008 Report Share Posted June 27, 2008 http://fivetechsoft.com/forums/viewtopic.php?t=11651&highlight=memoria http://fivetechsoft.com/forums/search.php?mode=results João Santos - São Paulo. kmt_karinha@pop.com.br kapiaba@brfree.com.br Fone: (11) 3106-2832 FWH 2.7 - xHARBOUR 0.99.61 - WorkShop.Exe Quote Link to comment Share on other sites More sharing options...
kapiaba Posted June 27, 2008 Report Share Posted June 27, 2008 // Testing a GET #include "hbmemory.ch" #include "FiveWin.ch" //------------------------------------------------------------------------// function Main() local oDlg local dDay := Date() local oGet MSGSTOP( "0 = Free Variable Space (KB) " + str( memory( HB_MEM_CHAR ) ) ) DEFINE DIALOG oDlg TITLE "Just a get" @ 2, 2 SAY "Date:" OF oDlg @ 2, 6 GET oGet VAR dDay OF oDlg SIZE 40, 10 SPINNER ; VALID ! Empty( dDay ) @ 3, 7 BUTTON "&Ok" OF oDlg SIZE 30, 12 ACTION oDlg:End() @ 3, 16 BUTTON "&Cancel" SIZE 30, 12 OF oDlg ACTION oDlg:End() CANCEL oGet:bGotFocus := { || oGet:SelectAll() } ACTIVATE DIALOG oDlg CENTERED Release All /*limpia arreglo y llama al colecor de basura de xharbour*/ hb_gcAll() MSGSTOP( "0 = Free Variable Space (KB) " + str( memory( HB_MEM_CHAR ) ) ) return nil //------------------------------------------------------------------------// procedure AppSys // Xbase++ requirement return //------------------------------------------------------------------------// #ifdef __XPP__ #define GetNew _GetNew #endif CLASS TClipGet FROM Get METHOD Display() VIRTUAL ENDCLASS //---------------------------------------------------------------------------// function GetNew( nRow, nCol, bVarBlock, cVarName, cPicture, cColor ) return TClipGet():New( nRow, nCol, bVarBlock, cVarName, cPicture, cColor ) //---------------------------------------------------------------------------// id=code>id=code>João Santos - São Paulo. kmt_karinha@pop.com.br kapiaba@brfree.com.br Fone: (11) 3106-2832 FWH 2.7 - xHARBOUR 0.99.61 - WorkShop.Exe Quote Link to comment Share on other sites More sharing options...
qiinfo Posted June 27, 2008 Author Report Share Posted June 27, 2008 Olá johnson, O que disse Hernan realmente é uma excelente idéia. Variaveis STATIC ================ Uso poucas, mas mesmo assim vou usar a tecnica explicada pelo hernan. Variaveis PUBLIC ================ Estas uso frequentemente, mas vou usar o esquema de classes. ...mas acredito que o problema não está no jeito da gente programar e sim no xharbour ou fivewin , ou seja, o problema vem de cima. Talvez por inexperiência minha não estou conseguindo resolver este problema, mas seguimos na expectativa de poder resolver isto. Obrigado, Rossine FW 2.2c + @say + Clipper 5.2e + libs 5.3b / FWH 2.7 + @say + xHarbour Divinópolis/ MG Quote Link to comment Share on other sites More sharing options...
vagner Posted June 27, 2008 Report Share Posted June 27, 2008 citação:Olá Dablys e Alexandre, Por enquanto tambem não sei como resolver isto. A memoria nunca volta ao que era anteriormente a execução de alguma função. Muito estranho isto. Aà vai as perguntas dolorosas e que suas soluções valem ouro: 1) Será que isto é um problema do xharbour ? 2) Será que isto é um problema do fivewin ? 3) O que fazer para solucionar este SÉRIO problema ??? Mesmo um simples programa sempre vai consumindo mais e mais memoria. Acho que muitos nunca se deram conta deste GRAVE problema (consumo de memoria GALOPANTE). Se alguém já passou por isto e soube como solucionar, por favor mostre-nos o caminho (hehe) Obrigado, Rossine FW 2.2c + @say + Clipper 5.2e + libs 5.3b / FWH 2.7 + @say + xHarbour Divinópolis/ MG id=quote>id=quote>Olá Rossine, blz ? Meu, isso é um problema que enfrento desde o clipper, perda de memória e recursos, é realmente um grave problema, porém, está também relacionado ao RWindows. Infelizmente o que podemos fazer é otimizar ao máximo nossos sistemas, como colocou o Johnson, eu já faço isso a muito tempo , em relação as variáveis publicas, é uma boa saida, variáveis static somente ser for muito necessária, locais a vontade, Private (o q é isso ? ). Botões, escolha o que menos lhe consuma recursos, eu parei de usar a TSButton e a TSBrowse, a muitos anos, pois o consumo que dava era enorme (Não sei como está hoje ) Por isso montei as minhas em cima da do FW, me dá o efeito que eu quero e o consumo é bem menor Bom é isso , otimizar o programa é a melhor saida Veja se no seu prg de cadastro se está colocando muitas figuras que dá um consumo maior, veja se está com resource, faça um teste e mude para @ ou vice versa, veja como está definindo seus Gets Says Buttons, Browses, alguma coisa está pegando, vai bloqueando tudo, e desbloqueando aos poucos, com certeza irá encontrar o problema Mas fique ciente que ainda haverá consumo de recursos/memória Vagner Wirts VI Encontro está chegando , não perca Quote Link to comment Share on other sites More sharing options...
qiinfo Posted June 27, 2008 Author Report Share Posted June 27, 2008 Olá João, Executei o seu exemplo e me me retornou os seguintes resultados: Ao entrar no sistema: Free Variable Space (KB) 864412 Ao sair do sistema: Free Variable Space (KB) 849400 É sobre esta perca que estou falando, e se monto uma função para chamar a tela de cadastro e fico repetindo a entrada e saida dela, aà a memoria vai só abaixando e nunca é restaurada. Obrigado e abraços, Rossine FW 2.2c + @say + Clipper 5.2e + libs 5.3b / FWH 2.7 + @say + xHarbour Divinópolis/ MG Quote Link to comment Share on other sites More sharing options...
qiinfo Posted June 27, 2008 Author Report Share Posted June 27, 2008 Olá Vagner, citação: otimizar o programa é a melhor saida id=quote>id=quote>Concordo plenamente com você citação: Mas fique ciente que ainda haverá consumo de recursos/memóriaid=quote>id=quote>Sei disto, mas o que questiono aqui é o porque quando entro em uma tela de cadastro e depois saio, a memoria não retorna como estava, ou seja, alguma coisa ficou na memória, mas o que ? Existe alguma função que me mostra o as variáveis que estão na memoria naquele momento, e depois tem como apagá-las da memória ? Obrigado, Rossine FW 2.2c + @say + Clipper 5.2e + libs 5.3b / FWH 2.7 + @say + xHarbour Divinópolis/ MG Quote Link to comment Share on other sites More sharing options...
kapiaba Posted June 27, 2008 Report Share Posted June 27, 2008 citação:Olá João, Executei o seu exemplo e me me retornou os seguintes resultados: Ao entrar no sistema: Free Variable Space (KB) 864412 Ao sair do sistema: Free Variable Space (KB) 849400 É sobre esta perca que estou falando, e se monto uma função para chamar a tela de cadastro e fico repetindo a entrada e saida dela, aà a memoria vai só abaixando e nunca é restaurada. Obrigado e abraços, Rossine FW 2.2c + @say + Clipper 5.2e + libs 5.3b / FWH 2.7 + @say + xHarbour Divinópolis/ MG id=quote>id=quote>ESTà CORRETO, É ASSIM MESMO. NÃO SE PREOCUPE. PRINCIPALMENTE O WINDOWS XP, TIRA ISTO DE LETRA AUTOMATICAMENTE. SEMPRE QUE NECESSITAR DE MAIS MEMORIA, O WINDOWS XP, BUSCARA NAS AUXILIARES E ´COMPENSA´. EXECUTE O PROGRAMA, VEJA A MEMORIA QUE ELE OCUPOU. EXECUTE UM EDITOR DE TEXTOS QUALQUER. VERA QUE NÃO SERà MAIS A MESMA MEMORIA. NÃO SE PREOCUPE, POIS O WINDOWS ´ALOUCOU´ CADA UM EM UM LOCAL, NÃO CAUSANDO NENHUM PROBLEMA A SUA APLICAÇÃO. EM 32 BITS, NÃO TENHA MEDO. A NÃO SER QUE ISTO SEJA UM DEFEITO DO @SAY... hehehehehehe. Em tempo: Nem em 16 Bits, eu tive problemas com memória... A não ser, quando queimava o pente. kkkkkkkkkkkkk. RECURSOS... AHH, RECURSOS!!! Abraços. João Santos - São Paulo. kmt_karinha@pop.com.br kapiaba@brfree.com.br Fone: (11) 3106-2832 FWH 2.7 - xHARBOUR 0.99.61 - WorkShop.Exe Quote Link to comment Share on other sites More sharing options...
alex2002 Posted June 27, 2008 Report Share Posted June 27, 2008 Olá galera. Só pra ficar claro. Como disse acima, a declaração das variáveis são corretas e este mesmo sistema antes funcionava sem a tal "perda" de memória. Todas as máquinas são Windows XP com no mÃnimo 512 de RAM (memória fÃsica não é problema). Não fizemos nenhuma mudança no sistema que levasse a tal ocasião, apenas mudamos a versão do xHarbour + FiveWin (antes era o 0.9960 e 2.40). Um abraço, Alexandre Pereira fwh 7.04, xharbour, .9971, MyMake, xDev, SqlLib msn: alexpdasilva6@hotmail.com atualmente em Rondônia Quote Link to comment Share on other sites More sharing options...
kapiaba Posted June 27, 2008 Report Share Posted June 27, 2008 citação:Olá galera. Só pra ficar claro. Como disse acima, a declaração das variáveis são corretas e este mesmo sistema antes funcionava sem a tal "perda" de memória. Todas as máquinas são Windows XP com no mÃnimo 512 de RAM (memória fÃsica não é problema). Não fizemos nenhuma mudança no sistema que levasse a tal ocasião, apenas mudamos a versão do xHarbour + FiveWin (antes era o 0.9960 e 2.40). Um abraço, Alexandre Pereira fwh 7.04, xharbour, .9971, MyMake, xDev, SqlLib msn: alexpdasilva6@hotmail.com atualmente em Rondônia id=quote>id=quote>ALEXANDRE, FICAR CLARO O QUE??? IDENTIFIQUE O MODULO. COM UMA NOVA VERSAO DE COMPILADOR, TENS QUE ADAPTAR UMA ROTINA RUIM, A NOVA REALIDADE DO COMPILADOR. ACHE O MODULO PROBLEMATICO E LIBERE A MEMORIA DA MAQUINA COM O COMANDO QUE INDIQUEI. ERRO É SEU, E O COMPILADOR ESTA ´FALANDO´ PRA VOCE. OU VOCE ACHA QUE É INFALIVEL, COMO O SENHOR VAGNER WIRTS SE ACHA??? KKKKKKKKKKKKKKKKKKKKKKKKKKK. Abraços. João Santos - São Paulo. kmt_karinha@pop.com.br kapiaba@brfree.com.br Fone: (11) 3106-2832 FWH 2.7 - xHARBOUR 0.99.61 - WorkShop.Exe Quote Link to comment Share on other sites More sharing options...
alex2002 Posted June 27, 2008 Report Share Posted June 27, 2008 citação:ACHE O MODULO PROBLEMATICO E LIBERE A MEMORIA DA MAQUINA COM O COMANDO QUE INDIQUEI. ERRO É SEU, E O COMPILADOR ESTA ´FALANDO´ PRA VOCE. OU VOCE ACHA QUE É INFALIVEL, COMO O SENHOR VAGNER WIRTS SE ACHA??? KKKKKKKKKKKKKKKKKKKKKKKKKKK. id=quote>id=quote>João, Pra vc ter uma idéia, eu já analisei este programa pelo menos umas 15 vezes. Já sei ele de traz pra frente. Sinceramente, não sei o que pode ser. Declarações de variáveis? Nossas declarações são bem definidas (não que sejamos iguais ao Wirts (longe disso hehehehe)). O que pega é que antes ele rodava legal. Por isso da desconfiança, mas de qualquer forma vamos ficar "debugando" aqui para poder pegar o bicho e relatar no fórum. Também vou incrementar a sua sugestão pra ver se tem um resultado positivo. Um abraço, Alexandre Pereira fwh 7.04, xharbour, .9971, MyMake, xDev, SqlLib msn: alexpdasilva6@hotmail.com atualmente em Rondônia Editado por - alex2002 on 27/06/2008 11:55:42 Quote Link to comment Share on other sites More sharing options...
kapiaba Posted June 27, 2008 Report Share Posted June 27, 2008 citação: citação:ACHE O MODULO PROBLEMATICO E LIBERE A MEMORIA DA MAQUINA COM O COMANDO QUE INDIQUEI. ERRO É SEU, E O COMPILADOR ESTA ´FALANDO´ PRA VOCE. OU VOCE ACHA QUE É INFALIVEL, COMO O SENHOR VAGNER WIRTS SE ACHA??? KKKKKKKKKKKKKKKKKKKKKKKKKKK. id=quote>id=quote>João, Pra vc ter uma idéia, eu já analisei este programa pelo menos umas 15 vezes. Já sei ele de traz pra frente. Sinceramente, não sei o que pode ser. Declarações de variáveis? Nossas declarações são bem definidas (não que sejamos iguais ao Wirts (longe disso hehehehe)). O que pega é que antes ele rodava legal. Por isso da desconfiança, mas de qualquer forma vamos ficar "debugando" aqui para poder pegar o bicho e relatar no fórum. Um abraço, Alexandre Pereira fwh 7.04, xharbour, .9971, MyMake, xDev, SqlLib msn: alexpdasilva6@hotmail.com atualmente em Rondônia id=quote>id=quote>A FALHA É NO MODULO. SE VOCE TIVER UM PROCESSAMENTO DEMORADO NESTE MODULO, USE O SYSREFRESH() NO LOOPING. E AO SAIR DA APLICACAO OU DO PROCESSAMENTO, LIBERE A MEMORIA COM O COMANDO DO XHARBOUR INDICADO: HB_GCALL(). João Santos - São Paulo. kmt_karinha@pop.com.br kapiaba@brfree.com.br Fone: (11) 3106-2832 FWH 2.7 - xHARBOUR 0.99.61 - WorkShop.Exe Quote Link to comment Share on other sites More sharing options...
qiinfo Posted June 27, 2008 Author Report Share Posted June 27, 2008 Olá pessoal, O ideal seria salvar a memória antes de qualquer processamento, e depois restaurar esta memória. Mas como fazer isto ??? Abraços, Rossine FW 2.2c + @say + Clipper 5.2e + libs 5.3b / FWH 2.7 + @say + xHarbour Divinópolis/ MG Quote Link to comment Share on other sites More sharing options...
evandro Posted June 27, 2008 Report Share Posted June 27, 2008 Olá, No sistema que o Alex2002 está reportando, já usamos a única variável pública conforme o Ceccarelli sugere. Funcionava 100% sem problemas na versão 0.99.51 do xHarbour+ FWH 2.6. Ao mudar para a versão Xhb0.99.71+FWH7.04 passou a dar o erro. Claro que tem alguma coisa na rotina que despende mais memória que em outras rotina que não dão o problema. Mas porque com uma versão não dá o problema e com outra dá. E se mudarmos para versões mais novas ainda, solucionaria? []s, Evandro G. de Paula Curvelo - MG evandro@skillnet.com.br (Escr. - na Cidade) imortal@skillnet.com.br (Res. - na Roça) FWH 2.6+PellesC+MyMake+xHarbour.org 0.99.5+SqlLib I PREPARATÓRIO PARA O VI ENCONTRO FIVEWIN - 05/JULHO/2008 - CURVELO - MG Quote Link to comment Share on other sites More sharing options...
kapiaba Posted June 27, 2008 Report Share Posted June 27, 2008 citação:Olá, No sistema que o Alex2002 está reportando, já usamos a única variável pública conforme o Ceccarelli sugere. Funcionava 100% sem problemas na versão 0.99.51 do xHarbour+ FWH 2.6. Ao mudar para a versão Xhb0.99.71+FWH7.04 passou a dar o erro. Claro que tem alguma coisa na rotina que despende mais memória que em outras rotina que não dão o problema. Mas porque com uma versão não dá o problema e com outra dá. E se mudarmos para versões mais novas ainda, solucionaria? []s, Evandro G. de Paula Curvelo - MG evandro@skillnet.com.br (Escr. - na Cidade) imortal@skillnet.com.br (Res. - na Roça) FWH 2.6+PellesC+MyMake+xHarbour.org 0.99.5+SqlLib I PREPARATÓRIO PARA O VI ENCONTRO FIVEWIN - 05/JULHO/2008 - CURVELO - MG id=quote>id=quote>SOLUCIONARIA O QUE??? PRIMEIRO, TENS QUE PROVAR QUE É UM ERRO DO COMPILADOR. EU DUVIDO E FAÇO POUCO... PORQUE ANTES FUNCIONAVA? PORQUE O COMPILADOR ´DEIXAVA´ PASSAR POR QUE ELE NÃO TINHA PREVISÃO PARA ´BARRAR´. ATUALIZADA A VERSÃO DO COMPILADOR, ELE COMEÇA ENTÃO A ´BARRAR´ PROBLEMAS COM LÓGICA RUIM... TROQUEI DE COMPILADOR, E NOTEI, QUE EU ´KGAVA´ 3X4... CORRIGI O MODULO... VOCES FALAM... FALAM... NÃO MOSTRARAM NADA... E QUEREM QUE O COMPILADOR ´ASSUMA´ O ERRO... É RUIM, HEIM?!! ROSSINE, QUEM CONTROLA A MEMORIA, É O WINDOWS, NÃO SEU PROGRAMA. VOCE NÃO ESTà TENDO PERDA DE MEMORIA, TENS CONSUMO NATURAL DE MEMORIA, QUE SE LIBERA NATURALMENTE COM O COMANDO APROPRIADO AO SE SAIR DE UMA ROTINA OU PROGRAMA. Abraços. João Santos - São Paulo. kmt_karinha@pop.com.br kapiaba@brfree.com.br Fone: (11) 3106-2832 FWH 2.7 - xHARBOUR 0.99.61 - WorkShop.Exe Quote Link to comment Share on other sites More sharing options...
vagner Posted June 27, 2008 Report Share Posted June 27, 2008 citação:SOLUCIONARIA O QUE??? PRIMEIRO, TENS QUE PROVAR QUE É UM ERRO DO COMPILADOR. EU DUVIDO E FAÇO POUCO... Abraços. João Santos - São Paulo. kmt_karinha@pop.com.br kapiaba@brfree.com.br Fone: (11) 3106-2832 FWH 2.7 - xHARBOUR 0.99.61 - WorkShop.Exe id=quote>id=quote>Olá Kapi, as vezes é difÃcil de vc entender alguma coisa , eles (xHarbour), sempre mudam coisas que nem sempre há necessidade, isso já foi reportado por muitos no news do xharbour, coisas que funcionavam direito deixam de funcionar, e depois que relatamos o problema, é novamente arrumado para nova versão, isso é pq muitos mexem nele e como são programadores, também estão sujeitos a erro. E existem ainda coisas que não estão implementadas como a que vou postar abaixo, veja que quem respondeu foi o próprio Luiz Rafael Culik (o responsável pelo xHarbour no Brasil) Ola > Ex: > local lnVAR := 0 as int > local laARR := {} as array > > Existe algum parametro que posso utilizar para contornar, sem ter que > alterar todo sistema? pode tentar usar -w3 que e o strong typing do xharbour lembre apenas que no momento nao esta 100% funcional eu recomendo comentar os as tipo no seu fonte []s Luiz id=code>id=code>Com isso, vc pode ver que alterações são feitas a todo momento e melhorias lógico , mas também existem coisas que temos que ficar "caçando" para saber o que foi mudado, um exemplo simples : Na Versão 8.05 do xHarbour foi criada uma Lib "ZLib.Lib", onde havia uma função de tratamento de Zip, que ficava na HBZip.Lib até a versão 8.04 Fácil de resolver quando vc sabe onde procurar, agora lhe falo uma coisa , fica difÃcil vc pegar um programa compilado com a 8.04 funcionando direitinho, compilar com a 8.05 e dar erro na compilação, e vc ter q sair correndo procurar onde está o problema, e saber depois q simplesmente, retiraram a função de uma lib e jogaram em outra sem mais nem menos Vagner Wirts VI Encontro está chegando , não perca Quote Link to comment Share on other sites More sharing options...
kapiaba Posted June 27, 2008 Report Share Posted June 27, 2008 citação: citação:SOLUCIONARIA O QUE??? PRIMEIRO, TENS QUE PROVAR QUE É UM ERRO DO COMPILADOR. EU DUVIDO E FAÇO POUCO... Abraços. João Santos - São Paulo. kmt_karinha@pop.com.br kapiaba@brfree.com.br Fone: (11) 3106-2832 FWH 2.7 - xHARBOUR 0.99.61 - WorkShop.Exe id=quote>id=quote>Olá Kapi, as vezes é difÃcil de vc entender alguma coisa , eles (xHarbour), sempre mudam coisas que nem sempre há necessidade, isso já foi reportado por muitos no news do xharbour, coisas que funcionavam direito deixam de funcionar, e depois que relatamos o problema, é novamente arrumado para nova versão, isso é pq muitos mexem nele e como são programadores, também estão sujeitos a erro. E existem ainda coisas que não estão implementadas como a que vou postar abaixo, veja que quem respondeu foi o próprio Luiz Rafael Culik (o responsável pelo xHarbour no Brasil) Ola > Ex: > local lnVAR := 0 as int > local laARR := {} as array > > Existe algum parametro que posso utilizar para contornar, sem ter que > alterar todo sistema? pode tentar usar -w3 que e o strong typing do xharbour lembre apenas que no momento nao esta 100% funcional eu recomendo comentar os as tipo no seu fonte []s Luiz id=code>id=code>Com isso, vc pode ver que alterações são feitas a todo momento e melhorias lógico , mas também existem coisas que temos que ficar "caçando" para saber o que foi mudado, um exemplo simples : Na Versão 8.05 do xHarbour foi criada uma Lib "ZLib.Lib", onde havia uma função de tratamento de Zip, que ficava na HBZip.Lib até a versão 8.04 Fácil de resolver quando vc sabe onde procurar, agora lhe falo uma coisa , fica difÃcil vc pegar um programa compilado com a 8.04 funcionando direitinho, compilar com a 8.05 e dar erro na compilação, e vc ter q sair correndo procurar onde está o problema, e saber depois q simplesmente, retiraram a função de uma lib e jogaram em outra sem mais nem menos Vagner Wirts VI Encontro está chegando , não perca id=quote>id=quote>VAGNER, APESAR DE VOCE INSISTIR EM SER ´JUMA´, NESTA EXPLICAÇÃO, QUE NÃO TEM NADA A VER COM O PROBLEMA DO ALEXANDRE, VOCE ESTà ABSOLUTAMENTE CORRETO. INSISTO, QUE O PROBLEMA DE MEMORIA, NÃO TEM NADA A VER COM A VERSÃO DO COMPILADOR. ELE QUE ME PROVE EM CONTRARIO... VOCE PODE ATÉ CHAMAR O LUIZ RAFAEL CULIK, QUERO VER ELE PROVAR, QUE UM PROBLEMA DE MEMORIA, SEJA DO COMPILADOR. PAGO PRA VER... EM BREJAS!!! Abraços. João Santos - São Paulo. kmt_karinha@pop.com.br kapiaba@brfree.com.br Fone: (11) 3106-2832 FWH 2.7 - xHARBOUR 0.99.61 - WorkShop.Exe Quote Link to comment Share on other sites More sharing options...
vagner Posted June 27, 2008 Report Share Posted June 27, 2008 citação:VAGNER, APESAR DE VOCE INSISTIR EM SER ´JUMA´, NESTA EXPLICAÇÃO, QUE NÃO TEM NADA A VER COM O PROBLEMA DO ALEXANDRE, VOCE ESTà ABSOLUTAMENTE CORRETO. INSISTO, QUE O PROBLEMA DE MEMORIA, NÃO TEM NADA A VER COM A VERSÃO DO COMPILADOR. ELE QUE ME PROVE EM CONTRARIO... VOCE PODE ATÉ CHAMAR O LUIZ RAFAEL CULIK, QUERO VER ELE PROVAR, QUE UM PROBLEMA DE MEMORIA, SEJA DO COMPILADOR. PAGO PRA VER... EM BREJAS!!! Abraços. João Santos - São Paulo. kmt_karinha@pop.com.br kapiaba@brfree.com.br Fone: (11) 3106-2832 FWH 2.7 - xHARBOUR 0.99.61 - WorkShop.Exe id=quote>id=quote>Quem está sendo "JUMA" agora, se vc acabou de concordar comigo ? Pode ser que no Compilador, criaram uma função que ocupe uma parte da memória, e esqueceram de limpar na saida , não esqueça que são programadores como nós, sujeito a falhas Ah !!!, esqueci , vc não comete falhas Vagner Wirts VI Encontro está chegando , não perca Quote Link to comment Share on other sites More sharing options...
alex2002 Posted June 27, 2008 Report Share Posted June 27, 2008 hehehehehehe Um abraço, Alexandre Pereira fwh 7.04, xharbour, .9971, MyMake, xDev, SqlLib msn: alexpdasilva6@hotmail.com atualmente em Rondônia Quote Link to comment Share on other sites More sharing options...
kapiaba Posted June 27, 2008 Report Share Posted June 27, 2008 citação: citação:VAGNER, APESAR DE VOCE INSISTIR EM SER ´JUMA´, NESTA EXPLICAÇÃO, QUE NÃO TEM NADA A VER COM O PROBLEMA DO ALEXANDRE, VOCE ESTà ABSOLUTAMENTE CORRETO. INSISTO, QUE O PROBLEMA DE MEMORIA, NÃO TEM NADA A VER COM A VERSÃO DO COMPILADOR. ELE QUE ME PROVE EM CONTRARIO... VOCE PODE ATÉ CHAMAR O LUIZ RAFAEL CULIK, QUERO VER ELE PROVAR, QUE UM PROBLEMA DE MEMORIA, SEJA DO COMPILADOR. PAGO PRA VER... EM BREJAS!!! Abraços. João Santos - São Paulo. kmt_karinha@pop.com.br kapiaba@brfree.com.br Fone: (11) 3106-2832 FWH 2.7 - xHARBOUR 0.99.61 - WorkShop.Exe id=quote>id=quote>Quem está sendo "JUMA" agora, se vc acabou de concordar comigo ? Pode ser que no Compilador, criaram uma função que ocupe uma parte da memória, e esqueceram de limpar na saida , não esqueça que são programadores como nós, sujeito a falhas Ah !!!, esqueci , vc não comete falhas Vagner Wirts VI Encontro está chegando , não perca id=quote>id=quote>KKKKKKKKKKKKKKKKKKKKK. PROGRAMADORES COMO ´NÓS´ É O KCTE!! PROGRAMADORES COMO VOCE... SÓ SE FOR COMO VOCE... PRA KGAR ASSIM.... KKKKKKKKKKKKKKKKKKKK. CADÊ WIRTEEEEEESSSSSS??? CADÊ WIRTEEEEEESSSSSS??? COM CERVEJA, É ERRO DO ALEXANDRE PEREIRA, QUE APRENDEU A PROGRAMAR COM QUEM??? QUEM??? QUEM??? COM VAGNER WIRTS... ORAS, POIS, POIS!! Abraços João Santos - São Paulo. kmt_karinha@pop.com.br kapiaba@brfree.com.br Fone: (11) 3106-2832 FWH 2.7 - xHARBOUR 0.99.61 - WorkShop.Exe Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.