Planet ccppbrasil.org

Concurrency Double Coverage

2010-04-21T22:13:56+00:00

This post is equivalent to 2 of them.

Here I'm pointing the materials for 2 talks I'd given about Concurrency:

Paralelismo com .NET Framework 4.0 - MSDN Brazil WebCast

Download Samples & Slides from this talk

Introduction to Visual C++ 10 Concurrency Runtime - 6. Encontro C&C++ Brasil

Download Samples & Slides from this talk

Both talks covered concurrency/parallel programming, of course.

The first one was about .NET Framework 4.0 and the new features including: Task Parallel Library, PLINQ, Concurrency Collections, and a lot of managed code and concurrency stuff. The samples was written in C#. During the Q&A section someone asked about the use of those features with UI. I put an extra sample covering this issue!

The second one was about C++, my number one favorite programming language, and concurrency. In fact, was about a Introduction to ConcRT, a concurrency runtime shipped with Visual C++ 10.

If you want to try these samples and amazing features for free, you can download the Visual C++ 10 Express and the other Visual Studio 10 tools.

Every post has a code. Thus, it isn't different:

Find Files (sequential and parallel) in C#:

using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using System.Collections.Concurrent;

namespace DotNet4_ParallelSamples
{
using dir = System.IO.Directory;

abstract class FileFinder
{
    public IEnumerable<string> FindFiles(string dir_path, string filenameHint)
    {
        Action<string> addItem;
        var filesFound = CreateResultBuffer(out addItem);
        FindFilesCore(dir_path, filenameHint, addItem);
        return filesFound;
    }

    protected string[] GetFiles(string dir_path)
    {
        var files = new string[0];
        try
        {
            files = dir.GetFiles(dir_path);
        }
        /* ignore */
        catch (UnauthorizedAccessException) { }
        catch (System.IO.IOException) { }
        /* ignore */

        return files;
    }

    protected string[] GetDirectories(string dir_path)
    {
        var directories = new string[0];
        try
        {
            directories = dir.GetDirectories(dir_path);
        }
        /* ignore */
        catch (UnauthorizedAccessException) { }
        catch (System.IO.IOException) { }
        /* ignore */

        return directories;
    }

    protected abstract IEnumerable<string> CreateResultBuffer(out Action<string> addFunc);

    protected abstract void FindFilesCore(string dir_path, string filenameHint, Action<string> addToResult);
}

class SequentialFileFinder : FileFinder
{
    protected override IEnumerable<string> CreateResultBuffer(out Action<string> addFunc)
    {
        var buffer = new List<string>();
        addFunc = buffer.Add;

        return buffer;
    }

    protected override void FindFilesCore(string dir_path, string filenameHint, Action<string> addToResult)
    {
        foreach (var file in GetFiles(dir_path))
        {
            if (file.Contains(filenameHint))
            {
                addToResult(file);
            }
        }

        foreach (var directory in GetDirectories(dir_path))
        {
            FindFilesCore(directory, filenameHint, addToResult);
        }
    }
}

class ParallelFileFinder : FileFinder
{
    protected override void FindFilesCore(string dir_path, string filenameHint, Action<string> addToResult)
    {
        Parallel.ForEach(GetFiles(dir_path), (file) =>
        {
            if (file.Contains(filenameHint))
            {
                addToResult(file);
            }
        });

        Parallel.ForEach(GetDirectories(dir_path), (directory) =>
        {
            FindFilesCore(directory, filenameHint, addToResult);
        });
    }

    protected override IEnumerable<string> CreateResultBuffer(out Action<string> addFunc)
    {
        var buffer = new ConcurrentBag<string>();
        addFunc = buffer.Add;

        return buffer;
    }
}
}

Find Files (sequential and parallel) in C++:

#include <windows.h>
#include <ppl.h>

using namespace Concurrency;

#include <list>
#include <string>
#include <algorithm>
#include <iostream>

using namespace std;

#include "_helper.hpp"

struct Directory
{
    static void GetDirectories( __in const wchar_t* path, __out list<wstring>& directories )
    {
        EnumIOItems( path, [&]( __in const WIN32_FIND_DATA& ffd )
        {
            if ( ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY && L'.' != ffd.cFileName[0] )
                directories.push_back( wstring( path ).append( ffd.cFileName ).append( L"\\" ) );
        });
    }

    static void GetFiles( __in const wchar_t* path, __out list<wstring>& files )
    {
        EnumIOItems( path, [&]( __in const WIN32_FIND_DATA& ffd )
        {
            if ( !(ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) )
                files.push_back( wstring( path ).append( ffd.cFileName ) );
        });
    }

private:
    template<class Function>
    static void EnumIOItems( __in const wchar_t* path, __in Function _Func )
    {
        WIN32_FIND_DATA ffd = { NULL };
        HANDLE hFind = FindFirstFile( wstring( path ).append(L"*").c_str(), &ffd );
        if ( INVALID_HANDLE_VALUE != hFind )
        {
            do _Func( ffd ); while( 0 != FindNextFile( hFind, &ffd ) );
            FindClose( hFind );
        }
    }
};

class FileFinder
{
public:
    typedef list<wstring> result_type;
    typedef result_type& result_type_ref;

    FileFinder(){}
    virtual ~FileFinder(){}

    void FindFiles( __in const wchar_t* path, __in const wchar_t* filenameHint, __out result_type_ref filesFound )
    {
        FindFilesCore( path, filenameHint, filesFound );
    }

protected:
    void GetFiles( __in const wchar_t* path, __out result_type_ref files ) const
    {
        Directory::GetFiles( path, files );
    }

    void GetDirectories( __in const wchar_t* path, __out result_type_ref directories ) const
    {
        Directory::GetDirectories( path, directories );
    }

    template<class Container, class Item> void add( Container& c, const Item& i ) const { c.push_back( i ); }

    virtual void FindFilesCore( __in const wchar_t* path, __in const wchar_t* filenameHint, __out result_type_ref filesFound ) const = 0;
};

class SequentialFileFinder : public FileFinder
{
protected:
    virtual void FindFilesCore( __in const wchar_t* path, __in const wchar_t* filenameHint, __out result_type_ref filesFound ) const
    {
        list<wstring> files;
        GetFiles( path, files );
        for_each( files.begin(), files.end(), [&]( __in const wstring& file )
        {
            if( wstring::npos != file.find( filenameHint ) )
                add( filesFound, file );
        } );

        list<wstring> directories;
        GetDirectories( path, directories );
        for_each( directories.begin(), directories.end(), [&]( __in const wstring& dir )
        {
            FindFilesCore( dir.c_str(), filenameHint, filesFound );
        } );
    }
};

class ParallelFileFinder : public FileFinder
{
protected:
    virtual void FindFilesCore( __in const wchar_t* path, __in const wchar_t* filenameHint, __out result_type_ref filesFound ) const
    {
        combinable<result_type> filesFound_partial;

        list<wstring> files;

        GetFiles( path, files );
        parallel_for_each( files.begin(), files.end(), [&]( __in const wstring& file )
        {
            if( wstring::npos != file.find( filenameHint ) )
                add( filesFound_partial.local(), file ); //<-
        } );

        join( filesFound_partial, filesFound ); //<-

        list<wstring> directories;
        GetDirectories( path, directories );
        parallel_for_each( directories.begin(), directories.end(), [&]( __in const wstring& dir )
        {
            FindFilesCore( dir.c_str(), filenameHint, filesFound );
        } );
    }

private:
    void join( __in combinable<result_type>& filesFound_partial, __out result_type_ref filesFound ) const
    {
        filesFound_partial.combine_each( [&](result_type_ref local)
        {
            copy( local.begin(), local.end(), back_insert_iterator<result_type>( filesFound ) );
            local.clear();
        } );
    }
};

Typedef arcaico

2010-04-20T12:26:03+00:00

A API do Windows geralmente prima pela excelência em maus exemplos. A Notação Húngara e o Typedef Arcaico são duas técnicas que, por motivos históricos, são usados a torto e a direito pelos códigos de exemplo.

Já foi escrito muita coisa sobre os prós e contras da notação húngara. Já o typedef arcaico, esse pedacinho imprestável de código, ficou esquecido, e hoje em dia traz mais dúvidas na cabeça dos principiantes em C++ do que deveria. Para tentar desobscurecer os mitos e fatos, vamos tentar explicar o que significa essa construção tão atípica, mas comum no dia-a-dia.

Vejamos um exemplo típico desse pequeno Frankenstein semântico:

typedef struct _MINHASTRUCT {
   int x;
   int y;
}
MINHASTRUCT, *LPMINHASTRUCT;

Bom, eu nem sei por onde começar. Talvez pelo conceito de typedef.

Typedefs

Um typedef, basicamente, é um apelido. Você informa um tipo e define "outro tipo".

typedef <tipo> apelido;

O <tipo> é tudo que fica entre o typedef e o novo nome, que deve ser um identificador válido na linguagem. Por exemplo, a empresa onde trabalho fez um typedef informal do meu nome:

typedef Wanderley Caloni Wandeco;

Se, futuramente, eu sair da empresa e entrar outro "Wanderley alguma-coisa", será possível usar o apelido novamente, bastando alterar o typedef:

typedef Wanderley Cardoso Wandeco;

Bom, "outro tipo" é forma de dizer. Isso é uma descrição errônea em muitos livros. De fato, o compilador enxerga o mesmo tipo com outro nome, daí chamarmos o typedef de apelido, mesmo.

/** @file dois_apelidos.cpp */
#include <iostream>
 
using namespace std;
 
struct Struct
{
   int x;
   int y;
};
 
typedef Struct Struct1;
typedef Struct Struct2;
 
int main()
{
   Struct1 s1;
   Struct2 s2;
 
   cout << typeid(s1).name() << endl;
   cout << typeid(s2).name() << endl;
}

C:\Tests>cl /EHsc dois_apelidos.cpp
...
/out:dois_apelidos.exe
dois_apelidos.obj

C:\Tests>dois_apelidos.exe
struct Struct
struct Struct

Granularidade dos tipos

Tipos simples são fáceis de entender porque possuem seus símbolos no mesmo lugar:

int x;
char c;
long p;

Já os tipos um pouco mais complicados permite alguma mudança aqui e acolá:

int* x;
char *y;
long * p;

Essa liberdade da linguagem, mesmo sendo um recurso útil, pode ser bem nocivo dependendo de quem olha o código:

int x, y; // dois inteiros
int * x, y; // um ponteiro para inteiro e um inteiro
int x, *y; // um inteiro e um ponteiro para inteiro
int *x, y; // um ponteiro para inteiro e um inteiro

Em algumas formas da sintaxe, além de ser inevitável, gera bastante desconfiança:

// Um ponteiro para função que recebe dois inteiros e não retorna nada.
typedef void (*FP)(int, int);

// Um ponteiro para função que recebe dois inteiros e não retorna nada.
void (*)(int, int);

// Um cast para ponteiro para função que recebe dois inteiros e não retorna nada.
( ( void (*)(int, int) ) pf )(x, y);

#include <iostream>
 
void func(int x, int y)
{
   std::cout << x << '-' << y << '\n';
}
 
int main()
{
   void* pf = func;
   ( ( void (*)(int, int) ) pf )(3, 14);
}

Structs em C++

Antigamente, as structs eram construções em C que definiam um agregado de tipos primitivos (ou outras structs) e que poderiam gerar variáveis desse tipo em qualquer lugar, desde que informado seu nome e que se tratasse de uma struct:

/** @file structs.cpp */
struct MyStruct { int x, y; };
 
void func1()
{
   struct MyStruct ms;
   //...
}
 
void func2(struct MyStruct msa)
{
   //...
}
 
int main()
{
   struct MyStruct ms;
   func2(ms);
}

Para evitar toda essa digitação, os programadores usavam um pequeno truque criando um apelido para a estrutura, e usavam o apelido no lugar da struct (apesar de ambas representarem a mesma coisa).

struct MyStruct { int x, y; };
typedef struct MyStruct MS;

typedef struct MyStruct { int x, y; } MS;
struct MyStruct ms1; // ainda prolixo
MS ms2; // mais simples

Com a definição da linguagem C++ padrão, e mais moderna, essa antiguidade foi removida, apesar de ainda suportada. Era possível usar apenas o nome do struct como seu tipo:

/** @file structs.cpp */
struct MyStruct { int x, y; };
 
void func1()
{
   /*struct*/ MyStruct ms;
   //...
}
 
void func2(/*struct*/ MyStruct msa)
{
   //...
}
 
int main()
{
   /*struct*/ MyStruct ms;
   func2(ms);
}

Porém, isso vai um pouco além de quando a Microsoft começou a fazer código para seu sistema operacional. Naquela época, o padrão ainda estava se formando e existia mais ou menos um consenso de como seria a linguagem C++ (sem muitas alterações do que de fato a linguagem C já era). De qualquer forma, a linguagem C imperava bem mais que C++. Dessa forma, já era bem formada a ideia de como declarar uma struct: a forma antiga.

typedef struct _MINHASTRUCT {
   int x;
   int y;
}
MINHASTRUCT, *LPMINHASTRUCT;

Além do uso controverso do _sublinhado para nomear entidades (que no padrão foi recomendado que se reservasse aos nomes internos da biblioteca-padrão) e do uso de MAÍUSCULAS_NO_NOME (historicamente atribuído a nomes definidos no pré-processador), o uso do typedef atracado a um struct era muito difundido. E ficou ainda mais depois que a API do Windows foi publicada com essas definições.

Como fazer,então?

Ora, do mesmo jeito que é feito há vinte anos: sem typedefs. O próprio paradigma da linguagem, independente de padrões de APIs, de sistemas operacionais ou de projetos específicos já orienta o programador para entender o que o espera na leitura de um código-fonte qualquer. Qualquer pessoa que aprendeu o básico do básico sobre ponteiros e structs consegue ler o código abaixo:

// Papai, o que que é isso?
// Ora, filho, apenas uma definição de estrutura!
//
struct MinhaStruct {
   int x;
   int y;
};
 
// muitas linhas abaixo...
 
void func(MinhaStruct* ms)
{
   // asterisco significa ponteiro para MinhaStruct!
}
 
int main()
{
   MinhaStruct ms;
   func(&ms);
}

Agora, para entender a forma antiga, ou você se baseou no copy&paste dos modelos Microsoftianos, ou seja, decoreba, ou você é PhD em Linguagem C/C++ e padrões históricos de linguagens legadas. Se não é, deveria começar o curso agora.

// Papai, o que que é isso?
// Ora, filho, apenas uma definição de sinônimo da struct
// _MINHASTRUCT, cujo nome não é usado, para dois nomes
// em maiúsculas, apesar se não serem defines, com uma
// nomenclatura de ponteiro que eu nunca vi na vida (obs: 
// papai programa em um sistema não-Windows).
//
typedef struct _MINHASTRUCT {
   int x;
   int y;
}
MINHASTRUCT, *LPMINHASTRUCT;
 
// muitas linhas abaixo...
 
void func(LPMINHASTRUCT ms)
{
   // o que diabos é um LP, mesmo?
}
 
int main()
{
   MINHASTRUCT ms;
   func(&ms);
}

Da mesma forma, o uso de uma estrutura simples de tipos mantém a lista de nomes do seu projeto limpa e clara. Compare o visualizador de classes em projetos Windows com algo mais C++ para ter uma ideia.

É claro, essa é apenas uma sugestão. Existem vantagens em sua utilização. Existe alguma vantagem no modo antigo? Existe: a Microsoft usa, e talvez mais pessoas usem. Basta a você decidir qual deve ser o melhor caminho.

Atualização

De acordo com o leitor Adriano dos Santos Fernandes, a obrigatoriedade do nome struct após seu nome continua valendo para a linguagem C padrão, assim como no compilador GCC ocorre um erro ao tentar omiti-la. Apenas na linguagem C++ essa obrigatoriedade não existe mais.

Eu não fiz meus testes, mas confio no diagnóstico de nosso amigo. A maior falha do artigo, no entanto, é usar a linguagem C como base, quando na verdade ele deveria falar sobre o uso desses typedefs em C++. Esse erro também foi corrigido no original.

0xc0de

2010-04-05T18:54:24+00:00

Recentemente resolvi fazer alguns testes relacionados a inicialização de objetos em C++ em diferentes ambientes. Tive algumas surpresas…

O padrão C++ define três tipos de inicialização:

zero-initialization – Neste texto traduzido como inicialização por zeros.
default-initialization – Traduzido como inicialização padrão.
value-initialization – Traduzido como inicialização por valor

O significado de cada um é explicado detalhadamente [§8.5.5]. Mas a linguagem e formalismo utilizados em documentos técnicos normalmente não são os mais triviais possíveis. Portanto, não é raro aparecerem algumas dúvidas.

O caso em que estava interessado é relativamente simples e abrange apenas um sub-conjunto das regras de inicialização. Colocando em termos práticos, queria analisar qual seria o valor de um membro inteiro de um struct em situações distintas.

Além de coisas mais simples e conhecidas como chamadas convencionais a construtores, as informações do padrão que considerei pertinentes para o seguinte trecho de código são as seguintes:

Um objeto construído através de um par vazio de parêntesis deve passar por uma inicialização por valor [§ 8.5.7]. Note que isso se aplica a uma inicialização do tipo T * t = new T(); [§ 5.3.4] ou até mesmo do tipo T();[§ 5.2.3].
Quando um objeto de tipo não-POD (Plain Old Data) não tem nenhum inicializador ele deve passar por uma inicialização padrão. Esse é o caso, por exemplo, de uma expressão como T * t = new T; ou T t;. No entanto, se o objeto for de tipo POD ele e seus sub-objetos não passam por inicialização alguma e, consequentemente, têm valor indeterminado [§ 8.5.9].
Uma inicialização padrão de um objeto tipo POD como int (não para arrays) resulta em uma inicialização por zeros [§ 8.5.5].
Uma inicialização por valor de um objeto de um tipo classe (excluindo union) promove uma inicialização por valor de seus membros não-estáticos e classes bases.

struct PlainOldData //POD
{
  int id_;
};

struct NonPOD_CompilerCtor
{
  int id() const { return id_; }

private:
  int id_;
};

struct NonPOD_UserCtor
{
  NonPOD_UserCtor() : id_() {}
  int id() const { return id_; }

private:
  int id_;
};

O programinha que escrevi apenas cria objetos dos tipos definidos acima com duas sintaxes diferentes. Em seguinda, inspeciono os valores do membro id_.

int main()
{
  PlainOldData * a = new PlainOldData;
  NonPOD_CompilerCtor * b = new NonPOD_CompilerCtor;
  NonPOD_UserCtor * c = new NonPOD_UserCtor;

  //...

  PlainOldData * d = new PlainOldData();
  NonPOD_CompilerCtor * e = new NonPOD_CompilerCtor();
  NonPOD_UserCtor * f = new NonPOD_UserCtor();

  //...
}

Os valores que esperava para o membro id_ são os seguintes:

a – O objeto é criado sem parêntesis e o tipo é POD. Logo, não há inicialização e o valor de id_ é indeterminado.
b – O objeto é criado sem parêntesis e o tipo é não-POD. Logo, a inicialização é padrão. No entanto, o construtor é o gerado pelo compilador, o qual não faz inicialização de nenhum membro. Portanto, o valor de id_ é indeterminado.
c – O objeto é criado sem parêntesis e o tipo é não-POD. Novamente, temos inicialização padrão. Agora, com a diferença de que existe um construtor definido pelo usuário que inicializa explicitamente id_. Este, então, sofre inicialização por valor, a qual resulta em inicialização por zeros devido ao fato de int ser POD.
d – O objeto é criado com parêntesis vazios e, assim como nos outros dois casos abaixo, a inicialização é por valor. Este caso se trata de um POD. Logo, a inicialização por valor resulta diretamente em inicialização por zeros.
e – Como dito acima, o objeto sofre inicialização por valor, já que foi criado com parêntesis vazios. O membro id_ também sofre inicialização por valor que, devido ao fato de se tratar de um POD, resulta em inicialização por zeros.
f – Novamente, inicialização por valor. Naturalmente, o construtor definido pelo usuário é invocado. Este inicializa por valor o membro id_, que por ser um POD sofre inicialização por zeros.

Testando com compiladores diferentes obtive os seguintes resultados.

Compilador	a	b	c	d	e	f
G++ 4.2.4	0	0	0	0	0	0
Mingw – G++ 4.4.0	Indeterm.	Indeterm.	0	0	0	0
VC++ 2008 Express	Indeterm.	Indeterm.	0	0	0	0
Digital Mars 8.5.1	0	0	0	Indeterm.	0	0

Para completar a avaliação também resolvi utilizar sintaxes correspondentes às usadas acima só que com alocação na pilha.

int main()
{
  PlainOldData aa;
  NonPOD_CompilerCtor bb;
  NonPOD_UserCtor cc;

  //...

  PlainOldData const& dd = PlainOldData();
  NonPOD_CompilerCtor const& ee = NonPOD_CompilerCtor();
  NonPOD_UserCtor const& ff = NonPOD_UserCtor();

  //...
}

Já que nesses casos o fator determinante na inicialização é a presença ou não dos parêntesis, esperava obter exatamente os mesmos resultados do código anterior. Apenas uma observação: As referências para const dos últimos três casos são apenas uma estratégia artificial para testar a inicialização através da expressão X(), já que X x(); é na verdade a declaração de uma função que não recebe parâmetros e retorna X.

Desta vez os resultados foram os seguintes:

Compilador	aa	bb	cc	dd	ee	ff
G++ 4.2.4	Indeterm.	Indeterm.	0	0	0	0
Mingw – G++ 4.4.0	Indeterm.	Indeterm.	0	0	0	0
VC++ 2008 Express	Indeterm.	Indeterm.	0	0	Indeterm.	0
Digital Mars 8.5.1	Indeterm.	Indeterm.	0	Indeterm.	0	0

Bom, como pode ser visto encontrei muitas variações de comportamento entre os compiladores. Espero não ter cometido alguma interpretação errônea pelos meandros do padrão, mas os únicos compiladores que foram conformantes na primeira leva de testes foram o G++ 4.4.0 (Mingw) e o Visual C++ 2008. Já para a segunda parte, na qual esperava exatamente os mesmos resultados, apenas o G++ 4.4.0.

O estilo funcional em C++

2010-03-31T02:19:50+00:00

Estava de mau humor e resolvi ironizar a vida estudando numa aula de Java o artigo "Why Functional Programming Matters", que eu copiei do site do Haskell.

Acabei finalmente entendendo (eu acho!) as primeiras implicações importantes de lazy evaluation. O exemplo mais simples dessas implicações no artigo, na minha opinião, está no programa que computa aproximações da raiz quadrada pelo método de Newton-Raphson.

Esse método é basicamente uma expressão matemática que começa com um resultado anterior e usa esse resultado para computar um próximo, garantindo que o próximo é melhor que o anterior.

