From felipe em felipeoliva.eti.br  Fri Dec 12 06:36:16 2014
From: felipe em felipeoliva.eti.br (Felipe N. Oliva)
Date: Fri, 12 Dec 2014 12:36:16 -0200
Subject: [Cascavel-pm] Perl para sistemas embarcados
Message-ID: <548AFD60.1060402@felipeoliva.eti.br>

Olá senhores,

Esta é minha primeira postagem aqui na lista, e peço a paciência de 
todos em caso de falar alguma bobagem.

Estou em meio a um projeto de sistema embarcado onde meu foco é deixar o 
sistema o menor possível. Meu problema é que o Perl ocupa um espaço 
relativamente alto (para uma aplicação embarcada).

Alguém poderia me dar uma dica de como reduzir o seu tamanho e do Perl 
em si e seus módulos?

Att,
Felipe N. Oliva

From dan.vinciguerra em gmail.com  Fri Dec 12 07:32:11 2014
From: dan.vinciguerra em gmail.com (Daniel Vinciguerra)
Date: Fri, 12 Dec 2014 13:32:11 -0200
Subject: [Cascavel-pm] Perl para sistemas embarcados
In-Reply-To: <548AFD60.1060402@felipeoliva.eti.br>
References: <548AFD60.1060402@felipeoliva.eti.br>
Message-ID: <CADoJa-GWV3rTUNDYM0J35Rqd=JxNnf4ZLiXJ9FVa2LH=yeyo3Q@mail.gmail.com>

Pra responder isso provavelmente o pessoal vai querer saber um pouco mais
sobre seu cenário.

Com embarcado e pelo que você disse, esta desenvolvendo um projeto de
software que rodará em um SO embarcado, seja Linux, Android, Windows CE,
whatever...

Tendo isso em mente, certamente você tenha recursos de hardware limitados
(memória, processamento e storage) e precise que seu software não seja um
"espaçoso".

É isso mesmo com o que você esta lidando!?


best,


*Daniel Vinciguerra (@dvinciguerra)*
Web solution architect, perl dev, vegetarian, geek and co-founder at *Bivee*
bivee.com.br  -  github.com/Bivee

2014-12-12 12:36 GMT-02:00 Felipe N. Oliva <felipe em felipeoliva.eti.br>:

> Olá senhores,
>
> Esta é minha primeira postagem aqui na lista, e peço a paciência de todos
> em caso de falar alguma bobagem.
>
> Estou em meio a um projeto de sistema embarcado onde meu foco é deixar o
> sistema o menor possível. Meu problema é que o Perl ocupa um espaço
> relativamente alto (para uma aplicação embarcada).
>
> Alguém poderia me dar uma dica de como reduzir o seu tamanho e do Perl em
> si e seus módulos?
>
> Att,
> Felipe N. Oliva
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/cascavel-pm/attachments/20141212/aa82f980/attachment.html>

From felipe em felipeoliva.eti.br  Fri Dec 12 07:51:03 2014
From: felipe em felipeoliva.eti.br (Felipe N. Oliva)
Date: Fri, 12 Dec 2014 13:51:03 -0200
Subject: [Cascavel-pm] Perl para sistemas embarcados
In-Reply-To: <CADoJa-GWV3rTUNDYM0J35Rqd=JxNnf4ZLiXJ9FVa2LH=yeyo3Q@mail.gmail.com>
References: <548AFD60.1060402@felipeoliva.eti.br>
	<CADoJa-GWV3rTUNDYM0J35Rqd=JxNnf4ZLiXJ9FVa2LH=yeyo3Q@mail.gmail.com>
Message-ID: <548B0EE7.8060900@felipeoliva.eti.br>


On 12/12/2014 13:32, Daniel Vinciguerra wrote:
> Pra responder isso provavelmente o pessoal vai querer saber um pouco 
> mais sobre seu cenário.
>
> Com embarcado e pelo que você disse, esta desenvolvendo um projeto de 
> software que rodará em um SO embarcado, seja Linux, Android, Windows 
> CE, whatever...
>
> Tendo isso em mente, certamente você tenha recursos de hardware 
> limitados (memória, processamento e storage) e precise que seu 
> software não seja um "espaçoso".
>
> É isso mesmo com o que você esta lidando!?
>
>
> best,
>
> *
> Daniel Vinciguerra (@dvinciguerra)*
> Web solution architect, perl dev, vegetarian, geek and co-founder at 
> *Bivee*
> bivee.com.br <http://bivee.com.br> - github.com/Bivee 
> <https://github.com/Bivee>
>
> 2014-12-12 12:36 GMT-02:00 Felipe N. Oliva <felipe em felipeoliva.eti.br 
> <mailto:felipe em felipeoliva.eti.br>>:
>
>     Olá senhores,
>
>     Esta é minha primeira postagem aqui na lista, e peço a paciência
>     de todos em caso de falar alguma bobagem.
>
>     Estou em meio a um projeto de sistema embarcado onde meu foco é
>     deixar o sistema o menor possível. Meu problema é que o Perl ocupa
>     um espaço relativamente alto (para uma aplicação embarcada).
>
>     Alguém poderia me dar uma dica de como reduzir o seu tamanho e do
>     Perl em si e seus módulos?
>
>     Att,
>     Felipe N. Oliva
>     _______________________________________________
>     Cascavel-pm mailing list
>     Cascavel-pm em pm.org <mailto:Cascavel-pm em pm.org>
>     http://mail.pm.org/mailman/listinfo/cascavel-pm
>
>
>
>
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
Sim Daniel, vamos lá.

- Sistema operacional baseado em FreeBSD;
- Arquitetura: x86_64;
- Disco: atualmente ocupa 45MB(pendrive, HDD ou SSD);
- Memória RAM: a partir de 512MB;

Preciso exatamente que meu Sistema operacional por completo não seja um 
"espaçoso".

Att,
Felipe N. Oliva
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/cascavel-pm/attachments/20141212/05d15a34/attachment.html>

From breno em rio.pm.org  Fri Dec 12 07:53:44 2014
From: breno em rio.pm.org (breno)
Date: Fri, 12 Dec 2014 13:53:44 -0200
Subject: [Cascavel-pm] Perl para sistemas embarcados
In-Reply-To: <548AFD60.1060402@felipeoliva.eti.br>
References: <548AFD60.1060402@felipeoliva.eti.br>
Message-ID: <CAHS-WQawe_sONhW6YpHTxRWtMiSMza83EXAwrcQCwNUjux-Cow@mail.gmail.com>

Oi Felipe,

Parabéns pela primeira mensagem! Tomara que seja a primeira de muitas (e
não deixe de entrar nos outros grupos também, como Brasil-PM ou as
regionais de sua escolha - a menos que vc seja de Cascavel, claro :D)

Sobre a sua pergunta, depende de um monte de fatores. Perl, assim como
todas as linguagens dinâmicas, é feito para poupar seu tempo e preocupação
em relação a alocação de memória, interrupções, rotinas, etc. Naturalmente,
isso vem com um preço, em velocidade e em tamanho - tanto em disco quanto
em memória.

Para mim, se você não está disposto a pagar esse preço, a primeira pergunta
que você tem que fazer é: Perl é a melhor linguagem para esse problema? Ou
melhor: linguagens dinâmicas são o melhor tipo de linguagem para esse
problema? Se a resposta for "não", escreva seu código em C, Lua ou mesmo
Assembly, e vc certamente conseguirá chegar a um binário muito menor.
Obviamente, nesse caso o preço a pagar é o tempo de desenvolvimento e o
cuidado necessário com alocação de espaço, tratamento de erros, manipulação
de variáveis, etc.

Você diz que o programa em Perl (e o perl em si) ocupam muito espaço para
uma app embarcada. De quanto estamos falando? Quanto seria bom o
suficiente? De repente rola de chegar a esse número. De repente não.

Dito isso, se vc realmente quer diminuir o espaço ocupado em disco, há
algumas coisas que você pode tentar:

* http://perldoc.perl.org/perlembed.html - aqui vc encontra dicas para
rodar código Perl a partir de um programa em C. Como a compilação inclui só
as libs necessárias, de repente o resultado fica menor para a app
embarcada. Obviamente, o resultado pode ser oposto, mas aí vc vai ter que
testar;

* Você não precisa de documentação para executar código, então pode
"minificar" os arquivos .pm e .pl na hora de embarcar o código. O espaço em
memória será o mesmo, mas em disco, será menor;

* Analogamente, se vc tem certeza do que será utilizado e de todas as
possíveis ramificações do seu código, pode arrancar fora subs que com
certeza nunca serão chamadas. Eu só faria isso em último caso, e com
cobertura de 100% em testes de ramificação;

