asuro lib 3.0 by MadMan2k

[cuda]

kann ich da die alten Dateien Asuro.src\firsttry bei 2.7 weiterbenutzen oder muss ich mir was neues anlegen.
z.B. im winavr Verzeichnis oder so...

[damaltor]

tjo... wie du evtl bemerkt hast wird die "normale" lib weiter bearbeitet. vielleicht fragst du, ob du nicht da mitarbeiten kannst? wäre doch besser, als das projekt zu spalten.

das lustige ist, dass ich das schon vor dem release der 3.0 gemacht habe und meine Änderungen dort im Branch 3.0 abgelegt wurden, den ich dann nachdem keine Änderungen vorgeschlagen wurden und das Projekt insgesamt stagniert hat als Version 3.0 übrer gna.org herausgebracht habe. (in absprache mit marvin)

die Änderungen die Interrupts in avr-libc 1.4+ betreffend wurden übrigens nicht in die 2.7 zurückportiert. Und da marvin bei gna.org zu mir gleichwertiger Admin ist frage ich mich wieso man für die 2.7 die veraltete codebase genommen hat und warum man jetzt bei der immernoch veralteten beleiben sollte...

das die änderungen schon vorher bestanden wusste ich, meiner meinung nach ist es allersings ein fehler (ganz besonders gegenüber anfängern) die funktionen umzubenennen. das forum hat auch entsprechend reagiert.
egal, ich will diene arbeit nicht schlecht machen oder kritisieren, im gegenteil, es ist echt klasse wenn weiterentwickelt wird. trotzdem sollte zusammengearbeitet werden. nicht alles was veraltet ist, ist schlecht, wind*ws vista zB hat mehr bugs als eine ameisenkolonie. also sprich mit den anderen, arbeitet zusammen und helft euch gegenseitig, sonst spaltet sich das projekt und das macht es weder für profis noch für anfänger einfacher. also frag doch einfach mal, warum die alte codebase verwendet wird. vielleicht hat es ja einen grund...

[MadMan2k]

das die änderungen schon vorher bestanden wusste ich, meiner meinung nach ist es allersings ein fehler (ganz besonders gegenüber anfängern) die funktionen umzubenennen.

naja, wenn ein anfänger auf die Lib wechselt, wir er eh die doku wegen den neuen funktionen dazu lesen müssen. Dort kann man dort die Umbenennung vermerken. Die "neuen" Anfänger kann man dann direkt an die neue lib verweisen.
Ich finde es nämlich besser die Bennenung konsistent in englisch zu halten als ewige alte Zöpfe mitzuschleppen. Meinetwegen können wir auch eine Übergangszeit festlegen in der die funktionen deprecated aber noch vorhanden sind.

. nicht alles was veraltet ist, ist schlecht, wind*ws vista zB hat mehr bugs als eine ameisenkolonie.

also übertragen auf die libs darfst du gerne etwas konkreter werden
mit veraltet meinte ich, dass die fehler die ich in der 3.0 gefixt habe noch in der 2.7 drin sind.

[damaltor]

naja, die alte lib hat fehler. was solls, sie funktioniert recht gut. trotzdem ist nicht zwingend die neue version fehlerfrei; dazu müsste sie erstmal im dauertest laufen. warum meldest du dich nicht mal bei der anderen gruppe, sagst, du willst mitmachen und hast ein paar ideen und bugfixes, und ihr führt das alles wieder zusammen? es ist sehr schade wenn so ein (relativ) großes projekt sich spaltet aus mangelnder zusammenarbeit.

die umbenennung der funktionen:
klar sind die rechtschreibfehler von arexx recht dämlich (break, odometrie usw). aber 99,9 % der geschriebenen programme basieren auf diesen fehlern. man müsste also alle demo-programme von arexx, alle programme hier aus dem forum, alle, die man evtl schonmal geshrieben hat usw ändern bevor man mit der neuen lib arbeiten kann.
sowie das programm kompiliert ist, interessieren die schreibfehler ohnehin keinen mehr, warum sollte man also so eine (zwar fachlich korrekte, aber aus anwendersicht recht unnötige) änderung vornehmen?

[m.a.r.v.i.n]

Hi,

