| AVISOS - Avaliação em Época Normal
|
|
Esclarecimento de dúvidas:
- Consultar sempre o corpo docente atempadamente: presencialmente ou através do endereço oficial da disciplina [1].
- Não utilizar fontes de informação não oficialmente associadas ao corpo docente (podem colocar em causa a aprovação à disciplina).
- Não são aceites justificações para violações destes conselhos: quaisquer consequências nefastas são da responsabilidade do aluno.
|
|
Requisitos para desenvolvimento, material de apoio e actualizações do enunciado (ver informação completa em Projecto de Compiladores):
- O material de apoio é de uso obrigatório e não pode ser alterado.
- Verificar atempadamente (mínimo de 48 horas antes do final de cada prazo) os requisitos exigidos pelo processo de desenvolvimento.
|
|
Processo de avaliação (ver informação completa em Avaliação do Projecto):
- Datas: 2015/03/25 12:00 (inicial); 2015/04/14 12:00 (intercalar); 2015/05/20 12:00 (final); 2015/05/20-2015/05/27 (teste prático).
- A entrega inicial, sendo crucial para o projecto, é obrigatória e sua não realização implica a exclusão da avaliação do projecto e, por consequência, da avaliação da disciplina.
- Verificar atempadamente (até 48 horas antes do final de cada prazo) os requisitos exigidos pelo processo de avaliação, incluindo a capacidade de acesso ao repositório CVS.
- Apenas se consideram para avaliação os projectos existentes no repositório CVS oficial.
- Trabalhos não presentes no repositório no final do prazo têm classificação 0 (zero) (não são aceites outras formas de entrega). Não são admitidas justificações para atrasos em sincronizações do repositório. A indisponibilidade temporária do repositório, desde que inferior a 24 horas, não justifica atrasos na submissão de um trabalho.
- A avaliação do projecto pressupõe o compromisso de honra de que o trabalho correspondente foi realizado pelos alunos correspondentes ao grupo de avaliação.
- Fraudes na execução do projecto terão como resultado a exclusão dos alunos implicados do processo de avaliação em curso.
|
| Material de Uso Obrigatório
|
| As bibliotecas CDK e RTS de apoio ao desenvolvimento do projecto são de uso obrigatório:
|
|
|
| A máquina virtual, fornecida para desenvolvimento do projecto, já contém todo o material de apoio.
|
| Uso Obrigatório: Repositório CVS
|
| Apenas se consideram para avaliação os projectos existentes no repositório CVS oficial.
Trabalhos não presentes no repositório no final do prazo têm classificação 0 (zero) (não são aceites outras formas de entrega). Não são admitidas justificações para atrasos em sincronizações do repositório. A indisponibilidade temporária do repositório, desde que inferior a 24 horas, não justifica atrasos na submissão de um trabalho.
|
Prazo de Revisão
A entrega intermédia pode ser revista até à data da entrega final do projecto.
Critérios de Avaliação
LER COM ATENÇÃO
A avaliação da entrega intermédia considera a execução de intervenções em várias regiões do código do compilador em desenvolvimento, assim como a gestão do projecto correspondente.
A avaliação é realizada sobre a versão existente no CVS no final do prazo para a entrega intermédia. Projectos que não apresentem alterações relativamente ao conteúdo inicial do repositório CVS ou relativamente à entrega inicial não serão considerados.
Advertem-se os alunos sobre a consulta de colegas de anos anteriores. Estas consultas podem ser positivas, mas comportam algum risco, pois o processo e critérios de avaliação podem ter mudado. Além disso, a proficiência do colega pode majorar negativamente o resultado da avaliação em curso. Não são admitidas quaisquer justificações com base na história da disciplina.
Estas condições são aplicáveis à data da entrega intermédia.
Em caso de dúvidas suscitadas por qualquer elemento neste texto, no projecto, ou na disciplina em geral, os alunos são fortemente encorajados a consultar o corpo docente.
| VALORAÇÕES
|
|
Existem 6 valores (dos 20 disponíveis para o projecto) associados a esta entrega:
- gestão do projecto: 1 valor
- projecto com a estrutura correcta no repositório CVS: 0.5 valores (i.e., código que não apresente a estrutura canónica de um compilador desenvolvido com a CDK é considerado sem a estrutura correcta -- consultar estas páginas sobre o desenvolvimento do projecto com base no repositório CVS)
- projecto compila e produz compilador "pwn" ("pwn", com letras minúsculas: variações correspondem a "não compilação"): 0.5 valores
Se o projecto compilar, poderão ser atribuídos mais 5 valores (desenvolvimento do compilador), distribuídos como se segue:
- Flex (completo): 1.5 valores
- Tokens correspondentes aos símbolos e palavras chave (simples ajuste do Simple)
- Identificadores (simples ajuste do Simple)
- Inteiros (deve estar implementada a base 16 -- a base 10 já está implementada no Simple)
- Reais (extensão dos inteiros)
- Strings (extensão do Simple)
- O Flex deve retornar os tokens ao byacc (sobre DEBUG, ver abaixo) -- o não retorno de tokens penaliza fortemente toda a componente Flex (ver penalizações)
- BYACC (completo): 1 valor
- Regras correspondentes a literais de reais e strings (simples extensão do Simple)
- Regras correspondentes a ciclos, etc. (simples extensão e adaptação do Simple)
- Regras correspondentes a declarações de variáveis
- Regras correspondentes a declarações/definições de funções
- As acções correspondentes às regras definidas no BYACC devem estar implementadas (simples criação de nós) -- a não implementação corresponde a penalizações (var abaixo)
- Nós (nodes) (completo): 1 valor
- Todos os nós necessários para a linguagem (utilizados na especificação BYACC e em passos subsequentes) devem ser criados
- A não criação de nós motivada pela ausência de definição de acções no BYACC é penalizada (ver abaixo)
- Sugere-se (por simplicidade de gestão do código) a separação das várias classes de nós em namespaces coerentes (à la Compact; este aspecto, no entanto, não é avaliado)
- Semântica (visitors) (xml_writer completo; postfix_writer ver a seguir): 1.5 valores
- O "visitor" xml_writer deve estar completamente implementado (ver também DEBUG abaixo)
- O "visitor" type_checker deve ter todos os métodos (correspondentes aos nós, tal como o xml_writer), embora alguns possam estar ainda vazios (i.e., podem não executar qualquer acção)
- O "visitor" postfix_writer deve ter todos os métodos (correspondentes aos nós, tal como o xml_writer), embora alguns possam estar ainda vazios (i.e., podem não executar qualquer acção)
- Métodos correspondentes a acções semelhantes às existentes devem ser modelados nos existentes (exemplo, do_while_node -> do_repeat_node) (mesmo que não modificados numa primeira instância)
- A presença de implementações de semântica no postfix_writer (tabela de símbolos, validação de tipos, etc.) não é penalizada, mas não será avaliada nesta entrega
|
| PENALIZAÇÕES
|
|
Existem penalizações relativas à (deficiente) execução do projecto.
São considerados os seguintes aspectos preliminares:
- A linguagem do projecto contém a linguagem Simple, pelo que não há razão para não utilizar completamente o compilador Simple, eventualmente com pequenas alterações.
- A semântica da linguagem do projecto contém a da linguagem Simple, pelo que a implementação de alguns aspectos da linguagem do projecto não requer qualquer reimplementação relativamente ao Simple.
- O compilador Simple foi fornecido completamente funcional, assim como a versão inicial do compilador do projecto no respositório CVS (igual ao Simple e apenas alterado para ter o nome apropriado).
- A criação de novos nós não apresenta quaisquer dificuldades (são classes muito simples)
- O código dos métodos do visitor xml_writer corresponde a uma simples impressão dos atributos dos nós, através de uma travessia da árvore que formam e que os contém.
- O compilador é obrigatoriamente desenvolvido em C++.
Considerando os aspectos 1. a 6., são aplicadas as seguintes penalizações:
- Destruição de funcionalidade do compilador Simple sem substituição por funcionalidade equivalente do compilador do projecto: 4 valores
Não definição dos nós para regras BYACC em avaliação (ver acima) ou não utilização de nós definidos para a escrita dessas acções: 2 valores
- A utilização de funções e estruturas C, quando existem alternativas directas C++ (malloc em lugar de new, por exemplo; strcmp, etc. em lugar da classe std::string; e outras) terá uma penalização máxima de 1 valor
- Não utilização de qualquer material obrigatório: 6 valores (e considera-se projecto não realizado)
|
DEBUG
O despiste de problemas em especificações Flex pode ser realizado de forma simples utilizando os métodos descritos em How to Debug a Flex Specification.
O visitor xml_writer foi concebido para produzir uma representação textual hierárquica (árvore XML) correspondente ao programa em compilação.
É muito útil para inspeccionar a contrução da árvore de nós por parte do BYACC, permitindo, inclusivamente, a apresentação gráfica.
Legenda
A entrega intermédia vale 6 valores em 20.
Resultados de compilação: http://goo.gl/P20ilX
Os alunos são fortemente encorajados a compreender/verificar/corrigir os problemas reportados. Alunos cujo projecto não compile (e apenas esses), podem solicitar correcção de versão nova a partir do CVS (desconto aplicável). Não se considerarão outras alterações na avaliação intermédia.
Quaisquer dúvidas ou sugestões, relativas a esta informação, devem ser enviadas ao responsável pela disciplina.
As questões relativas às colunas "Problemas" devem ser resolvidas quanto antes (nos horários de dúvidas ou, sendo possível, por correio electrónico).
Pauta
<runphp>
echo<<<___EOT___
</tbody>
___EOT___;
</runphp>