Moodle

Tim
If you agree I can take charge (with Joseph collaboration) of this as I have alreay done some work on regexp code to see how it can be included in Cloze question.
So we can develop the two options as a specific question type and enclosed in multianswer..
Although Joseph has a 1.9 version, I think that this should be put in 2.0 with all the necessary changes.
There are some issues where will will need your expertise...

"<p>The only check done by the programme for the validity of your regular expressions consists in checking that opened parentheses and square brackets are correctly closed. If your parentheses and square brackets are not correctly closed, a warning message will be displayed showing the number of each. You should immediately edit the faulty question. </p>
<p> However this does not totally protect you from other errors. If you made an error in one of your regular expressions, either of the following can happen: a) a PHP error notice or warning will be displayed, something like [<em><strong>Fatal error</strong>: Maximum execution time of 30 seconds exceeded etc.</em> ] or b) no error will be displayed but you will see by yourself that the alternative answers generated from your faulty regexp are in fact not acceptable. You should of course immediately edit the problem question, trying to find and correct the faulty regular expression.</p>"

It would be nice if my REGEXP question type would at long last be considered for inclusion in Moodle core in version 2.0.

At the moment there are very few changes needed to make the 1.9 version (in contrib) compatible with 2.0 and I will look into the matter shortly and report in this tracker issue.

As for inclusion in CLOZE, again it's a matter of a few lines to be changed in the code. Pierre, can you look at my modified question/type/multianswer/questiontype.php for moodle 1.9 on http://moodle.org/mod/data/view.php?d=13&rid=338 and see how it could be adapted to 2.0 ? Thanks!

As for the warning message quoted by Pierre, this is no big deal. There must be a warning in case a question creator makes an error in the regular expression (easily done, given the complexitity of such expressions). But the most important thing to tell teachers using the REGEXP question type is to always preview and test each question before putting it into a quiz. Displaying all the details and testing the question in the Question Preview window is really the only way to make sure that the question will work (well, almost).

Of course if Tim can think of a better checking mechanism for the regular expression syntax (better than simply checking for even numbers of parenthesis and square brackets), then it would be fine.

Joseph

So I will divide the tasks as something like
1. convert to regexp.php 2.0 (i.e. dB calls)
2. add regexp to cloze
3. add a better REGEXP analyzer in the edit_regexp_form.Perhaps PHP5 try and catch can be usefull.
4.integrate the lang and help as a core question i.e. in the lang/en_utf8 directory so that is can be translated as usual core code.
...

Pierre,
In fact, at the moment I am pretty busy with the beginning of the academic year and new tasks I have undertaken (other than Moodle). I would be grateful if you would work on tasks #1 and #2 to start with, based on existing 1.9 REGExp question type (and cloze modifications).
If you can do this and commit to CVS and keep us (Tim and I) informed, then I would test the changes in 2.0.
Then we can proceed to tasks #3 (Tim?) and #4 (I would probably need to revise the Help files).
Joseph

I agree to take charge within our common delays related to "the beginning of academic year".

5. we should add a regexp testing interface
either in the edit question interface
or as a pop-up window
or at least add links to regexp tester browser plug-ins in the help.

As I am planning to add a cloze generator interface to multianswer, the pop-up could be a better solution.

Creating good regexp expression is not easy and as we add regexp to core, mots users will need to test their regexp expressions used to filter the answers .
So I propose to add to each answer (not the first one) a regexp expression test probably using the advanced feature (not shown here) to control the display.
So the user could put all the responses he need to test his regexp expression.

On Friday, I was discussing my TODO list with Martin, hence the fact I created this bug. Since I am using the tracker to track my todo list, can we leave this one assigned to me please.

However, while this is on my TODO list, it is quite a long way down. There are other things to do first, so I won't be doing any work here for a couple of months, so the fact that you are busy with start of academic year things right now is not an issue.

