Maurício Menon
domingo, 4 de agosto de 2013
domingo, 14 de outubro de 2012
Compilação entre diferentes Sistemas Operacionais no Mac OS X
Fichinha de fazer no Debian, certo? No Mac nem tanto, então segue página com binários para os preguiçosos:
http://crossgcc.rts-software.org/doku.php
Contém Cross Compilers para o Mac OS X não tão atualizados assim, mas prontos para usar. Dá para criar executáveis para Windows e Linux em 5 min.
Recomendações:
- criar links simbólicos na pasta de instalação, você nunca irá lembrar dos nomes começando em i386 na hora de compilar.
- adicionar ao path a pasta: echo 'export PATH=/usr/local/i386-mingw32-4.3.0/bin:$PATH' >> ~/.profile
Depois é so correr "pro" abraço:
- Windows:
mingw32-gcc -o semnome.exe Untitled1.c -mwindows -static
- Linux:
/usr/local/gcc-4.5.2-for-linux32/bin/i586-pc-linux-g++ -static
/usr/local/gcc-4.5.2-for-linux32/bin/i586-pc-linux-gcc -static
No Debian é fichinha trabalhar com várias versões do gcc e links simbólicos, no Mac ainda não descobri como fazer isso. Próximo post. Enquanto isso gcc + clang na máquina.
terça-feira, 14 de fevereiro de 2012
terça-feira, 7 de fevereiro de 2012
domingo, 27 de novembro de 2011
quinta-feira, 13 de outubro de 2011
iOS 5 na marra
Problemas?
Faça um backup no itunes, depois baixe os arquivos utilizando o wget com a opção -c:
./wget -c http://supportdownload.apple.com/download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/Mac_OS_X/downloads/041-2775.20111012.Mk3sw/iPhoto9.2Update.dmg
Acima é a atualização do iPhoto para o icloud, só para exemplo. Deve ser baixado o arquivo imagem referente ao modelo correto do iphone.
Depois apertanto o botão ALT clicar em restaurar e apontar para a imagem baixada. Pronto...
Faça um backup no itunes, depois baixe os arquivos utilizando o wget com a opção -c:
./wget -c http://supportdownload.apple.com/download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/Mac_OS_X/downloads/041-2775.20111012.Mk3sw/iPhoto9.2Update.dmg
Acima é a atualização do iPhoto para o icloud, só para exemplo. Deve ser baixado o arquivo imagem referente ao modelo correto do iphone.
Depois apertanto o botão ALT clicar em restaurar e apontar para a imagem baixada. Pronto...
sexta-feira, 22 de abril de 2011
H.264 x Webm - Porque o codec padrão do Google (Youtube) é uma porcaria
Texto completo em: http://x264dev.multimedia.cx/archives/377
Supposedly Google is open to improving the bitstream format — but this seems to conflict with the fact that they got so many different companies to announce VP8 support. The more software that supports a file format, the harder it is to change said format, so I’m dubious of any claim that we will be able to spend the next 6-12 months revising VP8. In short, it seems to have been released too early: it would have been better off to have an initial period during which revisions could be submitted and then a big announcement later when it’s completed.
Update: it seems that Google is not open to changing the spec: it is apparently “final”, complete with all its flaws.
In terms of decoding speed I’m not quite sure; the current implementation appears to be about 16% slower than ffmpeg’s H.264 decoder (and thus probably about 25-35% slower than state-of-the-art decoders like CoreAVC). Of course, this doesn’t necessarily say too much about what a fully optimized implementation will reach, but the current one seems to be reasonably well-optimized and has SIMD assembly code for almost all major DSP functions, so I doubt it will get that much faster.
I would expect, with equally optimized implementations, VP8 and H.264 to be relatively comparable in terms of decoding speed. This, of course, is not really a plus for VP8: H.264 has a great deal of hardware support, while VP8 largely has to rely on software decoders, so being “just as fast” is in many ways not good enough. By comparison, Theora decodes almost 35% faster than H.264 using ffmpeg’s decoder.
Finally, the problem of patents appears to be rearing its ugly head again. VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder”. Even VC-1 differed more from H.264 than VP8 does, and even VC-1 didn’t manage to escape the clutches of software patents. It’s quite possible that VP8 has no patent issues, but until we get some hard evidence that VP8 is safe, I would be cautious. Since Google is not indemnifying users of VP8 from patent lawsuits, this is even more of a potential problem. Most importantly, Google has not released any justifications for why the various parts of VP8 do not violate patents, as Sun did with their OMS standard: such information would certainly cut down on speculation and make it more clear what their position actually is.
But if luck is on Google’s side and VP8 does pass through the patent gauntlet unscathed, it will undoubtedly be a major upgrade as compared to Theora.
Overall verdict on the VP8 video format
Overall, VP8 appears to be significantly weaker than H.264 compression-wise. The primary weaknesses mentioned above are the lack of proper adaptive quantization, lack of B-frames, lack of an 8×8 transform, and non-adaptive loop filter. With this in mind, I expect VP8 to be more comparable to VC-1 or H.264 Baseline Profile than with H.264. Of course, this is still significantly better than Theora, and in my tests it beats Dirac quite handily as well.Supposedly Google is open to improving the bitstream format — but this seems to conflict with the fact that they got so many different companies to announce VP8 support. The more software that supports a file format, the harder it is to change said format, so I’m dubious of any claim that we will be able to spend the next 6-12 months revising VP8. In short, it seems to have been released too early: it would have been better off to have an initial period during which revisions could be submitted and then a big announcement later when it’s completed.
Update: it seems that Google is not open to changing the spec: it is apparently “final”, complete with all its flaws.
In terms of decoding speed I’m not quite sure; the current implementation appears to be about 16% slower than ffmpeg’s H.264 decoder (and thus probably about 25-35% slower than state-of-the-art decoders like CoreAVC). Of course, this doesn’t necessarily say too much about what a fully optimized implementation will reach, but the current one seems to be reasonably well-optimized and has SIMD assembly code for almost all major DSP functions, so I doubt it will get that much faster.
I would expect, with equally optimized implementations, VP8 and H.264 to be relatively comparable in terms of decoding speed. This, of course, is not really a plus for VP8: H.264 has a great deal of hardware support, while VP8 largely has to rely on software decoders, so being “just as fast” is in many ways not good enough. By comparison, Theora decodes almost 35% faster than H.264 using ffmpeg’s decoder.
Finally, the problem of patents appears to be rearing its ugly head again. VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder”. Even VC-1 differed more from H.264 than VP8 does, and even VC-1 didn’t manage to escape the clutches of software patents. It’s quite possible that VP8 has no patent issues, but until we get some hard evidence that VP8 is safe, I would be cautious. Since Google is not indemnifying users of VP8 from patent lawsuits, this is even more of a potential problem. Most importantly, Google has not released any justifications for why the various parts of VP8 do not violate patents, as Sun did with their OMS standard: such information would certainly cut down on speculation and make it more clear what their position actually is.
But if luck is on Google’s side and VP8 does pass through the patent gauntlet unscathed, it will undoubtedly be a major upgrade as compared to Theora.
quarta-feira, 23 de março de 2011
Ferramenta de análise de dados (Data analysis tool pack) no Office 2011
Sentiu falta da ferramenta de análise de dados (Data analysis tool pack) no Office 2011?
Então, não é sua culpa não saber onde está, não tem mesmo.
Use este, tem uma versão gratuita para ajudar, e possui as principais ferramentas de estatística embutido.
terça-feira, 22 de março de 2011
Macports a prova de orelha-seca
O macports começou reclamar do openssl, não compila e tal?
Não seja orelha seca e verifique a versão da zlib, se é própria para o sistema. O SL é somente 64 bits.
Fix: https://trac.macports.org/ticket/20954
Não seja orelha seca e verifique a versão da zlib, se é própria para o sistema. O SL é somente 64 bits.
Fix: https://trac.macports.org/ticket/20954
sudo port clean openssl zlib sudo port uninstall zlib sudo port -d install openssl
And
sudo port upgrade --force installed
segunda-feira, 22 de novembro de 2010
segunda-feira, 15 de novembro de 2010
Adding dictionaries to the built-in Dictionary Application in Leopard (via David’s logbook)
The Dictionary Application (Dict App for short) is really helpful at times when you are reading an eBook / web page. I even define my own shortcut key so that when I high light a word and press "Control + Command + A", the dictionary app will come up straight away and show me the meaning of the word that I've high lighted. But there is just one little problem…the Dict App only comes with a few built-in dictionaries…for instance if I want to k … Read More
via David's logbook
http://freebirdenglish.com/stardict_dic/
sábado, 13 de novembro de 2010
Alterar idioma de partes de texto no Office 2011
Para quem sente falta da barra inferior de idiomas do Office 2007 e 2010 e enlouquece com a caixa de ferramentas de idiomas do Office para Mac (2011) descrevo uma das possíveis soluções para textos multi-idioma.
Já adianto que é uma solução de engenheiro, precisava fazer um artigo com partes em português, inglês e espanhol em um Office 2011 recém adquirido e instalado. Se você é programador e conhece bem AppleScript, etc. e tal pode fazer algo muito mais elegante. O fato é que demorei 5 minutos para fazer isso. Meu tempo vale muito.
O Office 2004 funcionava bem, mas estava antiquado. O Office 2008 foi vergonhoso. E embora o OpenOffice tenha uma boa qualidade inquestionável, reinventar a roda para inserir quebras de seções com numerações próprias é cansativo. VM para rodar um produtivo, e importante, já adquirido Office 2007, parecia razoável.
O Office 2011 parecia uma boa solução para varrer a VM com Windows da máquina. Vale o preço: R$ 199 para 3 licenças. Mas carece (ou desconheço) de algumas funções presentes em outras versões.
A solução adotada aqui utiliza VBA (nível caixinha de areia) e um atalho de teclado para a macro. Tosco. Mas funciona.
Abra o Word 2011:
Na opção Tools clique em Macro e VBA editor:
Copie o texto abaixo:
Sub Set_EN_US()
Selection.LanguageID = wdEnglishUS
End Sub
Sub Set_PT_BR()
Selection.LanguageID = wdBrazilianPortuguese
End Sub
Sub set_ES()
Selection.LanguageID = wdSpanish
End Sub
Dentro de normal.dotm, em New Macros, cole no editor que fica aberto o texto à direita.
Depois é só ir em Tools, Customize Keyboard:
Role as categorias até aparecer a categoria macros, e clique nela.
Selecione a macro com o mouse e na caixa Press new keyboard shortcut selecione uma opção de atalho, como por exemplo, CTRL+I. É só repetir o processo para Inglês, Português e Espanhol.
Agora é só selecionar o texto no idioma diferente do padrão, a ser alterado, e executar o atalho de teclado configurado acima!
Agora é só selecionar o texto no idioma diferente do padrão, a ser alterado, e executar o atalho de teclado configurado acima!
Marcadores:
idioma,
linguagem,
mac office 2011 mudar para portugues,
Mac Os X,
macbook,
Microsoft Office Mac 2011,
Microsoft Office para Mac,
multi-idioma,
Office 2011,
snow leopard,
VBA
sábado, 7 de agosto de 2010
domingo, 14 de fevereiro de 2010
Removing Unwanted Startup Debian Files or Services
http://theos.in/desktop-linux/removing-unwanted-startup-debian-files-or-services/
Assinar:
Postagens (Atom)