Re: memory usage in cmucl


josephoswaldgg@xxxxxxxxxxx wrote:
goose wrote:
josephoswaldgg@xxxxxxxxxxx wrote:


Man, this thread just gets more and more interesting :-)

The general way a state machine gets expressed *might* be something
like


*might* ? How do you normally do it?

"might" is my disclaimer, roughly meaning, "I spent about 15 minutes on
this, didn't code an implementation, and have no idea whether this
actually is a good syntax."


Fair enough; I kinda assumed that you had an idiomatic way
of doing this[1].

For the kind of parser originally posted, I would probably code it
directly in Lisp.
For more complex lexing, I would probably find a Common Lisp library
designed for that purpose; hopefully one that would be nicely designed
and carefully coded to produce fast execution. Yet another method is to
use a TAGBODY/GO structure like one might use in Fortran. Finally, if I
had a problem that really needed elaborate state machine
implementation, I would either find a library or spend more time
polishing my design.

I'm really just "learning via experience"; I thought it would be a good
exercise (I did see a recent thread on cll about state-machines but
decided to see if what I could come up with was any good at all).

<snipped>

I.e. a state machine consists of

1) state variables

Sure

2) state nodes, each of which has
- an action function which gets called when the state is "entered"

Not really needed; the most I'd use it for is diagnostics (which is why
I wrote a macro to define the state).

My design intent was to separate the "work getting done" from the logic
determining the "next state".

Well, I dunno ... the state-machine is, in and of itself, the logic one
tries to express. Seperating "work getting done" from logic should
be a combination of using a high-level-language and helper-functions.

<snipped>

4) a final state (or states?)

Only one. In a state machine having a number of different
end states makes as much sense as having a number of
different start states.

Some might wish to indicate errors or nonsensical conditions or a
variety of conditions (e.g. a lexer recognizing distinct productions:
"integer" is an end state, "symbol" is another, etc.) with a
distinguished state. Equivalently, one could make a state variable hold
an "error indicator" or "end condition" to be checked at termination.
Or simply return a value of the appropriate Lisp type.


My normal method (in C) is to have an error state which gets
entered anytime any error is found with the error itself being
recorded in a state variable. The error state will then do
whatever processing I require and set the next state to be
end.

Have only a single definitive end-state; errors (and other
states which need to exit early) go to error-state (which on
the diagram will *always* transition to end-state).

My state diagrams are easier for me to verify if I can grab
a pencil and trace the path through the machine and
*always* end up in the end-state (my main reason for
using a state machine is *because* I can easily verify that
a complicated process *always* ends, even if it ends due to
errors).

<snipped>


but other than that, I initially did something
similar using a class to hold the entire machine; I always got
lost when trying to reference states that were not yet declared
so I decided to use a defconstant for each state.

One could use a hash table or tables mapping symbols to the
corresponding nodes.

I'd like to do something that enables the simple:
(defparameter my-state
(make-state-machine
(make-state start (...))
(make-state state1 (...))
....
(make-state stateN (...))
(make-state end (...))))

The function that steps through each state (run-step my-state)
will return the symbol of each state (which we can test against
"end") and the function/macro (make-state-machine) will
set the state initially to start.

(Although that means that you must name the start state "start"
and the end state "end". I see no harm in this as failure to do
so will cause an error immediately, and not after the system
has been deployed).


I will maybe make another attempt and repost this weekend
if I get the time.

Enjoy.

I intended to, but on my only fee day I took the wife to the zoo
(where humans outside the cages make funny noises, faces
and antics at the animals sitting calmly, solemnly and civilised
*inside* the cages; the irony is sadly wasted on many visitors
to the zoo :-).


(btw: I still do not know why cmucl is giving me memory leaks on
the original code. Any ideas in that direction about how lisp code
can actually leak memory would be helpful)

I don't have great insight into CMUCL's internals, but I suspect the
use of EVAL could invoke the compiler; that might generate quite a bit
of garbage compared to CLISP's. Or the use of CONCATENATE on strings
might cause different GC behavior on the two implementations.

It probably isn't a true leak; one could try invoking a full GC to see
how much memory is actually being retained.

My only worry is that this is not a cmucl problem, but a problem
with my code; I suspected that I was doing something not kosher
that was causing the GC to never reclaim memory.

cheers
goose

.

Relevant Pages

  • Re: memory usage in cmucl
    ... I would probably find a Common Lisp library ... had a problem that really needed elaborate state machine ... in which case your transition function could return the ...
    (comp.lang.lisp)
  • Re: A Proper Lexer
    ... Common Lisp. ... e.g. if you can design it so that the little language has a space ... experimental packrat parser (which describes the construction of tokens and ... If you design it with a state machine macro - code executed ...
    (comp.lang.lisp)
  • Re: FSM single process...BIG question
    ... I used to design FSMs considering the issues of Mealy vs Moore, ... I was using some system with a state machine compiler. ... figured out that my design was somewhere between Mealy and Moore. ...
    (comp.arch.fpga)
  • Re: A Proper Lexer
    ... Common Lisp. ... e.g. if you can design it so that the little language has a space ... If you design it with a state machine macro - code executed ... get away with fully-backtracking parsers and a packrat parser with no ...
    (comp.lang.lisp)
  • Re: Can a low-level programmer learn OOP?
    ... if the priority is ease of programming. ... Let's talk about design versus implementation for a moment, ... look at a problem and convert it to a state machine, ... and languages with good OO support make this ...
    (comp.lang.python)