And while I would like this issue to stay assigned to me. It is great that the two of you are keen to help with this, and I think you are correct in identifying the things that need to be done. Can I suggest that you create sub-tasks of this issue for the various things, and you can assign the sub-tasks to yourself, or assign them to me as appropriate. For now, shall we continue to build a 2.0 version of the regexp question type in contrib. When the time comes to move it into core, I will try to find a way of doing it that preserves CVS history. Thanks.

Tim
Sorry for the confusion, it was just to relieve you of this issue knowing (at least in part ...) your long TODO list.
Your solution is OK.
"For now, shall we continue to build a 2.0 version of the regexp question type in contrib. "
should be read as
"For now, we shall continue to build a 2.0 version of the regexp question type in contrib. " if I understand correctly.
However this means that the sub-tasks will be put in the Moodle tracker as MDL- although the CVS will be done on the CONTRIB.
Is this OK for you ?

Yes, code in contrib and MDL-... bugs is good. When we move it to core, we can move the code in the CVS repository so that all the history is preserved, at which point it will look as if everything was done in core in the first place.

1. convert to regexp.php 2.0 (i.e. dB calls)
2. add regexp to cloze
3. add a better REGEXP analyzer in the edit_regexp_form.Perhaps PHP5 try and catch can be usefull.
4.integrate the lang and help as a core question i.e. in the lang/en_utf8 directory so that is can be translated as usual core code.
So I will work on 1,2 and explore the interface for edit_regexp_form.php.
When something is ready I will notice here.
The project will be develop on http://132.208.141.198/moodle_head_exp user:moodle pw:moodle.
Joseph , having write access to your contrib will facilitate the process.

Pierre,

1- Thanks for your proposal. I am actually too busy right now to work on this, but will follow your developments and test them.

2- One important feature that should be added to the edit form: the possibility to move answers, insert, etc. as per my post here: http://moodle.org/mod/forum/discuss.php?d=65066 and MDL-8556.
When writing REGEXP questions, especially when editing and re-editing them for better answer analysis results, I quite often have to re-order my answers or insert new answers, so this feature is indispensable.

3- I quite agree for you to have access to REGEXP in contrib; you should ask for the proper access rights from Martin D.. I suppose you would only commit changes to HEAD (2.0), not to inferior versions (1.8-1.9), where I might sometimes commit minor changes.

All the best,
Joseph

Here a first version of questiontype.php 2.0
1 all DB call are 2.0 using $DB
2 all the code of expandregex.php has been included as internal functions of regexp_questiontype so that they could not interfere with other moodle functions.

Hi, everyone there!