* Você pode também analizar a sua árvore de dependência e ajustá-la para
usar versões alternativas e menores de determinados módulos. Por exemplo,
usar código XS em vez de PP, módulos ::Tiny em vez da versão completa, Moo
em vez de Moose. Em alguns casos você consegue até fazer um overhaul no
módulo e diminuir as dependências na mão (por exemplo, criar as classes
diretamente e na mão em vez de usar um framework.

* Existem alternativas que "zipam" o código e descompactam em memória na
hora de executar. Acho que o PAR faz isso, mas não uso há tanto tempo que
não sei te dizer;

* Algumas ferramentas como o "strip" (
https://en.wikipedia.org/wiki/Strip_%28Unix%29) podem reduzir o tamanho do
binário final arrancando trechos não utilizados;

* você pode tentar compilar o perl manualmente usando compiladores
diferentes (por exemplo, clang ou gcc) e flags de compilação diferentes,
comparar o resultado final e escolher o que ficou menor. As vezes os
resultados são bem significativos. Aproveite pra ler o script de
configuração do fonte do perl para desativar coisas que sabe que não vai
utilizar e que vem ativas por padrão, a diferença no tamanho do binário e
libs associadas pode ser significativa para o seu problema.

Só não esqueça que cada sugestão acima vem com um preço. Algumas vão exigir
mais CPU. Outras, mais memória. Outras, mais trabalho na hora de fazer
deploys. Outras tornam atualizações de módulos externos bem mais difíceis.
Outras exigem muito mais lógica na hora de estruturar seu programa.
Outras... acho que vc entendeu :)

Enfim, é isso. Boa sorte! :)

[]s

-b


2014-12-12 12:36 GMT-02:00 Felipe N. Oliva <felipe em felipeoliva.eti.br>:

> Olá senhores,
>
> Esta é minha primeira postagem aqui na lista, e peço a paciência de todos
> em caso de falar alguma bobagem.
>
> Estou em meio a um projeto de sistema embarcado onde meu foco é deixar o
> sistema o menor possível. Meu problema é que o Perl ocupa um espaço
> relativamente alto (para uma aplicação embarcada).
>
> Alguém poderia me dar uma dica de como reduzir o seu tamanho e do Perl em
> si e seus módulos?
>
> Att,
> Felipe N. Oliva
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/cascavel-pm/attachments/20141212/8804527d/attachment-0001.html>

From blabos em gmail.com  Fri Dec 12 08:13:53 2014
From: blabos em gmail.com (Blabos de Blebe)
Date: Fri, 12 Dec 2014 14:13:53 -0200
Subject: [Cascavel-pm] Perl para sistemas embarcados
In-Reply-To: <CAHS-WQawe_sONhW6YpHTxRWtMiSMza83EXAwrcQCwNUjux-Cow@mail.gmail.com>
References: <548AFD60.1060402@felipeoliva.eti.br>
	<CAHS-WQawe_sONhW6YpHTxRWtMiSMza83EXAwrcQCwNUjux-Cow@mail.gmail.com>
Message-ID: <CAAxpsiaGfhX0bd4gi_2JyzD+7R6tr=iAKBeH5i+UQa+q7O2HkA@mail.gmail.com>

Opa,

O que eu teria a dizer o breno já disse, mas reforçando, tudo depende do
que você tem disponível e do que/quanto está disposto a pagar por isso.

Em termos de embarcados*, linguagem como Perl, Python, etc não são
indicadas, justamente por ocuparem mais memória e terem uma performance um
pouco menor em geral.

Ter menos performance aqui significa gastar mais tempo e energia pra
realizar operações equivalentes. Dependendo da aplicação, tempo pode não
ser um problema, mas o consumo extra de bateria sim.

Normalmente, linguagens de mais alto nível pagam esses recursos em troca do
recurso "tempo do programador", ou seja, possibilitam que o desenvolvedor
crie código num nível muito mais alto de abstração num ambiente onde ele
tem tempo, memória e energia em grande escala.

Note porém que dependendo de alguns detalhes, como o domínio da aplicação,
se usa XS ou não, etc, pode ser que a aplicação em Perl nem fique com menos
performance, se o gargalo ficar por exemplo na taxa de transmissão do seu
rádio.

A questão sempre é sobre o que você é obrigado a abrir mão versus o que
você pode ou não abrir mão.

Para 99% dos casos, Perl não vai ser indicado para embarcados. Se você
estiver trabalhando nos outros 1%, dê mais detalhes, que vai ser
extremamente interessante ajudar.

***

Antigamente tinha isso aqui:

http://www.foo.be/docs/tpj/issues/vol5_3/tpj0503-0003.html

Mas creio que foi descontinuado nas versões recentes de Perl. A referência
me fugiu à memória, mas acredito ter lido que foi descontinuado em algum
release note recente.

***

Também existe isso aqui:

https://metacpan.org/pod/distribution/B-C/perlcompile.pod

***

*: O conceito de embarcados hoje é meio difuso mas normalmente contamos
situações onde os recursos são tão limitados que não há nem sistema
operacional rodando, quanto mais uma linguagem dinâmica disponível.

[]'s

2014-12-12 13:53 GMT-02:00 breno <breno em rio.pm.org>:
>
> Oi Felipe,
>
> Parabéns pela primeira mensagem! Tomara que seja a primeira de muitas (e
> não deixe de entrar nos outros grupos também, como Brasil-PM ou as
> regionais de sua escolha - a menos que vc seja de Cascavel, claro :D)
>
> Sobre a sua pergunta, depende de um monte de fatores. Perl, assim como
> todas as linguagens dinâmicas, é feito para poupar seu tempo e preocupação
> em relação a alocação de memória, interrupções, rotinas, etc. Naturalmente,
> isso vem com um preço, em velocidade e em tamanho - tanto em disco quanto
> em memória.
>
> Para mim, se você não está disposto a pagar esse preço, a primeira
> pergunta que você tem que fazer é: Perl é a melhor linguagem para esse
> problema? Ou melhor: linguagens dinâmicas são o melhor tipo de linguagem
> para esse problema? Se a resposta for "não", escreva seu código em C, Lua
> ou mesmo Assembly, e vc certamente conseguirá chegar a um binário muito
> menor. Obviamente, nesse caso o preço a pagar é o tempo de desenvolvimento
> e o cuidado necessário com alocação de espaço, tratamento de erros,
> manipulação de variáveis, etc.
>
> Você diz que o programa em Perl (e o perl em si) ocupam muito espaço para
> uma app embarcada. De quanto estamos falando? Quanto seria bom o
> suficiente? De repente rola de chegar a esse número. De repente não.
>
> Dito isso, se vc realmente quer diminuir o espaço ocupado em disco, há
> algumas coisas que você pode tentar:
>
> * http://perldoc.perl.org/perlembed.html - aqui vc encontra dicas para
> rodar código Perl a partir de um programa em C. Como a compilação inclui só
> as libs necessárias, de repente o resultado fica menor para a app
> embarcada. Obviamente, o resultado pode ser oposto, mas aí vc vai ter que
> testar;
>
> * Você não precisa de documentação para executar código, então pode
> "minificar" os arquivos .pm e .pl na hora de embarcar o código. O espaço em
> memória será o mesmo, mas em disco, será menor;
>
> * Analogamente, se vc tem certeza do que será utilizado e de todas as
> possíveis ramificações do seu código, pode arrancar fora subs que com
> certeza nunca serão chamadas. Eu só faria isso em último caso, e com
> cobertura de 100% em testes de ramificação;
>
> * Você pode também analizar a sua árvore de dependência e ajustá-la para
> usar versões alternativas e menores de determinados módulos. Por exemplo,
> usar código XS em vez de PP, módulos ::Tiny em vez da versão completa, Moo
> em vez de Moose. Em alguns casos você consegue até fazer um overhaul no
> módulo e diminuir as dependências na mão (por exemplo, criar as classes
> diretamente e na mão em vez de usar um framework.
>
> * Existem alternativas que "zipam" o código e descompactam em memória na
> hora de executar. Acho que o PAR faz isso, mas não uso há tanto tempo que
> não sei te dizer;
>
> * Algumas ferramentas como o "strip" (
> https://en.wikipedia.org/wiki/Strip_%28Unix%29) podem reduzir o tamanho
> do binário final arrancando trechos não utilizados;
>
> * você pode tentar compilar o perl manualmente usando compiladores
> diferentes (por exemplo, clang ou gcc) e flags de compilação diferentes,
> comparar o resultado final e escolher o que ficou menor. As vezes os
> resultados são bem significativos. Aproveite pra ler o script de
> configuração do fonte do perl para desativar coisas que sabe que não vai
> utilizar e que vem ativas por padrão, a diferença no tamanho do binário e
> libs associadas pode ser significativa para o seu problema.
>
> Só não esqueça que cada sugestão acima vem com um preço. Algumas vão
> exigir mais CPU. Outras, mais memória. Outras, mais trabalho na hora de
> fazer deploys. Outras tornam atualizações de módulos externos bem mais
> difíceis. Outras exigem muito mais lógica na hora de estruturar seu
> programa. Outras... acho que vc entendeu :)
>
> Enfim, é isso. Boa sorte! :)
>
> []s
>
> -b
>
>
> 2014-12-12 12:36 GMT-02:00 Felipe N. Oliva <felipe em felipeoliva.eti.br>:
>
>> Olá senhores,
>>
>>
>> Esta é minha primeira postagem aqui na lista, e peço a paciência de todos
>> em caso de falar alguma bobagem.
>>
>> Estou em meio a um projeto de sistema embarcado onde meu foco é deixar o
>> sistema o menor possível. Meu problema é que o Perl ocupa um espaço
>> relativamente alto (para uma aplicação embarcada).
>>
>> Alguém poderia me dar uma dica de como reduzir o seu tamanho e do Perl em
>> si e seus módulos?
>>
>> Att,
>> Felipe N. Oliva
>> _______________________________________________
>> Cascavel-pm mailing list
>> Cascavel-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/cascavel-pm
>>
>
>
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/cascavel-pm/attachments/20141212/de019a46/attachment.html>

