G-Portugol (.gpt) no auto-judge: três bloqueios medidos, e a decisão que falta

Separado da #269, cuja parte A (Portugol Studio) entrou no PR que acompanha esta issue. A issue original previa que as duas partes pudessem ir separadas "se a Parte B travar no Alpine", e mandava decidir com o resultado da tentativa, não antes. O resultado chegou.

As três tentativas

1. Construir no Alpine — para no ANTLR

O configure exige ANTLR mesmo com o parser já gerado no repositório (src/modules/parser/BasePortugolParser.cpp está commitado).

Instalar a ferramenta Java não basta:

$ runantlr            # java -cp antlr-2.7.7.jar antlr.Tool
ANTLR Parser Generator   Version 2.7.7 (20060906)

$ ./configure
checking for runantlr... /usr/local/bin/runantlr
checking for antlr-config... no
configure: error: O programa "antlr-config" nao foi encontrado

antlr-config vem do runtime C++ do ANTLR 2.7 (libantlr-dev), que o Alpine não empacota. Construí-lo seria um terceiro build aninhado, de código de 2006, sobre musl.

2. Construir no Debian — passa do configure, morre no make

Debian tem libantlr-dev e antlr. Com libpcre2-dev (o release novo pede PCRE2, não o PCRE legado que o INSTALL menciona):

configure OK
make FALHOU:
error: Token stream error reading grammar(s)

O ANTLR 2.7.7 falha ao ler a gramática do projeto. Não investiguei a fundo, mas a issue original já anotava o risco de codificação: as palavras-chave são acentuadas, e o ANTLR 2.7 é de antes do UTF-8 ser padrão.

3. O binário oficial — só x86_64

O release 1.2.0 (jan/2026, o upstream está vivo) publica:

gpt-linux-x86_64.tar.gz
gpt-win-x86_64.zip
manual.pdf

Não há build arm64. Um parque com judgehost arm64 — que a #53 existe para permitir, inclusive máquinas emprestadas por instituição parceira — não julgaria Portugol.

O que ainda vale a pena registrar

O lado bom, que continua verdadeiro e é o motivo de esta issue existir em vez de a parte ser abandonada:

o código de saída está certo (src/main.cpp:271: return success ? EXIT_SUCCESS : EXIT_FAILURE), então o CE sairia de graça, sem o contorno que o Portugol Studio precisou;
gpt -t traduz para C, e o gcc já está na imagem — isso evitaria o backend x86 do próprio gpt e daria executável nativo, sem partida de VM;
o upstream está ativo, ao contrário do Portugol Studio.

O que decidir

Estágio Docker baseado em Debian, construindo o gpt lá e copiando o binário — mas o build no Debian falha no make, então isto depende de resolver a gramática primeiro.
Usar o binário oficial x86_64, aceitando que judgehost arm64 não anuncia a capacidade gportugol. O roteamento por capacidade já lida com isso sozinho (MachineCapabilities sonda command -v gpt) — mas uma prova onde todo judgehost é arm64 aceitaria o envio e o deixaria sem máquina que o julgue, e isso precisaria de aviso na tela de linguagens.
Reportar a falha de build ao upstream e esperar. Ele está vivo, e Token stream error numa gramática própria é o tipo de coisa que o autor resolve rápido.
Não fazer. O Portugol Studio é o dialeto que se ensina (+200 mil usuários); o G-Portugol tem adoção bem menor.

Como reproduzir as medições

# Alpine
docker run --rm alpine:3.24 sh -c 'apk add --no-cache git build-base autoconf automake \
  libtool pcre-dev nasm bison flex && git clone --depth 1 https://github.com/gportugol/gpt.git /src \
  && cd /src && autoreconf -fi && ./configure'

# Debian
docker run --rm debian:bookworm sh -c 'apt-get update -qq && apt-get install -y -qq git \
  build-essential autoconf automake libtool libpcre2-dev nasm bison flex libantlr-dev antlr \
  && git clone --depth 1 https://github.com/gportugol/gpt.git /src && cd /src \
  && autoreconf -fi && ./configure && make'

