|
|
|
|
|
|
|
Das .NET Microframework braucht aber kein Windows 
|
|
|
|
|
|
|
|
|
|
|
Very funny.... veeeeeerrrryyy funny.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von rABBI
richtige-version-der-scheiß-libyaml-wrapper-script-datei-suche beschäftigt, als dass ich code hätte bauen können. geschweige denn gibt es irgendwo hoster, die ruby unterstützen. das gibts ja schon für python kaum. | |
Man bekommt zwar für wenig Geld schon einen V-Server der locker die Leistung bringt um sowas zu hosten, aber gut, da muss man sich drum kümmern.
Aber mir ist gerade eingefallen: Es gibt imho keine schnelle FastCGI Implementierung für Python. Es gibt zwar welche die in Python geschrieben sind, aber dann macht sich die Geschwindigkeit von fcgi wieder kaputt.
Ja, es gibt mod_python, aber mod_[sprache] sind mir nicht so lieb, weil man da meist auf abschottung durch andere module verzichten muss.
Verdammt, muss ich mir das etwa selber schreiben?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SirSiggi
Very funny.... veeeeeerrrryyy funny.
| |
Im Disney World solle es eingesetzt werden - bei den Ticketprüfmaschinchen. 
|
|
|
|
|
|
|
|
|
|
|
|
Und macht das das .Net Framework universell Einsetzbar?
|
|
|
|
|
|
|
|
|
|
|
Absolut - wenn Disney es benutzt kann es nicht böse sein!
|
|
|
|
|
|
|
|
|
|
|
|
Es geht nicht um gut und böse, sondern um die technische Einsetzbarkeit, wenn man sich nicht auf Windows beschränken kann oder will. Ganz egal von wem es stammt, selbst wenn es vom Teufel oder Gott persönlich käme würde das nichts ändern.
|
|
|
|
|
|
|
|
|
|
Du hast aber auch heute wieder eine Laune.
Die technische Einsetzbarkeit ist vor allem auf Windows vorbehalten. Auch wenn Mono auf einem netten Weg ist, hat MS immer wieder andere Techniken eingebaut.
Mit .NET 3.0 haben sie was nettes geschaffen - was aber wohl noch eine sehr lange Zeit warten muss bis es (wenn überhaupt) mit Mono läuft.
Silverlight, Microsofts neustes Kind mehr oder weniger, läuft zwar auch unter Linux (jedenfalls Serverseitig), aber nicht alles und dieses Browser-PlugIn werden sie auch nicht dafür anbieten.
Die Plattformunabhängigkeit von .NET bezweifel ich mal - außer man versteht unter Plattformunabhängig: Win 2000 - Vista & Mobile.
Aber was schick gemacht ist, dass .NET Sprachunabhängig ist.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [C.I.] Reman am 24.05.2007 8:47]
|
|
|
|
|
|
|
|
|
Die Technik .Net finde selbst ich toll. Das sage ich ganz ohne Befangenheit und Trollerei. Nur will ich nicht akzeptieren das Künstliche Barrieren geschaffen werden, die ohne Microsoft kaum zu überwinden sind. Deswegen werde ich persönlich es (sollte ich nicht müssen) es nicht einsetzen.
Übrigens ist Java genauso Sprachenunabhängig. Es gibt mittlerweile zig Sprachen für die JVM. Bloß bei Java hat Sun geschlafen. Hätten sie von vorneherein den Weg eingeschlagen, den sie jetzt bestreiten, wäre Java heute viel weiter.
/e: Im Falle Java <-> .Net wird mal wieder ziemlich deutlich: Konkurrenz belebt das Geschäft.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von SirSiggi am 24.05.2007 8:52]
|
|
|
|
|
|
|
|
|
Sun hat zwei Fehler gemacht:
- Die OpenSource Community zu lange ignoriert
- Ihre VM genau so genannt wie die Sprache
Ersteres haben sie mitlerweile ausgebügelt und sich um 180° gedreht.
Letzteres mag unwichtig anmuten, ist es aber nicht. Wenn jemand "Java" sagt, denn nahezu jeder an die VM und die Sprache (oder eine Mischung daraus). Das "Problem" gibt es bei .NET <-> C# zwar teilweise auch, aber dort ist es nicht so extrem weil es diese beiden begriffe gibt die klar getrennt sind.
|
|
|
|
|
|
|
|
|
|
|
|
Ich würde das nicht an OpenSource festmachen, sondern schlicht daran das Sun es nicht geschafft hat seine VM schnell an den Mann zu bringen. Erst in den letzten Jahren ist eine JVM auf den Desktops zum Standard geworden.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SirSiggi
| | Zitat von rABBI
ja! JA! JAJAJAJAJAJA!
ich will problemlos mehrdimensionale arrays anlegen, einfach indem ich sie anspreche! und mit namentlich bekannten schlüsseln als auch über zahlen! und durchiterierbar. und zum kaputtsortieren mit kruden funktionen! | |
Junge, nimm Ruby, bleib sauber und trotzdem glücklich.
| | Zitat von rABBI
[b]ich bin halt vom "ich hack das jetzt rein. das ist hässlich aber funktioniert." verwöhnt. | |
Junge, nimm Ruby, bleib sauber und trotzdem glücklich. Und streich das hässlich.
| | Zitat von rABBI
[b]perl hat kurze, nicht merkbare standardvariablen. perl ist im gegenzug nicht so sexy durchobjektiert wie ruby (das ich lieben würde, wenn es ausgereift wäre). perl ist nicht so einfach zu lesen wie python. perl ist nicht mit so wenig denksleistung zu schreiben wie php. perl hat ne ganze menge nachteile. die frage ist, wann die vorteile überwiegen.
| |
Was ist denn an Ruby nicht ausgereift? Ruby ist überaus stabil und durch die rubygems findet man auch für fast jede mögliche Aufgabe schon eine fertige Lösung die man nur noch einsetzen muss.
Okay, bleibt noch das Ruby etwas langsamer ist als Perl und Python und PHP was aber in der Realität entweder nicht auffällt, nicht stört , oder mit Ruby 2.0 und der Integration von YARV behoben wird.
| |
Ok, jetzt kommt der Bash Post! 
| |
| PHP: |
$struktur =
[ # erste Ebene, Array
1, # Simple Einträge
2, # Ansprechpar mit
3, # $struktur->[1]
"Hallo",
[ # zweite Ebene, Array
"1.1",
"1.2", # $struktur->[4]->[0]
"1.3",
{ # dritte Ebene, wir mogeln einen Hash unter
Key1 => "Value1",
Key2 => "Value2",
Key3 => [ # oha, ein Array als Value ;)
"4.1",
"4.2", # $struktur->[4]->[3]->{Key3}->[1]
"4.3",
"4.4"
]
Key4 => "Value3",
Key5 => { # Zack, noch ein Hash
SubKey2 => "SubValue2",
SubKey1 => "SubValue1",
SubKey4 => "SubValue4",
SubKey3 => "SubValue3" # $struktur->[4]->[3]->{Key5}->{SubKey3},
}
}
],
"Noch ein normaler Wert" # $struktur->[5]
];
|
|
Und jetzt wollen wir den Tiefsten geschachtelten Hash sortiert nach seinen Schlüsseln ausgeben:
| |
| PHP: |
my @sortedKeys = sort { $b cmp $a } keys %{$struktur->[4]->[3]->{Key5}};
foreach my $key (@sortedKeys) {
print "Key '$key' => '" . $struktur->[4]->[3]->{Key5}->{$key} . "'\n";
}
|
|
Oder Evtl. will ja jemand an den Ende des tiefsten geschachtelten Arrays ein paar Element hinzufügen?
| |
| PHP: |
push(@{$struktur->[4]->[3]->{Key3}}, "Element1", "Element2", "Element3");
|
|
Ja, man kann Sogar ganz hinten bei den SubKeys noch ein Objekt reinpacken wenn man gerne mag:
| |
| PHP: |
use CGI;
$struktur->[4]->[3]->{Key5}->{"CGI Objekt"} = CGI->new();
print $struktur->[4]->[3]->{Key5}->{"CGI Objekt"}->header();
|
|
Und jetzt wollen wir unsere gewachsene Struktur evtl. serialisieren und zwar mit dem darin verschachteltem Objekt und dessen aktuellen Objektzustand (also auch die Membervariablen):
| |
| PHP: |
use Data::Dumper;
open(my $dump, ">/tmp/dump.perl") or die "Can't open dumfile: $!";
print $dump Dumper $struktur;
close($dump);
|
|
Was kann man denn noch mehr wollen?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GH@NDI am 24.05.2007 9:15]
|
|
|
|
|
|
|
|
|
|
Eine Lösung ohne 1000 Klammern und Pfeile.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SirSiggi
Erst in den letzten Jahren ist eine JVM auf den Desktops zum Standard geworden. | |
Auf welchem Planeten? 
| | Zitat von GH@NDI
Was kann man denn noch mehr wollen? | |
Das alles ein Objekt ist.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Achse-des-boesen am 24.05.2007 9:22]
|
|
|
|
|
|
|
|
|
Erde? So jedenfalls meine Erfahrung.
Klar ists noch immer nicht auf jedem Rechner, aber es hat heute keiner mehr ein Problem damit 15MB runter zu laden wenn eine 200kb Java-Applikation gestartet werden soll.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SirSiggi am 24.05.2007 9:23]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Achse-des-boesen
| | Zitat von SirSiggi
Erst in den letzten Jahren ist eine JVM auf den Desktops zum Standard geworden. | |
Auf welchem Planeten?
| | Zitat von GH@NDI
Was kann man denn noch mehr wollen? | |
Das alles ein Objekt ist.
| |
Und wer denkt an den Overhead?
Objektorientiertheit schön und gut. Aber wenn primitive Datentypen nur noch als Objekt zur Verfügung stehen finde ich es einfach etwas weit gesponnen.
|
|
|
|
|
|
|
|
|
|
|
Pfff... Hardware ist günstig.
/e: Übrigens ist z.B. Ruby mit yarv (Yet another Ruby VM, das ja in Ruby gemerged werden wird) gar nicht mehr so viel langsamer als Perl. Ich muss mal diesen komischen Vergleich raussuchen. Klar, die Speichernutzung ist trotzdem höher.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SirSiggi am 24.05.2007 9:41]
|
|
|
|
|
|
|
|
|
| | Zitat von SirSiggi
Eine Lösung ohne 1000 Klammern und Pfeile.
| |
Die Pfeile werden in Perl6 durch Punkte ersetzt. Kommentar von Larry Wall
| |
-> becomes ., like the rest of the world uses.
| |
Perl6 Synopsis3
// Ach, und wenn du wirklich für normalsterbliche aufbaubare Strukturen haben willst, dann nimm halt YAML
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GH@NDI am 24.05.2007 9:46]
|
|
|
|
|
|
|
|
|
Ich wusste es. Es gibt 4 Python-FastCGI implementierungen und sämtliche sind in Python geschrieben.
Ich hab gerade mal in eine reingeschaut und da wird lustig mit Bitweisen Operatoren gearbeitet. In Python.
Meine Güte, ist das ineffizient... 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SirSiggi
An stelle zu motzen hättest du mich vieleicht mal fragen sollen. Ich kann mich nicht erinnern jemals ernsthafte Library-Probleme gehabt zu haben und sowohl der Interpreter an sich als auch rubygems haben immer wunderbar funktioniert. Hoster die Ruby unterstützen gibt es, aber natürlich nicht wie Sand am Mehr. | |
hab ich. sowohl hier als auch im rubyforum.
| | Der einzige Punkt wo ich (wie ich schon häufiger erwähnt habe) dir Recht geben muss ist die Sache mit der Dokumentation. Es existiert zwar so gut wie immer eine brauchbare, aber man sucht sich manchmal schon zu Tode.
| |
ich hab für die xml-sachen nirgends sinnvolle doku gefunden. alles nur grob angerissen mit kommentar "kommt später".
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SirSiggi
Es geht doch gar nicht ums Anlegen, sondern um das dynamische Erweitern von Arrays und Hashes mit weiteren Ebenen. Das ist in Perl unnötig kompliziert. Punkt.
| |
Dann lässte den -> halt einfach weg
| |
| PHP: |
my @a = (
[1,2,3],
[4,5,6],
[7,8,9]
);
print $a[1][2];
|
|
Ich persönlich schreibe ihn aber lieber. Dadurch wird einfach deutlicher das es sich bei $a[1] um eine Array REFERENZ handelt, also keinen normalen Array den man z.B. so mal eben mit den üblichen Array-Funktionen bearbeiten könnte.
// Zugegeben, da sind objektoirentierte Datentypen im vorteil, wenn du einfach mal mittels $array[] = "neuer wert"; was hinzustopfen kannst.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GH@NDI am 24.05.2007 9:52]
|
|
|
|
|
|
|
|
|
Naja, XML Parsing in Ruby ist auch in gewisser Weise unschön, weil die schöne Lösung (Rexml, wirklich Simpel) nur für kleine Datenmengen funktioniert (oder man sich mal in Streamparsing mit Ruby einlesen müsste, sollte wohl nicht so schwer sein) und die hässliche Lösung libxml einfach hässlich und undokumentiert ist (ich hab ca 2 Stunden gebraucht um die einzelnen Posts aus der XML Datei zu fischen, was für sowas simples eigentlich viel zu lang ist).
Der Schuss hat definitiv gesessen.
Vorhin war aber die Rede von yaml, und das ist nun wirklich kein Problem:
require "yaml"
| | Zitat von GH@NDI
// Zugegeben, da sind objektoirentierte Datentypen im vorteil, wenn du einfach mal mittels $array[] = "neuer wert"; was hinzustopfen kannst.
| |
Das ginge doch auch in Perl. Es gibt in Perl soviel Shortcuts für jeden Kleinmist, dann könnte man das ja auch integrieren.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von SirSiggi am 24.05.2007 9:55]
|
|
|
|
|
|
|
|
|
|
als hier die statistikdiskussion angefangen hat, wollte ich das in ruby machen. macht nix, wenn du dich nichtmehr erinnern kannst, ist schon ne weile her. auf meinem laptop mit ubuntu wollte yaml einfach nicht, der hat dauernd irgendwelche probleme in den wrappern. und auf meinem desktop mit xp läuft ruby, aber sobald rails oder gems einbezogen wird, kriecht die kiste als gäbs nix gutes. das ist einfach mal kein laufverhalten.
|
|
|
|
|
|
|
|
|
|
|
Na dann sind jetzt ja wieder alle etwas glücklicher.
Bleibt nur noch abzuwarten, bis rABBI kommt und ihn auf meinen Post verweisen
// Mensch, der ist ja schon seit 2.Posts da
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GH@NDI am 24.05.2007 9:57]
|
|
|
|
|
|
|
|
|
|
Nunja gut, ich kenne diese Probleme nicht, aber ich traue dir auch die "Ruby-Situation" objektiv zu bewerten. Ich hatte selbst unter Windows keine Probleme mit Ruby, aber da hatte ich kein Rails laufen. Gems ging ohne weiteres wie unter Linux auch. Belassen wir es dabei.
|
|
|
|
|
|
|
|
|
|
|
|
was die mehrfachen vergleiche hintereinander angeht: python ist da sehr sexay.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SirSiggi
Naja, XML Parsing in Ruby ist auch in gewisser Weise unschön, weil die schöne Lösung (Rexml, wirklich Simpel) nur für kleine Datenmengen funktioniert (oder man sich mal in Streamparsing mit Ruby einlesen müsste, sollte wohl nicht so schwer sein) und die hässliche Lösung libxml einfach hässlich und undokumentiert ist (ich hab ca 2 Stunden gebraucht um die einzelnen Posts aus der XML Datei zu fischen, was für sowas simples eigentlich viel zu lang ist).
Der Schuss hat definitiv gesessen.
Vorhin war aber die Rede von yaml, und das ist nun wirklich kein Problem:
require "yaml" | |
Ich würde wetten, dass yaml genau die gleich Probleme beim skalieren hat, wie die XML-Libaries, die nicht auf Streamparsing basieren.
Das ganze ist zum einen ein Prinzipproblem: Hat man eine Datenstruktur die irgendwie hirachisch ist und will sie in Objekten abbilden, so muss man sie einmal komplett durchlaufen und im Speicher ablegen[1]. Das dauert für große Datenmengen nunmal eine Zeit und außerdem bläht es den Speicherverbrauch auf.
Die andere Option ist Streamparsing. Die wiederrum ist nur brauchbar einsaetzbar, wenn man
- die Datenstruktur kennt
- viele Objekte aus der Struktur braucht für die man mehr oder weniger das gleich machen will
- einen gewissen Aufwand betreibt, da man schließlich so Sachen wie Syntaxfehler abfangen muss ohne zu crashen
Man muss ganz einfach zu Entwicklungszeit schon wissen, mit welchen Datenmengen man später umgehen muss. Wenn man dass nicht kann muss man raten.
--
[1] Ein Beispiel ist da die Kabelverlegungssoftware eines großen Automobilkonzerns. Die Anwendung ist komplett in C# geschrieben und basiert auf NET 2.0. Die Dateien werden komplett als XML abgelegt. Die XML-Dateien sind 500MB und größer (und werden in Zips gespeichert damit sie nicht soviel Platz brauchen ). Wenn man eine Datei öffnet, braucht die Workstation (eine wirklich fixe Windows XP Maschine im oberen 3GHZ Bereich mit 4GB Ram) Minuten(!) um das Ding zu laden. Speichern dauert genau so lange. Das ist für mich das perfekte Beispiel wie man XML nicht einsetzen sollte. Gut, die komplette Anwendung braucht entpackt nur 50MB Platz, vergleichbare Software bewegt sich da in einem 10fachen Bereich. Dafür hat die vergleichbare Software Binärformate und speichert die Daten in Dateien die keine 30MB sind.
[1]-2: Ich wünschte mir eine Libarie die Stream und Objektzugriff kombiniert. Man macht etwas wie xml->root->person->name und bekommt das Objekt ohne das die XML-Datei vorher komplett geparst wird. Erst beim eigentlich Zugriff auf die Daten, wird der Baum durchsucht. Der Baum wird dann natürlich entsprechend gecacht, so dass der nächte Zugriff auf eine ähnliche Struktur viel schneller geht. Problem dabei ist, dass man dann nicht mit realen Objekten arbeiten kann, da sie ja noch garnicht existieren, sondern erst im Laufe des Zugriffs erzeugt werden. Das wiederum dürfte in den meisten Sprachen völlig unmöglich sein, denn dazu müsste man sich quasi bis auf unterste Speicherebene durchhacken, damit ein Objektorientierte Zugriff auf nicht exisitierende Objekte möglich ist.
Man könnte das alles noch Optimieren, indem man vorher die XML Kurz durchläuft und die Bytepositition von ein paar Dingen abspeichert. Das würde dann zwar eine verdammte Menge an Seek-Magic erfordern, aber prinzipiell sollte es möglich sein.
--
/: Mir fällt gerade auf: Wenn man meine Posts liest und es nicht besser weiß, könnte man glatt meinen ich hätte Ahnung von dem was ich erzählen
//: Kann es sein das meine Posts quantitativ gesehen ein wenig übertrieben wirken?
///: Ein Blick in die Statistik beweist: Längenmäßig sind meine Posts in der Spitzengruppe nur von Ghandi übertroffen. Und der hat weniger Posts als ich (wenn man meinen alten Account mit einrechnet sogar über 100 weniger )
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von Achse-des-boesen am 24.05.2007 10:27]
|
|
|
|
|
|
|
|
|
Weiß eigentlich jemand, wie schnell die XML-Implementierung in Java ist? Ich hab auf der Arbeit folgendes Szenario:
5MB Xml werden in ca. 60MB Xml tranformiert. Das dauert auf der Workstation (3Ghz Dual Core (Pentium D), 1GB Ram, XP) ca. 2 Minuten und 40 Sekunden. Auf dem Server (4*Xeon mit je 2 Kernen, Takt ist mir gerade nicht bekannt, vermute aber mal so 2.4 Ghz je Kern) ungefähr VIER Stunden. Der Unterschied ist, dass auf dem Server Java zur Transformierung genutzt wird und unter Windows MSXML (also innerhalb von Visual Studio). Ein Problem hab ich schon ausgemacht, denn Java nutzt nur einen der (insgesamt) 8 Kerne. (Achso Server läuft mit Suse Linux). An der Optimierung arbeite ich noch, aber dennoch ist der Zeitunterschied ja enorm.
Achso, habe gestern entdeckt, dass Generics in C# auch insofern die Signatur beeinflussen, als dass ich schreiben kann.
| |
| Code: |
struct CrossProduct<E, Z>...
struct CrossProduct<E, Z, D>...
struct CrossProduct<E, Z, D, V>...
|
|
Das find ich echt prakisch 
|
|
|
|
|
|
|
|
| Thema: Gehirnsalat ( wir unter uns ) |
![[dk]peacemaker](./avatare/[dk]peacemaker.gif)