linuxcall-list

[Linuxcall] =?iso-8859-1?Q?RES=3A_=5BLinuxcall=5D_C=F3digo=2E=2E=2E?=

[<AAl...@am...>]

Coders, eu concordo com o André quanto a performance, mas a diferença entre
uma função genérica e outras menores em termos de processamento é muito
pequena. Uma outra solução poderia ser manter as pequenas funções, mas num
arquivo separado (módulo) de maneira que quando precisarmos mudar o formato
do arq. de configuração isso ficar fácil. Não é necessário fazer uma super
função, mas o que fizermos deve ser de fácil manutenção, já que amanhã pode
não sermos que estará dando manutenção ao código. Entre performance e
facilidade de manutenção fico com a segunda.

Coders, mandem suas opiniões, o projeto é grande e tem um futuro enorme se
sair bem feito e isso depende da gente.

[]s


Amauri Albuquerque
Engenheiro de Telecomunicações
Centro de Supervisão e Controle de Rede - CSCR
Americel
329-6811

> ----- Mensagem original -----
> De:		André Casteliano [SMTP:al...@br...]
> Enviada em:		Segunda-feira, 9 de Outubro de 2000 22:15
> Para:		Lista LinuxCall
> Assunto:		[Linuxcall] Código...
> 
> Olá pessoal,
> 
> a coisa apertou aki... tou bastante ocupado mas arrumei um tempinho prá
> dar uma olhada naquele código que o Amauri mandou...
> 
> Bom, ainda não sei realmente se é a melhor solução (aguardo a opinião
> dos demais coders...)... eu tenho a impressão de que funções menores e
> mais específicas seriam mais interessantes do que super-funções... acho
> que o programa se torna mais modular...
> 
> Uma super-função, acabaria sendo genérica demais... dei uma revisada
> naquele código que o Amauri mandou, corrigi uns pequenos bugs, otimizei
> um pouquinho e tou mandando ele agora, em anexo.
> 
> Amauri, eu entendi sua idéia cara. Uma função maior, genérica, e funções
> menores, que chamassem essa função maior e retornassem dados
> específicos. Só não sei se é a melhor solução...
> 
> As funções menores, que mandei da outra vez, podem até ter as mesmas
> rotinas, mas elas seriam usadas em partes diferentes do programa, de
> forma que, acredito eu, aumentaria a performance, mas também aumentaria
> o número de linhas de código a serem revisadas, caso mudássemos o
> formato do arquivo, por exemplo, como vc falou.
> 
> O melhor mesmo é discutirmos isso de forma que a melhor solução seja
> implementada. Afinal, o nosso objetivo é fazer do LinuxCall o MELHOR
> discador que existe (até mesmo se comparado ao de outras plataformas).
> 
> É isso aí... vamos ver a opinião do pessoal,
> 
> []'s
> 
> -- 
> André Casteliano
> Analista de Sistemas - al...@br...
> +---------------------------------------------+
> | Linux User: # 178853	Machine: # 79923      |
> | Linux Heavy User - Powered by Slackware 7.1 |
> | http://www.geocities.com/andre_casteliano/  |
> +---------------------------------------------+
> |        LinuxCall - The Linux Dialer         |
> |      http://linuxcall.sourceforge.net       |
> +---------------------------------------------+ << Arquivo: super.c >> 

[Linuxcall] =?ISO-8859-1?Q?Re=3A_=5BLinuxcall=5D_C=F3digo=2E=2E=2E?=

[Nelson C. de T. F. <nf...@in...>]

Pessoal,

> Coders, eu concordo com o André quanto a performance, mas a diferença entre
> uma função genérica e outras menores em termos de processamento é muito
> pequena.

Até que ponto a performance é um fator importante para um dialer? Se não
for tão crítico, vale mais a pena encarar o programa como um "meio de
comunicação entre humanos", e não somente entre homem-máquina.

> Uma outra solução poderia ser manter as pequenas funções, mas num
> arquivo separado (módulo) de maneira que quando precisarmos mudar o formato
> do arq. de configuração isso ficar fácil. Não é necessário fazer uma super
> função, mas o que fizermos deve ser de fácil manutenção, já que amanhã pode
> não sermos que estará dando manutenção ao código. Entre performance e
> facilidade de manutenção fico com a segunda.

Eu peguei a discussão no meio, mas se eu entendi a questão envolve o uso
de arquivos em formato texto. Porque não usar uma biblioteca em C que
permita usar expressões regulares (tipo Perl)? 

