Thanks to google docs, enjoy yourself.

appunti modelli per la qualità by dax is licensed under a Creative Commons Attribuzione – Condividi allo stesso modo 3.0 Italia License.

Author: bigambive (IP: 91.212.226.239 , ip-91-212-226-239.server.lu)
E-mail: beaseborspery@gawab.com
URL :
Whois : http://ws.arin.net/cgi-bin/whois.pl?queryinput=91.212.226.239
Comment:
Steady, they fundamental to be taught that filing lawsuits is not the movement of battle to around make disambiguate become fair an goal to piracy. Slightly than, it’s to conveyance something raise than piracy. Like serene of use. It’s to the nth status a fortuity easier to let out down the secure crazy iTunes than to search the Internet with gamble of malware and then crappy character, but if people are expected to cure-all as a cure-all as a pharmaceutical in spite of loads and stick-up owing ages, it’s not cornucopia to work. They lone be subjected to a extemporized issue in the conduct people contrive software and Mouth sites that unpleasantness it ridiculously tranquilly to picaroon, and up the quality. If that happens, then there command be no stopping piracy. But they’re too sharp and skittish of losing. Risks suffer with to be protected!
organic farming pros and cons

Cheers.

Comincio dalle cartelle:
mkdir -p "$builddir" "$repodir" "$cachedir"
$builddir è il workspace vero e proprio, conterrà le cartelle con i PKGBUILD dei programmi ossia le loro $startdir, solo per i casi di pacchetti devel conterrà anche i sorgenti.
$repodir è una cartella di transito, ckit copierà i pacchetti man mano che compila, vedere post_build(). Questa cartella in più conterrà anche i log che probabilmente starebbero più comodi in una ~/.ckit, magari più in la sposteremo, per ora 0.58 stanno ancora qui dentro.
$cachedir è la cartella deposito, ad ogni add() ckit sposterà i pacchetti __$aggiunti__ al repo (dove per aggiunti intendo un livello di astrazione su repo-add ed upload con rimozione versione precedente). Questa cartella __NON__ verrà mai svuotata in automatico perché non si può prevedere quando un pacchetto si compila ma “non funziona”, in tal caso sarà disponibile al volo la cache ma si dovrà procedere a mano per copiare dentro $builddir ed inserire il pacchetto nel lista dei build fatti, di questa lista ne parlerò tra brevissimo. L’unico modo per svuotare questa cache sarà con ckit -H e SOLO quando lo sviluppatore ne riterrà opportuna l’azione.