Volgorad State Technical University actively used regular expression questions in our courses. Hovewer, out of frustration from work with regexp questiontype (and it's author) we developed our own preg questiontype, based on shortanswer and preg_match() function, which has been in use in several real academical courses from February 2008. I'm a sort of considering it not polished enought to offer to community before a year of a real use (new module isn't a small patch), but just when we were quite happy to convert all our questions to preg and get rid of regexp for good, I'm found that regex is on shedule to inclusion in the core. So I must at least try to give you another option right now.

First of all I must state the difference between our preg questiontype and regexp:

1. Preg question type have NOT nice functionality to show the students the right first part of the answer (it can have it in future, but it will be based on native regular expression matching algorithms). So it also have NOT many pesky bugs related to it:
a. script doesn't failed thanks to a invalid regexp (regexp validation is absent right now, but can be added if necessary)
b. it support full preg syntax (including * and +) - we weren't too happy on downgrading syntax of regex with the necessity of manual editing of several hundreds of questions
c. it doesn't hang on complicated expressions (year before when we were using Joseph's regex it is used to hang when the number of possible different matches exceed approx. 1000, and this is only a 10 indepedent pairs of alternatives)
2. Preg questions uses answers ONLY to enter regular expression, there is NO strange first answer that must not be regular expression to display the correct answer for user (it's not so harmless as some strings doesn't compare with itself as a regular expressions) - we use a special field in the header of the form to enter correct answer in user-friendly form (there are also some plans to generate it based on regexp)
3. The changes to shortanswer question are minimal, so it actually can be supplied as a patch to it (adding an option 'Use regular expression matching' yes/no with no as default) - which will reduce the code duplication and the number of questiontypes to support. The changes also is very simple, so new questiontype was sufficiently stable from the beginning.

The preg also lacking Embedded answers integration (since after several bugs we tend to avoid using embedded answers where possible), but this can be done if necessary.

If you interested in this offer, I can send you preg questiontype for reviewing; and add any needed functionality (except complex partial matching - pity it is absent in preg_match as underlining PCRE library support it, and rendering this algorithm on php will significantly reduce the speed of matching - maybe we even must unite and vote for such option in php (there is even a patch to php to do this since 2005, but it isn't applied)). I can also create a patch to shortanswer question to support regular expressions (which is the best solution I can think).

It's up to you to decide what you need most: simple stable questiontype with full pcre support, or complex unstable questiontype with some additional hints in training mode.

Hi Oleg,

Thanks for offering a new, regular expression -based version of the SHORTANSWER question type. I do know the limitations of the present REGEXP question type, the fact that is not very robust and will hang if there are too many conditions to calculate, etc. And I quite agree that now would be the right time to compare my own REGEXP question with other options, such as yours. Here are some considerations I am offering.

1- Is your preg question type more similar to the "regular expression" option in the LESSON module SHORTANSWER question than to my REGEXP quiz question type?

2- As you know, the reason for my REGEXP not accepting * and + standard regular expressions characters is that it must be able to generate a finite number of alternative correct answers, which is clearly not possible with * and +

3- As you are aware, a large part of the REGEXP plugin is devoted to the automatic generation of such alternate correct answers, based on the regular expressions which will provide for this generation. And the HINT facility is based on that automatic generation. I mostly use the Quiz module for learning purposes, not for testing purposes, so for me the HINT facility and the feedback messages are of the utmost importance.

4- I disagree that REGEXP has "many pesky bugs related to it". I use it regularly with my students (for my English language and didactics classes) and it does exactly what I intended it for. What I have found from moodlers using it and posting in the Quiz forum is that some people want REGEXP to do "impossible tasks". One must be reasonable.

5- One point which could be improved is the authoring interface (as suggested by Pierre Pichet); and regular expressions should be tested one by one.

I would certainly be interested in testing your own regular expression plugin, if you would make it available here. Maybe Tim and Pierre would agree to test it to and report here. But as far as I can understand from your description, I'm afraid it will miss those features which are indispensable to me.

All the best,

Joseph

Hi, Joseph

1 - I'm unsure since we don't use lessons much. I'll see and tell you later.

2&3 - Yes, I know you reasons. First of all, there are things I'm totally not approve as an admin and software developer, and downgrading fucntionality (you question can accept + and * in old versions) without any means of automatically adapt to situations is one of them. We just happen to have only two full year courses using regex, and that only results on more than 300 questions which we must edit manually to comply with you new version (we found that write a new plugin was much easier). At the very least you must create an option in question, use you new system or not -this won't hurt anything in you precious HINT facility, but do a lot for some of the users of you questions. Backward compatibility is a high courtesy in the software development - but you choose to dismiss such problems as using you questions in improper way (thought it is a proper way to use regular expressions). Sorry for my tone there, but such issues can do a lot of damage for a large institutions. Well, now we can discuss more friendly options

The path you decide to take is to generate all possible correct answers. I think this path is wrong as it inherently add many issues that can't be resolved (it's also probably not properly tested for algorithm of such complexity - i'd seen some strange things in regexes with many brackets for one thing). This path is easier at first, but leads to deadend. I wonder, why did you choose it? Because it's relatively easy or you just don't know another ways? We may discuss it and find better ways. I'm interested in realisation of it too, but just now I'm lacking a good (probably postgraduate) student to write it and the time to do all the work by myself. I may help you or the programmer you'll found thought.

There are several better paths to do what you want, they can increase not only robustness and functionality, but what you seek too.
a) easy, but depends on unknown force. We can coopt and try to force php developers to add partial matching functionality to preg extension (there was even a patch to do this on php tracker since 2005, but it got lost). Actually there is partial matching in underlining C library (PCRE), so it is easy to add them to php. I can write such simple php extension by myself, but see no point in it since many hosting providers doesn't allow third party extensions. Still worth trying get it from php developers - maybe if you can get support from moodlers using you questions we can create a large force to try to vote for it. The downside will be high version of php required.
b) somewhat hard, but reliable. Alternatively, you can just get properly tested algorithm of partial matching from PCRE and port it to php. It's far better than try to create your own. Did you know C language to some extent? I can tell you where to look and, maybe, help with understanding code.
c) moderate difficulty. It's relatively easy to parse regular expression (either using parser generator or by simple finite automate). Having a syntax tree you can add it's nodes one by one and found, where the students answer stop matching. Get the last successful match and it's all. You can use a tree to properly validate regular expression too, and even display it to the user to decribe what wrong with his expression.

Feel free to ask any questions, if you don't understand what I writed above. I only outlined some possibilities, I can tell you more about any of them if you are serious about improving you question.

4. If i'm rightly understand, you are not very experienced software developer (I would be very glad to miss there, because then we can easily implement one of the solutions above), you attempt to write such complex algorithm is a valiant one, but it lacks many things to become sufficiently stable (especially if considered for core IMHO). You use only simple regular expressions for you purposes, and probably you supporters too. Dismissing things you can't do right now as 'impossible tasks' (especially based on users experience - who is better know what's possible - user or programmer?) isn't a very good practice in development. Actually, these things is not only possible, they are the normal part of the regular expressions functionality in many programming languages. Maybe you should not name you expressions regular, if you don't want to work with basic regex functionality? You potentianl users is not experienced with regexes too. You can easily create you own expressions syntax, suit it for you purposes, which will be even easier for people without programming exprerience (and easier to fully support by you program), and they wouldn't mislead people that have such experience. Or should we aim at full regular expressions functionality? Have you at least documented the changes to the regular expression syntax that you made, or you just have link to the sites with full syntax, with + and * ?

I agree, that my error was not giving our question to large auditory right away, so I don't have supporters in the forums. We tested it in 4 real courses with 5 authors, several hundred of questions (some with very complex expressions) and about two hundred of students.

Right now IMHO (in my Humble opinion, the real decision there is for Tim) you question isn't properly tested and taking wrong way for inclusion to the core (I think of core as a base of stable code). If you want, we can work together to upgrade and debug it's functionality, and than propose to include it to the core (and right now simply patch shortanswer with regular expression option). But you'll need to do most of actual programming by youself, or find someone to do it. I can explain, give sources and examples, and write the most difficult parts of code.

Actually, I planned many development that eventually lead us to you 'indispensable features' on more stable basis, but I lack time to do all actual programming by myself right now. My TODO list is based on complexity of the task:
A) generate correct answer for display to the student based on regular expression
B) parse regular expression and validate it; add HINT functionality based on syntax tree using
C) develop a way to show diff between students answer and the closest match of it to the regular expression (this is far better alternative, since you will show not many info to the student, who made an error on the begining) - but this probably could lead to Ph.D dissertation one of my postgraduate students, since there is a need to develop a new algorithms there.

I'll made my questiontype available there in few days, thought in it's current state it isn't very appealing to you. Right now it's features entering user-visible correct answer in the special field, not as one of the answers, and exact/partial match options (whether user want to find exact matches to all regexes, or he want to use expressions that matches with the part of the answer to report typical errors - right now you question may lack this).

