ZFX + Developia

Krishty hat geschrieben:

kimmi hat geschrieben:Wir bauen sehr zuverlässige embedded Devices damit, so schlimm isses nicht.

Das sagst du weil es

1. deine eigenen Werke sind; und
2. du dich durch dein Alter bedingt nicht jeden Tag mit den Script-Kiddies rumschlagen musst, die glauben, dass sie eine Eclipse-Installation zu Programmierern macht.

Ich versuche weiterhin nicht, hohe Komplexität zähmbar zu machen, sondern sie im Gegenteil möglichst weh tun zu lassen, damit man sie erst garnicht entstehen lässt.

Zum einen: nein, es sind nicht meine Werke, ich bau nicht mehr so viel SW im Job wie noch vor einigen Jahren.
Zum Thema Komplexität: Handhaben wir genauso und wenn man mit Treibern, sicherheitsrelevanten Anforderungen, wilden Dokumentationen von wilden embedded OS und überhaupt wilde OS zu zähmen hat, ist die einzige Möglichkeit, hier einen Überblick zu kriegen, Komplexität so weit es geht zu vermeiden.
Aber ich weiß sehr gut, wovon du sprichst. Ich hab mal in einer Firma mit dem "c++"-Codes eine F77-Entwicklers "gearbeitet" :).

Ich lese gern hier voller Be- und Verwunderung deine Ideen und Erkenntnisse zu Optimierungen, Compiler-Bugs und neuen Sprach-Features. Allerdings begnüge ich mich im Job meist mit Hausmannskost. Wie ich einst lesen durfte: "Konzentriere dich beim Entwickeln darauf, für den Nutzer einen Mehrwert zu schaffen, nicht für den Entwicker." Der Benutzer zahlt die Party hoffetlich irgendwann.

Gruß,
Kimmi

Das String Pooling von Visual C++ scheint ziemlich abgefuckt. static unsigned char wird als String behandelt und gepoolt, static unsigned char const aber nicht (oder zumindest nicht immer).

Dokumentation darf keine Weblinks enthalten. Nach zwei, drei Jahren sind alle Links tot und keiner weiß mehr, worauf http://msdn.microsoft.com/en-us/library/bb531421 verwiesen hat.

Ich ersetze alle Weblinks in allen meinen Quelltexten durch Verfasser und Titel. Suchmaschinen werden MSDN — "_mm_cvtsd_f64" auch in zehn Jahren noch finden können.

Oh, Windows!

Der Installer-Dienst ist kaputt.

More specifically, msiexec.exe hat eine Größe von 0 Bytes (durch ein Festplattenproblem in der Vergangenheit, das der Hersteller leugnet). Allein bis ich von abstrakten Fehlercodes und fehlgeschlagenen Updates zu dieser Erkenntnis gelangt bin, hat es schon gedauert.

Manuell ersetzen geht nicht, weil Windows nicht die Rechte dafür gewährt. Solche Systemdateien darf ja nicht einmal ein Administrator ersetzen, sondern nur vertrauenswürdige Installer.

Vertrauenswürdige Installer gibt es aber kaum weil Microsoft den Dienst seit Windows 7 nicht mehr als Download bereitstellt. Einziger Kandidat ist die Reperaturoption.

Die lokale Reperatur erkennt das Problem; sucht die Originaldatei in ihrem Repository – und meldet, dass die ebenfalls schrottreif ist.

Die Reperaturkonsole von der DVD geht nicht, weil der verdammte Notebook-Hersteller überhaupt keine Installations-DVD beigelegt hat. Ich darf also wieder drei Stunden lang die ISO aus dem Netz saugen und auf einen USB-Stick installieren.

Eine einzige kaputte Datei ist das Problem. Die ich 1:1 von einem anderen System kopieren könnte. Und ich muss mein halbes Wochenende mit einem Arsenal von Hobby-PC-Tüftler-Tricks verschwenden um sie zu ersetzen.

