Monthly Archives: July 2011

PHP-Unterstützung unter Eclipse Indigo

Posted on by

Da es z.Z. kein Paket gibt, dass einem eine direkte Installation einer PHP-Entwicklungsumgebung unter dem neuen Eclipse “Indigo” ermöglichen würde, ist ein wenig Handarbeit erforderlich.

Ich beziehe mich nachfolgend auf die Hinweise von “aaronbonner” auf der Webseite http://aaronbonner.tumblr.com/post/6035060125/installing-pdt-3-on-eclipse-3-7-indigo.

Die aktuelle Eclipse-Indigo-Version holt man sich von http://www.eclipse.org/downloads/.

Dort lädt man sich das Paket “Eclipse Classic 3.7” (in meinem Fall für 64Bit Linux) herunter und “installiert” das Paket in seinem Wunschverzeichnis durch entsprechendes Expandieren des Tar-Balls (z.B. mit ark).

Nun gilt es zunächst, Eclipse die erforderlichen Update-Sites bekannt zu machen. Wir wechseln daher über den Menüpunkt

“Help >> Install New Software … ”

auf die Seite “Available Software”. Hier klicken wir auf den Link “Available Software Sites” und fügen folgende Repository-Sites hinzu:

  • Indigo >> “http://download.eclipse.org/releases/indigo”
  • The Eclipse Project Updates >> “The Eclipse Project Updates”
  • PDT 3.0 Update Site >> “http://download.eclipse.org/tools/pdt/updates/3.0/milestones”
  • Subversive Site >> “http://community.polarion.com/projects/subversive/download/eclipse/2.0/indigo-site/”
  • Subversive Update Site >> “http://community.polarion.com/projects/subversive/download/integrations/update-site”
  • Subversive Integrations >> “http://community.polarion.com/projects/subversive/download/integrations/update-site”
  • Subversive SVN Connectors >> “http://community.polarion.com/projects/subversive/download/integrations/update-site”
  • WTP-Patches >> “http://download.eclipse.org/webtools/patches/drops/R3.1.2/P-3.1.2-20100413200422/repository/wtp-patches312-tests”

Wie man die Sites benennt, ist dabei jedem selber überlassen. Hauptsache die http-Adressen stimmen.

Danach installiert man sich die benötigten Pakete – in meinem Fall :

  • Eclipse Web Developer Tools
  • Eclipse XML Editors and Tools
  • Eclipse XSL Developer Tools
  • JavaScript Development Tools
  • JAX-WS DOM Tools
  • JAX-WS Tools
  • Native JavaHL 1.5 Implementation
  • Native JavaHL 1.6 Implementation
  • PHP Development Tools (PDT) Runtime Feature
  • PHP Development Tools (PDT) All-In-One SDK
  • PHP Development Tools (PDT) SDK Feature
  • PHP Development Tools (PDT) Source Feature
  • Remote System Explorer End-User Runtime
  • Subversion Revision graph
  • Subversive SVN Connectors
  • Subversive SVN JDT Ignoe Extensions
  • Subversive SVN Team Provider
  • Subversive SVN Team Provider Connectors Sources
  • SVNKit 1.2.2
  • SVNKit 1.3.3
  • SVNKit 1.3.5
  • Web Page Editor
  • WST Server Adapters
  • Axis2-Tools
  • Dynamic Languages Toolkit – Mylyn Integration
  • JST Server Adapters
  • JST Server UI
  • Mylyn Commons
  • Mylyn Context Connector: Eclipse IDE
  • Mylyn SDK
  • Mylyn Task List
  • Mylyn Task-Focused Interface
  • PDT Mylyn Feature
  • Subversive SVN Integration for the Mylyn Project
  • Target Management Terminal

Am wichtigsten sind hier natürlich die PDT-Pakete. Für die SVN-Anbindung
sind die Subversion-Pakete und Konnektoren wichtig. Wer Task-orientiert arbeiten will, sollte auf die Mylyn-Pakete zurückgreifen.

