shoneill

If I re-read your posts a few times I get the feeling you want to limit the types of messages a given actor can send and receive within the AF, is this correct?

I've posted the same question and I've been called mad for wanting something like that but for me it's the main reason why I do not use the AF.  I want to know at edit time if I'm trying to send an actor an incompatible message or not and the current AF does not allow for this because the message queues are too loosely defined.

In my experience you need to use a staggered inheritance to achieve what you want with the interface being re-defined at each inheritance level.  This means that all Boolean actory implement the boolean interface which accepts boolean messages.  If you try to send one of these to a Numeric actor, you get a broken wire.

Please see HERE and subsequently HERE for my take on this.

Shane

This will also only work if the methods thus defined are private scope.  Otherwise LV cannot concievably know which versiont o execute in a real VI due to the inheritance probability for any given object control or indicator.  This ambiguity is normally handled by DD but since you explicitly don't want that, the handling must be performed by limiting the usage of the VI to the class which defines it.

I also don't quite understand the sentence: "Also tried using classes, but then the same problem exists, just with a new abstraction layer added!"  Can you elaborate on this a little?

Shane.

PPS One thing I WOULD like is the ability to have static class methods with the same name but different connector panes.  That would be übercool.

I have an immediate aversion to this idea but I can't quite put my finger on the reason "Why".

I think the combination of non-DD and the "Must implement" will simply lead to massive code smell where programmers just implement the required VIs as empty husks and do the rest of the work in the rest of the child class.

Why not have custom data interfaces with a dynamically overwritten "Do" command.  This enables custom front-loading while avoiding the code smell of the "Must override" function essentially being useless becuase the code does not need to be called at all. 

Shane.

PS Or emberace OOP and just make your variable input an object isntead of a primitive.  Remember what AQ says : Everything should be an object.  Of course then the task of "showing" belongs in this class and not your notifier class.  Always tell an object what to do instead of asking it for details and doing it yourself.

Absolutely nothing about OOP requires a by reference design.

Even if 99.99% of OOP Implementations DO use references, it does not change the matter that the very nature of OOP does not demand either by value or by reference idioms.

Shane.

Sorry inline was a bad turn of phrase, what I meant was a subVI in the process rather than a parallel process. I'm not sure what target you are using but if you are pushing it that hard then I would think that the transport of the data and thread swap maybe a problem overhead as well but it would be interesting to know if not. That being said if the process can continue processing data while the main thread continues then this would seem a good way to go.

I would be interested to know how this goes, I'm always intrigued by oop on RT and primarily where it might break down.

Ok, now I get your "inline" comment. No problems.

The data sent between the main loop and the parallel loop is negligible. It's basically a simple status set and a subsequent status read (which I will do via a simply Queue read and write which shoukd be fast enough). I want to tell the parallel process to start and then in each loop of my main process check the status accordingly until it's finished. The parameters required for the parallel process can thus be completely separated from the main loop reducing complexity I think.

I'm trying to go a minimal "component" route.

Nothing's implemented yet, I'm just in the thought process.

Shane.

What are these VIs doing? Are they too slow because of the processing or because of the dynamic dispatch.

I am intrigued by a form of channeling pattern for processes so that you can have common code. Swapping the dd vi means changing the object type so I gues you need some form of fsctory method which loads the new object with the new VI. I would think about breaking down these processes in a more defined and/or fixed way though where possible. I highly doubt this will be faster than an inline VI (but will make the code parallel) and debugging is going to be a nightmare if the processes do have fixed responsibilities.

You can't inline a DD vi. Alone the overhead for calling a DD Vi is prohibitively expensive in our system. We're pushing a RT system to its limits.

The actual code WITHIN the DD Vi is quite fast but we can't afford to have the DD overhead each cycle, hence the handoff of parallel-process handlers.

The parallel processes (Different objects) would receive and respond to the exact same commands fromt he main loop, would use different criteris to evaluate the time to move to the next stage (for example). Therefore they should be transparently hot-swappable . If the actions were atomic, it would be no problem.

Shane.

Shane.

Paul,

that's pretty close to what I'm looking at but my question is about the details of replacement. I don't want the REceiver to change while the sender is waiting for a command to finish because this leads to some swkward situations.

I think I simply need to initially allow both to run in parallel and have some kind of "Get Receiver" at the start of any set of commands which must be executed on the SAME receiver and only when a receiver has no open listeners, can it be closed after receiving the "close" command. That way and pending commands will be finished before any real handoff takes palce. I essentially don't want the sender to know what type of receiver it's communicating with. I don't want it to have to know, I want plug-in receivers.

Shaen.

I'm considering a change to some of our code running on a RT and have a question.

I'm thinking of generating LVOOP-based "services" on the RT whose DD VIs are called in parallel to the main processing loop and communicate via queues or some other as yet undefined asynchronous mode. The reason for this is that the individual DD calls are WAY too slow for us to be calling in every iteration of our main loop.

So assuming I would have this up and running, I would of course like to investigate the option of changing the object for a given service "on the fly". How does one go about this? I would assume that the new object instantiates itself in parallel and then "takes over" the processing of the service requests. Of course the current state of the object to be replaced needs to be considered but my question is if there is an established method for doing this.

