ShaunR

Do you still have the same issue if you put the assembly in the system32 folder?

• Interviewer#3 :So, do you have an exact itinerary of where you will drive and park?
  
• Me: Yes I do.
  
• Interviewer#3 : Can I see it?
  
• Me : Of course. Do you have signatory authority to sign this non-disclosure agreement?
  
• Interviewer#3 : No.
  
• Me : Then perhaps I need to speak with someone who does. I can only give you that information if you sign the agreement.
  

it's the desire for the three current language benefits of overrides (defining the parent-child relationship, ability to require implementation, and ability to require calling parent for object construction and re-use), just without the requirement of the defined ConPane.

Yup. Except that it's not just the "ability to require implementation" currently, is it?. It's the ability to require implementation with identical arguments. I could re-architect so that the dummies weren't required. In fact, I did start out on that route. What you are seeing is "after" refactoring where I reduced the codebase for that part of the system by 65% and removed 3 supporting classes in complexity. So I have made the conscious decision to trash the "proper" architecture . I don't care how "correct" an architecture is if  it bloats my code by that much just to fulfill some sort of feigned righteousness. It would be more elegant and compact still, if I could get rid of the dummies too (hence my interest;) )

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