> In article <3d672df0-00e1-4300-94b4-6f1fd03d8...@34g2000hsf.googlegroups.com>,
>
>
>
>  gmail.com> wrote:

>>On Apr 26, 11:47=A0am, Robert Spykerman gmail.com>
>>wrote:

>>> On Apr 26, 7:20 pm, morrimich...@gmail.com 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 =A0stuffed 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@spe&ar&c.xs4all.nl &=nhttp://home.hccnet.nl/a.w.m.van.der.horst