XML dinamico

Atterra un altro "pezzo" necessario per 1.9a2, ovvero il parser XML dinamico: invece di attendere il caricamento completo di una pagina XML prima di interpretarla, Mozilla adesso comincia a mandare sul video le informazioni ricevute appena possibile. Se volete, è l'equivalente del parser (X)HTML dinamico che permette di cominciare a vedere le pagine web anche se non si è finito di caricarne tutti i dati. Nonostante questo, la 1.9a2 è stata rimandata alla prossima settimana, a causa di non meglio precisati bug comparsi all'ultimo momento (secondo me, problemini di sicurezza... ;) ).
Altre cose degne di nota:

• ora viene supportato anche VC9 ("Orcas")
  
• Suiterunner fa qualche altro passetto verso la compatibilità con XULRunner
• la pulizia della gestione degli eventi per il completo supporto alle tecnologie assistive, prosegue a grandi passi
• la gestione delle strutture fontconfig è ora comune a Linux e BeOS
• XPCOM è tornato compatibile con AIX
• Salvato un po' di spazio modernizzando alcune funzioni
• I pulsanti Avanti e Indietro non sono più disabilitati nella Personalizzazione della barra degli strumenti
  

Novità in Vista

Oltre ad una pletora di bugfix più o meno interessanti, una sforbiciatina al codice oramai inutile e alla correzione di qualche oscuro crash in XUL, si sono visti cambiamenti vari per un migliore funzionamento con il nuovo Windows Vista: ora è possibile impostare correttamente la applicazione predefinita nell'OS, e far funzionare correttamente gli aggiornamenti automatici anche senza i necessari permessi UAC.
Intanto è comparsa una lista dei requisiti funzionali o meno di FF3: mi pare che si punterà molto sui componenti aggiuntivi, sulla sicurezza e sulla semplificazione della gestione dei dati memorizzati, oltre al solito occhio di riguardo verso gli standard web. Da notare il supporto a CardSpace (MS) e OpenID, con API estensibile per altre tecnologie simili, e una ulteriore integrazione sia con Vista che con MacOS X (nulla mi sembra di vedere circa Gnome/KDE/???).
Via anche la guida in linea, sostituita da link a documentazione sul web.
Ci sono ancora piccoli spazi di discussione, ma il dado è quasi tratto... Da notare che alcune cose sono già state portate a termine (reflow branch, microsummaries, SVG/Canvas, integrazione look&feel Mac, migliorie alle schede), ma solo in minima parte.

Piccola aggiunta

Piccola per modo di dire...
Ora Gecko supporta display:inline-block; e display:inline-table; , come buono ultimo tra i motori di browser moderni, ma ci è arrivato anche lui (CSS2 e 3). Il primo ha un numero di bug sotto i 10.000, e dovrebbe esserci ancora una sorta di "bounty" per chi sistema i bug sotto le 5 cifre offerta anni addietro... ;)
In contemporanea sono arrivati anche dei fix dipendenti dalle due funzionalità implementate sia per i marquee, sia per i plug-in.
In attesa di una nuova patch che tenga conto delle critiche fatte in fase di review e superreview, tra poco sbarcherà anche il parser incrementale XML, che dovrebbe migliorare di parecchio le prestazioni con i documenti xml+xslt particolarmente grossi (ad es. le specifiche XSLT di W3C). Questa è un'altra caratteristica preventivata per 1.9a2: farà in tempo? Il freeze è lunedì...

Ancora cose interessanti

Come succede sempre, poco prima di una nuova versione alfa/beta si riversano montagne di patch interessanti nel nostro alberello... Vediamo un po' di citarne alcune in ordine sparso.

• (Mac) Utilizzare Print Manager invece di cups
• abbellimento dell'elenco dei file nelle cartelle senza index.html
• i file .rdf degli ISP possono ora anche fornire i formati .sfd dei filtri antispam utilizzati
• (SM) i vecchi file di DOMI (inglobati altrove, ovvero in layout e gfx) vengono ora rimossi dall'installer
• viene fornito un file esauriente di TLD validi
  
• tooltip per le cartelle di ricerca salvate
• TB ora usa la nuova API per il controllo ortografico (era l'ultima applicazione a farlo)
• (FF/SM) le voci di about:config presto avranno capacità di copia e incolla non solo per il nome delle preferenze, ma anche per il valore (messo dentro il primo passo).

Insomma, niente di cui lamentarsi troppo! :)

