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: Jim K. <jk...@ja...> - 2004-09-03 21:45:24
|
Hello, OpenG Developers I have just announced an OpenG Group meeting for next Tuesday (9/7). I would like to discuss the organization of project files and the build/package/release process. Additionally, there will be an update on the Coding Challenge, and other happenings. There is more information located here: http://www.openg.org/tiki/tiki-index.php?page=2004-09-07+Group+Meeting We will be having an online webcast and conference call so that you can join us remotely. Best Regards, -Jim Kring RSVP: jk...@op... |
From: Jim K. <jk...@ja...> - 2004-08-24 03:01:33
|
Hello All, FYI, a couple of weeks ago Dany Allard volunteered to help with the testing of the coding challenge entries. We are moving forward with this and hope to have it completed soon. More info coming soon. Regards, -Jim Kring |
From: Beuschel, A. <And...@os...> - 2004-08-02 15:44:36
|
Hi Jim, =20 all_packages-2.3.0.ogp.zip =20 this is the file I installed and I think the latest version available at that time I downloaded the file. =20 Best Regards ANDY _____ =20 From: ope...@li... [mailto:ope...@li...] On Behalf Of Jim Kring Sent: Saturday, July 31, 2004 1:26 PM To: ope...@li... Subject: RE: -variantconfig, -installation open G=20 Andy, =20 Which version of "all_packages" did you install? I'll try to reproduce your problem. =20 -Jim Kring _____ =20 From: ope...@li... [mailto:ope...@li...] On Behalf Of Beuschel, Andreas Sent: Monday, July 26, 2004 5:29 PM To: ope...@li... Subject: -variantconfig, -installation open G=20 =09 =09 HI!=20 I've installed the open G tools according to the tutorial for new Open G users.=20 -Is there a way to show the openG funcions dynamically in the 6.1 version (only in the 7.x I found this feature)=20 -during the installation I got an error message regarding the registry: something like I don't have the permission by the administrator to change registry=20 -later on I wanted to test the "Write Panel to INI__ogtk.vi" and ther was a failure message: Config Data Registry.vi [get data]: invalid object 0 is this message related to the problem during installation? Is it a problem with XP? Or LV 6.1?=20 - What can I do to get the test running?=20 Best Regards=20 Andy=20 __________________________________________________=20 Andreas Beuschel OSRAM Opto Semiconductor Inc. OLED R&D * 3870 North First Street, San Jose CA 95134 * (408) 456 4103 And...@os... <mailto:And...@os...> =20 |
From: Jim K. <jk...@ja...> - 2004-07-31 20:25:43
|
Andy, Which version of "all_packages" did you install? I'll try to reproduce your problem. -Jim Kring _____ From: ope...@li... [mailto:ope...@li...] On Behalf Of Beuschel, Andreas Sent: Monday, July 26, 2004 5:29 PM To: ope...@li... Subject: -variantconfig, -installation open G HI! I've installed the open G tools according to the tutorial for new Open G users. -Is there a way to show the openG funcions dynamically in the 6.1 version (only in the 7.x I found this feature) -during the installation I got an error message regarding the registry: something like I don't have the permission by the administrator to change registry -later on I wanted to test the "Write Panel to INI__ogtk.vi" and ther was a failure message: Config Data Registry.vi [get data]: invalid object 0 is this message related to the problem during installation? Is it a problem with XP? Or LV 6.1? - What can I do to get the test running? Best Regards Andy __________________________________________________ Andreas Beuschel OSRAM Opto Semiconductor Inc. OLED R&D * 3870 North First Street, San Jose CA 95134 * (408) 456 4103 <mailto:And...@os...> And...@os... |
From: Jim K. <jk...@ja...> - 2004-07-31 19:47:46
|
Hello, All There is a new release of all_packages (2.3.1). Better support was added for LV 7.1 on Mac OS X and Linux (Windows was already supported by 2.3.0). ogrsc_restart has not yet been updated to LV 7.1 on Linux (I haven't got my copy yet :-). Changes: all_packages 2.3.0 --> 2.3.1 -------------------------------------- ogrsc_dynamicpalette 0.7-1 --> 0.8-1 [NEW] supports LV 7.1 on all Platforms ogrsc_restart 1.1-1 --> 1.2-1 [NEW] supports LabVIEW 7.1 on Windows and Mac OS X Regards, -Jim Kring |
From: Jim K. <jk...@ja...> - 2004-07-31 19:42:03
|
-----Original Message----- From: SourceForge.net [mailto:no...@so...] Sent: Saturday, July 31, 2004 12:40 PM To: no...@so... Subject: [SourceForge.net Release] opengtoolkit : rsc_dynamicpalette Project: OpenG Toolkit (opengtoolkit) Package: rsc_dynamicpalette Date : 2004-07-31 12:39 Project "OpenG Toolkit" ('opengtoolkit') has released the new version of package 'rsc_dynamicpalette'. You can download it from SourceForge.net by following this link: <https://sourceforge.net/project/showfiles.php?group_id=52435&release_id=257 267> or browse Release Notes and ChangeLog by visiting this link: <https://sourceforge.net/project/shownotes.php?release_id=257267> You receive this email because you requested to be notified when new versions of this package were released. If you don't wish to be notified in the future, please login to SourceForge.net and click this link: <https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=5614 8> If you lost your SourceForge.net login name or password, refer to this document: <https://sourceforge.net/docman/display_doc.php?docid=760&group_id=1> Note that you may receive this message indirectly via one of your mailing list subscriptions. Please review message headers before reporting unsolicited mailings. |
From: Jim K. <jk...@ja...> - 2004-07-31 19:41:16
|
-----Original Message----- From: SourceForge.net [mailto:no...@so...] Sent: Saturday, July 31, 2004 12:38 PM To: no...@so... Subject: [SourceForge.net Release] opengtoolkit : all_packages Project: OpenG Toolkit (opengtoolkit) Package: all_packages Date : 2004-07-31 12:37 Project "OpenG Toolkit" ('opengtoolkit') has released the new version of package 'all_packages'. You can download it from SourceForge.net by following this link: <https://sourceforge.net/project/showfiles.php?group_id=52435&release_id=257 270> or browse Release Notes and ChangeLog by visiting this link: <https://sourceforge.net/project/shownotes.php?release_id=257270> You receive this email because you requested to be notified when new versions of this package were released. If you don't wish to be notified in the future, please login to SourceForge.net and click this link: <https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=6073 1> If you lost your SourceForge.net login name or password, refer to this document: <https://sourceforge.net/docman/display_doc.php?docid=760&group_id=1> Note that you may receive this message indirectly via one of your mailing list subscriptions. Please review message headers before reporting unsolicited mailings. |
From: Jim K. <jk...@ja...> - 2004-07-31 19:41:05
|
-----Original Message----- From: SourceForge.net [mailto:no...@so...] Sent: Saturday, July 31, 2004 12:37 PM To: no...@so... Subject: [SourceForge.net Release] opengtoolkit : rsc_restart Project: OpenG Toolkit (opengtoolkit) Package: rsc_restart Date : 2004-07-31 12:36 Project "OpenG Toolkit" ('opengtoolkit') has released the new version of package 'rsc_restart'. You can download it from SourceForge.net by following this link: <https://sourceforge.net/project/showfiles.php?group_id=52435&release_id=257 268> or browse Release Notes and ChangeLog by visiting this link: <https://sourceforge.net/project/shownotes.php?release_id=257268> You receive this email because you requested to be notified when new versions of this package were released. If you don't wish to be notified in the future, please login to SourceForge.net and click this link: <https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=1018 78> If you lost your SourceForge.net login name or password, refer to this document: <https://sourceforge.net/docman/display_doc.php?docid=760&group_id=1> Note that you may receive this message indirectly via one of your mailing list subscriptions. Please review message headers before reporting unsolicited mailings. |
From: Beuschel, A. <And...@os...> - 2004-07-27 00:29:35
|
HI! I've installed the open G tools according to the tutorial for new Open G users. -Is there a way to show the openG funcions dynamically in the 6.1 version (only in the 7.x I found this feature) -during the installation I got an error message regarding the registry: something like I don't have the permission by the administrator to change registry=20 -later on I wanted to test the "Write Panel to INI__ogtk.vi" and ther was a failure message: Config Data Registry.vi [get data]: invalid object 0 is this message related to the problem during installation? Is it a problem with XP? Or LV 6.1? - What can I do to get the test running? Best Regards Andy __________________________________________________ Andreas Beuschel OSRAM Opto Semiconductor Inc. OLED R&D * 3870 North First Street, San Jose CA 95134 * (408) 456 4103 And...@os...=20 |
From: Jim K. <jk...@ja...> - 2004-07-21 06:33:47
|
-----Original Message----- From: SourceForge.net [mailto:no...@so...] Sent: Tuesday, July 20, 2004 11:25 PM To: no...@so... Subject: [SourceForge.net Release] opengtoolkit : all_packages Project: OpenG Toolkit (opengtoolkit) Package: all_packages Date : 2004-07-20 23:25 Project "OpenG Toolkit" ('opengtoolkit') has released the new version of package 'all_packages'. You can download it from SourceForge.net by following this link: <https://sourceforge.net/project/showfiles.php?group_id=52435&release_id=254 626> or browse Release Notes and ChangeLog by visiting this link: <https://sourceforge.net/project/shownotes.php?release_id=254626> You receive this email because you requested to be notified when new versions of this package were released. If you don't wish to be notified in the future, please login to SourceForge.net and click this link: <https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=6073 1> If you lost your SourceForge.net login name or password, refer to this document: <https://sourceforge.net/docman/display_doc.php?docid=760&group_id=1> Note that you may receive this message indirectly via one of your mailing list subscriptions. Please review message headers before reporting unsolicited mailings. |
From: Jim K. <jk...@ja...> - 2004-07-21 06:33:44
|
-----Original Message----- From: SourceForge.net [mailto:no...@so...] Sent: Tuesday, July 20, 2004 11:22 PM To: no...@so... Subject: [SourceForge.net Release] opengtoolkit : rsc_restart Project: OpenG Toolkit (opengtoolkit) Package: rsc_restart Date : 2004-07-20 23:22 Project "OpenG Toolkit" ('opengtoolkit') has released the new version of package 'rsc_restart'. You can download it from SourceForge.net by following this link: <https://sourceforge.net/project/showfiles.php?group_id=52435&release_id=254 639> or browse Release Notes and ChangeLog by visiting this link: <https://sourceforge.net/project/shownotes.php?release_id=254639> You receive this email because you requested to be notified when new versions of this package were released. If you don't wish to be notified in the future, please login to SourceForge.net and click this link: <https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=1018 78> If you lost your SourceForge.net login name or password, refer to this document: <https://sourceforge.net/docman/display_doc.php?docid=760&group_id=1> Note that you may receive this message indirectly via one of your mailing list subscriptions. Please review message headers before reporting unsolicited mailings. |
From: Jim K. <jk...@ja...> - 2004-07-21 06:33:41
|
-----Original Message----- From: SourceForge.net [mailto:no...@so...] Sent: Tuesday, July 20, 2004 11:19 PM To: no...@so... Subject: [SourceForge.net Release] opengtoolkit : mnu_classic_sync Project: OpenG Toolkit (opengtoolkit) Package: mnu_classic_sync Date : 2004-07-20 23:19 Project "OpenG Toolkit" ('opengtoolkit') has released the new version of package 'mnu_classic_sync'. You can download it from SourceForge.net by following this link: <https://sourceforge.net/project/showfiles.php?group_id=52435&release_id=254 637> or browse Release Notes and ChangeLog by visiting this link: <https://sourceforge.net/project/shownotes.php?release_id=254637> You receive this email because you requested to be notified when new versions of this package were released. If you don't wish to be notified in the future, please login to SourceForge.net and click this link: <https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=1122 69> If you lost your SourceForge.net login name or password, refer to this document: <https://sourceforge.net/docman/display_doc.php?docid=760&group_id=1> Note that you may receive this message indirectly via one of your mailing list subscriptions. Please review message headers before reporting unsolicited mailings. |
From: Jim K. <jk...@ja...> - 2004-07-21 06:33:35
|
Hello, all I have found some time to update the openg toolkit to support LV7.1 on Windows (other platforms should follow in the near future). This was a problem with the Dynamic Palette View (dynamicpalette) package. Additionally I have updated Restart LabVIEW (restart) for LabVIEW 7.1 on Windows, and I have added a new package called "classic_sync" that adds the classic queue and notifier submenus to the "Synchronization" palette. Please download and test. I'll FW the (SourceForge) file release announcements to the list, which includes links to the downloads. Regards, -Jim Kring |
From: Brian G. <bri...@da...> - 2004-04-19 22:15:41
|
Jim Kring wrote: > One of the main issues at the moment is that when I run the testers I > get slightly different results (primarily for the top entries). I > have been running the tester on LV 7.0 and Windows XP. I have reduced > the problems by disabling my network adapter and shutting down > anti-virus and other services. However, there are still some problems. Unfortunately I believe that you have found the limitation of the measurement system and perhaps the top entries are equal in performance? Since we are using the built in MS timer we must run the code N times and average to get the actual time per iteration. N must be chosen so that it is large enough such that the 1 msec resolution (and overhead of reading the MS) timer becomes insignificant as compared to the actual time per iteration. But as N gets larger, the total time increases which gives a greater chance that the CPU may get hijacked for another Windows task. You have minimized this by shutting down services but there will always be something. (Don't move the mouse during testing) If you have a DAQ card available, you could use one of the counter/timers to get a 20MHz timestamp which solves the resolution issue, but there is still the issue of not knowing how much of the time for one iteration is due to reading the timer. The attached VI shows the variability. Christian introduced the concept of picking the fastest run and not averaging which I can agree with as long as memory leaks and other issues that could cause worsening performance over time are caught by another test. If so, you could use the test harness as it is to get the VI's that are performing equally and then we could pick the one test that was most representative of the task and run it many times with the hardware timer. The winner would be the one with the single fastest time? Or since the top performers may be equal in performance, you could use one of the other criteria as the tie break > Would it help if I made copies of all the entries available to those > of you who want to work on the test harness? I could password protect > them all, first. I've been using different versions of my own VI's so I don't need copies for development purposes. |
From: Jim K. <jk...@ja...> - 2004-04-17 23:43:40
|
Brian, Yes, I think that there is still a bit of work to do on the tester. Unfortunately I have a grueling deadline -- we are trying to ship a product by Thursday. One of the main issues at the moment is that when I run the testers I get slightly different results (primarily for the top entries). I have been running the tester on LV 7.0 and Windows XP. I have reduced the problems by disabling my network adapter and shutting down anti-virus and other services. However, there are still some problems. Would it help if I made copies of all the entries available to those of you who want to work on the test harness? I could password protect them all, first. -Jim Brian Gangloff wrote: > First I must apologize for not having my code ready and secondly for > not letting everyone know that I have been delayed. Since Christian > has already posted a tool for the "Remove Backspace" challenge I have > let my test harness slip thinking that the immediate need has been > satisfied. Is this a safe assumption? > Brian > |
From: Brian G. <bri...@da...> - 2004-04-16 21:42:50
|
First I must apologize for not having my code ready and secondly for not letting everyone know that I have been delayed. Since Christian has already posted a tool for the "Remove Backspace" challenge I have let my test harness slip thinking that the immediate need has been satisfied. Is this a safe assumption? Brian |
From: Jim K. <jk...@ja...> - 2004-04-16 16:28:12
|
Derrick, As Rolf mentioned, the OpenG version of "Current VIs Path.vi" behaves just like LabVIEW native (primitive) function "Current VIs Path", which is found in the File Constants palette. The one improvement of the OpenG version is that you can pass in a relative path -- in your case you could pass in a ".." to produce the path to the folder (or LLB) containing the VI. You will also notice several other File Constants on the OpenG palette which are found in the primitive File Constants palette. All these have behavior that is defined by the primitives. Thanks for posting your modified version. We welcome participation! Regards, -Jim Swinarsky, DJ Derrick (5453) @ IS wrote: >If that is the desired output, then I will go along with it. > >Derrick > >p.s. Sorry for posting the modified version to the mailing list. After I >sent the email I thought that it might not have been a smart idea... > >-----Original Message----- >From: Rolf Kalbermatter [mailto:rol...@ci...] >Sent: Friday, April 16, 2004 11:10 AM >To: ope...@li... >Subject: RE: Current VI's Path > > >Swinarsky, DJ Derrick (5453) @ IS wrote: > > > >>I believe there may be an error within Current VI's Path... >>or just don't understand why it works as it does. >> >> > >Well, this is about what is the definition of a path. For some >a path is just the entire absolute path to a file or directory, >for others it is the absolute path to the directory a file is >in. I personally tend to the first category. >Some use filename to indicate the entire path to a file and >others mean with filename only the last component in a path. > >What is right and what is wrong? I guess nobody and anybody! >Microsoft itself is not consistent in its MSDN API documentation >for the Win32 API in this and so are most other API documentations. > >At least in the LabVIEW documentation a path is just a specific >datatype which can be absolute, relative, or invalid and can point >to a volume, directory or file. The constant returning the path of >the Current VI uses the same convention as is used in the original >OpenG VI. > >Rolf Kalbermatter > > > |
From: Swinarsky, DJ D. (5. @ I. <d.s...@L-...> - 2004-04-16 16:13:43
|
If that is the desired output, then I will go along with it. Derrick p.s. Sorry for posting the modified version to the mailing list. After I sent the email I thought that it might not have been a smart idea... -----Original Message----- From: Rolf Kalbermatter [mailto:rol...@ci...] Sent: Friday, April 16, 2004 11:10 AM To: ope...@li... Subject: RE: Current VI's Path Swinarsky, DJ Derrick (5453) @ IS wrote: > I believe there may be an error within Current VI's Path... > or just don't understand why it works as it does. Well, this is about what is the definition of a path. For some a path is just the entire absolute path to a file or directory, for others it is the absolute path to the directory a file is in. I personally tend to the first category. Some use filename to indicate the entire path to a file and others mean with filename only the last component in a path. What is right and what is wrong? I guess nobody and anybody! Microsoft itself is not consistent in its MSDN API documentation for the Win32 API in this and so are most other API documentations. At least in the LabVIEW documentation a path is just a specific datatype which can be absolute, relative, or invalid and can point to a volume, directory or file. The constant returning the path of the Current VI uses the same convention as is used in the original OpenG VI. Rolf Kalbermatter ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ OpenGToolkit-Developers mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers |
From: Rolf K. <rol...@ci...> - 2004-04-16 16:09:54
|
Swinarsky, DJ Derrick (5453) @ IS wrote: > I believe there may be an error within Current VI's Path... > or just don't understand why it works as it does. Well, this is about what is the definition of a path. For some a path is just the entire absolute path to a file or directory, for others it is the absolute path to the directory a file is in. I personally tend to the first category. Some use filename to indicate the entire path to a file and others mean with filename only the last component in a path. What is right and what is wrong? I guess nobody and anybody! Microsoft itself is not consistent in its MSDN API documentation for the Win32 API in this and so are most other API documentations. At least in the LabVIEW documentation a path is just a specific datatype which can be absolute, relative, or invalid and can point to a volume, directory or file. The constant returning the path of the Current VI uses the same convention as is used in the original OpenG VI. Rolf Kalbermatter |
From: Swinarsky, DJ D. (5. @ I. <d.s...@L-...> - 2004-04-16 15:47:28
|
I believe there may be an error within Current VI's Path... or just don't understand why it works as it does. The output includes the Current VI's name instead of just the path. Is this the desired behaviour? I would have guessed that this would not give the filename.vi. As a workaround I am just adding an extra '..\' in the path I send into it. Attached is my modified version that removes the filename from the path. Please let me know if this is not the desired output and possibly the rational behind keeping the vi name with the path. Thanks, Derrick |
From: ALTENBACH,CHRISTIAN <cal...@uc...> - 2004-04-05 07:32:58
|
Well, I made a rough draft of my test suggestion. www.bol.ucla.edu/~caltenba/backspace_testerA010.zip To run, just select a folder containing several VIs conforming to the connector pattern of the backspace VI. It tests 6 different input strings, including empty. It uses the following scoring algorithm: - For each test, divide all times by the fastest to get normalized values. - For each VI, take the average of the normalized values. - Score = 100/Average. (Best possible score is 100% if VI is fastest on all tests.) There are some sparse comments on the diagrams. Lots of loose ends in the code, some held together by duck tape, but it seems to run fine. I'll document it a bit better later. Cheers Christian |
From: Jim K. <jk...@ja...> - 2004-04-03 17:23:49
|
Brian Gangloff wrote: > 4. Can we create a batch that completely quits LabVIEW between test VI's? Or even better, how about a LabVIEW executable that controls the development environment? I have been working on a tool called "lvbld" that allows building LabVIEW applications (as defined by .bld files) from the command-line on the Linux and Windows platforms. It is an executable application that communicates with the LabVIEW development environment using VI Server over TCP-IP. This methodology could possibly be used in the Remove Backspace test harness. When lvbld is run, it attempts to connect to LabVIEW using VI Server. If it cannot connect, it launches LabVIEW from the command-line, and then attempts to establish VI Server communication until a timeout is reached (see "lvbld.ini Settings" section, below, for a listing of lvbld settings). Once a VI Server connection (Application Reference) is established a strict VI reference is opened to <.\project\prodisttool.llb\_Build Application from Script.vi> which is called by reference. Finally, when all the builds are complete the remote application is shutdown, if it was not open prior to running lvbld. VI Server does not provide any means for shutting down an application. But, since both lvbld and LabVIEW share the same file system space, LabVIEW can me made to call VIs within lvbld (since LabVIEW executables are just glorified LLBs). A VI called app_exit.vi is included in the lvbld exe and contains a call to the "Quit LabVIEW" primitive. lvbld causes the LabVIEW development environment to run this VI and thereby causing it to exit. If you want to take a look at the lvbld source, it is located here: http://www.openg.org/tiki/tiki-index.php?page=LVBLD+-+Command+Line+Build+Tool -Jim |
From: Jim K. <jk...@ja...> - 2004-04-03 16:35:47
|
Prior to running, changes are made to priority, execution system, etc. and then the VI is saved. This way they are compiled prior to running. -Jim Paul F. Sullivan wrote: > I assume that all entries are compiled and saved for the LabVIEW > version and platform of testing before hand, but that is an assumption. > > Changing the priority or reentrancy also causes an asterisk to appear. > Do such operations also cause a compile lag on the first run after the > change? > > Paul > |
From: Paul F. S. <Pa...@SU...> - 2004-04-03 13:14:46
|
I assume that all entries are compiled and saved for the LabVIEW version and platform of testing before hand, but that is an assumption. Changing the priority or reentrancy also causes an asterisk to appear. Do such operations also cause a compile lag on the first run after the change? Paul |
From: Bookwalter, D. <Dan...@hs...> - 2004-04-03 02:30:25
|
well if you guys really want to test 'any' of your VI's i have someone working where i work that can challengE ANY-thing you can come up with!!!! just me being frustrated, no matter what i do i cant make these programs tight enough for this/these individual(s) not to break it/them.... hell one of these people broke XP within 30 mins... i had to completly re-install XP.... have a good weekend all......... Dan -----Original Message----- From: ALTENBACH,CHRISTIAN To: ope...@li... Sent: 4/2/04 12:56 PM Subject: Re: "Remove Backspace" test harness > can just pick up were we left off and everyone can get up to speed on > the issues without too much effort. I see several issues that must be discussed. (1) A good set of test strings. =============================== I would think that in real life such a VI typically encounters relatively short inputs with only a few \b characters. (In this respect, the current test string is quite pathological). A VI needs to be fast under all kinds of inputs and should not encounter slowdowns under certain conditions, so I suggest the following set of strings (to be expanded as needed): - an empty string - A short string (currently I use "XX\b\b\b\bAAAA\b\b\bBCC\bDXXX\b\b\b"=ABCD) - Jim's long string - A string of 1000000 characters (no \b!) - A string of 1000000 \b characters - A string of 1000000 characters, all even numbered characters are "\b". Suggestion for scoring: The times for each string are normalized to the fastest time (e.g. if one candidate is 10% slower, it would get a 1.1). Winner will have lowest average score, which could be as low as 1 if it is fastest on all strings (unlikely?). (2) VI settings =============== I am not sure if we should force priorities/reentrant on the VIs as currently done, but if so, what should the settings be? (3) VI execution ================ There are several ways to execute the VIs. Jim uses "invoke node" while my current VI uses "call by reference node". Jim sets the actual VI to "time critical", I set the core tester VI to "time critical", while setting the test subject to subroutine. What is better and why? What more realistically models the use in a real application? (4) Timing ========== Due to the ms timer resolution, the test must last at least a few hundred ms to get a few significant digits. Fast running VIs need to be called inside a loop, with the loop count tuned to the execution time. I would not use any averaging of runs, but do multiple runs, then pick the fastest. (All OS disturbances tend to lengthen the time!) 'later Christian ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ OpenGToolkit-Developers mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers _____________________________________________________________________ This electronic mail transmission contains confidential information intended only for the person(s) named. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you received this transmission in error, please send an electronic mail message to pos...@hs.... |