| Author |
|
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: April 25 2015 at 18:27 | IP Logged
|
|
|
Dave, two topics, nothing critical.
Topic 1:
Does it makes sense to have a ERROR TRIGGER. This would be a trigger, like all other triggers, but it would be set/called by an error. The use of this could be that I could have a macro that I call if I get an error. When triggered, I could capture the macro name, the line number (very important), and hopefully, a snapshot of all the temp variables before they get lost. So this Error-Macro would have all the temps from the previous macro available to dump/save/whatever. They would get dumped at the end of the Error-Macro. When you detect an error, you would still do all the things you do such as log it in the event log etc... but then do the trigger check. This could be very useful to debug a macro or a hard to find intermittent problem.
Topic 2:
In the future...
Would it be possible to have a form of, or a simple debugger?
The debugger could perhaps:
1. have breakpoints at a macro, breakpoints at a line within a macro. Or maybe just trigger the Error trigger.
2. single step a specific macro. With this capability, all the temp variables could be displayed, and we could watch them change. We could look at GV's and things like that.
This single step feature of the debugger doesn't have to be live, but could be external to the exec que. This would help new programmers (or me) to step through a macro and watch what happens. Similar to the multi-editor, but show (local) temp vars and have access to GV's.
Well, I can dream can't I?
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: April 26 2015 at 06:30 | IP Logged
|
|
|
gg,
The debugger is already on the to-do list but I'll see
if I can move it up in priority.
Concerning the error trigger...should be doable. What
kind of error would you expect this to fire on? There
is an execution queue error that I could do and of
course the critical error but are you getting other
errors that this should fire on? I would of course
have to recognize that the situation is an error.
Let me know about the errors and I'll get this added
to the to-do list.
Dave.
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: April 26 2015 at 11:41 | IP Logged
|
|
|
Thank you for your quick reply.
On the Error Trigger, I'd say that every error should set the trigger. That way, the programmer can decide what they desire to see/track/trace.
Since, I think, you blow off the remainder of the failing macro, this is all safely possible. This Error Trigger could call a user macro. Herein let's call it an Error Macro. Calling the Error Macro would blow off the remainder of the calling macro so you don't have a stack overflow issue.
When there's a formula error, you currently show the calculation on the bottom line of the editor, that could be available to show in the error macro maybe as a new system var called "LastErrorText". Maybe also have a new system var called "LastErrorType".
I'd offer to capture things like:
LastMacro
LastMacroLine
Parent Macro pending (on exec que)
LastTimedEvent
Date/Time of Error
LastErrorType
LastErrorText
LastInputString
LastSendString
Last controller input status
Last controller input string
Last controller output status
Last controller output string
(other I/O things)
[Local1-x]
System Vars...
Other things I don't know about......you can always add more stuff later.
As I read these forums, I see people (including me) with syntax errors, type or casting errors, I/O errors, jump errors, unexpected response errors and others. When these occur, it's usually difficult for the person to "see" what's happening. For myself, I dump what I can into a log file for debugging, but a lot of temp/local vars are gone by then, and I have to back track a var. With an Error Trigger, we can have one common macro to dump everything we want. You could even publish a "typical" Error Macro that dumps all this "stuff" to an error log file.
Some examples:
1. if (" "=0). Sometimes it's hard to see why that's a problem.
2. If the result of an acquired string isn't known, this could cause someone to chase this issue for days.
3. send...("[LOCAL1]"+"CHAR(27)") equates to "helloCHAR(27)" could become visible
4. if (left("LOCAL1]",2)="HELLO"
5. User-triggered. If someone just wants to see the machine at a particular program point. Usually when chasing I/O issues.
These are probably common issues someone would be interested in.
I'm guessing that most people don't have fault analysis skills as highly tuned as you have. With this help, us mortals could see both sides of the equation, or better yet, provide better and more detailed information when asking for your help. This might actually be more of a help for you!
The overall idea is to give a programmer more information about where and why there's an error and get a machine snapshot at the point of the error.
Remember "core dumps?" ok, never mind...
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 26 2015 at 22:19 | IP Logged
|
|
|
"core dumps?" sounds like Big Blue in the good ole days....
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: April 26 2015 at 22:24 | IP Logged
|
|
|
.. and you knew that!
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 27 2015 at 07:28 | IP Logged
|
|
|
GG, this is good stuff you bring up.
Basically we are looking at a transaction dump not a core dump. ¼ inch of paper vs 8 inches. Error trigger points, from a user’s perspective, would be a point in the logical flow. From the internals side of debugging is trying to pinpoint a Sysbase error caused by a definition or a syntax error. If PH knows there is a syntax error then I would think it would be relatively easy to isolate it to the cause. Grant it there are problems only Dave can test against but usually the frustrating ones are self-inflicted. Just my 2 ½ cents of useless rhetoric.
Ken, if you’re not pulling that big thing around you have done a lot in this arena your thoughts…..
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
MrGibbage
Super User
Joined: October 23 2006
Location: United States
Online Status: Offline
Posts: 513
|
| Posted: May 06 2015 at 20:38 | IP Logged
|
|
|
The error macro would have to be bullet-proof because if it too had an error, hoo boy! Infinite loop. Instead, I wonder if it would be safer if it was a PH
setting. Perhaps an email address to send the matter of the error. Or a text message phone number. Something that Dave can control so that he doesn't have to
worry about infinite loops and all.
__________________
Skip
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: May 06 2015 at 20:47 | IP Logged
|
|
|
Oops, I forgot about that one!
I suppose that's true.
Perhaps one solution would be for Dave, or PH, or the error macro itself, to disable the trigger and the macro would have to re-enable it when it's ready to handle the error condition again.
Very good point though!
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: January 25 2018 at 15:34 | IP Logged
|
|
|
I’m waking up this thread as it is the only place I
found close to what I am looking for. But then again
at
my age I might have missed it. I would like to be able
to Trigger from a Critical Message. In my case I know
the sequence that causes it and I would like to
Reinitialize from the Trigger automatically.
Did I miss something or is the only way by the visual
red screen? Dave, this goes way back to my continuing
fight with PLM errors. Your retries have helped a
little
but I am still fighting the problem by automating it.
Edited by BeachBum - January 26 2018 at 10:59
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
nick7920
Senior Member
Joined: March 04 2008
Location: United States
Online Status: Offline
Posts: 193
|
| Posted: January 25 2018 at 17:11 | IP Logged
|
|
|
BeachBum wrote:
I’m waking up this tread as it is the
only place I
found close to what I am looking for. But then again at
my age I might have missed it. I would like to be able
to Trigger from a Critical Message. In my case I know
the sequence that causes it and I would like to
Reinitialize from the Trigger automatically.
Did I miss something or is the only way by the visual
red screen? Dave, this goes way back to my continuing
fight with PLM errors. Your retries have helped a little
but I am still fighting the problem by automating it.
|
|
|
are you trying to do something/restart PLM on failure .
if so you can trigger a macro on PLM failure
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: January 25 2018 at 18:50 | IP Logged
|
|
|
Yep, you're close but the detection of the Critical
Error message is my problem. Where in Triggers or any
where else is there an alert to it? I have not found
an easy way to detect when it happens other than the
background of the PH screen goes red. As a result
there are 2 things one has to do. 1 is Reinitialize
and 2 fix and/or circumvent the cause.That is the easy
part, maybe. But one has to catch it first. As far as
triggering on a PLM failure, i'm not seeing a PLM
failure which would equate to Controller Trigger Type
and a Trigger ID of PLM. There is no log message that
corresponds to Critical Error that I can find.
My current thought is to catch it by capturing the
window using Window Spy and setting that in a Global
and going from there. Are we having fun yet?? Thanks
for the response...
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: January 27 2018 at 19:32 | IP Logged
|
|
|
Pete,
Been thinking about this and the best I can come up with would be to either scan the eventlog (critical errors go in the log) or like you suggest,
periodically scan for the Critical Error window. Both of these would need to be a periodic scan (timedevent) type thing. This is the best you can do
for now.
I have already added the code for a new "Critical Error" trigger in the codebase Im working on so this will be available with the next version. Still
working on adding other types of errors.
Dave.
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: January 27 2018 at 20:03 | IP Logged
|
|
|
Thanks Dave… In my case I can pretty well predict when
this will happen because I will get a negative return on
a ph_getinsteonlevelrt >= 0,"OK","PLM_ERR". This will
occur when you indicate you are trying 1 of 5
reconnects or whatever you are doing internally. I then
reinit and avoid the red screen of death….
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: An "ERROR TRIGGER" or Debugger.
