Perl 6 - the future is here, just unevenly distributed

IRC log for #webwork, 2013-02-22

| Channels | #webwork index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
03:09 goehle joined #webwork
03:09 goehle hey mgage
03:10 goehle http://michaelgage.blogspot.com/2013/02/math-achievements-and-webwork.html
03:10 goehle fyi
03:10 goehle left #webwork
15:05 rbeezer joined #webwork
15:12 goehle_ hey mgage
16:25 mgage goehle_: I'm back
17:24 goehle_ hey
17:24 goehle_ me too
17:24 goehle_ (mgage)
17:42 goehle_ hey mgage (take 2 or three ;) )
17:46 mgage goehle_: I'm back again -- what's up?
17:47 goehle_ I had a couple of questions and wanted to make sure that you had sorted everything out with the default achievement stuff
17:47 goehle_ Those "SetNameHere" achievements are included in the achievement folders in case people want ot poke around and use them
17:47 goehle_ but they *shouldn't* be included in the Default_Achievements.axp file
17:47 goehle_ (i.e. they shouldn't get imported if a user imports the default achievements)
17:48 mgage I haven't sorted them out yet -- but I got your message and I think I see what I'm supposed to do.  I'll check the default file and make sure it's ok
17:48 goehle_ It should be fine
17:50 goehle_ I also wanted to ask about a bug I found
17:50 mgage k -- I won't have to change it then.  I added all the new achievements and I think for the most part I'm going to keep the "old" version of the other files (which has SetNameHere entries)  -- and then I'll upload everything -- probably to 2.5.1.3  since that is still stabilizing (and it's the one I'm actually using. :-) )
17:50 mgage ok
17:50 goehle_ if you are using the *try me* option on library files and you hit submit for the answer
17:50 goehle_ the achievement evaluators will give you errors if achievements are enabled
17:51 goehle_ (because they are trying to access due_date and other stuff that doesn't exist for the "empty" set
17:51 goehle_ Should I change the achievement code so that it doesn't run if its part of that dummy set
17:51 goehle_ or should we set it so that submit doesn't even appear as an option for that set
17:54 mgage there are a bunch of things like that -- the original concept was that problems would always be in sets -- then that was hacked so that you could view them in the library (the concept of the Unset) -- it's unclear to me whether we want to continue to patch the code so that dates are defined,  etc. etc.  -- people are also trying to edit problems inside the library (which only kind of supports editing) --- it's tempting to fix each bug as it comes
17:54 mgage but I think a more designed fix is preferable. (even if that means leaving some bugs in place so that we have time/manpower to work on the bigger issue.)
17:55 mgage It's a compromise of course -- if we can fix something easily and quickly we should.
17:55 goehle_ it shouldn't be that hard,
17:55 mgage Perhaps just a warning message that this won't work properly until its in a set ---
17:55 goehle_ what is the name of the dummy set?
17:55 mgage That Unset
17:55 mgage Unset if I remember right
17:56 goehle_ what if people name their set unset?
17:56 mgage I think a generalized warning message about what works and doesn't work would be useful
17:57 goehle_ maybe, achievements *should* bail if its the unset
17:57 goehle_ it doesn't make any sense to run them then
17:57 mgage (They get what they deserve?  :-) )  but more seriously -- it would not be hard -- in fact it may already exist to but a flag in the environment that indicates that you are in the library environment.
17:58 goehle_ ok, I"ll do that then
17:58 mgage we can use that to enable/disable or warn about limitations in behavior.
17:59 goehle_ yeah, thats a good idea
17:59 mgage if it's not there  already then you'll need to hack the code that defines the environment.  I believe that at the moment the library actually uses a different module to set the environment (one of the renderProblem() functions) while the regular problems are set in PG.pm and PG/Local.pm.
18:00 mgage so that should make it pretty easy to determine whether you are in the library environment or not
18:00 goehle_ where would you put the flag
18:00 goehle_ as an element of $problem
18:00 goehle_ or as a variable on its own?
18:01 mgage one of my projects would be to refactor and combine these separate locations where the rendering environment for the problem are set up.  Fortunately they all then go through pg/lib/WeBWorK/PG/Translator -- so that at least doesn't have to be refactored.
18:01 mgage put it into   $envir->{inLibrary}   or something similar   (it will get read out to
18:01 goehle_ ah ok, good
18:02 mgage %envir{inLibrary}   and then access one or the other in the module.  In someways
18:02 mgage $enivr->{inLibrary} is safer since it is a little less likely to be changed by a problem author.
18:02 goehle_ ok
18:03 mgage (you may need to use $main::envir->{inLibrary}  depending where your code is located.
18:03 mgage There is probably a better name than inLibrary -- that was just an example
18:03 goehle_ So I'll put that environment variable there, I'll have it so that achievfements dont run when the environment variable is set, and I'll maybe put a warning on the problem page when the enviornment variable is set which says that not all features may work
18:04 mgage once you've got that then it's pretty clean -- a problem or module that thinks it might not work appropriately in the library can just reference that variable and put out a $WARN_MESSAGE() or something similar.
18:04 goehle_ yeah, that should be easy enough
18:05 goehle_ should I put this into 2.1.3?
18:06 mgage sounds good.  thanks.  -- it's still a bit of a patch/hack but it I think it helps encourage development of a more robust solution --  basically problems have to be reconceived so that they do not expect to be part of a set
18:07 goehle_ yeah, and that way when Problem.pm is run there will be an nice obvious way to skip things that should only be done if there is a set involved
18:07 mgage yes -- I think it's a small enough change that we can slip it into 2.5.1.3.  If it gets large then we'll want it put in   webwork2-dev branch devel   (I'm trying to cut down on the number of branches -- so all new stuff gets put into devel until it's ready to deploy)
18:09 goehle_ um, what else... I finished the blog post.  And I wanted to ask about the upcoming coding camp
18:09 mgage well -- I think Problem.pm _is_ only run when a set is involved.   The editor and library have their output rendered somewhat differently.  (actually the editor is a hybred and does use problem.pm to some extent)
18:09 goehle_ hmmm
18:09 goehle_ I think problem must be run
18:10 mgage not in the library I don't think -- certainly not for library3  but I think not even for library1
18:10 goehle_ because the achievement stuff is only called from Problem.pm
18:10 goehle_ maybe this is a different bug then
18:10 mgage I'd have to look then -- it's been a while since looked at that code.
18:11 mgage problem is called when you use try it from the homework page and also when you use tryit from the library
18:11 goehle_ yeah
18:11 mgage but it's not called when it is displaying the problem within the library page
18:11 goehle_ exactly
18:11 goehle_ right
18:12 goehle_ so the errors aren't when displaying in the library
18:12 mgage ok -- we're on the same page
18:12 goehle_ they are displayed when you are on a try it page
18:12 goehle_ and hit submit
18:12 goehle_ (because the Unset doesn't have the same stuff defined as a regular set)
18:13 mgage right -- so that might mean that we have to set this flag in a few more places to make
18:13 goehle_ so inLibrary isn't really approprate
18:13 goehle_ more like noSetData or something
18:14 mgage sure that you know you are being rendered in the "unset" environment.   I agree that we should be able to look at an explicit flag for that and not depend on reading the name of the surrounding set.
18:14 mgage yes noSetData is more appropriate -- and we may have to set it from more places than I first said.
18:16 mgage I don't have much to say immediately about code camp but I'll be working on planning this weekend .  I like the idea of someone working on cleaning up the css and creating a framework which makes it easy to write new themes.
18:17 mgage one idea would be to see if the student working it here would like to come to Raleigh and you could work on it together -- if you are still interested in that project.
18:17 goehle_ i'm trying to decide if I should cancel class on Friday or if its ok if I get there Friday evening
18:17 goehle_ that woudl be interesting
18:18 goehle_ I'm open to whatever, and I think getting some of the css under control would be nice
18:18 goehle_ (side question:  is this you
18:18 goehle_ DBD::mysql::st execute failed: Unknown column 'merge1.visible' in 'field list'
18:18 goehle_ WeBWorK::DB::Schema::NewSQL::Std
18:19 goehle_ (as in something you were working on for 2.5.1.3)
18:19 mgage either would probably be ok.  I'll try to get plans more developed so you can have a better idea of whether it's worth it to get there early or not.  I will be coming in Thursday afternoon (I got someone to take my class) and will be leaving in the late afternoon on Monday.
18:19 mgage you need to upgrade your courses.
18:19 goehle_ what changed in the db?
18:20 mgage we switched from a "published" field to a "visible" field in the database so that the name in the field would match the name used throughout the WW code
18:20 goehle_ ah ok
18:21 mgage after the upgrade your courses will have an unused "published" field in the database but it does no harm.
18:21 goehle_ Fixed it
18:21 goehle_ thanks
18:21 mgage I didn't delete it because I don't like to delete things automatically -- too much can go wrong
18:22 goehle_ yeah, and it doesn't hurt anything, like you said
18:22 mgage you can remove the published field by hand using mysql if you want -- but it's not necessary
18:22 goehle_ so is everyone getting to Raleigh on Thursday evening or on friday?
18:22 mgage it actually helps if you switch back to the older system.  the published field will already be there.
18:22 goehle_ right
18:23 goehle_ especially if you are fancy and have a webwor2-dev and webwork2 dual setup
18:23 mgage I don't know -- many from further away are getting there Thursday night -- there may be recent news on the google planning doc -- I think you have access to that?
18:23 goehle_ yeah
18:23 goehle_ I'll go check it out
18:24 mgage I have things working so that I can get between 2.5.1.1 and 2.5.1.3 in two minutes with minimum hassle -- it helps when I'm trying things out.
18:25 goehle_ looks like people are mostly getting there on thursday

| Channels | #webwork index | Today | | Search | Google Search | Plain-Text | summary