Auf die Gefahr hin Eigenwerbung zu machen: Ich habe vor 3 Jahren mal ein Vid-Tutorial gemacht, um Dateien in System32 zu ersetzen, die auch Admins nicht ersetzen dürfen:
http://www.youtube.com/watch?v=sw5ND2mlcmg

Ist es das, was du suchst?

Ja; dankesehr! Es geht um das System meiner Mutter; ich werde mich am nächsten Wochenende weiter drum kümmern.

Kannst du nicht einfach schnell mal irgendein Linux von einer Live-CD booten und die Datei rüberkopieren? ;)

"http://msdn.microsoft.com/en-us/library/bb531421"
So sollte auch kein Link aussehen. Aber ist eben Microsoft, einfach ignorieren.

..und so sehen Webseitenstrukturen achtenswerter Firmen aus: http://developer.android.com/design/pat ... views.html

Krishty hat geschrieben:Dokumentation darf keine Weblinks enthalten. Nach zwei, drei Jahren sind alle Links tot und keiner weiß mehr, worauf http://msdn.microsoft.com/en-us/library/bb531421 verwiesen hat.

Ich ersetze alle Weblinks in allen meinen Quelltexten durch Verfasser und Titel. Suchmaschinen werden MSDN — "_mm_cvtsd_f64" auch in zehn Jahren noch finden können.

spobat hat geschrieben:"http://msdn.microsoft.com/en-us/library/bb531421"
So sollte auch kein Link aussehen. Aber ist eben Microsoft, einfach ignorieren.

..und so sehen Webseitenstrukturen achtenswerter Firmen aus: http://developer.android.com/design/pat ... views.html

Wären hier URNs nicht deutlich sinnvoller? Gerade bei Doku, die man schwer ändern kann (z.B. Bücher), wäre der Vorteil von URNs schon wichtig. Der Ort muss dann halt aufgelöst werden (die Zuordnung könnte ja in einer Datenbank gehalten werden). Das bedeutet dann zwar Pflegeaufwand bei MS und Co, aber "Links" würden nicht mehr ins Leere greifen, sofern diese Pflege gründlich ist. Im anderen Fall (URL) wäre das gar nicht möglich - es sei denn die Orte ändern sich nie.

Braucht man dafür nicht eine lokal installierte Applikation, die das spezielle urn-präfix kennt?

10 Stunden Web-Development am Tag macht einen echt fertig.

Ständig darf man auf X Browsern testen, ob denn noch alles richtig gerendert wird und das Javascript seinen Job ordentlich tut.
Nicht nur, dass die Browser das Html und das Css unterschiedlich interpretieren, nein es gibt auch in Javascript 100te unterschiede...
Ich wünsche mir ein schnelles Web, das funktioniert. Eines, bei dem Jede Webseite die W3C-Validation besteht.
Bin mir sicher, dass man Webbrowser in allen drei Bereichen (HTML/CSS/JS) deutlich optimieren könnte, wenn sie nicht auf die Dummheiten tausender Webentwickler eingehen
müssten. Tut es bitte nicht. Eine Fehlermeldung "This Website just sucks, please don't use it.", wäre mir lieber.
Ein guter Ansatz ist Dart ( dartlang.org ), auch wenn es nur ein kleiner Schritt ist!

Ach ja, und Chrome auf Windows ist ganz sicher nicht das gleiche wie Chrome auf Mac oder Chromium auf Linux.
Man darf also auch über Betriebssysteme hinaus testen. Und dann sind da noch Handies. Und Tablets.

Ich werde mir eine kleine (2,3 Tage) Auszeit mit Scheme und C++ gönnen :)

Bin ich froh, dass ich webmäßig nur am Backend rumdoktore :D

spobat hat geschrieben:10 Stunden Web-Development am Tag macht einen echt fertig.

