I am new to Forth and just beginning to get serious. I an using gForth on Ubuntu for now. I want to use block files, and have found a nice little block editor: editb, which is working well but has no block file management functions. I've added Index, but really need to reorganize my block file.
Brodie says moving blocks is easy (at least for fig Forth) but I haven't found the way to load a block and write it to a different block number. Can anyone provide a hint?
Or, if there's somewhere I can look at the source of a more complete block editing environment, I may be able to figure it out for myself.
Any help appreciated, thanks!

I've found an answer, but I think it can be greatly simplified:
: copy-block ( from to -- )
block swap block
1024 0 do
2dup i + swap i + swap
dup C@ rot C! drop
loop 2drop ;

On 11/03/2023 11:56 am, Van Kichline wrote:
> I've found an answer, but I think it can be greatly simplified:
> : copy-block ( from to -- )
> block swap block
> 1024 0 do
> 2dup i + swap i + swap
> dup C@ rot C! drop
> loop 2drop ;

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

(assumes more than one block buffer)

On 11/03/2023 1:56 pm, dxforth wrote:
>
> : copy-block ( from to -- )
>    buffer swap block swap 1024 move update ;

Incorrect. Should be:

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

On Friday, March 10, 2023 at 7:01:32 PM UTC-8, dxforth wrote:
…
Thanks! That’s considerably simpler! I have a lot to learn.

On Friday, March 10, 2023 at 10:24:34 PM UTC-5, Van Kichline wrote:
> On Friday, March 10, 2023 at 7:01:32 PM UTC-8, dxforth wrote:
> …
> Thanks! That’s considerably simpler! I have a lot to learn.

Not sure if this works on GForth but some older systems kept a cell
just before the buffer address that contained the block number
and the update flag. This was how HsForth did it.

In those systems copy was:

: COPY ( from to -- ) FLUSH SWAP BLOCK CELL- ! UPDATE ;

Quite clever and even simpler.

On 11/03/2023 4:46 pm, Brian Fox wrote:
> On Friday, March 10, 2023 at 10:24:34 PM UTC-5, Van Kichline wrote:
>> On Friday, March 10, 2023 at 7:01:32 PM UTC-8, dxforth wrote:
>> …
>> Thanks! That’s considerably simpler! I have a lot to learn.
>
> Not sure if this works on GForth but some older systems kept a cell
> just before the buffer address that contained the block number
> and the update flag. This was how HsForth did it.
>
> In those systems copy was:
>
> : COPY ( from to -- ) FLUSH SWAP BLOCK CELL- ! UPDATE ;
>
> Quite clever and even simpler.

Looking at COPY from a screen editor I notice UPDATE was followed by
SAVE-BUFFERS. That ensures the data gets written to disk instead of
trusting it will.

This was the code for COPIES. Today it seems clumsy. Perhaps someone
can do better.

\ Copy u3 screens from screen u1 to u2
: COPIES ( u1 u2 u3 -- )
?dup if
swap 2 pick - >r over +
r@ 0< if swap 1 else 1- -1 then
r> 2swap do i 2dup + copy over +loop
then 2drop ;

On 2023-03-11 03:01, dxforth wrote:
> On 11/03/2023 1:56 pm, dxforth wrote:
>>
>> : copy-block ( from to -- )
>>     buffer swap block swap 1024 move update ;
>
> Incorrect.  Should be:
>
> : copy-block ( from to -- )
>     swap block swap buffer 1024 move update ;
>

It's a system specific solution (both variants are correct to the same
extent).

The address of a block buffer returned by BLOCK or BUFFER is transient,
with very weak guarantees by the standard to a program. This address
becomes invalid after any next performing of BLOCK, BUFFER, LIST, or
LOAD, parsing, displaying characters, etc, — see 7.3.2 Block buffer
regions [1].

The standard allows a system to implement even only one buffer for blocks.

So, a standard compliant solution is to use a separate temporary buffer:

1024 buffer: tmp

: copy-block ( u.block-from u.block-to -- )
swap block tmp 1024 move
tmp swap buffer 1024 move
update
save-buffers \ it's optional
;

