[C++]Unire più file .exe

[gugoXX]

Originariamente inviato da DioBrando

Io ci ho smanettato l'anno scorso scoprendolo alla conferenza, poi per motivi di tempo ecc. non ho approfondito e non è che mi ricordi moltissimo.
Boh puoi provare a chiedermi.
Mmm pvt? Vabbè che qui con gli OT...

E' molto banale quanto da vergognarsi.
Ho scaricato e installato (Anche se non mi sembra abbia installato nulla)
IronPython2.0
Mi aspettavo di avere una integrazione con Visual Studio, un po' come quando si installano i vari linguaggi come C++, VB.net, etc., con la loro bella macro-area e i loro "template" di progetto.
E invece mi e' comparsa solo la command line con
>>>

Ovviamente starei provando IronPython per l'integrazione con .net e tutte le altre facilities come i disegni delle Forms, l'integrazione in soluzioni con altri linguaggi, etc.etc
Anche perche' altrimenti mi sarei limitato a Python normale (CPython?)

C'e' quanto mi stavo aspettando e solo non l'ho trovato?

[gugoXX]

Originariamente inviato da cdimauro

Immagino, e lo vedrai sicuramente a breve.

Dai, a proposito di evangelisti, se avete tempo guardatevi questo
http://www.microsoft.com/emea/msdn/s...px?videoid=716

Fra l'altro, tra gli italiani c'e' un nutrito gruppo che spinge sul LINQ
I principali autori dei libri e delle presentazioni su LINQ sono proprio italiani.
E questo ci fa onore direi.
A parte il fortissimo accento italiano della presentazione...

[^TiGeRShArK^]

Originariamente inviato da gugoXX

E' molto banale quanto da vergognarsi.
Ho scaricato e installato (Anche se non mi sembra abbia installato nulla)
IronPython2.0
Mi aspettavo di avere una integrazione con Visual Studio, un po' come quando si installano i vari linguaggi come C++, VB.net, etc., con la loro bella macro-area e i loro "template" di progetto.
E invece mi e' comparsa solo la command line con
>>>

Ovviamente starei provando IronPython per l'integrazione con .net e tutte le altre facilities come i disegni delle Forms, l'integrazione in soluzioni con altri linguaggi, etc.etc
Anche perche' altrimenti mi sarei limitato a Python normale (CPython?)

C'e' quanto mi stavo aspettando e solo non l'ho trovato?

Originariamente inviato da DioBrando

Cesare ti ha già risposto cmq preciso il primo punto.

Hai 3 modi per utilizzare VisualStudio:
1. usi IronPythonStudio come ha detto Cesare che è basato su IronPython e VS2008 Shell
2. usi il pacchetto IronPython per ASP.NET
3. usi extensibility program attraverso l'SDK di VS, integrando una versione preesistente dell'IDE Microsoft (però è richiesto come minimo VS2005 perchè Ironpython non funziona con versioni antecedenti al framework 2.0)

Nessuna delle 3 và ad intaccare in alcun modo versioni preinstallate di VS.

mi sa che nel marasma del thread ti sei perso questo post di diobrando e il messaggio precedente con il link ad ironpythonstudio fornito da cesare

[cionci]

Originariamente inviato da fek

Anche a me sembra un tentativo di evangelizzazione e non nella terminologia inglese. Mi ricorda da vicinissimo l'evangelizzazione degli Apple fanatici

Ma che dici...l'ho visto solo io E solo io ho visto consigliare un martello per svitare una vite

[cdimauro]

Originariamente inviato da fek

Anche a me sembra un tentativo di evangelizzazione e non nella terminologia inglese. Mi ricorda da vicinissimo l'evangelizzazione degli Apple fanatici

:| Vabbé, e a quelli che consigliano C, C++ o addirittura l'assembly come gli chiamiamo? Matti da legare? -_-

Originariamente inviato da gugoXX

Dai, a proposito di evangelisti, se avete tempo guardatevi questo
http://www.microsoft.com/emea/msdn/s...px?videoid=716

Fra l'altro, tra gli italiani c'e' un nutrito gruppo che spinge sul LINQ
I principali autori dei libri e delle presentazioni su LINQ sono proprio italiani.
E questo ci fa onore direi.
A parte il fortissimo accento italiano della presentazione...

http://blogs.ugidotnet.org/janky/Default.aspx

Comunque installo SilverLight e vediamo che dice il link...

Originariamente inviato da cionci

Ma che dici...l'ho visto solo io E solo io ho visto consigliare un martello per svitare una vite

Riccardo, mi faresti vedere anche soltanto UNA volta in cui il concetto che hai esposto si applichi a me, cortesemente?

Così vediamo chi dei due parla più del dovuto...

