Lendo um relato sobre um pobre programador que apagou uma tabela inteira, porque esqueceu o where num delete, fiquei a pensar que o SQL deveria ter sintaxe diferente para alguns casos.Os updates e os deletes de tabelas inteiras deveriam indicar a intencao explicitamente:update my_table set my_column=0 all rows;delete other_table all rows;E se alguem esquecesse do all rows ou do where, seria um erro de sintaxe. Aposto que essa mudanca evitaria muito sofrimento. O CPAN nunca decepciona: ha um modulo para rotacionar as imagens conforme os metadados do JPEG. As maquinas fotograficas mais modernas gravam nos arquivos JPEG a orientacao das fotos e o modulo Imager::ExifOrientation permite carregar a imagem ja virada no sentido correto para exibir na tela.use Imager::ExifOrientation;sub next_photo { my $index=int(rand($#file_list)); my $filename=$file_list[$index]; my $image = Imager::ExifOrientation->rotate(path => $filename); scale($photo_width, $photo_height, $image); $photo->configure(-file=>'tmp.jpg'); $filename=$file_list[($index+1)%($#file_list+1)]; $image = Imager::ExifOrientation->rotate(path => $filename); scale($thumb_width, $thumb_height, $image); $thumb->configure(-file=>'tmp.jpg'); $main->update();}A magica tem seus limites: se o arquivo nao contiver a informacao de orientacao, a imagem sera carregada assim como esta no arquivo. Depois de explorar o mandelbrot com expoentes maiores de 2, com numeros reais, e com numeros negativos, eu tinha que verificar o que acontece com expoentes complexos.O calculo e um pouco mais complicado e tambem mais demorado.var pr=2;var pi=-0.009; function mandel(x,y) { var c=1; var r=x; var i=y; while(r*r+i*i<4 && c<MAXITER) { var a=Math.atan2(i,r); var b=r*r+i*i; var p=Math.pow(b,pr/2)*Math.pow(Math.E,-1*pi*a); var nr=p*Math.cos(pr*a+0.5*pi*Math.log(b)); var ni=p*Math.sin(pr*a+0.5*pi*Math.log(b)); r=nr+x; i=ni+y; c+=1; } return c;}O expoente tem uma parte real (pr) e uma parte imaginaria (pi).Valores grandes (maiores de 1) de pi distorcem muito a imagem, entao usei valores pequenos. De longe, percebe-se que algo nao esta certo. A imagem abaixo foi gerada com expoente=2-0.009i.De perto aparecem detalhes interessantes.Com 2+0.1i, a distorcao ja e grave.Eis algunas detalhes curiosos de 1/pi + i/e.Clique nas imagens para ve-las no tamanho original.E i/e merece um lugar num museu de arte moderna. O porta-retratos digital funcionou bem por cerca de 8 horas e entao parou com um erro de malloc(). Apos algumas simulacoes e pesquisa dos bugs do Tk, descobri que o defeito esta na classe Tk::Photo. Quando a imagem e carregada pela memoria (com -data), os bits ficam guardados para sempre. Quando sao lidos do disco, os dados nao persistem alem da proxima leitura.Entao, reescrevi alguns trechos e o codigo ficou um pouco menor. A funcao scale() nao retorna mais os dados; agora ela escreve um arquivo.sub scale { my ($width, $height, $image)=@_; my $scaled=$image->scale(xpixels=>$width,ypixels=>$height,type=>'min'); $scaled->write(file=>'tmp.jpg', type=>'jpeg'); }Por sua vez, a funcao next_photo() le este arquivo:sub next_photo { my $index=int(rand($#file_list)); my $filename=$file_list[$index]; $image->open(file=>$filename); scale($photo_width, $photo_height, $image); $photo->configure(-file=>'tmp.jpg'); $filename=$file_list[($index+1)%($#file_list+1)]; $image->open(file=>$filename); scale($thumb_width, $thumb_height, $image); $thumb->configure(-file=>'tmp.jpg'); $main->update();}Evidentemente, nao quero escrever este arquivo no cartao de memoria para nao apressar o seu fim. Entao, a solucao e criar um disco em RAM e escrever la. Ele nao precisa ser muito grande, os JPEGs temporarios nao passam de 100KB (por isso, o script original demorou a ocupar toda a memoria). Um diskgroup de minha base (11g) estava perigosamente cheio, entao resolvi transportar um tablespace pouco usado para um diskgroup mais lento.Suponha que os datafiles do tablespace TSX estejam no