Seja N o número cuja raiz quadrada você deseja aproximar, e uma aproximação anterior x. O procedimento começa chutando x, por exemplo 1. O método afirma que o próximo x deve ser ( x + ( N / x ) / 2 .

O artigo descreve um programa para resolver o método. O programa segue abaixo; para entendê-lo completamente, estude o artigo.

repeat f a = cons a ( repeat f ( f a ) )

within e ( cons a ( cons b rest ) ) =

= b , if abs(a - b) <= eps

= within e ( cons b rest), otherwise

next N x = ( x + N / x ) / 2

sqrt a0 e N = within e ( repeat ( next N ) a0 )

O espírito geral do programa é assim:

repeat é uma função que gera uma lista contendo um elemento inicial seguido do resultado da função f com argumento elemento-anterior. Observe que repeat gera uma lista infinita, assumindo que f está definida para todo a.

within é uma função que percorre uma lista procurando um par de elementos cuja diferença seja menor que um epsilon.

A notação de parâmetros em within faz o que eu chamo de "desempacotar a lista". O segundo argumento é uma lista; a definição de within desempacota os dois primeiros, chamando-os de a e b.

next computa a próxima aproximação da raiz quadrada de N com aproximação anterior x segundo o método de Newton-Raphson.

sqrt computa a raiz quadrada de um número conforme uma tolerância e e um chute inicial a0; sua definição aplica within a repeat, e repeat a next.

sqrt basicamente avalia within à lista gerada por repeat , e repeat gera a lista de resultados de next.

Este programa, segundo a intuição de um programador acostumado a linguagens imperativas, nunca termina, porque repeat nunca termina de gerar a lista infinita.

Porém, lazy evaluation garante que esse programa termina -- garante que repeat será avaliado apenas o número de vezes necessária para que within se satisfaça. Eu entendo que o segredo disso está no momento em que o interpretador avalia o "desempacotamento" de uma lista, porque este é o momento em que o processamento exige a geração de mais um elemento.

Isso é mesmo sensacional. Como seriam esses pequenos componentes em C++0x?

Vamos começar brincando com uma versão muito eficiente de abs, o que não tem nada a ver com o problema em questão.

template
auto abs (Number x) -> typename std::enable_if< std::is_signed::value, Number>::type
{
return x < 0 ? -x : x ;
}

template
auto abs (Number x) -> typename std::enable_if< ! std::is_signed::value, Number>::type
{
return x;
}

A notação acima é a nova notação para funções em C++0x, onde a especificação do retorno fica depois da lista de argumentos.

A definição de abs faz uso de SFINAE para sobrecarregar dois templates, de outro modo indistinguíveis, usando std::enable_if.

Assim, abs pode se reduzir a nada quando nem mesmo faz sentido que o número possua um sinal.

Em seguida, vamos chamar as listas de Range e declarar a forma geral de uma função unpack.

template
auto unpack (Range& r) -> Value;

template
auto unpack (Sequence& s) -> decltype(s.front())
{
typename Sequence::value_type v = s.front();
s.pop_front();
return v;
}

Definimos o significado de unpack providenciando uma sobrecarga, exclusiva para Containers da STL, que faz o que deve fazer. Em português, unpack resulta o elemento à esquerda e modifica a lista para conter o resto.

Assim, definimos within:

namespace detail
{

template
auto within (Number eps, Number a, Number b, Range rest) -> Number
{
    if (abs(a - b) <= eps) return b;
    else {
    const Number c = unpack(rest);
    return within(eps, b, c, rest);
    }
}

}

template
// requires(ValueType(Range) == Number)
auto within (Number eps, Range list) -> Number
{
const Number a = unpack(list);
const Number b = unpack(list);
return detail::within(eps, a, b, list);
}

within desempacota a e b e delega para uma subrotina; a subrotina faz o que se espera. Observe que a lista a processar é um desses tais Ranges.

O componente equivalente a repeat deve gerar esse Range.

namespace detail
{
template
struct repeat_range
{
    Function f;
    Value x;

    auto operator() () -> decltype(f(x))
    {
      return x = f(x);
    }
};

template
auto unpack (repeat_range& r) -> decltype(r())
{
    return r();
}
}

template
// requires(UnaryFunction(Function) && Domain(Function) == Value)
auto repeat (Function f, Value a) -> detail::repeat_range
{
return detail::repeat_range { f, a };
}

Um Range é um objeto especial, que representa a lista; definimos um repeat_range que continuamente aplica uma função, e definimos unpack para este Range. (Observe como repeat_range usa o último valor gerado na geração do próximo.)
A função repeat é utilitária e constrói o Range com os argumentos certos.

A notação de construção usada na definição de repeat também é nova, e generaliza a inicialização entre structs C e objetos C++.

Por último, implementamos a função importante para a aplicação, sqrt. Escolhi ocultar o equivalente a next porque a mim não interessa muito.

namespace detail
{
template
auto sqrt (Number N, Number x) -> Number
{
    return (x + (N / x)) / 2;
}
}

template
auto sqrt (Number N, Number x, Number eps) -> Number
{
return
    within(eps,
      repeat(
        [=] (Number x) { return detail::sqrt(N, x); },
        x
      )
    );
}

Agora, isso é punk. A função no detail computa a próxima aproximação é trivial. O driver principal, por outro lado, é complexo.

Em primeiro lugar, aquela notação esquisita ali é uma expressão lambda. Para todos os efeitos, a avaliação desta expressão produz uma função, que vira argumento para repeat.

repeat, portanto, aplicará uma função lambda -- que por sua vez computa a próxima aproximação da raiz de N com chute x -- ao valor inicial x. O símbolo [=] significa que os nomes dentro do lambda se tornam cópias por valor dos objetos de mesmo nome no escopo maior.

repeat, como vimos antes, produz um Range, sobre o qual within opera. E within procura um par de valores neste Range -- aplicando unpack quando necessário -- em busca de um par cuja diferença seja menor que eps.

Assim, nesmo programa C++, simulamos com significativo esforço a lazy evaluation funcional, para computar a raiz quadrada. Usando __attribute__((const)) esse programa deve otimizar até o Nirvana, mas eu não verifiquei.

O programa esparramado no texto acima funciona de verdade com o GCC 4.5 e provavelmente funciona também com o ICC 11.1.

Interface Programador-Máquina

2010-03-18T22:21:52+00:00

Ouvi algo interessante em uma aula do curso 6.00 do MIT, vendo o vídeo no celular, sobre a sobrecarga de operadores; o professor argumentava que essa era uma carecterística boa da linguagem de programação porque permitia uma interface consistente de programação.

Esse é um uso interessante das palavras; em geral, dizemos interface para nos referir a um contrato de comunicação entre dois pedaços de código executável.

Realmente, da mesma forma como essa representação é um contrato ou protocolo entre dois pedaços de código executável que se comunicam, também há contrato ou protocolo entre quaisquer duas coisas que se comunicam, como por exemplo o programador e a máquina.

Isso nos leva a pensar na linguagem de programação, como regra de sintaxe e semântica, como uma interface; e em pensar na qualidade de uma linguagem de programação como a qualidade dessa interface.

O meta-caso-de-uso que essa interface pretende realizar é "expressar o programa que eu tenho em mente"; o componente que implementa essa interface é o compilador. Realmente é o compilador, e não a máquina física; o compilador, sob essa ótica, é a máquina abstrata, que interpreta a expressão do programa e faz algo de útil. De fato, normas como C e C++ descrevem o efeito do programa sobre uma máquina abstrata.

Então, o que há com y + x ?

Há interface de alta qualidade na medida em que + significa o que você aprendeu ao longo de uma década de ensino de aritmética. Este julgamento fundamenta ambos os lados da divergência sobre se este símbolo deve ou deve não ser sobrecarregado para significar "concatenar duas strings". O lado deve entende que qualquer indivíduo compreende + como "juntar", "unir", "somar". O lado deve não entende que concatenar é "pôr um na frente do outro", que não possui a propriedade de associatividade.

O tema da aula no vídeo que eu estava assistindo era classes em Python e uma introdução aos abstract data types. Acho essa discussão pertinente porque ADTs são um conceito de meta-linguagem, e um ADT existe apenas na mente do programador. Faço essa distinção como a distinção entre o conjunto dos inteiros de que trata a álgebra e o tipo int da linguagem de programação.

Quando o programador representa um ADT na linguagem de programação como uma classe, ele por sua vez oferece a outro programador uma interface de programação. O usuário do ADT, por assim dizer, escreverá programas que dissertam sobre esse ou aquele valor. Assim, eu concordo com o professor: se eu estou descrevendo um ADT numérico, é muito conveniente poder sobrecarregar o símbolo + e permitir aos meus usuários falar sobre coisas na forma de y + x .

Agora, há algo de estético nessa história toda. Suponha que por qualquer motivo você não pode usar o símbolo + . Que nome você escolheria, add ou sum? Ou plus? add tem algo de imperativo, enquanto sum é um substantivo; ambos sugerem uma leitura diferente da expressão; e plus é apenas o nome de um símbolo!

add(y, x) // add y to x

sum(y, x) // the sum of y and x

plus(y, x) // y plus x

O Elements of Programming argumenta que o projetista de um ADT deve se esforçar para determinar uma "base computacional" para o ADT, um conjunto mínimo de operações básicas e eficientes que permitem ao programador expressar todos os programas úteis possíveis que discursam sobre seus valores.

Este é o aspecto aritmético de uma interface programador-máquina, por assim dizer; uma boa escolha de nomes é seu aspecto estético, talvez. Parte do processo de decifragem ou aprendizagem de um sistema -- rotina de um arqueólogo de sistemas legados -- é justamente aprender os símbolos na caótica cultura desse sistema, que podem ou não fazer sentido como se espera de um sistema "fresquinho".

Parte do esforço hercúleo em se convencer de um teorema de matemática avançada é justamente ler a notação simbólica usada -- que, sendo altamente abstrata, é frequentemente irreprodutível em linguagem natural. (E às vezes a diferença entre um signo e outro é meia dúzia de três ou quatro pixel.)

Produzir uma interface programador-máquina eficiente é sempre bom, mas programadores em execesso usam a eficiência como desculpa para produzir interfaces incompreensíveis. E no fim das contas todos nós sabemos que o custo de um projeto de sistema convencional é dominado por seu custo de manutenção.

Sistemas de Tempo Real – Part 1

2010-03-16T02:33:38+00:00

Neste post vou falar um pouco sobre Sistemas de Tempo Real, as principais motivações para sua utilização, sua arquitetura básica e alguns critérios para a escolha de um RTOS disponível no mercado.

Sexto Encontro de Programadores C/C++

2010-03-10T11:55:35+00:00

Começo de ano é sempre a mesma correria. Depois que a gente começa a se acostumar com a idéia de que o feriadão de Natal e Ano Novo acabaram, logo vem o carnaval e desanda tudo. Aproveitei este início de ano para tirar merecidas férias, já que finalmente meu curso de Engenharia da Computação terminou. Como um belo start para minha reintegração à sociedade, nada melhor que uma viajem ao nordeste brasileiro. Semanas antes desta viajem fiquei sabendo do novo encontro da comunidade de programadores C/C++. Por causa da viagem eu perderia o evento.

Um mês se passou e semana passada vi que o evento foi adiado para o próximo dia seis de março. Muito boa notícia já que além de poder participar do evento também vou falar um pouquinho. Já participei de outro encontro de programadores e fiquei muito feliz de poder falar para tantas pessoas sobre esse assunto tão misterioso para muitos, que é o desenvolvimento de drivers para Windows.

Sob meu ponto de vista os resultados foram muito bons. A palestra deu uma introdução ao assunto de desenvolvimento de drivers e obviamente os 60 minutos de palestra não foram suficientes para explicar o assunto com detalhes, mas foi interessante mostrar a ponta do iceberg e poder responder a algumas perguntas dos presentes. Eu escrevi um post que comenta sobre o encontro, mas recomendo o post do meu amigo Lesma que ficou muito bom.

Lidando com Memória Virtual em Drivers

Bem, neste novo encontro não vou dar novamente uma introdução ao assunto, mas vou comentar sobre algumas carasterísticas e curiosidades sobre Memória Virtual no desenvolvimento de drivers. Entenda que não vou fazer um resumo do capítulo 9 do Windows Internals, "Memory Management" que fala sobre Page Table Entries e Working Sets, mas sim demonstrar que, diferentes de uma aplicação User-Mode, drivers precisam estar cientes dos conceitos fundamentais de memória virtual e paginação, controlando paginação de objetos e atendendo à requisítos de paginação de memória e espaço de endereçamento.

Os tópicos a serem discutidos na palestra serão os seguintes:

Overview de Memória Virtual e Paginação.
Operações de I/O e manipulação de Buffers.
Prioridade de thread e acesso à memória.
Pools de alocação, Tags e Quotas.
Evitando Fragmentação.
Drivers no caminho da paginação.
Controlando paginação de funções.
Obtendo endereços reais de memória.
Dispositivos de acesso direto à memória (DMA).
Recursos do Driver Verifier.
Hands on: Operações de memórias por drivers no WinDbg.
Dúvidas.

Esta é a página oficial do evento e as inscrições estão abertas. Até lá!

Download dos slides

Problema os ícones especiais do Nautilus

2010-03-09T00:02:06+00:00

Não sei por que cargas d'água o ícone especial da pasta "Vídeos" na minha pasta de usuário no Nautilus perdeu a graça.

O Nautilus, para pastas especiais como "Imagens", "Música" etc. usa ícones especiais com umas figuras bem legais, como um trecho de rolo de filme pro "Vídeos".

Depois de muito procurar, percebi que o responsável pelo tema dos ícones usava alguma fonte de informação pra decidir quais pastas são especiais e aplicar ícones especiais -- ou não aplicar, de acordo com o tema.

Depois de procurar ainda mais, descobri esta fonte de informação no Fedora 12:

$HOME/.config/user-dirs.dirs

Realmente a linha de configuração para a pasta de vídeos estava com o nome errado.

techberto

2010-03-08T00:48:15+00:00

Em 2007 dois pesquisadores britânicos teorizaram um dispositivo que eles chamaram de ”alçapão de arco-íris”, sendo um dispositivo composto por uma lenteque seria responsável pela reflexão, dispersão e refração de um feixe de luz para o interior do artefato que teria uma placa com várias camadas de espelhos de metamateriais que poderia capturar o feixe de luz, não permitindo sua dispersão:

Stopping light in metamaterials: the trapped rainbow

Na época vários grupos ao redor do mundo, acreditando na teoria trabalharam alucinadamente tentando criar um protótipo funcional deste dispositivo e no final de 2009 um grupo de pesquisadores americanos conseguiu obter sucesso e com um aparato muito simples provaram o conceito da “armadilha de arco-íris”, demonstrando que os físicos britânicos estavam certos:

Rainbow trapped for the first time

Quando comentei este feito com um colega pela primeira vez, logo que via a notícia na semana que ela foi publicada na New Scientist, ele fez aquele clássico comentário: este pessoal não tem nada mais importante para fazer?

Bem, esta técnica poderá ser útil para armazenar informações de forma puramente ótica, algo que irá revolucionar a computação (e talvez a vida) no futuro, eliminando a necessidade de conversões de sinais óticos em eletrônicos, facilitando o processo de manipulação de fótons e proporcionando a criação de meios de armazenamento de informações revolucionário. E considerando que em 2009 também surgiu o primeiro processador quântico fotônico autêntico podemos elucubrar que parte do futuro da computação está na fotônica e esta nova descoberta é certamento um grande marco.

Quer algo mais útil do que isto?

Ruminando e divagando sobre este assunto com um amigo este final de semana, ele lembrou do filme Minority Report e de um cartão de armazenamento que parecia que as imagens estavam armazenadas de modo fotônico, visto que elas podiam ser parcialmente vistas sem mesmo estar no seu respectivo driver de leitura.

Com a evolução das pesquisas do grafeno, dos metamateriais e outros daqui a alguns anos silício será coisa do passado, se bobear armazenamento magnético também e por consequencias do entrelaçamento quântico a velocidade da luz irá parecer velocidade tartarugal, imaginou como será a computação e o futuro das telecomunicações?

No final de 2008, escrevi um post onde eu brincava que em 2050 “telepatia sintética” seria coisa do passado, bom, o DARPA tem financiado pesquisas nesta área e isto da tem a ver com ESP, visto que a tecnologia é puramente baseada em neurociência e telecomunicações, sendo-se que o artefato que possibilitará tal feito é puramente um dispositivo de neuroengenharia, área que tende a evoluir muito no futuro e aposto que vários dos “neuroengenheiros” serão nascerão a partir do fascínio pelos brinquedos Mindflex e o Star Wars Force Trainer.

Mas o quê a armadilha de arco-íris e a q-telepatia tem em comum? A resposta é: computação quântica. A neuroengenharia continuará presente, porém o processador quântico será peça fundamental.

E breve, os neurohackers já não serão mais atores da ficção cyberpunk e sim do novo contexto neurotecnológico do balaio de gato que será o admirável mundo novo da computação, fico imaginando a segunda (ou será terceira?) geração que será os q-neurohackers.

PS3 e o bug do ano bissexto

2010-03-05T02:12:34+00:00

Como profissional da área de tecnologia, sou um leitor assíduo de notícias da área. Gosto em especial de dois sites, o Gizmodo [1] e o Engadget [2]. Na segunda pela manhã uma notícia me chamou a atenção, milhões de videogames PlayStation 3 da Sony haviam parado de funcionar da noite para o dia. No decorrer do dia, descobriu-se que o problema estava no relógio interno do aparelho, que identificou 2010 como um ano bissexto, e passou do dia 28/02 para 29/02 ao invés de 01/03. Como diversas funções do videogame dependiam do valor correto da data do sistema para funcionar, o aparelho começou a apresentar vários problemas.

Namespaces: colocando cada coisa em seu lugar

2010-03-02T23:22:55+00:00

Evitando conflitos de nomes namespace é uma palavra reservada do C++ que implementa um mecanismo capaz de expressar agrupamento lógico. Em outras palavras, se um conjunto de declarações estão logicamente associadas de acordo com algum critério, elas podem ser colocadas juntas no mesmo namespace para expressar este fato. Um namespace também pode ser chamado de um [...]

Instalando o J2EE da Sun no Fedora 11

2010-02-25T23:22:46+00:00

Dois pequenos probleminhas.

Em primeiro lugar, o instalador reclama dizendo "Expression NOME_DO_PRODUTO is undefined on line 86, column 289 in /templates/components.ftl."

O problema é o código de localização; execute o instalador com LANG=C e pronto.

Em segundo lugar, eu uso um hostname personalizado meus sistemas -- este aqui se chama elisa. Nunca me dei ao trabalho de colocar o nome no /etc/hosts porque o mDNS funciona muito bem sem isso.

O instalador não gosta dessa situação e reclama em uma caixa de diálogo sobre "host name invalid".

Já estou usando esse esquema em outro lugar -- GlassFish J2EE 6 com Eclipse Galileo no Fedora 11 -- e funciona muito bem.

Escrevendo Filtros

2010-02-22T16:38:45+00:00

Vamos brincar de algo mais interessante agora. Obviamente ainda vamos dar passos pequenos para não nos perder com tantos detalhes. Hoje falarei sobre filtros de drivers. O IoManager do Windows nos permite adicionar funcionalidade a determinados drivers sem que tenhamos que substituí-lo. Um exemplo clássico seria um driver de criptografia de arquivos. Você não precisa escrever um novo driver de file system para que se tenha tal funcionalidade. Você pode simplesmente escrever um filtro que ficaria entre o driver de file system e o restante do sistema.

Na figura abaixo podemos observar o fluxo de IRPs que vão do IoManager para um certo driver, um filtro é instalado sobre o driver existente e passa a receber as IRPs no lugar do driver original. Com isso o filtro tem a oportunidade de alterar os parâmetros das IRPs recebidas, ou logar a atividade do driver original, ou duplicar solicitações do sistema para esse driver, ou mesmo negar serviço do driver original.

Numa operação de escrita, um filtro poderia criptografar os dados antes de enviá-los ao driver original, e de maneira similar, numa operação de leitura o filtro poderia decriptografar dados antes de entregá-los ao sistema.

Ainda não vai ser desta vez que construiremos um filtro de criptografia de file system. Filtros de criptografia de arquivos em tempo real estão entre os drivers mais complexos a serem escritos. Vamos escolher um driver mais simples, pra não dizer um bem besta, para aplicar os conceitos básicos demonstrados aqui.

Por falar em driver besta, vamos utilizar o driver deste post que já foi visto aqui. Este driver simplesmente armazena uma lista de strings enviadas por uma aplicação em operações de escrita. Tais strings são retornadas à aplicação em operações de leituras.

Escrevendo a DriverEntry

Como vimos neste outro post, uma das das coisas que a função DriverEntry() faz num driver comum é setar as Dispatch Routines que o driver vai atender para certo dispositivo. Para isso deve-se preencher o array de Major Functions que fica na estrutura DRIVER_OBJECT.

    //-f--> Seta as dispatch routines do driver.
    pDriverObj->MajorFunction[IRP_MJ_CREATE] = OnCreate;
    pDriverObj->MajorFunction[IRP_MJ_CLEANUP] = OnCleanup;
    pDriverObj->MajorFunction[IRP_MJ_CLOSE] = OnClose;
    pDriverObj->MajorFunction[IRP_MJ_READ] = OnRead;
    pDriverObj->MajorFunction[IRP_MJ_WRITE] = OnWrite;

No caso do nosso filtro de exemplo, queremos apenas monitorar a atividade do driver ao qual estamos atachados, dessa forma teremos sempre que encaminhar quaisquer IRPs recebidas ao driver de baixo. Uma forma simples e comum de fazer isso é setar todas dispath routines para uma única função. Essa função se encarrega de simplesmente logar a solicitação recebida e passá-la a diante.

Se dermos uma olhada na definicão de IRP_MJ_CREATE e seus amigos, veremos o seguinte trecho do arquivo wdm.h.

//
// Define the major function codes for IRPs.
//
 
 
#define IRP_MJ_CREATE                   0x00
#define IRP_MJ_CREATE_NAMED_PIPE        0x01
#define IRP_MJ_CLOSE                    0x02
#define IRP_MJ_READ                     0x03
#define IRP_MJ_WRITE                    0x04
#define IRP_MJ_QUERY_INFORMATION        0x05
#define IRP_MJ_SET_INFORMATION          0x06
#define IRP_MJ_QUERY_EA                 0x07
#define IRP_MJ_SET_EA                   0x08
#define IRP_MJ_FLUSH_BUFFERS            0x09
#define IRP_MJ_QUERY_VOLUME_INFORMATION 0x0a
#define IRP_MJ_SET_VOLUME_INFORMATION   0x0b
#define IRP_MJ_DIRECTORY_CONTROL        0x0c
#define IRP_MJ_FILE_SYSTEM_CONTROL      0x0d
#define IRP_MJ_DEVICE_CONTROL           0x0e
#define IRP_MJ_INTERNAL_DEVICE_CONTROL  0x0f
#define IRP_MJ_SHUTDOWN                 0x10
#define IRP_MJ_LOCK_CONTROL             0x11
#define IRP_MJ_CLEANUP                  0x12
#define IRP_MJ_CREATE_MAILSLOT          0x13
#define IRP_MJ_QUERY_SECURITY           0x14
#define IRP_MJ_SET_SECURITY             0x15
#define IRP_MJ_POWER                    0x16
#define IRP_MJ_SYSTEM_CONTROL           0x17
#define IRP_MJ_DEVICE_CHANGE            0x18
#define IRP_MJ_QUERY_QUOTA              0x19
#define IRP_MJ_SET_QUOTA                0x1a
#define IRP_MJ_PNP                      0x1b
#define IRP_MJ_PNP_POWER                IRP_MJ_PNP      // Obsolete....
#define IRP_MJ_MAXIMUM_FUNCTION         0x1b

Note que existe uma definição especial, a IRP_MJ_MAXIMUM_FUNCTION, que indica o índice máximo da tabela de dispatch rotines. Utilizaremos um loop simples para fazer com que todas rotinas em nossa tabela aponte para uma única rotina que daremos o nome de OnForwardDispatch.

    //-f--> Seta todas as dispatch routines do driver para
    //      uma que encaminhe a IRP para o driver original.
    for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++)
        pDriverObj->MajorFunction[i] = OnForwardDispatch;

Veremos a implementação dessa rotina mais tarde. O próximo passo que daremos aqui é localizar o device ao qual vamos nos atachar. Para fazer isso, usaremos a rotina IoGetDeviceObjectPointer(). Ela basicamente recebe o nome do device e nos retorna uma referência para ele.

NTSTATUS 
  IoGetDeviceObjectPointer(
    IN PUNICODE_STRING  ObjectName,
    IN ACCESS_MASK  DesiredAccess,
    OUT PFILE_OBJECT  *FileObject,
    OUT PDEVICE_OBJECT  *DeviceObject
    );

Observe que são dois os parâmetros de saída dessa rotina. Além do ponteiro para o device object ainda recebemos um ponteiro para um file object. Já ví algumas pessoas fazerem confusão com estes dois parâmetros, então vou dar alguma ênfase nisso.

O ponteiro para o file object representa uma conexão criada entre seu driver e o device que você abriu. Como vimos neste post, um file object é criado para respresentar conexões entre aplicações user mode e seu driver. Aplicações usam esse file object através do handle obtido na chamada à rotina CreateFile(). Aqui temos algo similar, mas apenas o Kernel foi envolvido. Isso significa que se você quizesse, você poderia lançar IRPs para o device solicitando operações como uma aplicação faria, mas não veremos isso hoje, ainda temos um filtro para terminar.

A grande confusão referente a estes dois parâmetros é com relação às referências entre os objetos. Na documentação vemos que o chamador desta rotina deverá liberar a referência que ganhou quando o device não for mais utilizado. Fazemos isso simplesmente usando a rotina ObDereferenceObject().

VOID 
  ObDereferenceObject(
    IN PVOID  Object
    );

"Já sei! Como estamos obtendo uma referência para um device object, então devo passar o ponteiro do device object. Certo?"

Er... Na verdade não. O file object é uma referência indireta ao device object. Conforme a figura abaixo, se imaginarmos que os contadores de referência apenas dizem respeito às nossas referências, quando chamarmos ObDereferenceObject() para o file object, seu contador de referência cairia para zero e uma nova chamada para ObDeferenceObject() seria feita indiretamente para o device object, fazendo com que seu contador de referência também caisse para zero destruindo o objeto.

