Menu
▾
▴
fofredux-devel — Developers discussion, bug fixing, and coding of fofredux
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(92) |
Dec
(142) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(33) |
Feb
(65) |
Mar
(76) |
Apr
(172) |
May
(124) |
Jun
(45) |
Jul
(76) |
Aug
(78) |
Sep
(1) |
Oct
(20) |
Nov
(6) |
Dec
(2) |
| 2007 |
Jan
(12) |
Feb
(7) |
Mar
(17) |
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Kevin <ke...@dr...> - 2005-12-13 16:17:44
|
Katie Bechtold wrote: >On Mon, Dec 12, 2005 at 11:21:29AM -0700, Kevin wrote: > > >>I'm not saying eliminate the feed table, just trim it down to what is >>absolutely necessary to maintain the relationships between the entities in >>the DB. >> >> > >I say go for it. > > > It was easier then I thought. I had some time this morning to do it. Please review these changes: cvs diff -kk -r PRE_FEEDREFACTOR -r PRE_CR_FEEDREFACTOR -Kevin |
|
From: Kevin <ke...@dr...> - 2005-12-13 05:39:03
|
Miles Beck wrote: >Does anyone know why when I run mysqlcheck it says it cannot find two >files? I checked and the files are there. Below is the output from >mysqlcheck. > >mysqlcheck fofredux >fofredux.fr_categories OK >fofredux.fr_feeds OK >fofredux.fr_items OK >fofredux.px_feeds >error : Can't find file: './fofredux/px_feeds.frm' (errno: 13) >fofredux.px_items >error : Can't find file: './fofredux/px_items.frm' (errno: 13) > >imageconnector:/var/lib/mysql/fofredux# ls >fr_categories.frm fr_feeds.frm fr_items.frm px_feeds.frm px_items.frm >fr_categories.MYD fr_feeds.MYD fr_items.MYD px_feeds.MYD px_items.MYD >fr_categories.MYI fr_feeds.MYI fr_items.MYI px_feeds.MYI px_items.MYI > > > Could it be you don't have permissions? What does the "ls -la" output look like? Is the table accessable through the database? (show tables like 'px_', select * from px_feeds, etc) >Also I noticed that the last update time for when feeds were updates >shows as 'never'. Does anyone know how to fix this so the update time >is populated again? > > Check to see if the cache directory is writable. This happens when the cached file for a feed is missing. -Kevin |
|
From: Kevin <ke...@dr...> - 2005-12-13 05:25:14
|
Miles Beck wrote: >On 12/12/05, Katie Bechtold <ka...@ho...> wrote: > > >>On Mon, Dec 12, 2005 at 06:21:44PM -0700, Miles Beck wrote: >> >> > >*snip* > > > >>I'm having trouble reproducing that error. Are there any particular >>feeds for which that seems more prone to happen? Can you tell us >>what version of PHP you're running? >> >> > >I just looked into this again. And now I can get this to happen all >the time on the bottom Old to New link. Not sure if this happened on >the top link or not. > >Also, when you click the top Old to New link and New to Old link, the >bottom links stays at whatever it was at before. > >For example, clicking on the top Old to New link should also change >the bottom link from Old to New, to New to Old being selected. > >I'm using php4 on Debian. 4.1.10-16 to be specific. >sourceforge.net/lists/listinfo/fofredux-devel > > Fixed. I made a change to the top links, but did not change the bottom ones. -Kevin |
|
From: Miles B. <mil...@gm...> - 2005-12-13 05:20:30
|
Does anyone know why when I run mysqlcheck it says it cannot find two files? I checked and the files are there. Below is the output from mysqlcheck. mysqlcheck fofredux fofredux.fr_categories OK fofredux.fr_feeds OK fofredux.fr_items OK fofredux.px_feeds error : Can't find file: './fofredux/px_feeds.frm' (errno: 13) fofredux.px_items error : Can't find file: './fofredux/px_items.frm' (errno: 13) imageconnector:/var/lib/mysql/fofredux# ls fr_categories.frm fr_feeds.frm fr_items.frm px_feeds.frm px_items.frm fr_categories.MYD fr_feeds.MYD fr_items.MYD px_feeds.MYD px_items.MYD fr_categories.MYI fr_feeds.MYI fr_items.MYI px_feeds.MYI px_items.MYI Also I noticed that the last update time for when feeds were updates shows as 'never'. Does anyone know how to fix this so the update time is populated again? |
|
From: Miles B. <mil...@gm...> - 2005-12-13 05:06:44
|
On 12/12/05, Katie Bechtold <ka...@ho...> wrote: > On Mon, Dec 12, 2005 at 06:21:44PM -0700, Miles Beck wrote: *snip* > I'm having trouble reproducing that error. Are there any particular > feeds for which that seems more prone to happen? Can you tell us > what version of PHP you're running? I just looked into this again. And now I can get this to happen all the time on the bottom Old to New link. Not sure if this happened on the top link or not. Also, when you click the top Old to New link and New to Old link, the bottom links stays at whatever it was at before. For example, clicking on the top Old to New link should also change the bottom link from Old to New, to New to Old being selected. I'm using php4 on Debian. 4.1.10-16 to be specific. |
|
From: Kevin <ke...@dr...> - 2005-12-13 02:52:00
|
Katie Bechtold wrote: >On Mon, Dec 12, 2005 at 06:21:44PM -0700, Miles Beck wrote: > > >>I just got the latest files from cvs and was checking it out. I >>noticed that sometimes when clicking the Old to New link I get the >>below error. >> >>Above the panel I see the following error: >>error with fof_category_rows() >> >> > >I'm having trouble reproducing that error. Are there any particular >feeds for which that seems more prone to happen? Can you tell us >what version of PHP you're running? > > > I've seen this also, but I can't reproduce it with the latest from CVS. The problem is category=None is passed in the URL instead of category=1 --Kevin |
|
From: Katie B. <ka...@ho...> - 2005-12-13 02:40:50
|
On Mon, Dec 12, 2005 at 06:21:44PM -0700, Miles Beck wrote: > I just got the latest files from cvs and was checking it out. I > noticed that sometimes when clicking the Old to New link I get the > below error. > > Above the panel I see the following error: > error with fof_category_rows() I'm having trouble reproducing that error. Are there any particular feeds for which that seems more prone to happen? Can you tell us what version of PHP you're running? -- Katie Bechtold http://hoteldetective.org/ |
|
From: Katie B. <ka...@ho...> - 2005-12-13 02:15:17
|
On Mon, Dec 12, 2005 at 11:21:29AM -0700, Kevin wrote: > I'm not saying eliminate the feed table, just trim it down to what is > absolutely necessary to maintain the relationships between the entities in > the DB. I say go for it. -- Katie Bechtold http://hoteldetective.org/ "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 |
|
From: Miles B. <mil...@gm...> - 2005-12-13 01:21:49
|
I just got the latest files from cvs and was checking it out. I noticed that sometimes when clicking the Old to New link I get the below error. Above the panel I see the following error: error with fof_category_rows() Then below the Old to New and New to Old links is the following error: Cannot query database. Have you run install.php? MySQL says: Unknown column 'None' in 'where clause' If I then click on the New to Old link and then try the Old to New link again it works. -Miles |
|
From: Kevin <ke...@dr...> - 2005-12-12 18:45:02
|
> On Sun, Dec 11, 2005 at 04:15:55PM -0700, Kevin wrote: >> 1) My beef with the way it is implemented basically boils down to this= : >> The way the image url is stored in the DB goes against standard >> normalization practices. > > I've commited the change to the repository; the image URL is now > stored in the feeds table rather than in the items table. > > >> Here's the rss url that is the problem: http://www.fark.com/fark.rss > > What's happening there is fark's server checking the referrer field: Good catch. What are the possible workarounds? One way I can think of is to cache th= e image file locally, either on the filesystem or in the DB. --=20 Kevin |
|
From: Katie B. <ka...@ho...> - 2005-12-12 18:36:23
|
On Sun, Dec 11, 2005 at 04:15:55PM -0700, Kevin wrote: > 1) My beef with the way it is implemented basically boils down to this: > The way the image url is stored in the DB goes against standard > normalization practices. I've commited the change to the repository; the image URL is now stored in the feeds table rather than in the items table. > Here's the rss url that is the problem: http://www.fark.com/fark.rss What's happening there is fark's server checking the referrer field: $ wget http://img.fark.com/images/2002/links/fark.gif --13:30:51-- http://img.fark.com/images/2002/links/fark.gif => `fark.gif' Resolving img.fark.com... 207.58.150.106 Connecting to img.fark.com|207.58.150.106|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 788 [image/gif] 100%[====================================================================>] 788 --.--K/s 13:30:51 (39.55 MB/s) - `fark.gif' saved [788/788] $ wget --referer='http://somewhere.else.com/' http://img.fark.com/images/2002/links/fark.gif --13:27:37-- http://img.fark.com/images/2002/links/fark.gif => `fark.gif.1' Resolving img.fark.com... 207.58.150.106 Connecting to img.fark.com|207.58.150.106|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 13:27:37 ERROR 403: Forbidden. -- Katie Bechtold http://hoteldetective.org/ |
|
From: Kevin <ke...@dr...> - 2005-12-12 18:27:28
|
> Ok, that's what I had thought may have been happening (sem-random sort > order). I don't know if the order *needs* to be exactly correct when > the dcdate or timestamp are the same, but at least keeping the feed > order consistent is a must. > > This change should be made and will be put in the 0.2 Release Candidate= . > Thanks for your help > Andy Glad to hear it. I always thought it was strange FoF didn't use the DB for sorting the lists of feeds/items. --=20 Kevin |
|
From: Kevin <ke...@dr...> - 2005-12-12 18:21:33
|
The issue on where to stick the feed image url got me thinking... Q: Why do we need to store the image URL in the database at all? More generally, why do we need to store any of the extra RSS feed info in the DB? I'm not saying eliminate the feed table, just trim it down to what is absolutely necessary to maintain the relationships between the entities i= n the DB. For the following columns, what I am suggesting is use the magpie rss cache as the only place where the data is stored for the application.=20 Magpie does a great job with caching the parsed RSS/Atom data structure.=20 So, I don't think we will see much of a performance hit from doing it thi= s way. I've only listed the non-critical attributes for a feed. The interface will not brake horribly if these are not available. (ex: cache file missing and feed is down) * description * latitude * longitude * type * image Comments? --=20 Kevin |
|
From: Andrew T. (nilspace) <nil...@us...> - 2005-12-12 18:10:16
|
Ok, that's what I had thought may have been happening (sem-random sort order). I don't know if the order *needs* to be exactly correct when the dcdate or timestamp are the same, but at least keeping the feed order consistent is a must. This change should be made and will be put in the 0.2 Release Candidate. Thanks for your help Andy On 12/12/05, Kevin <ke...@dr...> wrote: > > > Ok - I've noticed this over the past couple of days - but only > > verified it this morning. > > > > When I'm reading feeds, I"ll choose "flag all up to this item". If I > > click on, say, the fourth feed, and then click "mark as read", I > > notice that what was supposed to be the next newest item is still down > > on the list (originally I thought it marked it as read), and items > > that were lower (or not there?) are now at the top, chronilogically. > > > > Perhaps this is something to do with the timestamp for ordering? I'm > > still investigating, but I wanted to put it out there for you devs to > > also keep an eye out for. Before you click "Mark as Read" on a number > > of flagged entries, see what the next item (that is unflagged) is and > > see if it's at the top of your items when you click "Read". > > > > For identical values in the sort column (currently dcdate), it is not > guaranteed the item order will be consistent. > > I see this often for feeds which don't include a pubDate or dcdate. The > fallback is to use the cache timestamp. > > We could change this behavior easily by using SQL and specifying 2 sort > columns. > > "SELECT ... ORDER BY dcdate, id" > > -- > Kevin > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
|
From: Kevin <ke...@dr...> - 2005-12-12 17:43:15
|
> Ok - I've noticed this over the past couple of days - but only > verified it this morning. > > When I'm reading feeds, I"ll choose "flag all up to this item". If I > click on, say, the fourth feed, and then click "mark as read", I > notice that what was supposed to be the next newest item is still down > on the list (originally I thought it marked it as read), and items > that were lower (or not there?) are now at the top, chronilogically. > > Perhaps this is something to do with the timestamp for ordering? I'm > still investigating, but I wanted to put it out there for you devs to > also keep an eye out for. Before you click "Mark as Read" on a number > of flagged entries, see what the next item (that is unflagged) is and > see if it's at the top of your items when you click "Read". > For identical values in the sort column (currently dcdate), it is not guaranteed the item order will be consistent. I see this often for feeds which don't include a pubDate or dcdate. The fallback is to use the cache timestamp. We could change this behavior easily by using SQL and specifying 2 sort columns. "SELECT ... ORDER BY dcdate, id" --=20 Kevin |
|
From: Andrew T. (nilspace) <nil...@us...> - 2005-12-12 16:04:23
|
Ok - I've noticed this over the past couple of days - but only verified it this morning. When I'm reading feeds, I"ll choose "flag all up to this item". If I click on, say, the fourth feed, and then click "mark as read", I notice that what was supposed to be the next newest item is still down on the list (originally I thought it marked it as read), and items that were lower (or not there?) are now at the top, chronilogically. Perhaps this is something to do with the timestamp for ordering? I'm still investigating, but I wanted to put it out there for you devs to also keep an eye out for. Before you click "Mark as Read" on a number of flagged entries, see what the next item (that is unflagged) is and see if it's at the top of your items when you click "Read". Andy -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
|
From: Andrew T. (nilspace) <nil...@us...> - 2005-12-12 15:20:30
|
Ok - so we have a plan for resolving the RSS image storage? You can make use of the cache directory if that may help too (and check for updates on feed update? - at some point we probably want to add an "update feed settings" that will go through and attempt to rediscover lost feeds, grab any new metadata (name change, location change), and the favicon) Unfortunately, I think changes happened before and after this icon change. What do you all think about having Katie get these changes into 0.2. The alternative is rolling back around the RSS image changes. Thanks, Andy On 12/12/05, Katie Bechtold <ka...@ho...> wrote: > On Sun, Dec 11, 2005 at 04:15:55PM -0700, Kevin wrote: > > The way the image url is stored in the DB goes against standard > > normalization practices. The feed image URL is stored as a column in > > the items table. If the feed has 1000 items, the identical image URL > > is stored 1000 times in the db, when it really should only be stored > > once. (in the feed table, not the items table) > > I wrote to the original patch author asking why he implemented it > that way -- it seems wrong to me, too -- and I got no response. So > I plan to change it so the image URL is stored as a column in the > feeds table instead ASAP. > > > I think this change should be made before release. It will be alot > > harder to do afterwards. > > I agree; it will be a mess if we change it on users post-release. > > > 2) I have one feed where it shows the broken image icon, when the url i= s > > correct. ... > > Here's the rss url that is the problem: http://www.fark.com/fark.rss > > I'm seeing the same problem with that feed image, but I don't yet > know how to explain it. > > -- > Katie Bechtold http://hoteldetective.org/ > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
|
From: Katie B. <ka...@ho...> - 2005-12-12 15:02:07
|
On Sun, Dec 11, 2005 at 04:15:55PM -0700, Kevin wrote: > The way the image url is stored in the DB goes against standard > normalization practices. The feed image URL is stored as a column in > the items table. If the feed has 1000 items, the identical image URL > is stored 1000 times in the db, when it really should only be stored > once. (in the feed table, not the items table) I wrote to the original patch author asking why he implemented it that way -- it seems wrong to me, too -- and I got no response. So I plan to change it so the image URL is stored as a column in the feeds table instead ASAP. > I think this change should be made before release. It will be alot > harder to do afterwards. I agree; it will be a mess if we change it on users post-release. > 2) I have one feed where it shows the broken image icon, when the url is > correct. ... > Here's the rss url that is the problem: http://www.fark.com/fark.rss I'm seeing the same problem with that feed image, but I don't yet know how to explain it. -- Katie Bechtold http://hoteldetective.org/ |
|
From: Kevin <ke...@dr...> - 2005-12-11 23:27:25
|
Miles Beck wrote: >In the feed listing I am getting (Unkown feed type) for all listed feeds. > >I've attached a png file to show what I mean. > >-Miles > > When you update a feed, it should refresh the feed type to the actual version contained in the rss url. I had this same problem. --Kevin |
|
From: Kevin <ke...@dr...> - 2005-12-11 23:19:05
|
Katie Bechtold wrote: >On Sat, Dec 10, 2005 at 01:20:42PM -0700, Kevin wrote: > > >>Problem: The feed image handling needs work. It doesn't work for me >>and the way it's implemented just has a bad smell. I'm of the opinion >>we should back that out until after the release. >> >> > >When you say the image handling doesn't work for you, is it not >displying images for feeds that you know have them? Or are you >getting some error? > >Could you share what you don't like about how it's implemented? > > > 1) My beef with the way it is implemented basically boils down to this: The way the image url is stored in the DB goes against standard normalization practices. The feed image URL is stored as a column in the items table. If the feed has 1000 items, the identical image URL is stored 1000 times in the db, when it really should only be stored once. (in the feed table, not the items table) I think this change should be made before release. It will be alot harder to do afterwards. 2) I have one feed where it shows the broken image icon, when the url is correct. What's strange is, this is the only feed out of 15 which have images that I know of.. I don't get what's different with this one feed. I've tried Firefox 1.5, Opera 8, and IE6. All do the same thing: When I view the feed items, it either shows a broken image icon, or nothing at all. Here's the rss url that is the problem: http://www.fark.com/fark.rss |
|
From: Miles B. <mil...@gm...> - 2005-12-11 18:15:21
|
In the feed listing I am getting (Unkown feed type) for all listed feeds. I've attached a png file to show what I mean. -Miles |
|
From: Katie B. <ka...@ho...> - 2005-12-11 09:02:29
|
On Sat, Dec 10, 2005 at 01:20:42PM -0700, Kevin wrote: > Problem: The feed image handling needs work. It doesn't work for me > and the way it's implemented just has a bad smell. I'm of the opinion > we should back that out until after the release. When you say the image handling doesn't work for you, is it not displying images for feeds that you know have them? Or are you getting some error? Could you share what you don't like about how it's implemented? -- Katie Bechtold http://hoteldetective.org/ |
|
From: Kevin <ke...@dr...> - 2005-12-10 20:23:51
|
Andrew Turner (nilspace) wrote: >Hey everyone - please hold off on commits to CVS for a day or two. I >didn't realize which versions were which. > >Unless I hear otherwise, I'm calling the *current* CVSHEAD, Release >Candidate v0.2 (perhaps 0.2.2 :) Anyways, in order to prevent >confusion, don't check anything in until I let you know that I've >tagged the repos. > > > Problem: The feed image handling needs work. It doesn't work for me and the way it's implemented just has a bad smell. I'm of the opinion we should back that out until after the release. |
|
From: Andrew T. (nilspace) <nil...@us...> - 2005-12-10 19:55:45
|
Hey everyone - please hold off on commits to CVS for a day or two. I didn't realize which versions were which. Unless I hear otherwise, I'm calling the *current* CVSHEAD, Release Candidate v0.2 (perhaps 0.2.2 :) Anyways, in order to prevent confusion, don't check anything in until I let you know that I've tagged the repos. Thanks, Andy -- Andrew Turner ajt...@hi... 42.4266N x 83.4931W http://highearthorbit.com Northville, Michigan, USA |
|
From: Miles B. <mil...@gm...> - 2005-12-10 19:53:54
|
I was just updating the files via cvs and got the following error:
cvs -d:pserver:ano...@cv...urcefor =20
ge.net:/cvsroot/fofredux up
cvs update: warning: failed to open /root/.cvspass for reading: No
such file or directory
? cache
? config.php
cvs update: Updating .
U config.php.sample
P edit.php
P fof.css
RCS file: /cvsroot/fofredux/fofredux/init.php,v
retrieving revision 1.17
retrieving revision 1.22
Merging differences between 1.17 and 1.22 into init.php
rcsmerge: warning: conflicts during merge
cvs update: conflicts found in init.php
C init.php
P install.php
P view.php
cvs update: Updating magpierss
cvs update: Updating magpierss/extlib
Then when I try and load FoFRedux I get the following error:
<<<<<<< init.php =3D=3D=3D=3D=3D=3D=3D
Fatal error: Cannot redeclare fof_get_feeds() (previously declared in
/var/www/fofredux_RC-0_2/init.php:62) in
/var/www/fofredux_RC-0_2/init.php on line 1164
|
5 messages has been excluded from this view by a project administrator.
