Newsgroup: it.comp.macintosh
Titolo: OpenOffice nativo (no X11): finalmente!

Non mi sembra che sia già stato segnalato (in caso contrario mi
scuso):
http://eric.bachard.free.fr/news/

> 
http://eric.bachard.free.fr/news/
sperem!

 
http://eric.bachard.free.fr/news/
Uhm... cosa dovrebbe farlo preferire a NeoOffice, che è un ramo attivo
già da parecchio tempo, e quindi più testato?
Daniele
-- 
 my website: 
www.purrone.net
"We are the ones who will never be broken, we are the ones who survive!
 This is the sound that brings us together, you are the one by our side!
 And through it all, the spirit's alive!" (Dropkick Murphys)


saludos
germano il gatto grigio
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 già da parecchio tempo, e quindi più testato?
Per esempio potrebbe non usare Java e quindi risultare molto più
performante (su un MB 2 GHz con 2 GB di RAM NeoOffice impiega quasi 15
secondi solo per partire)... a mio avviso manca su OS X una suite
office completa, aggiornata e veramente usabile con soddisfazione:
NeoOffice è lento, M$ Office non è UB e non si sa quando e come
verrà aggiornato, iWorks tratta (bene) solo testi e presentazioni,
AppleWorks non lo nomino nemmeno...
Lunga vita a NeoOffice ma francamente oggi mi viene un po' di mal di
stomaco quando lo devo usare. Inoltre potrebbe significare un nuovo
orientamento in OpenOffice tale da favorire il ricongiungimento dei due
rami di sviluppo...

 già da parecchio tempo, e quindi più testato?
Se c'è java di mezzo anche lì nulla. Comunque son migliorati un pò tutti
e due...ora sono meno orrendi di interfaccia (direi che siamo ai tempi
di os x public beta).
-- 
www.malcom-mac.com/blog
software development for Mac/Win
nemo - cocoa newsgroups reader for macintosh

 di os x public beta).
ah mmmm neoffice è più mac. in compenso rimane esasperante lento.
Magari se openoffice fosse più veloce... chissà.


 
http://eric.bachard.free.fr/news/
E' senz'altro una buona notizia, ma vorrei ricordare che un OpenOffice
nativo esiste già da parecchio tempo e il suo nome è NeoOffice che da
poco è nativo anche per quanto riguarda l'interfaccia.
Non posso certo dire che sia una scheggia ad avviarsi ma sul mio iBook
ci mette una ventina di secondi ad avviarsi la prima volta e circa la
metà le altre.
Volevo far notare anche un aspetto prettamente più umano: per come la
vedo io sono senz'altro più meritevoli i due (si 2 contati che
lavorano sul codice + ovviamente i betatester) sviluppatori di
NeoOffice che portano avanti questo progetto con risultati ottimi che
il team di OpenOffice che pur essendo supportato da Sun, e penso altre
aziende, si sveglia solo ora con l'annuncio di una versione senza il
fardello di X11.
In conclusione su Mac onore e gloria a NeoOffice che almeno per me
sarà sempre al primo posto.

 sarà sempre al primo posto.
Da beta-tester di NeoOffice 1.x, sarò lieto di continuare a supportare
questo programma. Ma se OO risultasse migliore non continuerò certo ad
usare Neo per una questione di principio...
Ciao,
Paolo


Grande neooffice! 

 risultasse essere più stabile di OpenOffice, sarebbe vero il contrario.
puoi rinfrescare la memoria?
grazie
-- 
()_() | NN KAPISCO XK' CELLHAVETE T'ANNTO CN ME SL         | +----
(o.o) | XK' SKRIVO 1 P'HO VELLOCE MA HALL'ORA DITTELO      | +---+
'm m' | KE SIETE VOI K CI HAVVETE PROBBLEMI NO PENSATECI   |  O  |
(___) | HE SENZA RANKORI CIAOOOO                           |
                    raffaele punto salmaso at gmail punto com

 puoi rinfrescare la memoria?
No, perché è una storia lunga. Ma puoi andare a vedere nei forum di
Planamesa. Vai indietro di un paio di anni.
Ciao,
Paolo

 
http://eric.bachard.free.fr/news/
Una domanda banale: ma sia OpenOffice che NeoOffice sono Java?
-- 
Ciao,
ReX

 risultasse essere più stabile di OpenOffice, sarebbe vero il contrario.
Che poi all'inzio Open sarà più instabile... diciamo che non mi
stupirei.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 già da parecchio tempo, e quindi più testato?
neooffice è di una lentezza *mostruosa*
sono ottimista per openoffice nativo, finalmente 
se è quello che promette, neooffice è destinato all'oblio
-- 
=== Mablung The Heavy Hand ===

 
neooffice usa java pesantemente per tutto (o quasi) quello che riguarda 
l'interfacciarsi con osx (stampa, font, drag and drop). Openoffice di 
per sé ha bisogno di java solo per alcuni processi (tipo base).
f:
-- 
questa non e' una tag

 usare Neo per una questione di principio...
infatti, se openoffice riuscisse a colmare il gap di velocità mantenendo 
l'ammirabile stabilità ottenuta da pluby credo che difficilmente 
neooffice avrebbe ancora senso. quello che temo è proprio la qualità del 
lavoro del team di erik.


 
ricongiungimento non credo proprio, ma se openoffice avesse una release 
integrata con osx parecchi betatester che ora usano neooffice 
passerebbero a openoffice per la maggiore velocità, facilitando lo 
sviluppo.
anche se openoffice è lento di per sé e anche credendo a pluby quando 
dice che comunque certe cose rallentano passando su osx per la filosofia 
stessa di openoffice, l'abbandono di java e l'utilizzo di carbon in 
luogo di cocoa renderebbe presumibilmente il pacchetto più veloce in 
molte delle sue funzioni.
comunque lo sapremo l'anno prossimo.


 sperem!
comunque ho visto che la timeline vede una alpha solo a partire dal 
febbraio 2007. non vorrei che questo annuncio preventivo sia stato fatto 
solo per gettare sabbia sull'alpha di neooffice aqua.


 se è quello che promette, neooffice è destinato all'oblio
come dicevo altrove le mie paure sono legate alla qualità del lavoro del 
team di erik. ad oggi neooffice ha sempre promesso cose che stava per 
mantenere, o addirittura nel momento in cui le rilasciava. e ad oggi 
l'unica release di openoffice integrata decentemente con osx è quella di 
neooffice.
il team di erik invece vive di promesse e di annunci dati molto molto 
preventivamente. le mie esperienze di debugging con openoffice e 
issuezilla non sono poi molto positive, niente a che vedere con la 
rapidissima tempistica del lavoro di pluby con bugzilla.
comunque al momento erik ha in mano un demo di alcune funzioni che 
girano senza x11, non ci sono alpha e non ce ne saranno fino al 2007, e 
pare che non ci siano validi programmatori con basi carbon nel gruppo.
se son rose fioriranno, ma per ora non sputerei nell'unico piatto di 
portata.


 quello che temo è proprio la qualità del lavoro del team di erik.
Piccola scommessa: NeoOffice abbandonerà java (in una versione
utilizzabile del programma) prima di Erik.
Sono i vantaggi della concorrenza...
Ciao,
Paolo

 utilizzabile del programma) prima di Erik.
temo che vincerei. tutto neooffice è radicato su java, per neooffice 
abbandonare java significherebbe riscrivere tutto da zero in carbon  il 
lavoro già fatto in questi tre anni. è impossibile.


proteus anguinis ha scritto:

Grazie per la spiegazione, ma una soluzione completa e nativa analoga a 
Office per Windows non esiste?
-- 
Ciao,
ReX

 Office per Windows non esiste?
esiste per ppc office per mac, che comprende word, excel e powerpoint ma 
non access.
tranne neooffice/openoffice, tutti gli altri integrati (applework, 
iwork, thinkfree, ragtime) sono assai più limitati del pacchetto microsoft


 Office per Windows non esiste?
Definisci "nativo".


 lavoro del team di erik.
Scusami ma credo che quello che dici è al limite del FUD. 


 lavoro già fatto in questi tre anni. è impossibile.
Tenendo però conto che Apple ha deprecato le API Java/Cocoa, queste in
una futura release dell'OS spariranno. Quindi speriamo ci si metta di
buzzo buono.


 Scusami ma credo che quello che dici è al limite del FUD. 
ovvero?


 
Ma è PPC :-(!
-- 
Ciao,
ReX

proteus anguinis ha scritto:

Quando scrissi la tesi di laurea, prima di passarla a Latex avevo usato 
Word e non mi ricordo per quale ragione ma dovetti usare per un po' di 
tempo OpenOffice su Windows: beh, il risultato fu che molte tabulazioni 
saltarono e in generale i paragrafi non erano visualizzati come li 
vedevo in Word, alla fine dovetti ritornare a Office...
-- 
Ciao,
ReX

 Definisci "nativo".
Intendo una suite compilata e non interpretata (escludi quindi le 
applicazioni PPC che girano con Rosetta e le applicazioni Java).
-- 
Ciao,
ReX

 
ah beh che discorso, se hai la sfortunata idea di utilizzare un formato 
proprietario microsoft di cui non si conoscono le specifiche, aspettati 
di lavorare con il programma per cui quel formato è nato.


 non access.
Non ci avevo pensato! In questo momento, quindi, NeoOffice è il
pacchetto per ufficio più completo che ci sia su Mac. A qualsiasi
prezzo.
Ciao,
Paolo

 Ma č PPC :-(!
a me va piů veloce degli altri due nativi :-|
-- 
www.malcom-mac.com/blog
software development for Mac/Win
nemo - cocoa newsgroups reader for macintosh

 applicazioni PPC che girano con Rosetta e le applicazioni Java).
E da quando in qua una cosa non compilata non sarebbe nativa? Il sistema
di gestione di Fax distribuito con MacOS è scritto in Python *e* quindi
interpretato.
Ti sembra poco nativo?
Quando finalmente Microsoft avrà finito di scrivere Office in .Net (e
quindi girerà solo su CLR o compatibili) non sarà più nativo?


 ovvero?
Ovvero il fatto che dici di "temere per la qualità del codice di erik".
Come a dire che è un incompetente (cosa che mi risulta non essere).
Semmai il problema potrebbe essere cessazione di fondi o roba del
genere. Ma non credo proprio che Erik sia un incompetente.


 genere. Ma non credo proprio che Erik sia un incompetente.
non so, il supporto per 
openoffice.org
 1.x sotto x11 mi è sempre 
sembrato molto molto debole, bachi nati nella compilazione non sono mai 
stati corretti e non c'è mai stato uno straccio di supporto per gli 
utenti (che infatti era sul forum di trinity). La gestione di issuezilla 
mi sembra poi una babele dove un bug rischia di rimanere in sacche di 
debugging per anni. Mi pareva inoltre di ricordare che il team di erik 
avesse messo per iscritto le proprie competenze informatiche e che il 
curriculum non brillasse proprio, ma se mi dici così non vorrei aver 
confuso i due eri*
detto questo, annunciare il porting di Oo in cocoa poi smentirlo, 
annunciare quello in carbon quando non avevano nulla in mano, e ora 
annunciare la presentazione in autunno di un demo (eh già, si parla di 
alpha solo per l'inizio del 2007) in concomitanza dell'annuncio di 
neooffice aqua, ecco, non sono cose che mi fanno ben sperare per la 
serietà del loro progetto. anche le poche risposte venute fuori dopo la 
cancellazione dei riferimenti a neooffice dal sito ufficiale di 
openoffice.org
 sono state poco poco professionali.
poi magari sono bravissimo vedremo.


 quindi girerà solo su CLR o compatibili) non sarà più nativo?
Ma tu che intendi per nativo?
Occhio che io ho parlato di nativo con leggerezza, non volevo 
addentrarmi in discorsi informatici che credevo fuoriluogo. Ho inteso 
per nativo qualcosa di compilato in codice direttamente eseguibile dal 
processore della macchina di destinazione e non qualcosa che viene 
tradotto a runtime (vedi Java). Python non lo conosco quindi l'esempio 
che mi fai non l'afferro.
Ad ogni modo tutti i linguaggi interpretati sono irrimediabilmente più 
lenti di quelli compilati dato che c'è un passo in più da fare a runtime 
(vedi Java).
Ciao,
ReX

 (vedi Java).
Errore: con le migliori JVM JIT, esistono gia` oggi esempi di perfomance
di applicazioni Java superiori a quelle di applicazioni analoghe in C o
Objective C, e il CLR 2.0 di esempi del genere ne ha parecchi.
Traducendo un livello semanticamente intermedio in linguaggio macchina
"just in time", si aprono possibilita` d'ottimizzazione che "ahead of
time" esistono solo in laboratorio (perche` gli ottimizzatori statici
basati sull'intero programma richiedono un tempo che cresce
esponenzialmente colla dimensione del programma, quindi inutili salvo
per programmi-giocattolo da laboratorio).  Con l'eccezione forse di una
piccola utility che debba partire, fare un piccolissimo lavoro, e
terminare subito (nel qual caso il tempo di startup puo` dominare
l'intera operazione), per programmi che una volta partiti girino per
sostanziali quantita` di tempo l'ottimizzazione JIT e` l'idea del futuro
(e sempre piu` spesso ormai, anche del presente), e il JIT funziona
meglio basandosi su codice a livello semantico "altino" (i bytecode
delle varie VM progettate negli ultimi anni sono grosso modo al livello
semantico giusto, anche se l'uso di VM stack-oriented invece che
register-oriented puo` in tutta probabilita` essere un impedimento; su
questi sotto-temi puoi trovare svariatissime opinioni fra i ricercatori
in questo campo).
Le piccolissime utility possono essere fruttuosamente scritte in
linguaggio assembly (se si prevede che vengano poi usate miliardi e
miliardi di volte, ogni volta per breve tempo) o (un piccolo ma
ragionevole compromesso) in C, che e` praticamente un linguaggio
assembly portatile.  I programmi piu` sostanziali, invece, possono
trarre vantaggi crescenti da tecnologie piu` moderne basate su linguaggi
binari intermedi e generazione di codice macchina (e ottimizzazione)
just-in-time.
Ci vorranno probabilmente alcuni decenni perche` questi aspetti
risultino evidenti al profano (o anche solo al praticante praticone)
quanto lo sono gia` da decenni ai ricercatori piu` avanzati, e in tempi
piu` recenti ai praticanti che "tengono un orecchio a terra" e seguono
gli sviluppi delle tecnologie che stanno alla base del nostro lavoro...
Alex

> Quando finalmente Microsoft avrà finito di scrivere Office in .Net...
...già: quando? Magari mi sbaglio ma non mi risulta che, dopo anni di
sviluppo di .NET, ci sia ancora alcun sw maggiore di Microsoft basato
su CLR.
E francamente non ne sento la mancanza. Di una suite Office innovativa
su Mac invece sì... anche solo elementare tipo "Apple Works" ma con
look and feel Cocoa, template ricchi, etc...  insomma un iWorks che
finalmente includa anche spreadsheet e DB.

 in questo campo).
Mi sa che io e te parliamo delle stesse cose con termini differenti...
Il discorso che fai già l'ho sentito per le JVM Hot Spot ma sono pochi i 
casi in cui un programma compilato risulta più lento di uno interpretato.
-- 
Ciao,
ReX

 finalmente includa anche spreadsheet e DB.
Ma chiaramente. L'importante è avere una cosa che funziioni bene. a
tecnologia con cui è scritto è del tutto di scarsa importanza. Certo,
tecnologie che facilitassero la cosa...


 (vedi Java).
E via di luoghi comuni. Questo può anche essere vero allo stato attuale,
ma non è una verità inequivocabile.
Esattamente come oggigiorno il codice C spesso e volentieri batte l'ASM:
un compilatore ottimizzante conosce in dettaglio la dimensione delle
cache del processore, sa come funziona in dettaglio lo stesso, cosa
funziona meglio o peggio.
Può generare codice ottimizzato per ogni processore. Il programmatore
ASM invece può farlo per un solo processore per volta. Alcune tipologie
di algoritmi sono facilmente ottimizzabili in ASM (tipo gli algoritmi
numerici), ma le subroutine in generale no: dove entra gestione della
memoria e tutto, lavorare in un linguaggio di più alto livello fa si che
il codice sia meglio ottimizzabile a livello logico.
Di recente su iclp era stato postato un esempio particolarmente cretino
in cui, a meno di non conoscere *in dettaglio* il funzionamento della
STL e di smazzarsi per bene, il codice "ingenuo" scritto in Python era
di ordini di grandezza più svelto.
Questo è particolarmente divertente in quanto Python per ora fra i
linguaggi interpretati non è certo il più veloce (Java tipicamente lo è
molto di più, C# pure -- d'altra parte Python è un linguaggio di livello
estremamente più alto).
Tornando a noi... un compilatore JIT conosce la macchina esatta per la
quale sta lavorando, conosce dettagli specifici che a compile time non
erano noti, sa come può usare la memoria. La maggior parte degli esperti
concordano: la compilazione JIT nel caso medio sorpasserà quella
specifica.


 casi in cui un programma compilato risulta più lento di uno interpretato.
E questo lo rende meno "nativo"? Quindi un programma scritto usando
algoritmi lenti e sprecando memoria non è "nativo"?
E RealBasic? Compilare compila. Purtroppo spesso e volentieri è poco più
veloce di Python e parecchio più lento di Java.
Se poi in Python si usano librerie apposta (per computazioni numeriche
-- io sono arrivato a Numeric... adesso c'è Numpy che dicono essere
ancora più veloce --) si ottengono performance superiori sicuramente a
quelle di Java, e sovente superiori a quelle di C++.
Quindi Python diventa nativo quando fa codice numerico?


 del tutto naive del termine.
...ovvero un uso nativo del termine "nativo"! ("naive: from Latin
nativus native...")
Scusa ma l'ho trovato divertente... ;-)

 specifica.
Capirai, il problema non è la memoria (il codice è rilocabile anche se 
compilato), il problema vero è nelle applicazioni dinamiche, che 
caricano a runtime classi dell'OS o di terze parti non disponibili a 
compiletime.
-- 
Ciao,
ReX

 compiletime.
Ma questo non centra nulla con essere o meno compilato. Il punto chiave
è che un compilatore JIT ha informazioni che un compilatore tradizionale
non ha. Usandole, può raggiungere performance comparabili o addirittura
superiori nel codice applicativo standard.
Il problema di caricare o meno a runtime codice eseguibile (sia esso
classi o funzioni) non è legato *affatto* ad essere compilato o
bytecompilato o addirittura interpretato linea per linea.


 Scusa ma l'ho trovato divertente... ;-)
Confesso che speravo che qualcuno cogliesse :)


 tecnologie che facilitassero la cosa...
Beh, Java e C# dovrebbero appunto essere tecnologie del genere (come le
JVM e CLR su cui poggiano), e ancora di piu` dovrebbero esserlo altre
come Python, Ruby, Boo... ma sinche` una frazione importante del mercato
dimostra istintive reazioni negative basate puramente sulle tecnologie
usate per l'implementazione (come dimostra ad esempio l'atteggiamento di
ReX, che non chiede specifiche feature, o prestazioni, ma si accentra
invece totalmente sul "compilato e non interpretato", cioe` puri aspetti
tecnologici di implementazione), puo` essere saggio (triste, ma saggio)
per un'azienda evitare rischi di percezioni negative, sviluppando
soluzioni meno ricche e complete ma basate su tecnologie piu` vecchie e
tradizionali.
Questo appare particolarmente triste a un ingegnere, che per carattere e
formazione vorrebbe risolvere problemi REALI (e preferisce usare le
tecnologie *giuste* da un punto di vista puramente tecnico), ma
giustamente le aziende hanno anche un _marketing_, che sa tenere conto
anche dei desideri e delle paure del mercato (non meno reali per il puro
fatto di essere "tecnicamente ingiustificati" o basati su esperienze
negative con versioni ormai vecchie e sorpassate di dette tecnologie:-).
Alex

, altro paper del
1994 di Hölzle e Ungar su SELF-93 (si usano molteplici compilatori: uno
che fa codice "alla buona" ma gira molto in fretta, uno altamente
ottimizzante che gira "in background" e viene selettivamente applicato
solo agli "hot spot" identificati adattivamente e JIT).  Ma naturalmente
queste tecnologie sarebbero rigettate da chi preferisce la tecnologia
del 1954 (Fortran I, primo compilatore ottimizzante che generava codice
macchina, ovviamente AOT, ma molto efficiente;-).
Alex
 

 per le ultime versioni dei processori delle maggiori case produttrici.
E la cosa curiosa e` questa: fra le migliori distro di Linux, allo
stesso costo (zero), puoi sceglierne una "compilata AOT" per processori
abbastanza generici (386, addirittura; 586 o 686 se sei molto fortunato;
nessuna "finely tuned" per quel particolare modello e stepping level con
quella certa precisa quantita` e qualita` di caching e pipelines...!-),
_O_ una orientata al bootstrapping (praticamente tutto viene "mirato" e
iperottimizzato per lo specifico processore e sistema che hai TU).
Quanti di questi ultrapatiti dell'ottimizzazione specializzata a tutti i
costi, se usano Linux, scelgono quindi Gentoo (la distro basata sul
bootstrapping &c) invece di, che so, Debian o Ubuntu (per non dire di
Suse, Mandriva, Fedora e via elencando)...?  Risposta: pochi %.  La
comodita` del binario "sufficientemente generico" evidentemente la fa da
padrone rispetto alle prestazioni frazionalmente superiori... ma con il
vincolo di ripartire a ottimizzare a ogni cambiamento di configurazione
del sistema (piu` specializzi e ottimizzi il codice per una specifica
particolare configurazione, piu` problemi potresti avere a portarlo pari
pari su configurazioni anche solo "un pochetto" diverse, mentre quello
sufficientemente generico "benazzo o malazzo va" piu` o meno alla stessa
maniera su di un'ampia gamma di configurazioni).
_In pratica_, l'ottimizzazione molto specifica di grosse applicazioni
per particolari configurazioni di HW si fa rarissimamente... solo la
generazione dinamica di codice puo` rendere pratica questa idea (grazie
al fatto che l'ottimizzazione molto specifica ne risulta totalmente
automatizzata e "trasparente" nell'uso quotidiano).
Alex
 

 automatizzata e "trasparente" nell'uso quotidiano).
Esatto. Oltre al fatto che l'ottimizzazione dinamica è comunque
potenzialmente più efficace. 
Pensa che in pochi sanno (e ancora meno usano) che per esempio con MacOS
X e PPC (su intel non ho controllato) è possibile dare al processore
indicazioni di massima sul branching. E queste sono tutte cose che
potenzialmente velocizzano il tutto. Ma che nessuno fa...
Poi aggiungiamo che la maggior parte delle applicazioni dal punto di
vista del processore per la maggior parte del tempo non fanno *nulla*
(adesso ho un core al 10% e un all 8%, se fossero al 50% perchè sotto mi
stanno ottimizzando qualche applicazione, non mi darebbe proprio alcun
fastidio... poi se la tecnica prende piede, non vedo nemmeno in ottica
desktop problemi concettuali ad usare meccanismi di caching per il
codice JIT generato....)


 negative con versioni ormai vecchie e sorpassate di dette tecnologie:-).
Direi non solo ad un ingegnere. Penso ad un qualunque *tecnico* di
settore.


 
http://eric.bachard.free.fr/news/
ma è uscito?

 ma è uscito?
non esceeeee
si parla di una alpha con dentro 'quello che ci sarà' solo nel febbraio 2007
-- 
http://loscimmiotto.splinder.com/