Anfang der weitergeleiteten E-Mail:
> Von: Stephen Wille Padnos <[email protected]> > Datum: 06. Juni 2010 19:54:40 MESZ > An: Michael Haberler <[email protected]> > Betreff: Re: [Emc-developers] halmodule.cc enhancement: gets/getp/setp > methods added > > (this should go to the list, feel free to forward it) > > Michael Haberler wrote: >> ok, I'll cook up a list of python methods and intended usage which I'm going >> to add, and post that for review >> >> most of it is pretty clear to me (create / destroy signals,attach / detach >> pins to/from signals, >> get status information,walk pin/param/component/thread lists) >> >> I guess I'll go for returning lists of pins/params/components/threads >> >> -- >> >> this is a bit unclear to me: >> >> >>> load and unload components (halcmd doesn't really do this, it just uses >>> exec or emc_module_helper, depending) >>> >> If I do this without emc_module_helper, the script would need to run as >> root, right? >> > I think root would be necessary, yes. It's best to use emc_module_helper, > since that's what it's for :) >> what do you think of dropping the whole setp/sets/getp/gets thing and handle >> signals, pins and parameters as attributes? since hal really provides shared >> typed variables, that would look natural to me. >> >> like so: >> >> hal.signal_foo = 1 >> print hal.signal_bar >> > I don't know that this is a good idea. Remember that HAL is dynamic - pins, > signals, parameters, and components can change at any time. There is no > event system that could let python programs know that something has changed, > so I'm not sure how this property list would be maintained. Maintaining any > "private" information about HAL the configuration seems like a bad idea, > considering that it can change without warning o rnotification. >> if doing that - should I go for a structured namespace - like so: >> >> hal.signals.foo = 1 >> >> or even >> hal.components.usercomp23.signals.foo = 1 >> > I think it's best to use strings for everything: > hal.signals("foo") = 1 > myvar=hal.params("comp23.bar") > > (note that components don't own signals, so usercomp23.signals doesn't make a > lot of sense) >> or just flat, plus methods to determine the type? >> >> hal.typeof(hal.foo) ? >> > I'm not sure how to deal with types. Since HAL is strictly typed and python > isn't, it's a really good question. >> thanks for taking the time for sending your thoughts >> > It's the least I can do, considering you're the one doing the work :) > > - Steve > ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
