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

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

CATCH and THROW

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

Contents

  CATCH and THROW Mark Wills <markwills1970@gmail.com> - 2015-10-09 05:46 -0700
    Re: CATCH and THROW anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-09 16:05 +0000
      Re: CATCH and THROW "Elizabeth D. Rather" <erather@forth.com> - 2015-10-09 08:30 -1000
        Re: CATCH and THROW JennyB <jennybrien@googlemail.com> - 2015-10-09 12:19 -0700
          Re: CATCH and THROW Mark Wills <markwills1970@gmail.com> - 2015-10-09 12:30 -0700
    Re: CATCH and THROW "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-09 23:21 -0400
      Re: CATCH and THROW Paul Rubin <no.email@nospam.invalid> - 2015-10-09 20:37 -0700
      Re: CATCH and THROW Mark Wills <markwills1970@gmail.com> - 2015-10-10 01:16 -0700
        Re: CATCH and THROW Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-10-10 19:18 +0100
      Re: CATCH and THROW "HAA" <someone@microsoft.com> - 2015-10-11 12:18 +1000
        Re: CATCH and THROW hughaguilar96@gmail.com - 2015-10-10 23:21 -0700
          Re: CATCH and THROW rickman <gnuarm@gmail.com> - 2015-10-11 02:32 -0400
            Re: CATCH and THROW Paul Rubin <no.email@nospam.invalid> - 2015-10-10 23:51 -0700
              Re: CATCH and THROW rickman <gnuarm@gmail.com> - 2015-10-11 04:16 -0400
                Re: CATCH and THROW Paul Rubin <no.email@nospam.invalid> - 2015-10-11 23:27 -0700
                  Re: CATCH and THROW rickman <gnuarm@gmail.com> - 2015-10-12 02:39 -0400
                    Re: CATCH and THROW "Elizabeth D. Rather" <erather@forth.com> - 2015-10-11 21:26 -1000
                Re: CATCH and THROW "Elizabeth D. Rather" <erather@forth.com> - 2015-10-11 21:22 -1000
          Re: CATCH and THROW "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-12 01:29 -0400
            Re: CATCH and THROW rickman <gnuarm@gmail.com> - 2015-10-12 02:23 -0400
              Re: CATCH and THROW "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-12 19:52 -0400
                Re: CATCH and THROW rickman <gnuarm@gmail.com> - 2015-10-12 21:14 -0400
        Re: CATCH and THROW "Elizabeth D. Rather" <erather@forth.com> - 2015-10-10 21:19 -1000

Page 1 of 2  [1] 2  Next page →

#42493 — CATCH and THROW

I'm writing an article on my website about CATCH and THROW (finally got around to adding it to my system).

I have a lovely article that I clearly discovered ages ago, printed out, and forgot all about. I recently found it again which inspired me to add CATCH and THROW to my system. I'd like to include the text on my site, but with appropriate attribution. Therefore, if you know the origin of the following article (which I dictated with Dragon Naturally Speaking - what a God send of a program) then please let me know.

Get your sleuthing hats on!

Thanks

Mark

-----------------------------------------------

CATCH and THROW 

"Any action might fail. To keep a real-time system in continuous operation, the designer must be able to specify a recovery action to be taken as the effective replacement for the remainder of the action which was not successfully completed."
I.C. Pyle - "The ADA Programming Language" 1981. 



Many languages do not cater for exceptions at all. Those that do include Common Lisp, LOGO, ADA, and (I believe) C. As of ANSI pre-release report BASIS13, so does Forth, with the Error Handling Wordset (it should be called the Exception Handling Wordset).

This is a long overdue recognition of the simple fact that bears a good deal of repetition. Programs go wrong. Setting aside Goedel's Therorem and the 2nd law of thermodynamics there are understandable reasons for this. Programmers make mistakes. The amount of testing a program requires increases much faster than the size of the program. Specifications are incomplete. Programs have to interact with humans, a major source of fallibility. Hardware wears out. One in a million occurrences occur. The list is endless