From felipe em felipeoliva.eti.br  Fri Dec 12 09:18:37 2014
From: felipe em felipeoliva.eti.br (Felipe N. Oliva)
Date: Fri, 12 Dec 2014 15:18:37 -0200
Subject: [Cascavel-pm] Perl para sistemas embarcados
In-Reply-To: <CAAxpsiaGfhX0bd4gi_2JyzD+7R6tr=iAKBeH5i+UQa+q7O2HkA@mail.gmail.com>
References: <548AFD60.1060402@felipeoliva.eti.br>	<CAHS-WQawe_sONhW6YpHTxRWtMiSMza83EXAwrcQCwNUjux-Cow@mail.gmail.com>
	<CAAxpsiaGfhX0bd4gi_2JyzD+7R6tr=iAKBeH5i+UQa+q7O2HkA@mail.gmail.com>
Message-ID: <548B236D.1010005@felipeoliva.eti.br>


On 12/12/2014 14:13, Blabos de Blebe wrote:
> Opa,
>
> O que eu teria a dizer o breno já disse, mas reforçando, tudo depende 
> do que você tem disponível e do que/quanto está disposto a pagar por isso.
>
> Em termos de embarcados*, linguagem como Perl, Python, etc não são 
> indicadas, justamente por ocuparem mais memória e terem uma 
> performance um pouco menor em geral.
>
> Ter menos performance aqui significa gastar mais tempo e energia pra 
> realizar operações equivalentes. Dependendo da aplicação, tempo pode 
> não ser um problema, mas o consumo extra de bateria sim.
>
> Normalmente, linguagens de mais alto nível pagam esses recursos em 
> troca do recurso "tempo do programador", ou seja, possibilitam que o 
> desenvolvedor crie código num nível muito mais alto de abstração num 
> ambiente onde ele tem tempo, memória e energia em grande escala.
>
> Note porém que dependendo de alguns detalhes, como o domínio da 
> aplicação, se usa XS ou não, etc, pode ser que a aplicação em Perl nem 
> fique com menos performance, se o gargalo ficar por exemplo na taxa de 
> transmissão do seu rádio.
>
> A questão sempre é sobre o que você é obrigado a abrir mão versus o 
> que você pode ou não abrir mão.
>
> Para 99% dos casos, Perl não vai ser indicado para embarcados. Se você 
> estiver trabalhando nos outros 1%, dê mais detalhes, que vai ser 
> extremamente interessante ajudar.
>
> ***
>
> Antigamente tinha isso aqui:
>
> http://www.foo.be/docs/tpj/issues/vol5_3/tpj0503-0003.html
>
> Mas creio que foi descontinuado nas versões recentes de Perl. A 
> referência me fugiu à memória, mas acredito ter lido que foi 
> descontinuado em algum release note recente.
>
> ***
>
> Também existe isso aqui:
>
> https://metacpan.org/pod/distribution/B-C/perlcompile.pod
>
> ***
>
> *: O conceito de embarcados hoje é meio difuso mas normalmente 
> contamos situações onde os recursos são tão limitados que não há nem 
> sistema operacional rodando, quanto mais uma linguagem dinâmica 
> disponível.
>
> []'s
>
> 2014-12-12 13:53 GMT-02:00 breno <breno em rio.pm.org 
> <mailto:breno em rio.pm.org>>:
>
>     Oi Felipe,
>
>     Parabéns pela primeira mensagem! Tomara que seja a primeira de
>     muitas (e não deixe de entrar nos outros grupos também, como
>     Brasil-PM ou as regionais de sua escolha - a menos que vc seja de
>     Cascavel, claro :D)
>
>     Sobre a sua pergunta, depende de um monte de fatores. Perl, assim
>     como todas as linguagens dinâmicas, é feito para poupar seu tempo
>     e preocupação em relação a alocação de memória, interrupções,
>     rotinas, etc. Naturalmente, isso vem com um preço, em velocidade e
>     em tamanho - tanto em disco quanto em memória.
>
>     Para mim, se você não está disposto a pagar esse preço, a primeira
>     pergunta que você tem que fazer é: Perl é a melhor linguagem para
>     esse problema? Ou melhor: linguagens dinâmicas são o melhor tipo
>     de linguagem para esse problema? Se a resposta for "não", escreva
>     seu código em C, Lua ou mesmo Assembly, e vc certamente conseguirá
>     chegar a um binário muito menor. Obviamente, nesse caso o preço a
>     pagar é o tempo de desenvolvimento e o cuidado necessário com
>     alocação de espaço, tratamento de erros, manipulação de variáveis,
>     etc.
>
>     Você diz que o programa em Perl (e o perl em si) ocupam muito
>     espaço para uma app embarcada. De quanto estamos falando? Quanto
>     seria bom o suficiente? De repente rola de chegar a esse número.
>     De repente não.
>
>     Dito isso, se vc realmente quer diminuir o espaço ocupado em
>     disco, há algumas coisas que você pode tentar:
>
>     * http://perldoc.perl.org/perlembed.html - aqui vc encontra dicas
>     para rodar código Perl a partir de um programa em C. Como a
>     compilação inclui só as libs necessárias, de repente o resultado
>     fica menor para a app embarcada. Obviamente, o resultado pode ser
>     oposto, mas aí vc vai ter que testar;
>
>     * Você não precisa de documentação para executar código, então
>     pode "minificar" os arquivos .pm e .pl na hora de embarcar o
>     código. O espaço em memória será o mesmo, mas em disco, será menor;
>
>     * Analogamente, se vc tem certeza do que será utilizado e de todas
>     as possíveis ramificações do seu código, pode arrancar fora subs
>     que com certeza nunca serão chamadas. Eu só faria isso em último
>     caso, e com cobertura de 100% em testes de ramificação;
>
>     * Você pode também analizar a sua árvore de dependência e
>     ajustá-la para usar versões alternativas e menores de determinados
>     módulos. Por exemplo, usar código XS em vez de PP, módulos ::Tiny
>     em vez da versão completa, Moo em vez de Moose. Em alguns casos
>     você consegue até fazer um overhaul no módulo e diminuir as
>     dependências na mão (por exemplo, criar as classes diretamente e
>     na mão em vez de usar um framework.
>
>     * Existem alternativas que "zipam" o código e descompactam em
>     memória na hora de executar. Acho que o PAR faz isso, mas não uso
>     há tanto tempo que não sei te dizer;
>
>     * Algumas ferramentas como o "strip"
>     (https://en.wikipedia.org/wiki/Strip_%28Unix%29) podem reduzir o
>     tamanho do binário final arrancando trechos não utilizados;
>
>     * você pode tentar compilar o perl manualmente usando compiladores
>     diferentes (por exemplo, clang ou gcc) e flags de compilação
>     diferentes, comparar o resultado final e escolher o que ficou
>     menor. As vezes os resultados são bem significativos. Aproveite
>     pra ler o script de configuração do fonte do perl para desativar
>     coisas que sabe que não vai utilizar e que vem ativas por padrão,
>     a diferença no tamanho do binário e libs associadas pode ser
>     significativa para o seu problema.
>
>     Só não esqueça que cada sugestão acima vem com um preço. Algumas
>     vão exigir mais CPU. Outras, mais memória. Outras, mais trabalho
>     na hora de fazer deploys. Outras tornam atualizações de módulos
>     externos bem mais difíceis. Outras exigem muito mais lógica na
>     hora de estruturar seu programa. Outras... acho que vc entendeu :)
>
>     Enfim, é isso. Boa sorte! :)
>
>     []s
>
>     -b
>
>
>     2014-12-12 12:36 GMT-02:00 Felipe N. Oliva
>     <felipe em felipeoliva.eti.br <mailto:felipe em felipeoliva.eti.br>>:
>
>         Olá senhores,
>
>
>         Esta é minha primeira postagem aqui na lista, e peço a
>         paciência de todos em caso de falar alguma bobagem.
>
>         Estou em meio a um projeto de sistema embarcado onde meu foco
>         é deixar o sistema o menor possível. Meu problema é que o Perl
>         ocupa um espaço relativamente alto (para uma aplicação embarcada).
>
>         Alguém poderia me dar uma dica de como reduzir o seu tamanho e
>         do Perl em si e seus módulos?
>
>         Att,
>         Felipe N. Oliva
>         _______________________________________________
>         Cascavel-pm mailing list
>         Cascavel-pm em pm.org <mailto:Cascavel-pm em pm.org>
>         http://mail.pm.org/mailman/listinfo/cascavel-pm
>
>
>
>     _______________________________________________
>     Cascavel-pm mailing list
>     Cascavel-pm em pm.org <mailto:Cascavel-pm em pm.org>
>     http://mail.pm.org/mailman/listinfo/cascavel-pm
>
>
>
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
Obrigado pelos retornos.