Ständig darf man auf X Browsern testen, ob denn noch alles richtig gerendert wird und das Javascript seinen Job ordentlich tut.
Nicht nur, dass die Browser das Html und das Css unterschiedlich interpretieren, nein es gibt auch in Javascript 100te unterschiede...
Ich wünsche mir ein schnelles Web, das funktioniert. Eines, bei dem Jede Webseite die W3C-Validation besteht.
Bin mir sicher, dass man Webbrowser in allen drei Bereichen (HTML/CSS/JS) deutlich optimieren könnte, wenn sie nicht auf die Dummheiten tausender Webentwickler eingehen
müssten. Tut es bitte nicht. Eine Fehlermeldung "This Website just sucks, please don't use it.", wäre mir lieber.
Ein guter Ansatz ist Dart ( dartlang.org ), auch wenn es nur ein kleiner Schritt ist!

Ach ja, und Chrome auf Windows ist ganz sicher nicht das gleiche wie Chrome auf Mac oder Chromium auf Linux.
Man darf also auch über Betriebssysteme hinaus testen. Und dann sind da noch Handies. Und Tablets.

Ich werde mir eine kleine (2,3 Tage) Auszeit mit Scheme und C++ gönnen :)

..und trotzdem werden wir armen webdevs oftmals nicht ernst genommen :(
Das ist harte Arbeit ;)

btw: Wenn du nur noch ab IE9 und aufwaerts und die neusten versionen von den anderen browser unterstuetzen musst sind die meisten fehler die beim cross-browser-testing auffallen einfach nur auf schlechte Entwicklung zurueckzufuehren.
Aber natuerlich wird das dann nicht ordentlich gemacht sondern irgendwelche merkwuerdige browser-hacks genutzt die man wirklich fast niemals braucht (wenn man nicht total kranke sachen tut..aber wenn man das macht ist man auch selbst dran schuld :D).

Unterm Strich: Sei froh das du den quatsch nicht vor so 5 Jahren gemacht hast und noch IE6/7 und sowas unterstuetzen musstest - das war noch echter Spass. Gute alte zeit :D

spobat hat geschrieben:Braucht man dafür nicht eine lokal installierte Applikation, die das spezielle urn-präfix kennt?

Kommt halt drauf an. Wenn ich eine Online-Doku wie die MSDN habe, könnte man die Zuordnung per Datenbank realisieren. Die Datenbank müsste die MSDN dann natürlich immer finden, aber das sollte leichter sein, als die Orte unzähliger Seiten immer gleich zu lassen.

Bei Büchern ist das natürlich etwas problematischer. Aber ich könnte mir auch eine "globale" Datenbank vom W3C oder so vorstellen. Wäre natürlich aufwendig dann für jede kleine Seite eine URN zu beantragen, es sei denn man lässt sich clevere Namens-Konventionen einfallen. Für ISBNs gibts ja auch URNs, wobei eine ISBN ja prinzipiell schon sowas wie eine URN ist.

Stunden damit zugebracht, eine ordentliche Prozess-Kill-Mechanik unter Linux zu bauen (wenn ein Stick ein- oder ausgesteckt wird, sollen verschiedene Programme gestartet und wieder beendet werden)

BeRsErKeR hat geschrieben:Aber ich könnte mir auch eine "globale" Datenbank vom W3C oder so vorstellen.

Ich würde sagen die globale Datenbank ist das URL System im Internet. Microsoft und viele andere sind da einfach doof und haben ihre URLs nicht im Blick. Ob die Datenbank nun von URLs zu Content oder URNs zu Content mappt sollte eigentlich keinen großen Unterschied machen solange die Themen eigene IDs bekommen.

Visual C++ 2012, im Header:

    Class & operator = (Class const &) { }

… und die Definition aus der Klasse rausgeschoben:

    Class & Class::operator = (Class const &) { } // error: function missing return value

I can't even



P.S. @ URNs: Ich suche ein System, das keine Wartung braucht, weil die Quelltext nun zehn Jahre schlummern werden bis die ein völlig Fremder wieder auspackt und verstehen muss. Wenn ich heute eine Datenbank mit URNs in einem fremden Projekt vorfände, wüsste ich nicht, was sie mir bringen sollen. In zehn Jahren gibt es das Programm, womit konvertiert wurde, vielleicht garnicht mehr.

