imparare Objc+Cocoa
![G[3z]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
G[3z]
ideuzze che vorrei sviluppare magari facendo anche qualche spicciolo.
ora io vengo da php e vorrei creare delle vere app per osx. come mi
muovo? dove trovo una bella guida cocoa+objective c (magari aggiornata a
xcode 3.0) ?
Riccardo Campana
Non e' aggiornatissimo, ma un buono spunto per cominciare e':
http://www.macocoa.omitech.it/
Ciao
--
Riccardo Campana
pabel...@gmail.com
"Physics is like sex: sure, it may give some practical
results, but that's not why we do it" (Richard Feynman)
G[3z]
> Non e' aggiornatissimo, ma un buono spunto per cominciare e':
> http://www.macocoa.omitech.it/
>
> Ciao
grazie mi tuffo alla lettura
crxor 666
Lascia perdere Objective C e utilizza Python o Ruby.
E' molto piů comodo e semplice, oltre che puoi usarli anche per (quasi)
tutto il resto (compresa la programmazione web).
A me piace piů Python, per inciso.
--
cc = callcc {|cc| cc.call cc}; cc.call cc
∞
> molto più comodo e semplice
In effetti se vuole usare Cocoa è meglio iniziare con ObjC, altrimenti
certe idiosincrasie non vengono comprese. (Per non parlare del debug.)
- ∞
crxor 666
> In effetti se vuole usare Cocoa è meglio iniziare con ObjC, altrimenti
> certe idiosincrasie non vengono comprese. (Per non parlare del debug.)
Non sono d'accordo. ObjC è un linguaggio *notevolmente* più complesso da
maneggiare sia di Ruby che di Python.
Quando incontra un'idiosincrasia, chiederà. Altrimenti gli facciamo solo
fare un lavoraccio per poco o nulla.
G[3z]
> Non sono d'accordo. ObjC è un linguaggio *notevolmente* più complesso da
> maneggiare sia di Ruby che di Python.
mmm python sembra carino (semplice) come sintassi ma mi permetterà (in
effetti è una domanda da 1 milione di dollari) di sviluppare su iphone?
il mio obbiettivo e realizzare qualche concept su quella macchina
crxor 666
> mmm python sembra carino (semplice) come sintassi ma mi permetterà (in
> effetti è una domanda da 1 milione di dollari) di sviluppare su iphone?
> il mio obbiettivo e realizzare qualche concept su quella macchina
Allora ti vedo confuso: Objective-C e Cocoa *non* ti serviranno per
sviluppare sull'iPhone. Li si usa principalmente Javascript + xhtml +
css.
∞
Certo, nel momento in cui PyObjC viene portato là su. Credo proprio che
libffi sia già operante su ARM, per cui...
- ∞
∞
> > mmm python sembra carino (semplice) come sintassi ma mi permetterà (in
> > effetti è una domanda da 1 milione di dollari) di sviluppare su iphone?
> > il mio obbiettivo e realizzare qualche concept su quella macchina
>
> Allora ti vedo confuso: Objective-C e Cocoa *non* ti serviranno per
> sviluppare sull'iPhone. Li si usa principalmente Javascript + xhtml +
> css.
Senza poter sapere nulla di ufficiale, ObjC e Cocoa saranno
probabilmente usati nell'SDK di febbraio prossimo, poiché già vengono
usati per scrivere il software che Apple usa sull'iPhone.
- ∞
G[3z]
> > Allora ti vedo confuso: Objective-C e Cocoa *non* ti serviranno per
> > sviluppare sull'iPhone. Li si usa principalmente Javascript + xhtml +
> > css.
>
> Senza poter sapere nulla di ufficiale, ObjC e Cocoa saranno
> probabilmente usati nell'SDK di febbraio prossimo, poiché già vengono
> usati per scrivere il software che Apple usa sull'iPhone.
"Esattevolmente" questo :)
G[3z]
> Certo, nel momento in cui PyObjC viene portato là su. Credo proprio che
> libffi sia già operante su ARM, per cui...
oggi ho scoperto l'esistenza di sto PyObjC e sembra interessante!
intanto mi faccio amico cocoa!
crxor 666
> Senza poter sapere nulla di ufficiale, ObjC e Cocoa saranno
> probabilmente usati nell'SDK di febbraio prossimo, poiché già vengono
> usati per scrivere il software che Apple usa sull'iPhone.
E a questo punto bisogna vedere perchè Python e Ruby non dovrebbero
essere supportati, visto che la tecnologia c'è già tutta ed è
distribuita con Leopard.
∞
> ∞ <mill...@gmail.com> wrote:
>
> > Senza poter sapere nulla di ufficiale, ObjC e Cocoa saranno
> > probabilmente usati nell'SDK di febbraio prossimo, poiché già vengono
> > usati per scrivere il software che Apple usa sull'iPhone.
>
> E a questo punto bisogna vedere perchè Python e Ruby non dovrebbero
> essere supportati, visto che la tecnologia c'è già tutta ed è
> distribuita con Leopard.
Il ponte Ruby è molto tradizionale, mentre quello Python usa libffi che
è un pezzo di codice assai arcano e bizzarro (ma immagino che un port
ARM esista...).
- ∞
crxor 666
> Il ponte Ruby è molto tradizionale, mentre quello Python usa libffi che
> è un pezzo di codice assai arcano e bizzarro (ma immagino che un port
> ARM esista...).
Definire libffi arcano e bizzaro è a sua volta arcano e bizzarro. Per
dire ormai è mantenuto nel trunk del gcc.
Tra l'altro faccio notare che libffi è usato pure da RubyCocoa, a quanto
avevo letto. Per dire su wikipedia, dice ancora così.
∞
> > Il ponte Ruby è molto tradizionale, mentre quello Python usa libffi che
> > è un pezzo di codice assai arcano e bizzarro (ma immagino che un port
> > ARM esista...).
>
> Definire libffi arcano e bizzaro è a sua volta arcano e bizzarro. Per
> dire ormai è mantenuto nel trunk del gcc.
Be', costruire funzioni al volo si trova nel mio dizionario alla voce
"arcano e bizzarro". :)
> Tra l'altro faccio notare che libffi è usato pure da RubyCocoa, a quanto
> avevo letto. Per dire su wikipedia, dice ancora così.
Infatti mi chiedevo come facessero a fare gli eventuali puntatori alle
closure, dopo aver scritto il post di cui sopra :D
- ∞
Gia.
> [...] A me piace piů Python, per inciso.
E se si volesse iniziare con Python? Puoi consigliare un qualche
sito/manuale online?
grazie. :)
gia.
crxor 666
> E se si volesse iniziare con Python? Puoi consigliare un qualche
> sito/manuale online?
Allora, nell'ordine:
ci sono alcune traduzioni in italiano. se no sul sito americano trovi il
tutorial di van rossum in inglese. Oltre che una serie di risorse e di
link.
C'è inoltre liberamente disponibile Thinking in Python di Eckel e 'How
to think like a computer scientist'
<http://www.greenteapress.com/thinkpython/>
<http://www.mindview.net/Books/TIPython>
Il secondo non è certo un libro per principianti assoluti di
programmazione. Per chi volesse un libro di questo tipo, per
'principianti assoluti' suggerisco:
<http://www.swaroopch.com/byteofpython/>
Uno può sempre dargli una letta e concludere che è troppo elementare.
Aggiungo per te:
<http://www.scipy.org/>
crxor 666
> Be', costruire funzioni al volo si trova nel mio dizionario alla voce
> "arcano e bizzarro". :)
Per me è completamente normale. Sono un bel po' di anni che lavoro con
linguaggi dinamici e costruire funzioni e classi al volo non è nulla di
strano, anche se i linguaggi statici cercano di farcelo credere.
Ma anche nei linguaggi funzionali, che pure ho adoperato non poco, la
pratica è comune. Sostituendo funzione con predicato, si fa pure nei
linguaggi logici (anche li ho un po' di esperienza).
Certo, nel mondo statico è una cosa 'strana', principalmente perchè è
relativamente complessa da fare. E poi fin li... pensa, tempo fa ricordo
un casino poichè una data versione della glibc veniva fermata dai
sistemi di protezione di open bsd.
Sostanzialmente il punto è che loro creavano un po' di codice eseguibile
nella sezione .data e poi ci saltavano dentro all'occorrenza: questo non
è forse generare una 'funzione' al volo? :)
G[3z]
> Grazie mille. Post bloccato. :)
come si fa?
Andrea D'Amore
ri...@despammed.com (crxor 666) wrote:
> costruire funzioni e classi al volo non è nulla di strano, anche se i
> linguaggi statici cercano di farcelo credere.
Che vuol dire costruirli al volo ?
∞
> Certo, nel mondo statico è una cosa 'strana', principalmente perchè è
> relativamente complessa da fare. E poi fin li... pensa, tempo fa ricordo
> un casino poichè una data versione della glibc veniva fermata dai
> sistemi di protezione di open bsd.
L'arcano non sta nel costruire funzioni al volo (senza scavare nei
linguaggi "belli", anche solo considerando JavaScript, quante chiusure
ho scritto), ma nel costruire funzioni *native* al volo, il che richiede
il port di libffi per adattarsi all'ABI di ciascuna architettura. Non è
affatto strano, ma è una cosa che i programmi statici di solito non
fanno.
- ∞
∞
L'esempio canonico, in JavaScript:
function creaSommatore(x) {
return function(y) { return x + y; }
}
var somma2 = creaSommatore(2);
var somma4 = creaSommatore(4);
alert(somma2(5)); // mostra '7'
alert(somma4(5)); // mostra '9'
- ∞
crxor 666
> L'arcano non sta nel costruire funzioni al volo (senza scavare nei
> linguaggi "belli", anche solo considerando JavaScript, quante chiusure
> ho scritto),
Beh, Javascript non è per nulla meno dinamico degli altri che ho
scritto, eh.
> ma nel costruire funzioni *native* al volo, il che richiede
> il port di libffi per adattarsi all'ABI di ciascuna architettura. Non è
> affatto strano, ma è una cosa che i programmi statici di solito non
> fanno.
Come ti dicevo... lo faceva perfino la libc! :)
Diciamo che sono cose che non vengono troppo sbandierate in genere.
crxor 666
> Che vuol dire costruirli al volo ?
Quando programmi in aereo con il macbook air.
crxor 666
> ... e manuali scaricati, anche quello base base, che a prima vista
> sembra essere perfetto per iniziare. Ben venga se si esaurira` in
> fretta. :-)
Infatti. Se poi uno si stanca, ci sono gli altri. Ma è molto più
frustrante, IMHO, partire da uno tosto e fare una fatica dell'accidenti.
L'importante con Python è poi programmare, programmare e programmare.
Solo leggendo, si impara poco. E leggere la documentazione dei moduli
che 9/10 fanno già quello che vuoi.
Andrea D'Amore
mill...@gmail.com (∞) wrote:
> function creaSommatore(x) {
> return function(y) { return x + y; }
> }
>
> var somma2 = creaSommatore(2);
> var somma4 = creaSommatore(4);
>
> alert(somma2(5)); // mostra '7'
> alert(somma4(5)); // mostra '9'
Capito, a function is worth a thousand words.
Ne ho un'idea perché pratico un po' lua dove le funzioni sono uno dei 7
o 8 tipi base, ma di fatto non programmo attivamente quindi non ero
sicuro di cosa intendeste.
Mi manca il gergo insomma anche detto "la problematica gergale" in
ambito tecnico.
Python non li chiama "first class citizen" o qualcosa del genere ?
crxor 666
> Python non li chiama "first class citizen" o qualcosa del genere ?
si e no. in generale si dice che qualcosa in un linguaggio è un 'first
class citizen' per dire che lo si può manipolare agevolmente come i vari
componenti naturali del linguaggio.
In Python è facile manipolare gli oggetti. Le classi sono oggetti e le
funzioni pure sono oggetti. Da cui sono 'first class citizens'.
Salty-Dog
> Le classi sono oggetti e le
> funzioni pure sono oggetti.
Ossignur, ecco perché non sarò mai programmatore...
--
Per contattarmi:
http://formmailto.com/saltydog
Andrea D'Amore
welcome...@zuppa.co.uk (Salty-Dog) wrote:
> Ossignur, ecco perché non sarò mai programmatore...
Ma guarda che è una semplificazione, invece di avere entità separate le
fai convergere.
In iolanguage mi sembra che anche non ci siano neanche parole chiave del
linguaggio ma che siano anche queste oggetti.
∞
> In iolanguage mi sembra che anche non ci siano neanche parole chiave del
> linguaggio ma che siano anche queste oggetti.
In Io ci sono un paio di parole chiave (method e block), ma come in
Smalltalk tutti i costrutti di controllo (if, while, for) sono metodi.
- ∞
crxor 666
> Ossignur, ecco perché non sarò mai programmatore...
Perchè? E' una cosa semplice. E' una semplificazione e basta. Sai
maneggiare gli oggetti? Si: bene, allora puoi manipolare il tutto.
Nota che non è nemmeno una cosa che *devi* sapere. E' solo una comodità.
In altri linguaggi dove questa proprietà non è vera, per fare le stesse
cose ci vanno paginate di codice, il che rende tutto più complesso e
scomodo. E purtroppo ci sono determinati problemi che si risolvono o
così oppure dannandosi il fegato (o ancora rinunciando).
∞
> ∞ <mill...@gmail.com> wrote:
>
> > L'arcano non sta nel costruire funzioni al volo (senza scavare nei
> > linguaggi "belli", anche solo considerando JavaScript, quante chiusure
> > ho scritto),
>
> Beh, Javascript non è per nulla meno dinamico degli altri che ho
> scritto, eh.
Certo. È solo il contesto che lo peggiora...
> > ma nel costruire funzioni *native* al volo, il che richiede
> > il port di libffi per adattarsi all'ABI di ciascuna architettura. Non è
> > affatto strano, ma è una cosa che i programmi statici di solito non
> > fanno.
>
> Come ti dicevo... lo faceva perfino la libc! :)
> Diciamo che sono cose che non vengono troppo sbandierate in genere.
Mi hai fatto ricordare che persino GCC genera codice che genera codice
in taluni casi. (Esempio:
void funzioneAltrui(int (*funzione)());
void a() {
int x = 0;
// funzione interna
int b() {
return x + 1;
}
// ...
funzioneAltrui(&b);
// ...
}
In questo caso gcc crea codice che crea un trampolino a runtime per
chiamare b passandogli anche un puntatore a x, mantenendo però int ...()
come signature. Da quando c'è il bit NX, però, non si può più usare...)
- ∞
Salty-Dog
> come in
> Smalltalk tutti i costrutti di controllo (if, while, for) sono metodi
Questo ha un senso. Ma che siano oggetti... e pure le classi... boh.
crxor 666
> Questo ha un senso. Ma che siano oggetti... e pure le classi... boh.
E perchč? Se č possibile ricondursi ad un unico principio senza nessuna
complicazione aggiuntiva per nessuno, perchč non farlo?
Salty-Dog
> perchè non farlo?
Perché la mia mente semplice tra classi e oggetti così va in loop.
crxor 666
> Perché la mia mente semplice tra classi e oggetti cosě va in loop.
Puoi dimenticare la nozione e per te non cambierŕ nulla.
Ad ogni modo č un vero peccato: non c'č ragione per il problema di
esistere. Se poi ti parlassi della distinzione *logica* fra tipo e
classe (distinzione che molti linguaggi rispettano, per inciso)
collassi.
Salty-Dog
> Ad ogni modo è un vero peccato
Secondo me dovreste riformare (e uniformare) la terminologia alla luce
delle nuove possibilità. Intendo un glossario generale e univoco per
tutti i linguaggi.
crxor 666
> Mi hai fatto ricordare che persino GCC genera codice che genera codice
> in taluni casi. (Esempio:
> [snip]
> In questo caso gcc crea codice che crea un trampolino a runtime per
> chiamare b passandogli anche un puntatore a x, mantenendo però int ...()
> come signature. Da quando c'è il bit NX, però, non si può più usare...)
Non è vero. In primo luogo il 'bit nx' è una novità solo su X86. PPC,
SPARC e compagni hanno aggeggi simili da tempo.
Comunque se guardi, non è come dici tu. Ovvero il codice non è generato
a runtime, a quanto vedo. Semplicemente siccome C è tutto statico
l'implementazione tipica non ha bisogno di generare codice a runtime:
basta passare qualcosa che può essere utilizzato per raggiungere
l'ambiente della funzione chiamante.
∞
> > In questo caso gcc crea codice che crea un trampolino a runtime per
> > chiamare b passandogli anche un puntatore a x, mantenendo però int ...()
> > come signature. Da quando c'è il bit NX, però, non si può più usare...)
>
> Non è vero. In primo luogo il 'bit nx' è una novità solo su X86. PPC,
> SPARC e compagni hanno aggeggi simili da tempo.
OK, dicevo su OS X. Da 10.4 in poi, applicano il bit NX o equivalente
allo stack (sia su x86 che su PPC) che rende impossibile usare la cosa
di cui sopra...
> Comunque se guardi, non è come dici tu. Ovvero il codice non è generato
> a runtime, a quanto vedo. Semplicemente siccome C è tutto statico
> l'implementazione tipica non ha bisogno di generare codice a runtime:
> basta passare qualcosa che può essere utilizzato per raggiungere
> l'ambiente della funzione chiamante.
... perché la cosa che ti ho scritto sopra viene compilata in questo
modo:
void funzioneAltrui(int (*funzione)());
void a() {
int x = 0;
const void* puntatoreAdX = &x;
// funzione interna -- come la compila GCC
int b(void* puntatoreAdX) {
return (*puntatoreAdX) + 1;
}
// ...
void* spazioPerLaFunzione = alloca(...);
// QUI! GCC inserisce del
// codice che genera codice -- scrive in spazioPerLaFunzione
// una funzione che richiama b(puntatoreAdX) ma che
// non prende parametri, così da avere signature int ...();
// Va generato qui perché a runtime non sappiamo x, usato da b,
// dove verrà allocato.
// NB in questo modo, se ad esempio funzioneAltrui() richiamasse
// a() ancora, la seconda chiamata a funzioneAltrui() avrà
// un "b" differente -- quello che punta alla seconda istanza di
// x, prensente nello stack della seconda chiamata di a().
funzioneAltrui( (int (*)())
spazioPerLaFunzione);
// ...
}
- ∞
∞
crxor 666
> Secondo me dovreste riformare (e uniformare) la terminologia alla luce
> delle nuove possibilitą. Intendo un glossario generale e univoco per
> tutti i linguaggi.
Sarebbe sensato. In effetti la terminologia ci sarebbe, ma molti
linguaggi mainstream fanno fare casino.