Re: The correct code

Hi,

>Actually, ANS Forth is quite small once you consider that other languages
>depend up on huge libraries with dozens to hundreds of functions to call.

Yes, but as you know a lot of words are made of other words.
Thus, they are somewhat superfluous. Sometimes I think
removing them might even simplify programming.

But I wrote my remark more as a little provocation
in answer to the email of E. Rather - as
she referred to the Manual where ACTIVATE was explained.
It was a little provocation to me; because it happenend
I made errors and then I referred myself to the manuals
as to make them the culprit. So, now I think
she seized the opportunity to let me know I make little errors too.
It was just a little joke actually. ;) Partially at least. Because
removing superfluous commands might really still improve Forth.

>If you like, email me offline and I'll provide you with a list of resources
>you can check out. They have example programs, primers, tutorials, etc. I'd
>provide them here but I don't want to clutter the mailing list.

Well, I think I have nearly all the books about Forth.
Besides, I even wrote one myself (Forth from inside), it's only
in electronical form, it's an exercise book for beginners.
I wrote it for myself to have all the needed stuff at hand
to easily program in Forth. In teh beginning I used it a lot.
I guess the list of resources you refer to is the
Target site, isn't it?

Anyhow, if you have resources other than the Target site, and
with stuff that is not on the Target site, of course,
they are welcome.

BTW yesterday you suggested this:
>In your working code, you would make these small changes:

>: SEQBITFLASH BEGIN PAUSE ... code ... AGAIN ;
>
>After this is done, this action can be assigned to a TASK, so:

> TASK ACTIVATE SEQBITFLASH

This is OK, but thus, as I understand it, it should always be put in a colon
definition.
And a last thing I wanted to add is
I think it must always be put in the start-up word that will
come in GO in the App.f file, thus in our exemple in /TESTER
and immediately after TESTER BUILD.
I tried out the first piece of code you sent me yesterday, that is
the following:

: MYSTOP TESTER HALT ;

: SEQBITFLASH ( -- )
      1
        BEGIN PAUSE
        
          PORTB C@ 2DUP SWAP - AND
          PORTB C! 100 MS 2*
          PORTB C@ 127 = IF DROP 1 CR
                          THEN
           255 PORTB C! 100 MS
         AGAIN ; \ For in task TESTER

: WAITNOKEY ( -- )
  BEGIN PIND C@ 255 = UNTIL ;

: /TESTER ( -- )

     $FF DDRB C! \ Set PORTB as OUTPUT
     $FF PORTB C! \ set leds off at start up
     TESTER BUILD
        BEGIN PAUSE
            PIND C@ 254 = IF MYSTOP WAITNOKEY THEN
            PIND C@ 253 = IF TESTER ACTIVATE SEQBITFLASH WAITNOKEY THEN
        AGAIN ;

This code works fine. But I have the message "NO XTL port".
So it's not possible to test interactively.
That's why I think TESTER BUILD should always be immediately followed by
TESTER ACTIVATE.

Best greetings,
Viviane
----------------------------------------------------------------------
swiftx_at_forth.com The SwiftX programming discussion email list
To unsubscribe, send subject "unsubscribe" to swiftx-request_at_forth.com
For list command help, send subject "help" to swiftx-request_at_forth.com
Message archives are located at http://www.forth.com/archive/swiftx
----------------------------------------------------------------------
This list is a forum for SwiftX users. For product support and bug
reports, please send email to support_at_forth.com
----------------------------------------------------------------------
Received on Tue Aug 12 2003 - 01:11:16 PDT