Depois de obter o ponteiro para o device destino, teremos que criar nosso próprio device, o qual receberá as IRPs no lugar do device original. Para isso ainda usaremos a rotina IoCreateDevice() como faziamos com drivers, mas com algumas diferenças.

A primeira diferença é que seu device normalmente não tem nome. É possível criar filtros com nomes, mas isso pode gerar uma falha de segurança. Isso acontece pois quando um nome é consultado no Object Manager, suas regras de segurança são avaliadas. Quando criamos um filtro com nome, criamos a possibilidade de o mesmo objeto ser obtido por um nome diferente e que pode ter regras menos restritivas de segurança. Mas esse é outro assunto.

Quando criamos um device, precisamos informar o tamanho do device extension.

"O que vem a ser um device extension?"

Device extension é simplesmente um espaço de memória que está associada ao device object. Tal espaço normalmente mantém informações que dizem respeito ao device. O endereço do device ao qual estamos atachados normalmente fica no device extension. Desta forma, podemos definir que nosso device extension deve conter a seguinte estrutura.

//-f--> Nosso device externsion conterá apenas o endereço
//      do device ao qual estamos atachados.
typedef struct _DEVICE_EXTENSION
{
    PDEVICE_OBJECT  pNextDeviceObj;
 
} DEVICE_EXTENSION, *PDEVICE_EXTENSION;

Depois de criar nosso device object, configuramos o método de I/O copiando os bits DO_BUFFERED_IO e DO_DIRECT_IO. Se você não se lembra destes bits, dê uma olhada neste post. O filtro deve propagar a escolha do driver original e o driver tem o compromisso de não mudar método durante seu tempo de vida.

Agora estamos prontos para nos atachar ao device escolhido, e faremos isso utilizando a rotina IoAttachDeviceToDeviceStackSafe() para fazer nosso device entrar na pilha de dispositivos.

NTSTATUS
  IoAttachDeviceToDeviceStackSafe(
    IN PDEVICE_OBJECT  SourceDevice,
    IN PDEVICE_OBJECT  TargetDevice,
    IN OUT PDEVICE_OBJECT  *AttachedToDeviceObject 
    );

Com esta chamada obteremos o ponteiro do device ao qual estaremos atachados, esse device será o próximo device que receberá a IRP depois que você a passar a diante.

"Mas Fernando, nós já não temos o ponteiro do device de destino?"

Muito bem, quando você obtém o ponteiro para um device, você teoricamente não sabe se existem filtros já atachados sobre ele. O ponteiro que você recebe nesta rotina pode não ser o ponteiro para o device de destino. Na figura abaixo podemos entender como essa relação acontece.

"Fernando, existe uma versão unsafe desta rotina?"

Na verdade existe, a IoAttachDeviceToDeviceStack().

PDEVICE_OBJECT 
  IoAttachDeviceToDeviceStack(
    IN PDEVICE_OBJECT  SourceDevice,
    IN PDEVICE_OBJECT  TargetDevice
    );

Ela é considerada unsafe por causa de uma pequena janela de tempo que pode causar um race condition. Repare que a diferença entre estas rotinas é a forma de obter o endereço do próximo device. Na versão original, este endereço é obtido pelo retorno na função. Se colocarmos essa função para rodar em câmera lenta veremos os seguintes passos.

Seu device é atachado à pilha de dispositivos.
O endereço do próximo device é retornado pela função.
Seu driver recebe este endereço no retorno da função e atualiza o device extension.
IRPs começam a chegar e seu driver às encaminham para o próximo device da lista.

Tudo parece lindo e até dá a impressão de que tudo vai funcionar muito bem em qualquer situação, mas desenvolvedor de driver é um bixo treinado para buscar race conditions. Dê mais uma olhada na sequência, mas agora em câmera super lenta. Com essa câmera super lenta agora podemos observar os passos que podem ocorrer entre os passos 2 e 3.

Seu device é atachado à lista de dispositivos.
O endereço do próximo device é retornado pela função.
1. Sua thread é interrompida e uma IRP lançada por uma aplicação que roda em paralelo começa sua viagem por essa pilha de dispositivos.
2. Seu device, que já está atachado, recebe a IRP e tenta encaminhá-la ao device de baixo.
3. Oops! Nosso device extension ainda não foi atualizado com tal endereço.
4. Seu driver se lembra de quando era uma criança e de tudo o que vivera até ali.
5. Ele decide entrar de vez naquela dança e enviar a IRP para um device cujo ponteiro ainda é NULL causando um BSOD.
"Jeremias, eu sou homem. Coisa que você não é e não atiro pelas costas não..."

Enfim, entenda que mesmo que você utilize o retorno da rotina IoAttachDeviceToDeviceStack() diretamente para atualizar seu device extension, ainda assim existe uma janela de tempo em que seu device estará atachado, mas que o valor ainda não foi atualizado no device extension. Isso porque o valor de retorno de uma rotina vem por um registrador. Pegar o valor desse registrador e atualizar uma variável ainda dá chances para o azar.

    //-f--> ----==== NÃO COPIE ISSO ====----
    //      Aqui ainda temos uma janela de tempo entre o device ser
    //      atachado e o valor de pNextDeviceObj ser atualizado.
    pDeviceExt->pNextDeviceObj = IoAttachDeviceToDeviceStack(pMyDeviceObj,
                                                             pTargetDeviceObj);

A rotina IoAttachDeviceToDeviceStackSafe() faz o sistema interromper o fluxo de IRPs nesta pilha até que a variável apontada pelo ponteiro de saída seja atualizado. Por essa razão, o endereço passado nesta rotina deve ser o endereço final da variável onde este valor será armazenado, que em nosso caso é pDeviceExt->pNextDeviceObj sem passar por variáveis intermediárias.

Esses detalhes são importantes e farão você entender que usar a versão safe desta rotina não é garantia de que tudo dará certo. Imagine que usando a versão safe você receba o endereço do próximo device em uma variável local e depois atualize seu device extension. Esse é um daqueles típicos casos que é necessário substituir aquele componente que fica entre o teclado e a cadeira.

Acha preciosismo? Tente ler o capítulo 5 do livro "Programming the Microsoft Windows Driver Model" onde Walter Oney fala sobre como lidar com cancelamento de IRPs.

Depois de atacharmos nosso device já podemos liberar a referência obtida por IoGetDeviceObjectPointer() utilizando a rotina ObDereferenceObject(), já que a rotina IoAttachDeviceToDeviceStackSafe() já garantiu a referência até que essa ligação seja desfeita.

Muito bem. Pra quem não conseguiu entender quase nada do que eu disse, segue o código fonte da implementação da nossa DriverEntry() de exemplo. Sabe como é cabeça de programador, as vezes um if vale mais que mil páginas de explicação.

/****
***     DriverEntry
**
**      Ponto de entrada do driver.
**      Bem vindo ao inferno.
*/
extern "C"
NTSTATUS
DriverEntry(IN PDRIVER_OBJECT  pDriverObj,
            IN PUNICODE_STRING pusRegistryPath)
{
    NTSTATUS            nts;
    PDEVICE_OBJECT      pMyDeviceObj;
    int                 i;
    UNICODE_STRING      usDeviceName;
    PDEVICE_OBJECT      pTargetDeviceObj;
    PFILE_OBJECT        pFileObj;
    PDEVICE_EXTENSION   pDeviceExt;
 
    //-f--> Seta a rotina de descarga do driver.
    pDriverObj->DriverUnload = OnDriverUnload;
 
    //-f--> Seta todas as dispatch routines do driver para
    //      uma que encaminhe a IRP para o driver original.
    for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++)
        pDriverObj->MajorFunction[i] = OnForwardDispatch;
 
    //-f--> Inicializamos a string com o nome do device ao
    //      qual queremos nos atachar.
    RtlInitUnicodeString(&usDeviceName,
                         L"\\Device\\StringList");
 
    //-f--> Obtemos o ponteito do device de destino
    nts = IoGetDeviceObjectPointer(&usDeviceName,
                                   FILE_READ_DATA,
                                   &pFileObj,
                                   &pTargetDeviceObj);
    if (!NT_SUCCESS(nts))
        return nts;
 
    //-f--> Criamos nosso device object
    nts = IoCreateDevice(pDriverObj,
                         sizeof(DEVICE_EXTENSION),
                         NULL,
                         pTargetDeviceObj->DeviceType,
                         pTargetDeviceObj->Characteristics,
                         FALSE,
                         &pMyDeviceObj);
    if (!NT_SUCCESS(nts))
    {
        //-f--> Oops!
        ObDereferenceObject(pFileObj);
        return nts;
    }
 
    //-f--> Obtem nosso DEVICE_EXTENSION
    pDeviceExt = (PDEVICE_EXTENSION)pMyDeviceObj->DeviceExtension;
 
    //-f--> Utiliza o mesmo método de IO do driver original
    pMyDeviceObj->Flags |= pTargetDeviceObj->Flags & (DO_BUFFERED_IO | DO_DIRECT_IO);
 
    //-f--> Aqui nosso driver entra na pilha de dispositivos
    nts = IoAttachDeviceToDeviceStackSafe(pMyDeviceObj,
                                          pTargetDeviceObj,
                                          &pDeviceExt->pNextDeviceObj);
    if (!NT_SUCCESS(nts))
    {
        //-f--> Oops!
        IoDeleteDevice(pMyDeviceObj);
        //-f--> Aqui não está faltando um return.
    }
 
    //-f--> Independente de estarmos atachados ou não, devemos liberar
    //      a referência obtida do device de destino.
    ObDereferenceObject(pFileObj);
    return nts;
}

Escrevendo a OnDriverUnload

Aqui é onde a festa acaba, antes de o nosso driver ser descarregado pelo sistema, teremos que remover nosso device da pilha de dispositivos e destruí-lo. (Risadas maléficas)

O código aqui é simples e não requer explicações se você for capaz de ler os comentários contidos nele.

/****
***     OnDriverUnload
**
**      Rotina de descarga do driver.
*/
VOID
OnDriverUnload(IN PDRIVER_OBJECT  pDriverObj)
{
    PDEVICE_OBJECT      pMyDeviceObj;
    PDEVICE_EXTENSION   pDeviceExt;
 
    //-f--> Nosso device está na lista de devices criados por este driver
    //      então vamos obtê-lo simples assim:
    pMyDeviceObj = pDriverObj->DeviceObject;
 
    //-f--> Aqui obtêmos o device extension.
    pDeviceExt = (PDEVICE_EXTENSION)pMyDeviceObj->DeviceExtension;
 
    //-f--> Aqui removemos nosso device da pilha passando o endereço do
    //      próximo device para a rotina abaixo.
    IoDetachDevice(pDeviceExt->pNextDeviceObj);
 
    //-f--> Agora podemos destruir nosso device (risadas maléficas)
    IoDeleteDevice(pMyDeviceObj);
}

"Fernando, nosso driver é forçado a se descarregar quando o driver original é descarregado?"

Essa é a filosofia do WDM, drivers são carregados automáticamente quandos seus dispositivos são detectados e descarregados quando seus dispositivos são desativados ou removidos. Os filtros seguem as mesmas regras e são carregados/descarregados basendo-se nestes eventos.

Mas não é isso o que acontece aqui. Os drivers de exemplo que uso neste blog são do modelo Legacy, e não WDM. No modelo Legacy, drivers são iniciados seguindo sua ordem de carga no registry, e não tem nada a ver com a detecção do seu dispositivo. Os filtros precisam iniciar depois dos drivers originais, e isso também é controlado pela sua ordem de carga. Este post fala sobre a ordem de carga dos legacy drivers.

"Tá! Falou, falou e não respondeu minha pergunta. O que acontece se eu solicitar a descarga do driver original enquanto houver um filtro atachado sobre ele?"

A descarga dos drivers que formam uma pilha deve ocorrer de forma inversa à sua carga. Neste caso o filtro deve ser descarregado antes do driver original, desempilhando os devices de cima para baixo. Caso o driver original receba uma solicitação de descarga enquanto ainda hoverem referências a seus devices, seja por um filtro ou por uma aplicação, a descarga é adiada até que suas referências sejam desfeitas. Até lá, a tentativa de obter novas referências para um device que recebeu a solicitação de descarga serão negadas.

Escrevendo Dispatch Routines

As dispatch routines de um filtro também são diferentes das dispatch routines de um driver. Apensar de elas poderem completar uma IRP chamando IoCompleteRequest(), elas normalmente repassam a socilitação adiante utilizando a rotina IoCallDriver(). Vou falar mais sobre o comportamento das dispatch routines de um filtro em posts futuros. Neste filtro de exemplo vamos apenas logar a atividade e repassar a solicitação ao próximo driver.

Quando falamos em repassar uma solicitação estamos na verdade falando de repassar IRPs. A leitura deste outro post é essencial para o que vamos fazer na implementação de nossas dispatch routines.

Para acabar esse post ainda nessa vida, segue código da implementação de nossa dispatch routine. Depois de ler o post sobre IRPs que acabei de recomendar, ler os comentários deste código devem ser suficientes para entender tudo o que foi feito aqui, ou não.

/****
***     OnForwardDispatch
**
**      Nossa dispatch routine simplesmente loga a IRP
**      recebida e repassa a solicitação adiante.
**
*/
NTSTATUS
OnForwardDispatch(IN PDEVICE_OBJECT    pDeviceObj,
                  IN PIRP              pIrp)
{
    PDEVICE_EXTENSION   pDeviceExt;
    PIO_STACK_LOCATION  pStack;
 
    //-f--> Obtém ponteiro para o device extesion
    pDeviceExt = (PDEVICE_EXTENSION)pDeviceObj->DeviceExtension;
 
    //-f--> Obtém stack location corrente
    pStack = IoGetCurrentIrpStackLocation(pIrp);
 
    //-f--> Manda o nome na major routine da IRP
    ASSERT(pStack->MajorFunction <= IRP_MJ_MAXIMUM_FUNCTION);
    DbgPrint("[StringFilter] : %s\n", g_szMajorNames[pStack->MajorFunction]);
 
    //-f--> Como não estamos modificando nada na stack location,
    //      vamos deixá-la para que o próximo device a use.
    IoSkipCurrentIrpStackLocation(pIrp);
 
    //-f--> Encaminha a IRP para o próximo device.
    return IoCallDriver(pDeviceExt->pNextDeviceObj,
                        pIrp);
}

Caso não tenham entendido nada, não esqueçam de me mandar um e-mail expondo suas dúvidas (sem ofenças pessoais). Isso me ajudará a entender suas dificuldades e a melhorar minhas explicações.

Testando o Filtro

Essa é a parte fácil do post. Para testar o filtro teremos primeiro que compilar, instalar e iniciar o driver deste post. Se você ainda não sabe como fazer isso, este outro post pode te dar um ponto de partida. Depois disso, compile, instale e inicie o filtro.

Depois de instalados, podemos utilizar a aplicação de teste para exercitar o driver. Poderemos acompanhar a atividade do filtro observando suas mensagens de debug que podem ser vistas no depurador de Kernel ou simplemente usando esta aplicação, que dispensa o uso de um depurador para ver as mensagens de debug de um driver.

"Fernando, fiz um teste aqui e ví que ao iniciar o filtro ele loga um evento de IRP_MJ_CLOSE mesmo antes de iniciar a aplicação de teste. O que eu fiz de errado?"

Não há nada de errado. Isso acontece por causa da sequência de passos seguidos na rotina DriverEntry() do filtro. Inicialmente o driver chama a rotina IoGetDeviceObjectPointer(), isso faz com que o IoManager envie uma solicitação de IRP_MJ_CREATE para o driver original. Depois disso nos atachamos à pilha de dispositivos e por fim chamamos a rotina ObDereferenceObject() que vai finalizar a única referência do file object que recebemos, enviando uma solicitação de IRP_MJ_CLOSE para o driver de baixo. Como já estamos atachados a ele, então somos capazes de ver nossa própria atividade sobre o driver original. Isso pode ser observado pela pilha de chamadas que teremos se houver um breakpoint em nossa dispatch routine quando liberarmos a referência do file object ao final da DriverEntry().

kd> k
ChildEBP RetAddr  
f8af9bcc 804ee129 StringFilter!OnForwardDispatch
f8af9bdc 80578f6a nt!IopfCallDriver+0x31
f8af9c14 805b0b18 nt!IopDeleteFile+0x132
f8af9c30 80522bd1 nt!ObpRemoveObjectRoutine+0xe0
f8af9c54 f8c80663 nt!ObfDereferenceObject+0x5f
f8af9c7c 805767ff StringFilter!DriverEntry+0xf3
f8af9d4c 8057690f nt!IopLoadDriver+0x66d
f8af9d74 80534c12 nt!IopLoadUnloadDriver+0x45
f8af9dac 805c61ee nt!ExpWorkerThread+0x100
f8af9ddc 80541de2 nt!PspSystemThreadStartup+0x34
00000000 00000000 nt!KiThreadStartup+0x16

Como de costume, o fonte do filtro que foi implementado neste post está disponível para download. Nosso filtro não faz quase nada, mas já servirá de base para posts futuros que darão mais funcionalidade a ele explicando como tais funcionalidades são implementadas.

Até mais!

Download StringFilter.zip

Symbian agora totalmente opensource

2010-02-06T01:40:22+00:00

Antes o kernel e agora toda a plataforma. A Symbian Foundation decidiu abrir todo o código-fonte para os desenvolvedores. É certo que muitas das ferramentas necessárias para a compilação e construção do sistema operacional ainda são proprietárias, mas com a ajuda da comunidade de desenvolvedores, esta migração será questão de tempo. Ao mer ver, a abertura do código-fonte é parte da estratégia

techberto

2010-01-31T15:45:33+00:00

Apesar de extremamente prazeroso (ou às vezes nem tanto) acompanhar mailists e foruns nem sempre é tarefa fácil, seja pelo rumo que certas discussões geram, pela falta de tempo ou às vezes pela questão do foco. Acredito eu, que eventualmente todos vêem um assunto que é meio (ou inteiramente) off-topic sendo tratado com certo pudor, mas que você gostaria que a discussão evoluísse mas a própria lista e a netiqueta não permite.

Alguns dizem que a relação entre arquiteto e programador é de confiança e compreensão, arquitetos não confiam em programadores e estes não compreendem os arquitetos!

Esta afirmação pode parecer exagerada (como de fato é) mas recentemente identifiquei exatamente esta situação numa reunião onde o foco era NoSQL, atritos à parte, na hora pensei que este é um assunto que merece ser profundamente e adequadamente discutido e difundido e ver ele restrito a censura ou limite dos off topics era algo cruel, e isto me fez lembrar de algumas conversas que tive, sendo uma delas com o Pedro Lamarão (figura carimbada do grupo C & C++ Brasil) num happy hour e outra com o Jack Ganssle (quando ele esteve no Brasil para o workshop que o Portal Embarcados promoveu sobre Engenharia de Software) no qual o foco de ambas conversas foi o estímulo e a iniciativa. Pra ser sincero, foi com este foco que convidamos o Felipe Tonello para palestrar no VI Encontro de Programadores do grupo C & C++ Brasil (que vai ocorrer no próximo sábado dia 06/02/2010) para falar sobre seu projeto RoboQT, é com esta abordagem em mente pensei que era necessários fazer algo em ralação ao NoSQL…

Como muitos sabem:

DBMS != SQL
SQL != Evil
NoSQL != Paraíso

Para aqueles que apreciam o assunto e desejam discuti-los sem a preocupação de criar “OFF TOPICS”, com o propósito de criar um canal
independente (de linguagens de programação e DBMS) destinada para a discussão de Banco (não bando) de Dados não relacionais - NF², NF2, N1NF (non first normal form) , MRNN (Modelo Relacional Não-Normalizado) também conhecidos como nested relational, dimensional, multivalue, free-form, schemaless porém mais populares como NoSQL (Not Only SQL) criei a lista MRNN-Brasil:

http://groups.google.com/group/MRNN-Brasil

O foco é tratar o assunto sem pudores de abordagens acadêmicas,
profissionais ou produtos podendo ser tratado tanto BigTable (???),
Dynomite, Riak, Cassandra, CouchDB, HBase, Sherpa, Voldemort, Tokyo
Cabinet, MongoDB como as bibliotecas das mais diversas linguagens, sejam elas C, C++, Python, ERlang, Go, Haskell, Ruby, Brainfuck ou Whitespace ou até novas iniciativas; seja do ponto de vista de arquitetura, programação, segurança ou o que for, mas obviamente relacionado com MRNNs.

Talvez eu não tenha procurado direito, mas como eu não havia encontrado nada semelhante em Pt-BR, resolvi tomar esta iniciativa.

A escolha de um nome do vernáculo foi em razão de que NoSQL não intui muito para o que ele realmente representa (Not Only SQL) e esta NÃO é uma lista não para aqueles que relacionam SQL com algo do mal e NoSQL dá impressão de ser uma campanha anti-SQL; mesmo que no fundo esta ”buzzword” não (?!?!) signifique isto e após estímulo (indireto) do Luciano Ramalho (que é um entusiasta do assunto tanto quanto ele é de Python) acabei adotando o nome MRNN-Brasil ao invés de NoSQL-Brasil.

Espero que iniciativa possa ser útil para a comunidade.

Funções/Objetos

2010-01-26T14:14:25+00:00

Hoje vi em uma base de código-fonte uma função cujo nome é "signalCatcher" -- um substantivo. A regra geral de estilo é: dados são chamados por substantivos, funções por verbos no infinitivo.

Mas faz sentido que "signalCatcher" seja o nome daquilo que você vai entregar ao mecanismo de sinais para tratar os sinais da aplicação, certo?

Eu acredito que a linguagem de programação do futuro não deve fazer distinção entre objetos-dados e objetos-função, mesmo sintaticamente; ambos ocupam espaço na memória e portanto exigem alocação, e são mencionados através de referências.

Em C, todas as funções são efetivamente objetos imutáveis, mas houve o tempo em que funções não eram imutáveis; esse tempo poderia voltar. E apesar de a maioria dos objetos ser mutável, alguns objetos são propositalmente imutáveis, e seus projetistas procuram maneiras de armazená-los em ROM.

Uma função deve ser um objeto cujo tipo é função, um tipo genérico variando na lista de parâmetros e na lista de resultados. O valor de um objeto do tipo função deve ser interpretado como uma sequência de instruções para o processador alvo, organizada de acordo com uma convenção de chamada apropriada. Esta convenção apóia a operação fundamental que o programa realiza sobre o objeto, chamar.

É claro que, ainda assim, uma função é um objeto bem especial. Em particular porque não é um objeto cujo tamanho é regular -- não se pode saber qual é o tamanho de um objeto função apenas conhecendo seu tipo.

Um Helimodelo no XV Simpósio Multidisciplinar

2010-01-26T12:00:58+00:00

Esse é mais um daqueles posts Off-Topic que não tem nada a ver com nada. Ou quase nada. Acho que a maioria de vocês já esta cansada de saber que este é meu último ano da universidade e que este ano estou todo enrolado com nosso Trabalho de Graduação (TG). Quem acompanha meu Twitter tem uma idéia de como isso tem tomado meu tempo. Você pode estar se perguntando: "O que faz este projeto?". Em uma palavra: "Nada". Estamos trabalhando a mais de um ano desenvolvendo hardware, firmware, driver, software e controle para que o projeto não faça nada. Na verdade, o objetivo é que não aconteça nada com um helimodelo em voo. Tá, tudo bem, desde o começo agora.

Era uma vez um helimodelo

Alguns de vocês já sabem que além de programador retardado, também tento gastar o tempo que não tenho como helimodelista. Um helimodelo é um helicóptero em escala reduzida, equipado com motor à combustão ou mesmo elétrico. Com as funcionalidades de um helicóptero convencional, é capaz de realizar voos com as mesmas características e liberdade de movimentos. Na verdade, quanto à capacidade de voo, um helimodelo pode fazer mais que um helicóptero real. Não é incomum ver um helimodelo voando de cabeça para baixo.

Um helimodelo é controlado por um sistema de rádio controle que determina os movimentos de servomotores instalados na aeronave. Cada servo tem seu papel específico dentro do helimodelo. Um controla o acelerador, outro a inclinação das pás do rotor de cauda e assim por diante.

É fácil controlar um helimodelo?

Não mesmo. O rádio controle possui dois sticks, e assim, são 4 os movimentos que você deve comandar ao mesmo tempo, isso além das chaves adicionais. O grande problema é que para ganhar os reflexos necessários para fazer a correção leva um certo tempo de treino. Acredite, você não vai querer um helimodelo voando desgovernado perto de você. Além do risco de se ferir, é quase certo que o helimodelo acertará algo e se dividirá em vários pedaços. Posso dizer que este não é um equipamento barato e cada queda pode significar centenas de reais para colocar tudo para funcionar novamente. Para começar com esse hobby normalmente utilizamos um simulador.