Não sou um expert em Perl. Cheguei até o Perl pela facilidade, 
documentação e os vários módulos.

O papel do Perl no meu sistema é automação de processos, como: backup, 
checagens e etc;

A questão do espaço que tenho esbarrado são os modulos, libs, etc... não 
o aplicativo em si, exemplo backup.pl

Se eu estiver viajando podem falar, mas meu mundo perfeito é um deixar o 
aplicativo compilado somente com suas dependências.

Ainda acredito que consigo usa-lo, só me falta conseguir otimizar essa 
questão do espaço.

Talvez também vou utiliza-lo para Interface WEB e Sockets, mas isso 
ainda é um "talvez".

Att,
Felipe N. Oliva
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/cascavel-pm/attachments/20141212/65e18cf6/attachment-0001.html>

From breno em rio.pm.org  Sat Dec 13 07:12:15 2014
From: breno em rio.pm.org (breno)
Date: Sat, 13 Dec 2014 13:12:15 -0200
Subject: [Cascavel-pm] mod_perl
In-Reply-To: <AB3356A7D13B40CD9B0B121DDC100A72@payback.servehttp.com>
References: <AB3356A7D13B40CD9B0B121DDC100A72@payback.servehttp.com>
Message-ID: <CAHS-WQZXFR3j3AC5U8kYq3KTNW-AWruwo=5rh10pjnhQNRS0UA@mail.gmail.com>

Oi Kleber,

