Seite 1 von 2

Verfasst: Samstag 18. November 2006, 23:47
von sape
BlackJack hat geschrieben:Selbst an `os.path.sep` zu splitten hat den Nachteil, dass man damit nicht alle gültigen Pfade korrekt verarbeiten kann. `os.path.split` kommt auch damit klar wenn der Pfad `os.path.sep` und `os.path.altsep` gemischt enthält und auch wenn mehrere Pfadtrenner direkt aufeinander folgen.
BlackJack hat geschrieben:[...]
Kommt mit beiden Pfadtrennern zurecht und auch mit Wiederholungen. Aber irgendwas wichtiges habe ich sicher vergessen.
Irgendwie verstehe ich nicht recht was du meinst: Warum kommt os.sep nicht mit allen Pfaden klar? Was meinst du mit gemischten Pfaden?
EDIT: Bei mir funktioniert os.sep oder ich übersehe irgendwas wichtiges.

Verfasst: Sonntag 19. November 2006, 00:03
von BlackJack
Unter Windows kannst Du zum Beispiel den Pfad hier angeben:

r'c:\tmp/bla\\test//spam\\\viking///eric'

Das sind sechs Komponenten mit zwei verschiedenen Pfadtrennern. Und wenn man einen Pfadtrenner mehrfach wiederholt, dann zählt der nur einmal. Das berücksichtigt `os.path.split()` alles. Einfach an r'\' splitten bringt in diesem Fall ein falsches Ergebnis.

Verfasst: Sonntag 19. November 2006, 00:08
von sape
Achso, du meinst die ganze zeit folgende Zeile:

Code: Alles auswählen

path_remaining.rsplit(os.sep, reduce_range) 
OK, stimmt, rsplit würde dann nur nach dem Separator im os.sep den Pfad splitten.

Verfasst: Sonntag 19. November 2006, 00:24
von Leonidas
XtraNine hat geschrieben:WoNaDos ist ein User im Ruby forum.
WoNáDo ist auch in diesem Forum.

Und was Turing-Vollständigkeit heißt wurde im Ruby-Forum auch schon diskutiert.

Verfasst: Montag 20. November 2006, 00:22
von sape
Hi.

Ich hab mal alles in einem Modul zusammengefasst mit Dokumentation. (Docstrings wie gehabt für epydoc mit Markup).

Hab das Modul reducex.py genant. Das x soll für alle möglichen Datentypen stehen. Momentan sind ja nur 3 Funktionen vorhanden die Strings reduzieren. Mit reinkomme soll aber auch was für integer usw. Daher reducex.

Link: reducex.py - 1.0.0

EDIT: Hab das mal im ersten Post hinzugefügt und die Headline vom Thread angepasst.

Verfasst: Montag 20. November 2006, 13:24
von jens
btz. Zeile 100 ist zu lang... Ich hab es korrigiert, siehe diff: http://paste.pocoo.org/compare/171/

Edit (Leonidas): Diskussion über die GPL in den Thread GPL als Druckmittel verschoben.

Verfasst: Mittwoch 22. November 2006, 13:48
von lunar
Leonidas hat geschrieben:
lunar hat geschrieben:Und wenn es nur proprietäre Module gibt,