Da werden relative URLs in einer Ordnerstruktur das sinnvollste sein. Das wird man noch sehr sehr lange verstehen und man kann es ohne Datenbank und Server überall hinpacken. So würde ich ja am liebsten auch das alte Developia und das alte ZFX haben. Einmal online und einmal als Zip-Archiv zum Runterladen und genauso sollte das auch bei allen anderen Webseiten mit wichtigen informationen sein.

Krishty hat geschrieben:P.S. @ URNs: Ich suche ein System, das keine Wartung braucht, weil die Quelltext nun zehn Jahre schlummern werden bis die ein völlig Fremder wieder auspackt und verstehen muss. Wenn ich heute eine Datenbank mit URNs in einem fremden Projekt vorfände, wüsste ich nicht, was sie mir bringen sollen. In zehn Jahren gibt es das Programm, womit konvertiert wurde, vielleicht garnicht mehr.

Wenn die Datenbank weg ist, ist in der Regel auch die Doku/Seite weg. Von daher ist es dann eh egal.

Chromanoid hat geschrieben:Da werden relative URLs in einer Ordnerstruktur das sinnvollste sein. Das wird man noch sehr sehr lange verstehen und man kann es ohne Datenbank und Server überall hinpacken. So würde ich ja am liebsten auch das alte Developia und das alte ZFX haben. Einmal online und einmal als Zip-Archiv zum Runterladen und genauso sollte das auch bei allen anderen Webseiten mit wichtigen informationen sein.

Naja aber das bringt doch auch nix. Wenn eine absolute URL zur MSDN ins Leere greift, wird es eine relative doch auch, bzw. du kannst doch gar nicht relativ zur MSDN verlinken, wenn du nicht selbst auf dem Server liegst. Ich dachte es geht hier um die Verlinkung zu einer externen Quelle. Relative URLs machen doch nur innerhalb der gleichen Seite/Doku Sinn.

Ja, ich meinte innerhalb einer Ressourcensammlung, die über verschiedene Wege erreicht werden kann.

URNs für Ressourcen:
Alle URI-Systeme sind ja immer auf einen Auflöseprozess angewiesen. Leider haben wohl die wenigsten User eine Infrastruktur zur Auflösung von URNs direkt verfügbar. Es hat sich da ja auch noch keine Standardarchitektur etabliert. Kleine kostenfreie Namensräume (z.B. für Krishty) zu registrieren würde mit der Etablierung einer solchen Standardarchitektur immer noch ein Problem sein. Namensräume müssen ja theoretisch unendlich lange geschützt bleiben und dürften auch nicht übertragen werden. Es gibt glaube ich schon viele Vorschläge wie man solche kleinen Namensräume handhaben soll, das hier finde ich dazu ganz interessant: http://www.ietf.org/mail-archive/web/ur ... 00188.html / http://www.ietf.org/mail-archive/web/ur ... 00190.html

Das DNS für kleine private Namensräume einzusetzen, halte ich für das sinnvollste. Wie in der verlinkten Diskussion reicht der Domänenname natürlich nicht aus, da Domains ja recht häufig den Besitzer wechseln. Momentan erscheint mir ein rückwirkender Zeitstempel am schönsten. Also wenn ich eine Domain schon ein volles Jahr lang besitze, reicht dieses erste Jahr aus, um meinen Domain-Namen zu einem eindeutigen Namensraum zu machen (urn:dns:zfx.info:2003). Wenn man die Domain nun erst einen vollen Monat besitzt und schon einen Namensraum braucht, muss man also auch den Monat dazu nehmen (urn:dns:zfx.info:2002-07) usw.

Den so erhaltenen Namensraum könnte man dann benutzen, um eine beliebige Ressource zu benennen. Dabei sollte es sich am besten um eine o.g. Ressourcensammlung mit relativen Links handeln, dann reicht nämlich die Auflösung der Einstiegspunkt URN aus um die komplette Sammlung zu erschließen. Ein User könnte dann in seinem URN Auflöseprogramm für einzelne URN-Einstiegspunkte eigene URLs hinterlegen und so nicht mehr verfügbare Internetressourcen selbst bereitstellen. Dann braucht man auch keine große Datenbank, die jedes einzelne mit einer URN bezeichnete Dokument auflöst: urn:zfx.info:2003:www/viewtopic.php?f=9&t=307

