@nm In your second example, there is nothing special about the use of _self; you can replace it with, say, self, and it behaves the same.

My hand-waving as to why the failure occurred is presumably inaccurate. However, consider the following method added to your object:

export foo :: static := proc(_self)
    proc(self :: person) self:-age end proc(_self);
end proc;

That raises more-or-less the same error when the object class is created.  The anonymous procedure is not a local/export of the object and so has no access to the objects locals.  Maybe it should, but currently Maple's objects don't work like.  On the other hand, that isn't consistent with your use of overload (where the overloaded procedures can access the object locals).  My speculation is that overload has not yet been extended to handle the special case of the _self formal parameter.

@Carl Love A reasonable point. I speculate that it came about because the special nature of _self was introduced after objects.  That may also be why it is best used without a type declaration, that is, if _self as a formal parameter is given a type declaration it then behaves like an ordinary parameter.

@dharr A more efficient way to sort is to use the 'key' option:

sort(vecs, 'key' = (v -> LinearAlgebra:-Norm(v,2))):

That way the key (norm, in this case) is only computed once for each vector.

@Ash Niazi What commands did you execute?  Describing or uploading what you have done or want to do would be helpful.  It's not clear what you mean by "solving a State Space".

@maple_linux Apologies for the delay, didn't see your response until now.  The better way to handle this is with the Maple mint utility.  It can be invoked as a standalone procedure or via the maplemint procedure.  Note that because maplemint processes an assigned Maple procedure, rather than the text that defines the procedure, its reporting of implicitly declared variables is not as nice as mint's.

Using the following modification to your example

test_2 := proc()
    y1 := sin(x1);
    y2 := cos(z1) + z2^2;
    plot(y1, x1=1..2, color = "red");
end proc:

mint reports

Procedure test_2() on lines 1 to 5
  These names were used as global names but were not declared:  color, x1, z1, 
      z2
  These local variables were assigned a value, but otherwise unused:  y2
  These local variables were not declared explicitly:  y1, y2

while maplemint prints

maplemint(test_2);

Warning, (in test_2) `y1` is implicitly declared local
Warning, (in test_2) `y2` is implicitly declared local
Procedure test_2() 
  These names were used as global names but were not declared:  color, x1, z1, 
      z2
  These local variables were assigned a value, but otherwise unused:  y2

@mgmcderm Thanks for posting the worksheet, that is helpful.  A few comments.

Syrup actually solves the symbolic case, but doesn't recognize the solution as valid because it is in an unexpected form, a piecewise.  I'll fix that.  However, the solution is not particularly useful. 

You can pass the dontsolve option to Syrup:-Solve; it then returns a list of two sets: the equations and the solving variables. Those can then be manipulated as you wish. 

(eqs,vars) := op(Syrup:-solve(ckt, 'ac', 'dontsolve', 'symbolic'):
solve(eqs, vars) assuming R1 > 0;    # example

Passing them directly to Maple's solve procedure, maybe with additional assumptions may be useful.  For example, using assuming R1 > 0 removes one of the branches.  By using dontsolve you can enter placeholders in component values, then make any desired substitutions after extracting the equations and variables.

Am surprised that using ifelse in the value of the current source worked; Maple generally prefers piecewise, but in this case that returns no solution.

A refactoring of the expression yields results.  Change ifelse(v[2]>Vclamp,(v[2]-Vclamp)/Rclamp+ileak,ileak) to the equivalent max(v[2]-VClamp,0)/RClamp + ileak, then passing the symbolic option returns a result (multiple solutions).

Note that using conditionals dependent on circuit values with an ac analysis doesn't necessarily make sense; the ac analysis assumes linearity which may be violated by the conditions.

From the help page for coeffs:
Note that p must be collected (collect) with respect to the appropriate indeterminates.  For multivariate polynomials, you may need to use collect with `distributed`.

@Thomas Dean Note also,
 

(**) plot(sin);
Error, plot driver not found
(**) restart;
(**) plot(sin);
plotting was not implemented by the application

What would you like it to do?  Essentially what  command-line Maple does in an xterm, that is, pop open a plot window with the displayed plot?

@Thomas Dean Interesting.  I can reproduce the issue here.  Have probably never attempted a plot using the maple interface from emacs. Will look into it when I get some time.

What have you tried?  You can post a worksheet here; use the green up-arrow when responding.  The DynamicSystems package has commands that can simulate a linear state-space system with constant matrices.

@Preben Alsholm Thanks. Had to stare at that and the original for a while to spot the difference.  Should have just pasted into Maple.

@acer A named procedure might be easier to remember than the knowledge that the sequence of local variables is the second operand of a Maple procedure expression.  On the other hand, I know where to look for the info and probably won't recall a new procedure name.

Am trying to figure out what your sure suggests.  Maybe that the returned sequence would also include any type declarations that should probably be elided.  For example,

foo := proc() local k :: integer; k; end proc:
op(2, eval(foo));
                              k::integer

@charlie_fcl That error message is a concern; it shouldn't be displaying %1 but the subset of global variables that Syrup uses (i, v, s, and t) that are assigned. Strange.

@TX My point is that switch1 is doing effectively nothing.  You can short it out and the operation of the circuit is precisely the same (other than the voltage across the current source, which isn't an issue). Another way to think about this is that an ideal current source has infinite impedance; adding a switch in series with it has no effect, the current just keeps flowing.

@rcorless They (procname and thisproc) should behave the same in a compiled procedure, I believe.  I originally missed the part where you used procname.