Projetos Pessoais
Aqui estão os meus projetos mais interessantes, mais ou menos em ordem cronológica reversa.
Bible Reader (2025–)
Um aplicativo (ainda não lançado) para leitura da Bíblia. Na verdade, uma aplicação web. Acontece que tecnologias web são muito boas em exibir texto estático, então eu não me preocupei com ferramentas “nativas”.
Ainda está nos estágios iniciais, mas a diagramação está muito boa[a]. A coisa mais interessante que eu aprendi foi sobre scripture formats. A Bíblia tem uma estrutura tão única que existe mais de um formato só para ela! Eu escrevi um conversor de um deles[b] para HTML para exibir tudo como os tradutores pretendiam.
[a] Muito do que aprendi lá também usei na versão web deste blog.
[b] USFX, não foi a melhor escolha em retrospecto. Eu devia ter usado USJ ou USX.
cmod (2025)
cmod: a modern C build system that doesn’t require build files
Eu escrevi sobre o cconf[a] um tempo atrás, quando ele ainda era escrito em awk. Eu tinha reescrito em Python, usando TOML para configuração, e com algumas funcionalidades a mais, mas apaguei a única cópia (argh!) com um rm errado.
[a] cconf, a build system for C
Acho que a ideia básica ainda tem algum mérito, mas depois de perder o código eu repensei. Talvez eu nem queira um script de configuração! Então eu escrevi o cmod, um sistema de build sem configuração obrigatória. Ele só lista recursivamente todos os arquivos em C e compila todos eles. Você pode adicionar um arquivo de configuração para usar dependências do sistema.
É um script bem simples em shell que gera um build.ninja e imediatamente chama o Ninja. Faltam algumas funcionalidades desejáveis, como opções de compilação, pré-processadores customizados, e ser escrito em uma linguagem de verdade, mas eu já estou usando em todos os meus protótipos em C. É bem legal, parece Go ou Rust.
Agora também está num repositório git, então eu não posso perder de novo.
Oken (2022–2025)
Oken é um projeto ambicioso demais que eu refiz muitas vezes e tenho muito pouco para mostrar.
O objetivo era ter um depurador REPL estilo Lisp, sintaxe estilo Tcl, sistema de tipos gradual, multimétodos, e a capacidade de compilar para C para execução mais rápida. Era para servir como shell, linguagem de extensão, ou para escrever aplicativos completos.
Era ambicioso demais e o design nunca se encaixou direito. O mais perto que eu cheguei foi um protótipo de interpretador em Lua, seguindo o guia do Mal[a], sem a sintaxe estilo Tcl, mas com todas as funcionalidades de runtime que eu queria. Eu vi que multimétodos eram... uma péssima ideia. São muito difíceis de implementar com eficiência. E o resto era... basicamente Common Lisp com um sintaxe diferente. O que já dá para fazer no Common Lisp com reader macros.
Agora, eu entendo muito melhor quão bom é ter tipagem estática. Tipagem dinâmica é ótima quando comparada com sistemas estáticos ruins, como o estilos antigos de C ou Java, mas a maior parte da vantagem na velocidade de desenvolvimento é inútil quando seus programas são instáveis por causa disso. Eu ainda não gosto de sistemas de tipos estilo provador de teorema, como o Haskell ou o Rust (mesmo que sejam interessantes em teoria), porque deixam o programa difícil de modificar quando as invariantes mudam, mas sistemas dinâmicos não ajudam até você rodar o programa e ter um erro de tipo.
momOS
Há muito tempo eu venho pensando em qual sistema operacional eu recomendaria para a minha mãe usar. Notavelmente, eu ia querer que fosse o mesmo que eu uso, então precisa ser alguma coisa que tanto hackers de linha de comando como eu gostaria de usar, mas também que um usuário leigo (mas inteligente) gostasse de usar.
Não existe código publicável, mas a versão atual é assim:
- Chimera Linux como base
- COSMIC para a interface
- Firefox + uma versão customizada da Phoenix como navegador
- LibreOffice ou MS Office via Wine como pacote de escritório
- um frontend gráfico para o apk para gerenciamento de pacotes (gerencia um arquivo world por usuário, instalado como pacote virtual)
Minha mãe ainda não chegou a revisar o computador dela (ela está ocupada com outras coisas) então boa parte disso é teórica. Mas é interessante projetar. E mesmo que ela não mude para o Linux no fim, provavelmente eu vou mudar para o Chimera e uma versão da configuração acima.
3D Pong (2023)
Um jogo muito, muito ruim que fiz em algumas horas, como um game jam pessoal, só para saber como é “terminar” um jogo. O “tema” era 3D. Qualquer jogo, desde que fosse 3D. Infelizmente, o resultado final é tão ruim que eu mal posso considerar “terminado”.
Lake (2020–2021)
The Lake programming language: C but sweeter
Lake é um “substituto para C”[a]. Comecei este projeto depois de escrever um servidor pequeno em Rust. Não gostei de Rust, por vários motivos, mas quando voltei para C, senti falta de algumas funcionalidades. Então minha primeira tentativa, que eu agora chamo de lakec-old, era C, com uma sintaxe mais limpa e algumas funcionalidades do Rust.
[a] O nome é um trocadilho ruim, eu sei, mas “P” (de BCPL) já estava ocupado, e “D” também.
Comecei com o cproc[b], um compilador de C, e modifiquei progressivamente. Mudei a sintaxe, adicionei operator overloading, macros melhoradas, tipagem estrutural em alguns casos, genéricos, e várias outras melhorias de qualidade de vida. Eu tentei adicionar um sistema de ownership, mas não funcionava bem. E assim que eu tentei usar, percebi que copiar funcionalidades de uma linguagem que não gosto (Rust) tinha criado outra linguagem que não gosto. Quem diria!
Eu desisti quando estava tentando implementar inferência de tipos para genéricos e estava tendo muitos bugs irritantes. Percebi que eu já não acreditava no design da linguagem, e decidi recomeçar do zero.
Depois de mais dois redesigns do zero (só projetos, sem código), acabei com... basicamente Pascal. Não, seriamente, as únicas coisas que eu tenho contra Pascal são os problemas conhecidos (todos facilmente corrigíveis) e a sintaxe verbosa. Neste ponto, eu já tinha aprendido muito mais sobre como usar C melhor[c] e acabei só voltando a usar C, deixando este projeto de lado. Ainda quero retomar ele algum dia.
[c] Principalmente com o Chris Wellons (veja o resto do blog dele também)
SGS/libeverything/libok/libwinr (2019–2022)
Este projeto teve vários nomes, um para cada iteração. Só o libwinr foi lançado[a], e em um estado bem incompleto.
[a] libwinr: open a window and get a framebuffer
A ideia era fazer a camada de aplicação para um OS rodando no kernel do Linux, e me preocupar com o kernel depois (talvez baseado no Yax, talvez não). Descobri que o Wayland é difícil de usar diretamente, se você não quer depender de um monte de outras bibliotecas, e que existe um bom motivo pelo qual não vemos mais bibliotecas gráficas hoje. Elas são chatas de escrever.
Agora, eu só uso o SDL3, assumindo que ele vai ser portado para qualquer OS que eu precisar usar no futuro.
Craft (2019–2020)
Há muito tempo, eu tenho um conceito de design de jogos que pode ser resumido como “Minecraft, só que melhor”. A minha primeira tentativa real foi modificar o Craft do Michael Fogleman[a].
[a] Craft: a simple Minecraft clone written in C using modern OpenGL (shaders)
Aprendi muito sobre como ele funcionava, e ainda mais sobre como não escrever C. É uma base de código bem... interessante. Eu tentei fazer algum design de verdade, mas acabei me distraindo reescrevendo tudo porque o código estava tão esquisito.
No fim, as únicas novas funcionalidades notáveis foram a geração de mundo no servidor, e raytracing. Eu queria provar que dava para fazer raytracing em tempo real no meu laptop de 2014, e escrevi um raymarcher DDA no pixel shader[b] para isso. Tinha sombras e refração, mas qualquer tentativa de usar sub-raios acabava com o desempenho. Ele rodava a 30 FPS se a janela fosse metade da tela, o que era suficiente para mim na época.
[b] Inspirado no noeuclid, apesar de eu ter usado um algoritmo diferente.
Hoje eu sei como fazer muito, muito melhor, desde começar com um depth map até fazer path tracing com denoising, mas eu nunca mais quero revisitar aquele código. Talvez algum dia eu queira reescrever.
Distribuição com Static Linking (2018–2019)
Eu infelizmente perdi o código deste projeto. Tinha feito um “gerenciador de pacotes” pequeno em shell, sem suporte para dependências. Então, eu compilei musl, binutils, GCC, sbase e outros pacotes até que meu editor de texto (vis) e gerenciador de janelas (dwm, na época) estivessem todos empacotados como binários com static linking, compilados com o meu sistema.
Eu cheguei bem longe. Estava usando esses pacotes todos os dias, em vez dos fornecidos pela distribuição. Empacotar as bibliotecas do X foi interessante; como elas não são feitas para static linking, tive que juntar as bibliotecas estáticas com as dependências delas (desempacotando e reempacotando) para não ter erros de dependências ausentes.
Eventualmente, percebi que é impossível fazer static linking do OpenGL porque ele é um driver que precisa combinar com o driver do kernel. O que significa que todo programa gráfico no Linux moderno (com Wayland) precisa usar dynamic linking, mesmo que só por este motivo. Por isso desisti do projeto.
Yax (2018–2019)
Eu comecei este projeto quando entrei na faculdade, pensando que depois de começar a trabalhar, não ia mais ter tanto tempo para mexer nesse tipo de coisa. É um microkernel estilo Unix, com multitarefa, paginação e um sistema de arquivos virtual (VFS). O VFS suporta montagens de usuário estilo Plan 9, e é usado como IPC.
Este foi meu primeiro projeto grande em C. Comecei do tutorial “Bare Bones” do OSDev[a] e segui de lá. Aprendi bastante sobre como organizar o código para evitar bugs, mas minha inexperiência ainda aparece: quase tudo usa contagem de referência! Também usei aquela prática de um cabeçalho por unidade de tradução que é frequentemente recomendada, mas completamente inútil. Hoje eu dividiria módulos com uma granularidade maior.
Desisti dele assim que comecei a escrever um driver de disco e percebi que eu não gosto de escrever drivers. Além disso, ele não é diferente o suficiente do Linux para valer a pena usar[b], então eu decidi abandoná-lo e considerá-lo como “pronto”. Cumpriu seus objetivos de design—um “microkernel” com o VFS como IPC.
[b] Imagino que depois de bastante trabalho para tornar ele utilizável.
O nome vem do meu nome do meio, Ieks. Meu sobrenome (Minicz) soa parecido com outro microkernel estilo Unix, o MINIX.
Não tem chamada umount porque eu esqueci de implementar.