Thread: [Flickrfs-users] Bug fixes and my enhancement checked in.
Brought to you by:
manishrjain
Menu
▾
▴
flickrfs-users
|
From: <rdm...@bi...> - 2006-02-08 19:27:49
|
I've checked in the bug fixes that have been talked about here, as well as my ctime/mtime enhancement. I've put comments in the README for each bugfix/enhancement. I'm not sure if the REAME is supposed to be the changelog or if I should create a changelog? If it's OK with you, Manish, I'd next like to do something that I actually enjoy, though many programmers don't: refactoring. I can see several places where the code could be tightened up and simplified, now that you've roughed out how it all works. It will mean some fairly radical changes to the code, but in the end I think it will be easier to maintain and enhance (or I wouldn't suggest I do it!). --David |
|
From: Manish R. J. <man...@gm...> - 2006-02-09 02:03:11
|
On 2/9/06, rdm...@bi... <rdm...@bi...> wrote:
>
> I've checked in the bug fixes that have been talked about here, as well
> as my ctime/mtime enhancement. I've put comments in the README for
> each bugfix/enhancement. I'm not sure if the REAME is supposed to be
> the changelog or if I should create a changelog?
Gr8 that you finished off the ctime/mtime functionality. And I think it wd
be more useful if ctime is 'time photo is taken' extracted from photos Exif
data. While utime wd be the time when photo is uploaded.
If it's OK with you, Manish, I'd next like to do something that I
> actually enjoy, though many programmers don't: refactoring. I can see
> several places where the code could be tightened up and simplified,
> now that you've roughed out how it all works. It will mean some fairly
> radical changes to the code, but in the end I think it will be easier
> to maintain and enhance (or I wouldn't suggest I do it!).
Ok David. No probs with me, but I got some concerns. Lot of changes may ten=
d
to break the code. To make sure that the changes can be tracked, and the
code is still working, it wd be better to do all the changes followed by
thorough testing locally, and then put it upstream in 1 go, instead of doin=
g
cvs update after each small change.
Also, there are some functionalities and testing I wanted to complete:
1. Automatically resizing the photos to 800x600, 1024x728 etc. while
uploading. The user will specify which resolution the photos shd be
converted to through a 'settings.properties' file located in flickrfs Home
directory.
2. Meta data - I have tested the editing of metadata files through sed, vim=
,
and gedit. But more tests need to be done on other editors, for e.g. nano,
xemacs
3. Sync any changes done directly to flickr with flickrfs (while its still
mounted obv). This will mean flickrfs can automatically detect any new
photos uploaded to flickr (directly), and show them. Also means, that any
change in meta-data will be reflected as well. Though search results i.e.
tags/public or tags/personal need not be affected (or even synced).
It wd be best to do this using a command rather than a time bound
recurring thread. This wd prevent any inconsistencies.
I'd like someone to take these up, and remove the final obstacles to 'using
flickrfs'.
Manish
--
http://tuxmann.blogspot.com
"If I have seen further it is by standing on the shoulders of Giants"
"Software is like sex: it's better when it's free."
"An infinite number of monkeys typing into GNU emacs would never make a goo=
d
program."
|
|
From: <rdm...@bi...> - 2006-02-09 02:55:56
|
On Thu, 9 Feb 2006 at 10:03, Manish Rai Jain wrote: > On 2/9/06, rdm...@bi... <rdm...@bi...> wrote: > Gr8 that you finished off the ctime/mtime functionality. And I think it wd > be more useful if ctime is 'time photo is taken' extracted from photos Exif > data. While utime wd be the time when photo is uploaded. If by 'utime' you mean what is in the code self.atime, then yes I agree that makes maximum use of the available data. So date_taken=ctime, last_update=mtime, and date_uploaded=atime. >> If it's OK with you, Manish, I'd next like to do something that I >> actually enjoy, though many programmers don't: refactoring. I can see >> several places where the code could be tightened up and simplified, >> now that you've roughed out how it all works. It will mean some fairly >> radical changes to the code, but in the end I think it will be easier >> to maintain and enhance (or I wouldn't suggest I do it!). > > Ok David. No probs with me, but I got some concerns. Lot of changes may tend > to break the code. To make sure that the changes can be tracked, and the > code is still working, it wd be better to do all the changes followed by > thorough testing locally, and then put it upstream in 1 go, instead of doing > cvs update after each small change. The way I do this is I have a test suite. I only check in code when the test suite passes. The only problem is that my test suite doesn't test 100% of the functionality. In particular I'm not currently testing upload. So I guess I'd better figure out a way to do that. Come to think of it I had ideas about that when I first started writing the tests but had to give up because of some of the bugs I've now fixed, which means I should be able to resurrect that test code... Anyway, the way I'd like to do this is to make incremental changes, checking in as often as I can, where "I can" is defined as the full test suite runs without error. Does that address your concerns? (That methodology, by the way, is what I followed in doing the bug fixes, although in that case I was making more and more of the tests pass with each commit. But I always made sure nothing new broke before I did a check-in.) > Also, there are some functionalities and testing I wanted to complete: How about if I throw this list into a 'TODO' file in CVS? Presently I'll take a look at tackling them. --David |
|
From: Manish R. J. <man...@gm...> - 2006-02-10 00:55:56
|
On 2/9/06, rdm...@bi... <rdm...@bi...> wrote: > > On Thu, 9 Feb 2006 at 10:03, Manish Rai Jain wrote: > > On 2/9/06, rdm...@bi... <rdm...@bi...> wrote: > > Gr8 that you finished off the ctime/mtime functionality. And I think it > wd > > be more useful if ctime is 'time photo is taken' extracted from photos > Exif > > data. While utime wd be the time when photo is uploaded. > > If by 'utime' you mean what is in the code self.atime, then yes I > agree that makes maximum use of the available data. So > date_taken=3Dctime, last_update=3Dmtime, and date_uploaded=3Datime. > > >> If it's OK with you, Manish, I'd next like to do something that I > >> actually enjoy, though many programmers don't: refactoring. I can see > >> several places where the code could be tightened up and simplified, > >> now that you've roughed out how it all works. It will mean some fairl= y > >> radical changes to the code, but in the end I think it will be easier > >> to maintain and enhance (or I wouldn't suggest I do it!). > > > > Ok David. No probs with me, but I got some concerns. Lot of changes may > tend > > to break the code. To make sure that the changes can be tracked, and th= e > > code is still working, it wd be better to do all the changes followed b= y > > thorough testing locally, and then put it upstream in 1 go, instead of > doing > > cvs update after each small change. > > The way I do this is I have a test suite. I only check in code when the > test suite passes. The only problem is that my test suite doesn't > test 100% of the functionality. In particular I'm not currently testing > upload. So I guess I'd better figure out a way to do that. Come to > think of it I had ideas about that when I first started writing the tests > but had to give up because of some of the bugs I've now fixed, which > means I should be able to resurrect that test code... > > Anyway, the way I'd like to do this is to make incremental changes, > checking in as often as I can, where "I can" is defined as the full > test suite runs without error. Does that address your concerns? > (That methodology, by the way, is what I followed in doing the bug fixes, > although in that case I was making more and more of the tests pass with > each commit. But I always made sure nothing new broke before I did > a check-in.) Ok gr8. Go ahead. > Also, there are some functionalities and testing I wanted to complete: > > How about if I throw this list into a 'TODO' file in CVS? Presently > I'll take a look at tackling them. Thanks David. Fabio, I'd like you to take up one of the functionalities, an= d complete that. For now, photo resizing is the topmost priority. --David > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat= =3D121642 > _______________________________________________ > Flickrfs-users mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flickrfs-users > -- http://tuxmann.blogspot.com "If I have seen further it is by standing on the shoulders of Giants" "Software is like sex: it's better when it's free." "An infinite number of monkeys typing into GNU emacs would never make a goo= d program." |
|
From: Fabio S. <sp...@gm...> - 2006-02-10 12:53:36
|
> Thanks David. Fabio, I'd like you to take up one of the functionalities, > and complete that. For now, photo resizing is the topmost priority. At your command. :-) Well, it seems pretty easy, I will do that when I'll get the time. Meanwhile, I'm still waiting for support from sourceforge to recover my pass, I will eventually create a new account. Ciao -- Fabio |
|
From: Manish R. J. <man...@gm...> - 2006-02-10 00:58:38
|
The way I do this is I have a test suite. I only check in code when the > test suite passes. Can you please upload the test suite to CVS. Manish |
|
From: <rdm...@bi...> - 2006-02-10 12:39:48
|
On Fri, 10 Feb 2006 at 08:58, Manish Rai Jain wrote: > Can you please upload the test suite to CVS. Done. I've added the set creation test. I'm going to work on fixing the remaining bugs and further improving the tests before I do any refactoring. There is a README with notes on how to run it and what its current status is. Suggestions for improvements and pointers to things it isn't testing are welcome. --David |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X