[Allegro] Index-Problem

[Thomas Berger]

Liebe Liste,

ich hatte Herrn Eversberg gebeten, folgendes zu korrigieren,
er ist aber scheints zu sehr damit beschaeftigt, die aktuelle
Version fertigzustellen, daher muss ich selber etwas dazu
bemerken, da ich die meine Arbeitsweise betreffenden Behauptungen
nicht unkorrigiert lassen moechte:


Am 21.11.2013 08:50, schrieb Bernhard Eversberg:
> Am 20.11.2013 17:35, schrieb Thomas Berger:
>>
>> Meine Aenderungen r40 und r41 an avjob.cpp sind durch Herrn Eversbergs r42
>> kommentarlos zurueckgesetzt worden. Merke: In einem Programm, das keine Bugs
>> hat, sollte man nicht versuchen, welche zu reparieren.
>>
> ja, z.B. auch in SVN.
> Das war nämlich meine Vermutung, als ich plötzlich gewahr wurde,
> daß mein Schreibrecht auf dem acon-Repo weg war, und auch noch auf
> anderen. Konsterniert denkt man da an alles, aber nicht daran, daß
> da jemand, der seit Jahren Schreibrecht hat aber noch nie etwas
> beigetragen, nunmehr kommentarlos was eingebracht hat. Erstens hätten
> Sie mich als Hauptverantwortlichen darauf aufmerksam machen müssen,
> und dabei zweitens mitteilen, worum's denn ging, es kann doch relevant
> sein für die Doku, und zumal man so kurz vor einer Festschreibung unter
> Zeitdruck ist. Das Schreibrechtproblem hat aber jedenfalls bei mir jede
> andere Erwägung weggewischt und dazu geführt, daß ich kurzerhand meine
> aktuelle Fassung reingeknüppelt habe, nach Wiederherstellung des
> Schreibrechts, und weiter zum nächsten Punkt auf der Agenda, die bei
> mir auch nicht nur von allegro ausgefüllt wird.
> 
> Erst Ihre Bemerkung jetzt hat mich veranlaßt, mal hinzuschauen auf die
> erfolgten Änderungen, und habe die wieder eingepflegt. Diesen Umweg
> hätten Sie auch verhindern und sich selbst den Ärger sparen können.
> Anmerkungen zu einer Änderung, nebenbei, gehören zudem nicht nur ins
> SVN, sondern auch in die Quelle, denn die bleibt, das SVN vielleicht
> nicht oder die Quelle nicht da drin.

Mir war zur Kenntnis gebracht worden, dass in HANS-Datenbanken bei
aktuellen acons die Stichwortsuche im Titelregister nicht zuverlaessig
funktioniert, nach laenglicher Fehlersuche habe ich als Ursache zwei
unabhaengige Fehler in acon gefunden, und im svn-Repository (auf
das ich gluecklicherweise Schreibzugriff habe) korrigiert, da Fehler
und Korrektur einerseits eindeutig zu sein schienen und die Aenderung
jeweils nur eine Zeile betraf. Das waren die erwaehnten "r40" und "r41",
die ich /selbstverstaendlich/ beim Einchecken mit einem Kommentar
ausgestattet habe:

r40 | thb | 2013-09-18 21:56:08 +0200 (Wed, 18 Sep 2013) | 1 line
don't propagate garbage to 'get' after successful 'find'

r41 | thb | 2013-09-18 22:04:40 +0200 (Wed, 18 Sep 2013) | 1 line
dbGet liefert wieder Resultat von AbGet() als retval


Unmittelbar anschliessend habe ich Herrn Eversberg per Mail
ueber Fehlerbild, Fehlerursache und die von mir durchgefuehrte
Korrktur informiert, da sich daran aber laengere Eroerterungen
allerhand weiterer Probleme anschlossen, ist die
etwas laenger geraten und von mir daher erst eineinhalb Stunden
nach Einchecken der Korrekturen ins SVN abgeschickt worden:

>>>
1. Enthaelt ein komplexer Suchbegriff fuer ein find-Kommando irgendwo
  das Zeichen "#", so wird die Suche erfolgreich ausgefuehrt, jedoch
  ist hinterher der Error-Zustand (unspezifisch) gesetzt. Grund ist
  die Automatik zum laden des ersten Satzes, der Switch ballert
  ein "f" als erstes Zeichen in die aktuelle Zeile und faellt nach
  "get" durch, dort wird nun auf "#" ~irgendwo~ in der Zeile
  getestet, weil es "first #" etc. gibt. D.h. nach erfolgreicher
  Suche nach solchen Suchbegriffen wird nicht der erste Satz der
  Ergebnismenge, sondern Satz #1 der Datenbank geladen. Ts. Ts.

