| *** bskahan has quit IRC | 00:06 | |
| *** gintas has quit IRC | 00:24 | |
| *** jonesieboy has joined #schooltool | 00:37 | |
| *** bskahan has joined #schooltool | 00:46 | |
| *** jonesieboy has quit IRC | 01:06 | |
| povbot | /svn/commits: * jinty committed revision 4671: | 01:55 |
|---|---|---|
| povbot | /svn/commits: merge 4655:4670 from debian-packaging branch. | 01:55 |
| *** SteveA has quit IRC | 03:36 | |
| *** SteveA has joined #schooltool | 03:38 | |
| *** jinty has left #schooltool | 03:56 | |
| povbot | /svn/commits: * jinty committed revision 4672: | 04:04 |
| povbot | /svn/commits: Some packaging changes from testing with the rc3 tarballs. Seems to work. | 04:04 |
| povbot | /svn/commits: * jinty committed revision 4673: | 04:06 |
| povbot | /svn/commits: Whoops! This is a good candidate for porting to the RC. | 04:06 |
| povbot | /svn/commits: * jinty committed revision 4674: | 04:07 |
| povbot | /svn/commits: Whoops! This is also a good candidate for porting to the RC. | 04:07 |
| *** pcardune has joined #schooltool | 04:42 | |
| pcardune | anyone there? | 04:44 |
| bskahan | hi paul | 04:47 |
| pcardune | any idea on how i set up mechtest using the zope testing branch? | 04:48 |
| pcardune | like, how do i checkout the branch? | 04:49 |
| bskahan | sorry, I haven't used mechtest yet | 04:52 |
| bskahan | the module is called testbrowser now | 04:52 |
| pcardune | oh, isee | 04:52 |
| srichter | pcardune: testbrowser is part of ST/SB now | 05:19 |
| srichter | see my schooltool.level tests | 05:19 |
| pcardune | awesome, i'll take a look | 05:20 |
| *** bskahan has quit IRC | 05:41 | |
| *** tvon has quit IRC | 06:38 | |
| pcardune | it took me a long time to install everything (i'm on a mac and had to upgrade my python), but *wow* this is looking incredible | 06:40 |
| *** tvon has joined #schooltool | 07:04 | |
| *** srichter has quit IRC | 08:25 | |
| *** auxesis_ has joined #schooltool | 09:28 | |
| *** auxesis has quit IRC | 09:29 | |
| *** pcardune has quit IRC | 09:45 | |
| *** th1a has joined #schooltool | 10:38 | |
| *** Aiste has joined #schooltool | 10:47 | |
| *** mgedmin has joined #schooltool | 10:57 | |
| *** ignas has joined #schooltool | 11:05 | |
| *** gintas has joined #schooltool | 11:07 | |
| *** th1a has quit IRC | 11:15 | |
| *** thisfred has joined #schooltool | 11:26 | |
| *** th1a has joined #schooltool | 11:40 | |
| *** alga has joined #SchoolTool | 12:14 | |
| *** ignas has quit IRC | 12:55 | |
| *** th1a has quit IRC | 12:58 | |
| *** ignas has joined #schooltool | 12:59 | |
| *** th1a has joined #schooltool | 13:09 | |
| *** bskahan has joined #schooltool | 13:28 | |
| *** gintas has quit IRC | 13:48 | |
| * mgedmin is hungry | 14:29 | |
| *** jinty has joined #schooltool | 14:49 | |
| *** bskahan has quit IRC | 14:53 | |
| *** bskahan has joined #schooltool | 15:00 | |
| *** th1a has quit IRC | 15:33 | |
| *** ignas has quit IRC | 15:52 | |
| bskahan | is there a way to ftest for a page _not_ containing a particular string? | 16:57 |
| tvon | there are a few tests that do it | 17:23 |
| tvon | save the http output, then it's something like `'some string' not in result.getBody()` | 17:24 |
| tvon | or str(result) as someone did | 17:25 |
| *** th1a has joined #schooltool | 17:27 | |
| tvon | str(result) seems to be the norm | 17:27 |
| *** ignas has joined #schooltool | 17:27 | |
| *** srichter has joined #schooltool | 17:28 | |
| *** strichter has joined #schooltool | 17:28 | |
| mgedmin | str(result) gives you HTTP headers as well as the body | 17:28 |
| *** strichter has left #schooltool | 17:28 | |
| *** strichter has quit IRC | 17:28 | |
| tvon | ah | 17:28 |
| srichter | hi there | 17:28 |
| mgedmin | you can use either | 17:28 |
| mgedmin | hi, srichter | 17:28 |
| srichter | sorry I did not notice I was discuopnnected | 17:28 |
| mgedmin | I've a question for you | 17:28 |
| mgedmin | tom said you said something about portlets/pagelets in zope 3 being not a good implementation or some such | 17:29 |
| srichter | I actually said I was not sure and it looked complicated | 17:29 |
| srichter | but I looked at it the other day and I think it is not complex at all | 17:29 |
| srichter | just the demos are | 17:29 |
| mgedmin | ok | 17:30 |
| th1a | So we should use that unless we come up with a reason not to. | 17:30 |
| mgedmin | I guess all we need for schooltool are things that would let us do a tal:repeat="viewlet some_expression" tal:replace="structure view" | 17:30 |
| srichter | yeah | 17:31 |
| mgedmin | where some_expression is the equivalent of "give me all views that want to be put in a 'left sidebar' slot on IPerson objects" | 17:31 |
| srichter | right | 17:32 |
| srichter | btw, I dunno what you decided today in the meeting, but I could complete the ST refactorings | 17:34 |
| th1a | We need to finish the very rough draft proposal I wrote. | 17:35 |
| srichter | I think this would not be a bad idea anyways, since I then know the code better and documentation will be better too | 17:35 |
| th1a | But we essentially endorse your work :-) | 17:35 |
| srichter | I just read Marius' comments | 17:35 |
| mgedmin | we came up with a plan how to go ahead | 17:36 |
| mgedmin | sort of | 17:36 |
| srichter | can you briefly outline it? | 17:36 |
| mgedmin | first step was to apply all your refactorings to the trunk | 17:36 |
| mgedmin | well, maybe not all of them | 17:37 |
| srichter | ok | 17:37 |
| mgedmin | I'm not sure about import style refactorings, as you've probably noticed | 17:37 |
| srichter | yeah, but you told me you follow Zope 3 styles | 17:37 |
| srichter | we are slowly switching to that style as we work on packages | 17:37 |
| mgedmin | it might be that Zope 3 changed the style a bit, since we started following it | 17:37 |
| mgedmin | nowadays I see things like class Foo: zope.interface.implements(IBar) | 17:38 |
| srichter | I really like that style now; it is so much clearer | 17:38 |
| mgedmin | ok, which style is it -- the old Z3 style or the new Z3 style | 17:38 |
| mgedmin | ? | 17:38 |
| mgedmin | (the one that you like, I mean) | 17:38 |
| srichter | the new one | 17:38 |
| srichter | otherwise I would not have applied it to the refactorings ;-) | 17:38 |
| srichter | it's one of those cases where Jim hada vision and I noticed only much later how nice it is | 17:39 |
| tvon | Should a single 'ยป' in a span have i18n:translate ? | 17:47 |
| srichter | probably not | 17:47 |
| srichter | though you could imagine that for right-to-left languages it wnats to be "<<" | 17:48 |
| mgedmin | srichter, it appears that we (pov) might not be able to do much schooltool work before september 1 | 17:49 |
| mgedmin | we came up a list of things we thought is worth doing: | 17:49 |
| mgedmin | 1. merge your current refactorings | 17:49 |
| srichter | ok, and I am more free till that time | 17:50 |
| mgedmin | 2. merge schooltools & schoolbells skins | 17:50 |
| mgedmin | 3. split timetabling into a package so that you do not have to override calendaring views to hook up timetables to them | 17:50 |
| mgedmin | 4. split the implementation of person details into a pluggalbe package (store data in annotations, etc.) | 17:50 |
| mgedmin | 5. split notes into a package | 17:50 |
| mgedmin | 6. split courses & sections into a package | 17:51 |
| srichter | (I started 5 already) | 17:51 |
| mgedmin | 7. create a sample data generator (with subscribers that allow plugin packages contribute to the sample data) | 17:51 |
| mgedmin | 8. work on making the UI more pluggable (slots/pagelets/portlets/whatever) | 17:51 |
| mgedmin | 9. work on other things if there's time left | 17:51 |
| srichter | looks good | 17:52 |
| mgedmin | oops, forgot the most important one | 17:52 |
| mgedmin | N. work on database backwards compatibility | 17:52 |
| mgedmin | that's it | 17:52 |
| srichter | btw, do you guys agree with the directory structure I proposed? | 17:52 |
| mgedmin | but since we're busy now and you're free, and also since you've already started on something, and also since you probably have a more clear idea of what needs to be done | 17:52 |
| mgedmin | perhaps it would be better if you continued working in that branch | 17:53 |
| srichter | N.: I am the chpampion in this; after the CA work :-) | 17:53 |
| * mgedmin nods | 17:53 | |
| *** bskahan has quit IRC | 17:53 | |
| srichter | th1a: do you send me a proposed contract? | 17:54 |
| mgedmin | more aggressive directory structure refactorings, merge of schooltool/schoolbell top-level package namespaces, merge of svn branches are things that fall under step 9, I guess | 17:54 |
| mgedmin | we did not explicitly discuss them | 17:54 |
| th1a | OK. | 17:54 |
| srichter | mgedmin: did you have a chance to look at them? | 17:54 |
| mgedmin | I came up with one more risk for a complete ST/SB merge | 17:54 |
| srichter | mgedmin: did you have a chance to look at it? | 17:54 |
| mgedmin | functional tests: how do you make sure a person's view works correctly both when schooltool's extra packages are enabled in ZCML, and when they're disabled? | 17:55 |
| th1a | srichter: Sent. | 17:55 |
| srichter | th1a: thanks | 17:55 |
| mgedmin | srichter, I'd be happiest if we could merge items 1-8 on our list to trunk, and then try out your proposed aggressive refactorimergings in another branch | 17:56 |
| srichter | mgedmin: good point; I think I will come up with something when I go along; I do not have an answer out of the top of my head now | 17:56 |
| srichter | mgedmin: ok | 17:56 |
| srichter | I just want to merge with the trunk often, otherwise merging will become hell | 17:57 |
| srichter | how is going to do the pagelet conversion? Do you want me to work on it too; this way I could check out Roger's work and make suggestions for improvements | 17:59 |
| srichter | I am pretty sure he will value my input and agree to most changes I would propose | 17:59 |
| srichter | ok, Brian does the pagelet stuff; great | 18:00 |
| th1a | Hm? | 18:00 |
| srichter | I just read your document :-) | 18:00 |
| srichter | NEVERMIND! :-) | 18:01 |
| srichter | I misread | 18:01 |
| srichter | th1a: how do you want to work on this document? Do you want me to fill in some details and timeestiamtes and send it back to you or do you want to work on it? | 18:02 |
| th1a | Well, I'd like to get some details/comments back from you. | 18:03 |
| srichter | ok, so I'll work on the document | 18:03 |
| mgedmin | srichter, merges: yeah, good point. Although trunk will be mostly unchanged before September, I think. OTOH I'd like to review changes before committing them to the trunk. | 18:05 |
| mgedmin | I'll try to schedule some time during next two weeks for the review and maybe some merging | 18:05 |
| srichter | ok | 18:06 |
| mgedmin | I'm happy with you using pagelets | 18:06 |
| srichter | I'll start a new refactoring style as well | 18:06 |
| mgedmin | I think that will be a requirement when you split, e.g., person details into a subpackage | 18:06 |
| srichter | since the goals shift | 18:06 |
| srichter | this way incremental checkins will be easier | 18:06 |
| * mgedmin loves incremental checkins | 18:06 | |
| srichter | me too | 18:07 |
| srichter | but I worked differently on the branch; I basically deleted a code duplication and fixed the broken code | 18:07 |
| mgedmin | the checkins were pretty incremental | 18:08 |
| mgedmin | except maybe the 77KB ITimetabled refactoring | 18:08 |
| srichter | yeah, but not as much as they could have been, as you pointed out in your response (I agreed with that criticism; could have been mine ;-) | 18:08 |
| srichter | th1a: ok, I'll spend today working on the proposal; will you be here tomorrow give your okay? | 18:09 |
| srichter | or can I just keep going under the assumption it is okay? :-) | 18:10 |
| * srichter is in a really good mood today for some reason | 18:10 | |
| th1a | I will be here. | 18:10 |
| srichter | cool | 18:10 |
| th1a | Well, right now it is a proposal to pay POV for some work. | 18:10 |
| th1a | So your relationship to the proposal is a bit ambguous. | 18:11 |
| srichter | I see | 18:11 |
| srichter | I'll still fill it out | 18:11 |
| th1a | Although having you do the work for free and giving them something else to do is fine with me. | 18:11 |
| th1a | This paid/open source thing can get confusing. | 18:12 |
| th1a | If not self-defeating. | 18:12 |
| * mgedmin wishes he could just work and not worry about payments and stuff... | 18:12 | |
| th1a | But then you'd find something sexier than SchoolTool, right? | 18:13 |
| srichter | :-) | 18:14 |
| mgedmin | maybe, maybe not | 18:14 |
| mgedmin | some of the stuff we do is exciting | 18:15 |
| mgedmin | unfortunately, that's mostly framework work rather than domain work | 18:15 |
| srichter | relationship is cool | 18:16 |
| srichter | REST is cool | 18:16 |
| tvon | is there a decent way to test a set of macros? Specifically I'd like to test the batching macros outside of schoolbell | 18:16 |
| srichter | the Introspector was also a lot of fun! | 18:16 |
| mgedmin | tvon, yes | 18:16 |
| mgedmin | write a small sample package that uses them | 18:16 |
| mgedmin | then write unit tests | 18:16 |
| mgedmin | (doctests!) | 18:17 |
| tvon | I'm missing a step somewhere, how does that let me test the macro rendering? | 18:18 |
| SteveA | surely it goes: first write unit tests (doctests!) and then write a small package that uses them. | 18:18 |
| mgedmin | tvon, you write a page template in your sample package, and that page template uses your macros | 18:20 |
| mgedmin | you also write a view in the same sample package, that uses this page template, then you render the view in your test | 18:20 |
| tvon | ah, gotcha | 18:20 |
| mgedmin | it is even better if you write it not as a test, but as documentation | 18:21 |
| mgedmin | here's how you would use our batching macros | 18:21 |
| mgedmin | suppose, you have an application that bla bla, and you have a view that bla bla | 18:21 |
| mgedmin | then you add this method to this view | 18:21 |
| mgedmin | and use this macro in the page template | 18:21 |
| mgedmin | and voila: | 18:21 |
| mgedmin | >>> print view() | 18:21 |
| mgedmin | <BLANKLINE> | 18:22 |
| mgedmin | ... | 18:22 |
| mgedmin | Page 3 of 42: | 18:22 |
| mgedmin | ... | 18:22 |
| mgedmin | etc. | 18:22 |
| tvon | gotcha | 18:22 |
| tvon | mgedmin: thanks | 18:22 |
| mgedmin | >>> from schooltool.batching.tests.sample import SampleApp, SampleView, SampleWhatever | 18:23 |
| th1a | tvon: What does "Search" search in the index views? | 18:23 |
| tvon | th1a: title | 18:24 |
| tvon | could add username for users, description for groups/resources/etc | 18:24 |
| tvon | is zcatalog on the roadmap anywhere? | 18:25 |
| th1a | Good question, actually. | 18:25 |
| th1a | There doesn't seem to be a strong sentiment here for using it; I don't quite understand the pros and cons. | 18:29 |
| srichter | if we have a lot of objects it will make searchinf much faster | 18:30 |
| tvon | When previously discussed the thought was that we'd worry about optimization later... but now we are talking about 1,500 items in a container so maybe it's appropriate | 18:30 |
| srichter | but I think this will not matter unless we talk about a huge university (I think) | 18:30 |
| th1a | 1500 items in a container should be considered within our general requirements. | 18:31 |
| th1a | We need to handle that well. | 18:31 |
| th1a | 15,000, not so much. | 18:31 |
| tvon | maybe thats not enough to warrent a catalog | 18:31 |
| tvon | afk/coffee | 18:39 |
| mgedmin | I want a benchmark | 18:39 |
| srichter | th1a: the documentme too :-) | 18:39 |
| mgedmin | a unit/functional test that creates a container with many items, and measures search/rendering time | 18:40 |
| srichter | oops: mgedmin: me too :-) | 18:40 |
| mgedmin | plus a definitions of what rendering time is acceptable (in seconds) | 18:40 |
| mgedmin | and on what baseline hardware | 18:41 |
| *** alga has quit IRC | 18:41 | |
| mgedmin | let's just say 2000 items, 1 GHz CPU, < 1 second | 18:42 |
| *** th1a has quit IRC | 18:49 | |
| srichter | mgedmin: are you going to merge the refactor branch? | 18:52 |
| srichter | mgedmin: Aiste: ignas: are guys still there? | 18:57 |
| * mgedmin and ignas are here, th1a and alga aren't, gintas is but he's not on irc for some reason | 18:59 | |
| srichter | mgedmin: I mainly wanted to get to you :-) | 19:00 |
| mgedmin | srichter, yes, but I also have other things scheduled before that | 19:00 |
| mgedmin | I've only two big checkins left to review | 19:00 |
| srichter | mgedmin: ok, so I keep working on the refactor branch, till you have time to merge | 19:00 |
| srichter | ah, I see | 19:00 |
| mgedmin | I've also noticed some minor things such as typos in docstrings in some other checkins | 19:00 |
| srichter | ok | 19:00 |
| mgedmin | that I thought not worth mentioning, but worth fixing when I merge | 19:01 |
| srichter | I see | 19:02 |
| mgedmin | by the way, I should probably mention that I intended to do the merge incrementally | 19:05 |
| mgedmin | merge one checkin (or maybe a couple of related ones), fix up minor things, commit, repeat | 19:05 |
| srichter | yep, good idea | 19:05 |
| srichter | I think it is very difficult to put very specific tasks into the contract, since I see things as I go along | 19:06 |
| *** alga has joined #SchoolTool | 19:13 | |
| mgedmin | yeah | 19:13 |
| srichter | mgedmin: it might be better to say: I work on it this long and guarantee to get those pints done | 19:22 |
| SteveA | the code review drinking game? | 19:22 |
| srichter | huh? | 19:23 |
| SteveA | > I work on it this long and guarantee to get those pints done | 19:23 |
| SteveA | in the UK, a pint is the general unit of consumption of beer | 19:23 |
| srichter | LOL :-) | 19:24 |
| srichter | right, I did not even notice :-) | 19:24 |
| srichter | luckily for Tom, I don't drink | 19:24 |
| srichter | mgedmin: are you okay, if I use the new Z3 way of importing? | 19:43 |
| * mgedmin hums | 19:50 | |
| mgedmin | I'd prefer not to mix two different coding styles | 19:50 |
| srichter | right, I understand this sentiment completely | 19:51 |
| srichter | though I gave up on it, since it prohibits improvements | 19:51 |
| srichter | it's like saying: I prefer one way to do ftests | 19:51 |
| srichter | so we could never switch to testbrowser | 19:51 |
| ignas | srichter, and the import lookup automation :) | 19:52 |
| mgedmin | importgeddon anyone? | 19:52 |
| srichter | I put it on the list | 19:52 |
| mgedmin | but do we want it? | 19:52 |
| srichter | same for using testbrowser, or do you have objections? | 19:52 |
| srichter | mgedmin: you tell me :-) | 19:53 |
| srichter | I am definitely +1 | 19:53 |
| mgedmin | srichter, can you please briefly describe "the new Z3 way of importing" on schooltool-dev@ ? | 19:53 |
| srichter | sure | 19:53 |
| mgedmin | if we decide to go ahead with it, I want everyone to know it | 19:54 |
| srichter | so we noticed that the import statements in our python code became huge and intimidating | 19:54 |
| srichter | also, the imported objects never revealed anything about their location | 19:54 |
| mgedmin | and I'd probably want everyone to commit an import refactoring on a module before committing any other changes mixed with some import changes to it | 19:54 |
| srichter | so you have to go up to the beginning to see where they come from | 19:54 |
| mgedmin | srichter, tags ;) | 19:55 |
| srichter | anyways, so Jim decided it would be good to always just import part of the path to an object | 19:55 |
| srichter | how much you import is up to you and pacticalibity | 19:56 |
| ignas | ?pacticalibity? | 19:56 |
| srichter | so we started to simply import packages; especially the ones not in app are usually just imported | 19:56 |
| srichter | improt zope.interface | 19:56 |
| srichter | import persistent | 19:56 |
| srichter | import persistent.list | 19:57 |
| srichter | import zope.component | 19:57 |
| srichter | with zope.app it depends on you, so I usually do something like this: | 19:57 |
| srichter | from zope.app import container | 19:57 |
| srichter | from zope.app import preference | 19:57 |
| srichter | but sometiumes also | 19:57 |
| srichter | from zope.app.container import constraint | 19:57 |
| srichter | for the interfaces of a pckage, I commonly use (as Jim): | 19:58 |
| srichter | from zope.app.mypackage import interfaces | 19:58 |
| srichter | sometimes situations are tricky, becuase you want: | 19:59 |
| srichter | from zope.app import mypackage | 19:59 |
| srichter | mypackage.interfaces.IMyObject | 19:59 |
| srichter | this will not work, if zope.app.package.interfaces was not imported before | 19:59 |
| srichter | so I commonly do: | 19:59 |
| srichter | import zope.app.mypackage.interfaces | 19:59 |
| srichter | from zope.app import mypackage | 20:00 |
| srichter | (these cases appear frequently, but not often) | 20:00 |
| ignas | -0.7 | 20:00 |
| srichter | and they are not a problem int he running system | 20:00 |
| srichter | it is usually just a problem when running unittests | 20:00 |
| srichter | of course there is an argument that I probably should just use: | 20:01 |
| srichter | import zope.app.mypackage.interfaces | 20:01 |
| srichter | zope.interface.implements(zope.app.mypackage.interfaces.IMyObject) | 20:01 |
| mgedmin | I don't like it :-/ | 20:01 |
| srichter | (Jim tends to do this, though I think it's a bit lengthy) | 20:02 |
| srichter | I know it takes some getting used to | 20:02 |
| ignas | not that it has that many downsides | 20:02 |
| srichter | I really, really hated it the first time Jim did this, and changed it back to the old style :-) | 20:02 |
| mgedmin | what are the advantages of this schema? | 20:02 |
| SteveA | does that mean you can get rid of zapi ? | 20:02 |
| ignas | yet i can't see any benefits :/ | 20:02 |
| * SteveA thinks that zapi sucks | 20:02 | |
| srichter | SteveA: I think this is one of Jim's motivations | 20:03 |
| SteveA | the zope.component stuff should definitely not be in zapi | 20:03 |
| ignas | TAGS + (emacs | vi) + sane project structure are the way i would go ... | 20:03 |
| srichter | ignas: as a new comer it is much eaier to look at the file, since you are not overwhelmed with imports | 20:03 |
| srichter | and it is easier to work with unfamilaiar code | 20:03 |
| mgedmin | it's trivial to skip imports | 20:03 |
| ignas | srichter, but you are overwhelmed by code itself ... | 20:04 |
| mgedmin | you don't object to the huge GPL notice at the top of every source file, do you | 20:04 |
| mgedmin | ? | 20:04 |
| srichter | no, but that's different | 20:04 |
| srichter | anyways, Jim was reacting to experiences of newcomers during sprints | 20:04 |
| ignas | well from my experience with Z3 or schooltool - there aren't many duplicate classes or functions that are in use as to justify this ... | 20:05 |
| ignas | im very ho | 20:05 |
| srichter | oh, another advantage | 20:05 |
| mgedmin | duplicate names hurt grepability, so we avoid those | 20:05 |
| ignas | i mean you can get to the source file by using TAGS 95% of the time | 20:05 |
| srichter | in the new way you are much less likely to keep unused imports around | 20:06 |
| ignas | and you don't have to go to imports if you are using tags ... never ... | 20:06 |
| mgedmin | true, but we have a few different import checkers around ;) | 20:06 |
| srichter | I found at least 4-5 occurences of needless imports during the 2 days of refactoring | 20:06 |
| mgedmin | I used to run mine all the time on schooltool -- until it started breaking doctests | 20:06 |
| srichter | anyways, this was my case for the new import system | 20:07 |
| ignas | as I said - "-0.7" | 20:08 |
| mgedmin | let me summarize | 20:08 |
| mgedmin | + fewer imports at the top | 20:08 |
| ignas | you should multiply it by my credibility coefficient of course ;) | 20:08 |
| mgedmin | let me summarize | 20:08 |
| mgedmin | + fewer imports at the top | 20:08 |
| mgedmin | + easier to see where each name comes from (if the programmer is careful) | 20:08 |
| mgedmin | + fewer stale unused imports | 20:08 |
| mgedmin | is that all? | 20:09 |
| srichter | yeah, I think this summarizes all my points | 20:09 |
| mgedmin | ok, my points now | 20:11 |
| srichter | ok | 20:11 |
| mgedmin | - code becomes uglier (personal preference maybe) | 20:11 |
| srichter | (code becomes *longer*) | 20:11 |
| mgedmin | - it is hard to figure out what the prefix should be -- how many names to import and how many to keep repeating | 20:12 |
| mgedmin | - 'import foo.bar.baz' followed by 'from foo import bar' is really unobvious | 20:13 |
| mgedmin | - we're not used to it | 20:13 |
| mgedmin | you see, I am running out of objective objections ;) | 20:13 |
| SteveA | clear dependencies are important | 20:13 |
| SteveA | the relationship of dependency is the foundation of software design | 20:14 |
| SteveA | i don't know which variant is clearer. | 20:14 |
| mgedmin | I know which one is clearer to me | 20:14 |
| mgedmin | I don't know which one is clearer to a random guy | 20:14 |
| srichter | the new style gives you quicker overview of the imported packages | 20:16 |
| srichter | but it is not much of an advantage | 20:16 |
| mgedmin | old style, when sorted alphabetically, gives a better overview of imported packages | 20:18 |
| mgedmin | and also the breadth of our dependency on them | 20:18 |
| ignas | +1 for alphabetic sort on all import groups | 20:18 |
| srichter | well, this is a given either way (alphabetical sorting) | 20:18 |
| ignas | i can make my emacs magic do *all* the importing instead of some of the importing ;) | 20:19 |
| * mgedmin really wants to stop reading the discussion here and go back to reading checkins | 20:19 | |
| ignas | i am waiting for tests on muskatas/fridge anyway :( | 20:19 |
| srichter | mgedmin: do this; sleep over it and let me know tomorrow | 20:20 |
| mgedmin | let's just move this discussion to the mailing list | 20:21 |
| srichter | ok | 20:21 |
| mgedmin | developers who are not here now also deserve to participate | 20:21 |
| srichter | ok | 20:21 |
| SteveA | in launchpad we use the style | 20:22 |
| SteveA | from foo.bar.baz import ( | 20:23 |
| SteveA | BarBar, BazBaz, FooFoo, | 20:23 |
| SteveA | FishFish) | 20:23 |
| SteveA | this is good for line-by-line diffs | 20:23 |
| srichter | requires Py 2.4 | 20:23 |
| SteveA | and visually distinguishes the 'from whatever' from what is imported | 20:23 |
| SteveA | how long as python 2.4 been out? | 20:23 |
| srichter | which is another issue we need to discuss | 20:23 |
| srichter | I am for usign 2.4 | 20:23 |
| mgedmin | I am not against | 20:24 |
| * mgedmin wonders if anyone noticed that some of his objections to certain changes in other people's checkins are actually a case of a pot calling a kettle black... | 20:39 | |
| srichter | he he | 20:39 |
| *** thisfred has quit IRC | 20:43 | |
| srichter | mgedmin: btw, what do you think about switching ftests to testbrowser? | 20:44 |
| mgedmin | I've postponed thinking about it | 20:46 |
| mgedmin | I think I'll like that idea once I've time to consider it ;) | 20:47 |
| srichter | :-) | 20:47 |
| mgedmin | see you tomorrow, then | 21:06 |
| srichter | bye | 21:10 |
| *** mgedmin has quit IRC | 21:18 | |
| *** tvon has quit IRC | 21:31 | |
| *** tvon has joined #schooltool | 21:47 | |
| *** FarcePest has quit IRC | 22:01 | |
| *** ignas has quit IRC | 22:27 | |
| *** pcardune has joined #schooltool | 22:29 | |
| *** jelkner has joined #schooltool | 22:31 | |
| jelkner | question: we are setting up a cando (schooltool) instance for use by our school, and we want to have nice unix system v initialization. Is there a schooltoolctl file or something evailable? | 22:32 |
| jinty | jelkner: you mean you want it to start up every time you boot? | 22:36 |
| jelkner | yes | 22:39 |
| jinty | there is a debian init script in the debian dir which does that (schooltool.init). Its not in the current release tarballs, but is in the last. Perhaps it's usefull on unix. | 22:42 |
| *** admp has joined #schooltool | 22:42 | |
| jelkner | this is a fedora core 3 box | 22:43 |
| jelkner | and we are checking schooltool from svn | 22:43 |
| jinty | The init script does not need anything unusual, you could probably do with just modifying one of the fedora ones then. There was also a schooltool rpm floating around, maybe it contains one... | 22:47 |
| jelkner | jinty: i tried just adding this line to /etc/inittab: | 22:54 |
| jelkner | /opt/schooltool-fork/schooltool-server.py | 22:54 |
| jelkner | but it schooltool didn't start when we restarted the machine | 22:55 |
| jelkner | though /opt/schooltool-fork/schooltool-server.py will start it from the command line | 22:55 |
| tvon | inittab isn't a good place for that | 22:56 |
| jelkner | ok, where then? | 22:56 |
| tvon | rh/fedora uses different init.d setup than debian, but the debian one should probably work...you have schooltool installed in /opt/schooltool-fork ? | 22:56 |
| tvon | one sec,let me look at the deb script | 22:56 |
| jinty | neither is it pedantically secure to run the server as root | 22:56 |
| jinty | uses start-stop-daemon. dunno if that exists on fedora | 22:57 |
| jinty | the deb script i mean... | 22:57 |
| tvon | it's been a bit since I used fedora | 22:58 |
| jelkner | zopectl works on any distro | 22:58 |
| jelkner | all you need to do is sym link from /etc/init.d | 22:58 |
| jelkner | but schooltool-fork doesn't come with a zopectl type script and i don't know how to write one | 22:59 |
| tvon | http://source.schooltool.org/viewcvs/trunk/debian-packaging/schoolbell-debian/schoolbell.init?rev=4487&view=auto | 22:59 |
| tvon | thats the debian init script, you'll need to alter some paths thogh | 22:59 |
| tvon | though | 22:59 |
| jelkner | does that do the change user thing? | 23:00 |
| tvon | er, you want schooltool... | 23:00 |
| jinty | tvon: does fedora have start-stop-daemon? | 23:00 |
| *** eldafar has joined #schooltool | 23:00 | |
| jelkner | we need to start as root, so it can run on port 80 | 23:00 |
| jelkner | and then change users | 23:00 |
| tvon | jinty: IIRC yes | 23:00 |
| tvon | oh, wait | 23:01 |
| tvon | no, it does not | 23:01 |
| tvon | apologies jelkner, that script won't help you | 23:01 |
| * jinty goes to look for the schooltool rpm | 23:02 | |
| * tvon looks at sourceforge init scripts | 23:03 | |
| jelkner | it would be very helpful is schooltool could come with a schooltoolctl script | 23:11 |
| tvon | yeah | 23:11 |
| jinty | jelkner: do you have an e-mail address? | 23:14 |
| tvon | jinty: find it? | 23:14 |
| jinty | yep, had to figure out how to rip apart an rpm on debian though | 23:15 |
| tvon | heh | 23:15 |
| jinty | start-stop-daemon >> daemon | 23:16 |
| tvon | hrm | 23:16 |
| * tvon shrugs | 23:16 | |
| eldafar | his email is jelkner@divmod.com | 23:16 |
| *** alga has quit IRC | 23:19 | |
| povbot | /svn/commits: * srichter committed revision 4675: | 23:22 |
| povbot | /svn/commits: I must have forgotten to run this test after the last change. This fixes the ftest/ | 23:22 |
| povbot | /svn/commits: * srichter committed revision 4676: | 23:30 |
| povbot | /svn/commits: I forgot to check this in before. It goes hand-in-hand with the view_macros merge checkins. | 23:30 |
| povbot | /svn/commits: * srichter committed revision 4677: | 23:31 |
| povbot | /svn/commits: Put notes implementation into separate package. | 23:32 |
| eldafar | i'm trying to check out the testbrowser branch from Zope3 | 23:39 |
| eldafar | svn co http://svn.zope.org/Zope3/branches/testbrowser-integration Zope3 | 23:39 |
| eldafar | is there something wrong with that command, because it's not working | 23:39 |
| srichter | note that this version of testbrowser requires Python 2.4 | 23:43 |
| srichter | s/http/svn | 23:44 |
| srichter | you also need some additional packages: mechanize, ClientForm, ClientCookie, pullparser | 23:44 |
| srichter | they are in the schooltool trunk | 23:45 |
| *** FarcePest has joined #schooltool | 23:50 | |
| eldafar | thanks | 23:53 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!