Archivio per la categoria ".NET Framework"



Windows Update, Windows Live Writer e SyntaxColor4Writer

Primo post del 2008 all’alba del tredicesimo giorno di gennaio, complimenti a me stesso per la tempestività. Insomma, anche se con un ritardo madornale vorrei augurarvi un buon 2008… per lo meno ora sapete che non ho fatto la fine del topo. Tornando al titolo del messaggio, oggi vagando a caso per internet ho trovato conferma sul blog di Davide Vernole a un sospetto che già mi era venuto nei giorni scorsi ma su cui non avevo indagato più di tanto per mancanza di tempo: dopo l’ultimo Windows Update che ho effettuato, SyntaxColor4Writer ha smesso di funzionare in Windows Live Writer. In realtà nell’approvare gli aggiornamenti avevo notato con la coda dell’occhio una voce riguardante Windows Live Writer per cui mi era bastato fare 1+1, ad ogni modo mi sono ritrovato impossibilitato a usare il mio plugin preferito per la formattazione del codice client-side data anche la mancanza di aggiornamenti pubblicati sul sito ufficiale dell’autore. Accidenti, proprio quando volevo mettermi di buzzo buono per aggiornare la mia definizione della sintassi di Ruby alle novità della 1.9. Oh well, poco male, rispolveriamo un mio post pubblicato in occasione del rilascio di WLW B2 e adattiamolo all’esigenza odierna:

  1. E’ necessario avere installato Visual Studio dal momento che verrà utilizzato ILDASM per effettuare il dump del relativo codice IL della DLL di SyntaxColor4Writer. In teoria credo sia possibile usare anche monodis (l’equivalente per Mono) ma sinceramente, non avendolo mai provato, non ho idea di quale possa essere il risultato finale e del suo grado di compatibilità.
  2. Creiamo una directory in cui copiare il file IStaySharp.SyntaxColor4Writer.dll e apriamo una shell dei comandi puntando alla stessa per eseguire vsvars32.bat (importa tutte le variabili d’ambiente per usare i tool di VS)
  3. Per effettuare il dump completo con ildasm.exe via command line dovremmo specificare una sfilza di parametri abbastanza lunga, per cui lanciamolo senza argomenti per eseguirlo in modalità GUI: a questo punto importiamo la DLL IStaySharp.SyntaxColor4Writer.dll e facciamone il dump nella directory corrente spuntando tutte le opzioni nella dialog delle dump options. Per comodità salviamo il file IL risultante con il nome IStaySharp.SyntaxColor4Writer.il
  4. Apriamo con un editor di testo qualsiasi il file .IL appena generato e sostituiamo tutte le occorrenze della stringa .ver 12:0:1366:1026 con .ver 12:0:1367:1128 (in totale dovrebbero essere effettuate 3 sostituzioni). Con questa procedura non facciamo altro che aggiornare le reference agli assembly esterni di WLW specificando la nuova versione degli stessi, in realtà basta questo perché le API esposte da WLW verso i plugin non sono cambiate.
  5. Ora dobbiamo ricompilare la DLL con ILASM: torniamo alla shell e lanciamo questo comando:
    ilasm IStaySharp.SyntaxColor4Writer.il /dll /res:IStaySharp.SyntaxColor4Writer.res
  6. Una volta generata la nostra nuova versione di IStaySharp.SyntaxColor4Writer.dll non resta altro da fare che sostituire la DLL attualmente esistente nella directory Plugins di WLW e lanciare il programma.

Istruzioni sicuramente della mutua per uno sviluppatore .NET rodato, ma possono tornare comode ugualmente. A meno di cambiamenti particolari o differenze nelle API, come accaduto nel passaggio da B1 a B2 di WLW, questi passaggi dovrebbero rimanere validi anche per eventuali update futuri: basterà semplicemente aggiornare le stringhe di sostituzione con le relative versioni. Come in passato, se qualcuno avesse bisogno della DLL aggiornata e pronta per l’uso non dovrà far altro che contattarmi (anche privatamente, ho aggiunto l’indirizzo email in fondo alla pagina delle note in attesa di miglior organizzazione :-))

Microbenchmark: Ruby 1.9.0 contro tutti (… non proprio…)

