Newsgroup: it.comp.macintosh
Titolo: [OT ma non troppo] Perche' Software Libero.

Ci sono i motivi politici per cui una persona adotta il software libero, ma
sopratutto motivi pratici.
Lo avevo sperimentato anni fa con una scheda video supportata ma non troppo
da XFRee. In 3 mail e 2 giorni ero in grado di attendere senza problemi il
nuovo driver grazie ad una piccola patch.
Lo ho risperimentato oggi.
Stamane ho inviato un bug report riguardo ad un comportamento non bello
di Emacs con Carbon (problemi di focus).
Stasera ho gia` avuto una risposta e pare pure andare...
-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico e fancazzista 
\/

 di Emacs con Carbon (problemi di focus).
a proposito, nell'ultima versiona del cvs hanno implementato
l'antialising dei font?
-- 
Tommaso Passi - masolino
masolino [at] 
mail.inet.it

 l'antialising dei font?
Mi sembrava di aver sentito che era tra i todo, ma mi sono iscritto solo
oggi alla mailing list dei developer, tanto per vedere che succede e a
chi rompere le toe...


 Stasera ho gia` avuto una risposta e pare pure andare...
ti va di postare qui? :))
-- 
RiK0
 Il sonno del teschio genera troll, e il quoting li manifesta.


| 
| If the focus problem go away with this, it is due to the change
| between 1.69 and 1.70.
| 
| 				     YAMAMOTO Mitsuharu
Ho preso il file macterm.c, l'ho rimpiazzato al file che veniva dal CVS e
ho compilato. Per ora non ho noie, con l'ultima versione il problema si era
manifestato subito.
Invece ora pare reggere bene.
Credo che tra poco mandero` una risposta positiva a Mitsuharu.
(che sia parente del noto ammiraglio ?)


 manifestato subito.
allora ho capito anche perche` io non avessi il problema.
la mia versione e` ben piu` vecchia...
per i font >7bit si sa nulla? :))



che pero` attualmente non e` piu` sviluppato.
La cosa interessante e` che l'autore ha rilasciato i sorgenti del programma.
Ora io non sono un programmatore e quindi non ho idea di come compilare i 
sorgenti, quindi chiedo a voi, c'e` qualcuno che potrebbe compilarli ? o 
magari e interessato a continuare lo sviluppo ?.
-- 
Riccardo Saettone
Per rispondere togliere Alfa e Beta dall'indirizzo

 magari e interessato a continuare lo sviluppo ?.
in che linguaggio e' scritto?

 in che linguaggio e' scritto?
Cocoa, ma i sorgenti ha quanto a capito sono completi di tutto pronti da 
compilare, basta aprirli con xcode.
Secondo me e` un programma che merita.


 Cocoa
Cocoa?

 puoi scaricarti i sorgenti e guardare 
personalmente.


 personalmente.
Fatto, poi ci do un'occhiata e ti faccio sapere

 personalmente.
In effetti sono riuscito adesso a compilarlo, ho perto il progetto con xcode 
e poi ho dato il camndo build e` giusto cosi` ?.
La compilazione va a buon fine anche se vengono registrati degli "errori", 
probabilmente dovuti anche al fatto che i sorgenti erano stati fatti con la 
precedente versione di xcode.
Secondo me, varebbe la pena che lo sviluppo continuasse anche perche` gia` 
ora a parte qualche problema di stabilita` ha il 90% delle funzioni che un 
newsreader deve avere.


 chi rompere le toe...
era ora, ormai non riesco a farne a meno, mi sono abituato con lo
smoothing su tutte le apps e non averlo mi infastidisce parecchio
Alla fine uso gvim che ce l'ha
Ciao, Tommaso


 per i font >7bit si sa nulla? :))
Le dritte ricevute non hano funzionato. In compenso ho iniziato ad usare
una patch mandatami da Yamato-san per la versione CVS del file.
Vediamo, con quella che avevo messo non c'era il supporto per il tooltip.


 piuttosto un soprainsieme del C, dinamico e orientato agli oggetti.