With best regards, Oleg Sychev (Senior Lecturer of Software Development Department of Volgograd State Techncal University, Ph.D. in System Analysis, if you need any credentials whether I'm up to the task).

Well, Joseph, there are some exciting news!

I did a somewhat more thorought search and found a way to easily create a robust, reliable and fully functional regex with you HINT functionality: at least it would very easy display the beginning of the answer that correspond with the start of regular expression (you can do HINT from there just by trying any symbols as next). To do this, hovewer, we need to use external executable file, running from php. The program will be written in C++ using GPL version of Qt Library (so it should compile without any modifications on any Unix, Windows and Mac platform supported by Qt, but we still need to compile it on every platform separately). Your'e better know Tim and Pierre, so you'll can easier ask them if this OK. Actually, Moodle already uses such external executable in TEX filter, so it isn't something completely alien to Moodle.

We can supply a compiled versions for most popular platforms (and choose which to use by setting), and even write a script to compile it on Unix with gcc on installing.

1.Any regexp question type is a "potentially dangerous" question type as its involved an internal sofware process to analyze the student response and regexp expressions are complex things to handle.
Should these question type be part of the core code is a real question ?
Even more as students can be allowed to create questions on 1.9.

2.Last year I had a "vigorous discussion" with Tim about core code question types.
Since then working to strengthening calculated qustion or multianswer , I understand more his concerns about code stability and code maintenance.

3.Moodle Community needs people with diverse experience that are volunteers to give there time and effort and I appreciate greatly the work done by Joseph...

4. as the energy and competence of Oleg...

Sorry, I was interrupted.

Hi, Pierre.

1. I don't think there is something inherently dangerous in regular expressions by itself as long as we are don't add a complex code of our own (especially obligatory - any exprimental feature must have an option to turn it off), relying on existing matching functions (either from php (PCRE) or Qt) - they are very well tested and optimized. We used many very complex expressions - last one that gives troubles for one of our authors for example
[\s\t\n\r]*friend[\s\t\n\r]+(class[\s\t\n\r]+|)number[\s\t\n\r]+operator[\s\t\n\r]*+[\s\t\n\r]*([\s\t\n\r]*(const[\s\t\n\r]+|)[\s\t\n\r]*(class[\s\t\n\r]+|)number[\s\t\n\r]*(&[\s\t\n\r]*[A-Za-z_][A-Za-z_0-9]*|[\s\t\n\r]+[A-Za-z_][A-Za-z_0-9]*|&|)[\s\t\n\r]*,[\s\t\n\r]*(const[\s\t\n\r]+|)[\s\t\n\r]*(class[\s\t\n\r]+|)number[\s\t\n\r]*(&[\s\t\n\r]*[A-Za-z_][A-Za-z_0-9]*|[\s\t\n\r]+[A-Za-z_][A-Za-z_0-9]*|&|)[\s\t\n\r]*)[\s\t\n\r]*;+[\s\t\n\r]*
There was many errors in expressions, but we received nothing worse than incorrectly graded answers (even without any program validisation of regular expressions at all). So I don't think there is something in regular expressions in itself that can't be included in core (actually existing code of shortanswer question already use regular expression and preg_match to get wildcard functioonality - and in our question we use preg_match as well). Actually I can make a very small patch to allow regular expression functionality in shortanswer question, doesn't hurting anything in it's default behavour - just a pair of new options and a text field with appropriate help files) - this will reduce the number of questiontypes to support and I'll resolve any bugs everyone can find in it - even now code duplication between many questiontypes is great, thought I don't see an elegant solution to this right now.

There are issues with Joseph's code, and even more with his attitude to it's maintenance (nothing personal) thought - issues that must be dealt with before inclusion in core IMHO. The main problem with Joseph is that he sees only his (and similar) needs from regexes, and don't care a lot about users with different needs - even to a point to violate backward compatibility of his question, so that user must editing manually each problematic questions (about several hundreds in our case - he kindly told us how could this be done) to comply with new version of his questiontype, which was the only version compatible with new Moodle version (attitude which I never seen in Moodle core - that's why I'm greatly respect Moodle developers and thinks Moodle is an appropriate system for large institutions with many courses and students) to get some nice functionality he wants. He easiely can make his new functionality optional, so the old questions will still work with it turned off, but he preferred to dismiss such problems as demanding 'impossible tasks' from his regexs (see above) - this gives us a big pain one time. Such attitude is somewhat Ok in third party area, where everyone do what he want and just share his work with others, but this is completely not a form of attitude expected from core IMHO. This is a one source of my energy in the case: we a currently running pilot on Moodle and people there have very bad experience with Josephs question, they were not encouraged at all hearing that it will be included in the core.

