gerarchia chiamata pacchetti

Dork” post=91561Ciao a tutti,

prima di andare a cena, il qui pro quo che ho generato in questa discussione mi ha fatto tornare in mente un dubbio passato al quale mi ero (o mi era stato…) risposto “vedi nella documentazione dei vari pacchetti che carichi”

Ripropongo la domanda:

C’è un modo di sapere, guardando con occhi attenti, oppure cambiando qualche opzione oppure non lo so…chi è il responsabile della chiamata dei pacchetti che sono caricati?

Nell’esempio:

Il dubbio era se graphicx fosse caricato o meno da pgfplots. Così tolgo la chiamata a pgfplots e lo trovo caricato comunque…non so perché cerco e scopro che un mio pacchetto lo caricava…ok quindi confermato che non era caricato da pgfplots..e invece no…

Dunque c’è un modo di sapere che:

1) sono io che chiamo pgfplots;
2) prima era pgfplots cje chiamava graphicx;
3) poi era il mio pacchetto che chiamava graphics?

Buon appetito!

Corrado.

Cerca graphicx nel file log e lo scoprirai. Puoi ricavare qualche indizio anche dal messaggio finale che ottieni con [tt]\listfiles[/tt].

Ciao
Enrico

Come sai io sono quello che dice sempre di leggere la documentazione e il file .log fa parte della documentazione; un po’ strana, ma documenta quello che un determinato “job” di compilazione ha fatto. Non è certo una lettura facile e divertente, ma pur sempre il file .log documenta tutta la storia di quel particolare job di compilazione.

Anche il comando listfiles indicatoti da Enrico è utilissimo.

Ma vorrei aggiungere una cosa che rende la lettura del file .log o dell’output di listfiles un po’ difficle da interpretare.

Un certo pacchetto può venire chaiamto da diversi altri pacchetti; oppure per sbaglio potrebbe essere caricato più volte nello stesso preambolo. i comandi \RequirePackage e \usepackage controllano se un dato file è già stato caricato; se sì, talvolta, non sempre (non ho capito da cosa dipenda questo comportamanto) quei coandi controlalno anche quali opzioni sono state chiamante nelle varie chiamate; se le chiamante sono fatte con le stesse opzioni, quei comandi evitano di caricare di nuovo il pacchetto chiamato; se le opzioni osno diverse viene emesso un messaggio d’errore che informa del conflitto di opzioni; in ogni caso, anche se al messaggio d’errore si ordina di proseguire, il pacchetto chiamanto per secondo non viene caricato.

Leggere il file .log o l’output di listfiles permette di trovare i pacchetti che sono stati effettivamente caricati; quindi non si vedono chiamate multple. nel file log le parentesi tonde aperte e chiuse aiutano a districarsi un po’, ma permettono solo di risalire al pacchetto o alla classe che ha effettivamente caricato il pacchetto, non ha quelle altre chiamate che sono state ignorate. Sempre meglio di niente, ma non è facile scovare l’intera verità. Bisognerebbe aprire tutti i pacchetti caricati e farsi una liste delle chiamante eseguite cone \RequirePackage, poi forse si riesce a scoprire davvero chi chiama che cosa.

Infatti come ti ha detto @cfiandra, pgf chiama tikz che a sua volta chiama graphicx; se tu direttamente o indirettamente hai chiamanto graphicx prima di pgf, quando è il turno di tikz di chiamare graphicx, si scopre che il pacchetto c’è già e non viene chiamato una seconda volta. Analogamante, ma viceversa se tu chiami graphicx dopo pgf.

Un altro tipico esempio è quello di molti che chiamano amsmath, amsymb e amsfonts; ma amsfonts è già chiamato da amssymb, quindi non viene caricato una seconda volta.

Sarebbe desiderabile che tutti i pacchetti siano chiamabili senza opzioni; e questo meccanismo sarebbe perfetto per non chiamare due volte lo stesso pacchetto; e che ogni pacchetto sia configurabile con un comando del tipo \nomepacchettosetup; in modo che si possano anche cambiare le opzioni specificate altrove e non si avrebbe il conflitto di opzioni, al massimo un messaggio, in caso di opzioni mutuamente esclusive, che la tal opzione è stata annullata, perché successivamente contrastata dall’opzione tal’altra. Ma il LaTeX Team non può stare dietro alla miriade di pacchetti (quasi 3000) di cui è composto TeXLive, e la responsabilità di fare queste cose rimane sulle spalle di chi ha creato i pacchetti. Peccato che i pacchetti esistono da almeno 20 anni, alcuni non sono obsoleti affatto, ma il loro autori nel frattempo siano morti; nessuno lo sa, quindi quei pacchetti non verranno mai aggiornati.

Ognuno dovrebbe aiutare i curatori dei vari pacchetti sengalando loro eventuali conflitti, in modo che i curatori possano provvedere. Spesso le cose non vannao così. Io ho avuto recentemente una conferma che un curatore può anche invitare gli utenti del suo pacchetto a segnalare gli errori; io curo anche il file di descrizione della lingua Latina, che fa parte di LaTeX2e da quando esso esiste; chiesi anche aiuto ad un docente di latino dell’università per darmi una mano su alcune cosette; in questi 20 anni ho avuto tre segnalazioni di cose da correggere da utenti tedeschi. Ma tre giorni fa il prof che mi aveva dato una mano mi ha detto che quel file è inutilizzabile, perché si riferisce al latino moderno (e poi neanche tanto benei…) ma non va bene per il latino classico. D’accodo ma cosa serve mettere la richiesta di segnalare errori e segnalando l’indirizzo e-mail a cui rivolgersi se poi non ci si rivolge a nessuno e non si usa il software o si reinventa l’acqua calda per fare una cosa che basterebbe segnalare?

Questo grido di dolore è un po’ Off Topic, ma è collegato ai famosi conflitti, a chi carica che cosa, a quali opzioni siano state specificate, eccetera.

Segnalo che su TeXLive è apparso pkgloader.

Ciao
Claudio

cfiandra” post=91753Segnalo che su TeXLive è apparso pkgloader.

Ciao
Claudio

Battuto sul tempo! Stavo per segnalarlo io 🙂

Ciao
Tommaso

che, come ho già avuto occasione di commentare, risolve molti conflitti Ma non TUTTI.
Claudio