Um simulador é muito parecido com um vídeo-game. Com ele você recebe um joystick especial que é uma réplica de um rádio controle, mas que faz interface USB com seu computador. Você utiliza tal joystick para controlar um helimodelo na tela do seu computador. Assim, a cada queda que o modelo sofrer, basta apertar um botão de reset no próprio controle para que você possa tentar novamente. Quando eu estava começando no hobby, todos me indicaram um simulador até que comprei um. Fiquei pensando: "Que dificil que nada... Pra cima de mim? Só se for pra esses coroas. Tenho mais de vinte anos de vídeo-game nas costas". Quando comecei a brincar com o simulador ví que não era tão fácil assim. Dezenas e dezenas de quedas. Os simuladores são realmente um excelente início. Eles conseguem reproduzir com grandes detalhes o comportamento de um modelo.

Depois do simulador, você normalmente faz aulas de voo. E para isso você contrata um instrutor. Mas o que pode fazer um instrutor além de lhe desejar boa sorte? O que acontece é que rádios controles podem ser ligados por um cabo de treinamento. Esse cabo permite que o instrutor possa controlar o helimodelo, e com o mudar de uma chave, o controle passa para a mão do aluno. Se o aluno perder o controle sobre o modelo, o instrutor pode tomar o controle de volta e evitar que seu helimodelo novinho se transforme num monte de lixo.

Legal, mas e o projeto?

Nosso projeto tem como objetivo controlar um helimodelo em voo de forma a estabilizá-lo. Por isso digo que nosso projeto vai fazer nada. Houve professor que ainda disse: "Caramba! Vocês vão fazer tudo isso para fazer um helicóptero ficar parado?". Se você é um helimodelista, sabe que manter o helimodelo parado é o primeiro desafio de um piloto. Mesmo em ambientes sem vento, estabilizar um helimodelo requer uma boa quantidade de experiência. Nosso objetivo final seria descrever um plano de voo simples onde ele decole, estabilize no ar, faça alguns movimentos e finalmente pouse. Não queremos dar um passo maior que a perna. Vamos ver o que conseguimos até o dia da apresentação.

Para detectar os movimentos do helimodelo, nós instalamos alguns sensores no helimodelo, os dados dos sensores são reunidos por um microcontrolador que está instalado numa placa também a bordo do helimodelo. Depois de reunidos, os dados são enviados à uma outra placa em solo através de um módulo ZigBee. Na foto abaixo pode-se ver nossa plaquinha. Essa placa em solo é um kit da Atmel que tem suporte a diversas interfaces, sendo a USB uma delas. Assim, escrevemos o firmware e o driver USB para fazer com que tais leituras agora fossem recebidas pelo nosso software de controle.

Para fazer o controle, utilizaremos o novo Toolkit de lógica Fuzzy que está disponível no novo LabVIEW 2009 da National Instruments. Para quem não conhece, o LabVIEW é uma das principais ferramentas de controle utilizadas pela engenharia moderna. É possível fazer programas de controle apenas desenhando e arrastando componentes sobre a tela, pode parecer contraditório um desenvolvedor de baixo nível dizer isso, mas toda essa abstração nos dá tempo para dedicar às coisas que realmente precisam de tempo. A ferramenta também dispõe de interfaces de I/O permitindo trabalhar com sensores e atuadores diretamente sobre o meio eletrônico.

Uma outra informação interessante é que o Toolkit de PID e Lógica Fuzzy foi completamente re-escrito e reformulado com a ajuda de um brasileiro. Isso mesmo, Bruno Cesar (na foto ao lado) trabalha na National Instruments Brasil e foi um dos responsáveis por esse desenvolvimento. Acha isso conhecidência? Então o que você me diria ao saber que ele também se formou na Universidade São Judas Tadeu? Bruno esteve semana passada no campus da Mooca dando uma palestra sobre o novo módulo de lógica Fuzzy. Isso nos deu mais certeza de que a lógica Fuzzy é a ideal para nosso problema de controle, já que ela é perfeita para lidar com problemas complexos onde não se tem o modelo matemático que descreva o comportamento de um helimodelo. A lógica Fuzzy se baseia na experiência de um operador para atuar sobre os controles. É bem interessante.

O LabVIEW também nos permite que façamos chamadas à DLLs. Essa foi uma maneira simples que conseguimos para fazer com os dados que estavam no driver chagar ao software de controle. Assim, criamos uma DLL que abstraísse muitas das complicações de se interagir com um dispositivo USB. O LabVIEW apenas chama funções do tipo LeAmostra() que já retorna o dado pronto para o uso. Todo aquele código com CreateFile() e DeviceIoControl() ficou por conta da DLL, além de outras funções auxiliares.

Agora vocês podem estar se perguntando: "Mas como o LabVIEW vai atuar sobre o helimodelo?". Lembra daquele cabo de treinamento? Nossa placa USB vai receber as ações de controle do LabVIEW através da mesma DLL. Para fazer com que tais comandos sejam aplicados sobre o helimodelo, fizemos com que nossa placa USB se comporte como um rádio controle, que utilizará o cabo de treinamento para aplicar o controle sobre o helimodelo. Obviamente ainda teremos um piloto segurando o rádio no papel de instrutor, principalmente para evitar acidentes, onde um mal funcionamento de nosso projeto poderia transformar meu helimodelo num monte de lixo.

O Simpósio Multidisciplinar

Desde que comecei a escrever sobre o projeto neste blog, algumas pessoas ficaram curiosas e disseram: "Me avise quando houver alguma apresentação". Bom, esta é a sua chance de dar uma olhada em alguns projetos. Nosso projeto foi aceito para ter um espaço neste evento que vai acontecer de 18 a 25 de setembro na Universidade São Judas Tadeu. Serão várias apresentações curtas de 15 cada. Os projetos ainda não estão terminados, e dessa forma, você ainda não verá nenhum helimodelo voando sozinho por lá, mas estaremos com nosso equipamento dispostos a responder algumas perguntas. O simpósio é aberto à visitação pública. Não é necessário ser aluno para participar, basta se inscrever gratuitamente no site da universidade e pronto. Se quiser discutir um pouco sobre sensores, microcontroladores, firmwares, drivers, controle ou ainda helimodelismo, mesmo que durante um café, é só aparecer.

Bom, é isso aí. Já escrevi demais. Agora preciso voltar ao meu projeto.
Até mais!

Jack Sullivan rodeado de Woodsprites

2010-01-25T19:43:21+00:00

Final de ano, num rancho a beira-rio, curtindo o feriadão com a família, meus primos tiveram a idéia de fazer uma festa (que para minha surpresa havia sido preparada com boa antecedência) com direito a vários badulaques e inclusive com lightsticks (à volonté como diria os franceses ou à la vonté como nós abrasileiramos e gostamos de dizer) que sempre dá um tom alegre a festas noturnas e sempre leva a criançada (e inclusive vários marmanjos) a brincar diante das lâmpadas ultra-violetas, devido aos agradáveis efeitos visuais que tal combinação produz, sendo sempre um bom elemento para complementar a diversão.

Após a festa e em momento oportuno, meu sábio tio José, que tem uma curiosidade que eu muito aprecio, me fez a seguinte pergunta:

- O que faz estas pulseiras brilharem? Elas são realmente de neon?

Estes são um daqueles momentos que você sente imenso prazer, afinal perguntaram algo do que eu sabia responder e pelo qual naquele momento eu estava pensando por razões que vocês irão descobrir abaixo. Sem contar que com certas pessoas é sempre prazeiroso compartilhar um pouco de erudição ou como alguns preferem chamar, um pouco de cultura inútil para desopilar o fígado; apesar que se tratando de cultura eu nunca a acho inútil, mesmo que seja para filosofar sobre o bater de asas das borboletas do ponto de vista entomológico, neural, da física tratando da teoria do caos, da perspectiva cinematográfica comentando sobre criativo filme “efeito borboleta” ou poético lembrando por exemplo da famosa pretensão de Mhuammad Ali de “float like a butterfly, sting like a bee“. Mas dependendo do contexto isto pode ser um porre para quem está participando e ninguém gosta de ser desagradável, mas este não era o caso.

O neon é um gás nobre incolor, abundante no universo, mas presente em pequena quantidade no ar atmosférico, ele foi descoberto pelos químicos britânicos Morris Travers (que eu sempre confundo com Tavares) e William Ramsay no século 19, os mesmos que descobriram o gás xenônio e o criptônio; que apesar do nome krypton nada tem a ver com a saga de Kal-EL.

Segundo gás nobre mais leve, com um alto poder de refrigeração, 40 vezes maior que do hélio líquido e três vezes maior que o hidrogênio líquido, ele não está presente no light-stick!!!

A tradução de ligh-stick é “bastão luminoso”, mas sei lá por que cargas d’água (talvez pela mesma razão que vulgarizaram a expressão francesa à volonté para à la vonté) o mercado abrasileirou o nome para bastão de neon ou pulseira de neon, devido a sutil semelhança com as lâmpadas de neon, porém não é o gás nobre o responsável pela fonte de energia luminosa deste artefato, mas sim uma reação que ocorre com o cyalume (que está no bastão) similar e mais barato que ao luminol. No caso do luminol, ele reage com cobre e ferro, e como há ferro na hemoglobina, o luminol é vastamente empregado por equipes de investigação forense (como de CSI) para investigações criminais.

O que presenciamos no ligh-tstick (e nas cenas de CSI quando eles encontram sangue em algum local ou objeto) é o efeito conhecido como luminescência (nome com origem no latim “lumem”) que é a emissão de luz através por estímulo de radiação ionizante, luz ou reação onde uma energia química é transformada em energia luminosa. Na realidade quando o efeito é obtido através de algum composto químico sintético, como no caso do light-stick, ele é chamado de quimiluminescência e, apesar de não ser o caso, se fosse produzido por um organismo vivo ele seria chamado de bioluminescência sendo-se que há vários outros tipos de luminescência.

Voltando ao bastão.

No caso deste, normalmente há um solução de cyalume com uma ampola de vidro contendo uma solução de peróxido de hidrogênio (água oxigenada 35%) e quando o bastão é dobrado a ampola é quebrada, as soluções são misturadas o luminol começa a ser oxigenado e a quimiluminescência começa a ocorrer e fazer a alegria da galera. A duração do efeito depende da temperatura do local, sendo-se que temperaturas baixas são mais propícias para sua durabilidade, portanto colocar a pulseira na geladeira tende a prologar o efeito mas ele não se eternizará ou fará a efeito ocorrer novamente.

Vale lembrar que apesar de ser um efeito estudado a centenas de anos, com grandes evoluções no último século, este é um fenômeno não totalmente compreendido plenamente ainda sendo alvo de estudos e pesquisas.

No caso da bioluminescência, normalmente o substrato de uma proteína denominada luciferina (nome com origem no latim “lucifer” que significa “que ilumina”) é oxidada por uma enzima, denominada luciferase. Nesta reação há o consumo de uma molécula de trifosfato de adenosina (ATP) que excita energéticamente a luciferina e proporciona a geração de energia luminosa através da liberação da energia química.

A luminescência tem atraído o interesse do homem desde o princípio de sua existência, visto que do Pernambuco à China, os primeiros registros e pirilampos, fenômeno que Aristóteles (384 – 322 A.C) descreveu como “luz fria”. Em 1669, o médico H. Brandt criou a “phosphorus mirabilis”, que era uma reação que utiliza uma propriedade do fósforo quando exposto ao oxigênio do ar em certas circunstâncias e por esta reação ele obtia a “quimiluminescência” (termo que fui criado 200 anos depois), mas Brandt que era um alquimista na época não compreendia exatamente o que ele estava fazendo, apenas o que ele estava conseguindo; o fascínio das pessoas para quem ele apresentava seu experimento alquimista.

Talvez seja este fascínio (o a intenção de fascinar) que fez James Cameron

inserir na história de Avatar, a luminescência e a bioluminescência em Pandora como uma propriedade de todo organismo deste planeta, dos animais aos pequenes Woodsprites, as sementes de Utraya “Mokri”, e a Árvore das Almas, com propriedades místicas.

Quando meu tio Zé perguntou-me sobre o bastão de luz, a pouco eu estava lembrando da carinha de alegria de minhas sobrinhas ao brincar com os bastões de luz, sobre o fascínio da luminescência na humanidade e sobre o belo efeito que James Cameron conseguiu com Avatar, portanto nem preciso dizer o quanto achei oportuno a pergunta dele; porém confesso que na hora puxei um pouco o freio de mão e não externei toda minha viagem.

E por falar em viagem e para finalizar, vejam só o que este maluco fez com um bocado destes bastões:

Alerta, Cyalume é tóxico e além disto como comentei acima, há vidro nos bastões, portanto não façam isto em casa!

Namastê!

F# talk for .NET Architects Group

2010-01-25T17:51:46+00:00

Last week, 16th January to be precise, I gave another talk about my second favorite programming language: F#.

This event was managed by .NET Architects Group, a .NET brazilian discussion group. The organization was excellent and impeccable!

As you know, every post of this blog has a piece of code. Below, we have a sample to host a REST WCF Service with F# without using a configuration file to define bindings.

#r "System.ServiceModel.dll"
#r "System.ServiceModel.Web.dll"
#r "System.Runtime.Serialization"

open System
open System.ServiceModel
open System.ServiceModel.Web
open System.Runtime.Serialization
open System.ServiceModel.Description

[<ServiceContract>]
type IMyService =
    [<OperationContract>]
    [<WebGet(ResponseFormat=WebMessageFormat.Xml)>]
    abstract Ping : value:int -> string

//http://localhost:8081/svc/Ping?value=42
type MyService =
    interface IMyService with
        member this.Ping ( value ) = printfn "%d" value; string value

let svc = new ServiceHost( typeof<MyService>, new Uri( "http://localhost:8081/svc" ) )
let metadata = new ServiceMetadataBehavior( HttpGetEnabled = true )
svc.Description.Behaviors.Add( metadata )
svc.AddServiceEndpoint( ServiceMetadataBehavior.MexContractName, MetadataExchangeBindings.CreateMexHttpBinding(), "mex" )

let binding = new WebHttpBinding()
let endpoint = svc.AddServiceEndpoint( typeof<IMyService>, binding, String.Empty )
let behavior = new WebHttpBehavior()
endpoint.Behaviors.Add( behavior )

svc.Open()

printfn "Host is running..."
Console.ReadLine()

The slide-deck, scripts and program samples (not) showed there are available from here: FSharp Talk Samples

Editpat - the transparent notepad and post-it tool will be released in another occasion.

I'd like to express my gratitude to all the attendees, both on-site or online. You were all great!

Sexto Encontro de Programadores C++

2010-01-24T14:25:29+00:00

O grupo C&C++ Brasil (ccppbrasil) tem o imenso orgulhar em anunciar (agora oficialmente) o nosso sexto encontro. Detalhes:

Sexto Encontro de Programadores C & C++
dia 6 de março de 2010, sábado
em São Paulo, SP, na Avenida Paulista núemro 1439, 6º andar
5 palestras. Já temos propostas suficientes, falta a confirmação dos palestrantes e a ordem das palestras
As inscrição já estão abertas

A página oficial está em http://ccppbrasil.org/wiki/Grupo:Encontro_VI.

0 comentário(s)

Vou fazer uma palestra sobre Python na Campus Party

2010-01-22T18:59:20+00:00

Título: Seja dinâmico com Python
Descrição: Vou falar sobre quase todas as gambiarras e coisas maravilhosas que um programador pode fazer com os recursos "dinâmicos" do Python. Criar membros e métodos em runtime, usar o reflection mais simples do planeta, responder por métodos que não existem na hora em que são chamados. Métodos __MAGICOS__ e seus correlatos. Como transformar um registro de um banco de dados em um objeto (quase um ORM) com duas linhas de código (ou três). E as piadas quase-engraçadas de sempre
Data e hora: 26 de janeiro (terça-feira), 09:00hs da matina. Para quem vai acampar lá é uma boa maneira de começar a semana :-)
Links: Campus Party, agenda do evento, meu twitter

Além disso, devo ficar lá o dia inteiro. Essa palestra está sendo organizada pelo GruPy-SP, o Grupo de Usuários Python do Estado de São Paulo.

1 comentário(s)

techberto

2010-01-18T07:07:08+00:00

O core de organização de eventos do grupo C & C++ Brasil, com colaboração da Liga dos Programadores Indepentes mais alguns colaboradores e com apoio da galera do hashtag #ccppbrasil_meetings estão trabalhando na remotada dos eventos do grupo C & C++ Brasil para 2010, sendo-se que o primeiro evento será o encontro de programadores que está programado para o dia 06 de fevereiro de 2010 em São Paulo.

A programação ainda não está fechada mas há propostas de palestras sobre concorrência para C++, robótica, programação segura entre outras.

Maiores detalhes em http://www.ccppbrasil.org/wiki/Grupo:Encontro_VI

Está em planejamento também um encontro do pessoal de Porto Alegre.

Em breve será divulgado uma previsão de agenda para 2010.

Bons códigos e nos vemos lá!

Namastê!

techberto

2010-01-18T06:38:14+00:00

Epónymos era a figura que atribuía o nome a uma cidade na grécia clássica. Eponímia é o nome que dela deriva. Este conceito generalizou-se ao batismo de técnicas, objetos, atributos, invenções seja por vias diretas ou indiretas, sendo considerada a forma suprema de reconhecimento da atividade de um pesquisador.

Quando eu era adolescente e morava lá em Santa Fé do Sul (proporcionalmente 105.18 Km mais distante de São Paulo e 3.7840092199092412 vezes menor que Barbarcena) numa época em que eu realizava um curso técnico em eletrônica, com grande freqüência eu conversava com o (bom amigo) Batata sobre física, eletricidade, válvulas raras, RF, a vida, o universo e tudo mais; num destes bate-papo logo após uma desopilação hepática ele me comentou que quem deveria ser creditado pelo invento do rádio deveria ter sido o Padre Landell, um gaúcho que foi padre católico e um notável inventor e não Marconi ; físico italiano que plagiando estudos apresentandos pelo Nikola Tesla em 1899 apresentou ao mundo que Pe.Landell já havia apresentado em 1893 para um pequeno público em Campinas. Também foi o Batata que me revelou que o verdadeiro inventor do telefone teria sido Elisha Gray e não Alexander Graham Bell, quando eu solicitei suas “fontes” ele sacou de seu arquivo duas revistas Saber Eletrônica que relatavam estes fatos. Quando terminei de ler os artigos comentei: “Isto sim é pilantragem” e o Batata soltou uma que (na época) eu não entendi:

- “Isto sim é a apoteose da irresponsabilidade consciente” e tomei nota desta frase na hora, pois achei um “insight” muito inspirado…

Fiquei bastante curioso sobre estes fatos, infelizmente naquela época (década de 80) minhas fontes de pesquisas mais confiáveis diziam que os inventores da primeira aeronave havia sido os irmãos Orville e Wilbur Wright. Estas informações não mudaram minha vida, mas me tornaram um assíduo leitor na revista Saber Eletrônica por alguns anos como também me estimularam a pesquisar (eventualmente) sobre a história das invenções e das ciências.

Nestas primeiras pesquisas, percebi que muitas invenções passaram por disputas de paternidade, mas nem sempre a disputa tinha motivações financeira, como por exemplo foi o caso de Bob Kearn retratado no filme Flash of Genius. Um caso mais popular foi o exemplo da lâmpada que teve como primeiro inventor Joseph Swan mas Thomas Edison levou os créditos, porém foi quem melhor explorou a invenção, tendo inventado o sistema elétrico com rede de distribuição de energia, geradores de energia e todo um universo que viabilizou a comercialização da eletricidade, conseguindo explorar melhor a invenção. Caso similar ao telefone visto que Bell explorou muito bem “sua” invenção e as redes telefônicas. Porém, no caso dele vamos dizer que se aplica a máxima do batata visto que Bell se inspirou no trabalho de Johann Philipp Reis, descobriu o trabalho de Stephen Gray (que em 1729 teorizou um telefone funcional) comprou (a preço de banana) protótipos de Antonio Meucci, ouviu boatos do aparelho de Christian Ørsted e quando ficou sabendo que Elisha Gray (que era alguém com quem ele sabia que devia-se preocupar) iria registrar a patente de um telefone funcional, Bell subornou um funcionário do escritório de patentes e “conseguiu” registrar a patente do telefone primeiro, mas em 2002 a suprema corte americana reconheceu o trabalho de Antonio Meucci por ter sido o verdadeiro inventor do telefone; decisão justa mas tardia, afinal Meucci faleceu no século 19. No caso do rádio, entre aqueles que se proclamaram pais da invenção havia Nikola Tesla, Alexander Popov, Reginald Fessenden, Pe.Landell de Moura; em 1943 a Suprema Corte dos Estados Unidos concedeu a Tesla a Patente 763,772 creditando a ele a invenção do rádio, talvez porque era o único que ainda havia algum representante ativo nesta luta, pois analisando historicamente o Pe.Landell Moura foi quem conseguiu primeiro. Felizmente hoje Landell é mais conhecido no Brasil, sendo patrono dos radiamadores brasileiros sendo conhecido como um dos pioneiros na invenção da TV, ele foi o inventor do telefone sem fio, da comunicação via portadora ótica e entre outros campos ele é conhecido mundialmente por seu pioneirismo na bioeletrografia porém quanto ao rádio…

Numa destas pesquisas encontrei a palavra eponímia (acho que) pela primeira vez. Um exemplo de eponímia é a Salmonella, que tem origem do sobrenome do Dr.Daniel Elmer Salmon, mas que na realidade ela foi descoberta por Theobald Smith. Ué, como assim? De forma simplista, olha a máxima do batata aí novamente.

Num acaso, em 1992 li uma nota que Joel Cohen havia escrito um artigo no qual ele revelava que a “lei da eponímia de Stigler” foi muitas vezes formulada antes de Stigler a ter sequer nomeado. Mas o que era esta tal lei? Infelizmente era 1992, não consegui encontrar nada nas bibliotecas que eu tinha acesso e eu estava procurando nos lugares errados.

Poucos anos depois, ao acaso, descobri que a chamada Lei – da mesonímia ou eponímia – de Stigler afirmava que “no scientific discovery is named after its original discoverer” (nenhuma descoberta científica é designada com o nome do seu descobridor original) bem, neste momento comecei a pensar, nenhuma? Stigler chegou a esta conclusão observando várias descobertas, na área de economia e ciências, sendo-se que este trabalho proporcionou a ele o Nobel de Economia em 1982. Porém, se Cohen estava correto, até a lei de Stigler era vítima dela própria; ao menos ela era coerente. E ali senti que eu estava començando a aprender os nomes dos bois.

E eu ainda tinha aquela dúvida: todas? Obviamente que não podia ser todas, mas o quanto ela se aplicava? Qual ciência era mais suscetível? Porque esta tipo de situação era tolerada? Não há uma única resposta, cada caso é um história.

Alguns anos depois, felizmente já com a internet, resolvi pesquisar a origem de algo que a muito tempo eu tinha curiosidade e o que descobri foi interessante:

Em 1949, John Paul Stapp, um Ph.D, médico e coronel da USAF (nascido na Bahia em 1910) pioneiro nos estudos dos efeitos das forças de aceleração e desaceleração no organismo humano, que havia sido selecionado dois anos antes como “cobaia” de testes para medir a resistência humana a grandes acelerações, consegui bateu o recorde mundial de aceleração mas não pôde festejar o feito. Isto porquê os acelerômetros do trenó-foguete simplesmente não funcionaram. P. da vida, Stapp solicitou ao engenheiro responsável pelas medições - o então capitão Edward Murphy Jr. - uma análise para identificar a falha. Logo eles descobriram que um técnico ligara os circuitos do veículo ao contrário. No relatório de análise do problema, Murphy anotou: “Se há mais de uma forma de fazer um trabalho e uma dessas formas redundará em desastre, então alguém fará o trabalho dessa forma”.

Dr. Stapp popularizou a expressão ao comentar em uma entrevista a jornalistas, o diagnóstico de Murphy, atribuindo ao fato de que ninguém saiu ferido dos testes por levarem em conta a Lei de Murphy e explicou as variáveis que integravam a assertiva, ante ao risco de erro e consequente catástrofe.

Enfim, quem a popularizou foi Stapp e o seu autor (mesmo que atormentado por isto) sempre recebeu os méritos. Assim quando tive contato com as origens da folclórica e emblemática a Lei de Murphy minha primeira observação foi que a Lei de Stigler não se aplica a ela. Imagino que esta seja uma daquelas citações desgastadas que ninguém mais aguenta, mas como já dizia Nelson Rodrigues “toda unaminidade é burra”. Mas o que mostrou-se mais evidente é que a Lei de Murphy é mais poderosa que a Lei de Stigler! rs

