c't

c't-Projekte - Mailinglisten


[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

Re: [ct-bot] Basic-Interpreter (für c't-Bot)

Absender: Timo Sandmann
Datum: Mi, 13.04.2011 19:55:32
In-reply-to: <20110413172730.99d2e392.bergeruw@xxxxxxx>
References: <1ac236efdb2ae353dba0652e0009d0d7.squirrel@xxxxxxxxxxxxxxxxxxx> <B796DEF3-49CB-4F9A-B0AA-D42C7000926D@xxxxxxxxxxxxxxx> <20110309225657.432787bb.bergeruw@xxxxxxx> <4D19D5D5-4972-4D76-95F1-AFA65B36A076@xxxxxxxxxxxxxxx> <4D80E3E5.8050702@xxxxxxx> <C2269E6E-EBB2-40E9-B1EB-06984CD3ECDF@xxxxxxxxxxxxxxx> <9DDF1CF6-342A-4681-8296-77899A820AA8@xxxxxxxxxxxxxxx> <20110320213615.6522f43a.bergeruw@xxxxxxx> <6FB8CA6E-9D8F-4556-936C-0B0CC95B789A@xxxxxxxxxxxxxxx> <1a7fbb756d29789435f7638aa199bea6.squirrel@xxxxxxxxxxxxxxxxxxx> <77714C4A-E5BA-4D31-AFE5-4D20122ACC7C@xxxxxxxxxxxxxxx> <4D921683.5060902@xxxxxxx> <CEAAFE4A-1B5A-4163-ABAF-053B7261EC0A@xxxxxxxxxxxxxxx> <20110329231209.3a643626.bergeruw@xxxxxxx> <4D92DD39.90407@xxxxxxx> <53DA4806-F328-4FE1-82B9-17E8BE8F8C36@xxxxxxxxxxxxxxx> <4D94DFC7.1070505@xxxxxxx> <0DE34F28-6A1B-45F8-8A3C-9CC8D293410D@xxxxxxxxxxxxxxx> <4DA4B0EF.7020101@xxxxxxx> <E6E33CF5-B813-4A4C-94AC-E7A49A326B70@xxxxxxxxxxxxxxx> <20110413172730.99d2e392.bergeruw@gmx. net>


Hallo,

Am 13.04.2011 um 17:27 schrieb Uwe Berger:
> na sagen wir mal so: es kommt auf die Prozedure an, die dahinter steht. Es muss ja nicht fgets() oder usart_read_line() wie in dem Beispiel sein. Es könnte auch ein Prozedure sein die IR-Eingaben entgegennimmt, verarbeitet und in buf zurückgibt...

ja das ist klar, ich meinte nur, ob zwischen dem Einlesen einer Zeile (also kompletter Zahl) und einem Tastendruck unterschieden werden kann vom Basic-Programm aus.

> Ja es gehen nur Zahlen, wobei aber kein Fehler bei nichtnumerischen Zeichen generiert wird (es wird atoi() zur Konvertierung verwendet), das Ergebnis würde dann halt nur 0 sein.
> 
> Ich bin derzeit am überlegen, ob ich String-Support in den Interpreter einbaue. Bisheriger Stand der Überlegung geht dahin:
> * Stringvars haben ein $ hinter dem Namen, z.B. a$ und müssen eventuell vorher deklariert werden
> * die Länge jeder Stringvar wäre begrenzt bzw. in der Konfig einstellbar
> * Stringarrays, also DIM a$(10) sollte gehen
> * ein paar Grundfunktionen zur Stringverarbeitung, DATA dürfte auch Strings aufnehmen
> 
> Aber die Gedanken müssen noch ein wenig reifen, bis ich an die Umsetzung gehe.
> 
> Wäre das eine interessante Geschichte für euch?

Ich denke, das hängt ganz stark davon ab, was für Programme man entwickeln möchte. Meist benötigen String-Operationen aber sehr viel Platz im Flash, wobei das natürlich nicht so tragisch ist, wenn das Ganze optional bleibt. Ob dafür wirklich Bedarf besteht, kann ich aber nicht beurteilen. 

Grüße,
Timo