Viel Spass dann mit Eclipse Indigo und der zugehörigen PHP-Unterstützung !

Blender: Seeking Yellow – reloaded

Posted on by

In meiner Freizeit befasse ich mich immer mal wieder gerne mit Simulationsprogrammen. So hatte ich ein paar Jahre lang viel Freude an dem “Windows”- und “Apple”-Programm “Bryce”. Blender erschien mir – gemessen an meinen unprofessionellen Interessen – zu komplex und bzgl. einer Einarbeitung zu aufwendig. Jetzt habe ich mal wieder einen Anlauf unternommen und mich mit der Blender-Version 2.5 auseinandergesetzt. Als Einstieg habe ich ein Thema aufgegriffen, dass ich früher schon einmal mit Bryce behandelt habe.

Ein 3D Raytracing-“Experiment” mit Bryce

Vor ein paar Jahren hat mich Michael Grossmann anläßlich eines seiner Kunstprojekte auf eine interessante “Problemstellung” für Simulationsprogramme aufmerksam gemacht:

Was geschieht wenn man grüne und rote Glasscheiben übereinander legt? Und was geschieht im Gegensatz dazu, wenn man Schichten aus selbstleuchtenden Gasen übereinander legt?

In entsprechenden Experimenten kann man den Unterschied zwischen “aktiver” und “passiver” Farbmischung studieren. In der Malerei, beim Druck, aber auch in Photobearbeitungs- oder Publishing-Programmen beschäftigt man sich vor allem mit der passiven Farbmischung, während z.B. die Bilderzeugung auf LCD-Schirmen auf dem Prinzip der aktiven Farbmischung beruht. In vielen Fällen führt deshalb das Arbeiten am PC schnell auf eine Einbahnstraße vom RGB-Farbraum zum druckrelevanten CYMK-Farbraum. Gerade aus künstlerischer Sicht interessiert am PC die “aktive” Farbmischung als eigenständiges Thema leider kaum.

Ein paar “Versuche” mit Photoshop und danach Bryce haben Michael und mich 2003 dazu veranlasst, das Thema “aktive” Mischung in 3D mal anhand folgender konkreter Fragestellung anzugehen:

Was geschieht, wenn man einen Quader aus selbstleuchtendem roten Gas in eine passende, asymmetrisch positionierte Ausbohrung in einen Quader aus selbstleuchtendem grünen Gas setzt? (Beide Gase seien transparent.)

Die Physik und Grundlagen der menschlichen Farbwahrnehmung sagen einem, dass man auf diesem Wege – je nach Dicke der betrachteten grünen oder roten Schichten – ein Farbspektrum von Rot über Orange, Gelb, Grün erzeugen können muss – je nachdem wie sich die Lichtstrahlen aus den farbigen Gasbereichen überlagern. Faktisch sollte bei einer asymmetrischen Konfiguration der Blickwinkel dafür ausschlaggebend sein, was man sieht.

Michael und ich haben damals die Raytracing-Methoden von Bryce zur wirklichkeitsnahen Simulation dieser Aufgabenstellung angewendet. Die gewünschten selbstleuchtenden Gase habe ich mit Hilfe des äußerst vielseitigen Materialeditors von Bryce erzeugt. Siehe zu den Ergebnissen unserer Simulationen :
seeking yellow

von_der_Kante_635

So akademisch die ganze Idee anmuten auch mag – sie ist in mehrerlei Hinsicht interessant: physikalisch, künstlerisch, philosophisch – denn aus entsprechenden Simulationen kann man einmal mehr etwas darüber lernen, das nicht alles so ist, wie es zu sein scheint und dass die Bilder, die unsere Sinneswahrnehmung in unserem Bewußtsein erzeugt, “künstliche”, durch unser Gehirn und Sinnesverarbeitung vorinterpretierte Bilder sind. Obwohl wir etwas “Gelbes” im Zentrum unserer simulierten “Versuchsanordnung” sehen, sendet keines der simulierten Objekte einen gelben Lichtstrahl aus! Zur Erklärung siehe den obigen Link.