Outro dia, já em 2010, lendo o post Newton e os Universos Paralelos vi uma referência ao clássico embate Newton vs Hooke, que sempre me faz lembrar do embate Newton vs Leibniz . Muitas vezes a fama indevida ou a prova da Lei de Stigler ocorre de forma involuntária, no caso do Cálculo, não há eponímia, mas houve literalmente “a apoteose da irresponsabilidade consciente”, enfim, houve a pilantragem de Newton. Com o tempo descobri que o Batata não havia sido original, que a frase que me deslumbrou era do Carlos Imperial e ele omitiu, mas comparado ao que Newton fez isto não foi nada!

Apenas para contextualizar:

Isaac Newton fez descobertas elementares em gravitação, óptica, mecânica, dinâmica celeste e matemática! Era um cientista. Já Leibniz, pai do termo função, era um filósofo e se interessava por lingüística, história, direito, diplomacia, política, economia, teologia, biologia, geologia, matemática, filosofia e metafísica, sendo considerado como o último gênio universal e inclusive um virtuoso atleta.

Leibniz publicou o seu trabalho sobre Cálculo antes de Newton. Quando Newton teve acesso, ele ficou bastante irritado e temendo críticas, principalmente advindas de Robert Hooke, com quem não tinha muita afinidade desde quando ele publicou seu trabalho sobre ótica e que na ocasião era o presidente da Royal Society, Newton preferiu adotar uma estratégia vitriólica para “defender” seus interesses.

Quando Hooke faleceu, Newton tornou-se uma espécie de presidente vitalício da Royal Society, da qual Leibniz também era membro. Desta forma, ainda inconformado por ter perdido o bonde do Cálculo, com um aliado escocês, John Kell, começou a provocar Leibniz como plagiador. Muito irritado com esta história, ele enviou ofícios violentos à Royal Society para provar que ele, sim, inventara o Cálculo Diferencial e Integral (até hoje são usadas as notações de Leibniz – por exemplo, o famoso dy/dx). Diante daquela querela entre titãs e como sói acontecer, criou-se um comitê para investigar a questão. Esse comitê foi formado em quase sua totalidade por membros pró Newton. Em tempo recorde ficou pronto um relatório conferindo a Newton a prioridade da invenção. Mais tarde foi descoberto um rascunho desse relatório manuscrito por Newton! Na realidade, com o tempo descobriu-se que quase todos os artigos que foram escritos ” atacando” Leibniz foram apenas publicados em nomes de outros cientistas da época, mas foram escritos por Newton (tsc). Newton recebeu o título de Sir, faleceu em 31 de março de 1727 e foi sepultado na Abadia de Westminster, em Londres, entre os reis do Império Britânico. Apesar de suas mentiras e desvios de caráter, ele foi evidentemente um gênio, preguiçoso e ardiloso, porém sagaz e extremamente inteligente.

Todavia, a filosofia de Leibniz contribuiu para o que hoje chamamos de física moderna. Ele trabalhou com lógica simbólica, aperfeiçoou uma primitiva máquina de calcular e foi precursor da aritmética binária, base dos atuais computadores. Leibniz morreu em Hanover no dia 14 de novembro de 1716.

A melhor síntese desta história que eu já encontrei, do qual me apropriei de parte do texto está no trabalho Newton vs Leibinniz de Adalberto Nascimento, porém esta história é contada em vários livros.

Comentando sobre alguns destes assuntos no twitter com o @AlanJumpi e o @Feutestoun, surgiu um insight de escrever este post (ou algo parecido) foi quando comentei da Lei de Stigler e logo alguém me comentou que a @cyberdecker havia escrito a pouco tempo o post breve panorama da estatística e lei de Stigler que li gostei muito, sinceramente recomendo. Na sequência surgiu a idéia de debatermos tudo isto com mais algum tempero de nerdices num bar, numa divagação imaginei que o local ideal seria o bar & restaurante no fim do universo, logo pensei: como será uma ressaca de Pan-Galactic Gargle Blaster?

Saideira: por falar em aritmética binária, grandes gênios, inventores, absurdos e polêmicas sobre patentes, lembrei de uma clássica história onde em 1948 quando tentaram patentear as portas lógicas digitais, a U.S.Patents a negaram pois Nicola Tesla já a detinha desde a virada do século. Esta foi uma contribuição indireta de Tesla extremamente valiosa, visto que este monopólio certamente iria gerar um absurdo atraso tecnológico.

Ps: Ainda pensando nestes sci-fi drinks, como será uma ressaca de “Romulan Ale“? Bom, esta divagação incidental e um pouco (ou muito mais) sobre curiosidades sobre Tesla, Landell e história da ciência ficam para outro(s) post(s) que após quebrar o jejum, nas próximas aplicarei as técnicas de jack.

Namastê!

Programação e Semiótica 7

2010-01-13T14:17:07+00:00

Um novo exemplo para diminuir o tédio dos leitores e usar esses conceitos para entender o processamento de texto nos computadores.

Falemos sobre um programa que, por sua vez, deseja falar sobre textos em linguagem natural. Este programa fará referência a objetos cujo interpretante é "texto em linguagem de gente".

O que é texto em linguagem de gente? É uma sequência de símbolos que os seres humanos são capazes de entender como caracteres do seu idioma, que por sua vez se agrupam para formar palavras, frases etc. Nos idiomas latinos dizemos que as letras se agrupam para formar palavras; em idiomas como o japonês muitas vezes apenas um caracteres já é uma palavra inteira.

Mas o computador não sabe nada sobre caracteres, apenas sobre números. Com certeza o computador é capaz de representar na memória números uns na frente dos outros.

A intuição fundamental é a possibilidade de estabelecer um mapa de caracteres onde cada caractere está mapeado para um número e vice-versa. Formalmente, o mapa é uma função bijetora entre os conjuntos "números inteiros" e "caracteres".

Assim, um programa processador de texto faz referência a objetos cujo primeiro tipo é "número inteiro" e cujo segundo tipo é "caractere do mapa tal".

Suponha o seguinte mapa: a = 1, b = 2, c = 3 etc. O texto "abc" seria um objeto composto por três objetos numéricos contíguos 123.

Como poderia um programa colocar palavras em ordem alfabética? Toma dois objetos "palavra" e compara os dois caracteres iniciais como números; se forem diferentes, a ordem é numérica; se forem iguais fazemos a mesma coisa com o segundo caractere e assim por diante. Essa é a ordenação lexicográfica.

Esse esquema é interessante quando podemos usar um objeto de tamanho fixo e tipo "número" para todos os caracteres desejados. Mas com o advento da Internet e a interligação entre sistemas de todo o mundo se tornou inviável usar mapas de caracteres pequenos.

O que acontece quando um sistema do Japão envia 123 para um sistema do Brasil? Que mapa de caracteres o sistema do Brasil deve tomar como interpretante desses números? Essa dificuldade é a causa de muitos fenômenos bizarros na Internet, onde páginas mostram um monte de lixo onde deveriam estar caracteres latinos acentuados ou coisa parecida.

A primeira lição da interligação de sistemas processadores de texto é que não existe objeto "texto" compreensível sem um interpretante "mapa de caracteres" associado. Essa associação é um problema que sempre deve ser resolvido, mesmo que a solução seja um contrato entre todas as partes definindo um e apenas um mapa válido. Esse tipo de contrato não se mostrou viável a longo prazo.

Alguns sistemas de programação experimentaram construir tipos mais complexos para objetos; não apenas "texto" mas "texto ASCII" ou "texto ISO-8859-1" -- embutindo no tipo do objeto também o tipo do mapa de caracteres. Isso é interessante para apoiar contratos como o anterior, mas um pouco estranho quando o sistema deve aceitar diversos tipos de texto de diversas partes do mundo.

Estas parecem as coisas básicas que sempre queremos fazer com texto: contar o número de caracteres, decidir se dois textos são iguais, decidir qual de dois textos deve aparecer antes na ordem do dicionário, e inspecionar o texto letra por letra (para imprimir na tela, por exemplo). Com os mapas numéricos simples, podemos fazer todas essas coisas simplesmente trabalhando com pares de números: os primeiros de cada texto, depois os segundos de cada texto, etc.

Nesses mapas, existe uma referência sensata que atravessa a representação dos objetos da mais pura -- os números -- para a mais abstrata -- o caractere do texto.

Essa facilidade eventualmente terminou, o que ainda parece muito traumático para programadores acostumados com essa situação tão segura.

Eventualmente a comunidade internacional decidiu dar um basta na multiplicidade dos mapas e resolveu produzir o super-mapa Unicode. Este mapa é um catálogo de praticamente todos os caracteres usados na galáxia, associados cada um deles a um número inteiro positivo. Infelizmente, são muitos caracteres, que não podem ser representados com números pequenos.

A princípio, os indivíduos decidiram usar números grandes e manter o esquema de mapa com objetos de tamanho fixo. Assim, o processamento par-a-par continuaria possível. Mas os objetos texto explodiram de tamanho e essa esquema se mostrou inviável.

Então um compromisso foi firmado: um novo mapa foi produzido para o Unicode onde quase 90% dos textos continuaria com o mesmo tamanho, e apenas 10% seria maior. Este mapa às vezes usa um número por caracteres, às vezes dois, às vezes três e às vezes quatro. Este simples fato é o pesadelo dos programadores novatos de processamento de texto.

Por que este mapa UTF-8 possui uma representação tão estranha com objetos caractere de tamanho variável, deixou de ser sensata a referência direta número-a-caractere. Um sistema que recebe 1234 3456 5678 e deve interpretar esses números como texto deve não mais assumir que o primeiro número é um caractere, e o segundo um caractere etc. É possível que na realidade os dois primeros números sejam um caractere juntos.

Uma sequência de números que deve ser interpretada como UTF-8 não pode mais ser percorrida ingenuamente número a número, e os algoritmos de processamento baseados em comparações par-a-par estão quebrados. Isso, novamente, se deve ao fato de que UTF-8 viola propositalmente premissas simples de significação dos números que compõe um texto.

Isso foi um problema grave porque programas antigos despreocupadamente tratavam seu texto de forma crua, diretamente com os números, confortados pelas premissas do processamento de texto -- ao invés de fazer isso com funções especiais em módulos de processamento de texto.

Quando o significado dos números foi alterado nos processos de substituição de mapa por mapa, consertar esses programas foi tarefa infernal. Os programas com funções especiais de tratamento de texto modificaram apenas estas funções e foram livrados deste mal.

Esta vitória do encapsulamento pode ser compreendida pelo encapsulamento de uma função sígnica -- a compreensão dos signos-número como signos-letra encapsulada em certos entes responsáveis, e uma transformação cultural pôde ser efetivada apenas instruindo estes entes responsáveis, e não todos os entes.

No final das contas o problema se tornou tão bem resolvido que surgiu um componente tão reusável que surge por toda parte, a libiconv.

Programação e Semiótica 6

2010-01-12T13:37:30+00:00

Entender o texto de um programa sob a ótica da semiótica é um pouco mais fácil do que entender outros tipos de texto porque o limiar de realidade do programa está bem delineado e bem próximo: a máquina.

Por essa razão, não é preciso uma poderosa metafísica para entender o que é um objeto, mesmo que este esteja, para o programa escrito, totalmente oculto.

Bolei o seguinte diagrama para descrever as três propriedades fundamentais de um objeto segundo as regras da máquina.

Estas três propriedades são a "base" de um objeto e o determinam completamente; seu estado ou padrão de bits, seu local ou endereço, seu tamanho ou comprimento em bytes.

Local e tamanho são propriedades espaciais, sendo a memória um universo unidimensional. Falamos sobre onde um objeto está, e ao longo de que comprimento. Estado é uma propriedade temporal, e (potencialmente) muda a cada instante. Falamos sobre qual é o estado de um objeto (agora).

Mas eu venho insistindo que o programa escrito em linguagem de alto nível nada sabe sobre objetos, exceto aquilo que pode falar sobre eles através de referências, e tentando aplicar a nomenclatura da semiótica para dizer isso.

Bolei o seguinte diagrama para relacionar os três conceitos que eu estou tentando usar, que envolvem toda expressão no programa escrito sobre objetos.

Uma expressão em um programa escrito como "y = x + x" possui, além dos elementos sintáticos = e + os nomes y e x; estes nomes são tradicionalmente chamados variáveis e eu os estou chamando aqui de referências. Esses nomes significam objetos por intermédio de um tipo (que eu acredito ser equivalente ao interpretante.)

Linguagens como C++ prendem referência e tipo através da sintaxe; a ferramenta que interpreta o programa sempre sabe qual é o tipo associado a um nome como x. Linguagens como Javascript não prendem referência e tipo dessa forma, de modo que a ferramenta deve sempre considerar o contexto de uma expressão para inferir um tipo para x.

A vantagem do C++ (e similares) é a possibilidade de se apoiar em uma ferramenta para evitar que uma referência absurda seja formada e usada; linguagens como essa permitem a dedução da validade semântica a partir da validade sintática. Este é o sonho da análise estática de programas: descobrir erros no significado a partir do (uso da) sintaxe.

No seguinte exemplo em C++:

complex c1 = { 1.0, 1.0 };

c1 é uma referência cujo interpretante estático é "número complexo". Conhecendo os segredos deste interpretante, poderíamos compreender o resto do texto, o próprio objeto, como o número complexo 1 + i.

A vantagem do Javascript (e similares) é a possibilidade de se expressar
sobre objetos através de múltiplos tipos viáveis de acordo com a conveniência; linguagens como essa simplificam a validade sintática para aumentar as opções de validade semântica.

No seguinte exemplo em Javascript:

nome = "Pedro Lamarão";

nome é uma referência sem interpretante estático. Conhecendo os segredos da sintaxe da linguagem, saberíamos que aspas duplas implicam o interpretante "texto", e portanto nome significa o meu nome.

Independentemente de onde o leitor obtém um tipo-interpretante para uma variável-referência, é através deste que o objeto-estado possuirá uma conotação -- um significado imediato. Os três tipos fundamentais em máquinas contemporâneas são o inteiro-sem-sinal, o inteiro-com-sinal e o ponto-flutuante.

Programas do mundo real, porém, estão muito interessados em coisas como letras, textos, nomes de pessoas e lugares, valores em moeda local, fotos etc. Diversos programas precisam impor significados adicionais a objetos fundamentalmente aritméticos para serem úteis.

Essa necessidade nos leva naturalmente a pensar em objetos compostos por objetos simples e sobre a diferença conceitual entre um objeto na máquina concreta e um valor em um conjunto abstrato. Certos programas dirão que um certo objeto possui o valor "Pedro Lamarão" -- mesmo sabendo que a máquina fundamentalmente só compreende números.

O relacionamento entre as idéias objeto e valor, e a idéia de composição de objetos, torna o processo semiótico de um programa muito mais rico, interessante e passível de absurdos -- onde nem sempre se consegue responder com facilidade a perguntas simples como "x é igual a y?"

Semiótica e Programação 5

2010-01-07T10:57:46+00:00

Agora, para um pensamento menos entediante.

Considere que autenticação é o processo pelo qual um sujeito se convence que um certo signo de fato significa um certo objeto -- uma certa credencial de fato significa um certo indivíduo, por exemplo.

Quando você ouve a campainha e alguém dizer "Olá" e pensa "Deve ser fulano" você autentica o signo vocal para se convencer ainda mais usando o olho mágico.

O método de autenticação em sistemas de informação com a interação mais simples é a checagem de um segredo compartilhado. O sistema conhece um segredo para um username e assume que se alguém apresentar o username e o segredo, então deve ser o significado daquele username.

O programa em execução, após executar essa interação com sucesso, construirá um objeto na memória, e manterá uma referência para ele cujo significado ulterior é username-do-usuário. Já que a autenticação foi bem sucedida, o programa confiará até terminar que esta referência é adequada, e poderá usá-la para julgar se deve ou deve não permitir o usuário a abrir certos arquivos etc.

Esta confiança no significado daquela referência é perfeitamente adequada para programas convencionais: a memória de um programa convencional em um sistema convencional é exclusiva, de modo que ele pode facilmente se convencer de que o objeto referenciado é íntegro.

Às vezes programadores movem para sistemas diferentes onde as regras são diferentes, e esse tipo de expectativa implícita é violada com consequências drásticas.

O jovem programador que move sua atividade para a web pode escrever um site em script que autentica o usuário e guarda o username em um objeto da sessão. O programa subjacente então continuamente fará certa referência a este objeto para tomar decisões de segurança, afinal, esta referência está para o objeto certo, não é?

Porém, neste ambiente, o programador não pode assumir a integridade do objeto -- não ingenuamente, como eu assumi acima. Como a web é um sistema bem distribuído e como o browser acessa o site um arquivo por vez, sem qualquer continuidade, este objeto ao qual o script faz referência não está sob seu controle. Ele existe em uma memória distante, fora do seu controle.

Fora do seu controle significa sob controle de um outro agente: o cliente. Suponha então que eu faça um acesso a uma página restrita e posicione arbitrariamente um objeto com o username de outra pessoa justamente no local onde a referência do programa assume que ele esteja. Assim, eu posso mentir ao programa sobre quem eu sou, me valendo de uma ingenuidade no significado do programa.

Perceber esse furo de segurança no site pode ser difícil porque o texto do programa do site pode adequadamente obter o username e compará-lo com regras de autorização em todos os lugares. O problema aqui é semanticamente anterior a esta comparação: o problema está na premissa de que uma certa referência está de fato para um objeto com o significado esperado.

Assim, os defeitos nos processos de autenticação em sistemas de informação são compreensíveis sob a ótica de uma função sígnica com "defeito" -- uma oportunidade através da qual o par em uma conversação tem condições de mentir. Concretamente, esse defeito existe no programa na forma de uma confiança indevida sobre o objeto de uma referência.

Semiótica e Programação 4

2010-01-06T11:29:04+00:00

O padrão Proxy ocorre sempre que um objeto no sistema existe como substituto de outro objeto, por alguma razão. Em um sistema distribuído entre muitos computadores físicos, um objeto local pode ser substituto de um objeto que está em outro computador, ocultando o mecanismo de comunicação entre computadores.

O objeto proxy, de um modo ou de outro, possuirá uma referência ao objeto proxied; e o programa que possui uma referência ao objeto proxy possuirá uma referência ao objeto proxied.

Esses múltiplos níveis de indireção trazem problema para a expressão e compreensão do programa devido a frequente ausência de interpretantes para humanos -- também conhecidos como documentação.

Considere um objeto whatever que é um proxy para um objeto em um computador central, e uma rotina com essa aparência:

   get_name (whatever) -> (s1)
   ; s1 is the name of whatever

Um programa chama get_name e obtém uma referência ao objeto "nome" de um outro objeto qualquer.

Agora, resta a pergunta: se o programa que eu estou rodando modificar o valor de s1, o que acontece com whatever? Se Fulana rodar o mesmo programa depois que eu, que valor de s1 ela vai obter? s1 é uma referência para uma cópia ou é uma referência para o original?

Essa diferença é importante por razões que não apenas as consequências de modificar o objeto. A memória do computador é finita e portanto os programas devem cuidar de destruir os objetos que já acabaram de usar. Mas o que o programa que usa get_name deve fazer com o objeto referenciado por s1? Ele deve destruí-lo? Ele pode destruí-lo? Com certeza ele não pode destruir um objeto que está referenciado por diversos outros programas.

Por que (alguns) programas devem cuidar da presença dos objetos na memória, e dar manutenção nessa memória, existe sempre o problema de dispor de espaço para objetos ocuparem e por quanto tempo. Quando um programa faz algo como:

   string s4 = "Marcelinho"

a expressão de que "existe um s4 que é um texto" é interpretada implicitamente como "precisamos arranjar espaço para um texto pelo tempo necessário".

Quando o programa lida com objetos que foram criados por ele mesmo e são locais, o uso do espaço e do tempo é óbvio porque explícito; referências a objetos ocultos demandam maiores explicações.

As referências indiretas como os objetos proxies levam o problema além quando tornam possível que uma referência seja absurda -- uma referência a nenhum-objeto. Há programas onde faz sentido uma referência a nenhum-objeto e há programas onde isso não faz sentido. O programador deve deixar isso sempre claro sob pena de não ser compreendido.

Documentação é a única solução geral na medida em que linguagens de programação em geral não oferecem mecanismos sintáticos para se especificar esses atributos de uma referência.

Nem mesmo C++, que possui duas notações para referências com diversos graus de rigor sintático, consegue expressar tudo o que se deseja expressar, e a confusão sobre a especificação de "rvalue references" indica que ainda não está firmada a sintaxe do futuro.

Linguagens como Java, onde a quase totalidade dos objetos são criados por um gestor central em memória desconhecida, permitem ao programa ignorar a manutenção da memória mas ainda sofrem do problema de compreensão das referências.

Quando começamos a considerar as referências polimórficas a situação fica ainda mais punk.

URIs e a semiose da web

2010-01-04T17:15:58+00:00

(TODO: Será que estou usando os termos certos? Suponho que "significante" seja o mesmo que "interpretante" mas a nomenclatura da Semiótica não está bem firme na minha memória.)

Existe bastante semiose na comunicação entre programas de computador, mesmo que seja uma semiose extremamente simples, com um universo de possibilidades bastante limitado.

O serumano ao acessar uma página na Web digita no browser: http://www.twitter.com/pedrolamarao -- uma URI.

Existe algo de muito interessante acontecendo entre o serumano, o browser e um servidor perdido na rede; algo descrito em grande pompa teórica na especificação das URIs.

Em primeiro lugar, esse texto é bastante opaco para a maioria das pessoas; muitas delas compreendem que "twitter" é o nome de um "site" e que estão querendo ver as paradas de "pedrolamarao".

Alguns mais acostumados com a Web sabem que "http" é o nome das coisas que são da Web, e que existem outros nomes próprios de outros programas, como "ftp".

Realmente esse texto, ou esse símbolo, se divide em duas partes, e deve ser interpretado em dois estágios, ou como composto de dois símbolos distintos.

O primeiro símbolo é "http" que deve ser interpretado de acordo com um esquema bem simples -- a pura comparação textual. "http" vai para cá, "ftp" vai para lá e assim por diante. O nome desse símbolo é schema e esse símbolo será o interpretante do símbolo seguinte: deve-se interpretar o resto do texto de acordo com este princípio do texto.

Existe uma infinitude de possíveis schemas, já que um schema é apenas e tão somente um monte de letras em sequência. Além disso, o acordo entre todos nós sobre o que um schema significa pode ou pode não ser bem definido; é claro que a Internet inteira concorda sobre o que é "http", mas duvido que algum de vocês saiba como interpretar "astrotv" da mesma forma que eu.

Quando o schema é "http" o sistema sabe que deve usar o browser Web. Ao menos, assim esperamos que seja, quando clicamos em "http://www.twitter.com/pedrolamarao" sublinhado em azul naquele email que recebemos. O browser Web, por sua vez, sabe que o segundo símbolo -- "www.twitter.com/pedrolamarao" -- é composto também por diversos símbolos, quando a URI é "http".

O primeiro deste último conjunto é chamado authority e possui um entre poucos interpretantes aceitáveis. Neste caso, o domain name system ou DNS é o nome do sistema responsável. Este sistema dirá ao browser Web onde está o servidor responsável. Mais detalhes são irrelevantes. Restam poucos outros interpretantes aceitáveis, e seus sistemas são cheios de números.

O segundo deste último conjunto é chamado path. Este path possui um interpretante básico: o sistema de arquivos do servidor significado pelo authority. É o mesmo que os arquivos na máquina de qualquer pessoa. É claro que, como é da natureza do mundo, existem diversos outros interpretantes possíveis, como por exemplo algum outro programa dentro do servidor Web que mapeia "pedrolamarao" para um negócio em um banco de dados.

Porém, tudo o que o browser Web precisa saber, parte do seu acordo com o servidor Web, é que para qualquer path o servidor Web enviará uma porção de dados. Na maioria das vezes, esses dados estão de acordo com a norma HTML ou CSS e devem ser interpretados através destas -- seus interpretantes. É claro que nem sempre é assim, já que vêm também scripts Javascript, fotos JPEG, música MP3 etc. etc.

Como o browser sabe qual será o interpretante mais adequado para cada um desses símbolos bizarros de 0s e 1s que vêm pela rede? A semiose durante um simples abrir de página é complexa e cheia de elementos, e será finita apenas até o ponto em que o engenheiro perder o interesse nos detalhes do sistema.

