| View previous topic :: View next topic |
| Author |
Message |
TheSmallOne
Guru
Joined: 22 Jan 2005
Posts: 467
Location: Germany
|
 Posted: Sun Jun 24, 2018 8:57 am Post subject: Wird Gentoo komplizierter? |
 |
|
Hi,
mich würde mal eure Meinung interessieren.
Ich nutze Gentoo jetzt seit vielen Jahren, doch ich habe in letzter Zeit immer mehr das Gefühl, das es zunehmend komplizierter wird.
Früher konnte man problemlos ein emerge -Du @world ausführen – klar, es gab immer mal wieder ein paar Zirkel-Abhängigkeiten, oder USE-Flags, die ein manuelles Eingreifen erforderten. Meist hat man dann einfach ein Paket bewusst deinstalliert, welches dann beim Update als Abhängigkeit wieder neu installiert wurde, aber alles in allem keine großen Aufwände und auch immer bloß Einzelfälle.
Inzwischen kann ich jedoch kein World-Update mehr ausführen, ohne dass es irgendwelche Probleme gibt. Entweder ein Fehler wegen irgendwelcher Maskierungen, oder irgendwelche Python-Target-Geschichten. Es läuft einfach nicht mehr so problemlos wie „früher“.
Heute konnte ich z.B. nach dem sync nichtmal problemlos ein Portage-Update selbst einspielen, ohne dass es zu einer langfristigen Angelegenheit wurde.
Geht es euch auch so, oder habe ich einfach nur eine ungewöhnliche Installation? |
|
| Back to top |
|
 |
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Sun Jun 24, 2018 12:42 pm Post subject: |
|
|
Also ich hab eigentlich nicht das Gefühl des es komplizierter geworden ist.
Allerdings waren die News zu Python und jetzt heute wieder zu mpc in Zusammenhang mit dem gcc nicht so hilfreich.
Also aktuelles Beispiel - für den mpc wird nigendwo gesagt das die problematische Version 4 noch unstable ist. Das heisst in meinem Fall, ich muss gar nix machen, mich vielleicht später erinnern.
Für mich verwirrt die News erstmal, mehr weil man denkt, man müsse selber auch irgendwas was tun.
Grundsätzlich klappt bei mir aber das "emerge --ask --verbose --update --newuse --changed-deps --deep world" in der letzten Zeit eher besser als früher. *hust*
Das "--changed-deps" hab ich jetzt aber extra noch dazugenommen, weil ich festgestellt habe, des es leider immer wieder vorkommt, das Ebuilds ohne einen Versionssprung geändert werden, und man davon nix mitbekommt. |
|
| Back to top |
|
|
ChrisJumper
Advocate
Joined: 12 Mar 2005
Posts: 2390
Location: Germany
|
| Posted: Sun Jun 24, 2018 8:26 pm Post subject: |
|
|
Die Migration ist schwierig. Jetzt nicht Python, aber ein Wechsel von openrc zu systemd. Grub Lagcy zu Grub 2. Setzt man ein neues System auf, geht es geschmeidig wie eh und je finde ich.
Mit der Zeit muss man aufräumen, vielleicht mal die Daten migrieren oder auf komplett neue Architekturen wechseln.
Das einzige was mich regelmäßig stört ist wenn zu viele Unstable Pakete drin sind oder zu viele Overlays. Oder sich das Gefühl breit macht die aktuellen Pakete kommen zu spät. Stellenweise ist das wohl auch so, weshalb ein Overlay es etwas bequemer macht.
Aber man kann es dem Stable-Zweig nicht vorwerfen wenn dort erst mal getestet werden muss.. oder gar den Maintainern die Tester fehlen. In den meisten Fällen hilft aber ein Blick in den Bug-Tracker oder hin zu den Github-Issues/Readme Dateien in den Overlays.
Mit dem älter werden wirkt immer alles komplizierter. Im Grunde haben auch die Migrationen immer funktioniert ohne das es Datenverlust gab oder ich mich aus gesperrt hab. Aber neues und ungewohntes ist immer ein kleiner Ballance-Akt mit der Angst vor einem kleinen Fall. Am besten nimmt man sich dafür einfach ein wenig Zeit, hat trotzdem Backups und macht es wirklich nur wenn man Lust drauf hat.
Neben Pearl, QT oder zuletzt der Umstellung bei | Code: | [I] x11-base/xorg-proto
Verfügbare Versionen: 2018.4 **9999
Installierte Versionen: 2018.4(00:00:00 20.04.2018)
Startseite: https://cgit.freedesktop.org/xorg/proto/xorgproto/
Beschreibung: X.Org combined protocol headers |
Hatte ich auch ein wenig zu Kämpfen.
Auf einem anderen System auch mit einer Virtual Box Version, wegen dem Xorg-Proto. Stellenweise wirkte es so als seien die Ebuilds noch nicht auf die Verwendung von Xorg-Proto umschrieben und haben immer wieder mal andere Abhängigkeiten rein gezogen. Aber in dem Fall hilft dann Warten oder Zeitweise ein eigenes lokales Overlway erstellen wo man die Ebuilds anpasste. |
|
| Back to top |
|
|
toralf
Developer
Joined: 01 Feb 2004
Posts: 3922
Location: Hamburg
|
| Posted: Thu Jun 28, 2018 8:32 pm Post subject: Re: Wird Gentoo komplizierter? |
|
|
| TheSmallOne wrote: | Hi,
mich würde mal eure Meinung interessieren.
Ich nutze Gentoo jetzt seit vielen Jahren, doch ich habe in letzter Zeit immer mehr das Gefühl, das es zunehmend komplizierter wird. |
Was für eine Vorlage für eine altersdiskrinimierende Bemerkung 
- Aber nun ernsthaft:
m.E. wird Gentoo nicht unbedingt komplizierter, aber erwachsener. Dazu gehört, daß Portage der wachsende Paketanzahl, kombiniert mit immer komplexer werdenden Abhängigkeiten zwischen diesen, gerecht werden will. Denn früher war Portage eher ignorant (==jugendlich), wenn es um die Feinheiten von USE-Flag-Abhängigkeiten ging. Und heutzutage macht Portage dann nicht irgendwie weiter, sondern stoppt mit (zugegebenermaßen oftmals schwer zu lesenden) Fehlermeldungen. |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Fri Jun 29, 2018 2:23 pm Post subject: |
|
|
| Quote: | ich habe in letzter Zeit immer mehr das Gefühl, das es zunehmend komplizierter wird.
|
Ich glaube nicht, dass es komplizierter wird. ich habe vielmehr den Eindruck, dass es bei Gentoo manchmal ruhigere Phasen und manchmal stürmische Phasen gibt.
Die Pakete, bei denen es Probleme gibt, wechseln. Wenn ich mich richtig erinnere, waren früher (vor 10+ Jahren) Updates von Perl sehr aufwändig, dafür waren Updates von Python einfach. Jetzt ist genau andersherum... Python ist u.a. deshalb so kompliziert, weil wir mehrere Versionen gleichzeitig installieren müssen. Aber das ist nicht die Schuld der Gentoo Entwickler, sondern die Schuld der Python Entwickler. Ich sehne den Tag herbei, an dem auf allen meinen Rechnern nur noch eine Version von Python installiert ist! Ich habe das bisher nur auf einem einzigen Server geschafft. |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Mon Jul 02, 2018 11:44 pm Post subject: |
|
|
Sowas ist einfach nur unschön:
| Code: |
mithrandir@luthien ~ $ diff "/mnt/backup/Gentoo-System/usr/portage/games-arcade/supertux/supertux-0.5.1.ebuild" /usr/portage/games-arcade/supertux/supertux-0.5.1.ebuild
1c1
< # Copyright 1999-2017 Gentoo Foundation
---
> # Copyright 1999-2018 Gentoo Foundation
4a5,6
>
> : ${CMAKE_MAKEFILE_GENERATOR:=ninja}
34a37
> "${FILESDIR}"/${PN}-0.5.1-ninja.patch
41c44
< sed 's@logo_dev@logo@' \
---
> sed -e 's@logo_dev@logo@' \
46a50
>
53d56
< -DUSE_DEBUG="$(usex debug)"
54a58
> -DUSE_SYSTEM_PHYSFS=ON
56d59
<
58,65d60
< }
<
< src_compile() {
< cmake-utils_src_compile
< }
<
< src_install() {
< cmake-utils_src_install
|
Da ist der Ebuild einfach im Stillen geändert worden.
Ich hab dann den Rebuild gemacht und es ja es gab gleich einen Compilefehler. Der Ebuild verwendet jetzt das System-Physfs. Nur die stable Version war nicht mehr geeignet und ich musst auf die unstable 3er Version.
Gut hab ich also gemacht. Das Paket baut sauber neu. Aber dann beim revdep-rebuild gehts weiter.
Zwei weitere Pakete muss ich auch aktualisieren. media-libs/sdl-sound lies sich aber mit dem neuen dev-games/physfs-3.0.1-r1 nicht mehr baun. Und da blieb nur das per USE-Flag abzuschalten.
Es wäre wirklich schön gewesen wenn hier wenigstens eine neuen Version für games-arcade/supertux erzeugt worden wäre.
Ohne das "--changed-deps" hätte das alles wahrscheinlich erstmal eine Weile unerkannt weitergeschlummert. |
|
| Back to top |
|
|
artbody
Guru
Joined: 15 Sep 2006
Posts: 489
Location: LB
|
| Posted: Mon Jul 09, 2018 10:19 am Post subject: |
|
|
Also ich denke, dass es nicht Gentoo an sich ist was komplexer wird, sondern die einzelnen Programme incl. aller extrem Developer lastiger Docus.
Dann, dass es derzeit so einen Trend gibt, immer alles neu zu erfinden.
Schönstes Beispiel dürfte derzeit Enlightenment WM E16 als Orginal UND der gesamte neuen Schöpfung "Enlightenment WM" E17,18,..22,...xxxxx zu sein.
Die verdienen in meinen Augen den LINDI (Linux Disaster Preis)
Warum :
E16
Kernpunkte
1. Man klicke auf den Hintergrund egal wo und hat das Menu an der Position (alles gesparte Mauskilometer)
2. 3dimensionales array für virtuelle Bildschirme  (also x*y*n)
1996 man beachte
3. man fahre mit der Maus an den Bildschirmrand und befindet sich im nächsten virtuellen Fenster !! 1996 !!
ich hatte damit nie Probleme noch Abstürze - ein WM ohne viel Overhat
Dann Enlightenment 17,18,..22...xxxxxx
Alles neu alles GIGA, toll hier und mega dort , aber als erstes flog das 3D Array für virtuelle Bildschirme raus, also nur noch 2dimensional 
dann widgets hier und dort , dateimanager usw , der OVERHAT (aus Alu mit Löcher) wude mit der Zeit immer größer.
DIE FRECHHEIT an der Sache ist gerade aktuell
Man verwende einen tollen Namen für etwas ABSOLUT NEUES, klemmt sich an den Orginal Enlightenment dran UND bezeichnet diesen dann als den ALTEN welcher jetzt sogar aus dem Portage Tree rausflog weil zwei VÖLLIG verschiedene Softwarepakete über Slots nicht mehr zu handeln waren. 
22 Jahre Enlghtenment E16 und jetzt ist es ein inoffizielles Overlay   
https://bugs.gentoo.org/656020
_________________
Never give up
WM : E16 the true enlightenment
achim |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Jul 15, 2018 7:32 am Post subject: Re: Wird Gentoo komplizierter? |
|
|
| toralf wrote: | | Portage der wachsende Paketanzahl, kombiniert mit immer komplexer werdenden Abhängigkeiten zwischen diesen, gerecht werden will |
Nein. Die Zahl der Pakete in Gentoo hat im Gegenteil sogar abgenommen, und die Abhängigkeiten sind auch nicht viel anders als früher.
Was sich geändert hat, ist, dass es einige Entwickler hip fanden, Funktionalität, die zurecht in Extra-Tools wie revdep-rebuild, perl-updater oder python-updater ausgelagert war, als komplizierte Abhängigkeiten mit subslots und USE-flags auszudrücken, also das zugehörige NP-vollständige Problem der Abhängigkeitsauflösung zu vergrößern und damit den Paketmanager und Benutzer zu überfordern.
Bei Perl wurde das ganze noch mit Sachverstand gemacht, aber python nach minor-Versionen zu slotten und Pakete nur für die jeweilige Minor-Version zu kompilieren, ließ schon jedes Maß an Realismus vermissen und zwingt den Benutzer, entweder Dutzende von Paketen in überflüssigen Versionen zu installieren oder bei jedem minor-Upgrade massiv manuell einzugreifen. Wenn das dann noch mit anderen Problemen aus subslot-Abhängigkeiten zussamenstößt und vielleicht gar noch mit einem echten Bug in den Abhängkeiten, ist man schnell aufgeschmissen. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Jul 15, 2018 7:44 am Post subject: |
|
|
| mike155 wrote: | | [Aber das ist nicht die Schuld der Gentoo Entwickler, sondern die Schuld der Python Entwickler. |
Python:2 und Python:3 sind sehr verschieden; da ergibt es schon Sinn.
Zusätzliche Slots für Minor-Versionen sind ausschließlich die Schuld der Gentoo-Entwickler: Man muss nicht wegen jedem Furz, der nicht ganz abwärtskompatibel ist, einen neuen Slot aufmachen. Die Perl-Entwickler in Gentoo machen vor, wie man das vernünftig handhaben kann: Obwohl viele Perl-4-Programme unter perl-5.26 nicht ohne Änderung laufen, wurde da noch nie ein neuer Slot erzwungen. |
|
| Back to top |
|
|
artbody
Guru
Joined: 15 Sep 2006
Posts: 489
Location: LB
|
| Posted: Tue Jul 17, 2018 6:01 pm Post subject: |
|
|
python target
Ja python ist schon eine etwas anstrengende peinliche Nummer
Angefangen beim Einrücken ohne erzwungenes Ende bei
| Code: |
while..
if .....
if ...
if ...
else
or what indent
|
was erwartet man von solchen 
Satzzeichen wie Punkt, Komma usw
schaffen Klarheit, in jedem Text 
Mich wundert ja, dass die Pythonleute, in ihren Docu's, Satzzeichen verwenden.
| Code: |
#!/usr/local/bin/perl
$num = 20;
while ($num < 30) {
if ($num > 25) {
print "num is $num\n";
}
++$num;
}
|
unschön aber funktioniert trotzdem
aber ein guter Editor kann daraus wohl formatierten Code machen, was bei Python ja ausgeschlossen ist.
_________________
Never give up
WM : E16 the true enlightenment
achim |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Jul 18, 2018 9:34 am Post subject: |
|
|
| artbody wrote: | | Angefangen beim Einrücken ohne erzwungenes Ende |
Das finde ich gar nicht so schlimm, denn man rückt ja außer für Debugging-Zeilen ohnehin korrekt ein.
Was ich schlimmer finde, sind die Style-Regeln: Einrücktiefe 4 (wenn ohnehin erwartet wird, dass man den Code mit try/except vollstopfen muss) + 80-Zeichenlimit + noch viel mehr Einrücken bei den Zeilenumbrüchen. In typischen Programmen steht dann der Code am rechten Rand wortweise untereinander oder kann manchmal gar nicht Style-konform geschrieben werden.
| Quote: | | Code: | if .....
if ...
if ...
else
or what indent |
|
Dangling else ist kein python-spezifisches Problem, und außer Einrücktiefe (oder noch übler: Klammerzählen) gibt es da in keiner Sprache was Schönes. Selbst natürliche Sprachen tun sich damit extrem schwer.
| Quote: | | unschön aber funktioniert trotzdem |
Wenn Du solchen Code als Patch in einem meiner Projekte einreichst, bekommst Du ihn um die Ohren gehauen.
Der einzige Vorteil von Zeichen+Einrücken ist, dass die Redundanz eine Verifikationsmöglichkeit schafft. Der gcc macht das inzwischen mit geeigneten Optionen.
Aber da haben die Python-Leute schon recht: Der Mensch verlässt sich auf die optische Einrückung; einen Strichpunkt mehr/weniger übersieht er leicht. |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Wed Jul 18, 2018 11:21 am Post subject: |
|
|
| mv wrote: | | Dangling else ist kein python-spezifisches Problem, und außer Einrücktiefe (oder noch übler: Klammerzählen) gibt es da in keiner Sprache was Schönes. Selbst natürliche Sprachen tun sich damit extrem schwer. |
Code mit geschachtelten if/else Blöcken ist auch für Menschen schwer lesbar - und eine häufige Fehlerursache! Für mich gibt es nichts Schlimmeres, als Code-Review von Programmen, bei denen der Entwickler mehrere if/else Ebenen geschachtelt hat...
Dabei kann man beim Programmieren geschachtelte if/else Blöcke (und häufig auch else) vermeiden: wenn man Funktionen verwendet und sich an die Regel hält: keine Funktion mehr als 30-50 Zeilen - ergibt sich das fast von selbst. |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2283
Location: Adendorf, Germany
|
| Posted: Wed Jul 18, 2018 2:37 pm Post subject: |
|
|
| mike155 wrote: | | Dabei kann man beim Programmieren geschachtelte if/else Blöcke (und häufig auch else) vermeiden: wenn man Funktionen verwendet und sich an die Regel hält: keine Funktion mehr als 30-50 Zeilen - ergibt sich das fast von selbst. |
Die Regel ist recht geläufig, und die am zweithäufigsten gebrochene. (Gleich nach "Kommentiere deinen Code!" und knapp for "Benutze niemals 'goto'!" )
Aber Spaß beiseite, mehrfach geschachtelte If-Else-Blöcke sind in der Tat ein Fluch. Für mich heißt das meistens, dass der/die Autor/in keinen Plan hatte, sondern drauflosschrieb und dann erweiterte. Ebenfalls ohne Plan. Wegschmeißen und neu schreiben ist in den allermeisten Fällen die sauberste Lösung.
Naja... und zur Not tut es immernoch die Kombination aus AStyle und, zumindest unter Windoofs, Viasfora (Rainbow Braces (Wer vim benutzt kennt vielleicht das "Rainbow Parentheses" plugin...)).
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Jul 18, 2018 10:03 pm Post subject: |
|
|
| mike155 wrote: | | Dabei kann man beim Programmieren geschachtelte if/else Blöcke (und häufig auch else) vermeiden: wenn man Funktionen verwendet |
Da bin ich anderer Ansicht: Funktionen haben mit if-else nichts zu tun. Außerdem bin ich nicht der Ansicht, dass an if-else etwas schlechtes
| Quote: | | keine Funktion mehr als 30-50 Zeilen |
Diese Regel ist für C/C++ genauso weltfremd wie der Python-Style. Künstliches Ausplitten in Funktionen sorgt nur dafür, dass massenweise Parameter übergeben werden. In Python ist das in diesem Fall anders, weil innere Funktionen auf die Variablen der äußeren zugreifen dürfen. Aber innere Funktionen sind auch nicht schön. |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Thu Jul 19, 2018 1:39 pm Post subject: |
|
|
| mv wrote: | Funktionen haben mit if-else nichts zu tun.
|
Bitte? Die beiden wichtigsten Refactoring-Regeln zur Vermeidung von komplizierten geschachtelten if/else-Blöcken haben mit Funktionen zu tun:
- Wenn in einem then- oder else-Block längerer Code steht (und evtl. weitere if/else-Anweisungen): überlege, den Code in eine eigene Funktion auszugliedern. Das reduziert zwar nicht die Zahl der if/else-Anweisungen, erhöht aber die Lesbarkeit.
- Nutze "early return". Diese Technik reduziert die Anzahl der else-Blöcke erheblich und erhöht dadurch die Lesbarkeit. "Early return" ist natürlich nur möglich, wenn man mit Funktionen arbeitet. Das hört sich für Java/C/C++-Programmier vielleicht trivial an, weil die sowieso mit Funktionen arbeiten
 . Aber wenn man ein Script hat, das von oben nach unten runterprogrammiert wurde und in dem keine oder nur wenige Funktionen verwendet werden (und davon gibt's mehr als genug), muss man den Code erst mal in Funktionen unterteilen, damit man "early return" nutzen kann.
Wen es interessiert: ein Beispiel in C++ für diese Technik gibt es hier: https://arne-mertz.de/2016/12/early-return/.
Bevor Missverständnisse aufkommen: das heißt nicht, dass man die o.g. Regeln immer anwenden sollte oder dass "else" immer schlecht ist. Man muss jeden Einzelfall betrachten. Manchmal helfen die o.g. Regeln, manchmal nicht... |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Jul 19, 2018 8:49 pm Post subject: |
|
|
| mike155 wrote: | | Das reduziert zwar nicht die Zahl der if/else-Anweisungen |
Eben.
| Quote: | | Nutze "early return" |
Auch das hat mit Funktionen nur bedingt zu tun: break/continue läuft auf das selbe hinaus.
Für Beides gibt es gute Einsatzmöglichkeiten, aber es sind Stilmittel, die man möglichst vermeiden sollte, weil sie i.W. ein verkapptes "goto" sind und die Programmlogik verschleiern.
Besonders deutlich wird das, wenn man im Nachhinein feststellt, das man z.B. noch eine Resource (etwa eine Latte von malloc/new, mutexes o.ä.) benötigt und diese in allen Fällen freigegeben werden soll: Weil kein gemeinsamer "Treffpunkt" des Codes vorhanden ist, muss man die Resourcenfreigabe ev. in jedem Teil erneut handhaben, oder doch die versteckten "goto"s wieder entfernen.
Klar, in C++ behilft man sich da mit Temporärobjekten, und der Compiler kümmert sich in jedem Zweig darum, deren Destruktor aufzurufen, aber wenn man nur wegen solchen Programmierstils neue Objekte einführen muss, hat man möglicherweise etwas falsch gemacht. In C wäre man da ohenhin verratzt. Außerdem lässt sich nicht alles in ein Objekt binden: Je nach Programm sind möglicherweise am Ende des Blocks noch ganz andere Folgearbeiten notwendig. |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Thu Jul 19, 2018 10:46 pm Post subject: |
|
|
| Quote: | | Besonders deutlich wird das, wenn man im Nachhinein feststellt, das man z.B. noch eine Resource (etwa eine Latte von malloc/new, mutexes o.ä.) benötigt und diese in allen Fällen freigegeben werden soll: Weil kein gemeinsamer "Treffpunkt" des Codes vorhanden ist, muss man die Resourcenfreigabe ev. in jedem Teil erneut handhaben, oder doch die versteckten "goto"s wieder entfernen. |
Dia Aufgabe, dass man Ressourcen wieder freigeben muss, taucht in der Tat häufig auf. Ich löse diese Aufgabe typischerweise durch eine zweite Funktion:
| Code: | function a
{
1) Initialisieren open(), malloc(), Synchronisationsobjekte, usw
2) Funktion b aufrufen, die die eigentliche Aufgabe erledigt. Wenn in b Exceptions auftreten können, erfolgt der Aufruf in einem try/eval Block.
3) Cleanup: close(); free(), mutexes, Synchronisationsobjekte, usw
}
function b
{
Job erledigen
}
|
Dann ich kann ich mich in der Funktion b ganz auf meinen Job konzentrieren und meinen Algorithmus implementieren. In b muss ich mir keine Gedanken über Ausführungspfade oder die Freigabe von Ressourcen machen. Bei Bedarf kann ich mit return zurückspringen. Ergebnis sind relativ kurze Funktionen, die gut lesbar sind. Meines Erfahrung nach führt das zu stabilen Programmen: der Cleanup-code in Funktion a wird auf jeden Fall durchlaufen. Ein weiterer Vorteil ist, dass init- und cleanup-code in der Funktion a direkt untereinander steht. Dadurch sieht man Fehler schneller, als wenn init- und cleanup-Code noch durch weiteren Code getrennt wird. |
|
| Back to top |
|
|
franzf
Advocate
Joined: 29 Mar 2005
Posts: 4565
|
| Posted: Fri Jul 20, 2018 4:02 am Post subject: |
|
|
| mike155 wrote: | | Quote: | | Besonders deutlich wird das, wenn man im Nachhinein feststellt, das man z.B. noch eine Resource (etwa eine Latte von malloc/new, mutexes o.ä.) benötigt und diese in allen Fällen freigegeben werden soll: Weil kein gemeinsamer "Treffpunkt" des Codes vorhanden ist, muss man die Resourcenfreigabe ev. in jedem Teil erneut handhaben, oder doch die versteckten "goto"s wieder entfernen. |
Dia Aufgabe, dass man Ressourcen wieder freigeben muss, taucht in der Tat häufig auf. Ich löse diese Aufgabe typischerweise durch eine zweite Funktion:
| Code: | function a
{
1) Initialisieren open(), malloc(), Synchronisationsobjekte, usw
2) Funktion b aufrufen, die die eigentliche Aufgabe erledigt. Wenn in b Exceptions auftreten können, erfolgt der Aufruf in einem try/eval Block.
3) Cleanup: close(); free(), mutexes, Synchronisationsobjekte, usw
}
function b
{
Job erledigen
}
|
|
Aber speziell mutexes sind so angewandt ziemliche Performancefresser da sie während der gesamten function b blockieren. MMn. sollten die wirklich so eng wie möglich um den kritischen Teil liegen damit man möglichst viel parallel werkeln kann.
Ja, man kann eine function c einführen, die den parallel ausführbaren Teil enthält und nur darum die mutexes legen. Wird aber mit der Zeit ziemlicher Wust zu managen. Und beißt sich evtl. dann auch mit Speicher- und Filemanagement.
Generell finde ich das hier etwas zu theoretisch. Lass doch den Maddin unsauberen Code schreiben. Solange sein eix (und der ganze andere "Wust" ) funktioniert ist das doch in Ordnung, oder? |
|
| Back to top |
|
|
doedel
Guru
Joined: 05 Feb 2006
Posts: 579
Location: Denmark
|
| Posted: Fri Jul 20, 2018 7:08 am Post subject: |
|
|
| mv wrote: | | mike155 wrote: | | Das reduziert zwar nicht die Zahl der if/else-Anweisungen |
Eben.
| Quote: | | Nutze "early return" |
Auch das hat mit Funktionen nur bedingt zu tun: break/continue läuft auf das selbe hinaus.
|
Dann muss ich aber nochmal das forward-goto in Raum werfen, was in manchen fällen durchaus legitim ist.
Pseudocode:
| Code: |
function init_system() {
init_console();
ret = init_io();
if(ret) goto outhere_nocleanup;
ret = init_keyboard();
if(ret) goto outhere;
ret = init_mouse();
if(ret) goto outhere;
....
....
outhere:
cleanup_init();
outhere_nocleanup:
return;
|
_________________
1 ha == 1 Hekto-Ar == 1 Hektar |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2283
Location: Adendorf, Germany
|
| Posted: Fri Jul 20, 2018 9:50 am Post subject: |
|
|
| mv wrote: | | mike155 wrote: | | Das reduziert zwar nicht die Zahl der if/else-Anweisungen |
Eben.
| Quote: | | Nutze "early return" |
Auch das hat mit Funktionen nur bedingt zu tun: break/continue läuft auf das selbe hinaus.
Für Beides gibt es gute Einsatzmöglichkeiten, aber es sind Stilmittel, die man möglichst vermeiden sollte, weil sie i.W. ein verkapptes "goto" sind und die Programmlogik verschleiern. |
Hört, hört!
Und jetzt eine Anekdote dazu:
Als ich bei meinem vorherigen Arbeitgeber Anfing, das war im Jahre 2008, fand ich viele "goto"-Anweisungen in den vorhanden C-Quelltexten.
Als braver Befürworter und Unterstützer der "Benutze niemals goto!"-Regel, habe ich mit dem Hauptautor (mein Chef) darüber gesprochen.
Er forderte mich heraus: Sein Argument ist, dass ein "goto" hier die eleganteste Lösung sei. Ich solle versuchen eine eleganter ohne "goto" zu finden.
Ergebnis: Ging nicht. Zumindets nicht in C. In C++ wäre es kein Problem gewesen, dort gibt es Destruktoren, aber in C endete jeder Versuch, die "goto"s weg zu bekommen, in lächerlich breiten if-else-Verschachtelungen, idotischem Auslagern von Code-Schnippseln in Funktionen, oder eben schwer auffindbaren "early returns".
| doedel wrote: | | Dann muss ich aber nochmal das forward-goto in Raum werfen, was in manchen fällen durchaus legitim ist. |
Und genau darum handelte es sich in besagtem C-Code. Wie gesagt, in C++ gibt es Destruktoren, da benötigt man sowas nicht (kaum), aber in C ist der Ansatz gerne eine Hilfe um ein durchaus elegantes (und vor allem gut lesbares) Design zu bekommen.
Erkenntnis daraus: Programmierregeln und "Best Practices" sind prima als Orientierungshilfe, sollten aber nicht wie eine Zwangsjacke getragen werden.
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Fri Jul 20, 2018 12:18 pm Post subject: |
|
|
Ich mag es, wenn ich ein Programm bzw. eine Funktion einmal von oben nach unten lese - und dann weiß, was es/sie tut. Alles was dabei stört, versuche ich zu vermeiden.
Den von doedel gezeigten Code finde ich aber nicht optimal. Ich musste ihn mehrfach lesen, bis ich wusste, was es mit den "gotos" auf sich hat und was das Programm eigentlich tun soll. Wenn ich es richtig verstanden habe, soll der Code folgendes machen:
1) als erstes wird init_io() aufgerufen. Wenn der Aufruf scheitert, soll die Funktion zurückkehren
2) dann werden die einzelnen Devices der Reihe nach initialisiert. Wenn eine Initialisierung scheitert, soll abgebrochen werden und die Funktion soll zurückkehren.. Vorher soll aber auf jeden Fall noch cleanup_init() aufgerufen werden
3) Wenn alle Devices initialisiert werden können, soll auch cleanup_init() aufgerufen werden (wundert mich, aber steht so in dem Programm)
Ich würde versuchen, das auch so im Code so zu zeigen - damit es jeder sofort sieht, ohne dass er erst Ausführungspfade analysieren muss. Mein Code würde also vermutlich folgendermaßen aussehen:
| Code: | # return value: 0: SUCCESS, !=0: ERROR
function init_system() {
init_console();
ret = init_io();
if ( ret ) {
return ret;
}
ret = init_devices();
cleanup_init();
}
function init_devices() {
ret = init_keyboard();
if ( ret ) {
return ret;
}
ret = init_mouse();
if ( ret ) {
return ret;
}
...
} |
Der Code ist "goto"-frei und die maximale if-Tiefe ist 1. |
|
| Back to top |
|
|
franzf
Advocate
Joined: 29 Mar 2005
Posts: 4565
|
| Posted: Fri Jul 20, 2018 2:49 pm Post subject: |
|
|
Wobei du jetzt vor einem kleinen Problem stehst:
Dein Code nimmt bei den "..." an, dass es sich um Initialisierung weiterer Devices handelt.
Ich denke da wird durchaus anderer Code stehen, das sollte dann in init_system rein.
Von jetzt an hast du aber init_cleanup vorm return auszuführen.
Und zwar jedesmal wenn ret !=0.
Also entweder bei jedem neuen init_... ret-check+cleanup+return, oder alles in verschachtelte if-Blöcke.
MMn. nimmt sich das nicht so viel. Ich mag goto ja auch nicht aber in dem Fall versteht man was passiert, vor allem sind es klare Sprünge und nicht quer hin und her im Code.
(Und irgendwie finde ich die dauernden if ret return ret unästhetisch ) |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Jul 21, 2018 6:21 am Post subject: |
|
|
Das ist alles etwas Praxisfern: Die Funktionen init_mouse() usw in mike155's code liefern typischerweise (häufig mehrere) lokale Variablen zurück, mit denen man dan im Code und auch zum Deinizialisieren arbeiten will.
Klar: Möglicherweise kann man diese ganze Funktion in eine Klasse kapseln und die lokalen Variablen in Klassenvariablen transformieren.
Je nachdem ist das aber vielleicht nicht sinnvoll, und es sollte wirklich eine Standalone-Funtion sein, die halt nur sehr viele lokale Variablen hat.
In dem Moment wird die ganze Zerlegung in Teilfunktionen sehr problematisch, weil man dann eben jeweils Dutzende von Variablen hin- und zurückübergeben muss.
(Nein, das Kapseln dieser Variablen in eine künstliche Klasse/Struktur, deren Zweck die Anwenung in i.W. einer einzigen "aufgesplitteten" Funkltion ist, macht das Ganze eher noch chaotischer).
Es gibt eben halt nun mal Funktionen, die von ihrer Natur her lang sind.
Ob man diese mit forward-goto's übersichtlicher gestaltet, wage ich zu bezweifeln. gotos können in solchen Fällen natürlich minimal effiizienter sein (aber vielleicht auch nicht, weil implizit irgendwelche rewinds notwendig sein können). Ich bleibe dabei: Nur zu vermeidung von "else" sind weder Subfnuktionen noch gotos höchstens dann zweckmäßig, wenn man sich dadurch nichttrivialen duplizierten Code in verschiedenen else-Teilen spart. (Und auch in dem Fall sollte man vielleicht lieber über eine zusätzliche boolesche Variable nachdenken, die man am Ende abfragt, statt gotos/Subfunktionen zu benutzen).
Klar: Solange den Subfunktionen (fast) keine lokalen Parameter übergeben werden, und sie wirklich etwas logisch eigentsändiges tun,, sind Subfunktionen natürlich immer zweckmäßg, auch weil sid die Hauptfunktion kürzer machen. Aber das gilt unabhängig von if... else... -Fragen.
Edit: Erklärung zu gotos verlängert.
Last edited by mv on Sat Jul 21, 2018 7:01 am; edited 1 time in total |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Jul 21, 2018 6:48 am Post subject: |
|
|
| franzf wrote: | | Lass doch den Maddin unsauberen Code schreiben. Solange sein eix (und der ganze andere "Wust" ;)) funktioniert |
Ich verwehre mich stark gegen die Behauptung, unsauberen Code zu schreiben. Gerade in Projekten wie chessproblem, knapsack, oder osformat habe ich mir sehr viel Gedanken nicht nur über die öffentlichen Interfaces sondern auch über den Codeaufbau selbst gemacht. Wenn Du da der Meiinung bist, ich würde unsauber programmieren, verweise bitte auf konkrete Stellen.
Mit eix ist es naturgemäß schwieriger: Erstens hatte ich da schon vielen vorgefertigen Code geerbt, und dann werden von Zeit zu Zeit neue Features (bei portage oder manchmal auch bei eix) eingeführt, die so gar nicht zur internen Programmlogik passen. Typisches Beispiel ist das Herausnehmen von profile-Zeilen mit "-..." bei denen ein Textvergleich zutreffen muss (obwohl eix aus Effiziengründen, die Zeilen natürlich ganz anders konvertiert). Oder die Tatsache, dass die Behandlung von KEYWORDS="-*" oder ACCEPT_KEYWORDS="-*" früher eine vollkommen andere Logik erforderte als jetzt KEYWORD=""; insbesondere auch, was die Auswirkungen auf eix-eigene Features wie eix-test-obsolete angeht. Häufig wäre einfach ein totales Umstruktieren großer Klassen angemessen, aber das war nie praktikabel. Deswegen strotzt eix (in moderner Terminologie) inzwischen von Adapter- Bridge- und Facade-Patterns, die alle nicht vorhanden wären, wenn man eix nur für das aktuelle Portage neu schreiben würde. Aber weil nie abzusehen ist, welche Features die nächste EAPI bringen wird, muss eix zwangsläufig immer eine Behelfsbaustelle bleiben... |
|
| Back to top |
|
|
franzf
Advocate
Joined: 29 Mar 2005
Posts: 4565
|
| Posted: Sat Jul 21, 2018 6:59 am Post subject: |
|
|
| mv wrote: | | franzf wrote: | | Lass doch den Maddin unsauberen Code schreiben. Solange sein eix (und der ganze andere "Wust" ) funktioniert |
Ich verwehre mich stark gegen die Behauptung, unsauberen Code zu schreiben. Gerade in Projekten wie chessproblem, knapsack, oder osformat habe ich mir sehr viel Gedanken nicht nur über die öffentlichen Interfaces sondern auch über den Codeaufbau selbst gemacht. Wenn Du da der Meiinung bist, ich würde unsauber programmieren, verweise bitte auf konkrete Stellen. |
Martin, ich behaupte nicht dass du dreckigen Code schreibst. Ich wollte nur dezent darauf hinweisen, dass du durchaus Erfahrung hast und in deinem Softwarefundus einiges an nützlichen Tools steckt, die man als Gentooaner kennt und schätzt. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German) 
