ShaunR

.......it creates a shedload of code that you have to maintain

I mentioned PHP because it is one I'm fairly competent in rather than as a reference to your examples. My grammar is shocking sometimes I'm actually forever [intentionally] circumventing LabVIEWs type safety. It was useful to stop me shooting myself in the foot when I was many moons younger but as the grey hairs rampage to my neck-line (and lower) I've come to view it more as a hindrance than a feature. I expect if you took it away I'd also bitch about that too , but it does sometimes prevent some truly elegant solutions and compact generic code. Variants (the feature that never was...lol) aren't really the same as variable length argument lists. I consider that the com-pane is the labview equivalent of a function prototype (one terminal for each argument). I have been down the route of just having a single variant input instead of a number of terminals, but the amount of code you have to write and tricks you have to pull to make it useful, is just not worth it. Readability also becomes non existent. I'd rather have someone elses cake and eat mine

Well. I think you mentioned something earlier about varArgs and PHP (which admittedly may be easier because it is interpreted at run-time) has the capability to accept variable length arguments (func_get_args). Like most of these sorts of things, I don't care how it's implemented; that's not my job. However, it would be nice if it did.

IC. I have actually come across this instance before where it was frustrating that I couldn't have different terminals for an override. It forced me to have "dummy" terminals which were only functional in certain overrides which (to my mind) was unnecessarily confusing and meant more documentation. . (I didn't use LVPOOP because I wasn't talking about LV )

You can't win an emotional argument with logic!

That's the "She was asking for it" argument and says it all really!

Indeed. However removing diagrams is a maintenance nightmare if you are providing cross-platform, multi-version support. I use the password protection on the installer for the SQLite API For LabVIEW. Mainly to hide the mess underneath , but also because it's actually another development (a "Wizard Creator") that was co-opted very early in it's development to be used as a quick and dirty installer and can be a bit pedantic when fiddled with. If someone hacks that, it's just a testament to their character rather than a serious commercial implication for me. The API itself (the real software) is open source and relies on the "honor" system for purchasing which most of the LV community have the integrity to adhere to. However. If I had tried to make the installer "source-less" I would have ended up with 8 installers (and counting) just for windows let alone the other OSs.

Haven't read the whole thread (i.e the replies) as yet so might be going off half-cocked (as per usual). But is this definition (Must implement) just another name for abstract? Reference

Well. The adult way to go about it is to furnish NI with the exploit so they have the chance of evaluating whether they want to expend the effort in plugging it before you release it into the public domain. This would allow you to gain a moral position rather than just looking like a petulant script kiddie. Careers have been made this way and the skills are usually prized rather than punished. White hats and black hats come from the same milliners, however they are viewed and treated very differently both in the community and in the law courts.

Resolution isn't that important for Iris recognition (labview can achieve sub-pixel accuracy and the relative proportions of the eye are quite large). Focus and noise is more of a consideration. Therefore it is important you don't buy a webcam with a fixed focus (mobile phones have auto-focus which makes them extremely useful, webcams don't tend to) You've probably seen the simple ones with the annulus (Find Circles) that do some distance measurements (Caliper), but you can achieve better than that with LabVIEW and detect the number and sizes of "dark spots" (Particle Analysis Report) and changes in color, shading and discontinuities (ROI Profile).

You'd better hope that NI don't take you to task over the licensing of their closed-source, proprietary software then. (you admitted earlier that you are attempting to breach their licensing conditions )

Softice is the tool of choice. However. There are easier ways that don't require "cracking" the file or finding the "branch".It's a bit of a moot point with regards to LV though. Most of the time it's just used to prevent critisism of messy diagrams and there are no real secrets hidden. If IP is the problem it's buried in the exe. So apart from the exercise or the challenge, there isn't a lot of point in cracking diagrams. You're better off spending the time going out and getting laid.

Why don't you write one as you seem to think it is indispensable?

Indeed. Ever since lavag.org went off and came back again. The reply editor has been kind of screwed in Firefox (well Waterfox actually) for quoting (using Chrome now ) Then my statement stands. It is in violation of dataflow.

In the previous example, closing the VI reference immediately before or in parallel to the second Open VI Reference function creates a race condition Surely this is a "bug" that violates dataflow.

Quite right. Poor terminology on my part. Done. Agreed.. All LV arrays are "rectangular" arrays, however this is inefficient for large data-sets. We could actually handle non-rectangular arrays by using arrays of DVRs internally (again, the premise being that we would only convert to "rectangular" when necessary on extraction).......just a thought!

A local variable will be the fastest except for putting the indicator outside (and won't kick in that particular optimisation as long as you read it somewhere I think). The queues, however will have to reallocate memory as the data grows, so they are better if you want all the data, but a local or notifier would be preferable as they don't grow memory.,

Yes. That's what you want, right? Fast? Also. LV has to task switch to the UI thread. UI components kill performance and humans cant see any useful information at those sorts of speeds anyway ( 10s of ms ) . If you really want to show some numbers whizzing around, use a notifier or local variable and update the UI in a separate loop every, say, 150ms.

Some people have successfully back-saved to earlier versions of LabVIEW. There are certain features of the API that use methods that weren't available in older versions of labview but, if I remember correctly, there were only 2 or 3 of them (mainly using recursion) HDF5 is a file format. SQLite is a database. Whilst SQLite has it's own file format it has a lot of code to search, index and relate the data in the file. You will have to write all that stuff to manipulate the data contained in a HDF5 file yourself. Not sure what you are asking here. Can you make an exe? Yes. Do you need to add things to an installer? Yes-the sqlite binary. Yup. Looks really easy Now decimate and zoom in a couple of times with the x data in time (lets compare apples with apples rather than with pips) What I was getting at is that you end up writing search algos, buffers and look-up tables so that you can manipulate the data (not to mention all the debugging). Then you find its really slow (if you don't run out of memory), so you start caching and optimising. Databases already have these features (they are not just a file structure) , are quick and really easy to manipulate the data with efficient memory usage. Want the max/min value between two arbitrary points? Just a query string away rather than writing another module that chews up another shed-load of memory. Having said that. They are not a "magic bullet". But they are a great place to start for extremely large data sets rather than re-inventing the wheel, especially when there is an off-the-shelf solution already. (TDMS is a kind of database by the way and beats anything for streaming data. It gets a bit tiresome for manipulating data though)

You'll end up writing a shed-load of code that realises your own bespoke pseudo database/file format that's not quite as good and fighting memory constraints everywhere Much easier just to do this:

The easiest (and most memory efficient) solution is to pre-process the file and put the data in a database and then use queries to decimate. Take a look at the "SQLite_Data Logging Example.vi" contained in the SQLite API for LabVIEW. It does exactly what you describe but with real-time acquisition..

Done. Agreed.. All LV arrays are "square" arrays, however this is inefficient for large data-sets. We could actually handle non-square arrays by using arrays of DVRs internally (again, the premise being that we would only convert to "square" when necessary on extraction).......just a thought!