opengtoolkit-developers — OpenG Toolkit developers mailing list

RE: LabVIEW SSH Tools

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

Hi Jim
=20
> I haven't done any works with pipes in Windows and did a little bit of
> research.  I found the following on MSDN:
>=20
> =
<http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dllpr=
oc/base/creating_a_child_process_with_redirected_input_and_output.asp>

>Has anyone gotten pipes working in LabVIEW?  Would anyone more C++ =
savvy
>than myself be interested in working with me to get a generic "System =
Exec
>w/ Pipes" working?  I envision a DLL that could be called from LabVIEW =
(or
>maybe LabVIEW could call WinAPI DLLs directly) with functions for =
Spawning
>the Process (the command-line executable), Reading from, and Writing to =
a
>Pipe for communication with the running executable.

I haven't done anything with pipes yet although it isn't really =
difficult.
The article you qoute seems fairly straight forward. I think the current
System Exec most probably uses pipes for the three standard IO handles =
to
get the StdIn/Out and Err at all. What is the problem is that you do not
get the handle back but just the entire text after execution of the =
command.

I think although it might be sort of possible to go directly from =
LabVIEW
to the Win32 API, it is a much better and smarter aproach to pack =
everything
into a DLL. Instead of returning the entire StdOut/Err text at once it =
would
return the three handles which can then be used by other DLL functions =
to
read and write to/from those handles.

The code as shown in above example would almost work for that already. =
At the
moment I'm busy getting the Generic PortIO device driver working (Well =
generic
in that it supports Port IO in direct fast and indirect slow mode (the =
one the
current LabVIEW PortIO functions support) and possibly low mem access, =
not
multiplattform although I got a Linux example too, just need to adapt it =
a bit
to get it working nicely with LabVIEW.) I hope I have it ready end of =
this week
and then I'll look into the inherited pipe system exec if nobody else =
stepped
up to it until then.

Rolf Kalbermatter

RE: LabVIEW SSH Tools

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

> -----Original Message-----
> From: Jim Kring [mailto:ji...@ji...]
> Sent: Sat, February 28, 2004 7:42 PM
> To: 'OpenGToolkit-Developers'
> Subject: LabVIEW SSH Tools
>=20
>=20
> Hello all,
>=20
> I was wondering if anyone has done any work with LabVIEW and=20
> SSH.  I was
> looking at the PuTTY FAQ to see if there was a programmatic=20
> interface and
> saw the following:
>=20
> <http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#A.4.3>
>=20
> ##############=20
> Probably your best bet is to use Plink, the command-line=20
> connection tool. If
> you can start Plink as a second Windows process, and arrange for your
> primary process to be able to send data to the Plink process,=20
> and receive
> data from it, through pipes, then you should be able to make=20
> SSH connections
> from your program.
>=20
> This is what CVS for Windows does, for example.
> ##############
>=20
> I haven't done any works with pipes in Windows and did a little bit of
> research.  I found the following on MSDN:
>=20
> =
<http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dllpr=
oc/base/creating_a_child_process_with_redirected_input_and_output.asp>

Has anyone gotten pipes working in LabVIEW?  Would anyone more C++ savvy
than myself be interested in working with me to get a generic "System =
Exec
w/ Pipes" working?  I envision a DLL that could be called from LabVIEW =
(or
maybe LabVIEW could call WinAPI DLLs directly) with functions for =
Spawning
the Process (the command-line executable), Reading from, and Writing to =
a
Pipe for communication with the running executable.

Regards,

-Jim



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers

LabVIEW SSH Tools

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

Hello all,

I was wondering if anyone has done any work with LabVIEW and SSH.  I was
looking at the PuTTY FAQ to see if there was a programmatic interface =
and
saw the following:

<http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#A.4.3>

##############=20
Probably your best bet is to use Plink, the command-line connection =
tool. If
you can start Plink as a second Windows process, and arrange for your
primary process to be able to send data to the Plink process, and =
receive
data from it, through pipes, then you should be able to make SSH =
connections
from your program.

This is what CVS for Windows does, for example.
##############

I haven't done any works with pipes in Windows and did a little bit of
research.  I found the following on MSDN:

<http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dllpr=
oc/ba
se/creating_a_child_process_with_redirected_input_and_output.asp>

Has anyone gotten pipes working in LabVIEW?  Would anyone more C++ savvy
than myself be interested in working with me to get a generic "System =
Exec
w/ Pipes" working?  I envision a DLL that could be called from LabVIEW =
(or
maybe LabVIEW could call WinAPI DLLs directly) with functions for =
Spawning
the Process (the command-line executable), Reading from, and Writing to =
a
Pipe for communication with the running executable.

Regards,

-Jim

FW: [SourceForge.net Release] opengtoolkit : lib_string

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

-=3D oglib_string-2.1-1.ogp =3D-

Changes from 2.0-1 --> 2.1-1
--------------------------------
2004-02-24

[FIX] Format string was not wired in Boolean case of 'Format Variant =
Into
String'


-----Original Message-----
From: SourceForge.net [mailto:no...@so...]=20
Sent: Tuesday, February 24, 2004 2:37 PM
To: no...@so...
Subject: [SourceForge.net Release] opengtoolkit : lib_string


Project: OpenG Toolkit  (opengtoolkit)
Package: lib_string
Date   : 2004-02-24 14:37

Project "OpenG Toolkit" ('opengtoolkit') has released the new version of
package 'lib_string'. You can download it from SourceForge.net by =
following
this link:
<https://sourceforge.net/project/showfiles.php?group_id=3D52435&release_i=
d=3D219
389>
or browse Release Notes and ChangeLog by visiting this link:
<https://sourceforge.net/project/shownotes.php?release_id=3D219389>=20