"save-buffers" is optional since the system shall save to the HDD an
updated buffer before reuse it anyway.

[1] https://forth-standard.org/standard/block#block:buffers

--
Ruvim

Van Kichline schrieb am Samstag, 11. März 2023 um 00:35:28 UTC+1:
> I am new to Forth and just beginning to get serious. I an using gForth on Ubuntu for now. I want to use block files, and have found a nice little block editor: editb, which is working well but has no block file management functions. I've added Index, but really need to reorganize my block file.
> Brodie says moving blocks is easy (at least for fig Forth) but I haven't found the way to load a block and write it to a different block number. Can anyone provide a hint?
> Or, if there's somewhere I can look at the source of a more complete block editing environment, I may be able to figure it out for myself.
> Any help appreciated, thanks!

Once upon a time blocks had been invented to map whole disk sectors to memory
and process them there. Efficient during its time, but rather awkward today IMO.

Most OS-based Forths like gforth have moved on to sequential text files. So unless
you have specific reasons, consider converting your blockfile to a text file and use
your favourite text editor for restructuring and editing.

On 11/03/2023 7:23 pm, Ruvim wrote:
> On 2023-03-11 03:01, dxforth wrote:
>> On 11/03/2023 1:56 pm, dxforth wrote:
>>>
>>> : copy-block ( from to -- )
>>>     buffer swap block swap 1024 move update ;
>>
>> Incorrect.  Should be:
>>
>> : copy-block ( from to -- )
>>      swap block swap buffer 1024 move update ;
>>
>
> It's a system specific solution (both variants are correct to the same extent).
>
>
> The address of a block buffer returned by BLOCK or BUFFER is transient, with very weak guarantees by the standard to a program. This address becomes invalid after any next performing of BLOCK, BUFFER

That's depressing. Any idea what might cause the address/contents of BLOCK to
become invalid when BUFFER is executed?

dxforth <dxforth@gmail.com> writes:
>On 11/03/2023 1:56 pm, dxforth wrote:
>>
>> : copy-block ( from to -- )
>>    buffer swap block swap 1024 move update ;
>
>Incorrect. Should be:
>
>: copy-block ( from to -- )
> swap block swap buffer 1024 move update ;

Note:

|A call to BLOCK or BUFFER may render a previously-obtained
|block-buffer address invalid, as may a call to any word that:
[lots of other cases elided]

So a standard COPY-BLOCK should copy from the BLOCK to an intermediate
buffer, and only then call BUFFER and copy the data to the resulting
address.

Is this just a theoretical concern? No:

1) The first implementation of blocks in Gforth used just one block
buffer, so COPY-BLOCK would never work.

2) This implementation was replaced with one that currently uses 32
bufferes, so COPY-BLOCK works as intended in many cases, but
insidiously not in all cases: It chooses only one of the buffers for a
given block. In particular, if the block number of the two involved blocks modulo 32 is the same, you get the same buffer:

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

If you want to copy between two blocks that use the same
buffer, COPY-BLOCK will not work as intended.

Yes, one can consider this behaviour to signify a low quality of
implementation of the blocks wordset, or maybe that the standard is
not tight enough. But it seems to me that blocks these days cater to
a small minority, they know the quality of the blocks implementations
they use, and know how to work around their quirks. That's probably
why nobody has even discussed tightening the standard in this respect,
and IIRC nobody has asked for a higher-quality implementation in
Gforth. It's also not clear how such a tightening of the standard
would look like given multi-tasking Forth systems.

- 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:
>> The address of a block buffer returned by BLOCK or BUFFER is transient, with very weak guarantees by the standard to a program. This address becomes invalid after any next performing of BLOCK, BUFFER
>
>That's depressing. Any idea what might cause the address/contents of BLOCK to
>become invalid when BUFFER is executed?

1) If BUFFER needs a buffer and chooses the same one (e.g., in Gforth
even without multi-tasking).

2) (In a classical Forth system:) If BUFFER chooses a buffer that
contains a (different) UPDATEd block, performs I/O to save the
contents of that buffer to disk before giving it back as buffer for
the passed block number. Now, while the classical Forth system waits
for I/O to do it's work, it switches to a different task, which may
perform, e.g., one or more BUFFER operations, one of which might
choose the buffer that contains the block the original task loaded
with BLOCK.

