Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #43883 > unrolled thread

Ann: ANS/FORTH 2012 test suite update

Back to article view | Back to comp.lang.forth

Contents

  Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-27 20:06 +0000
    Re: Ann: ANS/FORTH 2012 test suite update Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-11-27 22:19 -0800
    Re: Ann: ANS/FORTH 2012 test suite update peter.m.falth@gmail.com - 2015-11-28 10:07 -0800
      Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-29 10:13 +0000
      Re: Ann: ANS/FORTH 2012 test suite update "steve@srpalmer.me.uk" <steverpalmer27@gmail.com> - 2015-11-29 03:47 -0800
        Re: Ann: ANS/FORTH 2012 test suite update Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-29 12:41 +0000
        Re: Ann: ANS/FORTH 2012 test suite update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-29 12:41 +0000
        Re: Ann: ANS/FORTH 2012 test suite update peter.m.falth@gmail.com - 2015-11-29 08:41 -0800
          Re: Ann: ANS/FORTH 2012 test suite update peter.m.falth@gmail.com - 2015-11-29 10:47 -0800
            Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-29 20:29 +0000
              Re: Ann: ANS/FORTH 2012 test suite update peter.m.falth@gmail.com - 2015-11-29 14:44 -0800
                Re: Ann: ANS/FORTH 2012 test suite update Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-30 01:24 +0100
                  Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 09:35 +0000
                    Re: Ann: ANS/FORTH 2012 test suite update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-30 18:04 +0000
                      Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 21:28 +0000
                        Re: Ann: ANS/FORTH 2012 test suite update Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-30 22:59 +0100
                          Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-12-01 12:29 +0000
                        Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-12-02 10:08 +0000
                          Re: Ann: ANS/FORTH 2012 test suite update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-05 15:57 +0000
                Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 09:49 +0000
                  Re: Ann: ANS/FORTH 2012 test suite update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-30 18:16 +0000
                    Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 21:28 +0000
                Re: Ann: ANS/FORTH 2012 test suite update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 10:25 +0000
            Re: Ann: ANS/FORTH 2012 test suite update "Elizabeth D. Rather" <erather@forth.com> - 2015-11-29 13:14 -1000
            Re: Ann: ANS/FORTH 2012 test suite update steverpalmer27@gmail.com - 2015-11-30 03:51 -0800
              Re: Ann: ANS/FORTH 2012 test suite update peter.m.falth@gmail.com - 2015-11-30 09:00 -0800
                Re: Ann: ANS/FORTH 2012 test suite update "Elizabeth D. Rather" <erather@forth.com> - 2015-11-30 07:54 -1000
                  Re: Ann: ANS/FORTH 2012 test suite update Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-30 18:25 +0000
                    Re: Ann: ANS/FORTH 2012 test suite update "Elizabeth D. Rather" <erather@forth.com> - 2015-11-30 11:06 -1000
        Re: Ann: ANS/FORTH 2012 test suite update "Elizabeth D. Rather" <erather@forth.com> - 2015-11-29 13:08 -1000

Page 2 of 2 — ← Prev page 1 [2]

#43979

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> I could of course special-case NAME>INTERPRET to detect these and return 0
>> for them. But what would this add other then complication
>>
>
>For the implementer, not the user.

It would also complicate things for the users of his system, because
they would have to special-case 0 in their programs.  Of course, as
long as the standard allows NAME>INTERPRET to return 0, programmers
have to special-case that in standard programs, but if we can find
consensus on not needing 0 in the next version of the standard, even
standard programs can become simpler.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#43984

On 30/11/2015 18:16, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>>> I could of course special-case NAME>INTERPRET to detect these and return 0
>>> for them. But what would this add other then complication
>>>
>>
>> For the implementer, not the user.
>
> It would also complicate things for the users of his system, because
> they would have to special-case 0 in their programs.  Of course, as
> long as the standard allows NAME>INTERPRET to return 0, programmers
> have to special-case that in standard programs, but if we can find
> consensus on not needing 0 in the next version of the standard, even
> standard programs can become simpler.
>

These words have only recently been added to Forth 2012. Ever heard of 
'get it right first time'?