Penso anche io. ObjectiveC e` una delle cose che Mac OS X si porta dietro
da NeXT. E a naso lo preferiro` al C++.


 da NeXT. E a naso lo preferiro` al C++.
infatti. a me piace davvero tanto. e` un bel linguaggio... non bello
come Python, ma ugualmente comodo e potente.
Hai una buona libreria standard, con delle buone API (e il FoundationKit
-- per generalizzare, quello che non e` GUI -- e` praticamente
compatibile con quello di GNU/Step... per le GUI qualche rogna in piu`
;) ).


 ;) ).
Che bello :).
Mi devo decidere a dare un'occhiata al programma XPager che mi ha
regalato il mio amico...


 regalato il mio amico...
fa quello che penso?



Era quello che ti attendevi ?
Patch correttive sono le benvenute!



nonostante le avvertenze e` molto stabile...
nelle preferenze, scegli effetti strani di transizione fra un desktop e
l'altro... hai il cubo e molti altri, tutti in openGL :))
anche questo e` tutto open :))
purtroppo ho visto che i due progetti insieme (chiaramente) non
funzionano bene.


 funzionano bene.
Marco si era scritto questa utility per lui. Fa il minimo che
serve e quindi presumibilmente pappa poche risorse.
Farli integrare ? 


 E io non sprecare cicli macchina :) 
Se il tuo problema e` un feticismo per i cicli-macchina e non uno per il
codice nativo, potresti trovare Objective-C una delusione rispetto alle
prestazioni di C++.  In C++, tutto il linguaggio sin dall'inizio e`
stato orientato (alcuni direbbero "distorto"...) dalla possibilita` di
NON sprecare cicli macchina: in altri termini, anche quando il
compilatore non era (ancora) in grado di sfruttare certi aspetti di
ottimizzazione, il linguaggio veniva comunque limitato a quelle
possibilita` che un compilatore futuro (usando tecnologie gia` note
all'epoca della progettazione del linguaggio) _avrebbe_ potuto
ottimizzare al punto di non sprecare cicli macchina.  Ad esempio, una
chiamata di metodo virtuale deve comportare UN look-up di un indirizzo
in una tabella (e quel ciclo macchina non e` "sprecato" perche`
ovviamente senza almeno un livello di indirettezza non puoi fare
dispatching...); questo ovviamente comporta una notevole rigidita` e
complessita` del linguaggio, ma se il tuo feticcio e` non sprecare cicli
macchina, cosi` dev'essere.
In Objective C, invece, sin dall'inizio l'architettura di dispatching e`
sempre stata ragionevolmente semplice e flessibile, modellata su quella
di Smalltalk.  In pratica, Objective C sono due linguaggi in uno: il C
per le operazioni elementari/procedurali, con "embedded" una specie di
sottoinsieme di Smalltalk per le parti OO/dispatching.
Naturalmente questo e` inaccettabile per chi non puo` concepire di
"sprecare cicli macchina".
Python puo` essere considerato frutto di una scelta analoga, eccetto che
i "due linguaggi" (o anche di piu`, in realta`) non li metti negli
stessi file-sorgente, ma in file separati: pippo.c se vuoi fare cose
elementari/procedurali in C, pippo.py se vuoi fare le cose OO, ad alto
livello, ecc ecc.  Personalmente preferisco di gran lunga questa scelta
(cosi` come ad esempio approvo che gli standard del linguaggio C _non_
supportino l'assembly embedded: se voglio scrivere codice assembly come
parte del mio programma preferisco comunque che se ne stia in file
sorgenti .asm tutti suoi, piuttosto che non mischiato al sorgente C in
file .c); evidentemente molti preferiscono i miscugli (e infatti
parecchi compilatori C supportano estensioni per miscugliare assembly al
sorgente C).
La scelta di separare i sorgenti (e interfacciarli con API ben definite)
ha permesso che alla iniziale situazione "C da una parte, Python
dall'altra" si aggiungessero N altri linguaggi possibili, come il pyrex
(un linguaggio intermedio con semantica sostanzialmente C + interfaccia
facilitata a Python, e sintassi praticamente Python) e mille altri
linguaggi esistenti (Fortran, C++, Objective C, ... e in altre
implementazioni Java, C#, ecc ecc).  Questa scelta impone inoltre che
anche la parte "alto livelo" sia auto-sufficiente (con l'aiuto di "bassi
livelli" intrinsecamente incorporati), il che facilita la scrittura di
prototipi (che spesso poi si dimostrano sufficienti, senza richiedere la
ri-stesura di alcuna parte in C o che altro...).
Comunque, purche` ci si renda conto con precisione del proprio
feticismo, non c'e` nulla di male a perseguirlo, ovviamente.  In
particolare e` importante che tu capisca, come apparentemente capisci,
che e` proprio il fatto dei "cicli di macchina" in quanto tali, non una
sua qualsiasi consequenza osservabile (come il tempo percepito
dall'utente), ad interessarti.  Ad esempio, Marchetti della Nokia, a
Europython, ci ha mostrato alcuni esempi di Python sui cellulari Nokia
Symbian Serie 60 confrontandoli con analoghi programmini C++ e Java.  Un
"programma" per spedire un SMS risultava poco sopra le 200 istruzioni in
C++, contro un paio in Python (un caso un poco estremo; rapporti piu`
normali erano sul 50:1 circa).  Naturamente la velocita` di esecuzione
dei due programmi era perfettamente indistinguibile da qualsiasi essere
umano (anche uno dotato di un cronometro di precisione).  Nondimeno e`
praticamente certo che la versione Python sprecava alcuni cicli di
macchina rispetto a quella C++.  Capisco dunque che qualcuno scelga di
fare 50 o 100 volte piu` lavoro, senza nessun vantaggio umanamente
osservabile, allo scopo di "non sprecare" alcuni cicli di macchina di un
processore cosi` possente e prezioso come quello incorporato in un
telefono cellulare (peccato che quei clcli "non sprecati" non si possano
mettere da parte per il futuro... e` questa storia dell'_interattivo_
che spreca miliardi e miliardi di cicli macchina, ora basta, bisogna
tornare al BATCH, quello si` che non ne spreca...!!!)...;-)
Alex

 Farli integrare ? 
beh... integrare i progetti direi di no... nel senso che fanno proprio
la stessa cosa :))
ma magari far collaborare gli sviluppatori :))
credo che il problema sia il reverse engeneering di Quartz... 


 tornare al BATCH, quello si` che non ne spreca...!!!)...;-)
Hmmmm, pensando a gente come i vari CL et simili di "Storie dalla Sala
Macchine" intravedo l'utilita della cosa... :) :) :) :) :)


 Macchine" intravedo l'utilita della cosa... :) :) :) :) :)
Mah, forse occorre essere della mia generazione (e averla quindi
_vissuta_, la stagione del "batch") per capire la battuta...!-).
Comunque tecnicamente e` indiscutibile: l'operazione batch (con
spooling) _non spreca_ i cicli di macchina che invece "spreca" qualsiasi
sistema multitasking pre-emptive, che sta sempre li` a commutare di
contesto da un processo all'altro, e magari a paginare a/da disco...!
Alex

 _vissuta_, la stagione del "batch") per capire la battuta...!-).
Mancata per un pelo. Ho solo sentito alcuni racconti.


 camicie per  stubare la caldaia  di una 740  con la AVTS.
Paragone del menga,  stubare e restaurare la caldaia di  una 740 ha un
valore intrinseco come conservazione di una testimonianza storica.
Nella frase precedente avrei desiderato esprimere un paragone con una
attivita` che non si giustifica se non col gusto di farla.
