Newsgroup: it.comp.os.amiga
Titolo: Intent: la GUI dei nuovi Amiga

TAO ha recentemente presentato un video, purtoppo non l'ho visto ne so
dove andare a pescarlo (mi pare fosse uno stream), pero' un tipo che
l'ha visto ha fatto alcuni grab (di bassa qualita') e li ha pubblicati
su questo sito: 
http://members.home.net/kovu401/intent.htm
Mi piacerebbe vedere tutto il video ma le finestre trasparenti che si
vedono qui [anzi, che non si vedono ;-) ]sembrano alquanto
interessanti. Il tipo in questione dice che non c'era alcun
rallentamento.
Luca
------
To reply remove "nojunk" from 
gdi...@hpu.nojunk.edu
http://www.geocities.com/SouthBeach/Canal/3184
 (Under Construction)
Sent via Deja.com 
http://www.deja.com/
Before you buy.

 uniformemente o a scatti).
A scatti, vedendolo molto rallentato ed ingrandito oscenamente...non so se
sia così di natura o per il frameskip... :-/
Ed intanto il materiale per sviluppatori non s'è visto...
--
Nii hao!
Giuseppe Gigante
Remove #nopub#to answer   mailto:
wexdg...@tin.it
  Togli #nopub# per
rispondere
mailto:
wexdg...@libero.it
"640Kb ought to be enough" Bill Gates 1981
"Non posso essermi ridotto così" Ranma Saotome 1996
ODIO LA GRAFICA ANSI!!!

 Ed intanto il materiale per sviluppatori non s'è visto...
Come dicono di solito i proprietari di amiga di turno "ancora due
settimane..." :)

 Unite for Java - Join the Java Lobby now! (
http://www.javalobby.org
)     <
============================================================================

 settimane..." :)
Io aspetto da un anno ormai, e conosco un amico, Guly, che mi ha fatto
conoscere l'amiga, che l'aspetta da 7 anni...
--
Nii hao!
Giuseppe Gigante
Remove #nopub#to answer   mailto:
wexdg...@tin.it
  Togli #nopub# per
rispondere
mailto:
wexdg...@libero.it
"640Kb ought to be enough" Bill Gates 1981
"Non posso essermi ridotto cosě" Ranma Saotome 1996
ODIO LA GRAFICA ANSI!!!

 ovvero non garantiscono l'eseguibilita' su tutte le JVM.
Ma questo caso e' praticamente tragico: un conto e' proteggere il codice, un
conto e' che questo gira solo piu' su Windows con IE. Allora potevano usare
un ActiveX invece che java...

 conoscere l'amiga, che l'aspetta da 7 anni...
Io aspetto dal 92, dopo la mostruosa delusione causata da A1200 e A4000.

[...] non garantiscono l'eseguibilita' su tutte le JVM.
 Perň su IE di *Microsoft* e WinNT di *Microsoft* ha funzionato. Eh sě,
Java assicura davvero un mercato piů libero, aperto alle alternative e
multipiattaforma...
Saluti.
--
    _
 Fa/_)io         - Amiga Group Italia -
  /__)enedetti   
http://www.amyresource.it/AGI/
/...entrarono Pompeo e Lepido, in assetto da guerra/

 multipiattaforma...
<standard>
Penso che quelli di Emblaze abbiano sottovalutato il fatto che la applet
decoder avrebbe dovuto girare anche su JVM diverse da quelle "standard di
mercato". E' notorio che le JVM su Linux e FreeBSD sono "strictly
compliant", quindi poco tolleranti a ofuscamenti troppo spinti (eliminazione
di invokevirtual, invokespecial, inline e final-izzazione del codice,
introduzione di caratteri non standard nei marcatori, ecc).
</standard>
Quello che dici, comunque, prescinde dalla portabilita' del Java.
Ti faccio un esempio di logica: se viaggiando in macchina fori una gomma, e'
colpa..
1) della macchina.
2) del chiodo sulla strada.
3) della gomma.
4) del fatto che non hai pagato il bollo.
5) del fatto che hai mangiato troppo e ti sei appesantito.
6) ..
Hai notato che ci sono risposte piu' logiche di altre ?


 un ActiveX invece che java...
<standard>
Penso che quelli di Emblaze abbiano sottovalutato il fatto che la applet
decoder avrebbe dovuto girare anche su JVM diverse da quelle "standard di
mercato". E' notorio che le JVM su Linux e FreeBSD sono "strictly
compliant", quindi poco tolleranti a ofuscamenti troppo spinti (eliminazione
di invokevirtual, invokespecial, inline e final-izzazione del codice,
introduzione di caratteri non standard nei marcatori, ecc).
</standard>
Comunque la scelta di ActiveX mi sembra molto azzardata, visti i noti
problemi di sicurezza. Ormai ActiveX su web lo usano solo i fedeli alla
linea M$ o quelli che non posso scegliere perche' semplicemente non hanno
abbastanza conoscenza per scegliere con serenita'.


 Io aspetto dal 92, dopo la mostruosa delusione causata da A1200 e A4000.
Intendi il superAmiga 3000+, con chip DSP ed SCSI ad alte performance?
--
Nii hao!
Giuseppe Gigante
Remove #nopub#to answer   mailto:
wexdg...@tin.it
  Togli #nopub# per
rispondere
mailto:
wexdg...@libero.it
"640Kb ought to be enough" Bill Gates 1981
"Non posso essermi ridotto così" Ranma Saotome 1996
ODIO LA GRAFICA ANSI!!!

 abbastanza conoscenza per scegliere con serenita'.
Interessante come punto di vista. Fortunatamente non la pensano cosi' la
Apple (QuickTime), la Macromedia (ShockWave), la Real (RealPlayer) e perfino
la SUN (Il JavaPlugin, per usare la JVM sun su IE4.x e 5.x e' proprio --
orrore! -- un ActiveX)!

 ha scritto nel messaggio
news:8096131322268...@news.tin.it...

L' uso di ActiveX e' _NECESSARIO_ per installare e far girare il java plugin
su IE. Si, hai indovinato, serve _solo_ sui prodotti M$: e' una scelta
OBBLIGATA. Per il resto, la tecnologia ActiveX e' rimasta solo un bel sogno
nelle notti di Bill (e nelle tue ?).


5) del fatto che hai mangiato troppo e ti sei appesantito.
Saluti.
--
    _
 Fa/_)io         - Amiga Group Italia -
  /__)enedetti   
http://www.amyresource.it/AGI/
/...ti ho visto dappertutto, anche in fondo al mare/

 non fosse paradossale, sarebbe ridicolo !
Leggiti le ultime sul VisualBasic di M$ (stanno cercando di clonare il java)
e cerca di capire dove vogliono arrivare loro..
Fugurati che SUN, per rimpiazzare la JVM (non standard) di IE hanno dovuto
ricorrere a un controllo ActiveX. Ma perche' SUN ha voluto rimpiazzare la
JVM di IE ? Semplice, proprio per evitare quello che hai appena descritto.


 Intendi il superAmiga 3000+, con chip DSP ed SCSI ad alte performance?
Gia'. E anche il fatto che quando aga e' uscito gia' faticava ad andare in
pari con quello che gia' c'era in giro... 

 nelle notti di Bill (e nelle tue ?).
No il fatto e' che ActiveX e' basato su eseguibili NATIVI per WIN32; quindi
e' abbastanza ovvio che sia "rimasto" solo su windows...
Il discorso che si faceva, comunque non era sui meriti di ActiveX o di Java
(anche perche' siccome uso un amiga, non posso utilizzare ne' l'uno ne'
l'altro), ma sul fatto che il player di streaming video (quello che mostrava
la GUI di Elate) scritto in Java aveva qualche bizzarra particolarita' per
cui funzionava solo su IE e SOLO su Windows; da quella considerazione era
nato il commento che *A QUEL PUNTO* tanto valeva un ActiveX...

 JVM di IE ? Semplice, proprio per evitare quello che hai appena descritto.
E' bello il fatto che in realta' la JVM fornita con IE e' il risultato della
causa SUN vs MicroSoft; quindi e' sufficientemente standard da accontentare
tutti i requirement imposti dalla SUN medesima durante il processo. 
Pero' la sun sa che le sue specifiche di Java non sono complete ne'
esaustive (vedasi la farsa multiplamente perpetrata riguardante la
standardizzazione ANSI di Java). Il che vuol dire che se uno prende le
specifiche (CHE SUN VENDE) per produrre una JVM da zero e' CONDANNATO a
produrre una versione incompleta ed incompatibile  -- poi figuriamoci se la
gente se ne esce con prodotti che usano gli effetti collaterali o le
funzioni non documentate: chi garantisce che un dato comportamento non sia
il risultato di qualche scorciatoia presa dall'ottimizzatore quando e' stata
compilata la JVM su una certa piattaforma? E chi garantisce che cambiando
una riga nel codice questa funzione rimarra'? E chi garantisce che la
prossima versione del super compilatore JIT non spacchera' tutto?

 prossima versione del super compilatore JIT non spacchera' tutto?
Il set di istruzioni del bytecode di JAVA e le specifiche del linguaggio
sono, a dir poco, lapidarie.
Pensa solo a quanti compilatori ed intepreti java ci sono in giro, sia PD
che commerciali.
Certo che se prendi uno Z80 e lo programmi in asm 6502 non puoi pretendere
che tutto funzioni a meraviglia e soprattutto non puoi dare la colpa allo
Z80.
Una JVM deve necessariamente seguire le specifiche alla lettera, cosi' come
il bytecode compilato da qualsiasi compilatore java deve essere
perfettamente aderente alle specifiche. Solo in questo modo si possono
costruire JVM sicure e funzionanti, magari ottimizzate e/o adattate a
compiti precisi.
Gli esempi di TAO-Group o di HotSpot la dicono lunga. Tao ha riscritto una
JVM JIT ottimizzata, Sun ha scritto HotSpot, una JVM auto-ottimizzante a
runtime, poi c'e' IBM, con la piu' veloce JVM sul mercato (e' free), poi
Kaffe, poi TowerJ, poi Symantec, poi Apple, poi Caldera, ... E figurati che
lo stesso bytecode gira _senza modifiche_ su tutte.


 lo stesso bytecode gira _senza modifiche_ su tutte.
Allora perche' e' possibile scrivere un offuscatore di java che rende il
codice eseguibile solo su
una JVM e non su un'altra????? E non stiamo parlando di un caso ipotetico,
anzi la discussione e' iniziata proprio dal fatto che del codice java gira
effettivamente solo su una piattaforma; ti diro' che non e' neanche un caso
raro...

 pari con quello che gia' c'era in giro...
L'AGA è controversa. C'è chi dice che è un capolavoro di retrocompatibilità,
e c'è chi diece ce era obsoleta già allora.
Cmq, oggidì è insopportabile. E mi basta questo.


 raro...
A me funziona tutto, a prescindere dalla JVM e dal S.O. ospite.
Mi ritengo moooolto fortunato..


 Mi ritengo moooolto fortunato..
Dipende moltissimo dalle applicazioni, comunque. Io ho avuto esperienze
buone ma anche esperienze tragiche... La media finale e' ancora ampiamente
negativa...

 negativa...
Solo per te... Io faccio girare 600kb di classi (mie, e non faccio cose
semplicine, utilizzo a fondo il multithreading interno di java, la
sincronizzazione, la gestione dei files, la grafica, swing, ecc.), piu'
qualche altro megabyte di classi Sun e di terze parti su diverse JVM e
diversi OS senza problemi. E il resto del mondo che usa java come me ? Siamo
tutti piu' ganzi di te ? Forse si..
Ma poi che te ne fai tu del Java ? Ci sono tanti altri ambienti operativi,
tanti linguaggi cosi' ottimizzati, funzionali, facili, simpatici, snelli e
potenti. Puoi scegliere, quindi ritieniti libero da ogni impegno e lascia il
java a chi lo usa e a chi lo vuole usare.


 java a chi lo usa e a chi lo vuole usare.
Purtroppo io non ci gioco, ma ci lavoro; quindi NON posso scegliere ne'
l'ambiente ne gli strumenti di sviluppo nella stragrande maggioranza dei
casi, perche' li ha gia' scelti il cliente con criteri suoi; ti garantisco
che un ambiente di sviluppo universale DAVVERO solido e funzionale sarebbe
una benedizione per tutte queste attivita' che spaziano da WinNT a Solarix a
HP-UX... ma i risultati sono ancora deludenti. Peccato.

 l'ambiente ne' ...
Siamo in due. Io ho scelto e mi ritengo molto soddisfatto (anche se la
perfezione e' pura utopia).
Se tu avessi avuto la facolta' di scegliere, cosa avresti usato ?


 Se tu avessi avuto la facolta' di scegliere, cosa avresti usato ?
Nei due casi descritti, alla fine l'utente usa solo Win32: nel caso della
telediagnosi perche' non ha scelta, nel caso del database multimediale
perche' tutti gli utenti e documentatori hanno solo windows. Per
l'applicazione di telediagnosi abbiamo lavorato MESI, eppure con un paio di
ocx e visualbasic ci sarebbe voluta una settimana... In ogni caso i miei
linguaggi favoriti sono il Perl e il C++; per Win32 la Borland produce uno
dei migliori ambienti di sviluppo C++ esistenti: il C++Builder, che riesce
ad unire il vero sviluppo visuale ideale per il prototyping e le
applicazioni RAD con un compilatore in grado di coprire almeno all'ottanta
percento le necessita' di sviluppo su windows. Su amiga, invece, le
alternative sono molte meno, comunque uso il SAS/C, anche perche' gli altri
compilatori sono o schifezze vergognose e piene di bug vendute a 3 volte il
loro valore (StormC) oppure pietose conversioni da unix che offendono lo
spirito medesimo di sviluppare su amiga... si parlo di gnuC e del grupo ADE
-- se volevo unix, mi prendevo un *BSD o linux -- il fatto che io abbia un
amiga implica che lo voglio usare come tale e non come una brutta copia di
un unixoide.

 un unixoide.
Perchè? Cos'ha che non va il gcc? :/
Saluti,
Fabio Alemagna



Lui in se nulla. Il fatto e' che non e' il GCC che si adatta alla
piattaforma, ma la piattaforma che deve adeguarsi (vedi ixemul.library su
amiga e cygwin.dll su win32). I tool di ade su amiga sono arrivati al punto
che non riesco neanche ad eseguirli se non uso la loro shell unix-like; poi
i programmi compilati con gcc tendono ad avere miti richieste tipo "stack
400000" (non so se e' per via della natura unix dei programmi in questione
-- in unix lo stack e' "gratis" o se e' perche la funzione alloca() della
libreria gcc alloca DAVVERO la roba nello stack)... come detto se voglio
unix posso usarmi unix davvero e non "fare finta" su Amiga. A parte che il
backend del GCC per 68k e' sottosviluppato a dire poco...

 400000" (non so se e' per via della natura unix dei programmi in questione
Mi serve sempre un esempio... Non vedo nessuna spiegazione tecnica
"generale" per quello che hai scritto.
Saluti,
Fabio Alemagna

 "generale" per quello che hai scritto.
Spiegazione tecnica generale:
Su unix e' normale scrivere:
void faiqualcosa(void) {
char buffer[30000];
    <qualcosa>;
}
perche' lo stack viene allocato al volo; su amiga una cosa simile invece e'
anormale: lo stack di default e' 4k (e normalmente non e' dinamico).
inoltre il gcc usa una particolare funzione builtin che si chiama alloca():
la funzione in questione serve per allocare memoria "temporanea" che si
disalloca da sola all'uscita della funzione in cui e' stata allocata; su
molte architetture questa operazione viene effettuata muovendo lo stackframe
della funzione in esecuzione (ovvero facendo crescere lo stack). Su amiga
non so come viene implementata, ma potrebbe essere la spiegazione all'uso di
stack anormale dei programmi scritti su gcc...
Per programmi che hanno questo genere di richieste basta fare un giro per
aminet; il medesimo gcc suggerisce di mettere 300000 come stack; l'utility
'ar' per le librerie richiede 200000 come stack per qualunque operazione non
banale.

 banale.
l'utility ar serve solo per gli sviluppatori, non è di nessuna utilità
per l'utente finale.
Saluti,
Fabio Alemagna

 per l'utente finale.
Era un esempio. Anche Doom portato su amiga con gcc usa 200000 di stack.

 Era un esempio. Anche Doom portato su amiga con gcc usa 200000 di stack.
Ma 200K di stack ti creano molti problemi? cmq non sgto qui a
convincerti, non ne ho nè voglia, nè è il mio compito. Siamo di due
opinioni differenti e mi sta bene così.
Ciao,
Fabio Alemagna

 opinioni differenti e mi sta bene così.
Si, e' un problema: la gran parte degli amiga ha 16 mega di memoria o anche
meno; non mi sta male che un programma usi memoria se gli serve; ma lo stack
sugli amiga e' allocato staticamente e non puo' essere swappato (se usi un
software di memoria virtuale, ovviamente), quindi se devo dare mezzo mega di
stack ad ogni applicazione, mi brucio tutta la memoria in un attimo, e
potrebbe essere memoria che l'applicazione usa una volta per secolo...