Il rilascio di Ruby 1.9 è previsto intorno a Natale e con il passare dei giorni la curiosità dei rubyisti si fa sempre più intensa. Stuzzicato da un microbenchmark pubblicato da Antonio Cangiano sul suo blog in cui ha messo a confronto la velocità di esecuzione di Ruby 1.8.6, Ruby 1.9.0 e Python 2.5.1 usando volutamente una funzione ricorsiva che calcolasse i primi 35 numeri della successione di Fibonacci, ho pensato che sarebbe stato interessante fare lo stesso test con i suoi script ma con condizioni diverse. A differenza di Antonio, che ha eseguito il suddetto microbenchmark sul suo MacBook Pro con OS X 10.5, ho pensato di effettuare i miei test su Windows chiamando in causa a questo punto anche IronRuby e, tanto per fare, anche PHP e Lua. Mi sarebbe piaciuto provare anche JRuby, ma purtroppo non ho nessuna esperienza e non saprei nemmeno da dove cominciare.

  • Configurazione: Microsoft Windows XP SP2 (x86) – AMD Athlon64 3700+ (2,2 GHz) – 2 GB RAM
  • Dettaglio versioni:
    • Ruby 1.9.0 (SVN rev. 14067 compilata con VC++ 2005)
      ruby 1.9.0 (2007-12-01 patchlevel 0) [i386-mswin32_80]
    • Ruby 1.8.6 (Ruby OneClick Installer 1.8.6-25)
      ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32]
    • IronRuby 1.0 pre-alpha (SVN rev. 65 compilata con CSC di VS 2005)
      IronRuby Pre-Alpha (1.0.0.0) on .NET 2.0.50727.832
    • Python 2.5.1 (Standard Python 2.5.1 Windows Installer)
      Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)]
    • Python 3.0a1 (Standard Python 3.0a1 Windows Installer)
      Python 3.0a1 (py3k:57844, Aug 31 2007, 16:54:27) [MSC v.1310 32 bit (Intel)]
    • PHP 5.2.5 (Binari ufficiali per Win32 – versione TS – no debug – Zend Engine 2.2.0)
      PHP 5.2.5 (cli) (built: Nov  8 2007 23:18:51)
    • PHP 5.3.0 (Snapshot ufficiale – versione TS – no debug – Zend Engine 2.3.0)
      PHP 5.3.0-dev (cli) (built: Dec  1 2007 04:19:04)
    • PHP 6.0.0 (Snapshot ufficiale – versione TS – no debug – Zend Engine 3.0.0-dev)
      PHP 6.0.0-dev (cli) (built: Dec  1 2007 02:04:58)
    • Lua 5.1.2 (LuaBinaries per Win32 di LuaForge)
      Lua 5.1.2  Copyright (C) 1994-2007 Lua.org, PUC-Rio

Le build di Ruby 1.9 e IronRuby sono state effettuate direttamente da me allineandomi questa mattina con i trunk nei rispettivi repository SVN, nel primo caso senza badare a ottimizzazioni particolari e nel secondo caso usando la modalità release. Per le versioni di sviluppo di PHP ho prelevato questa mattina da snaps.php.net i binari ufficiali e ho effettuato i test con la configurazione (php.ini) di default, così come per la versione stabile 5.2.5. Lo script per Python è stato leggermente modificato per la versione 3.0 dal momento che print è diventata una funzione e funziona diversamente dalla versione 2.5.

Gli script usati per Ruby, IronRuby e Python sono gli stessi di Antonio, aggiungo solo le mie varianti Lua e PHP (occhio, si tratta solamente di un becero port ai rispettivi linguaggi). Ecco come si presenta la versione in Lua:


function fib(n) if n == 0 or n == 1 then return n end return fib(n - 1) + fib(n - 2) end for n = 0, 35 do print("n=" .. n .. " => " .. fib(n)) end

Ed ecco invece la versione in PHP:


function fib($n) { if ($n == 0 || $n == 1) return $n; return fib($n - 1) + fib($n - 2); } for ($i = 0; $i <= 35; $i++) echo "n=", $i, " => ", fib($i), "\n";

I tempi riportati di seguito rappresentano la media calcolata sui risultati di 6 esecuzioni scartando la prima. Ecco i risultati ottenuti:

Ruby 1.9.0 : 21,123s
Ruby 1.8.6 : 94,736s
IronRuby : 26,123s
Python 2.5.1 : 33,827s
Python 3.0a1 : 48,718s
PHP 5.2.5 : 91,672s
PHP 5.3.0 : 77,813s
PHP 6.0.0 : 73,969s
Lua 5.1.2 : 14,912s

