Hello Ray, I like to use MANPOWER. I am doing my research work on MANPOWER. I need more information regarding the Manpower manual. Thank You Regards, deepak
On Thu, Nov 3, 2022 at 8:05 PM Russ Patterson <r...@relayman.org> wrote: > Hi Ray, > > > > My preference would be to use your suggested package approach (and require > Octave 6.2.0 or later). Anyone who really needs and older version of > Octave is likely savy enough to run simultaneous versions without trouble. > > > > Best regards, > > russ > > > > *From:* bounce-126942489-88411...@list.cornell.edu < > bounce-126942489-88411...@list.cornell.edu> *On Behalf Of *Ray Daniel > Zimmerman > *Sent:* Wednesday, November 2, 2022 9:02 AM > *To:* MATPOWER-L <matpowe...@list.cornell.edu> > *Subject:* FEEDBACK REQUEST: Octave requirements for new MATPOWER > > > > Hi MATPOWER Users, > > > > I need your feedback on a quick question. > > > > I’m working on finalizing things for a beta release of what amounts to a > nearly complete re-write of MATPOWER for version 8.0. More on that soon. > > > > Since this new version defines tons of new classes, I thought it would be > nice to put them all inside a package, probably named mp or matpower, to > avoid namespace pollution. For those who don’t know, a package is simply a > folder whose name begins with a ‘+’, like ‘+mp’. If that folder is in > your path, any class inside it, such as myclass.m can be accessed as > mp.myclass. > > > > The issue is that, for Octave users, putting the new MATPOWER classes > inside a package will require Octave 6.2.0 (released Feb 2021) or later, > otherwise we could support Octave 5.2.0 (released Jan 2020) or later. > > > > *So the question for you MATPOWER/Octave users is …* > > > > *What is your preference?* > > A. Require Octave 6.2.0 or later and put the new classes in its own > package. *OR* > > B. Support Octave 5.2.0 and leave all of the new classes in the main > namespace. > > > > *And a secondary question, for anyone who has an opinion, is …* > > > > *Which is the better name for the package, should we choose to go that > route?* > > C. mp - short and convenient to use *OR* > > D. matpower - longer, but better at avoiding name collisions > > > > This is a major update with massive changes and my goal is to introduce a > framework that will provide a solid foundation for MATPOWER development for > years/decades to come. > > > > Any feedback or comments are appreciated. > > > > Thanks, > > > > Ray > > >
