[Chandler-dev] [Sum] May 22 - 28

Wed Jun 7 17:32:35 PDT 2006

A few of these seem to have slipped through the previous summary, so 
technically this covers May 18 - 28...

Build and release
-----------------
*0.7alpha2, 0.7alpha3*
A branch was created for alpha2 and the trunk opened up to alpha3 
development Tue, May 23.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005947.html

*0.7alpha2*
QA signed off on 0.7alpha2-rc1 on Wed, May 24. Some critical bugs were 
deferred to alpha3, so you take some risk running alpha2.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005970.html

Bear and Pieter negotiated the final steps to getting the bits out to 
the web, and Bear closed the alpha2 branch. Alpha2 released Friday May 26.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005994.html

*0.7alpha3*
Alpha3 will be a short cycle, to focus on fixing the most important 
'dogfood' problems for our few current users. This includes background 
sync, intel mac support, and selected performance fixes. Estimated 
dates: June 21 (code freeze), July 7 (release).
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005956.html

*Intel Mac*
Andi got past one of the hurdles with a native Intel Mac build 
(PyLucene). He got patches for gcj from Sandro Tolaini, a Mac gcj user. 
Andi didn't do extensive performance measurements, but gave a few 
impressive gains (initial commit went from 14s -> 4s).
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005943.html

John T and Ted offered to be testers (they have Intel Mac hardware). If 
you have Intel Mac hardware, you can now try running Chandler natively 
by doing a "make install" build. SSL problems were noted in this 
message, but Heikki fixed them (captured in a later message).
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005971.html

Coding and design discussions
-----------------------------
*stamping as annotations*
Grant asked if kinds can customize behavior when getting stamped. The 
example he gave: a cert might want to encapsulate itself as an 
attachment when stamped as mail, events would turn themselves into 
invitations. Phillip replied that you could delegate behavior back to 
the underlying item -- the annotation has an "itsItem" attribute, so the 
stamp method can call back to a method on the original item 
"self.itsItem.whatever()".

Grant also brought up the use case of having items adapt themselves when 
being displayed in different UI contexts. Phillip rephrased that as the 
UI asking for annotations that are specific to the display context. 
Phillip pointed out that the point of using Annotations is to annotate 
items with additional data, not to substitute for adaptation. Stamping 
meshes pretty well with annotations. Adaptation is an independent and 
useful concept in its own right, but not really a solution to the 
stamping problem, as it doesn't address how attributes get stored, 
indexed, displayed, etc. Annotation solves these problems nicely. The 
rest of the gap (for stamping) can be covered by adding extra features 
to the Stamp base class (e.g. return all stamps that implement some 
interface). Phillip argued that it would be easier on developers to 
cover this with concepts that already exist in Chandler (annotations), 
as its one less thing to learn.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005929.html

Grant's plan is to try a stamping-as-annotation implementation.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005939.html

*i18n progress in Chandler*
Markku summarized his work on i18n. This included work on the 
wxGetTranslation-MessageFactory pipe, investigating the use of XRC based 
dialogs, modifying functional tests to test unicode support, filesystem 
unicode tests, and investigation into incremental builds for wxPython. 
The functional tests are waiting on some changes to the testing 
environment, expected next week.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005935.html

Grant explained how to get svn to accept non-ascii filenames on the mac 
(where UTF-8 is the filesystem encoding). This requires doing "export 
LANG=en_US.UTF-8" in the shell, otherwise filenames with non-ascii 
characters cause major problems with svn.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005936.html

Grant further explained that its better to avoid non-ascii filenames in 
svn, to avoid cross platform issues. He linked to discussions of the 
problem with more detail.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005937.html

Brian argued that we should have at least one test in Chandler that does 
try to load a file with a non-ascii name/path -- an .ics file would be a 
good example. As a hack, we could do this by renaming the file to the 
non-ascii name during the test and then restoring to something less 
offensive to svn.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005941.html

Heikki pointed out that he does something similar for crypto tests. He 
linked to the test code as an example.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005942.html

*sharing format discussions*
John Townsend pointed out that they are trying to get a sharing format 
discussion going on the cosmo list.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005949.html

*New test framework, logging defaults*
Mikeal described logging features in the new test framework. Report 
levels (suite, test, action, report) and level masking allow one to 
control output by level. 4 debug settings are exposed, the combinations 
of log failures only/log all output and observe masking/don't observe 
masking. One can specify stdout or file output. Each of these options 
can be set manually, Mikeal asked for feedback on the defaults.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005950.html

Heikki expressed a preference for minimal output by default (he 
mentioned the Python unittest ... as an example). If an error occurs, 
more info is helpful, including location of the error and why the error 
happened. Mikeal argued that its more helpful to have readable output. 
The framework will pass along the pass/fail comment strings, and test 
writers are trying to be good about providing them. Tracebacks are 
handled better, logged to both stdout and the logfile. More 
documentation to come (on the wiki).
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005958.html

Andi suggested that the defaults be the same as the ones on tinderbox. 
Mikeal replied that it actually makes sense to make them different (and 
is easy to do) -- giving more human readable info defaults for day to 
day use.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005959.html

Bryan asked why we're not using Python's logging. Mikeal explained that 
it would have taken longer. Some initial work is happening for a quick 
patch up, with a more elaborate longer term solution. One important 
concern is the integrity of the timing #s. Output is serialized and sent 
to an output object in tuples. The output can be offloaded to some 
central server, or stored and processed later (dump to a logger, sql 
statements, file, stdout, etc.) The new framework is designed to handle 
end to end testing: chandler, cosmo, and scooby.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005962.html

*Chandler background full-text indexing*
Andi added support for doing full text indexing with PyLucene in a 
background thread, to keep the UI thread more responsive. By default, 
the UI view will not do any PyLucene indexing during commit. The Lucene 
view picks up changes every minute and adds them to the Lucene index in 
the background. The old way is available with a command line flag. By 
default, a given view will do indexing during commit. An API is 
available to use the background indexer. The background indexer is 
currently hardcoded to run every minute -- we could change this to be 
tied to a user preference. An API is available to kick off the indexing 
in the background thread right away. PyLucene indexing is also 
considerably faster -- indexing happens in memory and is written out in 
one go.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005955.html

John asked about always indexing in the background, getting rid of the 
old behavior. Andi pointed out that the old behavior is more predictable 
which might be useful for testing, in particular performance testing.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005964.html

Heikki asked for a centralized way of forcing indexing to happen before 
using functionality that requires up to date indexing (vs 
once-a-minute). He gave an example of searching after sync'ing 
collections. Heikki is concerned that it is not reliable to add spot 
checks to the code to force indexing, but wasn't sure where the choke 
point should be. Andi mentioned the notifyIndexer() API. He also pointed 
out that collection syncing happens in a background thread as well, not 
in the UI view. The background thread that does collection sync will do 
index updating during commit (the original behavior), so when sync 
completes the indexes should be up to date. Only the UI thread avoids 
indexing during commit, as the UI thread needs to remain responsive to 
the user.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005966.html

Tinderbox perf data indicates the new code halved the time to import a 
large calendar. Overall, the new code is ~5% faster than it was before 
we started indexing, on Windows. Heikki noted that will need to add new 
tests and modify existing ones to work with indexing in a deterministic 
way, measuring indexing performance. Andi suggested that for meaningful 
time comparisons, we should run indexing during commit (as it was 
originally), or not at all, if the test doesn't depend on indexes. 
Command line flags can set this up, so that background indexing doesn't 
kick in at random during the test.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005966.html

*Talkback feedback*
Heikki is working on a crash reporting system for Chandler, not unlike 
Mozilla's Talkback. Talkback focuses on reporting C/C++ stack traces for 
hard crashes. Chandler's system should allow users to report uncaught 
Python tracebacks with additional system info. Heikki has client side 
code, minus the code that actually sends the report. Heikki observed 
that some webapps have similar functionality, so cross-posted to scooby. 
Jared and Heikki want feedback about the server side element of the 
feature. They propose using http post to send a single text file. XML? 
Plain text? Reports may need to be dumped into a database for search, 
processing. Perhaps discard reports after a certain time period. A 
simple query/display app would be useful, some access limited to staff 
or core team but stacktraces available to all and associated with bugs. 
Server side work should be open source.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005977.html

*Summer of Code: Multivariate Analysis for PIM data*
Philippe gave comments on Xun's summer of code project. The general idea 
of the project is to use multivariate analysis tools to create a model 
of chandler pim data and map newly acquired data, automatically tagging 
the data. One idea is to mark or tag new items as they come in as 
belonging to existing collections. Another is to cluster or segment 
data, assigning each cluster a tag or set of tags. See the post for much 
more detailed information on the project, including a staged 
implementation plan.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005978.html

*Bye bye Globals.views*
John is removing "Globals.views". To make CallItemMethodAsync useful 
without Globals.views, he modified the API to accept a block name 
(string) instead of the item. In his example, he passed "MainView" as 
the first argument instead of "Globals.views[0]". He updated the Amazon 
parcel to message blocks by name, which simplified the code nicely.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005983.html

Q & A for new contributors
--------------------------
*Feeds parcel tutorial woes*
Darshana tried out the tutorial and ran into a few snags. Bear responded 
with some tips about common problems setting up one's environment that 
cause import errors.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005969.html

*Getting started on Chandler*
Grant answered some questions posed by a Summer of Code intern, Ernesto. 
  Grant noted that the feeds tutorial was written for the 0.6.x release, 
and gave instructions for setting this code up to work through the 
tutorial. He explained how to get the source code for a full build, how 
to get documentation downloaded to read offline, and discussed 
development environments.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005995.html

Meetings and announcements
--------------------------
Markku organized a meeting about Python eggs, to come up to speed on how 
eggs work and to understand i18n/egg issues. He gave links to the 
existing documentation. Bear suggested that people read the code of the 
feeds parcel as a good example.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005974.html

Philippe noted that wx has a Summer of Code project related to i18n: 
"Right to Left language support".
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005980.html

Apps team meeting
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005981.html

Chandler dev meeting (order intel mac hardware, finish up alpha2)
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005985.html