Leccornie

Una giornata intensa, non solo sotto l'aspetto Mozilla (R.I.P. Borg, 15/9/1996-25/1/2007).
Tre le patch da leccarsi i baffi:

1. integrazione della notifica dei nuovi messaggi con spotlight (Mac);
2. corretto crash per doppia chiusura file handle degli archivi jar;
3. riduzione dell'utilizzo di memoria cache, sia in RAM che su disco, grazie all'eliminazione di un campo della struttura dati.

Ritocchi vari: cocoa, xforms, gcc, regressioni reflow-branch, nuova icona FF dell'installer di FF per Vista, ecc. Insomma, non hanno lesinato cambiamenti, dato che Gecko 1.9a2 è previsto per metà della prossima settimana.

Poca roba, ma molto, molto valida per il sottoscritto: finalmente hanno sistemato il problema dell'invisibilità dei pulsanti (Non spam, Non scam, Carica contenuto remoto, ...?) nel caso di header del messaggio spropositatamente lungo. Non mi è capitato più di recente, ma inizialmente ero bombardato di robaccia che dovevo catalogare come Spam e non potevo usare il pulsante (oltre a vedere delle intestazioni o dei pulsanti "tagliati") sul frontespizio del messaggio. Inutile dire che il mio bug report non è mai stato confermato, invece la segnalazione per tb2 è stata subito raccolta: ho chiuso il mio bug come duplicato, l'importante è il risultato!
Nuova versione di cairo integrata (maggiore velocità con immagini parziali e diversi fix per Mac/Cocoa), implementato css3-colors:transparent e il GCC di qualche post fa viene adesso fatto girare durante lo spegnimento di XPCOM per non confondere gli strumenti di rilevamento dei leak.

Business as usual

Periodo relativamente tranquillo per l'albero sorgente di Mozilla.
Finalmente si è conclusa felicemente l'avventura della tribolata patch per SVG (sono stati messi dentro gli ultimi 2 pezzi relativi a layout e gfx), e altri bug di SVG e di XForms sono stati risolti.
Hanno cominciato a fare capolino anche diversi fix (sia per il trunk che per il branch) necessari a Lightning, segno che avremo una nuova versione del suddetto insieme o subito dopo TB2. Quest'ultimo ha anche guadagnato un piccolo file .rdf che permette di creare molto semplicemente un nuovo account Gmail: il meccanismo usato è però generico, quindi immagino che avremo una nuova categoria di "estensioni" per TB (ma non credo saranno gestibili dall'Addon Manager), che permetteranno di configurare facilmente account di posta anche per gli ISP ed i servizi più "ostici".
Finito (o quasi, a parte le regressioni) il parto del reflow-refactor branch, David L. Baron si sta dedicando a sistemare diversi bug che affliggono Gecko fin dai tempi bui: sono stati fatti alcuni passi avanti per gestire anche inline-block e inline-table (CSS 2.1). Un'altra dimostrazione che passare l'Acid Test 2 in fondo è solo parte del problema, e non la panacea di tutti i mali...
Detto questo, IE7 comunque il test non lo passa! :-P

SM 1.1 sugli scaffali e Mac (PPC) in soffitta

E' ufficialmente uscito SeaMonkey 1.1, l'ultima major version di SeaMonkey prima della transizione a Suiterunner (toolkit) e contiene tanta roba già vista in FF e TB nuovi e venturi. Speriamo che ora la transizione al toolkit venga accelerata: alla fine una riunione di tutti i prodotti sotto la bandiera di XULRunner e del toolkit potrebbe essere benefica per tutti.
Altra notizia è che le ultime macchine di build/tinderbox Mac OSX PPC sono state spedite in soffitta, sostituite da un bel serverone con Intel-inside virtualizzato che produce build in Universal Binary.
Molto movimento sul lato bugfix: niente di davvero eclatante, ma è evidente una impennata nelle patch rivolte al lato posta. L'avvicinarsi di TB2 ha innescato una corsa in volata per sistemare un numero notevole di piccoli e fastidiosi difetti del codice mailnews, con alcune influenze anche su Tb 1.5.0.10 e seguenti. Da notare il fatto che ora è di nuovo possibile caricare le immagini remote nei gruppi di discussione. In parallelo prosegue la conversione a Cocoa della UI toolkit: adesso le freccette delle barre di scorrimento sono simili in tutto e per tutto a quelle di Mac OSX.

