Apple conferma Mac Os X 10.5 "Leopard" per il mese di Ottobre

[Asterion]

Originariamente inviato da Criceto

Non si sa nulla. Ma hanno tolto il "brushed metal" dalle finestre del Finder delle ultime beta... Mi sembra più che altro un passo indietro.

A me sto brushed metal non piaceva proprio

[s0r4]

Originariamente inviato da MenageZero

che volete che siano 3-4 mesi in +, anzi vorrà dire qualche release-bug in meno

veramente stanno ritardando perchè ci lavora meno gente, non perchè vogliono prendersi tutto il tempo e far uscire un prodotto più maturo di quello che sarebbe stato senza ritardo

[^TiGeRShArK^]

Originariamente inviato da Criceto

E perchè non Java allora?

Solo che ci sono (almeno) 3 differenze:
1. non servono nuove API (e perfino liguaggi!) riscritti da zero per utilizzarlo (basta una ricompilata del sorgente che girava sull'attuale GCC 4);
2. Permette di eseguire il codice su processori differenti e perfino sui cellullari (vedrai sull'iPhone...)!!
2a. In particolare il codice potrà girare sia a 32 che a 64 bit! (windows necessita addirittura di 2 versioni dell'OS differenti)
3. Il codice sarà più VELOCE che con il vecchio sistema

A me sembra abbastanza più avanzato!

ma va?
http://forum.nokia.com/main/market_s.../appforge.html

Quindi il .Net non gira sui cellulari?
dillo alla nokia che hanno sbagliato a scrivere sul loro sito
Per quanto riguarda le altre 3 caratteristiche dovresti ben sapere che .Net le supporta da una vita
Ma è vero..
è sempre la MS a copiare
ah..
e ancora non mi viene in mente perchè sono necessari dei nuovi linguaggi per sfruttare il .Net dato che vi gira anche Cobol volendo

[Kenny Rullo]

Originariamente inviato da Asterion

A me sto brushed metal non piaceva proprio

Infatti han pensato bene di reintrodurlo nell'ultima build rilasciata l'altra sera.
http://www.macrumors.com/2007/04/12/...rd-seed-9a410/

Il brushed metal fa proprio schifo, guardate come stona in mail.

Mi ricorda il "bianco-gessato" delle prime versioni di osx, una pena. Quasi lo preferisco nero come si paventava tempo addietro...

[Asterion]

Originariamente inviato da Kenny Rullo

Infatti han pensato bene di reintrodurlo nell'ultima build rilasciata l'altra sera.
http://www.macrumors.com/2007/04/12/...rd-seed-9a410/

Il brushed metal fa proprio schifo, guardate come stona in mail.

Mi ricorda il "bianco-gessato" delle prime versioni di osx, una pena. Quasi lo preferisco nero come si paventava tempo addietro...

Lo stile iTunes insomma... che scandalo non mi piace

[MenageZero]

Originariamente inviato da Criceto

Qui le cantonate le stai prendendo solo tu.

Di Leopard esiterà una sola versione. Che permetterà di eseguire sia applicazioni a 64 che a 32 bit. Molto probabilmente (se useranno l'LLVM) con un solo pseudo-binario.

Inoltre LLVM non necessita di un runtime tipo Java e NET, ma è semplicemente un layer intermedio durante la compilazione. Quindi non c'è nessuna VM (Virtual Machine), tant'è stanno cercando di cambiargli nome per non far ingenerare confusione a chi, come te, si ferma a leggere il titolo.

scusa l'intromissione (non sono attualmente informato su llvm), ma se non c'è un layer di "interpretazione/traduzione/compilazione-JIT/<quel che si vuole>" a runtime, mi sembra di intuire che quantomeno per es codice macchina x64 non potrà girare su una cpu x86, sarebbe quindi una situazione del tutto analoga a quella di win: con cpu ed os x64. possono girare tranqulllamente senza sia app a 32 che a 64 bit (solitamente senza apprezabili penalità per il codice a 32bit), mentre con una cpu x86 possono girare solo os e apps a 32 bit.
no ?

[Criceto]

Originariamente inviato da ^TiGeRShArK^

ma va?
http://forum.nokia.com/main/market_s.../appforge.html

Quindi il .Net non gira sui cellulari?
dillo alla nokia che hanno sbagliato a scrivere sul loro sito

Dimmi il modello così evito di comprarlo per sbaglio!

Originariamente inviato da ^TiGeRShArK^

Per quanto riguarda le altre 3 caratteristiche dovresti ben sapere che .Net le supporta da una vita
Ma è vero..
è sempre la MS a copiare
ah..
e ancora non mi viene in mente perchè sono necessari dei nuovi linguaggi per sfruttare il .Net dato che vi gira anche Cobol volendo

Magari il "Managed Cobol" che sarà incompatibile dal Cobol classico.

4. LLVM non è una Virtual Machine!
5. LLVM non supporta esclusivamente codice managed
6. LLVM supporterà linguaggi SCRIPTING altamente dinamici!
7. LLVM supporterà le SPU del Cell!!!!

Continuo?

.NET è un clone di Java. LLVM è un'altra cosa.

[MenageZero]

Originariamente inviato da s0r4

veramente stanno ritardando perchè ci lavora meno gente, non perchè vogliono prendersi tutto il tempo e far uscire un prodotto più maturo di quello che sarebbe stato senza ritardo

vero, la news dice questo, ma azzarderei che faranno anche in modo che alla fine cmq il bilancio del lavoro di rifinitura e debug sia in attivo per l'uscita ad ottobre rispetto alla abortita uscita a giugno, mica saranno fessi o autolesionisti

[s0r4]

Originariamente inviato da Criceto

.NET è un clone di Java. LLVM è un'altra cosa.

ma per piacere...
che poi prima di accanirvi per principio sul .net ricordatevi che non è una proprietà microsoft (anche se bill è quello che si sta sbattendo di più per affermarlo)

[s0r4]

Originariamente inviato da MenageZero

vero, la news dice questo, ma azzarderei che faranno anche in modo che alla fine cmq il bilancio del lavoro di rifinitura e debug sia in attivo per l'uscita ad ottobre rispetto alla abortita uscita a giugno, mica saranno fessi o autolesionisti

no, si basano semplicemente sul fatto che i propri clienti troveranno mille scuse per giustificare le loro azioni

ma se ci lavora meno gente come fai a dire che faranno di più?
e poi di più rispetto ad una release ipotetica di cui noi non abbiamo nessuna informazione

[Asterion]

Originariamente inviato da s0r4

ma per piacere...
che poi prima di accanirvi per principio sul .net ricordatevi che non è una proprietà microsoft (anche se bill è quello che si sta sbattendo di più per affermarlo)

.Net è sviluppato da MS ed è ovviamente proprietà loro

[Criceto]

Originariamente inviato da MenageZero

scusa l'intromissione (non sono attualmente informato su llvm), ma se non c'è un layer di "interpretazione/traduzione/compilazione-JIT/<quel che si vuole>" a runtime, mi sembra di intuire che quantomeno per es codice macchina x64 non potrà girare su una cpu x86, sarebbe quindi una situazione del tutto analoga a quella di win: con cpu ed os x64. possono girare tranqulllamente senza sia app a 32 che a 64 bit (solitamente senza apprezabili penalità per il codice a 32bit), mentre con una cpu x86 possono girare solo os e apps a 32 bit.
no ?

Il JIT (o il compilatore statico, integrabile anche in un eventuale installer) produrrà codice x86-64 sui processori Intel a 64 bit e codice x86-32 sui processori x86 a 32 bit partendo da un'unica rappresentazione intermedia, che è quella che dovrebbe essere distribuita. Analogamente su PowerPC e su Arm produrrà codice oggetto per le rispettive architetture. I JIT sono specifici per ogni singolo tipo di processore, ovviamente, ma solo quelli.

Il bello è che sarà possibile anche far girare lo stesso codice su processori ancora non esistenti, basterà implementare il relativo JIT. Quindi rendendo il codice pressochè "eterno" e lasciando ad Apple la possibilità di cambiare architettura quando vorrà se ne presenterà l'occasione.

[s0r4]

Originariamente inviato da Asterion

.Net è sviluppato da MS ed è ovviamente proprietà loro

e quindi mono su linux lo sta sviluppando bill come progetto per il corso di fondamenti di informatica all'università redmond

[^TiGeRShArK^]

Originariamente inviato da Criceto

Dimmi il modello così evito di comprarlo per sbaglio!

Nel link che ti ho inviato c'è scritto chiaramente series60 e series80.

Magari il "Managed Cobol" che sarà incompatibile dal Cobol classico.

Fallo girare su LLVM il cobol classico senza problemi di compatibilità

4. LLVM non è una Virtual Machine!

allora dici alla apple per favore che hanno sbagliato il nome da dargli (Low Level Virtual Machine)

5. LLVM non supporta esclusivamente codice managed

Originariamente inviato da Wikipewdia

Execution of managed code

Programs for a managed code environment are normally written in a human-oriented programming language, typically C# or Visual Basic .NET.

Before the code is run, the Intermediate Language is compiled into native machine code. Since this compilation happens by the managed execution environment's own runtime-aware compiler, the managed execution environment can guarantee what the code is going to do. It can insert garbage collection hooks, exception handling, type safety, array bounds, index checking, etc.

This is traditionally referred to as Just-in-time compilation. However, unlike most traditional just-in-time compilers, the file that holds the pseudo machine code that the virtual machine compiles into native machine code can also contain pre-compiled binaries for different native machines (such as x86 and PowerPC). This is similar in concept to the Apple universal binary format.

I vantaggi di LLVM si avranno esclusivamente con codice managed, dato che, come vedi perfettamente da quanto riportato, è l'unico che si può avvantaggiare del Just-in-time compiler.
Un codice non managed sarà compilato staticamente e quindi si comporterà esattamente come il classico codice che noi tutti conosciamo.

6. LLVM supporterà linguaggi SCRIPTING altamente dinamici!

http://pythonnet.sourceforge.net/
http://punto-informatico.it/p.aspx?id=1636216&r=PI
python per tua norma è un linguaggio di scripting ed è correttamente supportato da .Net

7. LLVM supporterà le SPU del Cell!!!!

.Net, come hai appena visto supporta anche i cellulari.
Ciò vuol dire che non ci sarebbe alcuna difficoltà a fargli usare anche le SPE del cell o un calcolatore costruito con un trenino a vapore se vogliamo.

Continuo?

mmmm..
sarebbe meglio se ti informi un pò prima di continuare a dire cose assolutamente non vere tentando di negare che Apple abbia palesemente copiato MS .Net

.NET è un clone di Java. LLVM è un'altra cosa.

Ma anche no.
LLVM è un clone di .Net

[Asterion]

Originariamente inviato da s0r4

e quindi mono su linux lo sta sviluppando bill come progetto per il corso di fondamenti di informatica all'università redmond

Lasciamo perdere l'ironia da poche lire e parliamo seriamente.

Mono, preso da fonte wikipedia ( http://it.wikipedia.org/wiki/Mono_(progetto) )

Mono è un progetto open source coordinato da Novell (precedentemente da Ximian) per creare un insieme di strumenti compatibili con il Framework .NET, secondo gli standard ECMA (Ecma-334 e Ecma-335).

I più importanti di questi strumenti sono il compilatore C# e il Common Language Runtime.

Dove l'ECMA ( http://it.wikipedia.org/wiki/Europea...rs_Association ) definisce certi standard:

ECMA (European Computer Manufacturers Association) International è un’associazione fondata nel 1961 e dedicata alla standardizzazione delle informazioni e dei sistemi di comunicazione. Dal 1994 viene chiamata ECMA International.

Ecma International è responsabile attualmente per molti standard:

* Specifiche linguaggio C#
* Specifiche linguaggio C++/CLI
* Common Language Infrastructure (CLI), Infrastrutture di linguaggio comune
* Specifiche linguaggio ECMAScript
* Linguaggio di analisi design e programmazione Eiffel (Linguaggio di programmazione Eiffel)
* Considerazioni ambientali per prodotti elettronici
* Formato file Universal 3D

Quindi, a partire da specifiche che MS ha rilasciato per c#, CLI e quant'altro, MONO crea un ambiente compatibile con .Net ma .Net, quindi l'implementazione di quelle specifiche è scritta da MS e a lei appartiene: sorgenti, compilatori, licenza di utilizzo del framework e quant'altro.

Questo non significa che scrive MONO non possa creare qualcosa di compatibile con .Net ma che non c'entra nulla con .Net.

Un'ultima nota: se è stato possibile scrivere MONO è perché MS ha rilasciato le specifiche del framework a ECMA.

Quindi non dire che .Net non appartiene a MS perché non è vero. Se vuoi smetirmi fallo pure ma invece delle battutine posta i link ai fatti per favore.

[s0r4]

Originariamente inviato da Asterion

...

.net non è una tecnologia microsoft
se io volessi potrei creare un .s0r4net, ma non se lo cagherebbe nessuno
la microsoft invece ha intuito la superiorità di questo sistema aperto ed ha cminciato a sviluppare un suo framework, che onestamente non potete paragonarmi ad una java vm con tutte le sua anticaglie e layer aggiuntivi

con mono adesso si sta cercando di creare un framework per linux, ma naturalmente partendo con un bel po di ritardo adesso devono seguire la microsoft ed integrare le caratteristiche non standard che ha inserito (come ad esempio le window form)
se non fosse uno standard aperto altrimenti col cavolo che la microsoft gli permetteva di portarlo su linux...

[^TiGeRShArK^]

Originariamente inviato da Criceto

Il JIT (o il compilatore statico, integrabile anche in un eventuale installer) produrrà codice x86-64 sui processori Intel a 64 bit e codice x86-32 sui processori x86 a 32 bit partendo da un'unica rappresentazione intermedia, che è quella che dovrebbe essere distribuita. Analogamente su PowerPC e su Arm produrrà codice oggetto per le rispettive architetture. I JIT sono specifici per ogni singolo tipo di processore, ovviamente, ma solo quelli.

Il bello è che sarà possibile anche far girare lo stesso codice su processori ancora non esistenti, basterà implementare il relativo JIT. Quindi rendendo il codice pressochè "eterno" e lasciando ad Apple la possibilità di cambiare architettura quando vorrà se ne presenterà l'occasione.

ma guarda un pò...
esattamente nè + nè - di ciò che fa il .Net

[Asterion]

Originariamente inviato da s0r4

.net non è una tecnologia microsoft
.

E' un tuo parere o hai una fonte?

http://it.wikipedia.org/wiki/Linguaggio_C_Sharp

Il C# (si pronuncia C sharp, sharp in inglese significa "in gamba" o più semplicemente diesis) è un linguaggio di programmazione object-oriented sviluppato da Microsoft all'interno dell'iniziativa .NET,

Da quello che leggo mi pare si dica il contrario di quanto affermi ( http://it.wikipedia.org/wiki/.NET ):

Ecco perché MS ha rilasciato le specifiche:

Microsoft ha sottoposto una parte delle specifiche di progetto di .NET all'esame di ECMA (European Computer Manufacturers Association) per consentirne la standardizzazione. Ciò costituisce un rischio, sebbene calcolato. Questa mossa ha lo scopo di favorire l'implementazione di versioni e strumenti compatibili con il nuovo standard, che facciano da strumenti di migrazione e conversione di software non scritto per Windows in codice .NET.

Riguardo Mono:

Mono è un'implementazione open source delle librerie runtime e di sviluppo di .NET

Riguardo il framework ( http://it.wikipedia.org/wiki/Framework_.NET ):

Il Framework .Net è la parte centrale della tecnologia .Net di Microsoft.

Se conosci fonti che dicono il contrario citale, io non ho alcun problema a tornare sui miei passi. Ma devi darmi qualcosa di più della tua parola...

[Criceto]

Originariamente inviato da ^TiGeRShArK^

Fallo girare su LLVM il cobol classico senza problemi di compatibilità

E chi lo vuole il Cobol?

L'LLVM è nato come back-end di GCC, quindi (per ora) compila il codice che compila GCC. Quindi C, C++, Objective C e simili. Quello che serve per compilare applicazioni ATTUALI (non riscritte in versioni "managed" di un linguaggio utilizzando nuove API, come .NET).

Poi, essendo la rappresentazione intermedia una specie di processore virtuale a 64 bit con registri infiniti, è possibile che altri linguaggi utilizzino questa come target invece di processori REALI, aumentando la disponibilità di linguaggi.

Il bello è che pare che il sistema sia adattabile anche per linguaggi di scripting come Ruby e Phyton. Questo li renderebbe automaticamente estremamente efficienti!

Originariamente inviato da ^TiGeRShArK^

allora dici alla apple per favore che hanno sbagliato il nome da dargli (Low Level Virtual Machine)

Non è di Apple il progetto (e il nome). Il progetto è OpenSource.
E poi per "virtual machine" di BASSO LIVELLO ci si riferisce alla rappresentazione intermedia della compilazione, non un ambiente virtuale tipo Java e .NET.

Originariamente inviato da ^TiGeRShArK^

I vantaggi di LLVM si avranno esclusivamente con codice managed, dato che, come vedi perfettamente da quanto riportato, è l'unico che si può avvantaggiare del Just-in-time compiler.
Un codice non managed sarà compilato staticamente e quindi si comporterà esattamente come il classico codice che noi tutti conosciamo.

Questa cosa te la sei inventata tu.
JIT <> da managed.

.NET crea un'inutile (?) macchina virtuale dove fa girare il codice, come Java. L'LLVM genera codice NATIVO.

E' vero che l'Objective C 2.0 che Apple utilizzerà in Leopard supporta la garbage collection. Ma è opzionale. Il JIT dell'LLVM funziona con tutti i linguaggi attualmente supportati dal GCC.

Originariamente inviato da ^TiGeRShArK^

http://pythonnet.sourceforge.net/
python per tua norma è un linguaggio di scripting ed è correttamente supportato da .Net

Leggendo la descrizione mi sembra un modo non proprio pulito e diretto per implementarlo. Insomma un ibrido. Il problema di .NET è che RICHIEDE linguaggi managed, quindi quelli che nativamente non lo sono si devono adattare al suo modello. Questa cosa non è richiesta dell'LLVM.

Originariamente inviato da ^TiGeRShArK^

mmmm..
sarebbe meglio se ti informi un pò prima di continuare a dire cose assolutamente non vere tentando di negare che Apple abbia palesemente copiato MS .Net

Faresti bene tu ad informarti prima di fare paragoni che non stanno nè in cielo nè in terra.

[^TiGeRShArK^]

Originariamente inviato da s0r4

.net non è una tecnologia microsoft
se io volessi potrei creare un .s0r4net, ma non se lo cagherebbe nessuno
la microsoft invece ha intuito la superiorità di questo sistema aperto ed ha cminciato a sviluppare un suo framework, che onestamente non potete paragonarmi ad una java vm con tutte le sua anticaglie e layer aggiuntivi

con mono adesso si sta cercando di creare un framework per linux, ma naturalmente partendo con un bel po di ritardo adesso devono seguire la microsoft ed integrare le caratteristiche non standard che ha inserito (come ad esempio le window form)
se non fosse uno standard aperto altrimenti col cavolo che la microsoft gli permetteva di portarlo su linux...

Java è tutto tranne che un'anticaglia
E le prestazioni con le VM attuali sono MOLTO buone.