LCR-Messgerät anschaffen sinnvoll?

Also sind die Kommentare dann nicht in der Registry zu finden. Danke, mehr wollte ich nicht wissen.

Aha... auch die Einstellungen und Save-Files diverser Programme? Ich kann mich noch dran erinnern, dass diverse Programme ihren Kram in ihrem Installationsorder speichern wollten...

Gerrit

Hier ist schon der Denkfehler. Die Anwendungen haben nicht lokal installiert zu sein sondern auch vom Netz zu kommen. Ebenso sollten Profile nicht auf die lokale Platte kopiert werden sondern auch nur auf dem Server vorhanden sein.

Gerrit

Bei 300Baud ist das noch nicht so das Problem, da werden 1 und 0 als diskrete Toene kodiert. Ich hab auch ueber 2 Jahre ein

Genau betrachtet ist es kein Schwachsinn. vi ist schwer zu lernen, aber wenn man ihn dann mal kann ist man extrem schnell. Abgesehen davon taugt er noch immer ueber langsame Leitungen (was ich fast taeglich brauche) und er ist auf jedem *IX zu finden.

Ich hab es getan und es geht... Du scheinst schlechte Leitungen zu haben. :)

Gerrit

Martin Klaiber wrote: > Dass man die Daten für die interne Verarbeitung innerhalb eines Programms

Ja, derzeit schon. Aber ich finde, die Entwicklung sollte langfristig in die Richtung gehen, dass es keine andere Baustelle ist. Wohlgemerkt: mir geht's hier um die _langfristige_ Entwicklung.

Die Ansätze mit der .Net-CLR/Powershell verfolgen da schon die richtige Idee. Virtuelle Maschine, die ein einheitliches Objekt(-austausch)format vorgibt, aber trotzdem mit verschiedenen Sprachen nutzbar ist. An der mangelnden Performance wird die Sache schon nicht scheitern, dafür sorgt Moore's Law automatisch.

Schoen... und der erzeugte Code ist dann aber nur mit VS durch den Compiler zu bekommen, oder wie loese ich das manuell?

Dann haben sie einfach noch nichts anderes probiert. Naja, spaetestens, wenn sie ihre Diplomarbeit in Office schreiben wollen und dabei kurz vor der Abgabe auf die Nase fallen lernen die meisten...

An die Studenten hier: Ich kann nur davor warnen die Diplomarbeit in Winword zu schreiben.

Schlechtes Beispiel... Oberes ist gescriptet, bei dir hab ich dann einen Desktop und darf erstmal wieder clicken gehen...

Gerrit

Falls es nicht aufgefallen ist... Moore's Law ist im Bezug auf Takt schon gegen die Wand gelaufen.

Gerrit

Ich kenne das AVR-Studio nicht, läuft ja AFAIK nur unter Windwos, aber der Vorteil von Editor und Makefile ist die höhere Flexibilität. Sie laufen, im Gegensatz zu AVR-Studio, auf fast jeder Plattform, und man braucht nicht zwingend eine grafische Oberfläche, um Code für den AVR schreiben zu können.

Ack, das spricht sicherlich für IDEs. Dagegen spricht, dass sie weniger flexibel sind, was z.B. die Wahl der Programmiersprache betrifft. Und das Schreiben eines Makefiles ist keine Geheimwissenschaft. Wer in der Lage ist, einen µC zu programmieren, schafft das auch. Es ist ja nur einmal nötig, und Makefiles ähneln sich auch stark.

Na gut, wenn man sich mit etwas nicht auskennt, kann man es natürlich nicht vernünftig benutzen. Nur stellt sich mir dann die Frage, ob Makefiles schlecht sind, weil sie schlecht sind, oder weil man sich damit nicht auskennt?

