hamlib-developer

[Hamlib-developer] Kylix binding for Hamlib

[Francois R. <fgr...@su...>]

Hello All,

I committed a binding for Borland's Kylix to the CVS.

Included in the tests/ directory is a small demo/test program.
It can select a rigs and open a very primative frequency display
dialog box.  Will improve later..


One problem I found while testing the binding was that there is no
way to verify that a non-null rig pointer is pointing to a valid 
rig structure.  During testing I solved this by adding a magic 
numbers to the rig structure.

Thus instead of

	if (!rig || !rig->caps) {
		return -RIG_EINVAL;
	}

we also check the magic numbers.

	if (!rig || rig->magic != RIG_MAGIC) {
		return -RIG_EINVAL;
	}
	if (!rig->caps || rig->caps->magic != RIG_MAGIC_CAPS) {
		return -RIG_EINVAL;
	}

Should we add magic numbers to the rig structures?  I can submit 
a patch if there is a need.

-- 
Cheers
  Francois Retief

--
---------------------------------------------------------------------
Electronic Systems Laboratory (ESL)
University of Stellenbosch
South Africa
Tel. +27-21-808-4472

** Developers of the SUNSAT micro-satellite **
http://sunsat.ee.sun.ac.za

Re: [Hamlib-developer] Kylix binding for Hamlib

[Stephane F. <f4...@fr...>]

Quoting Francois Retief <fgr...@su...>:

> I committed a binding for Borland's Kylix to the CVS.

Great! I used to be a Turbo Pascal fan, from the 4.0 version and onwards.
That's fun to see this clear language still alive.

> Included in the tests/ directory is a small demo/test program.
> It can select a rigs and open a very primative frequency display
> dialog box.  Will improve later..

Sorry, I won't be able to give it a try real soon, cause I don't
have Kylix installed yet. Somehow, I have not seen any Makefile.am
in your commit. Do you think it's too early to put it into dist?
Since there's no support in automake for .pas sources, you'll have 
to specify the build process in the Makefile.am, unless this is all 
handled by Kylix itself.

> One problem I found while testing the binding was that there is no
> way to verify that a non-null rig pointer is pointing to a valid 
> rig structure.  During testing I solved this by adding a magic 
> numbers to the rig structure.

You're right. Hamlib is not checking for non-null rig pointers.
But this is a tread-of. It depends how deep we trust the programmer
using the library. Hamlib can very well not check for any error at all.
However, we implicitly decided to test for initialization errors
caused by null pointers, catching most probable bug.
IMHO, verifying non-null rig pointer is a little bit paranoic,
were are not in the Linux kernel.
Anyway, it's fast, it's the C language. Adding code to check everything
with C would advocate for rewritting Hamlib in Java.
But we like to live dangerously, and avoid breeding bugs in our code :)

Hamlib only means to check for this:

        my_rig = rig_init(RIG_MODEL_DUMMY);
            /* imagine malloc failed, my_rig==NULL */

        rig_open(my_rig);  /* seg fault... */

..and not for random memory corruption within the RIG opaque structure.
If the user program messes to much with it, it'll get what ít's looking for.

Now, thinking of it twice (sorry folks, I sometimes happen to not think twice 
when I write code :), Hamlib is not checking the right thing.
It should check for rig_state.comm_state, preventing for example an app
from doing rig_set_freq() on a rig handle that was not rig_open'ed.
What do you all think? 


Btw Francois, you told me earlier you have a patch for the easycomm rotator.
Is it spinning already? Do you have any plan to commit it before 1.1.3?
I was thinking also that the rotator API lacks some capabilities, 
like the angular speed of the rotator (what units are best?),
and also a call like rot_get_destination, useful when the rotator
is still on its way.


Cheers,

Stephane

[Hamlib-developer] Re: Kylix binding for Hamlib

[Francois R. <fgr...@su...>]

Hello Stephane,

Stephane Fillod wrote:
> > Included in the tests/ directory is a small demo/test program.
> > It can select a rigs and open a very primative frequency display
> > dialog box.  Will improve later..
> 
> Sorry, I won't be able to give it a try real soon, cause I don't
> have Kylix installed yet. Somehow, I have not seen any Makefile.am
> in your commit. Do you think it's too early to put it into dist?
> Since there's no support in automake for .pas sources, you'll have
> to specify the build process in the Makefile.am, unless this is all
> handled by Kylix itself.

Hmm, forgot about the Makefile.am.  Kylix has also has a command-line
compiler, but I have not used it yet.   Kylix handle it's own build 
process. The user has to include the hamlib_*api.pas files in his
project to use the binding.

> You're right. Hamlib is not checking for non-null rig pointers.
> But this is a tread-of. It depends how deep we trust the programmer
> using the library. Hamlib can very well not check for any error at all.
> However, we implicitly decided to test for initialization errors
> caused by null pointers, catching most probable bug.
> IMHO, verifying non-null rig pointer is a little bit paranoic,
> were are not in the Linux kernel.
> Anyway, it's fast, it's the C language. Adding code to check everything
> with C would advocate for rewritting Hamlib in Java.
> But we like to live dangerously, and avoid breeding bugs in our code :)
> 
> Hamlib only means to check for this:
> 
>         my_rig = rig_init(RIG_MODEL_DUMMY);
>             /* imagine malloc failed, my_rig==NULL */
> 
>         rig_open(my_rig);  /* seg fault... */
> 
> ..and not for random memory corruption within the RIG opaque structure.
> If the user program messes to much with it, it'll get what ít's looking for.
> 
> Now, thinking of it twice (sorry folks, I sometimes happen to not think twice
> when I write code :), Hamlib is not checking the right thing.
> It should check for rig_state.comm_state, preventing for example an app
> from doing rig_set_freq() on a rig handle that was not rig_open'ed.
> What do you all think?

I agree that the magic number testing is going a bit overboard, but 
it is helpfull during testing. I'll keep a seperate patch for testing.

> Btw Francois, you told me earlier you have a patch for the easycomm rotator.
> Is it spinning already? Do you have any plan to commit it before 1.1.3?
> I was thinking also that the rotator API lacks some capabilities,
> like the angular speed of the rotator (what units are best?),
> and also a call like rot_get_destination, useful when the rotator
> is still on its way.

Yes, it is working. Got a little distracted by the Kylix binding. 
Will submit it tonight. 


Cheers
  Francois Retief

--
---------------------------------------------------------------------
Electronic Systems Laboratory (ESL)
University of Stellenbosch
South Africa
Tel. +27-21-808-4472

** Developers of the SUNSAT micro-satellite **
http://sunsat.ee.sun.ac.za

Re: [Hamlib-developer] Kylix binding for Hamlib

[<ro...@st...>]

Hello all,

On Mon, 14 Jan 2002, Stephane Fillod wrote:

> Quoting Francois Retief <fgr...@su...>:
>
> > I committed a binding for Borland's Kylix to the CVS.
>
> Great! I used to be a Turbo Pascal fan, from the 4.0 version and onwards.
> That's fun to see this clear language still alive.

I did some Turbo Pascal stuff with DOS a long time ago and wanted to
try Kylix, but I haven't done so yet. And then I read
http://slashdot.org/article.pl?sid=02/01/12/1832223 and the link to
http://freshmeat.net/articles/view/369/ .

Heise.de also has a report on it and notes that since the license is not
available before installation, parts of it might not have legal binding
(here in Germany).

Just for opening your eyes...

73, Robert
-- 
Robert Steinhaeusser, DL1NC / N9KBK                        dl...@da...
http://1409.org                                 ro...@st...