[ww-devel] webwork-devel Digest, Vol 41, Issue 14

goehle at gmail.com goehle at gmail.com
Tue Aug 26 19:42:55 EDT 2014 

I'm getting the same errors as Jason on my jitar server.  The weird thing
is I was able to get it working on my wcu server.


On Tue, Aug 26, 2014 at 7:08 PM, <webwork-devel-request at webwork.maa.org>
wrote:

> Send webwork-devel mailing list submissions to
>         webwork-devel at webwork.maa.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://webwork.maa.org/mailman/listinfo/webwork-devel
> or, via email, send a message with subject or body 'help' to
>         webwork-devel-request at webwork.maa.org
>
> You can reach the person managing the list at
>         webwork-devel-owner at webwork.maa.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of webwork-devel digest..."
>
>
> Today's Topics:
>
>    1. Re: The library browser not updating problem (Jason Aubrey)
>    2. Re: Issuing warning messages in PG (Davor Cubranic)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 26 Aug 2014 14:49:02 -0700
> From: Jason Aubrey <aubreyja at gmail.com>
> To: WeBWorK development discussion <webwork-devel at webwork.maa.org>
> Subject: Re: [ww-devel] The library browser not updating problem
> Message-ID:
>         <
> CAGNtDpdnhmbJp-x6fyjo0d9pWkfBJXQr_q1UfHgRUdEY-fXCsA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Well, at this point I think the error has something to do with how my ssl
> is configured.  Here is some evidence from my apache log with LogLevel
> info:
>
> There were a lot of errors: 500 Can't connect to
> webwork.math.arizona.edu:443 at /opt/webwork/webwork2/lib/WebworkClient.pm
> line 158
>
> [Tue Aug 26 14:35:13 2014] [info] [client 127.0.0.1] SSL library error 1 in
> handshake (server webwork.math.arizona.edu:443)
> [Tue Aug 26 14:35:13 2014] [info] SSL Library Error: 336151576
> error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
> [Tue Aug 26 14:35:13 2014] [info] [client 127.0.0.1] Connection closed to
> child 0 with abortive shutdown (server webwork.math.arizona.edu:443)
>
> So, you can see (1) that 'it' can't connect to
> webwork.math.arizona.edu:443
> and (2) the ssl handshake seems to be dying due to an unknown certificate
> authority.  But if you looked at my server, you would see (3) that my
> certificate authority is in fact well known:
>
> > Issued By
> >
> Common Name (CN) InCommon Server CA
> >
> Organizaton (O) Internet2
> >
> etc...
> >
> Also, there is the fact that (4) my web browsers have no problem connecting
> to the https site.
> So,
> (a) Maybe the perl module(s) running the webservice calls (LWP?) don't
> recognize the certificate authority.
> (b) Maybe the way my redirect to ssl is set up is messing with the web
> service calls. (Permanent redirect to a *:443 vhost)
> (c) Maybe there is some other configuration problem with my ssl set up.
> (d) Maybe this is completely unrelated to the actual problem.
>
> Thanks for any ideas.
> Jason
>
>
> On Mon, Aug 25, 2014 at 7:21 PM, Matt Haught <matt_haught at ncsu.edu> wrote:
>
> > I had a similar problem recently. For me I was missing the
> > perl-LWP-Protocol-https package. In firebug or chrome developer tools
> > go to the net/network tab, open the library browser, pick a subject,
> > and look for a post from instructorXMLHandler. In the response tab I
> > had a nice error telling me what I was missing rather then json code.
> >
> > I also have to patch WebworkWebservice.pm so the library browser will
> > work with shibboleth auth.
> >
> > Matt Haught
> > North Carolina State University
> >
> >
> > On Mon, Aug 25, 2014 at 3:30 PM, Jason Aubrey <aubreyja at gmail.com>
> wrote:
> > > Hi All,
> > >
> > > A number of people have reported a problem where after an install of
> > ww2.9
> > > the library browser (2) doesn't update or display problems when the
> > subject
> > > is changed.  I'm having this problem on the ww3 branch too.  My web
> > console
> > > says
> > >
> > > SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the
> > JSON
> > > data
> > >
> > > Is there a known solution to this problem yet?
> > >
> > > Thanks,
> > > Jason
> > >
> > >
> > > _______________________________________________
> > > 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/c428e7ff/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 26 Aug 2014 16:08:01 -0700
> From: Davor Cubranic <cubranic at stat.ubc.ca>
> To: WeBWorK development discussion <webwork-devel at webwork.maa.org>
> Subject: Re: [ww-devel] Issuing warning messages in PG
> Message-ID: <6905C5C5-6ECF-4976-BE3D-CA38FB7746A5 at stat.ubc.ca>
> Content-Type: text/plain; charset="windows-1252"
>
> 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.html
> >
>
> ------------------------------
>
> _______________________________________________
> webwork-devel mailing list
> webwork-devel at webwork.maa.org
> http://webwork.maa.org/mailman/listinfo/webwork-devel
>
>
> End of webwork-devel Digest, Vol 41, Issue 14
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://webwork.maa.org/pipermail/webwork-devel/attachments/20140826/3be33129/attachment-0001.html>

More information about the webwork-devel mailing list