Geht auch, VS bringt dafür commandline-tools mit (frag' nicht welche, müsste ich selber erfragen). Wir haben mittlerweile ein System, das nach jedem svn-checkin automatisch einen build macht, und Mails mit Fehlern und Warnungen zurückschickt. Geht also.

Allerdings. Die Leute tippern bei uns vorwiegend mit MiKTeX und TeXNiCCenter. Graphen mit gnuplot, Grafik meist mit CorelDraw (oder

Davon konnte ich sogar eine Freundin überzeugen, die ihre Geographie- Diplomarbeit mit TeX geschrieben hat. An solchen Lehrstühlen wird man dann aber wirklich erstaunt angeguckt "TeX" hatte dort noch nie jemand gehört.

Thomas Kindler schrieb:

Ich hatte mal das "Vergnügen", ein Programm zu pflegen, das mit VC++ 6 erstellt worden ist. Bis ich da die Linkerparameter gefunden hatte... Desweitern hatte ich die naive Idee, man könnte durch Kopieren des Programmverzeichnis einen "Fork" des Programms ermöglichen indem man das Projekt umbenennt. Letzteres war mir nicht gelungen, WIMRE gab es dabei noch irgendein anderes Problem mit Pfaden.

Ich meinte die nicht-Klartext-Dateien, .dsw und .dsp, WIMRE.

Also _ich_ bin mit Visual Studio _nicht_ intuitiv klargekommen.

Ich kenne 2 Informatiker persönlich, der eine hat einen Mac, der andere ist Windows-Fan. Allerdings hatte mein Grundlagen Informatik-Prof. in der ersten Vorlesungsstunde als erstes einmal gefragt, wer denn ein "vernünftiges" OS (er meinte Linux) nutze. Alle Programmieraufgaben setzten dann auch eine Shell und einen GCC voraus. Den Windowsusern (alle Erstsemester außer mir) empfahl er dann dringend Cygwin.

Ich spreche aber von Numbercrunching mit Matlab. Da kann man bei uns im Institut dann eben per ssh auf 10 anderen Arbeitsplatzrechnern im Hintergrund eine Simulation starten, wenn man die Ergebnisse dringend braucht.

Gruß Henning

Sind sie nicht.

Das kann sein, ist Sache des Anwendungsprogramms. Manche lassen auch einen Speicherort als Eintrag in der Registry angeben (das sollte aber dann als Dialog im Programm möglich sein).

Normalerweise geht das. Es sei denn, im Projekt sind irgendwo absolute Pfade eingetragen, was natürlich nicht notwendig ist (Auch die Dateiauswahldialoge machen von sich aus erstmal relative Pfade).

Stimmt, die Dinger nerven. Bei unserem Projekt haben wir uns allerdings drumrumgeschummelt -- die dsw und dsp-files wurden bei uns automatisch generiert. Alles sehr speziell für unser Projekt, weil wir aus dem Projekt nebenher per gcc-cross-compiler-chain Code für den AIBO generieren.

Bei VS2005 ist es mittlerweile besser, es gibt nur noch Klartext .sln und diverse XML-Dateien, die beim mergen eigentlich keine Probleme machen.

Ok, Geschmackssache. Speziell für die .Net-Sprachen macht der Editor aber Sachen, die vi oder emacs so nicht können kann, da der Editor echtes Wissen über den Programmaufbau hat (im Hintergrund wird kompiliert, damit kann die IDE dann nette Sachen machen).

Jepp, ohne cygwin wäre man manchmal schon ziemlich aufgeschmissen, und einige von uns wären evtl. umgestiegen. ssh, rsync, doxygen, graphviz, etc.. braucht man ja doch mal öfter. Mit cygwin hat man das beste aus beiden Welten, ohne umständlich auf VWware, zwei Rechner oder duell-boot angewiesen zu sein.

"Thomas Kindler" schrieb im Newsbeitrag news:eqspp9$ghg$ snipped-for-privacy@news01.versatel.de...

Danke, das gab's (wenn nicht noch frueher) schon 1977 mit P-Code fuer Pascal der UCSD, auch so ein gescheiterter Hype, (der schon sein eigenes Museum hat:

Egal wie schnell Prozessoren noch werden, richtig verwendet sind sie

Fuer Web-Anweundungen wahrlich egal, fuer wirkliche Anwendungen aber immer ein Argument.

Keine Frage, wuerde man heute ordentlich programmieren, waeren fast alle Programme mindestens 20 mal schneller :-)

Die Profile sind auch nur am Server vorhanden. Die Anwendungen werden zwecks Performance lokal installiert. Das is in den gefragten Office Anwendunge + Medienbearbeitung produktiver, als sie übers Netz laufen zu lassen.

War damals übrigends eine Novell Netware-Umgebung. Ganz schnuckelig :-)

Ja, und? Können halt ein paar Kerne dazu abgestellt werden, den VM-Code nebenher on-demand für die anderen ausführenden Kerne zu kompilieren.

Ja, dolle Wurst :( Deswegen dauert bei mir auf Arbeit das Öffnen eines pdf oder einer .doc auch Ewigkeiten - lokale Festplatten sind einfach schneller, trotz GBit-LAN und schnellem server. Von den armen Schweinen mit den ollen WinXP/256MB RAM-PCs und 100Mbit-NIC gar nicht zu reden, ich bin da mit meiner Kiste schon fast privilegiert :)

Martin Klaiber schrieb:

Semikolon. Bei Office 2003 oder Xp hingegen ein Komma. Typisch Microschrott. Inkompatibel zu allen, eingeschlossen sich selbst.

Guido

Mangels Detailkenntnisse kann ich dazu nichts sagen, ich befürchte allerdings, dass der Aufwand in keinem Verhältnis zum Nutzen stehen wird.

Bei PCs vielleicht schon. Aber was ist mit Controllern, die Daten untereinander austauschen sollen? Wäre kontraproduktiv, wenn ein Großteil der Rechenleistung und des Speichers nur für das Kodieren und Dekodieren eines sehr mächtigen und universellen Datenformats draufginge, obwohl sie nur ein paar spezielle Daten austauschen wollen. Ein Textinterface kann man auch in Assembler schreiben.

Dann stimmt was mit dem Setup nicht. Besonders bei Gbit sollte der Server schneller sein als die lokale Platte.

Gerrit

Gerrit Heitsch schrieb:

Ich mu=DF das leider best=E4tigen.

Guido