L’ANALISI
llama.cpp b12039: map e filtri nei template Jinja
llama.cpp integra map('filter') nei template Jinja: il tag b12039 identifica il codice. Limiti, test upstream e checklist per una prova controllata.
In breve: llama.cpp ora implementa map('filter') nel runtime Jinja; il codice è identificato dal tag b12039 e dal merge 59695669f1924c81f421f2044c690ed6373bec79. Serve a interpretare più template, non certifica il tool calling di un modello. La disponibilità di binari per quel tag non è verificata.
Analisi del repository: sono stati letti PR, diff, tag e metadati CI ufficiali. Non sono stati compilati i sorgenti né eseguiti modelli. La checklist è una proposta di verifica, non il resoconto di un test end-to-end. Fonti ricontrollate il 2 novembre 2026.
Che cosa cambia davvero nei template?
La PR implementa il mapping di un filtro sui singoli elementi di una sequenza, riutilizzando il percorso di esecuzione dei filtri ordinari. Il diff distingue questa chiamata dalla variante che estrae un attributo: non basta quindi dire che map fosse completamente assente prima. La novità utile è la forma map('filter'), con argomenti inoltrati al filtro. Per chi integra modelli, la conseguenza da verificare è se un template prima non interpretabile viene ora elaborato senza modificarlo. Diff e casi di test Jinja della PR 24033.
Il tag b12039 è una release con binari?
Il tag punta al commit del merge, completato il 2 novembre alle 11:45 ora italiana. Questo consente di fissare i sorgenti della prova. Non basta però una pagina raggiungibile nella sezione releases: durante la verifica l'API della release b12039 risponde 404 e la pagina espone archivi sorgente. Per questo non vengono promessi installer o eseguibili pronti. Il tag è la revisione analizzata, non l'affermazione che sia l'ultima disponibile; un'eventuale pubblicazione successiva dei binari va ricontrollata separatamente. Sorgenti llama.cpp al tag b12039.
Quali test sono documentati e quali mancano?
Il diff aggiunge casi in tests/test-jinja.cpp per filtri, concatenazione con attribute, argomenti e keyword non supportate. I metadati upstream restituiscono quindici check riusciti sullo head della PR. Questi sono controlli del progetto, non esecuzioni svolte qui, e non è stato letto un log specifico di test-jinja. Per evitare un salto logico, bisogna separare tre esiti: il template viene interpretato, il prompt risultante è quello atteso e il modello produce una chiamata tool valida. Il primo non dimostra gli altri due. Diff e casi di test Jinja della PR 24033.
Gemma4 e gli agenti funzionano tutti dopo il merge?
L'autore cita gli schemi tool di Gemma4 come motivazione della PR. Non è una certificazione di tutti i modelli, quantizzazioni o harness. La stessa descrizione precisa che sum sugli array resta non supportato e viene lasciato fuori dallo scopo. Se un template utilizza un altro filtro mancante, il nuovo mapping non elimina quel limite. L'intervento pratico va quindi guidato dal messaggio di errore e dal template effettivo, non dall'idea che un singolo merge renda completo il runtime Jinja. PR ufficiale 24033: scopo, merge e limiti.
Come impostare una prova senza alterare l'ambiente?
Preparare un ambiente di confronto separato e conservare la revisione in uso. Fissare commit, modello, quantizzazione e contenuto esatto del template; salvare anche un input privo di dati personali e lo schema di un tool innocuo. Confrontare prima la sola elaborazione del template, poi il prompt serializzato, infine l'output strutturato del modello. Non concedere accesso a filesystem sensibili, credenziali o azioni esterne per dimostrare una compatibilità sintattica. Se manca la riproduzione del problema iniziale, registrare il risultato come non conclusivo. Questa è una procedura proposta, non una misura già ottenuta. PR ufficiale 24033: scopo, merge e limiti.
Condizioni e limitazioni
Sono verificati tag, merge e diff; non una release binaria. L'API release del tag risponde 404 alla verifica. I test aggiunti e i check CI upstream non sostituiscono un test locale del modello o del tool calling. Il filtro sum sugli array resta fuori dallo scopo della modifica.
Checklist pratica
- Registrare tag e commit esatti, modello, quantizzazione e template utilizzati.
- Conservare l'ambiente precedente e predisporre un confronto isolato.
- Riprodurre un caso minimo che utilizzi map('filter'), senza dati personali.
- Controllare separatamente rendering del template, prompt e chiamata tool.
- Usare un tool innocuo e senza effetti esterni; non fornire credenziali reali.
- Distinguere esito locale, check upstream e compatibilità ancora non provata.