While we're discussing NAME>INTERPRET, wouldn't it have been better to 
have put it and friends like TRAVERSE-WORDLIST into the Search-Order 
word set because they requires that word set to be present to be usable. 
I ask this because we're trying to be stricter with the test suite and 
make the optional word set tests independent of each other, only relying 
on core words and that is impossible with these words in Programming tools.


-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#43965

On 29/11/2015 22:44, peter.m.falth@gmail.com wrote:
> The file I get the errors in is to-float-test.4th
>
> Here they are
>
> INCORRECT RESULT: t{  S"  9"   >FLOAT  ->   FALSE     }t    \ Leading space
> WRONG NUMBER OF FP RESULTS: t{  S"  9"   >FLOAT  ->   FALSE     }t    \ Leading space
> INCORRECT RESULT: t{  S" 9 "   >FLOAT  ->   FALSE     }t    \ Trailing space
> WRONG NUMBER OF FP RESULTS: t{  S" 9 "   >FLOAT  ->   FALSE     }t    \ Trailing space
>
>> >FLOAT is a way to read in FP numbers from different sources and is specified
> to allow different FP representations. It even allows a string of blanks to be
> interpreted as zero. A leading or trailing space should not disqualify it.
>

I agree. As I said before I didn't write the test. It looks like the 
author tested against the letter of the BNF specification for >FLOAT 
which says nothing about spaces. Section A.12.6.1.0558 states embedded 
spaces are explicitly forbidded so it depends on whether the term 
'embedded spaces' includes leading and trailing spaces. In plain English 
I would say not and agree with you that they should be permitted, 
particularly as that section also states that >FLOAT 'accepts a much 
broader syntax'.

If leading and trailing spaces can be accepted then the BNF 
specification needs to be modified in the standard document.

I'd appreciate other opinions on this. In the meantime just comment out 
the tests or ignore the errors.

> In my opinion the standard here describe the minimum that a system must
> deliver to be compliant. It can choose to do more. I allow also binary hex
> input like
>
> S" 0x1.1234ABCDp64" >FLOAT

That's definitely outside the standard and so won't be tested, you need 
your own test program for that.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#43950