Does anyone have experience of such a process handover, or even know what this is typically called?

Shane.

My first attempt at distributing with a "master LVLIB wrapper" was a dismal (personal) failure. Performance fell through the floor. Trying to pull classes back out of the LVLIB caused massive project-wide corruption in several classes. I'm pretty sure this initial attempt was my own fault... which essentially consisted of selecting a few dozen classes and dragging them all into an LVLIB at once (don't try this at home, kids).

Been there, done that.

I almost totally wrecked a LVOOP project by trying to add then to lvlibs. A single mistake (I don't actually know WHAT the mistake was) led to all mixed-up relationships and a profusely cursing programmer.

I'm wary of lvlibs since.

Shane

Can you post some code so that we can see HOW you're doing it?

Shane.

Lots of Eastern Europe uses 12-XII-2012 or XII-12-2012, where the months are Roman numerals, which has the nice property of being language independent AND distinguishing the day from the month so order isn't ambiguous. I really like this one.

I'm from Europe (And have been to eastern europe) and I would have to say that I've never seen this formatting before. Can NI output this with standard formatters?

Shane

%H:%M:%S %d.%m.%Y

@cowen,

this I didn't know. I've certainly never passed a clone it's own reference.... Seems really counter-intuitive.

+1 for Bug.

Can you provide a reference? I’ve only seen mention of that problem when the two events are in different event queues in the same event structure, such as a statically-registered event and a dynamically-registered one.

I had the problem with an XControl which I was peppering with events to show that XControl value updates often lag behind the calling VI. Doing this I saw that when queuing up many events fast enough, the order became mixed up. I DO remember making a post about this on the NI site but for the life of me I can no longer find it. I have found a link of mine which points to nirvana, so maybe my post was removed for some reason...

Here's a post from someone else having the same problem essentially.

Shane.

How do I edit my posts?

The link I wanted to place int eh last post is not really related.

Please ignore me while I go insane.

Thank you.

Shane.

In rare cases the event queue can get muddled if the events are sent more quickly than the timestamp resolution can take care of. This leads to the events possibly being received IN THE WRO_NG ORDER. This is within the same event queue, and can be provoked even with the same event.

It has been reported and apparently the timestamp will include a more robust mechanism in future to avoid this....

In this regard, the queue vs events comparison gets a bit weird as the order in a Queue CANNOT be muddled (AFAIK).

Shane.

Ps I'm still a big event fan though.

By convention, the Event Registration Refnum is wired exclusively to one and only one Event Structure, and this wire is never branched -- the exact same convention as the "Register for Events" node. The difference? The User Event ref remains private to the containing Messenger class; no naked refs are exposed to be manipulated with User Event prims by callers.

Erm, Jack this is not technically correct.

Once an event fires, the naked event refnum IS exposed as part of the data within the event structure allowing foolish of malevolent programs to destroy the user event refnum.

I have an idea on the labview Idea exchange to remedy this but it has almost zero traction.

Shane.

From me. I find them a bit difficult. Just a bit.

I don't know why people are hacking around on the poor old unsigned integers. They're a positive lot and never have anything ngative to say about anyone.

if I change something in the private scope it ought to make a change in the public interface if my tests are "well designed".

Regarding this statement: I seem to realise that people are referring to changes in the behaviour of the object exposing the interface under test (Execution time etc.) and not the interface itself. These (for my definition at least) are not changes to the interface. Hence my comments on the original post.

It's a pedantic thing but for me changes to the interface (acceptable input range, fuinction definitions etc.) do not equal changes measurable via the interface. But hey, I have zero formal software training so my personal opinions are just that, personal opinions.

A statement like: mif I change something in the private scope it ought to make a change which is measurable over the public interfcace if my tests are "well designed". sounds completely different to me.

Shane.

Hey, if I'm wrong, I'm always willing to learn. The statement I referred to above just seemed not quite right, and I'm not sure at the moment of you guys agree with me or not.....

Well. There is white-box, grey-box and black-box testing.

Indeed. I find it weird to expect a private implementation change to be reflected in the public interface and still claim to be encapsulated. Seems a contradiction to me.

Saying that wou're going to test the private implementation (via whichever methods are most preferable for any given class) is something completely differen to saying "I'll test the private implementation via the public interface".

You hit on an important aspect, but it's not the only one. If testing should be concerned with the public interface and only the public interface-- no matter how low level, if I change something in the private scope it ought to make a change in the public interface if my tests are "well designed".

Only if your encapsulation is bad. I really don't know if I can agree with this statement at all. It seems very non-oop to me.

Shane.

The event structure. Events are handled in the owning vi.

Yeah, that's been int he LV help for years but to the best of my knowledge it's either simply wrong or hugely misleading. I work a lot with events and with subpanels and I've never encountered a problem. I hesitated for a long time because of this text in the LV help. I never understood what it meant.

Shane.

I think you forgot the something

WHAT? I'm certain I attached something.... D'oh

Here it is (maybe)

Random class.zip