Perl 6 - the future is here, just unevenly distributed

IRC log for #webwork, 2013-04-06

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

All times shown according to UTC.

Time Nick Message
00:08 mgage_ joined #webwork
00:55 mgage_ joined #webwork
01:51 mgage_ joined #webwork
02:08 Paul_Pearson joined #webwork
02:08 goehle_ joined #webwork
02:08 aubreyja joined #webwork
02:08 ChanServ joined #webwork
02:12 goehle_ hey mgage
02:13 mgage_ hi
02:15 mgage_ hi goehle
02:18 mgage_ goehle: what's up?
02:21 goehle_ hey
02:21 goehle_ sorry
02:21 mgage_ np
02:21 goehle_ don't have alerts turned on
02:22 goehle_ just wanted to let you know that I make a pull request for a bunch of changes to develop and published a blog post
02:22 goehle_ also wanted to see what else needs to be done
02:23 mgage_ I saw them.  -- I'm still constructing webwork sets for next week for my classes :-)  I'll look at the new stuff tomorrow.
02:23 goehle_ no rush
02:23 goehle_ I was able to get bootstrap tabbing working
02:23 goehle_ but its not particularly elegant
02:24 mgage_ There is some clean up work that should be done on homework sets editor 2 (although it will eventually be replaced by homework manager) -- some of the features don't quite work -- for example importing sets with a new name doesn't always respect the new name
02:24 mgage_ good -- that's a help
02:25 goehle_ Interesting, I haven't run into that
02:25 goehle_ I was thinking I might go through some of my code and try and speed things up with smarter database calls
02:25 mgage_ one of the larger projects I'd like to start is a to create a collection of test problems/programs that insure that new features of WW don't accidentally destroy old features.  i started a gage_test course on my github as a beginning
02:26 mgage_ speeding things up with the database calls would be useful -- and you already know that code
02:26 mgage_ You could also construct some unit test programs to test out the database calls made through DB.pm -- that could be very useful
02:26 mgage_ (include timing if possible)
02:27 goehle_ yeah, that wouldn't be a huge thing.  Another useful testing thing would be a test course along with a script that would automatically fill up the tables with rows
02:28 goehle_ so you could have your test course with a wide variety of problem types to check
02:28 mgage_ yes
02:28 goehle_ and also check to make sure things work with a realistic database setup
02:28 mgage_ that's the kind of thing i started with gage_test   there is also one on testcourses.webwork.maa.org/webwork2/gage_test
02:29 goehle_ does archiving courses save all of the table data?
02:29 mgage_ eventually I'd like to make it completely automatic but it's already useful to have a suite of questions that I can walk through with a new version of WW to see if anything obvious has gone awry
02:29 mgage_ yes
02:29 goehle_ nice,
02:29 goehle_ including past answers?
02:30 mgage_ (actually I'm not 100% sure about past answers -- but it would be easy to add -- particularly with past_answers specific to one course -- I believe there is just a list of tables that are saved
02:30 mgage_ it will be in the admin modules
02:31 goehle_ I'll check that out too
02:31 goehle_ That should give me something to think about
02:31 goehle_ I'm not sure I'll be able to do much next week, but we'll see
02:31 mgage_ when we go to non-native tables the strategy for archiving a course will be come a bit more complicated since we will have to select the applicable rows for a given course.
02:32 goehle_ right
02:32 mgage_ you're doing great
02:32 mgage_ thanks
02:32 goehle_ np.  I'll also try to get my changes pulled to the university test server to get some testing done.  If you have time/energy and want to test them on your server that would also be good.
02:33 goehle_ Since its on develop its not a huge issue
02:33 mgage_ I'll do that -- I plan to get some preliminary testing done on hosted2 this weekend
02:34 goehle_ for future reference, how important is it that I split up my commits more
02:34 mgage_ and perhaps move my production server to release 2.7 -- we'll see about that.
02:34 goehle_ for example, I fixed essay answers so you can use backticks to format math (and it won't complain about variable context)
02:35 goehle_ but its not clear to me how easy it would be for you to extract just that from the pull request I did today
02:35 mgage_ it's quite useful to split up your commits -- it's easier to review them, it's more likely that they will import cleanly -- and perhaps most important it is easier over the long haul for people to review the commits and decided what has been added and whether they think it is safe to import this stuff to their servers.
02:36 goehle_ its a real hassle for my work flow since I often end up doing more than one thing at a time
02:36 mgage_ I haven't looked yet -- but I think that would be easy enough.   Your individual commits to your own git should be as atomic as possible.   If that is true then even if you submit a bunch of commits at once in a pull request i can (with a bit of work) cherry pick a subset of the new features.
02:37 goehle_ (for example, I was fixing those broken links all afternoon as I ran across them.)
02:37 mgage_ that's where the git add command comes in very handy.  you can do a git add (just one file) and a commit in just a few seconds.
02:37 mgage_ none of the other changes get included in the commit.
02:38 goehle_ that could be good
02:38 goehle_ I tried working on different branches simultaneously at Raleigh and that was too confusing
02:38 goehle_ git add would let me bug fix single files without commiting everything (which would be half unfinished in places)
02:39 mgage_ yes -- I've had to cut down on branches also. but entering bug fixes in single commits while I'm working on something else is easy -- and then if necessary i can cherry pick the bug fixes later.
02:39 mgage_ exactly -- at first I thought that feature was a nuisance but I've come to really appreciate it
02:40 mgage_ you can even collect a bunch of bug fixes and merge them into a main branch before you merge the new feature.
02:40 goehle_ as long as there are no file collisions :P
02:40 goehle_ still, that would have been useful today
02:40 mgage_ it's also a good habit to always create a new branch   when you start a new feature -- makes it much easier to back out
02:41 goehle_ unfortunately the broken link stuff should be merged relatively quickly (so that other people dont end up duplicating the fixes) but its currently all tied up with my math4 tweaks
02:41 mgage_ if you commit and merge (or rebase) pretty regularly there aren't many file collisions.
02:41 goehle_ what I meant was sometimes you bugfix a file that you are also working on for a feature
02:41 goehle_ then its harder to seperate out the changes into different commits
02:42 mgage_ I'll try to untangle them -- I can't do that using github alone but I can do it using git on my laptop development repo
02:42 goehle_ Its often clear to me after the fact how I should have done it, but apriori is tough
02:43 goehle_ It shouldn't be too bad though
02:43 mgage_ I'm not an expert yet, but that is part of the fancy stuff you can do with git -- if your commits were atomic enough you can reorder them the way they should have been done.
02:44 mgage_ you can use the git stash feature also
02:44 goehle_ I was using stash earlier
02:44 goehle_ when switching between branches
02:45 goehle_ I ended up breaking something or another and had to revert.  Then again I seem to do that a lot with git
02:45 mgage_ yes -- and you could use it to temporarily hide your current copy, checkout a fresh copy of the file, fix the bug, commit it, and then pop your stash (it might have a merge collision which you could fix quickly)
02:46 goehle_ that would be nice
02:46 mgage_ it's easier to remember to start a new branch when you are about to start something --- then reverting is easy -- just back up the branch to where you forked off -- but you need to develop the habit of creating new branches
02:46 goehle_ and committing often
02:46 mgage_ yes
02:47 mgage_ by the way -- it also helps the documentation -- somewhat automatically
02:49 goehle_ I'll have to put more effort into good git habits then.  Unfortunately today is not a stellar example.  At least I got a lot done though.  I should be off to bed in any case.  Have a good weekend.
02:49 mgage_ ttyl
02:49 goehle_ left #webwork
04:25 rbeezer joined #webwork
13:02 mgage_ joined #webwork
15:13 Paul_Pearson joined #webwork
15:52 mgage_ joined #webwork
16:39 mgage_ joined #webwork
17:41 mgage_ joined #webwork
18:12 mgage_ joined #webwork
18:57 mgage_ joined #webwork
20:55 mgage_ joined #webwork
21:30 mgage_ joined #webwork
23:20 mgage_ joined #webwork

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