Tagged: .NET RSS

  • admin 11:57 on 09.07.2009 Permalink | Reply
    Tags: .NET, ,   

    C# Konstrukt ‘using’ selbst gebaut mit Scala 

    Mit Scala ist es recht einfach Funktionen zu schreiben, die sich in der Verwendung wie Sprachkonstrukte anfühlen. Das kann man sehr gut nutzen um textuelle DSLs zu entwickeln. Ein Beispiel ist das Testframework ScalaTest mit dem man Tests folgendermaßen formulieren kann:

    map should (contain key ("one") and not contain value (10))
    result should be => (0)
    book should have (title ("Programming in Scala"))
    tempFile should not be a ('directory)
    quotient should be (1.0 plusOrMinus 0.2)

    Als kleine Demonstration zeige ich hier nun wie man das ‘using’ Konstrukt aus C# in Scala nachahmen kann. Die Funktionsweise dieses Blocks ist simpel, aber immer wieder nützlich. Man übergibt einen Stream bzw. irgendeine Instanz, die IDisposable implementiert, verwendet diese und das Schließen bzw. Zerstören der Instanz geschieht ganz von alleine.

    using (var file = File.CreateText("test.dat")
    {
        file.WriteLine("C# is");
        file.WriteLine("great");
    }

    Was wirklich passiert ist, dass der Compiler ein try finally Block erzeugt, der in jedem Fall .Dispose() aufruft, womit dann im Falle eines Streams auch automatisch .Close() zum Zuge kommt. Fangen wir mit der Scala-Übersetzung an. Eine erste Methode könnte eine simple Funktion höherer Ordnung in der folgenden Art sein:

    val file = new PrintWriter("test.dat")
    using (file, () => {
      file.println("scala is")
      file.append("great")
    })
    
    def using(stream: Closeable, operation: () => Unit) {
      try {
        operation
      } finally {
        stream.close()
      }
    }

    Using erwartet den Stream sowie die auszuführende Funktion, die nichts erwartet und nichts zurückgibt (Unit entspricht praktisch void in C#). Wir können die Syntax noch weiter verbessern, indem wir den zweiten Parameter in einen By-Name-Parameter umschreiben:

    def using(stream: Closeable, operation => Unit)

    Nun fehlen die zwei Klammern in der Signatur, was dazu führt, dass wir sie auch beim Aufrufen weglassen können:

    using (file, { ... })

    Das kommt der Version aus C# schon recht nahe. Einen Unterschied können wir jedoch nicht verstecken – in Scala sind Variablendeklarationen keine Ausdrücke. Somit können wir sie z.B. nicht wie in C an eine Methode übergeben, sondern müssen die Variable im Voraus definieren und sie dann an using übergeben.
    Doch trotzdem gibt es hier noch Verbesserungsmöglichkeiten. Wir können using in eine partiell auswertbare Methode umwandeln, sodass using einen Parameter erwartet und als Ergebnis wieder eine Funktion zurück liefert, die nur noch die Operation als Argument bekommt. Das sieht dann so aus:

    def using(stream: Closeable)(operation: => Unit)  { ... }

    Damit sind wir nunam Ziel angelangt. Wir können das using-Konstrukt fast wie in C# nutzen (in Scala können normale Klammern auch durch geschweifte ersetzt werden):

    val file = new PrintWriter("test.dat")
    
    using (file) {
      file.println("scala is")
      file.append("great")
    }
     
    • Heiko 12:37 on 22.02.2010 Permalink

      Schöne Demo!

      Eine Anmerkung: Wir müssen und sollten die Variable file gar nicht im Voraus definieren, wenn wir sie nur innerhalb von using verwenden wollen. Besser wäre

      using (new PrintWriter(“test.dat”)) {

      }

    • Michael 06:20 on 23.02.2010 Permalink

      @Heiko: Aber wie soll man dann Methoden des Streams aufrufen können?

  • admin 02:55 on 26.01.2009 Permalink | Reply
    Tags: .NET, , , Performance,   

    Lazy Loading von Plugins in multilingualen .NET Applikationen 

    Letztes Jahr hab ich eine kleine Anwendungs-Shell gebaut, welche mir die Entwicklung von Desktopanwendungen einfacher machen soll. Schwerpunktmäßig habe ich mich dabei auf die Features Erweiterbarkeit, Multilingualität, Lazy Loading und gute Trennung der Logik von der Oberfläche konzentriert. Als festes Standbein habe ich das Framework Mono.Addins genutzt, mit dem ich in meinen Anwendungen Erweiterungspunkte in einem XML-Baum definieren kann.

    Ähnlich wie in XUL oder XAML erzeuge ich außerdem etliche Teile meiner Oberflächen direkt aus dem XML-Baum, der sich aus allen XML-Knoten der geladenen Plugins ergibt. Dies ermöglichst es mir Menüs und Werkzeugleisten darzustellen ohne alle Plugin-Assemblies zu laden. Denn die Infos über Struktur, Titel und Icons der Oberfläche befinden sich bereits in den XML-Daten und müssen nicht erst vom .NET Code erzeugt werden. Mit solchen Prinzipien kann man auch große Anwendungen zu einem schnellem Start verhelfen, Visual Studio, #Develop und Co machen es genauso.

    (More …)

     
  • admin 00:26 on 14.01.2009 Permalink | Reply
    Tags: .NET, , , ,   

    Materialien zum Techtalk 

    Am Samstag haben wir unseren ersten studentischen Techtalk veranstaltet. Die Veranstaltung in meinen Augen auf jeden Fall ein Erfolg, ich denke jeder von uns konnte an dem Tag einiges lernen und freut sich nun auf das nächste Mal :-) . Die Teilnehmerzahl kann ruhig noch etwas wachsen, aber das wird sicherlich schon fast ganz alleine kommen, wenn wir mit der Organisation früher anfangen und der Termin dann eher feststeht.

    Mit etwas mehr Vorlauf ist es dann auch sogar noch mehr Teilnehmern möglich eigene Präsentationen zu zeigen, die ja doch etwas mehr Vorarbeit benötigen als ich dachte. Ich wollte eigentlich das Session Hijacking vorführen, aus Zeitgründen hat es dann aber doch nur für eine XSS-Lücke gereicht :-) .

    (More …)

     
  • admin 13:29 on 29.12.2008 Permalink | Reply
    Tags: .NET,   

    Veröffentlichung meiner Arbeit zu “Virtuelle Maschinen” 

    Im Jahr 2006 habe ich eine schriftliche Arbeit über vituelle Maschinen geschrieben. In dem 30-Seiten langem Dokument gehe ich zuerst allgemein auf verschiedene existierende VM-Typen ein. Dann werden verschiedene Vorteile und Nachteile aufgezeigt, immer an konkreten Beispielen wie z.B. Java oder der .NET-Plattform. Behandelt werden unter anderem die Themen Plattformunabhängigkeit, Geschwindigkeit, Speicherverbrauch, Sicherheit, Flexibilität und Sicherheit.

    Auch interessant ist der Abschnitt über die (grundlegende) Funktionsweise von Garbage Collectoren. Außerdem ist das letzte Kapitel der Ayox Intermediate Language gewidmet, eine Eigenentwicklung einer Zwischensprache (ein Mix aus Java Bytecode und CIL) mit zugehöriger Laufzeit (Interpreter, etc.).

    Download der Arbeit (pdf)


    Viel Spaß beim Lesen :-)

     
  • admin 00:38 on 24.12.2008 Permalink | Reply
    Tags: .NET, , , ,   

    Domain Specific Languages 

    Jetzt so kurz vor Weihnachten beschäftigt mich ein interessantes Thema, welches das Potenzial hat die Softwareentwicklung an einigen Stellen stark zu vereinfachen: DSL, genauer gesagt Domain Specific Languages. Darunter versteht man eine auf ein Problem zugeschnittene Sprache, wobei Sprache hier nicht unbedingt eine typische Text-Sprache wie Java sein muss. Es kann sich genauso gut um eine grafische Repräsentation handeln.

    Jeder von uns hat schon mit einer DSL gearbeitet, wir haben es nur nicht mitbekommen :-) . Denn genau genommen sind SQL als auch RegEx zwei DSLs, die besonders ausdrucksstark sind in ihrer Domäne. Mit einer RegEx kann ich String-Muster definieren, deren Programmierung in einer “normalen” Programmiersprache dutzende Zeilen benötigen würde. Für Abfragen aus relationalen Datenbanken eignen sich RegEx aber natürlich nicht, daher sagt man die Sprache ist auf eine Domäne – ihr Arbeitsgebiet – beschränkt.

    (More …)

     
  • admin 10:15 on 05.09.2008 Permalink | Reply
    Tags: .NET, Debugging, ,   

    Remote Debugging: .NET-Software mit Visual Studio unter Linux debuggen 

    Die Leute vom Mono-Projekt arbeiten gerade intensiv an dem Mono Debugger (mdb) und einem Visual Studio Plugin, mit dem Remote Debugging von .NET-Software erstmals möglich wird. Damit kann man endlich direkt aus seiner gewohnten Windows/Visual Studio-Umgebung heraus seine Programme unter Linux starten lassen und ganz normal debuggen mit allem was dazu gehört … Haltepunkte, Beobachten lokaler Variablen etc.

    Meiner Meinung nach eine geniale Sache, die sicherlich die Verbreitung von .NET-Software unter Linux stark verbessern und die Akzeptanz von Mono vergrößern wird.

    Alternativ zum Remote Debugging mit Visual Studio wird man auch bald mit MonoDevelop .NET-Software debuggen können – direkt unter Linux. Bis dato gibt es keinen integrierten Debugger für MonoDevelop 1.0, das soll sich nun aber mit Version 2.0 ändern – die zusammen mit Mono 2.0 fertiggestellt wird. Hoffentlich ist es bald so weit :-)

     
  • admin 19:47 on 19.07.2008 Permalink | Reply
    Tags: .NET, , , ,   

    NClass – Alternativer Klassendiagramm-Editor 

    Wer keine der teuren Visual Studio Versionen besitzt, kann trotzdem hübsche Klassendiagramme zeichnen und sich den Code dazu generieren lassen. Das Programm NClass erzeugt nicht nur Diagramme, die genauso gut wie die aus Visual Studio aussehen .. es kann auch etwas mehr. Beispielsweise gibt es mehr Beziehungsarten und eine Java-Unterstützung.

    Aktuell ist die Version 1.08, doch scheint die in der Entwicklung befindliche Version 1.09 schon ausreichend stabil zu sein. Diese Version bietet unter anderem eine Unterstützung für Mono (quasi Linux-Unterstützung) und einige andere coole Featuers (z.B. Zooming und schickere Diagramme).

    Das Tutorial zu dem Typo3-Such-Filter wird nächste Woche weitergehen … ich muss dazu erst einiges vorbereiten :-)

     
  • admin 23:19 on 26.06.2008 Permalink | Reply
    Tags: .NET, , Netzwerkprogrammierung   

    Lidgren Netzwerkbibliothek 

    Möchte man Netzwerkspiele oder sonstige netzwerk-fähige Anwendungen schreiben, findet man eine ganze Menge guter Bibliotheken für C++ im Internet. Im .NET Bereich ist die Auswahl jedoch nicht gerade groß, dafür gibt es eine ausgezeichnete C#-Bibliothek namens Lidgren, die fast keine Wünsche offen lässt.

    Lidgren setzt auf das Netzwerkprotokoll UDP (User Datagram Protocol), baut jedoch auch Charakterisken einer TCP-Verbindung nach, was die Bibliothek sehr flexibel macht. Man kann als Programmierer selber entscheiden wie wichtig die Daten sind, die man versendet und ob die Reihenfolge beim Empfänger genau stimmen muss.

    Die Besonderheit des UDP-Protokolls besteht ja darin, dass Pakete verloren gehen können, in einer anderen Reihenfolge ankommen können … und zu allem Überfluss natürlich auch kaputt ankommen können. Alle diese Nachteile haben allerdings den Vorteil, dass diese Übertragungsart sehr schnell ist, denn das UDP-Protokoll muss nicht ständig die Reihenfolge der Pakete überprüfen. Auch werden keine Empfangsbestätigungen verschickt und dann ggf. Pakete mehrmals versendet.

    Lidgren vereint die Stärken von UDP und TCP. Jede Nachricht, die man versendet, bekommt einen Kanal zugewiesen, der den Nachrichtentyp festlegt. Folgende Kanäle sind möglich:

    • “Unreliable unordered” – Reihenfolge der Nachrichten ist unbestimmt; Nachrichten können verloren gehen.
    • “Reliable unordered” – Alle Nachrichten kommen an; Reihenfolge ist unbestimmt
    • “Sequenced” – Nachrichten können verloren gehen; Reihenfolge wird eingehalten
    • “Ordered” – Alle Nachrichten kommen in der vorgesehenen Reihenfolge an (früher oder später)

    Die Netzwerkbibliothek beherrscht darüber hinaus noch weitere Funktionen wie das kontrollierte Drosseln des Netzwerktransfers (Bandwidth Throttling), Verschlüsselung und die Zeitsynchronisation. Auch sehr interessant ist, dass man – speziell zum Testen – einen künstlichen Lag oder eine Wahrscheinlichkeit für verloren gehende Pakete definieren kann.

     
  • admin 20:38 on 16.05.2008 Permalink | Reply
    Tags: .NET, , , ,   

    Gendarme – Alternative zu FxCop? 

    Viele kennen sicherlich die Codeanalyse von Microsoft, die auch in einige Editionen der Visual Studio Produkte integriert ist … nun gibt es eine Open Source Alternative namens Gendarme, die innerhalb des Mono Projekts entwickelt wird.

    Mit Gendarme kann man Probleme in seinem .NET-Code finden und leicht beheben. Neben echten Problemem werden von dem Analyse-Tool aber auch sehr viele Vorschläge und harmlose Warnungen angezeigt, die für ein besseres OOP-Design sorgen sollen. So meckert Gendarme z.B. bei sehr langen Methoden, deckt mögliche Threading-Probleme auf und sorgt allgemein für besseren und stabileren Code.

    Aktuell gibt es einen Assistenten, der nach dem Auswählen von .NET-Assemblies einen Report ausgibt. In Zukunft wird es sicherlich auch eine Integration in ausgewählte IDE’s geben, ein Addin für MonoDevelop ist bereits in Arbeit.

     
  • admin 23:21 on 11.04.2008 Permalink | Reply
    Tags: .NET, , ,   

    Open Toolkit 

    Vor einiger Zeit bin ich auf das Open Toolkit gestoßen, einen sehr coolen OpenGL/OpenAL .NET-Wrapper. Anders als z.B. Tao funktioniert das Toolkit bei mir auch problemlos unter Linux/Ubuntu. Außerdem bietet OpenTK zusätzlich zur normalen C-API von OpenGL/OpenAL viele High-Level-Klassen. Besonders interessant ist für mich das einfache Zeichnen von Text, der dann auch noch gut aussieht.

    Ein weiterer Pluspunkt: Es gibt ein Winforms-Control, was mit Mono und .NET gleichermaßen funktioniert und so erstmals die Entwicklung von CrossPlattform-OpenGL-Programmen mit .NET möglich macht.

    Da es bisher kein Stable-Release gibt, sind jedoch Veränderungen der Schnittstelle an der Tagesordnung. Dafür kann man aber auch noch selber Patches einsenden, um diese zu verändern. So habe ich nun beispielsweise Unterstützung für Bezier-Kurven nachgereicht, sowie die Anbindung von Mathe-Klassen an die OpenGL-API ermöglicht.

    Bekanntermaßen muss man bei vielen Matrix-Funktionen in OpenGL einen Zeiger übergeben, der auf das float[]-Array zeigt. OpenTK bringt eine Reihe von nützlichen Strukturen wie Vector3 oder Matrix4 mit, mit denen der sichere Umgang mit OpenGL problemlos möglich ist. Auch in Sprachen, die ohne Zeiger auskommen müssen – wie Visual Basic. Beispiel:

    Vector3 start = new Vector3(1.0f, 0.0f, 5.0f);
    Vector3 end = new Vector3(5.0f, 3.0f, -6.0f);
    Matrix4 projection = Matrix4.LookAt(...);
    GL.LoadMatrix(ref projection);
    GL.Color4(Color.Green);
    
    GL.Begin(BeginMode.Lines);
        GL.Vertex3(start);
        GL.Vertex3(end);
    GL.End();
    

    So einfach war OpenGL-Programmierung noch nie :-)

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
esc
cancel