> Coders, mandem suas opiniões, o projeto é grande e tem um futuro enorme se
> sair bem feito e isso depende da gente.

A minha idéia de fazer uma interface baseada no Mozilla/XUL ainda está de
pé, só falta eu arranjar algum tempo. :-)

A propósito, alguém poderia documentar o funcionamento dos scripts, isto
é, listar todos os arquivos que estão sendo usados e a função de cada um
deles? Seria legal descrever com um pouco mais de cuidado o funcionamento
dos scripts mais importantes.

[]s

Nelson

__________________________________________________________________
Nelson Ferraz                           Insite - Solucoes Internet
e-mail: nf...@in...           http://www.insite.com.br/

Re: [Linuxcall] Re: [Linuxcall] =?iso-8859-1?Q?C=F3digo=2E=2E=2E?=

[Alex B. <ne...@za...>]

Nelson Correa de Toledo Ferraz wrote:

> Eu peguei a discussão no meio, mas se eu entendi a questão envolve o uso
> de arquivos em formato texto. Porque não usar uma biblioteca em C que
> permita usar expressões regulares (tipo Perl)?

Seria um otima ideia, ia facilitar bastante pros programadores em C pq
eu já tenho todas as expressoes regulares prontinha.. Ai a
compatibilidade com os scripts seria 10!

> A propósito, alguém poderia documentar o funcionamento dos scripts, isto
> é, listar todos os arquivos que estão sendo usados e a função de cada um
> deles? Seria legal descrever com um pouco mais de cuidado o funcionamento
> dos scripts mais importantes.

OK, pode deixar que eu mando....

-- 
 /------------------------------ \          ____ 
 | Alex Borro - Neo-Linux_Inside |          \   \
 | Faculdade de Engenharia       |    |\   >>\   \>
 | Mecatrônica - UNICAMP         |----| \_____\   \_______
 >-------------------------------<    |   L  I  N  U  X   \
 | Powered By LINUX SLACKWARE 7.1|----|________    _______/
 | Kernel 2.2.16   User: 164956  |            /   /
 | e-mail:  ne...@ya...     |         >>/   />
 \-------------------------------/          /___/
 
The box said "Requeries Windows 9x, Windows NT 4, or better",
  so I installed Linux.

Re: [Linuxcall] Re: [Linuxcall] =?iso-8859-1?Q?C=F3digo=2E=2E=2E?=

[C. <al...@br...>]

Alex Borro wrote:
> 
> Seria um otima ideia, ia facilitar bastante pros programadores em C pq
> eu já tenho todas as expressoes regulares prontinha.. Ai a
> compatibilidade com os scripts seria 10!

Puts... cara, ia ajudar um monte!!!

> > A propósito, alguém poderia documentar o funcionamento dos scripts, isto
> > é, listar todos os arquivos que estão sendo usados e a função de cada um
> > deles? Seria legal descrever com um pouco mais de cuidado o funcionamento
> > dos scripts mais importantes.
> 
> OK, pode deixar que eu mando....

Beleza... valeu Alex... ajudou bastaaaannnteee!

[]'s

-- 
André Casteliano
Analista de Sistemas - al...@br...
+---------------------------------------------+
| Linux User: # 178853	Machine: # 79923      |
| Linux Heavy User - Powered by Slackware 7.1 |
| http://www.geocities.com/andre_casteliano/  |
+---------------------------------------------+
|        LinuxCall - The Linux Dialer         |
|      http://linuxcall.sourceforge.net       |
+---------------------------------------------+

Re: [Linuxcall] Código...

[Marcelo B. <md...@ma...>]

---[ printf("Em ter, 10 out 2000, Nelson Correa de Toledo Ferraz escreveu"); ]---
//  Pessoal,
//  
//  > Coders, eu concordo com o André quanto a performance, mas a diferença entre
//  > uma função genérica e outras menores em termos de processamento é muito
//  > pequena.
//  
//  Até que ponto a performance é um fator importante para um dialer? Se não
//  for tão crítico, vale mais a pena encarar o programa como um "meio de
//  comunicação entre humanos", e não somente entre homem-máquina.

Isso me traz à lembrança aquela vez em que estavamos discutindo e
debugando junto as primeiras implementações em XStep junto com o
André. Eu mesmo cheguei a comentar sobre o uso de listas encadeadas,
mas essas listas são um sac* e vimos que não precisávamos de tanta
complicação, e então foi adotada uma forma mais simples e
'entendível' de implementação.