The problem with actual Joseph's code is that he try to match regular expressions byhimself (probably lacking understanding underlining theory) and took a wrong way to do this (I'm just happened to teach "The Programming Laguage Theory and Methods of Translation" last years so I'm know what I say) - he try to use brute force algorithm, thought he must use finite automate and, probably, backtracking. I'm sort of appreciate his courage and big work dealing with such problems - this is not a sort of the problems I want to deal just in free time even been an exprienced programmer - but unfortunately only courage doesn't make a stable code.

2. As an administrator and developer I can understand Tim's concerns quite well. Consistency and backward compatibility is a great thing in a large institution, when you have many courses and a lot of questions to support (as I understand Tim also work in a large university). Josephs attitude, focusing more on functionality than stability and compatibility, is preferred in small cases.

So I see those option as appropriate (IMHO - in my Humble opinion)
1) create a stable patch for shortanswer questiontype (or a new questiontype for core) using existing matching functions - this doesn't cost you any problem and regular expressions is well to have in the core, as they are very useful sometimes - leaving Joseph's unstable code in 3d party area for now (so he and his users doesn't lose anything). I can work with Joseph to make his code more stable, if he want it, and after this I will vote for it inclusion in the core.
2) I can easily create a way to achieve at least some of Joseph's functionality without complex code using external executable file - this will be somewhat tricky to install in several cases (see TEX filter), but stable and robust once your get it working
3) the problem of regular expression validation is a more complex one. It is not immediately necessary, since using standard functions we don't receive anything too bad from invalid regexes (you approach to regexes as 'potentially dangerous' may be related more to you experience with Josephs code than to regexes in itself). Validation is moslty a problem of the user creating question, especially if he is novice - it's nice to have (thought we do well without it) but requires more complex code. First of all I can add a link to one of the Internet regex validation site to the questionpage. It's relatively easy to allow user to create unit tests for regexes - entering several answers that must match it and during validation check, that all of that answers is match with some 100% regex - this saves pains of entering all test cases after any editing of expressions. Actual validation requires parsing of expressions (and you'll even be able to tell the user what his regex really means), which can't be done without some complex code. I can write it in C in no time, it's far worse for php thought lacking widely accepted scanner and parser generators - also I would appreciate someone with web designer skills working with me on the case.

Right now I'm adding a sort of simple validisation based on assumption, that correct answer in user-readable form, entered by teacher, must match at least one 100% expression. I'm sorry that I don't upload our questiontype there right now, but I can't properly test it since question editing of most questiontypes on my testing site is broken thanks to implementing MDL-17064. I'll make code avaible shortly after we find general consensus and fix it.

It is good to have a technical debate about the merits, or otherwise, of adding the Regex question type to core. However, please can we avoid personal attacks. They don't help with anything. (Even if Oleg had one bad experience with Joseph in the past. You can note that if you like, but then you should try to get over it and move on.)

When I suggested adding regex to core, it was based on the fact it had been around for a long time, and got updated for each new Moodle release; and from reading the forums people seemed to use it and like it. Therefore it seemed like a easy, quick win to add it to Moodle 2.0. However, when I made that suggestion, I had not looked at the code, and I still have not. Obviously I would before actually adding it to core, but I have lots of other things to work on for Moodle 2.0, so I will not get around to thinking about the regex question type in detail until after Christmas. In the mean time that should not stop anyone else working on it, or discussing it. In fact, please do. I think all of you have thought more about this than I have so far!