You receive this email because you requested to be notified when new
versions of this package were released. If you don't wish to be notified =
in
the future, please login to SourceForge.net and click this link:
<https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=3D=
5615
6>
If you lost your SourceForge.net login name or password, refer to this
document:
<https://sourceforge.net/docman/display_doc.php?docid=3D760&group_id=3D1>=


Note that you may receive this message indirectly via one of your =
mailing
list subscriptions. Please review message headers before reporting
unsolicited mailings.

FW: [SourceForge.net Release] opengtoolkit : all_packages

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

-=3D all_packages-2.1.5 =3D-

oglib_appcontrol-2.1-1
oglib_array-2.0-1
oglib_boolean-2.0-1
oglib_comparison-2.0-1
oglib_error-2.0-1
oglib_file-2.2-1
oglib_lvdata-2.2-1
oglib_lvzip-2.0-2
oglib_msgqueue-2.0-1
oglib_numeric-2.0-1
oglib_string-2.1-1          <=3D=3D Updated
oglib_time-2.0-1
oglib_variantconfig-2.2-1
ogrsc_dynamicpalette-0.6-1
ogrsc_restart-1.0-1

-=3D 2.1.5 Changelog =3D-

all_packages         2.1.4 --> 2.1.5
--------------------------------------
oglib_string         2.0-1 --> 2.1-1 (fixed 'Format Variant Into =
String')


-----Original Message-----
From: SourceForge.net [mailto:no...@so...]=20
Sent: Tuesday, February 24, 2004 2:34 PM
To: no...@so...
Subject: [SourceForge.net Release] opengtoolkit : all_packages


Project: OpenG Toolkit  (opengtoolkit)
Package: all_packages
Date   : 2004-02-24 14:33

Project "OpenG Toolkit" ('opengtoolkit') has released the new version of
package 'all_packages'. You can download it from SourceForge.net by
following this link:
<https://sourceforge.net/project/showfiles.php?group_id=3D52435&release_i=
d=3D219
390>
or browse Release Notes and ChangeLog by visiting this link:
<https://sourceforge.net/project/shownotes.php?release_id=3D219390>=20

You receive this email because you requested to be notified when new
versions of this package were released. If you don't wish to be notified =
in
the future, please login to SourceForge.net and click this link:
<https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=3D=
6073
1>
If you lost your SourceForge.net login name or password, refer to this
document:
<https://sourceforge.net/docman/display_doc.php?docid=3D760&group_id=3D1>=


Note that you may receive this message indirectly via one of your =
mailing
list subscriptions. Please review message headers before reporting
unsolicited mailings.

FW: 'Occurrence' OpenGOOP Object

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

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

/* Cause occurrence o to be triggered at time t. time probably
   is system time (Timer ticks) in ms and a new call to this
   function seems to overwrite a previous time. */
MgErr OccurAtTime(Occurrence o, uInt32 t);

Note: There seems no accessible (exported) way to delete a once
armed timed occurrence other than deallocating that occurrence.
=20
Rolf
 =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

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...>]

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

[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: OpenGOOP Inheritance Requirements Model

[<Bjo...@si...>]

I think it would be nice if it was possible to create a new and empty class
from the palette. Then use the wizard to "fill in the blanks" and all the
other stuff. Maybe not that usefull for top level vis?

> -----Original Message-----
> From: Jim Kring [mailto:ji...@ji...]
> Sent: 17. desember 2003 08:26
> To: OpenGToolkit-Developers
> Subject: OpenGOOP Inheritance Requirements Model
> 
> 
> Hello All,
>  
> I am working hard to get OpenGOOP Inheritance ready for an 
> alpha release.
> The class template and some prototype class generator/linker tools are
> almost finished.  As such, this is a good time to ping the 
> rest of the OpenG
> developers, since you will probably be the first users of OpenGOOP
> Inheritance.  I want to get some feedback from you all on the 
> high-level
> requirements for OpenGOOP Inheritance.  Basically, I want to 
> know what you
> all want out of a "Wizard" -- the tools for automated class 
> generation,
> development, maintenance, documentation, etc.  There are two 
> main goals that
> I am shooting for: (1) programmatic interface to the wizard 
> and (2) make the
> design modular by utilizing a plug-in framework based on OpenGOOP
> Inheritance abstract classes.  Goal #2 won't be realized 
> until later, once
> the OpenGOOP Inheritance design stabilizes.  Goal #1 is the short-term
> focus.  But, before the programmatic interface can be 
> developed, we need to
> define the features that you all want.  So, take a look at 
> this list an
> please feel free to comment.
>  
> Regards,
>  
> -Jim
>  
>  
> OpenGOOP Inheritance Requirements Model
>  
> -= Constraints =-
>  
> FR_010 - Utilize OpenGOOP for Classes 
> OpenGOOP Inheritance should use LV2 Globals Called by 
> Reference, as the
> individual class data stores.  An inheritance hierarchy is created by
> aggregating the instances of the individual classes in the inheritance
> hierarchy.  Children will access the data of thier parents 
> through special
> "core" VIs provided by the parents.
>  
> FR_011 - The "core" of the class may be easily upgraded by 
> class developers.
> 
> The Core of the class are those parts that are not customized by class
> developers.  The core does not contain (but may depend upon) 
> VIs or TypeDefs
> that defines the structure of the class.  The Core is the 
> "glue" that holds
> the class together.  Replacing the Core of the class (e.g with a newer
> version) should be transparent to the class developer.  Also, 
> there may be
> many types of Cores that are optimized for certain type of 
> performance (e.g.
> instanciation speed, access speed, data size, etc).
>  
> FR_012 - The "Common Core" should be as small as possible, initially. 
> The "Common Core" is the portion of the core that all 
> OpenGOOP Inheritance
> classes depend upon.  Initially, this should be kept as small 
> as possible,
> since all classes depend upon it.  Initially Common Core 
> components will be
> stored in each Class's "Core" folder (and be linked within 
> the classes own
> namespace).
>  
> FR_013 - Wizard should provide plug-in interfaces that are 
> implemented by
> OpenGOOP Inheritance subclasses. 
> This provides two benefits.  First, it allows us to eat our 
> own dog food.
> Second, it allows users to create new plug-ins and features 
> of the Wizard --
> this is of huge importance to the project.  These interfaces 
> should be well
> documented and templates should be made available.
>  
> -= Features =-
>  
> Class Creation:
>  
> FR_001 - Classes can be created from other classes (as a copy).
>  
> FR_013 - Classes can be created from class meta information.
> Classes can be created from class meta information such as 
> class name, data
> members, methods, etc.; perhaps in an XML file or similar.
>  
> 
> Class Deployment:
>  
> FR_002 - Classes can be "built" into Apps 
> Classes should be able to be built.  This means that the source may be
> consolidated into a single folder (or LLB).
>  
> FR_003 - Classes can be "name mangled" 
> Classes can be name mangled with a suffix such that the name 
> appears like
> *__opengtool.vi
> 
> Class Documentation:
>  
> FR_006 - Class meta information (documentation) may be 
> exported to file. 
> 
> Class Management:
>  
> FR_004 - Classes may be renamed 
> Renaming should also take into consideration whether 
> dependant classes are
> to be relinked to the renamed class.
>  
> FR_005 - Classes may be relinked to a new parent class 
> 
> FR_009 - Class "icon banners" may be updated automatically. 
> A VI "icon banner" is often used accross the top of all VIs 
> within a class.
> This "icon banner" is just a string that represents the class name.
> 
> Class Visualization:
>  
> FR_007 - Class inheritance hierarchy may be visualized
> There should be a way to visualize the relationships between 
> classes in an
> inheritance hierarchy
>  
> FR_008 - Class structure may be visualized. 
> There should be a way to visualize a class's structure.  This 
> should show
> the various members (public, protected, and private data) and 
> methods.  The
> visualization tool should group by type (modifier): e.g. 
> public, virtual,
> etc).
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign 
> up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell 
> to sys admin.
> Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
> _______________________________________________
> OpenGToolkit-Developers mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
> 

OpenGUnit - a unit test framework

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

Hello All,

I just wanted to plant this seed since it is near on the horizon (I =
hope).
Once OpenGOOP Inheritance is a reality, it will be much more feasible to
implement a very flexible unit test framework for G.  Such a framework
really needs inheritance and dynamic polymorphism (plug-ins).

I am thinking that what we need is something like PyUnit (a unit test
framework for Python).  Here is a quick summary:  We would define a =
TestCase
class that defines virtual (overridable) methods such as setUp, =
tearDown,
and runTest (as well as a means to define multiple tests).  To create a
specific test case, you would create a class that inherits from =
TestCase.
You would then implement (override) the aforementioned methods of =
TestCase.

When a TestCase is run, the test framework would invoke setUp to =
initialize
the test.  Then, if no error occurs, the framework would invoke runTest.
Finally, regardless of whether runTest was successful, tearDown would be
invoked to tidy up.  The TestCase class would have several methods like
failUnlessEqual, failIfEqual, failUnlessError, failUnless.  These would =
be
called inside one's subclass of TestCase to send pass/fail info to the =
test
framework.

There would also be a class called TestSuite, which is used to aggregate
test cases and test suites.

Finally there would be various different TestRunner classes which run
TestSuites and allow different types of interaction with running tests.

For more info on PyUnit, check out http://pyunit.sourceforge.net

The overview (link below) gives a good description of how one uses the =
Unit
Test framework.
http://pyunit.sourceforge.net/pyunit.html#OVERVIEW

The unittest module documentation (link below) shows all of the classes =
(and
their methods) of unittest.
http://pyunit.sourceforge.net/unittest.html


Lastly, what about a project name?  'Gunit' is already taken.  I like
'OpenGUnit', or maybe 'LabUnit'...

Any thoughts?

Regards,

-Jim

OpenGOOP Inheritance Requirements Model

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

Hello All,
=20
I am working hard to get OpenGOOP Inheritance ready for an alpha =
release.
The class template and some prototype class generator/linker tools are
almost finished.  As such, this is a good time to ping the rest of the =
OpenG
developers, since you will probably be the first users of OpenGOOP
Inheritance.  I want to get some feedback from you all on the high-level
requirements for OpenGOOP Inheritance.  Basically, I want to know what =
you
all want out of a "Wizard" -- the tools for automated class generation,
development, maintenance, documentation, etc.  There are two main goals =
that
I am shooting for: (1) programmatic interface to the wizard and (2) make =
the
design modular by utilizing a plug-in framework based on OpenGOOP
Inheritance abstract classes.  Goal #2 won't be realized until later, =
once
the OpenGOOP Inheritance design stabilizes.  Goal #1 is the short-term
focus.  But, before the programmatic interface can be developed, we need =
to
define the features that you all want.  So, take a look at this list an
please feel free to comment.
=20
Regards,
=20
-Jim
=20
=20
OpenGOOP Inheritance Requirements Model
=20
-=3D Constraints =3D-
=20
FR_010 - Utilize OpenGOOP for Classes=20
OpenGOOP Inheritance should use LV2 Globals Called by Reference, as the
individual class data stores.  An inheritance hierarchy is created by
aggregating the instances of the individual classes in the inheritance
hierarchy.  Children will access the data of thier parents through =
special
"core" VIs provided by the parents.
=20
FR_011 - The "core" of the class may be easily upgraded by class =
developers.

The Core of the class are those parts that are not customized by class
developers.  The core does not contain (but may depend upon) VIs or =
TypeDefs
that defines the structure of the class.  The Core is the "glue" that =
holds
the class together.  Replacing the Core of the class (e.g with a newer
version) should be transparent to the class developer.  Also, there may =
be
many types of Cores that are optimized for certain type of performance =
(e.g.
instanciation speed, access speed, data size, etc).
=20
FR_012 - The "Common Core" should be as small as possible, initially.=20
The "Common Core" is the portion of the core that all OpenGOOP =
Inheritance
classes depend upon.  Initially, this should be kept as small as =
possible,
since all classes depend upon it.  Initially Common Core components will =
be
stored in each Class's "Core" folder (and be linked within the classes =
own
namespace).
=20
FR_013 - Wizard should provide plug-in interfaces that are implemented =
by
OpenGOOP Inheritance subclasses.=20
This provides two benefits.  First, it allows us to eat our own dog =
food.
Second, it allows users to create new plug-ins and features of the =
Wizard --
this is of huge importance to the project.  These interfaces should be =
well
documented and templates should be made available.
=20
-=3D Features =3D-
=20
Class Creation:
=20
FR_001 - Classes can be created from other classes (as a copy).
=20
FR_013 - Classes can be created from class meta information.
Classes can be created from class meta information such as class name, =
data
members, methods, etc.; perhaps in an XML file or similar.
=20

Class Deployment:
=20
FR_002 - Classes can be "built" into Apps=20
Classes should be able to be built.  This means that the source may be
consolidated into a single folder (or LLB).
=20
FR_003 - Classes can be "name mangled"=20
Classes can be name mangled with a suffix such that the name appears =
like
*__opengtool.vi

Class Documentation:
=20
FR_006 - Class meta information (documentation) may be exported to file. =


Class Management:
=20
FR_004 - Classes may be renamed=20
Renaming should also take into consideration whether dependant classes =
are
to be relinked to the renamed class.
=20
FR_005 - Classes may be relinked to a new parent class=20

FR_009 - Class "icon banners" may be updated automatically.=20
A VI "icon banner" is often used accross the top of all VIs within a =
class.
This "icon banner" is just a string that represents the class name.

Class Visualization:
=20
FR_007 - Class inheritance hierarchy may be visualized
There should be a way to visualize the relationships between classes in =
an
inheritance hierarchy
=20
FR_008 - Class structure may be visualized.=20
There should be a way to visualize a class's structure.  This should =
show
the various members (public, protected, and private data) and methods.  =
The
visualization tool should group by type (modifier): e.g. public, =
virtual,
etc).

'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

opengoop-0.7 released

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

<http://sourceforge.net/projects/opengtoolkit/>

-= ogfwk_opengoop-0.7-1.ogp =-

v0.7 is compatible with LabVIEW 6.0, 6.1, and 7.0 on all platforms.
It has optional components that depend on the OpenG Toolkit v2.x


Changes from 0.6-1 --> 0.7-1
--------------------------------
2003-12-16
[Fix] made 'Get Data to Modify' reentrant
[Mod] Data Store VI name is now obtained by static link


Changes from 0.5-1 --> 0.6-1
--------------------------------
2003-12-01
[Fix] 'Set Modified Data' now releases semaphore even if error in. 


Changes from 0.4-1 --> 0.5-1
--------------------------------
2003-12-01
[NEW] Added a progress dialog to the wizard


Changes from 0.3-1 --> 0.4-1
--------------------------------
2003-12-01
[NEW] Package is now compatible with LV 7.0
[FIX] Wizard now works in LV 7.0 (Open VI Reference to
      template problem, fixed by option 0x02)
[MOD] '(Un)Flatten Object to(from) File' now linked to OGTK-2.x

relink_project_to_ogtk_2 0.4 released

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

<http://sourceforge.net/projects/opengtoolkit/>

I fixed a bug, added a warning/instruction dialog, and *tested* it ;-)

-Jim

FW: [A] XML to Variant?

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

OpenG Developers,

I have updated the Flatten to XML example on OpenG.org by adding an
Unflatten from XML.  "OpenG Unflatten from XML" overcomes two major
limitations of the LabVIEW Native version of "Unflatten from XML"

1) It uses only the XML string as the basis for the output variant data. =
 It
