Finites State Machine (OT?)

[Sander Vesik]

-----------------
And so you're his doting fellatrix?

No.

-------------------
So may he. So do I.
But which may still exclude the truth I mentioned on his part.

You see:
I don't HAVE to know everything to be smarter than YOU are.
Grasp set theory, over and against statistics you can't know.

Its not apparent you grasp much relevant to the group i'm reading
this from.

 

[R. Steve Walz]

Its not apparent you grasp much relevant to the group i'm reading
this from.

 

[Stephen Sprunk]

Pardon me, but what server do you have that has only one thread?

There's only one common implementation, ircd. The variant I've used is the
one for EFnet, but AFAIK all public networks use trivial patches to the same
common base.

And any given thing can block its particular system call, yes, but
your main loop dispatches the functions and rather than waiting for
a particular link in the chain, it can go ahead and do something
else, and just check back whenever it wants to try thing 1 again.

That's true for simpler operations like read() and write(), but others such
as gethostbyaddr() are pretty much guaranteed to block under any conditions
and no non-blocking versions are available. Even if everything were
non-blocking, you'd still need an FSM to be able to pick up where you left
off on the next pass through all the connections.

Or are you saying that a FSM is indistinguishable from a flowchart?

I've never seen an FSM that remotely looked like a flowchart.

S

 

[John S. Dyson]

comp sci students are cheap - all you need is a lecture theatre (uni's have
these) and a computer room (they have these too) and you can pump out
thousands of fee-paying "grads" every year.....there is a plague of these
people, and it probably goes some way to explaining the fact that modern
software is generally unreliable, bug-riddled shite.

Good and complex software often requires a significant emotional/intellectual
investment from the developers, and cookie cutter implementation of new
or non-trivial software is unrealistic. Creating cookie cutter software
developers who don't invest much of their selves into their work will
result in alot of sloppy, suboptimal, buggy, or less than desirable
quality software.

Non-trivial software does often require 'thinking', and that requires
investment from the 'thinker'. Spending 'time' on a project isn't
sufficient (or sometimes even necessary.) The old idea of 'working
smart, not hard' isn't 100% true, because 'working smart' can require
alot of effort -- but with the payoff of minimizing more brute force
work in the future.

Maybe one of the more important attributes would be that the programmer
enjoy the work, and be willing to intensely invest in the early phases
so as to mitigate needed brute force development and inefficient test/debug
cycles later on.

Development teams also have made the mistake of replacing careful
implementation and design with brute force 'test/debug' cycles. This
is even worse than violating the 'work smart, not hard*' rule. (Again,
the implication of working 'hard' is relative.) For quick programming
hack projects, the 'test/debug' cycle has been re-enforced by using
incredibly fast computers nowadays, but even in the trivial case, a
careful design can save lots of time.

John

 

[Rich Grise]

I learned about FSM as a 14-year-old kid, I had a friend who worked for NCR,
and him, me and my mate bruce networked our ataris thru the joystick port;
he was a failed comp sci student, and taught me and bruce much about program
design.

So, you're saying you learned about computers/state machines from a guy who
flunked?

Cheers!
Rich

 

[Peter Boyle]

Non-trivial software does often require 'thinking', and that requires
investment from the 'thinker'. Spending 'time' on a project isn't
sufficient (or sometimes even necessary.) The old idea of 'working
smart, not hard' isn't 100% true, because 'working smart' can require
alot of effort -- but with the payoff of minimizing more brute force
work in the future.

better yet "work smart _AND_ hard" (quality people in small quantities).

Peter Boyle

 

[Active8]

When a client first connects to a server, there are all sorts of things the
server must do before it allows the client to start chatting, such as
checking DNS, IDENT, and an optional username/password. Since the standard
ways to check these things are blocking and the server only has one thread,
an FSM is very useful. Here's a pseudocode example:

IDLE:
client connects
send DNS request
start timer
move to DNS_WAIT

DNS_WAIT:
if timer expires, move to DNS_ERROR, otherwise:
update client_info with DNS response
send IDENT request
start timer
move to IDENT_WAIT

