robitex

ansys” post=73897

La domanda che mi sono posto è però questa: è vero che una guida tematica toglie risorse che altrimenti andrebbero verso ArsTeXnica la rivista del gruppo?

Credo di sì.

Non ho capito: pensi che non ci sia sovrsapposizione o che le guide tematiche tolgano energia ad Ars?

ansys” post=73897

[quote=”cfiandra”]A me la proposta di Roberto piace parecchio. Quello che forse non è ancora stato menzionato è il fatto che serve una certa pianificazione da parte dell’autore e sforzo nel to be compliant da parte del contributore. Mi spiego con un esempio: se l’autore ha deciso che il codice viene inserito con il pacchetto listing e il contributore manda tutto con fancyvrb diventa poi complicato uniformare le cose. La pianificazione dell’autore consiste nel caratterizzare il proprio formato in anticipo, in modo tale che i contributori si adeguino…

In effetti in origine avevo pensato ad una classe apposita per le guide tematiche in modo da uniformare il formato, gestire al meglio questioni come quella da te sollevata. Ma non ho mai pensato di realizzarla in attesa che arrivasse un contributo in tal senso.

Non sono proprio favorevole. L’utilità di avere un formato non-standard permette di apprendere e conoscere classi/pacchetti/stili/font/comandi e così via. La cosa più importante, però, è la disponibilità del codice.
[/quote]

Una classe standard per le guide tematiche non impedirebbe l’uso di pacchetti particolari ma offrirebbe una base comune per arrivare rapidamente al succo del discorso. O forse è preferibile sviluppare le guide in modo assolutamente indipendente. Mi piaceva però l’idea di qualcosa di coordinato almeno nelle strutture tipografiche principali e non è forse questo che conta, la coerenza tipografica come esempio stesso delle caratteristiche di TeX?
Se infatti dai uno sguardo alle guide tematiche pubblicate finora, trovi altrettanti stili ed impostazioni. Se di guide tematiche del GuIT si tratta, allora uno stile anche molto configurabile, comune deve pur esserci.

Grazie.
Un saluto.
R.

Ciao

cfiandra” post=73888A me la proposta di Roberto piace parecchio. 🙂 Quello che forse non è ancora stato menzionato è il fatto che serve una certa pianificazione da parte dell’autore e sforzo nel to be compliant da parte del contributore. Mi spiego con un esempio: se l’autore ha deciso che il codice viene inserito con il pacchetto listing e il contributore manda tutto con fancyvrb diventa poi complicato uniformare le cose. La pianificazione dell’autore consiste nel caratterizzare il proprio formato in anticipo, in modo tale che i contributori si adeguino…

In effetti in origine avevo pensato ad una classe apposita per le guide tematiche in modo da uniformare il formato, gestire al meglio questioni come quella da te sollevata. Ma non ho mai pensato di realizzarla in attesa che arrivasse un contributo in tal senso.

cfiandra” post=73888Leggendo gli ultimi post nel filone dell’Introduzione all’uso di TikZ in Ingegneria in realtà mi è venuta un’altra idea che magari però si adatta bene solo a questa guida. La propongo più in dettaglio nel filone apposito mentre qui la descrivo in breve per non andare troppo OT. Ho pensato di lanciare una call for pictures ovvero in un mese di tempo si può inserire nel filone (o anche mandare per mail) il codice e due righe di spiegazione tecnica per figure di ambiti trattati e non della guida. In questo modo il progetto è diventa comunitario, ma non si è forzati ad utilizzare un repo e i contributori non sono forzati ad usare magari classi non standard.

Anche questa è una giusta osservazione: un repo standard non è immediato da gestire. Occorrono diversi passi come la creazione di una chiave crittografica.
In una sezione community vi sarebbero comunque anche form per l’invio di contributi. Tempo fa ho già sperimentato un componente per la gestione dei form con un discreto risultato. I link sono ancora nascosti.

In generale, mi sembra che le opinioni siano favorevoli. Ricordo molto bene quando alla fine di un meeting la discussione si fermò sulla disponibilità di template LaTeX pronti all’uso, ed in effetti, nello step 1 del nuovo sito, questo è l’ultimo punto ancora da implementare.
La sezione community potrebbe inizialmente contenere proprio le pagine dei template.
Ciao

OldClaudio” post=73874L’iniziativa è ottima, ma secondo me lo sviluppo comunitario richiede un coordinatore, altrimenti si rischia che ognuno (autorizzato ad accedere ai sorgenti) faccia delle aggiunte o delle modifiche che sono in contrasto con altre o vengano ripetuti in luoghi diversi gli stessi concetti.
La GuidaHuIT è un lavoro comunitario, forse troppo grande perché io riesca a fare correttamente il lavoro di coordinatore, ma qui voglio prendere ad esempio l’ottima Arte di scrivere con LaTeX; il fatto che Lorenzo sia così “geloso” dei suoi sorgenti è una cosa che capisco benissimo; lui è il coordinatore e la recente associazione con Tommaso non ha fatto altro che migliorare il tutto; Entrambi sono aperti a suggerimenti e critiche, segnalazioni di errori di cose che potrebbero essere fraintese. Nessuno di noi che ha contribuito all’Arte in qualche forma indiretta si sente “menomato” dal fatto di aver dovuto aspettare che Lorenzo e Tommaso approvassero e facessero propria la comunicazione ricevuta dagli lettori/utenti di quella guida.
Spero che anche i lettori/utenti della GuidaGuIT non si siano sentiti “menomati” nel dover passare attraverso di me.
Ma questo non vuol dire che il lavoro della Community non debba essere coordinato.

