[00:04] <sladen> mention 'python implementation of...'
[00:04] <sladen> where do the request IDs come from?
[00:05] <sladen> Web-address, and date
[00:06] <sladen> sub-heading "Protocol overview" above "+Since it is not well-documented elsewhere"
[00:07] <sladen> Link to http://code.google.com/apis/protocolbuffers/docs/overview.html  after mention
[00:10] <sladen> tcole: impressive.  excellent
[00:10] <sladen> tcole: (although I can't assess technical accuracy, yet)
[00:10]  * tcole nods
[00:10] <tcole> I'll make the changes you've suggested
[00:12] <sladen> probably note that 'python-gdata' contains the Google Buffer python implementation
[00:12] <dobey> actually, python-protobuf does
[00:12] <dobey> gdata is something else
[00:13] <tcole> right
[00:13] <tcole> and that's why I should mention python-protobuf explicitly :)
[00:15] <tcole> that ... request ID thing is an interesting question actually
[00:16] <tcole> for the client-iniated stuff I think we just use an incrementing counter
[00:16] <tcole> (it doesn't really matter)
[00:16] <tcole> but I'm not sure offhand what we do for server-initiated things
[00:16] <sladen> note that it doesn't matter
[00:16] <sladen> (eg. there is not need to call   u1storage.generateRequestID()
[00:21] <tcole> ha
[00:21] <tcole> I missed an important detail
[00:21] <tcole> client request numbers are odd
[00:21] <tcole> and server-initiated request numbers are even
[00:22] <tcole> (effectively we use the low bit to create a separate namespace for client versus server-initiated things)
[00:23] <sladen> understatement ;-)
[00:24] <sladen> tcole: add README to debian/docs when it's done too.
[00:25] <tcole> ah, good catch; thanks!
[00:27] <tcole> uh, hmm
[00:27] <tcole> the comment here is wrong
[00:27] <tcole> in the code
[00:27] <tcole> I will need to fix that too...
[00:27] <tcole> or else I need to check what the server is doing
[00:29] <sladen> # we are a client, we do odd requests that one?
[00:29] <sladen> "# we are a client, we do odd requests"
[00:30] <sladen> would be clear to say   "odd numbered request IDs (eg. 1,3,5,...)" or something
[00:32] <sladen> is this package used to implement ubunet too?
[00:32] <tcole> yes
[00:35] <sladen> remember not to accept any external contributions then
[00:36] <tcole> indeed
[00:36] <tcole> that's one reason why we split it out into a very minimal separate project/package
[00:37] <tcole> aside from the other good reasons to do so
[00:37] <dobey> we accept external contributions
[00:37] <dobey> there's no real reason not to
[00:37] <tcole> well, for the protocol bits
[00:37] <tcole> the server depends on that and it is AGPL
[00:38] <dobey> we do require the contributor agreement though
[00:38] <tcole> oh, right
[00:38] <tcole> I wasn't remembering far enough into the discussion
[00:38] <tcole> durr
[00:38] <tcole> this is what happens when I'm neck-deep in code and try to talk
[00:38] <dobey> well, we should review contributions well enough to not break things :)
[00:39] <sladen> It would be good to include the requirement for copyright assignement for any contributed patches
[00:39] <dobey> also, we'll want to get translations in protocol as well for any of the strings there
[00:39] <dobey> anyway, must go now
[00:39] <dobey> later
[00:39] <tcole> yes, the contributor agreement thing ought to be mentioned in the README as well
[00:39] <sladen> ...note the requirement for ... in the README
[00:39] <sladen> yup
[00:39] <tcole> yes
[00:40] <tcole> well, I'm amused
[00:40] <tcole> it seems the server currently uses even request IDs too :(
[00:41] <tcole> amused is the wrong word for what I am feeling
[00:41] <tcole> at least if I'm reading the code correctly
[00:44] <sladen> probably it doesn't matter as they're always used in one direction only
[00:45] <sladen> but if they do overlap that's most likely to affect debugging
[00:52] <tcole> yeah, thinking about it more
[00:52] <tcole> the way things are at the moment, it isn't likely to cause visible harm
[00:52] <tcole> but still should be fixed
[00:52] <tcole> I put in an ubunet bug
[00:52] <tcole> I think we're beyond changing it on the clients at this point
[00:53] <tcole> hm, I think that does it for me for tonight
[00:53] <tcole> I just pushed more updates to the README
[00:53] <tcole> probably look at getting that landed monday
[01:00]  * sladen bzr pulls
[01:08] <tcole> also fixed the comments in the actual code to match what the client does and the readme says
[01:14] <sladen> 00:29 < sladen> "# we are a client, we do odd requests"
[01:14] <sladen> 00:30 < sladen> would be clear to say   "odd numbered request IDs (eg. 1,3,5,...)" or something
[01:15] <sladen> oops
[02:06] <sladen> tcole: 'protoc' itself appears to actually be in 'protobuf-compiler'
[02:07] <tcole> hm, isn't that what I said in the readme?
[02:07] <tcole> that protoc was available via the protobuf-compiler package?
[02:07] <tcole> or did I word it confusingly?
[02:10] <sladen> it currently talks about python-protobuf;  I haven't used either so I dont know to what extent that package is needed directly
[02:13] <BUGabundo1> you guys still at it?
[02:13] <BUGabundo1> lol
[02:22] <sladen> is/was 'idisk' a codename?
[02:22] <sladen> < sladen> tcole: it currently talks about python-protobuf;  I haven't used either so I dont know to what extent that package is needed directly
[02:23] <tcole> idisk was never a codename for us that I'm aware of
[02:23] <tcole> and python-protobuf is a typo
[02:24] <tcole> or, well
[02:24] <tcole> need both python-protobuf and protobuf-compiler I guess
[02:26] <tcole> pushed fix
[02:31] <sladen> tcole: re: "This protocol applies only to the file storage service and not other Ubuntu One services."  if this protocol is built on top of another protocol, what is the protocol below
[02:31] <tcole> I don't understand the question.
[02:31] <sladen> tcole: eg. how does the server differientiate storage-protocol from email-protocol from foo-prtocol
[02:32] <tcole> different ports, at least
[02:32] <tcole> typically different servers on the backend as well
[02:32] <sladen> oh right.
[02:33] <sladen> I take it this doesn't work particulary well via HTTP proxy servers
[02:33] <sladen> so port 20100 is u1storage
[02:36] <tcole> actually, no
[02:36] <tcole> it does SSL on port 443
[02:37] <tcole>     parser.add_option("--port", dest="port", metavar="PORT",
[02:37] <tcole>                       default=443,
[02:37] <tcole>                       help="The port on which to connect to the server")
[02:37] <tcole>     parser.add_option("--host", dest="host", metavar="HOST",
[02:37] <tcole>                       default='fs-1.ubuntuone.com',
[02:37] <tcole>                       help="The server address")
[02:37] <tcole> actually we just have different servers
[02:37] <tcole> as long as the firewall allows https through it should allow this
[02:39] <sladen> is this an HTTPS channel (that happens to be on port 443)
[02:39] <tcole> just raw SSL, IIRC
[02:39] <sladen> or this a RAW TCP channel (that just ... okay
[02:43] <sladen> so SSL is setup, keys checked etc, and then instead of HTTP, the u1storage binary application of google buffer is spoken back/forth
[02:44] <sladen> most interesting
[02:45] <sladen> so ubunet is not a monolithic app on a single machine
[02:45] <sladen> it's an app that happen to listen on one particular port on one particular machine and speak just one protocol
[02:45] <sladen> (ubut
[02:46] <sladen> tcole: who do I ask in the ubunet team to find out what they actually call/refer daemon running on fs-1.ubuntuone.com
[02:47] <tcole> well, lucio who will be here on Monday is the foremost expert on it
[02:47] <tcole> but we call it the "API server"
[02:47] <tcole> which is not really the most helpful/descriptive name
[02:47] <__lucio__> storage api server should be good enough
[02:48] <tcole> yes, though we shall have to distinguish file storage and structured storage eventually
[02:50] <sladen> __lucio__: is that what you actually called it when chatting over the coffee table?
[02:50] <sladen> s/called/call/
[02:50] <__lucio__> tcole: i imagine structure storage will go by the name of couch something
[02:51] <tcole> sladen: it's been "server" or "api server" mostly..
[02:51] <__lucio__> sladen: we called it the server, but i dont hitnk that will help you at all. then the API server. i complained about that becuase thats also too generic. so storge api server is the closest name i can think of that devs will understand what you re talking about and it makes sense to people from the outside
[02:52] <tcole> sladen: if it makes you feel better, we call the syncdaemon chicharra sometimes
[02:52] <__lucio__> hitnk == think in some places south of the ecuador
[02:54] <__lucio__> luckily, you dont need to know what we call each other :)
[02:55] <sladen> so "ubunet storage api server"
[02:55] <tcole> s/ubunet/ubuntu one/
[02:56] <sladen> no, "ubuntu one" is the this vague term that is causing alot of respentment, confusion and complication from being vague
[02:57] <sladen> I'm doing my best to try and track down how to (accurately and colloquially) refer to the componets in the stack in ways that do not use the phrase "ubuntu one"
[02:58] <sladen> that phrase is tarnished, it's useless as anything other than a marketing brand
[02:59] <sladen> (where being vague + all encompassing *is* the desired result)
[02:59] <sladen> it's the difference between   CLI, CLR, CTS, C# and ".Net"
[03:06] <sladen> the latter is useful for a Microsoft sales-person, but it is of little use to a Mono developer needing to articulate the finer points of a JIT compiler
[03:08] <__lucio__> i would still advise against using ubunet. it means nothing now.
[03:09] <sladen> __lucio__: mmm.
[03:09] <sladen> __lucio__: what's the actual binary running fs-1.ubuntu.com called?
[03:10] <tcole>  /usr/bin/python :)
[03:10] <__lucio__> sladen: canonical/ubuntuone/storage/server/server.py
[03:11] <sladen> crikey
[03:14] <tcole> maybe we should start giving things ikea names
[03:15] <sladen> I'm slightly amazed that names haven't developed on their own
[03:15] <tcole> it's a shame we couldn't legally use "hammertime"
[03:19] <sladen> eg. if I'm discussing a component in Launchpad I can succinctly refer to Malone/Soyuz/Rosetta
[03:21] <sladen> you just tweak it slightly;  eg.  hammermime
[03:24] <sladen> Suppose I could just do what that magazine did for the Spice Girls
[03:25] <sladen> make so up and see if they stick
[03:37] <lifeless> tammerhime?
[03:43] <rmcbride> Hammermime, now that would be something to see.
[03:43] <rmcbride> BTW, sladen thanks VERY much for your bug reports today
[03:43] <rmcbride> I'm one of the guys on the team learning packaging dos and don'ts and they were VERY helpful
[03:44]  * rmcbride returns to weekend-lurk mode
[05:25] <dobey> wow
[06:48] <platypus_> How can I get an invite to ubuntuone? currently using Dropbox just want to give ubuntuone a run
[11:01] <sladen> mmm, so loking at what would be shared between hammertime and any future email/calendar sync, AFAICT, the only common element would be the use of python-protobuf
[11:26] <sladen> lifeless: yeah, 'hammerhime' would have the edge on pronoucnability
[12:06] <sladen> how is "storagefs" used in general conversation
[12:11] <sladen> __lucio__: up one more level;  what's the file in /etc/init.d/ that runs  /usr/bin/env python canonical/ubuntuone/storage/server/server.py after a reboot
[12:12] <sladen> __lucio__: don't tell me, that's called  canonical-ubuntuone-storage-server.sh  ...
[13:20] <sladen> o is there a web-based [D[D[D[D[D[D[D[D[D[D[D[B[B[B[B
[13:20] <sladen> is there a web-based interface to u1sync aswell?  (as part of ubunet and exposed by HTTPS?)
[13:20] <ceelight> Hi everybody! Is there a changelog or something that describes bugfixes ect. of new ubuntuone-client versions somewhere? thx!
[13:21] <sladen> https://bugs.edge.launchpad.net/ubuntuone-client/+bug/384065  seems to suggest that it does
[13:21] <sladen> if so, what is this called
[14:03] <dobey> sladen: u1sync doesn't have a special web interface of its own, no. that bug is confusing as it's a few bugs in one
[14:04] <sladen> dobey: okay.  Any idea what is referring to?
[14:05] <sladen> dobey: (the webbrowser reference)
[14:05] <dobey> sladen: the main issues seem to be that a) ubuntuone is slow for uploading his data, and b) the local interface to uploading files is a bit confusing (which is filed as another bug)
[14:05] <dobey> sladen: https://ubuntuone.com/files/ <- web ui
[14:07] <sladen> dobey: what does that URL give (if you're successfully logged in).  Is it a directory listing equivalent to the contents of  ~/Ubuntu One/
[14:08] <dobey> sladen: it's a file browser view effectively similar to viewing ~/Ubuntu One/ in browser mode in nautilus, yes
[14:10] <sladen> dobey: and you can do upload/download operations equivalent to those undertaken by u1sync-agent
[14:10] <dobey> you can upload files and download files via the web, yes
[14:10] <sladen> dobey: and you can do upload/download operations equivalent to those (handed to the nautilaus extension) and undertaken by u1sync-agent
[14:11] <dobey> the nautilus extension doesn't do anything with files
[14:11] <dobey> it simply sets emblems based on status, and provides UI to share folders
[14:11] <dobey> and a button to connect/disconnect the service
[14:17] <dobey> sigh. palm pre has some ui issues :-(
[14:18] <dobey> and why the hell won't it log in to my mail server :-/
[14:35] <sladen> dobey: interestingly, that nautilus extensions won't have worked for anyone except on amd64 (or whatever arch the buildds are)
[14:40] <dobey> sladen: how do you figure?
[14:55] <dobey> sladen: the nautilus extension is currently in python... so it's architecture independent (the ubuntuone-client package is built for architecture all)
[14:55] <dobey> sladen: and when I finish the C port of it, it will still build on any architecture just fine, and even should work on win32 if you are running nautilus on win32
[14:57] <sladen> dobey: yeah, but that .so file is only being compiled as the architecture of the buildd in question.  (bug #384276)
[14:58] <sladen> it works on all platforms, but only if compiled for each (Architecture: _any_)
[14:58] <dobey> eh
[14:59] <sladen> basic computing 101, different processors have different instruction sets
[14:59] <sladen> i386 binaries do not run on powerpc
[14:59] <sladen> amd64 binaries do not run on sparc
[15:00] <sladen> arm binaries do not run on ia64
[15:01] <sladen> python programs, SVG images files, shell scripts; work on all processor types without recompiling, because they are interpreted and not compiled to the native instruction set
[15:02] <sladen> C libraries must be compiled for each processor type, and the result binary (and package) will only work on that processor type
[15:03] <dobey> i know how architectures work. thank you very much.
[15:05] <dobey> and there isn't an .so in the debian package
[15:07] <sladen> apologies if there isn't.  What is the file in  nautilus/ubuntuone-nautilus.c  compiled to?
[15:07] <dobey> it's not currently compiled by the package build
[15:07] <dobey> it's the in-process port of the extension to C
[15:09] <sladen> ah, so it's not used yet
[15:10] <dobey> right
[15:10] <sladen> The current code being  canonical/ubuntuone/nautilus/nautilus_api.py
[15:15] <sladen> what's "fsm" ?
[15:17] <dobey> file something manager
[15:17] <dobey> sladen: the current code being nautilus/storage.py actually
[15:22] <radix> finite state machine?
[15:26] <sladen> dobey: if an {email,calendar,...} client is written, would have use 'python-u1storage' ?
[15:26] <sladen> dobey: if an {email,calendar,...} client is written, would that use 'python-u1storage' ?
[15:26] <sladen> or what is have it's down low-level protocol
[15:26] <dobey> or maybe finite state machine
[15:27] <dobey> the 'structured storage' thing that we're going to release soon will use the couchdb protocol for replication
[15:28] <sladen> so that's won't share (any) code with the u1sync/u1storage stuff currently released?
[15:31] <sladen> the only thing in common is that that it falls under the same "Ubuntu One" high-level project name
[15:32] <dobey> i don't know what all exactly is shared for code with that, as i haven't been working on it. i've been working on the file storage stuff
[15:32] <dobey> but ubuntuone-storage-protocol is the protocol for filesystem level storage stuff
[15:32] <dobey> ie, the "this is for storing files, not simple text records like contacts/events"
[15:33] <dobey> hrmm, i wonder if i can theme the palm pre
[15:33] <dobey> probably requires mucking about with the firmware though :(
[15:35] <sladen> I'm trying to get my head around whether  replication stuff (in general, not just of files) is built on top of a replicated filesystem protocol (u1storage, currently (only) implemented by ubuntuone-storage-protocol)
[15:37] <sladen> or if u1storage, (a convenience library for remote file access currently called ubuntuone-storage-protocol) is/is going to be implemented on top of some more generic blob/sha1 hash notification system
[15:37] <sladen> I think I confused even myself in writing those two lines
[15:37] <sladen> I'll go and read the code again and try to guess
[15:40] <sladen> ...
[15:41] <sladen> dobey: does the http://ubuntuone.com/files/ work with directories uploaded using the u1sync commandline/ftp tool (not the u1sync-agent)
[15:42] <dobey> sladen: ubuntuone.com/files/ shows you what is in your subscribed storage account. if you upload a directory with u1sync, it will be under My Files/ yes
[15:44] <sladen> BUGabundo: any chance you could do me a screenshot showing http://ubuntuone.com/files/  with both some files/stuff synced via your ~/Ubuntu One/ directory, and also some stuff sycned via the commandline u1sync tool ?
[15:52] <BUGabundo> sladen: not now
[15:54] <dobey> palm pre is sexy, but i really don't want all of my aim/facebook/etc contacts to show up everywhere :(
[15:54] <BUGabundo> on an Assembly
[16:04] <__lucio__> sladen: i thin its called /etc/init.d/ubuntuoneapiserver
[16:48] <dobey> later
[16:49] <BUGabundo> dobey: later
[16:52] <artir> BUGabundo: later
[16:53] <BUGabundo> artir: I'm staying
[16:53] <BUGabundo> lol
[16:53] <artir> I didn't saw the dobey:
[16:53] <artir> xd
[17:14] <sladen> __lucio__: dobey: can you tell me what "updown server" refers to?
[17:14] <__lucio__> sladen: its the server that handles the web uploads and downloads
[17:17] <sladen> __lucio__: so does updown use canonical.ubuntuone.storage.protocol to connect to fs-1 just like another client, or does it access the disk directly
[17:19] <__lucio__> it doesnt use the protocol, no
[17:27] <sladen> can somebody remove the Milestone on  https://bugs.launchpad.net/ubuntuone-client/+bug/377346  and repoint it at the server-end (ubunet)
[17:27] <sladen> it doesn't relate to the client software at all
[17:36] <sladen> with regspect to oauthenciation, what do  'rtu', 'uau', 'atu' refer to?  I'm presuming the 't' is '-to-'
[17:39] <sladen> and same with https://bugs.launchpad.net/ubuntuone-client/+bug/326256  can somebody remove the milestone, repoint it to ubunet and restore the milestone as it doesn't relate to the client software in any way
[18:29] <sladen> __lucio__: what/who is "ISD" ?
[18:59] <sladen> rmcbride: regarding 100meg.file  etc, is it really that big?
[18:59] <sladen> rmcbride: and for things like the JPGs, what's the license of those?


[03:24] <OvenWerks> Would missing data have anything to do with AMD governor? Anyway. Hope you find it all
[03:25] <OvenWerks> Eickmeyer: Is it reasonable to expect a user to hit the enter/return as part of entering a new name for a pulse bridge?
[03:37]  * OvenWerks thinks he will assume so
[03:50] <Eickmeyer> OvenWerks: Yes, absolutely.
[03:50] <OvenWerks> makes things easier
[03:50] <Eickmeyer> And no, looks like a good chunk of the data is gone. The good news is that everything git-wise was pushed, so we're good.
[05:53] <OvenWerks> I seem to have found the trick... pulse bridging works much better...
[05:53] <OvenWerks> prolly means I need to do the same for the rest of the jack stuff.
[05:54] <OvenWerks> The trick... with a combo box is that when it is updated or refilled it emits a signal even if it is set sensitive = False
[05:55] <Eickmeyer> Oh! Cool!
[05:57] <OvenWerks> So the user changes it and we save it ... refilling the widget which emits signal again and goes in circles... so I set a flag with a timed loop that does the update and while that flag is set signals are ignored... but that means everything gets up dated and there is a delay.
[05:58] <OvenWerks> so instead, I set the widgets I want to deal with to sensitive: False and just check that instead of my flag. It means I just change what has to be changed and there is no delay.
[05:59] <OvenWerks> pending publish
[06:00] <OvenWerks> I have had Carla crash a few times.
[06:00] <Eickmeyer> Oh cool! I'm guessing that cuts the checks it does and lowers the CPU usage.
[06:00] <Eickmeyer> Yeah, new version of Carla is around the corner. Filipe is working hard.
[06:00] <OvenWerks> Maybe not much...
[06:02] <OvenWerks> .7 while jack is running but 3.3 peaks when stopped.
[06:03] <OvenWerks> bounces back and forth in top from .7 to 3.3 or so
[06:03] <Eickmeyer> Interesting. Makes sense, but 3.3 still seems a little high, but I guess it doesn't matter if Jack isn't running since one probably won't be using that interface much if at all.
[06:04] <OvenWerks> xfce task manager shows "0"
[06:04] <OvenWerks> also shows total cpu as 3-4%
[06:05] <Eickmeyer> I'd play around with it, but as stated earlier, that installation went belly-up.
[06:05] <OvenWerks> no worries.
[06:12] <OvenWerks> wonko: I have probably done what you wanted to do already :P
[06:12] <OvenWerks> wonko: feel free to do more though


[00:06] <AlanBell> this is a launchpad team https://launchpad.net/~accessibility
[00:06] <JanC> hajour: a group of users on launchpad
[00:06] <JanC> like the one AlanBell points to
[00:08] <hajour> ok i go look .thanks
[00:09] <hajour> professional people i assume ?
[00:15] <Pendulum> hajour: nope, that's the launchpad team for us
[00:19] <hajour> a ok
[00:21] <hajour> i am not in a launchpadteam i think
[00:22] <hajour> if i understand my page on launchpad
[00:25] <charlie-tca> hajour, you can join the launchpad team for accessibility
[00:25] <hajour> how can i do that?
[00:26] <charlie-tca> go to that team in firefox and find a button that says "join"
[00:27] <charlie-tca> there should be a "join this team" on the right side
[00:27] <hajour> done
[00:27] <hajour> do i have to do something more?
[00:28] <charlie-tca> Did it say anything?
[00:28] <hajour> You have successfully joined Accessibility.
[00:28] <charlie-tca> Great! Now you are on a team
[00:29] <hajour> thought i already was in the team :))
[00:29] <charlie-tca> We have many places to join and help
[00:29] <charlie-tca> You are in the team here. You are in the team on forums, I think. You are helping the team.
[00:30] <charlie-tca> Now you are a member of the launchpad team
[00:30] <hajour> what can i do for the launchpad
[00:30] <hajour> launchpad team i mean
[00:31] <charlie-tca> You don't do anything. It counts for a how many persons on the team thing
[00:32] <hajour> ok :)thought maybe there was something to help there to
[00:33] <charlie-tca> No, We help in here and on the wiki and stuff
[00:35] <hajour> ok:)
[00:36] <hajour> if the personas are ready where we working do we get then new personas?
[00:37] <hajour> working on i mean
[00:55] <hajour> if i can figure out how inkscape works exactly.i can make drawings with it.
[00:56] <hajour> i wonder if it is more difficult then pencil and paper
[01:07] <hajour> ubuntu thinks further about what people really need.ubuntu the community that really cares about people. just playing with some words
[01:58] <JanC> drawing with a computer tends to be more difficult for some things and easier for other things
[01:59] <hajour> mmm i have to use on it
[01:59] <JanC> and if you like to use crayons, then MyPaint might be interesting
[02:00] <JanC> it can simulate all sorts of crayons, pencils, brushes, etc.
[02:00] <hajour> already drawing years  with pencil and crayons
[02:02] <hajour> i Sal look.inkscape is finally a program what is more understandable for me
[02:08] <hajour> its 3.10 in night here in about 10 minutes i go to sleep
[02:39] <hajour> goodnight all
[07:30] <hajour> hai all
[12:06] <hajour> Pendulum, i like to have that sort information what you have told last night.about the lines.it helps me to make good personas
[12:10] <hajour> i have worked  true last night til 3.45 in night about that in odt documents.if i have enough i put it in by personas again.
[12:12] <hajour> and i are thinking about how to do it.so you and me can read it easy
[12:13] <hajour> first i need to sleep now.only have got 2 and a half hour sleep last night
[12:14] <Pendulum> hajour: yes sleep! please don't burn yourself out on this
[12:14] <Pendulum> you've done a lot of work and you need to take care of yourself first
[12:15] <hajour> sometimes i am lost my out switch.then my mind go s on and on
[12:16] <hajour> i just care very much about this project
[12:18] <hajour> i will be here in evening .that will be in about 7 hours from now
[12:23] <hajour> off to sleep now till later
[22:12] <hajour> hai all
[23:02] <hajour> Pendulum,  ore AlanBell  just a idea for the line problem .Automatic breakup of long sentences in to smaller ones with correct punctuation.
[23:07] <hajour> i am really terrible a wake up and that idea came up.first think i think on is the accessibility program
[23:07] <hajour> first thing i think on i mean
[23:12] <hajour> akk told me there is already something like that.but its not very good.we need a version with better English.
[23:26] <hajour> hai Cheri703