Tra l'altro Fran parla di "evangelizzazione", e questo, logica alla mano, non implica che si applichi necessariamente a chi consiglia di utilizzare un martello al posto di un cacciavite...

[tomminno]

Originariamente inviato da gugoXX

Non ho mai detto di rinunciare alle stored procedure.
Solo non vorrei vederle scritte nel linguaggio proprietario del DB di turno, che peraltro e' praticamente sempre un procedurale che puzza di vecchio (Con i controsensi che sto intuendo proprio in questo periodo dell'avere un linguaggio procedurale per gestire i dati strutturati di un DB)
E infatti sia in Oracle che in SqlServer (che sono tra i migliori, potete dire cosa volete), si possono scrivere StoredProcedure in Java nel primo, e in C# nel secondo.

Eh?
Stored procedure da linguaggio?
Vorrai dire stored procedure temporanee, che sono di una lentezza impressionante (fare il count su una tabella con 20000 elementi impiega 250ms contro gli 0ms di una query diretta).

Codice C# compilato, richiamabile dal C# di altri parti, debuggabile e testabile senza troppi problemi e con le possibilita' che permette tale linguaggio.
Sono pezzi di codice che vanno comunque a finire dentro il DB, ma scritti in un linguaggio che e' ben diverso dal PL/SQL o dal T-SQL.

Potresti fornire dei riferimenti, non mi risulta che si possano scrivere e di conseguenza salvare su DB Stored Procedure (se non appunto SP temporanee) in C#.

E comunque non sarebbe neppure vero che il programmare in C# e basta genererebbe tanto traffico di rete.

Traffico di rete no, visto che transiterebbero gli stessi dati sia usando una interfaccia nativa sia ADO.NET o qualunque altro wrapper.

Prima si', era facile cadere nella trappola. Ora con il LINQ non sarebbe piu' cosi' tanto vero, e lo sto sperimentando proprio in questi giorni.
Il motore LINQ genera al volo le istruzioni SQL da sottomettere al database, sono progettate per essere funzionali, e l'istruzione SQL viene generata tutta insieme e sottomessa al database senza dover scartare nulla, se l'ho sfruttata bene.

Fatta prova con un server ad alto carico e LINQ rallenta notevolmente, rispetto allo stesso codice "vecchia maniera".
Per il momento è stato scartato.

[cdimauro]

Originariamente inviato da tomminno

Eh?
Stored procedure da linguaggio?
Vorrai dire stored procedure temporanee, che sono di una lentezza impressionante (fare il count su una tabella con 20000 elementi impiega 250ms contro gli 0ms di una query diretta).

Potresti fornire dei riferimenti, non mi risulta che si possano scrivere e di conseguenza salvare su DB Stored Procedure (se non appunto SP temporanee) in C#.

Forse si riferiva a roba come questa: http://www.postgresql.org/docs/8.3/static/plpython.html

In particolare, con Python: http://www.postgresql.org/docs/8.3/s...hon-funcs.html

Sulla carta mi sembra che la soluzione dovrebbere abbastanza veloce, in quanto, se non ho capito male (correggetemi perché non ho letto tutto il documento e al momento non ho abbastanza tempo per farlo), il codice Python verrebbe eseguito all'interno del server.

EDIT: anche con FireBird l'adozione di linguaggi diversi da quello built-in è in discussione (e molto probabilmente verrà approvata). Ecco qui http://www.firebirdsql.org/index.php...d=roadmap_2008

Release 2.5.0
External (e.g. Java) procedures (*)
(*) Under discussion, can be postponed

[gugoXX]

Originariamente inviato da tomminno

Eh?
Stored procedure da linguaggio?
Vorrai dire stored procedure temporanee, che sono di una lentezza impressionante (fare il count su una tabella con 20000 elementi impiega 250ms contro gli 0ms di una query diretta).



Potresti fornire dei riferimenti, non mi risulta che si possano scrivere e di conseguenza salvare su DB Stored Procedure (se non appunto SP temporanee) in C#.



Traffico di rete no, visto che transiterebbero gli stessi dati sia usando una interfaccia nativa sia ADO.NET o qualunque altro wrapper.



Fatta prova con un server ad alto carico e LINQ rallenta notevolmente, rispetto allo stesso codice "vecchia maniera".
Per il momento è stato scartato.

Non so cosa intendi per stored procedure temporanee.
Il metodo che conosco io per farlo si chiama CLR Stored Procedure.
E si possono usare anche per le function.
P.Es. nel mio database qui abbiamo fatto una CLR Stored Function per supplire alla mancanza della GROUP_CONCAT in Sql-Server.
Ovvero una funzione di gruppo che concatena le stringhe presenti nella stessa colonna, ma in righe diverse.

Prova a cercare riferimenti, ce ne sono parecchi in giro.
E prova ad immaginare quel codice scritto in LINQ, e non nel vecchio stile.

