LabVIEW 2017 Dynamic Event Registration Behaviour

[ShaunR]

30 minutes ago, hooovahh said:

So you weren't implying this is a bug that everyone relies on, by quoting someone saying:

Well. Listen to this for a few minutes It is my sentiments entirely and I get just as annoyed and frustrated as he does with this sort of thing..

24 minutes ago, hooovahh said:

This isn't the same issue as your event example above.  In the DVR case you actually made a method for the next iteration to use the newly created reference.  In the event case there is no shift register or feedback node.  You register for something, but then the next iteration of the loop has the event structure getting that null refnum again.

I supplied a prototype (DVR ref constant) to the the initialising terminal to fix the datatype and then initialise the DVR (with Create DVR). From my perspective. This is the same as supplying an event refnum to the left hand dynamic terminal and then initialising (registering) the event which is passed to the right hand terminal. In this analogy. The feedback node is hidden under the hood which is why the new registration miraculously appears at the left terminal after re-registering.

I think it is just a better analogy than a queue which is also hidden.

Edited March 2, 2018 by ShaunR

[hooovahh]

1 minute ago, ShaunR said:

I supplied a prototype (DVR ref constant) to the the initialising terminal to fix the datatype and then initialise the DVR (with Create DVR).

Right but that isn't what is happening in the event example.  Yes you are providing a type, telling the event structure what type to expect, but this isn't happening on just the first iteration of the loop (like the DVR example).  You are providing a type, and providing what the event structure expects is a valid refnum that points to to the specific events it should react to.  And every iteration of this loop you are providing a null reference.  The DVR example works because the new reference is used, the event structure doesn't because that new reference is replaced with a null at the start of the next loop.

I agree that there is a type of feedback node internal to the event structure, being able to know what it registered for last time.  But by providing a new event to the outside of the event structure, it believes you are telling it to now use that event instead of the last one you told it to.

[ShaunR]

2 minutes ago, hooovahh said:

Right but that isn't what is happening in the event example.  Yes you are providing a type, telling the event structure what type to expect, but this isn't happening on just the first iteration of the loop (like the DVR example).  You are providing a type, and providing what the event structure expects is a valid refnum that points to to the specific events it should react to.  And every iteration of this loop you are providing a null reference.  The DVR example works because the new reference is used, the event structure doesn't because that new reference is replaced with a null at the start of the next loop.

I agree that there is a type of feedback node internal to the event structure, being able to know what it registered for last time.  But by providing a new event to the outside of the event structure, it believes you are telling it to now use that event instead of the last one you told it to.

Correct. The behaviour has changed. It used to work similarly as I described (and to the DVR analogy). Now it doesn't.

[hooovahh]

This is a DVR analogy that represents why the event structure example doesn't work:

This is more representative of what you are doing.  Yes it worked previously, but it shouldn't have.  If this VI worked in 2009, and doesn't in 2017 would you also claim it is a feature an not a bug?

EDIT: Also that video sounds interesting so far but is quite long, is there part you find the most relevant.

Double Edit: Seems I found it around 9 minutes in.

[ShaunR]

22 minutes ago, hooovahh said:

This is a DVR analogy that represents why the event structure example doesn't work:

This is more representative of what you are doing.  Yes it worked previously, but it shouldn't have.  If this VI worked in 2009, and doesn't in 2017 would you also claim it is a feature an not a bug?

EDIT: Also that video sounds interesting so far but is quite long, is there part you find the most relevant.

It is representative of what it is doing now, maybe, and not nearly as useful. Also yes. If it had worked like that for a decade and I had written code to leverage it, I wouldn't expect it to stop working one day. Notice too, how a shift register, like the event, would restore the behaviour?

Lets be clear here. It's not a difference between 2009 and 2017. It is 2017 differs from all versions back as far as [at least] 2009.

I thought I had set the time start. anyhoo.....

Start at about 8 mins through to about 12 mins.

Edited March 2, 2018 by ShaunR

[drjdpowell]

