S Jack <sdwjack69@gmail.com> writes:
> I like block files and wouldn't care for a Forth that doesn't support
> them. The way they worked originally, as in FigForth, I find neat. I
> also like the simple coding of the Fig editor.

I should mention my block editor with vim-ish key bindings:

https://vsta.org/cgi-bin/fview.py?path=/src/vi.txt

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

On Saturday, March 11, 2023 at 7:50:06 PM UTC-8, Andy Valencia wrote:
> I should mention my block editor with vim-ish key bindings:
>
> https://vsta.org/cgi-bin/fview.py?path=/src/vi.txt
>
> Andy Valencia
> Home page: https://www.vsta.org/andy/
> To contact me: https://www.vsta.org/contact/andy.html
I will give this a try, thanks!

"minf...@arcor.de" <minforth@arcor.de> writes:
>Anton Ertl schrieb am Samstag, 11. M=C3=A4rz 2023 um 12:23:03 UTC+1:
>> In Gforth BUFFER just calls BLOCK, and that reads.
>
>Shouldn't it be the other way round? Somewhat in the line of
>
>: BLOCK \ ( ub -- adr ) 7.6.1.0800 provide block in assigned buffer
> dup buffer dup (update-flag-set?)
> IF nip ELSE tuck swap (read-block-from-file) (reset-update-flag) THEN ;

Yes, now I think that the idea is that block calls buffer. The
current implementation of BUFFER in Gforth is actually the same as the
very first implementation of buffer I wrote in 1994:

(Bernd Paysan 1998-12-13) : buffer ( u -- a-addr ) \ block
(Neal Crook 1999-04-16)[documentation, not shown here]
(Anton Ertl 1994-08-10) \ reading in the block is unnecessary, but simpler
(Anton Ertl 1994-08-10) block ;

I can only guess at why I did it this way at the time: Apparently
despite having used blocks from 1983 to the late 1980s, I did not
understand them well enough at the time to know exactly what the point
of BUFFER is, and that despite the reading taking a noticable amount
of time (I used blocks on a C64 with floppy disks); I guess it was not
that often that I wanted to just write a block from scratch.

And Bernd Paysan kept this BUFFER implementation in his multi-buffer
revision, intended for better performance. He had worked extensively
with blocks, too, and blocked.fb in Gforth is from him.

