Undefined class constant 'GIVEUP_ALWAYS'

Undefined class constant 'GIVEUP_ALWAYS'

de Carroll Morgan -
Número de respuestas: 5

I now get this error when previewing a CodeRunner question that (I believe) was working a month or so (maybe two months) ago.

Any idea what might be causing it?

Thanks


En respuesta a Carroll Morgan

Re: Undefined class constant 'GIVEUP_ALWAYS'

de Tim Hunt -
Is it possible that you upgraded the question type plugin (qtype_coderunner) without also updating the question behaviour plugins that is also required (qbehaviour_adaptive_adapted_to_coderunner)?
En respuesta a Carroll Morgan

Re: Undefined class constant 'GIVEUP_ALWAYS'

de Tim Lock -
Also worthing nothing, we are seeing the reverse problem, qbehaviour_adaptive_adapted_to_coderunner updated to 1.41 but coderunner not updated 4.1.1.

Coderunner plugin needs a dependency against qbehaviour_adaptive_adapted_to_coderunner for the constants class usage to resolve this issue.
En respuesta a Tim Lock

Re: Undefined class constant 'GIVEUP_ALWAYS'

de Carroll Morgan -
Thank you Tim and Tim.

It took a day or so to look in to it because I am not the Moodle/CR hoster, and I had to contact those who were. And they in turn had to "escalate". But I think your suggestions were right on the money (I passed them on to the IT guys), and it is now fixed.

Thank you.
En respuesta a Tim Lock

Re: Undefined class constant 'GIVEUP_ALWAYS'

de Richard Lobb -
There is already a dependency from coderunner to the required version of qbehaviour_adaptive_adapted_to_coderunner. The problem appears to be in the opposite direction. I'm not sure if the Moodle plugin-manager handles a cyclic dependency in the version.php files of two inter-dependent plugins, although I would hope it does - Tim, can you confirm, please?
En respuesta a Richard Lobb

Re: Undefined class constant 'GIVEUP_ALWAYS'

de Tim Hunt -

Cyclic dependency is handled fine.

However, we have a choice: either declare the current cyclic dependency, or move stuff around so that the dependency can remain one-way - but I suspect it is naïve to think that would really be true, even if all the code references pointed one way.