Drivers 3.0

Nonostante il titolo, non si parla di drivers Windows, ma dei personaggi addetti a migrare il codice Mozilla/Gecko dalla versione 1.8 alla versione 1.9, cui corrisponderanno le versioni 3.0 di FF e TB.
La cosa importante è che invece di essere un gruppo molto ampio di persone che copre tutto il codice (com'è stato finora), qui abbiamo 2 persone per ogni "comparto", con una netta divisione di ruoli e compiti. Personalmente, apprezzo molto il fatto che Boris Zbarsky è stato affiancato a Benjamin Smedberg: la rigorosità del primo (nonché aficionado di SM! ;) ) dovrebbe bilanciare l'irruenza genialoide ma sregolata del secondo... Speriamo.
Per gli altri accoppiamenti, sempre i soliti nomi, eccetto uno: Damon Sicore, nuovo dipendente della Corporation che non avevo mai sentito nominare prima, pezzo da 90 di Jboss ora acquisita da RedHat che si occuperà di tutto un po' (categoria "General"), sicurezza compresa. Per mescolare un poco le acque, tutti quanti hanno un indirizzo presso mozilla.com, anche quelli che sono chiaramente dipendenti di altre società... ;)

Per il codice, una valanga di fix non troppo interessanti (degni di nota un paio di memory leak per casi estremi, e una ripulitura del codice dei widget Mac OS cocoa) e l'ennesimo balletto di checkin/backout per codice sempre legato a Thebes e/o SVG in generale: troveranno il bandolo della matassa? :) Interessante un fix circa il numero di server SMTP gestibili da TB/SM senza che si incasini il profilo: ci sono voluti solo un tot di anni per arrivarci! :-P

Eppur si muove...

Complice il weekend con annesso lunedì festivo (negli USA), fino ad oggi si è visto davvero poco di interessante. Ci sono stati un po' di bugfix sparsi qua e là, compresi un paio di memory leak, un bug causato dal sistema dei commenti di questo sito (blogspot.com, davvero!) che provocava crash, e una alquanto ridicola serie di checkin/checkout da parte di Robert O'Callahan per il traghettamento verso Thebes delle routine che gestiscono il rendering del testo. Il checkin era stato provato qualche giorno fa, per essere subito tolto a causa delle regressioni nei test di velocità di caricamento delle pagine e del browser. Ieri ci hanno riprovato con esiti pessimi (alcune piattaforme non passavano più alcun test), e quindi i cambiamenti sono stati annullati ancora una volta. Allora si è passati a fare il checkin di un pezzetto per volta in modo da isolare le parti problematiche (e non doversi gestire più un bel patch voluminoso): adesso mi pare di capire che mancano due-tre pezzi che si portano appresso anche qualche crash bug. Insomma, un ottimo candidato per un branh experimental che ci si è ostinati a voler evitare con tutte le conseguenze del caso... Mah...
Vorrei anche segnalarvi un esempio classico di cosa gli sviluppatori di SeaMonkey devono affrontare più spesso di quanto non si immagini (lo so, sono di parte, ma leggete ancora un poco).
Da diverso tempo Calendar (estensione di SM) è stata dismessa per concentrarsi su SB/Lightning: nessun rimpianto al riguardo. Si sono quindi aperti alcuni bug per poter far funzionare Lightning anche su SM e recuperare le funzionalità perdute. Dopo aver verificato i lungo e in largo le incompatibilità tra LT e SM si è scoperto che gli sviluppatori di TB avevano modificato un ID (leggi: nome) di una sidebar a cui si agganciano le modifiche di LT, che quindi non funzionavano su SM.
Corretto il nome, finita l'incompatibilità. Restano ovviamente tanti problemi a livello di tema, ma la funzionalità ora c'è.
E cose di questo tipo sono accadute decine di volte nel passaggio tra xpfe (cross platform front end) e toolkit, e solo adesso si sta sanando la situazione, grazie a Suiterunner.

Le cose che verranno

Dopo il GCC descritto nei post precedenti, comincia a farsi strada nei sorgenti di Mozilla un altro pezzo di novità: Web Applications 1.0. Questa specifica è uno sviluppo parzialmente indipendente dal W3C che si è fatta strada negli ultimissimi anni come risposta da parte degli esperti del Web di adesso alle nuove "tendenze" del Web stesso (applicazioni remote e form complessi). Inoltre non è legata a linguaggi o browser specifici (come ogni buona specifica).
Il fatto che Mozilla cominci ad abbracciarla, è un tiepido segno che qualcosa si muove: non dico buono, visto che altre tecnologie implementate in Mozilla invece di fortuna non ne hanno avuta affatto, come ad esempio P3P per la privacy.
Ad ogni modo, è un altro tassello sulla strada di FF3 (oltre che di Mozilla/XULRunner come piattaforma di sviluppo di applicazioni varie, web compreso).
Grande lavoro anche sull'accessibilità: FF3 si preannuncia essere il browser di riferimento anche per tutti i navigatori con disabilità varie.
SM 1.1 ha avuto un nuovo giro di release candidate: se non ci saranno altre brutte sorprese, SM 1.1 vedrà la luce molto presto, e gli sviluppatori potranno così concentrarsi su Suiterunner (SM su toolkit come FF/TB). Si preannuncia un anno interessante...

Quello che non verrà, invece, è il post con le rivelazioni sul sottoscritto che viene richiesto da un vero pseudotecnico molto gentilmente. Ho aperto questo blog per tenere informate le persone su un certo argomento e non sui cavoli miei! :) Eppoi sono un timidone, e 5 rivelazioni mi sembrano davvero troppe. Acconsento a farne solo una: al liceo ero in classe con un politico molto visto in tv di recente, e che ora non è più segretario del suo partito... ;) E sì, anche all'epoca era così palloso e logorroico...

