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 ;
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.
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!
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 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 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
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?
On 2023-03-11 03:01, dxforth wrote:program. This address becomes invalid after any next performing of 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 ;
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
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:
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.
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?
Using blocks is inherently more difficult than files, and any
newbies are strongly advised against using blocks, if files are
available.
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.
Not sure if this works on GForth but some older systems kept a cellThat'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
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 Saturday, March 11, 2023 at 2:02:34 PM UTC-6, Van Kichline wrote:Thanks! I did not have this, will dig into it.
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
: 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
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.
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.
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
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:In Gforth BUFFER just calls BLOCK, and that reads.
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?
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 ;
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:I will give this a try, thanks!
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
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?
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 ;
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
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.
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
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?
...Why - what's special about that code whereby certain values would fail? Remember:4 block hex. $5601034AB198 ok
68 block hex. $5601034AB198 ok
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 39:32:41 |
Calls: | 6,708 |
Calls today: | 1 |
Files: | 12,241 |
Messages: | 5,353,642 |