A cada passagem de símbolo a símbolo por um interpretante escolhido por qualquer agente nessa confusão toda há chance para algum problema. Administradores de servidor Web vivem às voltas com "página não encontrada" e arrancam os cabelos para entender porque um determinado path não foi encontrado. Volta e meia um browser Web resolve imprimir um monte de lixo na tela quando o usuário tem certeza que está baixando um filme. Às vezes um sujeito digita o nome de um site e o browser Web diz "nome não encontrado". O que acontece quando a configuração do DNS está com defeito!? E alguns infelizes usam sistemas que não tem muita certeza sobre o que fazer com nomes começando com "http".

Toda vez que surge um novo sistema de componentes na indústria há bravatas sobre o desenvolvimento de um novo tipo de "nome globalmente único". É o grande sonho da humanidade, ser capaz de nomear os entes sem ambiguidade. Todo um conjunto de sociedades esotéricas existe em desespero para aprender o Idioma de Adão, que soube nomear todas as coisas sem hesitação. Os humanos com senso prático compreendem que nomes são acordos entre as partes e estabelecem tais acordos entre si. O schema "http" por exemplo possui um significado em acordo estabelecido sob a autoridade do IANA. Mas você sabe o que IANA significa?..

Semiótica e Programação 3

2009-12-30T15:50:06+00:00

Do ponto de vista do Java e do C#, C++ é uma linguagem fracamente tipada. Apesar de dizer isso abusar dos termos, existe um fundo de verdade ali.

C++, ao contrário de Java e C#, permite a formação de referências arbitrárias a qualquer objeto -- mesmo objetos hipotéticos.

Programas como este são aceitáveis, para o compilador:

list<string>* l = (list<string>*)0x12345;
l->sort();

Esta propriedade é inútil para a maioria dos programas, o que torna C++ excessivamente complicada aos olhos da maioria dos programadores. Se o programa está dizendo que naquele lugar ocorre um list<string> então isso deve ser verdade, certo? Boa sorte!

Existem programas que fazem uso dessa possibilidade, como programas para máquinas onde certos endereços são especiais e têm significado pré-definido.

Programas como este também são aceitáveis:

dog* marley = new dog();

spaceship* one = (spaceship*)marley;

one->launch();

Essa possibilidade é inerente à máquina, na medida em que o significante de uma referência existe apenas no mundo do discurso; a máquina conhece apenas bits. A reinterpretação de um padrão de bits é uma operação de pura semiótica: não é necessário computar nada, apenas compreender os bits de uma forma diferente. Assim sendo, C++ se limita a dizer que não fará esforço para garantir que esse programa faz sentido -- o problema é todo seu.

A estrutura que o tipo de uma referência impõe ao programa pode ser tal que nem todos os padrões de bits possíveis para aquele segmento de memória tenham um significado. Assim, apesar de o programa afirmar que ali está um objeto spaceship, o padrão de bits que ocorre ali pode não representar um objeto spaceship -- e o programa é literalmente um absurdo.

Em outras palavras, esse programa potencialmente viola invariantes do tipo spaceship, que são pré-condições automáticas para a chamada da função launch.

A reinterpretação irrestrita de objetos é uma das características mais estranhas dessa linguagem, e mais difícil de pôr em prática de forma útil.

Um desses usos é a transferência de objetos entre programas através de um dispositivo, técnica em que o programa receptor obtém uma pura sequência de bytes e assume que ali está o objeto transferido. Isso é chamado serialização porque torna o objeto, que possui significado e estrutura, em um série de bits.

Outro desses usos é a técnica de move construction do Elements of Programming, onde o objeto é reinterpretado de acordo com sua underlying class e copiado como tal -- e esta cópia é justamente a movimentação desejada.

Semiótica e Programação 2

2009-12-30T12:55:38+00:00

Linguagens cuja proposta é tipagem forte permitem através de sua sintaxe a expressão de constrições sobre a manipulação do estado de um objeto denotado por uma referência. Linguagens cuja proposta é tipagem fraca permitem manipulações de objetos com pouca constrição.

Entendendo uma referência nesse contexto como o mesmo que um signo, o tipo é o significante de uma referência, impondo significado ao objeto denotado.

Para o programa, o tipo impõe constrições sobre as manipulações possíveis ou válidas desse objeto. Em linguagens como C++, a diferenciação dos tipos permite a seleção de uma entre diversas operações possíveis de modo particularmente significativo para o objeto referenciado.

Naturalmente, programas podem formar diversas referências ao mesmo objeto, o que causa diversas dificuldades à especificação do significado de um programa como um todo e atrapalha ferramentas de transformação de código -- o "problema de aliasing".

A especificação da máquina abstrata que determina o significado de um programa deve responder de algum modo a questão: suponha uma referência a cujo tipo é A e uma referência b cujo tipo é B onde ambas denotam o mesmo objeto; suponha que um programa escreva um valor válido através de a e então leia um valor através de b; qual é o significado desse programa para A e B arbitrários?

Linguagens de tipagem fraca frequentemente realizam conversões auto-mágicas internamente de modo que o programa acima sempre possui um significado compreensível. C++ dirá que o programa acima possui em geral um significado indefinido.

Semiótica e Programação

2009-12-28T11:11:47+00:00

É interessante observar que podemos sem erro considerar todo nome de variável e função em um programa C++ como uma referência. Esta referência, assim como possivelmente muitas outras, denotam um certo objeto que, em si, não passa de uma combinação de três informações: um local, uma quantidade de armazenagem, e um estado atual. Referências cujo tipo é ponteiro-para-Foo conotam um objeto do tipo Foo.

Drivers de Boot no Windows

2009-12-17T15:05:39+00:00

Tenho acompanhado o trabalho do meu amigo Lesma, que em seu blog tem descrito como o processo de boot transforma um apanhado de bytes no disco rígido em um sistema operacional vivo. Pegando carona nesse tema, vou aproveitar para comentar sobre a ordem de carga dos drivers durante este processo. Com isso posso tentar responder uma pergunta frequente dos leitores: "Como fazer para que meu driver seja o primeiro a ser carregado?". Talvez este post possa clarear um pouco as coisas neste sentido, ou não.

Eu primeiro! Eu primeiro!

Um ponto importante a ser considerado no modelo Legacy quando escrevemos um driver é o referente ao momento no qual seu driver é carregado. Isso é configurado no valor "Start" na chave do driver no registro. Quatro valores configuram o momento da carga do seu driver, sendo eles:

Boot (0) - Drivers são carregados durante o boot, antes mesmo sistema operacional estar completamente pronto para execução.
System (1) - Drivers são carregados depois dos drivers de boot, quando o Kernel já está completamente funcional.
Automatic (2) - Neste grupo os drivers são carregados quando os subsistemas forem carregados. Basicamente junto com os serviços de User Mode.
Manual (3) - Nenhuma carga automática é realizada aqui, o driver é carregado somente quando alguém, ou algum componente, solicita sua carga.
Disabled (4)- Mesmo que o driver seja solicitado, sua carga é negada.

"Bom, então para meu driver ser o primeiro a ser carregado ele precisa ser iniciado como boot e pronto?"

Na verdade seu driver vai disputar um lugar na fila de drivers que querem ser iniciados no boot. Vários drivers estão configurados para ser iniciados nesse momento e o seu será apenas mais um. Mesmo entre os drivers de boot, uma ordem de carga precisa ser seguida para que certos drivers possam contar com os serviços de outros drivers. Por esse motivo, drivers se separam em grupos. Um grupo de cada vez vai sendo iniciado até que todos os drivers de boot passem por esse processo.

Drivers identificam seu grupo pelo valor "Group" encontrado em sua chave de registro. Esta chave deve conter o nome do grupo ao qual o driver pertence. Os nomes de todos os grupos podem ser encontrados na chave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder. Nela existe um valor do tipo REG_MULTI_SZ chamado "List" que contém a lista de todos os grupos existentes dispostos em sua ordem de carga.

"Tudo bem, meu driver está configurado para ser iniciado em Boot e está configurado para iniciar com o primeiro grupo de drivers. Pronto agora?"

Quase. Quando falamos em iniciar grupos de drivers, já fica sub-entendido que mais de um driver será carregado. A ordem que tais drivers são carregados dentro de cada grupo também pode ser determinada.

A chave KHEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GroupOrderList mantém uma série de valores, cada um com o nome de um grupo. O valor é do tipo REG_BINARY e sua interpretação é um array de conjuntos de quatro bytes. O primeiro conjunto indica quantas tags estão contidas naquele buffer binário. Os demais conjuntos são as representações numéricas de cada tag. Dessa forma, a interpretação do buffer exibido na figura abaixo nos dá a informação de que temos seis tags, sendo elas: 1, 2, 3, 4, 5 e 6.

"Mas o que é uma tag?"

Uma tag é a identificação numérica de um driver dentro de um determinado grupo. Um driver se identifica pelo valor "Tag" que podemos encontrar na chave do driver no registro.

Apesar de o exemplo nos mostrar uma ordem crescente de tags, o valor da tag não determina a ordem de carga dos drivers. A ordem é determinada por sua posição dentro do buffer binário.

Ficou com nojinho de mexer em buffers binários? Você pode utilizar o OSR Driver Loader que configura tudo isso pra você quando utilizado para instalar um driver.

Colocar sua tag como primeiro na lista de tags classifica sua ordem de carga dentro de um determinado grupo, mas ainda não é fator determinante para ter seu driver carregado antes de todos os drivers do universo. Um novo grupo sempre pode ser criado e ter sua ordem de carga configurada para antes do seu grupo.

Todas essas regras sobre grupos, tags e afins não fazem sentido nos drivers gerenciados pelo Plug-And-Play (Pnp) Manager, já que a carga de tais drivers é solicitada quando o dispositivo ao qual seu driver está relacionado é detectado pelo driver de barramento.

"Aff! Fernando, pega leve e tenta explicar isso de novo."

Tudo bem, vamos lá. Quando você instala um driver Pnp, você o associa a um determinado dispositivo. Apenas como exemplo, digamos que esse dispositivo seja um conversor USB/Serial. Seu driver será carregado automagicamente quando seu dispositivo for detectado e será descarregado quando o dispositivo for removido.

Para que ele seja detectado, outros dispositivos precisam ser detectados antes, tais como controladora PCI, controladora USB e hub USB. Essa lista de dependência cria a pilha de dispositivos USB.

A controladora PCI, ao ser detectada, tem seu driver carregado e este enumera seus dispositivos filhos, já que PCI é um barramento. Para cada disposivito detectado, esse driver utiliza o barramento para detectar a identidade de cada dispositivo e cria um Phisical Device Object (PDO) para cada um deles. O Pnp Manager carrega o driver de cada dispositivo atachado a esse barramento. Esse driver criará o Functional Device Object (FDO) do dispositivo, dando funcionalidade a ele.

Um desses dispositivos é a controladora do barramento USB. Seguindo o ritual, o driver de barramento USB enumera seus dispositivos filhos, criando novos PDOs. Assim, os hubs USB são detectados e seu driver será carregado. Este driver criará um novo FDO para cada hub. O driver de hub USB vai enumerar seus dispositivos filhos e é nesse momento que seu dispositivo é detectado. O driver que você escreveu será carregado e o Pnp Manager irá chamar sua rotina AddDevice, que receberá o PDO que o driver de hub criou referente ao seu dispositivo.

Ufa! Tudo bem, tenham calma. O assunto Plug-And-Play não é o foco deste post e já está na minha lista de posts futuros.

Toda essa atividade que age recursivamente serve para montar a árvore de dispositivos do sistema. Sabendo que esta árvore é formada pelos nossos drivers e seus devices, fica explícito aqui que no fundo "As árveres somos nozes". A figura abaixo dá uma idéia de como a árvore de dispositivos é organizada.

Ainda falando sobre ordem de carga de drivers, não faria sentido ter seu driver carregado antes de todos os outros drivers, já que os componentes básicos para a comunicação com seu dispositivo ainda não foram carregados, e por isso, não possuem funcionalidade nenhuma. Além do mais, ter seu driver carregado muito cedo lhe trará problemas em lidar com outros componentes do sistema que ainda não estarão prontos para atender seu pedido. Mais detalhes neste post.

Depurando no Boot

Outro assunto curioso e que pode gerar alguma confusão é o referente ao debug de drivers que são carregados no boot. Apesar de a conexão de Debug usar o meio serial, firewire ou mesmo USB, os drivers referentes a estes meios não precisam estar carregados para que você possa realizar o debug do sistema. Em outras palavras, o driver de porta serial não é utilizado para fazer debug do sistema quando se usa o meio serial. Isso seria um problema se pensarmos que alguns drivers são carregados e inciados antes do driver de porta serial. Como estes drivers seriam depurados?

O fato é que o algoritmo que lida com os meios de depuração do sistema são definidos no próprio Kernel (mais precisamente no módulo ntoskrnl.exe e seus irmãos). Este módulo lida diretamente com o hardware responsável pelo meio utilizado. Essa é também a explicação para outra pergunta frequente: "Meu computador não tem porta serial. Posso usar um conversor USB/Serial do lado Target para fazer debug do sistema?". Como acabamos de ver, um conversor USB/Serial depende de toda uma pilha de dispositivos para que a porta serial esteja disponível. Tal funcionalidade não está implementada no algoritmo de debug do sistema, e como comentei neste outro post, sistemas mais novos implementam novas funcionalidades de debug no Kernel.

Mesmo que seu driver seja de boot, ele ainda pode ser depurado. Este outro post mostra ainda como fazer mapeamento de um driver de boot pelo WinDbg. Não sabe do que estou falando? É sobre ter seu driver substituído por uma nova versão automaticamente no lado target quando este for carregado. Vale a pena dar uma olhada.

Have fun!

Lendo e medindo o tempo em C e C++: função time()

2009-12-16T19:09:33+00:00

Bom, chega de teoria e encheção de lingüiça e vamos para o código de uma vez por todas. A função mais conhecida para pegar a data e hora é a função time() da C runtime, que retorna quantidade de segundos desde o "Unix Epoch", que é meia noite (00:00:00) de 1 de Janeiro de 1970.

Características da função time():

Retorna a quantidade de segundos desde 1 de Janeiro de 1970. Ou seja, a sua precisão máxima é de um segundo. Ou seja, não serve para medir performance. (ou seja, vou explicar mais sobre isso depois)
O horário retornado é GMT, para pegar o horário local é necessário fazer manualmente o cálculo para ajuste de fuso horário. Para usar o horário local é necessário usar a função get_timezone (ou _tzset no Visual C++) para ler a diferença do fuso que você usará para fazer o cálculo depois
Como o retorno da função é um número inteiro, é muito fácil fazer contas com ele. Para avançar a data em dois dias, por exemplo, é só somar [60 * 60 * 24 * 2].
Durante o inicio dos tempos do unix o retorno era do tipo int de 32 bits. Fazendo uma conta simples com os limites de um inteiro, vemos que o limite de medição é algum dia no ano de 2038, criando uma nova e repaginada versão do bug do milênio. Nas versões mais atuais dessa função o retorno é um int64, o que empurra o limite para uma data bem longínqua, quando provavelmente não haverá mais programadores vivos no universo.
Por ser uma função da C runtime, está disponível em qualquer compilador C e C++ (qualquer == qualquer compilador não-exótico para plataformas não-exóticas). É provavelmente a função mais multiplataforma de todas que eu vou mostrar

Como um trecho de código vale mais do que 0xFFFFFFFFFFFFFFFF palavras, here we go:

#include <stdio.h>
#include <tchar.h>
#include <time.h>
#include <iostream>
#include <iomanip>
#include <string>

using namespace std;

void print_time(time_t t)
{
  tm* formatted_time;

  //
  // essa função "quebra" essa quantidade de segundos e dia, mês, ano, etc
  //
  formatted_time = gmtime(&t);

  //
  // isso vai mostrar algo como "2009/12/07 14:42:57"
  // note que é necessário somar 1900 na data para pegar o ano corrente
  //
  cout  setfill('0')  
    setw(4)  formatted_time->tm_year+1900  "/" 
    setw(2)  formatted_time->tm_mon+1  "/" 
    setw(2)  formatted_time->tm_mday  " " 
    setw(2)  formatted_time->tm_hour  ":"  
    setw(2)  formatted_time->tm_min  ":"  
    setw(2)  formatted_time->tm_sec  endl;
}


int main()
{
  time_t t;

  //
  // pega o número de segundos desde 1970
  //
  t = time(NULL);

  //
  // mostra na tela, formatado
  //
  print_time(t);

  //
  // pega o fuso horário da máquina para pegar o horário local
  // ao invés de GMT. 
  //
  long timezone;

  _tzset(); // carrega as configurações de fuso

  _get_timezone(&timezone); // lê a diferença do fuso

  cout  timezone  endl;

  //
  // ajusta o horário pelo fuso
  //
  t -= timezone;

  print_time(t);

  //
  // avança da data em 2 dias
  //
  t += 48 * 60 * 60;

  //
  // mostra novamente
  //
  print_time(t);

  return 0;
}

Esse código foi feito no Visual C++ (Windows). Existem pequenas diferenças nos nomes das funções no Linux, mas o conceito é o mesmo. Consulte sua documentação preferida para detalhes específicos.

1 comentário(s)

O mistério do sizeof – parte 3

2009-12-16T14:43:01+00:00

Código Fonte: #include <cstdlib> #include <iostream> using namespace std; struct A { void funcaoA() {} }; struct B { void funcaoB() {} }; struct C { void funcaoC() {} }; struct ABC1 { A a; B b; C c; }; struct ABC2: public A, public B, public C { }; int main(int argc, char *argv[]) { cout << "sizeof( A ): " << [...]

bytes e suas interpretações

2009-12-01T21:36:54+00:00

Houve época em que, ao programar C#, sempre me irritava ver a notação byte -- me parecia estúpido ter um tipo na linguagem de programação chamado byte.

Li hoje em um manual da Intel:

"Although bytes, words, and doublewords are fundamental data types, some instructions support additional interpretations of these data types to allow operations to beperformed on numeric data types (signed and unsigned integers, and floating-point numbers)."

Hoje, programando em C++, me irrita que não exista uma distinção entre char-que-é-sequência-opaca-de-bits, char-que-é-número-inteiro e char-que-é-elemento-alfabético.

O texto do manual é interessante; para a máquina, realmente existe apenas o byte e suas variantes como padrões de bits; o que quer que você faça de interessante com esse byte implica uma interpretação desse byte.

A máquina é untyped; não existe mecanismo formal pelo qual se possa deduzir que uma interpretação para este byte é correta ou incorreta. Dependendo de quem você é, isso pode parecer ótimo ou absurdo.

As razões porque isso é ótimo são boas, mas diminuiriam muito com algumas poucas extensões do C++. Programadores de aritmética com poucos recursos computacionais aprendem rapidamente, por exemplo, que a máquina pode computar muito rapidamente produto e divisão por 2 sem usar as instruções de produto e divisão de inteiros -- usando as instruções de shift de sequências de bytes. Esses programadores podem argumentar que essa é a vantagem da programação untyped.

Felizmente, podemos pensar de trás pra frente; aceitando como axioma que a memória representa sempre bits, então devem haver implementações ótimas para produto_por_2 e quociente_por_2 -- assim como é_par e é_negativo. Isso sugere que uma linguagem de programação com esses operadores nativos para números inteiros satisfaz as necessidades do programador acima -- diminuindo drasticamente a necessidade de permitir shifts em objetos do tipo inteiro.

Essa idéia me vem do "Elements of Programming", de Stepanov e McJones; no livro eles discutem a idéia de "base computacional" de uma estrutura de dados. Quando aritmética inteira é implementada em uma máquina binária, produto_por_2, quociente_por_2, é_par e é_negativo devem fazer parte da base computacional dos tipos inteiros -- simplesmente por serem especialmente rápidas.

(No livro, eles não estudam representações de números reais; alguém se habilita a compor uma base computacional para números reais representados como em IEEE 754?)

[Editado!]

Acho, além disso, interessante a definição de certos tipos de dados inúteis no manual da Intel, como bit field e string. Essas definições parecem mais sugestões de uso que definições, já que nem um bit field nem um string é mais que um ou mais bytes contíguos.

Me parece que essas definições apóiam a definição posterior de operações extendidas ou especializadas sobre bytes, como referências a bits individuais ou cópia otimizada de bytes contíguos. É claro que essas são, ainda, operações simples sobre sequências de bits, e não demandam interpretação especial.

Droplet

2009-12-01T00:34:01+00:00

Esbarrei com este projeto que achei bastante interessante, como um link às vezes é mais verboso do que mil palavras:

- Droplet

Liga dos Programadores Independentes: primeira reunião

2009-11-30T19:32:12+00:00

Como temos quorum suficiente, está confirmada a primeira reunião para dia 2 de dezembro, quarta-feira, no O'Malleys, a partir das 19 horas. Com não sei exatamente quantas pessoas irão aparecer, vou reservar mesas para 10 pessoas. Como eu já tinha dito, lá as comandas são individuais e cada um paga sua própria conta. Chegando pergunte onde ficam as mesas e tenha certeza que um monte de programadores reunidos é algo bem fácil de achar.

Só para esclarecer o debate do post anterior: você faz parte do público alvo do encontro se você é programador e tem uma idéia (implementada ou não) para fazer um software (produto ou serviço) para vender e ganhar dinheiro, não importa o motivo. Você pode estar puto com seu chefe e odiar trabalhar das 9 às 6 ou simplesmente ter vontade de abrir sua própria empresa. O encontro é para que programadores solitários e independentes tenham pessoas para discutir a viabilidade das suas idéias, e para discutir também métodos para colocá-las em prática. Para discutir métodos de desenvolvimento para transformar suas idéias em produtos e serviços e viver disso.

Você não faz parte do público alvo se você tem a idéia para um software mas não consegue escrever o software sozinho. Esse encontro especificamente não é um bom lugar para encontrar um programador para implementar a sua idéia. Para isso tente a apinfo. Talvez isso mude se o grupo crescer e se organizar, seria ótimo um encontro para juntar pessoas com boas idéias com pessoas com conhecimento técnico para executá-las. Não é (preconceito|elitismo|frescura|complexo de superioridade), é só questão de foco e redução de pauta para tentar fazer desse encontro o primeiro de muitos.

8 comentário(s)

Mais um Engenheiro à solta

2009-11-30T17:10:42+00:00

Ufa! Quarta-feira passada foi minha última prova da universidade. Parece mentira mas finalmente o curso de Engenharia da Computação chegou ao fim. Ainda temos que entregar uma papelada do projeto de conclusão de curso, mas são apenas papéis. Acabaram as provas, os trabalhos, os relatórios e agora um baita peso começa a sair das minhas costas à medida que as notas vão sendo liberadas no site da universidade. Quem me segue no Twitter teve uma idéia da correria que tem sido. Esse ano foi especialmente apertado por conta das dependêcias que tive que cursar, do estágio que tive que fazer, e por fim, do projeto de formatura que tivemos que apresentar.

O projeto foi o maior responsável pela minha ausência no blog, foram muitos testes, sustos, sensores queimados, apresentações e feiras.

Pera aí! Você disse sensores queimados?

Isso mesmo. Murphy pode ser considerado um integrante do nosso grupo já que esteve sempre presente no desenvolvimento do projeto. Nas vésperas da apresentação para a banca avaliadora, um mal contato nos reguladores de tensão, originado pela trepidação do motor do helimodelo, fez com que quase tudo se queimasse. Foi um desespero geral, já que os sensores eram importados. Sem falar da grana que teríamos que desembolsar, ainda teríamos que aguardar a entrega que ocorre em média em duas semanas. Nesse momento Murphy nos deu uma trégua. Particularmente acho que ele ficou com pena de nós. Digo isso porque no dia seguinte encontramos uma revenda de sensores similares aos que estávamos usando no projeto aqui em Santo André (cidade onde moro). Quando entramos em contato com a revenda, descobrimos que eles tinham os sensores em estoque. Inacreditável não?

Depois da apresentação que fizemos para a banca avaliadora, ainda fomos convidados a participar da apresentação de gala da universidade, onde os melhores projetos do ano foram exibidos.

Também ficamos em segundo lugar no concurso "Melhor Aplicação Acadêmica Baseada em PC" promovido pela National Instruments, e com isso fomos convidados a expor nosso trabalho no stand da National no ISA Show 2009. O mais legal é que o primeiro lugar deste concurso foi conquistado por um grupo também da minha sala na Universidade São Judas Tadeu. Isso evidenciou que além de ficarmos na frente de várias outras universidades, mostrou que nossa sala né brinquedo não.

A National Instruments produziu este vídeo explicativo onde eu falo sobre a idéia básica do projeto. O vídeo foi feito na chácara de um dos componentes do grupo, onde ficamos internados nas últimas semanas antes das apresentações finais.

Este é apenas um post de "Ei, estou voltando do coma!". Agora vou parar de falar sobre o projeto e voltar a falar sobre o que realmente interessa: "Telas Azuis da Morte". O meu grande dilema agora é se devo também comentar algo sobre firmware e hardware. Desenvolvi muitas atividades com software embarcado não só durante a produção do projeto.

Durante o projeto, sobretudo desenvolvendo protocolo USB em um 8051 utilizando o Keil, além de ler sensores e trabalhar com barramentos em um PIC utilizando o compilador C18 no MPLAB.

Além disso, tive a oportunidade de contribuir no desenvolvimento de um projeto do IPEI. O hardware deste projeto mede os resultados de uma máquina de tração e os envia a um computador via USB. Contribui no desenvolvimento do firmware PIC implementando o protocolo HID mais uma vez utilizando o MPLAB.

Por último e não menos importante, também contribui no desenvolvimento de firmware FreeScale durante meu estágio na Commodity. Este firmware também lida com protocolo USB, e conta com o auxílio de um chip que dispoê desta interface, já que o DSP que compunha a solução não o fazia. Desta vez tive que utilizar o Code Warrior no desenvolvimento, e revivi o tempo em que trabalhei na Provectus desenvolvendo um Bootloader para a atualização do próprio firmware via rede 485, só que dessa vez foi através da USB.

Tanta interação com a USB de ambos os lados do cabo é principalmente fruto dos conhecimentos adquiridos com o livro "USB Complete" de Jan Alexlson. Não me lembro se já comentei sobre esse livro aqui antes, mas vale a pena falar dele principalmente sobre do ponto de vista eletrônico/firmware. O livro é simplesmente ótimo, mas diz não cobrir o desenvolvimento de drivers para USB pois tal assunto daria um livro à parte. Com isso ele indica um velho conhecido nosso, o "Programming the Windows Driver Model" de Walter Oney.

De qualquer forma, aguardem por reformas neste blog. Durante muito tempo tenho trabalhado no limite para conseguir postar e ainda dar conta de todo o resto. Agora meu tempo extra me permitirá fazer posts com mais frequência e finalmente montar turmas abertas do Curso de Drivers para Windows.

Como alguns de vocês já sabem, mantenho uma lista de interessados no curso e que serão notificados por e-mail quando as turmas forem abertas. Independente disso, gostaria de receber e-mails sobre preferências de horários e especialidades, tais como WDM/KMFD/UMDF/File Systems ou ainda sobre ênfase em USB/PCI.

É isso aí. Para um post que não tinha nada a dizer, até que esse disse muito.
Até breve!

C++ em múltiplas configurações

2009-11-29T12:12:39+00:00

Parte dos meus esforços em entender o ambiente de programação C++ é buscar os padrões de uso do pré-processador, algo que eu nunca encontrei catalogado sistematicamente.

Ao meu ver, existem dois grandes grupos de usuários do pré-processador: programadores que usam macros como formas de reusar código totalmente inline, e programadores que usam macros para variar a definição de um programa C++ de acordo com variáveis de configuração.

A comunidade do C++ acredita que a necessidade de usar macros hoje praticamente não existe; essas pessoas deveriam ser mais específicas e dizer que a necessidade de usar macros para reusar código totalmente inline já não existe, porque compiladores otimizadores e templates de função são capazes de fazer isso.

(Eu chamo reusar código totalmente inline a uma forma de reuso que insere código diretamente no chamador, sem utilizar o mecanismo de chamada de subrotina, que envolve empilhamento, desempilhamento e saltos.)

Porém, não há solução sintática para o problema das configurações -- ao menos, não há solução bem conhecida. É interessante ler sobre a história do autoconf.

Otimização nas Sombras do C++

2009-11-26T15:50:09+00:00

Eu não encontro pessoalmente esse tipo de coisa com muita frequência atualmente, mas foi tempo em que volta e meia me aparecia código-fonte muito esperto, ou críticas muito espertas sobre o meu código-fonte, com relação a quão "ótimo" ele é.

Em C, essas espertezas eram invariavelmente transformações de uma notação legível e imediatamente representativa do algoritmo lógico por uma notação ilegível, equivalente mas que executava mais rápido.

Truques de aritmética de ponteiros para escrever mais rápido na memória, truques horrendos com while e switch sem break pra desenrolar loops -- vários truques cujo objetivo é escrever o mesmo código gerando um programa melhor.

De certa forma, os truques dessa época eram motivados pelos compiladores dessa época, máquinas de transformação burra de C para assembler. Com o objetivo de gerar o melhor assembler, programadores produziam pior C -- mais rápido, sim, mas menos legível e de mais difícil manutenção.

Com o passar do tempo, os compiladores se tornaram otimizadores, capazes de inlining, remoção de código morto, desenrolamento de loops, progragação de valores constantes etc.

As máquinas, por sua vez, introduziram pipelines para otimizar o trabalho de processador mais e mais rápido que a memória, capazes de execução computações intermediárias simultaneamente a recuperação de dados da memória, especulação sobre valores futuros para adiantar computações etc.

Compiladores cientes do pipeline passaram a otimizar ainda mais, ordenando e reordenando instruções de modo a obter o melhor desempenho do otimizador alvo.

Quem tem à mão um excelente compilador otimizador não precisa mais se preocupar em produzir código esperto. O compilador quase invariavelmente é melhor do que o programador humano. Ele também é a ferramenta adequada para a esperteza -- porque projetos críticos frequentemente transformam um código-fonte em programas para diversas máquinas, onde as peculiaridades variam muito.

Mas então, um dia, surgiram as máquinas multi-processadas. A seguinte citação resume a tragédia da programação para tais máquinas:

Yeah, I know. "Multithreading is hard" is a cliché, and it bugs me, because it is not some truism describing a fundamental property of nature, but it’s something we did. We made multithreading hard because we optimized so heavily for the single threaded case.

O problema fundamental de um programa multithreaded em uma máquina onde os processadores compartilham a memória é o de garantir que um certo objeto lógico -- uma sequência de bytes na memória -- não será escrito e lido de forma incosistente por múltiplos processadores -- porque um está escrevendo pela metade quando outro está lendo, etc.

Por mais que um programador faça esforço para ordenar adequadamente as instruções em um programa -- de modo que qualquer ordem de leitura possível faça algum sentido -- o fato é que o otimizador do compilador, e o otimizador do pipeline, fará mágicas com a presença e a ordem das instruções, violando a expectativa do programador.

Desse modo, os truques espertos da atualidade não são truques para otimizar o assembler e sim truques para evitar inconsistência no acesso concorrente à memória.

As pessoas legais agora falam sobre atomics e memory barriers.

O que há de curioso aqui é que esse problema espirra em certas direções mesmo onde não há múltiplos threads. Ao programar uma máquina com suporte a memory mapped I/O o mesmo problema de consistência ocorre sobre um endereço memory mapped -- reordenar leituras e escritas ali resulta no caos.

Tendo chegado até aqui, releia seu livro favorito sobre C++ sobre o significado da palavra-chave volatile.

A Liga dos Programadores Independentes

2009-11-25T10:22:20+00:00

Eu tenho certeza que não sou o único programador com ideias mirabolantes para dominar o mundo. Seja um projeto de software para ficar bilionário ou um simples serviço online para ajudar o ego (com Google Adwords para ajudar mais ainda o ego), já ouvi várias boas ideias de várias pessoas com quem trabalhei e convivi. O grande problema é que ninguém tem a organização e foco necessários para tocar um projeto desses. Eu também não, mas estou tentando chegar lá. E depois de aproximadamente 17 candidatos a sócio (sócio-programador, não o financeiro), eu desisti de tentar apoio nas minhas empreitadas. Sou agora um programador independente.

Lendo o Twitter do Rafael Beckel vi que ele também estava com ideias para dominar o mundo, então liguei pra ele para marcarmos um chopp e conversar. Nenhum chopp depois (acabamos indo para o McDonalds) pensamos em montar um grupo de programadores malucos com ideias malucas, para termos com quem discutir nossas maluquices. Não é algo para discutir como montar um plano de negócio ou como conseguir dinheiro para financiar uma empresa. É para conversar sobre software. E sobre como manter o foco em um projeto quando você trabalha nele sozinho. E, claro, para ter pessoas para discutir suas ideias. O Rafael também escreveu sobre a conversa que tivemos.

Como eu já disse, o foco é software. Pode ser indelicadeza da minha parte (sendo "indelicadeza" um puta de um eufemismo), mas pessoas que não sabem programar e não são da área de software não seriam bem vindas nesse suposto grupo (não queremos montar um sebrae). O foco é software, o publico alvo são pessoas que sabem fazer software. Com as próprias mãos. Pessoas que querem discutir organização e método para terminar seu software, já que não adianta ter um plano de negócio ou zilhares de pesquisas de sei-lá-o-que se você não tem software para o usuário interagir.

Minha idéia é um primeiro encontro de buteco para discutirmos o formato do grupo. Dia 2 de dezembro, quarta-feira, no O'Malleys que fica perto da Paulista. Além de ser um lugar onde é possível conversar, a comanda é individual e não tem 10%. Quem não quiser me acompanhar me acompanhar no pint de Guinness pode tomar um refrigerante e não dividir a conta com os malditos programadores bêbados. Comentem sobre a data e hora e farei um outro post semana que vem confirmando o horário e local.

23 comentário(s)

Mais sombras no Ambiente de Programação C++

2009-11-23T17:55:04+00:00

Estou lendo a ementa do curso de pós-graduação em Análise e Projeto de Sistemas da PUC-Rio, onde ocorre o seguinte:

"Laboratório de Linguagens de Programação

Objetivo – Capacitar o aluno a distinguir os principais componentes de linguagens de programação não convencionais tais como: programação orientada a objetos, programação orientada a eventos e programação para Internet/intranet."

A presença de "programação orientada a eventos" ali é interessante; a ementa prossegue em explicar que neste módulo o aluno aprenderá a programar Applets Java, que são orientados a eventos.

O que se chama "orientação a eventos" ali é uma técnica de projeto de aplicativos úteis plugados em algum tipo de framework de apoio, que cuida de enviar os tais eventos para o aplicativo.

Há um sub-grupo dos programadores de C++ que dirá a você que "não programa interfaces de usuário". Essa é uma afirmação interessante porque, compreendido com rigor máximo, significa que os programas produzidos por essa pessoa produzem resultados totalmente invisíveis.

Todo programa de computador possui uma interface de usuário -- senão, o usuário nunca veria seu resultado. Programadores C++ são criados desde o berço para produzir programas cuja interface com o usuário é o terminal -- um dispositivo capaz de apresentar um mapa de 80x24 caracteres.

O que há de interessante nisso é que existe um mecanismo subjacente a esse terminal que suporta a parafernália usada para pôr ali os tais caracteres -- std::cout, printf etc. Esse mecanismo é inicializado, mantido e finalizado pela implementação do C++ de forma oculta ao usuário.

Existem ambientes peculiares onde o C++ não inicializa nada disso -- ou inicializa essas coisas de forma inesperada. Os compiladores da Microsoft oferecem um parâmetro de chamada ao compilador para selecionar o "subsistema" -- CONSOLE ou WINDOWS. Aplicativos compilados para o subsistema WINDOWS não fazem coisas úteis quando o programa chama printf.

No projeto onde estou alocado agora, o sistema implantado no dispositivo-alvo é altamente customizado, e a biblioteca padrão C++ apresenta esquisitices parecidas. Não existe um "terminal" e chamar printf às vezes não faz nada, às vezes bloquea o sistema eternamente em um signal handler.

Bibliotecas como a Qt e a Glib oferecem uma terceira via, que talvez pudesse ser compreendida como um terceiro subsistema, o EVENT_LOOP. Esse subsistema possui sua própria API e faz tudo pela aplicação, que apenas inicia operações no sistema e senta esperando por notificações sobre o resultado. Assim são os Applets Java.

Tudo isso sugere que o ambiente de execução do C++ executa mais que apenas o código da aplicação, e de fato existem atividades que ocorrem antes de main iniciar e depois de main finalizar. O programador atento procurará pelo código-fonte ou executável do CRT no seu sistema -- o C Run-Time.

WebCast sobre DLR no .NET Framework 4.0

2009-11-18T20:04:24+00:00

Amanhã 12:00hs estarei apresentando o "MSDN Webcast: Trabalhando com o DLR no .NET Framework 4. Falarei da versão nova da DLR (Dynamic Language Runtime) que fará parte do .NET 4.0, de IronPython e sobre como integrar scripts Python no C#.

Parece que ainda consta o nome do Alfred Myers como apresentador, mas eles devem arrumar isso logo

0 comentário(s)

Meu Twitter

2009-11-18T12:55:53+00:00

Também é sobre programação e afins (com poucos avisos úteis tipo "acabou a luz aqui, catso, perdi meus fontes #apagão"). Não espere saber se eu acordei de bom humor ou se o filme xpto é bom ou não.

http://www.twitter.com/rodrigostrauss

0 comentário(s)

Lendo e medindo o tempo em C e C++

2009-11-17T20:32:18+00:00

Existem vários motivos para um programa consultar o "horário da máquina". Os mais comuns são registrar a data e hora de um acontecimento ou ação do usuário (data de acesso à um arquivo, por exemplo) ou medir o intervalo entre dois momentos para saber o tempo que algo levou.

Em C e C++ existem diversas maneiras de ler uma representação numérica de um determinado instante no tempo, e cada uma tem seu uso e característica. Essa salada de funções e APIs existem porque usando C e/ou C++ você tem acesso à todas as camadas de abstração (ou não-abstração), desde o relógio da placa mãe, passando pela BIOS, pelas APIs do sistema operacional até as funções da runtime do C ou do boost::datetime. Nessa série de posts vamos ver as características de cada forma de ler o "horário da máquina".

Toda representação numérica de um instante no tempo é dada pela diferença entre o instante da medição e um instante tido como referência. Quando usamos uma data e hora no nosso calendário gregoriano, tomamos como referência a "data tradicional da encarnação de Jesus Cristo". Isso é uma referência. 26 de maio de 1980 é tradução de (instance referência) + (1980 anos) + (5 meses) + (26 dias). Passando essa data para qualquer pessoa/programa que use a mesma refererência, ela consigirá saber de que instante no tempo você está falando. É importante saber esse conceito porque em programação a referência muitas vezes é diferente da referência do calendário gregoriano (por motivos técnicos e não religiosos. Sem teorias da conspiracão, pelamordedeus).

Quando usamos uma data e hora "normal" (ou seja, do calendário), ainda temos outra variável na verificação do horário: o fuso e o horário de verão. O horário de Brasília (fuso de São Paulo, onde eu moro) é de -3 horas em relação ao horário GMT, que é tido como a referência mundial para os fusos (GMT é Greenwich Mean Time, horário de Greenwich na Inglaterra). O horário de verão não muda o fuso do país, mas adianta o horário em uma hora. Na prática, é como se São Paulo virasse GMT-2. O fuso é uma informação controlada pelo SO, e mudar o fuso pode causar mais problemas ainda. Os SOs tratam o horário de verão explicitamente. Quem cuida de sistemas de produção onde a data e hora é algo importante sabe o inferno que é quando começa ou quando termina o horário de verão.

Saindo da história e voltando para a programação, existem alguns fatores importantes para escolher qual sistema de medição usar. Um fator importante é se o instante referência é fixo ou não (calendário gregoriano x quantidade de segundos desde que a máquina foi ligada). O outro é a precisão da medição, geralmente em segundos ou menos. Se você precisa medir o tempo que leva para concatenar uma string, medir em segundos não vai adiantar nada (isso geralmente leva nanosegundos).

Resumindo o que precisamos saber para escolher que função ou API de tempo usar:

Referência: se é uma referência fixa (início do calendário gregoriano) ou uma referência relativa (hora de início da máquina ou de inicialização do sistema operacional)
Precisão do retorno. Não adiantar usar uma função que retorna a hora com precisão de segundos se vou fazer um cálculo de período que leva microsegundos.
Precisão de leitura. Existem funções que retornam em milisegundos, mas a precisão é menor que isso. A função GetTickCount da API Win32 retorna a quantidade de millisegundos desde o início do sistema, mas sempre em intervalos maiores do que 15ms. Ou seja, ele não consegue medir algo que leva menos do que 15ms
Performance. Algumas funções de leitura de hora são mais rápidas que outras. Se vocês faz isso dentro de um loop, isso faz diferença

Por exemplo, uma função com precisão baixa pode ser usada para medir o tempo de abandono do meu blog, já que faz muuuito tempo que eu não atualizo isso aqui :-)

O próximo post terá código. Não se preocupem, estou mais ansioso por isso do que vocês.

4 comentário(s)

techberto

2009-11-17T01:47:55+00:00

Neste 14/11/2009, o portal Embarcados e o grupo C & C++ Brasil com a produção da Tempo Real Eventos realizou, no Hotel Century Paulista em São Paulo, a edição 2009 do Seminário C & C++ para Sistemas Embarcados. Mais uma vez esta foi uma experiência extremamente gratificante, principalmente pela satisfação que alguns colegas, amigos e o público em geral demonstraram durante o desenvolvimento do seminário e pós sua realização.

O DQ, da Tamid, realizou em seu blog algumas notas e abaixo segue alguns comentário que não representa nem 1% do que foi o seminário:

- O evento iniciou com uma palestra sobre Interfaces de Periféricos com Microcontroladores em C do DQ, que mostrou-se um excelente conteúdo para um Hands On com o subtítulo de “21 formas de piscar um led com linguagem C em vários microcontroladores”!

- Na sequência foi a palestra do Luiz Barros, sobre Otimização de C++ para Sistemas Embarcados, que foi bem interessante e acabei em vários momentos dando meus pitacos, curiosamente mais uma vez confirmei que em aplicações com a plataforma SH4, C++ tem sido amplamente utilizado, durante o evento desenvolvedores de cinco empresas deram este feedback para mim.

- Durante o almoço, entre bits e bytes, conversamos de flamewares (e lembrei da lei do ricbit), assembly vs C++, surgiu a conversa de um projeto que me relataram muito inusitado de um sistema, onde… bom, deixa eu voltar para os relatos do seminário! :^p

- Após o almoço, o Alessandro Cunha, da TechTrainning, apresentou uma palestra que foi muito pontual tanto no assunto quanto no tempo consumido. Nos primeiros contatos com ele, fiz uma sugestão besta de tema e ele conseguiu extrair algo de bom da besteira que apresentei e formatou uma obra prima: Projetando Sistemas Embarcados com Baixo Consumo de Energia, com dicas preciosas que cativaram o público.

E encerrando o conteúdo técnico do seminário, o Luiz Barros desmistificou o “Desenvolvimento de Device Driver para GNU/Linux”, derepente surgiram algumas pessoas no evento e quando fui conferir descobri que elas vieram apenas para ver esta palestra, alguns até começaram a dizer que perderam o medo do device drivers development. Particularmente nunca tive medo, porém device driver & kernel development é uma arte negra…

Anteriormente ajudei a enumerar 17 formas de acender um led e derepente, não mais que derepente, fez-se a teatralização da piada:

- “quantos engenheiros são necessários para acender um led”

do qual eu participei desta teatralização como coadjuvante, no qual entrei mudo e sai calado e depois me disseram que a resposta seria:

- ”um de hardware, um de firmware e um de software” (tsc)…

Mas o Alessandro Cunha foi além e pensou em escrever o livro 2001 formas de acender um led, mas nem só de led foi o seminário! Houve CAN, RS232, SPI, microcontroladores, C, C++ e felizmente tive a oportunidade rever alguns amigos e realizar alguns contatos preciosos. Particularmente fiquei feliz que uma sugestão que eu dei a Microgênios foi levada a sério e hoje eles também estão produzindo e comercializando a plataforma Arduino no Brasil, assim como troquei figurinhas sobre os bugs da BeagleBoard com o Luis Barros, conheci um pouco mais sobre a plataforma Tower com vários colegas, vi uma apresentação de uns alunos do Dado, numa EVDK Luminary, de uns jogos desenvolvidos em eLua que poderiam seduzir muitos aficcionados em jogos; entre muitas outras conversas.

Finalizando oficialmente evento, realizamos um sorte de brindes oferecidos por Texas Instruments, Freescale, Atmel/Kobama, Editora Erica, Tempo Real Eventos, Agit Informática e Microgênios, onde as fotos dos ganhadores podem ser vistas aqui.

Mais uma vez, fui um dos primeiros a chegar no local e um dos últimos a sair do happy hour, que aliás, como sempre, foi uma extensão do evento e o início da organização dos próximos eventos.

Namastê!!!

As sombras do Ambiente de Programação C++

2009-11-16T22:17:32+00:00

Estou realmente escrevendo sobre este assunto! É claro que, até reunir material suficiente para um livro maneiro, vai demorar muito tempo. Até lá espero encontrar alguma publicação legal que aceite artigos.

Minha motivação inicial para entender os mistérios do ambiente de programação C++ foi estudar a ABI do C++, que seria necessário implementar no sistema operacional C++.

Existem outros aspectos interessantes desse ambiente, porém, que são pouco focalizados pelas obras educativas sobre a linguagem.

Um deles é o relacionamento entre o mundo restrito da norma ISO C e o mundo maior do sistema. C fala a você sobre unidades de tradução e estabelece regras mínimas sobre como múltiplas unidades de tradução podem compor um programa válido. Ao redor da linguagem, porém, existe o problema de processar cada uma dessas unidades e produzir de fato um negócio único equivalente a este programa. Existirão então diversos blocos intermediários, os "objetos compilados", e existirá um componente ligador. A norma C não descreve este ligador, apenas impõe seus requisitos.

Outro é o modo como os mecanismo de linguagem e do sistema são usados na prática como mecanismos de abstração, e como os projetos de engenharia fazem uso desses mecanismos para lidar com problemas reais de configuração. O ambiente como um todo provê diversas maneiras de abstrair certos trechos de código; desde a seleção de arquivos a compilar, onde um arquivo pode conter a listagem para o sistema A enquanto outro contém a listagem para o sistema B; até a composição de bibliotecas dinâmicas no momento da carga na memória, onde o programa usa a versão A da biblioteca no sistema A, e a versão B da biblioteca no sistema B.

Para lidar com toda essa parafernália sistêmica ao redor do C são imprescindíveis ferramentas que operam fora da linguagem, dirigindo todas as ferramentas de forma conveniente. O projeto de middleware de televisão digital da TQTVD tem, por exemplo, aproximadamente mil unidades de tradução individuais a processar. Certamente o programador não deve chamar as ferramentas uma vez para cada um desses arquivos, sob pena de tornar o dia de trabalho um desperdício de horas absurdo. Existem portanto ferramentas para apoiar essa tarefa que, apesar de não fazer parte da definição da linguagem ou do compilador, são absolutamente imprescindíveis para se trabalhar com ela.

Tudo isso implica que a expertise no desenvolvimento de sistemas em C++ envolve diversas outras habilidades e técnicas individuais, fora aquelas envolvendo a expressão de programas em C++. Essas outras habilidades e técnicas se tornam tão mais importantes quanto o projeto pressione o programador para fora da abstração de um sistema para o mundo concreto das diversas máquinas.

Sob outro ângulo, posso comparar as listas de componentes teórica e prática que compõe o pipeline de transformação de código-fonte. Teoricamente, o pipeline C é: pré-processador, compilador, ligador ou arquivador. Na prática do projeto onde estou envolvido é: configurador de build, ferramenta de build, compilador.

Uma lição que estou tirando de tudo isso é que os melhores pensamentos sobre a linguagem de programação ideal nunca resultariam em um excelente sistema construído se essa linguagem não for implementada em ferramentas adequadas, que suportem um ciclo de desenvolvimento extremamente conveniente. O esquema de compilação separada do C oferece bons mecanismos de abstração, sem dúvida, mas torna o tempo de compilação uma infinitude de "começa e termina" processos.

Em contra-partida, opiniões sobre características de linguagem de programação do tipo "viagem na maionese" ou "impossível" parecem refletir o fato de que, até então, ninguém soube produzir uma ferramenta que a implementasse. O mecanismo de "export" do C++ por exemplo foi considerado um fracasso; agora que as técnicas de LTO e serialização de ASTs de programas estão se tornando mais difundidas, talvez com mais cinco ou dez anos "export" seja trivial.

Go Lang

2009-11-12T22:45:11+00:00

Uma linguagem com as facilidades sintáticas de Python, porém estática e que gere executáveis com opcodes com pouca dependência e desempenho similar aos de C e que desfrute dos recursos computacionais de concorrência que os atuais processadores e computadores oferecem com facilidade é algo que muitos, a muito tempo desejavam. Conheço engenheiros que só tem C e Assembly como opção e que sempre costuma afirmar que “odeiam C”, pelos clássicos problemas da linguagem e compiladores.

Para minha surpresa li este artigo ontem no Slashdot:

Go, Google’s New Open Source Programming Language