Two of the principles of open source software are 'scratch your own itch' and 'release early and release often'. That is, follow your motivation to write code that does the things you personally require, and don't be afraid to share them, even if they are not completely polished yet. (Then release updates as you find and fix bugs - or as other people find and fix bugs and share them with you.) Both Oleg and Joseph have scratched their own itch, which is good. Oleg, it would be good if you had time to get your question type into contrib (http://docs.moodle.org/en/Contrib). It is good that you don't want to claim it is stable until you have run it yourself for a year, but there is no harm sharing an alpha-quality, unsupported release sooner.

One of the strengths of the Moodle project is that it has always had teachers closely involved in the development process, either just in discussions, or acutally writing code. That sometimes leads to code that causes professional developers to throw up their hands in horror, but it does lead to a tool that lets you construct powerful learning experiences. It is relatively easy for an experienced programmer to rewrite crappy code, to do the same thing, but more robustly/faster/more securely/.... It is harder to work out what makes a powerful learning tool in the first place. (Of course, it is not so easy to learn to be an experienced programmer, it has taken me over 10 years so far, and I know my limitations. For example, I know I don't want to have to write or maintain a regex matching algorithm)

About using 3rd party C++ libraries. You need to keep in mind http://docs.moodle.org/en/Moodle_design_goals, paricularly the first two. Certainly it is not something to do lightly.

The main security risk with allowing arbitrary regular expressions is that it is relatively easy to write regexs that require exponential time to match (e.g. http://swtch.com/~rsc/regexp/regexp1.html) - leading to potential denial of service problems if you have untrustworthy teachers. I don't think this represents a major risk, but it is worth noting.

Well, here we are - you can test our preg questiontype now. It's seems that I must have a write access to CVS to place it in Contrib section, which I have not .

There are a two problems with this code:
1) help files isn't so detailed. English is not my native language, so I avoid writing many in it without an editor (if someone would like to help me I'll be pleased)
2) there is a code duplication, which can be avoided, but I'm unsure where place a function common both to question_edit_preg_form and question_preg_qtype classes (it probably must be a statical function in one of them, but in which one? could anyone more experienced with moodle help me?)

Hi, Tim

Could you please tell me you opinion on one thing now: our question is very similar to shortanswer. Would you like to view it as a separate questiontype or as a patch to shortanswer (so I can have time to write the patch)?

Excuse me, if I'm offended someone. I have nothing personal against Joseph. I just don't want to see a repetion of these old events again, especially in the core.

"but there is no harm sharing an alpha-quality, unsupported release sooner" - well, I'm sort of unsure there since some people may use it and create a large database of questions - and than get stuck with it. However now I'll release it to the community (thought I don't think it will be widely accepted in the near future in any case since Joseph has a head start).

" It is relatively easy for an experienced programmer to rewrite crappy code, to do the same thing, but more robustly/faster/more securely/.... It is harder to work out what makes a powerful learning tool in the first place. ...........About using 3rd party C++ libraries. Certainly it is not something to do lightly. " I'm agree with you in general, but not in the case of regex matching, it's too complex ... well, I'll be happy if someone there will rewrite Joseph code on more consistent basis, using correct algorithms. I'm certainly don't want do it by myself. I think my questiontype will eventualy evolve to maintain Josephs learning functionality on another basis, but not right now. As about Qt Library, it's well known for its cross-platform compatibility. And if Joseph's functionality is very important I'm think it's still the best way to achive it now.

"The main security risk with allowing arbitrary regular expressions is that it is relatively easy to write regexs that require exponential time to match " -it's no problem with preg_match because PCRE abandon matching when the maximum number of recursive steps reached. I run a?NaN matching aN test with N=100 (which must take 10^15 years of execution on Perl according to article you mentioned) and it was done in no time on my local machine, far faster than any moodle form generation (with wrong result of course). So there is no security risks there for preg extension. (Thought a Joseph's code is very vulnerable to this risk, as it uses brute force algorithm. We found this out on our real questions soon enought.)

Joseph, I placed a link to you questiontype on the page of our question within modules and plugins database with clear description to the users in what cases that would prefer you questiontype. Will you do the same?