hier mal mein Vorschlag zur Güte, damit hoffentlich wieder alle glücklich und zufrieden sind:

* wir mergen beide Libs zu einer Version zusammen. Bugfixes aus der 3.0 Version und Doku und neue Funktionen aus der 2.7 Version. Die Doku sollte 2-sprachig de-en bleiben, wie bereits in der 2.7rc3 Version.
* Die nichtenglischen Funktionsnamen und Definitionen werden in englische umbenannt. Trotzdem bleibt die alte Schreibweise als Define vorhanden, damit sich auch alte Quellen ohne Änderungen übersetzen lassen. In der Doku werden die alten Schreibweise als veraltet gekennzeichnet. Die mitausgelieferten Beispiele in der Lib werden auf die neue Schreibweise umgestellt. (ist teilweise auch schon so in der 2.7rc3 gemacht)
* Ob das Repository bei Gna oder Sourceforge liegt, ist mir erstmal egal. 1 Repository sollte längerfristig genug sein. Neue Releases sollte man allerdings auf beiden Servern veröffentlichen.

Hab ich noch irgendwas vergessen, Gegenvorschläge?

[damaltor]

nein, find ich klasse. so sollte das sein =)

[radbruch]

MotorPower() als Ersatz für MotorSpeed()?

Ach ja, man könnte die neuen Funktionsnamen doch als #define ergänzen, dann würden auch die alten Programme laufen.

[MadMan2k]

Hi,

hier mal mein Vorschlag zur Güte, damit hoffentlich wieder alle glücklich und zufrieden sind:

* wir mergen beide Libs zu einer Version zusammen. Bugfixes aus der 3.0 Version und Doku und neue Funktionen aus der 2.7 Version. Die Doku sollte 2-sprachig de-en bleiben, wie bereits in der 2.7rc3 Version.
* Die nichtenglischen Funktionsnamen und Definitionen werden in englische umbenannt. Trotzdem bleibt die alte Schreibweise als Define vorhanden, damit sich auch alte Quellen ohne Änderungen übersetzen lassen. In der Doku werden die alten Schreibweise als veraltet gekennzeichnet. Die mitausgelieferten Beispiele in der Lib werden auf die neue Schreibweise umgestellt. (ist teilweise auch schon so in der 2.7rc3 gemacht)
* Ob das Repository bei Gna oder Sourceforge liegt, ist mir erstmal egal. 1 Repository sollte längerfristig genug sein. Neue Releases sollte man allerdings auf beiden Servern veröffentlichen.

Hab ich noch irgendwas vergessen, Gegenvorschläge?

1. meiner Meinung nach sollte die doku in den sources auf alle fälle englisch sein. Dazu sollte es noch HTML alternativen in anderen Sprachen. (einschließlich deutsch) geben.
2. wär ich auch dafür. leider lässt sich nicht alles über den präprozessor umbiegen. "compat.h"?
3. auf gna hab ich schon den asuro flasher und man kann ohne viel umstellung auch den neuen bootloader hinzufügen. außerdem sind die server von gna deutlich flotter. daher wäre ich hier für gna.org.

außerdem hätte ich noch eine Anmerkung zur Änderung 2.6 -> 2.7:

aufsplitten in viele dateien. warum? ich würde hier höchstens in die kern bibliothek mit der ursprünglichen funktionalität und einige extra libs wie für I2C, UltraSchall etc. unterschieden.
Zudem würde ich noch einige zu spezifische Funktionen ausgliedern und nur optional anbieten. (PrintInt)

[damaltor]

die teilung ist dazu da, um kleinere hex-files zu produzieren. so werden nur die tatsächlich gebrauchten funktionen mitkompilieren.

[Sternthaler]

Hallo zusammen (ja zusammen)
Ich war gerade auf dem gna.org-Server, da mich das Thema ja gerade wegen der Doku auch interressiert.

Die auf dem Server abgelegte Doku ist etwas 'schmaler' als die bis jetzt unter sourceforge vorhanden Doku. Das ist nicht so dramatisch.
Aber wie kann ich die doppelt verpackte Lib auspacken. Für tar hätte ich ja was, aber das bz2 kennen meine Entpacker und ich nicht.