On Apr 28, 2:21=A0pm, Albert van der Horst <alb...@[EMAIL PROTECTED]
>
wrote:
> In article
<3d672df0-00e1-4300-94b4-6f1fd03d8...@[EMAIL PROTECTED]
>,
>
>
>
> =A0<morrimich...@[EMAIL PROTECTED]
> wrote:
> >On Apr 26, 11:47=3DA0am, Robert Spykerman <robert.spyker...@[EMAIL PROTECTED]
>
> >wrote:
> >> On Apr 26, 7:20 pm, morrimich...@[EMAIL PROTECTED]
wrote:
>
> >> > In most Forths that I have used, output is on the same line as the
> >> > input to the interpreter, but in Xina the output is on the next
line.=
> >> > For instance:
>
> >> > \ Most Forths:
> >> > 2 2 + . 4 ok
> >> > \ Xina
> >> > 2 2 + .
> >> > 4 ok
>
> >> > Is their anyway to make Xina output on the same line as it's input?
I=
> >> > don't mind having to edit the assembly source if that is what's
> >> > neccesary. Also, is their a way to get Mops to do this as well?
>
> >> > Thanks in advance.
>
> >> Hmm.. that's an interesting question.
>
> >> What you are seeing is the default behaviour of lina.
>
> >> I am still dissecting and piecing the source together in my head.
Lina
> >> takes input from the console from stdin, (ie REFILL-TIB) and the
> >> carriage return you see (before the output and OK) , I believe stems
> >> from the cr you tap in as stdin is read via READ-FILE.
>
> >> I've looked thru' the source and I can't account for it in any other
> >> way at present.
>
> >> So to change this behaviour, I am not sure exactly what you can do
> >> about it, as yet.
>
> >> One possibility may be to flip some flags in the termio structure
that
> >> sets up the terminal via the ioctl syscall. Maybe there might be a
> >> flag that could prevent the newline. I admit I am unsure about
whether
> >> this will work, I do not know enough about this - still learning how
> >> linux/unixes are put together :)
>
> >> Albert van der Horst might be able to suggest something.
>
> >> If I find out I shall let you know, meanwhile if you find any thing
> >> else buggy let me know, there's a lot of work yet to be done. I still
> >> haven't found out why my fork =3DA0stuffed up :)
>
> >> Robert Spykerman
>
> >I don't know if you consider it a bug or not, but base 36 doesn't
> >work. Which is a shame since you can have ever so much fun with it.
>
> It doesn't work out of the box. This is because a word
> starting with G-Z is not recognized as a number.
> After REQUIRE DEADBEEF those number denotations are added.
>
> (This should be REQUIRE DEADHORSE because HEX DEADBEEF is
> recognized all right:
>
> HEX DEADBEEF .
> -21524111 OK
>
> Anyway... )
>
> It may pay off to look through the forth.lab file.
> You can view it with an ascii editor.
>
> Groetjes Albert
>
> --
> --
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- like all pyramid schemes -- ultimately falters.
> albert@[EMAIL PROTECTED]
&=3Dnhttp://home.hccnet.nl/a.w.m.van.der.horst
REQUIRE isn't defined, and the version of Xina that I got from the CVS
was just the kernel in assembler. But I don't really need base 36, I
just wanted to play with it (for instance what is R2-D2's model number
in decimal?). Now if only I could figure out how to use termios using
assembler. Could I put the tcgetattr and tcsetattr stub calls in the
kernel without breaking anything?
|
