Zugg Software :: View topic - [325B] #MXP commands within a trigger scope are effective NO-OPS (Resolution?)

Posted: Fri Sep 10, 2010 12:15 am

I am making a separate post for this problem, trying to pin down what is wrong is the reason I found the bug which I posted here.
The reason I ran that test was to attempt to find why #MXP commands were not affecting the window when they were executed within a trigger scope. I discovered that for no apparent reason #MXP statements executed in the body of a trigger or within aliases that are invoked within a #TRIGGER scope have no effect on the window. However, if you run the same aliases from the command line or invoke them from another alias which is not invoked from within a #TRIGGER scope, the windows will be updated correctly. There is no failure from running in a #TRIGGER scope if done from an untitled session (as the test in the related post shows), only in a live session this problem arises. If, for instance, one moves the given test to a live session, the window will not update and the strange behavior will not appear. What's more, this affects all scripts that write using #MXP (scripts that have been executing for many beta versions). This behavior only appeared when I started using #MXP from within GMCP triggers. That there is a relationship, this is apparent, that the relationship is linear, it is not, since the problem also arises when the scope is that of a "normal" trigger. Running the scripts in 3.23a, with the package which was current at the time, works. Running 3.23a with the package in the 3.24 or 3.25 state, fails. The failure is also applicable to 3.24
EDIT: This is a an uneducated guess, to be sure, but I suspect that the #MXP commands are writing to a "phantom" widow. This would certainly explain the behavior since that is what happens when CMUD can't find a variable, even though it exists in some class, so then creates it in the root. The script accessing the variable will experience a similar behavior as described above until the "extra" variable is removed from the package. Until the "root" variable is removed the script will appear to fail, though the "extra" variable is being updated "correctly". The script failure is caused by incorrect scoping. So might also be why the above problem occurs.
EDIT: When I said "run the posted test" in a live session, I really meant "run the test on an existing auxiliary window" in a live session.

Posted: Fri Sep 10, 2010 4:21 pm

I'm really not sure what you are talking about here. There isn't any "phantom" window. #MXP commands are parsed by the window that causes the trigger to fire. #MXP is essentially a #SHOW command with the MXP ESC[1z pre-pended to the text.

I answered the bug report in the other post and it was related to using the DEST MXP command. Other MXP tags do not exhibit that behavior. But using DEST was completely corrupting the line buffers in the window and could cause all sorts of weird behavior.

If you have an example of a different problem with an MXP command that doesn't use DEST, then please post the details.

Posted: Sat Sep 11, 2010 2:25 am

The "phantom window" thing was a suggestion based on how cmud is bound to duplicate things it can't find but exist. I was trying to create a model that explained the problem, I was not claiming that that was the problem. As to the problem being related to GMCP, I specifically said that there wasn't a linear relationship, and there may be no relationship at all. However, I encountered the problem when I tried to write the data gathered when the GMCP triggers fired so I thought that might be a cause, but since triggers that are not related to GMCP also fail then if there is a relationship to GMCP, it cannot be a direct one. At any rate, this was also a suggestion, not a claim.
All that being said, the problem is real. I cannot get #MXP to write to the windows if the commands are in a trigger scope. I am not claiming that #MXP does't work, because it does. I can invoke any alias that uses it from the command line and it will work just fine. It is when the aliases are invoked from a trigger that nothing happens. Some of these triggers have been around since day one and have worked since day one. Now they don't work, or rather, now nothing gets written to the windows. In fact, the windows don't even become visible. So yes, as far as my scripts go, #MXP within a trigger scope is a NO-OP. Turning #MXP debugging shows that nothign happens, that is, no debugging information is generated. However if the alias runs from the command line, there is debugging information. So the question is: Where are these commands going?
If I had the code in front of my I could point out possible reasons for the problem. Since I don't, I can only speculate. As I pointed out, tests in an untitled session work fine. The same tests in a live session don't. I've gone as far as creating a new package to eliminate the possibility of corruption. The result was the same.

Posted: Sat Sep 11, 2010 3:17 am

You'll need to give me a specific example of something that isn't working. I'm not seeing any problems with any of my MXP or triggers here.

Example that works fine:

Posted: Sat Sep 11, 2010 4:44 am

This is the a complete GMCP trigger:

Posted: Sat Sep 11, 2010 4:50 pm

The problem is that you are doing this within a GMCP trigger. Like Telnet triggers, GMCP triggers run at a very low level in the network socket processing routines. #MXP parsing it done at a higher level. So #MXP is not available within GMCP or Telnet trigger types.

In general, anything in a GMCP or Telnet trigger should be very small and fast. Remember that CMUD is waiting for this trigger to complete before finishing processing the incoming socket data. So it would be really easy to add a lot of lag to your session with a trigger like this.

My recommendation is that you simply set the variables chardb.* within the GMCP trigger and then have a separate Alarm trigger that runs every few seconds and updates the MXP DEST window with the results. You can set an additional variable in the GMCP trigger to tell the Alarm that the Char window needs to be updated.

If you absolutely must update the window from within the GMCP trigger, then the only other way is to use the #WINDOW command to send data to the Char window and to position the cursor you can send the appropriate VT100 escape codes.

Posted: Sun Sep 12, 2010 3:51 am

I understand your explanation and it makes sense. Two things still puzzle me: A) It worked in 3.23a and B) When I disable all MXP writes to the window (actually, delete the window, disable the scripts and re-start CMUD) all writes to MXP windows which are not within a GMCP trigger scope, work properly as they did before this problem arose. So, somehow it seems that once any MXP parsing is attempted (as you explained), all MXP DEST calls are disabled whether they originate from the low-level trigger scope or not. This applies also to MXP FRAME calls.

Posted: Mon Sep 13, 2010 2:09 am

OK, I've solved the problem. I have the answers to the two puzzles. Though I am not sure there isn't a bug.
The reason it works in 3.23a and not in 3.24+ is because I actually changed the code. In 3.23a I was triggering of char* only. One trigger to process the entire thing. While in 3.24+ I used a trigger for each sub-package. Evidently, the firing overlap is what is causing the problem. I went back to a single-trigger environment and both A and B above are gone. Problem B falls into the category of collateral damage. Now, whether this is a bug or not, is not for me to say. If one uses triggers for the sub-packages, MXP fails to deliver, if one uses one trigger for the entire package, everything works fine.

Posted: Mon Sep 13, 2010 4:40 am

OK, it stopped working again. I guess it's one shot deal. Just as before, it works this session, next session it doesn't. I guess I just have to write a windows app to do the job.

Posted: Mon Sep 13, 2010 6:11 pm

Posted: Tue Sep 14, 2010 12:58 am

I did follow and implement your rules and they work just fine. Still, there is a problem with my original post. Ignoring the fact that my original scripts worked in 3.23a and don't work in 3.24+, let's look at what else is happening. If I use my original scripts which, for reasons you stated, fail to have MXP DEST work, all other MXP DEST tags within any other trigger will also fail, even though those triggers are non-GMCP. So whatever is happening to MXP when invoked from a GMCP trigger spreads through the entire client. If I use your way of doing things, non-GMCP triggers invoke MXP successfully, if I use my former method, non-GMCP triggers experience the same problem as GMCP triggers when using MXP DEST.
Here is what is more bizarre:
Let's say that I run the scripts as you indicated above. Everything works. Now I disable those scripts and the GMCP char* trigger and re-instate my old methodology, that is, I restore the GMCP triggers that invoke MXP DEST directly. They will work. So, the problem is deeper than a failure to parse because MXP DEST is being invoked from a low-level trigger. If this were the only problem, re-instating the old scripts after running the new scripts would still suffer the same failure. Now, if I close the session with the old scripts installed and then re-start it, the old scripts won't work (but they were operational in the previous session). See my point? There has to be something going on beside the low-level invocation. The old scripts should never work, but they do if they are not used when the first writes to the window are done. Of course, once MXP DEST fails, it fails for all triggers. In fact, it's more than MXP DEST, MXP FRAME also fails, because non-GMCP triggers that attempt to open a window using FRAME, fail to do so (when the old scripts are operational).

Posted: Tue Sep 14, 2010 4:17 pm

You'll need to show me a specific non-GMCP trigger that is having this problem. For example, I just tried this and it worked fine: