opengtoolkit-developers

'Occurrence' OpenGOOP Object

[Jim K. <ji...@ji...>]

Hello All,

One thing that I have found bothersome about occurrences is that the
'Generate Occurrence' function is more of an Occurrence "constant" than =
a
"generator".  Each call to an instance of 'Generate Occurrence' will =
return
the same occurrence.  So, I wrapped the occurrence primitives in a =
stripped
down OpenGOOP Class.  The data store contains only an occurrence, and =
there
is one unique occurrence per object instance (since the data core is a
reentrant LV2 global, called by reference).  Another added benefit of =
having
OpenGOOP wrapper VIs around the occurrence primitives is that they have
error IO, which makes data flow sequencing possible without the classic
one-frame sequence structure.

So, I have a few questions:

Does it make sense to augment the default behavior of occurrences?  If =
so,
what features and behaviors should be implemented?  Is this tool useful?

Regards,

-Jim

Re: 'Occurrence' OpenGOOP Object

[Jean-Pierre D. <jea...@tr...>]

Jim,

I think that by using CLNs within labview.exe to functions like AllocOccu=
r and DeallocOccur you can create (new at each call) and
destroy occurences. However, I don't know how platform (in)dependant it i=
s. I'm sure Rolf has more to say about this...

Jean-Pierre


----- Message d'origine -----=20
De : "Jim Kring" <ji...@ji...>
=C0 : "'OpenGToolkit-Developers'" <ope...@li...urcefo=
rge.net>
Envoy=E9 : 16 d=E9cembre, 2003 23:06
Objet : 'Occurrence' OpenGOOP Object


Hello All,

One thing that I have found bothersome about occurrences is that the
'Generate Occurrence' function is more of an Occurrence "constant" than a
"generator".  Each call to an instance of 'Generate Occurrence' will retu=
rn
the same occurrence.  So, I wrapped the occurrence primitives in a stripp=
ed
down OpenGOOP Class.  The data store contains only an occurrence, and the=
re
is one unique occurrence per object instance (since the data core is a
reentrant LV2 global, called by reference).  Another added benefit of hav=
ing
OpenGOOP wrapper VIs around the occurrence primitives is that they have
error IO, which makes data flow sequencing possible without the classic
one-frame sequence structure.

So, I have a few questions:

Does it make sense to augment the default behavior of occurrences?  If so=
,
what features and behaviors should be implemented?  Is this tool useful?

Regards,

-Jim

RE: 'Occurrence' OpenGOOP Object

[Rolf K. <rol...@ci...>]

Jean-Pierre,

You are right, but use "LabVIEW" instead. "LabVIEW.exe" will only work =
on
Windows as LabVIEW will just do a LoadLibrary on that name and it does =
not
have an exe extension on all platforms. But the "LabVIEW" keyword is
apparently trapped in the CLN function and directly redirected to its =
own
export function table without using the platform specifc LoadLibrary =
call.

You can see that when using "LabVIEW" you don't get any functions listed
in the Function name drop box as LabVIEW does aparently not support
enumerating directly the export table but you can get all the names if
you enter exactly the path the to LabVIEW.exe file, as LabVIEW then just
enumerates the export section of the executable image, which is exactly
the same for Win32 DLLs as it is for Win32 EXEs.

So you first enter the full path to LabVIEW.exe, then select the =
appropriate
function and then change the path to "LabVIEW". Now you just need to =
know
the exact prototypes ;-)

/* This is the same as the NotARefnum constant in LabVIEW */
#define kNonOccurrence  0

/* Basically the same as a LVRefNum, an opaque pointer to a LabVIEW =
private
data structure, which you should never try to assume anything about as =
it
may completely change between versions. I think current LabVIEW actually
uses here a so called cookie which is a 32 bit number only meaningful to
the instance who created it. */
Private(Occurrence);

Occurrence  AllocOccur(void);
MgErr Occur(Occurrence occ);
MgErr DeallocOccur(Occurrence o);

Rolf Kalbermatter

