Newsgroup: it.comp.macintosh
Titolo: CoreAudio sono in C++...

o Objective-C?
Ho scoperto che tutto quello che mi serve (per pilotare una interfaccia 
MIDI emagic) è diponibile tra le api di tale CoreAudio. Il problema è 
che tutti gli esempi di CoreAudio che ho visto sono scritti in C++ o in 
Objective-C. La mia piccola applicazione, invece, l'avevo fatta in Java.
C'è modo di utilizzare tali api di CoreAudio in java (riscrivere tutto 
in Objective-C non credo sia il caso perchè non ne so assolutamente niente)?
Grazie mille!

)

)
Ah ok...ciň vuol dire che ci posso rinunciare. Ok cmq grazie!

 in Objective-C non credo sia il caso perchč non ne so assolutamente niente)?
Comunque abbandonare Java č cosa buona e giusta in se e per se.
Poi fai tu.
-- 
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.

 Poi fai tu.
Non lo metto in dubbio, però il programmino era già pronto e un pò mi 
secca doverlo riscrivere in un linguaggio che non conosco affatto. Ma mi 
sa che non c'è altra alternativa...

 sa che non c'è altra alternativa...
Ottimo modo per imparare un nuovo linguaggio. Poi non ci vuole molto ad
imparare Objective C.


 imparare Objective C.
Vai mi hai convinto :) Ora cerco un pò di documentazione su ADC :)

 Vai mi hai convinto :) Ora cerco un pò di documentazione su ADC :)
Non ti fidare, dice sempre cosi` :P
-- 
Al mio mulo non piace la gente che ride

 Non ti fidare, dice sempre cosi` :P
Eheh, non è poi così facile, vero? Vabbè almeno di materiale free che ne 
è parecchio, vediamo che riesco a combinare :)


Pero` la mancanza di garbage collection e` veramente uno scandalo

 Pero` la mancanza di garbage collection e` veramente uno scandalo
Oooh vedo i presupposti per un bel flame tecnico. :D
Argomenti, prego. In cosa la gestione dell'allocazione di memoria di
Java sarebbe migliore di quella dell'Obj-C? :)

ArAgost ha scritto:

Guarda, normalmente uso Java. Di recente ho comprato un Mac ed ho
iniziato a studiare la programmazione in questo ambiente. Dicevo questo
semplicemente perche` la gestione a mano del reference counting degli
oggetti con retain, release e autorelease e` piu` soggetta ad errori
rispetto ad un mondo dove queste cose sono fatte automaticamente. Alla
fine quello che devi fare a mano in Obj-C, Java lo fa in automatico per
te. E questo io lo trovo un bene.
Qui potrei dire una cazzata, ma mi sembra che l'autorelease, pool viene
liberato (se non fatto esplicitamente) al termine del programma. Il
garbage collector, invece, automaticamente parte in background ad
intervalli piu` o meno regolari o quando ci sono determinate
condizioni, e quando parte garantisce la consistenza del tutto. Volendo
fare la stessa cosa in Obj-C bisognerebbe fare un thread ad-hoc che di
tanto in tanto svuota l'autorelease pool. Non so se questo e`
thread-safe. Se non lo e` sono cavoli ed ancora... altro codice non
facile da debuggare.
Comunque anche se l'autorelease pool avesse dei meccanismi per
autosvuotarsi rimane sempre la considerazione iniziale che per quanto
mi riguarda e` gia` grave. E` una vita che non chiamo distruttori,
riniziare a farlo mi stranisce :)

 Pero` la mancanza di garbage collection e` veramente uno scandalo
Leopard avra' Objective-C con garbage collector (vedi man gcc, al flag
-fobjc-gc).
 - ∞
-- 
Membro #23 della Lega dei Capelli d'Argento.

 liberato (se non fatto esplicitamente) al termine del programma.
