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: 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: 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 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: 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: 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: 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: Jim K. <ji...@ji...> - 2003-11-09 10:42:36
|
Chris, Thanks for the reply. BTW, I have added your email address to the authorized senders to the list, but if you are interested in joining the list you can do so at: <https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers> Regards. -Jim > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] > On Behalf Of Christophe Salzmann > Sent: Sunday, November 09, 2003 12:19 AM > To: rol...@ci...; Jim Kring > Cc: ope...@li... > Subject: Re: VISA alternative > > > 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 > > > > > > > > ------------------------------------------------------- > 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-10 17:54:30
|
Chris, Rolf, et al. Ideally, it would be nice to have an interface that was identical to the = old serpdrv VIs (but with error IO, of course ;-): ./vi.lib/Instr/Serial.llb However, since it is a huge task to code up such an abstraction in each development environment, then what I would suggest is to wrap each OS's serial API in a shared library, and doing so in a way most natural for = that OS. Then, for each platform, the higher-level cross-platform API can be written in G. This way there can be more people helping with the cross-platform support and the folks working on the OS layer can focus = only on that (also fewer shared library builds etc.). The OpenG Package Installer can take care of installing all of the platform specific = stuff. Any thoughts? -Jim > -----Original Message----- > From: ope...@li...=20 > [mailto:ope...@li...]=20 > On Behalf Of Christophe Salzmann > Sent: Sunday, November 09, 2003 12:19 AM > To: rol...@ci...; Jim Kring > Cc: ope...@li... > Subject: Re: VISA alternative >=20 >=20 > Jim, Rolf, >=20 > I second Rolf in the fact that a generic IOPort driver might=20 > be a quite large project. On the other hand a serial driver=20 > sounds like a reasonable starting point. Now regarding the=20 > Mac, there is no serial port built-in anymore. If you want=20 > one you should either replace your internal modem or use an=20 > usb-serial converter. On the other hand you can "route" your=20 > serial line to a bluetooth connection to talk to other=20 > devices such as phone, PDAs, etc. So there will be some use=20 > for such driver. There is no native parallel port on the Mac=20 > (I guess you all know it) but some external hardware provide=20 > this extension. I've some code for to access the serial port=20 > that worked quite well under OS9, I haven't done anything=20 > with OSX, but I guess this should not be too difficult. I=20 > guess the first step will be to define what functionalities=20 > we want in this driver and then see what can be done under=20 > each platforms. >=20 > I'll explore what is possible under OSX and let you know >=20 > Have a good week-end >=20 > Chris=20 >=20 >=20 > > 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...,=20 > > ope...@li... > > Subject: RE: VISA alternative > >=20 > > Jim Kring [mailto:ji...@ji...] wrote: > >=20 > >> If anyone has been reading the info-lv thread on NI VISA=20 > licensing,=20 > >> you can see that there is a huge demand for an open source=20 > solution=20 > >> for serial and parallel port I/O. NI only allows you to=20 > distribute=20 > >> 10 copies of your built application that uses NI "Driver=20 > Software". =20 > >> After that, they want $395 per copy! Sounds like a good openg=20 > >> project to me. How about OpenGSerp and OpenGPortIO? I don't have=20 > >> the background to code up the OS interface or sharedlib, but I can=20 > >> help with all other aspects of the project. > >=20 > > Well, first as I stated earlier on Info-LabVIEW I do not think that=20 > > the $395 is for a VISA runtime license but rather for the=20 > entire VISA=20 > > software, with development libraries, documentation, T&M Explorer,=20 > > VISA Interactive Control and whatever there is. Anything=20 > else would be=20 > > stupid and completely unlogical to explain, as you can buy some NI=20 > > products which come with VISA for not much more than that amount. > >=20 > > Second I was thinking about creating an OpenG PortIO driver which=20 > > supports both the slow but simple register access of the NI=20 > solution=20 > > as well as an alternative high speed access, which needs some prior=20 > > intialization. I have all the information and even some=20 > code for Win32=20 > > here but need to clean it up and prepare a proper LabVIEW=20 > solution for=20 > > it. It will be a source code release but since you need a=20 > Windows DDK=20 > > installed to compile it, I don't think there will be many people=20 > > trying to compile it themselves, so a pre- compiled binary will be=20 > > provided as well. I have not a very good idea about how to go to=20 > > implement the same under Linux, although it shouldn't be that=20 > > difficult, but for Mac I'm completely clueless, nor if there is=20 > > actually any possible need for this on the Mac. After all you don't=20 > > have LPT and COM ports there ;-) > >=20 > > Third trying to write a OpenG Serp driver is a pain of a=20 > thing to do.=20 > > Doing so for one plattform is already quite a serious project, but=20 > > trying to support Win32, Linux, and Mac OS X is most=20 > probably a major=20 > > undertaking, requiring more commitement from several people=20 > than most=20 > > of us are willing and able to do. You would have to=20 > abstract the Win32=20 > > COMM API on one hand, the Linux device interface on the=20 > other and the=20 > > Macintosh device driver interface (or can one maybe use the Unix=20 > > device interface without loosing to much control), which are=20 > > completely different in their design, interface, and=20 > abstraction. Of=20 > > course one could still use the disappeared Device IO Control nodes,=20 > > which LabVIEW still supports in 7.0. But there are a number=20 > of issues.=20 > > The Device IO Control interface in LabVIEW is built to=20 > interface with=20 > > the Mac Device Manager and can actually be used to call=20 > virtually any=20 > > Mac OS device driver although it never was really used for anything=20 > > but the serial port drivers. On Windows the famous serpdrv=20 > acts as a=20 > > translation between the Mac OS Device Manger interface used=20 > in LabVIEW=20 > > and the native Win32 COMM API. The architecture of this translator=20 > > driver has never been published and depends on some internal > > tools only available by NI, but has some similarities with=20 > creating CINs. > > On Linux I'm not exactly sure if a similar serpdrv exists=20 > or if the LabVIEW > > Device IO Interface nodes map directly to the unix device=20 > driver interface. > > Problem is, that I'm fairly sure that NI tries to=20 > completely disable support > > for this interface in one of the next major releases. > > So the only viable solution would really be over a shared=20 > library interface > > which in itself should work quite fine as proven in lvzlib=20 > and to a lesser > > extend in labpython. > > Neverthless serial port programming on Win32 API level in a=20 > generic way, and > > not just for a particular device, is anything but pleasant,=20 > and other systems > > won't be much simpler here. > >=20 > > Rolf Kalbermatter > >=20 > >=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 |