Log of #chandler for 20040714, from 0000h to 2400h

Previous day's transcript | This day's raw log | Show all


TimePersonSaid
01:12grant_ > opus twiki query
01:12opus > The following URLs are available:
01:12opus > 12. http://wiki.osafoundation.org/twiki/bin/view/Chandler/ApplicationQuery
01:12opus > 78. http://wiki.osafoundation.org/twiki/bin/view/Chandler/ChandlerQuerySystem
01:12opus > 335. http://wiki.osafoundation.org/twiki/bin/view/Chandler/QueryFramework
02:22opus > *** Tinderbox ERROR *** kilauea-osx: the build failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
02:27opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
09:48Morgen > mark, drv_libxml2.py is missing in the mac 0.3.20 distro
09:48Morgen > that's why it doesn't run
09:53Morgen > mark, also, the crash on linux is because we don't have Andi's latest PyLucene, I think
09:54Morgen > Anyone who has downloaded the 0.3.20 mac distro that Mark mailed a link to can download this file: http://builds.osafoundation.org/tmp/drv_libxml2.py and save it in the Chandler_osx_0_3_20.app/Contents/Resources directory (as a workaround)
09:57markie > Morgen, I am releasing a fix for this RSN/it turns out the build for OSX does not put the file where it belongs (unlike linux, which does)
09:57ducky > markie -- could you please update http://downloads.osafoundation.org/chandler/snapshots/ to reflect the .18, .19, and .20 milestones?
09:58Morgen > where it belongs?
09:58Morgen > mark, it doesn't include drv_libxml2.py at all :-)
09:59markie > Morgen, the drv_libxml2.py gets copied into $(SNAP)/$(SITE) during the python make on linux (I have the logs) but it does not happen on OS X
09:59Morgen > Ah, just the person we need :-)
09:59Morgen > Mark, do you know how to get Andi's latest PyLucene into the release?
10:03Morgen > Mark, using the 0.3.20 download, I can exit cleanly on linux; if I simply do a CVS checkout and "make install" (which gets release-0.3-10.tar) I get an error. I suspect that the release-0.3-10.tar archive is not up-to-date?
10:10markie > Yes, Morgen, I put Andi's latest PyLucene into the 0.3-10 tarball
10:11Morgen > did you upload it
10:11markie > They should be there, the milestones were built from the tarballs
10:13katie > markie: what's the status on the builds to use for the qa session today?
10:14markie > I am trying to get the OS X fix built, and the linux issue resolved.
10:14markie > Windows milestone is working
10:14katie > so both os x and linux have problems?
10:14markie > Yes, resolvable
10:14katie > yes, but we have 45 minutes
10:14katie > so it sounds like we need to scratch the session today
10:15katie > unless we can productively use the time on just windows
10:15Andi > what are the problems ?
10:22Morgen > the osx problem is easily fixed by people downloading a single file: http://builds.osafoundation.org/tmp/drv_libxml2.py
10:23Morgen > mark, external/source-0.3-10.tar is dated July 9, but Andi's PyLucene fix was done on July 12
10:27markie > Morgen, are you referring to linux or OS X versions?
10:27Morgen > source code
10:27markie > Oh, the SOURCE! Yipes.
10:27Morgen > I don't think we have Andi's latest PyLucene in our release
10:27markie > I can fix that immediately
10:28Morgen > since sources-0.3-10.tar is earlier than his fix
10:34opus > opus-debian: success
10:42ducky > markie -- so is the OS X version ready to go?
10:43markie > OS X is being constructed as we speak, I will post here when it can be downloaded and the URL
10:43ducky > okay
10:52markie > The Windows milestone build 0.3.20 can now also be downloaded from http://downloads.osafoundation.org/chandler/snapshots/0_3_20/ (please wait for about fifteen minutes for the updated OS X build)
10:54ducky > markie -- do you mean "the build will take another fifteen minutes to upload", or do you mean "it will take you 15 minutes to download"?
10:56ducky > markie -- wait, was there a problem with the Windows build? I thought it was just Mac.
10:57grant > the external source tarball was updated, effects all builds it sounds like.
10:57ducky > urk
10:57markie > The Windows version is fine. The Mac version had problems, it is fixed and needs to be uploaded
10:57Morgen > ducky, I assume he mentioned the windows distro because it is now on the "downloads" server in addition to the "builds" server
10:59ducky > Hello, and welcome to the OSAF IRC Office Hour!
10:59ducky >
10:59ducky > As always, we log everything in #chandler for future reference. You can find transcripts for today's chat at
10:59ducky > http://kahuna.osafoundation.org/~ducky/getIrcTranscript.cgi?date=20040714
10:59ducky >
10:59ducky > Next week, we plan to release a special milestone, "Integration Point A". Integration Point A
10:59ducky > and Integration Point B are special milestones in that they are somewhat feature-driven, not purely
11:00ducky > clock-driven. They give the various groups a point to shoot for for integrating features.
11:00ducky > Today, we'd like to shake out this milestone (3.20) to help make Integration Point A more
11:00ducky > robust. This is also a chance to "kick the tires" and get a glimpse of Chandler's direction.
11:00ducky >
11:00ducky > To download this version of Chandler, go to
11:00ducky > http://builds.osafoundation.org/chandler/snapshots/0_3_20/
11:00ducky >
11:00ducky > (Note that there was a build problem with the OS X version of 3.20. Markie has fixed it, but it will take about fifteen more minutes for it
11:00ducky > before it's up on the downloads page given above. Markie will announce
11:00ducky > here when it's ready to go.)
11:00ducky >
11:00ducky > Katie, do you have any opening remarks?
11:00katie > yes
11:01katie > when you bring up chandler for the first time, you should see a navbar, a sidebar, and a "content area"
11:02katie > the sidebar will list 6 "item collections": In, Out, Calendar, Contacts, Junk and Trash
11:02katie > none of these collections will have any items in them :)
11:02katie > to generate sample items, you can use the test menu
11:03katie > in particular, you can generate calendar items, which will show up in the calendar item collection
11:03katie > if you choose the calendar item collection, and generate some items, you should now be able to see the items in a list view, a month view, a day view, and a week view
11:04katie > what is new here?
11:04katie > the sidebar is new
11:04katie > the item collections used by the sidebar are new
11:04lisa > Sorry I'm late; I didn't realize I got cut off silently a few minutes ago.
11:05katie > the calendar blocks used by the views are new
11:05katie > the ability to select betweeen subblocks in the tabbed view is new
11:06katie > if you select an item in the list, you should see a detail view of that item
11:06katie > the detail view is also new
11:07katie > much of the detail view is scaffolding
11:07lisa > The summary of what we did (and the few things we didn't do) can be found here: http://wiki.osafoundation.org/twiki/bin/preview/Chandler/ZeroPointFourAResults
11:07lisa > To get the complete list you have to compare that to the engineering plan down the page on http://wiki.osafoundation.org/twiki/bin/view/Chandler/ZeroPointFourPlanning
11:07katie > in particular, the detail view has one significant interesting feature: stamping
11:08lisa > We expect the few things listed as undone on the Results page can mostly be wrapped up this week.
11:09donn > Shall I say a few words about stamping?
11:09katie > donn: that would be great
11:09donn > There are three buttons on the Markup Bar of the Detail View that do stamping
11:09pieter > a better link for Katie's first URL is http://wiki.osafoundation.org/twiki/bin/view/Chandler/ZeroPointFourAResults
11:10donn > The buttons are used to "stamp" one item into another
11:11donn > for instance you can take a note, stamp it by pressing the checkmark button, and it becomes a Task
11:11lisa > thx Pieter that was my mistake :)
11:12donn > There are three stamp buttons: the Mail stamp that looks like human heads in profile
11:12donn > the task stamp, which looks like a checkmark on a box
11:12donn > and the calendar stamp, which looks like a clock
11:12pieter > /me looks like there is some garbage in my URL so it's bad too ;-(
11:13donn > In theory you can both stamp and unstamp each of these aspects onto an Item
11:13donn > so you can construct mail-tasks etc
11:13donn > Under the test menu you can add kind-specific views to the sidebar
11:14donn > these views list all the items of a given kind, even if they are multiple-stamped
11:14donn > so a mail-task item should appear in the mail view and the task view
11:15donn > when you select an item, the detail view should toggle the stamp buttons to reflect the current item's stamp
11:15donn > so a mail-task item should already have the mail and task buttons toggled
11:16lisa > There's links to Mimi's related design documents here: http://wiki.osafoundation.org/twiki/bin/view/Chandler/DetailViewProject
11:16lisa > Like the StampingWorkflow page
11:16ducky > donn -- I just tried to stamp a note with linux 3.20, and it stayed a note and didn't appear in the task-kind view
11:17ducky > oh, there it went
11:17donn > I have not tested on linux, so it sounds like we've got a bug there
11:17ducky > I guess the previous time, I had selected a field somehow and not the entire note ?
11:17chao > More directly, Mimi's design doc is at: http://wiki.osafoundation.org/twiki/bin/view/Chandler/DetailViewSpec
11:17ducky tries again
11:17donn > Yes, the table view is a bit confusing - it has two kinds of highlights: cell highlight and line highlight
11:18ducky > how do you highlihgt a cell vs a line? and vice versa?
11:18donn > the cell highlight is a frame around a cell, and that item is not really selected
11:18donn > I think the arrow keys move the cell highlight around, clicking should give you line highlight
11:18donn > john probably knows more about this
11:18katie > hey chao and donn: I just added StampingWorkflow and MarkingUpWorkflow to the DetailViewProject (DetailViewSpec was already there) -- are those still good specs to be looking at?
11:19donn > I think yest
11:19donn > yes
11:19ducky > donn -- it would be nice if I could click on the task stamp even if I'm cell highlighted
11:19donn > I'll be adding a description of stamping later tonight
11:19chao > katie: yes, but they are not specific to 0.4
11:19katie > thats ok
11:20ducky > also, here's funny behavior: I selected a cell (by click once on cell, click again). I clicked on the task stamp button, the item disappeared; I clicked on the task stamp button (expecting the other item to disappear) and the first one reappeared
11:21ducky > btw, does anybody else have the milestone build up now?
11:21donn > That sounds like a bug - I'm guessing that the original item was still selected and it unstamped it back
11:21ducky_linux > right, but it shouldn't have still been selected if it wasn't there
11:22donn > So, in case it's unclear to everyone, stamping is still very new and potentially buggy
11:22ducky_linux > if I click somewhere else on the second item, (thus selecting it) I can unstamp it just fine
11:22lisa > There's more stuff in there besides Stamping :)
11:22donn > Stamping is a key part of what we plan to do with Chandler, so we put it into this build even though it's not quite ready for prime-time
11:23donn > It uses new stuff in the Detail View, Item Collections, and the Repository
11:23donn > Bug reports are welcome
11:23lisa > Brian did you figure out how people can test your IMAP email downloading?
11:23pieter > I'm curious, in 3.20 does the item stamp state get recorded in the repository?
11:23bkirsch > Lisa: I ask markie for the info but he was tied up with the release
11:23lisa > We haven't tied downloaded email into other features much yet, but you can suck in data from the server
11:23bkirsch > Here is what you need to do on you platform build
11:23ducky_linux > donn, some traceback; not sure what caused it, but something having to do with the stamping I was just doing
11:24ducky_linux > File "/home/ducky/src/Chandler_linux_0_3_20/parcels/osaf/contentmodel/ContentModel.py", line 120, in StampKind
11:24ducky_linux > self.StampPostProcess(futureKind, dataCarryOver)
11:24ducky_linux > File "/home/ducky/src/Chandler_linux_0_3_20/repository/item/Item.py", line 134, in __getattr__
11:24ducky_linux > return self.getAttributeValue(name)
11:24ducky_linux > File "/home/ducky/src/Chandler_linux_0_3_20/repository/item/Item.py", line 524, in getAttributeValue
11:24ducky_linux > raise AttributeError, "%s has no value for '%s'" %(self.itsPath,
11:24bkirsch > locate the osaf/parcels director
11:24ducky_linux > AttributeError: //userdata/contentitems/1rlQ8rlL17ofex00aP1c6p has no value for 'StampPostProcess'
11:24donn > Pieter: It should, since stamping essentially changes the Kind of an item, and that must be recorded in the repository
11:24bkirsch > then go to the mail parcel
11:24hazmat > for stamping, is it basically create a new item of type kind with relation to originating item?
11:24bkirsch > edit the account to point to your iimap server and user password and you are done
11:24bkirsch > look at the chandler.log to watch you messages download
11:24ducky_linux > uh, bkirsch, what is the name of the file that people need to alter
11:25bkirsch > markie: do you any platform specific info to add
11:25bkirsch > that ducky
11:25bkirsch > the file is parcel.xml
11:25john > hasmat: stamping changes the kind of an existing item
11:25opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
11:25bkirsch > is parcels/osaf/mail
11:25bkirsch > s/is/in/
11:25bkirsch > :0
11:25lisa > the filename itself is "parcel.xml", right BK?
11:25lisa > or is there a separate file for now with account info?
11:25bkirsch > yes the file is parcels
11:26bkirsch > parcels/osaf/mail/parcel.xml
11:26hazmat > john, are attributes that don't carry over between the kind schemas then in effect lost?
11:26lisa > Hazmat: No, they're additive when you stamp.
11:26bkirsch > edit the emailAccount to point to your configuration
11:26lisa > You'd only lose attributes if you unstamped something which is a direct indication to remove attributes
11:27hazmat > so stamping is more then just changing kind its an amalagm of kinds in a way?
11:27hazmat > or is just the item retaining state while changing kinds
11:27john > hasmat: stamping typically mixes in a kind
11:27hazmat > ic, thanks
11:28donn > here's a link with more info about the internals of changing an item's kind: http://wiki.osafoundation.org/twiki/bin/view/Chandler/CPIAContentModelSupport
11:30ducky_linux > so bkirsch, you change e.g.
11:30ducky_linux > <attributes itemref="mail:serverPort"/>
11:30ducky_linux > to
11:30ducky_linux > <attributes itemref="mail:serverPort">myserver.com</attributes>
11:30ducky_linux > ? Is that the way to do it?
11:31bkirsch > Ducky here is an example
11:31bkirsch > <content:EmailAccount itsName="IMAPAccount One">
11:31bkirsch > <content:displayName>IMAP Server</content:displayName>
11:31bkirsch > <content:serverName>localhost</content:serverName>
11:31ducky_linux > btw, another traceback, not sure what I was doing:
11:31bkirsch > <content:accountType>IMAP4</content:accountType>
11:31ducky_linux > Traceback (most recent call last):
11:31bkirsch > <content:accountName>brian</content:accountName>
11:31ducky_linux > File "/home/ducky/src/Chandler_linux_0_3_20/parcels/osaf/framework/blocks/ControlBlocks.py", line 353, in GetValue
11:31bkirsch > <content:password>MyPassword</content:password>
11:31bkirsch > <content:serverPort>143</content:serverPort>
11:31ducky_linux > return self.GetView().GetElementValue (row, column)
11:31bkirsch > </content:EmailAccount>
11:31ducky_linux > File "/home/ducky/src/Chandler_linux_0_3_20/parcels/osaf/framework/blocks/ControlBlocks.py", line 206, in GetElementValue
11:31ducky_linux > item = self.blockItem.contents [row]
11:31ducky_linux > File "/home/ducky/src/Chandler_linux_0_3_20/parcels/osaf/contentmodel/ItemCollection.py", line 62, in __getitem__
11:32ducky_linux > return self.getRepositoryView()[self.results[index]]
11:32ducky_linux > IndexError: list index out of range
11:32ducky_linux > cool, thx brian
11:32lisa > We'll be working on getting email/sharing account editing into the GUI in the latter half of 0.4 development.
11:33katie > a couple of things you can try out with the calendar blocks btw (although I know some of these are still buggy)
11:34hazmat > you know what would be really helpful to outside developers is a diagram of the chandler components/packages and their various states of stability
11:34katie > (1) if you are in the day, week or month view, you should be able to go forward/back in time
11:34katie > hazmat: sure, we could probably arrange something like that even for next week
11:34lisa > Hazmat: tracking stability on a package level could be pretty time-consuming! But I agree it would be nice.
11:34hazmat > something along the lines of this http://peak.telecommunity.com/DevCenter
11:34katie > ok, without detailed stability
11:34lisa > Is there automation for that?
11:35hazmat > lisa, it doesn't have to be detailed, just a general classifcation
11:35lisa > Yeah, the Peak diagram is nice.
11:35katie > lisa: we could take the diagram we have, for example, and modify it that way
11:35katie > not on a day by day basis, but as of a particular release, for example
11:36hazmat > that would be great, there is so much changing and its rather hard to know whats not in flux
11:36katie > hazmat: dude, its all in flux!
11:36hazmat > well not nesc. changing but much that is being worked/developed
11:36opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
11:36lisa > Yeah, remember this week's milestone build is not a release :)
11:36lisa > It's just a "special" milestone build :)
11:37hazmat > katie, definitely, but the foundation sounds like it starting to come together
11:37katie > sure, even if we are just consistent about what the names of the pieces are
11:37katie > a good idea
11:38hazmat > at least from a non gui perspective and for myself, the integration of the twisted layer will be the last piece i'd like to see before starting to get back into the code base
11:38katie > calendar blocks: you should be able to change dates in the mini calendar, and it should change the date in the visible calendar block (month/week/day)
11:38lisa > BK you want to talk more about the current issues with the twisted layer?
11:39bkirsch > sure
11:39bkirsch > we have twisted integrated as a core service with in the Chandler application layer
11:39bkirsch > the twisted reactor is started in its own thread
11:40bkirsch > The imap code utilizes the reator by calling reactor.callFromThread(methodName)
11:40bkirsch > which says execute the given methodName in the reactor thread
11:40bkirsch > to utilize twisted with the repository required some additional logic
11:40bkirsch > Andi added views on to the repository
11:40ducky_linux > hmmm
11:41bkirsch > before that one view was present on each thread
11:41bkirsch > since twisted code shares a single thread
11:41bkirsch > you need to create a view of the repository for each class running logic in twisted
11:41ducky_linux > bkirsch, fyi, I tried to modify the XML file, and I apparently need more detail on the format, as now CHandler won't boot for me
11:41ducky_linux > not sure it needs to be resolved today
11:41ducky_linux > or ever
11:41ducky_linux > since you're going ot put in a GUI Real Soon Now
11:42bkirsch > I created a new class AbstractRepositoryViewManager class to add in the view logic
11:42bkirsch > my IMAP code extends from this class and is a good example of how to work with view
11:42bkirsch > right now I am working with the Twisted folks to abstract view switching in to the twisted layer
11:43bkirsch > if we can get a good api this would be done in a future twisted release
11:43bkirsch > ducky: lets take the issue off line and I will try to resolve it for you
11:43bkirsch > any questions
11:43bkirsch > ?
11:43ducky_linux > yes.
11:43ducky_linux > uh, yes, let's take offline
11:44bkirsch > also one new idea added but still being refined is commits in the reactor thread
11:44bear > by view do you mean the item lists that a background task needs to interact with the repository?
11:44hazmat > bkirsch, is that going to be the general pattern for blocking calls (ie callinthread) or will there be a dedicated io/task queue or thread pool (some subset of twisted's own)
11:44bkirsch > a repository commit can take a long time to complete if merging is required
11:44bkirsch > this can end blocking the twisted thread
11:45bkirsch > so the AbstractRespositoryViewManager has code in it to execute the commit in a non-twisted thread and post the result success of failure via a callback
11:45bkirsch > the imap utilizes this as well
11:46bkirsch > hazmat: not sure I follow your question can you be more specific
11:46bkirsch > callInThread is a different api from callFromThread
11:47hazmat > from chandler to do a potentially blocking operation will there be a higher level api than callinThread?
11:48bkirsch > from where are you refering
11:48bear > so we should think of a AbstractRepositoryViewManager as a pool of "connection classes" that gui tasks can farm out repository stuff and then wait for a callback?
11:48lisa > So it would be good to know before people start to leave, did anybody try to download the milestone build today and succeed? Did anybody try and fail?
11:48chao > I'm randomly clicking on different items and widgets, it seems to be very unresponsive - each click maxes my CPU usage for about 2 secs - is that to be expected?
11:49bkirsch > you will not have to worry about blocking unless you are in twisted
11:49ducky_linux > I downloaded at about 1015AM
11:49bear > testing on win2k as we speak
11:49ducky_linux > I can crash Chandler-linux pretty easily
11:49aparna > I downloaded at about 11:20 on Mac and it went thru fine
11:50ducky_linux > aparna, how does the mac version look?
11:50ducky_linux > crashes?
11:50aparna > There are bugs but it doen't crash
11:50ducky_linux > sluggish?
11:50aparna > somewhat
11:51katie > we've definitely noted application sluggishness
11:51chao > pc and mac builds started up for me.
11:51hazmat > bkirsch, i guess i'm curious if there is going to be an abstraction for the purpose of not dealing with a bunch of simulatenous threads in twisted, and correspondinv views on the repo and associated memory usage, but i think i'm out of my depth and this is something that could be optimzied latter, but its why i was wondering about an abstraction api
11:51katie > the apps team wants to look at this next week
11:51chao > Both are very sluggish
11:51opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
11:51bear > win2k starts fine
11:52bkirsch > hazamat: hang on one second
11:54pieter > I'm finding the WinXP version quite buggy, frequently using >70% CPU, and crashes too :-(
11:54Jeffrey > bkirsch: I'm curious, since we're using Twisted, does that mean we get IMAPS essentially for free, now that you've got IMAP working? I don't have an IMAP server to test against :)
11:55Jeffrey > (I mean, an IMAP server running on port 143)
11:55bear > jeffrey - I run an imap server - I can give any osaf'r an account to use
11:55Jonathan > bear: I would like to have such an account
11:55Jeffrey > That would be useful to me, thanks bear.
11:55bear > k
11:57bkirsch > jeffrey: yes but we are gonna switch from pyopenssl to m2crypto so at the moment no ssl with in twisted in chandler but this will be resolved shortly
11:57Jeffrey > OK. Yeah, I thought not yet, just checking.
11:58Jeffrey > But I'll check using my new account from bear :)
11:59bkirsch > hazmat: the is a abstract api
11:59ducky_linux > The clock has struck noon Pacific Time, so the Official OSAF Office Hours time is up.
11:59ducky_linux > This doesn't mean that the conversation is required to end.
11:59ducky_linux >
11:59ducky_linux > You are certainly welcome to continue hanging out and talking here, but
11:59ducky_linux > many of the West Coast people will probably disappear to go to lunch soon.
11:59ducky_linux >
11:59ducky_linux > The IRC logs for #chandler are all available on-line; today's is at:
11:59ducky_linux > http://kahuna.osafoundation.org/~ducky/getIrcTranscript.cgi?date=20040714
11:59ducky_linux >
11:59ducky_linux > Thank you for joining us!
12:00bkirsch > to run twisted code in the twisted thread use reactor.callFromThread
12:00bear > lisa - so far no crashes or other booms with build on win2k
12:00lisa > cool, bear :)
12:00bkirsch > to commit a view in a dedicated thread use AbstractRepositoryViewManager.commit thread
12:01bkirsch > hazmat: if you would like to talk further please feel free to email me or continue on IRC
12:01Andi > markie: is the tree open for commits again ?
12:02hazmat > bkirsch, i'll do email, at the moment its bedtime
12:02bkirsch > hazmat: great
12:02markie > Andi, yes, since yesterday after 6
12:03Andi > cool
12:03markie > I've uploaded new linux milestones, did not get a chance to test yet
12:03grant > markie, great, thanks
12:04lisa > What's uploading new linux milestones?
12:04Andi without testing them ?
12:04lisa > do you mean the new linux distro?
12:05markie > I rebuilt the linux 0.3.20 since updating source dist (ummm, yes "distribution files")
12:07grant > SvenDowideit, hi there. We are just wrapping up.
12:09opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
12:16john > markie: is the tree open?
12:17bear > john - yes
12:21grant > Andi, FYI I made some progress. I have my local apache able to use a Chandler python with it's libraries for CGI. I'm starting to look at modifying Store.py to be a client to the repository similar to the scripts you emailed me.
12:22Andi > neat
12:22grant > thanks
12:24sprout > grant: what are you working on? I did some stuff because I was looking to make some blog software atop the repository
12:25grant > nice. I have a very very simple wiki I'm working to get get on top of the repository.
12:26grant > what blog software are you using?
12:26sprout > maybe we should swap notes about this sometime -- my stuff is a little dusty
12:26opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
12:26grant > sounds good.
12:26sprout > well, I was thinking of trying to port pyblosxom.
12:26bear > probably pyblosxom :)
12:26sprout > I'm pretty familiar with the internals.
12:27grant > great
12:27grant > bear and I have been looking at a little 3-file wiki called owiki-python
12:27sprout > ah.
12:28sprout > as I recall, I ran into a bunch of issues with file permissions.
12:28bear > yea - he got those also ;)
12:28sprout > you're doing CGI, not mod python right?
12:28grant > yup, cgi
12:28grant > I fixed the permissions
12:29grant > at least for simple stuff so far
12:29bear > cgi is easier to test IMO - easier to alter the environment to have it use the chandler-built python
12:29sprout > yeah
12:29grant > yeah
12:30sprout > I had to do some weird exec stuff in the cgi in order to get my little tests to work.
12:30bear > with the environment set I think grant just had to change the #!
12:30grant nods
12:30grant > so far
12:30sprout > debian or os x
12:30grant > debian
12:31grant > apache 1.3.29
12:31sprout > yeah, proably easier on debian.
12:32bear > my only concern with cgi is thrashing the repository because of the startup/shutdown
12:33sprout > that's an understatement
12:33bear > :)
12:33grant > details, details ;-)
12:33bear grins
12:34sprout sighs
12:34grant > for testing of one transaction per minute or less it's no big deal.
12:34bear nods
12:34grant > even if it isn't pretty
12:34bear > something along the lines of mod_python will be needed eventually
12:35bear > mod_chandler :)
12:35grant nods
12:35sprout > yup
12:35sprout > either that or servlets for python, which do exist, apparently
12:35bear > that would be cool - running little python servlets in a tomcat setup
12:35grant > interesting
12:36sprout > it doesn't use tomcat.
12:36sprout > all python
12:36bear > sorry - s/tomcat/tomcat-like/
12:36Andi > anybody ready to gcj compile tomcat ? ")
12:36Andi > :)
12:36bear gags andi and shoves him into the dungeon
12:37sprout > yeah, then we could run chandler in jython...
12:37bear > nope nothing to look at here - move along - move along
12:37Andi gaarghl
12:37grant > heh
12:37sprout > that was for stuart
12:37Andi > or Pavlov
12:38bear > hmm, jython runs on a vm, squeak is a vm ...
12:38bear > chandler over croquet anyone?
12:38sprout smacks bear with a fish
12:38bear > gah!
12:38bear > wow - that one scared andi away :)
12:38sprout > i'd say there's a better chance of chandler on ironpython on the CLR
12:39bear > implementing chandler as a collection of clr based servlets :)
12:40sprout > or maybe we'll just write a program that translates python in to Lisp.
12:40grant > DaniGro: are you listening? :-)
12:41grant > he's a C# fan I think.
12:41sprout is becoming one
12:42hazmat > i've been using pythonnet for some groove work as of recently, its really quite nice, its not a clr langugage, but it allows transparent access to clr assemblies from cpython (http://cvs.zope.org/PythonNet)
12:42hazmat > not to be confused with ironpython.com
12:42grant > wild
12:43sprout > actually i'm becoming a CLR fan, not really a C# fan
12:46opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
12:52grant > markie, on the new linux build I got a warning that during startup: WARNING: Could not properly read security provider files: file:///home/vajda/gcc-3.2.2/install/lib/security/libgcj.security (one other file) then Falling back to standard GNU security provider.
12:52grant > it launches ok
12:52grant > but I thought you might like to know about Andi's name in the warning.
12:53markie > Known issue, grant; we need to add to release notes
12:54grant > ok
13:17opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
13:45opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
14:15opus > *** Tinderbox ERROR *** kilauea-osx: the build failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
14:20opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
14:35opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
14:39john > katie: are you around?
14:39katie > on phone w/morgen
14:39john > ok
14:42katie > hi john
14:42katie > off the phone now
14:51heikki_pkisummit > markie: can these bugs be marked fixed: bug 1556, bug 1561, bug 1575 ?
14:52markie > OK, I want to make the OS X tree green again; looks like wrong binary problem (too many root sets)
14:53markie > How's your conference going?
14:53heikki_pkisummit > of course I don't want them marked fixed if they are not fixed - I am just asking if they are and if so they should be marked accordingly
14:53heikki_pkisummit > pretty good, learned some cool stuff
14:54markie > I have checked in the changed files, so they should be marked fixed
15:36opus > *** Tinderbox ERROR *** kilauea-osx: the build failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
15:41opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
16:11opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
16:34opus > *** Tinderbox ERROR *** kilauea-osx: the build failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
16:39opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
16:59opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
17:26opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
17:55john > anybody remember the parcel XML to set the initial or default value of a attribute with cardinality list to look like an empty list?
18:01bear > you mean the example morgen gave for setting an attribute in the mailing list?
18:07bear > attributeItem.addValue("initialValue", [ ] )
18:09opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
18:10john > no it's actually <initialValue/>
18:10bear > doh!
18:10bear > you did say xml didn't you - sorry
18:30opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
18:36ducky > opus, insult badpeople
18:36opus > badpeople: You are nothing but a gorbellied enema-bucketful of spur-galled yoo-hoo.
19:16opus > *** Tinderbox ERROR *** kilauea-osx: the build failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
19:21opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
19:36opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
19:55Last > message repeated 1 time(s).
21:03opus > *** Tinderbox ERROR *** kilauea-osx: the build failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
21:29opus > *** Tinderbox ERROR *** kilauea-osx: the build failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
21:34opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
23:04opus > *** Tinderbox ERROR *** kilauea-osx: build_failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
23:14opus > *** Tinderbox ERROR *** kilauea-osx: the build failed :: Do not checkin on red except to fix the tree. *** HELP *** (Tree is OPEN)
00:00--- > Thu Jul 15 2004