Moin leider versagen an der Stelle Langenscheidts, Babbelfishes und was hier sonst noch so an Vokabelheftchen rumfliegt. Obwohl ich 7.5 Achtel der GNU AVR-Libc/ Makes and Haves "durchhabe" gelingts leider immer noch nicht lückenlos einigen mehrfach verwendeten Begriffen die wirkliche Bedeutung zuzuschanzen. Wäre nett die ein oder andere Idee zu erhaschen. Bleibt nur zu fragen: Was sich hinter den Worten: deprecated --> /*missbilligt passt nicht so ganz*/ despite --> /*hier kommt Beleidigung raus - nur: */ /*Wie beleidige ich 'ne Function ?*/ globber /globbering foo im Kontext der Atmel gcc Manuals verstecken soll. Da der Compiler es teilweise auch "ausspricht" möchte ich schon verstehen was genauer damit gemeint ist. Danke & Gruss ALOTOFQ
to deprecate -- in diesem Falle heißt das, daß ein damit bezeichnetes API ausdrücklich nicht mehr zur Benutzung empfohlen wird, es wird gewissermaßen ,,entpfohlen''. :-) Alter Code darf das noch 'ne Weile als Übergangslösung nutzen, aber das Ziel ist, daß irgendeine künftige Version dieses API (oder Feature) nicht mehr besitzen wird. despite -- trotz(dem) globber? -- muß ein Schreibfehler sein. Ich tippe auf clobber -- zerstören außerdem `to glob', `globbing', im Unix-Jargon benutzt für ein pattern matching, typischerweise für Dateinamen (Erweiterung von Sternchen, Fragezeichen und in eckigen Klammern gefaßten Zeichen- gruppen) foo -> siehe das Jargon file z. B. http://pinewo.ods.org/cgi-bin/jarl?query=foo
Aber bitte, Du hast mich bei der Gelegenheit drauf gebracht, daß diese Art der Benutzung von »despite« kein gutes Englisch ist. Ist bislang noch keinem von den Amis aufgefallen :), aber die können sowieso kein gutes Englisch. :-)) Besser wäre hier »in spite of« (was aber laut Webster von »in despite of« herrührt, daher fällt das offenbar sonst keinem auf und hat sich auch in meinen Sprachgebrauch schon eingeschlichen). Wo müssen wir das Bier denn trinken? ;-)
Laut Eric Weddington ist diese Benutzung von despite kein schlechtes Englisch. Er hat mich aber darauf aufmerksam gemacht, daß man nach dem despite einen potentiellen Widerspruch erwarten würde, der hier gar nicht zu erkennen ist. Insofern wird das Ganze jetzt also doch nochmal umformuliert. ;)
deprecated = Abgelehnt despite = Beleidigung to clobber = verprügeln AVR Beschreibung in Englisch = ???! Also wenn man eine Funktion beleidigt wird man vom Compiler abgelehnt und verprügelt. Oder so ... (kopfkratz) SCNR Notker
Hallo Joerg ... dank "MakeFile" voll im Linux versunken fanden wir eben erst wieder Zugang zum Internet und somit kann Deine Frage des "wo trinkens" auch nun erst beantwortet werden. Wir sind hier so um Bremen umzu verteilt, und vielleicht bist Du demnächst grad mal in der Nähe. Die "Jargons" waren völliges Neuland; Darin finden sich viele weitere Erklärungen des LinuxXerlebens. Um gleich noch 'ne Frage anzuhängen .... Absolut unentdeckt bleibt eine Liste der AVR-GCC Optionen; teilweise treffen die DJGPP Optionen zu, nur ist deren Umfang nicht grad übersichtlich. Irgendwie muss doch direkt ein Assembler.asm zu compilieren /linken sein - welches e.g. im AVR_Studio benutzt werden könnte ??? Bisher disassemblierts dort wild drauf los. Wo in dem Zusammenhang auch keiner richtig den Reim drauf geschnitzt bekommt, ist die #include <avr/io.h> _Schreibweise. (Pfadangabe innerhalb der "spitzen Klammern" - Im GNU DJGPP e.g. funktionierts so anscheinend garnicht.) Auch die Einbindung der libc (?? eigentlich wohl per -lc) gelang es noch nicht zu entschlüsseln. Vielen Dank noch mal für den ganzen Aufwand Gruss Carl
Jo, Bremen ist mir gerade bißchen weit weg. ;-) Das Jargon-File ist vielleicht das Beste, was Eric S. Raymond je zusammengeschrieben hat. :-) Die Optionen sind allesamt in der man page erklärt, und wenn mich nicht alles täuscht, sollte eine Version davon auch bei WinAVR mit dabei sein (evtl. als PDF?). Ansonsten, wenn Ihr eh' noch ein Linux an der Hand habt, macht das alles dort, außerdem benutzt das Linux ja selbst den gleichen gcc, also reicht ein »man gcc« aus. Die nicht-so-sehr-Standard Optionen sind auch in der avr-libc Doku erwähnt, aber wie's so ist, wenn man so etwas schreibt und viel zu tief in der Materie drinsteckt: profane Dinge wie -I, -D und -U, die praktisch jeder C-Compiler gleichermaßen versteht, habe ich dort vergessen zu erwähnen. #include <dir/file.h> ist eine völlig gängige Version, die im Unix seit Urzeiten üblich ist (dort kommt C halt her), und die jeder mir bekannte C-Compiler auch auf DOS verstanden hat. Beispielsweise konnte selbst ein uraltes Turbo-C schon <sys/types.h> verstehen. Bei der avr-libc haben wir uns dann entschieden, alle AVR-Spezifika in das Unterverzeichnis avr/ zu schieben, damit dies klar abgegrenzt ist. In der obersten Ebene sind dann nur noch die Header-Files, die entweder im C-Standard definiert sind oder die eine langjährige Tradition haben. Damit sollte z. B. klar sein, daß <avr/signal.h> etwas Grundverschiedenes vom <signal.h> ist, das man typisch bei Unixen für die Behandlung von Signalen finden kann. Da DOS seit Version 2.x und Windows von Anfang an intern auch Vorwärtsstriche als Verzeichnis-Trenner benutzen kann, muß man das dort auch nicht anders schreiben. Die libc (und die libgcc) werden standardmäßig am Ende des Linker- Kommandos angehängt. Starte das Kommando mit -v, dann siehst Du die Kommandozeilen, die der Compiler-Treiber an die einzelnen Unterprozesse gibt.
Das ja ist echter Service !!! ...Tja- das U_nix; wie der Name schon hergibt fehlts daran noch "etwas" am Durchblick. Ein Grund uns vorweg erstmal mit Pascal (da gabs 'nen gutes Buch ...) langsam der hardwarenahen Hochsprachenprogrammierung zu nähern. (Wobei man doch wieder durchs "Fenster" fliegt) Problem sind nicht die Compiler als Solche; vor Jahren begonnene erste "C"ehversuche endeten - in der Zeit grosser DOS auf Win(32) Umstellung- stets im Nirwana. Programmbeispiele, Compiler etc. waren ein kompletter VersionsMischMatsch. Ist schon ätzend - wenn angezeigte Fehler wirklich nicht existierten und man nach Jahren bemerkt mit 'ner 16 Bit Compilerversion rumgehunzt zu haben. Mit Linux gabs das Problem so nicht - dafür andere. E.g. dort notwendiges Verständnis der Unix History. (Linux benutzen wir nur als reine DOS_Erweiterung - ganz in "schwarz" Bash as Ba(t)sh can.) Eben SchlackenWare. Somit koppelt der Atmel_Beginn das "Durchbeissen" durch die GNU Compiler in Etwa bewusst - ein wohl noch Jahre dauernder Weg. Blinken tuts schonmal - da kann der Rest nur reine Formsache sein ... Tausend Dank nochmals Carl
> Das Jargon-File ist vielleicht das Beste, was Eric S. Raymond je zusammengeschrieben hat. :-) Das Jargon File stammt nicht von ESR, er ist lediglich der aktuelle Maintainer. Das Jargon File gab es bereits, als ESR noch in die Hosen geschissen hat ;D Ich bin btw der Coder von jarl, Link steht irgendwo da oben; ich ziehe demnächst in eine andere Wohnung und kann dort nicht mehr rund um die Uhr den Webserver laufen lassen. Da hier so viele UN*X-Köpfe sitzen, dachte ich mir ich frage mal nach, ob mir hier jemand (legal) einen Account auf seinem Webserver geben kann, auf dem ich das CGI-Script (jarl) weiterhin hosten kann. Bin unter broesel@studcs.uni-sb.de oder auf http://pinewo.ods.org/ erreichbar. Gruß Philip
Daß das Jargon-File so viel älter ist, wußte ich auch noch nicht. Wieder was dazugelernt. Der Rest ist bißchen OT hier... Du müßtest schon mal eine Abschätzung haben, wieviel CPU und Traffic das so kostet. Ideal für Dich wäre ein Nachfolgeverein des Individual Network, bei dem Du dann Mitglied würdest, aber mit SaxNet sind wir hier tüchtig weit weg von Dir. Kannst mir mal eine private Mail schreiben, wenn wir das weiter diskutieren wollen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.