doesn't need a copy of the original data type.
2) It supports data within variants (the native version doesn't)

Anyone want to help work to bring these into the OpenG Toolkit?  Before =
we
can add them to the toolkit we need a test plan to validate that we are
supporting all data types in the schema and that we can handle errors
correctly.

-Jim

-----Original Message-----
From: inf...@pi... [mailto:inf...@pi...] On
Behalf Of Jim Kring
Sent: Tuesday, December 09, 2003 10:20 AM
To: 'Martin Gustafsson'; 'Info-LabVIEW'; 'Dees, Ian'
Subject: RE: [A] XML to Variant?


Martin and Ian,

I got inspired late last night and decided to try and create a pure G
version of "Unflatten from XML" that outputs variant LabVIEW data.  It =
turns
out that it didn't take as long as I thought.  You can download the =
working
example here:

<http://openg.org/tiki/tiki-index.php?page=3DEXAMPLE+-+OpenG+Flatten+to+X=
ML>

But remember, this is just example code.  I'm sure there are a few bugs =
and
maybe some unhandled data types.  If I get enough feedback and folks =
want to
help develop or debug these VIs, I will gladly turn them into a =
supported
library of the OpenG Toolkit.

Cheers,

-Jim


> -----Original Message-----
> From: inf...@pi...
> [mailto:inf...@pi...] On Behalf Of Martin Gustafsson
> Sent: Monday, December 08, 2003 4:34 PM
> To: 'Jim Kring'; 'Info-LabVIEW'
> Subject: Re: [A] XML to Variant?
>=20
>=20
> Jim,
>=20
> Sorry, I misinterpreted you. Yes, I suppose you can say that
> it parses no deeper than the variant, and I do think it is=20
> unfortunate. I would prefer a parser that didn't have a type=20
> input, but instead always put out a variant. This combined=20
> with tools for extracting information about variant data=20
> types would be very useful to me.
>=20
> Best regards
> Martin Gustafsson
>=20
> > Martin,
> >=20
> > Yes, that's basically what I said:
> >=20
> > > > The "Unflatten from XML" function doesn't parse
> > > > the XML string any deeper than the variant,
> > > > meaning that it does continue to convert XML
> > > > data inside the variant.
> >=20
> > Based on your example, the XML string for a Boolean in a Variant=20
> > would look like the following:
> >=20
> > <LvVariant>
> > <Name>Variant</Name>
> > <Boolean>
> > <Name>error in (no error)</Name>
> > <Val>1</Val>
> > </Boolean>
> > </LvVariant>
> >=20
> > But all the variant data gets lost if we convert the above XML=20
> > string to a variant, as shown below:
> >=20
> > <LvVariant>
> > <Name>Variant</Name>
> > </LvVariant>
> >=20
> > This is because "Unflatten from XML" ignores Variant data in the XML =

> > string.
> >=20
> > -Jim
> >=20
> >=20
> > Martin Gustafsson <oct...@te...> said:
> >=20
> > > Ian and Jim,
> > >=20
> > > You cold actually take anything (like a boolean), convert it to=20
> > > variant, flatten to XML, unflatten from XML and get nothing out,=20
> > > regardless of what you wire as "data type" to unflatten.
> > >=20
> > > There is also a reverse phenomenon: If you wire a variant as data=20
> > > type, nothing will come out regardless of what comes in.
> > >=20
> > > Best regards
> > > Martin Gustafsson
> > >=20
> > > > Ian,
> > > >=20
> > > > LabVIEW's native conversion between Variant Data and
> XML is a one
> > > > way, transformation.  The "Unflatten from XML" function doesn't=20
> > > > parse the XML string any deeper than the variant, meaning that=20
> > > > it does continue to convert
> > > > XML data inside the variant.  Maybe the algorithm that=20
> > LabVIEW uses
> > > > to "parse" the XML string is actually traversing the strict data =

> > > > structure (the "type" input) rather than the XML string data=20
> > > > itself.
> > > > To do the later=20
> > > > would require an XML parser, rather than a LabVIEW data=20
> > > > traversal routine. =20
> > > > We (OpenG Folks) thought about creating an "Unflatten from=20
> > > > XML" VI that would=20
> > > > return variant data, since we had already developed a=20
> > pure G version
> > > > of "Flatten to XML", but it was quickly realized that doing the=20
> > > > inverse on variant data would be a larger (but not impossible)=20
> > > > undertaking.
> > > >=20
> > > > You can take a look at the OpenG "Flatten to XML" here:
> > > >=20
> > > > <http://openg.org/tiki/tiki-index.php?page=3DEXAMPLE+-+OpenG+Fla
> > > > tten+to+XML>
> > > >=20
> > > > If you are interested in working on an "Unflatten from
> XML" that
> > > > overcomes the limitations of the LabVIEW primitive, I would be
> > > > more than happy to
> > > > participate.
> > > >=20
> > > > -Jim
> > > >=20
> > > >=20
> > > > "Dees, Ian" <Ian...@an...> said:
> > > >=20
> > > > > Hello, fellow wireworkers.
> > > > >=20
> > > > > I've stumbled onto some interesting behavior in
> LabVIEW 6.1 and
> > > > > was
> > > > > wondering if anyone here has either replicated or even
> > > > worked around
> > > > > this
> > > > > issue:
> > > > >=20
> > > > > 1) In a new, blank VI, drop an error cluster control on
> > the front
> > > > > panel.
> > > > > 2) On the diagram, wire the terminal to a To Variant node.
> > > > > 3) Wire the output of the To Variant node into a Flatten to
> > > > XML node.
> > > > > 4) Wire the output of the flatten node to an Unflatten from
> > > > XML node.
> > > > > 5) Wire the output of the To Variant node into the "type"
> > > > input of the
> > > > > unflatten node.
> > > > > 6) Create an indicator from the unflatten node and run the VI.
> > > > >=20
> > > > > If you probe the data at various points, you can trace the
> > > > information
> > > > > as it becomes a real variant with all the values filled in, a=20
> > > > > valid LabVIEW XML string, and finally a valid but empty
> > variant at the
> > > > > output.  Is there any way to make LabVIEW's Unflatten
> > from XML node
> > > > > pick up all the data from the string?  Is the behavior
> > different in
> > > > > LabVIEW 7?
> > > > >=20
> > > > > Thanks in advance for any advice.
> > > > >=20
> > > > > Sincerely,
> > > > >=20
> > > > > Ian Dees
> > > > > Software Engineer
> > > > > Anritsu
> > > > > 972-783-2120
> > > > >=20
> > > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > > --
> > > >=20
> > > >=20
> > > >=20
> > >=20
> > >=20
> >=20
> >=20
> >=20
> > --
> >=20
> >=20
> >=20
>=20
>=20

FW: Dec 2nd OpenG Meeting Summary - NI Software License Agreement

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

Hello OpenG Developers,

Below is an announcement that you might have already seen.  It is the
summary of last Tuesday's (Dec 2) OpenG Group Meeting, which discussed =
the
new NI Software License Agreement.  I would like to thank those people =
who
participated in the meeting and helped send this very important message =
to
NI.  I ran this meeting summary past at least a half dozen of the =
community
representatives who attended the meeting, to make sure that it was an
accurate account of the thoughts and ideas expressed by the group.  In =
fact,
several people contributed directly to the content of the meeting =
summary,
and I would like to give extra thanks those people.

-Jim

-----Original Message-----
From: Jim Kring [mailto:jk...@op...]=20
Sent: Thursday, December 04, 2003 8:19 PM
To: 'jk...@op...'
Subject: Dec 2nd OpenG Meeting Summary - NI Software License Agreement


Hello OpenG Members,

At the December 2nd OpenG Group meeting we gathered to discuss the =
latest
changes (April 2003) to NI Software License Agreement (NISLA). There was =
an
excellent exchange of ideas and concerns from members of OpenG, LAVA, =
and
National Instruments. It was especially encouraging to see =
representation by
NI at the meeting, and to hear that they were listening to the concerns =
of
the community of users and were going to take these points and issues =
back
to Austin to discuss with others...

Read the rest of the meeting summary at http://openg.org >> Dec 2nd =
Meeting
Minutes - NI Software License Agreement

Regards,

-Jim Kring

RE: variantconfig - missing keys

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

Mike,

Thanks for the comments.  I like this idea.  It certainly would be =
possible
to dynamically construct (as a variant) such a data structure.  If you =
have
the time, I'd like to work with you on the use-case that you have =
described,
and then we can back-out the requirements for a useful data structure.
Also, since the output of the Variant Config File VIs are a variants, it
would be possible to utilize variant attributes as a place to put this =
extra
data, without affecting the existing connector panes, in any way.

I'd like to also introduce another concept that I've mentioned to =
several
people, off-list.  The attached example (Merge Clusters) shows how to =
merge
the contents of a cluster into a different, by similarly typed, cluster.
The elements in the source cluster, which are common to the destination
cluster will be merged.  The elements which are not common, are ignored.
Where this differs from reading an INI file and populating a data =
structure
is that INI file keys do not have "type".  You must explicitly tell =
"Read
Key.vi" the type of the key, and then "Read Key.vi" will format the key =
from
a string into the data type that you have specified.  Basically you are
using your target data structure as the definition of the source's data
structure.

-Jim

> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Michael C. Ashe
> Sent: Tuesday, December 02, 2003 8:16 AM
> To: ope...@li...
> Subject: RE: variantconfig - missing keys
>=20
>=20
> It would be nice if the returned data structure was returned=20
> in a format that optionally included all the keys, whether=20
> INI data was found or the default was used, and what the=20
> value was. Where I'm going with this is that, in the event of=20
> an error/lack of data, it might be useful to be able to pump=20
> this into a slightly modified version of the Universal Probe,=20
> which would then display the cluster data in the tree and=20
> indicate if the data came from INI or default.
>=20
> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]On
>  Behalf Of Jim Kring
> Sent: Tuesday, December 02, 2003 2:34 AM
> To: ope...@li...
> Subject: variantconfig - missing keys
>=20
>=20
> Someone has requested a feature for the Variant Configuration File I/O
> (variantconfig) library.  Here is the request:
>=20
> ########################################
> Together with the indication "Key found", it would be handy=20
> if - for example
> - "Read INI-cluster" would have an extra stringoutput that=20
> contains the
> name(s) of the missing key(s) so the user knows where to look=20
> in the INI-file. ########################################
>=20
> I was thinking that there are really two things that you want to test
> against:
>=20
> 1) Which sections/keys are in the INI file but not in the LV=20
> data structure
> 2) Which sections/keys are in the LV data structure but not=20
> in the INI file.
>=20
> The latter (2) is more important, IMO, since the user may=20
> want notification as to which elements were populated with=20
> default values.  The former (1) is useful when a data=20
> structure changes and one might wish to flush the data in the=20
> INI file to remove stale sections/keys.
>=20
> So, the question that I have, is how best to implement this=20
> feature?  It might be useful to return the missing=20
> sections/keys in a programmatically useful data structure=20
> (more than just a string containing a list of missing
> sections/keys)
>=20
> The 'missing sections' could be implemented simply as an=20
> array of strings -- one element for each missing section. =20
> However, the 'missing keys' structure would be a little more=20
> complicated because we would need to include the section=20
> owning the missing keys.  This could be implemented as an=20
> array of section clusters, where each section cluster=20
> contains the name of the section and the keys that are=20
> missing from the section.  This is shown below (where {}=20
> denotes a cluster and [] denotes an array):
>=20
> [ { section1, [ key1, key2, ... ] }, { section2, [ key1,=20
> key2, ... ] }, ... ]
>=20
> Any thoughts?
>=20
> -Jim
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.=20
> Does SourceForge.net help you be more productive?  Does it=20
> help you create better code?  SHARE THE LOVE, and help us=20
> help YOU!  Click Here: http://sourceforge.net/donate/=20
> _______________________________________________
> OpenGToolkit-Developers mailing list=20
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.=20
> Does SourceForge.net help you be more productive?  Does it=20
> help you create better code?  SHARE THE LOVE, and help us=20
> help YOU!  Click Here: http://sourceforge.net/donate/=20
> _______________________________________________
> OpenGToolkit-Developers mailing list=20
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>=20

OpenG Toolkit all_packages-2.1.4 released

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

<https://sourceforge.net/projects/opengtoolkit/>

-=3D all_packages-2.1.4 =3D-

oglib_appcontrol-2.1-1
oglib_array-2.0-1
oglib_boolean-2.0-1
oglib_comparison-2.0-1
oglib_error-2.0-1
oglib_file-2.2-1
oglib_lvdata-2.2-1
oglib_lvzip-2.0-2
oglib_msgqueue-2.0-1
oglib_numeric-2.0-1
oglib_string-2.0-1
oglib_time-2.0-1
oglib_variantconfig-2.2-1
ogrsc_dynamicpalette-0.6-1
ogrsc_restart-1.0-1

Notes:

* dynamicpalette-0.6 is compatible with LabVIEW 6.0, 6.1, and 7.0 on
  Windows; 6.1 and 7.0 on Linux; and 7.0 on Mac OS X
* OpenG Toolkit 2.x packages are name mangled as "*__ogtk.vi" to avoid
  namespace collisions with vi.lib


-=3D 2.1.4 Changelog =3D-

all_packages         2.1.3 --> 2.1.4
--------------------------------------
oglib_lvdata         2.1-1 --> 2.2-1 (fixed palette, control names typo)


-=3D 2.1.3 Changelog =3D-

all_packages         2.1.2 --> 2.1.3
--------------------------------------
oglib_appcontrol     2.0-2 --> 2.1-1 (fixed palette)


-=3D 2.1.2 Changelog =3D-

all_packages         2.1.1 --> 2.1.2
--------------------------------------
oglib_file           2.1-1 --> 2.2-1 ("Strip Path Extension" =
+PolyMember)


-=3D 2.1.1 Changelog =3D-

all_packages         2.1.0 --> 2.1.1
--------------------------------------
oglib_variantconfig  2.1-1 --> 2.2-1 (added missing VI back into =
palette)


-=3D 2.1.0 Changelog =3D-

all_packages         2.0.7 --> 2.1.0
--------------------------------------
ogrsc_restart       +1.0-1


-=3D 2.0.7 Changelog =3D-

all_packages         2.0.6 --> 2.0.7
--------------------------------------
oglib_variantconfig  2.0-1 --> 2.1-1 (Added "found?" outputs to Read =
VIs)


-=3D 2.0.6 Changelog =3D-

all_packages         2.0.5 --> 2.0.6
--------------------------------------
oglib_lvdata         2.0-1 --> 2.1-1 (+Variant Constant and palette mod)


-=3D 2.0.5 Changelog =3D-

all_packages         2.0.4 --> 2.0.5
--------------------------------------
ogrsc_dynamicpalette 0.5-1 --> 0.6-1 (Added 2D Dynamic Palette)


-=3D 2.0.4 Changelog =3D-

all_packages         2.0.3 --> 2.0.4
--------------------------------------
ogrsc_dynamicpalette 0.4-1 --> 0.5-1 (Added LV7.0 support for Mac OS X)


-=3D 2.0.3 Changelog =3D-

all_packages         2.0.2 --> 2.0.3
--------------------------------------
ogrsc_dynamicpalette 0.3-1 --> 0.4-1 (Fixed LV7.0 platform specific =
support)


-=3D 2.0.2 Changelog =3D-

all_packages         2.0.1 --> 2.0.2
--------------------------------------
oglib_appcontrol     2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem)
oglib_file           2.1-1 --> 2.1-2 (Fixed non-Windows Install Problem)
oglib_lvzip          2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem)
ogrsc_dynamicpalette 0.2-1 --> 0.3-1 (Added LV6.0/6.1 and Linux support)


-=3D 2.0.1 Changelog =3D-

all_packages         2.0   --> 2.0.1
----------------------------------------------------------
oglib_file           2.0-1 --> 2.1-1

lvdata-2.2 released

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

<http://sourceforge.net/projects/opengtoolkit/>

-=3D oglib_lvdata-2.2-1.ogp =3D-


Changes from 2.1-1 --> 2.2-1
--------------------------------
2003-12-02

[FIX] VArray palette menu was missing 'Array to Array of VData'
[FIX] 'Array of VData to VArray' error cluster names were reversed


Changes from 2.0-1 --> 2.1-1
--------------------------------
2003-11-17

* New VI - "Variant Constant" is a "merged VI" that was added to the
palette. This allows users to drop a Variant constant onto the block
diagram.
* Palette Change - Added "Variant Constant" and "Get TDEnum from Data" =
to
the Palette


Changes from 1.6-1 --> 2.0-1
--------------------------------
2003-07-03

* Cosmetic - "Array Dim(s) from TD.vi", "Parse String with TDs.vi", =
"Strip
Units.vi" - removed ".vi" extension from VI Window Appearance for =
palette VI
title
* New VI - "Remove Typedefs from Variant.vi"
* Added "Remove Typedefs from Variant.vi" to "Type Descriptor" =
subpalette.


2003-05-06

* New VI - "Get Array Element Default Data.vi"
* New VI - "Unwrap VVariant"
* New suPalette - VVariant
* Added Variant primitives to Data Tools Root palette.
* Addtion to VArray Palette - "Get Array Element Default Data.vi"


2003-04-24 merge from the branch unit_dev

* Added Typedefs:
** Type Descriptor.ctl >>> array of I16. All VIs using a TD are now =
linked
to this typedef.
** Base Units.ctl  >>> an enum typedef for base units as described in =
App
Note 154=20
** Physical Units.ctl >>> a cluster of {Base Unit, Exponent}

* Added VIs:
** Array Dim(s) from TD.vi >>> we had only one with variant input.
** Get Element TD from Array TD.vi >>> we had only one with variant =
input.
** Get Physical Units from TD.vi >>> outputs an array of Physical Units =
each
base unit with its exponent
** Get Physical Units.vi >>> same as previous except for variant input.

--------------------------------
2003-04-23 *** 1.6 Released ***
--------------------------------

FW: Dec 2nd OpenG Group Meeting (Tonight)

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

Hello All,

Tonight's OpenG Group meeting (6:30PM PST) will be held online via =
webcast
(no physical meeting in Mountain View).  Webcast info may be found at
http://openg.org/webcast/ .  At this meeting we will discuss software
licensing and specifically the new NI Software License Agreement.  As of
LabVIEW 7.0 the language of the National Instruments Software License
Agreement has changed. It appears to provide National Instruments with =
much
more protection of their interests, but also to be potentially more
restrictive for end users. We will discuss these changes and talk about =
the
possible implications. There are portions of the new NISLA that =
potentially
affect OpenG, and we are in the process of discussing the intent and
language of the NISLA with National Instruments. This meeting will =
provide
an opportunity to learn about the changes, get an update of ongoing
discussions with NI, and to discuss the NISLA and software licensing, in
general.

You can find meeting information online at http://openg.org/meetings/ .  =


Regards,

-Jim Kring

------------------

December 2nd, 2003 - OpenG User and Developer Group Meeting=20
Come learn about and participate in the open source LabVIEW community =
and
projects. You can participate in OpenG group meeting via webcast =
(webcast
starts at 6:30pm)=20

When: Tuesday 12/01/2003 || 6:30 p.m. - 9:00 p.m. Pacific Standard Time
(PST) UTC/GMT -8 hours=20

Where: Online via webcast and conference call

Online Webcast Info:=20
Visit http://OpenG.org/webcast/=20
Or email jk...@op... for information on how to attend the online
webcast.=20

Agenda=20

6:30 p.m. - First-Timers Introductions, Firing up the web cast=20

6:45 p.m. - Announcements
* OpenG Toolkit 2.0=20
* OpenG Package Installer 1.0=20
* Dynamic Palette View

7:15 p.m. - NI Software License Agreement=20
As Open Source Developers, licensing of software products is something =
that
we should all know a little bit about. As of LabVIEW 7.0 the language of =
the
National Instruments Software License Agreement has changed. It appears =
to
provide National Instruments with much more protection of their =
interests,
but=20
also to be potentially more restrictive for end users. We will discuss =
these
changes and talk about the possible implications. There are portions of =
the
new NISLA that potentially affect OpenG, and we are in the process of
discussing the intent and language of the NISLA with National =
Instruments.
This meeting will provide an opportunity to learn about the changes, get =
an
update of ongoing discussions with NI, and to discuss the NISLA and =
software
licensing, in general.=20

9:00 pm Adjourn

=20

RE: variantconfig - missing keys

[Michael C. A. <mic...@im...>]

It would be nice if the returned data structure was returned in a format
that optionally included all the keys, whether INI data was found or the
default was used, and what the value was. Where I'm going with this is that,
in the event of an error/lack of data, it might be useful to be able to pump
this into a slightly modified version of the Universal Probe, which would
then display the cluster data in the tree and indicate if the data came from
INI or default.

-----Original Message-----
From: ope...@li...
[mailto:ope...@li...]On Behalf Of
Jim Kring
Sent: Tuesday, December 02, 2003 2:34 AM
To: ope...@li...
Subject: variantconfig - missing keys


Someone has requested a feature for the Variant Configuration File I/O
(variantconfig) library.  Here is the request:

########################################
Together with the indication "Key found", it would be handy if - for example
- "Read INI-cluster" would have an extra stringoutput that contains the
name(s) of the missing key(s) so the user knows where to look in the
INI-file.
########################################

I was thinking that there are really two things that you want to test
against:

1) Which sections/keys are in the INI file but not in the LV data structure
2) Which sections/keys are in the LV data structure but not in the INI file.

The latter (2) is more important, IMO, since the user may want notification
as to which elements were populated with default values.  The former (1) is
useful when a data structure changes and one might wish to flush the data in
the INI file to remove stale sections/keys.

So, the question that I have, is how best to implement this feature?  It
might be useful to return the missing sections/keys in a programmatically
useful data structure (more than just a string containing a list of missing
sections/keys)

The 'missing sections' could be implemented simply as an array of strings --
one element for each missing section.  However, the 'missing keys' structure
would be a little more complicated because we would need to include the
section owning the missing keys.  This could be implemented as an array of
section clusters, where each section cluster contains the name of the
section and the keys that are missing from the section.  This is shown below
(where {} denotes a cluster and [] denotes an array):

[ { section1, [ key1, key2, ... ] }, { section2, [ key1, key2, ... ] }, ...
]

Any thoughts?

-Jim



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
OpenGToolkit-Developers mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers

variantconfig - missing keys

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

Someone has requested a feature for the Variant Configuration File I/O
(variantconfig) library.  Here is the request:

########################################
Together with the indication "Key found", it would be handy if - for =
example
- "Read INI-cluster" would have an extra stringoutput that contains the
name(s) of the missing key(s) so the user knows where to look in the
INI-file.
########################################

I was thinking that there are really two things that you want to test
against:

1) Which sections/keys are in the INI file but not in the LV data =
structure
2) Which sections/keys are in the LV data structure but not in the INI =
file.

The latter (2) is more important, IMO, since the user may want =
notification
as to which elements were populated with default values.  The former (1) =
is
useful when a data structure changes and one might wish to flush the =
data in
the INI file to remove stale sections/keys.

So, the question that I have, is how best to implement this feature?  It
might be useful to return the missing sections/keys in a =
programmatically
useful data structure (more than just a string containing a list of =
missing
sections/keys)

The 'missing sections' could be implemented simply as an array of =
strings --
one element for each missing section.  However, the 'missing keys' =
structure
would be a little more complicated because we would need to include the
section owning the missing keys.  This could be implemented as an array =
of
section clusters, where each section cluster contains the name of the
section and the keys that are missing from the section.  This is shown =
below
(where {} denotes a cluster and [] denotes an array):

[ { section1, [ key1, key2, ... ] }, { section2, [ key1, key2, ... ] }, =
...
]

Any thoughts?

-Jim

appcontrol-2.1 released

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

<http://sourceforge.net/projects/opengtoolkit/>

-= oglib_appcontrol-2.1-1.ogp =-


Changes from 2.0-2 --> 2.1-1
--------------------------------
2003-12-01
[FIX] 'Mangle VI Name' window title no longer shows '__ogtk'