IRC log of #schooltool for Tuesday, 2006-03-28

*** jinty has quit IRC00:13
*** tiredbones has quit IRC00:13
*** jinty has joined #schooltool00:14
*** jinty has quit IRC00:32
*** jinty has joined #schooltool00:33
*** tiredbones has joined #schooltool00:46
*** tiredbones has quit IRC01:05
*** tiredbones has joined #schooltool01:05
*** jinty has quit IRC02:15
*** jinty has joined #schooltool02:16
*** jinty has quit IRC02:55
*** jinty has joined #schooltool02:57
*** jinty has quit IRC04:28
*** jinty has joined #schooltool04:29
*** jinty has quit IRC04:57
*** jinty has joined #schooltool04:58
*** vmx__ has joined #schooltool05:57
*** vmx_ has quit IRC05:57
*** vmx_ has joined #schooltool07:18
*** vmx__ has quit IRC07:20
*** vmx_ is now known as vmx09:33
*** jinty has quit IRC10:43
*** jinty has joined #schooltool10:44
*** jinty has quit IRC11:14
*** jinty has joined #schooltool11:15
*** jinty has quit IRC11:38
*** jinty has joined #schooltool11:42
*** jinty has quit IRC12:02
*** jinty has joined #schooltool12:18
*** alga has joined #SchoolTool12:20
*** Aiste has quit IRC12:23
vmxcan a run a specific unittest instead of all tests? (atm i use "make test")12:31
*** mgedmin has joined #schooltool12:39
*** mgedmin changes topic to "SchoolTool development | IRC logs at | Dev meetings Tue, 14:30 UTC (17:30 EEST)| CanDo dev meetings Tue, 4pm EST"12:42
*** ignas has joined #schooltool12:45
*** Aiste has joined #schooltool12:55
*** thisfred has joined #schooltool13:05
*** faassen has joined #schooltool13:06
*** jinty has quit IRC13:52
*** jinty has joined #schooltool13:55
*** jinty has quit IRC14:16
*** ignas has quit IRC14:23
*** ignas has joined #schooltool14:27
*** povbot` has joined #schooltool15:20
*** faassen has quit IRC15:24
*** Aiste has quit IRC15:26
*** mgedmin has quit IRC15:26
*** jinty has joined #schooltool15:33
*** povbot has quit IRC15:34
*** vmx_ has joined #schooltool15:37
*** vmx has quit IRC15:39
*** jinty has quit IRC15:56
*** Aiste has joined #schooltool16:06
*** jinty has joined #schooltool16:07
*** tiredbones has quit IRC16:20
*** tiredbones has joined #schooltool16:20
*** Aiste_ has joined #schooltool16:37
*** Aiste has quit IRC16:38
*** Aiste_ has quit IRC17:05
*** vmx__ has joined #schooltool17:22
*** vmx_ has quit IRC17:23
*** ignas has quit IRC17:25
*** Aiste has joined #schooltool17:28
*** mgedmin has joined #schooltool17:28
* th1a yawns.17:30
*** ignas has joined #schooltool17:31
th1aIs it 17:30 in Vilnius?17:31
ignashi :)17:31
th1aHi ignas.17:31
th1aEveryone ready to go here?17:32
ignaswhom are you pinging ?17:34
ignasping -t :)17:34
ignasping -b  i mean17:34
th1aWell, it is time to start the meeting, right?17:34
th1asrichter?  Let's see... no faassen.17:35
algaUnfortunately I'll have to leave soon17:35
algablame the DST TZ shift17:35
srichterI am here17:35
th1aOK.  This probably won't take long.17:35
th1aWhat's POV's status?  Ready to work on SchoolTool soon?17:36
algastarting next week at best17:36
algaour deadline is still looming this Friday17:36
th1aAh.  I thought it was last Friday.17:36
th1aDid everyone read the big update I wrote last week.17:37
ignasth1a, still reading :/17:37
srichterth1a: yeah, though for me nothing was really any news, but I am very happy about the direction17:38
srichterit was the right move17:38
th1aI'm not happy about moving more slowly.  We just have to not move TOO slowly.17:38
srichteryeah, I agree we need to pick up speed17:39
th1aSo one implication for POV in particular is that the first testers of attendance will be St. Ives.17:40
srichterI was more referring to using next year as a bets year and not risking full installations17:40
th1asrichter:  Well, we're at a dead stop at the moment, so I agree.17:40
tiredbonessrichter, what direction do you see?17:40
th1asrichter:  beta not bets?17:40
ignasth1a, a question - what will happen to school*bell* in ubuntu/Debian ?17:41
th1aSo after this iteration of attendance I'll have to get Miles from St. Ives talking directly to POV about what needs to be finished for his school.17:41
srichtertiredbones: I see no directions, this is Tom's job :-) I just enjoy working on what Tom tells me is important to work on. He he.17:41
tiredboneshe he17:41
srichterth1a: btw, I did some work on SchoolTool last Monday and a little bit on Tuesday17:42
th1aignas:  Well, we'll have to implement the grand plan to derive SchoolBell from the SchoolTool source tree sometime between now and Breezy+1.17:42
srichterthe quick progress I made with the UI indicates that the API is good17:42
ignasth1a, as many users are comming and asking for various fixes/directions while not really being aware that we are not going to do anything with SB for some time ...17:42
mgedminth1a: breezy + 1 == dapper17:42
mgedminI assume you meant dapper + 117:42
*** alga has quit IRC17:43
th1aWell, we've all learned something about the open source development process, I guess.17:44
th1aWe (Mark, Steve, me...) were all too optimistic about people coming along with their own SchoolBell fixes.17:44
th1aAlthough, realistically, you probably always get about 1 patch for every 25 complaints and requests, at best.17:45
tiredbonesth1a, I think it's because of zope tech that slowed it down.17:45
th1aMaybe 1 per 100.17:45
ignasbut they are very good with coming up with feature requests and bug reports :D17:45
th1atiredbones:  That's true, I'm afraid.17:45
ignasin triplicates most of the time17:45
srichterI just think that the crowd that SchoolBell is attracting is not the development crowd17:47
th1aignas:  Try not to let the SchoolBell situation get you down.17:47
th1asrichter:  That is true as well.17:47
srichterspecifically since SchoolBell does not integrate into CMF, Plone, CPS, Silva or whatnot17:47
ignasth1a, it is not leting me down, i just want to know - what should i say to someone who is requesting a fix that is not going to happen for 6 months17:47
ignasth1a, as i don't want to ignore users, that's all17:47
srichterignas: tell them that; it's open source; they always have the option to pay you fix it17:48
th1aAs we discussed last week, we couldn't make the moves we needed to with licensing, etc., to move into the center of the Python/Zope calendaring world.17:48
srichterin fact that would be my answer as a business man :-)17:48
th1aWe just have to be honest about the fact that we're working on different things.17:49
srichterI agree17:49
th1aI mean, so many open source projects are completely abandoned.  We're still around, so that's something.17:49
srichteryes, and we are producing something usable for at least 4-5 schools17:50
tiredbonesth1a, tom seems very down.17:50
srichterplus all the other ones that are already using SchoolBell for smaller projects17:50
srichterI think in September we will really see the benefits of the current work17:51
th1atiredbones:  One thing about meeting online is that you can get out of bed 15 minutes before the meeting starts.  But it is hard to be chipper when you do that.17:51
ignasth1a, is the "we will not work directly on schoolbell until dapper+1" fact written somewhere, os i could give the link to people who are asking about SB?17:51
srichteronce people are using our stuff and we can turn around and create very customized reports using templates, adjust features as needed, it will be a joy to support users17:51
*** vmx__ is now known as vmx17:51
th1asrichter:  Yes.  Few people have seen the past six months' work.17:51
srichteralso, SchoolTool is much more in our core focus, so support will come more natural17:52
th1aignas:  I'm working on the website this week, so I'll make sure that's as clear as possible.17:52
th1aOTOH, I don't want people to stop trying it out and reporting bugs, so I'm not sure what the result would be.17:53
vmxif schoolbell will be derived from schooltool, this information should be added too. so that the people know that it could be developed further, and it is not completely on hold17:53
tiredbonestech will not win out over a deliverable.17:53
th1aOK.  I don't want to get too rambly here.17:54
tiredbonesI thought the whole point of XP was get something before your customer.17:54
th1atiredbones:  Yes.17:55
th1aActually, though, we are going to end up working more on the calendaring within SchoolTool in the next six months than I had been thinking.17:55
th1aOne thing that has changed a bit is that two of the schools (HTH and SLA) place a high priority on students and parents viewing their homework, etc., through the web.17:56
th1aSo for POV, between now and September, the focus will be:17:57
th1a* getting attendance ready for St. Ives.17:57
th1a* cleaning up calendaring for the above mentioned use17:58
th1a* probably some work on reports.17:58
ignasattendance is connected to calendaring too, as "attendance events" and timetabling are really closely related to calendaring, so yes i think we will have to do it properly sooner or later17:59
th1aWe'll probably need to work on the weekly calendar view and the printed calendars to make them more polished.17:59
tiredbonesth1a, can that list be further broken down?17:59
th1atiredbones:  Presumably.  I just made it up though.18:00
th1aThat was more thinking out loud than revealing the next chapter in the master plan.18:00
srichterwhat would be the resources required to have a simple calendar/event API that we can hook into18:01
*** jinty has quit IRC18:01
srichterI need to create events eventually too, but honestly I am very afraid of the code18:01
ignassrichter, can you elaborate on that ?18:01
th1aAlso, then, as next school year goes on, we'll start testing attendance in more schools, so there will be ongoing work and refinement through the year.18:01
srichterbasically I just want to say:18:01
srichter>>>> ev = Event(...)18:02
srichter>>> cal.addEvent(ev)18:02
srichtermaybe before that:18:02
srichter>>> cal = ICalendar(ISchoolToolApplication(None))18:02
srichterI really do not want to have to worry about more18:02
srichteris that possible?18:03
ignassrichter, you should try that :) i think it works that way18:03
mgedminsrichter: yes18:03
mgedminthat's exactly what you do18:03
mgedminwell, the Event class is named differently, IIRC18:03
srichteris that documented somewhere like that?18:03
srichtermgedmin: ok, I don't care about that bit. :-)18:03
ignasbut i am afraid that you will have to provide the right datetime in UTC which is causing some problems at the moment18:03
srichterok, no problem either18:03
mgedminsrichter: look at src/schooltool/app/booking.txt18:04
srichteras long as there is a document on how to add an event without knowing the entire package, then I am totally happy18:04
th1aI've assigned ignas the task of writing some more timezone-related documentation.18:04
srichterok, will do18:04
srichterth1a: cool, that's great as well18:04
th1aSo basically, at this point the calendar API doesn't handle the timezone correction itself, but whatever component is adding the even has to do it?18:05
ignasyou have to deal with this only when you are converting user entered dates to datetime18:05
mgedminth1a: the calendar API has an artificial constraint requiring all datetimes to be in UTC18:05
mgedminso you have to do that18:05
srichterI think this constraint is not as bad as you make it sound18:06
mgedminI didn't imply it was bad18:07
ignasif you are creating an abstract event on datetime.datetime.utcnow() - you only have to localize it to UTC18:07
srichterit is the same type of constraint as saying: all human-readable text must be unicode18:07
mgedminI just wanted to say things would continue to work if it were removed18:07
mgedmin(unless there's something unexpected that I missed)18:07
ignassrichter, you haven't seen the event grid on 04-02 (thew time you turn clocks) probably18:07
mgedmin(where by 'it' I meant the constraint)18:07
mgedminyeah, DST transitions make hourly grids interesting18:08
ignasas well as recurring events18:08
ignasthey start jumping18:08
mgedminno they do not18:08
mgedminthat's the whole problem18:08
ignasyes they do :)18:08
mgedminUTC does not have daylight savings18:08
ignasoh :) they look like they do jump to our users18:09
mgedminso if you want 10 o'clock in your local time18:09
mgedminwhen your local time jumps around18:09
mgedminyou're not going to get it18:09
mgedminwhile we enforce storage in UTC18:09
mgedminanyway, the back-end is solid18:10
srichterI think this is good; the view code or some adapter should handle the conversion18:10
mgedmin(unless you start thinking about all-day events interacting with various timezones)18:10
srichterfor example, when America/New_york switches times, we go from EST to EDT18:10
vmxjust a notice: at the moment i try to get allday events right. perhaps not the nicest solution (i've chatted with ignas and th1a about it), but a working one. i hope it'll be ready soon18:12
th1avmx:  We were bemoaning the lack of user contributions earlier, but we need to give you some credit.18:13
* srichter notes that vmx is the first outside School* hacker :-)18:13
th1aPretty much.  Except me.18:13
th1aAnd pcardune.18:13
th1aI guess there have been a few.18:13
th1aOK.  Any other roadmap related questions?18:16
th1aI guess we can wrap up then.18:18
th1aHave a good week, folks.18:18
* th1a bangs the virtual gavel.18:18
srichteryou too18:18
vmxif the meeting is over. i've a question. there's a comment in the source:18:21
vmx# XXX utc here is a bug, probably
vmxbut why wasn't it changed if it is a bug?18:21
*** Aiste has quit IRC18:22
mgedminvmx: where in the source?18:22
vmxapprox: line 75018:23
vmxi also think that start_dt = datetime.combine(start, time(tzinfo=utc)) is wrong, but why wasn't it changed to datetime.combine(start, time(tzinfo=self.timezone))18:24
vmxi'm on the way on making some tests, just need to find some nice timezones to test with, first18:24
mgedminyes, that bit should not use UTC18:25
*** jinty has joined #schooltool18:25
mgedminit wasn't changed because we did not have the time to do it yet18:26
mgedmindo it properly18:26
*** th1a has quit IRC18:26
mgedmin(write the test etc)18:26
vmxah ok18:26
mgedminugh, getEvents uses dt.replace(tzinfo=self.timezone18:26
mgedminanother bug18:26
mgedminnever ever use datetimeobj.replace(tzinfo=somethingelse)18:26
mgedminit will not work properly18:27
*** th1a has joined #schooltool18:27
ignaswith pytz18:27
*** Aiste has joined #schooltool18:28
ignasdate-util timezones will handle the "replace" semi properly, not 100% properly but like 99.967447916666671 % properly18:28
vmx".replace()" is used quite often18:28
ignasbut as we are using pytz18:29
ignasreplace is never a good way to apply a timezone18:29
ignasyou should use tzinfo.localize(dt)18:30
vmxi see "astimezone" very often in the source. what about that one?18:31
mgedminit's good18:31
mgedminthe semantics is different18:31
mgedminyou use astimezone to convert, e.g. 14:30 UTC to 17:30 EEST18:31
mgedminyou use tz.localize to convert 14:30 "naive time" to 14:30 EEST18:32
mgedmindt.replace() and datetime.combine() should raise a red flag18:32
mgedminit is very easy to use them incorrectly18:32
ignasdt.replace() shoud be avoided when doing date arithmetic too18:33
vmxi use datetime.combine() for alldayevents, but perhpas tz.localize could be used18:33
ignasvmx, depends on why, where and how ...18:34
vmxalthough astimezone and all the others are used to often. there's an event.dtstarttz. that's (almost) all you need18:34
*** faassen has joined #schooltool18:34
faassenargh, sorry, I only remembered just now that the meeting was an hour ago. :(18:35
vmxignas: we talked about the best way to handle all-day-events. i had again another idea18:36
ignasyes, i am listening18:36
ignasthough, mgedimn advised just using timezoned datetime objects as arguments to the expand function18:37
vmxwhat about storing only the date in the database, and EventForDisplay sets dtstart of the event to 0:00 local time18:38
vmxthat would be (almost) all18:38
ignasvmx, we must store only date, and why do we need dtstart 0:00 for allday events at all ?18:38
ignasdtstart with the time is there only for hysterical reasons :/18:38
*** pcardune has joined #schooltool18:39
vmxsorry i ment you should set dtstarttz to 0:00 local time18:40
vmxignas: yes but atm you can read very often things like "" you just need to replace it with:18:40 at it'll work18:40
vmxyou won't need to make a difference between alldayevents and normal one18:40
*** pcardune has quit IRC18:40 should be
vmxi think it is ok to have no real difference between alldayevents and other ones if EventForDisplay was called18:42
ignasvmx, if i would not care about the interface for calendaring, i would do that, but we must keep the interface clean, what is the purpose of a datetime with 00:00 local time in an attribute for an allday event ?18:42
ignasEventForDisplay should be designed to cope with allday events not the other way around ...18:42
*** pcardune has joined #schooltool18:42
pcardunedoes anyone know if the server is down?  I can't access the site18:43
ignasall day and normal events should provide a sane interface that enables implementing User interface, but should not be designed to work around incorrect behaviour of UI classes18:43
ignasthat's why some minor bugs are taking more time to fix, we are trying to keep the whole thing maintainable and sane18:44
jintypcardune: doesn't look like it from here18:44
jintypcardune: but I am soon going to restart it.18:45
vmxignas: then one would intruduce a new attribute and it will be fine? EventForDisplay cope with alldayevents. if you call it with an allday-event it will get a date and not a datetime. you will the convert it to datetime for much easier handling (and get event.dtstartz)18:46
pcardunejinty: ok18:46
vmxyou will get much cleaner code this way18:46
vmxelse you would always have problems with date vs. datetime18:47
ignasvmx, sorry, i can't visualize the change you have just proposed18:47
ignasintroduce new attribute to what ?18:47
vmxok :)18:47
vmxi'll start how i understood what you said18:48
vmxevent.dtstart is wrong for alldayevents (as it is only a date and not a datetime)18:48
vmxi propose that dtstart is "abused" also for alldayevent dates18:49
vmxas you don't like it, one could also introduce a new attribute18:50
vmxwhich could then be named event.datestart. alldayevents would then have an empty dtstart, but a datestart18:50
jintypcardune: should be back up18:51
vmxand i said that it doesn't make much sense introducing a new attribute, only because the name is wrong18:51
jintypcardune: btw, whats up with the cando list at
jintypcardune: are you guys ever going to use it?18:52
ignasvmx, i am not proposing just plainly adding an attribute, this is not how interfaces are being *designed*18:55
pcardunejinty: we were going to use it, and I did use it a few times, but people seemed to despise the idea of having a mailing list, and nobody else ever used it18:55
ignasand IMHO your last sentence is completely 100% wrong18:56
ignasvariables have names for a reason18:56
pcardunejinty: But I would still like to use it, and we will definitely need it in the future, so if it's not too much trouble to leave it around, I would appreciate that18:56
vmxok, you're right18:56
ignasif there is a better name for a variable - you go and change all the instances of it, not put array of carrots into the variable named tuple_of_potatoes18:57
jintypcardune: sure it's not a problem to leave it around, I only ask because there was only one post in the archives18:57
vmxignas: ok you're really right. else the code will get very messy soon18:57
pcardunejinty: ok, thanks.18:57
vmxignas: so a better name for dtstart would be start18:58
vmxas it was designed probalby no one thought about events without a time18:59
mgedmingot it in one18:59
vmxof course start will ne UTC19:00
vmxwhat about an variable called "dtstartz". that would be the start but expanded to datetime if it isn't already19:00
ignasvmx, actually, i'd split EventFor Display into 2 different classes, one for allday events and another for normal events, and modify the UI code accordingly19:00
vmxor isn't it ok to have a "pseudo" time suddenly?19:00
mgedminwhy do we need a datetime for displaying all-day events?19:00
mgedminis it used anywhere?19:01
vmxmgedmin: atm it is used as the same code for all events is used19:01
ignasvmx, yes, that is my point - it is not ok to have a "pseudo" time19:01
ignassomeone will use it as if it was normal time sooner or later ...19:02
vmxignas: but it will be duplicated code19:02
ignasbase classes are for such things as elimination of duplicate code, not "pseudo" time19:04
vmxor if's, what is even more ugly ;)19:05
ignasyou put ifs first, then you see a pattern19:06
ignasthen you refactor it19:06
vmxi just see the comment "We have date objects, but ICalendar.expand needs datetime objects" in the code19:06
vmxi think that's is the main problem, but that could be changed19:07
vmxas _getDays() doesn't really need datetime19:07
vmxi'll just take a look at the source again :)19:07
vmxa try to change it from scratch again19:08
* jinty prays that when schooltool implements database packing that there is some kind of robust command line tool for this (In addition to a fancy TTW way)19:09
vmxi've a question about the database behind everything. i haven't found the functions where the events really get stored and read out. where are they?19:10
ignasit's all ZODB magic19:10
ignasevents inherit from Persistent19:10
ignasand are geting stored automagically when you add them to a calendar19:10
ignaswhile calendars get stored when you add them to persons/groups etc.19:11
vmxwhere would i e.g. define that event.start is sometimes date and the other times datetime?19:11
ignasyou don't have to19:11
vmxso i have to have the right object time when the event gets added?19:14
ignasyou can store bananas in there, ZODB handles everything19:15
ignasadding attributes is a bit different, you have to write evolution scripts that add these attributes to old instances19:16
ignasrenaming attributes needs evolution scripts too19:16
ignasbut if you will write a working patch that will pas mgedmin's code review process - we will write these ourselves19:16
vmxok, that's a deal :)19:18
vmxi still don't understand how event.start will be date on alldayevents and datetime on normal ones?19:19
th1ajinty:  How much did the database pack?19:19
jinty400MB -> 90 MB19:20
jintybut that was still worse than th log file, which was at 800MB before i started rotating it;)19:20
ignasvmx, i'd probably split the class, and try to make sure no one ever gets allday events and simple events together unless he is using only their common interface ...19:21
ignasbut i don't really have the time to design anything, or work on it at the moment19:22
vmxignas: just to be sure i've understood everything. will there be 2 interfaces like ICalendarEvent and ICalnedarAllDayEvent? or 2 different implemnetations of the event interface? or something different?19:28
ignasI don't know now, sorry, when it comes to core classes i like discussing posible solutions wiht mgedmin or alga for some time on the whiteboard, before settling with one of the ideas, because there are a lot of variables to consider ...19:32
ignasthe elegance of the solution, the elegance of the resulting implementation, evolution scripts etc.19:32
ignasand most of the time they have good ideas, or spot various shorcomings in my ideas ...19:33
ignasvmx, i'd just say - use your judgement, and do your best ...19:34
vmxok. so there isn't really anything i can do atm? so i'll probably start to hack the look of the weekview a bit19:34
ignasif you will do a good job, we will apply the patch19:34
vmxi think i haven't enough background information to do it19:34
vmxand i'm not a good enough in oop19:35
ignasoh, by the way - even a less than perfect patch will be usefull, as we can gather only the usefull bits out of it ...19:35
vmxi could also write some tests, as i know some of the problems19:36
ignasvmx, i'd recomend to fix that19:36
ignasvmx, that would be nice too, a bug report with a failing test case is 100 times better than just a bug report19:36
vmxit'll get better soon as next term i'll have a course about software engeneering :)19:38
vmxthanks for the book recommandation19:38
vmxas the calendar development is on hold i assume there won't be much discussions about it19:41
ignasprobably, unless i'll decide to fix some stuff on weekends (1 in 10 chance of that happening :/)19:42
vmxnp, i can understand that. if there are different priorities, one can't do much about it19:43
vmxok, i g2g. it was a nice chat, thanks for the time19:50
*** Aiste has quit IRC19:51
*** jinty has quit IRC20:35
*** jinty has joined #schooltool20:38
*** faassen has quit IRC20:57
*** thisfred has quit IRC21:20
*** jinty has quit IRC21:52
*** ignas has quit IRC22:15
*** mgedmin has quit IRC23:10
*** flint has joined #schooltool23:57
flintgood afternoon paul...23:57
pcardunehi flint23:59

Generated by 2.15.1 by Marius Gedminas - find it at!