Jump to content

jgcode

LabVIEW Tools Network
  • Posts

    2,397
  • Joined

  • Last visited

  • Days Won

    66

Everything posted by jgcode

  1. Will do. Done! I have added a Status to the top of the post. When the review is final, I will create a summary post and add a link in the OP under the Status. I will then lock the topic so there are no more posts, forming an archive for the review. As this change will be submitted (and consequently published as a package), any further discussion of the VI would warrant a new review for new changes.
  2. I hope that is not part of the punchline.
  3. Yer, the iPhone App has some Mod functions too. I accidentally deleted someones post (went to hit Quote but obviously missed!) but had to get to a PC to restore it.
  4. It turns out there is only 8. Therefore, I will change my question to: You obviously understand octet?
  5. Hi Shaun, thanks for your reply. Here is some interesting points from testing (note: I did it in 2011 as I had it fired up at the time) after I stripped out the new argument: The arrays inside or outside the loop made no difference I cut and pasted your arrays in - this made it faster. It must be to do with the Search 1D Array primitive? Did you optimize the order of elements in the array? I replaced the order of the tests (e.g. ran your VI in first frame, mine in last frame (in the performance test) and this changed the results! It made mine faster. Can you verify this? With the new argument stripped its pretty similar however, if the argument is to be removed I think your version (above) is better (I had constraint of handling both arguments when I wrote the proposed VI). Cheers -JG
  6. Thanks for the feedback Jim, the Remove non-printable characters (False) argument was a feature of Fast Trim so I included it in the proposed VI however, I had to make Fast Trim fit the original OpenG Trim Whitespace leading/trailing interface. i agree with respect to orthogonal functionality - we could definitively decompose it into two VIs. What do others think?
  7. You obviously understand binary?
  8. You are welcome my friend. OpenG's direction is definitely a forward one. Currently the 4.0 release is in LabVIEW 2009. The cool thing about packages is that you can always install an older version. Unfortunately new updates in later versions would not be available (obviously). We would love to have you on board if the above works for you (be that now or in the future).
  9. Wow, I thought they would have compression on those things. Reminds me of when I handled raw AVI back in the day. Anyways, sounds like a plan. Can't wait. Cheers for your time recording the sessions.
  10. Howdy! I am trialing a new model of review for OpenG VIs. I want to enlist the help of the entire LAVA community. If the VI under review is one that you use in your projects, interests you, or you just have a moment free whilst hanging out on LAVA (I mean, where else would you rather be, right?), then please check it out and leave your feedback. The aim is - to steal a line from Christina - to get more eyes on the VIs I am hoping this will lessen the load on individual reviewers whilst increasing the quality of the changes (or proposed changes). This model is based on the assumption that there are a lot of Community folk who would like to contribute to OpenG but don't have the time to commit on a regular basis. The reviews posted may be in the form of specs or actual VIs etc... Feel free to leave your feedback in the form of comments, documents, code (changes, tests) or whatever makes sense! You can get started by checking out the newly proposed Trim Whitespace VI code. The LabVIEW community appreciates your time. Kind regards Jonathon Green OpenG Developer PS - Of course, if you are interested in contributing more to OpenG, please PM me!
  11. This OpenG Review is now closed. See Summary Post here. Please start a new thread to discuss new changes to this VI. Community, This is the integration of ShaunR's Fast Trim to OpenG's Trim Whitespace function. Please review the code and submit all comments below. On testing PC the new Trim Whitespace VI is >3x faster than the native version and ~5x faster than current OpenG version. Aside from the algorithm change the VI is now a subroutine (like natvie version). The new interface supports an additional argument Remove non-printable characters (False), see BD for further comments. Kind regards Jonathon Green OpenG Developer Trim Whitespace (String) 1.vi TEST - Trim Whitespace (Performance).vi TEST - Trim Whitespace 1.vi
  12. OpenG to the rescue? <!-- copy and paste. Modify height and width if desired. --> <object id="scPlayer" width="1288" height="638" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LabVIEW%202011/media/08629e27-bbc8-4451-a4c4-560ee04ec845/jingswfplayer.swf" > <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LabVIEW%202011/media/08629e27-bbc8-4451-a4c4-560ee04ec845/jingswfplayer.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFFFFF" /> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LabVIEW%202011/media/08629e27-bbc8-4451-a4c4-560ee04ec845/FirstFrame.jpg&containerwidth=1288&containerheight=638&content=http://content.screencast.com/users/jgcode/folders/LabVIEW%202011/media/08629e27-bbc8-4451-a4c4-560ee04ec845/OpenG%20Cluster%20to%20V%20Array.swf&blurover=false" /> <param name="allowFullScreen" value="true" /> <param name="scale" value="showall" /> <param name="allowScriptAccess" value="always" /> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LabVIEW%202011/media/08629e27-bbc8-4451-a4c4-560ee04ec845/" /> Unable to display content. Adobe Flash is required. </object>
  13. I think there was talk of Mark filming some of the sessions and posting them up on LAVA. That would be great to see (hint, hint, nudge, nudge, know what I mean?)
  14. As mentioned above: I am sure AQ has commented on this before? What would you do with the flag? You would have to run precheck code in every public method and handle exceptions. That sounds like a lot of work.
  15. ...and LabVIEW in general, which is why it's so much fun!
  16. See here: My LVOOP class control has a black border, what does that mean?
  17. Yes - you can have different constructor CP's for each Class. The only things I can currently think of are: You must have a unique name for each Constructor VI for Classes with children Using a Constructor in a pure LVOOP Plug-in architecture may require a Wrapper VI so the API (i.e. Interface) is standardised across all public methods.
  18. FWIW the constructor method I present in the video link does not use dynamic input/outputs. Using type-defs in Classes is a whole 'nother thread. However, using a cluster is not the best interface - you should use separate accessors methods for each property IMHO.
  19. This seems like a lot of work in comparison - do you use this often and prefer it over the constructor/init method? Are you able to comment on pros/cons? Cheers -JG
  20. I like the idea and have similar questions to Greg. Can you provide more info on how they would be 'used' please. What is your vision for blogs on LAVA? LAVA used to have them right?
  21. The cool thing is the settings persist from full site to the mobile version (I can't see where to change then on mobile version) - now I have mobile 'portal' - love it.
  22. I am up for trying anything new - so I like it to Plus like works in mobile version when reps don't.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.