OpenGL 4.1 in arrivo

[Amiga Supremo]

Veramente spiegatemelo

Come ho scritto pocanzi, AOS è un prodotto commerciale.

[ikir]

Questo è vero, concordo.
Però AMIGA lo spegne ugualmente per WINDOWS (o meglio neanche lo compera), se la prospettiva è che il bellissimo sw perfettamente integrato nel suo OS preferito, è identico a quello che potrebbe utilizzare su altre piattaforme, dove tra l'altro gira pure meglio ma ad un costo inferiore.
Dietro al OS c'è una azienda commerciale; cominci a finirlo degnamente e già un bel balzo in avanti l'avremo fatto!

E quindi la soluzione? Qualcuno me la spieghi perchè io non la ho.
Adesso abbiamo che per scrivere un software devi fare tutto a mano quando negli altri OS da decenni usano degli editor grafici. Non possiamo sfruttare delle veloci compilazioni di librerie prese da altri os perchè altrimenti non sono amiga-like e quindi dobbiamo convertirle. Non posso usare Python come motore di scripting perchè non è ARexx.
Mi spiegate uno sviluppatore che ha un buon software su akltre piattafrome e volesse portarlo su OS4/MOS che deve fare? Deve spendere mesi (=soldi) per capire come fare a convertire il tutto? E per cosa? Per una base di utenti che va da 10 a 1000?
Veramente spiegatemelo

Concordissimo! Progresso per favore e meno pare mentali.

[afxgroup]

Come ho scritto pocanzi, AOS è un prodotto commerciale.

E beh? Anche Windows è un prodotto commerciale. Cosa signifca? Che la Microsoft deve fare il software per tutti?

[divina]

Vabbè buttiamo tutti OS4 e passiamo a MorphOS, è questo il concetto ?

Mah ..

@Divina

Si ma come si apre sto eMac ?

concetto afferrato bravo

Lo giri, togli qualche vite, e lateralmente le altre, poi "esce" come un guscio, cmq dato che devi solo installare la ram apri semplicemente lo sportello sul retro (quello con una sola vite, lì trovi i due slot ram).
Per l' HD devi invece aprire il "guscio" (ti consiglio una guida, tutorial online per questa operazione, un po' più laboriosa, se hai problemi te ne cerco una).

[divina]

Diciamo che MOS ha spiccato il volo mentre e OS4 si è incartato . Oltre tutto si sta pensando di progettare delle Ferrari, mentre il software rimane al palo.
Spero che non ci troveremo con un'astronave che trascina un aratro.

speriamo si sveglino un po'

[samo79]

concetto afferrato bravo

Mah ...

Lo giri, togli qualche vite, e lateralmente le altre, poi "esce" come un guscio, cmq dato che devi solo installare la ram apri semplicemente lo sportello sul retro (quello con una sola vite, lì trovi i due slot ram).
Per l' HD devi invece aprire il "guscio" (ti consiglio una guida, tutorial online per questa operazione, un po' più laboriosa, se hai problemi te ne cerco una).

Ti rispondo di la

[divina]

concetto afferrato bravo

Mah ...

[esketos]

E quindi la soluzione? Qualcuno me la spieghi perchè io non la ho.

La soluzione potrebbe essere la costituzione di una bella "cooperativa" di sviluppatori che lavorano assieme per creare qualcosa di buono su AMIGA (per tutte e tre le distribuzioni). Una volta prodotto del software che sia degno di essere chiamato tale scegliere se distribuirlo gratuitamente o richiedere un contributo (non un pagamento) per supportare altri progetti.

Aspè... scusate... stavo citando il sogno che ho fatto stanotte

[Tuxedo]

...benvenuto nel club dei sognatori/utopici... :P

[ShInKurO]

Te l'ho detto.. tutti vorrebbero che Arexx fosse migliorato. Il problema è che non si puo'. Perchè non ci sono i sorgenti. Te lo riscrivi tu da zero?

A parte che su MorphOS l'hanno fatto... ma vabbè.
Cmq io concordo con cdmauro, nel senso che a me non interessa ARexx in quanto REXX, ma in quanto AmigaRexx. Quando Python sarà integrato come AmigaRexx su AmigaOS4 allora si potrà considerare una reale alternativa ad ARexx. Al momento è solo un linguaggio con cui puoi scrivere programmi su OS4. Spero di essermi spiegato

[afxgroup]

A parte che su MorphOS l'hanno fatto... ma vabbè.

C'è un bel post in un'altra area del sito.. dice che MOS compie dieci anni.... E comunque di implementazioni Rexx in giro ce ne sono.. non vi costa nulla prenderle e fare il vostro RexxMast bello nuovo e fiammante..

[ShInKurO]

E allora mi dici che differenza c'è tra le due? Che in una hai la tabella fatta in un modo e nell'altra no?

La spiegazione l'ha data già cdmauro, io invece ti espongo il mio pensiero più chiaramente riguardo cosa sono le librerie Amiga e gli shared object:

Il concetto di libreria nativa su AmigaOS è quello di avere una serie di funzioni condivise in memoria accessibili da tutti i programmi che ne vogliono fare uso senza ricaricare ogni volta il codice e occupare per ciascuna esecuzione altra memoria.
Questa soluzione è affascinante, ma comporta problemi nel momento in cui si ha una versione di libreria in memoria che è bacata, o quando si richiede una versione differente della libreria che sta in memoria, e quella corrente non può essere smontata perchè è attualmente utilizzata da un altro programma.

Il concetto di shared object è quello di avere un insieme di funzioni caricate dal programma che ne richiede l'uso, senza condividerle con altri programmi, che a loro volta dovranno caricarsi la loro copia di libreria in memoria. Pessimo tempo nel caricamento, occupazione della memoria con crescita lineare. MA: ogni programma sta al suo posto con la sua bella versioncina di libreria che non dà fastidio a nessuno.

L'ideale sarebbe quello di far evolvere le librerie Amiga in modo tale che su richiesta possano coesistere più versioni della stessa libreria in memoria. Questo è quello a cui in teoria potrebbero servire le interfacce nelle librerie AmigaOS4.

Un altro problema è il fatto che se un programma crasha, in molti casi si porta giù anche la libreria, la quale rimane in memoria, ma non può essere utilizzata da altri programmi. Ovviamente gli shared object non hanno questo problema.
La soluzione è quella di permettere lo "smontaggio" di librerie Amiga caricate da programmi che hanno crashato nel caso queste risultino inaccessibili da altri programmi. In pratica è il Resource Tracking.

Dunque risolti questi problemi sulle librerie Amiga non ritengo necessario preferire l'uso di shared object alle librerie Amiga, se non come mezzo per fare porting più velocemente. Una volta portato il programma però dovrebbe essere amighizzato (tutti i porting, altrimenti è inutile), e cioè questi sb dovrebbero essere convertiti in librerie Amiga, e il programma dovrebbe accedere a questa nuova versione, in modo che ottenga tutti i vantaggi di AmigaOS.

Questo è il quadro che mi sono fatto della situazione. Gli shared object in quanto tali non sono un'evoluzione per AmigaOS, bensì sono un'involuzione per il nostro sistema, che però permette un più semplice porting di programmi da altre piattaforme.
In altre parole hanno tutto il mio appoggio per porting preliminari, ma li disdegno se vengono messi allo stesso livello delle librerie Amiga. In pratica gli shared object in quest'ultimo caso sarebbero solo un palliativo per un sistema che non ha saputo implementare un buon tracciamento delle risorse e non ha saputo migliorare le proprie librerie.

No significa portabilità. E riusabilità del codice. Perchè visto che abbiamo la possibilità di sfruttare software preso da altre piattaforme dobbiamo reinventarci la ruota o aggiungere dei pezzi di codice solo per dire "noi abbiamo le librerie in formato amiga like" che alla fine fanno la stessa cosa.
cioè se vedo un libSDL.so mi vengono i brividi e se invece vedo PowerSDL.library allora sono felice.. Poi che facciano entrambi la stessa non mi interessa nulla.

Fanno le stesse cose, ma in modo differente: la libreria amiga viene caricata in memoria una volta sola e condivisa dai programmi, lo shared object invece dà una sezione locale di dati ad ogni programma che ne fa uso, dunque n programmi n shared object in memoria. Concetto totalmente alieno ai concetti alla base di AmigaOS.
Se A RICHIESTA si ottenesse una cosa simile dalle librerie Amiga in modo trasparente allora sarebbe bello, ma spingere i programmatori Amiga di terze parti verso gli shared object è il suicidio di AmigaOS.

Infatti quando su OSX c'era l'1% del software che hanno oggi hanno portato X11 e nessuno si è scandalizzato. Ed hanno avuto software come OpenOffice che oggi noi sogniamo di avere in nativo (la versione per bimbi naturalmente) con una bellissima e funzionalissima interfaccia MUI

A parte che X11 su OSX è molto più integrato al sistema di quello che abbiamo noi.
Ma cmq non è che la gente si è fossilizzata sui porting X11 senza usare la roba nativa. Anche Firefox prima girava su X11, poi è stato portato "nativo", la stessa cosa sta avvenendo con OpenOffice.
Su AmigaOS4 invece ci si fossilizza, e anzi si favorisce questa fossilizzazione, non è una buona cosa.

E cosa centra il fatto di programmare MUI con le shared object?

C'entra, perchè se programmo su Amiga, se dovrò crearmi una libreria da zero allora implementerò una libreria Amiga, non uno shared object. Non so se mi sono spiegato.
Se chi sviluppa l'OS mi spinge invece a creare shared object allora mi domando perchè debba fare una cosa simile su Amiga quando su Linux avrei maggiore supporto per questa tecnologia.

Forse non ti è chiaro il fatto che MUI4 non lo avrai mai su OS4 perchè altrimenti quelli di MUI ammazzano lo sviluppatore? Vuoi programmare MUI4? O vai su MOS oppure aspetti che qualche gruppo di programmatori si faccia il mazzo per far si che Zune abbia tutte le API di MUI4 e poi ti fai un bel porting su OS4.
Io ti consiglio la prima strada.. Intanto io mi divertirò a programmare con Reaction che nonostante quello che pensi tu mi diverte. Anche se le cose non vengono fatte a livello scolastico/universitario come magari vengono fatte con MUI

Ma infatti se la situazione non cambia passerò di certo a MorphOS, del resto a me non piace creare interfacce utente in stile anni '90 perchè il framework a disposizione manca di caratteristiche moderne... De gustibus...

Questo valeva nel 1985 e ancora non era stato inventato (/copiato) tutto..

A me non pare che si utilizzi OSX come si maneggi Windows. Confondi la standardizzazione dell'usabilità/delle tecnologie nei sistemi con la mera copia, non è così. Ci sono tante cose che negli anni sono diventate standard, e la gente è abituata a usare le cose in un certo modo, o sapere che sotto le interfacce utente ci sono certe cose. Poi c'è un'altra parte, la quale invece caratterizza ciascun sistema in modo unico. AmigaOS4 sta perdendo questa seconda parte per inseguire la prima.
Se tutti i sistemi non avessero la propria unicità (che sia riguardante l'usabilità o le API) non ci sarebbe alcun motivo per preferire un sistema a un altro.

Devo proporre ai Friedens e al gruppo di Adtools di cambiare l'estensione standard delle librerie da .so a .library. Così su Windows avremo .dll, su unix .so e su OS4 .library.. Che poi facciano tutte le stesse cose.. beh amen.

Il concetto di shared object non cambia mica se cambi l'estensione...o è la prossima evoluzione AmigaOS4 quella di diventare dipendente dalle estensioni?

[cdimauro]

A mio avviso si dovrebbe superare la limitazione delle librerie dell'Amiga, e introdurre un concetto simile a quello delle shared library di altri s.o..

Questo non significherebbe perdere l'identità che ha sempre contraddistinto l'Amiga e le sue librerie standard.

Semplicemente le librerie standard permettono di eseguire codice "puro", e ciò pone dei grossi limiti. Intendo come strumento a disposizione dei programmatori.

Limiti che si potrebbero superare con uno strumento più aggiornato, appunto. Ma rimanendo sempre nell'ambito AmigaOS.

A naso dico che è fattibile, retrocompabile, e ho pure qualche idea a riguardo.

Non sono d'accordo, invece, sul fatto di poter utilizzare più versioni della stessa libreria. Ricadiamo nel famigerato "dll hell", e la soluzione che ha proposto Microsoft dopo XP, ossia quella di tenere una copia locale di ogni libreria, non mi è mai piaciuta.

Uno dei vantaggi dell'AmigaOS che ho sempre apprezzato è stato quello di avere una sola libreria che esponeva delle precise API. Libreria che era retrocompatibile, appunto, visto che al più si aggiungevano API nuove, oppure si utilizzavano flag di registri / strutture che erano inutilizzati e riservati.

Sì, ci sono problemi dovuti a bug che si trascinano per tutte le applicazioni. I bug, però, non sono la prassi, ma l'eccezione. E vanno corretti...

[divina]

@ShInKurO

tutto chiarissimo e spiegato in modo perfetto, anche per chi come me conosce poco della programmazione lato AmigaOS; emerge in modo chiaro che non c'è base e poca testa nella progettazione attuale di AmigaOS4, ma di questo me ne sono accorto già da tempo senza troppa fatica, preferisco MorphOS perchè in tal senso è molto più lineare e coerente e la linea guida c'è ed è pure più innovativo ... piano piano ma i tasselli entrano in modo logico

ciao

[ShInKurO]

Non sono d'accordo, invece, sul fatto di poter utilizzare più versioni della stessa libreria. Ricadiamo nel famigerato "dll hell", e la soluzione che ha proposto Microsoft dopo XP, ossia quella di tenere una copia locale di ogni libreria, non mi è mai piaciuta.

La scelta è già stata presa ai tempi di OS4.0, anche se l'idea iniziale era quella di utilizzare questo espediente per implementare una sorta di memoria protetta, ma che è naufragato in favore di una prossima implementazione standard di questa caratteristica.
Parafrasando la mia guida:

AmigaOS4 introduce dei cambiamenti per ciò che concerne l'accesso alle
funzioni di una libreria. Nel paragrafo precedente avevamo appreso come
un programma, per accedere alle funzioni contenute all'interno di una
libreria, debba prima ottenere accesso alla Base della libreria.
Attraverso la Base il programma acquisisce quindi la possibilità di
accedere alla tavola delle funzioni della libreria corrispondente. Su
AmigaOS4 è stato introdotta una nuova versione di librerie condivise, le
quali supportano più tavole delle funzioni, queste ultime vengono
chiamate "interfacce". Su AmigaOS4 non è dunque possibile accedere
direttamente a delle funzioni di una libreria solo aprendo quest'ultima
con OpenLibrary(), bisognerà esplicitare prima quale interfaccia
contiene le funzioni cui noi ci riferiremo. Le funzioni base di una
libreria sono puntate quasi sempre dall'interfaccia "main", su OS4 anche
le funzioni delle API di AmigaOS3.x sono accessibili da tale interfaccia.
Dunque mentre su AmigaOS3.x è bastato avere accesso alla Base di una funzione
attraverso OpenLibrary(), su AmigaOS4 bisognerà anche richiedere
l'accesso ad un'interfaccia della libreria, nel nostro caso "main". Per
ottenere tutto questo sono presenti in ExecSG (il nuovo kernel di
AmigaOS4) due nuove funzioni, chiamate GetInterface() e DropInterface(),
utilizzate rispettivamente per aprire e chiudere un'interfaccia.