Piccolezze

Giornata di "tagli" in casa Mozilla: dopo aver segato via da extensions/ la cartella xmlterm (un progetto di esempio pubblicato nel 2000 e di fatto abbandonato a se stesso subito dopo), Brendan Eich (capo ingegnere Mozilla nonché padre di JavaScript) ha rimosso la cache delle proprietà JavaScript dall'interprete.
Divertente leggere i commenti nel bug: dopo anni di rinvii e di silenzio, nel giro di 5 minuti zac! Buttato via tutto!
Risultato? Risparmiati 5KB in un colpo solo... E sono stati recuperati i circa 170KB "persi" col GCC dell'altro giorno (almeno secondo i dati relativi a SM). 175KB in un giorno sono un vero sogno! :) Ci si aspetta il peggioramento delle prestazioni in alcuni benchmark JS, ma ci dovrebbe guadagnare la stabilità in caso di sitemi MP (multiprocessore): la vecchia cache infatti era soggetta a race conditions su questo tipo di macchine.

Una domenica qualsiasi

Una discreta calma piatta nell'albero dei sorgenti: l'unico cambiamento degno di nota è una semplificazione nelle strutture dell'interprete JavaScript che ha permesso di risparmiare 4.5KB nel codice, e sostituire 3 algoritmi con uno solo (la quintessenza del refactoring!). Soluzione tampone per il crash del GCC finché non viene implementata una soluzione definitiva al bug (che è ben più importante del previsto e non si verifica solo con le build di debug): in alternativa, David Baron credo sia incline a volere il backout del GCC...
Si è accesa un po' di polemica tra chi vuole buttare a mare l'attuale lxr (lo strumento di controllo via web dei sorgenti Mozilla) con una versione "parallela" sviluppata da timeless: a mio modesto avviso lxr nella forma attuale è veramente limitato, poiché non consente di inserire più di 30 caratteri circa nella ricerca, e non supporta diverse comode opzioni per la ricerca.
Alcuni sviluppatori sono però contrari a certe scelte (soprattutto visive) fatte nella nuova versione, oltre al fatto che le modifiche non sono mai state sottoposte ad un vero processo di verifica. Critica rispedita al mittente da quegli sviluppatori che invece usano ormai da tempo esclusivamente la nuova versione, e che quindi ritengono che oramai il test sul campo è prova inonfutabile della bontà dei cambiamenti fatti.

L'Epifania tutte le...