A programmers focus is mostly on algorithms and data structures. Once these are understood a program can be made to run. This is the smallest part of programming. Turning a working program into a secure, reliable, stable program is the harder task. Too often this is underrated. One can use the best theories of structured programming, trapping erroneous input before it is used, apply rigourous testing and design specification systems such as SSADM and still a program will bomb out. Perhaps not straightaway, but it will.

Exceptions are a major problem. Those things that almost never happen, but when they do need special handling. Things like running out of space on disk. Or a valve failing on a piece of machinery, or a group of data items conspiring to make the top of stack zero just before attempting to divide. The trouble is that catering for these can turn an elegant program into a morass of flags and conditionals. And, given enough paths, you will take a wrong turn eventually. Correctness is especially important in process control. When a word processor trashes your hard disk it may cause heartache or expense, but when a plane tumbles from the sky it costs lives. I do not think this can be overstated.

When an exception occurs we need to detect it, executes an appropriate exception handling code and then continue the program. Of course we may not wish to continue from the same place that we left off. If we failed to open a file it would be silly to try to write to it. This may mean jumping out of a deeply nested subroutine to the word that initiated the file access, such as a menu very near the top level routine. This is where exception handling words such as CATCH and THROW useful.

CATCH takes the execution token (CFA) of a Forth word as an argument. It then executes this word. Assuming that the word THROW is not executed during the execution of this word, CATCH places a zero on top of the stack. This indicates that an exception did not arise during the execution of the word.

Throw takes a number N from the stack. If N is zero it does nothing. if then is nonzero it jumps out of subroutine after subroutine until it finds a CATCH. Once it has found a CATCH it adjusts the data stack and places the number and on the top, to indicate that an exception has occurred. The adjustment it makes to the data stack is this; it ensures that the same number of items are on the stack as before the CATCH was executed, not including the execution token that CATCH used. The value of any stack item that may have been altered between the CATCH and the THROW is unspecified and must be assumed to be invalid. Execution then continues just after the CATCH. Catches can be nested.

Throw's stack action may seem a little strange. In fact it is making the best of a bad job. It can't do nothing to the stack. The number of items on the stack would be unknown. It can't clear the stack. Obviously. Throw cannot know the stack action of the word that CATCH executes, but the programmer can. So it sets it to the depth that was before, and makes it the programmer's responsibility to drop any invalid items.

It is possible, but inappropriate, to make a distinction between system generated exceptions, such as divide by zero error and disk full error, and program detected exceptions, such as a valve failure. Both are equally damaging to a program. This suggests that CATCH and THROW should be incorporated into the heart of the Forth system. This is neat, as it means the default action of say, /MOD can be to abort with an error message if top of stack is zero, but the action can be altered by intercepting the THROW with a programmer defined CATCH. It also means that there be no need for a test in THROW for THROW without CATCH, as any THROW without a CATCH will be handled by the system CATCH.

CATCH and THROW are very unstructured, both in terms of flow control (i.e. the return stack) and data flow (i.e. the data stack). Therefore certain disciplines should be adopted in their use.

Firstly every exception should be uniquely identifiable. This means the number passed to THROW should be an exception number. For readability exception numbers should be defined as constants with meaningful names. Any CATCH, with the exception of the top level CATCH, should only perform one exception handling routine for one specified exception. If it receives an exception other than the specified one it should THROW it to the next level CATCH. Exception handling should be done by CATCH, never by THROW. This allows greater reusability of code. For the same reason throws should be done at the lowest possible level in the code, and catches at the highest, while still allowing a program to recover gracefully from an exception. CATCH and THROW should only be used where they are completely justifiable, and not just an easy way of jumping out of nested loops. Search your heart before using them.

A finished program should never invoke the system CATCH. It should report a serious system malfunction, give instructions to the user to contact the system designer and dump any information that may be useful in debugging. As a sweetener it should offer the user a temp and fault finders fee, claim the ball any contact the designer. This will also encourage the programmer to ensure that this error handler need never be invoked. I suggest that system exceptions be given negative numbers, and program to find one's positive numbers, to avoid conflict.