Simulationstechnisch hat die Aufgabenstellung einiges zu bieten: Mit Hilfe
geeigneter Simulationsprogramme wie Bryce kann man hier etwas darstellen, was technisch nur schwer zu realisieren wäre. Und ferner erlaubt uns Bryce, eine Kamera in die Gas-Objekte hinein zu bewegen und Blickwinkel aufzunehmen, die in einer realen Welt kaum zugänglich wären. Ferner steht entsprechenden Kamerafahrten durch die Gaskörper nichts im Wege. Und nicht zuletzt macht die Sache Spass – denn die Ergebnisse können farblich wirklich spektakulär sein. Siehe hierzu die Bilder unter seeking yellow

Blender statt Bryce

Trotz meines Fables für Bryce fanden Michael und ich es als Linux-Anhänger damals etwas ärgerlich, dass wir es nicht geschafft haben, unser “seeking yellow”-Projekt mit Opensource-Programmen durchzuziehen. Im besonderen kamen wir mit dem Material-Editor der damaligen Blenderversion nicht klar.

Außerdem gab es damals einige Leute, die das Ergebnis der Simulation schlichtweg für Unsinn erklärt haben, da sie mit aktiver Farbmischung nicht vertraut waren. Daher erschien es uns wichtig, die Ergebnisse unseres “Ray-Tracing-Experiments” durch ein unabhängiges Simulationsprogramm bestätigen.

Vor ein paar Tagen habe ich deshalb erneut versucht, unsere damaligen “Experimente” ansatzweise mit “Blender” in der Version 2.5 nachzuvollziehen.

Dieses Unterfangen erwies sich als viel leichter als anfänglich vermutet. Blender bestätigt die früheren Ergebnisse der Bryce-Simulationen von Michael und mir in vollem Umfang. Zudem können wir nun viel einfacher und ganz ohne Windows auch komplexe Konfigurationen studieren.

Diese “Experimente” mit Blender mögen auch für andere interessant sein. In einigen weiteren Artikeln in der Kategorie “Blender” dieses Blogs werde ich beschreiben, wie man etwa zu folgenden Bildern kommt:

cube_in_cut_cube_rundinger_110719

cubes_cut_and_uncut_110718_640

cubes_cut_and_uncut_uten_env_map_110718_opt

metaball_sphere_in_cube_110717_3

cube_in_cut_cube_rundinger_110719_opt

Obwohl in diesen Ansichten einer Kombination von roten, grünen, blauen Quadern oder Kugeln eingesetzt wird und alle möglichen gelben, orangen und violetten Farben erscheinen, gibt es im ganzen “Versuchsaufbau” der Simulationen kein einziges Objekt, das gelbe oder violette Strahlen aussenden würde. Aber in einer 3D-Welt mit aktiven Farbmischungen ist eben so einiges
möglich. An anderen Beispielen kann man zudem zeigen, dass es mit einfachen eckigen Körpern gelingen kann, runde kaustik-ähnliche Kurven zu erzeugen.

Optik in 3D macht Spaß mit Blender !

Eclipse – zu langsam bei großen Dateien?

Posted on by

Muss nach einer längeren Pause mal wieder intensiv mit PHP entwickeln. Bei dieser Gelegenheit habe ich mich wirklich über einen größeren Bug in Eclipse Helios geärgert.

Das Problem unter Eclipse Helios

Dieser Bug betrifft das Editieren großer Dateien und gliedert sich eigentlich in 2 Teile:

  • Die Reaktionsgeschwindigkeit des Editors beim Tippen nimmt mit zunehmender Größe der Dateien immer schneller ab. Die getippten Buchstaben erscheinen nur erheblich verzögert am Schirm. Oberhalb 5000 Zeilen pro Datei ist der Eclipse eigene PHP Editor nicht mehr zu gebrauchen.
  • Parallel zum Tippen beginnt Eclipse offenbar den gesamten Code des Files auf potentielle Fehler zu untersuchen. Die CPU-Belastung ist hierbei enorm.