Ich hoffe, dass ich diesen bedauerlichen Zustand zu meinen Lebzeiten nicht erleben muss... ;) Muss dich leider enttäuschen: madwifi, ltmodem, und die ganzen AVM ISDN-Sachen sind alle proprietär.
Schon, aber noch gibt es ja freie Treiber, wenn auch nicht für jede Hardware. Mit ein Grund, warum hier bei mir kein ISDN werkelt...
Leonidas hat geschrieben:
lunar hat geschrieben:Es mag sein, dass das arrogant klingt, aber ich frage mich, warum die Hersteller ihren Treiber nicht einfach unter die GPL stellen und in den Kernel Tree aufnehmen lassen?
Weil das nicht immer mit allem funktioniert? (Außerdem vermute ich, dass wenn man sich den Quelltext von den NVidia und ATI-Treibern ansehen würde, würde man feststellen, dass es Sondermüll ist). Siehe Natscape.. wie lange haben die Entwickler für Mozilla 1.0 gebraucht? Und Erfolg hatten sie sowieso erst mit Firefox.
Da hast du einen weiteren Vorteil genannt: Proprietären Sondermüll kann den Kernel unerkannt verschmutzen, im Kernel würde derartiger Müll sicherlich durch etwas saubereres ersetzt. Das würde vielleicht am Anfang nicht funktionieren, aber kontinuierlich verbessert werden, bis es dann irgendwann läuft.
Dass dieses System funktioniert, zeigt imo die Erfahrung. Ich hatte mit den freien Treibern noch nie Probleme. Dateisystem, Festplatte, Netzwerkkarte, Soundkarte, CD Laufwerk, etc. funktioniert alles ohne Probleme. Das einzige, was ab und zu Schwierigkeiten machte, war der fglrx Treiber, der unter anderem das ordnungsgemäße Beenden des X Servers verhindert (zumindest bei mir).
Leonidas hat geschrieben:
lunar hat geschrieben:Dadurch hätten sie nicht nur die Entwicklung des Treibers von Hals, sondern im Gegenteil noch eine qualitativ hochwertige Arbeit direkt von den Kernelentwicklern und eine Menge unbezahlter Tester.
Dann solltest du dir schleunigst einen Rechner mit Intel 965 Express Chipset besorgen.
Was willst du mir damit jetzt sagen?
Leonidas hat geschrieben:Und woher willst du wissen, ob auf dem Code nicht irgendwelche bescheuerten Patente drauf sind (argh, Softwarepatente.. wer sich die ausgedacht hat gehört sowieso eingewiesen)?
Das kann man nicht wissen. Aber der Verzicht auf Softwarepatente gehört nunmal zur freien Software. Imo schaden Softwarepatente sowieso mehr als das sie nützen.
Leonidas hat geschrieben:
lunar hat geschrieben:Andere Hersteller stellen zwar keine eigenen freien Treiber zur Verfügung, ermöglichen aber immerhin den einfachen Zugang zur Spezifikation. Trotzdem sind diese Hersteller nicht unmittelbar vom Bankrott bedroht...
Aber vermutlich nehmen sie auch nicht so das große Geld ein. Und in Firmen geht es ja nicht darum, dass man sympathisch ist, sondern das man Geld einnimmt. Willkommen in der Marktwirtschaft.
Eine Menge Firmen nehmen mit quelloffener Software eine Menge Geld ein. Linux und Marktwirtschaft, oder besser freie Software und Marktwirtschaft sind keine Gegensätze.
Leonidas hat geschrieben:
lunar hat geschrieben:So komisch es klingt... Wenn die Hersteller ihre Spezifikationen freigeben würden, dann kann die Community den Treiber tatsächlich besser entwickeln.
Genau. So wie cdrecord in neueren Versionen mein CD-ROM laufwerk nicht mehr unterstützt. So eine tolle Community, dass der einzige der daran gearbeitet hat Jörg Schillig war.
Die Ursache waren hier Lizenzstreitigkeiten und imo auch persönliche Konflikte. Bei genauer Betrachtung des Streits zwischen dem Debian Projekt und Jört Schillig kann ich mich des Eindrucks nicht erwehren, dass Jörg Schillig nicht unbedingt an Zusammenarbeit und Verbesserung des eignen Codes interessiert war. Debian musste cdrecord sogar forken, um endlich eigene Patches einbringen zu können, die cdrecord an das Debian System anpassen.
Ähnliches gilt anscheinend auch für Hans Reiser...
Leonidas hat geschrieben:
lunar hat geschrieben:Das Testen wird dann von anderen Entwicklern übernommen oder von den Verrückten, die täglichen Snapshots des Kernel-Trees bauen und booten ;)
So viele verrückte tester gibt es nicht und sie haben auch nicht jede Hardware um den Kernel darauf zu testen.
Also zumindest bei den großen Distributoren werden umfangreiche Tests ausgeführt. Und die Ergebnisse fließen wieder in den Kernel zurück.
Leonidas hat geschrieben:
lunar hat geschrieben:Und wenn ein Treiber häufig gebraucht wird, dann finden sich auch genügend Entwickler.
Hat man ja an dem frühen Versionen von Kernel 2.6 gesehen, wo brennen nicht ging. Aber vielleicht brennen die Entwickler ja nicht.
Frühe Versionen sind wohl kaum ein geeignetes Argument. Man möge sich nur mal anschauen, was in frühen Versionen von Windows so alles nicht funktionierte. Entscheidend ist aber, dass die Fehler behoben wurden und brennen jetzt, im stabilen 2.6er Kernel, wunderbar funktioniert.
Leonidas hat geschrieben:
lunar hat geschrieben:Zum anderen gäbe es mehr Leute, die die Treiber testen würden, denn freie Treiber aus dem Kernel setzt jeder automatisch nach einer Installation ein, während die proprietären Treiber erst installiert werden müssen, was bei weitem nicht jeder macht.
Aber viele und die Installation unter zum Beispiel Ubuntu ist ein Kinderspiel.
Ich verwende keine proprietären Treiber. Und die Nutzer anderer Distributionen wie Suse oder Fedora haben diese Treiber erst gar nicht. Diese Distributoren sind folglich mehr oder weniger gezwungen, freie Treiber zu unterstützen und ausgiebig zu testen.
Leonidas hat geschrieben:
lunar hat geschrieben:interessant sind die Abschnitte "The Kernel needs a stable api" and "Closed Source Linux kernel modules are illegal".
Eben, das ist das Problem an der GPL. Wenn er sagt, dass es illegal ist, muss das gar nicht der wahrheit entsprechen - da wurden schon viele Diskussionen drüber geführt.
Mir geht es noch nicht mal darum, dass solche Module illegal sind oder nicht. Das ist sowieso eher Glaubenssache. ;)
Aber ich finde, GKH zeigt sehr schlüssig, dass das Entwicklungsmodell des Kernels, also die Art wie Änderungen eingepflegt werden und die Auswirkung dieser Änderungen auf das API und ABI des Kernels, mit proprietären Modulen schlecht vereinbar sind. Das steht im ersten Abschnitt "The Kernel needs a stable api".
Leonidas hat geschrieben:
lunar hat geschrieben:Ob das für DRI Treiber für Grafikkarten mit ausreichender Performance funktioniert, glaube ich erst, wenn ich das in der Praxis sehe...
Dann solltest du dir mal Windows ansehen, dort ist die GUI größtenteils in den Kernel integriert. Ich finde es gut, so viele Teile des Systems vom Kernel abzukoppeln und auszulagern.
Persönlich finde ich Microkernel-Ansätze insgesammt interessanter, L4 hat bewiesen dass sowas auch performant sein kann, außerdem steigt die Rechenleistung sowieso, dass ich finde, dass man langsamere Ansätze gegenüber schnelleren bevorzugen kann, sofern der langsamerere Ansatz "sauberer" ist.
Versteh mich nicht falsch, ich bevorzuge den modularen Ansatz von Linux ebenfalls über den monolithischen Ansatz des Windowssystems, bei dem wahrscheinlich sogar die Animation des Word-Heftklammer-Männchens im Kernel integriert ist ;)
Allerdings gibt es einige wenige Bereiche, in denen die unvermeidbaren Auswirkungen auf die Performance nicht erwünscht sind. Ein Bereich ist eben 3D Beschleunigung. Da muss die Praxis zeigen, ob das ein akzeptabler Weg ist.

Gruß
lunar

PS: Wollt ihr euch eigentlich nicht mal die "Zitat teilen" Funktion aus forum.ubuntuusers.de abschauen? Das würde das Beantwortung solche epischen Postings doch erleichtern ;)