Menu
▾
▴
opengtoolkit-developers — OpenG Toolkit developers mailing list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(53) |
Nov
(66) |
Dec
(24) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(5) |
Mar
(72) |
Apr
(15) |
May
|
Jun
|
Jul
(10) |
Aug
(2) |
Sep
(18) |
Oct
(2) |
Nov
|
Dec
(6) |
| 2005 |
Jan
(41) |
Feb
(28) |
Mar
(14) |
Apr
(18) |
May
(10) |
Jun
(6) |
Jul
(5) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
|
From: Christophe S. <chr...@ep...> - 2003-11-09 08:19:23
|
Jim, Rolf, I second Rolf in the fact that a generic IOPort driver might be a quite large project. On the other hand a serial driver sounds like a reasonable starting point. Now regarding the Mac, there is no serial port built-in anymore. If you want one you should either replace your internal modem or use an usb-serial converter. On the other hand you can "route" your serial line to a bluetooth connection to talk to other devices such as phone, PDAs, etc. So there will be some use for such driver. There is no native parallel port on the Mac (I guess you all know it) but some external hardware provide this extension. I've some code for to access the serial port that worked quite well under OS9, I haven't done anything with OSX, but I guess this should not be too difficult. I guess the first step will be to define what functionalities we want in this driver and then see what can be done under each platforms. I'll explore what is possible under OSX and let you know Have a good week-end Chris > From: Rolf Kalbermatter <rol...@ci...> > Reply-To: rol...@ci... > Date: Fri, 07 Nov 2003 23:55:41 +0100 > To: 'Jim Kring' <ji...@ji...> > Cc: chr...@ep..., ope...@li... > Subject: RE: VISA alternative > > Jim Kring [mailto:ji...@ji...] wrote: > >> If anyone has been reading the info-lv thread on NI VISA licensing, you can >> see that there is a huge demand for an open source solution for serial and >> parallel port I/O. NI only allows you to distribute 10 copies of your built >> application that uses NI "Driver Software". After that, they want $395 per >> copy! Sounds like a good openg project to me. How about OpenGSerp and >> OpenGPortIO? I don't have the background to code up the OS interface or >> sharedlib, but I can help with all other aspects of the project. > > Well, first as I stated earlier on Info-LabVIEW I do not think that the $395 > is for a VISA runtime license but rather for the entire VISA software, with > development libraries, documentation, T&M Explorer, VISA Interactive Control > and whatever there is. Anything else would be stupid and completely unlogical > to explain, as you can buy some NI products which come with VISA for not > much more than that amount. > > Second I was thinking about creating an OpenG PortIO driver which supports > both the slow but simple register access of the NI solution as well as an > alternative high speed access, which needs some prior intialization. I have > all the information and even some code for Win32 here but need to clean it > up and prepare a proper LabVIEW solution for it. It will be a source code > release but since you need a Windows DDK installed to compile it, I don't > think there will be many people trying to compile it themselves, so a pre- > compiled binary will be provided as well. I have not a very good idea about > how to go to implement the same under Linux, although it shouldn't be that > difficult, but for Mac I'm completely clueless, nor if there is actually any > possible need for this on the Mac. After all you don't have LPT and COM ports > there ;-) > > Third trying to write a OpenG Serp driver is a pain of a thing to do. Doing > so for one plattform is already quite a serious project, but trying to support > Win32, Linux, and Mac OS X is most probably a major undertaking, requiring > more commitement from several people than most of us are willing and able > to do. > You would have to abstract the Win32 COMM API on one hand, the Linux device > interface on the other and the Macintosh device driver interface (or can one > maybe use the Unix device interface without loosing to much control), which > are completely different in their design, interface, and abstraction. > Of course one could still use the disappeared Device IO Control nodes, which > LabVIEW still supports in 7.0. But there are a number of issues. The Device > IO Control interface in LabVIEW is built to interface with the Mac Device > Manager and can actually be used to call virtually any Mac OS device driver > although it never was really used for anything but the serial port drivers. > On Windows the famous serpdrv acts as a translation between the Mac OS Device > Manger interface used in LabVIEW and the native Win32 COMM API. The > architecture > of this translator driver has never been published and depends on some > internal > tools only available by NI, but has some similarities with creating CINs. > On Linux I'm not exactly sure if a similar serpdrv exists or if the LabVIEW > Device IO Interface nodes map directly to the unix device driver interface. > Problem is, that I'm fairly sure that NI tries to completely disable support > for this interface in one of the next major releases. > So the only viable solution would really be over a shared library interface > which in itself should work quite fine as proven in lvzlib and to a lesser > extend in labpython. > Neverthless serial port programming on Win32 API level in a generic way, and > not just for a particular device, is anything but pleasant, and other systems > won't be much simpler here. > > Rolf Kalbermatter > > |
|
From: Rolf K. <rol...@ci...> - 2003-11-08 10:58:45
|
Jim Kring [mailto:ji...@ji...] wrote: > We'll have to see what NI's final word is. I'm pretty=20 > concerned since some folks I know are using VISA Serial > in an embedded application that is a shipping product. > BTW, what sort of non-NI hardware can NI-VISA be used > with? Serial port, USB port, Ethernet, VXI any others? > Can a non-NI GPIB boards be used with NI-VISA? I think so. NIs Tulip VISA passport driver (don't ask me about the reason for that name, I wouldn't know at all) is supposedly a driver to interface to the HP-GPIB driver and possibly some other HP hardware such as their GPIB to VXI controller. Rolf Kalbermatter |
|
From: Jim K. <ji...@ji...> - 2003-11-08 08:03:23
|
Mike, We'll have to see what NI's final word is. I'm pretty concerned since some folks I know are using VISA Serial in an embedded application that is a shipping product. BTW, what sort of non-NI hardware can NI-VISA be used with? Serial port, USB port, Ethernet, VXI any others? Can a non-NI GPIB boards be used with NI-VISA? -Jim > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] > On Behalf Of Michael Ashe > Sent: Friday, November 07, 2003 9:20 PM > To: ope...@li...; > ope...@li... > Subject: Re: OpenGToolkit-Developers digest > > > Hi Kevin, others, > > I haven't chimed in yet on this VISA issue, but it bears on > not only the OpenG Toolkit, but very heavily on OSTE as well. > I would like to distribute OSTE in executable form as well as > the source code, with drivers and code modules, but with NI's > licensing it might be pretty tough. Open(G)VISA would help a > lot. OSTE's grandfather was a military functional test > system that was very heavily based on VXI and GPIB. Without > VISA or the older VXI and GPIB drivers we'd be hobbled. > Worse, NI could take OSTE, add VISA and distribute for less > than the $395.00 of an outside license. > > Any thoughts? Lastly, I think I am going to try to find and > dust off my old LabVIEW 3.1 and 4.1 versions to look back > through the old pre-VISA driver stuff. > > Cheers, > Mike Ashe > OSTE Project Manager > > ---- Kevin Valentine <k.v...@ve...> wrote: > > On 2003.11.07 17:10 > > ope...@li... wrote: > > > Date: Fri, 7 Nov 2003 22:09:20 -0000 > > > To: "ope...@li..." > > > <ope...@li...> > > > Subject: VISA alternative > > > From: "Jim Kring" <ji...@ji...> > > > Cc: <rol...@ci...>, <chr...@ep...> > > > Reply-To: ope...@li... > > > > > > If anyone has been reading the info-lv thread on NI VISA > licensing, > > > you can > > > see that there is a huge demand for an open source > solution for serial and > > > parallel port I/O. NI only allows you to distribute 10 > copies of your built > > > application that uses NI "Driver Software". After that, > they want $395 per > > > copy! Sounds like a good openg project to me. How about > OpenGSerp and > > > OpenGPortIO? I don't have the background to code up the > OS interface or > > > sharedlib, but I can help with all other aspects of the project. > > > > > > -Jim > > > > > > > Wow, that is such a cool idea! Why not call it OpenG-VISA? > Covers it > > all: GPIB, RS232, ethernet, etc. Haven't seen the info-lv thread (I > > just subscibed). Did a search for open source visa and found one > > place: > > > > http://www.pnpi.spb.ru/~bazhenov/atel/English/whatVISA.htm > > > > They refer to Open-Visa which they claim to be an open > source version > > of visa. There's nothing more on their site regarding this. Googled > > more on open-visa, still nothing. > > > > Checked out sourceforge.net found these: > > http://sourceforge.net/projects/linux-gpib/ > > http://sourceforge.net/projects/gpib-tcl/ > > http://sourceforge.net/projects/gpib82357a/ > > http://sourceforge.net/projects/freedaq/ > > http://sourceforge.net/projects/libgpib/ > > > > Am I correct in thinking that we would need these hardware drivers? > > I'm guessing that anything that NI has produced, even though open > > source, has the licensing restrictions you noted above. If we cant' > > touch anything of NI's then that's fine. Looks like there's > enough out > > there for us to get started :-) > > > > How much work will comforming to the VISA spec involve? Went to the > > vxipnp.org and dl'ed the spec (vpp-4.3). Suppose I can answer this > > myself as I read through it (285 pages). Perhaps you're right about > > breaking it up into two separate projects, for now. > > > > -kevin > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, > and more! http://www.apachecon.com/ > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > |
|
From: Jim K. <ji...@ji...> - 2003-11-08 07:53:01
|
Hey Dan, Thanks for the comments. Regarding termonology and definitions, there = is a lot of flux of ideas right now and things can certainly change. After = doing a little review of my OOP text books, I agree that the terms "Abstract Method/Class" do have strict OOP definitions and that it would probably = be a bad idea to use the word "Abstract" if we didn't adhere to the OOP definition that it cannot also have its own implementation. Maybe we = should decide exactly what OOP features we want to impliment and how, and then decide what to call our constructs. One problem that we will have is = that, since the LV compiler isn't enforcing the OOP constructs, we probably = can't check/enforce most things until run-time (like checking if a class that inherits from a purely abstract class implements all of the abstract methods). The more constructs we have, the more work that the wizard = will have to do. For example, if an abstract class is special, it might need = its own template. -Jim > -----Original Message----- > From: ope...@li...=20 > [mailto:ope...@li...]=20 > On Behalf Of Dan Ponce > Sent: Friday, November 07, 2003 2:49 PM > To: ope...@li... > Subject: RE: [opengoop inheritance] Virtual Methods should be=20 > called Dynamic Methods >=20 >=20 > I think abstract is the wrong term. The OpenG definition of=20 > a"Virtual Method" is "A Virtual Method is one which may be=20 > overrided by a descendant class. It is created from a special=20 > Virtual Method template, that has the ability to look for and=20 > dynamically execute descendent class implementations of the=20 > method, or else call its own implementation of the method. " =20 > It is clearly not an abstract method, at least as the term is=20 > used in Java. Abstract methods do not have implementations. >=20 > I don't think it is confusing to use the term Virtual Method,=20 > as here it is used in the same way as in Endevo's GOOP Wizard=20 > 3. If there is a need to use a different term, and if=20 > Dynamic isn't quite right, how about something along the=20 > lines of Overridable Base Method or Dynamically Overridable Method. >=20 > On a slight different topic, I do think there needs to be an=20 > Abstract Method construct. The way Endevo handled it seems=20 > to be an afterthought and has at least one flaw, according to=20 > their white paper. >=20 > ----- Original Message ----- --__--__-- >=20 > Message: 2 > From: "Jim Kring" <ji...@ji...> > To: <ope...@li...> > Subject: RE: [opengoop inheritance] Virtual Methods should be=20 > called Dynamic Methods > Date: Fri, 7 Nov 2003 00:52:58 -0800 > Reply-To: ope...@li... >=20 > Niels and Bj=3DF8rnar, >=20 > After listening to the arguments you both make, I agree that=20 > "abstract" might be the best term to use, rather than=20 > "dynamic". Also, I think =3D that "prototype" has an OOP=20 > design pattern (Gang of Four) definition and "template" has=20 > an edit-time connotation, which make these two choices =3D not=20 > very attractive. >=20 > -Jim >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest=20 > developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV,=20 > and more! http://www.apachecon.com/=20 > _______________________________________________ > OpenGToolkit-Developers mailing list=20 > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers >=20 |
|
From: Michael A. <mic...@im...> - 2003-11-08 05:20:21
|
Hi Kevin, others, I haven't chimed in yet on this VISA issue, but it bears on not only the OpenG Toolkit, but very heavily on OSTE as well. I would like to distribute OSTE in executable form as well as the source code, with drivers and code modules, but with NI's licensing it might be pretty tough. Open(G)VISA would help a lot. OSTE's grandfather was a military functional test system that was very heavily based on VXI and GPIB. Without VISA or the older VXI and GPIB drivers we'd be hobbled. Worse, NI could take OSTE, add VISA and distribute for less than the $395.00 of an outside license. Any thoughts? Lastly, I think I am going to try to find and dust off my old LabVIEW 3.1 and 4.1 versions to look back through the old pre-VISA driver stuff. Cheers, Mike Ashe OSTE Project Manager ---- Kevin Valentine <k.v...@ve...> wrote: > On 2003.11.07 17:10 ope...@li... wrote: > > Date: Fri, 7 Nov 2003 22:09:20 -0000 > > To: "ope...@li..." <ope...@li...> > > Subject: VISA alternative > > From: "Jim Kring" <ji...@ji...> > > Cc: <rol...@ci...>, <chr...@ep...> > > Reply-To: ope...@li... > > > > If anyone has been reading the info-lv thread on NI VISA licensing, you can > > see that there is a huge demand for an open source solution for serial and > > parallel port I/O. NI only allows you to distribute 10 copies of your built > > application that uses NI "Driver Software". After that, they want $395 per > > copy! Sounds like a good openg project to me. How about OpenGSerp and > > OpenGPortIO? I don't have the background to code up the OS interface or > > sharedlib, but I can help with all other aspects of the project. > > > > -Jim > > > > Wow, that is such a cool idea! Why not call it OpenG-VISA? Covers it all: GPIB, RS232, ethernet, etc. Haven't seen the info-lv thread (I just subscibed). Did a search for open source visa and found one place: > > http://www.pnpi.spb.ru/~bazhenov/atel/English/whatVISA.htm > > They refer to Open-Visa which they claim to be an open source version of visa. There's nothing more on their site regarding this. Googled more on open-visa, still nothing. > > Checked out sourceforge.net found these: > http://sourceforge.net/projects/linux-gpib/ > http://sourceforge.net/projects/gpib-tcl/ > http://sourceforge.net/projects/gpib82357a/ > http://sourceforge.net/projects/freedaq/ > http://sourceforge.net/projects/libgpib/ > > Am I correct in thinking that we would need these hardware drivers? I'm guessing that anything that NI has produced, even though open source, has the licensing restrictions you noted above. If we cant' touch anything of NI's then that's fine. Looks like there's enough out there for us to get started :-) > > How much work will comforming to the VISA spec involve? Went to the vxipnp.org and dl'ed the spec (vpp-4.3). Suppose I can answer this myself as I read through it (285 pages). Perhaps you're right about breaking it up into two separate projects, for now. > > -kevin |
|
From: Kevin V. <k.v...@ve...> - 2003-11-07 23:15:02
|
On 2003.11.07 17:10 ope...@li... wrote: > Date: Fri, 7 Nov 2003 22:09:20 -0000 > To: "ope...@li..." <ope...@li...> > Subject: VISA alternative > From: "Jim Kring" <ji...@ji...> > Cc: <rol...@ci...>, <chr...@ep...> > Reply-To: ope...@li... > > If anyone has been reading the info-lv thread on NI VISA licensing, you can > see that there is a huge demand for an open source solution for serial and > parallel port I/O. NI only allows you to distribute 10 copies of your built > application that uses NI "Driver Software". After that, they want $395 per > copy! Sounds like a good openg project to me. How about OpenGSerp and > OpenGPortIO? I don't have the background to code up the OS interface or > sharedlib, but I can help with all other aspects of the project. > > -Jim > Wow, that is such a cool idea! Why not call it OpenG-VISA? Covers it all: GPIB, RS232, ethernet, etc. Haven't seen the info-lv thread (I just subscibed). Did a search for open source visa and found one place: http://www.pnpi.spb.ru/~bazhenov/atel/English/whatVISA.htm They refer to Open-Visa which they claim to be an open source version of visa. There's nothing more on their site regarding this. Googled more on open-visa, still nothing. Checked out sourceforge.net found these: http://sourceforge.net/projects/linux-gpib/ http://sourceforge.net/projects/gpib-tcl/ http://sourceforge.net/projects/gpib82357a/ http://sourceforge.net/projects/freedaq/ http://sourceforge.net/projects/libgpib/ Am I correct in thinking that we would need these hardware drivers? I'm guessing that anything that NI has produced, even though open source, has the licensing restrictions you noted above. If we cant' touch anything of NI's then that's fine. Looks like there's enough out there for us to get started :-) How much work will comforming to the VISA spec involve? Went to the vxipnp.org and dl'ed the spec (vpp-4.3). Suppose I can answer this myself as I read through it (285 pages). Perhaps you're right about breaking it up into two separate projects, for now. -kevin |
|
From: Dan P. <Dan...@ga...> - 2003-11-07 23:09:17
|
> On a slight different topic, I do think there needs to be an Abstract Method > construct. The way Endevo handled it seems to be an afterthought and has at > least one flaw, according to their white paper. I misspoke here. I should have said Abstract Class. Dan. |
|
From: Rolf K. <rol...@ci...> - 2003-11-07 22:53:51
|
Jim Kring [mailto:ji...@ji...] wrote: > If anyone has been reading the info-lv thread on NI VISA licensing, = you can=20 > see that there is a huge demand for an open source solution for serial = and=20 > parallel port I/O. NI only allows you to distribute 10 copies of your = built=20 > application that uses NI "Driver Software". After that, they want = $395 per=20 > copy! Sounds like a good openg project to me. How about OpenGSerp = and=20 > OpenGPortIO? I don't have the background to code up the OS interface = or=20 > sharedlib, but I can help with all other aspects of the project. Well, first as I stated earlier on Info-LabVIEW I do not think that the = $395 is for a VISA runtime license but rather for the entire VISA software, = with development libraries, documentation, T&M Explorer, VISA Interactive = Control and whatever there is. Anything else would be stupid and completely = unlogical to explain, as you can buy some NI products which come with VISA for not much more than that amount. Second I was thinking about creating an OpenG PortIO driver which = supports both the slow but simple register access of the NI solution as well as = an alternative high speed access, which needs some prior intialization. I = have all the information and even some code for Win32 here but need to clean = it up and prepare a proper LabVIEW solution for it. It will be a source = code release but since you need a Windows DDK installed to compile it, I = don't think there will be many people trying to compile it themselves, so a = pre- compiled binary will be provided as well. I have not a very good idea = about how to go to implement the same under Linux, although it shouldn't be = that difficult, but for Mac I'm completely clueless, nor if there is actually = any possible need for this on the Mac. After all you don't have LPT and COM = ports there ;-) Third trying to write a OpenG Serp driver is a pain of a thing to do. = Doing so for one plattform is already quite a serious project, but trying to = support Win32, Linux, and Mac OS X is most probably a major undertaking, = requiring more commitement from several people than most of us are willing and = able to do. You would have to abstract the Win32 COMM API on one hand, the Linux = device interface on the other and the Macintosh device driver interface (or can = one maybe use the Unix device interface without loosing to much control), = which are completely different in their design, interface, and abstraction.=20 Of course one could still use the disappeared Device IO Control nodes, = which LabVIEW still supports in 7.0. But there are a number of issues. The = Device IO Control interface in LabVIEW is built to interface with the Mac = Device Manager and can actually be used to call virtually any Mac OS device = driver although it never was really used for anything but the serial port = drivers. On Windows the famous serpdrv acts as a translation between the Mac OS = Device Manger interface used in LabVIEW and the native Win32 COMM API. The = architecture of this translator driver has never been published and depends on some = internal tools only available by NI, but has some similarities with creating = CINs. On Linux I'm not exactly sure if a similar serpdrv exists or if the = LabVIEW Device IO Interface nodes map directly to the unix device driver = interface. Problem is, that I'm fairly sure that NI tries to completely disable = support for this interface in one of the next major releases. So the only viable solution would really be over a shared library = interface which in itself should work quite fine as proven in lvzlib and to a = lesser extend in labpython. Neverthless serial port programming on Win32 API level in a generic way, = and not just for a particular device, is anything but pleasant, and other = systems won't be much simpler here. Rolf Kalbermatter |
|
From: Dan P. <Dan...@ga...> - 2003-11-07 22:49:56
|
I think abstract is the wrong term. The OpenG definition of a"Virtual Method" is "A Virtual Method is one which may be overrided by a descendant class. It is created from a special Virtual Method template, that has the ability to look for and dynamically execute descendent class implementations of the method, or else call its own implementation of the method. " It is clearly not an abstract method, at least as the term is used in Java. Abstract methods do not have implementations. I don't think it is confusing to use the term Virtual Method, as here it is used in the same way as in Endevo's GOOP Wizard 3. If there is a need to use a different term, and if Dynamic isn't quite right, how about something along the lines of Overridable Base Method or Dynamically Overridable Method. On a slight different topic, I do think there needs to be an Abstract Method construct. The way Endevo handled it seems to be an afterthought and has at least one flaw, according to their white paper. ----- Original Message ----- --__--__-- Message: 2 From: "Jim Kring" <ji...@ji...> To: <ope...@li...> Subject: RE: [opengoop inheritance] Virtual Methods should be called Dynamic Methods Date: Fri, 7 Nov 2003 00:52:58 -0800 Reply-To: ope...@li... Niels and Bj=F8rnar, After listening to the arguments you both make, I agree that "abstract" might be the best term to use, rather than "dynamic". Also, I think = that "prototype" has an OOP design pattern (Gang of Four) definition and "template" has an edit-time connotation, which make these two choices = not very attractive. -Jim |
|
From: Jim K. <ji...@ji...> - 2003-11-07 22:09:21
|
If anyone has been reading the info-lv thread on NI VISA licensing, you can see that there is a huge demand for an open source solution for serial and parallel port I/O. NI only allows you to distribute 10 copies of your built application that uses NI "Driver Software". After that, they want $395 per copy! Sounds like a good openg project to me. How about OpenGSerp and OpenGPortIO? I don't have the background to code up the OS interface or sharedlib, but I can help with all other aspects of the project. -Jim |
|
From: Jim K. <ji...@ji...> - 2003-11-07 19:18:33
|
Derek, I have created a section on the OpenGOOP Inheritance Feasibility Page called "glossary of terms". Please feel free to add content to this and other pages. Any registered user can edit most OpenG.org pages. If you can think of better ways to organize this information, please speak up. So far I have just been dumping infomation onto this, and other, pages. <http://www.openg.org/tiki/tiki-index.php?page=OpenG+Fwk% 3A+OpenGOOP+Inheritance+Feasibility> -Jim Derek Shpuniarsky <ds...@ya...> said: > Hi All, > > I'm new to the list so let me first introduce myself > as quickly as possible: > Derek Shpuniarsky > San Jose/SF Bay Area > Many years of LabVIEW development > Some textbook knowledge of OOP through a software > engineering book and learning (beginner level) C++. > > I'm loooking forward to working on this project with > all of you and hope I am able to contribute as much as > I learn. > > Now M2C... > > It seems to me, the best name for these types of > methods/classes depends on the context. During 'high > level' system design (i.e. at the stage where we only > care that we will be using an oscilloscope and not an > HP<whatever>) it would be best to call them Abstract > Methods/Classes since they aren't tied to a particular > implementation. When implementing them in the code it > would be best to use the term Dynamic, as in "Dynamic > Method/Class Call Interface", since it describes its > function. > > This leads me to agree with Jim, that we should use > the term Abstract Method/Class. However the definition > for this term should contain 'dynamic' since it > describes how it is implemented. > > BTW, has a glossary of terms been started? > > Derek > > --- Jim Kring <ji...@ji...> wrote: > > Niels and Bjørnar, > > > > After listening to the arguments you both make, I > > agree that "abstract" > > might be the best term to use, rather than > > "dynamic". Also, I think that > > "prototype" has an OOP design pattern (Gang of Four) > > definition and > > "template" has an edit-time connotation, which make > > these two choices not > > very attractive. > > > > -Jim > > > > > -----Original Message----- > > > From: > > ope...@li... > > > > > > [mailto:ope...@li...] > > > > > On Behalf Of Svingen Bjørnar > > > Sent: Friday, November 07, 2003 12:23 AM > > > To: > > 'ope...@li...' > > > Subject: RE: [opengoop inheritance] Virtual > > Methods should be > > > called Dynamic Methods > > > > > > > > > I only have limited experience with OOP from C++ > > some years > > > ago. IMO virtual, dynamic and abstract are > > misleading, since > > > what you are defining is more of a template > > (dynamic > > > template) or prototype. "Dynamic" is not that far > > off seen in > > > context, but when left alone it sounds strange. > > All in all i > > > think "abstract" is better. > > > > > > Just my $0.02 > > > > > > > > > > > > > -----Original Message----- > > > > From: Niels Harre [mailto:ni...@ha...] > > > > Sent: 6. november 2003 23:22 > > > > To: > > ope...@li... > > > > Subject: Re: [opengoop inheritance] Virtual > > Methods should > > > be called > > > > Dynamic Methods > > > > > > > > > > > > Howdy, > > > > > > > > I've given the suggestion some thought.. I agree > > that > > > > "Virtual Virtual > > > > Instruments" doesn't sound too good. But I'm not > > too sure we > > > > should change > > > > the name to "Dynamic Methods". > > > > > > > > The case with double adjectives in "Virtual > > Virtual > > > > Instrument" may also > > > > arise when using "Dynamic": Consider the > > explanation "A > > > > dynamic method > > > > dynamically calls (using VI server) a method in > > a descendant > > > > class". In my > > > > opinion pretty much the same, and too close to > > the underlying > > > > technology. > > > > > > > > The question is: What is a "Virtual Method" > > thought to accomplish? > > > > > > > > - it defines an interface (the connector pane). > > > > - it has no implementation in the class where it > > is defined. > > > > - its implementation is deferred to a descendant > > class. > > > > > > > > That is an abstraction... consequently I suggest > > that > > > > "Virtual Methods" > > > > should be called "Abstract Methods". Also, - > > taking it a step > > > > further - > > > > what about classes having the same features as > > listed > > > > above... Should they > > > > be called "Dynamic Classes". The class itself is > > not dynamic. > > > > However, - > > > > "Abstract Classes" are abstractions... > > > > > > > > Please let me know what you think. Even though I > > don't belive > > > > we should > > > > spend too much time on this. > > > > > > > > All the best > > > > Niels > > > > > > > > At 20:16 05-11-2003 +0000, Jim wrote: > > > > >Hello All, > > > > > > > > > >Stephen Mercer, a member of the LabVIEW > > Development Team at > > > > NI, attended our > > > > >group meeting last night. During the OpenGOOP > > Inheritance > > > > discussion he > > > > >recommended that we call Virtual Methods > > "Dynamic Methods" > > > > to avoid confusion > > > > >with the term Virtual Instruments (we don't > > want Virtual Virtual > > > > >Instruments). I like this idea. Any > > objections or comments? > > > > > > > > > >-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 > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > 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 > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > 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 > > > > > > > > > > > > ------------------------------------------------------- > > 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 > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > -- |
|
From: Derek S. <ds...@ya...> - 2003-11-07 17:44:55
|
Hi All, I'm new to the list so let me first introduce myself as quickly as possible: Derek Shpuniarsky San Jose/SF Bay Area Many years of LabVIEW development Some textbook knowledge of OOP through a software engineering book and learning (beginner level) C++. I'm loooking forward to working on this project with all of you and hope I am able to contribute as much as I learn. Now M2C... It seems to me, the best name for these types of methods/classes depends on the context. During 'high level' system design (i.e. at the stage where we only care that we will be using an oscilloscope and not an HP<whatever>) it would be best to call them Abstract Methods/Classes since they aren't tied to a particular implementation. When implementing them in the code it would be best to use the term Dynamic, as in "Dynamic Method/Class Call Interface", since it describes its function. This leads me to agree with Jim, that we should use the term Abstract Method/Class. However the definition for this term should contain 'dynamic' since it describes how it is implemented. BTW, has a glossary of terms been started? Derek --- Jim Kring <ji...@ji...> wrote: > Niels and Bjørnar, > > After listening to the arguments you both make, I > agree that "abstract" > might be the best term to use, rather than > "dynamic". Also, I think that > "prototype" has an OOP design pattern (Gang of Four) > definition and > "template" has an edit-time connotation, which make > these two choices not > very attractive. > > -Jim > > > -----Original Message----- > > From: > ope...@li... > > > [mailto:ope...@li...] > > > On Behalf Of Svingen Bjørnar > > Sent: Friday, November 07, 2003 12:23 AM > > To: > 'ope...@li...' > > Subject: RE: [opengoop inheritance] Virtual > Methods should be > > called Dynamic Methods > > > > > > I only have limited experience with OOP from C++ > some years > > ago. IMO virtual, dynamic and abstract are > misleading, since > > what you are defining is more of a template > (dynamic > > template) or prototype. "Dynamic" is not that far > off seen in > > context, but when left alone it sounds strange. > All in all i > > think "abstract" is better. > > > > Just my $0.02 > > > > > > > > > -----Original Message----- > > > From: Niels Harre [mailto:ni...@ha...] > > > Sent: 6. november 2003 23:22 > > > To: > ope...@li... > > > Subject: Re: [opengoop inheritance] Virtual > Methods should > > be called > > > Dynamic Methods > > > > > > > > > Howdy, > > > > > > I've given the suggestion some thought.. I agree > that > > > "Virtual Virtual > > > Instruments" doesn't sound too good. But I'm not > too sure we > > > should change > > > the name to "Dynamic Methods". > > > > > > The case with double adjectives in "Virtual > Virtual > > > Instrument" may also > > > arise when using "Dynamic": Consider the > explanation "A > > > dynamic method > > > dynamically calls (using VI server) a method in > a descendant > > > class". In my > > > opinion pretty much the same, and too close to > the underlying > > > technology. > > > > > > The question is: What is a "Virtual Method" > thought to accomplish? > > > > > > - it defines an interface (the connector pane). > > > - it has no implementation in the class where it > is defined. > > > - its implementation is deferred to a descendant > class. > > > > > > That is an abstraction... consequently I suggest > that > > > "Virtual Methods" > > > should be called "Abstract Methods". Also, - > taking it a step > > > further - > > > what about classes having the same features as > listed > > > above... Should they > > > be called "Dynamic Classes". The class itself is > not dynamic. > > > However, - > > > "Abstract Classes" are abstractions... > > > > > > Please let me know what you think. Even though I > don't belive > > > we should > > > spend too much time on this. > > > > > > All the best > > > Niels > > > > > > At 20:16 05-11-2003 +0000, Jim wrote: > > > >Hello All, > > > > > > > >Stephen Mercer, a member of the LabVIEW > Development Team at > > > NI, attended our > > > >group meeting last night. During the OpenGOOP > Inheritance > > > discussion he > > > >recommended that we call Virtual Methods > "Dynamic Methods" > > > to avoid confusion > > > >with the term Virtual Instruments (we don't > want Virtual Virtual > > > >Instruments). I like this idea. Any > objections or comments? > > > > > > > >-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 > > > > > > > > > > > > > ------------------------------------------------------- > > > 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 > > > > > > > > > > ------------------------------------------------------- > > 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 > > > > > > ------------------------------------------------------- > 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 |
|
From: Jim K. <ji...@ji...> - 2003-11-07 09:10:01
|
Hello all,
=20
I have committed the "GeomTest" OpenGOOP Inheritance demo (shown at the
OpenG Group Meeting this past Tuesday) to CVS. It has been relinked to =
the
OpenG Toolkit 2.0. This example is currently the most evolved
implimentation of OpenGOOP inheritance. We are going to continue to do
implimentation work using this example. Once the design has stabilized =
we
will pull the implemenation out of the example and create a template =
class
that can be instanciated with a wizard. To access GeomTest in CVS use:
=20
CVSROOT:
":ext:{SourceForgeUserName}@cvs.opengtoolkit.sourceforge.net:/cvsroot/ope=
ngt
oolkit"
module: "opengoop_inheritance"
=20
The GeomTest example source is located here:
=20
opengoop_inheritance/demos/GeomTest/2003-10-28
=20
-Jim
|
|
From: Jim K. <ji...@ji...> - 2003-11-07 08:52:58
|
Niels and Bj=F8rnar, After listening to the arguments you both make, I agree that "abstract" might be the best term to use, rather than "dynamic". Also, I think = that "prototype" has an OOP design pattern (Gang of Four) definition and "template" has an edit-time connotation, which make these two choices = not very attractive. -Jim > -----Original Message----- > From: ope...@li...=20 > [mailto:ope...@li...]=20 > On Behalf Of Svingen Bj=F8rnar > Sent: Friday, November 07, 2003 12:23 AM > To: 'ope...@li...' > Subject: RE: [opengoop inheritance] Virtual Methods should be=20 > called Dynamic Methods >=20 >=20 > I only have limited experience with OOP from C++ some years=20 > ago. IMO virtual, dynamic and abstract are misleading, since=20 > what you are defining is more of a template (dynamic=20 > template) or prototype. "Dynamic" is not that far off seen in=20 > context, but when left alone it sounds strange. All in all i=20 > think "abstract" is better. >=20 > Just my $0.02 >=20 > =20 >=20 > > -----Original Message----- > > From: Niels Harre [mailto:ni...@ha...] > > Sent: 6. november 2003 23:22 > > To: ope...@li... > > Subject: Re: [opengoop inheritance] Virtual Methods should=20 > be called=20 > > Dynamic Methods > >=20 > >=20 > > Howdy, > >=20 > > I've given the suggestion some thought.. I agree that > > "Virtual Virtual=20 > > Instruments" doesn't sound too good. But I'm not too sure we=20 > > should change=20 > > the name to "Dynamic Methods". > >=20 > > The case with double adjectives in "Virtual Virtual > > Instrument" may also=20 > > arise when using "Dynamic": Consider the explanation "A=20 > > dynamic method=20 > > dynamically calls (using VI server) a method in a descendant=20 > > class". In my=20 > > opinion pretty much the same, and too close to the underlying=20 > > technology. > >=20 > > The question is: What is a "Virtual Method" thought to accomplish? > >=20 > > - it defines an interface (the connector pane). > > - it has no implementation in the class where it is defined. > > - its implementation is deferred to a descendant class. > >=20 > > That is an abstraction... consequently I suggest that > > "Virtual Methods"=20 > > should be called "Abstract Methods". Also, - taking it a step=20 > > further -=20 > > what about classes having the same features as listed=20 > > above... Should they=20 > > be called "Dynamic Classes". The class itself is not dynamic.=20 > > However, -=20 > > "Abstract Classes" are abstractions... > >=20 > > Please let me know what you think. Even though I don't belive > > we should=20 > > spend too much time on this. > >=20 > > All the best > > Niels > >=20 > > At 20:16 05-11-2003 +0000, Jim wrote: > > >Hello All, > > > > > >Stephen Mercer, a member of the LabVIEW Development Team at > > NI, attended our > > >group meeting last night. During the OpenGOOP Inheritance > > discussion he > > >recommended that we call Virtual Methods "Dynamic Methods" > > to avoid confusion > > >with the term Virtual Instruments (we don't want Virtual Virtual=20 > > >Instruments). I like this idea. Any objections or comments? > > > > > >-Jim > > > > > > > > >------------------------------------------------------- > > >This SF.net email is sponsored by: SF.net Giveback Program. Does=20 > > >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/=20 > > >_______________________________________________ > > >OpenGToolkit-Developers mailing list=20 > > >Ope...@li... > >=20 > >> = https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > >=20 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. Does=20 > > 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/=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 > help you create better code? SHARE THE LOVE, and help us 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 |
|
From: <Bjo...@si...> - 2003-11-07 08:23:20
|
I only have limited experience with OOP from C++ some years ago. IMO virtual, dynamic and abstract are misleading, since what you are defining is more of a template (dynamic template) or prototype. "Dynamic" is not that far off seen in context, but when left alone it sounds strange. All in all i think "abstract" is better. Just my $0.02 > -----Original Message----- > From: Niels Harre [mailto:ni...@ha...] > Sent: 6. november 2003 23:22 > To: ope...@li... > Subject: Re: [opengoop inheritance] Virtual Methods should be called > Dynamic Methods > > > Howdy, > > I've given the suggestion some thought.. I agree that > "Virtual Virtual > Instruments" doesn't sound too good. But I'm not too sure we > should change > the name to "Dynamic Methods". > > The case with double adjectives in "Virtual Virtual > Instrument" may also > arise when using "Dynamic": Consider the explanation "A > dynamic method > dynamically calls (using VI server) a method in a descendant > class". In my > opinion pretty much the same, and too close to the underlying > technology. > > The question is: What is a "Virtual Method" thought to accomplish? > > - it defines an interface (the connector pane). > - it has no implementation in the class where it is defined. > - its implementation is deferred to a descendant class. > > That is an abstraction... consequently I suggest that > "Virtual Methods" > should be called "Abstract Methods". Also, - taking it a step > further - > what about classes having the same features as listed > above... Should they > be called "Dynamic Classes". The class itself is not dynamic. > However, - > "Abstract Classes" are abstractions... > > Please let me know what you think. Even though I don't belive > we should > spend too much time on this. > > All the best > Niels > > At 20:16 05-11-2003 +0000, Jim wrote: > >Hello All, > > > >Stephen Mercer, a member of the LabVIEW Development Team at > NI, attended our > >group meeting last night. During the OpenGOOP Inheritance > discussion he > >recommended that we call Virtual Methods "Dynamic Methods" > to avoid confusion > >with the term Virtual Instruments (we don't want Virtual Virtual > >Instruments). I like this idea. Any objections or comments? > > > >-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 > > > > ------------------------------------------------------- > 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 > |
|
From: Niels H. <ni...@ha...> - 2003-11-06 22:22:03
|
Howdy, I've given the suggestion some thought.. I agree that "Virtual Virtual Instruments" doesn't sound too good. But I'm not too sure we should change the name to "Dynamic Methods". The case with double adjectives in "Virtual Virtual Instrument" may also arise when using "Dynamic": Consider the explanation "A dynamic method dynamically calls (using VI server) a method in a descendant class". In my opinion pretty much the same, and too close to the underlying technology. The question is: What is a "Virtual Method" thought to accomplish? - it defines an interface (the connector pane). - it has no implementation in the class where it is defined. - its implementation is deferred to a descendant class. That is an abstraction... consequently I suggest that "Virtual Methods" should be called "Abstract Methods". Also, - taking it a step further - what about classes having the same features as listed above... Should they be called "Dynamic Classes". The class itself is not dynamic. However, - "Abstract Classes" are abstractions... Please let me know what you think. Even though I don't belive we should spend too much time on this. All the best Niels At 20:16 05-11-2003 +0000, Jim wrote: >Hello All, > >Stephen Mercer, a member of the LabVIEW Development Team at NI, attended our >group meeting last night. During the OpenGOOP Inheritance discussion he >recommended that we call Virtual Methods "Dynamic Methods" to avoid confusion >with the term Virtual Instruments (we don't want Virtual Virtual >Instruments). I like this idea. Any objections or comments? > >-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 |
|
From: Jim K. <ji...@ji...> - 2003-11-06 09:05:00
|
I forgot to mention. You will need to manually select the "Dynamic Palette View" as your active palette (after restarting LabVIEW), once you install ogrsc_dynamicpalette. -Jim > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] > On Behalf Of Jim Kring > Sent: Thursday, November 06, 2003 1:02 AM > To: OpenGToolkit-Developers > Subject: OpenG Toolkit 2.0 > > > Hello All, > > I have just released several openg toolkit packages as > version 2.0. You can download them all in the "all_packages" > package (all_packages-2.0.ogp.zip) or individually. Note > that the new "Dynamic Palette View" > (ogrsc_dynamicpalette-0.2-1.ogp) package is currently only > supporting LV7.0 win/linux. I will be working to get 6.0 and > 6.1 supported, and on all platforms. Also note that the > OpenG Package Installer (v0.9) automatically installs the > "palette" package (which creates an "OpenG" custom palette > view). This package/palette is no longer used. > > OpenG Toolkit VIs are now installed at... > > ./user.lib/_OpenG.lib/<package> > > This solves several problems. Also, the Dynamic Palette > View's palette-synched folders are located at... > > ./user.lib/_dynamicpalette_dirs/<mnufilename> > > There is a text file at... > > ./user.lib/_dynamicpalette_dirs/menu_to_dir_map.txt > > ...which tells which folders map to which directories. > Essentially the directories are named after the mnu file that > they are synch'ed to. The OpenG Toolkit does not install VIs > in these folders, only .mnu files that point to VIs beneath... > > ./user.lib/_OpenG.lib/ > > However, users are encouraged to put their own VIs inside of > dynamic palette view folders instead of editing the palettes. > This is the reason that the dynamicpalette_dirs folder is > located beneath user.lib. Both _OpenG.lib and > _dynamicpalette_dirs are preceded by an underscore to prevent > the "User Libraries" palette from noticing them in the > user.lib folder. > > -Jim > > > > -= OpenG Toolkit 2.0 =- > > Please Note: > * dynamicpalette-0.2 is only compatible with LabVIEW 7.0 on > Windows & Linux > * OpenG Toolkit 2.0 packages are name mangled as "*__ogtk.vi" > to avoid namespace collisions with vi.lib > > Included Packages: > * oglib_appcontrol-2.0-1.ogp > * oglib_array-2.0-1.ogp > * oglib_boolean-2.0-1.ogp > * oglib_comparison-2.0-1.ogp > * oglib_error-2.0-1.ogp > * oglib_file-2.0-1.ogp > * oglib_lvdata-2.0-1.ogp > * oglib_lvzip-2.0-1.ogp > * oglib_msgqueue-2.0-1.ogp > * oglib_numeric-2.0-1.ogp > * oglib_string-2.0-1.ogp > * oglib_time-2.0-1.ogp > * oglib_variantconfig-2.0-1.ogp > * ogrsc_dynamicpalette-0.2-1.ogp > > > > > ------------------------------------------------------- > 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 > |
|
From: Jim K. <ji...@ji...> - 2003-11-06 09:01:47
|
Hello All, I have just released several openg toolkit packages as version 2.0. You = can download them all in the "all_packages" package = (all_packages-2.0.ogp.zip) or individually. Note that the new "Dynamic Palette View" (ogrsc_dynamicpalette-0.2-1.ogp) package is currently only supporting = LV7.0 win/linux. I will be working to get 6.0 and 6.1 supported, and on all platforms. Also note that the OpenG Package Installer (v0.9) = automatically installs the "palette" package (which creates an "OpenG" custom palette view). This package/palette is no longer used. OpenG Toolkit VIs are now installed at... ./user.lib/_OpenG.lib/<package> This solves several problems. Also, the Dynamic Palette View's palette-synched folders are located at... ./user.lib/_dynamicpalette_dirs/<mnufilename> There is a text file at... ./user.lib/_dynamicpalette_dirs/menu_to_dir_map.txt ...which tells which folders map to which directories. Essentially the directories are named after the mnu file that they are synch'ed to. The OpenG Toolkit does not install VIs in these folders, only .mnu files = that point to VIs beneath... ./user.lib/_OpenG.lib/ However, users are encouraged to put their own VIs inside of dynamic = palette view folders instead of editing the palettes. This is the reason that = the dynamicpalette_dirs folder is located beneath user.lib. Both _OpenG.lib = and _dynamicpalette_dirs are preceded by an underscore to prevent the "User Libraries" palette from noticing them in the user.lib folder. -Jim =20 -=3D OpenG Toolkit 2.0 =3D- Please Note: * dynamicpalette-0.2 is only compatible with LabVIEW 7.0 on Windows & = Linux * OpenG Toolkit 2.0 packages are name mangled as "*__ogtk.vi" to avoid namespace collisions with vi.lib Included Packages: * oglib_appcontrol-2.0-1.ogp * oglib_array-2.0-1.ogp * oglib_boolean-2.0-1.ogp * oglib_comparison-2.0-1.ogp * oglib_error-2.0-1.ogp * oglib_file-2.0-1.ogp * oglib_lvdata-2.0-1.ogp * oglib_lvzip-2.0-1.ogp * oglib_msgqueue-2.0-1.ogp * oglib_numeric-2.0-1.ogp * oglib_string-2.0-1.ogp * oglib_time-2.0-1.ogp * oglib_variantconfig-2.0-1.ogp * ogrsc_dynamicpalette-0.2-1.ogp |
|
From: Jim K. <ji...@ji...> - 2003-11-05 20:30:07
|
Hello All, Stephen Mercer, a member of the LabVIEW Development Team at NI, attended our group meeting last night. During the OpenGOOP Inheritance discussion he recommended that we call Virtual Methods "Dynamic Methods" to avoid confusion with the term Virtual Instruments (we don't want Virtual Virtual Instruments). I like this idea. Any objections or comments? -Jim |
|
From: Jim K. <ji...@ji...> - 2003-11-05 20:11:52
|
There is an announcement on the OpenG.org front page with a link to the meeting downloads. -Jim |
|
From: Jim K. <ji...@ji...> - 2003-10-30 03:13:38
|
Hello All, I have created an "OpenG Toolkit" navigation menu at OpenG.org, and = added it to the right-hand side-bar, above "Featured Projects". One comment that = I have received from numerous visitors to the website, is that it is hard = to find the OpenG Toolkit downloads. This is one step towards solving that problem. The "OpenG Toolkit" navigation menu looks something like the following: _____________________________ | OpenG Toolkit | |_____________________________| | | | Hom...@Op... | | Pro...@So... | | Documenation | | Development | | Downloads | |_____________________________| Check it out... -Jim |
|
From: Jim K. <ji...@ji...> - 2003-10-30 02:31:44
|
I have added Bug and RFE (Request for Feature Enhancment) categories for each of the OpenG Toolkit packages. This is one important step towards having a more formal development and release process. For each package release, we need to include a listing of all bug fixes and new features in the release notes/changelog. It will be up to the developers working on a toolkit component to capture this information during the development process. Can we automate this somehow? Can CVS be used to automatically generate reports of commits between two tags (for example "rel-1.0" and "rel-1.1")? One idea that I had was to keep a changelog.txt file in each CVS module root folder and commit this file, itself, to CVS. Should a changelog file be included inside a package? -Jim |
|
From: Jim K. <ji...@ji...> - 2003-10-30 01:31:17
|
msgqueue 1.1 released (Thu, 30 Oct 2003 01:10:32 GMT) https://sourceforge.net/project/shownotes.php?release_id=194205 Notes: "Remove Msg Queue Element.vi" is now a LabVIEW version dependent VI. The LabVIEW 7.0 version does not have the "from end (F)" Boolean that was removed from "Remove Queue Element.vi" by NI. Changes: [FIXED] 832742 'Remove Msg Queue Element.vi' is broken in LabVIEW 7.0 |
|
From: Jim K. <ji...@ji...> - 2003-10-29 19:45:25
|
Hello all, OpenGOOP Inheritance is going to be the topic at next Tuesday's group meeting. You can get info on the meeting, including how to attend the webcast, here: http://openg.org/meetings/ Over the course of the next week, I will be posting some questions and comments to the list, for feedback from those of you who are working on = this project. This meeting will be a good opportunity to advertise the = project to other OpenG developers/users/contributors/enthusiasts and get some feedback while we're at it. Regards, -Jim |
|
From: Jim K. <ji...@ji...> - 2003-10-29 06:19:41
|
Jean-Pierre, Yes, all of your statements are in line with what we have been = discussing. I have put together an inheritance example that also implements virtual methods. http://www.OpenG.org/OpenGOOP/GeomTest_2003-10-28.zip I don't have time, right at the moment, to list all of the features of = this example, but if you dive into it, you will find that there are many = comments in the code and I have tried not to make spaghetti ;-) Niels and I have had some chats on MSN Messenger about the design, and = he mentioned that he was going to post some comments (related to the = seperation of public/protected/private data) to the list after I made the example available for download. Hopefully this should make for a good = discussion. BTW, I just realized that sister (and other distant relative) class inheritance refnums do not upcast to their common ancestor at build = array nodes. This is to be expected, but it was not obvious to me, as first. = You will notice in the GeomTest example that I had to first upcast Circle_GF = and Rectangle_GF to GeometricFigure before I could build an array of GeometricFigures. -Jim > -----Original Message----- > From: ope...@li...=20 > [mailto:ope...@li...]=20 > On Behalf Of Jean-Pierre Drolet > Sent: Sunday, October 26, 2003 7:45 AM > To: ope...@li... > Subject: [opengoop] Data Storage and access (was: Re:=20 > [opengoop] Virtual Methods (Abstraction)) >=20 >=20 > Hi all, >=20 > Jim, >=20 >=20 > from what I understand, you'll need many data storage , one=20 > for object protected data and one per class for private data.=20 > If there is a storage for each class level, why don't we put=20 > both protected and private data in the same storage and have=20 > VIs to get access for each class? To construct the whole=20 > object data we still use control templates for the object but=20 > fill it by reading object storage. Specifically, to access=20 > whole object data, the leaf object (as opposed to root) reads=20 > the whole parent data (for its class > level) and bundle its own protected data. >=20 > I see an advantage here as when the whole object data is=20 > accessed, code is executed at each class level so the class=20 > is warned that data is read or modified. Otherwise, when=20 > datastorage is created by the leaf (root), methods to access=20 > the data are simple read/write without the parents (childs=20 > being notified by the change. That's very important for=20 > encapsulation since it the current implementation, the child=20 > can access and modify parent data. >=20 > In some other text based languages, access to data are truly=20 > methods. When you define a property of an object, you also=20 > defines two methods to read and write the property. It is not=20 > simply an assignment to a memory space of the property. The statements >=20 > object.property =3D newvalue > value =3D object.property >=20 > are really executed as methods > object.set_property(newvalue) > value =3D object.get_property() >=20 > This way, data is encapsulated and only the class own methods=20 > can modify class data. >=20 > For OpenGOOP, the "car" object can actually modify the=20 > "speed" property of the parent "vehicle" by setting a new=20 > value in the object cluster but then the vehicle isn't=20 > notified immediatly of the value change. This could be done=20 > if the "car" invokes the "Vehicle Set Speed.vi" method. >=20 > My point is that there is more in object data access than=20 > data storage I/O. If the class could store its own data and=20 > provide its own methods to access it, then we would have=20 > encapsulation and protection. That doesn't trash the=20 > inheritance clusters we've designed, just that these=20 > datatypes are to be bundled by accessing many levels of data. >=20 > Jean-Pierre >=20 >=20 > ----- Message d'origine -----=20 > De : "Jim Kring" <ji...@ji...> > =C0 : <ope...@li...> > Envoy=E9 : 17 octobre, 2003 15:04 > Objet : RE: [opengoop] Virtual Methods (Abstraction) >=20 >=20 > Niels, >=20 > I like your idea. I have tried to use it as the basis for my=20 > example, below. In this example, each class stores its own=20 > protected and private data; the strict inheritance structure=20 > is made accessible to descendants; and only protected data=20 > (not private) are accessible to descendants. >=20 > How about using the following distinction? > - Private: Only members of the class can access this data. > - Protected: Only members of the class and its descendants=20 > can access this data. >=20 > Below is a scheme that I think will work. I have also posted=20 > images, and a downloadable example to a new page at OpenG.org=20 > called "Strict Data Inheritance Cluster With Private=20 > Attributes". The page is located here:=20 > http://www.openg.org/tiki/tiki-index.php?page=3DStrict+Data+Inhe > ritance+Cluste > r+With+Private+Attributes >=20 > --- Class Data Structures --- >=20 > Each class has five clusters which are typedefs: > - {Class Protected Data} =3D Class's protected data elements > - {Class Private Data} =3D Class's private data elements > - {Class Data Store} =3D {{Class Protected Data}, {Class=20 > Private Data}} > - {Class Inheritance Data} =3D {{Parent Inheritance Data},=20 > {Class Protected Data}} > - {Class Data} =3D {{Class Inheritance Data}, {Class Private Data}} >=20 > --- Class Data Access VIs --- >=20 > Class Low-Level Data Access Utility VIs: - Gets/Sets {Class=20 > Data Store}. Only callable from Class. > - Class Get Data Store.vi > - Class Get Data Store to Modify.vi > - Class Set Data Store.vi >=20 > Data Access VIs for Class to Call: - Gets/Sets {Class Data}. =20 > Only callable from Class. > - Class Get Data.vi > - Car Get Data to Modify.vi > - Class Set Modified Data.vi >=20 > Data Access VIs for Child to Call: - Gets/Sets {Class=20 > Inheritance Data}. Only callable from Class's child. > - Class Get Inheritance Data.vi > - Class Get Inheritance Data to Modify.vi > - Class Set Inheritance Data.vi >=20 > Let me know what you think. >=20 > -Jim >=20 >=20 > > -----Original Message----- > > From: ope...@li... > > [mailto:ope...@li...] > > On Behalf Of Niels Harre > > Sent: Thursday, October 16, 2003 5:08 PM > > To: ope...@li... > > Subject: RE: [opengoop] Virtual Methods (Abstraction) > > > > > > Hi Jim et al, > > > > I have a few comments: > > > > This "protected" data type is as indicated by it's name not as=20 > > conservative as data carrying the term private! In LV - if a given=20 > > child class can access it's parents "protected" data - it=20 > will/can be=20 > > done,- also by end > > users. The architecture of LV is in this sense too open.... > > so it cannot > > be avoided. Consequently - I suggest that if we want to > > implement different > > data types (private, protected, public)(and we do not know > > which (yet)) > > then select an open data model, which isn't coupled too hard to the > > implementation. > > > > That's the main reason - I think - we should look more in the=20 > > direction of your latter suggestion: the alternative to the=20 > > inheritable data structure. > > > > The data structures could be arranged like this (very much as you=20 > > suggest): > > > > parent class =3D {{public parent data}, ... <whatever data types> = ...=20 > > ,{private parent data}} > > > > {ancestor0 public data} =3D {public parent data} > > child0 class =3D {{public child0 data}, ... <whatever data types>=20 > > ...,{private child0 data}, {ancestor0 public data}} > > > > {ancestor1 public data} =3D {{public child0 data}, {ancestor0 public = > > data}} child1 class =3D {{public child1 data}, ... <whatever=20 > data types> > > ...,{private child1 data}, {ancestor1 public data}} > > > > Still the bundle and unbundle (not by name) can be used. > > > > Further - this might be a step too far - it's the=20 > implementation of=20 > > the class which should instantiate memory space for any objects > > created. This > > implies that the constructor of a child classes should call > > it's inherited > > constructor, which again calls his inherited constructor. > > .... > > > > > > What=B4do you think? > > > > All the best, > > ---Niels > > > > > > At 18:46 15-10-2003 -0700, you wrote: > > >-=3D Re: encapsulation =3D- > > > > > >After doing some reading, I realize that the object data is > > considered > > >to be "protected" if descendants can access it, but end > > users cannot. > > >End user's only have access to the object vi (public) > > methods. So, I > > >guess it is OK for descendants to access ancestor data. > > > > > > > > >-=3D Re: inheritable data structure =3D- > > > > > >One problem that I have with the inheritable data=20 > structure is that=20 > > >since it is "inside-out", descendants have to "dig" into=20 > the object=20 > > >data cluster in order to get to the descendent data -- the > > more levels > > >in the inheritance hierarchy, the deeper they have to go. > > This seems > > >backwards, and confusing to me. I prefer digging into the > > object data > > >cluster in order to get to ancestor data. Plus, descendents will=20 > > >normally be accessing the descendant data, and not normally the=20 > > >ancestor data, so descendent data should be easier to get to. > > > > > >The only (but very useful) advantage of the inheritable data > > structure > > >is that a descendant data type will coerce to an ancestor=20 > data type,=20 > > >and ancestor "downcasts" to descendant using "Variant to > > Data". This > > >has two implications. > > > > > >1) One does not have to bundle and unbundle data in "Class > > Get/Set Data > > >as Parent.vi", which means that there is no manual (or=20 > "scripting")=20 > > >task that needs to occur in order to update the > > bundle/unbundle nodes > > >when a data type changes. Note that "Bundle/Unbundle by > > Name" breaks > > >when an element name changes, and Bundle breaks when the number of=20 > > >elements changes (However, Unbundle doesn't break when the=20 > number of=20 > > >elements changes). > > > > > >2) Data could be stored in the oldest ancestor (root), > > rather than the > > >youngest descendant. Does this have any advantages? One, > > that I can > > >think of is that there will be no dynamic calls for=20 > accessing data.=20 > > >However, does this amount to much and how much overhead will > > there be > > >if we are converting to variant and back very often, anyway? > > > > > >-=3D An alternative to the inheritable data structure =3D- > > > > > >The change that we made to the inheritable data structure of > > wrapping > > >the {class added data} in a cluster, can also be applied to the=20 > > >standard inheritance cluster, for a benefit that eliminates > > problem #1, > > >above (bundle/unbundle growth). > > > > > >For example let's look at a Car's data cluster: > > >{Car Data} =3D=3D {{LandVehicle Data},{Car Added Data}} > > >Where: > > >{LandVehicle Data} =3D {{Vehicle Data}, {LandVehicle Added Data}} > > > > > >Since each object's data is a cluster of exactly two=20 > subclusters, we=20 > > >can bundle and unbundle (not by name) without worrying about > > the nodes > > >growing in size. Therefore {Object Added Data} can grow in size=20 > > >without changing the number of elements in {Object Data}. > > > > > >I have posted an example of this on OpenG.org called "Strict Data=20 > > >Inheritance Cluster". The page is located at: > > > > > >http://www.openg.org/tiki/tiki-index.php?page=3DStrict+Data+Inh > > eritance+C > > >luste > > >r > > > > > > > > > > > >-Jim > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ope...@li... > > > > [mailto:ope...@li...] > > > > On Behalf Of Jean-Pierre Drolet > > > > Sent: Tuesday, October 14, 2003 5:42 PM > > > > To: ope...@li... > > > > Subject: Re: [opengoop] Virtual Methods (Abstraction) > > > > > > > > > > > > Ahh... > > > > > > > > I was sure you were talling about the "new" fact that=20 > an ancestor=20 > > > > does have access to child data thru the introduced variant... > > > > > > > > The encapsulation issue also exists for embedded clusters > > datatypes. > > > > It may be possible for Class Get Data.vi to cast, unbundle and=20 > > > > return only the class specific data. More easily with=20 > inheritance=20 > > > > clusters since class specific data is bundled in a cluster. The=20 > > > > problem I see actually is that the parent class isn't > > always aware > > > > when its data is accessed so it may be important that > > either a) the > > > > clild can't access parent data at all or b) it is allowed > > to modify > > > > it but all the ancestors Get/Set Data methods are invoked > > to notify > > > > that the data is accessed and modified. Maybe two methods can be > > > > used: Get/Set Class Data to access class specific data only and=20 > > > > Get/Set Object Data to access all object data. In the latter,=20 > > > > Get/Set methods are invoked for all classes to > > access data. > > > > > > > > It is also important for the object to have private data (not=20 > > > > get/set outside the class) like internal state variables. These=20 > > > > shouldn't be affected by get/set data operation on public > > variables. > > > > This private data need to be store in the object data space too. > > > > > > > > > > > > > > > > Jean-Pierre > > > > > > > > > > > > ----- Message d'origine ----- > > > > De : "Jim Kring" <ji...@ji...> > > > > =C0 : <ope...@li...> > > > > Envoy=E9 : 13 octobre, 2003 22:23 > > > > Objet : RE: [opengoop] Virtual Methods (Abstraction) > > > > > > > > > > > > Jean-Pierre, > > > > > > > > Actually what I am talking about is the inverse. I am not too=20 > > > > concerned with an ancestor having access to descendant=20 > data, but=20 > > > > rather I am concerned with a descendant having access to > > ancestor's > > > > private data. Right now there is no distinction=20 > between private=20 > > > > data and public data -- all object data is public. =20 > Therefore, a=20 > > > > class cannot protect itself from a descendant that=20 > doesn't fully=20 > > > > understand its implementation (and descendants=20 > shouldn't have to=20 > > > > understand). Maybe there could be two types of data storage,=20 > > > > public and private. Public data would be accessible to the=20 > > > > descendants, via their object data clusters, and private data=20 > > > > would not be accessible to descendants. Private data will not=20 > > > > need an inheritance scheme since it is only available to one=20 > > > > class-level. > > > > > > > > -Jim > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.net email is sponsored by: SF.net Giveback Program.=20 > > > > SourceForge.net hosts over 70,000 Open Source Projects. See the=20 > > > > people who have HELPED US provide better services: Click > > > > here: http://sourceforge.net/supporters.php > > > > _______________________________________________ > > > > OpenGToolkit-Developers mailing list=20 > > > > Ope...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-deve > lopers > > > > > > > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: SF.net Giveback Program.=20 > >SourceForge.net hosts over 70,000 Open Source Projects. See=20 > the people=20 > >who have HELPED US provide better services: Click here:=20 > >http://sourceforge.net/supporters.php > >_______________________________________________ > >OpenGToolkit-Developers mailing list=20 > >Ope...@li... > >https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program.=20 > SourceForge.net hosts over 70,000 Open Source Projects. See=20 > the people who have HELPED US provide better services: Click=20 > here: http://sourceforge.net/supporters.php > _______________________________________________ > OpenGToolkit-Developers mailing list=20 > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email sponsored by: Enterprise Linux Forum=20 > Conference & Expo The Event For Linux Datacenter Solutions &=20 > Strategies in The Enterprise Linux in the Boardroom; in the=20 > Front Office; & in the Server Room http://www.enterpriselinuxforum.com > _______________________________________________ > 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: The SF.net Donation=20 > Program. Do you like what SourceForge.net is doing for the=20 > Open Source Community? Make a contribution, and help us add=20 > new features and functionality. Click here:=20 > http://sourceforge.net/donate/=20 > _______________________________________________ > OpenGToolkit-Developers mailing list=20 > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers >=20 |
4 messages has been excluded from this view by a project administrator.