O processo de discagem já é algo considerávelmente lento em
comparação a um possível ganho de performance que pudesse ser obtido
em virtude de uma forma de implementação ou outra.

//  > Uma outra solução poderia ser manter as pequenas funções, mas num
//  > arquivo separado (módulo) de maneira que quando precisarmos mudar o formato
//  > do arq. de configuração isso ficar fácil. Não é necessário fazer uma super
//  > função, mas o que fizermos deve ser de fácil manutenção, já que amanhã pode
//  > não sermos que estará dando manutenção ao código. Entre performance e
//  > facilidade de manutenção fico com a segunda.

Exatamente. Eu sou totalmente a favor da modularização do projeto. É
muito viável reunir grupos de funções com finalidades específicas em
arquivos .c separados, e mesmo os includes dependendo do caso.

Eu antes me embananava todo pra trabalhar dessa forma, com vários
arquivos separados e coisa e tal. Mas uma vez que se pegue o costume,
basta partir de um makefile inicial e seguir atualizando-o que tudo
vai sem problemas.

Principalmente num projeto como esse, feito a várias mãos, isso é
importantíssimo, pois facilita em muito o desenvolvimento e
administração do código.

//  Eu peguei a discussão no meio, mas se eu entendi a questão envolve o uso
//  de arquivos em formato texto. Porque não usar uma biblioteca em C que
//  permita usar expressões regulares (tipo Perl)? 

Opa, idéia interessante.
Eu não trabalhei com isso ainda. Nelson, você conhece alguma
biblioteca em C desse tipo? Se você puder comentar algo mais a
respeito seria muito bom.

//  > Coders, mandem suas opiniões, o projeto é grande e tem um futuro enorme se
//  > sair bem feito e isso depende da gente.
//  
//  A minha idéia de fazer uma interface baseada no Mozilla/XUL ainda está de
//  pé, só falta eu arranjar algum tempo. :-)

O linux e suas infinitas possibilidades, isso é sensacional.
LinuxCall em bash script, C, XStep, GTK, Mozilla/XUL...

Quanto a falta de tempo, putz, é fogo...

Às vezes eu me pergunto por que o comando
$ grep DIA tempo.h

retorna...

#define DIA  24*HORA

Ah se eu pudesse mudar isso... :)

//  A propósito, alguém poderia documentar o funcionamento dos
scripts, isto //  é, listar todos os arquivos que estão sendo usados
e a função de cada um //  deles? Seria legal descrever com um pouco
mais de cuidado o funcionamento //  dos scripts mais importantes.

Taí uma coisa que tem que ser feita mesmo...

Recentemente andei lendo alguma coisa sobre sed e no trampo vou ter
que começar a mexer muito com scripts, então unindo o útero ao
agradável, seria interessante para mim aprender mais de sed, e como
os scripts do Alex estão recheados dele (sed é powered!) talvez eu
possa dar uma mão nesse sentido. 

Infelizmente ando meio ruinzão de saúde ultimamente, os últimos 5
dias foi só chegar em casa e cair na cama por que não tava guentando
mesmo. Eu já queria estar com umas funções de tratamento de modem
prontas pra mandar pra vocês mas infelizmente não deu. Mas assim que
eu melhorar boto isso no ar. Aproveitando o embalo,
relacionem ai o que vocês precisam relacionado a isso, ok? Por
enquanto, já estou prevendo as seguintes funcionalidades:

* Enviar string de reset e/ou inicialização para o modem;
* Envio dos ATI's e tratamento do retorno dos mesmos;
* Função para varrer as seriais em busca de um possível modem; Nesse
caso em específico, a busca de modens 'de verdade' nas portas padrões
(ttyS0 a ttyS3) me parece sem problemas, mas eu nunca usei winmodens,
então se vocês tiverem algo a comentar sobre isso, possíveis
diferenças, portas utilizadas, etc, seria bom.


Bom, por enquanto é isso ai.

Um grande abraço a todos,

-- 
Marcelo D. Beckmann - Linux User #173935
md...@ma... - UIN 53189692
http://marcelobeckmann.cjb.net
 .~.   233MMX 32MB 8.4+3.2GB Quantum Fireball
 /V\   OPL3SAx TGUI9680 2MB 33600 CL5 2.2.14 + Slack7 2.2.13
/(.)\ "Estamos de volta aos tempos em que os homens eram homens
^`~´^  e programavam seus próprios drivers de dispositivo." L.T.