Non esattamente, viene liberato quando viene rilasciato. Viene creato un
nuovo autorelease pool a ogni giro di run loop, e rilasciato al termine
del giro, se usi NSRunLoop; se non lo usi, creare e rilasciare ap e' tua
responsabilita' (ad esempio in un tool da linea di comando devi iniziare
con un bel NSAutoreleasePool* pool = [NSAutoreleasePool new]; e finirlo
con [pool release];, pena tonnellate di warning a runtime e leak degli
oggetti autorilasciati).


 se usi NSRunLoop
Ah: NSApplication usa automaticamente il run loop, quindi una cocoa
application normale fa tutto da se'.


 
Questa e` una good news! :)

 Eheh, non è poi così facile, vero? 
Avendo conoscenza con Java non è tanto difficile per davvero.
Sei semplicemente molto più dinamico (ergo puoi fare *più* cose
facilmente).
Ad ogni modo tenendo conto che la documentazione è comunque in larga
parte per ObjectiveC, ti fai un doppio favore.


 riniziare a farlo mi stranisce :)
Pensa che è un vero peccato... alle volte le strategie RAII semplificano
*enormemente* la gestione del codice. Quindi semmai viene tristezza per
i try/finally che provano a fare quello che le variabili automatiche
fanno, appunto, automaticamente.
Poi nulla da dire contro il GC, solo non è la "via": dipende cosa devi
fare.


 Pero` la mancanza di garbage collection e` veramente uno scandalo
Non più di avere nel 2006 un linguaggio come Java. Quello è uno scandalo
in toto.
Ingessato peggio del C++, senza avere la possibilità di evadere da tale
ingessatura. Adesso ci hanno provato con i generics, peccato che siano
una pena assurda.
Per il resto è macchinoso e inutilmente poco produttivo.


)
in cui non bisognava sporcarsi le mani con
il paradigma retain/release.
Tutto perso: non ci resta che applescriptare.


Si, su questo effettivamente hai ragione
scrivere roba tipo HyperFeaturedClass<CustomizedWithThat>
hyperFeaturedClass = new HyperFeaturedClass<CustomizedWithThat>(); non
e` che sia tutta 'sta bellezza :)

 imparare Objective C.
Per ora ho solo disegnato l'interfaccia con Inferface Builder: ma che 
strumento eccezzionale!!! Non avevo mai visto una cosa così!!! E sono 
sicuro che ho utilizzato sono una piccola parte delle sue potenzialità! 
Magnifico.

 
Come lo scriveresti in C++, o in Objective-C che non ha neanche i generics?
Inoltre, non concordo con Mc Osten riguardo le critiche a Java. Conosco sia 
Objective C che Java, ma il primo è una generazione indietro.
Infine la produttività è data da cosa devi farci, e per l'80% delle 
applicazioni Java è molto piu' produttivo di altri linguaggi.
Fabrizio

 applicazioni Java è molto piu' produttivo di altri linguaggi.
Si. Estremamente più produttivo dell'assembly, nettamente più produttivo
del C e abbastanza più produttivo del C++.
Fortunatamente ci sono linguaggi di livello ancora più alto che rendono
Java davvero poco produttivo. Non parliamo poi dei framework disponibili
per questi linguaggi (penso a Twisted o a ROR).
Java è molto adottato nell'industria, ma è almeno una generazione e
mezzo indietro, ormai.


 sicuro che ho utilizzato sono una piccola parte delle sue potenzialità!
Beh, a me IB piace abbastanza (anche se è molto criticato). Ma ad essere
sinceri il Matisse di NetBeans 5 o il tool di Visual Studio non sono
certo indietro.
Poi io raramente disegno GUI, quandi non entro nel merito... ma insomma
:)


 e` che sia tutta 'sta bellezza :)
Non parlavo della sintassi. Sono un grandissimo fautore delle sintassi
"belle", ma in fondo quella di Java non è atroce. Mutua abbastanza dal C
in generale e da C++ in particolare per essere decorosa.
Mi riferisco al cosidetto meccanismo di cancellazione del tipo:
addirittura da quasi l'idea di non essere programmazione *davvero*
generica, ma poco più che zucchero sintattico e qualche controllo sulla
compilazione.



Va be', almeno ti da qualche garanzia in piu` che puoi controllare a
compile-time.
Ben venga :)

 WebScript