Also, you don't answer about developing you question. I still think there is at least one not very hard way to achive you needs, once you get acquainted with some tools that'll generate the most complex parts of code for you. Are you interested in this?

Oleg, it is probably best if you create a separate tracker issue (in the CONTRIB project) with your code attached. Make sure it gets assigned to Anthony Borrow, and he will work with you to add it to contrib CVS, and give you write access to it. (Please add me as a watcher, or tell me this issue number if you do this. Thanks.)

In terms of how I think this should work in an ideal word. If I had the time, I would like to try using and idea I got from the Bugzilla advanced search form. Look at just the 'A Comment:' field on https://bugzilla.mozilla.org/query.cgi?format=advanced (and ignore everything else on that monstrous form ). I like the way they have a dropdown giving a number of matching options. Would that work as an enhancement to the short-answer question type?

I don't necessarily mean we should give teachers exactly those choices, we would need to think about which options are most useful, but just use that general approach. But, for example 'Contains all the words' is hard to do in a regex. Of course, it would be nice to adopt an approach that makes it easy to add new matching options in future (but without breaking existing questions).

"Would that work as an enhancement to the short-answer question type? " - probably yes, there is nothing complex there, the patch just will be somewhat big. I can't give you any definite shedule on this, but may work on it when I have a time (if you want).

We need to think about interface thought. The user definitely must have possibility to choose different choices in one question, but setting every subanswer in specific option is tiring, so there probably must be some sort of global preference too. And maybe a subitems when creating the question (such as in adding an assignment now) to set general choice (which can be rewritten individually).

Can we work on this together? I certainly can refactor the question type to allow subplugins (and write some), but question creating interface is somewhat different. Well, probably another issue to create. Who must do it - you or I?

P.S. I created CONTRIB-869 and added you as a watcher there.

It seems I attached the wrong file there. Here is a right one.

Well, I don't have time to think about this now, so I would rather you work on this mostly on your own, and it is not a problem if the work does not happen to a schedule.

Well, don't work on it completely on your own. I suggest you post about what you are doing and ask questions in the Quiz forum (http://moodle.org/mod/forum/view.php?f=121) - I will probably respond to postings there, and you will get the benefit of other people's ideas too even if I am too busy, so that takes the pressure off me, which is nice.

Also, it is a good idea if you can write about what you plan to do on http://docs.moodle.org/en/Development:Developer_notes before you do it. That makes it easy for people to comment, and it is a good place to do things like write about different interface ideas.

I created a page in wiki for further discussion of shortanswer development: http://docs.moodle.org/en/Development:Shortanswer_question_development . Anyone interested is welcome there.

Yes, I saw it. It would be good if you posted about it in the quiz forum.

Hi Tim,
I would like to upgrade my REGEXP question type plugin to moodle 2.0 but it seems I cannot get the new DB create/upgrade system in Moodle 2.0 to work.
I have copied the 2 files question/shortanswer/ install.xml and upgrade.php to question/regexp/ install.xml and upgrade.php, just replacing everywhere shortanswer with regexp (plus changing the only different field name usecase to usehint).
When I go to my moodle 2.0 Notifications, however, nothing is created in the database.
What should I do?
Thanks in advance,
Joseph Rézeau
PS.- I sent you as private e-mail to your open.ac.uk address a few days ago but I'm not sure you received it.

Sorry, I did get that email, but it got buried.

You are missing a /db in your paths in the above comment, but I assume you did not make the same mistake in the code.

Did you remember to create/update version.php?

Thanks Tim, that was it, I had not updated the $plugin->version = xxxxxxxxxxx;
line in my version.php file.
Now it's working.
By the way, what value should I put in the second line: $plugin->requires = 2007101000;
Joseph

A safe option is to copy the version value from the top level version.php.

If you are sure your code is backwards compatible with earlier versions, then you can use an earlier date.

I now don't want to add new question types until after my new question engine is complete (MDL-20636).

Just updating things to be a more accurate reflection of the state of play.