Aus meiner Sicht ist also wenn überhaupt eine Kombination aus relativer URL und URN als Einstiegspunkt sinnvoll.

Das klingt in der Tat sehr interessant. Guter Ansatz!

Chromium: HTTP download of files over 2GB will stop exactly at 2GB and report as Done

WTF

WTF

besteht seit 2011?!

WTFFFFWTFWTFWTF

> Please, How to solve this?

> Also having this problem on Google Chrome 14.0.835.163 m on Windows 7 SP1 64-bit.

> To me it seems ridiculous. I've tried to download a 3GB over http in Chrome both for Mac OSX Lion and Windows 7. Once it reaches 2GB, download reports as done, although it hasn't downloaded the entire file yet.

> That had happened to me a lot before. It suddenly started downloading completely again about a week ago or so, I didn't do anything.

> Closing the bug since users report that the issue is not reproducible.

WTFWTFWTFWTFWWTTTTFFFTFWFFTWFFWFTWFWFTWFTFTFT

Erinnert mich an den Schmankerl: http://bugs.sun.com/view_bug.do?bug_id=8017776 betrifft den contextclassloader bei java webstart in verbindung mit swing

Now if i start with the java console enabled/showing. It works just fine. If i disable or hide the java console through the preferences the bean class can't suddenly be found.

Ist allerdings in der nächsten Version gefixt...

Ich tippe mal auf signed int als Zählervariable für die heruntergeladenen bytes pro Datei :mrgreen:

Naja das ganze scheint ja nicht immer aufzutreten. Vielleicht irgendeine Komponente, die nur manchmal anspringt?

Das ist unmöglich zu sagen wenn man nicht weiß, welchen Download-Manager Chromium verwendet und wie er funktioniert und wie er angepasst wurde.

Ich frage mich auch, aus welchen Beweggründen Chrome noch ein 32-Bit-Prozess ist … ob nur wegen des geringeren Speicherverbrauchs, oder ob irgendwelche Abhängigkeiten noch nicht ganz portabel sind, oder ob sie sich den Aufwand von zwei Versionen sparen wollen.

Sofern ich weiss liegt das an V8. Das ist [noch?] nicht ganz portabel :).
Ob sie V8 ueberhaupt noch x64-komatibel machen, bleibt offen. Schliesslich haben sie ja bald Dart.

Ich kann aber auch nicht verstehen, warum du unbedingt einen 64-bit Prozess (oder bei Chrome: Prozess-Armee) willst. Das muss ja keinesfalls bedeuten, dass dann alles toll und schnell ist. :/

32bit ist allgemein hässlich. Ganz ehrlich, wer hat mit Code Segmenten überhaupt angefangen? Und von Calling Convention will ich gar nicht erst reden. AMD64 ist vom Programmieren her einfach viel schöner.

Danke für den Hinweis mit V8!

Ja; es gibt zwar einige Gründe, die für 32-Bit-Maschinentext sprechen (zu allererst die höhere Lokalität); aber 64-Bit ist sauberer, schneller, und einfacher zu warten. Darum interessieren mich die genauen Beweggründe, warum Chrome nur als 32-Bit-Version verfügbar ist.

Krishty hat geschrieben:Danke für den Hinweis mit V8!

Ja; es gibt zwar einige Gründe, die für 32-Bit-Maschinentext sprechen (zu allererst die höhere Lokalität); aber 64-Bit ist sauberer, schneller, und einfacher zu warten. Darum interessieren mich die genauen Beweggründe, warum Chrome nur als 32-Bit-Version verfügbar ist.

Also bei mir ist die V8-Bibliothek eine 64-Bit-Executable, ebenso wie Node.JS. Beim Chrome-Browser bin ich mir nicht so sicher.