Makes me wonder if the non-reading BUFFER is just a too-complex
interface, or if I just used the wrong source material to learn it
(Ronald Zech's book was my primary source for learning Forth).

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

dxforth <dxforth@gmail.com> writes:
>> In Gforth BUFFER just calls BLOCK, and that reads.
>
>So that leaves multi-tasking as the only reason for ANS' requirement an
>interim buffer be used to copy a block. The simplified code posted would
>work on Gforth and majority of systems in use today?

If you mean

|: copy-block ( from to -- )
| swap block swap buffer 1024 move update ;

from <tuhh4p$2dn7r$1@dont-email.me>, that would fail with Gforth for
certain values of from and to.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

On 12/03/2023 7:55 pm, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>> In Gforth BUFFER just calls BLOCK, and that reads.
>>
>> So that leaves multi-tasking as the only reason for ANS' requirement an
>> interim buffer be used to copy a block. The simplified code posted would
>> work on Gforth and majority of systems in use today?
>
> If you mean
>
> |: copy-block ( from to -- )
> | swap block swap buffer 1024 move update ;
>
> from <tuhh4p$2dn7r$1@dont-email.me>, that would fail with Gforth for
> certain values of from and to.

Why - what's special about that code whereby certain values would fail?

In article <167859284307.22763.12722674216596088048@media.vsta.org>,
Andy Valencia <vandys@vsta.org> wrote:
>S Jack <sdwjack69@gmail.com> writes:
>> I like block files and wouldn't care for a Forth that doesn't support
>> them. The way they worked originally, as in FigForth, I find neat. I
>> also like the simple coding of the Fig editor.
>
>I should mention my block editor with vim-ish key bindings:
>
>https://vsta.org/cgi-bin/fview.py?path=/src/vi.txt

My editor with wordstar key bindings may be interesting.
mina version of ciforth works in DOSBOX and have full screen
editing mode, see the chapter of editing commands.
It accesses the video memory directly. It is a decendant
of my Osborne (CP/M) editor. (63 K + 1k video memory ).
I've seen no other editors that can copy a multi line definition
easily from one screen to the next. (It piles up lines
at the bottom of the screen, the pulls it in editing the
target screen.)

>
>Andy Valencia
>Home page: https://www.vsta.org/andy/
>To contact me: https://www.vsta.org/contact/andy.html

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

In article <2023Mar12.092557@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>
>Makes me wonder if the non-reading BUFFER is just a too-complex
>interface, or if I just used the wrong source material to learn it
>(Ronald Zech's book was my primary source for learning Forth).

It comes from the old times hardware capabilities.
This was the time only IBM had 8" floppies, not available and
certainly not affordable.
Allocating a buffer for block 1000 with no previous content saves the
time spooling the tape to nearly the end. Arie Kattenberg had a block
system working on the digital Philips micro cassette recorder, that
was accessable by block number, relatively fast, but what matters
more, you had not position a tape recorder by hand.
This strategy saves you a ton of waiting time.
Imagine you working on a project with 8 blocks. You can
work mostly in cache. Then you take a coffee break and
type FLUSH. I still posses that hardware.

In ciforth I have not bothered to change the original fig-forth
source, w.r.t allocation, that works fine.
For the WANT system I needed locking the block in memory,
and later I discovered that the buffers came in handy for
implementing a classical INCLUDE that works line-by-line.
In general I lock blocks, files and in this case buffers in
memory for interpreting the content.

I changed UPDATE to write with no delay. Delaying write does
not make sense for blocks allocated in files.
Editing blocks is rare. Maybe a user wants changing a
line in a preference block, or an address that is
different in Raspberry pi from 1 to 2.
That is much simpler in vi in overtype mode, just
take care not to change the line length.

>- anton

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

dxforth <dxforth@gmail.com> writes:
>On 12/03/2023 7:55 pm, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>>>> In Gforth BUFFER just calls BLOCK, and that reads.
>>>
>>> So that leaves multi-tasking as the only reason for ANS' requirement an
>>> interim buffer be used to copy a block. The simplified code posted would
>>> work on Gforth and majority of systems in use today?
>>
>> If you mean
>>
>> |: copy-block ( from to -- )
>> | swap block swap buffer 1024 move update ;
>>
>> from <tuhh4p$2dn7r$1@dont-email.me>, that would fail with Gforth for
>> certain values of from and to.
>
>Why - what's special about that code whereby certain values would fail?

Remember:

4 block hex. $5601034AB198 ok
68 block hex. $5601034AB198 ok

So if you use 4 68 COPY-BLOCK, $5601034AB198 will contain block 68 and
MOVE will see the same from and to addresses, so it will not do
anything. And the end result will be that block 68 will be unchanged.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

On Sunday, March 12, 2023 at 9:28:10 AM UTC-7, Anton Ertl wrote:
....
> >Why - what's special about that code whereby certain values would fail?
> Remember:
> 4 block hex. $5601034AB198 ok
> 68 block hex. $5601034AB198 ok
....

True, in gForth I find any two blocks or buffers with a separation divisible by 32 yield the same address. (32 being the number of buffers allocated.)
That makes utility copying quite risky without the interim buffer.
I did not anticipate that. Thanks!

On 13/03/2023 3:24 am, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>> On 12/03/2023 7:55 pm, Anton Ertl wrote:
>>> dxforth <dxforth@gmail.com> writes:
>>>>> In Gforth BUFFER just calls BLOCK, and that reads.
>>>>
>>>> So that leaves multi-tasking as the only reason for ANS' requirement an
>>>> interim buffer be used to copy a block. The simplified code posted would
>>>> work on Gforth and majority of systems in use today?
>>>
>>> If you mean
>>>
>>> |: copy-block ( from to -- )
>>> | swap block swap buffer 1024 move update ;
>>>
>>> from <tuhh4p$2dn7r$1@dont-email.me>, that would fail with Gforth for
>>> certain values of from and to.
>>
>> Why - what's special about that code whereby certain values would fail?
>
> Remember:
>
> 4 block hex. $5601034AB198 ok
> 68 block hex. $5601034AB198 ok
>
> So if you use 4 68 COPY-BLOCK, $5601034AB198 will contain block 68 and
> MOVE will see the same from and to addresses, so it will not do
> anything. And the end result will be that block 68 will be unchanged.

The problem surely is that you implemented BUFFER with BLOCK (arguably
contrary to ANS) and the latter reads. Even this wouldn't have been a
problem had you implemented a working LRU buffer selection scheme. It's
these two departures from convention in combination that causes Gforth
to fail - not copy-block.