[19:59] --> Sie haben den Kanal #forth-ev betreten (-bernd@p5DCD610A.dip0.t-ipconnect.de). [19:59] *** Kanalmodi: [19:59] Hallo! [19:59] Hallo Bernd [20:02] Noch nicht viel los... triefender Patriotismus in der Tagesschau... [20:02] tja. [20:22] http://www.complang.tuwien.ac.at/anton/euroforth/ef12/papers/paysan-recognizers.pdf gibt "access denied" Absicht? ;) [20:24] Bestimmt nicht. [20:29] Mail an Anton geschickt... [20:29] Martin Bitter kämpft noch mit einem Ubuntu-Bug, der seinen Rechner seit neuestem einfrieren lässt. [20:29] Ich blätter nur grade in den Proceedings... [20:30] Wenn das wieder geht, kann er das Editorial schreiben... [20:30] Mach' das, sind interessant. [20:32] http://bernd-paysan.de/recognizers.pdf [20:33] Enthält aber nichts anderes als der VD-Artikel in der 2012/02-VD. [20:33] macht nix ;) [20:33] danke [20:35] --> martin_53 hat den Kanal betreten (-martin@pD9E4645D.dip.t-dialin.net). [20:35] Tagchen [20:35] Hallo Martin! [20:35] Lebt dein Ubuntu-RAID-System wieder? [20:36] Nein. Es ist alles viel schlimmer! [20:36] Den kann ich auch noch beisteuern: http://amforth.sourceforge.net/articles/Recognizer-en.pdf [20:36] Hallo Marin [20:36] oops. T vergessen. [20:37] Kurz: der Kontroller sollte melden, wenn eine der beiden Platten den Geist aufgibt, das hat er nicht gemacht. jetzt sind beide hin. :-( [20:37] Aha. [20:37] Das klingt natürlich nicht toll... [20:38] Raid sind nur redunante Ausfallquellen. [20:38] Sozusagen redundante single point of failures.... [20:38] Und vor allem kein Ersatz für ein Backup. [20:39] Backup hab' ich :-) [20:39] Das klingt gut. [20:39] Kannst du es auch restaurieren? [20:40] Nur - die sicherungsdatei von Evolution (Mailer) ist defekt. Hatte ich ja zuerst aufs Raid geschreiben und dan auf Backup. [20:40] Das Lebenswichtige hat überlebt. Muss es nur mühsam zusammenklauben. Und neue Festplatten kaufen. [20:40] Ja, das klingt nicht so sonderlich schlimm. [20:40] Vier Tage Mail sind ind Nirwana - nicht soo schlimm. [20:41] Ich lass' meine Mails immer auf allen Servern, bis sie dort (bei GMX nach 3 Monaten) hinten 'runterfallen. [20:42] Dann kann hier lokal die Hölle los sein, meine Daten sind trotzdem noch da. [20:42] ein eigener cyrus imap und rsync jede Nacht auf verschiedene Destinationen haben bislang bei mir das schlimmste verhindern können [20:42] Tja, dachte ich hätte ich auch. Aber das ganze ist ja kurz nach einer Neuinstallation passiert. Und da war default eingestellt: Nachrichten auf Server löschen. [20:43] Deshalb die vier Tage. [20:44] Matthias - kannst du mir (PM) sagen wie du rsync eingestellt hast. [20:44] Ihr spracht über Recognizer? [20:45] Matthias hat die EuroForth-Proceedings angeguckt. [20:46] fossil werde ich als nächstes restaurieren. Ordner ist noch da - muss 'nur' fossil installieren. [20:46] Ach, bei fossil musst du dir keine großen Gedanken um die Daten machen, die sind ausreichend gut verteilt ;-) [20:46] Sachichja. [20:47] martin_53: hast Post [20:48] Ich hatte nur vermutet, dass Bernd seine recognizer-Ideen zwar veröffentlicht hat, aber dennoch für sich behalten will. Anton schien dabei aktiv zu unterstützen. ;) [20:49] Du meinst: kryptisch? [20:50] Im Directory Listing war alles fein, aber dann... [20:50] nö: access denied [20:50] Aha. [20:50] Na, ich war im Irrtum und Bernd hat mir freundlicherweise geholfen [20:50] Also, das machen nur Leute, die an Kryptographie arbeiten. [20:50] Sie veröffentlichen ihren Algorithmus, aber das Paper dazu ist total kryptisch. [20:51] Und natürlich kann man im Prinzip auch ihr Programm benutzen, nur die Bedieneroberfläche ist kryptisch. [20:51] Eigentlich wär' das kein Problem, denn der Sourcecode ist mitgeliefert, kann man also ändern. [20:51] Jetzt ratet mal, warum das nicht klappt! [20:52] Nur für DTC Forth geschrieben? [20:53] Man kann in jeder Programmiersprache kryptischen Code schreiben ;-) [20:54] Manche sind aber geeigneter als andere ;) [20:55] Restaurierung meines persönlichen Dokumentenordners läuft (das ist auch die VD drin) 1,3 Gb von 5,6GB noch 12 Minuten. [20:55] Ein ITC Forth ist da nicht so toll. Das kennt jeder von früher. Aber DTC.... [20:56] ITC DTC indirect vs direct threaded code? [20:56] ja [20:56] Irgendwelche merkwürdigen Forth-Erweiterungen sind ideal geeignet. [21:00] Oder das was ich in Wurstkessel mache: Mit Forth C-Code generieren. [21:00] Da kann man dann sicher sein, dass weder Forth- noch C-Programmierer verstehen, was ich da mache. [21:01] Programme, die Programme schreiben, die dann ausgeführt werden sind das einzig wahre [21:02] Genau so mache ich das. [21:02] Ich bin viel zu faul, selber Programme zu schreiben. [21:02] Man ist ja schon nahe dabei, wenn man ein umbecilled? (Nabelschnur)-Forth schreibt. [21:03] Umbilical schreibt sich das. [21:03] Deshalb das Fragezeichen. [21:04] Das ist aber auf andere Weise kryptisch - da hat man zwei Rechner, auf denen ein Programm läuft - der eine Teil hier, der andere da. [21:04] Ich hab lange gegrübelt, was das wohl sein soll. [21:05] Matthias: halt kryptisch :-) [21:06] aber jeder hat so getan als ob er genau wüsste, was das ist. Eine Beschreibung hab ich bis heute nicht gefunden. Inzwischen hab ich mir das aber zusammengereimt [21:06] @Martin: Hast du das Android-Gforth eigentlich schon mal ausprobiert? [21:06] Der Nachteil des nachgeborenen. Meine Forth-Erfahrungen sind halt nicht lückenlos seit 197x ;) [21:07] Nein - ich wußte gar nicht, dass es fertig ist. [21:07] Egmont Woizel hat mal einen sehr guten Vortrag gehalten. [21:08] Naja, was heißt fertig: Es gibt ein Gforth.apk, das ab Android 2.3 funktioniert, außer auf einigen billigen Huawei-Gurken. [21:08] Die billigen Huawei-Gurken werden aber nicht auskommen! [21:09] Und es ist glaub ich zig mal 'neu' erfunden worden. Ich hab' auch mal was geschreiben, was blanks und kommentare rausfilterte. Das machte das laden schneller. [21:09] Im Playstore? DAs apk? [21:09] Nein, im Playstore habe ich es noch nicht eingestellt. [21:10] Aber im Forth-eV-Wiki gibt's einen Link auf ein Gforth.apk. [21:10] NB. Gerade ist fossil update fertig. Die rückseite sieht gut aus. [21:10] Ein Umbilical-Forth hat zwei Wörter definiert: KEY16 und EXECUTE. [21:10] KEY16 liest zwei Bytes von der seriellen und legt sie auf den Stack. [21:10] Dann schick mir mal die Gforth.apk, bitte. [21:10] EXECUTE führt die beiden Wörter aus. [21:11] http://bernd-paysan.de/Gforth.apk [21:11] Nix schicken. [21:11] Auch gut :-) [21:11] http://pygmy.utoh.org/3ins4th.html fand ich sehr informativ dazu [21:12] Nach all' dem Stress (schlaflose Nächte) bin ich jetzt erleichtert, und leg mich mal aufs Ohr. [21:12] CU! [21:12] Er nentn es nur nicht umbilical [21:12] Ciao! Gute Nacht! [21:12] cu [21:12] Es ist auch mehr traditionell, was er da macht. [21:12] <-- martin_53 hat den Kanal verlassen. [21:12] Der b16-Debugger funktioniert auch etwa so. [21:13] Copyright 1991 sagt auch viel [21:13] Das Umbilical hat noch ein "," definiert. [21:13] In der Schleife läuft BEGIN KEY16 EXECUTE AGAIN [21:14] Wenn man etwas compilieren will, schickt man ' KEY16 ' , an das Target. [21:15] Ist die Schnittstelle eigentlich allgemein oder hat jeder seine eigenen bytecodes? [21:15] die über die serielle Leitung gehen [21:15] Jeder hat seine eigenen Bytecodes. [21:16] Ich habe beim B16-Debugger folgendes definiert: [21:16] * i - read status, response is one status byte [21:16] * a - address, followed by two bytes, big endian [21:16] * w - write data, followed by one byte data, addr++ [21:16] * W - write data, followed by two bytes data, addr+=2 [21:16] * r - read data, response is one byte data, addr++ [21:16] * l - transfer low byte, respones is one byte data, addr++ (no read access) [21:17] read und write jeweils aus der Pespektive des Hosts vermuet ich mal [21:17] Ja. [21:17] was ist dann transfer? [21:17] Das ist ein 16-Bit-Prozessor. [21:17] Du liest ein 16-Bit-Wort also mit [21:17] axxrl [21:18] xx sind die beiden Adress-Bytes. [21:18] Dabei wird nur ein echter Schreibzugriff gemacht, nicht zwei. [21:18] Für 8-Bit-Prozessoren ist das l natürlich überflüssig. [21:18] dann macht wohl *w noch eine Null im upper byte? [21:19] Nein, w macht einen Byte-Zugriff, mit der entsprechenden Byte-Access-Maske gesetzt. [21:20] ahh, jetzt hab ich den axxrl Teil verstanden. [21:23] Ich schließe mich dann mal Martin an. [21:23] Ciao! [21:23] Bis neiulich dann [21:23] * BerndPaysan macht das Licht aus