Ora un po’ di considerazioni:

  • Ruby 1.9 è dannatamente più veloce di Ruby 1.8.6. Punto.
  • IronRuby non è nemmeno uscito dallo stato di pre-alpha e già offre prestazioni molto buone, vicine a quelle di Ruby 1.9 che invece si sta avvicinando al rilascio. Ottimo!
  • Mi incuriosisce la differenza tra i tempi di Ruby 1.8.6 registrati da Antonio su OS X e quelli registrati da me su Windows: 159 secondi rispetto a 95 secondi mi sembra un abisso, soprattutto perché immagino che un Core 2 Duo 2.2 GHz sia più performante di un Athlon64 3700+ 2.2GHz.
  • Python 3.0 è più lento di Python 2.5.1, ma la versione 3.0a1 risale a fine Agosto per cui sarebbe il caso di ripetere lo stesso benchmark con una versione più aggiornata.
  • PHP sembra migliorare abbastanza con il passaggio da Zend Engine da 2.2.0 a 2.3.0, ma comunque le prende alla grande da Ruby 1.9 e Python.
  • Lua li straccia senza alcun ritegno.
  • Ordine di arrivo: Lua 5.1.2, Ruby 1.9.0, IronRuby 1.0 pre-alpha, Python 2.5.1, Python 3.0a1, PHP 6.0, PHP 5.3, PHP 5.2.5, Ruby 1.8.6.

Ovviamente un singolo microbenchmark di questo tipo non può essere assolutamente considerato come un valido indicatore delle prestazioni offerte da un linguaggio in situazioni reali, però i risultati sono comunque curiosi. A quanto pare i rubyisti avranno già un bel regalo assicurato per questo Natale :-)

PS: noto al termine della scrittura che Antonio ha scritto un altro articolo, aggiungendo Lisp e Haskell.

F#… e .NET diventa ufficialmente "funzionale"

La notizia dell’approvazione da parte di OSI delle licenze Microsoft Ms-PL e Ms-RL sta tenendo il banco delle discussioni, come del resto sarebbe stato logico aspettarsi fin dall’inizio, ma a me piacerebbe parlare di altro pur restando in casa Microsoft. Infatti è notizia di oggi che F#, linguaggio di programmazione funzionale nato in seno ai laboratori Microsoft Research, diventerà un linguaggio supportato ufficialmente sulla piattaforma .NET, tanto che verrà pienamente integrato in Visual Studio anche se con tempistiche non definite. L’impegno sarà inoltre quello di farlo crescere e certamente questa attenzione ufficiale da parte di Microsoft lo aiuterà molto in questo senso. Sinceramente non ho mai avuto occasione di provare F#, in passato ho letto documentazione e curiosato in qualche esempio limitandomi per il resto a installarlo ma senza poi provarlo effettivamente, ora magari vedrò di darci un’occhiata un po’ più convinta in scia a questa notizia. Nel frattempo per dettagli ulteriori c’è l’annuncio di S. Somasegar (corporate vice president del reparto sviluppo di Microsoft) sul suo blog.

Microsoft e i sorgenti delle librerie di .NET: qualche considerazione

