Ciao a tutti, volevo capire come tradurre (e se necessario) i seguenti termini
- service shared object
si rifà a questa frase A cgi-env directory which will contain all
the zcfg metadata files and the service shared object (C Shared
Library or Python module)
- datatype (riguardante il linguaggio C) per esempio quello qui sotto:
typedef struct maps{
char* name;
struct map* content;
struct maps* next;
} maps;
grazie
Luca
On Tue, 9 Nov 2010 16:39:29 +0100, Luca Delucchi wrote
Ciao a tutti, volevo capire come tradurre (e se necessario) i
seguenti termini - service shared object si rifà a questa frase A
cgi-env directory which will contain all the zcfg metadata files and
the service shared object (C Shared Library or Python module)
??? service shared object ???
sia l'una che l'altra cosa sono essenzialmente
delle banali librerie a caricamento dinamico.
nel caso dei moduli Python accompagnate da
qualche meta-file (egg).
non divertiamoci ad inventare termini
nuovi ad ogni passo per definire roba
nota e stranota sotto altri nomi più
comuni.
- datatype (riguardante il linguaggio C) per esempio quello qui sotto:
typedef struct maps{
char* name;
struct map* content;
struct maps* next;
} maps;
datatype = tipo di dati
non riguarda solo il C, ma qualsiasi linguaggio
basato appunto sulla tipizzazione
(praticamente tutti, escludendo i "trottolini"
come JavaScript, Python, VisualBasic ...)
ma personalmente eviteri di tradurre, perchè
è uno di quei casi in cui il termine inglese
ormai è diventato di uso corrente (almeno
tra gli addetti)
ciao Sandro
non riguarda solo il C, ma qualsiasi linguaggio
basato appunto sulla tipizzazione
(praticamente tutti, escludendo i "trottolini"
come JavaScript, Python, VisualBasic ...)
dando del trottolino a Python (e in qualche modo anche a JavaScript)
secondo me ti stai facendo piu' di qualche nemico! 
per VisualBasic la definizione calza 
--
Paolo Corti
GIS specialist and web developer
web: http://www.paolocorti.net
twitter: @paolo_corti
On Tue, 9 Nov 2010 17:30:31 +0100, Paolo Corti wrote
dando del trottolino a Python (e in qualche modo anche a JavaScript)
secondo me ti stai facendo piu' di qualche nemico!
per VisualBasic la definizione calza
ok, chiedo parzialmente venia per Python:
nonostante sia typeless è abbastanza rigoroso
e consistente da risultare ragionevolmente
usabile.
ma JS è un dannato casino
meno male che poi qualche anima pia
ha provveduto ad inventare FireBug
ma tu Paolo te lo ricordi che incubo
era fare debugging JS qualche anno fa ?
... magari sul 'mitico' MSIE 5.5 ...
comunque su un punto sicuramente concordiamo:
è veramente molto difficile (se non assolutamente
impossibile) riuscire a trovare un casino senza
capo ne coda più pasticciato di VB 
ciao Sandro
Il 09 novembre 2010 17:01, <a.furieri@lqt.it> ha scritto:
On Tue, 9 Nov 2010 16:39:29 +0100, Luca Delucchi wrote
Ciao a tutti, volevo capire come tradurre (e se necessario) i
seguenti termini - service shared object si rifà a questa frase A
cgi-env directory which will contain all the zcfg metadata files and
the service shared object (C Shared Library or Python module)??? service shared object ???
sia l'una che l'altra cosa sono essenzialmente
delle banali librerie a caricamento dinamico.
nel caso dei moduli Python accompagnate da
qualche meta-file (egg).
ok...
non divertiamoci ad inventare termini
nuovi ad ogni passo per definire roba
nota e stranota sotto altri nomi più
comuni.
non ho capito bene a cosa ti riferisci, io l'ho solo trovata non me la
sono inventata io
datatype = tipo di dati
immaginavo però volevo esserne sicuro
ciao Sandro
ciao
Luca
Ciao Sandro
ma JS č un dannato casino
meno male che poi qualche anima pia
ha provveduto ad inventare FireBug
che fosse problematica l'implementazione, sono d'accordo e sicuramente
FireBug ha dato una grande mano.
Ma il linguaggio di per se e' molto potente ed ha una sua grande dignita', IMHO.
Ne e' dimostrazione il proliferare delle librerie, talvolta molto
eleganti, che astraggono con un layer intermedio la complessita' allo
sviluppatore (ad es jQuery o Ext JS).
Quello che a volte, a causa di implementazioni veloci e farraginose e
- non ultima - magari la scarsa conoscenza dello stesso da parte dello
sviluppatore, puo' sembrare un linguaggio brutto e scomodo, puo'
prendere nuova luce se visto in ottiche diverse, quali ad es le
elegantissime implementazioni di OpenLayers o di jQuery, tanto per
fare due esempi noti ai piu'.
Ed ora sta di nuovo succedendo qualcosa di nuovo: dopo il rilascio di
V8 [1] da parte di Google, c'e' ad es questo node.js [2] che sembra
abbia performance impensabili e una scalabilita' grandiosa e che mette
a disposizione possibilita' di chiamate asincrone in maniera molto
semplice. Tanto e' vero che stanno nascendo framework server basati su
tale implementazione, quali ad es Express [3], che tra l'altro si
accoppiano benissimo con i nuovi storage NoSQL (ad es CouchDb o
MondoDb, tanto per dirne due tra i piu' noti).
Insomma lunga vita al JavaScript, anche se sovente puo' evocare brutti
ricordi
ma tu Paolo te lo ricordi che incubo
era fare debugging JS qualche anno fa ?
... magari sul 'mitico' MSIE 5.5 ...
praticamente una pletora di alert et similia
infatti FireBug ha secondo me il merito principale per l'uscita dei
framework javascript di cui ho scritto in precedenza.
V8 dara' ora ulteriore spinta.
comunque su un punto sicuramente concordiamo:
č veramente molto difficile (se non assolutamente
impossibile) riuscire a trovare un casino senza
capo ne coda piů pasticciato di VB
infatti (e lo dico da persona che ha usato VB5/6 per anni) e' un
linguaggio/strumento diseducativo che dovrebbe essere proibito a chi
si avvicina alla programmazione
E per di piu', ora che non ha quasi piu' senso sviluppare applicazioni
gestionali desktop, e' anche diventato privo di utilita', secondo me.
ci vediamo a Foligno, un caro saluto
P
[1] http://code.google.com/p/v8/
[2] http://nodejs.org
[3] http://expressjs.com
--
Paolo Corti
GIS specialist and web developer
web: http://www.paolocorti.net
twitter: @paolo_corti
On Wed, 10 Nov 2010 09:21:27 +0100, Luca Delucchi wrote
> ??? service shared object ???
> sia l'una che l'altra cosa sono essenzialmente
> delle banali librerie a caricamento dinamico.
> nel caso dei moduli Python accompagnate da
> qualche meta-file (egg).
>ok...
> non divertiamoci ad inventare termini
> nuovi ad ogni passo per definire roba
> nota e stranota sotto altri nomi più
> comuni.
>non ho capito bene a cosa ti riferisci, io l'ho solo trovata non me
la sono inventata io
Luca, lo so bene che non te la sei inventata tu ...
giusto per capirci fino in fondo e per avere
un quadro più organico e completo:
- nella notte dei tempi esisteva solo lo static
linkage: cioè il software era già organizzato in moduli
distinti (librerie), ma era obbligatorio "cucire"
(link) tutti i moduli necessari dentro all'eseguibile
al momento della build: dopo di che non era più possibile
nessuna modifica (appunto: statico)
- in tempi successivi (anni '80) è stato introdotto
il dynamic linkage: ora i moduli sono completamente
esterni all'eseguibile, e verranno collegati solo
al momento dell'esecuzione (run time).
insomma, le benedette DLL aka shared libraries
- una ulteriore evoluzione di questa architettura
dinamica consente addirittura di collegare in run
time anche moduli niente affatto previsti in fase di
progettazione iniziale (a patto che questi moduli
implementino un'interfaccia standard e ben nota).
ed ecco che nascono così le architture "a plugin".
in fondo Python (come tantissimi altri SW) lavora
semplicemente così quando richiami una IMPORT FROM:
va a cercarsi in una directory nota un EGG-file
di configurazione per quel package, dopo di che
si carica la DLL aka shared library relativa.
quindi possiamo divertici a chiamarli in mille
modi: moduli, estensioni, espansioni, plug-in ...
ma in fondo al meccanismo ci trovi sempre e
comunque le librerie a caricamento dinamico
ciao Sandro