Parliamo dei log, esistono 4 log, dei quali 2 fissi e 2 volatili. I due log volatili sono quelli più usati ossia il $buildlog e $checklog mentre i due log fissi sono $deletelog ed $updatelog.
$buildlog è valorizzato dalla build() in particolare post_build(), e contiene la lista dei pacchetti presenti nella $repodir quindi i pacchetti prossimi ad essere aggiunti. Se pensate che è ridondanza vi do ragione, è proprio così infatti c’è in progetto l’eliminazione ma per ora 0.58 esiste. La potenza di ckit è data anche da questo log, hai la possibilità di dare sempre makepkg a mano per cavoli tuoi, puoi farlo fare ad un amico te lo giri via rete o con penna un modo qualsiasi, l’importante è che lo copi in $repodir e __PER_ORA__ inserire il nome in $buildlog a mano in un posto qualsiasi purché a capo di una riga vuota e seguito da un Invio (credo carrage return e line feed nell’atto pratico) quindi dare ckit -A che man mano che __$aggiunge__ (n.b. sul significato di aggiungere spiegato poco sopra) sposterà i pacchetti nella cache e solo al termine eliminerà il log, che non servirà più evidentemente.
$checklog è valorizzato dalla check() e contiene i pacchetti ottenuti dalla funzione stessa, ossia i pacchetti che necessitano aggiornamento perché outdated. Non ci sarà differenza tra stabili e devel, non a livello di log certo, ma a livello di check(). Per come è progettato ckit la check() non terrà conto dei pacchetti devel che non sono presenti nel workspace, perché questo? Si tenga d’occhio che i pacchetti stabili hanno un riscontro immediato da AUR, e sebbene ciò può tecnicamente avvenire anche per i devel questo non è affidabile. Come risolve ckit? Bene, ad ogni check() lui esegue questo controllo:
if [[ "$develcheck" == "0" ]] && is_devel "$pkg" && [[ -d "$builddir/$pkg" ]]; then
dove il primo argomento indica l’espresso consenso dello sviluppatore nel voler processare i pacchetti devel, il secondo indica l’effettiva presenza della versione devel mentre il terzo indica l’effettiva presenza della cartella nel workspace. In questo modo si consente esplicito consenso nel seguire l’andamento della versione devel, quindi ckit provvederà a __capire__ lo stato del repository dei sorgenti con un makepkg a vuoto che sincronizzerà il repository remoto
makepkg -o 2>&1 | awk -v "pkg=$pkg" '$0 ~ pkg {print $6}'
Nel caso sia presente un ipotetico pacchetto “voluminoso” quale un xbmc-svn con ben 5 giga di sorgenti, lo sviluppatore potrà non seguirne l’andamento semplicemente non avendone la cartella, o eliminandola, in workspace. Lo sviluppatore potrà cominciare a seguire quel pacchetto semplicemente __$installando__ nel suo workspace la cartella con il PKGBUILD di quel pacchetto con ckit -U xbmc-svn. Con questa particolare speigazione sono uscito un pelo fuori traccia, ma penso sia stato utile per capire il fatto delle cartelle del workspace.
Passiamo ai due log fissi, questi log sono stati introdotti con lo scopo di colmare lacune di ckit. Ebbene si, ckit ha lacune, ma che non sono proprie dello script quanto dei pacchetti. Servono ad intridurre elasticità sui PKGBUILD, in realtà è più una falla dei PKGBUILD fatti male che limitano l’effettivo lavoro di building, quindi ckit prevede che ci possono essere PKGBUILD fatti coi piedi e si prepara a superare questa lacuna.
$deletelog contiene alcuni pacchetti inseriti __SOLO__ manualmente dallo sviluppatore che necessitano di essere svuotati dei sorgenti. Ad esempio, amule-devel è devel quindi ckit non gli segherà i sorgenti però ha un carattere stabile a snapshots notturni ed ogni archivio è standalone quindi è inutile conservare l’archivio dei sorgenti della release precedente. In tal caso lo si potrà scrivere nel $deletelog per poi dare ogni tanto a discrezione dello sviluppatore ckit -DL (o anche ckit -D amule-devel). Altro problema l’ho notato a suo tempo su gnome-do-bzr, il PKGBUILD fatto coi piedi non riusciva a superare alcune copie ed un modo efficace era rimuovere a mano alcune robe, detto a spiccioli bastava anche un makepkg -c ad ogni build() ma questo comportava inserire un paramertro delegando allo sviluppatore mentre un modo per farlo in automatico (o semi-automatico) era mediante $deletelog (o in alternativa sempre ckit -D foo-bar-baz). Ho subito notato una possibilità di far cooperare -D e -B ma di primo acchito ho notato conflitti nell’uso delle risorse, magari prossimamente si potrebbe risolvere.
$updatelog viene sempre e __SOLO__ scritto a mano dallo sviluppatore, e contiene i pacchetti che necessitano di un aggiornamento manuale da AUR. Questo viene in soccorso per colmare la lacuna dei PKGBUILD non proprio fatti male, ma che sono devel e conservano un carattere stabile, ad esempio xbmc-svn che nonostante sia devel viene aggiornato solo a commit che compilano saltando i commit intermedi. Altro esempio è su gnome-do-bzr che a mio parere è proprio un pacchetto fatto coi piedi e conserva tutte le lacune previste, sia per la sincronizzazione dei sorgenti che per la compilazione. Ma non ho intenzione di correggere PKGBUILD, ne tantomeno si richiede che vengano corretti. ckit accetta tutto volente o nolente semplicemente si adatta e amen, quindi in questi termini la check() verrebbe sempre lanciata con -ULCd o -ULC (n.b. i riferimenti ai PKGBUILD per lo meno di gnome-do-bzr sono relativi al periodo di quando ho iniziato a seguirne lo sviluppo, attualmente non so come procede se hanno migliorato o peggiorato non mi importa ho iniziato così ho notato irregolarità quindi frega niente, si va avanti così male non fa e questo non implica l’utilità dei log fissi se ce n’è / ce n’è stato almeno uno, ce ne possono essere altri quindi i log possono servire sempre).