The implementation is highly system specific. For those with gemForth for the Atari ST the one given will work. Others will, I am afraid, have to figure it out for themselves. This version saves the data stack pointer on the return stack, and the return stack pointer in the variable 'CATCH. The previous value of 'CATCH is also stashed, to allow nesting. If there is no THROW, CATCH restores the variable and leaves a zero. Throw restores the return stack to just after the catch, using the value in 'CATCH, restores the 'CATCH to its former value and the data stack to its former depth. It leaves its argument on top of stack. That the definitions are very short means that there is no reason why any implementation of ANSI Forth should not include the error handling word set. Given its usefulness any Forth producer should be encouraged to include it. I shall certainly press for its inclusion in FANSI.

[toc] | [next] | [standalone]

#42514

Mark Wills <markwills1970@gmail.com> writes:
>I have a lovely article that I clearly discovered ages ago, printed out, an=
>d forgot all about. I recently found it again which inspired me to add CATC=
>H and THROW to my system. I'd like to include the text on my site, but with=
> appropriate attribution. Therefore, if you know the origin of the followin=
>g article (which I dictated with Dragon Naturally Speaking - what a God sen=
>d of a program) then please let me know.

My guess is that it was written by Mitch Bradley; ask him for
confirmation.

- 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]

#42519

On 10/9/15 6:05 AM, Anton Ertl wrote:
> Mark Wills <markwills1970@gmail.com> writes:
>> I have a lovely article that I clearly discovered ages ago, printed out, an=
>> d forgot all about. I recently found it again which inspired me to add CATC=
>> H and THROW to my system. I'd like to include the text on my site, but with=
>> appropriate attribution. Therefore, if you know the origin of the followin=
>> g article (which I dictated with Dragon Naturally Speaking - what a God sen=
>> d of a program) then please let me know.
>
> My guess is that it was written by Mitch Bradley; ask him for
> confirmation.

It's a nice article, but I doubt if it was written by Mitch due to the 
reference to gemForth for the Atari ST, which is not something that I 
think he used. Mitch had his own Forth, originally on Suns,n which was 
the basis for Open Firmware.

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]

#42523

On Friday, 9 October 2015 19:30:52 UTC+1, Elizabeth D. Rather  wrote:

> 
> It's a nice article, but I doubt if it was written by Mitch due to the 
> reference to gemForth for the Atari ST, which is not something that I 
> think he used. Mitch had his own Forth, originally on Suns,n which was 
> the basis for Open Firmware.
> 

Credit where it's due:

Gordon Charlton Forthwrite FigUK Issue 59 (April 1991)

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

#42524

Thank you very much Jenny!

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

#42537

On Fri, 09 Oct 2015 08:46:50 -0400, Mark Wills <markwills1970@gmail.com> wrote:

> I'm writing an article on my website about CATCH and THROW
>
> [...]
>
> CATCH and THROW
>
> [...]
>
>
> Many languages do not cater for exceptions at all.

Um, what are CATCH and THROW?  Why are they needed?
That should be explained before ever mentioning an
exception.  It appears I have to read half of this
to find out how CATCH and THROW are implemented, but
I still don't know what they're supposed to do by then ...

Are these like setjmp and longjmp in C?
Or, are they like signal?


Rod Pemberton

-- 
Just how many texting and calendar apps does humanity need?
Just how many food articles from neurotic millenials do we need?

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

#42538

"Rod Pemberton" <boo@fasdfrewar.cdm> writes:
> Are these like setjmp and longjmp in C?
> Or, are they like signal?

They are like setjmp and longjmp, sort of.  You pass an xt to catch and
you can throw a return value.  It's explained in the gforth manual and
presumably other places.

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

#42543

On Saturday, 10 October 2015 04:21:00 UTC+1, Rod Pemberton  wrote:
> On Fri, 09 Oct 2015 08:46:50 -0400, Mark Wills <markwills1970@gmail.com> wrote:
> 
> > I'm writing an article on my website about CATCH and THROW
> >
> > [...]
> >
> > CATCH and THROW
> >
> > [...]
> >
> >
> > Many languages do not cater for exceptions at all.
> 
> Um, what are CATCH and THROW?  Why are they needed?
> That should be explained before ever mentioning an
> exception.  It appears I have to read half of this
> to find out how CATCH and THROW are implemented, but
> I still don't know what they're supposed to do by then ...
> 
> Are these like setjmp and longjmp in C?
> Or, are they like signal?
> 
> 
> Rod Pemberton
> 
> -- 
> Just how many texting and calendar apps does humanity need?
> Just how many food articles from neurotic millenials do we need?