Leider kann man sich nicht immer aussuchen, wie groß die Dateien sind, mit denen man arbeiten muss. Und dann wird der Eclipse Editor unter Helios wirklich zu einer Arbeitsbehinderung.

Siehe hierzu auch https://bugs.eclipse.org/bugs/show_bug.cgi?id=326261. In den Beiträgen zum Bug wird als Zwischenlösung empfohlen, das Syntaxcoloring abzuschalten. Ferner gibt es einen etwas schwierig einzuspielenden Patch.

Lösung 1: Wechsel zu Eclipse Indigo

Ich habe gestern auf meinem Laptop die neue Eclipse Version Indigo installiert. Nach einem Tag intensiver Arbeit kann ich diesen Schritt jedem empfehlen, der von dem beschriebenen Problem betroffen ist. Unter Indigo ist der erste der beiden Punkte tatsächlich behoben. Man kann auch bei relativ großen Dateien wieder fließend tippen.

Allerdings folgt auf das Editieren weiterhin eine längere Orgie der Dateianalyse mit sehr hoher CPU-Belastung. Wohl dem, der hier mehrere CPU-Cores zur Verfügung hat.

Wie ich von Helios zu Indigo übergegangen bin, beschreibe ich in einem nachfolgenden Artikel.

Lösung 2: Kompaktere Codes – kompaktere Klassen

Ein Gutes hat der “Bug” ja vielleicht: Um die Code-Dateien zu verkleinern, beginnt man immer öfter, über den Aufbau und die Struktur der eigenen Klassen nachzudenken.

Ich habe jedenfalls bei meinen eigenen Klassen, in denen sich über die Jahre hinweg immer mehr Methoden angesammelt haben, begonnen, bestimmte Variablen bzw. Methoden besser zu gruppieren, in separate Repräsentations- und Funktionalklassen zu bündeln und dann auszulagern. Bei Bedarf instanziiert die ursprüngliche Klasse dann entsprechende Objekte. Hierzu gibt es je nach Situation mehrere brauchbare Entwurfsmuster.

Eine einfache Variante, die die Struktur der wachsenden Klassen weitgehend aufrechterhält, ist die Delegation der Aufgabe in der Form, dass man die bisherige Methode in der Hauptklasse belässt, aber die Aufgabe selbst auf den Aufruf eines Funktionalklassen-Objekts und dessen entsprechende Methode verschiebt. Die zu manipulierenden Variablen werden dabei ggf. von der ursprünglichen Hauptklasse selbst wiederum als Objekt übergeben. Da diese Übergabe immer “by reference” geschieht, wird der Bedarf an Speicher nicht wesentlich erhöht. Die Klassen-Codes werden bei einem solchen Vorgehen i.d.R. sehr viel kompakter.

Denen, die sich mit Entwurfsmustern intensiv beschäftigen möchten, sei bei dieser Gelegenheit übrigens das Buch “PHP Design Patterns” von Stephan Schmidt (http://www.phpdesignpatterns.de/auflage-2/#buch) allerwärmstens empfohlen. Ich jedenfalls entdecke immer wieder neue “Offenbarungen” in diesem Buch.

Ein anderer Weg zu überschaubaren Dateien führt ggf. über eine klarere Unterteilung der Vererbungshierarchie.

Content Assistance bei verteiltem Code

In beiden Fällen ist es bzgl. der Unterstützung (Content Assistance) beim Coding sinnvoll, sich im Editor auch Variable aus anderen Dateien vorschlagen zu lassen. Hierzu muss amn den entsprechenden Haken unter dem Menüpunkt

"Window >> Preferences >> PHP >> Editor >> Content Assist >> Show Variables from other files"

setzen.

.