Re: [delphi-br] [MAF] Processamento de informações em lote
Isse é o tipo de problema que me dá água na boca! Vamos lá. Seu problema pode ser resolvido com a estrutura de dados FIFO (First In First Out), também conhecida como FILA (o primeiro que entra é o primeiro que sai). O Delphi tem uma classe pra lidar com essa estrutura, se chama TQueue e fica na unit Contnrs. Nessa estrutura, há dois métodos principais: Push - para colocar um item no final da fila Pop - para remover o item que está no início da fila Na implementação em Delphi, os itens são do tipo Pointer. Você pode criar uma classe para encapsular as informações que recebe via socket. Se essa classe herdar de TInterfacedObject você nem precisará se preocupar com a desalocação desses objetos. O problema com a sua solução: Arrays dinâmicos precisam ser realocados na memória cada vez que você aumenta o tamanho dele. Dependendo da quantidade de itens no array e do quanto cada item ocupa em memória, isso pode ser uma operação cara. Independente do tamanho que chega o seu array e do quanto ele ocupa em memória, com certeza a solução usando uma FILA terá um desempenho melhor (além de ser bem mais elegante). Espero ter ajudado. Um abraço, Dirlei Dionísio http://MaisQueBomCodigo.blogspot.com Em Sex, 2010-05-21 às 13:47 +, Marcos Abreu Ferreira escreveu: Pessoal, tenho a seguinte situação: Recebo informações de um sistema via socket e essas informações teem que ser processadas na ordem que chegam e não podem ser processadas sem que o processamento da anterior termine. Tentei fazer usando o ClientDataSet, onde criei um campo autoincrement e outro com a informação a ser processada. Como posso receber umas 200 linhas de informações por segundo, o ClientDataSet se mostrou lento, pois preciso de uma resposta super rápida no processamento. Resolvi então trabalhar com array dinâmico, onde a cada vez que recebo uma informação, crio um elemento novo no array e salvo a informação lá. Tenho uma variável global onde controlo qual foi o último array processado e verificando quantos elementos tem o array, processos os faltantes. Coloquei um timer varrendo o array de 1 em 1 milisegundo. Qual a opinião de vocês quanto a minha solução? Teriam alguma dica sobre como melhora-la?
Re: [delphi-br] SVN - Ambientes de Homologação e Produção
Alexandre, Aqui onde trabalho fazemos commit mesmo antes de ter concluído uma implementação grande. Isso, de certa forma, é um backup dos trabalhos em desenvolvimento. Quando liberamos uma versão para teste, fazemos commit de tudo para o repositório, mesmo antes dos testes. Se os testes detectarem algum problema, corrigimos, liberamos nova versão e fazemos commit de tudo novamente. Quando os testes são concluídos, adicionamos uma Tag com o número da versão (no formato n.n.n.n) aos fontes que estão no repositório. Se antes de concluírmos a implementação for necessário resgatar a última versão estável, baixamos o repositório o projeto com o Tag da versão estável. Não creio ser uma boa idéia ter mais de um repositório para o mesmo projeto. Você pode seguramente isolar a versão estável da que está em manutenção usando Tags. Um abraço, Dirlei Dionísio http://MaisQueBomCodigo.blogspot.com Em Qui, 2010-05-20 às 15:39 -0300, Alexandre escreveu: Pessoal, aqui eu uso o svn como controle de versões. O método que estamos usando no momento é: 1. o desenvolvedor corrige bugs e coloca o .exe pra teste. Alguem testa, da ok, entao ele comita eta em produção. 2. o desenvolvedor tem uma implementação grande para fazer. Ele dá um update e inicia. Dá os updates para atualizar seus fontes ao decorrer do tempo. Ao fim, coloca o.exe em testes. Alguem faz o teste e da o ok. Entao ele comita e fica em produção. Gostaria de saber se há uma forma melhor de se fazer isso, seja usando o svn (branch), seja criando um novo repositorio para produção e deixando o atual como testes. O que os senhores conhecem a respeito? Att. Alexandre Pedroto ASP Informatica (21) 2667-4488
Re: [delphi-br] Ajuda para definir valor de projeto
Isso é, provavelmente, a parte mais crítica do projeto. Estimar o preço baseado no tempo de desenvolvimento x custo por hora é o que quase todo mundo faz (inclusive a empresa onde trabalho), mas pressupõe que o cliente sabe exatamente o que ele precisa antes de o projeto começar e que a análise e o projeto serão feitos sem falhas. Nessa abordagem, muitas vezes se acrescenta um percentual de gordura sobre o preço final para cobrir eventuais falhas na estimativa. Às vezes funciona, às vezes não. A margem de acerto é maior em projetos muito pequenos (de alguns dias a 1 ou 2 semanas). O que tenho insistido para conseguir implantar onde trabalho é o Contrato de escopo variável (ou negociável). Talvez seja de ajuda pra você ler sobre o assunto. [ ]'s Dirlei Dionísio http://MaisQueBomCodigo.blogspot.com Em Ter, 2010-05-18 às 14:06 -0300, Eduardo Melo escreveu: Ola Pessoal, Eu vou desenvolver um sistema para uma loja de material de construção, o sistema terá cupom fiscal, cadastros, parte financeira. Gostaria de ter uma base de como cobrar por um sistema. Eu devo cobrar pelo projeto a desenvolver mais uma mensalidade? Exemplo penso em cobrar pelo sistema como um projeto que irei no cliente coletar as informações, sempre estarei em contato com o cliente para desenvolver o sistema adequado, pensei no valor de R$ 3.000,00 (três mil reais) pelo projeto e mais uma mensalidade para questão de suporte, gostaria de saber se esta errado o método de cobrar esse valor, ou cobrar só implantação e a mensalidade. Gostaria da opinião do pessoal do grupo. Desde de já agradeço. -- Atenciosamente Eduardo Melo Bacharelado em Sistemas de Informação
Re: [delphi-br] Hibernate
Existem o DObject e o tiOPF. Você deve encontrar outras opções procurando por ORM Delphi no Google. PS: Suponho que você tenha um motivo para querer usar ORM (Mapeamento Objeto-Relacional) no Delphi. []'s Dirlei. Em Qua, 2010-05-05 às 17:28 +, adauri_jr escreveu: Boa tarde a todos, para o Java e o .Net existe um framework, chamado Hibernate( http://pt.wikipedia.org/wiki/Hibernate ), alguem sabe se existe algo parecido pro Delphi ? Obrigado Jr.
Re: [delphi-br] ZLib+Winzip
Jhosef, Se você não deseja utilizar componentes de terceiros, vejo algumas alternativas: 1 - Compreender a estrutura de um arquivo ZIP e criar você mesmo uma forma de gerar arquivos compactados que possam ser extraídos pelo Winzip/Winrar. Um arquivo no formato ZIP contêm um ou mais arquivos compactados com o algoritmo DEFLATE (geralmente), porém no final do arquivo há metadados como o nome e tamanho original/compactado de cada arquivo. A biblioteca ZLib do Delphi usa o algoritmo DEFLATE, mas não gera esses metadados necessários ao ZIP, apenas gera a sequência de bytes compactada. Você precisa adicionar os metadados para gerar um legítimo arquivo ZIP. Informações sobre esses metadados você certamente encontrará na internet. 2 - Você também pode olhar o código de algum componente que já faça isso e escrever o seu próprio código. Ou pode copiar o código para a sua aplicação - se a licença do componente permitir isso (ou se você não liga pra violar licenças). 3 - Ainda outra alternativa é levar junto com o seu software algum programa command-line que faça esse trabalho por você (Já usei o 7zip para isso). Um abraço, Dirlei. On 05/05/2010 10:36, Jhosef Marks wrote: E ai galera, é o seguinte... Com a Zlib do delphi eu consegui compactar um arquivo, mas não consigo descompacta-lo com o Winzip ou Winrar... Já procurei na lista e no google alguma forma de fazer isso sem componentes ou bibliotecas de terceiro, quero usar apenas o ZLIB nativo do delphi e mais nada. Estou usando o Delphi 2010. Isso é possível Att, Jhosef Marks de Carvalho Blog: http://www.jhosefmarks.com.br Jesus está voltando E se o meu povo, que se chama pelo meu nome, se humilhar, e orar, e buscar a minha face e se converter dos seus maus caminhos, então eu ouvirei dos céus, e perdoarei os seus pecados, e sararei a sua terra. (2 Cr 7:14)
Re: [delphi-br] Qual o limite de tamanho para um executável?
Fellipe, O que esse programa faz? Agora comentanto o comentário do amigo Walter - Acho que imagens não precisam ser restritas, desde que fiquem fora do executável. - Racionar forms é perigoso pois pode diminuir a usabilidade do software e/ou aumentar a complexidade dele. Usar herança visual de formulários pode ser uma alternativa. [ ]'s Dirlei. Em Ter, 2010-05-04 às 09:25 -0300, Walter Chagas (Bol) escreveu: Executáveis muito grandes são mal sinal. Sinal de que o projeto/programação/codificação está mal estruturado. Sinal de que o compilador ou o Linkeditor estão mal configurados. Sinal de que o projeto está muito gordo ou cheio de coisas que nunca serão usadas. Executáveis muito grandes, são lentos, dão problemas de alocação de memória e recursos, dentre outros. Quase todos aqui são unânimes em propor a modularização. Quebrar seu exe em dll's ou Bpl's que, inclusive, facilitam muito a manutenção visto que dependendo do que for, voce só mexe na dll e pronto. Não compromete o resto do sistema. Convem sempre analisar as configurações do compilador e do linkador antes de gerar o exe final para implantar. Pode-se perfeitamente, por exemplo, desabilitar as opções de debugação. Outra coisa que incha executavel é mandar incluir parametros e mapeamento interno para usar o Turbo Debugger da borland (Include TD32 Debug Info). Verifique se isto está habilitado. A regra básica é: O executavel passou de 4MB, é hora de revisão. Revise se há rotinas que podem ser incorporadas em módulos, bem como funções. Revise se há redundância de código e se fragmentos de código comuns em vários pontos não podem ser convertidos em uma função a ser armazenada em uma dll que faça a mesma coisa. Imagens, devem ser restritas ao mínimo possível e, preferencialmente, de baixa resolução. Imagens grandes = executaveis grandes = alocação maior de memória. Forms podem ser racionados. Verifique se um processo/Rotina em seu sistema que use 5 forms não podem cair pra pra 2 forms ou mesmo 1 com abas. Componenetes de acesso a dados (Queries, DSPs e CDS´s) podem ser reaproveitados. Verifique se voce não está usando componentes demais pra coisas de menos. E por aí vai... []s Walter Alves Chagas Junior Belo Horizonte - MG - Brazil wchagasj bol.com.br http://delphitocorporerm.blogspot.com/ http://twitter.com/wchagas MSN: whitesock...@hotmail.com SKYPE: WalterChagasJr - Original Message - From: Fabiano Moura mctbrasil gmail.com To: delphi-br@yahoogrupos.com.br Sent: Monday, May 03, 2010 11:48 PM Subject: Re: [delphi-br] Qual o limite de tamanho para um executável? E eu que pensei que o meu programa de 8 MB era grande, rsrsrs!!! Em 3 de maio de 2010 19:29, Marcos Alexandre Lemos Rodrigues marcosalexandre.rodrigues gmail.com escreveu: Limite não existe, já vi executáveis com mais de 300 MB. Só não é prático. Melhor separar em pacotes bpl mesmo ou então em dlls, que além de ficar mais fácil trabalhar, existe opção de carregar na memória apenas quando o usuário realmente precisar do módulo, economizando memória geral. Em 3 de maio de 2010 19:14, Rubem Rocha rubem.rocha dtmanaus.com.br escreveu: 35MB? Meu amigo, considere ‘para ontem’ separar sua aplicação em módulos, preferencialmente em pacotes BPL. Tem material a botão na Internet falando sobre isso. Sds. De: delphi-br@yahoogrupos.com.br delphi-br%40yahoogrupos.com.br [mailto: delphi-br@yahoogrupos.com.br delphi-br%40yahoogrupos.com.br] Em nome de Fellipe Henrique Enviada em: segunda-feira, 3 de maio de 2010 16:16 Para: delphi-br@yahoogrupos.com.br delphi-br%40yahoogrupos.com.br Assunto: [delphi-br] Qual o limite de tamanho para um executável? Amigos, tenho um executável, que está chegando perto dos 35MB... existe algum limite? se passar dele começa a dar problemas? que tipos de problemas? Att. -- _ T.·.F.·.A.·. Fellipe Henrique
Re: [delphi-br] OFF TOPIC-Multiprocessamento com Firebird
Dê uma olhada na configuração CpuAffinityMask. Há algo a respeito dela em http://www.janus-software.com/fbmanual/manual.php?book=admintopic=8 []'s Dirlei. Em Qui, 2010-04-29 às 00:10 -0300, Yahoo escreveu: Verifiquei que em computadores com multiprocessadores, o Firebird só usa um núcleo do processador quando acessa o banco de dados. Dessa forma a performance do servidor não é totalmente aproveitada. Como fazer para que o firebird use todos os núcleos do processador? Existe alguma versão especial, alguma configuração ou modo diferente de fazer a instalação do Firebird para isso?
Re: [delphi-br] URGENTE: Problema com Exceções
Se uma exceção acontece dentro de um bloco try..except, por padrão ela será capturada pelo Debugger e exibida dentro da IDE. No Debugger Options do Delphi7 há um configuração Stop On Delphi Exceptions que desabilita esse comportamento. Deve haver algo equivalente no lazarus. Dirlei. Em Ter, 2010-04-27 às 19:49 -0300, Paulo César escreveu: Pessoal, Uso o Lazarus e desenvolvi o seguinte código: procedure TForm1.Button1Click(Sender: TObject); begin try Edit3.text:=floattostr(strtofloat(edit1.text)/strtofloat(edit2.text)); except on E:Exception do begin ShowMessage(E.message); end; end; end; Quando ele executa, ele dá o seguinte erro: project1.exe raised exception class 'External: SIGFPE' Porém, se eu executo ele pelo .exe, ele não causa o erro. Quem pode ajudar? É urgente pessoal!!! Abraços, Atenciosamente, Paulo César de Oliveira,
Re: [delphi-br] OFF TOPIC-Multiprocessamento com Firebird
Dê uma olhada na configuração CpuAffinityMask. Há algo a respeito dela em http://www.janus-software.com/fbmanual/manual.php?book=admintopic=8 []'s Dirlei. Em Qui, 2010-04-29 às 00:10 -0300, Yahoo escreveu: Verifiquei que em computadores com multiprocessadores, o Firebird só usa um núcleo do processador quando acessa o banco de dados. Dessa forma a performance do servidor não é totalmente aproveitada. Como fazer para que o firebird use todos os núcleos do processador? Existe alguma versão especial, alguma configuração ou modo diferente de fazer a instalação do Firebird para isso?