E como ele fazia referência a um artigo na ARS Technica, fui conferir a notícia:

Go: new open source programming language from Google

Go, como toda linguagem, nasceu de necessidades, frustrações e certamente surpreenderá, logo criará uma legião de fãs assim como frustrará muitos outros, mas sendo Open Source e com uma licença BSD-Style ela tem potencial de agregar muitos desenvolvedores ao seu core-development. Particularmente eu já instalei, comecei a brincar já me frustrei mas amei as goroutines.

O dilema que está em sua motivação é muito parecido com o que alguns já passaram em certos desenvolvimentos, escolher entre uma linguagem com compilação eficiente, execução performática e facilidade de programação; para oferecer tudo isto nativamente numa única linguagem de programação os autores resolveram partir para seu desenvolvimento.

Para quem dizia que eu era meio maluco por gostar de Haskell, Erlang, C++ e Python e uma linguagem ideal seria a que fosse uma composição de características de todas elas, tive uma fantástica surpresa, além de uma (quase) decepção!

A surpresa fantástica, veio pelo fato que o Google busca com este empreendimento:

- “Uma nova linguagem de programação que busca a performance com concorrência embutida, que é quase comparável a C, mas com a sintaxe mais expressiva e compilação rápida” e além de tudo ela tem pedigree! Pois entre seus projetistas estão Robert Griesemer, Russ Cox, Rob Pike (um dos pais da linguagem Limbo e do Plan9) e Ken Thompson; K, apesar de dispensar apresentações apenas para recordar ele é um dos pais da linguagem B, do UNIX e também trabalhou no projeto do Plan9.

Além da inspiração sintática básica de C ela ”tenta” combinar as facilidades das linguagens dinâmicas (Python e JavaScript), com contribuições de Pascal/Modula/Oberon (quanto a declarações e packages), além de algumas idéias de Erlang, CSP, Newsqueak e Limbo (na concorrência). Porém, é uma nova linguagem!

Da ARS Technica eu fui direto para o site do projeto: golang.org

E encontrei mais algumas definições curiosas:

- “Go” buscou inspirações em todas estas linguagens para criar uma de propósito geral, projetada com “systems programming” em mente, “fortemente tipada” (aqui eles não beberam na fonte de Python) e com uso de garbage-collect (tsc) com suporte nativo a programação concorrente e com gramática compacta e regular, isto tudo soa muito interessante.

Porém, no site do projeto um dos links me chamou muito a atenção:

Go for C++ Programmers

Como o foco dela é “system programming” e por suas características performáticas, de cara já forçar um replace de C++ era esperado. Será este um grande golpe em C++ ou um golpe mortal na linguagem D? Por outro lado lembro-me da afirmação do Herb Sutter que os programadores C++ são os mais abertos a aprenderem novas linguagens, esta afirmação nem sempre me parece verdadeira, mas para os casos onde ela se aplica (que são muitos) o foco do Google parece estar correto.

Agora, veja esta simples comparação sintática:

Go                           C++
var v1 int;               // int v1;
var v2 string;            // const std::string v2;  (approximately)
var v3 [10]int;           // int v3[10];
var v4 []int;             // int* v4;  (approximately)
var v5 struct { f int };  // struct { int f; } v5;
var v6 *int;              // int* v6;  (but no pointer arithmetic)
var v7 map[string]int;    // unordered_map<string, int>* v7;  (approximately)
var v8 func(a int) int;   // int (*v8)(int a);

De cara ela me irrita pois var me lembra Pascal, mas a declaração de struct me pareceu mais elegante e prefiro declarações explícitas de funções, classes e métodos, ponto para Go.

Outro detalhe que me chamou a atenção é que por enquanto há compiladores disponíveis para Linux e Mac OS X que geram opcodes para AMD64 (x86 e 64 bits), x86 de 32 bits e está no forno um compilador ARM! Será que ele permitirá compilação bare-metal para produção de firmware? Tenho suspeita que sim.

Vejam algumas diferenças conceituais entre C++ e Go:

Go não tem classes com construtores ou destrutores. Mas sim métodos de classe, uma hierarquia de herança de classes e funções virtuais, ela fornece interfaces que são utilizadas como os templates de C++; portanto ela oferece programação genérica.
Go usa garbage collection. Não é possível liberar memória explícitamente. Este gerenciamento de memória “pretende” ser incremental e altamente eficiente em processadores modernos.
Go tem ponteiros, mas não a aritmética de ponteiro. Não é possível empregar um ponteiro para percorrer os bytes de uma string.
Arrays são valores de primeira classe. Quando um array é usado como um parâmetro de função, a função recebe uma cópia da matriz, não um ponteiro para ele. No entanto, na prática, muitas funções usam “slices” de parâmetros; “slices” suportam os ponteiros para arrays subjacentes. “Slice” é um recurso importante da linguagem.
Strings são fornecidas pela linguagem. Mas elas não podem ser alteradas depois de sua criação.
Tabelas hash são fornecidas pela linguagem. Eles são chamados de maps. Velhos conhecidos de outra linguagens.
Threads são separadas da execução, e os canais (channels) de comunicação entre eles, são fornecidos pela linguagem.
Certos tipos (maps e channels) são passados por referência, não pelo valor. Ou seja, passar um map para uma função não é copiar o map, e as alterações da função do map são vistas pelo invocador. Como referências de tipos de C++, porém mais similar como é em Python.
Go não usa “header files”. Em vez disso, cada arquivo fonte é parte de um package definido, similar a Python, Oberon e Pascal. Quando um package define um objeto (tipo, constante, variável, função) com um nome começando com uma letra maiúscula, esse objeto é visível a qualquer outro arquivo que importe esse package.
Ela não oferece suporte a conversão implícita de tipo. Operações que misture tipos diferentes requerem casts (que em Go são chamadas de conversions).
Go não suporta sobrecarga de funções e não suporta os operadores definidos pelo usuário.
Go não suporta os qualificadores const ou volatile.
Ela usa nil para ponteiros inválidos e C++ usa NULL ou simplesmente 0.

Sobre as diferenças sintáticas recomendo realmente a leitura da página Go for C++ Programmers, mas antes a leitura dos documentos Tutorial, Effective Go, Language Design FAQ, Language Specification entre outros documentos para o entendimento de alguns conceitos como as fantásticas goroutines. Porém se o tempo permitir, assista a apresentação do Rob Pike no Tech Talk, chamada What is Go?

Confesso que algumas características não me agradaram muito, já outras me pareceram muito interessantes (leia-se channels e goroutines), porém ainda é cedo para apresentar uma avaliação. Entrei na Go Nuts! que é a lista oficial da linguagem e com 2 dias de existência ela já tinha mais de 800 mensagens e 1.200 membros. Será que esta linguagem irá revolucionar? Um ponto positivo é que ela é Open Source porém patrocinada pelo Google, well… tenho minhas suspeitas que sim e em pouco tempo ela irá causar uma reviravolta.

Maiores detalhes acessem o site oficial do projeto: golang.org

PS: Já estou vendo os anúncios de emprego solicitando programadores com 2 a 5 aos de experiência em G0, antes mesmo do lançamento da linguagem completar 1 ano!

bcsanches

2009-11-06T11:48:46+00:00

Hoje foi inaugurado o PontoV, que é o mais novo portal brasileiro sobre desenvolvimento de jogos. O portal surgiu de uma parceria minha com o Vinícius do PontoV (http://vinigodoy.wordpress.com).

O nosso objetivo no portal é compartilhar nossas experiências em gamedev e reunir os desenvolvedores brasileiros.

O nosso foco principal é trazer conteúdo de qualidade sobre GameDesign, Java e C++, além de artigos de profissionais da área.

A principio não sei ao certo qual será o futuro do blog, pois tópicos sobre programação vão acabar sendo destinados ao PontoV, então estou aberto a sugestões .

De qualquer forma nos vemos no PontoV: http://www.pontov.com.br

Java vs. C#, uma perspectiva estranha

2009-11-03T19:55:44+00:00

Você pode achar o que quiser na disputa entre Java e C#, mas onde na documentação da Microsoft você vai encontrar uma afirmação tão direta, sincera e esclarecedora?

"Prior to Java 2 Standard Edition, JDK 1.4, the AWT focus subsystem was inadequate."

http://java.sun.com/javase/6/docs/api/java/awt/doc-files/FocusSpec.html

bug bizarro no RVCT 2.2

2009-10-29T16:13:27+00:00

Descobrimos um bug bizarro no RVCT 2.2 onde a compilação de uma chamada a um operador de conversão do std::auto_ptr gera as seguintes instruções:

1. push into stack from register
2. unconditionally jump to (1)

Alguém já viu isso?

Linus Torvalds apoia o Lançamento do Windows 7

2009-10-23T15:06:42+00:00

Em um conferência de Linux no Japão, a Microsoft coloca (de propósito ou não) um ponto de venda do Windows7 em frente ao local. Nosso amigo Linus Torvalds tira uma onda e vai lá “prestigiar” o lançamento.

Fonte da foto.

techberto

2009-10-18T19:29:24+00:00

É com grande prazer que depois de alguns meses sem postar nada por aqui, venho quebrar o silêncio com uma notícia super interessante.

Depois do sucesso do evento do ano passado, este ano o Portal Embarcados, a Tempo Real Eventos e o grupo C & C++ Brasil realizará a segunda edição do Seminário C & C++ para Sistemas Embarcados.

Com palestrantes de alto-nível e conteúdo super-interessante, como o do ano passado, ele está imperdível!

Ele acontecerá no dia 14 de novembro de 2009, em São Paulo, no Century Hotel, maiores detalhes vejam aqui.

Nos vemos lá.

Nasmastê!

0xc0de

2009-10-17T13:51:25+00:00

Então, quais são as opções para lermos um arquivo inteiro para memória (armazenando-o em uma std::string, por exemplo) em C++? O programa abaixo ilustra algumas alternativas simples.

#include <iostream>
#include <fstream>
#include <sstream>
#include <iterator>
#include <string>

void stringstream_read_file();
void istream_iterator_read_file();
void istreambuf_iterator_read_file();

int main()
{
  //Lê copiando o buffer file stream para o string stream.
  stringstream_read_file();

  //Lê iterando pelo stream e fazendo extração com operator>>.
  istream_iterator_read_file();

  //Lê iterando diretamente pelo buffer e copiando caracteres.
  istreambuf_iterator_read_file();

  return 0;
}

void stringstream_read_file()
{
  std::ifstream fs("file.txt");
  if (!fs.good())
    std::cout << "Error." << std::endl;
  else
  {
    std::ostringstream ss;
    ss << fs.rdbuf();
    std::cout << ss.str() << std::endl;
  }
}

void istream_iterator_read_file()
{
  std::ifstream fs("file.txt");
  if (!fs.good())
    std::cout << "Error." << std::endl;
  else
  {
    fs.unsetf(std::ios_base::skipws); //Para manter os espaços.
    std::string s((std::istream_iterator<char>(fs)), std::istream_iterator<char>());
    std::cout << s << std::endl;
  }
}

void istreambuf_iterator_read_file()
{
  std::ifstream fs("file.txt");
  if (!fs.good())
    std::cout << "Error." << std::endl;
  else
  {
    std::string s((std::istreambuf_iterator<char>(fs)), std::istreambuf_iterator<char>());
    std::cout << s << std::endl;
  }
}

Outras idéias?

Jawbreaker "old school" code (aka Bubble Breaker)

2009-10-10T21:31:28+00:00

I was organizing and archiving the files from my machines, and I found an old sample written as sample to my presentation at Microsoft TechEd Brazil 2005. It was a console (not video game console) version of a popular Pocket PC game, Jawbreaker. Today I'd recompiled the old C++ code on my Vista and OS X machines, let's check the results:

Running on Windows Vista:

Running on Mac OS X:

This Jawbreaker code has a nice recursive code logic, I guess that has a lot of "breakers" source code in the Internet, so I encourage you to compare with my version ;-)

(Normally, when we look back to old code we blame ourselves - specially a 4-5 years old code, obviously I think I can do this code better today. But in average I'm very proud of this old version :-))

#include

<iostream>
#include <iomanip>
#include <vector>
#include <memory>
#include <utility>
#include <map>
#include <cstdlib>
#include <algorithm>

using namespace std;

//http://support.microsoft.com/default.aspx?scid=kb;en-us;231847
float rnd() //Visual Basic as-is
{
static unsigned long rndVal = 0x50000L;
float rndFloat;
rndVal = (rndVal * 0x43fd43fdL + 0xc39ec3L) & 0xffffffL;
rndFloat = (float)rndVal / (float)16777216.0;
return rndFloat;
}

int absolute( int value )
{
return value < 1 ? -value : value;
}

class CBoard;

class CCell
{
pair< int, int > Coordinate_; //first == row, second == column
int Value_;

void Initialize( int row, int col, int value )
{
    Coordinate_.first = row;
    Coordinate_.second = col;
    Value_ = value;
}

friend class CBoard;

void set_Value( int value ){ Value_ = value; }

public:
CCell( int row, int col, int value ) : Coordinate_( row, col ), Value_( value ){}
CCell( const CCell& ref ) : Coordinate_( ref.Coordinate_ ) , Value_( ref.Value_ ){}
const int get_Row() const { return Coordinate_.first; }
const int get_Column() const { return Coordinate_.second; }
const int get_Value() const { return Value_; }
};

class Finder;

class CBoard
{
pair< int, int > Boundaries_; //first == rows, second == cols
auto_ptr< vector<CCell> > Cells_;
pair< int, int > LeftTopMost_; //first == top most, second == left most
auto_ptr< vector<CCell> > SavedCells_;
pair< int, int > SavedLeftTopMost_; //first == top most, second == left most

friend class Finder;

public:
    int get_Value( int row, int col )
    {
      if( row > get_Rows() || col > get_Columns() )
        return NULL;
      return (*Cells_)[ translate_Coordinate( row, col ) ].get_Value();
    }

    int get_Left(){ return LeftTopMost_.second; }

    int get_Top(){ return LeftTopMost_.first; }

    int get_Columns(){ return Boundaries_.second; }

    int get_Rows(){ return Boundaries_.first; }

    void display()
    {
      cout << "\n";
      cout << setw(4) << " ";
      for( int col = 1; col <= get_Columns(); ++col )
        cout << setw(3) << "[" << col << "]";
      cout << endl;

      for( int row = 1; row <= get_Rows(); ++ row )
      {
        cout << "[" << row << "]" << (row < 10 ? " " : "");
        for( int col = 1; col <= get_Columns(); ++col )
        {
          int v = (*Cells_)[ translate_Coordinate( row, col ) ].get_Value();
          if( v > 0 )
            cout << setw(4) << v << " ";
          else
            cout << " ";
        }

        cout << "\n";
      }

      cout << "\n";
    }

private:
    void moveColumnsToRight( int col )
    {
      for( int r = get_Top(); r <= get_Rows(); ++r )
      {
        set_Value( r, col, col > 1 ? get_Value( r, col - 1 ) : NULL );
      }
      if( col > 1 ) moveColumnsToRight( col - 1 );
    }

    void remove_Item( int row, int col )
    {
      if( row == 1 )
      {
        set_Value( 1, col, NULL );
        return;
      }

      if( get_Value( row - 1, col ) != NULL )
      {
        set_Value( row, col, get_Value( row - 1, col ) );
        remove_Item( row - 1, col );
      }
      else
      {
        set_Value( row, col, NULL );
        if( row == get_Rows() )
          moveColumnsToRight( col );
      }
    }

    void save()
    {
      for( int row = get_Top(); row <= get_Rows(); ++row )
        for( int col = get_Left(); col <= get_Columns(); ++col )
        {
          CCell& cell_ref = (*Cells_)[ translate_Coordinate( row, col ) ];
          (*SavedCells_)[ translate_Coordinate( row, col ) ].Initialize( cell_ref.get_Row(), cell_ref.get_Column(), absolute( cell_ref.get_Value() ) );
        }

      SavedLeftTopMost_.first = LeftTopMost_.first;
      SavedLeftTopMost_.second = LeftTopMost_.second;
    }

    void recover()
    {
      int top = SavedLeftTopMost_.first,
      left = SavedLeftTopMost_.second;
      for( int row = top; row <= get_Rows(); ++row )
      for( int col = left; col <= get_Columns(); ++col )
      {
        CCell& savedcell_ref = (*SavedCells_)[ translate_Coordinate( row, col ) ];
        (*Cells_)[ translate_Coordinate( row, col ) ].Initialize( savedcell_ref.get_Row(), savedcell_ref.get_Column(), savedcell_ref.get_Value() );
      }

      LeftTopMost_.first = top;
      LeftTopMost_.second = left;
    }

    void set_Value( int row, int col, int value )
    {
        (*Cells_)[ translate_Coordinate( row, col ) ].set_Value( value );
    }

    void check_ChangeLeftTopMost()
    {
      for( int r = get_Top(); r <= get_Rows(); ++r )
      {
        bool is_row_filled = false;
        for( int c = get_Left(); c <= get_Columns(); ++c )
        {
          if( get_Value( r, c ) != NULL )
          {
            is_row_filled = true;
            break;
          }
        }

if( !is_row_filled ) set_Top( get_Top() + 1 ); else break;

      }

      for( int c = get_Left(); c <= get_Columns(); ++c )
      {
        bool is_col_filled = get_Value( get_Rows(), c ) != NULL;
        if( !is_col_filled ) set_Left( get_Left() + 1 ); else break;
      }
    }

    void set_Left( int left ){ LeftTopMost_.second = left; }

    void set_Top( int top ){ LeftTopMost_.first = top; }

    int get_RandomValue( int min, int max )
    {
      return static_cast<int>( (max - min + 1) * rnd() + min );
    }

    int translate_Coordinate( int row, int col )
    {
      return (row - 1) * get_Columns() + (col - 1);
    }

private:
    static const int DEFAULT_NUMBEROF_ROWS = 16;
    static const int DEFAULT_NUMBEROF_COLS = 8;
    static const int DEFAULT_NUMBEROF_PIECES = 3;

public:
    CBoard( int rows = DEFAULT_NUMBEROF_ROWS, int cols = DEFAULT_NUMBEROF_COLS, int max_number_of_pieces = DEFAULT_NUMBEROF_PIECES ) :
      Boundaries_( rows > 0 ? rows : DEFAULT_NUMBEROF_ROWS , cols > 0 ? cols : DEFAULT_NUMBEROF_COLS ),
      LeftTopMost_( 1, 1 ),
      Cells_( auto_ptr< vector<CCell> >( new vector< CCell >( Boundaries_.first * Boundaries_.second, CCell( 0, 0, 0 ) ) ) ),
      SavedLeftTopMost_( 1, 1 ),
      SavedCells_( auto_ptr< vector<CCell> >( new vector< CCell >( Boundaries_.first * Boundaries_.second, CCell( 0, 0, 0 ) ) ) )
    {
      int max_number_of_pieces_ = max_number_of_pieces > 0 ? max_number_of_pieces : DEFAULT_NUMBEROF_PIECES;
      for( int row = get_Top(); row <= get_Rows(); ++row )
        for( int col = get_Left(); col <= get_Columns(); ++col )
          (*Cells_)[ translate_Coordinate( row, col ) ].Initialize( row, col, get_RandomValue( 1, max_number_of_pieces_ ) );
    }
};

class FinderResult
{
friend class Finder;

Finder& Finder_;
int Count_;
int Current_Row_, Current_Col_;

public:
    FinderResult( const FinderResult& fr ) :
      Finder_( fr.Finder_ ),
      Count_( fr.Count_ ),
      Current_Row_( fr.Current_Row_ ),
      Current_Col_( fr.Current_Col_ )
      {
      }

private:
    FinderResult( Finder& finder ) :
      Finder_( finder ),
      Count_( 0 ),
      Current_Row_( 0 ),
      Current_Col_( 0 )
    {
    }

    void set_data( int row, int col, int count )
    {
      Count_ = count;
      Current_Row_ = row;
      Current_Col_ = col;
    }

public:
    void confirm();
    void cancel();
    const int get_Count() const;
    bool can_Continue() const;
};

class Finder
{
CBoard& Board_;
FinderResult* FinderResult_;
bool CanUndo_;
vector< pair<int, int > > Path_; //first = row, second = col;

friend class FinderResult;

public:
    Finder( CBoard& board ) : Board_( board ), CanUndo_( false )
    {
      FinderResult_ = new FinderResult( *this );
    }

    ~Finder()
    {
      delete FinderResult_;
    }

    FinderResult& find( int row, int col )
    {
      Path_.clear();
      int ref_value = Board_.get_Value( row, col );
      InternalFind( row, col, ref_value );
      CanUndo_ = false;
      FinderResult_->set_data( row, col, static_cast<int>( Path_.size() ) );
      if( Path_.size() > 1 )
        Board_.save();
      return *FinderResult_;
    }

    bool undo()
    {
      if( CanUndo_ )
      {
        Board_.recover();
        CanUndo_ = false;
        return true;
      }
      return false;
    }

    const vector< pair< int, int > >& get_Path() const{ return Path_; }

private:
    bool has_PossibleCombinations()
    {
      for( int row = Board_.get_Top(); row <= Board_.get_Rows(); ++row )
        for( int col = Board_.get_Left(); col <= Board_.get_Columns(); ++col )
        {
          Path_.clear();
          InternalFind( row, col, Board_.get_Value( row, col ) );
          if( Path_.size() > 0 )
          {
            InternalCancel();
            return true;
          }
      }
      return false;
    }

    void InternalCancel()
    {
      for( vector< pair<int, int> >::const_iterator iter = Path_.begin(); iter != Path_.end(); ++iter )
      {
        int row = iter->first, col = iter->second, value = Board_.get_Value( row, col );
        Board_.set_Value( row, col, value * -1 );
      }
    }

    bool is_match( int row, int col, int ref_value )
    {
      return Board_.get_Value( row, col ) == ref_value;
    }

    void save( int row, int col, int ref_value )
    {
      Path_.push_back( pair<int, int>( row, col ) );
      Board_.set_Value( row, col, ref_value * -1 );
    }

    void refresh_board( int row, int col )
    {
      int ref_value = Board_.get_Value( row, col );
      if( ref_value < 0 )
      {
        for( int r = Board_.get_Top(); r <= Board_.get_Rows(); ++r )
          for( int c = Board_.get_Left(); c <= Board_.get_Columns(); ++c )
          {
            if( Board_.get_Value( r, c ) == ref_value )   Board_.remove_Item( r, c );
          }
        }
        Board_.check_ChangeLeftTopMost();
      }
    }

private:
    void InternalFind( int row, int col, int ref_value )
    {
      if( ref_value == NULL || Board_.get_Value( row, col ) == NULL ) return;

      Up( row, col, ref_value );
      Down( row, col, ref_value );
      Left( row, col, ref_value );
      Right( row, col, ref_value );
    }

    void Right( int row, int col, int ref_value )
    {
      int ref_col = col + 1;
      if( ref_col > Board_.get_Columns() ) return;
      if( is_match( row, ref_col, ref_value ) )
      {
        save( row, ref_col, ref_value );
        InternalFind( row, ref_col, ref_value );
      }
    }

    void Left( int row, int col, int ref_value )
    {
      int ref_col = col - 1;
      if( ref_col < 1 ) return;
      if( is_match( row, ref_col, ref_value ) )
      {
        save( row, ref_col, ref_value );
        InternalFind( row, ref_col, ref_value );
      }
    }

    void Down( int row, int col, int ref_value )
    {
      int ref_row = row + 1;
      if( ref_row > Board_.get_Rows() ) return;
      if( is_match( ref_row, col, ref_value ) )
      {
        save( ref_row, col, ref_value );
        InternalFind( ref_row, col, ref_value );
      }
    }

    void Up( int row, int col, int ref_value )
    {
      int ref_row = row - 1;
      if( ref_row < 1 ) return;
      if( is_match( ref_row, col, ref_value ) )
      {
        save( ref_row, col, ref_value );
        InternalFind( ref_row, col, ref_value );
      }
    }
};

void FinderResult::confirm()
{
Finder_.refresh_board( Current_Row_, Current_Col_ );
Finder_.CanUndo_ = true;
}

void FinderResult::cancel()
{
Finder_.InternalCancel();
}

const int FinderResult::get_Count() const
{
return Count_;
}

bool FinderResult::can_Continue() const
{
return Finder_.has_PossibleCombinations();
}

Below, to reference, the original PocketPC interface of Jawbreaker by Microsoft:

The windows source code has been released!

2009-10-06T12:35:46+00:00

Ops! praticamente três meses sem postar nenhuma novidade. Porém não tinha como deixar passar em branco este post… está semana estarei de volta as atividades e compartilhando as novidades!

Perceba que o código e bem tosco, porém divertido! o uso do return com o método void main() foi forçar a barra!