desculpa não ter respondido antes, só vi o email agora :(

Ainda está com problemas para carregar funções? O mod_perl é uma ferramenta
poderosa mas um tanto confusa mesmo - por essas e outras que o
desenvolvimento Perl moderno para web foge dessas implementações e prefere
soluções como PSGI.

Pela sua mensagem, parece que o mod_perl está tendo dificuldades em
encontrar a função "grava_conf" criada pelo seu código. Estou supondo que
ela é criada e importada ao carregar o arquivo "c:\payback\dosbox.plx", mas
é só achismo meu - me corrija se estiver errado!

Se é esse o caso, o cache do mod_perl pode estar se perdendo. Ele compila
uma vez, grava no namespace ModPerl::ROOT::ModPerl::Registry:::blablabla, e
esquece. Na hora que você executa em outro script, ele ve que o arquivo já
está compilado em memória e pula, mas como o seu arquivo atual foi gravado
em *outro* namespace do mod_perl, ele não acha a função.

Uma solução rápida para você é descobrir em que módulo a função
"grava_conf" é definida e chamar ela com o full namespace em vez de apenas
como "grava_conf()". Por exemplo, suponha que ela tenha sido definida no
módulo Payback::Utils:

---------8<---------
package Payback::Utils;
use strict;
use warnings;

sub grava_conf {
    ...
}

1;
--------->8---------

Daí, nos lugares onde você usa, em vez de dizer:


require 'c:\\payback\\dosbox.plx';
grava_conf($conf,$prog);


Você tem que dizer:

require 'c:\\payback\\dosbox.plx';
Payback::Utils::grava_conf($conf,$prog);

Isso deve resolver o seu problema de função não encontrada dentro do
mod_perl (espero!)


Dito isso, acho importante citar que, na maioria dos casos, ter "require"
escrito assim não é uma boa prática hoje em dia. Há vários motivos para
isso (além do problema que você já está experimentando): a dependência via
"require" é avaliada durante o tempo de execução, não de compilação,
deixando a execução do seu programa potencialmente mais lenta; o "require"
exige o caminho do arquivo no sistema de arquivos em vez de abstrair isso
pra você e acaba deixando o seu código menos portátil - imagine ter que
rodar seu código Windows em um Linux, você vai ter que mudar o "c:\" e as
barras em tudo! Mesmo no Windows, imagine ter que botar seu programa em
outro diretório? Finalmente, o require estimula carregar scripts ".pl"
quando a boa prática de hoje sugere que você separe seu programa
logicamente em módulos, facilitando a reutilização de código, a
identificação de erros e a manutenção do seu programa. Ou seja, em vez de
'c:\\payback\\dosbox.plx',você teria um arquivo (por exemplo)
"lib/Dosbox.pm" com:

---------8<---------
package Dosbox;
use strict;
use warnings;

# funcoes do dosbox.plx

1;
--------->8---------

e em vez de chamar como:

 require 'c:\\payback\\dosbox.plx';

você colocaria um:

use Dosbox;

no topo do seu código.

Idealmente, o código dentro do script "c:\\payback\dosbox.plx" seria
refatorado em módulo(s) com namespace(s) significativo(s). Mesmo deixar
tudo desse arquivo junto em um grande "Dosbox.pm" já seria potencialmente
benéfico. Se o script de antes não apenas definia funções mas também
executava algum código, declarava variáveis, etc, você pode iniciar o
refactoring colocando todo o código dentro de uma grande sub e ir separando
aos poucos. Isso é particularmente importante se você tem muitas variáveis
"my" e está em ambiente mod_perl, já que o comportamento do mod_perl pode
tornar o conteúdo delas inesperado.

Espero ter ajudado! E desculpe novamente pela demora.

[]s

-b



On Sun, Nov 30, 2014 at 5:33 PM, kleber <payback em oi.com.br> wrote:
>
> Olá Srs  ,
>
> Instalei o mod_perl no meu computador sendo que ao iniciá-lo recebo a
> seguinte mensagem :
>
> [Sun Nov 30 09:29:28 2014] [notice] Apache/2.2.22 (Win32) PHP/5.2.8
> mod_apreq2-20090110/2.8.0 mod_perl/2.0.7 Perl/v5.16.3 configured --
> resuming normal operations
>
> Utilizei a seguinte configuração no apache :
>
> PerlModule ModPerl::RegistryBB
> <Files ~ "\.plx$">
>  SetHandler perl-script
>  PerlResponseHandler ModPerl::RegistryBB::handler
>  PerlOptions +ParseHeaders
>  Options -Indexes MultiViews FollowSymLinks +ExecCGI
>  PerlSendHeader On
>  Order allow,deny
>  Allow from all
> </Files>
>
> Consigo executar vários scripts em mod_perl porém estou tendo problema com
> scripts que tem as instruções :
>
>                   require 'c:\\payback\\dosbox.plx';
>                   grava_conf($conf,$prog);
>
> Quando executo o script com esta característica recebo a seguinte mensagem
> de erro :
>
> [error]Undefined subroutine &ModPerl::ROOT::ModPerl::
> RegistryBB::C_3a_Payback_Contabil_Operacao_Fluxo_Formulario_2eplx::grava_conf
> called at C:/Payback/Formulario.plx line 47.
>
> Nota - Em ambiente cgi ( sem mod_perl ) todos os scripts são executados
> normalmente ( sem problemas ).
>
> Pesquisando na internet encontrei o seguinte texto no perl.apache.org : (
> http://perl.apache.org/docs/1.0/guide/porting.html  - See Names
> collisions with Modules and libs.) :
>
> There are three solutions for this:
>
> .Solution 1
>
> The first two faulty scenarios can be solved by placing your library
> modules in a subdirectory structure so that they have different path
> prefixes.
> The file system layout will be something like:
>  ./tool1/Tool1/Foo.pm
>  ./tool1/tool1.pl
>  ./tool2/Tool2/Foo.pm
>  ./tool2/tool2.pl
>
> And modify the scripts:
>  use Tool1::Foo;
>  use Tool2::Foo;
>
> For require() (scenario number 2) use the following:
>  ./tool1/tool1-lib/config.pl
>  ./tool1/tool1.pl
>  ./tool2/tool2-lib/config.pl
>  ./tool2/tool2.pl
>
> And each script contains respectively:
>  use lib qw(.);
>  require "tool1-lib/config.pl";
>
>  use lib qw(.);
>  require "tool2-lib/config.pl";
>
> This solution isn't good, since while it might work for you now, if you
> add another script that wants to use the same module or config.pl file,
> it would fail as we saw in the third scenario.
>
> Let's see some better solutions.
>
> .Solution 2
>
> Another option is to use a full path to the script, so it will be used as
> a key in %INC;
>  require "/full/path/to/the/config.pl";
>
> This solution solves the problem of the first two scenarios. I was
> surprised that it worked for the third scenario as well!
>
> With this solution you lose some portability.
> If you move the tool around in the file system you will have to change the
> base directory or write some additional script that will automatically
> update the hardcoded path after it was moved.
> Of course you will have to remember to invoke it.
>
> .Solution 3
>
> Make sure you read all of this solution.
>
> Declare a package name in the required files! It should be unique in
> relation to the rest of the package names you use. %INC will then use the
> unique package name for the key.
> It's a good idea to use at least two-level package names for your private
> modules, e.g. MyProject::Carp and not Carp, since the latter will collide
> with an existing standard package.
> Even though a package may not exist in the standard distribution now, a
> package may come along in a later distribution which collides with a name
> you've chosen.
> Using a two part package name will help avoid this problem.
>
> Even a better approach is to use three level naming, like
> CompanyName::ProjectName::Module, which is most unlikely to have
> conflicts with later Perl releases.
> Foresee problems like this and save yourself future trouble.
>
> What are the implications of package declaration?
>
> Without package declarations, it is very convenient to use() or require()
> files because all the variables and subroutines are part of the main::
> package.
> Any of them can be used as if they are part of the main script. With
> package declarations things are more awkward.
> You have to use the Package::function() method to call a subroutine from
> Package and to access a global variable $foo inside the same package you
> have to write $Package::foo.
>
> Lexically defined variables, those declared with my () inside Package will
> be inaccessible from outside the package.
>
> You can leave your scripts unchanged if you import the names of the global
> variables and subroutines into the namespace of package main:: like this:
> use Module qw(:mysubs sub_b $var1 :myvars);
>
> You can export both subroutines and global variables. Note however that
> this method has the disadvantage of consuming more memory for the current
> process.
>
> See perldoc Exporter for information about exporting other variables and
> symbols.
>
> This completely covers the third scenario. When you use different module
> names in package declarations, as explained above, you cover the first two
> as well.
>
> Comentário - Estas alternativas inviabiliza a utilização do mod_perl em
> meu ambiente sistêmico ( existem vários scripts que utilizam a instrução
> require ) e
> não seria sensato ter que multiplicá-los para individualizar nomes.
>
> ____________________________________________________________
> ________________________________________
>
> Localizei também este texto na internet e não entendi ( meu conhecimento
> em perl é limitado )
>
> Code Caching Effects ( http://www.informit.com/
> articles/article.aspx?p=23010&seqNum=4  )
>
> Recall that mod_perl caches compiled scripts.
> This helps it run scripts faster, but what happens if you change a script?
> Does mod_perl continue to execute
> the cached version? Nope. Apache::Registry keeps track of the scripts that
> it has run and checks the modification date of the original file when a
> script is requested again.
> If the date has changed, it recompiles the script and the new version is
> used instead.
> You can verify this for yourself. Request a script, and then change it and
> click the Reload button in your browser.
> You should see the changed output.Then change the script back and click
> Reload again.You should see the original output.That's what you expect and
> want to happen.2
>
> However, this behavior doesn't apply to modules pulled into your script
> via use or require.
> If you change those files, the changes won't be noticed until you restart
> the server.
> Another workaround for this problem is to use the Apache::StatINC module,
> which forces Apache to check the last modification time even for modules
> referenced from use or require statements.
> This is a technique best used on a development server, because it slows
> down Apache. Run perldoc Apache::StatINC from the command line for more
> information.
>
> Script caching also is responsible for another mysterious problem.
> If you use or require a library file, that file's code is pulled in to
> your script, compiled, and cached, as usual.
> If the file doesn't contain a package declaration to specify a namespace,
> however, the code goes into your script's own namespace.
> This is main when you run scripts in standalone mode, but scripts run in
> their own unique namespace under mod_perl.
> If your script is called script.pl, for example, the namespace might be
> &Apache::ROOT::cgi_2dperl::script_2epl.
> Normally, having unique namespaces per script is a good thing, because it
> helps keep scripts that are run under a given httpd child from colliding
> with each other in the main namespace.
> But it causes a problem for unpackaged library code. Here's why: Suppose
> you run your script script.pl that uses a library file MyLib.pm
> containing a function lib_func(). script.pl will execute properly.
> Now suppose you have a second script, script2.pl, that wants to use
> MyLib.pm, too.When the second script, executes, mod_perl, sees the use or
> require line for the library file,
> notices that the file has already been processed and cached, and doesn't
> bother to recompile it.Then when script2.pl calls lib_func() from the
> library file, an error occurs:
>
> [error] Undefined subroutine
> &Apache::ROOT::cgi_2dperl::script2_2epl::lib_func called
>
> This happens because functions in the library file have been compiled, but
> they're in the namespace for script.pl, not script2.pl.To fix this
> problem,
> make sure the library file includes a package declaration, and then invoke
> its functions using the package identifier. MyLib.pm can be written like
> this:
> package MyLib;
>
> sub lib_func
> {
>   ...
> }
> ...
>
> After making that change, your scripts should invoke MyLib::lib_func()
> rather than  lib_func().
>
> Alguém sabe como resolver este problema ?
>
> Agradeço a atenção dispensada ,
>
> kleber
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/cascavel-pm/attachments/20141213/e5b730e9/attachment-0001.html>

From payback em oi.com.br  Sat Dec 13 13:30:32 2014
From: payback em oi.com.br (payback em oi.com.br)
Date: Sat, 13 Dec 2014 19:30:32 -0200
Subject: [Cascavel-pm] mod_perl
In-Reply-To: <CAHS-WQZXFR3j3AC5U8kYq3KTNW-AWruwo=5rh10pjnhQNRS0UA@mail.gmail.com>
References: <AB3356A7D13B40CD9B0B121DDC100A72@payback.servehttp.com>
	<CAHS-WQZXFR3j3AC5U8kYq3KTNW-AWruwo=5rh10pjnhQNRS0UA@mail.gmail.com>
Message-ID: <17A8073A8160407D9EDD9FEB4CF5BC71@win7server>

Olá Breno ,

Agradeço sua gentileza em responder. 

Sou leigo em perl ( gosto de pesquisar e aprender ).
Resolvi o problema retirando todos os require dos scripts.  
Está funcionando corretamente e o tempo de resposta é bem melhor.
( levei uns 4 dias para fazer isto em todos os scripts )

Tomo a liberdade em abordar outro assunto : Modulo SSL no Apache 2.2.22

Depois de muita pesquisa instalei no apache 2.2.22 o modulo mod_ssl e está funcionado.
Criei o certificado com o openssl-win32 ( http://slproweb.com/products/Win32OpenSSL.html ).

Utilizei a configuração padrão do apache para ssl ( conf / extra / http-ssl.conf ).

Nota - instalei em dois computadores :  windows 7 e  windows 2003 server.

Observei que está acontecendo o seguinte :

- Ao executar no modo seguro em https://localhost o meu aplicativo roda normalmente ( tem um bom tempo de resposta ) 
nas duas máquinas ( win7 e win2003 ) apesar do windows declarar certificado não seguro.

- Quando executo de outra forma ( https://win7server ou https://win2003 na console ou em rede ) percebo  , através do log ,
que o apache reinicializa várias vezes e o tempo de resposta está altíssimo. 

Nota - estou recebendo as seguintes mensagens de erro :

[1] - Relatando erro enfileirado: aplicativo com falha httpd.exe, versão 2.2.22.0, módulo com falha ssleay32.dll, 
versão 1.0.1.10, endereço com falha 0x00023cb1. ( win7 e win2003 )  

[2] - wuaueng.dll (840) SUS20ClientDataStore: Falha na recuperação/restauração do banco de dados com erro inesperado -551.
( somente no wi2003 e acho que este erro não tem nada a ver com mod_ssl no apache )

[3] - Ao executar o windows  update no win2003 recebo a seguinte mensagem : Número do erro: 0xC8000227

Você conhece este assunto modo ssl no apache e pode me dar alguma dica ?

Conhece algum fórum especializado em apache onde eu possa postar este assunto ?

Mais uma vez agradeço a atenção dispensada , 

kleber


From: breno 
Sent: Saturday, December 13, 2014 1:12 PM
To: Cascavel Perl Mongers 
Subject: Re: [Cascavel-pm] mod_perl

Oi Kleber,


desculpa não ter respondido antes, só vi o email agora :(


Ainda está com problemas para carregar funções? O mod_perl é uma ferramenta poderosa mas um tanto confusa mesmo - por essas e outras que o desenvolvimento Perl moderno para web foge dessas implementações e prefere soluções como PSGI.


Pela sua mensagem, parece que o mod_perl está tendo dificuldades em encontrar a função "grava_conf" criada pelo seu código. Estou supondo que ela é criada e importada ao carregar o arquivo "c:\payback\dosbox.plx", mas é só achismo meu - me corrija se estiver errado!


Se é esse o caso, o cache do mod_perl pode estar se perdendo. Ele compila uma vez, grava no namespace ModPerl::ROOT::ModPerl::Registry:::blablabla, e esquece. Na hora que você executa em outro script, ele ve que o arquivo já está compilado em memória e pula, mas como o seu arquivo atual foi gravado em *outro* namespace do mod_perl, ele não acha a função.


Uma solução rápida para você é descobrir em que módulo a função "grava_conf" é definida e chamar ela com o full namespace em vez de apenas como "grava_conf()". Por exemplo, suponha que ela tenha sido definida no módulo Payback::Utils:


---------8<---------

package Payback::Utils;

use strict;

use warnings;


sub grava_conf {
    ...
}

1;

--------->8---------


Daí, nos lugares onde você usa, em vez de dizer:


require 'c:\\payback\\dosbox.plx';
grava_conf($conf,$prog);



Você tem que dizer:


require 'c:\\payback\\dosbox.plx';
Payback::Utils::grava_conf($conf,$prog);


Isso deve resolver o seu problema de função não encontrada dentro do mod_perl (espero!)



Dito isso, acho importante citar que, na maioria dos casos, ter "require" escrito assim não é uma boa prática hoje em dia. Há vários motivos para isso (além do problema que você já está experimentando): a dependência via "require" é avaliada durante o tempo de execução, não de compilação, deixando a execução do seu programa potencialmente mais lenta; o "require" exige o caminho do arquivo no sistema de arquivos em vez de abstrair isso pra você e acaba deixando o seu código menos portátil - imagine ter que rodar seu código Windows em um Linux, você vai ter que mudar o "c:\" e as barras em tudo! Mesmo no Windows, imagine ter que botar seu programa em outro diretório? Finalmente, o require estimula carregar scripts ".pl" quando a boa prática de hoje sugere que você separe seu programa logicamente em módulos, facilitando a reutilização de código, a identificação de erros e a manutenção do seu programa. Ou seja, em vez de 'c:\\payback\\dosbox.plx',você teria um arquivo (por exemplo) "lib/Dosbox.pm" com:

---------8<---------

package Dosbox;

use strict;
use warnings;


# funcoes do dosbox.plx

1;
--------->8---------


e em vez de chamar como:

require 'c:\\payback\\dosbox.plx';


você colocaria um:

use Dosbox;


no topo do seu código.


Idealmente, o código dentro do script "c:\\payback\dosbox.plx" seria refatorado em módulo(s) com namespace(s) significativo(s). Mesmo deixar tudo desse arquivo junto em um grande "Dosbox.pm" já seria potencialmente benéfico. Se o script de antes não apenas definia funções mas também executava algum código, declarava variáveis, etc, você pode iniciar o refactoring colocando todo o código dentro de uma grande sub e ir separando aos poucos. Isso é particularmente importante se você tem muitas variáveis "my" e está em ambiente mod_perl, já que o comportamento do mod_perl pode tornar o conteúdo delas inesperado.


Espero ter ajudado! E desculpe novamente pela demora.


[]s


-b




On Sun, Nov 30, 2014 at 5:33 PM, kleber <payback em oi.com.br> wrote: 
  Olá Srs  ,

  Instalei o mod_perl no meu computador sendo que ao iniciá-lo recebo a seguinte mensagem :

  [Sun Nov 30 09:29:28 2014] [notice] Apache/2.2.22 (Win32) PHP/5.2.8 mod_apreq2-20090110/2.8.0 mod_perl/2.0.7 Perl/v5.16.3 configured -- resuming normal operations

  Utilizei a seguinte configuração no apache :

  PerlModule ModPerl::RegistryBB
  <Files ~ "\.plx$">
  SetHandler perl-script
  PerlResponseHandler ModPerl::RegistryBB::handler
  PerlOptions +ParseHeaders
  Options -Indexes MultiViews FollowSymLinks +ExecCGI
  PerlSendHeader On
  Order allow,deny
  Allow from all
  </Files>

  Consigo executar vários scripts em mod_perl porém estou tendo problema com scripts que tem as instruções :

                    require 'c:\\payback\\dosbox.plx';
                    grava_conf($conf,$prog);

  Quando executo o script com esta característica recebo a seguinte mensagem de erro :

  [error]Undefined subroutine &ModPerl::ROOT::ModPerl::RegistryBB::C_3a_Payback_Contabil_Operacao_Fluxo_Formulario_2eplx::grava_conf called at C:/Payback/Formulario.plx line 47.

  Nota - Em ambiente cgi ( sem mod_perl ) todos os scripts são executados normalmente ( sem problemas ).

  Pesquisando na internet encontrei o seguinte texto no perl.apache.org : ( http://perl.apache.org/docs/1.0/guide/porting.html  - See Names collisions with Modules and libs.) :

  There are three solutions for this:

  .Solution 1

  The first two faulty scenarios can be solved by placing your library modules in a subdirectory structure so that they have different path prefixes.
  The file system layout will be something like:
  ./tool1/Tool1/Foo.pm
  ./tool1/tool1.pl
  ./tool2/Tool2/Foo.pm
  ./tool2/tool2.pl

  And modify the scripts:
  use Tool1::Foo;
  use Tool2::Foo;

  For require() (scenario number 2) use the following:
  ./tool1/tool1-lib/config.pl
  ./tool1/tool1.pl
  ./tool2/tool2-lib/config.pl
  ./tool2/tool2.pl

  And each script contains respectively:
  use lib qw(.);
  require "tool1-lib/config.pl";

  use lib qw(.);
  require "tool2-lib/config.pl";

  This solution isn't good, since while it might work for you now, if you add another script that wants to use the same module or config.pl file, it would fail as we saw in the third scenario.

  Let's see some better solutions.

  .Solution 2

  Another option is to use a full path to the script, so it will be used as a key in %INC;
  require "/full/path/to/the/config.pl";

  This solution solves the problem of the first two scenarios. I was surprised that it worked for the third scenario as well!

  With this solution you lose some portability.
  If you move the tool around in the file system you will have to change the base directory or write some additional script that will automatically update the hardcoded path after it was moved.
  Of course you will have to remember to invoke it.

  .Solution 3

  Make sure you read all of this solution.

  Declare a package name in the required files! It should be unique in relation to the rest of the package names you use. %INC will then use the unique package name for the key.
  It's a good idea to use at least two-level package names for your private modules, e.g. MyProject::Carp and not Carp, since the latter will collide with an existing standard package.
  Even though a package may not exist in the standard distribution now, a package may come along in a later distribution which collides with a name you've chosen.
  Using a two part package name will help avoid this problem.

  Even a better approach is to use three level naming, like CompanyName::ProjectName::Module, which is most unlikely to have conflicts with later Perl releases.
  Foresee problems like this and save yourself future trouble.

  What are the implications of package declaration?

  Without package declarations, it is very convenient to use() or require() files because all the variables and subroutines are part of the main:: package.
  Any of them can be used as if they are part of the main script. With package declarations things are more awkward.
  You have to use the Package::function() method to call a subroutine from Package and to access a global variable $foo inside the same package you have to write $Package::foo.

  Lexically defined variables, those declared with my () inside Package will be inaccessible from outside the package.

  You can leave your scripts unchanged if you import the names of the global variables and subroutines into the namespace of package main:: like this:
  use Module qw(:mysubs sub_b $var1 :myvars);

  You can export both subroutines and global variables. Note however that this method has the disadvantage of consuming more memory for the current process.

  See perldoc Exporter for information about exporting other variables and symbols.

  This completely covers the third scenario. When you use different module names in package declarations, as explained above, you cover the first two as well.

  Comentário - Estas alternativas inviabiliza a utilização do mod_perl em meu ambiente sistêmico ( existem vários scripts que utilizam a instrução require ) e
  não seria sensato ter que multiplicá-los para individualizar nomes.

  ____________________________________________________________________________________________________

  Localizei também este texto na internet e não entendi ( meu conhecimento em perl é limitado )

  Code Caching Effects ( http://www.informit.com/articles/article.aspx?p=23010&seqNum=4  )

  Recall that mod_perl caches compiled scripts.
  This helps it run scripts faster, but what happens if you change a script? Does mod_perl continue to execute
  the cached version? Nope. Apache::Registry keeps track of the scripts that it has run and checks the modification date of the original file when a script is requested again.
  If the date has changed, it recompiles the script and the new version is used instead.
  You can verify this for yourself. Request a script, and then change it and click the Reload button in your browser.
  You should see the changed output.Then change the script back and click Reload again.You should see the original output.That's what you expect and want to happen.2

  However, this behavior doesn't apply to modules pulled into your script via use or require.
  If you change those files, the changes won't be noticed until you restart the server.
  Another workaround for this problem is to use the Apache::StatINC module, which forces Apache to check the last modification time even for modules referenced from use or require statements.
  This is a technique best used on a development server, because it slows down Apache. Run perldoc Apache::StatINC from the command line for more information.

  Script caching also is responsible for another mysterious problem.
  If you use or require a library file, that file's code is pulled in to your script, compiled, and cached, as usual.
  If the file doesn't contain a package declaration to specify a namespace, however, the code goes into your script's own namespace.
  This is main when you run scripts in standalone mode, but scripts run in their own unique namespace under mod_perl.
  If your script is called script.pl, for example, the namespace might be &Apache::ROOT::cgi_2dperl::script_2epl.
  Normally, having unique namespaces per script is a good thing, because it helps keep scripts that are run under a given httpd child from colliding with each other in the main namespace.
  But it causes a problem for unpackaged library code. Here's why: Suppose you run your script script.pl that uses a library file MyLib.pm containing a function lib_func(). script.pl will execute properly.
  Now suppose you have a second script, script2.pl, that wants to use MyLib.pm, too.When the second script, executes, mod_perl, sees the use or require line for the library file,
  notices that the file has already been processed and cached, and doesn't bother to recompile it.Then when script2.pl calls lib_func() from the library file, an error occurs:

  [error] Undefined subroutine
  &Apache::ROOT::cgi_2dperl::script2_2epl::lib_func called

  This happens because functions in the library file have been compiled, but they're in the namespace for script.pl, not script2.pl.To fix this problem,
  make sure the library file includes a package declaration, and then invoke its functions using the package identifier. MyLib.pm can be written like this:
  package MyLib;

  sub lib_func
  {
    ...
  }
  ...

  After making that change, your scripts should invoke MyLib::lib_func() rather than  lib_func().

  Alguém sabe como resolver este problema ?

  Agradeço a atenção dispensada ,

  kleber 
  _______________________________________________
  Cascavel-pm mailing list
  Cascavel-pm em pm.org
  http://mail.pm.org/mailman/listinfo/cascavel-pm



--------------------------------------------------------------------------------
_______________________________________________
Cascavel-pm mailing list
Cascavel-pm em pm.org
http://mail.pm.org/mailman/listinfo/cascavel-pm
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/cascavel-pm/attachments/20141213/eb554878/attachment-0001.html>

From breno em rio.pm.org  Sat Dec 13 15:05:11 2014
From: breno em rio.pm.org (breno)
Date: Sat, 13 Dec 2014 21:05:11 -0200
Subject: [Cascavel-pm] mod_perl
In-Reply-To: <17A8073A8160407D9EDD9FEB4CF5BC71@win7server>
References: <AB3356A7D13B40CD9B0B121DDC100A72@payback.servehttp.com>
	<CAHS-WQZXFR3j3AC5U8kYq3KTNW-AWruwo=5rh10pjnhQNRS0UA@mail.gmail.com>
	<17A8073A8160407D9EDD9FEB4CF5BC71@win7server>
Message-ID: <CAHS-WQb1OObFeb8-XNsrPU8kXMsEtfQ9d40sgbsTzhB7yXXdOA@mail.gmail.com>

Oi Kleber,

Não uso Windows há muitos anos - menos ainda como servidores web - mas, ao
que parece, esse erro do OpenSSL acontece quando a versão que você instalou
não é compatível com a sua arquitetura (por exemplo, 32 bits x 64 bits), ou
quando o Apache não encontra todas as dependências da biblioteca -
problemas de %PATH ou coisa que o valha.

Experimenta ir no diretório onde o OpenSSL foi instalado e copiar os
arquivos ssleay32.dll, libeay32.dll e openssl.exe para dentro do diretório
bin do apache (normalmente "apache/bin", mas acho que depende de onde você
instalou o seu Apache) e reinicia. Se eles já existirem, manda sobrescrever
(faça um backup antes, óbvio). Reza a lenda que botar no
C:\Windows\System32 também ajuda. Mas isso tudo é dica de Google, não posso
afirmar nada nem sobre a corretude nem sobre problemas de segurança
associados.

Boa sorte!

[]s

-b



On Sat, Dec 13, 2014 at 7:30 PM, <payback em oi.com.br> wrote:
>
>   Olá Breno ,
>
> Agradeço sua gentileza em responder.
>
> Sou leigo em perl ( gosto de pesquisar e aprender ).
> Resolvi o problema retirando todos os require dos scripts.
> Está funcionando corretamente e o tempo de resposta é bem melhor.
> ( levei uns 4 dias para fazer isto em todos os scripts )
>
> Tomo a liberdade em abordar outro assunto : Modulo SSL no Apache 2.2.22
>
> Depois de muita pesquisa instalei no apache 2.2.22 o modulo mod_ssl e está
> funcionado.
> Criei o certificado com o openssl-win32 (
> http://slproweb.com/products/Win32OpenSSL.html ).
>
> Utilizei a configuração padrão do apache para ssl ( conf / extra /
> http-ssl.conf ).
>
> Nota - instalei em dois computadores :  windows 7 e  windows 2003 server.
>
> Observei que está acontecendo o seguinte :
>
> - Ao executar no modo seguro em https://localhost o meu aplicativo roda
> normalmente ( tem um bom tempo de resposta )
> nas duas máquinas ( win7 e win2003 ) apesar do windows declarar
> certificado não seguro.
>
> - Quando executo de outra forma ( https://win7server ou https://win2003
> na console ou em rede ) percebo  , através do log ,
> que o apache reinicializa várias vezes e o tempo de resposta está
> altíssimo.
>
> Nota - estou recebendo as seguintes mensagens de erro :
>
> [1] - Relatando erro enfileirado: aplicativo com falha httpd.exe, versão
> 2.2.22.0, módulo com falha ssleay32.dll,
> versão 1.0.1.10, endereço com falha 0x00023cb1. ( win7 e win2003 )
>
> [2] - wuaueng.dll (840) SUS20ClientDataStore: Falha na
> recuperação/restauração do banco de dados com erro inesperado -551.
> ( somente no wi2003 e acho que este erro não tem nada a ver com mod_ssl no
> apache )
>
> [3] - Ao executar o windows  update no win2003 recebo a seguinte mensagem
> : Número do erro: 0xC8000227
>
> Você conhece este assunto modo ssl no apache e pode me dar alguma dica ?
>
> Conhece algum fórum especializado em apache onde eu possa postar este
> assunto ?
>
> Mais uma vez agradeço a atenção dispensada ,
>
> kleber
>
>
>  *From:* breno <breno em rio.pm.org>
> *Sent:* Saturday, December 13, 2014 1:12 PM
> *To:* Cascavel Perl Mongers <cascavel-pm em pm.org>
> *Subject:* Re: [Cascavel-pm] mod_perl
>
>    Oi Kleber,
>
> desculpa não ter respondido antes, só vi o email agora :(
>
> Ainda está com problemas para carregar funções? O mod_perl é uma
> ferramenta poderosa mas um tanto confusa mesmo - por essas e outras que o
> desenvolvimento Perl moderno para web foge dessas implementações e prefere
> soluções como PSGI.
>
> Pela sua mensagem, parece que o mod_perl está tendo dificuldades em
> encontrar a função "grava_conf" criada pelo seu código. Estou supondo que
> ela é criada e importada ao carregar o arquivo "c:\payback\dosbox.plx", mas
> é só achismo meu - me corrija se estiver errado!
>
> Se é esse o caso, o cache do mod_perl pode estar se perdendo. Ele compila
> uma vez, grava no namespace ModPerl::ROOT::ModPerl::Registry:::blablabla, e
> esquece. Na hora que você executa em outro script, ele ve que o arquivo já
> está compilado em memória e pula, mas como o seu arquivo atual foi gravado
> em *outro* namespace do mod_perl, ele não acha a função.
>
> Uma solução rápida para você é descobrir em que módulo a função
> "grava_conf" é definida e chamar ela com o full namespace em vez de apenas
> como "grava_conf()". Por exemplo, suponha que ela tenha sido definida no
> módulo Payback::Utils:
>
> ---------8<---------
> package Payback::Utils;
> use strict;
> use warnings;
>
> sub grava_conf {
>     ...
> }
>
> 1;
> --------->8---------
>
> Daí, nos lugares onde você usa, em vez de dizer:
>
>
> require 'c:\\payback\\dosbox.plx';
> grava_conf($conf,$prog);
>
>
> Você tem que dizer:
>
> require 'c:\\payback\\dosbox.plx';
> Payback::Utils::grava_conf($conf,$prog);
>
> Isso deve resolver o seu problema de função não encontrada dentro do
> mod_perl (espero!)
>
>
> Dito isso, acho importante citar que, na maioria dos casos, ter "require"
> escrito assim não é uma boa prática hoje em dia. Há vários motivos para
> isso (além do problema que você já está experimentando): a dependência via
> "require" é avaliada durante o tempo de execução, não de compilação,
> deixando a execução do seu programa potencialmente mais lenta; o "require"
> exige o caminho do arquivo no sistema de arquivos em vez de abstrair isso
> pra você e acaba deixando o seu código menos portátil - imagine ter que
> rodar seu código Windows em um Linux, você vai ter que mudar o "c:\" e as
> barras em tudo! Mesmo no Windows, imagine ter que botar seu programa em
> outro diretório? Finalmente, o require estimula carregar scripts ".pl"
> quando a boa prática de hoje sugere que você separe seu programa
> logicamente em módulos, facilitando a reutilização de código, a
> identificação de erros e a manutenção do seu programa. Ou seja, em vez de
> 'c:\\payback\\dosbox.plx',você teria um arquivo (por exemplo)
> "lib/Dosbox.pm" com:
>
> ---------8<---------
> package Dosbox;
> use strict;
> use warnings;
>
> # funcoes do dosbox.plx
>
> 1;
> --------->8---------
>
> e em vez de chamar como:
>
> require 'c:\\payback\\dosbox.plx';
>
> você colocaria um:
>
> use Dosbox;
>
> no topo do seu código.
>
> Idealmente, o código dentro do script "c:\\payback\dosbox.plx" seria
> refatorado em módulo(s) com namespace(s) significativo(s). Mesmo deixar
> tudo desse arquivo junto em um grande "Dosbox.pm" já seria potencialmente
> benéfico. Se o script de antes não apenas definia funções mas também
> executava algum código, declarava variáveis, etc, você pode iniciar o
> refactoring colocando todo o código dentro de uma grande sub e ir separando
> aos poucos. Isso é particularmente importante se você tem muitas variáveis
> "my" e está em ambiente mod_perl, já que o comportamento do mod_perl pode
> tornar o conteúdo delas inesperado.
>
> Espero ter ajudado! E desculpe novamente pela demora.
>
> []s
>
> -b
>
>
>
> On Sun, Nov 30, 2014 at 5:33 PM, kleber <payback em oi.com.br> wrote:
>>
>> Olá Srs  ,
>>
>> Instalei o mod_perl no meu computador sendo que ao iniciá-lo recebo a
>> seguinte mensagem :
>>
>> [Sun Nov 30 09:29:28 2014] [notice] Apache/2.2.22 (Win32) PHP/5.2.8
>> mod_apreq2-20090110/2.8.0 mod_perl/2.0.7 Perl/v5.16.3 configured --
>> resuming normal operations
>>
>> Utilizei a seguinte configuração no apache :
>>
>> PerlModule ModPerl::RegistryBB
>> <Files ~ "\.plx$">
>> SetHandler perl-script
>> PerlResponseHandler ModPerl::RegistryBB::handler
>> PerlOptions +ParseHeaders
>> Options -Indexes MultiViews FollowSymLinks +ExecCGI
>> PerlSendHeader On
>> Order allow,deny
>> Allow from all
>> </Files>
>>
>> Consigo executar vários scripts em mod_perl porém estou tendo problema
>> com scripts que tem as instruções :
>>
>>                   require 'c:\\payback\\dosbox.plx';
>>                   grava_conf($conf,$prog);
>>
>> Quando executo o script com esta característica recebo a seguinte
>> mensagem de erro :
>>
>> [error]Undefined subroutine &ModPerl::ROOT::ModPerl::
>> RegistryBB::C_3a_Payback_Contabil_Operacao_Fluxo_Formulario_2eplx::grava_conf
>> called at C:/Payback/Formulario.plx line 47.
>>
>> Nota - Em ambiente cgi ( sem mod_perl ) todos os scripts são executados
>> normalmente ( sem problemas ).
>>
>> Pesquisando na internet encontrei o seguinte texto no perl.apache.org :
>> ( http://perl.apache.org/docs/1.0/guide/porting.html  - See Names
>> collisions with Modules and libs.) :
>>
>> There are three solutions for this:
>>
>> .Solution 1
>>
>> The first two faulty scenarios can be solved by placing your library
>> modules in a subdirectory structure so that they have different path
>> prefixes.
>> The file system layout will be something like:
>> ./tool1/Tool1/Foo.pm
>> ./tool1/tool1.pl
>> ./tool2/Tool2/Foo.pm
>> ./tool2/tool2.pl
>>
>> And modify the scripts:
>> use Tool1::Foo;
>> use Tool2::Foo;
>>
>> For require() (scenario number 2) use the following:
>> ./tool1/tool1-lib/config.pl
>> ./tool1/tool1.pl
>> ./tool2/tool2-lib/config.pl
>> ./tool2/tool2.pl
>>
>> And each script contains respectively:
>> use lib qw(.);
>> require "tool1-lib/config.pl";
>>
>> use lib qw(.);
>> require "tool2-lib/config.pl";
>>
>> This solution isn't good, since while it might work for you now, if you
>> add another script that wants to use the same module or config.pl file,
>> it would fail as we saw in the third scenario.
>>
>> Let's see some better solutions.
>>
>> .Solution 2
>>
>> Another option is to use a full path to the script, so it will be used as
>> a key in %INC;
>> require "/full/path/to/the/config.pl";
>>
>> This solution solves the problem of the first two scenarios. I was
>> surprised that it worked for the third scenario as well!
>>
>> With this solution you lose some portability.
>> If you move the tool around in the file system you will have to change
>> the base directory or write some additional script that will automatically
>> update the hardcoded path after it was moved.
>> Of course you will have to remember to invoke it.
>>
>> .Solution 3
>>
>> Make sure you read all of this solution.
>>
>> Declare a package name in the required files! It should be unique in
>> relation to the rest of the package names you use. %INC will then use the
>> unique package name for the key.
>> It's a good idea to use at least two-level package names for your private
>> modules, e.g. MyProject::Carp and not Carp, since the latter will collide
>> with an existing standard package.
>> Even though a package may not exist in the standard distribution now, a
>> package may come along in a later distribution which collides with a name
>> you've chosen.
>> Using a two part package name will help avoid this problem.
>>
>> Even a better approach is to use three level naming, like
>> CompanyName::ProjectName::Module, which is most unlikely to have
>> conflicts with later Perl releases.
>> Foresee problems like this and save yourself future trouble.
>>
>> What are the implications of package declaration?
>>
>> Without package declarations, it is very convenient to use() or require()
>> files because all the variables and subroutines are part of the main::
>> package.
>> Any of them can be used as if they are part of the main script. With
>> package declarations things are more awkward.
>> You have to use the Package::function() method to call a subroutine from
>> Package and to access a global variable $foo inside the same package you
>> have to write $Package::foo.
>>
>> Lexically defined variables, those declared with my () inside Package
>> will be inaccessible from outside the package.
>>
>> You can leave your scripts unchanged if you import the names of the
>> global variables and subroutines into the namespace of package main:: like
>> this:
>> use Module qw(:mysubs sub_b $var1 :myvars);
>>
>> You can export both subroutines and global variables. Note however that
>> this method has the disadvantage of consuming more memory for the current
>> process.
>>
>> See perldoc Exporter for information about exporting other variables and
>> symbols.
>>
>> This completely covers the third scenario. When you use different module
>> names in package declarations, as explained above, you cover the first two
>> as well.
>>
>> Comentário - Estas alternativas inviabiliza a utilização do mod_perl em
>> meu ambiente sistêmico ( existem vários scripts que utilizam a instrução
>> require ) e
>> não seria sensato ter que multiplicá-los para individualizar nomes.
>>
>> ____________________________________________________________
>> ________________________________________
>>
>> Localizei também este texto na internet e não entendi ( meu conhecimento
>> em perl é limitado )
>>
>> Code Caching Effects ( http://www.informit.com/
>> articles/article.aspx?p=23010&seqNum=4  )
>>
>> Recall that mod_perl caches compiled scripts.
>> This helps it run scripts faster, but what happens if you change a
>> script? Does mod_perl continue to execute
>> the cached version? Nope. Apache::Registry keeps track of the scripts
>> that it has run and checks the modification date of the original file when
>> a script is requested again.
>> If the date has changed, it recompiles the script and the new version is
>> used instead.
>> You can verify this for yourself. Request a script, and then change it
>> and click the Reload button in your browser.
>> You should see the changed output.Then change the script back and click
>> Reload again.You should see the original output.That's what you expect and
>> want to happen.2
>>
>> However, this behavior doesn't apply to modules pulled into your script
>> via use or require.
>> If you change those files, the changes won't be noticed until you restart
>> the server.
>> Another workaround for this problem is to use the Apache::StatINC module,
>> which forces Apache to check the last modification time even for modules
>> referenced from use or require statements.
>> This is a technique best used on a development server, because it slows
>> down Apache. Run perldoc Apache::StatINC from the command line for more
>> information.
>>
>> Script caching also is responsible for another mysterious problem.
>> If you use or require a library file, that file's code is pulled in to
>> your script, compiled, and cached, as usual.
>> If the file doesn't contain a package declaration to specify a namespace,
>> however, the code goes into your script's own namespace.
>> This is main when you run scripts in standalone mode, but scripts run in
>> their own unique namespace under mod_perl.
>> If your script is called script.pl, for example, the namespace might be
>> &Apache::ROOT::cgi_2dperl::script_2epl.
>> Normally, having unique namespaces per script is a good thing, because it
>> helps keep scripts that are run under a given httpd child from colliding
>> with each other in the main namespace.
>> But it causes a problem for unpackaged library code. Here's why: Suppose
>> you run your script script.pl that uses a library file MyLib.pm
>> containing a function lib_func(). script.pl will execute properly.
>> Now suppose you have a second script, script2.pl, that wants to use
>> MyLib.pm, too.When the second script, executes, mod_perl, sees the use or
>> require line for the library file,
>> notices that the file has already been processed and cached, and doesn't
>> bother to recompile it.Then when script2.pl calls lib_func() from the
>> library file, an error occurs:
>>
>> [error] Undefined subroutine
>> &Apache::ROOT::cgi_2dperl::script2_2epl::lib_func called
>>
>> This happens because functions in the library file have been compiled,
>> but they're in the namespace for script.pl, not script2.pl.To fix this
>> problem,
>> make sure the library file includes a package declaration, and then
>> invoke its functions using the package identifier. MyLib.pm can be written
>> like this:
>> package MyLib;
>>
>> sub lib_func
>> {
>>   ...
>> }
>> ...
>>
>> After making that change, your scripts should invoke MyLib::lib_func()
>> rather than  lib_func().
>>
>> Alguém sabe como resolver este problema ?
>>
>> Agradeço a atenção dispensada ,
>>
>> kleber
>> _______________________________________________
>> Cascavel-pm mailing list
>> Cascavel-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/cascavel-pm
>>
>  ------------------------------
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>
>
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/cascavel-pm/attachments/20141213/a80faab3/attachment-0001.html>