Xina output behaviour.

[m***@gmail.com]

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.

[Robert Spykerman]

Post by m***@gmail.com
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.
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 stuffed up :)

Robert Spykerman

[s***@controlq.com]

Date: Sat, 26 Apr 2008 09:47:10 -0700 (PDT)
Newsgroups: comp.lang.forth, comp.lang.forth.mac
Subject: Re: Xina output behaviour.

Post by m***@gmail.com
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.
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 stuffed up :)
Robert Spykerman

Almost ... I believe you are looking to uncooked terminal I/O, as it were,
and the extraneous <cr> is from the input. You'll need to set echo OFF,
and then you will be responsible for what appears on the screen. Similar
code is used for password processing, where echo is just turned off until
a CR terminates the input ... man termio(s) on most *nix systems will
describe the code in more detail ...

HTH ...
Rob.
---- Posted via Pronews.com - Premium Corporate Usenet News Provider ----
http://www.pronews.com offers corporate packages that have access to 100,000+ newsgroups

[m***@gmail.com]

Post by Robert Spykerman

Post by m***@gmail.com
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.
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  stuffed up :)
Robert Spykerman

The only termio flag that I can find to effect the NL character causes
it to be echoed even with ECHO turned off, so it looks like I need to
turn the termio ECHO & ICANON flags off permanently then make the
input words manually echo characters.

[Robert Spykerman]

On Apr 27, 2:47 am, Robert Spykerman <***@gmail.com>
wrote:
...

Post by Robert Spykerman
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 stuffed up :)
Robert Spykerman

Ok, I think I may have managed to fix the SYSTEM word. I've had to
patch around it a little and create an XOSFORK word to call fork
because I discovered that the OS X fork syscall returns the PID in EAX
and another value in EDX, which is slightly different to the linux
behaviour.

This one in EDX appears to be either 1 or 0 and appears to indicate
the parent and child. Whether this can take other values I am not
quite so sure yet. I'm really going to have to dig in deep into the
kernel source to see why this is so.

Anyhow, trial and error's produced a working SYSTEM word, so as far as
I can tell the current iteration of the mac port works almost as good
as lina 4. All that's left is probably to start work on SAVE-SYSTEM.
And hope that no other unexpected surprises rear their head.

The source is still messy and in need of tidying, in fact so does the
CVS, but if you dare, you may try getting xina.asm at: (please send
bug reports)

http://xina.cvs.sourceforge.net/xina/xina-generic/

Instructions for building in comments.

Robert Spykerman

[Albert van der Horst]

<SNIP>

Post by Robert Spykerman
Anyhow, trial and error's produced a working SYSTEM word, so as far as
I can tell the current iteration of the mac port works almost as good
as lina 4.

Marvellous!

How is the options and library doing?
Can you say
xina -a
and do
REQUIRE DEBUG DO-DEBUG
REQUIRE DUMP PAD 100 DUMP
REQUIRE SEE SEE DUMP
and all that ?

Post by Robert Spykerman
All that's left is probably to start work on SAVE-SYSTEM.