...Mozilla Application Suite porta via! :-P
Oggi, facendo l'aggiornamento di Fedora Core 5, mi sono ritrovato SeaMonkey 1.0.7 [replacement for Mozilla Application Suite 1.7.13] tra i vari update: è finita un'epoca.
Per il resto direi nulla da segnalare: piccoli aggiustamenti dopo la rivoluzione di ieri, e altri ancora ne mancano visto che i dati sui memory leak sono schizzati a 727KB... Probabilmente si tratta solo di errati conteggi, ma comunque qualcosa da controllare, oltre al fatto che su certe build particolari (debug) sembra che il nuovo GCC vada in crash in maniera ripetibile.

Gestire la spazzatura

In una giornata in cui sono state integrate decine di patch (compresa una del vostro che aggiunge un po' di accesskey alle finestre di dialogo di pubblicazione per Composer), è calata una piccola "bomba" tecnologica da 270KB, un nuovo garbage cycle collector. Urge qualche chiarimento.
Il Garbage Collector (GC per gli amici) è quello strumento software, che funziona parallelamente all'applicativo (di solito in un thread separato), che permette di raccogliere e riciclare tutta la "spazzatura" creata da un programma: in certi casi viene fornito dall'ambiente stesso in cui l'applicazione gira (ad es. Java), in altri deve essere fornito dall'applicativo stesso. Mozilla non fa eccezione alla regola, e infatti implementa (se non erro) l'ennesima versione del GC di Bohm (ovvero l'algoritmo più diffuso) usando il reference counting: detto in parole povere, tutte le volte che alloco della memoria incremento un contatore, e tutte le volte che la libero lo decremento di uno. Il valore che resta (se diverso da zero) viene indagato dal GC per vedere se si tratta di memoria che è possibile recuperare oppure se è ancora in uso. Questo funziona bene per certi tipi di dati e di strutture, ma non funziona affatto per le strutture dati cicliche, ovvero quelle che fanno riferimento a se stesse (per le quali non posso usare il ref counting visto che non so riferire ogni singolo numero ad una specifica copia della struttura, visto che sono tutte copie di se stessa): se cancello la struttura "radice" tutto il resto dell'albero invece di essere recuperato e liberato dal GC rimane nel limbo, sprecando risorse.
Nel tempo sono state usate diverse tecniche per sopperire a questa carenza, di solito molto complesse e molto "artefatte" se non artigianali: il nuovo garbage cycle collector invece è la soluzione scientifica e prevedibile di questo problema (magari non è altrettanto efficiente, ma ha il vantaggio di essere corretta e completa, e quindi prevedibile in ogni caso).
Cosa ci si guadagna, visto che le prestazioni del GC dovrebbero peggiorare di un 10-20%?
Innanzi tutto la gestione tramite il nuovo sistema è molto semplificata: basta dire quale struttura bisogna controllare e il GCC (non il compilatore, occhio!) se la gestisce da solo.
Secondo, finiscono tutte le implementazioni "ad hoc" per ogni struttura, quindi alla fine si risparmia "spazio" e si diminuiscono i bug (il codice è uno per tutti, quindi più facilmente gestibile). Terzo, il tutto viene implementato a livello di XPCOM/XULRunner, quindi sarà disponibile per tutta la piattaforma Mozilla, a qualsiasi livello e per qualsiasi applicativo: facendo un paragone un po' improprio, il GCC diventa parte del Sistema Operativo Mozilla, e ne beneficiano tutte le applicazioni che in tale SO girano.

Altre cosucce degne di nota:

• A breve le macchine di build di mozilla.com/org per Win useranno MSVC8 SP1 (VC Express 2005 versione free) per default (risolvendo così alcuni crash per certi utenti con una nuova dll di MS).
• Il supporto e l'integrazione con Vista: passi avanti concreti.
• Si spera che con qualche patch e una nuova versione di Cygwin/Mingw (al momento poco compatibili con Vista) dovrebbe essere superato il problema di dover fare build con un make "antiquato" e oramai quasi introvabile proprio sotto Cygwin.
• Continua l'integrazione di patch specifiche per OS/2 che dovrebbero permettere a SM di restare "in vita" su OS/2 per più di poche ore (se non ho capito male c'è un grave problema di gestione della memoria centrale che si esaurisce troppo in fretta perché SM non può usare la memoria esterna, anche se disponibile).