[ww-devel] Issuing warning messages in PG

Tue Aug 26 19:08:01 EDT 2014

Thanks for the pointer, I had not known about Value::traceback. This is just what I’d hoped for.

I can confirm that ‘Value::traceback' still works as you described. Although, it would be nice if in list context it returned a list, rather than concatenating everything into one giant string. But at least I can use string manipulation to reverse this and chop up the trace into individual calls, then output what I want.

Davor

On Aug 26, 2014, at 2:36 PM, Davide P. Cervone <dpvc at union.edu> wrote:

> You can try
> 
>     WARN_MESSAGE(Value::traceback());
> 
> which should give you the calling history for the function.  The top two frames are removed -- one will be the Value::traceback() call itself, and one the routine that called it, so that should get you the traceback for the function that called your utility.  If you want more or fewer frames, you can pass a number to Value::traceback() that will tell how many frames to drop.  The default is 2.  So 
> 
> 	WARN_MESSAGE(Value::traceback(0));
> 
> should get you the complete traceback, including Value::traceback itself.
> 
> See if that helps.  I haven't used it in a while, and hope it still works!
> 
> Davide
> 
> 
> On Aug 26, 2014, at 5:14 PM, Davor Cubranic wrote:
> 
>> Having just tried using both in a custom macro, I have a case where it was more useful to use the undecorated version. The main reason was because the ‘caller’ information output by ‘WARN_MESSAGE’ wasn’t very useful because the direct caller was always the same utility function. This function could be called from multiple user-facing functions, which is what I had really wanted to include in the output. (Unfortunately, access to `caller()` is restricted.)
>> 
>> So this is a bit like the difference between ‘carp’ and ‘die’. Sometimes it decorated output is useful, other times not, so I hope this ability stays around. More generally, it would be really nice to get the line in the PG problem that caused the warning, not in the internals of the macros used. 
>> 
>> Davor
>> 
>> On Aug 26, 2014, at 12:45 PM, Gage, Michael <michael.gage at rochester.edu> wrote:
>> 
>>> Hi Davor,
>>> 
>>>  Thanks much.  I won’t change the behavior at the moment. I think (or at least thought at the time) that it was 
>>> appropriate for the PG version to have more decorations, compatible with its specific use in problems.  I am wondering about changing  
>>> the name of the PG method for consistency but I think I’ll leave it alone for the moment.  Perhaps later.
>>> 
>>> Take care,
>>> 
>>> Mike
>>> 
>>> On Aug 26, 2014, at 3:32 PM, Davor Cubranic <cubranic at stat.ubc.ca> wrote:
>>> 
>>>> Thanks for the clarification Mike. I fixed the call to the old name in ‘custom_problem_grader’ and the POD in PGcore.pm. The pull request is at pg/pull/155.
>>>> 
>>>> I’ll let you decide whether to make WARN_MESSAGE and PG->warning_message behave exactly the same.
>>>> 
>>>> Davor
>>>> 
>>>> On Aug 26, 2014, at 12:22 PM, Gage, Michael <michael.gage at rochester.edu> wrote:
>>>> 
>>>>> Hi Davor,
>>>>> 
>>>>> Perhaps I should change the $PG->warning_message for consistency. 
>>>>> I changed the PG macro message to WARN_MESSAGE early on to make it more consistent with “warn”.  when it was warning_message I kept 
>>>>> mistyping it.
>>>>> 
>>>>> the reference in custom_problem_grader is a bug and should be fixed. I’ll submit it to bugzilla
>>>>> along with a reference to the misleading comments in PGcore.pm
>>>>> 
>>>>> In any PG problem you should use WARN_MESSAGE.  In the macro files you may have to 
>>>>> use main::WARN_MESSAGE  particularly if you have declared a package name in the file.
>>>>> 
>>>>> In the .pm files you will not have easy access to WARN_MESSAGE but in most cases (when PGcore is a parent) you
>>>>> will have access to the method in PGcore. 
>>>>> 
>>>>> Both DEBUG_MESSAGE  and WARN_MESSAGE() are constructed by PG and are meant to allow a bit more 
>>>>> control over the error message.  It also allows the possibility of handling these messages differently when the problem is 
>>>>> rendered in a webservice or in a library than when it is rendered in a problem.
>>>>> 
>>>>> “warn” is a perl command.  It is still sometimes needed when DEBUG_MESSAGE doesn’t work, e.g. if there is a syntax error than 
>>>>> perl simply closes down and the messages in the DEBUG_MESSAGE pipeline are never delivered.
>>>>> 
>>>>> Take care,
>>>>> 
>>>>> Mike
>>>>> 
>>>>> 
>>>>> On Aug 26, 2014, at 2:27 PM, Davor Cubranic <cubranic at stat.ubc.ca> wrote:
>>>>> 
>>>>>> The current code and documentation seem to be a bit out of date about issuing warnings. For instance, in ‘lib/PGcore.pm’, there is the following POD:
>>>>>> 
>>>>>> There are three message channels
>>>>>> $PG->debug_message()   or in PG:  DEBUG_MESSAGE() 
>>>>>> $PG->warning_message() or in PG:  WARNING_MESSAGE()
>>>>>> They behave the same way, it is simply convention as to how they are used.
>>>>>> 
>>>>>> But there is no macro WARNING_MESSAGE anywhere. There is, however, WARN_MESSAGE in ‘macros/PG.pl’. This one is not quite the same as just calling ‘$PG->warning_message()’, because it decorates the message with caller info and frames it with a line border.
>>>>>> 
>>>>>> ‘lib/PGcore.pm’ also used to contain function “WARN”, but it was commented out in commit 92127e6 (in 2010). It is still used by the “custom_problem_grader_fluid” macro in ‘macro/PGgraders.pl’.
>>>>>> 
>>>>>> Question: what is the right thing to do? I’m seeing PG macros using mostly “WARN_MESSAGE”, with a few “warn” thrown in. Nobody calls $PG->warning_message directly.
>>>>>> 
>>>>>> Davor
>>>>>> _______________________________________________
>>>>>> webwork-devel mailing list
>>>>>> webwork-devel at webwork.maa.org
>>>>>> https://urldefense.proofpoint.com/v1/url?u=http://webwork.maa.org/mailman/listinfo/webwork-devel&k=p4Ly7qpEBiYPBVenR9G2iQ%3D%3D%0A&r=enN3K%2BCUdz1bRKB01s3PUtIX0B0zjgWTYpo9pUAD9Ek%3D%0A&m=7xgj59c0UBM%2Bn%2FrwDGvWKZ1lz91orFG8G5RBKvtwerY%3D%0A&s=3a217f3a0041f9f60ff1b516878fd92a1b504eac049c756d511223567ed1ccac
>>>>> 
>>>>> _______________________________________________
>>>>> webwork-devel mailing list
>>>>> webwork-devel at webwork.maa.org
>>>>> http://webwork.maa.org/mailman/listinfo/webwork-devel
>>>> 
>>>> _______________________________________________
>>>> webwork-devel mailing list
>>>> webwork-devel at webwork.maa.org
>>>> https://urldefense.proofpoint.com/v1/url?u=http://webwork.maa.org/mailman/listinfo/webwork-devel&k=p4Ly7qpEBiYPBVenR9G2iQ%3D%3D%0A&r=enN3K%2BCUdz1bRKB01s3PUtIX0B0zjgWTYpo9pUAD9Ek%3D%0A&m=Gqk0M99dCnNJIiPiMU19GBUvQy7ax0XJJOSUw%2B8rtSI%3D%0A&s=d577b794547fe6e85788111df90580af175a192f147a1a07cf06e55440bc96be
>>> 
>>> _______________________________________________
>>> webwork-devel mailing list
>>> webwork-devel at webwork.maa.org
>>> http://webwork.maa.org/mailman/listinfo/webwork-devel
>> 
>> _______________________________________________
>> webwork-devel mailing list
>> webwork-devel at webwork.maa.org
>> http://webwork.maa.org/mailman/listinfo/webwork-devel
> 
> _______________________________________________
> webwork-devel mailing list
> webwork-devel at webwork.maa.org
> http://webwork.maa.org/mailman/listinfo/webwork-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://webwork.maa.org/pipermail/webwork-devel/attachments/20140826/2d6669f7/attachment-0001.html>