Be', abbiam F-Script e recentemente pure il transfugo StepTalk.


 certo indietro.
IB si puo' criticare un sacco, ma l'idea di trattare una UI come una
serie di oggetti serializzata, invece di avere tool che producono
codice, e' stata rivoluzionaria (basta guardare il recente XAML di m$
per trovare diverse analogie tra uno xaml e un .nib...).


 WebScript
Mi hai fatto fare un rewind al '96 quando usci' WebObjects 1.0 
scaricabile da 
next.com
! :-D
Ciao
Mirko

 mezzo indietro, ormai.
Ora parli tu di generazioni...è indietro ma rispetto a chi?
Ciao,
Fabrizio

 Esempio?
Ti ha fatto degli esempi: Twisted per il pitone, Ruby on Rails per il
rubino, che sono eccezionali (o meglio, cosi' ho sentito per il primo
che ancora non ho toccato con mano, il secondo invece l'ho visto in
azione ed e' bello assai).


 compile-time.
Guarda che i templates di C++ funzionano indubbiamente meglio.


).

).
Guarda che hanno un intero ponte JS-Cocoa gia' integrato nel sistema,
dentro WebKit (guarda le interfacce WebScripting)...


 "Agile" perche' taglia un sacco di fuffa.
*subscribe*.


 Esempio?
Python, Ruby. A conoscerlo bene Haskell.


 dentro WebKit (guarda le interfacce WebScripting)...
Appunto. Quel che mi auspicavo e che estendessero l'uso di
JavaScript fuori dal WebKit: già in Tiger viene usato per
l'Installer e in Quartz Composer.

 l'Installer e in Quartz Composer.
Beh, entrambi lo tirano fuori dal WebKit. E' in quella libreria per
ragioni "storiche" (e' kjs!) e pratiche, ma e' usabile anche senza
tirarti dietro il resto del kit...



Visto che da come argomenti sembri essere molto esperto, mi
suggeriresti un po' di features a tuo avviso cool per andare ad
approfondirle? Ti ringrazio.

 approfondirle? Ti ringrazio.
Guarda: Core Data, Interface Builder (e il tutorial Currency Converter),
i meccanismi di delegazione e target/action, il meccanismo chiave-valore
(key-value coding/observing).


 (key-value coding/observing).
Si. In particolare suggerirei anche di dare un occhio a come si possono
usare gli Observer e gli altri meccanismi asincroni per eliminare (o
ridurre) l'uso dei thread.
Interessante potrebbe anche dare un occhio a come i vari Design Pattern
vengono resi facilmente in ObjectiveC (con addirittura esempi "pronti"
dalla libreria standard usati in pratica).


 dalla libreria standard usati in pratica).
Intendi
<
http://tuvix.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals
/CocoaDesignPatterns/chapter_5_section_3.html#//apple_ref/doc/uid/TP4000
2974-CH6-SW5>? :D


 ridurre) l'uso dei thread.
Ah! La catena dei responder, pure! Quella e' un'idea favolosa.


 in generale e da C++ in particolare per essere decorosa.
Salendo un attimo di livello però, a parità di aver scritto codice
buono, trovo che la leggibilità e pulizia non sia proprio paragonabile
:)
P.S. Da "amatore" della programmazione, Obj-C finora è il linguaggio che
mi ha più stupito. Devo solo recuperare Python... mi sono rotto di
leggerne meraviglie e non saperne nulla! :D

 2974-CH6-SW5>? :D
In  particolare si (anche se non conoscevo il documento). Mi riferivo
anche solo a ragionarci sopra e leggere documentazione "sparsa".


 leggerne meraviglie e non saperne nulla! :D
Ti stupirà ancora di più.


 Ti stupirà ancora di più.
Ehm, ho guardato un po' gli archivi ma non ho trovato nulla di
soddisfacente. Hai mica da dare indicazioni ad un poveretto, molto
disposto ad imparare, non nuovo alla programmazione, che vuole imparare
il suddetto linguaggio "dal punto di vista di un MACutonto" (non
necessario)?  

 Ti stupirā ancora di pių.
Ao`, ma la voi fini`? :P
-- 
Al mio mulo non piace la gente che ride

 necessario)?  
IMHO ti conviene chiedere su iclp. Io ho seguito un particolare processo
di apprendimento di Python: mi sono letto qualche tutorial in rete e poi
ho iniziato a scrivere codice.


 Ao`, ma la voi fini`? :P
E perchč? ;)


 E perchč? ;)
Perche` mi fai sentire in colpa :P
Che sono arrivato a scrivere 'Hello World', poi da Novembre non l'ho
piu` toccato


 ho iniziato a scrivere codice.
Io invece pure.  Avendo moglie e figli fuori citta` un dato weekend, mi
posi come obbiettivo di scrivere un robino (una piccola app web in CGI
per il calcolo e il display di probabilita` condizionate relative alla
divisione dei colori nel gioco del bridge) nel corso del weekend; non
pensavo di riuscire a finirlo, ma di farmi un'idea delle sue
potenzialita`, problemi, ecc, di questo linguaggio di cui avevo appena
guardato il tutorial; tutto sommato, potendoci star su dalle 7 del
mattino di sabato (io mi sveglio sempre presto) alle 10 di sera idem
(...e presto m'addormento;-), e poi di nuovo la domenica, cavolo, in 20
e piu` ore di lavoro almeno a un pre-prototipo ero certo di arrivarci.
Alle 11 del mattino del sabato (4 ore) avevo finito, avevo scritto
moduli riusabili per il calcolo combinatorio e per il templating cosi`
da fare il sito multilingue (quest'ultimo e` ancora reperibile in rete
come YAPTU), e mi ero gia` fatto idee precise su cosa MANCAVA a questo
linguaggio, specificamente la possibilita` di dotare i tipi container
che scrivevo io stesso di un metodo speciale, che pensavo si sarebbe
dovuto chiamare __contains__, per i test di appartenenza.  Postai in
merito su comp.lang.python...
...e imparai che la "funzionalita` mancante" era gia` pianificata per il
prossimo release venturo (1.6), e che il nome del metodo speciale era
gia` stato deciso ed era... __contains__.
All'animaccia del linguaggio compatibile col mio modo di pensare...!-)
Ovviamente da quel famoso weekend ne uscii totalmente sedotto da Python.
Alex

 Guarda che i templates di C++ funzionano indubbiamente meglio.
Curiosita` mia, mi spieghi come i template C++ (che conosco a menadito)
funziano meglio dei nuovi generics di Java (che non conosco? cioe`, Java
si`, con un po' di ruggine, ma la 1.5 specificamente e quindi i generics
no...) -- grazie anticipate!
Alex

 no...) -- grazie anticipate!
I generics di Java non esistono. Sono un artefatto di compilazione.
Ad esempio, se tu hai una bella List<Integer>, alla compilazione vedrai
che la classe ha bellissimi metodi con .add(Integer), .get(int) che
ritorna l'Integer alla posizione data ecc. ecc. tutto typesafe.
Solo che questi metodi non esistono, ovvero non c'e' un momento in cui
il template viene istanziato e la classe riscritta per usare Integer
come invece avviene in C++. Quello che succede e' invece che esiste solo
una classe List con solamente un metodo .add(Object) e un metodo .get()
che ritorna un Object, e ad esempio:
Integer i = lista.get(10); // ritorna Integer
viene compilato come (Java 1.4):
Integer i = (Integer) lista.get(10); // ritorna Object
Insomma, e' zucchero sintattico attorno ai cast, che pero' introduce il
concetto della typesafety onnipresente in Java anche in queste
situazioni (ovvero "io mi aspetto qui un intero, compilatore, avvertimi
se ho fatto qualche cavolata").
Tant'e' che si possono avere situazioni in cui si possono assegnare
oggetti List<UnTipo> a variabili List<UnAltroTipoIncompatibile>, che la
JVM non intercetta perche' in realta' sono tutti semplici oggetti List
(puoi compilare casi del genere perche' l'oggetto e' passato attraverso
una variabile con wildcard, come List<?>, e il compilatore non sa piu'
qual e' il tipo originale) che generano ClassCastException quando si
chiamano metodi a runtime. Ovviamente, il compilatore sa che la
situazione puo' essere pericolosa e emette sempre come minimo un warning
in questi casi.


 no...) -- grazie anticipate!
Beh, sui templates C++ non dico nulla allora.
I generics sono sintatticamente simili: esempio
ArrayList<String> lines = new ArrayList<String>()
L'unica cosa "bella" è che è immediato "limitare" via interfaccia
definendo generics di tipo <T extends SomeInterface> o anche <T extends
SomeClass> (ma questo mi pare decisamente meno interessante).
O anche <T extends OneInterface & NoOneInterface &
OneHundredThousandInterfaces>.
Ma ora arriviamo al punto: la macchina virtuale *non* ha oggetti di tipo
generico e  tutti gli oggetti sono di classi ordinarie. Definendo un
tipo generico il compilatore ottiene un tipo grezzo, il cui nome è il
nome del tipo generico senza parametri di tipo. Le variabili di tipo
vengono cancellate e diventano Object, oppure se limitate l'equivalente
tipo (SomeInterface).
E così abbiamo di nuovo classi ordinarie. E poi il compilatore aggiunge
dei cast. L'esempio classico è quello della Pair
Pair<Node> pn;
Node n1 = pn.getFirst()
sotto il cappello contiene una chiamata al grezzo Pair.getFirst e poi il
cast da Object a Node.
Ora veniamo ad alcune limitazioni:
1. I tipi primitivi non entrano nei generics. 
2. Siccome i tipi generici sono sostituiti, codice tipo
obj isinstanceof GenericClass<Double>
ha successo (se obj è di un qualche tipo di GenericClass) *sempre*,
anche se obj è per dire un GenericClass<String>. Il compilatore comunque
da un messaggio di warning (in pratica significa che non si dovrebbe
fare).
Idem getClass() e compagnia... insomma, la riflessione rimane
castratissima.
3. Le eccezioni non possono essere generiche. In particolare nei casi in
cui vogliamo che un'eccezione si salvi un po' di stato dell'oggetto
"rotto" per analizzarlo ed eventualmente metterlo a posto non è molto
pratico, visto che non può essere generica (mentre l'oggetto che la
lancia e il cui stato  vorremmo salvare lo è).
4. Gli array non possono essere di tipi generici.
5. Non si possono definire istanze di tipi generici
public Pair(){
        first  = new T();
        second = new T();
}
è proibito. Anche
T[] arr = new T[5];
6. Nei campi e nei metodi statici ovviamente non si possono avere
riferimenti ai tipi parametrici
public static T someMethod() // sbagliato
7. Bisogna evitare i conflitti dopo una cancellazione
tipicamente se ho una superclasse con un metodo foo(Object), nella
sottoclasse non posso definire un metodo foo(T) [perchè verrebbe
cancellato in foo(Object) ed entra in conflitto].
8. "Per supportare la translazione per cancellazione, si impone la
restrizione che una classe o una variabile di tipo non possono essere
contemporaneamente un sottotipo di due interfacce che costituiuscono
parametri della stessa interfaccia"
class Foo implements Comparable<Foo>
class Bar extends    Foo             implements Comparable<Bar>
//forbidden


 piu` toccato
Si fa presto :)
Purtroppo Aruba non incoraggia in tal senso (anche se noi in effetti
avevamo fatto un sacco di roba su Aruba con dei CGI Python).
D'altra parte se ti guardi Ruby e Python e poi scegli, va bene uguale.
Questione di pochi giorni per dare una spolveratina ad entrambi. Poi
imparato bene uno, puoi imparare l'altro via diff in una manciata di
tempo.



Se ne avete altri da consigliarmi, mandate pure che bookmarko.
-- 
La matematica non  possiede soltanto la verità, 
ma anche la bellezza suprema, una bellezza fredda  ed austera, 
come quella della scultura. 
[ Bertrand Arthur William Russell ]

 tempo.