Ich habe die entsprechende Aenderung als r40 ins acon-Repository
eingecheckt.

2. Voriges ist ja nur aufgefallen wegen der Fehlermeldung, die
hat ihren Grund in Aenderungen zu V32.irgendwas letzten Sommer,
als Sie sich ums Locking gekuemmert haben:

int AVJOB::dbGet(RECNR recn,int res)

gibt seitdem im Regelfall

       return Alock; // ==0 wenn OK ! -1=unbesetzt

zurueck, und das ist ziemlich schlecht: Erwartet wird die
positive Anzahl der Kategorien im geladenen Satz, damit
das Ergebnis von dbGet als "kein Fehler" interpretiert wird.

Revision r41 aendert das zurueck auf Rueckgabe von r, also dem
Ergebnis von AbGet().

/Wie/ aber die Locking-Resultate in das Ergebnis von dbGet
einfliessen sollen, ist mir unklar, weiter oben in dbGet
wird z.B. das Ergebnis von AwRecLock zurueckgegeben, falls
nicht 0, das ist aber ein positiver Integer, der Locking-
Fehler wird also als Erfolg interpretiert: Das duerfte nicht
beabsichtigt sein...

...
<<<

Herr Eversberg hat dann am 23.9. auf diese Mail geantwortet und
es entspann sich ein laengerer Mailwechsel um die hier ausgelassenen
Teile meines Reports, da ist dann vermutlich zu schnell in
Vergessenheit geraten, dass Korrekturen im SVN bereits vorlagen
und durch einfaches "auschecken" aktiv haetten werden koennen.

So wie Herr Eversberg es heute geschildert hat, gab es gestern
Rechteprobleme mit seinen Zugriffsdaten auf das Repository, in
Folge deren Behebung ist das (auf r39 vom Juni beruhende)
"Working Copy" mit den von ihm durchgefuehrten Korrekturen
unbrauchbar geworden, so dass er letztendlich seine Version
in eine neue Arbeitskopie /kopieren/ musste, dabei wurden dann
die im September durch mich erfolgten Aenderungen unbemerkt
ueberschrieben, denn die ueblichen Mechanismen der Quellcode-
Verwaltung, die das unbeabsichtige Nicht-Beruecksichtigen von
Aenderungen verhindern sollen, waren durch diese Vorgehensweise
ausgehebelt. Das (unkontrolliertes durch-die-Gegend-kopieren
von Dateien) ist aber nach meinem Eindruck beruhigenderweise
nicht die uebliche Vorgehensweise von Herrn Eversberg, sondern
war der besonderen Situation geschuldet.



> Was mich am Wort "Bug" stört, ist nicht die Vorstellung, allegro könnte
> welche haben, sondern das alberne, nichts zielführendes aussagende Wort
> selbst und sein Gebrauch in der bequemen Selbsttäuschung, damit schon
> was gesagt zu haben. Ist es mir bis heute nicht gelungen, das zu vermitteln?

Nun, ich bemuehe mich normalerweise um differenzierte Ausdrucksweise
und nutze daher auch die Vokabeln "Buglet" oder "Problem" und vermutlich
noch andere mehr. Da ich nicht davon ausgehen konnte, dass sich
die Leser dieser Liste nach Erwaehnung von "r40" und "r41" selbst
auf die Suche im SVN-Repository machen wuerden, um sich ganz objektiv
eine eigene Meinung ueber das Kaliber der Probleme zu bilden, halte
ich die Nenung als "Bug" fuer einen echten Service: Immerhin
hat acon die Recherche nach einem legitimen Suchbegriff heimlich
in ein "hole Satz 1" abgewandelt und das fiel nur daher wirklich auf,
weil "hole Satz 1" zwar ausgefuehrt wurde, aber durch ein voellig
unabhaengiges Problem faelschlicherweise einen Fehler zurueckmeldete.
Beides sind m.E. Bugs wie aus dem Lehrbuch, und die Tatsache, dass
sie ueber ein Jahr unentdeckt geblieben sind, mildert das nicht.

viele Gruesse
Thomas Berger