On 11/29/15 8:47 AM, peter.m.falth@gmail.com wrote:
> On Sunday, 29 November 2015 17:41:19 UTC+1, peter....@gmail.com  wrote:
>> On Sunday, 29 November 2015 12:47:27 UTC+1, st...@srpalmer.me.uk  wrote:
>>> Hi Peter,
>>>
>>>> I found a problem.
>>>> You have changed COMPARE to STR= but you give a definition to S=
>>>> in the utilities file. STR= is used in 3 of the files so compilation stops
>>>
>>> Gerry is on this.  Thanks for reporting it.
>>>
>>>> Then I found several problems in my Forth when running the Block tests.
>>>> This is due to the way I implement Blocks. I simply do a memory mapping
>>>> of the blockfile and have it all in memory. For this reason I can set
>>>> : BUFFER  BLOCK ; and have no buffers at all. Any modification of a block
>>>> is handled by the operating system (Linux or Windows) and eventually
>>>> transferred to disk.
>>>>
>>>> For this reason I fail your tests when you UPDATE and then run EMPTY-BUFFERS
>>>> as the contents has already been written.
>>>> I need to think if I want to introduce a buffer to transfer each block thru
>>>> to pass your tests. I like the simplicity of the mapped file and it has
>>>> worked well for me for 20 years.
>>>
>>> Thanks for the feedback.  I checked the ANS standard regarding blocks and buffers and found the following relevant statements:
>>>
>>> Section 7.2 gives a definition of "block buffer: A block-sized region of data space where a block is made temporarily available for use. The current block buffer is the block buffer most recently accessed by BLOCK, BUFFER, LOAD, LIST, or THRU."
>>>
>>> Section 7.6.1.2400 gives the semantics of the word UPDATE, including the statement "Mark the current block buffer as modified. ... UPDATE does not immediately cause I/O."
>>>
>>> Section 7.6.2.1330 gives the semantics of the extension word EMPTY-BUFFERS, saying "Do not transfer the contents of any UPDATEd block buffer to mass
>>> storage."
>>>
>>> I've checked the wording in Release Candidate 3 of Forth 2012 [RC3] and the latest version I can find on-line and they are all the same.
>>>
>>> The Rationale section goes on to say and Blocks "Early Forth systems ran without a host OS; these are known as native systems. Such systems provide mass storage in blocks of 1024 bytes. The Block Word set includes the most common words for accessing program source and data on disk."  The Block word set operational model (as I interpret from the definitions above) is also trying to maintain consistency with native systems without advanced memory management hardware.  In particular, the forth system maintained a cache of buffers and the forth program had to indicate when a buffer had been changed (UPDATE) and when the changes where complete and so needed to be written back (FLUSH).
>>>
>>> It also provided the option of throwing away the changes using EMPTY-BUFFERS.  (I'm not sure how a Forth Program that used more than one buffer could know what was being thrown away, but there you go.)  The semantics indicated in the language standard specifically state that even UPDATEd blocks do not get written back if EMPTY-BUFFERS is called.
>>>
>>> Moving forwards to modern times with 32+ bit processors and hardware memory managers, I can quite understand the attraction of a memory mapped block file.  All changes are automatically captured and there is no need for UPDATE or FLUSH or others.  I suspect that it will make the life on real Forth Program using blocks to be much easier.  However, I don't think it is consistent with the language standard.
>>>
>>> To test compliance with the standard, (at around line 555) I write a block (UPDATEd and FLUSHed) to one value, then change it, UPDATE it, but then discard the changes using EMPTY-BUFFERS.  The expectation is that the block contains the first value, not the second.  I guess that this is (at least one of) the place where an error is being reported.  If I've misunderstood the standard, then obviously the test should be changed, but I think that this test is a fair reflection of, in particular, section 7.6.2.1330.
>>>
>>> You do ask a good question as to whether to change your current approach.  This will depend on your use cases.  I could easily be wrong, but I also get the impression that the Block word set is "falling out of fashion".  The ANS standard stated in section 3.2.5 that "A system need not provide any standard words for accessing mass storage. If a system provides any standard word for accessing mass storage, it shall also implement the Block word set."  RC3 has only the first statement and does not include the second statement, eliminating the need to provide at least the block word set.  I also struggle to see how the provided API could be used in a multitasking system, since the Forth Program can never now whether the address it has in the cache is still valid.  This problem disappears with a memory mapped block file.
>>>
>>> So a long answer, but basically:
>>>   1. I think that the tests are consistent with the language standard;
>>>   2. I can see the advantages of the memory mapped block file and you may choose usability over compliance.
>>>
>>> Thanks again,
>>> Steve
>>
>> Hi Steve,
>>
>> I share your analysis and think that my implementation failed when I updated
>> the block when modified but not marked updated.
>>
>> I have now implemented 1 buffer and pass all of the tests except one.
>> This is a bug on my side in save-input that was there all the time
>> (or seen now with 1 buffer)
>>
>> I found one problem that I think is an error in your test.
>> In TL7 (line 474) you test if there is only one buffer. if that is the case
>> you drop the parameters and push zeros and then exists. There is one drop
>> to much.
>>
>> I can see that you and Gerry have put in a lot of work on these tests.
>> They have really helped me create a better forth. A big thanks for your efforts
>>
>> BR
>> Peter
>
> Hi again Steve,
>
> I fixed my problem but did still not pass the test!
> Instead I found a problem in your test.
> In TCSIRIR4 at line 653 you shift to the next block to start writing to it
> but the old buffer is not updated so it will be overwritten and not committed
> to the disk. Inserting an UPDATE SAVE-BUFFERS solved this.

In a correctly-written BLOCK system SAVE-BUFFERS should not ever be 
necessary
except when you're about to power-down the system, because BLOCK should
automatically write an UPDATEd buffer when the buffer is about to be reused.
UPDATE *is* necessary if you have changed any block contents, though.

Cheers,
Elizabeth

> I now pass all the tests in the test suite except one.
>
> INCORRECT RESULT: \? T{ $" [']" FORTH-WORDLIST GET-NAME-TOKEN NAME>INTERPRET -> 0 }T
>
> But this I do not really consider a problem. Maybe this test should be deleted
>
> I also get 2 errors on the FP tests, but also these I think is OK.
> I allow an FP number to have leading or trailing blank chars where your
> tests does not.
>
> Again thanks to both Steve and Gerry for a very good work put into this test suite
>
> BR
> Peter
>


-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#43967

Hi Peter

Earlier you noted:

> > > I found one problem that I think is an error in your test.
> > In TL7 (line 474) you test if there is only one buffer. if that is the case
> > you drop the parameters and push zeros and then exists. There is one drop
> > to much.

And also:

> I fixed my problem but did still not pass the test!
> Instead I found a problem in your test.
> In TCSIRIR4 at line 653 you shift to the next block to start writing to it
> but the old buffer is not updated so it will be overwritten and not committed
> to the disk. Inserting an UPDATE SAVE-BUFFERS solved this.

On GitHub raised an issue (#7) to cover these faults.  You can see that I tried to take account of the single buffer case, but I neglected to test it.  My fault and apologies.

I've also created a branch on GitHub (fix/iss7) which I believe fixes these two faults along the lines that you have indicated.  I've now tested it against the single buffer case, a 4 buffer cache configuration and gforth and found no faults; the evidence attached to issue #7.

I've not addressed some of the other issues that have been raised on this discussion yet.  I think I want to wait for a little while.

I might raise a word of warning about having only a single buffer cache.  Suppose block 14 has the text:

    4 BLOCK 64 TYPE CR

If you now do 14 LOAD, you might expect this to display the first line of block 4, but it actually displays the first line of block 14.  (I've tried this on my forth with a single buffer and it does work this way.)  The reason is that as soon as the BLOCK word has finished, you go back to the interpreter which reloads block 14.  With a single buffer cache, this will overwrite block 4.  Of course, this curiosity may not be a problem for your use case, but I thought I'd mention it.

Cheers,
Steve

[toc] | [prev] | [next] | [standalone]

#43974

On Monday, 30 November 2015 12:51:44 UTC+1, steverp...@gmail.com  wrote:
> Hi Peter
> 
> Earlier you noted:
> 
> > > > I found one problem that I think is an error in your test.
> > > In TL7 (line 474) you test if there is only one buffer. if that is the case
> > > you drop the parameters and push zeros and then exists. There is one drop
> > > to much.
> 
> And also:
> 
> > I fixed my problem but did still not pass the test!
> > Instead I found a problem in your test.
> > In TCSIRIR4 at line 653 you shift to the next block to start writing to it
> > but the old buffer is not updated so it will be overwritten and not committed
> > to the disk. Inserting an UPDATE SAVE-BUFFERS solved this.
> 
> On GitHub raised an issue (#7) to cover these faults.  You can see that I tried to take account of the single buffer case, but I neglected to test it.  My fault and apologies.
> 
> I've also created a branch on GitHub (fix/iss7) which I believe fixes these two faults along the lines that you have indicated.  I've now tested it against the single buffer case, a 4 buffer cache configuration and gforth and found no faults; the evidence attached to issue #7.
> 
> I've not addressed some of the other issues that have been raised on this discussion yet.  I think I want to wait for a little while.
> 
> I might raise a word of warning about having only a single buffer cache.  Suppose block 14 has the text:
> 
>     4 BLOCK 64 TYPE CR
> 
> If you now do 14 LOAD, you might expect this to display the first line of block 4, but it actually displays the first line of block 14.  (I've tried this on my forth with a single buffer and it does work this way.)  The reason is that as soon as the BLOCK word has finished, you go back to the interpreter which reloads block 14.  With a single buffer cache, this will overwrite block 4.  Of course, this curiosity may not be a problem for your use case, but I thought I'd mention it.
> 
> Cheers,
> Steve

Hi Steve,

I do not see how block 14 would be reloaded, what is making that?
There is no refill or load going on. I would expect it to continue
executing on screen 4 at the position it was at (8).

I avoid this problem anyway by coping the screen to a source-buffer before
starting to interpret it. The example works as it should an type the first
line of block 4

BR
Peter

[toc] | [prev] | [next] | [standalone]

#43975

On 11/30/15 7:00 AM, peter.m.falth@gmail.com wrote:
> On Monday, 30 November 2015 12:51:44 UTC+1, steverp...@gmail.com  wrote:
>> Hi Peter
>>
>> Earlier you noted:
>>
>>>>> I found one problem that I think is an error in your test.
>>>> In TL7 (line 474) you test if there is only one buffer. if that is the case
>>>> you drop the parameters and push zeros and then exists. There is one drop
>>>> to much.
>>
>> And also:
>>
>>> I fixed my problem but did still not pass the test!
>>> Instead I found a problem in your test.
>>> In TCSIRIR4 at line 653 you shift to the next block to start writing to it
>>> but the old buffer is not updated so it will be overwritten and not committed
>>> to the disk. Inserting an UPDATE SAVE-BUFFERS solved this.
>>
>> On GitHub raised an issue (#7) to cover these faults.  You can see that I tried to take account of the single buffer case, but I neglected to test it.  My fault and apologies.
>>
>> I've also created a branch on GitHub (fix/iss7) which I believe fixes these two faults along the lines that you have indicated.  I've now tested it against the single buffer case, a 4 buffer cache configuration and gforth and found no faults; the evidence attached to issue #7.
>>
>> I've not addressed some of the other issues that have been raised on this discussion yet.  I think I want to wait for a little while.
>>
>> I might raise a word of warning about having only a single buffer cache.  Suppose block 14 has the text:
>>
>>      4 BLOCK 64 TYPE CR
>>
>> If you now do 14 LOAD, you might expect this to display the first line of block 4, but it actually displays the first line of block 14.  (I've tried this on my forth with a single buffer and it does work this way.)  The reason is that as soon as the BLOCK word has finished, you go back to the interpreter which reloads block 14.  With a single buffer cache, this will overwrite block 4.  Of course, this curiosity may not be a problem for your use case, but I thought I'd mention it.
>>
>> Cheers,
>> Steve

Steve, please try to keep your lines to 72 chars.
>
> Hi Steve,
>
> I do not see how block 14 would be reloaded, what is making that?

His text interpreter is working from Block 14, and therefore will 
restore it. If it did not, it would find itself interpreting whatever 
text or data or whatever is in Block 4. This is a good example of why 
nobody writes a one-block-buffer system. The only way to avoid this 
behavior would be to move the string to a temporary location before 
typing it. On multitasking systems, as a rule one avoids typing out of a 
block buffer, because another task might use your buffer (since your 
TYPE is performing I/O), so moving the string to a temporary buffer is 
common practice.

> There is no refill or load going on. I would expect it to continue
> executing on screen 4 at the position it was at (8).

Yes, when the interpreter is working in a block it has to do a refill 
for each word.

> I avoid this problem anyway by coping the screen to a source-buffer before
> starting to interpret it. The example works as it should an type the first
> line of block 4

Moving the block to interpret it is not common practice and the rules 
are such that it isn't necessary, but moving a string to be *typed* is 
appropriate in multitasked or one-buffer implementations.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#43980

"Elizabeth D. Rather" <erather@forth.com> writes:

>On 11/30/15 7:00 AM, peter.m.falth@gmail.com wrote:
>> On Monday, 30 November 2015 12:51:44 UTC+1, steverp...@gmail.com  wrote:
>>> Hi Peter
>>>
>>> Earlier you noted:
>>>
>>>>>> I found one problem that I think is an error in your test.
>>>>> In TL7 (line 474) you test if there is only one buffer. if that is the case
>>>>> you drop the parameters and push zeros and then exists. There is one drop
>>>>> to much.
>>>
>>> And also:
>>>
>>>> I fixed my problem but did still not pass the test!
>>>> Instead I found a problem in your test.
>>>> In TCSIRIR4 at line 653 you shift to the next block to start writing to it
>>>> but the old buffer is not updated so it will be overwritten and not committed
>>>> to the disk. Inserting an UPDATE SAVE-BUFFERS solved this.
>>>
>>> On GitHub raised an issue (#7) to cover these faults.  You can see that I tried to take account of the single buffer case, but I neglected to test it.  My fault and apologies.
>>>
>>> I've also created a branch on GitHub (fix/iss7) which I believe fixes these two faults along the lines that you have indicated.  I've now tested it against the single buffer case, a 4 buffer cache configuration and gforth and found no faults; the evidence attached to issue #7.
>>>
>>> I've not addressed some of the other issues that have been raised on this discussion yet.  I think I want to wait for a little while.
>>>
>>> I might raise a word of warning about having only a single buffer cache.  Suppose block 14 has the text:
>>>
>>>      4 BLOCK 64 TYPE CR
>>>
>>> If you now do 14 LOAD, you might expect this to display the first line of block 4, but it actually displays the first line of block 14.  (I've tried this on my forth with a single buffer and it does work this way.)  The reason is that as soon as the BLOCK word has finished, you go back to the interpreter which reloads block 14.  With a single buffer cache, this will overwrite block 4.  Of course, this curiosity may not be a problem for your use case, but I thought I'd mention it.
>>>
>>> Cheers,
>>> Steve

>Steve, please try to keep your lines to 72 chars.
>>
>> Hi Steve,
>>
>> I do not see how block 14 would be reloaded, what is making that?

>His text interpreter is working from Block 14, and therefore will
>restore it. If it did not, it would find itself interpreting whatever
>text or data or whatever is in Block 4. This is a good example of why
>nobody writes a one-block-buffer system. The only way to avoid this
>behavior would be to move the string to a temporary location before
>typing it. On multitasking systems, as a rule one avoids typing out of a
>block buffer, because another task might use your buffer (since your
>TYPE is performing I/O), so moving the string to a temporary buffer is
>common practice.

>> There is no refill or load going on. I would expect it to continue
>> executing on screen 4 at the position it was at (8).

>Yes, when the interpreter is working in a block it has to do a refill
>for each word.

>> I avoid this problem anyway by coping the screen to a source-buffer before
>> starting to interpret it. The example works as it should an type the first
>> line of block 4

>Moving the block to interpret it is not common practice and the rules
>are such that it isn't necessary, but moving a string to be *typed* is
>appropriate in multitasked or one-buffer implementations.

I've introduced a lock on blocks that are being used. Even if a block is
UPDATEd it is not a candidate for freeing until the lock is lifted.
So I don't have a problem with the typing of screen 4 from screen 14.
It is not clear whether this system would be ISO compliant.
I called it ciforth (close to ISO) for a reason. It is not productive
to go language-lwayering on subjects like this.

>Cheers,
>Elizabeth

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#43982

On 11/30/15 8:25 AM, Albert van der Horst wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>
>> On 11/30/15 7:00 AM, peter.m.falth@gmail.com wrote:
>>> On Monday, 30 November 2015 12:51:44 UTC+1, steverp...@gmail.com  wrote:
>>>> Hi Peter
>>>>
>>>> Earlier you noted:
>>>>
>>>>>>> I found one problem that I think is an error in your test.
>>>>>> In TL7 (line 474) you test if there is only one buffer. if that is the case
>>>>>> you drop the parameters and push zeros and then exists. There is one drop
>>>>>> to much.
>>>>
>>>> And also:
>>>>
>>>>> I fixed my problem but did still not pass the test!
>>>>> Instead I found a problem in your test.
>>>>> In TCSIRIR4 at line 653 you shift to the next block to start writing to it
>>>>> but the old buffer is not updated so it will be overwritten and not committed
>>>>> to the disk. Inserting an UPDATE SAVE-BUFFERS solved this.
>>>>
>>>> On GitHub raised an issue (#7) to cover these faults.  You can see that I tried to take account of the single buffer case, but I neglected to test it.  My fault and apologies.
>>>>
>>>> I've also created a branch on GitHub (fix/iss7) which I believe fixes these two faults along the lines that you have indicated.  I've now tested it against the single buffer case, a 4 buffer cache configuration and gforth and found no faults; the evidence attached to issue #7.
>>>>
>>>> I've not addressed some of the other issues that have been raised on this discussion yet.  I think I want to wait for a little while.
>>>>
>>>> I might raise a word of warning about having only a single buffer cache.  Suppose block 14 has the text:
>>>>
>>>>       4 BLOCK 64 TYPE CR
>>>>
>>>> If you now do 14 LOAD, you might expect this to display the first line of block 4, but it actually displays the first line of block 14.  (I've tried this on my forth with a single buffer and it does work this way.)  The reason is that as soon as the BLOCK word has finished, you go back to the interpreter which reloads block 14.  With a single buffer cache, this will overwrite block 4.  Of course, this curiosity may not be a problem for your use case, but I thought I'd mention it.
>>>>
>>>> Cheers,
>>>> Steve
>
>> Steve, please try to keep your lines to 72 chars.
>>>
>>> Hi Steve,
>>>
>>> I do not see how block 14 would be reloaded, what is making that?
>
>> His text interpreter is working from Block 14, and therefore will
>> restore it. If it did not, it would find itself interpreting whatever
>> text or data or whatever is in Block 4. This is a good example of why
>> nobody writes a one-block-buffer system. The only way to avoid this
>> behavior would be to move the string to a temporary location before
>> typing it. On multitasking systems, as a rule one avoids typing out of a
>> block buffer, because another task might use your buffer (since your
>> TYPE is performing I/O), so moving the string to a temporary buffer is
>> common practice.
>
>>> There is no refill or load going on. I would expect it to continue
>>> executing on screen 4 at the position it was at (8).
>
>> Yes, when the interpreter is working in a block it has to do a refill
>> for each word.
>
>>> I avoid this problem anyway by coping the screen to a source-buffer before
>>> starting to interpret it. The example works as it should an type the first
>>> line of block 4
>
>> Moving the block to interpret it is not common practice and the rules
>> are such that it isn't necessary, but moving a string to be *typed* is
>> appropriate in multitasked or one-buffer implementations.
>
> I've introduced a lock on blocks that are being used. Even if a block is
> UPDATEd it is not a candidate for freeing until the lock is lifted.
> So I don't have a problem with the typing of screen 4 from screen 14.
> It is not clear whether this system would be ISO compliant.
> I called it ciforth (close to ISO) for a reason. It is not productive
> to go language-lwayering on subjects like this.

I assume, then, you have more than one buffer, which is normal practice. 
Single-buffer implementations are just not practical.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#43948

On 11/29/15 1:47 AM, steve@srpalmer.me.uk wrote:
> Hi Peter,
>
>> I found a problem.
>> You have changed COMPARE to STR= but you give a definition to S=
>> in the utilities file. STR= is used in 3 of the files so compilation stops
>
> Gerry is on this.  Thanks for reporting it.
>
>> Then I found several problems in my Forth when running the Block tests.
>> This is due to the way I implement Blocks. I simply do a memory mapping
>> of the blockfile and have it all in memory. For this reason I can set
>> : BUFFER  BLOCK ; and have no buffers at all. Any modification of a block
>> is handled by the operating system (Linux or Windows) and eventually
>> transferred to disk.
>>
>> For this reason I fail your tests when you UPDATE and then run EMPTY-BUFFERS
>> as the contents has already been written.
>> I need to think if I want to introduce a buffer to transfer each block thru
>> to pass your tests. I like the simplicity of the mapped file and it has
>> worked well for me for 20 years.
>
> Thanks for the feedback.  I checked the ANS standard regarding blocks and
> buffers and found the following relevant statements:
>
> Section 7.2 gives a definition of "block buffer: A block-sized region of
> data space where a block is made temporarily available for use. The current
> block buffer is the block buffer most recently accessed by BLOCK, BUFFER,
> LOAD, LIST, or THRU."
>
> Section 7.6.1.2400 gives the semantics of the word UPDATE, including the
> statement "Mark the current block buffer as modified. ... UPDATE does not
> immediately cause I/O."
>
> Section 7.6.2.1330 gives the semantics of the extension word EMPTY-BUFFERS,
> saying "Do not transfer the contents of any UPDATEd block buffer to mass
> storage."
>
> I've checked the wording in Release Candidate 3 of Forth 2012 [RC3] and
> the latest version I can find on-line and they are all the same.
>
> The Rationale section goes on to say and Blocks "Early Forth systems ran
> without a host OS; these are known as native systems. Such systems provide
> mass storage in blocks of 1024 bytes. The Block Word set includes the most
> common words for accessing program source and data on disk." The Block word
> set operational model (as I interpret from the definitions above) is also
> trying to maintain consistency with native systems without advanced memory
> management hardware.  In particular, the forth system maintained a cache
> of buffers and the forth program had to indicate when a buffer had been
> changed (UPDATE) and when the changes where complete and so needed to be
> written back (FLUSH).
 >
> It also provided the option of throwing away the changes using EMPTY-BUFFERS.
> (I'm not sure how a Forth Program that used more than one buffer could know
> what was being thrown away, but there you go.)  The semantics indicated in
> the language standard specifically state that even UPDATEd blocks do not
> get written back if EMPTY-BUFFERS is called.

In the first place, there were virtually no systems with fewer than 2 block
buffers (I don't know of any). Each buffer had a "status" cell that 
contained
the block number of the block it currently contained. Its sign bit was 
set to
mark it updated. EMPTY-BUFFERS set all those status cells to zero, so there
is no longer any information as to what the buffer contained or whether it
had been changed.

This is not a word that is used often. The two principal occasions are:

* To "change your mind" after an edit and avoid having the mistake 
written to disk; and

* To force the system to read the next block from physical disk.

To understand the latter, you must understand that disk accesses are the 
most time-consuming thing going on in a system, even today. Modern OSs 
have huge disk caches to avoid too many disk accesses, but that was not 
always true, especially in a native Forth. Therefore, a correctly 
implemented block system will always check its buffers to see if a block 
is in memory before issuing a READ, and will write changed data only 
when an UPDATEd buffer needs to be used for a different block.

> Moving forwards to modern times with 32+ bit processors and hardware memory
> managers, I can quite understand the attraction of a memory mapped block
> file.  All changes are automatically captured and there is no need for UPDATE
> or FLUSH or others.  I suspect that it will make the life on real Forth
> Program using blocks to be much easier.  However, I don't think it is
> consistent with the language standard.

That depends on whether you always want your changes immediately made 
permanent. That may seem like an odd thing to worry about, but I can 
still recall occasions when, for example, I had just copied one block to 
another, and realized that the destination was the wrong block and one 
which I desperately did *not* want to overwrite! YMMV.

> To test compliance with the standard, (at around line 555) I write a block
> (UPDATEd and FLUSHed) to one value, then change it, UPDATE it, but then
> discard the changes using EMPTY-BUFFERS.  The expectation is that the block
> contains the first value, not the second.  I guess that this is (at least
> one of) the place where an error is being reported.  If I've misunderstood
> the standard, then obviously the test should be changed, but I think that
> this test is a fair reflection of, in particular, section 7.6.2.1330.

Yes, that sounds correct.

> You do ask a good question as to whether to change your current approach.
> This will depend on your use cases.  I could easily be wrong, but I also
> get the impression that the Block word set is "falling out of fashion".
> The ANS standard stated in section 3.2.5 that "A system need not provide
> any standard words for accessing mass storage. If a system provides any
> standard word for accessing mass storage, it shall also implement the
> Block word set."  RC3 has only the first statement and does not include
> the second statement, eliminating the need to provide at least the block
> word set.

At the time Forth94 was passed, there were still many block-based 
systems. This was an important entitlement for users in transition. Now 
20 years past, it's much less so. The main use for blocks nowadays 
involves flash, and the tradeoffs are rather different.

> I also struggle to see how the provided API could be used in
> a multitasking system, since the Forth Program can never now whether the
> address it has in the cache is still valid.  This problem disappears with
> a memory mapped block file.

In fact, they *always* acted like memory-mapped block files. If your 
program said 100 BLOCK then the word BLOCK would search the current 
buffers, and if 100 was there, return its address with no actual I/O 
taking place. Only if the requested block wasn't there would it do a 
READ. The better systems had algorithms to minimize disk accesses in 
that case, such as using the least-recently-accessed block's buffer. All 
tasks shared the same buffer pool. In your code, you never know  when 
physical access is taking place (unless you just did an 
EMPTY-BUFFERS--that is not a word to be used casually in a multitasked 
system!).

> So a long answer, but basically:
>   1. I think that the tests are consistent with the language standard;
>   2. I can see the advantages of the memory mapped block file and you may
> choose usability over compliance.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web