Sul LINQ to SQL sto facendo anche io parecchie prove, e sono partito proprio dal vedere cosa viene generato in SQL a seconda delle istruzioni sottomesse.
Sto cecando di capire i limiti e quale sarebbe lo stile giusto di programmazione per far fare all SQL proprio quello che si farebbe normalmente.
E se si fa particolare attenzione devo dire che non sto avendo affatto brutti risultati.

[dupa]

Originariamente inviato da gugoXX

Non so cosa intendi per stored procedure temporanee.
Il metodo che conosco io per farlo si chiama CLR Stored Procedure.
E si possono usare anche per le function.
P.Es. nel mio database qui abbiamo fatto una CLR Stored Function per supplire alla mancanza della GROUP_CONCAT in Sql-Server.
Ovvero una funzione di gruppo che concatena le stringhe presenti nella stessa colonna, ma in righe diverse.

Prova a cercare riferimenti, ce ne sono parecchi in giro.
E prova ad immaginare quel codice scritto in LINQ, e non nel vecchio stile.

Sul LINQ to SQL sto facendo anche io parecchie prove, e sono partito proprio dal vedere cosa viene generato in SQL a seconda delle istruzioni sottomesse.
Sto cecando di capire i limiti e quale sarebbe lo stile giusto di programmazione per far fare all SQL proprio quello che si farebbe normalmente.
E se si fa particolare attenzione devo dire che non sto avendo affatto brutti risultati.

Ciao sembra interessante sto LINQ, tu hai mai usato Hibernate? sarei curioso di confrontare le due soluzioni, da Javista conosco solo Hibernate/JPA

[cdimauro]

Per .NET c'è NHibernate.

[dupa]

Originariamente inviato da cdimauro

Per .NET c'è NHibernate.

sìsì lo so, sono un felice utilizzatore di Hibernate/Java, guardando su wikipedia ho visto che c'è una sorta di LINQ anche per Java, vorrei avere un'idea del confronto tra Hibernate vs LINQ (a occhio mi sa che microsoft ha scopiazzato dalla comunità java)

[cdimauro]

Dall'invenzione della ruota in poi l'uomo non ha mai smesso di copiare...

[dupa]

Originariamente inviato da cdimauro

Dall'invenzione della ruota in poi l'uomo non ha mai smesso di copiare...

il problema è chi copia sempre, senza inventare mai

[cdimauro]

Si può copiare migliorando, che è già qualcosa (e fa parte della nostra evoluzione).

Comunque difficile trovare qualcuno che copia e basta. Magari tu ne conosci qualcuno, ma a me al momento non viene in mente nessuno.

[fek]

Originariamente inviato da dupa

il problema è chi copia sempre, senza inventare mai

Non dire fesserie
http://research.microsoft.com/

[cdimauro]

Perché sei intervenuto Fran? Avevo appena steso la tela per intrappolarlo...

[dupa]

Originariamente inviato da fek

Non dire fesserie
http://research.microsoft.com/

Be', avere ricercatori, non vuol dire produttore idee intelligenti e innovative.
Anzi, considerando le dimensioni di microsoft, direi che producono ben poche idee rispetto le potenzialità che hanno.

Mi citi 3 invenzioni di casa Microsoft che la concorrenza ha copiato?

[fek]

Originariamente inviato da dupa

Anzi, considerando le dimensioni di microsoft, direi che producono ben poche idee rispetto le potenzialità che hanno.

Opinione tua per altro assolutamente non condivisibile. Sfogliati la pagina di research se sei interessato.
Se il tuo scopo e' trolleggiare invece dillo subito.

Mi citi 3 invenzioni di casa Microsoft che la concorrenza ha copiato?

Ok, il tuo scopo era trolleggiare.

[DioBrando]

Originariamente inviato da fek

Anche a me sembra un tentativo di evangelizzazione e non nella terminologia inglese. Mi ricorda da vicinissimo l'evangelizzazione degli Apple fanatici

pfui :oh:

non mi metto troppo contro solo perchè voglio fare anche io un'esperienza UK (profittatore mode on )


a parte gli scherzi, sapete bene che non è così.
Riprendete quei thread

[fek]

Originariamente inviato da DioBrando

pfui :oh:

non mi metto troppo contro solo perchè voglio fare anche io un'esperienza UK (profittatore mode on )

a parte gli scherzi, sapete bene che non è così.
Riprendete quei thread

Allora ti insegno subito come ragionano qui in UK: perception is everything
Non importa com'e' o come non e', importa come viene percepito, e ti assicuro che venite percepiti al momento come evangelizzatori di un linguaggio

Ho dovuto imparare questa lezioncina a mie spese e te la passo gratuitamente.