ShaunR

"Read"

 
Yet you, and me, and others make the compromise (or make the mistake) of sometimes using Dynamic Dispatch purely for the Must Override and Must Call Parent contract. 

Nope. It's not as effervescent as that in this case. I care not for architectural astronautics

The override is used because of "re-use" and to avoid code replication which is not a pre-requisit for override which is generally used either to modify the object or as a placeholder. The override enables me to put operations that are identical in all the child classes  (error translation for example) into a single location. The dynamic dispatch is still, however, required as the child (in the example, the protocol) is still determined at run-time. This is no different from the parent calling the "Read" from within a case-statement (where each case is a different protocol) and then carrying on to process the result of the call. However, with the case statement scenario I could indeed have different terminals for each protocol.
 

And using a class instead of input fields doesn't work because.......

rolf, you really now are getting flarn and I confused. You know we are two different forum members right?

In the world you have three sorts of friends: Your friends who love you, your friends who do not care about you, and your friends who hate you.

I didn't mention PHP, but instead Lua. Lua is not interpreted but compiled into byte code, just like .Net, Python and others. I don't think it makes that much difference if a language is interpreted, compiled or byte coded, in terms of vararg implementation. The most close vararg analogy in LabVIEW would be Variants.

 

Ohh you say that it is a pain to implement and maintain such an interface? But so are all vararg type interfaces! In terms of typesafety, stack boundery handling and all that, you can't have the cake and eat it too!

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

But how could you define a super-abstract method and use it anywhere except in the implementor of that method (and possibly inherited classes from the implementor)? LabVIEW, C(++) and Java all have a parameter interface that is defined at compile time, so needs to be well known when compiling and therefore no one who doesn't see the full interface definition of a method can possibly use it.

C allows some trickery with function pointer casting but that is not only ugly but outright dangerous. C++ is much more strict in that sense and normally doesn't allow function pointer casts just as Java, which doesn't really know anything about casting other than between compatible objects.

 

Lua goes in fact into that direction, as functions are themselves full objects and can have variable number of arguments, with a function always knowing how many parameters it was passed to (and it of course shouldn't try to retrieve more parameters from the stack than it got passed, but the Lua engine protects that). In addition return parameters of functions are always returned as function return values and yes a function can have 0, 1, or any other number of return values too.

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.

I believe the 'abstract' concept from other languages typically defines the full function prototype, including parameters. Which makes 'abstract' more akin to Dynamic Dispatch than Must Implement. I'm suggesting Must Implement does not define the function parameters for subclasses.

 

(But perhaps Must Implement does require a minimum set of parameters; the object input, for instance, would be required in order to invoke 'Call Parent Method' <headscratch>gotta chew on that one</headscratch>).

 

(And a sincere virtual+1 to you for joining this thread without using the term LVPOOP  Perhaps the term 'functional programming' piqued your interest   Just ribbing.)

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    )

Your proposal sounds like my wife.  She often not only wants me to do something (lets think of this as the interface) but she also wants me do do it her way (your enforcement) even though this has no bearing on the start or end status of the operation.

 

By leaving the block diagram in the VI, they are throwing all the details on the street, as you put it.

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

The other thing to consider is, right or wrong, there are a number of people using this feature out there already. (I don't know numbers or anything but I have certainly seen it). I don't think they would be impressed in NI turned around and said its been compromised but we aren't going to attempt to improve the protection you are using on your IP. I do always recommend removing the diagram if it is highly sensitive though.

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.

That's all -- admittedly, the suggestion of 'Must Implement' is not OOP-y, and I'm still curious if any other languages address (either, have implemented, or have explicitly rejected) a notion such as 'Must Implement'.

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?

In an abstract class, you can also declare a method as abstract, which means that the method is not implemented and that any non-abstract subclass must implement it. An abstract method has no body:

Reference

That still doesn't mean it's smart for them to rely on it. Remember I said I was trying to get past the password protection? I was able to do so by changing only two bytes. As I said before though, I'm not comfortable posting it until I know for a fact I won't get sued.

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).