- 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

In article <tuhh4p$2dn7r$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:
>On 11/03/2023 7:23 pm, Ruvim wrote:
>> On 2023-03-11 03:01, dxforth wrote:
>>> On 11/03/2023 1:56 pm, dxforth wrote:
>>>>
>>>> : copy-block ( from to -- )
>>>>     buffer swap block swap 1024 move update ;
>>>
>>> Incorrect.  Should be:
>>>
>>> : copy-block ( from to -- )
>>>      swap block swap buffer 1024 move update ;
>>>
>>
>> It's a system specific solution (both variants are correct to the same extent).
>>
>>
>> The address of a block buffer returned by BLOCK or BUFFER is transient, with very weak guarantees by the standard to a
>program. This address becomes invalid after any next performing of BLOCK, BUFFER
>
>That's depressing. Any idea what might cause the address/contents of BLOCK to
>become invalid when BUFFER is executed?
>

BUFFER was renamed into (BUFFER) in ciforth from FIGForth.
It is worthy of the round brackets, because it is an internal word.
--------------------

() Return the address addr of a buffer assigned to identification n ,
probably a block number. Block numbers are positive, so a negative
value can be used for a buffer that is used for some other purpose.
The buffer layout is as follows: a cell with n, a cell with the
status, and the content of length B/BUF . The status is negative for
locked. The l.s.b. gives zero for free and one for valid data. The
block is not read from the disc. The buffer is either one that was
already assigned, or else a free buffer. If there is none free, some
non-locked buffer is freed. The contents of that buffer is written to
the disc, if it was marked as updated. In ciforth this will never
happen, because updated blocks are written immediately. In ciforth
blocks can be locked, and locked buffers are never freed by (BUFFER) .
An update flag would somehow be multiplexed with the lock count, but
it is not needed in this ciforth. If all buffers were locked, (BUFFER)
throws exception 48.
-------------
The description suggest that you don't need the word unless you want
to mess with the internals of FORTH.

\ Copy block one to block two.
: C-S SWAP BLOCK SWAP BLOCK B/BUF CMOVE UPDATE ;
This requires that you have at least two block buffers.
Any content made before to other blocks, is at risk of
being lost, unless you do UPDATE diligently.
You must understand that BLOCK is a cache for a disk or a
file. So after any change to a block in memory you should
say UPDATE to notify that it is to be written to disk in
at a convenient time.

You have a wrong understanding of BLOCK if you ask that the address or
content has changed. You have only control over blocks via the UPDATE.
You can only change a block immediately after obtaining the address of
the block. In other words you have no business worrying about address
or content of blocks!

Using blocks is inherently more difficult than files, and any
newbies are strongly advised against using blocks, if files are
available.

I use blocks in lina (and am chastized for it!) but actually I
use it as a read only library, never changing blocks, never using
blocks for application source code, inserting blocks using external
tools, and never using block numbers, not even if symbolically
defined.

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 -

On 11/03/2023 8:56 pm, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>> The address of a block buffer returned by BLOCK or BUFFER is transient, with very weak guarantees by the standard to a program. This address becomes invalid after any next performing of BLOCK, BUFFER
>>
>> That's depressing. Any idea what might cause the address/contents of BLOCK to
>> become invalid when BUFFER is executed?
>
> 1) If BUFFER needs a buffer and chooses the same one (e.g., in Gforth
> even without multi-tasking).

BUFFER doesn't read. How would the contents change?

> 2) (In a classical Forth system:) If BUFFER chooses a buffer that
> contains a (different) UPDATEd block, performs I/O to save the
> contents of that buffer to disk before giving it back as buffer for
> the passed block number. Now, while the classical Forth system waits
> for I/O to do it's work, it switches to a different task, which may
> perform, e.g., one or more BUFFER operations, one of which might
> choose the buffer that contains the block the original task loaded
> with BLOCK.

