*** Protokolldatei gestartet *** Datum: Mi Jan 21 19:57:03 2009 [Mi Jan 21 2009] [19:57:03] Betreten Sie haben den Kanal #forth-ev betreten (~bernd@ppp-93-104-12-95.dynamic.mnet-online.de). [Mi Jan 21 2009] [19:57:08] Modus Kanalmodi: [Mi Jan 21 2009] [19:58:39] Betreten MatthiasT_ hat den Kanal betreten (~mt@frnk-5f753219.pool.einsundeins.de). [Mi Jan 21 2009] [20:09:49] Betreten erwaelde hat den Kanal betreten (-user@p549E98C5.dip0.t-ipconnect.de). [Mi Jan 21 2009] [20:09:58] n'abbennd! [Mi Jan 21 2009] [20:10:07] servus [Mi Jan 21 2009] [20:11:19] Ich hab gestern dein geflicktes "d-minus" eingebaut. Funktioniert natürlich. Dann hab ich beschlossen, einen "case" testcase zu bauen. [Mi Jan 21 2009] [20:12:13] Mit dem von mir mal ausgegrabenen Flashforth case tut alles außer dem "default" case. Ich muß wohl mal sehen, was da wirklich draus gebaut wird. [Mi Jan 21 2009] [20:12:48] Das case, was in der amforth lib liegt, tat gleich gar nicht. Warum auch immer. :-( [Mi Jan 21 2009] [20:12:55] case hat mir Ulli ausgeredet. Da habe ich rein gar nichts mehr investiert [Mi Jan 21 2009] [20:14:17] Soso. Klar, man kann natürlich alles mit if else if else then then machen, aber es sieht einfach nicht lesbar aus. Erschwerend kommt dazu, daß der forth mode im emacs so'n Konstrukt nicht nach *meinem* Geschmack einrückt ;-> [Mi Jan 21 2009] [20:15:10] Aber das flashforth ding ist nicht so esoterisch aufgeschrieben, das krieg ich vielleicht raus, wo das klemmt. [Mi Jan 21 2009] [20:16:06] Ich habe auch zuviele "case" Implementierungen gefunden, die alle von sich behauptet haben, der Weisheit letzter Schluss zu sein. Die alten Forth Dimensions sind da eine reiche Fundgrube [Mi Jan 21 2009] [20:16:20] Hallo! [Mi Jan 21 2009] [20:16:42] Die Katastrophenshow ist zuende ;=) [Mi Jan 21 2009] [20:16:45] Hi [Mi Jan 21 2009] [20:16:47] Hallo Bernd. [Mi Jan 21 2009] [20:17:12] Nachrichten guck ich schon mehrere Jahre nich mehr, da wird man ja depressiv %-> [Mi Jan 21 2009] [20:17:25] Im Moment sind sie alle total Obama-high ;-) [Mi Jan 21 2009] [20:18:20] Einerseits tut er mir jetzt schon ein bißchen leid, andererseits hat er sich den Job selber ausgesucht. Schaumermal. [Mi Jan 21 2009] [20:18:41] Der hat ein Helfersyndrom, das ist genau der richtige Job für ihn. [Mi Jan 21 2009] [20:20:11] *lol* [Mi Jan 21 2009] [20:20:12] Für CASE: Einfach in die cbr.fs von Gforth schauen (das sind die Kontrollstrukturen für Gforth EC) [Mi Jan 21 2009] [20:20:58] Das sieht ungefähr so aus: [Mi Jan 21 2009] [20:21:06] 0 Constant CASE immediate [Mi Jan 21 2009] [20:21:25] : of 1+ >r ]] over = IF drop [[ r> ; [Mi Jan 21 2009] [20:21:34] : endof >r postpone else r> ; [Mi Jan 21 2009] [20:21:46] : endcase postpone drop 0 ?DO postpone THEN LOOP ; immediate [Mi Jan 21 2009] [20:21:58] OF und ENDOF natürlich auch immediate [Mi Jan 21 2009] [20:22:14] ]] und [[ klammern Sequenzen, die alle gepostponed werden. [Mi Jan 21 2009] [20:22:29] Lustiger Kommentar: \ !! the implementation does not match the stack effect [Mi Jan 21 2009] [20:22:47] Aha. Das geht dann sogar ohne 'ne Variable und nested cases kriegt man auch geschenkt. Hab ich das jetzt richtig gesehen? [Mi Jan 21 2009] [20:22:56] Ja. [Mi Jan 21 2009] [20:23:03] Nur genügend Stack braucht man. [Mi Jan 21 2009] [20:23:09] Ich bin beeindruckt. [Mi Jan 21 2009] [20:23:33] Erich, dann schick mal bitte die getestete Datei ;=)) [Mi Jan 21 2009] [20:24:02] Ich schreib dann rein "von einem Anspruchsvollem Nutzer für Gut befunden" [Mi Jan 21 2009] [20:24:03] Geht das auch in 3 Minuten ;-))) [Mi Jan 21 2009] [20:24:17] Morgen reicht völlig aus ;=) [Mi Jan 21 2009] [20:24:20] Ansonsten gilt natürlich: Wenn möglich, lieber Sprungtabelle bauen. [Mi Jan 21 2009] [20:24:43] "Anspruchsvoller Nutzer", ist ja nett. Im Geschäft gibt's schon noch andere Namen für meinereiner ... [Mi Jan 21 2009] [20:25:41] Gibt sogar eine extra Web-Zeitung: http://www.derquerulant.net/ [Mi Jan 21 2009] [20:25:44] Sprungtabelle ist aber nur cool, wenn die Werte irgendwie halbwegs zusammen liegen, iddrrr? [Mi Jan 21 2009] [20:25:59] Ja. [Mi Jan 21 2009] [20:26:15] wassesallesgibt. [Mi Jan 21 2009] [20:26:17] Ansonsten kann man immer noch einen B-Tree nutzen. [Mi Jan 21 2009] [20:26:42] Oder eine Hash-Tabelle [Mi Jan 21 2009] [20:27:03] Jump Tables brauchen zur Erzeugung viel RAM. Den gibts bei den kleinen Controllern nicht (immer) [Mi Jan 21 2009] [20:27:24] Wenn die Tabelle einigermaßen dicht ist, braucht sie weniger Platz als ein CASE-Statement. [Mi Jan 21 2009] [20:27:52] Flash haben wir genug, am RAM haperts [Mi Jan 21 2009] [20:27:59] Wieso RAM? [Mi Jan 21 2009] [20:28:10] Die Werte in der Tabelle sind doch konstant. [Mi Jan 21 2009] [20:28:49] Wenn man keinen Instruction-Memory-Fetch hat, legt man Sprünge in die Tabelle. [Mi Jan 21 2009] [20:31:20] Naja, beeindruckt hat mich an der case Geschichte eigentlich nur, daß ich halt "geglaubt" habe, das fliegt, bis ich systematisch geguckt hab. Im Geschäft bin ich auch gerade am Testen von [Mi Jan 21 2009] [20:31:52] ner neuen Sache. Aber das macht kein' Spaß, weil egal wohin man sieht, tut's nur geradeaus so wie [Mi Jan 21 2009] [20:32:19] 's soll. Wehe man gibt irgendwas in anderer Reihenfolge ein ... *ächz*** [Mi Jan 21 2009] [20:32:21] Gibt es eigentlich eine Hash-Implementierung in Forth? [Mi Jan 21 2009] [20:32:34] Alle möglichen. [Mi Jan 21 2009] [20:32:43] Die Frage beim Hash ist immer, was will man hashen? [Mi Jan 21 2009] [20:32:44] Also eine, die ohne grossen Aufwand nutzbar wäre? [Mi Jan 21 2009] [20:32:56] In meinem Fall Cells [Mi Jan 21 2009] [20:33:02] Wenn du Zahlen hashen willst, einfach mit einer passenden Primzahl multiplizieren. [Mi Jan 21 2009] [20:33:06] (XT um genau zu sein) [Mi Jan 21 2009] [20:33:56] Im Kern denke ich an einen simplen Profiler, der mitzählt wie oft ein Wort aufgerufen wurde [Mi Jan 21 2009] [20:34:19] Da würde ich aber einfach für jedes Wort eine RAM-Zelle reservieren [Mi Jan 21 2009] [20:34:22] Direkt im Dictionary kann ich das nicht mitzählen, da braucht man für jeden Profilerllauf einen Controller [Mi Jan 21 2009] [20:34:38] Andererseits habe ich nicht soviel RAM [Mi Jan 21 2009] [20:34:45] und in das Wort vorne rein (ram) compilieren [Mi Jan 21 2009] [20:34:48] Das ich das einfach 1:1 abbilde [Mi Jan 21 2009] [20:35:04] Aha, d.h. es soll so eine Art Schätzwert 'rauskommen. [Mi Jan 21 2009] [20:35:28] Die Wörter DUP, COLD und WRZLPRMPFT sind 51 mal aufgerufen worden. [Mi Jan 21 2009] [20:35:35] Mein bisheriger Worst-Case ist einfach eine Routine, die linear in einer Liste sucht. [Mi Jan 21 2009] [20:35:42] Da ist dann klar, es war einmal COLD, 50 mal DUP, und WRZLPRMPFT gar nicht ;-) [Mi Jan 21 2009] [20:35:53] Wobei die Liste einfach ein paar XT:Counter darstellt [Mi Jan 21 2009] [20:36:16] (ich hätte paar gross schreiben sollen) [Mi Jan 21 2009] [20:37:08] Also werden nur ein paar Wörter geprofiled, und der Rest nicht, oder? [Mi Jan 21 2009] [20:37:56] Da würde ich dann aber wirklich ein extra-Wort definieren, etwa so: [Mi Jan 21 2009] [20:38:01] Gute Frage, nächste Frage. eigentlich sollten alle Worte gezählt werden. Performance wird so etwa in den Keller gehen, aber das ist nunmal der Preis [Mi Jan 21 2009] [20:38:53] : r> 1 over @ +! cell+ >r ; [Mi Jan 21 2009] [20:39:12] : ~p~ ram here 0 , rom postpone , ; immediate [Mi Jan 21 2009] [20:39:30] Wenn man alle Wörter zählen will, braucht man für jedes Wort einen Zähler. [Mi Jan 21 2009] [20:39:32] In den Flash kann ich nicht schreiben, ausserdem habe ich Havard-Architektur [Mi Jan 21 2009] [20:39:54] d.h. r> und +! arbeiten in verschiedenen Universen [Mi Jan 21 2009] [20:40:09] Aber die Idee ist angekommen. Danke [Mi Jan 21 2009] [20:40:16] Ja, macht ja nichts, da muss man halt dann I@ +! machen (oder wie auch immer das Fetch im I-Space heißt). [Mi Jan 21 2009] [20:41:07] Wenn du das mit einem Hash machen willst, also z.B. so: [Mi Jan 21 2009] [20:41:09] Man kann beim Anlegen des Wortes eine Zelle im RAM reservieren, die dann beim Aufruf des betreffenden Wortes incrementiert wird. Das macht dann der inner interpreter... [Mi Jan 21 2009] [20:41:22] da brauche ich keinen Hash mehr. Cool.# [Mi Jan 21 2009] [20:41:29] : r@ 37 * 31 and cells count-table + +! ; [Mi Jan 21 2009] [20:41:36] Nur einen profiler-build des Systems. [Mi Jan 21 2009] [20:41:50] Genau. [Mi Jan 21 2009] [20:42:12] Wenn du nicht genügend Platz hast im RAM, dann musst du meinen Hash-Vorschlag mit mehreren verschiedenen Primzahlen nacheinander übersezten [Mi Jan 21 2009] [20:42:20] Ha, da hat sich der Chat doch schon gelohnt :=) [Mi Jan 21 2009] [20:42:33] und dann aus den jeweils unterschiedlichen Ergebnissen raten, ob sich da eine Lösung ergibt ;-) [Mi Jan 21 2009] [20:43:22] RAM ist relativ. Die meisten meiner Boards haben keinen externen RAM, außer ein System. Das hat 2 Bänke mit dem vollen 16-Bit Adressbereich. Da kann man schon ein wenig zaubern und die Anzahl der Aufrufe ist unabhängig vom Controllertyp [Mi Jan 21 2009] [20:43:47] Ok, Erich wird fluchen, aber ich kann damit gut leben ;=) [Mi Jan 21 2009] [20:44:36] ¿Qué? Wenn ich dann an dem Bahnhof mal ankomme, vielleicht ... [Mi Jan 21 2009] [20:44:50] Ok, ich versuchs mal [Mi Jan 21 2009] [20:45:14] mir schwebt ein System vor, in dem man mitzählen kann, wie oft ein bestimmtes Wort aufgerufen wird. [Mi Jan 21 2009] [20:46:00] Das würde man klassischerweise vermutlich mit einem Counter bei jedem Dictionary-Eintrag und einem passenden inner interpreter lösen [Mi Jan 21 2009] [20:46:20] geht bei amforth nicht. Der Flash wäre in null-komma-nichts kaputt [Mi Jan 21 2009] [20:46:54] Also muss der Counter verlagert werden und es braucht eine passende Umsetzung XT -> Counteradresse, die nicht allzuviel Ressourcen schluckt [Mi Jan 21 2009] [20:47:05] Jezzet. Deswegen RAM. [Mi Jan 21 2009] [20:47:08] Erste Idee war ein Hash [Mi Jan 21 2009] [20:47:23] (ich mag halt perl, das ist manchmal schlecht) [Mi Jan 21 2009] [20:47:27] Und aktuelle Idee ist eine Indirektion. [Mi Jan 21 2009] [20:48:04] Aber der "anspruchsvolle Nutzer" kann sich ja hoffentlich aussuchen, ob er/sie ein zählendes system haben will. Oddrrr? [Mi Jan 21 2009] [20:48:33] Und außerdem hab ich atmega644P's bestellt ;-) [Mi Jan 21 2009] [20:49:04] Neueste Idee ist ein zählendes System, das zwar langsamer läuft, aber dafür mehr Infos rausrückt [Mi Jan 21 2009] [20:49:41] Wobei die Counter in einem Speicherbereich liegen, der vom normalen Programm gar nicht erriecht wird (back switching zwischen zwei [Mi Jan 21 2009] [20:49:48] 64 KB Bänken) [Mi Jan 21 2009] [20:50:32] Boah ey. [Mi Jan 21 2009] [20:50:48] www.alvidi.de [Mi Jan 21 2009] [20:50:51] Kann ich noch'n anderes Thema anschneiden, pleez? [Mi Jan 21 2009] [20:50:58] jetzt ja [Mi Jan 21 2009] [20:51:02] Je nachdem wie viel Info man haben will, kann man Profiling bei jedem Control flow change machen. [Mi Jan 21 2009] [20:52:03] Ich hatte Dir doch gemailt, daß die Jungs von etherrape mich gefragt hatten, ob man deren C mit Deinem amforth verheiraten kann. Ich hab nur verstanden, daß das schwierig ist. [Mi Jan 21 2009] [20:52:28] jupp [Mi Jan 21 2009] [20:53:11] Ich denk mir so in meiner kleinen Welt, daß da die fixe Registerbelegung bei forths mitspielt. Aber zum Thema andersrum "amforth ruft deren C-Funktionen auf", was ist da der Haken? [Mi Jan 21 2009] [20:53:37] Sollte eigentlich nicht wirklich ein großes Problem sein. [Mi Jan 21 2009] [20:54:30] erstes Problem: Wie kommt der C Quellcode auf den Controller [Mi Jan 21 2009] [20:54:45] Den compiliert man und extrahiert ihn mit objdump [Mi Jan 21 2009] [20:55:02] Als assembler mitzuverlinken, hab ich mir so vorgestellt --- kleine Welt Syndrom? [Mi Jan 21 2009] [20:55:04] zweites Problem: der C Quellcode (oder dessen assemblierter Teil) braucht eine gewisse Laufzeitumgebung [Mi Jan 21 2009] [20:55:19] Die ist ja dabei, in der avr-libc. [Mi Jan 21 2009] [20:55:30] Das wird ja alles beim Compilieren schon passend zusammengelinkt. [Mi Jan 21 2009] [20:55:55] die libc ist das dritte Problem. Die gibts nicht bei amforth. Ist ein Teil der Laufzeitumgebung [Mi Jan 21 2009] [20:56:16] C wird auf dem PC compiliert, amforth läuft auf dem Controller [Mi Jan 21 2009] [20:56:34] Ja klar, aber letztendlich wird ein amforth ja auch auf dem PC assembliert. [Mi Jan 21 2009] [20:56:51] Also, ich kann's zwar nicht auswendig, aber ich denk mir [Mi Jan 21 2009] [20:57:01] a. C code in assembler übersetzen [Mi Jan 21 2009] [20:57:02] Lasst hören. Ich bin gespannt. [Mi Jan 21 2009] [20:57:16] b. den amforth assembler Teil dazu [Mi Jan 21 2009] [20:57:53] das alles dem assembler verfüttern --- die Frage ist: kann der das *richtig* zusammenbauen? Bernd kann das. [Mi Jan 21 2009] [20:58:21] c. das resultat in Maschinencode und ab auf den controller [Mi Jan 21 2009] [20:58:39] d. dann muß zwar der amforth code noch hinterher ... [Mi Jan 21 2009] [20:59:20] Für mich sieht's dann aus wie: ich lade ein mit C-Funktionen aufgepepptes amforth und kann die C-Funktionen aus amforth aufrufen. Aber wie gesagt --- meine kleine Welt. [Mi Jan 21 2009] [21:00:16] Nachteil der ganzen Sache ist immer: Man muss sich mit nicht richtig zusammenpassenden Sachen 'rumquählen [Mi Jan 21 2009] [21:00:19] Ich habe da Zweifel. Grosse sogar. [Mi Jan 21 2009] [21:00:44] Wenn in dem etherrape-Teil etwas nicht stimmt, ist das Ändern nicht so leicht. [Mi Jan 21 2009] [21:00:48] Jo, das habe ich schon beforchten. Aber sexy wärs. [Mi Jan 21 2009] [21:01:13] Eine Alternative wär natürlich, deren coole Funktionen nach amforth zu portieren. [Mi Jan 21 2009] [21:01:28] Ideal wäre ein c2forth, was den ganzen C Krempel übersetzen kann [Mi Jan 21 2009] [21:02:18] Und ich finde, die haben schon sexy Sachen: eine Art abgespecktes tcp/ip Protokoll, welches über rs485 (z-bus) oder rfm12 Netze laufen soll. zum Beispiel. [Mi Jan 21 2009] [21:03:13] ein TCP/IP für amforth wäre schon schön [Mi Jan 21 2009] [21:03:25] RFM12 stelle ich mir weniger kritisch vor. [Mi Jan 21 2009] [21:03:43] (Bernd: Das sind 433 MHz Module) [Mi Jan 21 2009] [21:04:21] Ich selber kann sowas nicht produzieren --- jedenfalls nicht in der Zeit, die ich habe. Aber was sag ich denen ... "s duud nedd" ist ja ein wenig einfallslos. [Mi Jan 21 2009] [21:04:49] Ja, aber das, was man bei RFM12 bekommt, ist einfach rohe Datenblöcke senden/emfpangen. [Mi Jan 21 2009] [21:05:00] Den Rest muss man da auch in Software machen. [Mi Jan 21 2009] [21:05:12] Angefangen mit der Fehlerkorrektur. [Mi Jan 21 2009] [21:05:58] Darum gehts ja grade, das den Programmcode schon jemand geschrieben hat. Nur in der falschen Sprache ;=) [Mi Jan 21 2009] [21:06:06] Das ist korrekt. Ich hab's bei mir noch nicht am Fliegen. Aber man kann damit halt seine Sensoren quasi direkt vom Rechner aus ansprechen. Ich hab keine Ahnung ob das robust ist, aber deswegen quatscht man ja. [Mi Jan 21 2009] [21:07:47] www.lochraster.org/etherrape http://wiki.lochraster.org/wiki/Etherrape www.ethersex.de (firmware) [Mi Jan 21 2009] [21:08:46] Wenn ich die Featureliste durchlese, dann klingt mir das nach völligem Overengineering. [Mi Jan 21 2009] [21:08:50] IMHO kommt man nich drum herum, den ganzen C code in Forth nachzuprogrammieren. Was es gibt, dient als Inspiration aber das wars schon [Mi Jan 21 2009] [21:09:36] Jo, die featureliste ist fett. Aber fast alles ist optional und kann auch in der firmware dekonfiguriert werden. [Mi Jan 21 2009] [21:10:45] Also, bei Sensoren über RFM12 oder z-bus ansprechen, würde ich mich eher von Heinz Schnitter inspirieren lassen. [Mi Jan 21 2009] [21:10:54] Mal sehen, vielleicht krieg ich die Beschreibung von dem Protokoll mal aus dem Code seziert. Womöglich isses nicht mal sooooo schwierig. [Mi Jan 21 2009] [21:11:53] Kommt Heinz zufällig nach Rheine? [Mi Jan 21 2009] [21:12:06] Mit sehr hoher Wahrscheinlichkeit. [Mi Jan 21 2009] [21:12:23] Aber ONF ist sowieso sehr einfach erklärt: Die Kommunikation besteht im Wesentlichen aus Forth-Quelltext. [Mi Jan 21 2009] [21:12:27] Angemeldet hab ich mich noch nicht, aber ich hab's vor. [Mi Jan 21 2009] [21:12:47] Das Packet braucht also Quelle/Ziel im Header, Forth-Quelltext und Checksumme. [Mi Jan 21 2009] [21:13:14] Oder bei RFM12 irgendeinen ECC-Code, damit man auch den einen oder anderen Bitfehler ausbügeln kann. [Mi Jan 21 2009] [21:14:10] Das Ziel schickt bei Erfolg der Aktion "ok" zurück, und bei Misserfolg "ko", und versucht sich dann auch auf den Zustand vor Empfang des Packets zurückzusetzen. [Mi Jan 21 2009] [21:15:49] Das müsste sich eigentlich ziemlich schnell in Forth implementieren lassen, ohne in irgendwelche C-Quellen zu gucken. [Mi Jan 21 2009] [21:16:25] Ist das irgendwo beschrieben, alte 4D oder so? [Mi Jan 21 2009] [21:16:36] Glaube schon. [Mi Jan 21 2009] [21:17:43] Matthias: Du hast doch ein pollin netgw board, oder wie das heißt. Das hat doch auch einen ethernet controller dran oddrrr? [Mi Jan 21 2009] [21:18:00] ja, ich habe auch rfm12 module [Mi Jan 21 2009] [21:18:33] Hast Du vor, mit dem ethernet Dings reden zu wollen? also abgespecktes tcp/ip? [Mi Jan 21 2009] [21:18:44] ja [Mi Jan 21 2009] [21:18:58] nur ohne abgespeckt ;=) [Mi Jan 21 2009] [21:19:17] Aha, dann wärs tatsächlich gescheiter alles in amforth zu bauen. [Mi Jan 21 2009] [21:19:29] Wie ohne? Ich würde direkt Ethernet-RAW-Sockets aufmachen, und ohne drüberliegendes Protokoll reden. [Mi Jan 21 2009] [21:20:08] ich will tcp (telnet zumindest) [Mi Jan 21 2009] [21:20:29] ethernet alleune ust für mich nutzlos [Mi Jan 21 2009] [21:20:47] Brauchst du die Routing-Funktionalität? [Mi Jan 21 2009] [21:21:01] nein, lan reicht aus. [Mi Jan 21 2009] [21:21:08] Eben, dann reicht Ethernet roh. [Mi Jan 21 2009] [21:21:10] Dann wird dsa quasi so ein "multi-protokoll" board, welches die Kontrollers an ein ethernet verbindet. [Mi Jan 21 2009] [21:21:36] nicht unbedibgt, aber wenn machbar auch das [Mi Jan 21 2009] [21:22:02] Ziemlich cool. Riecht aber nach ordentlich Arbeit. [Mi Jan 21 2009] [21:22:14] ich denke, jahresende [Mi Jan 21 2009] [21:23:08] oder später ... [Mi Jan 21 2009] [21:23:50] Also, d.h. ich sage den etherrape Buben: amforth als Skriptsprache in ihre etherrape firmware einzubauen, als Skriptsprache ist schwierig. Umgekehrt aus amforth raus deren Sachen aufrufen ist zwar eher machbar, wird ihnen aber sowieso nicht gefallen. [Mi Jan 21 2009] [21:24:08] Und für amforth benutzen wir die Inspiration und die Kraft der Quellen. [Mi Jan 21 2009] [21:24:52] es sei denn, jemand baut einen genialen c2forth Transpiler [Mi Jan 21 2009] [21:25:06] Ja, dafür braucht man aber ein ziemlich komplexes Forth [Mi Jan 21 2009] [21:25:11] Mit CASE, Locals und so weiter. [Mi Jan 21 2009] [21:25:14] ;-) [Mi Jan 21 2009] [21:25:15] Betonung auf "genial", gell? [Mi Jan 21 2009] [21:25:21] ja [Mi Jan 21 2009] [21:25:44] einen "einfachen" gibts von mpe ltd [Mi Jan 21 2009] [21:26:23] Aber der generierte Code ist nicht wirklich lesbar [Mi Jan 21 2009] [21:26:46] Bernd: bist Du eigentlich mit dem LegoNXT irgendwie zugange? [Mi Jan 21 2009] [21:27:02] Ich bin vor lauter anderen Sachen nicht zum NXT gekommen. [Mi Jan 21 2009] [21:27:58] Dacht ich mir schon. Ich wär im Moment gewillt, meinen Wetterkruscht auf den Linuxtag zu schleifen, da blinkt's immerhin, und die Kurven sind auch ganz nett. [Mi Jan 21 2009] [21:28:24] Ich muss da mal gucken, ob die C-Libraries, die ich verwende, inzwischen etwas ausgereifter sind, und auch funktionieren. [Mi Jan 21 2009] [21:28:31] Aber viel wird da nicht dazu kommen, schätze ich mal. Einen Windsensor hab ich noch angefangen. Zählen tut's schon mal. [Mi Jan 21 2009] [21:29:26] Allerdings ist für den Linuxtag noch nixx angeleiert --- mann kanns also noch aussitzen ;-) [Mi Jan 21 2009] [21:30:08] Ja, müssen wir aber relativ bald machen, und uns schon vor der Tagung anmelden. [Mi Jan 21 2009] [21:31:23] Jo. Carsten hat sich zu dem Thema bislang ausgeschwiegen, und das Direktorium auch. Ich kann unmöglich die ganze Zeit am Stand sein, weil schließlich mein Scheff die Reise bewilligt hat. Da muß schon noch Vortragsprogramm für mich abfallen. [Mi Jan 21 2009] [21:33:01] Na gut. So langsam Zeit für die Heia. Macht's gut! [Mi Jan 21 2009] [21:33:07] Einen CFP vom Linuxtag hat er schon mal 'rumgeschickt, ich hab's geforwwarded [Mi Jan 21 2009] [21:33:12] Gute Nacht. [Mi Jan 21 2009] [21:33:14] adeke [Mi Jan 21 2009] [21:33:19] Beenden MatthiasT_ hat den Server verlassen (EOF From client). [Mi Jan 21 2009] [21:33:30] gut Nacht! [Mi Jan 21 2009] [21:34:06] Verlassen erwaelde hat den Kanal verlassen (quit.).