I'm writing my own article for my website. It'll be ready in a day or so.
You can be my proof-reader ;-)
I like the article, hence it'll also be included on site, since it was
the stimulus to prompt me to add CATCH & THROW.

Very simply:

: MightGoWrong SomeAction Error? IF 99 THROW THEN ;

: TryThing 
  ['] MightGoWrong CATCH DUP 99 = IF Disaster ELSE ?DUP IF THROW THEN THEN ;

So, TryThing executes MightGoWrong via CATCH. If a particular error happens,
we throw error code 99. Note: If no THROW is executed, CATCH adds a 0 to the
stack. After execution of MightGoWrong (we've either got 99 or 0 on TOS)
we test the error code. If it's 99 we call Disaster. If it's not 99, but
not 0, then we THROW it again (it will be caught by the next higher up
CATCH, which might be at the system level, which will do an ABORT, or
it might be at a higher level in your application). If it's 0 then all
is well and we continue.

I've written some syntactic sugar which makes it much nicer to use 
(especially for inexperienced Forth coders, which is basically everyone
that uses my particular system) but the above is CATCH and THROW in a
nutshell.

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

#42551

On 10/10/2015 09:16, Mark Wills wrote:
> Very simply:
>
> : MightGoWrong SomeAction Error? IF 99 THROW THEN ;
>
> : TryThing
>    ['] MightGoWrong CATCH DUP 99 = IF Disaster ELSE ?DUP IF THROW THEN THEN ;
>

TryThing can be simplified a bit to

: TryThing
     ['] MightGoWrong CATCH DUP 99 = IF Disaster ELSE THROW THEN ;

as 0 THROW is a noop.

-- 
Gerry

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

#42557

Rod Pemberton wrote:
>
> Um, what are CATCH and THROW?  Why are they needed?

It's for programmers who believe they know where a program
will go wrong.

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

#42564

On Saturday, October 10, 2015 at 6:19:09 PM UTC-7, HAA wrote:
> Rod Pemberton wrote:
> >
> > Um, what are CATCH and THROW?  Why are they needed?
> 
> It's for programmers who believe they know where a program
> will go wrong.

My only use for CATCH and THROW is to escape from a recursive-descent search when I have found the answer (cleaner than passing a flag up through every level indicating that the search is concluded) --- my LC53 encryption-cracking program does this.

I'm not impressed with using exceptions to handle problems because in most cases there is no way to solve the problem and continue as if the problem hadn't occurred --- the best you can do is get back to a safe place so the user can start over --- ABORT puts you back in the command-line (the QUIT outer-interpreter) which is a safe place to start over from, but in a turnkey program that provides a GUI rather than a command-line, some other safe place needs to be provided.

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

#42566

On 10/11/2015 2:21 AM, hughaguilar96@gmail.com wrote:
> On Saturday, October 10, 2015 at 6:19:09 PM UTC-7, HAA wrote:
>> Rod Pemberton wrote:
>>>
>>> Um, what are CATCH and THROW?  Why are they needed?
>>
>> It's for programmers who believe they know where a program
>> will go wrong.
>
> My only use for CATCH and THROW is to escape from a recursive-descent search when I have found the answer (cleaner than passing a flag up through every level indicating that the search is concluded) --- my LC53 encryption-cracking program does this.
>
> I'm not impressed with using exceptions to handle problems because in most cases there is no way to solve the problem and continue as if the problem hadn't occurred --- the best you can do is get back to a safe place so the user can start over --- ABORT puts you back in the command-line (the QUIT outer-interpreter) which is a safe place to start over from, but in a turnkey program that provides a GUI rather than a command-line, some other safe place needs to be provided.

I used CATCH and THROW to trap problems with serial comms.  If a 
response timed out or was received invalid, the CATCH/THROW mechanism 
allowed the code to more easily find its way back to either retrying the 
operation or exiting a section of code to a point where other action 
could be taken.  While ABORT puts you back to the command line, it also 
destroys all context of the problem as well as requiring the user to 
start over whatever was being done.  In my case it was a test procedure 
for a module.  Being able to repeat the test rather than aborting the 
test program was a life saver.

Eventually I found the problem which was not software.  But in the 
meantime it allowed the test functionality to be used if less than 
optimally efficient.

Trying to code this in more conventional flow control resulted in a mess 
of flag checking which made the stack data more complex as well as the 
code.

-- 

Rick

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

#42567

rickman <gnuarm@gmail.com> writes:
> If a response timed out or was received invalid, the CATCH/THROW
> mechanism allowed the code to more easily find its way back to either
> retrying the operation or exitingn....  Trying to code this in more
> conventional flow control resulted in a mess of flag checking

You could also do this with a multitasker.  In the error case, the
serial port task would send a message to the control task, then jump
back to the top of its own event loop.  This is usually cleaner when
there are asynchronous events and timeouts in a system.

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

#42569

On 10/11/2015 2:51 AM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> If a response timed out or was received invalid, the CATCH/THROW
>> mechanism allowed the code to more easily find its way back to either
>> retrying the operation or exitingn....  Trying to code this in more
>> conventional flow control resulted in a mess of flag checking
>
> You could also do this with a multitasker.  In the error case, the
> serial port task would send a message to the control task, then jump
> back to the top of its own event loop.  This is usually cleaner when
> there are asynchronous events and timeouts in a system.

Multitaskers may not be overly hard, but they are not trivial to design. 
  The serial data protocol is not async, it is command/response.  The 
timeout is waiting for a "valid" reply.  The incoming message is parsed 
and if it is not correctly formatted, especially if it is not terminated 
by the newline, it is not treated as received.

Even if a multitasker is used, this doesn't really help to cut through 
the messy error handling in the many words involved.  You still need to 
code handling the error condition in the many words of serial protocol 
task as well as handling it in every word called in the control task.

The position in the higher level code (control "task") gives insight to 
the nature of the problem and how to handle the failure, but lower level 
words detect the error while handling the protocol.  So the CATCH/THROW 
connection is the most expedient way to get from low level error to high 
level handler.

I wish I had considered error detection and handling when the code was 
first written, but I didn't know about CATCH/THROW then.  I only learned 
about it after I had the explicit need.  The kind folks here gave me a 
few pointers and much advice.

-- 

Rick

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

#42588

rickman <gnuarm@gmail.com> writes:
> Multitaskers may not be overly hard, but they are not trivial to
> design. The serial data protocol is not async, it is command/response.
> The timeout is waiting for a "valid" reply.

It sounds async in the sense that a command is sent and the other device
replies some unpredictable time later.  Yeah I wouldn't write a
multitasker just for the sake of something like that, but if the Forth
you were using already had multitasking, it's just another approach you
could use.  Mostly just commenting on alternative ways to organize this
type of program.

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

#42590

On 10/12/2015 2:27 AM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> Multitaskers may not be overly hard, but they are not trivial to
>> design. The serial data protocol is not async, it is command/response.
>> The timeout is waiting for a "valid" reply.
>
> It sounds async in the sense that a command is sent and the other device
> replies some unpredictable time later.  Yeah I wouldn't write a
> multitasker just for the sake of something like that, but if the Forth
> you were using already had multitasking, it's just another approach you
> could use.  Mostly just commenting on alternative ways to organize this
> type of program.

The response delay is not significant to the functioning of the 
software.  In reality that delay is actually very predictable as it 
comes from a hardware process and the only variability is in the 
synchronization with the clock, approximately <= 40 ns.

I get the purpose of the comment.  I just don't agree with it.  I think 
using a multitasker doesn't address the issues in error recovery.  The 
problem I had was that it greatly complicates the control flow. 
CATCH/THROW simplifies this somewhat.  Multitasking is orthogonal to the 
issue.

-- 

Rick

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

#42593

On 10/11/15 8:39 PM, rickman wrote:
> On 10/12/2015 2:27 AM, Paul Rubin wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> Multitaskers may not be overly hard, but they are not trivial to
>>> design. The serial data protocol is not async, it is command/response.
>>> The timeout is waiting for a "valid" reply.
>>
>> It sounds async in the sense that a command is sent and the other device
>> replies some unpredictable time later.  Yeah I wouldn't write a
>> multitasker just for the sake of something like that, but if the Forth
>> you were using already had multitasking, it's just another approach you
>> could use.  Mostly just commenting on alternative ways to organize this
>> type of program.
>
> The response delay is not significant to the functioning of the
> software.  In reality that delay is actually very predictable as it
> comes from a hardware process and the only variability is in the
> synchronization with the clock, approximately <= 40 ns.
>
> I get the purpose of the comment.  I just don't agree with it.  I think
> using a multitasker doesn't address the issues in error recovery.  The
> problem I had was that it greatly complicates the control flow.
> CATCH/THROW simplifies this somewhat.  Multitasking is orthogonal to the
> issue.
>

I agree that multitasking isn't really relevant to the use of 
CATCH/THROW. I have used it in Forths with many tasks and with only one.

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]

#42592

On 10/10/15 10:16 PM, rickman wrote:
> On 10/11/2015 2:51 AM, Paul Rubin wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> If a response timed out or was received invalid, the CATCH/THROW
>>> mechanism allowed the code to more easily find its way back to either
>>> retrying the operation or exitingn....  Trying to code this in more
>>> conventional flow control resulted in a mess of flag checking
>>
>> You could also do this with a multitasker.  In the error case, the
>> serial port task would send a message to the control task, then jump
>> back to the top of its own event loop.  This is usually cleaner when
>> there are asynchronous events and timeouts in a system.
>
> Multitaskers may not be overly hard, but they are not trivial to design.
>   The serial data protocol is not async, it is command/response.  The
> timeout is waiting for a "valid" reply.  The incoming message is parsed
> and if it is not correctly formatted, especially if it is not terminated
> by the newline, it is not treated as received.
>
> Even if a multitasker is used, this doesn't really help to cut through
> the messy error handling in the many words involved.  You still need to
> code handling the error condition in the many words of serial protocol
> task as well as handling it in every word called in the control task.
>
> The position in the higher level code (control "task") gives insight to
> the nature of the problem and how to handle the failure, but lower level
> words detect the error while handling the protocol.  So the CATCH/THROW
> connection is the most expedient way to get from low level error to high
> level handler.

Every Forth I've ever used since 1971 has had a multitasker. Designs 
have evolved in detail over the years, but the basic principles of 
Chuck's design have been solid. Like all Chuck's designs, his 
multitaskers are quite different from conventional computer-science 
designs (simpler, smaller, and faster), but are rock solid and have been 
utterly reliable in challenging real-time applications with lifetimes of 
10 years or more. The basic principles of the SwiftOS Multitasker are 
described in Forth Application Techniques.

> I wish I had considered error detection and handling when the code was
> first written, but I didn't know about CATCH/THROW then.  I only learned
> about it after I had the explicit need.  The kind folks here gave me a
> few pointers and much advice.

It's really quite powerful, and one of the best innovations in Forth94.

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]

#42586

On Sun, 11 Oct 2015 02:21:06 -0400, <hughaguilar96@gmail.com> wrote:

> my LC53 encryption-cracking program does this.
>

Aren't you an U.S. citizen?

Cracking is illegal under the DMCA.

You need to have authority granted to
you from the copyright holder of LC53.
Even though that is you, you might
want to put it in writing just in
case they don't believe you ...


Rod Pemberton


-- 
Just how many texting and calendar apps does humanity need?
Just how many food articles from neurotic millenials do we need?

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

#42587

On 10/12/2015 1:29 AM, Rod Pemberton wrote:
> On Sun, 11 Oct 2015 02:21:06 -0400, <hughaguilar96@gmail.com> wrote:
>
>> my LC53 encryption-cracking program does this.
>>
>
> Aren't you an U.S. citizen?
>
> Cracking is illegal under the DMCA.
>
> You need to have authority granted to
> you from the copyright holder of LC53.
> Even though that is you, you might
> want to put it in writing just in
> case they don't believe you ...

Cracking encryption is not illegal under the DMCA.  Cracking encryption 
used to protect copyright is illegal.

-- 

Rick

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web