Re: What is Forth best at?

On Mar 24, 4:26 am, "Bruce McFarling" <agil...@xxxxxxxxxxxx> wrote:
On Mar 24, 1:00 am, "rickman" <gnu...@xxxxxxxxx> wrote:

No, I mean you assume pretty much everything you said before.
You assume that the failure will be some weird situation that
can't be duplicated on a unit in the lab

If failures did not happen in the field, there wouldn't
be a need for field trials. You could go straight from the
States to a full roll-out in the field without field
trials.

that an interactive compiler or interpreter is the only
way of debugging the remote unit

I never once assumed any such thing. I always assumed that
there was another way of remotely debugging the unit.

and that the process of using the integrated interpreter
won't result in problems when the unit is fed something
wrong that is irrecoverable.

I don't see why the patch I write in C and upload is any
less likely to result in irrecoverable problems than the
patch I write in Forth and commit to flash after testing.

The two things being compared are not writing a patch to Flash in two
different languages. The things being compared are uploading an new
rev of code to a machine designed to accept code revs with a backup
mechanism to recover if the upload fails in some way, and a test
platform where a programmer is developing code on the fly and any sort
of mistake can be made which potentially can put the system in an
unrecoverable state. It has nothing to do with intentionally writing
to the Flash from Forth, it is the accident I am worried about.


012345678901234567890123456789012345678901234567890123456789
Indeed, since I'm liklier to test more boundary conditions,
and since most critical errors with the interpretor would
happen when the patch is still in RAM, I suspect that I
would be less likely. But I'm not the expert on that side
of it, you tell me ... why is my patch more likely to be
error free when it is a binary compiled from C than when
it is Forth code copied from the logs of the session with
the Forth of the remote unit.

Why are you more likely to test boundary conditions using Forth? If
you mean in the conditions of the field, then you are talking about
using the target as a debug platform and that carries a significant
risk of needing on-site human intervention.

The two cases you are comparing are not where I see the risk as I
state above.

Perhaps you have a way of developing code on the target that does not
carry the risk of putting the machine in an inoperable state?


If you have a remote unit that is in a factory or other
place where humans can get to it, then it does not matter
a lot what you do since they can always reboot or even
reload the code for you.

I'm a development economist with a research interest in
the use of decentralized credit, education, health,
transport and agricultural extension services to promote
development of the agrarian economy. What do I care about
which is the most effective solution on the factory floor?
How do I even get grant funding to study it if I develop
an interest in it?

I give up, how do you do that?


I was referring to a situation where you *need* a means
of uploading code because there is no human contact with
the remote.

No matter how remote the field station ... and it can't
be as remote as an spacecraft or I couldn't have installed
it on site, and it's got to be a PITA to get to it,
because the fact that its a PITA to get to is the point,
I still do not see why the patch I've written is more
secure than the source code I've uploaded. To me, the
shorter turnaround in testing what is going on inside
the unit makes it likely that the source code that is
uploaded is more secure.

Because you keep focusing on the patch *after* the risky development
on the remote target. It is the development process where you are
dealing with untested code.

Thinking about it for a bit, I can see where using the remote target
as a way to collect data on the problem might be a useful feature. I
have not seen many cases where the target was being exposed to
unexpected stimulus. More often it was just a matter of the full
range of expected stimulus not being tested beforehand. Regardless,
this is likely to be identified more rapidly if the target system can
describe what has happened. But this advantage has to be weighed
against the extra risk of using the target as a development platform.
If that risk is too high or the consequences too severe, then this
facility should be left out of a remote system.

.

Relevant Pages

  • Re: What is Forth best at?
    ... be a need for field trials. ... I don't see why the patch I write in C and upload is any ... patch I write in Forth and commit to flash after testing. ... the Forth of the remote unit. ...
    (comp.lang.forth)
  • Re: Blank screen after logging into RWW
    ... You cannot connect to a remote computer or start a remote application when ... From a good working workstation in the network you should be able to ... If I go to RWW from the LAN, ... computer and/or the computer attempting to gain access to the target ...
    (microsoft.public.windows.server.sbs)
  • Re: More FYI
    ... Checkpoint patch developed and made available – 2/4/2004 ... > corporate networks for remote client computers. ... > A remote attacker may exploit this flaw to remotely compromise any VPN-1 ... Attackers will be able to run commands under the ...
    (comp.security.firewalls)
  • RE: WMI ExecQuery from Win32_NTEventLogFile in a Workgroup environ
    ... I thought that GetObjiect was where the target PC from which the query was ... "urkec" wrote: ... "dest" sets the base filepath where the script resides (eg. ... I have a script that runs on one node and copies files from all the remote ...
    (microsoft.public.scripting.vbscript)
  • Re: Problem with the System Cloning Tool
    ... I guess I still didn't explain it right :-) I have a development system and a target ... The target system is headless but I can connect to it from my development system ... So I'm looking for a tool like 'newsid' that I can run from a remote ...
    (microsoft.public.windowsxp.embedded)
Loading