You are currently browsing the category archive for the 'Sistemas' category.
Palavras-chave: Python, command prompt, prompt de comandos, prompt, DOS, Windows
Quando executamos um programa “.py” no Windows uma janela de prompt irá aparecer automaticamente para que as eventuais saídas de texto do seu programa sejam enviadas para lá.
Mas essa janela pode se tornar incoveniente quando o nosso programa já provê uma interface gráfica pois, neste caso, teríamos duas janelas abertas para a mesma aplicação.
A janela aparece porque a extensão “.py” está associada ao interpretador “X:\PythonXX\python.exe” que está configurado para abrir uma janela de prompt.
Caso você precise executar seu programa sem essa janela é melhor usar o interpretador “X:\PythonXX\pythonw.exe” que é feito justamente para esse propósito.
A extensão “.pyw” é associada à esse interpretador, portanto, basta renomear os seus arquivos .py, .pyc e .pyo para .pyw que as janelas de prompt deixarão de aparecer.
Palavras-chave: linux, cache, buffers, limpeza, memória, carregamento, disco, filesystem
O Linux mantém em memória os dados recentemente carregados do disco, e ali eles ficam enquanto possível. Isso acelera o processo de carregamento destes mesmos dados no futuro, como na execução de programas e leitura de arquivos.
As áreas na memória que carregam esses dados chamam-se caches. Você pode notar os caches em ação quando roda um programa pela segunda vez e ele carrega muito mais rapidamente que na primeira.
Mas às vezes é necessário fazer algum teste onde esse efeito de cache deve ser anulado, por exemplo, medir tempo de carregamento de um programa, ou o tempo necessário para processar algum arquivo. Já vi gente reiniciando a máquina só para poder ter uma medição confiável no tempo de carregamento de um programa.
Para economizar nosso tempo e paciência, e ter um efeito semelhante sem precisar reiniciar a máquina, podemos pedir ao kernel que limpe todos os caches que estiverem em memória. Basta usar uma entrada no /proc, existente nas versões mais recentes do kernel, rodando o comando:
echo 1 > /proc/sys/vm/drop_caches
Palavras-chave: OpenGL, Linux, multi-thread, drivers NVidia, crash, segmentation fault, segfault
Se seu programa explode em uma função OpenGL sem nenhum motivo aparente, verifique se a chamada está sendo feita desde a thread onde a OpenGL foi inicializada.
As bibliotecas que vêm com os drivers da NVidia (libGL.so) para X não são muito tolerantes com programas com multi-threading, enquanto a libGL.so da Mesa parece ser mais tolerante a isso. Isso pode levar à confusa situação de o programa rodar sem problemas em alguns sistemas e morrer em outros.
Nos casos em que tive esse problema, o segfault ocorreu na função glViewport(), mas é provável que ocorra com outras funções.
Não existe solucão mágica, mas um workaround — para ao menos testar a hipótese — é mudar o LD_LIBRARY_PATH para apontar ao libGL.so da xorg (se não a tem instalado, tente copiar de outro lugar etc). Verifique se a biblioteca correta está sendo usada com ldd e teste. Já a solucão definitiva é mover as chamadas OpenGL que acessam o mesmo contexto para uma única thread (ou protegê-las com mutexes).
Palavras-chave: Mac, embed framework, dylib, Cocoa, deployment, XCode
No OS X, bundles de aplicativos (as pastas .app) podem conter as bibliotecas dinâmicas e Frameworks que o programa usa. Assim sua aplicação passa a ser auto-contida: o usuário não precisa instalar bibliotecas extra que você usou, nem é necessário um instalador que copie essas bibliotecas no sistema do usuário.
Para isso, faça o seguinte:
- Compile o framework ou biblioteca usada com o atributo de diretório de instalação (Installation Directory) tendo o valor “@executable_path/../Frameworks”. Para configurar isso no XCode:
- Abra o projeto da biblioteca ou framework
- Vá em Project -> Edit Active Target
- No tab Build, selecione Configuration:All Configurations e Collection:Deployment
- Preencha o campo “Installation Directory” com @executable_path/../Frameworks
- Recompile
Também é possível mudar este atributo em uma biblioteca já compilada, mas isto será tratado em um outro post.
- Copie suas dependências no diretório Contents/Frameworks do seu .app
O XCode pode fazer isto automaticamente:- Selecione o Target que corresponde à sua aplicação na lista Groups & Files e no combo Active Target
- Project -> New Build Phase -> New Copy Files Build Phase
- Em Destination: selecione Frameworks e deixe o resto como está
- Selecione o grupo “Copy Files” na lista Groups & Files e largue as bibliotecas e frameworks a incluir
Após estes passos, sua aplicação deverá conter suas bibliotecas em Aplicacao.app/Contents/Frameworks.
Comentários Recentes