tag:blogger.com,1999:blog-83003924173733950512024-08-29T23:00:28.293+01:00Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.comBlogger36125tag:blogger.com,1999:blog-8300392417373395051.post-61255686227756590082010-12-23T19:00:00.000+00:002011-03-04T03:41:09.251+00:00

(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. Existe uma outra forma de representar a máquina que é muito mais eficiente. Basicamente, consiste em usar duas listas: uma para as células à

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com0tag:blogger.com,1999:blog-8300392417373395051.post-70231986213080274992010-12-23T02:02:00.000+00:002011-03-04T03:40:48.304+00:00

(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(). Em primeiro lugar vamos criar uma função que corre apenas um comando, mas suporta qualquer um deles. Basicamente queremos fazer pattern matching para chamar as pequenas funções que escrevemos atrás. runOne :: BFCommand -&gt

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com11tag:blogger.com,1999:blog-8300392417373395051.post-91303884717730113152010-12-23T00:16:00.001+00:002011-03-04T03:39:48.198+00:00

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. Este interpretador terá de efectuar tanto input como output, e por isso deverá usar o tipo de dados paramétrico IO. Este tipo de dados costuma causar confusão nos aprendizes de Haskell por várias razões, algumas das quais são: input

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com5tag:blogger.com,1999:blog-8300392417373395051.post-85036566800457435072010-12-09T23:55:00.003+00:002011-03-04T03:39:20.472+00:00

(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… A função read consome o texto todo e devolve um valor. A função readsPrec no

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com7tag:blogger.com,1999:blog-8300392417373395051.post-41895834222069883202010-12-09T22:16:00.001+00:002011-03-04T03:38:44.766+00:00

(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. > :i Readclass Read a where readsPrec :: Int -> ReadS a-- ... mais outras que não interessam ...-- ... montes e montes de instâncias ... Temos de definir uma função que recebe um

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com0tag:blogger.com,1999:blog-8300392417373395051.post-90811935263643830172010-12-09T21:47:00.001+00:002011-03-04T03:38:25.112+00:00

(continuando…) show usando show usando show Mas como é que obtemos as representações textuais das instruções? Muito simples! Usamos a classe Show! Mas para isso temos de instanciar Show para BFCommand, definindo show :: BFCommand –> String: instance Show BFCommand where show = undefined Para já vamos deixar assim e acabar de definir show :: BF –> String. Podemos então agora

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com1tag:blogger.com,1999:blog-8300392417373395051.post-3893924046726731962010-12-09T20:07:00.001+00:002011-03-04T03:38:02.187+00:00

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

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com2tag:blogger.com,1999:blog-8300392417373395051.post-42867765908358945632010-01-22T16:10:00.003+00:002011-03-04T03:37:37.999+00:00

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. Exercício 1: Servidor de eco Para implementar o servidor de eco vamos usar a classe java.net.ServerSocket, que serve para receber conexões externas com o método accept. Este método devolve

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com1tag:blogger.com,1999:blog-8300392417373395051.post-13989950405199025702010-01-08T18:09:00.001+00:002011-03-04T03:37:08.927+00:00

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? Testes manuais Monta-se um num instante com umas text boxes e um botão para executar um método em particular. Ou então faz-se algo semelhante na linha

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com0tag:blogger.com,1999:blog-8300392417373395051.post-2110998750843867462009-12-08T16:53:00.002+00:002011-03-04T03:36:38.953+00:00

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. Tipos de erro Os erros que podem surgir numa aplicação podem ser divididos em quatro categorias, consoante com a sua causa: erros do programador, erros do utilizador, erros de ambiente e o que eu costumo

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com1tag:blogger.com,1999:blog-8300392417373395051.post-81614173519133853402009-12-02T06:34:00.001+00:002011-03-04T03:36:19.434+00:00

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: o tipo de dados de retorno não pode ser usado por completo; 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); é fácil esquecermo-nos de testar os valores de retorno;

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com0tag:blogger.com,1999:blog-8300392417373395051.post-42737703432284554972009-12-01T01:16:00.001+00:002011-03-04T03:35:47.926+00:00

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. Código frágil, aka vidro Uma transformação ingénua de código com locks implícitas para locks explícitas seria desta forma: // implícitasynchronized(obj) { // região crítica}// explícita (não é

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com1tag:blogger.com,1999:blog-8300392417373395051.post-1629646562544424662009-11-05T13:38:00.001+00:002011-03-04T03:35:21.295+00:00

Por esta altura já devem dominar wait conditions. Por isso vou só elaborar rapidamente o que é um semáforo, e mostrar o código. Um semáforo é uma primitiva de concurrência que protege um determinado número de recursos. As threads podem adquirir e libertar esses recursos. Embora isto pareça semelhante a locks, um semáforo é muito mais liberal (e flexível): não existe o conceito de

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com0tag:blogger.com,1999:blog-8300392417373395051.post-89328760598459247042009-11-05T12:35:00.001+00:002011-03-04T03:34:47.951+00:00

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. Este tipo de estrutura pode ser usada

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com2tag:blogger.com,1999:blog-8300392417373395051.post-27920137983060631502009-10-30T18:00:00.001+00:002011-03-04T03:34:27.540+00:00

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

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com0tag:blogger.com,1999:blog-8300392417373395051.post-6213041215037477732009-10-14T15:18:00.001+01:002011-03-04T03:33:58.907+00:00

Agora é-nos pedido para reimplementar o banco com exclusão mútua ao nível das contas individuais. O que significa isto? Até agora no nosso banco ocorre apenas uma transacção de cada vez porque temos todos os métodos críticos marcados com synchronized. Isto significa que enquanto alguém está a efectuar uma transacção, ninguém pode mexer em nenhuma conta. No entanto não existe problema

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com1tag:blogger.com,1999:blog-8300392417373395051.post-20231851788584165652009-10-14T15:17:00.001+01:002011-03-04T03:32:59.171+00:00

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. Para resolver este problema temos de garantir que enquanto uma thread está a incrementar o contador, nenhuma das outras threads faz o mesmo. Por outras palavras (mais que mil?), queremos que as

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com3tag:blogger.com,1999:blog-8300392417373395051.post-4080760690027902192009-10-08T02:09:00.001+01:002011-03-04T03:32:17.160+00:00

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.

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com6tag:blogger.com,1999:blog-8300392417373395051.post-55900328853435169812009-06-29T11:11:00.001+01:002011-03-04T03:30:43.683+00:00

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. Makefile CONFIG=config.mkDEPS=deps.mkinclude $(CONFIG) SRC_FILES=$(wildcard *.c)HDR_FILES=$(wildcard *.h)OBJ_FILES=$(patsubst %.c,%.o,$(SRC_FILES))LDLIBS=$(patsubst %,-l%,$(

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com3tag:blogger.com,1999:blog-8300392417373395051.post-40201353988681572142009-06-27T15:19:00.001+01:002011-03-04T03:30:08.831+00:00

…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. O que temos de fazer para a nossa shell permitir este tipo de comunicação entre processos é o seguinte: processar a string do comando para detectar pedidos de pipes;

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com5tag:blogger.com,1999:blog-8300392417373395051.post-85404668362193284442009-06-27T15:13:00.002+01:002011-03-04T03:12:38.059+00:00

Para adicionar à shell a possibilidade de redireccionar o standard input e o standard output de e para ficheiros temos de usar a system call dup2: $ man dup2 Esta system call faz com que o descritor passado no segundo parâmetro aponte para o mesmo ficheiro que o primeiro. Se o segundo descritor já estava aberto, este é fechado primeiro. Depois de chamar esta função tanto faz usar o primeiro

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com0tag:blogger.com,1999:blog-8300392417373395051.post-33195692621254481342009-06-17T15:36:00.000+01:002011-03-04T03:12:10.138+00:00

Background/Foreground Até aqui a nossa shell corre sempre os processos em foreground. Isto significa que a shell pára até cada processo terminar. Assim não podemos correr mais que um processo de cada vez. Para isso temos de manter alguns processos em background. Isto significa apenas que a shell não espera por eles. Temos no entanto de manter uma lista destes processos. Vou recorrer a uma

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com0tag:blogger.com,1999:blog-8300392417373395051.post-67968238379939319462009-06-17T13:50:00.001+01:002011-03-04T03:10:13.019+00:00

Queria pedir desculpa a todos aqueles que me pediram ajuda no domingo por não ter respondido a ninguém. Não tenho net em casa, e por isso só reparei nos comentários bastante tarde. Também tive teste de CG na segunda-feira e por isso só comecei a estudar para SO segunda à tarde. Ainda acabei o código dos guiões que me faltavam, mas só perto da meia-noite. Duvido muito que por essa altura tenham

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com6tag:blogger.com,1999:blog-8300392417373395051.post-10298114948968326982009-05-25T09:27:00.001+01:002011-03-04T03:06:49.729+00:00

Um pequeno aparte Bem, eu não gosto muito deste guião. A página do manual da system call signal que é apresentada no guião, começa assim: The behavior of signal() varies across Unix versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. Depois de ler isto é óbvio porque é que eu prefiro sigaction. Mas a sigaction é

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com4tag:blogger.com,1999:blog-8300392417373395051.post-76775282945964951682009-05-25T09:24:00.001+01:002011-03-04T03:05:37.163+00:00

A lista de system calls deste guião é deveras assustadora. Não contando com a system, são nada mais, nada menos que sete variantes da mesma função: exec. A system é bastante simples. Recebe uma string com um comando para correr, executa-o e returna o seu código de saída. Experimentem executar isto: #include <stdlib.h>int main(void){ int exit = system("ls –l"); return

Martinho Fernandeshttp://www.blogger.com/profile/10298505469149672373noreply@blogger.com4