Re: [Hamlib-developer] Re: API suggestions

[Frank S. <vk...@ix...>]

Stephane Fillod wrote:


<snip>

> REM: the problem with xxxx_t cmd_get_xxx(RIG *rig) would be the
>      unability to check the return code.

I have seen in some circumstances the  use  of stuff like

struct ret_val {
	return_value;
	int validity_indicator;
}

struct ret_val *get_whatever(..)

So when you get a ptr to ret_val when returning
from the function, you can always check the
"data valid indicator" to see if there is a 
proper return_value, or if the indicator says,
an error occurred. 

Could we use this for setting and getting data ??

Or, pass &result into functions so that it may be set like

int rig_get_mode(RIG *rig, mode_t mode, int *result)

ie: rig_get_mode updates mode and result.

Comments ??

> 
> BTW, is the "_" in "cmd_set_xxx_" a typo ?

TYPO !! :-()

> 
> Also, I'm thinking that the "cmd_" prefix can generate some namespace
> clashes (well, no if the other objects is not dealing with vfo's
> and ham specific stuff :). Anyway, would it be better to have this:
> 
>         rig_set_mode(RIG *rig, rig_mode_t mode)
>         rig_set_vfo(RIG *rig, vfo_t vfo)
>         rig_set_freq(RIG *rig, freq_t freq)
>         rig_set_filter(RIG *rig, filter_t filter)
> 

Thats fine, I am glad we can agree before the API gets too big :-)

> Talking about namespace, I'd prefer to have mode_t instead of rig_mode_t.
> Should you see any concern?

mode_t looks good to me

> 
> About convenience functions like:
> >
> > cmd_set_channel_(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo
> > ....,,,, filter_t filter..)
> >
> > is some frontend convenience function that backend libs can handle
> > either directly as is toward the rig if the rig can handle it that way,
> > or the backend lib breaks it into the simpler functions shown above if
> > the rig needs it that way. We dont care up the front how its done
> > int the back of course (apart from efficiency issues of course)!
> >
> 
> In your previous mail, you were proposing that we can pass NULL
> parameters into the cmd_set for those things you
> dont want to change since previos command. Well, it depends
> on what your understanding of NULL. For instance, 0 can be meaningfull
> for the vfo_t type, etc.  (anyway, we can use -1)

I guess we should have a value that has no meaning in any other
context than indicating PARAM_NULL (-1 is a candidate of course).

But, using rig_set_mode(rig,mode) is maybe cleaner than
rig_set_channel(rig,NULL_PARAM, mode, NULL_PARAM, NULL_PARAM ..)


> > Ok, now I sleep better !!
> >
> 
> Sometimes, coding is like certain ham bands,
> it's only open at night :-)
> 

Yeah, I sometimes have bit too much D-layer absorbption
in the neural net sometimes.. :)

> --
> Stephane                                        F4CFE
>

Also, many times I get the following errors from your mail


    **********************************************
    **      THIS IS A WARNING MESSAGE ONLY      **
    **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
    **********************************************

The original message was received at Mon, 18 Sep 2000 11:18:14 +0200
from cismrelais.univ-lyon1.fr [134.214.101.250]

   ----- The following addresses had transient non-fatal errors -----
ste...@en...
    (expanded from: <ste...@in...>)


OR


    **********************************************
    **      THIS IS A WARNING MESSAGE ONLY      **
    **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
    **********************************************

The original message was received at Mon, 18 Sep 2000 07:59:37 +0200
from cismrelais.univ-lyon1.fr [134.214.101.250]

   ----- The following addresses had transient non-fatal errors -----
ste...@en...
    (expanded from: <ste...@in...>)

   ----- Transcript of session follows -----
... while talking to hotu.ens.insa-rennes.fr.:
>>> MAIL From:<vk...@ix...> SIZE=1811
<<< 451 <vk...@ix...>... Go away!
ste...@en...... Deferred: 451
<vk...@ix...>... Go away!
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old

So, you may have to check hamlib-developer instead ??

/Frank..
-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com