That's likely it. Reading the polyForth manual it only guarantees contents
between BLOCK ... UPDATE and BUFFER ... UPDATE provided no word that does
I/O is executed. Apparently PF comes with a function BLOCKS that copies a
range of blocks. Presumably it's multi-tasking friendly.

dxforth <dxforth@gmail.com> writes:
>On 11/03/2023 8:56 pm, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>>>> The address of a block buffer returned by BLOCK or BUFFER is transient, with very weak guarantees by the standard to a program. This address becomes invalid after any next performing of BLOCK, BUFFER
>>>
>>> That's depressing. Any idea what might cause the address/contents of BLOCK to
>>> become invalid when BUFFER is executed?
>>
>> 1) If BUFFER needs a buffer and chooses the same one (e.g., in Gforth
>> even without multi-tasking).
>
>BUFFER doesn't read. How would the contents change?

In Gforth BUFFER just calls BLOCK, and that reads.

- 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 11/03/2023 9:38 pm, albert wrote:
>
> Using blocks is inherently more difficult than files, and any
> newbies are strongly advised against using blocks, if files are
> available.

The Standard makes the writing of programs difficult by postulating
a hypothetical least common denominator. It's much easier writing
for a real system.

Anton Ertl schrieb am Samstag, 11. März 2023 um 12:23:03 UTC+1:
> dxforth <dxf...@gmail.com> writes:
> >On 11/03/2023 8:56 pm, Anton Ertl wrote:
> >> dxforth <dxf...@gmail.com> writes:
> >>>> The address of a block buffer returned by BLOCK or BUFFER is transient, with very weak guarantees by the standard to a program. This address becomes invalid after any next performing of BLOCK, BUFFER
> >>>
> >>> That's depressing. Any idea what might cause the address/contents of BLOCK to
> >>> become invalid when BUFFER is executed?
> >>
> >> 1) If BUFFER needs a buffer and chooses the same one (e.g., in Gforth
> >> even without multi-tasking).
> >
> >BUFFER doesn't read. How would the contents change?
> 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 ;

On Friday, March 10, 2023 at 9:46:37 PM UTC-8, Brian Fox wrote:
> Not sure if this works on GForth but some older systems kept a cell
> just before the buffer address that contained the block number
> and the update flag. This was how HsForth did it.
>
> In those systems copy was:
>
> : COPY ( from to -- ) FLUSH SWAP BLOCK CELL- ! UPDATE ;
>
> Quite clever and even simpler.
That's what I (almost) recalled, from looking at a FIG Forth editor some time back which I can no longer locate. I scoured the gForth docs for any mention of such organization, but found none. In general the docs didn't touch on implementation, so it may be so, but it doesn't seem safe to assume. Thanks for clarifying that, though.

On Saturday, March 11, 2023 at 2:02:34 PM UTC-6, Van Kichline wrote:

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 use Vim editor for my
everyday editing needs. Of course the Fig editor is not going to
compete with that but I make point to use blocks and the simple editor
where I can.

It seems blocks are of little interest to the standard community. You
may be better served by looking at original block code to see how
they worked. You can get copy of a DOS FigForth in below link.
The Fig editor is also contained in the zip.

https://archives.scovetta.com/pub/power_programming/FORTH/FIG_4TH.ZIP
--
me

On Saturday, March 11, 2023 at 12:11:16 PM UTC-8, S Jack wrote:
> On Saturday, March 11, 2023 at 2:02:34 PM UTC-6, Van Kichline wrote:
>
> 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 use Vim editor for my
> everyday editing needs. Of course the Fig editor is not going to
> compete with that but I make point to use blocks and the simple editor
> where I can.
>
> It seems blocks are of little interest to the standard community. You
> may be better served by looking at original block code to see how
> they worked. You can get copy of a DOS FigForth in below link.
> The Fig editor is also contained in the zip.
>
> https://archives.scovetta.com/pub/power_programming/FORTH/FIG_4TH.ZIP
> --
> me
Thanks! I did not have this, will dig into it.

On Saturday, March 11, 2023 at 12:23:43 AM UTC-8, Ruvim wrote:
....
> : copy-block ( u.block-from u.block-to -- )
> swap block tmp 1024 move
> tmp swap buffer 1024 move
> update
> save-buffers \ it's optional
> ;
....
> Ruvim