Scusate.
Il modo di gestire i progetti mi è rimasto in mente e non l’ho descritto (progetto intenderò una guida tematica):
per ogni guida viene creato un repository di proprietà del coordinatore. Il coordinatore ha la responsabilità dei contenuti della guida.
Il contributore non farebbe altro che clonare il repository, modificare i sorgenti e proporle al coordinatore chiedendo di riunificare i sorgenti.
Il coordinatore valuta la proposta fin nei minimi dettagli e decide se accettare o meno.
Questo succede normalmente nello sviluppo dei progetti open, ed è un idea derivata dal lavoro fatto insieme ad Agostino sull’articolo per pgfplots per ArsTexnica.
Abbiamo avuto qualche problema tecnico nel coordinare i sorgenti e risolvere i diversi punti di vista. Penso che il processo di produzione dell’Arte svolto da Lorenzo e Tommaso sia un po’ nelle stesse condizioni.
Riassumendo, la proposta non è altro che l’avvio di una piattaforma tecnica di sviluppo dei progetti, in cui l’Autore rimane Autore ed il contributore rimane contributore.

Per il discorso Wiki, non a caso o citato negli approfondimenti l’articolo di Lapo su Ars. Ho riflettuto anche con Massimiliano (con messaggi di posta), nel momento in cui ho affrontato l’impostazione del nuovo sito. Mi sono fatto la convinzione che sia migliore la via delle guide tematiche piuttosto che un wiki, molto aperto e flessibile ma forse poco adatto all’argomento TeX, così ricco e complesso.

Stiamo discutendo di una questione che ritengo importante, e che potrebbe portare molte persone a dare il lo ro piccolo contributo, anche solo la propria testimonianza di utilizzatore, e che adesso non dispongono di uno strumento immediato per farlo, nonostante la disponibilità del nuovo sito del GuIT.
Un saluto.
R.

Elrond” post=73815

[quote=”Elrond” post=73812]Problema Windows (sempre problemi dà…): mi pare che le opzioni si indichino con lo slash, ma non ci giurerei e non ho nessuna intenzione di avviare Windows per verificarlo.

No, le opzioni si indicano al solito modo con [tt]-[/tt] o [tt]–[/tt].

Ciao
Orlando

Ok, grazie. Ricordavo che chkdsk vuole le opzioni con gli slash, pensavo quindi che tutti i comandi fossero così[/quote]
Confermo, alcuni comandi di Windows, per esempio shutdown accetta opzioni con in carattere \:
`shutdown \s \t 1800`
spegne la macchina tra 30 minuti.
ecco la prima parte dell’help del comando:
`C:\Users\Roberto>shutdown -help
Sintassi: shutdown [/i | /l | /s | /r | /g | /a | /p | /h | /e] [/f]
[/m \\computer][/t xxx][/d [p|u:]xx:yy [/c “commento”]]

Nessun arg Visualizza la Guida. Equivale a digitare /?.
/? Visualizza la Guida. Equivale a digitare il comando senza
opzioni.
/i Visualizza l'interfaccia utente grafica (GUI).
Deve essere la prima opzione.
/l Esegue la disconnessione. Non può essere utilizzata
insieme all'opzione /m o /d.
/s Arresta il computer.
/r Arresta e riavvia il computer.
/g Arresta e riavvia il computer. Dopo il riavvio del
sistema, riavvia tutte le applicazioni registrate.
/a Interrompe l'arresto del sistema.
Può essere utilizzata solo durante un periodo di timeout.
/p Spegne il computer locale senza attendere un periodo di timeout n
é inviare un avviso.
Può essere utilizzata insieme alle opzioni /d e /f.
/h Mette in ibernazione il computer locale.
Può essere utilizzata insieme all'opzione /f.
/e Specifica il motivo di un arresto imprevisto del computer.
/m \\computer Specifica il computer di destinazione.
/t xxx Imposta su xxx secondi il periodo di timeout prima dell'arresto.
L'intervallo valido è 0-315360000 (10 anni), il valore predefinit
o è 30.`
R.

Elrond” post=73810

[quote=”Guida tematica alla riga di comando, R.G.”]Il $ riportato negli esempi come primo carattere, simboleggia la riga di comando ed è
chiamato prompt. Ha il compito di separare informazioni utili dai comandi utente.

Andrebbe specificato che è tipico dei sistemi Unix.

Tecnicamente non è vero, dipende dalla shell: qui ci sono alcuni esempi di prompt per differenti shell, come vedete non tutti usano [tt]$[/tt]. D’altra parte il dollaro è il prompt predefinito della bash e della sh, probabilmente chi usa altre shell sa anche cos’è un prompt e lo sa riconoscere all’interno di una guida ;)[/quote]

Giusta segnalazione.
Nella pagina di wikipedia il carattere $ è quello più diffuso per il prompt di comando, ma non è certo l’unico possibile.
Grazie ed alla prossima.
R.