| *** tpb has joined #melange | 00:00 | |
| *** madrazr has joined #melange | 02:17 | |
| *** ChanServ sets mode: +v madrazr | 02:17 | |
| *** mithro has joined #melange | 02:30 | |
| *** ChanServ sets mode: +v mithro | 02:30 | |
| *** dhaun has joined #melange | 03:04 | |
| *** florinciu has joined #melange | 03:53 | |
| *** Merio has joined #melange | 05:25 | |
| *** ChanServ sets mode: +v Merio | 05:25 | |
| *** madrazr has quit IRC | 05:30 | |
| *** madrazr has joined #melange | 07:03 | |
| *** ChanServ sets mode: +v madrazr | 07:03 | |
| *** scorche has quit IRC | 07:46 | |
| *** ArthurLiu has quit IRC | 07:46 | |
| *** jamtoday has quit IRC | 07:46 | |
| *** Erant has quit IRC | 07:46 | |
| *** nuba has quit IRC | 07:46 | |
| *** dhaun has quit IRC | 07:46 | |
| *** mithro has quit IRC | 07:46 | |
| *** madrazr has quit IRC | 07:46 | |
| *** florinciu has quit IRC | 07:46 | |
| *** MatthewWilkes has quit IRC | 07:46 | |
| *** lisppaste9 has quit IRC | 07:46 | |
| *** kblin has quit IRC | 07:46 | |
| *** tansell has quit IRC | 07:46 | |
| *** schultmc has quit IRC | 07:46 | |
| *** scorche|sh has quit IRC | 07:46 | |
| *** r0bby has quit IRC | 07:46 | |
| *** madrazr has joined #melange | 07:48 | |
| *** florinciu has joined #melange | 07:48 | |
| *** dhaun has joined #melange | 07:48 | |
| *** mithro has joined #melange | 07:48 | |
| *** MatthewWilkes has joined #melange | 07:48 | |
| *** scorche|sh has joined #melange | 07:48 | |
| *** scorche has joined #melange | 07:48 | |
| *** jamtoday has joined #melange | 07:48 | |
| *** ArthurLiu has joined #melange | 07:48 | |
| *** schultmc has joined #melange | 07:48 | |
| *** r0bby has joined #melange | 07:48 | |
| *** Erant has joined #melange | 07:48 | |
| *** lisppaste9 has joined #melange | 07:48 | |
| *** tansell has joined #melange | 07:48 | |
| *** nuba has joined #melange | 07:48 | |
| *** kblin has joined #melange | 07:48 | |
| *** irc.freenode.net sets mode: +vv madrazr mithro | 07:48 | |
| *** madrazr has quit IRC | 09:16 | |
| *** dhans has joined #melange | 09:19 | |
| *** dhans has quit IRC | 09:31 | |
| *** madrazr has joined #melange | 09:31 | |
| *** ChanServ sets mode: +v madrazr | 09:31 | |
| Merio | dhans: ping | 10:00 |
|---|---|---|
| *** dhans has joined #melange | 10:56 | |
| *** dhans has quit IRC | 11:40 | |
| *** dhans has joined #melange | 11:43 | |
| *** dhaun1 has joined #melange | 12:22 | |
| *** dhaun has quit IRC | 12:23 | |
| *** dhaun1 is now known as dhaun | 12:23 | |
| *** dhans has quit IRC | 12:27 | |
| *** Lennie has joined #melange | 13:46 | |
| *** ChanServ sets mode: +o Lennie | 13:46 | |
| ajaksu | jamtoday: ping | 13:54 |
| *** ajaksu has quit IRC | 15:01 | |
| Lennie | Merio: ping | 15:12 |
| Lennie | Merio: 2-0 behind :P | 15:13 |
| Merio | Lennie: pong | 15:13 |
| Lennie | Ajaksu is beating you :D | 15:13 |
| Merio | Lennie: about what? :) | 15:13 |
| Lennie | soccer :P | 15:13 |
| Lennie | 3-0 | 15:14 |
| Lennie | Italy has no chance the last 10 min :D | 15:14 |
| Merio | Lennie: fantastic! :) I didn't even know of it ^__^ | 15:15 |
| Lennie | hehe | 15:15 |
| Lennie | I just turned the tv on for some background noise :P | 15:16 |
| Merio | Lennie: but well it's not a surprise with Brazil ^__^ | 15:16 |
| Lennie | hmm | 15:16 |
| Lennie | didn't italy win the WC? | 15:16 |
| Lennie | 3 years ago | 15:16 |
| Merio | Yes, followed it a lot ^_^ | 15:16 |
| madrazr | Lennie: and I was giving exam on that day too during the Italy vs France match :P | 15:17 |
| madrazr | our Univ sucks :D | 15:17 |
| Merio | madrazr: ahhh.. you made me recall happiness ^__^ | 15:17 |
| madrazr | Merio: heh how? :P | 15:17 |
| madrazr | Merio: Univ? ;-) | 15:17 |
| Merio | Finals of last WC ^_^ | 15:17 |
| madrazr | Merio: hah hah Ok | 15:18 |
| Merio | madrazr: no ^_^ | 15:18 |
| Lennie | :D | 15:18 |
| Lennie | Nothing compared to dutch soccer craziness :) | 15:18 |
| Merio | madrazr: I've lost an Italy European Cup match because of a lesson of Physics... sic | 15:18 |
| Lennie | last EC we took over switserland :D | 15:18 |
| Lennie | by caravan :P | 15:19 |
| Lennie | craziness :D | 15:19 |
| Merio | I remember the semi-final against Denmark I think in 1996 | 15:19 |
| Lennie | anyhow, I'm not that much of a soccer fan D | 15:19 |
| Lennie | but I like the Dutch team | 15:19 |
| Merio | Me too for Italy :) | 15:19 |
| Lennie | just because apparently I'm proud of my country LO: | 15:19 |
| Lennie | *:P | 15:19 |
| madrazr | Merio: heh | 15:19 |
| Merio | Well I'm not too proud, but still fan :) | 15:19 |
| Lennie | hehe | 15:20 |
| Lennie | that might be a better thing to say | 15:20 |
| Merio | which one? | 15:20 |
| Lennie | not too proud but still a fan :P | 15:21 |
| Merio | :) | 15:21 |
| Lennie | I'm off | 15:26 |
| madrazr | Lennie: see you | 15:26 |
| madrazr | good night | 15:26 |
| Lennie | madrazr: you should get some sleep soon :P | 15:27 |
| Merio | Lennie: c ya :) | 15:27 |
| Lennie | you can do more 120% work tomorrow :D | 15:27 |
| Lennie | nn :) | 15:27 |
| madrazr | Lennie: ROFL! he he :D | 15:27 |
| madrazr | Lennie: thanks for the concern :P will sleep soon | 15:27 |
| *** Lennie has quit IRC | 15:27 | |
| *** solydzajs has joined #melange | 15:28 | |
| *** ChanServ sets mode: +o solydzajs | 15:28 | |
| *** solydzajs has quit IRC | 15:28 | |
| *** madrazr1 has joined #melange | 16:33 | |
| *** madrazr has quit IRC | 16:33 | |
| *** madrazr1 is now known as madrazr | 16:34 | |
| *** ajaksu has joined #melange | 16:34 | |
| *** ChanServ sets mode: +v madrazr | 16:34 | |
| *** ankitg has joined #melange | 16:53 | |
| *** madrazr has left #melange | 17:07 | |
| *** dhans has joined #melange | 17:26 | |
| *** dhaun has quit IRC | 17:30 | |
| *** florinciu has quit IRC | 17:45 | |
| *** MatthewWilkes has quit IRC | 18:27 | |
| *** dhans_ has joined #melange | 18:58 | |
| jamtoday | ajaksu: If you've pushed all the changes you've got, I can going through the code review...it looks like JS mostly. | 19:07 |
| *** dhans has quit IRC | 19:07 | |
| jamtoday | ajaksu: Also, I'd like to go in and get the GSOC modularization over with....i'd like to discuss a proposed implementation | 19:07 |
| ajaksu | jamtoday: I can't git mv the files the way I hg mved them, any hints? | 19:07 |
| jamtoday | is that like remove/add? | 19:08 |
| jamtoday | you can just rename files in git | 19:08 |
| jamtoday | and it will know that it's the same file | 19:09 |
| jamtoday | so you could just do 'mv foo.py bar.py' | 19:09 |
| ajaksu | jamtoday: move from one directory to the other works like that? no wonder I couldn't figure it out :)( | 19:09 |
| ajaksu | cool, let me try | 19:09 |
| jamtoday | Not from outside the git repo of course :) | 19:09 |
| jamtoday | but within it, yes | 19:09 |
| ajaksu | dumb me moved-with-rename to the wrong folder, is the mv detection hash based of fs based? will it work if I just move again or should I reset working copy status? :) | 19:14 |
| ajaksu | jamtoday: I think I got it, can you take a look at last push? | 19:19 |
| jamtoday | you should be able to move it again | 19:19 |
| jamtoday | just do a git status | 19:20 |
| jamtoday | it should say that you've renamed the file | 19:20 |
| ajaksu | doh, I copied one of the files instead of moving, should I push a delete or do something smarter? | 19:21 |
| ajaksu | jamtoday: when do you have 30-40 minutes to discuss modularization? can we add survey linking to the discussion? | 19:28 |
| *** dhans_ has quit IRC | 19:46 | |
| *** dhans has joined #melange | 19:46 | |
| *** mithro has quit IRC | 20:00 | |
| jamtoday | You can always reset | 20:08 |
| jamtoday | ajaksu: Anytime is good, as long as I'm around. If you have a specific time, let me know and I'll make sure I'm around | 20:09 |
| ajaksu | jamtoday: I'd like to have a high density discussion during a pre-defined ammount of time, as we tend to chat in outbursts alternating with long lags :) | 20:36 |
| *** mithro has joined #melange | 20:50 | |
| *** ChanServ sets mode: +v mithro | 20:50 | |
| *** Merio has quit IRC | 21:06 | |
| *** dhans has quit IRC | 21:07 | |
| jamtoday | ajaksu: good idea. i am here right now, and not leaving for at least an hour | 21:10 |
| jamtoday | or just ping me with a little bit of notice | 21:11 |
| ajaksu | jamtoday: I need about 10 minutes here, I think it'd fit in under 1 hour then :) | 21:12 |
| jamtoday | Do you feel like you have a good understanding of the survey workflow at this point? | 21:16 |
| jamtoday | I think the one point of confusion is what the purpose of the mentor survey is | 21:16 |
| jamtoday | You mentioned that the grading survey is only taken if the student survey isn't submitted? | 21:16 |
| ajaksu | jamtoday: ok, back and here for a looong time now :) | 21:19 |
| jamtoday | A few things that might be useful to explicitly state: | 21:19 |
| jamtoday | It is alright for *all* surveys (midterm/final or not) to be associated with a program | 21:20 |
| jamtoday | I don't necessarily think it needs to be this way, but that's what Lennie said would be best for now | 21:20 |
| ajaksu | jamtoday: I guess I do, the issue I see now is mostly about how can we have many surveys pairs for the same mentor-student pair, the rest seems like easy generalizations to build into the main survey classes | 21:20 |
| jamtoday | And that's already how the surveys work, so thats fine | 21:20 |
| jamtoday | The mentor-student pair is a compound value joined by a student project | 21:21 |
| jamtoday | so the way i see it is that the student project is the key for things like showing both the midterm and final for a student | 21:21 |
| ajaksu | right, now we have survey pairs too | 21:21 |
| ajaksu | how do we know student-survey-a goes with mentor-survey-a and student-survey-b goes with mentor-survey-b? | 21:22 |
| jamtoday | Whenever anyone (student or mentor) submits a midterm or final survey, they must choose a project | 21:22 |
| jamtoday | The project is used as the key, and then you can filter by the survey-taker | 21:23 |
| jamtoday | the SurveyRecord has a project key. If the SurveyRecord is to be subclassed for midterm/finals, this project key would go into the subclassed model | 21:24 |
| ajaksu | say we have two non-midterm-nor-final surveys, a and b, that have student-mentor links similar to midterm's... | 21:24 |
| jamtoday | Well these use cases get tricky....and I haven't been given a lot of direction besides "make sure that we're ready for midterms" | 21:25 |
| ajaksu | if we have a way to know how student-survey-a goes with mentor-survey-a and student-survey-b goes with mentor-survey-b, we don't need two different models for midterms and finals | 21:25 |
| jamtoday | The project could still be used as a key, but then only be optional | 21:25 |
| jamtoday | The project key isn't actually a required property, so this is currently the case | 21:26 |
| ajaksu | but the project returns a student or mentor, now thay have many survey results there... which one relates to this result I have in hand (where I got the project info from)? | 21:26 |
| ajaksu | if you think about only having one survey of class midterm, one of class final and one of class pure-survey, it's all unambiguous | 21:27 |
| jamtoday | using the existing model, this could be done by filtering by a common survey | 21:27 |
| jamtoday | each SurveyRecord links back to a Survey | 21:28 |
| ajaksu | sure, but there's the detail that the mentor's SurveyRecord links to the mentor-survey-a, and the student's SurveyRecord links to student-survey-a | 21:28 |
| jamtoday | yes, and this is where we get to the one property that I think needs an immediate change | 21:29 |
| ajaksu | now you mention it, we could make it so each survey had a student-part and a mentor-part, problem solved | 21:29 |
| ajaksu | which property is that? | 21:29 |
| jamtoday | and that's the SURVEY_TAKING_ACCESS property | 21:29 |
| jamtoday | because "student" or "mentor" should be distinct from "student-midterm", "mentor-midterm", etc. | 21:30 |
| jamtoday | And this would solve the problem you describe | 21:30 |
| jamtoday | umm...let me think it through and make sure that's accurate, actually | 21:30 |
| jamtoday | Because a mentor can take more than one midterm | 21:31 |
| jamtoday | But not for the same project :) | 21:31 |
| jamtoday | The midterm/final distinction could be done by adding more fields to the SURVEY_TAKING_ACCESS property, or creating a new is_evaluation property | 21:31 |
| ajaksu | jamtoday: once you have more than one survey-kind entity per pair, things go back to starting point :) | 21:32 |
| ajaksu | (btw, did you see the other access kinds pawel wants? http://codereview.appspot.com/78043/diff/1/2#newcode116 ) | 21:32 |
| tpb | <http://ln-s.net/3MRE> (at codereview.appspot.com) | 21:32 |
| ajaksu | I like is_evaluation, and I think it could well be something we check on e.g. view and helpers to customize format and behavior | 21:33 |
| ajaksu | but imagine I run ghop and there are 5 self-evaluation surveys that are taken by me and my mentor, in pairs | 21:34 |
| ajaksu | do we want to add self-eval_1... self-eval5 to SURVEY_TAKING_ACCESS? | 21:34 |
| jamtoday | of course not....so I think the question is if we need the entity to contain what # survey it is | 21:35 |
| ajaksu | looks like we're adding stuff to the base class that belongs to its instances, in this case Survey or SurveyRecord entities | 21:35 |
| jamtoday | Because from the requirements, it seems like if the evaluation fails, there won't be another one | 21:35 |
| jamtoday | has_grades is a close approximation | 21:36 |
| jamtoday | SurveyRecord is an expando class, so it's easy to add a setattr() to those | 21:36 |
| jamtoday | looking into GRADE_OPTIONS | 21:37 |
| ajaksu | I think we could devise a property that encodes what kind of survey it is and works as an extension point | 21:38 |
| jamtoday | so combining SURVEY_TAKING_ACCESS and GRADE_OPTIONS and has_grades ? | 21:39 |
| ajaksu | something like it, but instead of all the behavior being set now, we'd make it extensible and maybe make the defaults match what midterms or non-evaluation needs | 21:40 |
| ajaksu | I added a new kind of choice question and was very impressed about how little it needed changing besides adding a new widget and form building method: the way you wrote _editPost made it neatly modularized from the start | 21:42 |
| ajaksu | that and using expando plus schema, very extensible and simple to work with | 21:42 |
| ajaksu | hello? :) | 21:46 |
| jamtoday | that was the goal, I'm glad it's working as intended | 21:47 |
| jamtoday | I'm looking at the models now | 21:47 |
| jamtoday | we could definitely get rid of has_grades | 21:47 |
| ajaksu | I don't think I wrote about this yet, but now choice questions have an 'options' textarea, one option per line... had to add something like this when I saw Leslie's example: https://spreadsheets.google.com/viewform?formkey=cjV0aVVtcGhtdEdhSnp5bTl6b2Fob1E6MA | 21:48 |
| tpb | <http://ln-s.net/3MRN> (at spreadsheets.google.com) | 21:48 |
| jamtoday | yes, very useful | 21:50 |
| jamtoday | for ranking something from 1-x | 21:51 |
| ajaksu | now, for midterms (and our merge that might be tomorrow IIUC), I'd like to have some sort of explicit link between surveys, as the kind of trouble (and ways to correct things) we can get from that seem much easier to deal with than those from unexpectedly having the project link not working as it should | 21:51 |
| jamtoday | That would be possible, but only after one survey is already taken | 21:52 |
| jamtoday | It could be done in a few lines, in a getCompanionSurvey method | 21:53 |
| jamtoday | I still can't think of any use cases where it would be necessary, but it can certainly be done | 21:53 |
| ajaksu | unless we link surveys (not surveyrecords), but then any issues with project links could happen here too... so how about project or Survey links for 'there will be a link', then a link between records we can edit? | 21:54 |
| ajaksu | we might use the same survey class for midterms, finals and regular surveys, that's a nice use case :) | 21:55 |
| jamtoday | oh, i see. linking surveys | 21:55 |
| jamtoday | So the midterm links to the final, or midterm 1 links to midterms 2, 3, 4... | 21:56 |
| jamtoday | And then a link between records we can edit.... | 21:57 |
| jamtoday | Looking at the past example, it makes me think it would be nice to facilitate multi-part questions | 21:57 |
| ajaksu | I was thinking of mentor-student links for midterms 1, 2, 3, 4, because each of these would be actually two surveys (student and mentor IIUC?) | 21:58 |
| jamtoday | this would need to be many to many....so we might want to make a new model for this | 21:58 |
| jamtoday | we could just do a db.ListProperty(db.Link) | 21:59 |
| jamtoday | But that's not a very descriptive sort of link. | 21:59 |
| jamtoday | er * db.ListProperty(db.Key) | 22:00 |
| ajaksu | a new model is what Lennie doesn't call the simple and ugly way, so I guess he likes the idea better than the explicit link :) | 22:00 |
| ajaksu | ah, no, he meant a new model that represents a pair of surveys, so it would be more useful than the many to many link | 22:01 |
| ajaksu | it would be a sure way to match the correct student survey to the mentor survey grading it :) | 22:01 |
| jamtoday | okay so this new model entity would be like SurveySequence, and there is a ReferenceProperty that links to it | 22:04 |
| jamtoday | And we do a reverse lookup from SurveySequence and then order -date to get the proper order of surveys | 22:05 |
| jamtoday | Is this what you had in mind? | 22:05 |
| ajaksu | no, what lennie had in mind (and I prefer the simple ugly way but mostly because it's simple) was a SurveyPair entity, linked to whatever can identify its two users | 22:07 |
| ajaksu | each entity would encapsulate a surveyrecords pair | 22:08 |
| jamtoday | uh oh...you just lost me | 22:08 |
| jamtoday | i mean, it makes sense | 22:08 |
| jamtoday | but I thought we were talking about linking surveys, not survey records | 22:08 |
| jamtoday | Because linking survey records is as easy as doing a lookup for a common project | 22:08 |
| ajaksu | guess so :) | 22:09 |
| ajaksu | so, basically student x has 5 survey pairs and we want to get his mentor's surveyrecord for survey_pair_3 :) | 22:10 |
| ajaksu | or, IOW, the corresponding mentor records for student record y :) | 22:11 |
| jamtoday | Common project, common survey | 22:11 |
| jamtoday | er... | 22:11 |
| jamtoday | not common survey | 22:11 |
| jamtoday | The only way to do this without an explicit link would be to do some hackish stuff with indexes | 22:12 |
| jamtoday | okay...i'll add a surveypair properyt | 22:12 |
| ajaksu | right, not common survey, so we have 4 student records and 4 mentor records that link to the same project, we want a clear way to pair them correctlu | 22:12 |
| ajaksu | *correctly :) | 22:12 |
| jamtoday | Uh oh...this gets even more troublesome. Let's say we have a student taking a final, and the student and mentor have already taken the midterm. When we're looking for a SurveyPair, we see the last mentor survey, linked to the last SurveyPair. | 22:14 |
| jamtoday | So when you're looking for a survey pair, you're looking for the most recent complimentary survey without an existing SurveyPair.... | 22:14 |
| ajaksu | hm, a SurveyPair might benefit from previously defined survey links, so we can filter them on survey and see if the records are there, or on records by user so we can get the other half of the pair | 22:16 |
| ajaksu | I'll work on a view that shows 1:1 pairings of student-mentor surveyrecords, so I might get a better understanding of this issue :) | 22:18 |
| jamtoday | ajaksu: but the problem is that student-midterm-3 needs to know not to pair up with mentor-midterm-2 | 22:19 |
| jamtoday | so that's why I suggest a survey should only link to a "single" survey | 22:20 |
| ajaksu | right, that makes sense, should it be per-survey property holding a link? i think that plus project gives us the necessary resolution, as does a record pair entity plus single survey link | 22:22 |
| jamtoday | IIUC the options are either a property, or a new compound model | 22:24 |
| ajaksu | in both cases we'd have 1:1 survey links and 1:1 record links, right? | 22:24 |
| jamtoday | yes | 22:24 |
| ajaksu | the property (being a per survey link) needs a second dimension to match records, which project can offer successfuly | 22:25 |
| jamtoday | yes | 22:26 |
| jamtoday | I'm ready to get cracking on this, I want to make sure we're on the same page | 22:26 |
| ajaksu | well, that's kinda what I wanted from the start, so I think we're on the same page and verse :) | 22:26 |
| jamtoday | there's going to two new models, one called SurveySequence and one called SurveyPair | 22:26 |
| jamtoday | er SurveyRecordPair | 22:27 |
| ajaksu | wait, we're not in the same verse, then :) | 22:27 |
| ajaksu | I thought we would get a property or a new model, not both... but I can only see benefits from having the link recorded in more places, so go for it :) | 22:28 |
| jamtoday | We actually don't need the SurveySequence model. | 22:31 |
| jamtoday | Just SurveyRecordPair | 22:31 |
| ajaksu | sounds perfect :) | 22:32 |
| jamtoday | Okay I'll get on that | 22:34 |
| jamtoday | it looks like we have notifications working as well? | 22:35 |
| jamtoday | btw SurveyRecordPair would make additional_mentors support (in the issue tracker) much easier | 22:35 |
| jamtoday | because from what I hear the 1:1 matching doesn't always pan out in real life | 22:35 |
| ajaksu | notifications are not working, just a POC that eventually gets to send emails when users haven't taken a given survey :) | 22:36 |
| jamtoday | I did want to resolve a decision about SURVEY_TAKING_ACCESS, I think that just 'student' and 'mentor' is confusing, because it could either mean midterm or non-midterm | 22:36 |
| jamtoday | Okay, I'll add that to the tracker | 22:37 |
| ajaksu | yeah, 1:1 is a dream that leads us down dangerous roads :) | 22:37 |
| jamtoday | I'm also going to finish the mentor-side of taking surveys, so that when you have already taken a survey and want to edit it, it will retrieve the correct survey | 22:38 |
| jamtoday | (more difficult for mentors, since they can take more than one evaluation at a time) | 22:38 |
| ajaksu | as pawel pointed out in the review, you might also want students-with-active-projects (does that exclude failed ones?) | 22:38 |
| jamtoday | the default behavior should be that you need an active project | 22:39 |
| jamtoday | and in the logic, that's a filter | 22:39 |
| jamtoday | But we could do one for 'failed students', for example | 22:39 |
| jamtoday | The most important change is just to distinguish between midterms and non-midterm surveys | 22:40 |
| ajaksu | yes, sounds trickier for mentor, is the ui redundant (as in 'make sure absent minded mentors know project x means student y') ? | 22:40 |
| jamtoday | I'm going to generate a link to the project page that includes all that info | 22:41 |
| ajaksu | are 'failed-student' and 'still passing student' things we can tell from looking at the project? | 22:41 |
| jamtoday | it could also be generated inline, but keeping it simple to start | 22:41 |
| ajaksu | good, let's keep things simple :) | 22:41 |
| jamtoday | from student_project.py: status = db.StringProperty(required=True, default='accepted', | 22:42 |
| jamtoday | choices=['accepted', 'mid_term_passed', 'mid_term_failed', | 22:42 |
| jamtoday | 'final_failed', 'passed']) | 22:42 |
| jamtoday | argh..pick_multi state still nwfm | 22:43 |
| ajaksu | cool, that makes all pawel's wishes easy to get :) | 22:44 |
| jamtoday | but the code looks right | 22:44 |
| ajaksu | and it wfm, what can it be? | 22:44 |
| ajaksu | does it fail local and in the staging instance? | 22:44 |
| ajaksu | ah, does it show in your survey record? | 22:46 |
| ajaksu | brb :) | 22:48 |
| jamtoday | actually, after pulling your latest changes I get a JS editable() failure | 22:51 |
| jamtoday | for both taking and editing | 22:53 |
| jamtoday | wfu? | 22:53 |
| ajaksu | I must've mucked it in the git commit, as I only tested the changes on hg... let me see if actually I did the move in hg and what I did in git | 22:54 |
| jamtoday | okay ill be back in a little bit....just wrote out my tasks for tonight and saved log of this convo to jog my memory... | 22:55 |
| ajaksu | ok :) | 22:56 |
| ajaksu | hehe, I got so worried about doing the moves correctly in git that I got them right, but forgot to merge the template changes :D | 22:57 |
| ajaksu | pushed, sorry for the mess | 23:01 |
| ajaksu | I'll be away for a snack, brb | 23:02 |
| jamtoday | no problem | 23:02 |
| jamtoday | I'm still getting a "missing ) after argument list" for taking surveys | 23:04 |
| jamtoday | nice job on the radio buttons | 23:05 |
| jamtoday | i think that last error was my fault...fixed now | 23:09 |
| * jamtoday is trying to figure out how to intelligently add a GET arg using window.location... | 23:16 | |
| ajaksu | back, I used jquery to add a get arg (with load, but there should be something similar for redirects?) | 23:17 |
| ajaksu | jamtoday: checked the taking page just to make sure and found no error either. I still have no idea about pick_multi not working :/ | 23:22 |
| *** mithro has quit IRC | 23:58 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!