*** Protokolldatei gestartet *** Datum: Do. Jan 9 20:01:37 2014 [Donnerstag, 9. Januar 2014] [20:01:37] Betreten Sie (-bernd@p5DCD70AD.dip0.t-ipconnect.de) haben den Kanal #forth-ev betreten. [Donnerstag, 9. Januar 2014] [20:01:42] Modus Kanalmodi: [Donnerstag, 9. Januar 2014] [20:01:45] Hallo! [Donnerstag, 9. Januar 2014] [20:01:54] Halo Meister! [Donnerstag, 9. Januar 2014] [20:02:18] Erich hat sich bei mir entschuldigt, er hat Linux-Stammtisch ;) [Donnerstag, 9. Januar 2014] [20:02:24] Aha [Donnerstag, 9. Januar 2014] [20:02:38] Na, mal sehen, ob noch wer kommt. [Donnerstag, 9. Januar 2014] [20:02:45] jo [Donnerstag, 9. Januar 2014] [20:03:13] Wie löst du eigentlich das CREATE-DOES>-im-Flash-Problem? [Donnerstag, 9. Januar 2014] [20:03:32] XT überschreiben. [Donnerstag, 9. Januar 2014] [20:03:56] Im Flash kannst du ja nur einmal schreiben. [Donnerstag, 9. Januar 2014] [20:03:58] Atmega's Flash ist da ziemlich kooperativ [Donnerstag, 9. Januar 2014] [20:04:54] Ist dein Default-Create-Xt dann einer mit lauter FFs? [Donnerstag, 9. Januar 2014] [20:04:56] Ja und? Seitenweise kann ich den löschen und dann wird die eine betreffende Zelle mit dem neuen Wert bestückt. Vorher wird nur geprüft, ob es nicht auch ohne page erase geht [Donnerstag, 9. Januar 2014] [20:05:07] Ok. [Donnerstag, 9. Januar 2014] [20:05:16] Nein ;) Der Flash wird schon ordentlich getresst [Donnerstag, 9. Januar 2014] [20:05:33] Ich überlege aber, das XT schreiben etwas zu delayen [Donnerstag, 9. Januar 2014] [20:05:59] Das macht noForth - Delay bis das Wort gefunden wird oder ein neues Wort definiert wird. [Donnerstag, 9. Januar 2014] [20:07:01] Gforth EC auf R8C setzt dovar (also den Doer für Create) so, dass da sehr viele 1er sind, und der dodoes-Doer dann nur durch Löschen einzelner Bits erzeugt werden kann. [Donnerstag, 9. Januar 2014] [20:07:03] Ich bin mit dem amforth nicht sonderlich schonend, was Flash oder EEPROM angeht. Bei 3 EUR pro Chip halte ich das für unnötig. Development Boards müssen mit Hardwareschaden rechnen [Donnerstag, 9. Januar 2014] [20:07:43] Ja, das ist ein akzeptabler Tradeoff. [Donnerstag, 9. Januar 2014] [20:07:46] Wobei ich immer auf dem ersten Chip herumspiele. So dramatisch ist das gar nicht, wie man es aus den Meinungen der Leute heraushören kann [Donnerstag, 9. Januar 2014] [20:08:33] Zunächst geht bei Flash die Data Retention 'runter. Das stört dich insbesondere bei einem Development-Chip nicht, der wird eh täglich neu geflasht. [Donnerstag, 9. Januar 2014] [20:08:46] Klar kann ich den Flash in Sekunden totflashen, wenn ich das denn wollte [Donnerstag, 9. Januar 2014] [20:11:11] Wenn ich fertigen Code irgendwo ausrolle, wird der Flash sehr überschaubar belastet. Da wird es auch nur aller Jubeljahre Updates geben. Bei 10,000 Erasezyklen (Garantiert) lebt der verbaute Chip sehr lange. Mal abgehen davon, dass da sicher ein komplettes Hexfile vom Develsystem abziehe und das komplett neu flasche... [Donnerstag, 9. Januar 2014] [20:14:49] Wenn du eine Flash-Page löscht, speicherst du dann die zu erhaltenden Daten in einer anderen, noch unbenutzten Flash-Page? [Donnerstag, 9. Januar 2014] [20:17:34] Nicht ganz. Der Atmega hat einen Pagecache, den ich neu aufbaue. Dieser Cache überlebt den Erase und kann dann am Stück zurückgeschrieben werden. [Donnerstag, 9. Januar 2014] [20:17:50] Aha. Ja, das ist natürlich geschickt. [Donnerstag, 9. Januar 2014] [20:18:16] Der ist zwar kein RAM (jede Adresse kann nur einmal geschrieben werden), aber sonst nicht weiter beschränkt, was die Zyklen angeht. [Donnerstag, 9. Januar 2014] [20:20:02] Ich nehme an, dass die das innen in ihrem Flash-Block schon als RAM implementiert haben. [Donnerstag, 9. Januar 2014] [20:20:11] Nur halt nicht als General-Purpose-RAM. [Donnerstag, 9. Januar 2014] [20:21:34] Vielleicht. Witzig ist das Write-Once Feature. Deswgen muss ich das zu ändernde Datum als erstes in den Cache schreiben und dann den Rest von der Flashpage einfach drüberbügeln. [Donnerstag, 9. Januar 2014] [20:22:00] Ja, das ist witzig. [Donnerstag, 9. Januar 2014] [20:22:27] Ich hatte bei dem Elotouch-Projekt einen Flash mit 16-Bit-Zugriffen. [Donnerstag, 9. Januar 2014] [20:22:35] Der 8051 hat natürlich byteweise 'reinschreiben wollen. [Donnerstag, 9. Januar 2014] [20:22:53] Also gab's da einen Write-Cache für Zugriffe von geraden Adressen. [Donnerstag, 9. Januar 2014] [20:23:12] Die darauffolgende ungerade Adresse hat dann den eigentichen Schreibzugriff ausgelöst. [Donnerstag, 9. Januar 2014] [20:23:50] Weil ich "keep it simple" mache, konnte man natürlich diese gerade Adresse so oft beschreiben, wie man wollte, und es war auch irrelevant, welche Adresse man dafür genommen hat. [Donnerstag, 9. Januar 2014] [20:24:58] Und natürlich gab's auch prompt Probleme, weil der Keil-Compiler Intel-Hex ausgespuckt hat, das die letzte ungerade Adresse weglies ;-) [Donnerstag, 9. Januar 2014] [20:25:15] Der Atmegaflash ist auch 16bit pro AdressUnit. Byteweiser Zugriff nicht ausgeschlossen. Das ist etwas skurril. Ich hab das als Forth-Cell einfach übernommen. Macht den CELL+ etwas sinnfrei. Beim RAM ist der 2+, beim Dictionary ist das 1+ [Donnerstag, 9. Januar 2014] [20:26:21] Ja, Forth geht nicht von so uneinheitlichen Memory-Modellen aus. [Donnerstag, 9. Januar 2014] [20:27:17] Dafür ist amforth aber ganz schon dicht an den Forth-Standard herangekommen. [Donnerstag, 9. Januar 2014] [20:27:35] 100% geht aber nicht. Hab ich vor Jahren mal mit Ulli diskutiert [Donnerstag, 9. Januar 2014] [20:28:29] Ja, ich möchte zur Zeit wissen, woran's klemmt, weil man diese Probleme evtl. beseitigen kann. [Donnerstag, 9. Januar 2014] [20:30:18] Hab ich meine Zweifel. [Donnerstag, 9. Januar 2014] [20:30:55] Eigentlich müsste man Dictionary und Datenbereich sauber trennen [Donnerstag, 9. Januar 2014] [20:31:35] Das sollte gehen. [Donnerstag, 9. Januar 2014] [20:31:38] Der Speicher einer Variablen sollte nicht im Dictionary sein, z.B. [Donnerstag, 9. Januar 2014] [20:32:17] Klar. [Donnerstag, 9. Januar 2014] [20:32:34] Das macht wegen Cache-Konflikten auch auf dem Desktop Sinn. [Donnerstag, 9. Januar 2014] [20:32:53] Also, zumindest bei Native-Code-Systemen, bei denen das Dictionary überwiegend Code enthält. [Donnerstag, 9. Januar 2014] [20:33:02] bei gforth brauch ich nur ein ' name cell+ machen und schon hab ich den Speicher. Selbst bei einem Value klappt das. [Donnerstag, 9. Januar 2014] [20:34:10] Ja, bei Gforth ist der Code ja auch woanders. [Donnerstag, 9. Januar 2014] [20:34:13] Das ist ja auch ok, solange man Dictionary im RAM hat [Donnerstag, 9. Januar 2014] [20:34:34] Beispiel VFX-Forth: [Donnerstag, 9. Januar 2014] [20:34:37] variable foo ok [Donnerstag, 9. Januar 2014] [20:34:37] foo . ' foo . 134882368 135000859 ok [Donnerstag, 9. Januar 2014] [20:34:48] Da ist ganz schön was zwischen foo und ' foo. [Donnerstag, 9. Januar 2014] [20:35:44] Ist aber immer noch der gleiche Speicher. IIRC hat ERather mal was geschrieben, dass @/! nicht auf den Speicher des Dictionary kommen sollen. Zumindest soll man das nicht erwarten. [Donnerstag, 9. Januar 2014] [20:36:19] Ja, der Code kann eben tatsächlich ganz woanders sein. [Donnerstag, 9. Januar 2014] [20:36:29] Also, ein xt muss keine Daten-Adresse sein. [Donnerstag, 9. Januar 2014] [20:36:41] Das ist jetzt schon standard-konform. [Donnerstag, 9. Januar 2014] [20:36:53] Wenn ich aber die ganzen CREATE 100 ALLOT Sequenzen sehe, die dann ganze Tabellen ablegen, auf die dann mit @ zugriffen wird.... [Donnerstag, 9. Januar 2014] [20:37:14] 100 ALLOT alloziert aber nicht Code-Dictionary, sondern Daten-Space. [Donnerstag, 9. Januar 2014] [20:37:29] Sicher, aber woher weiss der Create das? [Donnerstag, 9. Januar 2014] [20:38:13] Create muss - im Normalfall jedenfalls - auf den nächsten freien Datenspeicher zeigen. [Donnerstag, 9. Januar 2014] [20:38:21] Mit ALLOT kannst du dann mehr holen. [Donnerstag, 9. Januar 2014] [20:38:27] Die Tabelle wird übrigens mit , gefüllt. [Donnerstag, 9. Januar 2014] [20:38:30] Und , legt auch die Werte im Datenspeicher an. [Donnerstag, 9. Januar 2014] [20:39:05] Das sollte man im Standard mal sehr viel deutlicher darlegen. [Donnerstag, 9. Januar 2014] [20:39:13] Ja. [Donnerstag, 9. Januar 2014] [20:40:10] Dann haben solche Extrempunkte wie die Atmegas vielleicht eine Chance, das korrekt abzubilden. Ich denke aber, das da viel Code geändert werden muss [Donnerstag, 9. Januar 2014] [20:40:35] Du müsstest immer noch alle Strings und so im Daten-Space anlegen. [Donnerstag, 9. Januar 2014] [20:40:47] Da es beim ATmega kein Daten-Flash gibt, bleibt da nur das knappe RAM. [Donnerstag, 9. Januar 2014] [20:41:06] Lösbar. Ich kanns zur Laufzeit in einen Buffer kopieren und den übergeben. [Donnerstag, 9. Januar 2014] [20:41:07] Oder Adress-Mapping in @. [Donnerstag, 9. Januar 2014] [20:41:43] Für das interpretative s" gibt es ja so einen Puffer. [Donnerstag, 9. Januar 2014] [20:42:06] Für das compilierte nicht, da kannst du davon ausgehen, dass alle s" gleichzeitig erreichbar sind. [Donnerstag, 9. Januar 2014] [20:42:44] Für die meisten Fälle dürfte die Puffer-Lösung aber funktionieren. [Donnerstag, 9. Januar 2014] [20:43:12] Es muss ja nicht nur einen Puffer geben. RAM ist zwar knapp, aber irgendwie sollte das machbar sein. [Donnerstag, 9. Januar 2014] [20:46:01] von-Neumann-Architekturen sind da halt schon Forth-freundlicher. [Donnerstag, 9. Januar 2014] [20:46:43] Die anderen machen aber mehr Spaß ;) [Donnerstag, 9. Januar 2014] [20:48:48] Weiß nicht, ich habe als Reaktion auf das 8051-Projekt ja den b16 entwickelt - macht mehr Spaß ;-). Dabei habe ich bei dem 8051 sogar das Flash sowohl in den Code- als auch Datenspeicher gemappt (und auch das RAM). [Donnerstag, 9. Januar 2014] [20:49:09] Code im RAM ausführen beim 8051 war auch was, was unsere Kunden für "völlig unmöglich" hielten ;-) [Donnerstag, 9. Januar 2014] [20:50:17] Maschinencode muss beim Atmega auch im Flash sein. Der innere Forth-VM Interpreter könnte da großzügiger sein. ITC sei dank... [Donnerstag, 9. Januar 2014] [20:50:42] Native Compiler wären da beschränkter [Donnerstag, 9. Januar 2014] [20:55:28] Die Speichermodelle sind aber ohnehin vielfältig: NUMA bei großen Systemen, oder der Core-spezifische Minispeicher beim Propeller, der auf einen globalen RAM zugreifen kann. Greenarry hatte da auch ein paar neue Ideen. Die Cores auf einer Grafikkarte sind nochmal anders [Donnerstag, 9. Januar 2014] [20:56:16] NUMA heißt ja nur, dass die Zugriffszeit nicht trivial ist. [Donnerstag, 9. Januar 2014] [20:56:45] Nur ist gut ;) [Donnerstag, 9. Januar 2014] [20:56:48] Bei Green Array ist jeder Knoten ein "Computer", der halt mit seiner Nachbarschaft vernetzt ist. [Donnerstag, 9. Januar 2014] [20:57:21] Auf NUMA-Speicher kann man "flach" zugreifen, muss aber mit Performance-Einbußen rechnen (evtl. sehr starken ;-). [Donnerstag, 9. Januar 2014] [20:57:32] Aber gehen tut's immer. [Donnerstag, 9. Januar 2014] [20:58:04] Irgendwie geht fast alles irgendwann [Donnerstag, 9. Januar 2014] [20:58:56] Mir ist auch nicht so ganz klar, wie man großen Speicher in Forth verwaltet (ich rede von 1TB RAM++) [Donnerstag, 9. Januar 2014] [21:01:14] Auf solchen Rechnern lässt man das eh das Betriebsystem machen. [Donnerstag, 9. Januar 2014] [21:04:04] Ich glaube aber, dass Forth gewinnen würde, wenn es den unified memory Ansatz verlassen könnte [Donnerstag, 9. Januar 2014] [21:05:56] Das fügt halt aber konzeptionelle Komplexität in die Forth-VM ein, die jetzt nicht da ist. [Donnerstag, 9. Januar 2014] [21:06:21] Ansonsten: Bibliotheken, Bibliotheken und als Krönung: Bibliotheken. Nicht jeder will alles selbst from scratch bauen [Donnerstag, 9. Januar 2014] [21:07:02] Die Wordsets sind eine gute Idee, aber viel zu wenig und nicht mehr zeitgemäß [Donnerstag, 9. Januar 2014] [21:07:57] Ja, das ist auch Stephen Pelcs Meinung. [Donnerstag, 9. Januar 2014] [21:08:21] Aber wenn's um die praktische Realisierung geht, ist Stephen auf der "if you want it done right, you have to do it yourself"-Schiene. [Donnerstag, 9. Januar 2014] [21:08:40] Er hat MINOS aufgegeben, als er mit dem Terminal nicht weiterkam. [Donnerstag, 9. Januar 2014] [21:08:45] Das ist bei ihm abgestürzt. [Donnerstag, 9. Januar 2014] [21:08:47] Bei mir nicht. [Donnerstag, 9. Januar 2014] [21:09:00] Ich konnte sein Problem nicht reproduzieren, und deshalb nicht fixen. [Donnerstag, 9. Januar 2014] [21:09:18] Und er meinte, ich sei da nicht kooperativ gewesen. [Donnerstag, 9. Januar 2014] [21:09:39] Ein Nachteil, dass Forth so einfach ist/erscheint. Da denkt jeder, er könne alles selbst und dann am Besten... [Donnerstag, 9. Januar 2014] [21:09:45] ;-) [Donnerstag, 9. Januar 2014] [21:10:46] Wahrscheinlich hat Stephen Probleme mit einer Entwickler-Version von VFX gehabt, die ich nicht hatte. [Donnerstag, 9. Januar 2014] [21:11:53] Naja, jetzt nutzt er Gtk, und das ist für typische embedded-Linux-Systeme einfach viel zu bloatig. [Donnerstag, 9. Januar 2014] [21:12:27] Ein anderes Thema wäre Parallelprocessing. Sei es als Multitasking innerhalb einer CPU oder übers Netz. [Donnerstag, 9. Januar 2014] [21:13:24] Gtk ist besser als Qt. [Donnerstag, 9. Januar 2014] [21:13:58] Gnome ist ja auch besser als KDE ;) [Donnerstag, 9. Januar 2014] [21:13:58] Multitasking ist gelöst, da müssen nur ein paar Sachen standardisiert werden. [Donnerstag, 9. Januar 2014] [21:14:10] Mir gefällt KDE besser. [Donnerstag, 9. Januar 2014] [21:14:23] KDE ist zuviel Bloat ;) [Donnerstag, 9. Januar 2014] [21:15:29] Das ist Gnome aber auch. Die übelste Zwiebel im KDE ist Akonadi. [Donnerstag, 9. Januar 2014] [21:15:57] Ich kämpfe zur Zeit bei net2o mit der Stabilisierung bei Multi-Threading. [Donnerstag, 9. Januar 2014] [21:16:39] Das ist hauptsächlich Fizelarbeit, weil Gforth selbst nicht überall thread-safe ist. [Donnerstag, 9. Januar 2014] [21:16:58] Gestern habe ich ecvt durch ecvt_r ersetzt... [Donnerstag, 9. Januar 2014] [21:17:12] Der aktuelle fossilstand bringt den Test-client auf 100% CPU und sonst nix [Donnerstag, 9. Januar 2014] [21:17:25] Du brauchst da vermutlich ein neues Gforth ;-) [Donnerstag, 9. Januar 2014] [21:17:34] Bei mir läuft alles. [Donnerstag, 9. Januar 2014] [21:17:47] Jungfäuliches Testsystem mit do neu aufgesetzt. [Donnerstag, 9. Januar 2014] [21:18:17] Ich mach doch, was der Meister sagt ;) [Donnerstag, 9. Januar 2014] [21:18:19] Hm... [Donnerstag, 9. Januar 2014] [21:18:40] gforth --version sagt 20131227--- [Donnerstag, 9. Januar 2014] [21:19:07] Die Version ändert sich nicht unbedingt jeden Tag. [Donnerstag, 9. Januar 2014] [21:19:57] Wie gesagt. Alles gelöscht und per aktuellem (!) do alles neu aufgebaut. [Donnerstag, 9. Januar 2014] [21:20:14] Ja, mach' ich hier auch. [Donnerstag, 9. Januar 2014] [21:20:17] Auch die Installationen unter /usr/local waren alle weg [Donnerstag, 9. Januar 2014] [21:20:26] Sollte dann eigentlich tun. [Donnerstag, 9. Januar 2014] [21:20:53] Kommt dir bekannt vor? So vor ein paar Zeilen zurück? ;) [Donnerstag, 9. Januar 2014] [21:21:24] Du bekommst mit dem aktuellen do das Gforth aus dem aktuellen git-Repro gebaut, wenn es net2o.fs nicht sauber lädt. [Donnerstag, 9. Januar 2014] [21:21:55] Es gibt zwei gforth Verzeichnisse: EInes mit der Versionsnummer, eines mt nem .git drin. [Donnerstag, 9. Januar 2014] [21:22:03] Ja. [Donnerstag, 9. Januar 2014] [21:22:20] Das soll so sein, das erste ist der Snapshot, der dient dazu, das aus den Sourcen zu bauen. [Donnerstag, 9. Januar 2014] [21:22:37] Unter /usr/local/bin kommt aber das gforth mit der Versionsnummer [Donnerstag, 9. Januar 2014] [21:23:12] Naja, das git-Gforth hat die gleiche Versionsnummer. [Donnerstag, 9. Januar 2014] [21:23:22] Die ändert sich nicht jeden Tag! [Donnerstag, 9. Januar 2014] [21:24:02] Hast du einen Vorschlag zur Automatisierung? [Donnerstag, 9. Januar 2014] [21:24:31] Also, wenn ich in Git einen Tag vergebe, wird mit Versionsnummer gebuildet, sonst mit Git-Hash? [Donnerstag, 9. Januar 2014] [21:25:27] Die git hashnummer ist nicht wirklich brauchbar. IMHO [Donnerstag, 9. Januar 2014] [21:25:48] Naja, zur Unterscheidung von "Snapshot build" vs. "Git build" schon. [Donnerstag, 9. Januar 2014] [21:26:19] Den Timestamp vom Compiler generieren zu lassen löst das Problem auch nicht [Donnerstag, 9. Januar 2014] [21:26:50] Ich fürchte, da wirst Du wohl bei jedem incompatiblem Change die version anpassen müssen. [Donnerstag, 9. Januar 2014] [21:27:01] Wahrscheinlich. [Donnerstag, 9. Januar 2014] [21:27:10] Die letzte Änderung war ein Bugfix in c-section. [Donnerstag, 9. Januar 2014] [21:27:23] Die ist von außen gar nicht sichtbar, nur, dass c-section jetzt verwendbar ist. [Donnerstag, 9. Januar 2014] [21:27:25] Nicht jeder commit wird das erfodern. (Docu oder so) [Donnerstag, 9. Januar 2014] [21:27:46] Das könnte dein Problem sein. [Donnerstag, 9. Januar 2014] [21:27:54] Mach' mal einen git pull in dem gforth-Verzeichnis mit git. [Donnerstag, 9. Januar 2014] [21:28:01] Und dann make && sudo make install [Donnerstag, 9. Januar 2014] [21:28:39] Wenn du die Version mit kaputtem c-section hattest, dann erklärt die das Hängen. [Donnerstag, 9. Januar 2014] [21:29:18] c-section ( ... xt lock -- ... ) fürt xt als "critical section" aus, also mit lock gesetzt und hinterher garantiert freigegeben. [Donnerstag, 9. Januar 2014] [21:29:22] Der Change würde dann eine neue Versionsnummer rechtfertigen [Donnerstag, 9. Januar 2014] [21:29:36] Snapshot-Datum auf jeden Fall. [Donnerstag, 9. Januar 2014] [21:30:07] sieht viel besser aus. [Donnerstag, 9. Januar 2014] [21:30:16] Läuft [Donnerstag, 9. Januar 2014] [21:30:30] >timing braucht man übrigens nicht mehr, das 'Rausschreiben des Timings mach' ich jetzt nicht mehr auf das Terminal. [Donnerstag, 9. Januar 2014] [21:30:39] Dann war's das. [Donnerstag, 9. Januar 2014] [21:31:28] der git pull hatte die pthread.fs aktualisiert. [Donnerstag, 9. Januar 2014] [21:31:31] Ja. [Donnerstag, 9. Januar 2014] [21:31:37] Da war das drin. [Donnerstag, 9. Januar 2014] [21:31:53] Das sind nur 4 falsche durch 2 richtige Zeilen ersetzt. [Donnerstag, 9. Januar 2014] [21:32:32] sowas soll manchmal Wunder bewirken.. [Donnerstag, 9. Januar 2014] [21:32:33] Es ist immer erstaunlich, wenn man Bugs fixt, und das Wort hinterher nur noch halb so lang ist wie vorher. [Donnerstag, 9. Januar 2014] [21:34:28] Wenn Du jetzt ohnehin auf gforth-git abfährst, kann der wget vorher IMHO entfallen. [Donnerstag, 9. Januar 2014] [21:34:42] (im ./do) [Donnerstag, 9. Januar 2014] [21:35:00] Was mache ich mit Leuten, die noch gar kein Gforth haben? [Donnerstag, 9. Januar 2014] [21:35:17] Ohne Gforth kannst du das git-Gforth nicht bauen. [Donnerstag, 9. Januar 2014] [21:35:41] git gforth fixen ;) [Donnerstag, 9. Januar 2014] [21:35:55] Da gibt's nix zu fixen. [Donnerstag, 9. Januar 2014] [21:36:02] Gforth baut sich halt zu 75% selbst. [Donnerstag, 9. Januar 2014] [21:36:09] Also brauchst du ein Gforth, um Gforth zu bauen. [Donnerstag, 9. Januar 2014] [21:36:27] Der Snapshot baute sich doch auch selbst. [Donnerstag, 9. Januar 2014] [21:36:30] Und die Distribution enthält die Teile von Gforth, für die man ein Gforth braucht, um sie zu bauen. [Donnerstag, 9. Januar 2014] [21:36:41] Das Git-Repo sollte diesen Binär-Müll aber nicht enthalten. [Donnerstag, 9. Januar 2014] [21:37:33] Das überlasse ich Dir ;) [Donnerstag, 9. Januar 2014] [21:37:42] Ich mach dann mal Schluss für heze [Donnerstag, 9. Januar 2014] [21:37:47] heute... Tss [Donnerstag, 9. Januar 2014] [21:37:48] Ciao! [Donnerstag, 9. Januar 2014] [21:37:51] Ciao [Donnerstag, 9. Januar 2014] [21:37:54] * BerndPaysan macht das Licht aus [Donnerstag, 9. Januar 2014] [21:37:59] Beenden MatthiasT (~Thunderbi@dslb-178-006-007-130.pools.arcor-ip.net) hat diesen Server verlassen ("").