[SP-pm] WWW::Scripter - Como tirar o objeto da memória
Andre Carneiro
andregarciacarneiro at gmail.com
Fri Apr 16 13:34:04 PDT 2010
2010/4/16 Lindolfo "Lorn" Rodrigues <lorn.br at gmail.com>
> Seguindo o link do mantovani
> http://www.perl-community.de/bat/poard/thread/14778 , e se você olhar no
> perldoc também vai fazer
> O modulo é alpha, então isso pode acontecer, se isso for uma coisa critica
> para sua aplicação escolhe outro modulo, ou manda um patch pro cara :D
>
>
>
Não, não é crítico não. Inclusive é bem capaz deles enviarem um XML...
rsrs!! Mas gostaria de resolver o problema mesmo assim...
Quanto ao patch, é uma idéia q me passou pela cabeça sim...
Cheers!
>
> 2010/4/16 Andre Carneiro <andregarciacarneiro at gmail.com>
>
>>
>>
>> Em 16 de abril de 2010 15:47, Daniel de Oliveira Mantovani <
>> daniel.oliveira.mantovani at gmail.com> escreveu:
>>
>> 2010/4/16 Andre Carneiro <andregarciacarneiro at gmail.com>:
>>> > Bom dia !
>>> >
>>> > Estou fazendo um spider e estou tendo problemas para retirar o objeto
>>> > WWW::Scripter da memória.
>>> >
>>> > Esse módulo é bem interessante para evitar que você tenha que estudar o
>>> > Javascript que o 'brilhante' designer fez e devolve a saída desse
>>> Javascript
>>> > em formato HTML. Até aí, tudo bem! Funciona! Maravilha!
>>> >
>>> > O problema é que eu preciso que isso funcione em um spider onde eu
>>> tenho
>>> > várias iterações com esse objeto, e para cada 'get' que ele faz em cima
>>> de
>>> > uma página, ele reserva um novo espaço na memória que não libera nunca.
>>> >
>>> > Lendo a documentação, eu vi que existe um método 'clear_history', mas
>>> > aparentemente não serve para isso que eu estou querendo. Tentei forçar
>>> uma
>>> > chamada para DESTROY, mas também não está funcionando. Abaixo tem um
>>> > segmento de código que pode ajudar vocês a me ajudarem.
>>> >
>>> > <code>
>>> > .
>>> > .
>>> > .
>>> > my $scripter = WWW::Scripter->new;
>>> > $scripter->use_plugin('JavaScript');
>>> > $scripter->max_history(1);
>>> > while(defined($tree)){
>>> > my @products =
>>> >
>>> $tree->findnodes("/html/body/div[\@id='container']/div[\@id='geral']/center/div[\@id='centro']/div[\@id='centro2_int']/div[\@id='produtos-vitrine']/div");
>>> >
>>> > print "\n\n#################################ACHEI " . @products
>>> .
>>> > "PRODUTOS!\n\n";
>>> > foreach my $p(@products){
>>> > if($p){
>>> > print "\n\n" . $p->as_HTML;
>>> > #link/imagem
>>> > my ($prelink) = $p->findnodes('a');
>>> > if($prelink) {
>>> > my $u = $prelink->attr('href');
>>> > $u = decode_entities($u);
>>> > $self->product->url_original($u);
>>> > $self->product->url($self->product->url_original.
>>> > '&frompartner=3212');
>>> > my $preimg = $prelink->look_down(_tag => 'img');
>>> > if($preimg){
>>> > $self->product->imagem($preimg->attr('src'));
>>> > }
>>> >
>>> > #Capturando detalhes
>>> > # print "\n\nURL: " . $self->product->url_original .
>>> > "\n\n";
>>> >
>>> eval{$self->agent->get($self->product->url_original)};
>>> > if($self->agent->success){
>>> > $scripter->get($self->product->url_original);
>>> > my $dtree =
>>> > HTML::TreeBuilder::XPath->new_from_content($self->agent->content);
>>>
>>> Você colocou o $scripter->clear_history
>>> aqui ?
>>>
>>>
>>> > $self->get_detail($dtree , $scripter);
>>> > }else {
>>> > .
>>> > .
>>> > .
>>> > }
>>> > .
>>> > .
>>> > .
>>> > }
>>> > }
>>> >
>>> > </code>
>>> >
>>>
>>> Como você só colocou um pedaço do código, não da para saber, o final.
>>> Você percebeu que você está iniciando um objeto TreeBuilder a cada
>>> iteração do laço que o request é realizado com sucesso, você está
>>> fazendo $dtree->delete ?
>>>
>>>
>> O pedaço do código que eu coloquei é suficiente para ver como o treco está
>> sendo usado entre as iterações. Não precisa de mais nada além daquilo. Além
>> do mais eu isolei essa mesma parte no MEU código para poder observar e ainda
>> sim continua acumulando o alocação de memória, ou seja, não está liberando a
>> memória.
>>
>>
>>> O módulo não tem nenhum "Report Bug", se fosse problema do módulo de
>>> estourar a memória, com certeza alguém já teria reportado.
>>>
>>>
>>>
>> Pode ser então que eu seja o primeiro a fazer um! :D
>>
>>
>>> Por tanto, se você ler na documentação tem um atributo chamado:
>>> max_docs, por favor quando você iniciar o objeto, mude-o para 1
>>>
>>>
>> Eu já vi esses atributos e continua não liberando memória... :D
>>
>>
>>
>>> my $script = WWW::Scripter->new(max_docs => 1, max_history => 1)
>>>
>>> "The maximum number of document objects to keep in history (along with
>>> their corresponding request and response objects). If this is omitted,
>>> Mech's stack_depth + 1 will be used. This is off by one because
>>> stack_depth is the number of pages you can go back to, so it is one
>>> less than the number of recorded pages. max_docs considers 0 to be
>>> equivalent to infinity."
>>>
>>>
>> Boa! Mas eu já tinha testado isso, e continua não liberando memória mesmo
>> assim.
>> Mas é um bom lugar pra começar a fuçar no código...
>>
>>
>>
>>> Isso não é nada mais do que o atributo, "stack_depth" do Mechanize que
>>> guarda os históricos do get, se não me falhe minha memória.
>>> http://search.cpan.org/~sprout/WWW-Scripter-0.010/lib/WWW/Scripter.pod<http://search.cpan.org/%7Esprout/WWW-Scripter-0.010/lib/WWW/Scripter.pod>
>>>
>>> Estou esperando, para saber se agora funcinona, ok!
>>>
>>>
>> Acho que isso não vai rolar tão cedo... de qq forma obrigado!
>>
>>
>> Cheers!
>>
>> --
>> André Garcia Carneiro
>> Analista/Desenvolvedor Perl
>> (11)82907780
>>
>> _______________________________________________
>> SaoPaulo-pm mailing list
>> SaoPaulo-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>>
>
>
>
> --
> lorn at lornlab dot org
> Lindolfo "Lorn" Rodrigues
>
>
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm at pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>
--
André Garcia Carneiro
Analista/Desenvolvedor Perl
(11)82907780
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20100416/a58a63e3/attachment.html>
More information about the SaoPaulo-pm
mailing list