IDENT_WAIT:
if timer expires, move to IDENT_ERROR, otherwise:
update client_info with IDENT response
if anonymous users allowed, move to USER_CONNECTED
else start timer and move to USER_WAIT

USER_WAIT:
if timer expires, move to USER_ERROR, otherwise:
update client_info with username
start timer
move to PASS_WAIT

PASS_WAIT:
if timer expires, move to USER_ERROR, otherwise:
if password correct, move to USER_CONNECTED
else restart timer and move to USER_WAIT

USER_CONNECTED:
if timer expires, move to INACTIVE_ERROR
if input rate exceeds threshhold, move to USER_FLOOD
if username received, update client_info, start timer, and move to PASS_WAIT
if OPER command received and valid, move to OPER_CONNECTED
parse one user-level command in input buffer
restart timer

USER_FLOOD
if input rate below threshold, move to USER_CONNECTED
else discard any input

OPER_CONNECTED
if MODE -o command received, restart timer and move to USER_CONNECTED
(operator returning to user status)
parse multiple user- or operator-level commands in input buffer

Obviously there are a number of error states referenced which I didn't give
pseudocode for, but they either terminate the connection (and move to IDLE)
or kick back an error and move to another state depending on the admin's
configuration.

S

Thanks. I see now. I forgot that I started a little chat program -
actually IM. In it's present state, you have to know the IP addy of
the recipient and the recipient gets the IP addy from the sender via
some method of the ActiveX control I used which should tell you that
my app is probably a microshaft dependant POS I was just toying
with an idea - starting with the basic crap and building from there
- IMing my girlfriend without having to worry about the whole world
knowing what we were going to be doing later

Maybe one day I'll check out some open source code. Nah... I'd
rather check her out

 

[Terry Given]

I once tried to debug a program that consisted of a single 3500-line
while loop that _would_ have been a state machine, if the programmer
had known what a state machine was.

sounds terrible. I bet you couldnt convince the programmer that it was a
state machine, and therefore can be analysed as such.....

Terry

 

[Jeffrey C. Dege]

It is, however, very frustrating arguing with people with limited technical
education, when the problem is their lack of understanding of complex issues
(usually mathematical).

My particular beef is with people who invent their own "solutions"
to problems for which there are long-proven solutions.

--
"The national budget must be balanced. The public debt must be
reduced; the arrogance of the authorities must be moderated and
controlled. Payments to foreign governments must be reduced,
if the nation doesn't want to go bankrupt. People must again
learn to work, instead of living on public assistance."
- Marcus Tullius Cicero

 

[John S. Dyson]

My particular beef is with people who invent their own "solutions"
to problems for which there are long-proven solutions.

Some invention can be useful -- but I agree that too often a 'new engineer'
will reinvent techniques that have been long ago originated. The few
times that I have 'really' innovated, I had to do long patent searches
to make sure that I didnt' stomp on someone else (making sure that my
design wouldn't cause problems.) FreeBSD has one of those semi-innovations,
where I had to do alot of research to make sure that there wasn't
a problem. (If being done for a large company, I would have probably
had to patent the design.)

John

 

[John Larkin]

My particular beef is with people who invent their own "solutions"
to problems for which there are long-proven solutions.

But new circuits are fun! I try to never copy anybody's old designs,
including my own.

John

 

[Sir Charles W. Shults III]

But new circuits are fun! I try to never copy anybody's old designs,
including my own.

Exactly! And you are far less likely to run into copyright or patent
problems that way.

 

[John S. Dyson]

Exactly! And you are far less likely to run into copyright or patent
problems that way.

All too often an 'invention' is a 're-invention' and too often
conflicting with previous patents. Of course, trying to clean
room a design does help with copyright. (Ignorance of a
patent shouldn't give amnesty for a violation... Well, there
are too many 'obvious' patents, but ignore that.)

John

 

[john jakson]

------------------------
That's merely your disingenuous lie.


------------------------
I AM among the prefects, you insipid little shit-mind!

(here since 1992)

-Steve

No Steve, you a big fat TURD, go flush yourself!

 

[Stephen Sprunk]

No Steve, you a big fat TURD, go flush yourself!

Boys, can you please at least _pretend_ to be professionals before we're all
forced to killfile you?

S

 

[Terry Given]

I don't see how you could possibly teach a compiler class without
either covering, or requiring as prerequisite, finite automata and
state machines.

I do - in an attempt to boost student numbers, and hence government funding.
If that is the objective, then producing useful, skilled grads is NOT, so
who cares if they dont know about FA/FSM? Besides, arent compilers written
with compiler compilers nowadays.....

I learned about FSM as a 14-year-old kid, I had a friend who worked for NCR,
and him, me and my mate bruce networked our ataris thru the joystick port;
he was a failed comp sci student, and taught me and bruce much about program
design.

I also "learned" them at uni, although they were covered only briefly in
comp sci. Digital electronics papers covered them in detail, as expected (As
a kid, I tried repeatedly to design a DRAM controller for 4116's (pinched
from a dead defender pcb, using 3 supplies - +5V, -5V, +12V IIRC) but
couldnt, as I didnt understand FSM. I got David Comer's appropriately titled
book, and off I went. Eventually, my DRAM controller actually worked, but it
took me about 3 years to make it so)

And I don't see how a degree in Comp Sci could not include classes in
compiler technology and context-free grammars.

comp sci students are cheap - all you need is a lecture theatre (uni's have
these) and a computer room (they have these too) and you can pump out
thousands of fee-paying "grads" every year.....there is a plague of these
people, and it probably goes some way to explaining the fact that modern
software is generally unreliable, bug-riddled shite.

Terry

 

[R. Steve Walz]

No Steve, you a big fat TURD, go flush yourself!

 

[Terry Given]

So, you're saying you learned about computers/state machines from a guy who
flunked?

Cheers!
Rich

Why yes, I did indeed (at the ripe old age of 14). He flunked because (his
explanation) he was too busy writing software to bother with uni. He called
them ASMs though. But the networking software worked, and bruce and I
certainly upskilled a lot.

I have worked with a number of uni grads - BE, ME, PhD - and have found the
degree is not a valid predictor of ability. Ultimately, a degree proves
conclusively that you met the minimum standards required to get it, and
proves bugger all else. Most of the dreadful design problems I have posted
to s.e.d. have been the result of 2 people, one ME (MIT) the other PhD
(MIT), neither of whom deserve the title engineer.

Conversely I have worked with a number of technicians, some without any
formal training whatsoever, who have been highly skilled (about half of them
have since obtained BE's and become very good design engineers). In general,
those with degrees tend to have better mathematical skills than those
without. This is not necessarily important though, as maths alone rarely
leads to novel solutions - inspiration/perspiration usually does that.

It is, however, very frustrating arguing with people with limited technical
education, when the problem is their lack of understanding of complex issues
(usually mathematical). Try explaining pole placement to an electrician (pcb
layout guy), who insists that "220pF is too small" (in this case it was a
flyback compensation network re-design, to raise Fcross from 0.5Hz (yes,
0.5Hz - a moving coil meter would clearly show the transient response) to
abound 1kHz. I "won" the argument by pulling rank, and promising to endure
public humiliation if I was wrong).

The degree is most useful when it comes to getting your first job (those
without degrees tend to get filed in the "round" file). After that,
employment history tends to dominate. Although I have had a lot of success
in job interviews (one in particular) with pointing out design improvements
which can save money/improve reliability.

 

[Toon Moene]

Jeffrey C. Dege wrote:

Hmmm... Wy do I get the feeling that 'tried' is the operative word here?
:-(

"Real Programmers are not afraid of five-page-long do loops ..."

Hmmm, 3500 / 60 ~ 60

OK, I see your point.

 

[Rich Grise]

"Real Programmers are not afraid of five-page-long do loops ..."

Maybe not, but it sounds more like bravado to me. An _effective_
programmer keeps both ends of his loops on the same page.

Cheers!
Rich