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: Brian G. <bri...@da...> - 2005-05-10 03:13:19
|
Dou...@mk... wrote: >What performance benchmarks comparing OpenGOOP and dqGOOP can you share >with us? Doug > > The attached spreadsheet has data from running the test classes that are in the zip file. I plan on running the test under more controlled conditions, but the results are typical of what I have been seeing. Brian |
|
From: <Dou...@mk...> - 2005-05-09 20:53:31
|
What performance benchmarks comparing OpenGOOP and dqGOOP can you share with us? Doug |---------+---------------------------------------------------> | | Brian Gangloff <bri...@da...> | | | Sent by: | | | ope...@li...ur| | | ceforge.net | | | | | | | | | 04/22/2005 09:18 PM | | | Please respond to | | | opengtoolkit-developers | | | | |---------+---------------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: ope...@li... | | cc: chr...@ya... | | Subject: Re: dqGOOP beta | >----------------------------------------------------------------------------------------------| Brian Gangloff wrote: > In the Testing folder is a VI already to test performance. I will > send test classes for OpenGOOP and NIs GOOP in a little while. Here is the link for the test classes, there are three. You don't need to run the setup.exe for these to work, so you can just unzip this to take a look at a class made with dqGOOP. http://downloads.dataact.com/dqGOOP/GOOPTest.zip Brian ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ OpenGToolkit-Developers mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers This e-mail is intended solely for the person or entity to which it is addressed and may contain confidential information. Any review, dissemination, copying, printing or other use of this e-mail by persons or entities other than the addressee is prohibited. If you have received this e-mail in error, please contact the sender immediately and delete the material from any computer. |
|
From: Mark B. <mb...@Ch...> - 2005-04-26 17:00:22
|
If any one is interested in a new implementation of Goop using Ques to store the data I started a discussion on the LAVA site here. http://forums.lavausergroup.org/index.php?showtopic=1392 My initial trials show it to be faster and less complicated than the current OpneG model. Mark Balla Sr. Test Engineer Cherry Electrical Products 11200 88th Ave. Pleasant Prairie, WI 53158-0913 Phone: 262-942-6420 Cell: 847-721-2047 Fax: 262-942-6411 Email mb...@ch... The information contained in this e-mail is confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copy or use of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify us immediately at the e-mail address above and delete the original message. Thank you. |
|
From: Jim K. <jim...@ja...> - 2005-04-24 20:45:40
|
Yes, OpenG Packages are cross-platform in nature and Commander makes distribution a piece of cake. Also, I recommend HTML docs for cross-platform documentation. -Jim > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] > On Behalf Of Michael Aivaliotis > Sent: Sunday, April 24, 2005 1:37 PM > To: ope...@li... > Subject: Re: dqGOOP beta > > If you make it a package installable form Commander then > handling OS and > LV versions is already handle for you through the Commander > interface. I > would recommend investigating this approach. > > Thank You > Michael Aivaliotis > > Brian Gangloff wrote: > > > Jim Kring wrote: > > > >> Brian, > >> > >> I presume that you used the Nullsoft Scriptable Installer System > >> (NSIS) for > >> the dqGOOP installer. Does NSIS support installing > something to more > >> than > >> one location? For example, it would be VERY cool if you > could have > >> multiple > >> optional installation locations, such as: > >> > >> C:\Program Files\National Instruments\LabVIEW 6.1 > >> C:\Program Files\National Instruments\LabVIEW 7.0 > >> C:\Program Files\National Instruments\LabVIEW 7.1 > >> > >> > >> > > Yes, that is the plan. I will have a components page similar to > > LabVIEW Version Chooser that will list all of the installed LabVIEW > > versions so you can check the the ones you want dqGOOP > installed to. > > The maintenance page will also be working so you can add > and remove as > > well. > > > >> I'm not sure how this would be done, as I have yet to > really learn the > >> capabilities of NSIS. > >> > >> > > The registry is the best for Windows (to find out installed > versions > > of LV) and maco's could be used for the NSIS code. > > > >> Anyhow, I would recommend creating an OpenG Package file > with dqGOOP > >> since > >> this would allow a cross platform and LabVIEW version installation > >> approach. > >> BTW, in a couple months we may have a GUI for building > packages. It > >> on the > >> to-do list. > >> > >> > > I may need some help in verifing non windows installations. > I've read > > how to distribute help for the mac, but would need someone > with a mac > > to test that everything still works. > > > >> Regards, > >> > >> -Jim Kring > >> > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products > from real users. > > Discover which products truly live up to the hype. Start > reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > OpenGToolkit-Developers mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > > > > > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > |
|
From: Michael A. <mi...@ai...> - 2005-04-24 20:36:49
|
If you make it a package installable form Commander then handling OS and LV versions is already handle for you through the Commander interface. I would recommend investigating this approach. Thank You Michael Aivaliotis Brian Gangloff wrote: > Jim Kring wrote: > >> Brian, >> >> I presume that you used the Nullsoft Scriptable Installer System >> (NSIS) for >> the dqGOOP installer. Does NSIS support installing something to more >> than >> one location? For example, it would be VERY cool if you could have >> multiple >> optional installation locations, such as: >> >> C:\Program Files\National Instruments\LabVIEW 6.1 >> C:\Program Files\National Instruments\LabVIEW 7.0 >> C:\Program Files\National Instruments\LabVIEW 7.1 >> >> >> > Yes, that is the plan. I will have a components page similar to > LabVIEW Version Chooser that will list all of the installed LabVIEW > versions so you can check the the ones you want dqGOOP installed to. > The maintenance page will also be working so you can add and remove as > well. > >> I'm not sure how this would be done, as I have yet to really learn the >> capabilities of NSIS. >> >> > The registry is the best for Windows (to find out installed versions > of LV) and maco's could be used for the NSIS code. > >> Anyhow, I would recommend creating an OpenG Package file with dqGOOP >> since >> this would allow a cross platform and LabVIEW version installation >> approach. >> BTW, in a couple months we may have a GUI for building packages. It >> on the >> to-do list. >> >> > I may need some help in verifing non windows installations. I've read > how to distribute help for the mac, but would need someone with a mac > to test that everything still works. > >> Regards, >> >> -Jim Kring >> > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > > > |
|
From: Brian G. <bri...@da...> - 2005-04-24 20:29:17
|
Brian Gangloff wrote: > The attached new template could provide a solution for some instances > with only a few Modify methods, but could end up with a race condition > if you had many Modify methods. Sorry, forgot the attachment.. |
|
From: Brian G. <bri...@da...> - 2005-04-24 20:27:45
|
Jim Kring wrote: >Brian, > >I presume that you used the Nullsoft Scriptable Installer System (NSIS) for >the dqGOOP installer. Does NSIS support installing something to more than >one location? For example, it would be VERY cool if you could have multiple >optional installation locations, such as: > >C:\Program Files\National Instruments\LabVIEW 6.1 >C:\Program Files\National Instruments\LabVIEW 7.0 >C:\Program Files\National Instruments\LabVIEW 7.1 > > > Yes, that is the plan. I will have a components page similar to LabVIEW Version Chooser that will list all of the installed LabVIEW versions so you can check the the ones you want dqGOOP installed to. The maintenance page will also be working so you can add and remove as well. >I'm not sure how this would be done, as I have yet to really learn the >capabilities of NSIS. > > The registry is the best for Windows (to find out installed versions of LV) and maco's could be used for the NSIS code. >Anyhow, I would recommend creating an OpenG Package file with dqGOOP since >this would allow a cross platform and LabVIEW version installation approach. >BTW, in a couple months we may have a GUI for building packages. It on the >to-do list. > > I may need some help in verifing non windows installations. I've read how to distribute help for the mac, but would need someone with a mac to test that everything still works. >Regards, > >-Jim Kring > |
|
From: Brian G. <bri...@da...> - 2005-04-24 20:16:14
|
Hi Mark and Jim, Thanks for looking at dqGOOP. Since Mark and Jim both brought up the same point, I will just reply to the one and copy everyone in. Brian Mark Balla wrote: > > Brian, > > I was playing around with the dqGoop this weekend. > Very nice Idea Goop is probably my favorite LabView topic. > This approach looks much more elegant as well a smaller footprint. > I am very interested in any information you have on performance > improvements with dqGoop vs. OpenGoop. > Did you download the zip file that that was mentioned in the email that you replied to (bottom of this one as well)? It has 3 test classes, they can be found in the respective ..\Testing directories. OpenGOOP does very well on get and set, but the create time is very slow. Please run the tests on your computer and let me know how dqGOOP compares. > I have a suggestion to help fix an issue I found. > > First the issue > Because the Modify Data vi removes the data from the Que this leaves > the que blank. So any program that needs to only read the data can not > do so until the data is put back. This creates a bottle neck in Goop vis > like mine where several loops only read the object data and only 1 or 2 > vis change it. If I have a Modify vi that takes 500 ms to update the data > then all the read vis must wait that time before moving on. OpenGoop does > not have this issue because the semaphore only stops other programs from > changing not reading. > It has been my opinion (and I could be wrong), that locking the data should do just that, lock it. Once the Modify VI gets the data, it is no longer valid data since the Modify VI is changing it. The question is then, when you want to get data do you want the latest data (wait for lock) or is old data OK. dqGOOP currently provides the mechanism for the first, but as you and Jim have pointed out there isn't a way for the second. The attached new template could provide a solution for some instances with only a few Modify methods, but could end up with a race condition if you had many Modify methods. I will have to think a bit on how to provide access to old (last before lock) data. I don't have the time to look at your example code, but from the description it sounds like too much overhead. If you haven't yet, read the first three topics in the help file. They give a good description of why I started to develop dqGOOP, but it all boils down to performance. I have applications that need to be able to create and access many GOOP objects quickly. > I think I found a way to avoid this issue with only a few changes to > the core code. > Suggested Changes > > Create New Object Vi > Instead of a Que size of 1 use a size of 2. Most of the time there will > only be one data set in the que except when updating changed data. > > Get Data to Modify Vi > Acquire a Semaphore > Preview Que data. This will still allow others to read it also. > > Set Modified Data Vi > Enqueue the New Data > Dequeue the Old Data. This leaves only the new data remaining while never > forcing other vis to wait for data > Release Semaphore. > > I have example code that I've attached. > I will look at it but it probably won't be until next week since I will be out of the office this coming week and half of the next. > dqGoop may be the concept that brings Goop the the masses. > I hope so, but credit has to be given to Endevo for bringing it first and OpenGOOP for providing the first open source version. > I don't know if you are a LV8 beta tester or not but this approach > will fit very nicely with the new LVOOP classes. > No I'm not, but its good to hear. I like "LVOOP" class, is that NIs official terminology? > Can I request that you please create a post on Lava or OpenG or both > so we can start discussions with the LV community? > Yes, but probably not until I return. Or if you want to start one, I can join when I return. > Great concept and thanks for sharing it. > Thanks for looking > Mark > > > > -----Original Message----- > From: Brian Gangloff > To: ope...@li... > Cc: chr...@ya... > Sent: 4/22/05 8:18 PM > Subject: Re: dqGOOP beta > > Brian Gangloff wrote: > > > In the Testing folder is a VI already to test performance. I will > > send test classes for OpenGOOP and NIs GOOP in a little while. > > Here is the link for the test classes, there are three. You don't need > to run the setup.exe for these to work, so you can just unzip this to > take a look at a class made with dqGOOP. > > http://downloads.dataact.com/dqGOOP/GOOPTest.zip > > Brian > |
|
From: Jim K. <jim...@ja...> - 2005-04-24 17:52:58
|
Brian, I presume that you used the Nullsoft Scriptable Installer System (NSIS) for the dqGOOP installer. Does NSIS support installing something to more than one location? For example, it would be VERY cool if you could have multiple optional installation locations, such as: C:\Program Files\National Instruments\LabVIEW 6.1 C:\Program Files\National Instruments\LabVIEW 7.0 C:\Program Files\National Instruments\LabVIEW 7.1 I'm not sure how this would be done, as I have yet to really learn the capabilities of NSIS. Anyhow, I would recommend creating an OpenG Package file with dqGOOP since this would allow a cross platform and LabVIEW version installation approach. BTW, in a couple months we may have a GUI for building packages. It on the to-do list. Regards, -Jim Kring > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] > On Behalf Of Brian Gangloff > Sent: Saturday, April 23, 2005 9:06 AM > To: ope...@li... > Subject: Re: dqGOOP beta > > Brian Gangloff wrote: > > > The installer ONLY installs into the default LabVIEW 7.0 > directory. > > (C:\Program Files\National Instruments\LabVIEW 7.0). > Eventually the > > installer will let you choose which LabVIEW version to > install for. I > > was testing to see if the license page could point to an html page, > > but it doesn't display so I have to fix. > > The installer will now let you choose the LabVIEW directory and the > license page is corrected. > > available at: > > http://downloads.dataact.com/dqGOOP/Setup.exe > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > |
|
From: Jim K. <jim...@ja...> - 2005-04-24 05:27:41
|
Brian, First, let me say that this is a very nice and GOOP implementation. It is very clever how you get the mutex/semaphore-like behavior "for free" with the "Dequeue Element" function waiting for an element to be queued. Also, how the "Preview Queue Element" function allows reading the data store (when one is not intending to write data). However, there is one behavioral difference b/w the dqGOOP and traditional semaphored data, which you might have noticed -- a call to "Get Data" will wait until a data modifying member function has written the data. Basically the "Get Data" and "Get Data to Modify" will both wait until "Set Modified Data" is called, since "Preview Queue Element" cannot return until there is an element on the queue, which will not occur while data is in the process of being modified. I don't think that this is a big deal for most (if any) applications, but it is a difference worth mentioning. Cheers, -Jim Kring > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] > On Behalf Of Brian Gangloff > Sent: Saturday, April 23, 2005 9:06 AM > To: ope...@li... > Subject: Re: dqGOOP beta > > Brian Gangloff wrote: > > > The installer ONLY installs into the default LabVIEW 7.0 > directory. > > (C:\Program Files\National Instruments\LabVIEW 7.0). > Eventually the > > installer will let you choose which LabVIEW version to > install for. I > > was testing to see if the license page could point to an html page, > > but it doesn't display so I have to fix. > > The installer will now let you choose the LabVIEW directory and the > license page is corrected. > > available at: > > http://downloads.dataact.com/dqGOOP/Setup.exe > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > |
|
From: Brian G. <bri...@da...> - 2005-04-23 16:05:42
|
Brian Gangloff wrote: > The installer ONLY installs into the default LabVIEW 7.0 directory. > (C:\Program Files\National Instruments\LabVIEW 7.0). Eventually the > installer will let you choose which LabVIEW version to install for. I > was testing to see if the license page could point to an html page, > but it doesn't display so I have to fix. The installer will now let you choose the LabVIEW directory and the license page is corrected. available at: http://downloads.dataact.com/dqGOOP/Setup.exe |
|
From: Brian G. <bri...@da...> - 2005-04-23 01:18:55
|
Brian Gangloff wrote: > In the Testing folder is a VI already to test performance. I will > send test classes for OpenGOOP and NIs GOOP in a little while. Here is the link for the test classes, there are three. You don't need to run the setup.exe for these to work, so you can just unzip this to take a look at a class made with dqGOOP. http://downloads.dataact.com/dqGOOP/GOOPTest.zip Brian |
|
From: Brian G. <bri...@da...> - 2005-04-22 20:58:09
|
Hello, Here is a link to a beta version of the dqGOOP Toolkit that I mentioned on the Info-LabVIEW list. The installer ONLY installs into the default LabVIEW 7.0 directory. (C:\Program Files\National Instruments\LabVIEW 7.0). Eventually the installer will let you choose which LabVIEW version to install for. I was testing to see if the license page could point to an html page, but it doesn't display so I have to fix. http://downloads.dataact.com/dqGOOP/Setup.exe The wizard is exactly the same as OpenGOOP, but I added a sequence to automatically name the enum for the object reference (thanks to code from Philippe Guerit). I also want add the option to move the probes. There is a help file that gets installed, the first three topics give a summary of the features and how it works. You can get to it from Start/Programs/DataAct/dqGOOP/help or if you create a class and have context help on, there should be an active link. In the Testing folder is a VI already to test performance. I will send test classes for OpenGOOP and NIs GOOP in a little while. Brian |
|
From: Brian G. <bri...@da...> - 2005-04-07 21:42:51
|
Hello again, Version 1.1.0 is now available! You can download the latest version here =20 http://downloads.dataact.com/LVC-1.1.0.401-setup.exe If you are using the Automatic launching option (Auto=3DTrue), there is = now another option to specify a delay that will allow the automatic = launching to be stopped. To enable this option add "AutoDelay=3DXX" (where XX is a = delay in milliseconds) key to the LVC_Action.ini. With this option enabled, = there is an additional button on LVC_Action window which can be pressed or = <F5> to stop the automatic action. The installer will now correctly register LabVIEW extensions on a = computer that doesn't have LabVIEW installed and the repair function is now more robust. (FYI, I have a recursive delete registry key VI if anyone needs it). I am still planning on working on the plug-in architecture, but it won't = be available until the next major release. Thanks to everyone who has tried LVC and for all of the feedback and support. Sincerely, Brian Gangloff President Certified LabVIEW Developer DataAct Incorporated 375 Westminster Rd, Suite 300 Rochester, NY 14607 585.802.6036 bri...@da... http://www.dataact.com >=20 |
|
From: Rolf K. <rol...@ci...> - 2005-04-05 21:33:05
|
When trying to test my newly created packages I did use the File->Install Single Package menu option in the OpenG Commander. I got consistently an error 5008 so I went looking and found a problem within the function called to do this operation. In OGPM Add Package to Cache.vi the function OGPM Add Package File to Cache.vi is called. This function MOVES the package from the original location into the cache directory. Right after that the function OGPM Get Package Name.vi function is called with the original package file path to retrieve the package name, BUT the package has been already moved into the the cache and is therefore not available anymore. Possible solutions might be: 1) Use a COPY in the OGPM Add Package File to Cache.vi instead of MOVE. Is it really desirable to remove the original package from the disk? I would think this a little bit strange (I was rather surprised that the original package disappeared after I had selected it!) 2) Retrieve the package name from the now moved package in the cache instead of the original one And last but not least 3) The whole package name was just read in OGPM Add Package File to Cache.vi to determine the name of the target file in the cache to only be retrieved again as the next step after this function. Adding an output cluster to OGPM Add Package File to Cache.vi containing the package name parameters would be much more logical, more efficient and also add no complexity to the diagram of this VI at all. Rolf Kalbermatter CIT Engineering Nederland BV Treubstraat 7H 2288 EG Rijswijk Tel: +31 (0)70 415 9190 The Netherlands Fax: +31 (0)70 415 9191 |
|
From: Jim K. <jim...@ja...> - 2005-04-05 06:30:37
|
I agree. I'll make sure that this finds it's way into the source. Regards, -Jim > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] > On Behalf Of Dou...@mk... > Sent: Monday, April 04, 2005 12:44 PM > To: ope...@li... > Subject: Re: OpenG Package Manager improvement > > > Sounds like a capital improvement to me! Doug Femec > > > > |---------+---------------------------------------------------> > | | "Rolf Kalbermatter" | > | | <rol...@ci...> | > | | Sent by: | > | | ope...@li...ur| > | | ceforge.net | > | | | > | | | > | | 04/04/2005 03:41 PM | > | | Please respond to | > | | opengtoolkit-developers | > | | | > |---------+---------------------------------------------------> > > >------------------------------------------------------------- > ---------------------------------| > | > | > | To: > <ope...@li...> > | > | cc: "'Jim Kring'" <jk...@ja...> > | > | Subject: OpenG Package Manager improvement > | > > >------------------------------------------------------------- > ---------------------------------| > > > > > When trying to dig into the package creation through the > package manager > I ran into an error creating the final package. It turned out > to be the > "packaged" directory which didn't exist on my system and > which therefore > caused an error when the .ogp package could't be created. > > I was considering adding the function to make sure that the directory > exists > to the ZLIB Open ZIP File.vi function, but think that this would be a > little > to much for a library function. Instead I identified the OGPM Create > Package > >From Pkg File.vi function which might benefit from the the > addition of > the > Create Dir if Non-Existent.vi function. > > Included is a copy of that function to add to the next release of the > OGPM > Package if this is deemed a useful improvement. > > Rolf Kalbermatter > (See attached file: OGPM Create Package From Pkg Files__ogc.vi) > > > This e-mail is intended solely for the person or entity to which it is > addressed and may contain confidential information. Any review, > dissemination, copying, printing or other use of this e-mail > by persons or > entities other than the addressee is prohibited. If you have > received this > e-mail in error, please contact the sender immediately and delete the > material from any computer. > |
|
From: <Dou...@mk...> - 2005-04-04 19:53:31
|
Sounds like a capital improvement to me! Doug Femec |---------+---------------------------------------------------> | | "Rolf Kalbermatter" | | | <rol...@ci...> | | | Sent by: | | | ope...@li...ur| | | ceforge.net | | | | | | | | | 04/04/2005 03:41 PM | | | Please respond to | | | opengtoolkit-developers | | | | |---------+---------------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: <ope...@li...> | | cc: "'Jim Kring'" <jk...@ja...> | | Subject: OpenG Package Manager improvement | >----------------------------------------------------------------------------------------------| When trying to dig into the package creation through the package manager I ran into an error creating the final package. It turned out to be the "packaged" directory which didn't exist on my system and which therefore caused an error when the .ogp package could't be created. I was considering adding the function to make sure that the directory exists to the ZLIB Open ZIP File.vi function, but think that this would be a little to much for a library function. Instead I identified the OGPM Create Package From Pkg File.vi function which might benefit from the the addition of the Create Dir if Non-Existent.vi function. Included is a copy of that function to add to the next release of the OGPM Package if this is deemed a useful improvement. Rolf Kalbermatter (See attached file: OGPM Create Package From Pkg Files__ogc.vi) This e-mail is intended solely for the person or entity to which it is addressed and may contain confidential information. Any review, dissemination, copying, printing or other use of this e-mail by persons or entities other than the addressee is prohibited. If you have received this e-mail in error, please contact the sender immediately and delete the material from any computer. |
|
From: Rolf K. <rol...@ci...> - 2005-04-04 19:41:59
|
When trying to dig into the package creation through the package manager I ran into an error creating the final package. It turned out to be the "packaged" directory which didn't exist on my system and which therefore caused an error when the .ogp package could't be created. I was considering adding the function to make sure that the directory exists to the ZLIB Open ZIP File.vi function, but think that this would be a little to much for a library function. Instead I identified the OGPM Create Package From Pkg File.vi function which might benefit from the the addition of the Create Dir if Non-Existent.vi function. Included is a copy of that function to add to the next release of the OGPM Package if this is deemed a useful improvement. Rolf Kalbermatter |
|
From: PJ M <pjm...@ya...> - 2005-04-02 19:49:01
|
Brian and all; I tried your utility, and it is really very usefull. > > I'd like to be able to config LVC to automatically > launch > > files in the version of LabVIEW that they are > compiled for > > (or the lowest version of LV installed, whichever > is greater). > > This is now available by adding Auto=True to the > LVC_Action.ini file. The > LVC_Action.exe UI still flashes since a window has > to be open for the exe to > complete. Let me know how it works for you. I was > thinking of putting a > small delay that would allow a function key to > override the automatic > feature? The Auto=True is nice, but It will be great to have a way of disabling/enabling it at will. As you mentioned, a function key might do it, or an option in the system tray (if you figure out a way of getting in there), or may be a simple small floating toolbar/window might do it. Regards Philippe --- Brian Gangloff <bri...@da...> wrote: > Here's a note that I sent to Jim earlier explaining > what's in the latest > release of LVC. I forgot to copy the list in on the > first send, so here it > is. > > Hi Jim, > > Jim Kring wrote: > > > > > > Yes, that would be great. I've really grown > to like the LVC > > > > > > Thanks for the feedback > > > > > > > Here's some more... > > > > I'd like to be able to config LVC to automatically > launch > > files in the version of LabVIEW that they are > compiled for > > (or the lowest version of LV installed, whichever > is greater). > > This is now available by adding Auto=True to the > LVC_Action.ini file. The > LVC_Action.exe UI still flashes since a window has > to be open for the exe to > complete. Let me know how it works for you. I was > thinking of putting a > small delay that would allow a function key to > override the automatic > feature? > > > I'd like to be able to right-click on LLB files > and convert > > them to folders containing VIs. There is an OpenG > VI that > > can do this conversion (attached). Each time I > want to do > > this (and I do it a lot, because I hate LLBs > during > > development), I have to do the conversion manually > -- it's > > slow. Having a shell extension for this conversion > would be great! > > I haven't completed this yet due to the fact that I > want to allow for a > plug-in architecture. Here are some of the other > actions that I was > considering adding to the right-click (or extended > SHIFT right-click) menu: > -LLB to Directory > -Mass Compile > -Print > -Use as template (operate on directory => copy and > then use OpenG rename > folder of vis...) > > The latest version can downloaded at > http://downloads.dataact.com/LVC-1.0.10.369(beta)-setup.exe > > Or use the update button from the LVC_About window > > There is a problem with the 1.0.8.334 uninstaller, > but it shouldn't matter > if you are planning on upgrading since there is no > need to uninstall LVC > before installing a newer version. However, if > anyone wants to be able to > uninstall 1.0.8.334 without upgrading here is a link > to a working > uninstaller (This will only work if you have not > tried to uninstall with the > current uninstaller) > > http://downloads.dataact.com/Uninstall.zip > > I also added the ability to get another file's > version by dragging it to an > empty space on the LVC_Version window. > > My idea of the keeping LVC in the system tray isn't > going to work since the > NI DDE VIs don't allow a DDE server to receive > commands. > > I will let you know when the plug-in architecture is > ready. > > Regards, > Brian > > > > ------------------------------------------------------- > This SF.net email is sponsored by Microsoft Mobile & > Embedded DevCon 2005 > Attend MEDC 2005 May 9-12 in Vegas. Learn more about > the latest Windows > Embedded(r) & Windows Mobile(tm) platforms, > applications & content. Register > by 3/29 & save $300 > http://ads.osdn.com/?ad_idh83&alloc_id149&op=click > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Brian G. <bri...@da...> - 2005-03-25 20:44:50
|
Rolf Kalbermatter wrote: >You can have a DDE server but there is indeed no provision to allow for >receiving of DDE_EXECUTE messages nor in a server nor for a client. > >While I started to work on this a long time ago by writing a replacement >DLL which would implement all the DDE functions for LabVIEW similar as >they are now, including support for receiving of DDE execute, this has >never been finished. Contacts with NI if there would be a possibility to >get their source code for the DDE CIN to expand on that, didn't give the >desired result either. > Thats too bad, I don't know of any other way for the shell to notify LVC if it was running in the tray which file was double clicked (or right clicked action selected). >However integration into the system tray can - and I think actually only >- be done trough calls into shell APIs. The problem here is that you >need to support some event mechanisme which the tray API does by >callbacks and that will require some C code interface such as a CIN or >DLL. > >George Zou has such Vis, maybe that he would be willing to provide them >for this project. > I have a copy of George's toolkit so that's not an issue. >They would however have to be integrated through a >plugin architecture to avoid hard dependencies on Windows only >functionality. > > LVC is currently very much Windows dependent, mostly due to the fact that I am now Windows dependent. I started with LabVIEW on the mac but that was a long time ago... Brian |
|
From: Rolf K. <rol...@ci...> - 2005-03-24 06:27:50
|
>My idea of the keeping LVC in the system tray isn't going to work since >the NI DDE Vis don't allow a DDE server to receive commands. You can have a DDE server but there is indeed no provision to allow for receiving of DDE_EXECUTE messages nor in a server nor for a client. While I started to work on this a long time ago by writing a replacement DLL which would implement all the DDE functions for LabVIEW similar as they are now, including support for receiving of DDE execute, this has never been finished. Contacts with NI if there would be a possibility to get their source code for the DDE CIN to expand on that, didn't give the desired result either. However integration into the system tray can - and I think actually only - be done trough calls into shell APIs. The problem here is that you need to support some event mechanisme which the tray API does by callbacks and that will require some C code interface such as a CIN or DLL. George Zou has such Vis, maybe that he would be willing to provide them for this project. They would however have to be integrated through a plugin architecture to avoid hard dependencies on Windows only functionality. Rolf Kalbermatter CIT Engineering Nederland BV Treubstraat 7H 2288 EG Rijswijk Tel: +31 (0)70 415 9190 The Netherlands Fax: +31 (0)70 415 9191 |
|
From: Jim K. <jim...@ja...> - 2005-03-24 06:12:15
|
Brian, I tried the new release and it is working great for me. I encourage all = of the OpenG folks out there to download this tool and give it a try -- it' great. Thanks again, Brian, for your generous donation of licenses to = OpenG developers. Best Regards, -Jim Kring=20 > -----Original Message----- > From: ope...@li...=20 > [mailto:ope...@li...]=20 > On Behalf Of Brian Gangloff > Sent: Wednesday, March 23, 2005 7:22 PM > To: ope...@li... > Subject: FW: OpenG builder and beta software >=20 > Here's a note that I sent to Jim earlier explaining what's in=20 > the latest > release of LVC. I forgot to copy the list in on the first=20 > send, so here it > is. >=20 > Hi Jim, >=20 > Jim Kring wrote: > >=20 > > > > Yes, that would be great. I've really grown to like the LVC > > >=20 > > > Thanks for the feedback > > >=20 > >=20 > > Here's some more... > >=20 > > I'd like to be able to config LVC to automatically launch > > files in the version of LabVIEW that they are compiled for=20 > > (or the lowest version of LV installed, whichever is greater). >=20 > This is now available by adding Auto=3DTrue to the=20 > LVC_Action.ini file. The > LVC_Action.exe UI still flashes since a window has to be open=20 > for the exe to > complete. Let me know how it works for you. I was thinking=20 > of putting a > small delay that would allow a function key to override the automatic > feature?=20 >=20 > > I'd like to be able to right-click on LLB files and convert > > them to folders containing VIs. There is an OpenG VI that=20 > > can do this conversion (attached). Each time I want to do=20 > > this (and I do it a lot, because I hate LLBs during=20 > > development), I have to do the conversion manually -- it's=20 > > slow. Having a shell extension for this conversion would be great! >=20 > I haven't completed this yet due to the fact that I want to=20 > allow for a > plug-in architecture. Here are some of the other actions that I was > considering adding to the right-click (or extended SHIFT=20 > right-click) menu: > -LLB to Directory > -Mass Compile > -Print > -Use as template (operate on directory =3D> copy and then use=20 > OpenG rename > folder of vis...) >=20 > The latest version can downloaded at > http://downloads.dataact.com/LVC-1.0.10.369(beta)-setup.exe >=20 > Or use the update button from the LVC_About window >=20 > There is a problem with the 1.0.8.334 uninstaller, but it=20 > shouldn't matter > if you are planning on upgrading since there is no need to=20 > uninstall LVC > before installing a newer version. However, if anyone wants=20 > to be able to > uninstall 1.0.8.334 without upgrading here is a link to a working > uninstaller (This will only work if you have not tried to=20 > uninstall with the > current uninstaller) >=20 > http://downloads.dataact.com/Uninstall.zip >=20 > I also added the ability to get another file's version by=20 > dragging it to an > empty space on the LVC_Version window. >=20 > My idea of the keeping LVC in the system tray isn't going to=20 > work since the > NI DDE VIs don't allow a DDE server to receive commands. >=20 > I will let you know when the plug-in architecture is ready. >=20 > Regards, > Brian >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by Microsoft Mobile & Embedded=20 > DevCon 2005 > Attend MEDC 2005 May 9-12 in Vegas. Learn more about the=20 > latest Windows > Embedded(r) & Windows Mobile(tm) platforms, applications &=20 > content. Register > by 3/29 & save $300 http://ads.osdn.com/?ad_idh83&alloc_id=15149&opLk > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers >=20 |
|
From: Brian G. <bri...@da...> - 2005-03-24 03:22:16
|
Here's a note that I sent to Jim earlier explaining what's in the latest release of LVC. I forgot to copy the list in on the first send, so here = it is. Hi Jim, Jim Kring wrote: >=20 > > > Yes, that would be great. I've really grown to like the LVC > >=20 > > Thanks for the feedback > >=20 >=20 > Here's some more... >=20 > I'd like to be able to config LVC to automatically launch > files in the version of LabVIEW that they are compiled for=20 > (or the lowest version of LV installed, whichever is greater). This is now available by adding Auto=3DTrue to the LVC_Action.ini file. = The LVC_Action.exe UI still flashes since a window has to be open for the = exe to complete. Let me know how it works for you. I was thinking of putting = a small delay that would allow a function key to override the automatic feature?=20 > I'd like to be able to right-click on LLB files and convert > them to folders containing VIs. There is an OpenG VI that=20 > can do this conversion (attached). Each time I want to do=20 > this (and I do it a lot, because I hate LLBs during=20 > development), I have to do the conversion manually -- it's=20 > slow. Having a shell extension for this conversion would be great! I haven't completed this yet due to the fact that I want to allow for a plug-in architecture. Here are some of the other actions that I was considering adding to the right-click (or extended SHIFT right-click) = menu: -LLB to Directory -Mass Compile -Print -Use as template (operate on directory =3D> copy and then use OpenG = rename folder of vis...) The latest version can downloaded at http://downloads.dataact.com/LVC-1.0.10.369(beta)-setup.exe Or use the update button from the LVC_About window There is a problem with the 1.0.8.334 uninstaller, but it shouldn't = matter if you are planning on upgrading since there is no need to uninstall LVC before installing a newer version. However, if anyone wants to be able = to uninstall 1.0.8.334 without upgrading here is a link to a working uninstaller (This will only work if you have not tried to uninstall with = the current uninstaller) http://downloads.dataact.com/Uninstall.zip I also added the ability to get another file's version by dragging it to = an empty space on the LVC_Version window. My idea of the keeping LVC in the system tray isn't going to work since = the NI DDE VIs don't allow a DDE server to receive commands. I will let you know when the plug-in architecture is ready. Regards, Brian |
|
From: Jim K. <jim...@ja...> - 2005-03-19 18:52:02
|
Martin, > I can work with the CVS if I use ssh instead of ext ... Great. BTW, I noticed that you committed some new files. "comm wait for bytecount.vi" is missing "Error Maker.vi" (see missing VIs below): D:\project\lv6.lib\Error\error exception.vi D:\project\lv6.lib\Error\_subvi\Single Error Exception.vi D:\project\lv6.lib\Error\Error Maker.vi I suggest using the OpenG "Build Error Cluster" function, or include your Error VIs as support functions in the serial library. Regards, -Jim > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] > On Behalf Of Martin Henz > Sent: Saturday, March 19, 2005 7:22 AM > To: ope...@li... > Subject: Re: CVS / serial > > Hi Jim, > > Jim Kring wrote: > > > I just tried the CVSROOT: > > > :ext:mh...@cv...:/cvsroot/opengtoolkit > > > Using your password, and it worked fine for me. > > > I'm perplexed. Maybe you should try from another machine. > Do you have > > windows firewall (or other) installed? Any network issues? > > I can work with the CVS if I use ssh instead of ext ... > > :ssh:mh...@cv...:/cvsroot/opengtoolkit > > > > -- > Martin > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > |
|
From: Martin H. <mar...@mh...> - 2005-03-19 15:22:28
|
Hi Jim, Jim Kring wrote: > I just tried the CVSROOT: > :ext:mh...@cv...:/cvsroot/opengtoolkit > Using your password, and it worked fine for me. > I'm perplexed. Maybe you should try from another machine. Do you have > windows firewall (or other) installed? Any network issues? I can work with the CVS if I use ssh instead of ext ... :ssh:mh...@cv...:/cvsroot/opengtoolkit -- Martin |
4 messages has been excluded from this view by a project administrator.