E` possibile che dia un occhio anche a Ruby, credo


 E` possibile che dia un occhio anche a Ruby, credo
Saggio. Complessivamente a me piace piů Python al momento, ma immagino
piů per abitudine che per altro.
Ruby lo uso senza problemi ( spesso per analogia con Python ), ma per
ora non ho dovuto scrivere codice "tosto". Grosso modo con Rails per
adesso va scritto un po' di codice *banale* per mettere a posto i
modelli e codice altrettanto banale per fare le view.
Ti basta un po' di sintassi.
Mi interesserebbe trovare qualcosa di un po' cazzuto su cui divertirmi.
Ma sono pigro... il CGI per pulire IntelliTXT di merda, per dire, lo ho
fatto in Python senza nemmeno pensare che avrei potuto farlo in Ruby.
Cosa non č bello avere Andale Mono su MacOS X... altro che Monaco!


 Ti basta un po' di sintassi.
Per Ruby pensavo di comprare il libro che hai tu su Rails e cominciare
direttamente cosi`.
Ma ovviamente dopo Python


 Ma ovviamente dopo Python
Saggio.



Bookmarkato


 Bookmarkato
E' antico, sia il libro che il link.
Per il libro è in schedule la seconda edizione, per il libro la seconda
edizione è fuori da un anno buono.
  ngw

 per il libro la seconda edizione è fuori da un anno buono.
Buono a sapersi


:

Magari lo scrivo in italiano.
Dico, il libro Apogeo è su (parte di) Rails 1.0 ed è in schedule la seconda
edizione (in inglese però), per il pickaxe (il link) la seconda edizione è 
fuori da più si un anno, ed è sensibilmente migliore.
Con Ruby for Rails prendi due piccioni con una fava, e puoi prenderlo in PDF.
  ngw

 Se ne avete altri da consigliarmi, mandate pure
The Computer Language Shootout Benchmarks:
http://shootout.alioth.debian.org/
-- 
http://mio.discoremoto.virgilio.it/ppg/

 fuori da piů si un anno, ed č sensibilmente migliore.
Meglio, ma si capiva comunque :)


 Meglio, ma si capiva comunque :)
Beh, il mio parser era andato in segfault.


 Con Ruby for Rails prendi due piccioni con una fava, e puoi prenderlo in PDF.
Purtroppo trovo faticosi da leggere i libri in pdf. Nel senso che dovrei
stamparli, poi. E credo che aggiungendo il costo della stampa, alla fine
ridiventi conveniente quello cartaceo.


 The Computer Language Shootout Benchmarks:
Direi che questo non insegna a programmare in nessuno dei linguaggi
menzionati.


 menzionati.
Ed è una mezza cazzata, perchè non usa gli idiomi tipici dei linguaggi che
avrebbe la pretesa di esaminare, ma fa dei semplici "porting" di un
determinato algoritmo.
  ngw 

 fra Rails 1.0 e 1.1?
http://snipurl.com/oben
http://snipurl.com/q9iu
  ngw

 menzionati.
Un'osservazione veramente molto acuta...
-- 
http://mio.discoremoto.virgilio.it/ppg/

 determinato algoritmo.
Appunto, non č un tutorial di un bel nulla °:|

 Appunto, non è un tutorial di un bel nulla °:|
In compenso fa passare la voglia di mettersi a fare i benchmark a mano.


 Un'osservazione veramente molto acuta...
Abbastanza acuta da farti scrivere uno dei primo post tutto da solo
senza citare dal web e senza insultare.


 
http://snipurl.com/q9iu
Thank you.


 determinato algoritmo.
E non solo. Tipicamente dimostra nulla, in quanto in qualsiasi
linguaggio di alto livello l'algoritmo di sort (per dire) è
l.sort()  :) [lo smiley da ovviamente errore di sintassi]
e in effetti non mi scriverò mai *quel* tipo di algoritmi (o li ho già
fatti, oppure se ne ho bisogno vedo possibile che sia tempo di scrivere
la sottolibreria in C/C++).