IMO, what would be best is to just get rid of the password protection entirely in LV 2013. Existing password-protected VIs would just open normally as if there wasn't a password. As for intellectual property, it's their fault for expecting miracles from what is essentially security through obscurity. If they care so much about their precious code, they can just remove the block diagrams, and deal with the side-effects. Open source is the way to go, and NI shouldn't help people hide their code. If the block diagram is accessible to LabVIEW, but it doesn't obey the user who wants to view it, that is certainly not user-friendly, and I could even go so far as to classify it as a bug. Though unfortunately I doubt NI will see it my way.

/rant

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 )

but somewhere, deep deep down in the loading routine of LabVIEW.exe is a branch instruction that allows or denies this.

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.

We need a new password cracker :-(

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

ShaunR, I'm slightly confused by your most recent post. I'm assuming the third quote attributed to me was actually your comment. I'm responding to that.

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 )

It may surpise you, but yes, there is a potential race condition there. Assuming the reference is the only thing holding the target VI in memory, the second call (by name) might return an error but it also might succeed.

Several LV releases ago, the Close Reference function was always asynchronous making it very common for the target VI to briefly remain in memory after the close. Somewhere around LV 8.2, I made a change that made the Close Reference synchronous much of the time. The keyword here is much. There are a variety of things that can determine whether or not the Close Reference will immediately.

 

So, if the Close Reference determines it cannot immediately dispose of the target VI, the referenced code is a race condition.

Then my statement stands. It is in violation of dataflow.

The image with two Open VI Ref calls does not violate dateflow. Unless I am missing something, the diagram is syntactically valid. If you believe there is a bug, will you elaborate?

It seems to say that opening a VI ref then closing it immediately before attempting to re-open by name (whilst linked via the error cluster) will cause a race condition. This should not be the case. The second call (by name) should always return an error in this example. If it doesn't, then it is violating dataflow since the ref should be at least marked as invalid if not completely removed from memory and, as there are no other open references, the second call should fail.

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.

You can go for me, next time!

(The grass is always greener...)

Square arrays? Equal dimension size? You must mean rectangular arrays or?

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!

Sure! I've added the indicators just for avoiding the "unused code/dangling pin" compiler optimization. You're right, it wasn't very clever, the queue idea is much better. The slow random number generator inside the for loop is there for the same reason to avoid unfair comparisons between the formula node SubVI and the standard one.

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.,

With output auto-indexing disabled, wouldn't the indicators outside the loop kick in compiler optimizations? Anyway, a queue in this case seems a better option.

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.

thanks for your advice. but the sqlite can't run when the version is below labview 2009.besides,

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)

how about the HDF5?if the sqlite is easier than HDF5?

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.

thanks. if the sqlite will influence make a .exe installer?

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.

If you had complex record types I would agree but this is just straight numeric data. A binary file is not that hard to work with and gives high performance random access with a smaller footprint than databases because it doesn't have all the extra functionality we are not using

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)

The advice for acquiring the data sounds good. Pulling the data in as chuncks for parsing and placing into preallocated arrays will keep things memory efficient.

The problem is that 100 million points is always going to cause you issues having it in memory at once. You also will find if you try and write this to a graph this requires a separate copy of the data so this is going to cause issues again.

I think you are going to have to buffer to disk to achieve this. You can do it as a database but I would be just as tempted to just put it to a binary file when you have a simple array. You can then easily access specific sets of elements from the binary file (you cannot do this easily with a text file) very efficiently. I think for the graph you are going to have to determine the best way to deal with this. You are probably going to have to decimate the data into it and then allow people to load more detail of the specific area of interest to minimise the data in memory at any given time.

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:

hi, I want to read and process large data(nearly 100 million rows,the file size over 500MB), the original format of the file is .txt, through rename as .dat we get the binary file. The attachment is my vi. When the file is larger than 1 million lines(the data is singal Column), there is a wrong with "the memory is full".I want to read the data and plot a graph in the time domain, on the graph I can see the detail by zoom tools; and then do some anlysis about FFT and Statistics .I don't know how to do decimation in chunks .another thing ,maybe the memory release is also important. can you help me? thanks!

the data from a dynamic strain test，the sampling rate is 10K/s。if we can get the whole result use a little data decimation from a chunk ,when we zoom some detail, such as in one chunk, we can get the whole data on the graph without decimation?thanks!

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..