Questo è quanto, vorrei solo concludere con una nota sull’ultima funzione aggiunta relativa alla manutenzione del workspace. Dopo un po di tempo, mesi o settimane, aggiungendo o droppando pacchetti si potrebbe raggiungere un certo livello di occupazione su disco del workspace. In tal caso nasce un problema, se do un bel rm -rf /foo/bar/baz/workspace poi mi tocca ricordarmi tutti i pacchetti devel che seguivo per averne le cartelle? La risposta ovviamente è si, ma ho introdotto proprio di recente una nuova interfaccia -S che chiama aurdevelsync(), che scorre la lista dei pacchetti saltando quelli stabili, di volta in volta verrà chiesto foo-devel: update? (y/n) quindi si potrà procedere alla __$installazione__ nel workspace per procedere con i successivi check().

Detto ciò, chiudo. Saluti.

Stamattina ho provato slim, con questo .xinitrc
exec ck-launch-session openbox-gnome-session
e qualcosa presa da Marinz circa slim.conf da questo articolo qui.

Tutto qui, con slim ho risolto tutto in un lampo, cosa che non riuscivo proprio con gdm.

In Wordnet la parola viene considerata come un’associazione fra una word-form e una word-meaning. La word-form è l’espressione fisica della parola, la stringa come concatenazione di lettere, mentre la word-meaning è il concetto lessicale che la word-form esprime.
La matrice lessicale realizza il mapping tra word-form e word-meaning. Nei casi di parole con più significati, quindi polisemiche, avremo più word-meaning che corrisponderanno ad una stessa word-form, mentre nei casi opposti di parole sinonime avremo più word-form che corrisponderanno ad una stessa word-meaning.
Una word-meaning viene rappresentata dall’insieme di tutte le word-form che possono essere usate per esprimerla, questo insieme si chiama synset.
I synset sono quindi collezioni di sinonimi di word-form che aranno associati ad ogni word-meaning, le word-form quindi sono mappate tra loro grazie ai synset mentre le word-meaning sono mappate tra loro grazie alle relazioni tra i synset. L’utente quindi, conoscendo la semantica di almeno una delle word-form del synset, è in grado di ricavasi la word-meaning, ossia il significato della parola.
Sulla base della memoria lessicale umana, Wordnet si suddivide in quattro categorie lessicali: nomi, verbi, aggetivi ed avverbi. I nomi sono legati da due tipologie di relazioi: relazioni lessicali e relazioni semantiche. Le relazioni lessicali interessano le word-form, ad esempio sinonimi e contrari tra parole con stessa word-meaning, od opposta; mentre le relazioni semantiche interessano le word-meaning, ad esempio l’eponimia tra significati. L’eponimia stabilisce un nesso logico di tipo inclusivo tra word-meaning e può essere iperonimia, quando dati due word-meaning la seconda è inclusa nella prima, mentre iponimia quando si verifica l’opposto. I verbi sono legati da due tipologie di relazioni: implicazione e causa. La prima è simile all’iperonimia dei nomi ma riguarda gesti o attività, mentre la seconda è un’azione prodotta da un’altra.