Build, release, QA
------------------
*Upgrading Linux target platform to Ubuntu*
Bear explained that we successfully upgraded our full build Tinderbox to
Ubuntu (Breezy Badger). We'll soon generate builds that target "modern"
Linux distros. This should be transparent for most, but may cause
problems for older distros like FC4. Please report any issues running
Chandler on Linux.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006039.html
*Changes to list of supported platforms*
Bear gave us the lowdown on recent changes to supported platforms...
Linux: We'll be using Ubuntu as the official build platform starting
June 9. All continuous builds and checkpoints will be done on Ubuntu.
OSAF's build, tinderbox, qa, and shared dev machines have been updated.
Intel Mac: We have new hardware, and builds are going well. When full
and quick tinderboxes are created, Bear will add Intel Mac to the list
of supported platforms.
Windows: no real change, although Andi did test Chandler on Win2k
recently and resolved some problems. 0.7alpha3 should work on win2k.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006076.html
Grant asked about the Ubuntu version. Heikki responded "Breezy". We
haven't yet tested Dapper, but it should be easy to switch once we've
got the infrastructure set up.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006079.html
*Cosmo-demo upgrade*
Jared sent a notice to all lists that cosmo-demo is being upgraded to
0.4 and all data will be wiped clean. Accounts will need to be
recreated, and collections republished (causing new tickets to be
created for the collections).
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006044.html
*New Test Framework*
Mikeal announced that QA has been working on a new test framework.
They've been working on a branch (test_framework). They are ready to
merge the changes into the trunk. The changes are limited to Utility.py,
scripting/script.py and a new tools/cats directory. Mikeal has a wiki
page that outlines changes and improvements:
http://wiki.osafoundation.org/bin/view/Journal/MikealRogers20060605NewCATSFramework
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006030.html
Brian K asked about recent i18n additions to CATS. Mikeal replied that
they discussed the i18n changes and have a plan. They will make changes
to their new tests when they merge the test_framework branch into the trunk.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006032.html
Phillip Eby asked if the framework interoperates with the unittest
framework. He explained that it would be helpful if tests could be
discovered using existing unittest based tools. Individual projects
could be fully testable with "setup.py test". Mikeal responded that this
update to the framework is a short term update to fix the most painful
problems, and that the more ambitious framework (OAF) will be used to
test all 3 projects, and will integrate with unittest.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006034.html
*Background sync*
I asked that we start getting more people to use and test the background
sync branch.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006036.html
Morgen proposed that we go ahead and land the background
sync branch into the trunk. He noted that stamping/unstamping an already
shared item isn't yet supported (merging this kind of change between
views isn't yet well supported). He also pointed out that if/when the
stamping implementation changes to use annotations, the view merging
code won't have to deal with the current stamping case. Morgen polled
the list: is it ok to break shared-item-stamping for a while and merge
the branch soon?
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006040.html
Phillipe, Grant, Reid and I +1'd Morgen's proposal. Morgen explained
that sync'ing with the office calendar will work, even with stamped
events. The problem comes when you stamp an already shared event and
sync it. Morgen will look at making this case fail gracefully.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006048.html
Performance
-----------
*Performance Targets*
Heikki asked what the biggest performance headaches are for end users,
subjectively. He will be working on writing new test cases. Sheila
listed her top 5: (1) switching between calendars (2) overlaying
calendars (3) double clicking for new calendar event (4) stamping events
as a communications item (5) jumping to a new week.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006068.html
John suggested that (1), (2), and (5) were only slow the first time they
happened against a new repository, and thus should be rare for end
users. Sheila, Ted and Priscilla responded emphatically that these cases
are problematically slow every time, not just the first time. Ted noted
that he switches between his 5 calendars frequently, he has lots of
events in each calendar, and he goes back and forth between the current
date and a week or two ahead of time. He also echoed Sheila's
observation that creating new events is slow, and that this causes a
problem where he creates multiple events because he didn't get feedback
quickly enough. Ted notes that these use cases are slower than we'd like
even on the native Intel Mac build.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006071.html
I suggested we highlight existing tests, based on Sheila, Ted, and
Priscilla's feedback: (1) new event from double clicking, (2) overlay
calendar, (3) jump calendar by one week, and (4) stamp item. I suggested
adding one test: (5) Switching between calendars. I argued that these
tests + some sharing/syncing tests should be our focus, listed at the
top of the tinderbox list and run against repositories of different
sizes, especially the new test data set the QA team is working on. I
also suggested writing or fixing dashboard/table tests: (1) scroll
table, (2) new item from menu in dashboard, (3) switch to dashboard view.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006077.html
Heikki explained that he has tests for publishing and subscribing, but
they are not yet enabled. He asked about mail syncing. He noted that
running perf tests is time consuming, so running every test against
repositories of many sizes may not be practical. He noted the usefulness
of comparing to previous results, and that we might be able to remove a
few of the tests. Heikki pointed out that we have a few of the listed
tests already, and that the existing stamping test should suffice.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006082.html
*Profiling from test menu*
I asked if anyone thought Bug 4401 was important enough to take over and
fix: "Profiling from the test menu should capture more data".
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006075.html
i18n
----
*About box and i18n*
Brian K and Mimi agreed to move the about box html from an external
.html file to a python source file. This will allow it to be localized
more easily. Philippe had a related bug where he renamed SplashScreen.py
to AboutBox.py, as it was implementing the about box and not the splash
screen.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006041.html
*Localization, Eggs and the Repository*
Brian K brought a bug discussion to the attention of the list.
http://bugzilla.osafoundation.org/show_bug.cgi?id=6007
The main issue is that Chandler needs access to some localized strings
and resources before the Repository is created. One of the proposals was
to store paths to translation files in the repository, with some
workaround for the bootstrap/startup cases. Brian would prefer to avoid
having an edge case like this, and not depend upon the repository for
translation files. He noted that it would still be ok for an item or
block to store its translations in the repository.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006052.html
Bryan S and Heikki agreed with Brian K that translations should not have
a dependency on the Repository. John pointed everyone at an earlier
discussion (including two proposed implementations).
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006057.html
Phillip Eby pointed out that Markku's prototype is a good working
demonstration of his original proposal: an API that can find all egg
supplied resources at startup with a single scan. It doesn't need the
repository or any other special install steps. Markku posted his
prototype to Bug 5970.
https://bugzilla.osafoundation.org/show_bug.cgi?id=5970
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006058.html
Phillip quoted some code from Markku's prototype (the code loops over
the eggs on sys.path and builds an index). He proposed changing the code
to add an activation callback -- when eggs are "activated" (added to
sys.path) they can load their resources at that point. The code for
Phillip's proposal is included in the message. The callback will be
called for all eggs on sys.path at startup, and will be called by the
egg runtime for any eggs loaded later. This approach will also handle
the future case where eggs are downloaded and installed while Chandler
is running.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006063.html
John asked if the registration will only happen once, and not every time
Chandler is run (a performance win). Phillip replied in the affirmative.
Egg scanning at startup handles installParcel, parcel creation, and soon
resource checking -- all only when Chandler notices the egg contains
parcels not in the repository.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006064.html
In response to Brian K's questions, Phillip explained that Markku's
prototype code is 100% Chandler agnostic (it doesn't import any Chandler
code, make use of the Repository, or know anything about 'parcels').
Eggs publish their own i18n resources. The prototype provides an API for
looking up resources and retrieving them later. We can use it in
Chandler, and it will be available to other projects. Brian K asked if
parcels could use installParcel to install translations, and answered
his own question: No. Andi agreed.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006072.html
*i18n overview*
Brian K summarized recent progress made by himself and Markku on i18n.
1. Unit and Functional Tests now use non-ascii characters for
displayable strings.
2. Chandler works with non-ascii file paths on all 3 platforms.
3. Made decisions about how to use Python file system APIs:
- unicode to bytes: use utf8 encoding
- bytes to unicode: use sys.getfilesystemencoding()
4. Chandler uses wx to determine the OS locale. (More accurate than ICU)
5. wx localization files get loaded at startup. (Used for dialogs)
6. MessageFactory added to access wx localized strings
7. About dialog was moved from a static .html file to Python
8. Uncovered two bugs
9. Prototyped a translation loading solution that has no dependencies on
Chandler -- this will be put into place when Brian gets back.
10. Markku is working on a patch that will allow devs to use xrc files
for dialog layout and still use the translation service.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006086.html
Andi brought up a problem: this introduces a dependency on wx for i18n.
What about headless chandler? Andi asked for more details about the
problems with ICU finding the locale.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006087.html
Intern projects
---------------
*Multivariate Analysis*
After instrumenting the feed parcel to display a tag in the detail view,
Xun did some experiments with slashdot feeds. (See the message for more
details). He ran into some problems with lucene, and would be interested
in help from OSAF folks with lucene experience.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006089.html
*Natural language parsing*
Darshana Chhajed is a summer intern who will be working on natural
language parsing in Chandler. Jeffrey will be her mentor. He asked the
list for feedback on the architecture/design. (1) One goal is to parse
date/time/duration fields as they are being edited. The plan is to look
at Bear's existing work on date parsing using regular expressions. The
design would be to return a list of weighted matches for an
auto-complete drop down. (2) Another goal would be to make a
mini-command line or quick entry box more painless. In this situation
there is less context, so handling English grammar becomes important,
and regular expressions may prove less useful. The plan is to look at
toolkts like NLTK. They may be slow, so looking at relative processing
costs should be part of the investigation. (3) A third goal is to parse
emails and instant messages, e.g. stamping items with event information.
Current thinking is that (1) would be useful now, (2) useful before 1.0
and (3) useful anytime but requires more design work and has performance
issues, so not a high priority. The plan is to start with (1) and to
focus on US English parsing, creating a framework allowing for different
locale based parsing resources. Parsing resources should take a unicode
string and return a list of possible interpretations for the fields it
understands, with associated confidences. Parsing resources should be
registered to allow the appropriate parser to be used. Right direction?
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006085.html
Miscellaneous
-------------
*Plugin parcel development, feeds tutorial*
Grant ran into a few problems when updating the feeds tutorial for
0.7alpha2. Grant assumes we want the end user to download Chandler, make
a FeedsPlugin folder, create a simple setup.py, use "setup.py develop",
create a feeds subfolder and proceed with the tutorial. This is broken
right now in the end user distribution. The developer has to use
Chandler's RunPython for setup.py to work correctly. Problems include:
(1) RunPython fails on Mac (Bug 6019) (2) CHANDLERHOME must be set to
use RunPython outside of the Chandler directory (3) looks to Grant as if
RunPython.bat will never work outside of the Chandler directory on
Windows. Is there something we can do here? Interns and SoC devs should
get the source and do "make install". This solution adds requirements
(subversion, make).
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006084.html
*Styles and ConfigParser*
Philippe outlined current ad-hoc solutions to "Styles": i18n looking up
OS color and font, blocks/Styles.py, application/styles.py, a task for a
generic styles mechanism, and a wiki proposal. Philippe requested we
bring these efforts together. He noted that we have a bugzilla
component, now owned by John, and that John is the driver for styles.
Philippe noted that blocks/Styles.py addresses platform size and font
disparity (useful), but not a way for designers or users to modify
styles. The new application/styles.py is based on the Python
ConfigParser. One can specify data using a syntax similar to Python but
more forgiving. He also noted that our desired solution should take OS
prefs into account, as these are used for i18n and accessibility.
Philippe proposed building on ConfigParser, as it solves the problem of
"style file" nicely, stays close to Python, and avoids reinventing CSS.
He listed open questions: How can we avoid proliferation of .conf files?
Do we cascade them, for 3rd party parcels? Will i18n related .conf files
be included in translation eggs? Are we reinventing resource files? Is
there a better well known Python alternative to conf files? wx alternative?
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006080.html
*Single-ref handling*
While tracking down a broken repository problem (Bug 6028), Andi
realized a flaw with single-refs that point at no existing items. These
used to return 'None', which makes it hard to work with the attribute
and thus error prone. He changed the data model code to return the
dangling single-ref instead of None.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006088.html
Meeting notes
-------------
Reid did a code review of the Markup Bar and Multistate button on Monday
(June 5).
http://wiki.osafoundation.org/bin/view/Projects/GeekTalk060506
Apps team meeting
http://wiki.osafoundation.org/bin/view/Journal/AppsMeeting20060607
Chandler eng meeting
http://wiki.osafoundation.org/bin/view/Journal/EngineeringMeetingNotes20060608
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