Relacionado: #269 (parte A, feita), #53 (judgehost heterogêneo).

Portugol Studio como linguagem do auto-judge (issue #269, parte A) (#297

Reportado ao upstream, com as medições refeitas

Comentei nas três issues do gportugol/gpt que já existiam e cobrem cada bloqueio — não abri nenhuma nova, porque o terreno já estava mapeado por lá:

Nossa constatação	Onde foi	O que eu disse
build quebrado com ANTLR 2.7	gpt#1 — Migrar para o ANTLR4	o erro, o que não é a causa, e a sugestão do `configure`
só binário x86_64 na release	gpt#10 — Publicar `make dist` como artefato	por que trava um juiz, e `runs-on: ubuntu-24.04-arm` como saída barata
backend x86 amarra a arquitetura	gpt#5 — Avaliar remoção do NASM	voto na alternativa 3 (C + GCC), com a ressalva de manter o `-o`

Uma correção do que eu havia escrito aqui

O corpo desta issue dizia que o make morre em Token stream error e insinuava que a codificação das gramáticas era a causa provável — as palavras-chave do Portugol são acentuadas, e o ANTLR 2.7 é de 2006.

Está errado, e eu verifiquei. Rodei o ANTLR 2.7.7 do Maven Central diretamente sobre as seis gramáticas do projeto:

lexer.g -> ok    parser.g -> ok    semantic.g -> ok
pt2c.g  -> ok    interpreter.g -> ok    x86.g -> ok

E o lexer.g passa sob file.encoding UTF-8, ISO-8859-1 e o padrão do ambiente. Também comparei os bytes antes e depois do commit 11f98d9 (Add pre-commit hooks), achando que ele tivesse convertido a codificação: já era UTF-8 nos dois lados.

Então o bloqueio não é gramática nem encoding — é como o build invoca o ANTLR no Debian (o runantlr empacotado, ou os argumentos do Makefile.am). Não isolei qual dos dois.

Um achado novo, e o mais acionável dos três

src/modules/parser/BasePortugolParser.cpp está commitado no repositório — o parser gerado já vem pronto. Mas o configure aborta pedindo ANTLR mesmo assim:

checking for antlr-config... no
configure: error: O programa "antlr-config" nao foi encontrado

Se o configure aceitasse os fontes gerados quando presentes, exigindo ANTLR só para regenerar, o gpt compilaria em qualquer sistema com um compilador C++ — hoje, sem depender da migração para o ANTLR4 nem da disponibilidade do ANTLR 2.7.

Isso muda a ordem das nossas opções: deixa de ser "esperar o upstream migrar para ANTLR4" e passa a ser "um ajuste de configure.ac", que é o tipo de coisa que rende PR pequeno.

E o Alpine confirmado com controle positivo

$ apk search antlr
(nada)

$ apk search pcre          # controle: o comando funciona
libpcre16-8.45-r4
libpcre2-16-10.48-r0

Zero pacotes ANTLR em 28.542. Não é "está num repositório menos usado" — não existe.

G-Portugol entra no auto-judge pelos tres bloqueios que a #296 dava c…

O veredito do job do juiz foi lido: verde

O PR #371 foi mergeado (262b03f). Ele dizia, com todas as letras, que a afirmação central dependia de uma medição que não era dele:

NÃO VERIFICADO: nenhuma imagem foi construída nesta máquina. Que o estágio do ANTLR e o do gpt terminem, e que a linguagem realmente julgue, é o que o job do juiz mede — e ele constrói as imagens do zero.

Medido agora, no commit que foi mergeado (b68e802):

Judging (all languages, inside the sandbox)   pass
Julgamento pela fila (imagem da aplicação)    pass
OK (2787 tests, 12582 assertions)

Ou seja: os três estágios de construção terminam — o runtime C++ do ANTLR 2.7 do fonte, o gpt, e a cópia do invocador nas três imagens — e a suíte completa passa dentro da imagem.

Duas razões pelas quais esse verde é afirmação sobre o G-Portugol, e não silêncio sobre ele:

o job roda com --fail-on-skipped. A entrada gportugol tem promessa de versão em ToolchainVersionsMatchCatalogTest (/usr/local/bin/gpt -v) e linhas próprias em LanguageConformanceTest. Se o gpt não existisse na imagem, esses casos pulariam — e pular é falhar neste job. Não existe o resultado "passou porque não rodou";
o Julgamento pela fila (imagem da aplicação) também passou, o que exercita a paridade entre a imagem do juiz e a da aplicação — a mutação que o G-Portugol entra no auto-judge pelos três bloqueios que a #296 dava como fechados (#296) #371 já tinha feito à mão.

O que ainda segura esta issue

Só o que sempre foi decisão humana: oferecer ou não a linguagem numa prova. O corpo do #371 é explícito em não decidir isso no lugar de quem mantém.

Além disso, o valor da linguagem rio abaixo continua dependendo do upstream — ver #309. A novidade de hoje lá é que marcelometal deixou a primeira review em PR nosso desde janeiro, e que o branch antlr4 dele (PR gportugol/gpt#13) foi construído por mim numa terceira plataforma (macOS arm64, runtime ANTLR4 4.13.2) com gpt -t dando saída idêntica à gravada — que é justamente o caminho que este auto-judge usa.

Revisão de 23/09/2026: o escopo técnico desta issue está cumprido — dá para fechar

Conferido no master de hoje (8e96864), e não pelo último comentário:

a entrada está ligada no catálogo: ['name' => 'G-Portugol (1.2)', 'extension' => 'gportugol', ..., 'is_active' => true] (app/Models/Language.php:305);
a promessa de versão existe (ToolchainVersions: /usr/local/bin/gpt -v), e a linguagem tem família própria, fixture e casos no LanguageConformanceTest;
o job do juiz passou com --fail-on-skipped no commit do G-Portugol entra no auto-judge pelos três bloqueios que a #296 dava como fechados (#296) #371, o que exclui "passou porque não rodou".

O último comentário dizia que o que segurava a issue era a decisão humana de oferecer ou não a linguagem numa prova. Essa decisão já foi tomada no próprio código: is_active => true é oferecer. E oferecer por prova continua sendo escolha do admin, porque languages tem contest_id e is_active por contest.

O que resta do G-Portugol é upstream (gportugol/gpt: os nossos PRs, as issues de segurança, a migração para ANTLR4), e isso já tem casa na #309, que é onde dependência de terceiro é acompanhada.

Recomendação: fechar esta issue, com a #309 como referência para o que é de terceiro. Não abri PR porque não há código faltando.

Navigation Menu

Repository navigation

G-Portugol (.gpt) no auto-judge: três bloqueios medidos, e a decisão que falta #296

As três tentativas

1. Construir no Alpine — para no ANTLR

2. Construir no Debian — passa do configure, morre no make

3. O binário oficial — só x86_64

O que ainda vale a pena registrar

O que decidir

Como reproduzir as medições

Reportado ao upstream, com as medições refeitas

Uma correção do que eu havia escrito aqui

Um achado novo, e o mais acionável dos três

E o Alpine confirmado com controle positivo

O veredito do job do juiz foi lido: verde

O que ainda segura esta issue

Revisão de 23/09/2026: o escopo técnico desta issue está cumprido — dá para fechar

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

G-Portugol (.gpt) no auto-judge: três bloqueios medidos, e a decisão que falta #296

Description

As três tentativas

1. Construir no Alpine — para no ANTLR

2. Construir no Debian — passa do configure, morre no make

3. O binário oficial — só x86_64

O que ainda vale a pena registrar

O que decidir

Como reproduzir as medições

Activity

matbrgz commented on Sep 18, 2026

Reportado ao upstream, com as medições refeitas

Uma correção do que eu havia escrito aqui

Um achado novo, e o mais acionável dos três

E o Alpine confirmado com controle positivo

matbrgz commented on Sep 22, 2026

O veredito do job do juiz foi lido: verde

O que ainda segura esta issue

matbrgz commented on Sep 23, 2026

Revisão de 23/09/2026: o escopo técnico desta issue está cumprido — dá para fechar

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions