run :: BF -> IO ()

(continuando…)

A representação da máquina que usamos até aqui (um par com o índice onde está a cabeça, e a lista com as células) não é muito eficiente, porque é necessário percorrer a lista recursivamente para ler ou alterar o valor da célula actual.

run :: BF ->

(continuando…)

Falta o While!

Depois de ter funções que correm cada um dos diferentes comandos em BF, vamos agora juntar tudo até chegar à função run :: BF –> IO().

run ::

Na sequência da série de posts sobre a escrita de instâncias de Show e de Read em Haskell, este post trata da implementação de um interpretador de brainfuck.

read :: Read a => String –> a

(continuando…)

readsPrec usando readsPrec usando readsPrec

Bem, tal como fizemos com o Show, vamos começar por Read BFCommand, fazer tudo menos o While, fazer o Read BF à custa do Read BFCommand, e depois acabar a parte do While no Read BFCommand à custa do Read BF. Espero que isto não vos dê a volta a cabeça…

read :: Read a => String ->

(continuando…)

Show foi fácil, então e Read?

Agora que já instanciamos Show, vamos instanciar Read. Esta é mais complicada que Show, mas não é inacessível.

Em primeiro lugar, vamos inspecionar a classe Read.

read :: Read a =>

(continuando…)

show usando show usando show

Mas como é que obtemos as representações textuais das instruções?

Muito simples! Usamos a classe Show!

read ::

Ouvi dizer que havia dificuldades em perceber como se definem instâncias da classe Read em Haskell, apesar das explicações dos professores. Esta é a minha tentativa de iluminar algumas mentes sobre isso.

Parece que há um trabalho sobre uma linguagem de programação estranha, mas que acho muito interessante chamada brainfuck. Não vi o enunciado, mas ao que parece é necessário fazer pelo menos uma instância de Show e de Read para os tipos que representam programas em brainfuck.

---

Sockets cliente/servidor

O que é um socket?

De uma forma muito simples e rápida (visto isto ser matéria que diz respeito a Comunicações por Computador), um socket é uma das pontas de um canal de comunicação entre duas máquinas.

Testes

Não tenho tido tempo para acabar a série sobre excepções ou para fazer um post sobre sockets (estou a tratar disso :). Aqui fica um post (a “pedido” de um colega) que já tinha preparado há uns tempos…

---

Como é que testam o vosso código?

Excepções, parte II (vários tipos de erros)

No último post falei de excepções e das instruções fornecidas por linguagens de alto-nível para as manipular. Neste vou falar das situações em que estas surgem e como devem ser tratadas.

Excepções, parte I (de códigos de erro a excepções)

Códigos de erro

Em C há muitas funções que devolvem valores especiais para indicar erros. Esta estratégia, embora simples, apresenta vários defeitos:

1. o tipo de dados de retorno não pode ser usado por completo;
2. o código que chama estas funções é bastante chato de escrever e difícil de ler (são necessário ifs por todo o lado);
3. é fácil esquecermo-nos de testar os valores de retorno;
4. é trabalhoso propagar estes erros manualmente pela stack acima;

Usar locks explícitas, correctamente

Por vezes synchronized não serve e temos de usar locks explicitamente. No entanto, quando abandonamos a simplicidade de synchronized, também abandonamos as suas garantias de segurança e robustez.

Variáveis de condição (semáforo)

Por esta altura já devem dominar wait conditions. Por isso vou só elaborar rapidamente o que é um semáforo, e mostrar o código.

Variáveis de condição (BoundedBuffer)

O enunciado deste exercício pede a implementação de um bounded buffer que funcione correctamente com múltiplas threads. Um bounded buffer como o próprio nome indica é um buffer de tamanho fixo. É necessário que depois de cheio as tentativas de adicionar novos dados ao buffer bloqueiem, e o mesmo para tentativas de retirar dados quando este estiver vazio.

Variáveis de condição (banco)

O primeiro exercício do terceiro guião pede para reimplementar a classe Banco de modo a bloquear as operações que conduzam a saldos negativos. Como o título é “Variáveis de Condição” o que realmente se pretende é que as operações que conduzam a saldos negativos bloqueiem até que seja possível efectuá-las e não que sejam proibidas, para resolvermos este problema com variáveis de condição em lugar de simples ifs.

Exclusão Mútua (deadlocks)

Agora é-nos pedido para reimplementar o banco com exclusão mútua ao nível das contas individuais.

O que significa isto?

Exclusão Mútua

No último post encontrámos um problema que surge numa situação tão simples como incrementar um contador, simplesmente porque introduzimos paralelismo sem termos controlo sobre esse paralelismo.

Criação de Threads

Teoria

Em cada instante na nossa máquina existem vários processos a correr em simultâneo. Não importa se temos um único processador/core ou mais que um processador/core. O sistema operativo faz com que os processos corram em simultâneo, ou melhor, com que os processos deêm a impressão de correr em simultâneo. Isto permite que eu escreva este post enquanto ouço música, entre outras coisas.

Mais Makefiles

Para aqueles que ainda não usam Makefiles (porque “dá muito trabalho”, porque “não sei fazer isso” ou porque “não vou perder tempo”) deixo aqui um template (mais ou menos) genérico para compilar pequenos programas em C.

Pipelines

…ou em brasileiro: canalizações :)

$ man 7 pipe

Como diz no manual um pipe é um canal de comunicação unidireccional entre dois processos. Um dos processos escreve (com write) numa ponta, o outro lê (com read) na outra.