Thanks! While I have plenty of buffers on hand now, I am aiming for embedded systems in the future and this may help me prevent issues a year or two down the road.
After relying on search engines for doing Forth research for a month, posting here and getting excellent feedback has been a delight!

On Saturday, March 11, 2023 at 3:11:16 PM UTC-5, S Jack wrote:
> On Saturday, March 11, 2023 at 2:02:34 PM UTC-6, Van Kichline wrote:
>
> 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 use Vim editor for my
> everyday editing needs. Of course the Fig editor is not going to
> compete with that but I make point to use blocks and the simple editor
> where I can.

Not sure if this is of any interest to you but I took a run at adding more
VI features to Sam Falvo's VIBE editor for blocks.

The code is here:
https://github.com/bfox9900/VIBE99/blob/main/src/VIBE9980.FTH

The preamble at the top conditionally loads a bunch of stuff because
my iteration of Camel Forth is just 8K, mostly CORE.
(NEEDS FROM is my way to make a tiny conditional compilation tool)

It might not be too tough to port it to another system however.

The biggest not portable part is the copy buffer called TEMP.
TEMP uses video RAM. If you changed TEMP to a BUFFER:
and replace VREAD and VWRITE with MOVE it would be
closer to ready for a conventional Forth system. (no promises)
And replace VTYPE with TYPE.

If nothing else it's beginning to create what you like in VI for blocks.
I can't go much farther with 24K of RAM for code. :-)))

On 11/03/2023 10:17 pm, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>> On 11/03/2023 8:56 pm, Anton Ertl wrote:
>>> dxforth <dxforth@gmail.com> writes:
>>>>> The address of a block buffer returned by BLOCK or BUFFER is transient, with very weak guarantees by the standard to a program. This address becomes invalid after any next performing of BLOCK, BUFFER
>>>>
>>>> That's depressing. Any idea what might cause the address/contents of BLOCK to
>>>> become invalid when BUFFER is executed?
>>>
>>> 1) If BUFFER needs a buffer and chooses the same one (e.g., in Gforth
>>> even without multi-tasking).
>>
>> BUFFER doesn't read. How would the contents change?
>
> 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?

On 12/03/2023 7:11 am, S Jack wrote:
> On Saturday, March 11, 2023 at 2:02:34 PM UTC-6, Van Kichline wrote:
>
> 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 use Vim editor for my
> everyday editing needs. Of course the Fig editor is not going to
> compete with that but I make point to use blocks and the simple editor
> where I can.
>
> It seems blocks are of little interest to the standard community. You
> may be better served by looking at original block code to see how
> they worked. You can get copy of a DOS FigForth in below link.
> The Fig editor is also contained in the zip.
>
> https://archives.scovetta.com/pub/power_programming/FORTH/FIG_4TH.ZIP

When editing screens some way to insert/delete blocks comes in handy.
Not sure how many systems support that.

On 12/03/2023 6:02 am, minf...@arcor.de wrote:
> Anton Ertl schrieb am Samstag, 11. März 2023 um 12:23:03 UTC+1:
>> dxforth <dxf...@gmail.com> writes:
>>> On 11/03/2023 8:56 pm, Anton Ertl wrote:
>>>> dxforth <dxf...@gmail.com> writes:
>>>>>> The address of a block buffer returned by BLOCK or BUFFER is transient, with very weak guarantees by the standard to a program. This address becomes invalid after any next performing of BLOCK, BUFFER
>>>>>
>>>>> That's depressing. Any idea what might cause the address/contents of BLOCK to
>>>>> become invalid when BUFFER is executed?
>>>>
>>>> 1) If BUFFER needs a buffer and chooses the same one (e.g., in Gforth
>>>> even without multi-tasking).
>>>
>>> BUFFER doesn't read. How would the contents change?
>> 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 ;

Gforth it's defined : BUFFER BLOCK ;

Since BLOCK contains the functionality of BUFFER it begs the question why
not factor it out as tradition and everyone else has done.