Verfasst am: 05.09.2012, 22:33
Titel: Problem mit "load" unter R2012a
Hallo Forum,
ich habe eine Menge programmiert und stelle fest, dass seit R2012a nichts mehr läuft. Es liegt daran, dass txt files nicht mehr richtig gelesen werden. Ich schreibe unter R2011b
und in welchem Format liegt die Textdatei vor? Eine Beispieldatei würde helfen.
Grüße,
Harald
Hallo Harald
Es hängt eine Datei an. Im gegebenen code fehlen die Anführungsstriche: dataset=load('dataset.txt'), sorry. Ach ja: Ich nutze Macs mit OS10.6.8. Am Ende liegt es wieder daran ...
Beste Grüße,
Christian
Wow! Das nenne ich mal einen peinlichen Bug. Das Zeilen-Enden-Drama zieht sich ja immerhin schon seit DOS 1.0-Zeiten auf dem IBM-PC (1981!) hin. In diesen 33 Jahren sind tausende Programme an den \r\n-Tücken gescheitert. TMW sollte dringend solche Standard-Probleme in den Unit-Tests prüfen, bevor eine Version released wird. Andernfalls wird der Eindruck provoziert, Matlab würde gar nicht mit Unit-Tests geprüft...
Was ich von einem Bug-Fix per Upgrade halte, habe ich in diesem Forum wiederholt betont. Neue Versionen enthalten offensichtlich(!) immer auch neue Bugs. Wenn man ein größeres Programm für ernsthafte Zwecke benutzt, ist ein Matlab-Version-Upgrade also keine Methode, um die Gesamt-Qualität zu steigern oder auch nur zu erhalten.
Zudem kann sich ja nicht jeder Kunde ein Upgrade leisten. Die Workarounds sind zwar meistens sehr hilfreich (hier ein großes Lob!), aber wenn man z.B. ein Programm veröffentlicht, muss man bisweilen einen Rattenschwanz mit Ausnahmen abfangen, weil Release A bei diesen Befehl scheitert, B bei einem anderen, etc...
Ich bitte den Technischen Support, den Entwicklern kräftig auf die Füße zu treten. Schwächliche oder fehlende Unit-Tests kosten die Benutzer und den Support viel Zeit und Geld.
Hallo Harald,
vielen Dank für die Information!!! Blöd, dass es da keinen patch für gibt. Ich habe jetzt den R2012b prerelease installiert und es funktioniert tatsächlich. Das offizielle R2012b release steht aber auch in 2 Wochen oder so an (wenn man warten kann).
Viele Grüße,
Christian
Ich hatte so sehr versucht um das Wort "blöd" herum zu kommen... Du hast aber ganz recht. Leider scheint Patchs einzelner Funktionen nicht ohne weiteres Möglich zu sein.
Man kann natürlich auch in den Files \r durch \n ersetzen, also CHAR(13) durch CHAR(10):
Code:
fid = fopen(FileName, 'r');
Data = fread(fid, Inf, '*char');
fclose(fid);
Data = strrep(Data, char([13, 10]), char(10)); % DOS -> Unix
Data = strrep(Data, char(13), char(10)); % MacOS9 -> Unix
fid = fopen(FileName, 'w');
Data = fwrite(fid, Data, 'char');
fclose(fid);
Ich habe diesen Fall überprüft. Seit Januar 2012 sind nur 5 Kunden mit diesem Problem an MathWorks herangetreten. Auch wenn hier jemand gesagt hat, dass auch andere Betriebssysteme betroffen sind, waren es interessanterweise nur Mac user.
Der Bug wurde zügig gefixt und es gibt einen Workaround. Ob peinlich oder nicht, aber es kommt auf die Häufigkeit an und wie schwerwiegend ein Bug ist, ob ein Patch (als Teil eines Service Packs) geliefert wird. Von einem R2012a SP1 habe ich noch nicht gehört. Jeder Kunde, der sich an den Support wendet und nach einem Patch fragt kann sich darauf verlassen, dass der Aufwand von den Entwicklern geprüft wird. Technisch gibt es da extrem grosse Unterschiede.
Zu dem inwiefern der Support den Entwicklern auf die Füsse steigen soll - ich habe gesehen, dass ein Manager aus der Entwicklung schon von selbst aktiv geworden ist. Mehr kann ich öffentlich nicht sagen.
Vielen Dank für die Antwort. Wie immer ist das Feedback von einem Insider sehr wertvoll. Ich kann
MAT-files im ASCII-Format mit CHAR(13) als Zeilentrenner wurde sicherlich unter MacOS-9 geschrieben. Dann finden sie wohl eher ihren Weg auf einen MacOS-X-Rechner, statt auf einen Windows- und Linux-PC.
Zitat:
Der Bug wurde zügig gefixt und es gibt einen Workaround.
Nun, "zügig" heißt offenbar nachdem das Release von TMW getestet wurde und die Pre-Release-Tester auch nichts fanden.
Mit "peinlich" meine ich, dass nun schon Generationen von Programmierern über das gleiche Problem stolpern. Der dämliche Streit um die Normierung der ASCII-Codes hat schon vor 30 Jahren die Programmierer zur Weißglut getrieben und das setzt sich bei Unicode nahtlos fort.
Programmierfehler sind verständlich und nicht zu verhindern. Aber Steuerzeichen bei ASCII-Text sind absolute Standard-Probleme und müssen unbedingt umfassend getestet werden, genau wie numerische Funktionen auf Inputs von leeren Arrays, Inf, NaN, imaginären Zahlen, SINGLEs, Integer-Typen etc. getestet werden müssen. Offenbar wurde hier punktuell geschlampt.
(Dear programmer of LOAD and/or its tests: Sorry! I never forget that I have programmed even more silly bugs! I have implemented the solution of "A*x = 0" by "x = -A" for a scientific publication about numerical methods. Because this was written in C and not in Matlab, the program did even run, but not successfully of course.)
In Matlab tauchen immer wieder Bugs auf, die in meinen Augen durch übliche Unit-Tests hätten auffallen müssen. Selbstverständlich lässt sich TMW nicht in die Karten schauen, wenn es um die internen Test-Methoden geht. Ich bin mir sicher, dass TMW sehr viele Bugs findet und bereinigt, bevor eine Version veröffentlicht wird. Nur rutschen immer wieder Bugs durch, die trivial aussehen. Ich erinnere mich an "A'\b;", das in 2009b (ohne SP1!) im Gegensatz zu "transpose(A)\b" falsche Ergebnbisse lieferte. Ein paar weitere wurden in CSSM: 26735 diskutiert. Die erwähnten Bugs waren "schwerwiegend" und traten "häufig" auf. Und TMW hat deshalb auch ein SP1 für 2009b herausgegeben. Das fand ich sehr gut, aber natürlich auch sehr notwendig.
Auch dass jetzt ein Manager der Entwicklungsabteilung aktiv wird, zeugt vom hohen Engagement und effizienter Qualitäts-Kontrolle. Ebenso, dass der Technische Support in diesem Forum so aktiv ist und offenbar bestens dokumentiert wird, wieviele Kunden welche Probleme hatten.
Mir ist klar, dass Servicepacks für TMW enorm teuer sind. Auf der anderen Seite bekomme ich fast täglich Micro-Patchs von Microsoft, Oracle und Adobe, wobei ich für Java und den Acrobat-Reader nicht einmal etwas bezahlt habe. Die Workarounds in Matlab's Bug-List sind bereits sehr gut. Zusammen mit einem automatischen Download wären dies oft bereits Micro-Patchs und viele Probleme könnten so bei den Nutzern so abgefangen werden. Gibt es keine Möglichkeit die SPs so handlich zu machen, dass auch 10 Stück davon pro Halbjahr machbar und finanzierbar werden?
Während ich die Patchs der genannten Firmen sehr nützlich finde, ist deren Support schlecht. Was nützen tägliche Updates, wenn z.B. Standard-Funktionen von Windows wie SHFileOperation nicht gefixed werden und undokumentiert ihr Verhalten ändern? Man kann hunderte Emails an Microsoft senden und sicher sein, dass gar nichts passiert. Ich weiß genau, warum ich meine Programme mit Matlab erstelle, und nicht mit MSVC.
Dass sich nur 5 User beschwert haben, heißt zwar, dass sich (Anzahl der Matlab-User) minus 5 nicht beschwert haben. Mit einem ordentlichen Unit-Test hätten sich 0 User beschwert.
Gruß, Jan
[EDITED, Jan, 07-Sep-2012 08:00, leicht gekürzt]
Zuletzt bearbeitet von Jan S am 07.09.2012, 07:18, insgesamt 2-mal bearbeitet
Vielen Dank für die Beiträge und die background infos hinsichtlich der bugs. Die Sache ist sicherlich komplexer als sie scheint. Es ist allerdings schwierig zu beurteilen, wie es sein kann, dass ein offenbar plattformübergreifender bug in so einem Basisbefehl wie "load" nicht von viel mehr usern angezeigt wurde. Klar, es gibt workarounds, aber dennoch, es arbeiten doch sicher viele Leute mit dem Kommando.
Nichtsdestoweniger erscheint der TMW-support sehr hilfsbereit und engagiert, was man von anderen Softwareunternehmen nicht immer so behaupten kann.
Beste Grüße,
Christian
Einstellungen und Berechtigungen
Du kannst Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum posten Du kannst Dateien in diesem Forum herunterladen
MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.
RSS