*** ignas has quit IRC | 02:30 | |
*** lisppaste5 has quit IRC | 06:59 | |
*** lisppaste5 has joined #schooltool | 07:04 | |
*** Aiste has joined #schooltool | 10:44 | |
*** thisfred has joined #schooltool | 11:02 | |
*** jfroche has joined #schooltool | 11:18 | |
*** ignas has joined #schooltool | 11:38 | |
ignas | SteveA: are you there? | 11:44 |
---|---|---|
SteveA | I am here | 11:46 |
ignas | like 2 weeks ago i missed the chat about bzr between you marius and th1a | 11:47 |
ignas | i was on my way home thus without a connection for 1 hour or so | 11:47 |
SteveA | we had a chat about bzr? | 11:47 |
ignas | 11-27 | 11:48 |
SteveA | we had a chat about using launchpad iirc | 11:48 |
ignas | migration to launchpad | 11:48 |
SteveA | not about bzr | 11:48 |
SteveA | about bug tracking | 11:48 |
ignas | and you talked about svn-bzr issues a bit | 11:48 |
ignas | and you have mentioned that you need requirements, and that you could organize a meeting to discuss the migration | 11:48 |
SteveA | maybe as a side conversation | 11:48 |
SteveA | ok | 11:48 |
ignas | http://schooltool.pov.lt/irclogs/%23schooltool.2006-11-27.log.html#t2006-11-27T19:27:48 | 11:49 |
ignas | and like 20 minutes of the side conversation after that ... | 11:49 |
ignas | as i am the one who tried migrating from svn to bzr i could try explaining the problems i am having if you would tell me whom should i send them to ;) | 11:51 |
SteveA | just a sec, I'll see | 11:51 |
*** poolie has joined #schooltool | 11:55 | |
SteveA | ignas: poolie (martin pool) and ddaa (david allouche) who both know much about bzr are joining this channel | 11:56 |
poolie | hi ignas | 11:56 |
ignas | poolie: hi | 11:56 |
ignas | should i wait for ddaa or just start complaining ? :) | 11:57 |
*** ddaa has joined #schooltool | 11:58 | |
ignas | hi | 11:58 |
ddaa | hello | 11:58 |
ddaa | sorry, got my servers crossed | 11:58 |
ignas | :) | 11:58 |
ignas | http://source.schooltool.org/trac/browser/trunk/schooltool | 11:58 |
SteveA | ignas is a core schooltool developer | 11:58 |
ddaa | o/` Pink Floyd, Riding the Gravy Train o/` | 11:59 |
ignas | the repository in question | 11:59 |
SteveA | ignas: I haven't given these guys much background | 11:59 |
ignas | i know | 11:59 |
SteveA | so I think you should start by explaining what you want to do | 11:59 |
ddaa | Come on here dear boy, have a cigar | 12:00 |
ddaa | You wanna go far, you wanna fligh high | 12:00 |
ignas | as schooltool will start using launchpad for the bugtracking and project management | 12:00 |
ignas | i think it would be nice to migrate from svn to bzr | 12:00 |
ignas | as that would give us all the benefits of distributed vcs as well as make the integration with launchpad smoother | 12:01 |
ignas | i have tried using at least 3 tools to do that without results that would be good enough though :/ | 12:01 |
ddaa | So, I guess you'd like at least to get a conversion of the repo. | 12:02 |
ddaa | What are the tools you are talking about? | 12:02 |
ignas | tailor, svn2brz, bzr-svn | 12:02 |
ignas | as i want to do a full switch (bzr-svn is just not working on schooltool svn, so i think relying on only bzr would be better) | 12:03 |
ddaa | ok, I'd be happy to see what problem you had with bzr-svn. If there's no way we can make it work easily, I could also convert your trunk and branches using cscvs. | 12:03 |
ignas | svn2bzr was the one that got me nearly what i want | 12:03 |
ignas | you see - our branches are a bit unorthodox :/ | 12:04 |
ddaa | ignas: let's talk about conversion later. With SteveA's permission, I'll make this my top priority this week. | 12:04 |
SteveA | there's a thing I heard about subversion | 12:04 |
ignas | ok | 12:04 |
SteveA | it has lots of "you can do this" in it | 12:04 |
SteveA | and that means it's easy to go unorthodox | 12:05 |
ddaa | Are there other things you would like information about, that we can discuss now while poolie is there? | 12:05 |
SteveA | ddaa: I'd like to get those database patches rolled out, but other than that, I'm happy for you to help out schooltool | 12:05 |
ignas | hmm, shared repository support and tags | 12:06 |
ddaa | Like consideration of how to implement your development process with bzr. | 12:06 |
poolie | i agree | 12:06 |
poolie | ignas, tags are implemented by a plugin atm, while we experimented | 12:06 |
ddaa | tags -> poolie, it's still not yet implemented, so you can get as good tags as with svn using repositories | 12:06 |
ddaa | oh, really, great! | 12:06 |
poolie | i am working on bringing them into mainline this week | 12:06 |
poolie | yeah i hope so | 12:07 |
poolie | ignas: cvsps may also be worth a try | 12:07 |
ignas | i see, as for the development process - jinty (Brian Sutherland) will be the one affected most by it | 12:07 |
ignas | poolie: cvsps ? | 12:07 |
poolie | ddaa, if you can help him ignas that would be great | 12:07 |
poolie | https://launchpad.net/products/bzr-cvsps-import | 12:08 |
ddaa | the thing is, if you set up a repository, you can have tags in bzr pretty much the same way as you have in svn. Would that be enough, or is something more like cvs or git tags needed? | 12:08 |
ddaa | poolie: you mean jinty? | 12:09 |
ignas | ddaa: i think shared repository (if i understand it would make tags not to take up whole 200-300 mbs) would be good enough | 12:09 |
ddaa | ignas: you understand correctly, a branch that introduces no change is essentially free in a repository (pretty much just i a directory). | 12:10 |
ignas | bzr2svn would have been good enough just that it doesn't support that | 12:10 |
ddaa | so, just as svn, a tag can be a branch w/o new change | 12:10 |
ignas | thus all the branches were taking up like 2gb of space after migration ... | 12:11 |
ddaa | ignas: that's probably easy to fix | 12:11 |
ddaa | the "put data in a branch" is well separated from "use shared repository for this branch" in bzr | 12:12 |
ddaa | ignas: did svn2bzr otherwise import your data successfully? | 12:12 |
ignas | i think so, maybe with some flaws in interbranch merges | 12:12 |
ddaa | unless you usedi svk, svn does not really record merges... | 12:13 |
ignas | yes indeed, would cvsps be able to detect such things? | 12:14 |
ddaa | I'm confused with the introduction of cvsps here. It's a tool for migrating from CVS AFAIK. | 12:14 |
ignas | i just assumed that it's just a name | 12:15 |
ddaa | well, unlike cscvs that does svn too (yes, confusing names) | 12:15 |
ignas | as for the development process - i want to come up with a migration routine that can be reliably performed whenever i want, so i could do it when everything else (deployment, packaging) is already set up | 12:16 |
ddaa | essentially, cvsps is a tool for working around cvs not having atomic commits, and recording commit timestamps provided by the client, which can lead to some serious mess, but is completely CVS-specific. | 12:17 |
ignas | so we could safely switch on a convenient date | 12:17 |
ignas | i see | 12:17 |
ddaa | mh | 12:17 |
ignas | btw isn't svn2bzr kind of abandoned/undeveloped at the moment? | 12:17 |
ddaa | yes, jelmer used to maintain it but now focuses on bzr-svn | 12:18 |
ddaa | so... you want a script that you can run that takes your svn repo as input, and gives you a collection of bzr branches as output, right? | 12:19 |
ignas | i'd prefer svndump as the input | 12:19 |
ddaa | ok, it's not an essetial difference though :) | 12:19 |
ignas | probably | 12:20 |
ddaa | so... depending how things turn out that may be difficult to do. But if you say that svn2bzr does roughly the right thing, that seems doable. | 12:20 |
poolie | um sorry, i was completely confused in mentioning cvsps | 12:21 |
ignas | but yes, i'd like to come up with a script that does things reliably and in a right way | 12:21 |
ignas | as i can ensure that repository will not undergo any significant changes | 12:21 |
ignas | the script will keep working for a long time unless someone makes bzr internals non compatible ;) | 12:21 |
poolie | but i wonder if the script that reads its output could be converted to read svndump... | 12:22 |
ddaa | I'd need some more information later to adress some details of the conversion (specifically, if something special needs to be done to ensure consistency of files ids for files introduced in branches). | 12:22 |
ignas | file ids? | 12:23 |
ddaa | in bzr, each file has an id, that allows to track renames | 12:23 |
ignas | oh | 12:23 |
ignas | so that merging from a branch would work properly | 12:24 |
ddaa | that means that if, in SVN, you branch/foo out of trunk at revision 12, then introduce file trunk/hello in revision 13, then copy it it branch/foo/hello at revision 14. | 12:25 |
ddaa | When converting to bzr, something needs to be done to make sure hello has the same id in both branches, otherwise you'll have annoying conflicts on the first merge, and you will lose some annotation data. | 12:25 |
ignas | that's what i thought about | 12:26 |
ddaa | depending on how much you care about the output of "bzr annotate", and how complex was your merging history, it might be complicated | 12:26 |
ddaa | that's a problem that bzr-svn deals quite well with | 12:26 |
ignas | i see | 12:27 |
ddaa | but because it needs to know branch roots to deal with it, that means that if you repo was not always following the /trunk and /branches/* convention, it will barf (ATM, hope to fix it eventually) | 12:27 |
ignas | how hackable is bzr-svn when it comes to treat "/svn/trunk/*" as separate branches idea | 12:28 |
ignas | i know i only had to add one class to svn2bzr to make it do the thing i want | 12:28 |
ddaa | I got a general idea of how to do it. But I'm not familiar with the code yet. | 12:28 |
ddaa | though maybe we can do something short of the Right solution, since you really want a one-off conversion. That would be one option to investigate if your merging history is too complex to deal with svn2bzr. | 12:29 |
ignas | it might be the case ... | 12:30 |
ignas | as i had /trunk/schooltool then it became /trunk/schoolbell + /trunk/schooltool and then /trunk/schooltool again | 12:30 |
ignas | schooltool and schoolbell being separate but interdependent projects | 12:31 |
ddaa | as in, different scope, or parallel branches? | 12:31 |
ignas | as in different scope | 12:31 |
ignas | schootool checking out schoolbell as an svn external | 12:31 |
ddaa | okay... this level of complexity, it _should_ be possible to deal with given some elbow grease. | 12:32 |
ignas | i hope so :) | 12:33 |
ddaa | I'm more concerned about things like "zillions of individual copies across branches and trunk that must keep track of file identity" | 12:33 |
ignas | oh and we had zope3 in our repository a couple of times too | 12:33 |
ddaa | mh... if it was kept well segregated, that should not be a problem | 12:33 |
ddaa | if it was included directly (not with externals) in another branch, you'd have to keep the bloat, or we'll have to find a way to excise it from the svn dump... | 12:34 |
ignas | oh and some old branches got moved into /branches/obsolete/branch* | 12:34 |
ddaa | care about those? | 12:34 |
ignas | hmm, i don't know that's the problem | 12:35 |
ddaa | to be really straight, I usually run the launchpad.net imports, so I have limited experience with other conversion tools. | 12:35 |
ddaa | But I've got a good grip on the sort of issues that can pop up. | 12:36 |
ddaa | If you do not care about the obsolete branches, I expect we can safely ignore them. | 12:36 |
ignas | hmm | 12:36 |
ddaa | if you do care about them, it's certainly possible to keep them | 12:37 |
ddaa | I just know how good is svn2bzr at dealing with this | 12:37 |
ddaa | just _do not_ know | 12:37 |
ddaa | ignas: what UTC times are around usually? | 12:37 |
ignas | i was just making svn2bzr treat /branches/obsolete/* as branches | 12:37 |
ignas | 11:00-19:00 | 12:38 |
ddaa | you're early :) | 12:38 |
ignas | for sure, sometimes 9:00-20:00 | 12:38 |
ignas | i must come to work 13:00 (vilnius time) | 12:39 |
ddaa | good, I'm here usually 10:00-18:00 (paris time) | 12:39 |
ddaa | I mean 10:00-18:00 UTC, I live in Paris. | 12:39 |
ignas | if you will want to play with ST repo http://ignas.pov.lt/st.dump.bz2 is the svn dump (37 megs) | 12:40 |
ignas | an old one, but it has all the quirks | 12:40 |
ddaa | downloading | 12:41 |
ddaa | would like to know anything else about bzr, before I go back to my lair? | 12:42 |
ddaa | got some sharp instruments I want to try on this dump :) | 12:42 |
ignas | :) | 12:42 |
ignas | is it easy to set up a check in mailing list? | 12:42 |
ddaa | mh | 12:43 |
ddaa | there's a plugin around, and there is a commit ML for bzr itself | 12:43 |
ddaa | poolie: ping? | 12:43 |
poolie | hi | 12:43 |
ddaa | ignas: how easy is the email-on-commit thingy to set up? | 12:43 |
ddaa | oops | 12:44 |
ddaa | ^ this was for poolie | 12:44 |
poolie | pretty straightforward i believe | 12:44 |
poolie | there are docs | 12:44 |
ddaa | ignas: actually there are two approaches: one is send the email from the "bzr commit" command. The other one is "watch a branch and send emails when new stuff appears". | 12:44 |
ignas | hmm, i see, we'll need that, and some integration with buildbot | 12:45 |
ddaa | the former is only really reliable when you have a single committer on the branch (like pqm). The latter involves a cron job. | 12:45 |
ddaa | right, you use buildbot to run test suites? | 12:46 |
ignas | hmm | 12:46 |
ignas | yes | 12:46 |
ignas | pqm sounds like a nice thing, yet it might be a bit complicated to set up | 12:46 |
ddaa | yes, and yes :) | 12:47 |
ddaa | you know what pqm is? | 12:47 |
ignas | i would like to have the kind of set up bzr mailing list has | 12:47 |
ignas | ddaa: seen a few SteveA's presentations on the subject | 12:47 |
ignas | seen some scary diagrams | 12:47 |
ddaa | DVCS tends to produce scary diagrams | 12:48 |
ignas | well, as long as it will make my job easier | 12:48 |
ddaa | it's one of those things that's actually quite simple if you can see them with the right frame of mind | 12:48 |
ignas | just like Zope3 :D | 12:49 |
ddaa | so, the nice thing with pqm is that it can run the test suite and only accept commits that cause no test failure | 12:49 |
ddaa | it also avoids unecessary contention on a branch when you have many active committers | 12:49 |
ignas | i liked the mandatory code review with possibility to reject check ins part :) | 12:50 |
poolie | it is still a bit complex to set up | 12:50 |
ignas | as for commiters we have 2 of them at the moment | 12:50 |
poolie | i'd suggest thinking about pqm later | 12:50 |
ignas | :) | 12:50 |
ddaa | okay, then branch contention is not a problem, and you can probably just hit the other dev on the head if he does not run the test suite before comitting :) | 12:50 |
poolie | there is also | 12:51 |
poolie | http://bundlebuggy.aaronbentley.com/ | 12:51 |
ddaa | you see, in the lp or bzr team, we would need globally distributed LARTs to achieve effective hitting-on-the-head, so we use PQM instead :) | 12:51 |
ignas | now this one i like | 12:51 |
ignas | well, my colleague is in Belgium | 12:52 |
ignas | and other possible developers are in the US | 12:52 |
ignas | so LARTS would be nice too :D | 12:52 |
ddaa | so, pqm goes in the "later" basket | 12:52 |
ddaa | poolie: think we should plagiarize bb in lp? | 12:53 |
ignas | thanks a lot for your help | 12:55 |
poolie | i think we have enough on our plate :) | 12:55 |
poolie | so what did you decide about conversion? | 12:56 |
ddaa | I'll be checking how it goes with svn2bzr | 12:56 |
ddaa | and see if output can be reasonably tuned to get good file-id consistency | 12:57 |
poolie | cool | 12:58 |
jfroche | ignas: hello! provideAdapter(DateFormatterFullView, [datetime.date, IRequest], IDateFormatter , 'fullDate') should be replaced by a zcml view statement right ? | 12:58 |
ignas | yes | 12:58 |
ignas | hi | 12:58 |
ignas | :) | 12:58 |
jfroche | problem with the view statement is that for="" is waiting for an interface | 12:59 |
jfroche | and datetime.date has no z3 interface | 12:59 |
ignas | have you tried datetime.date ? | 13:01 |
jfroche | ignas: my fault, i was using browser:view instead of zope:view | 13:10 |
jfroche | ignas: i have just commited, did you recieve the automated diffs in your mail ? | 13:29 |
jfroche | cause seems i didn't get it | 13:29 |
ignas | missing too | 13:29 |
ignas | looking at it in trac | 13:29 |
jfroche | i am fixing the tests now | 13:30 |
ignas | jfroche: could you try getMultiAdapter instead of queryMultiAdapter | 13:30 |
ignas | i think you won't have to raise the error yourself | 13:30 |
jfroche | oh i see | 13:31 |
ignas | dateformatter.py is missing the fat header with all the licence stuff | 13:31 |
jfroche | right, as many .py does in skin | 13:31 |
jfroche | ignas: great getMultiAdapter does the job ! | 13:33 |
jfroche | tkx | 13:33 |
poolie | ignas: tim is working on a better way to do commit mailing lists, as a supermirror service | 13:47 |
ignas | nice | 13:49 |
*** mgedmin has joined #schooltool | 13:55 | |
jfroche | ignas: i have discovered something which might be a problem for the dateformatter, in the user preference a user can define its date format | 14:17 |
ignas | we can drop that | 14:18 |
ignas | if someone will miss it - it's fixable | 14:18 |
jfroche | ok | 14:18 |
jfroche | ignas: should i comment the test ? | 14:20 |
ignas | remove not comment | 14:20 |
ignas | do not put commented out code in to the repository | 14:20 |
jfroche | ok | 14:20 |
ignas | if anyone will need it he can just go to svn and find it | 14:20 |
jfroche | i see | 14:21 |
jfroche | ignas: if a request hasn't HTTP_ACCEPT_LANGUAGE in the environ, the date isn't rendered correctly as no language is provided by the request | 14:34 |
jfroche | should i change the code or the test ? | 14:34 |
ignas | shouldn't it default to english ? | 14:35 |
jfroche | i does not | 14:35 |
jfroche | it does not | 14:35 |
ignas | then make it do so :) | 14:35 |
ignas | or is it difficult ? | 14:35 |
ignas | hmm | 14:35 |
ignas | maybe just set the HTTP_ACCEPT | 14:36 |
ignas | in your test | 14:36 |
jfroche | i get dates like this: 1, 2006 1 01 instead of Sunday, January 1, 2006 | 14:36 |
jfroche | if not language is provided | 14:36 |
ignas | eek, yep - the default Zope3 date formatter is bogus | 14:36 |
jfroche | should i dig into it ? | 14:37 |
ignas | yes i think so | 14:44 |
ignas | do all the browsers send accept_language tag | 14:44 |
ignas | what might be the values | 14:44 |
ignas | what happens if no locale is found | 14:44 |
ignas | how will dates look in that case ? | 14:44 |
ignas | if they look ugly - maybe we can set the default renderer to UK/US? or mabe the ISO one? | 14:45 |
mgedmin | ah, yes, the infamous default zope locale | 14:48 |
mgedmin | with week day names like "1", "2", ... | 14:48 |
jfroche | I can also test for accept_language in my dateformatter and set english if nothing found | 14:49 |
*** jinty has joined #schooltool | 14:50 | |
jfroche | when no language is set i have: <LocaleIdentity (None, None, None, None)> as request.locale.id | 14:52 |
jfroche | i would need <LocaleIdentity (en, None, None, None)> | 14:52 |
jfroche | would it be bad to set something else than None for default language argument of the LocaleIdentity init method ? | 14:54 |
ignas | hmm | 14:54 |
ignas | don't really know what's the right way | 14:56 |
ignas | i think you should ask in Zope3-dev | 14:56 |
ignas | and you don't want to change Zope3 code | 14:56 |
jfroche | right | 14:56 |
jfroche | i ll do one trick in my dateformatter | 14:57 |
ignas | i'd suggest you to check self.request.locale.id.language in your views | 14:57 |
ignas | and if it's none | 14:57 |
ignas | set it to some value | 14:57 |
jfroche | right | 14:58 |
*** alga has joined #SchoolTool | 16:00 | |
*** th1a_ is now known as th1a | 16:30 | |
* th1a shuffles some papers around. | 16:30 | |
th1a | Good morning, folks. | 16:31 |
th1a | Hi ignas, jfroche. | 16:31 |
jfroche | hello th1a | 16:32 |
th1a | Did we lose ignas? | 16:33 |
ignas | hi | 16:34 |
th1a | Ah. | 16:35 |
th1a | OK. | 16:35 |
th1a | Hi ignas. | 16:35 |
th1a | So... | 16:35 |
th1a | Next Monday is Christmas, and the next Monday is New Year's, so we probably need to juggle our schedule a bit. | 16:36 |
th1a | Perhaps we can skip next Monday and meet Jan. 2nd? | 16:36 |
jfroche | ok for me | 16:36 |
ignas | ok | 16:36 |
th1a | All right, so we just need to plan out the rest of this year. | 16:37 |
th1a | I sent the 2007 budget to Mark about 7 hours ago. | 16:37 |
th1a | Hopefully we'll get word back from him soon. | 16:37 |
ignas | i must come up with a plan for next quarter, get an invitation letter from tom and start getting a visa | 16:38 |
ignas | finish the timetable refactoring | 16:38 |
ignas | and get the person work started | 16:38 |
th1a | I'll resend the letter. | 16:39 |
th1a | Did I call you Albert or something? | 16:39 |
jfroche | i ll finish to fight against date localization (i won) and i ll dive into gradebook | 16:40 |
ignas | no, Agejevas | 16:40 |
th1a | Sorry! | 16:40 |
ignas | like 3 times :) | 16:40 |
th1a | Obviously, I was just changing my old letter. | 16:40 |
th1a | Anyhow, the one other thing I need from you two is quarterly goals for next year. | 16:41 |
th1a | That's a priority. | 16:41 |
ignas | for all 3 quarters or for the first quarter ? | 16:41 |
th1a | First two. | 16:41 |
th1a | The third quarter goal is to deploy successfully. | 16:42 |
th1a | The fourth is to keep it running. | 16:42 |
ignas | ok | 16:42 |
jfroche | i spoke about this during the last meeting at the school | 16:43 |
jfroche | i ll write them clearly with the help of Nicolas | 16:43 |
jfroche | and send them to you | 16:43 |
jfroche | or write them somewhere on launchpad ? | 16:43 |
th1a | This doesn't need to be on Launchpad. | 16:43 |
th1a | It also would be a good time to note major dependencies between the two of you. | 16:45 |
th1a | If one of you will be expecting the other to write something. | 16:45 |
ignas | hmm | 16:45 |
th1a | Or not. | 16:45 |
ignas | looking 6 months forward is quite far | 16:45 |
th1a | Yes. | 16:46 |
th1a | I'm not looking for anything super-specific. | 16:46 |
ignas | hmm | 16:46 |
ignas | without super-specific validation part might be difficult ... | 16:46 |
ignas | how will the validation of our effort be accomplished? | 16:47 |
ignas | deployment is a clear goal | 16:47 |
ignas | what about intermediate goals ? | 16:48 |
ignas | should we talk with schools about that, and have schools as referees, or will you be doing it? | 16:48 |
th1a | Perhaps we should have the schools play a role here. | 16:49 |
th1a | Whether or not they think the attendance module is ready is more important than if I do. | 16:49 |
th1a | So let's plan on having the schools play a role in validation. | 16:50 |
jfroche | i ll ask them | 16:50 |
th1a | So that would imply that completing a few large blocks of functionality would be appropriate for a milestone. | 16:51 |
th1a | It has to be relevant to the end-user. | 16:51 |
th1a | jfroche: So tell me more about Lycee Emile Jacqmain. | 16:53 |
th1a | How does one abbreviate that? | 16:54 |
ignas | th1a: what about the modifications to the quarterly plan if users want A more than B (B being in the plan) | 16:54 |
jfroche | i met with the different persons (accountant, the guy in charge of the computers there and the director) | 16:54 |
th1a | ignas: I'm flexible, but I'd like them to approve the sequence as early as possible. | 16:55 |
jfroche | LEJ | 16:55 |
jfroche | they seems to be motivated | 16:55 |
jfroche | they have different parts separated | 16:55 |
jfroche | many reencoding | 16:55 |
jfroche | they would like to use 1 system | 16:56 |
th1a | How many students? | 16:56 |
jfroche | their schedule software seems to be really good (but really expensive) as it calculate and verify the different constraints in the timetables of every teacher | 16:56 |
th1a | We're not trying to replace that yet, but we'll need to import the data. | 16:57 |
jfroche | good question | 16:57 |
jfroche | yes and for that i ll need a way to define my person | 16:57 |
th1a | What does the person need to do? | 16:59 |
ignas | have different demographics data | 16:59 |
ignas | different forms for adding/editing | 17:00 |
ignas | different columns for displaying in tables | 17:00 |
jfroche | many things aren't needed, other will need to be added to the person | 17:00 |
ignas | not break schooltool core tests | 17:00 |
th1a | Using adapters is key, I presume. | 17:02 |
th1a | Anyhow... anything else from LEJ? | 17:04 |
jfroche | they seems to want first the gradebook | 17:05 |
ignas | hmm | 17:05 |
ignas | i can send you some links/examples of lithuanian gradebooks | 17:05 |
th1a | That's not a bad idea, since that's our weakest point. | 17:06 |
th1a | In terms of being furthest from completion. | 17:06 |
jfroche | the guy implemented a way to encode point in Excel ... it should be pretty easy to beat him | 17:06 |
ignas | http://dienynas.bst.lt/vsm/aprasymas/Elektroninis_dienynas%205.0.0.php | 17:06 |
ignas | here ya go | 17:06 |
ignas | it's lithuanian | 17:06 |
ignas | though screenshots should give you some ideas | 17:07 |
ignas | if you'll want translation just post me the header | 17:07 |
jfroche | bookmarked | 17:08 |
jfroche | i ll recieve his use cases in january | 17:08 |
th1a | Nice illustrations. | 17:08 |
ignas | yep | 17:08 |
th1a | Nice clean design, too. | 17:09 |
ignas | i know | 17:09 |
ignas | everything lithuanian school needs too | 17:10 |
th1a | That looks better than most of the American products I've seen. | 17:10 |
th1a | What was the conclusion of the bzr chat this morning? | 17:12 |
th1a | It seems like importing our whole history is part of the difficulty. | 17:12 |
th1a | Is that necessary? | 17:12 |
ignas | i think so, with our policy to not have unnecessary code in the repository a lot of parts of the history are important | 17:13 |
ignas | and the merge of schooltool/schoolbell is pretty recent | 17:14 |
ignas | we're not in a hurry anyway | 17:14 |
ignas | still have to clear all the things with jinty | 17:14 |
th1a | ok | 17:15 |
th1a | All right, anything else? Questions? | 17:15 |
ignas | any ideas about having some consensus way of changing quarterly plans? | 17:16 |
ignas | if there is a need | 17:16 |
th1a | Well, how about if you have the school sign off on an initial plan as soon as you can. | 17:17 |
ignas | with approval from you and from school | 17:17 |
th1a | Yes. | 17:17 |
ignas | hmm | 17:17 |
th1a | ignas: I know that might not happen until the New Year. | 17:18 |
th1a | Give me your best guess before the end of the year, though. | 17:18 |
ignas | should I plan on overlap with Belgian feature set, or we should just plan for the worst case (separate codebases) and keep the commonalities as a bonus for successful cooperation? | 17:19 |
th1a | We should plan for overlap. | 17:19 |
th1a | As much is practical. | 17:19 |
ignas | depending on someone else to do the feature might be dangerous, but we still have to try to gain as much as possible from possible overlaps | 17:19 |
th1a | It is tricky. | 17:20 |
ignas | at the moment we have that - part of jfroche's work is blocked on me fixing the person | 17:20 |
ignas | and maybe in such cases it would be better to just work on these issues separately | 17:21 |
ignas | if one fails - the other might succeed etc ;) | 17:21 |
th1a | There's no perfect solution. | 17:21 |
th1a | I guess my point is to TRY to be efficient in dividing work. | 17:22 |
ignas | my points are a bit contradicting - setting quarterly goals that are achievable even if jfroche won't be able to help me at all, and helping him as much as possible by providing support, improving core schooltool, cooperating on overlapping features | 17:25 |
th1a | Well, I suppose one reason to set the goals is to make clear what's most important. | 17:27 |
th1a | The primary thing for you is to deploy SchoolTool at the Lyceum. | 17:27 |
th1a | And NOT doing that because of your other priorities is not acceptable. | 17:28 |
ignas | sounds clear | 17:29 |
th1a | So perhaps the right way to look at it is to plan for the worst case scenario, you're writing all this yourself, | 17:29 |
th1a | but hopefully you can use some code from jfroche, and hopefully that compensates for the time spent collaborating. | 17:30 |
ignas | ok | 17:30 |
ignas | now as upcoming CanDo meetings are canceled | 17:30 |
ignas | maybe you know what their plans were for resource booking? | 17:31 |
ignas | apparently schooltool already supports their usecase, just that if they have enough time - i know a couple of things that could be improved in that area ;) | 17:31 |
th1a | pcardune and Lumiere were discussing that recently, I think. | 17:33 |
ignas | hmm, in #schooltool ? | 17:33 |
th1a | I imagine they'll continue discussing it. | 17:33 |
th1a | Yes. | 17:33 |
th1a | Last week. | 17:33 |
ignas | i'll look for that | 17:35 |
th1a | Hm... I seem to be losing my signal. | 17:35 |
th1a | ignas: Don't be afraid to send an email about it. | 17:36 |
ignas | :) | 17:36 |
jfroche | th1a: i ll provide specs for the LEJ server | 17:36 |
jfroche | but wondering if they will really accept to pay it | 17:37 |
th1a | They want to host it locally? | 17:37 |
th1a | Can't use our server? | 17:37 |
th1a | Well, let's wrap this up. | 17:41 |
th1a | Have a Merry Christmas and Happy New Year everyone. | 17:42 |
jfroche | th1a: they want to keep things locally | 17:42 |
th1a | I guess I should have included a server in my budget. | 17:43 |
jfroche | no | 17:43 |
jfroche | did you recieve Nicolas email ? | 17:43 |
jfroche | he ll try to get it via the school parents commity | 17:43 |
th1a | OK. Yes, I need to reply to Nicolas's email. | 17:43 |
* th1a drops the bag of gravel. | 17:46 | |
jfroche | have a nice Christmas and happy new year too! | 17:49 |
ignas | happy happy happy to everyone ;) | 17:52 |
*** wdickers has joined #schooltool | 17:57 | |
th1a | hi wdickers | 17:58 |
wdickers | hello | 17:58 |
wdickers | Alan and I are a little confused about the order of events when a SIF_Event message is sent to an agent. | 18:00 |
wdickers | The spec gives an example of the agent needing more information, so it sends out a SIF_Request before sending out the intermediate ack | 18:01 |
th1a | Huh? | 18:01 |
th1a | What is happening? | 18:01 |
th1a | Start at the beginning. | 18:02 |
*** aelkner has joined #schooltool | 18:03 | |
wdickers | morning | 18:03 |
Lumiere | hi | 18:03 |
aelkner | Good morning. | 18:03 |
wdickers | on page 26 of the spec it talks about what happens when a SIF_Event is sent to the agent from the ZIS | 18:03 |
ddaa | ignas: ping | 18:03 |
ignas | ddaa: pong | 18:04 |
ddaa | ignas: just out of curiosity, what operating system are you running? | 18:04 |
ignas | the true one :) | 18:05 |
th1a | wdickers: Page 26 by printed page number? | 18:05 |
ddaa | ignas: Edgy? | 18:05 |
ignas | yep | 18:05 |
ddaa | cool | 18:05 |
aelkner | wdickers: looking now... | 18:05 |
wdickers | No, page 15 on printed | 18:05 |
ddaa | just making sure that if it works for me, it can reasonably work for you :) | 18:05 |
aelkner | We were looking at that on Sat. We got to page 16 where the acks where described. | 18:06 |
aelkner | 17 even. | 18:06 |
aelkner | Remember the Agent Local Queue section? | 18:07 |
aelkner | We decided not to consider the case where the agent has its own queue for now. | 18:07 |
Lumiere | ignas, th1a: I chatted with Eldar at the sprint saturday | 18:07 |
ignas | yes | 18:07 |
wdickers | Yes, but I would like to ask th1a about the order when the agent gets a SIF_Event. Remember, we were confused when it requested information before sending an ack? | 18:08 |
Lumiere | I'm going to work out our list of use cases this week | 18:08 |
Lumiere | I spent last week beating up myself for the sprint | 18:08 |
aelkner | thla: are you tere? | 18:09 |
th1a | aelkner: Right. Don't worry about that. | 18:09 |
th1a | Here's the sequence. | 18:09 |
th1a | Agent sends GetMessage. | 18:09 |
th1a | ZIS looks in the agent's queue, and pulls off an event. | 18:09 |
th1a | ZIS sends event to agent. | 18:09 |
th1a | Hm... perhaps I'm not here. | 18:09 |
th1a | I seem to be having connectivity problems. | 18:09 |
wdickers | I see you th1a | 18:09 |
aelkner | me, too. | 18:10 |
wdickers | But our problem is right after that. In the spec, the agent needs an object to resolve the event, so it sends out a request to the ZIS /before/ sending an intermediate ack to the ZIS | 18:10 |
aelkner | That IS what the spec says. | 18:11 |
th1a | Did you get the beginning of my explanation? | 18:11 |
aelkner | We got up to "ZIS sends and event..." | 18:11 |
th1a | If the agent can quickly take the action called for in the Ack, it does so and sends and immediate Ack. | 18:13 |
th1a | If it is going to take a while, it sends and intermediate Ack, and then a final Ack when it is done. | 18:13 |
th1a | That's pretty much it. | 18:13 |
th1a | I think you guys are reading too deeply into the SMB explanation. | 18:13 |
aelkner | It gives an example, so we thought it worth following. | 18:14 |
aelkner | Will, we could also not worry about it if Tom suggests so. | 18:15 |
wdickers | yeah, I guess so | 18:15 |
aelkner | thla: section 3.4 talks about DTDs, but you downloaded XSDs from the site, right? | 18:16 |
th1a | From the agent's point of view, it is pretty simple. | 18:16 |
th1a | From the ZIS's point of view, it is a bit involved. | 18:16 |
th1a | Do you understand what the SMB is for? | 18:16 |
th1a | Yes, DTD's are on the way out. | 18:16 |
wdickers | One last question about acks: to what is an ack a response? Are all messages responded to with an ack? | 18:17 |
aelkner | To prevent deadlocking. | 18:17 |
wdickers | Yes, to avoid a deadlock | 18:17 |
aelkner | Fair question. | 18:17 |
th1a | Um... I don't think you generally Ack an Ack. | 18:17 |
th1a | Otherwise, pretty much everything is Acked. | 18:17 |
th1a | But it has to end sometime ;-) | 18:18 |
aelkner | That's why Will asked about the SMB example. | 18:18 |
aelkner | It said to respond to the event with a request before sending the ack. | 18:18 |
aelkner | That was confusing. | 18:18 |
aelkner | It is a good case to discuss. | 18:18 |
wdickers | gotcha | 18:18 |
aelkner | The agent receives an event for which it doesn't have an immediate response. | 18:19 |
aelkner | It need to ask for information. | 18:19 |
Lumiere | th1a: resource scheduling is being written as a draft spec on the cando wiki | 18:20 |
Lumiere | as soon as I get a chance | 18:20 |
Lumiere | I'll start writing the stuff we're seeing | 18:20 |
th1a | Why? | 18:21 |
th1a | Incidentally, some of the explanations are better in the 2.0 spec, so it might be helpful to reference that when you're confused. | 18:21 |
th1a | No. | 18:21 |
th1a | That shouldn't happen. | 18:21 |
th1a | Maybe it is *possible*, but it doesn't make sense. | 18:21 |
th1a | An event is add/change/delete something in the agent's database. | 18:21 |
th1a | It shouldn't require additional info. | 18:21 |
th1a | Lumiere: Thanks. | 18:21 |
aelkner | So it should intermediate ack followed bt the request for the information. | 18:21 |
aelkner | The spec says to request the info first, then ack second. | 18:21 |
aelkner | thla: is the spec wong here? | 18:21 |
Lumiere | but I was busy with cando sprint stuff... so just trying to get to it | 18:21 |
Lumiere | (first I need to shop for wine) | 18:22 |
th1a | aelkner: Are you looking at 3.3.5–3: Agent Message Queue - Example 1 | 18:22 |
aelkner | 3.3.5.6. | 18:23 |
aelkner | Use of SMB. | 18:23 |
aelkner | The example is clear enough, just doesn't seem accurate. | 18:23 |
aelkner | Oh yes, 3.3.5-3 is the figure. | 18:24 |
aelkner | of Table. | 18:24 |
aelkner | It seems to be mistaken, that's all. | 18:24 |
aelkner | Perhaps we don't need to worry about the example. | 18:25 |
th1a | Yes, that example appears to be screwed up. | 18:25 |
aelkner | God. Then it's not us. | 18:26 |
aelkner | Good, not god. | 18:26 |
aelkner | We will assume that it means what we would think makes sense. | 18:26 |
wdickers | ahaha, all that pain for nothing | 18:26 |
aelkner | Besides, it's more complex than any of our use cases. | 18:26 |
aelkner | Not for nothing. | 18:27 |
aelkner | We benefitted from thinking about SMB, even if the example lead us astry a bit. | 18:27 |
Lumiere | wow | 18:27 |
Lumiere | so, aelkner or wdickers... who will submit the bug to the SIF people XD | 18:28 |
aelkner | thla: I thought we would avoid the 2.0 spec for now considering that you've been coding for 1.5. | 18:28 |
th1a | I really think it is helpful to do the easy stuff first before worrying about the few hard parts. | 18:28 |
aelkner | XD? What's that? | 18:28 |
wdickers | Laughter | 18:29 |
Lumiere | cross-eyes and laughing | 18:29 |
aelkner | What are we laugging about? | 18:29 |
th1a | aelkner: I'm not saying implementing 2.0, but I'm sure they've fixed that bug in the spec, and there are more detailed explanations of how things are handled on the agent side. | 18:29 |
th1a | Laughing at your misfortune. | 18:29 |
Lumiere | and that I am involved in it | 18:29 |
Lumiere | I was just a misfortune machine saturday | 18:29 |
th1a | Also, you can navigate the 2.0 spec via the web instead of giant pdf. | 18:30 |
aelkner | I don't the misfortune. We're just working the problem. | 18:30 |
aelkner | see the misfortune. | 18:30 |
*** thisfred has quit IRC | 18:30 | |
th1a | The misfortune of focusing on a bug in the spec. | 18:31 |
aelkner | Is your code going to match the 2.0 spec. Reason being, we like boing able to see the code match the spec. | 18:31 |
aelkner | It helps us to understand it. | 18:32 |
aelkner | And follow your thought process in writing the code. | 18:32 |
wdickers | Well this table is in chronological order and seems to be the same structure | 18:32 |
wdickers | http://specification.sifinfo.org/Implementation/2.0/Messaging.html#SIF_Event | 18:32 |
th1a | The basic mechanics haven't changed in 2.0, so it is reasonable to use it as a reference for this stuff. | 18:33 |
aelkner | wdickers: that sounds like a good idea. | 18:34 |
aelkner | The new spec looks like it's easier to follow, anyway. | 18:34 |
aelkner | Section 4 is the one to digest, from the beginning. | 18:36 |
aelkner | Let's see if Tom has coded each of the messages described therein. | 18:36 |
th1a | You can see that here https://www.hosted-projects.com/trac/sif/pyagentlib ;-) | 18:37 |
wdickers | hmm, well I'll check the logs and the 2.0 spec for a flow chart of what we want to see. | 18:39 |
wdickers | But my time has run out, I'll see you guys later | 18:39 |
aelkner | Will, we'll go over this stuff tonight if you're available. | 18:39 |
*** wdickers has quit IRC | 18:39 | |
*** aelkner has quit IRC | 18:41 | |
*** ignas has quit IRC | 19:53 | |
*** jinty has quit IRC | 19:58 | |
*** yuy has joined #schooltool | 20:27 | |
*** aelkner has joined #schooltool | 20:27 | |
*** aelkner has joined #schooltool | 20:29 | |
yuy | Stephan? | 20:30 |
aelkner | Linda, you're in! | 20:31 |
yuy | Yes. Now we wait for Stephan. | 20:31 |
aelkner | srichter: are you there? | 20:31 |
Lumiere | hi Linda | 20:31 |
srichter | aelkner: here | 20:31 |
srichter | yuy: aelkner: hello everyone | 20:32 |
aelkner | Hey Stephan! | 20:32 |
yuy | Lumiere: hey. | 20:32 |
yuy | Okay. Shall we start? | 20:32 |
srichter | shoot! :-) | 20:32 |
aelkner | Linda and I have been editing your book, so we thought we'd check in with you. | 20:32 |
aelkner | First our goals are three-fold: | 20:33 |
aelkner | 1) learn Zope using the book. | 20:33 |
yuy | 2) make edits | 20:33 |
aelkner | 2) correct any spelling or gramatical errrors. | 20:33 |
aelkner | 3) Make sure the code samples are still functioning | 20:33 |
srichter | ok | 20:34 |
aelkner | For 2), I thought you wouldn't mind if Linda went ahead and made those types of changes without checking with you. | 20:34 |
srichter | :-) it's better this way | 20:34 |
yuy | although I will say that we agreed on this for grammatical and syntax errors, like the spelling 'puython' to 'python' | 20:35 |
aelkner | In the process of going over the book, a fourth goal emerged. | 20:35 |
aelkner | Could we restructure the chapters a little to make it useful for the beginner? | 20:36 |
yuy | Part I consists of a lot of theory, and contribution to Zope itself. | 20:36 |
srichter | aelkner: actually, I was thinking about transfering the ownership to you guys completely | 20:36 |
srichter | basically: here is all I have use it to your liking | 20:37 |
aelkner | If that's the case, then we could take it upon ourselves. | 20:37 |
srichter | yep | 20:37 |
aelkner | Jeff and Dave Welsh are having a lot of succes recruiting high school students/ | 20:37 |
srichter | that's so great | 20:37 |
aelkner | WE would like to have a book they could use when they get started in the summer. | 20:37 |
srichter | makes me happy! :-) | 20:38 |
srichter | aelkner: yep, that would be great | 20:38 |
aelkner | I would be happy to work with Linda on making the book something they could use to get started. | 20:38 |
aelkner | We wouldn't need to bother you with minute details then. | 20:38 |
srichter | right | 20:38 |
yuy | aelkner: Right. But when something like moving Part III before Part I, oughtn't we contact Stephan for that? | 20:39 |
srichter | I am really busy and I feel really bad with my constant delayed responses | 20:39 |
aelkner | We'll just send you the updates every couple of weeks so that you see what we've been doing. | 20:39 |
srichter | yuy: not necessary; I am giving you all the ownership, so you can do whatever you like | 20:39 |
aelkner | yuy: how do you lke that? :) | 20:39 |
srichter | yuy: aelkner: and I will help you guys with some guidance for the chapters that are hopelessly out of date | 20:39 |
yuy | srichter: ie., the chapters about the wikis? | 20:40 |
srichter | I was thinking of the chapters covering Local Utilities, for exmaple | 20:41 |
srichter | yuy: it would be fantastic, if you could update the wikis | 20:41 |
srichter | yuy: the Makefiles have all the code in them to generate HTML + doing the upload to zope.org | 20:41 |
aelkner | yuy: You mean the chapter on installing new Zope packages, right? | 20:43 |
srichter | ah, ok | 20:43 |
yuy | aelkner: Actually, I had meant Chapter 3.5. It talks about adding a sample wiki. | 20:43 |
yuy | I'm going through the steps really quickly, because I remembered that last time I had no luck getting them up. | 20:44 |
srichter | yeah, this is another chapter that would need some thinking and restructuring | 20:44 |
aelkner | srichter: that's the chapter that we thought would probably be better near the end of the book. | 20:44 |
aelkner | After the student has experience making their own packages. | 20:44 |
aelkner | Also chapter 4: setting up virtual hosting. | 20:45 |
srichter | aelkner: right | 20:46 |
aelkner | Also all of part II, cpaters 5-12 should come later. | 20:46 |
srichter | in fact, my recent experience has shown that the book is backwards | 20:46 |
srichter | I have started to produce training materials that have a very different structure | 20:46 |
srichter | I was thinking about having you help me with that, but I would have to clear up some copyright things first | 20:47 |
aelkner | Although chapter 7 might come sooner, after the student has built the first component | 20:47 |
yuy | srichter: Is it anything that we can incorporate into the book right now? | 20:47 |
aelkner | Chapter 8, too looks like something that is interesting to the beginner. | 20:47 |
srichter | I can send you the outline, but anything else needs a couple of days to figure out the copyright | 20:47 |
aelkner | Ok. We'll hold off on restructuring until we hear from you on the copyright. | 20:48 |
aelkner | srichter: in the meantime, a strategic question: | 20:49 |
srichter | aelkner: yuy: Okay, outline sent | 20:49 |
yuy | Lovely Systems? | 20:50 |
aelkner | In chapter 13, you have some of the source files printed and some you just refer the user to the svn repository. | 20:50 |
yuy | aelkner: Sometimes they are incredibly similar, and do not need reprinting. | 20:51 |
srichter | yuy: it is a company in Austria for which I developed the original outline | 20:51 |
yuy | aelkner: *to others already printed | 20:51 |
aelkner | Would you be alright with the idea of printing all of the sample files even if they are in the repositry. | 20:51 |
aelkner | I think it's more complete and easier for the user that doesn't have internet access. | 20:51 |
aelkner | They may ust be reading the book away from a computer. | 20:51 |
srichter | yuy: if the printed and SVN version are not equal, then the text is outdated | 20:51 |
srichter | aelkner: that's fine with me | 20:52 |
aelkner | yuy: we will keep the test up to date. | 20:52 |
srichter | this actually points out a huge problem with the book; it develops one large and complete example | 20:52 |
aelkner | how's that a problem? | 20:53 |
srichter | I am now convinced that this is a bad strategy | 20:53 |
srichter | it is too complex | 20:53 |
yuy | srichter: Isn't that a good thing because it keeps the reader focused on how the different components can be applied to a single situation. | 20:53 |
srichter | you have to explain a lot of things that are irrelevant to the discussed topic | 20:53 |
yuy | and it is impossible to create an all-encompassing example? | 20:53 |
srichter | yuy: yes, this is one advantage of the approach | 20:53 |
srichter | yuy: no, it is not impossible, but generally not a good idea | 20:54 |
aelkner | Then again, if you keep it all as one project, it simulates the real world of developing something like cando. | 20:54 |
srichter | yuy: think of your HS classes | 20:54 |
srichter | yuy: you always learn small pieces; it is usually up to a final project to pull many things together | 20:54 |
yuy | we have different examples. do not dispose of the entire connectivity of the exercises, but create several large projects thorughout the book. | 20:54 |
aelkner | Think of this as a final project for advanced students. | 20:55 |
aelkner | It's ok for it to be long and complex as long as it starts simple and builds. | 20:55 |
srichter | aelkner: yes, you are right; this is the very big advantage and the purpose of the book: Zope 3 can do complex things | 20:55 |
aelkner | We just need to get simple things done first to get the student excited about early success. | 20:56 |
aelkner | Then as we add more complex stuff to the project, the student needs to learn more complex things. | 20:56 |
aelkner | For instance, I don't know if marker interfaces should come up first. | 20:56 |
aelkner | If the student doesn't see the application right away, it only confuses. | 20:57 |
yuy | Okay. But marker interfaces are something good to learn overall from the start, is what I gathered from the book. | 20:58 |
yuy | It builds the base to start, doesn't it? | 20:58 |
srichter | aelkner: ah, marker interfaces should be first :-) | 20:58 |
srichter | aelkner: because they demonstrate the simplest use of an interface | 20:59 |
srichter | aelkner: makring something, so we can register against it | 20:59 |
aelkner | Do we register against it right away? | 20:59 |
aelkner | I didn't get that far yet. | 21:00 |
yuy | srichter: Although, you will have to note that although I have not completed Part I and went directly to the hands-on Part III, they were mentioned in Part III. That's why, as Alan already said, we were thinking of moving the hands-on part more to the beginning. | 21:00 |
aelkner | right. | 21:00 |
aelkner | And bring marker interfaces into the discussion only if they are used right away. | 21:01 |
yuy | aelkner: That's the thing, though. They always are... | 21:01 |
aelkner | Could you point out where? | 21:01 |
srichter | right, the book is meant to be read starting in part III | 21:01 |
Lumiere | then shouldn't that be part I? | 21:02 |
srichter | It just seemed odd to have the PartI and II material later on | 21:02 |
yuy | srichter: So... why not start it there? I see the advantages of having background before... but theoretical concepts would be wrapped up later, wouldn't they? | 21:02 |
srichter | but that is definitely a style and personal liking question | 21:02 |
yuy | ah. | 21:02 |
aelkner | It always depends on the audience. | 21:03 |
yuy | Audience: defined as potential developers. | 21:03 |
aelkner | srichter: I think you had the zope II developer in mind, am I right? | 21:03 |
srichter | no, I had the pure Python programmer in mind | 21:04 |
srichter | I expected a certain level of programmer zen | 21:04 |
aelkner | Someone with advanced python knowledge. | 21:04 |
srichter | yes | 21:04 |
aelkner | That's why you got into discussing adapter and the like so eary. | 21:04 |
srichter | right, I basically wanted to season the developer for what they are in for. | 21:05 |
srichter | the training outline I sent you guys, starts the other way around | 21:05 |
srichter | it discusses resources and views first | 21:05 |
aelkner | Only thing is that a lot of people, especially young students, need to see stuff in action as they learn. | 21:05 |
srichter | in fact of a 4 day training + 1 day final project, I only started talking about the CA and adapters on the third day! | 21:06 |
aelkner | I'm no differeent. | 21:06 |
aelkner | That sounds like something that could guide us. | 21:06 |
srichter | aelkner: the training outline aims at early success | 21:06 |
aelkner | Assuming you have the copyright issue worked out, should we restructure the book to follow the training outline? | 21:06 |
srichter | aelkner: and I was able to split most topics in 30 mins chunks | 21:07 |
srichter | aelkner: in case the copyright works out, we should reexamine the net worth of the book, or whether it would be better to work on something based on the training material | 21:07 |
aelkner | I could see that being effective. | 21:08 |
yuy | srichter: aelkner: just wanted to let you know I'm leaving in about two minutes, if I was needed for anything. | 21:08 |
srichter | yuy: thanks a lot for joining in | 21:09 |
aelkner | That's ok.. The ball's in Stepan's court for now. | 21:09 |
srichter | yuy: enjoy Christmas; I will be in touch via E-mail | 21:09 |
aelkner | How soon do you think you'll know about the copyright? | 21:09 |
yuy | yuy: Happy Christmas to you, too. I check my email everyday. | 21:09 |
aelkner | yuy: we'll continue learning until then. | 21:09 |
yuy | aelkner: Fine. | 21:10 |
srichter | aelkner: are you a registered user? | 21:10 |
aelkner | How do you mean? | 21:10 |
aelkner | Registered where? | 21:10 |
srichter | with IRC | 21:10 |
*** yuy has left #schooltool | 21:11 | |
aelkner | Do you mean the provate chat? | 21:11 |
srichter | yeah | 21:11 |
aelkner | I sent you a message there. You didn't get it? | 21:11 |
srichter | np | 21:11 |
aelkner | I want to solve this problem. Are you saying you didn't get my message? | 21:12 |
srichter | you must be a registered user (i.e. use /id pwd) to send pricate messages | 21:12 |
srichter | right, I did not get it | 21:12 |
srichter | aelkner: yeah, I checked, you are not identified | 21:12 |
aelkner | what exactly do I need to do to register, and is it a one-tiome thing? | 21:13 |
srichter | yeah, one-time at http://freenode.net | 21:13 |
srichter | then, whenever you log in, you provide /id pwd | 21:13 |
aelkner | group registration? | 21:14 |
srichter | hold on, I am trying to find out how to do it | 21:14 |
srichter | aelkner: do /msg NickServ | 21:15 |
srichter | then the following: | 21:15 |
srichter | help | 21:15 |
srichter | register pwd | 21:15 |
srichter | id pwd | 21:16 |
aelkner | I typed "/msg NickServe" and got "Usage: MSG <nick> <message>, sends a private message" | 21:16 |
srichter | without the "e" | 21:16 |
aelkner | I did do it without the "e", that was a typo. | 21:17 |
srichter | that should have openened a new chat window for you | 21:17 |
srichter | so try this: /msg NickServ register pwd | 21:17 |
srichter | then this: /msg NickServ id pwd | 21:17 |
*** ignas has joined #schooltool | 21:18 | |
aelkner | I assume you mean for me to fill in aelkner and my password for "id pwd" | 21:18 |
srichter | no | 21:18 |
*** mgedmin has quit IRC | 21:18 | |
srichter | "id" is a command in nickserv | 21:19 |
aelkner | Ok I did it literally. | 21:19 |
srichter | the system knows your nickname | 21:19 |
srichter | yep, you are identified now | 21:19 |
*** aelkner has quit IRC | 21:32 | |
Lumiere | just need to get an affiliation | 21:32 |
*** ignas has quit IRC | 22:24 | |
*** ddaa has quit IRC | 23:26 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!