It's too bad they didn't "fix" it by allowing this (where I take Shaun's original code and just delete the constant):

Assuming an internal shift-register behavior in the Event Structure, then this "uninitialized shift register" behaves in a perfectly dataflow-like fashion, and it's even simpler to code.   Unfortunately, it's also broken, as the Event Structure wont adapt to the type input to the right-hand Dynamic Event Terminal.

[ShaunR]

8 minutes ago, drjdpowell said:

It's too bad they didn't "fix" it by allowing this (where I take Shaun's original code and just delete the constant):

Assuming an internal shift-register behavior in the Event Structure, then this "uninitialized shift register" behaves in a perfectly dataflow-like fashion, and it's even simpler to code.   Unfortunately, it's also broken, as the Event Structure wont adapt to the type input to the right-hand Dynamic Event Terminal.

Or they could have just left it alone ;)

[drjdpowell]

1 hour ago, ShaunR said:

For the purpose of the analogy, the feedback node is hidden.

I see your point there; a "read only on first call" input makes sense.   Unfortunately, it doesn't just read the input on first call, and there are use cases (though perhaps rare) where one might feed in different refnums on each iteration.   If you look at the example I posted, the input tunnel to the loop actually changes what it outputs, which breaks the dataflow rules.

I agree they should not have changed the behavior that has applied for so long (especially without telling people).

[ShaunR]

29 minutes ago, drjdpowell said:

I see your point there; a "read only on first call" input makes sense.   Unfortunately, it doesn't just read the input on first call, and there are use cases (though perhaps rare) where one might feed in different refnums on each iteration.   If you look at the example I posted, the input tunnel to the loop actually changes what it outputs, which breaks the dataflow rules.

I agree they should not have changed the behavior that has applied for so long (especially without telling people).

I'm not sure what "use cases" you are thinking of. But changing the event event reference null and voids all the cases using it. It is a design time, type, decision and can't be changed on the fly. The only thing one can do at run-time is listen for or stop listening for events. It seems, however, that if you really, really unlisten (Unregister For Events) then you are now stuffed.

Edited March 2, 2018 by ShaunR

[drjdpowell]

2 hours ago, ShaunR said:

It is a design time, type, decision and can't be changed on the fly.

To my understanding, the data type is fixed at design time but the Event Registrations are run-time dynamic.   I think Jack Dunaway's excellent examples on User Events showed this.

[ShaunR]

On 02/03/2018 at 8:28 PM, drjdpowell said:

To my understanding, the data type is fixed at design time but the Event Registrations are run-time dynamic.   I think Jack Dunaway's excellent examples on User Events showed this.

Ahh. You are talking about panel/control/user refnums contained within an event ref? Yes they are. That still works as expected <2017 - either before the structure or inside it. There was no bug here to prevent this use case.

evnt5.vi

[Antoine Chalons]

statement that starts at 10:00 is the key and it ends with "if it's a bug that people rely on, it's not a bug, it's a feature".

[ShaunR]

2 hours ago, Antoine Chalons said:

statement that starts at 10:00 is the key and it ends with "if it's a bug that people rely on, it's not a bug, it's a feature".

Yup. My fault. I've changed the quote and noted in the edit. It also makes hooovahhs objection moot; for which he can carry no blame since I subtly misquoted. The sentiment is unchanged.

It's well worth watching from ~8mins through to ~12. I agree 100% with him and it is the reason I pulled Linux support for my toolkits that aren't pure LabVIEW - even though they do work on that platform.

Edited March 4, 2018 by ShaunR

[ShaunR]

There is a bug fix listed for 2017 for the following.

596804—Re-registering a dynamic event can cause subscribing event frames to behave improperly

There are no details beyond that but I suspect the behavioural change is a side effect of fixing this-whatever it was

Edited March 4, 2018 by ShaunR

[shoneill]

On 02/03/2018 at 6:21 PM, ShaunR said:

I'm not sure what "use cases" you are thinking of. But changing the event event reference null and voids all the cases using it. It is a design time, type, decision and can't be changed on the fly. The only thing one can do at run-time is listen for or stop listening for events. It seems, however, that if you really, really unlisten (Unregister For Events) then you are now stuffed.

The bolded statement is rubbish, I'm sorry.

I have a use case.  In order to create a branching execution order in my event-driven code, I create entirely new registration refnums for a branch, swap out the event registration wires, execute the branch (which may itself branch....) before returning to the original queued up events.  It's a rare use case, but it does exist and is powerful. It also adheres to all of LabVIEW's semantic rules of how things should work.

I was reading the thread for a while and thought I was going to side with Shaun, but after looking at the code which he posted, I have to side with the others and say it's clearly (and I mean really clearly) an illegal buffer reuse compiler bug which has been fixed, and that's good.  The semantics of the code dictate that the Event Shaun wishes to fire should never be handled in this code.

The event registration refnum can be changed in every iteration of the Event structure.  That's dataflow.  The prototype of the Event Structure must remain constant but the actual event wueues handles within can be altered and substituted at will.  Swapping out the Event registration refnum and wiring up new references to the existing refnum (as mentioned elsewhere in the thread) are NOT the same thing.  Wiring up a new reference to an existing Registration refnum changes the event source for that event queue, but leaves all existing events in there.  Swapping out the event registration refnum actually changes the event queue.  Both of these should work and both of these adhere perfectly to dataflow.

Edited March 6, 2018 by shoneill

[ShaunR]

2 hours ago, shoneill said:

The prototype of the Event Structure must remain constant

and what happens if you change this "prototype" refnum?

On 3/2/2018 at 5:21 PM, ShaunR said:

null and voids all the cases using it.

Maybe?

Everything else is guessing but you should post some code to show your use case like everyone else has.

[shoneill]

The usage of the word "Prototype" was careless.  Use "Datatype" instead.

If you mean changing the data carried on the strictly-typed wire attached to the left-hand side of the event structure, then the job queue for the event structure changes to whetever is contained there.  As expected really.  Jack Dunaway has an example of it in a link previously provided (not by me) in this thread (snippet provided below).

If you mean changing the TYPE of the wire, that's a silly question since that can't be done.  Doing that requires a recompile of the VI.

 

[ShaunR]

1 hour ago, shoneill said:

that's a silly question since that can't be done

It can be done but it:

On 02/03/2018 at 5:21 PM, ShaunR said:

null and voids all the cases using it.

because:

On 02/03/2018 at 5:21 PM, ShaunR said:

It is a design time, type, decision and can't be changed on the fly.

1 hour ago, shoneill said:

Doing that requires a recompile of the VI.

Indeed it does.

Edited March 6, 2018 by ShaunR

[shoneill]

And this relates to your original code....... how?  You are NOT changing the datatype of your registration refnum, you are changing the data on the wire (which is the first of the two cases I mentioned in my previous post) and for which I posted a trivial example.

[ShaunR]

11 minutes ago, shoneill said:

And this relates to your original code....... how?  You are NOT changing the datatype of your registration refnum, you are changing the data on the wire (which is the first of the two cases I mentioned in my previous post) and for which I posted a trivial example.

It relates to drjdpowells comment:

On 02/03/2018 at 5:08 PM, drjdpowell said:

I see your point there; a "read only on first call" input makes sense.   Unfortunately, it doesn't just read the input on first call, and there are use cases (though perhaps rare) where one might feed in different refnums on each iteration.   If you look at the example I posted, the input tunnel to the loop actually changes what it outputs, which breaks the dataflow rules.

Which I later went on to say:

On 03/03/2018 at 10:34 PM, ShaunR said:

Ahh. You are talking about panel/control/user refnums contained within an event ref? Yes they are. That still works as expected <2017 - either before the structure or inside it. There was no bug here to prevent this use case.

There was confusion between "refnums". I took it to mean the event "prototype" refnum (since that was my first example use case) and he was talking about contained renums. What I said was not "rubbish", though.

Edited March 6, 2018 by ShaunR

[shoneill]

The code I posted illustrates why a "read only on first call" cannot work.

If what you said is not rubbish, then more clarification is needed because by my understanding it is.  You can change the protoype refnum for another of the same type no problem.  You can bait and switch to your heart's content.  Hence my insistance on differentiating between the data contained within the Refnum and the Type fo the refnum.  One is possible to switch (without invalidating anything), the other isn't.  Of course you can't change it for a refnum of a DIFFERENT type, that's a design time decision.

The code I posted swaps out the refnum for another, but of the same datatype and therefore there's no invalidation at all.

[ShaunR]

8 hours ago, shoneill said:

The code I posted illustrates why a "read only on first call" cannot work.

I don't think it is a "read only on first call" and I never said as such. I intuited that it may be as described in the DVR example and was "a feedback node/shift register that was "initialised on first call". That was my observation of its behaviour and I wrote code around that. It obviously does work because your example taken from jacks stuff was written way before 2017 (2015, in fact) and before the change in behaviour and my examples show that it also works as expected when registering and re-registering in pre 2017 versions.

I think you have just miss-interpreted what I said and then proceeded to jump up and down about the semantic meanings. I have been very clear, with examples, of what the issue is; what the change has been, and we have all discussed various work-arounds and alternatives. I may be a lone voice in thinking that it is unacceptable to change a behaviour that worked fine (as far as I could tell) for a decade but then I have to rewrite code, so it's understandable.

[shoneill]

• I never claimed you said that.  But it was said.  The code I posted illustrates why the proposed operation is incorrect. Jack's code only serves to illustrate why your intuiting which led to your original code was flawed.
• I don't think I've misinterpreted anything. I understand the original code, the changes and the workarounds. The workaround is to better understand the issue and code appropriately.
• Regarding not wanting code to change and the plea to Linus' authority: Taken at face value, Linus' comment would preclude the closing of any security flaw which has ever been exploited. Yes, obviously Linus is claiming that Spectre and such should be maintained indefinitely as some may be using it. 

[ShaunR]

4 hours ago, shoneill said:

I never claimed you said that.  But it was said.

Perhaps you should direct your comments to them instead.

4 hours ago, shoneill said:

I don't think I've misinterpreted anything. I understand the original code, the changes and the workarounds. The workaround is to better understand the issue and code appropriately.

I also never said you misrepresented anything. I  said you misinterpreted what I said.

4 hours ago, shoneill said:

Regarding not wanting code to change and the plea to Linus' authority: Taken at face value, Linus' comment would preclude the closing of any security flaw which has ever been exploited. Yes, obviously Linus is claiming that Spectre and such should be maintained indefinitely as some may be using it.

It's not a plea to authority. It is just a better oration of my own view with a preceding explanation as to the reasoning so that I don't have to write pages and pages. Your straw man argument doesn't help your case in this context.

There is little point in continuing this branch of the conversation as it has just become me defending against unfounded accusations and that doesn't impart any useful information about the issue to anyone.

If you have more technical input, then by all means please do.

Edited March 7, 2018 by ShaunR

[shoneill]

All of my input has been technical. The information you seek is all in this thread if you care to find it.

23 minutes ago, ShaunR said:

I also never said you misrepresented anything. I  said you misinterpreted what I said.

I also never used the word "misrepresent", so I'm unaware what you're referring to here. Is this supposed to be a joke regarding misinterpreting my misinterpret?

24 minutes ago, ShaunR said:

It's not a plea to authority. It is just a better oration of my own view with a preceding explanation as to the reasoning so that I don't have to write pages and pages. Your straw man argument doesn't help your case in this context.

I disagree re. the plea to authority.  Plus, I'm fully aware of the ridculousness of the logical extension of what Linus said when context is ignored. Note the smiley.

26 minutes ago, ShaunR said:

There is little point in continuing this branch of the conversation as it has just become me defending against unfounded accusations and that doesn't impart any useful information about the issue to anyone.

If you have more technical input, then by all means please do.

Well, for yourself perhaps but others read these threads also so even if you stoicly refuse to listen to any relevant technical details (or god forbid, other opinions), others may be able to incorporate the technical details of the discussion to help form their own opinions.