Okay, here is the plan, assuming you are using mach-o objects.
(I read the doc's, it is gonna be no pick-nick!)

1. Find and apply all tools to strip the binary from all unneeded
symbols and sections. Look at loader options, and ``help strip''
``apropos strip''
2. link two versions. In one of them, add a buffer of $4568
bytes at the beginning, e.g. in front of cold.
3. Send to me (or otherwise publish) for both versions
A. binary
B. source
C. objdump output, or whatever tool there is to have
information of the binary
D. The output of
HEX BM . EM .
E. A DUMP of everything below BM that you can still fetch
without a crash.

My mail address is in my sig.

Post by Robert Spykerman
And hope that no other unexpected surprises rear their head.

Well, we haven't run the regression test yet. Mostly it surprises
me what problems still lurk, but they are mostly minor.

Post by Robert Spykerman
The source is still messy and in need of tidying, in fact so does the
CVS, but if you dare, you may try getting xina.asm at: (please send
bug reports)
http://xina.cvs.sourceforge.net/xina/xina-generic/

Once the source is somewhat stable, I can add it to my generic
system. This will provide us with nice tailored pdf documentation.
That will be version 5.xx though.

Post by Robert Spykerman
Instructions for building in comments.

What do you mean?

Post by Robert Spykerman
Robert Spykerman

Groetjes Albert

--

[Robert Spykerman]

Post by Albert van der Horst
Marvellous!
How is the options and library doing?
Can you say
xina -a
and do
REQUIRE DEBUG DO-DEBUG
REQUIRE DUMP PAD 100 DUMP
REQUIRE SEE SEE DUMP
and all that ?

Well, as you've probably realized I've been porting your stable
version 4.x not the 5.

All the above seems to work except REQUIRE DEBUG - it says it's not
present but I get the exact same result on the same untouched version
of lina running on linux, so maybe my forth.lab file is a little out
of date.

So files/blocks and options are probably okay.

If you asked if I have any concerns at present:

* I mapped the newselect syscall to select. Seems to work so far. /
fingers crossed.
* I really need to get the kernel source to find out about all these
syscalls, ie the quickfix for fork the OS X one turns out to be quite
a bit different than the linux one in terms of return values - I don't
know if my dirty fix will return the appropriate error message should
one occur.

Post by Albert van der Horst
Okay, here is the plan, assuming you are using mach-o objects.
(I read the doc's, it is gonna be no pick-nick!)

You said it heh. It'll be fun though. Be worth it.

I'm gonna be really busy in real life for the next 5 days though, so
don't hold your breath, but as soon as I can, I'll email you some
results. You can get me at this email at gmail.

Post by Albert van der Horst
D. The output of
HEX BM . EM .

At the moment, this I can get you.
BM = 0x20C8, EM = 0x4002054
Difference, ie EM BM - . 0x3FFFF8C

It is slightly different from the linux values, but from memory I
think linux binaries start executing higher up.

ie on lina on my debian, I get BM = 0x8049074, 0xC049000 again with a
difference of 0x3FFFF8C

Post by Albert van der Horst
E. A DUMP of everything below BM that you can still fetch
without a crash.

With what I have, I can show you this:

REQUIRE DUMP HEX \ BM = 0x20C8
OK
1000 100 DUMP

0000,1000: CEFA EDFE 0700 0000 0300 0000 0200 0000 |................|
0000,1010: 0800 0000 3C02 0000 8500 0000 0100 0000 |....<...........|
0000,1020: 3800 0000 5F5F 5041 4745 5A45 524F 0000 |8...__PAGEZERO..|
0000,1030: 0000 0000 0000 0000 0010 0000 0000 0000 |................|
0000,1040: 0000 0000 0000 0000 0000 0000 0000 0000 |................|
0000,1050: 0000 0000 0100 0000 7C00 0000 5F5F 5445 |........|...__TE|
0000,1060: 5854 0000 0000 0000 0000 0000 0010 0000 |XT..............|
0000,1070: 0080 0000 0000 0000 0080 0000 0700 0000 |................|
0000,1080: 0700 0000 0100 0000 0000 0000 5F5F 7465 |............__te|
0000,1090: 7874 0000 0000 0000 0000 0000 5F5F 5445 |xt..........__TE|
0000,10A0: 5854 0000 0000 0000 0000 0000 C820 0000 |XT........... ..|
0000,10B0: 386F 0000 C810 0000 0000 0000 0000 0000 |8o..............|
0000,10C0: 0000 0000 0004 0080 0000 0000 0000 0000 |................|
0000,10D0: 0100 0000 7C00 0000 5F5F 4441 5441 0000 |....|...__DATA..|
0000,10E0: 0000 0000 0000 0000 0090 0000 00A0 FF03 |................|
0000,10F0: 0080 0000 0000 0000 0700 0000 0700 0000 |................|
OK
FFF @
Bus error

The magic number is winking at us from $1000 = shows the mach-o
header. This is exactly how the file looks like on disk. Anything
lower falls into the first 4k, pagezero, as you can see, the OS
doesn't like it when I touch it.

So access to the headers does not seem too difficult.

I think I see what you're getting at though, you want to see what
changes in the headers in the 2 differently sized binaries?

I'll get back to you on the other jobs, at the moment, I gotta get
back to real life <grin>

Post by Albert van der Horst

Post by Robert Spykerman
Instructions for building in comments.

What do you mean?

In the comments of the xina.asm file, at the top I put the mac
specific command line invocation of the build tools necessary to get a
working binary from the assembly source. Options like -segprot etc for
the linker, that sort of thing.

Post by Albert van der Horst
Groetjes Albert

Robert Spykerman

[Robert Spykerman]

On Apr 27, 11:13 pm, Albert van der Horst <***@spenarnc.xs4all.nl>
wrote:
..

Post by Albert van der Horst
Okay, here is the plan, assuming you are using mach-o objects.
(I read the doc's, it is gonna be no pick-nick!)
1. Find and apply all tools to strip the binary from all unneeded
symbols and sections. Look at loader options, and ``help strip''
``apropos strip''
2. link two versions. In one of them, add a buffer of $4568
bytes at the beginning, e.g. in front of cold.
3. Send to me (or otherwise publish) for both versions
A. binary
B. source
C. objdump output, or whatever tool there is to have
information of the binary
D. The output of
HEX BM . EM .
E. A DUMP of everything below BM that you can still fetch
without a crash.
My mail address is in my sig.

..

Post by Albert van der Horst
Groetjes Albert

Albert, sorry about the delay, had a lot of real life to deal with,
but I've just sent you a tar.bz2 with some data to the email address
on your website and sig.

Now it's just a matter of sitting down with all this output and
figuring out how best to hack it. Down with a bit of a flu so it may
take a while as well :(

Tell me if you do not get it in case gmail messes it up or it gets
caught in a spam filter or something (I've put ciforth xina in the
title)

Robert Spykerman

[m***@gmail.com]

Post by Robert Spykerman

Post by m***@gmail.com
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.
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  stuffed 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.

[Robert Spykerman]

On Apr 28, 2:36 pm, ***@gmail.com wrote:
...

Post by m***@gmail.com
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.

Base 36? What are you doing? Exploring Mayan ruins or something? :)

Mmmm.. It can count. In a manner of speaking.

The problem is probably that digits beyond hex have not properly been
defined in the kernel to work.

So...

80386 ciforth 4.0.6
17 BASE !
OK
10 1 - .
G OK
DECIMAL 36 BASE !
OK
10 1 - .
Z OK
1Z 1+ .
20 OK
20 Z * .
20 Z ? ciforth ERROR # 12 : NOT
RECOGNIZED
20 G .
20 G ? ciforth ERROR # 12 : NOT
RECOGNIZED
G.
G.? ciforth ERROR # 12 : NOT
RECOGNIZED
G
G? ciforth ERROR # 12 : NOT
RECOGNIZED

I'm guessing that it's probably a trivial matter to fix the kernel
source to take in these letters, just follow what's been done for base
16. May take a look after fixing some other things like SAVE-SYSTEM
and ensuring everything else works.

For now, all your base > 16 are NOT belong to us...

Robert Spykerman

[Albert van der Horst]

Post by m***@gmail.com

Post by Robert Spykerman

Post by m***@gmail.com
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.
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

--

[m***@gmail.com]

Post by Albert van der Horst

Post by m***@gmail.com

Post by Robert Spykerman

Post by m***@gmail.com
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.
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
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.

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?

[Robert Spykerman]

Post by m***@gmail.com
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?

forth.lab is in the xina-generic subdir.

Or you can get it from lina

invoke xina with forth.lab in your path with

xina -a

which will load the forth.lab file.

You will then get REQUIRE. It works.

I admit, the CVS is pretty untidy - I've got to get them to reset
everything then tidy it up - mea culpa, CVS is a very complicated tool
in retrospect I shouldn't have bothered for such a relatively simple 1
file source project. I thought at the time it might have been a good
idea to try and learn how to use it.

Robert Spykerman

[Albert van der Horst]

Post by Robert Spykerman

Post by m***@gmail.com
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?

forth.lab is in the xina-generic subdir.
Or you can get it from lina
invoke xina with forth.lab in your path with
xina -a
which will load the forth.lab file.
You will then get REQUIRE. It works.
I admit, the CVS is pretty untidy - I've got to get them to reset
everything then tidy it up - mea culpa, CVS is a very complicated tool
in retrospect I shouldn't have bothered for such a relatively simple 1
file source project. I thought at the time it might have been a good
idea to try and learn how to use it.

CVS in itself certainly isn't overkill. One of its guises (Tortoise
on Windows) is so pleasant to use that I use it routinely
for such simple things as day to day version of a log book,
indeed a single file.

Things will become more complicated, then you may be happy
that you did it after all. And maybe I can use it as a starting
point for a public ciforth cvs version.

What I would advise is to just store the starting point (in this
case lina) as version 1.0. E.g if I fetch version 1.0 of lina,
I get a working version of good old fig-forth.
If I fetch version 1.0 of my Dec Alpha ciforth, I get some i86
ciforth. Version 1.0 of renesas ciforth is some 6809 ciforth.
(An indeed versions 1.12 is the first version that is even
accepted by the renesas assembler.)
In this way all diffs are present in the archive.

Post by Robert Spykerman
Robert Spykerman

--

[Albert van der Horst]

Post by m***@gmail.com
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.
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

Try this

1000 MS

As you see, the carriage return is reflected before even the execution
is started. It is the point where you can no longer edit the line.
The carriage return is reflected by the OS, not lina/xina.
So what you have to do is change the way the console behaves,
which is regulated by the dreaded termios struct. I'm looking into
it right now, for a flash program, and it is not pretty.
You have to disable echo, then reflect everything manually.
Come to think about it, it also means you cannot see what you
type, before you press return. So this is hardly an option.

In the generic system, you can plug in a key by key input.
There is a prelude.m4 with ``define({_KEY_BY_KEY_}, _no)''
Once xina is added to the configuration files, you can use that.
This is the step that generates the .asm.

By the way I think it is similar to a request to ask a Unix shell
not to do
echo aap
aap
but
echo aap aap

I personally would not like that.

It is useful for 4 by 16 character displays, I admit.
(But embedded ciforth version have a KEY-BY-KEY by default.)

Post by m***@gmail.com
neccesary. Also, is their a way to get Mops to do this as well?
Thanks in advance.

I'm glad this kind of things come up. It means at least it is more
or less working.

Groetjes Albert

--

[d***@web.de]

Post by m***@gmail.com
Also, is their a way to get Mops to do this as well?

In file MLTEFwindMod.txt change method interpret: of class MLTEFwind:

:m INTERPRET: { \ echoCR? strt end -- }
( ... )

getselect: theMLTEview nip dup setselect: theMLTEview

echoCR? IF space THEN \ was: echoCR? IF cr THEN
evalFromQE flush_TWstr

( ... )
;m

Then rebuild PowerMops from the PMops nucleus.

Cheers,
Reinhold Straub

[m***@gmail.com]

Post by m***@gmail.com
Also, is their a way to get Mops to do this as well?

:m INTERPRET:  { \ echoCR? strt end -- }
( ... )
        getselect: theMLTEview nip dup  setselect: theMLTEview
        echoCR? IF  space  THEN         \ was: echoCR? IF  cr  THEN
        evalFromQE  flush_TWstr
( ... )
;m
Then rebuild PowerMops from the PMops nucleus.
Cheers,
Reinhold Straub

Thank you very very much.