> -----Original Message-----
> From: Jean-Pierre Drolet [mailto:jea...@tr...]
> Sent: Wed, December 17, 2003 2:21 PM
> To: ope...@li...
> Subject: Re: 'Occurrence' OpenGOOP Object
>=20
>=20
> Jim,
>=20
> I think that by using CLNs within labview.exe to functions=20
> like AllocOccur and DeallocOccur you can create (new at each call) and
> destroy occurences. However, I don't know how platform=20
> (in)dependant it is. I'm sure Rolf has more to say about this...
>=20
> Jean-Pierre
>=20
>=20
> ----- Message d'origine -----=20
> De : "Jim Kring" <ji...@ji...>
> =C0 : "'OpenGToolkit-Developers'"=20
> <ope...@li...>
> Envoy=E9 : 16 d=E9cembre, 2003 23:06
> Objet : 'Occurrence' OpenGOOP Object
>=20
>=20
> Hello All,
>=20
> One thing that I have found bothersome about occurrences is that the
> 'Generate Occurrence' function is more of an Occurrence=20
> "constant" than a
> "generator".  Each call to an instance of 'Generate=20
> Occurrence' will return
> the same occurrence.  So, I wrapped the occurrence primitives=20
> in a stripped
> down OpenGOOP Class.  The data store contains only an=20
> occurrence, and there
> is one unique occurrence per object instance (since the data core is a
> reentrant LV2 global, called by reference).  Another added=20
> benefit of having
> OpenGOOP wrapper VIs around the occurrence primitives is that=20
> they have
> error IO, which makes data flow sequencing possible without=20
> the classic
> one-frame sequence structure.
>=20
> So, I have a few questions:
>=20
> Does it make sense to augment the default behavior of=20
> occurrences?  If so,
> what features and behaviors should be implemented?  Is this=20
> tool useful?
>=20
> Regards,
>=20
> -Jim
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign=20
> up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell=20
> to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
> _______________________________________________
> OpenGToolkit-Developers mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>=20
>=20

RE: 'Occurrence' OpenGOOP Object

[Jim K. <ji...@ji...>]

Rolf,

I was able to get AllocOccur, Occur, and DeallocOccur.  They seem to =
work
great.  I also noticed the following functions exported by LabVIEW.exe
(LV70), which look interesting.

AllocOccurHdlr
OccurAtTime
OnOccurrence
OnOccurrenceWithTimeout
InterruptSafeOccur

I would presume that 'OnOccurrenceWithTimeout' is analagous to the 'Wait =
on
Occurrence' primitive... is this right?

-Jim


> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Rolf Kalbermatter
> Sent: Thursday, December 18, 2003 12:21 AM
> To: ope...@li...
> Subject: RE: 'Occurrence' OpenGOOP Object
>=20
>=20
> Jean-Pierre,
>=20
> You are right, but use "LabVIEW" instead. "LabVIEW.exe" will=20
> only work on Windows as LabVIEW will just do a LoadLibrary on=20
> that name and it does not have an exe extension on all=20
> platforms. But the "LabVIEW" keyword is apparently trapped in=20
> the CLN function and directly redirected to its own export=20
> function table without using the platform specifc LoadLibrary call.
>=20
> You can see that when using "LabVIEW" you don't get any=20
> functions listed in the Function name drop box as LabVIEW=20
> does aparently not support enumerating directly the export=20
> table but you can get all the names if you enter exactly the=20
> path the to LabVIEW.exe file, as LabVIEW then just enumerates=20
> the export section of the executable image, which is exactly=20
> the same for Win32 DLLs as it is for Win32 EXEs.
>=20
> So you first enter the full path to LabVIEW.exe, then select=20
> the appropriate function and then change the path to=20
> "LabVIEW". Now you just need to know the exact prototypes ;-)
>=20
> /* This is the same as the NotARefnum constant in LabVIEW */=20
> #define kNonOccurrence  0
>=20
> /* Basically the same as a LVRefNum, an opaque pointer to a=20
> LabVIEW private data structure, which you should never try to=20
> assume anything about as it may completely change between=20
> versions. I think current LabVIEW actually uses here a so=20
> called cookie which is a 32 bit number only meaningful to the=20
> instance who created it. */ Private(Occurrence);
>=20
> Occurrence  AllocOccur(void);
> MgErr Occur(Occurrence occ);
> MgErr DeallocOccur(Occurrence o);
>=20
> Rolf Kalbermatter
>=20
> > -----Original Message-----
> > From: Jean-Pierre Drolet [mailto:jea...@tr...]
> > Sent: Wed, December 17, 2003 2:21 PM
> > To: ope...@li...
> > Subject: Re: 'Occurrence' OpenGOOP Object
> >=20
> >=20
> > Jim,
> >=20
> > I think that by using CLNs within labview.exe to functions
> > like AllocOccur and DeallocOccur you can create (new at=20
> each call) and
> > destroy occurences. However, I don't know how platform=20
> > (in)dependant it is. I'm sure Rolf has more to say about this...
> >=20
> > Jean-Pierre
> >=20
> >=20
> > ----- Message d'origine -----
> > De : "Jim Kring" <ji...@ji...>
> > =C0 : "'OpenGToolkit-Developers'"=20
> > <ope...@li...>
> > Envoy=E9 : 16 d=E9cembre, 2003 23:06
> > Objet : 'Occurrence' OpenGOOP Object
> >=20
> >=20
> > Hello All,
> >=20
> > One thing that I have found bothersome about occurrences is=20
> that the=20
> > 'Generate Occurrence' function is more of an Occurrence "constant"=20
> > than a "generator".  Each call to an instance of 'Generate
> > Occurrence' will return
> > the same occurrence.  So, I wrapped the occurrence primitives=20
> > in a stripped
> > down OpenGOOP Class.  The data store contains only an=20
> > occurrence, and there
> > is one unique occurrence per object instance (since the=20
> data core is a
> > reentrant LV2 global, called by reference).  Another added=20
> > benefit of having
> > OpenGOOP wrapper VIs around the occurrence primitives is that=20
> > they have
> > error IO, which makes data flow sequencing possible without=20
> > the classic
> > one-frame sequence structure.
> >=20
> > So, I have a few questions:
> >=20
> > Does it make sense to augment the default behavior of
> > occurrences?  If so,
> > what features and behaviors should be implemented?  Is this=20
> > tool useful?
> >=20
> > Regards,
> >=20
> > -Jim
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials. Become an=20
> > expert in LINUX or just sharpen your skills.  Sign up for IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell=20
> > to sys admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
> > _______________________________________________
> > OpenGToolkit-Developers mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
> >=20
> >=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign=20
> up for IBM's Free Linux Tutorials.  Learn everything from the=20
> bash shell to sys admin. Click now!=20
> http://ads.osdn.com/?ad_id=1278&alloc_id371> &op=3Dick
>=20
> _______________________________________________
>=20
> OpenGToolkit-Developers mailing list=20
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>=20

RE: 'Occurrence' OpenGOOP Object

[Rolf K. <rol...@ci...>]

Hi Jim,

> I was able to get AllocOccur, Occur, and DeallocOccur.  They=20
> seem to work
> great.  I also noticed the following functions exported by LabVIEW.exe
> (LV70), which look interesting.

Don't forget to make sure you actually dealloc all occurrences you ever
allocated. By enveloping it in an object this should be quite doable. =
They
do allocate some memory each time. Also try to not overuse them to much.
At least in LV 6.1 and earlier there is a slight problem in that the =
invocation
time of any LVRefNum based object drastically increases with the number =
of
allocated objects of that object type. I guess this has to do with a =
linear
search of the LVRefnum in its internal RefNum pool list (some call these
Cookies and CookieJars). Also once the list has been enlarged the access
times seem to stay constant eventhough you deallocated all but one =
object
properly until you restart LabVIEW.
=20
> AllocOccurHdlr
Forget this, it's a callback mechanisme and won't do any good in LabVIEW
code but only in C.

> OccurAtTime
Should be ok, I will try to find the prototype of this

> OnOccurrence
> OnOccurrenceWithTimeout
These have probably to do with the callback mechanisme.

> InterruptSafeOccur

Can be used to occur from within a driver (e,g. at Interrupt time) I =
would
assume. Probably not important at all from the LV diagram.

> I would presume that 'OnOccurrenceWithTimeout' is analagous=20
> to the 'Wait on
> Occurrence' primitive... is this right?

Yes, but as I said the node sets up a callback which will be called into
on timeout or occurrence and therefore the OnOccurrence.. functions are
unlikely to be usable from a CLN.

Rolf