Ieri era il giorno dell’annuncio, oggi tocca alle reazioni a freddo. Come era lecito aspettarsi, il rilascio dei sorgenti da parte di Microsoft delle librerie di .NET sta facendo discutere parecchio e in tutti i sensi. Alcune argomentazioni a dire il vero hanno dell’incredibile, con ironie sulla via dell’open source di Microsoft quando non risulta da nessuna parte che avessero intenzione di clonare o anche soltanto scimmiottare qualche forma open source con la pubblicazione dei sorgenti. L’iniziativa Shared Source di Microsoft non ha nulla a che vedere con l’open source e se proprio avessero voluto avvicinarsi a qualcosa di simile allora avrebbero utilizzato una licenza di quelle sottoposte al vaglio di FSF OSI, non certo una blindatissima MS-RL. Come al solito certa gente deve far prendere aria alla bocca per poter essere contenta. Esistono tuttavia due punti molto pratici degni di essere riportati perché lasciano effettivamente qualche punto interrogativo aperto:

  1. Non sarà assolutamente permesso editare o riprendere parti del codice delle librerie per aggirare qualche baco identificato durante la consultazione o il debug. Nel caso del ritrovamento di un bug, così come è già oggi del resto, esso dovrà essere inviato tramite un report a Microsoft con il suo solito sistema di feedback per poi attendere speranzosi, a volte anche per mesi, una hotfix ufficiale. Nel frattempo la licenza proibirà in maniera tassativa la creazione di patch "personalizzate" da applicare alle librerie. In parte questo comportamento è comprensibile in un’ottica esasperatamente business oriented (leggasi: protezione dell’integrità dell’ambiente, supporto non minato da agenti esterni imprevedibili, garanzie da poter fornire ai big player), ma lascia comunque l’amaro in bocca il fatto di essere davanti alla carota senza poterla raggiungere. Guardare ma non toccare, anche se farlo risolverebbe un problema e magari invoglierebbe ancora di più gli sviluppatori a inviare patch a Microsoft per snellire tutto il processo.
  2. Il codice che verrà rilasciato sarà estremamente differente dal prodotto che si può già ottenere con tool come Reflector perché non saranno presenti alterazioni del codice dovute alla rielaborazione dei compilatori e saranno mantenuti anche i commenti. Questo elevato grado di dettaglio alimenta quindi il timore che guardando i sorgenti delle librerie si possa essere soggetti a eventuali procedimenti legali per qualche presunta violazione (software patents). Per assurdo è la stessa paura che Microsoft ha nei confronti di licenze come la GPL e che cerca di contrastare vietando ai propri sviluppatori di guardare il codice di progetti coperti da licenze virali di questo tipo. Curioso no? Tra l’altro quella di chi si appresterà a scavare nei sorgenti di .NET sarà una paura quasi legittima viste le recenti esternazioni di Microsoft nei confronti di Linux e di alcuni progetti open source e senza dimenticare passate azioni legali intentate dal big di Redmond.

Ovviamente non si è costretti ad aderire, si potrà sempre rifiutare la licenza MS-RL non usufruendo quindi dei sorgenti delle librerie di .NET e rimanendo di fatto in una situazione pari a quella attuale, diciamo che non si perderà nulla rispetto a oggi ma sicuramente si avrà da perdere in opportunità. Rimango comunque dell’idea che quanto è stato annunciato sia positivo e, per chi vorrà sottoscrivere i termini imposti dalla licenza, sarà sicuramente un grande aiuto poter effettuare il debug addentrandosi negli internals delle librerie del framwork quando necessario, tuttavia trovo anche comprensibili e condivisibili alcune considerazioni pratiche e dubbi comuni espressi da più persone.

.NET Framework 3.5 e i suoi sorgenti… senza Reflector…

Oggi Scott Guthrie, general manager della Divisione Sviluppo di Microsoft, ha rivelato una notizia particolarmente inaspettata che ha colpito la comunità di .NET come un fulmine a ciel sereno con una novità che avrà sicuramente una rilevanza enorme per chi sviluppa abitualmente in questo ambiente: con il rilascio di .NET Framework 3.5 e la concomitante uscita di Visual Studio 2008 RTM (ex Orcas) saranno resi disponibili i sorgenti delle librerie della BCL di .NET Framework dietro licenza MS-RL, il tutto accompagnato dal codice di altre componenti molto importanti dello stack di sviluppo .NET quali ASP.NET, Windows Forms, ADO.NET e Windows Presentation Foundation. Altre tecnologie, come LINQ e Windows Communication Foundation, arriveranno nei mesi successivi. I sorgenti saranno scaricabili manualmente attraverso un download apposito oppure Visual Studio sarà in grado di caricare automaticamente sia i simboli che i sorgenti via web se ritenuti necessari durante la fase di debug di un’applicazione. Proprio qui si trova la grande differenza con il poter banalmente vedere i sorgenti delle librerie decompilandoli con Reflector: con VS 2008 sarà possibile eseguire delle sessioni di debug step-by-step addentrandosi nei sorgenti delle librerie di .NET, ripercorrendo nel callstack tutto il flusso di esecuzione fin là dove prima non era consentito… e scusate se è poco. Scusate se è poco anche un altro dettaglio non indifferente: poter conoscere gli internals delle librerie può portare a un grande valore aggiunto nell’ottica dell’ottimizzazione e di un migliore utilizzo delle stesse. Ovviamente potete trovare maggiori dettagli nel messaggio di Scott. L’annuncio di oggi è l’ennesimo tassello che conferma la mia impressione di una Microsoft in preda a correnti interne differenti e molto contrastanti tra loro.