The download counters for xpressive.zip and foreach.zip dropped to 1 for some reason. I seem to recall this happening before. There seems to be some bug wrt the download counters -- possible some race condition? -- Eric Niebler Boost Consulting www.boost-consulting.com
--- Eric Niebler wrote:
The download counters for xpressive.zip and foreach.zip dropped to 1 for some reason. I seem to recall this happening before. There seems to be some bug wrt the download counters -- possible some race condition?
The counter for mpl_math.zip dropped to nil. Cromwell D. Enage __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Cromwell Enage wrote:
--- Eric Niebler wrote:
The download counters for xpressive.zip and foreach.zip dropped to 1 for some reason. I seem to recall this happening before. There seems to be some bug wrt the download counters -- possible some race condition?
The counter for mpl_math.zip dropped to nil.
Sorry to say but I have no clue what the problem is :-( -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Cromwell Enage wrote:
--- Eric Niebler wrote:
The download counters for xpressive.zip and foreach.zip dropped to 1 for some reason. I seem to recall this happening before. There seems to be some bug wrt the download counters -- possible some race condition?
The counter for mpl_math.zip dropped to nil.
Sorry to say but I have no clue what the problem is :-(
It doesn't make sense to have download counters at all, really, if they randomly drop to zero every now and then. Just a few days ago you made a change that allowed the counters to be preserved when uploading a file of the same name. The problems started shortly thereafter. Coincidence? -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Rene Rivera wrote:
Sorry to say but I have no clue what the problem is :-(
It doesn't make sense to have download counters at all, really, if they randomly drop to zero every now and then.
I didn't say it was random... Just that I don't know the cause ;-)
Just a few days ago you made a change that allowed the counters to be preserved when uploading a file of the same name. The problems started shortly thereafter. Coincidence?
Don't know. Are the two instances mentioned so far for files that got re-uploaded? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Eric Niebler wrote:
Just a few days ago you made a change that allowed the counters to be preserved when uploading a file of the same name. The problems started shortly thereafter. Coincidence?
Don't know. Are the two instances mentioned so far for files that got re-uploaded?
No, I hadn't re-uploaded either foreach.zip or xpressive.zip. These were the two most frequently downloaded files, though, so perhaps it has something to do with two people downloading simultaneously. Just a wild guess. I don't know about mpl_math.zip, though. -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" <eric@boost-consulting.com> wrote
It doesn't make sense to have download counters at all, really, if they randomly drop to zero every now and then.
Frustrating though it is (I had to drop typeof download counter in the past from 99 to zero, because I had to re-upload the file initialy uploaded by Peder), I think it's a very useful tool, even though imperfect, providing a good indication of amount of interest combined with author(s) activity. FWIW, if not download counter, there would be no BOOST_TYPEOF now. Anybody knows where it is stored? Maybe a simple backup procedure would help... Regards, Arkadiy
Arkadiy Vertleyb wrote:
"Eric Niebler" <eric@boost-consulting.com> wrote
It doesn't make sense to have download counters at all, really, if they randomly drop to zero every now and then.
Anybody knows where it is stored? Maybe a simple backup procedure would help...
I know exactly where it's stored :-) And as a temporary measure I can manually reset the count back up. People would have to tell me the path to the file and the count it should be. I have to trust people to not lie about the count, but I think Booster are generally honest. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
I know exactly where it's stored :-) And as a temporary measure I can manually reset the count back up. People would have to tell me the path to the file and the count it should be. I have to trust people to not
--- Rene Rivera wrote: lie about
the count, but I think Boosters are generally honest.
In Template Metaprogramming / mpl_math.zip, the last count was 126. Cromwell D. Enage __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Cromwell Enage wrote:
In Template Metaprogramming / mpl_math.zip, the last count was 126.
Grr... OK scratch the option of changing the count manually. The file system permissions don't allow it :-( I'll figure something else out eventually (I would have to add to the phpATM web interface to allow me to change the count.) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Arkadiy Vertleyb wrote:
"Eric Niebler" <eric@boost-consulting.com> wrote
It doesn't make sense to have download counters at all, really, if they randomly drop to zero every now and then.
Frustrating though it is (I had to drop typeof download counter in the past from 99 to zero, because I had to re-upload the file initialy uploaded by Peder), I think it's a very useful tool, even though imperfect, providing a good indication of amount of interest combined with author(s) activity. FWIW, if not download counter, there would be no BOOST_TYPEOF now.
You misunderstand. My comment was not out of frustration. It's a matter-of-fact observation that if the download counters randomly and periodically drop to zero, then the numbers have NO meaning. They didn't go to zero because someone set them to zero, or because someone deleted and/or re-uploaded a file. They just mysteriously went to zero. Knowing this can happen, what can you infer about a file by looking at its download counter? It also doesn't make sense for Rene to "fix" the counters manually because it'll just happen again. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
It also doesn't make sense for Rene to "fix" the counters manually because it'll just happen again.
No it doesn't :-) The real solution would be to fix the source of the problem. That source is the use of the PHP flock function to do the synchronization which has unsolvable issues <http://www.php.net/manual/en/function.flock.php> -- That leaves one other solution which is to patch phpATM to use some for of reliable database. Which means forking even more the phpATM code, which is OK as it's GPL. But it's more maintenance for us. Or ultimately finding something other than phpATM that works better. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
"Eric Niebler" <eric@boost-consulting.com> wrote
Arkadiy Vertleyb wrote:
"Eric Niebler" <eric@boost-consulting.com> wrote
It doesn't make sense to have download counters at all, really, if they randomly drop to zero every now and then.
Frustrating though it is (I had to drop typeof download counter in the
from 99 to zero, because I had to re-upload the file initialy uploaded by Peder), I think it's a very useful tool, even though imperfect,
past providing a
good indication of amount of interest combined with author(s) activity. FWIW, if not download counter, there would be no BOOST_TYPEOF now.
You misunderstand. My comment was not out of frustration. It's a matter-of-fact observation that if the download counters randomly and periodically drop to zero, then the numbers have NO meaning. They didn't go to zero because someone set them to zero, or because someone deleted and/or re-uploaded a file. They just mysteriously went to zero. Knowing this can happen, what can you infer about a file by looking at its download counter?
I did understand. What I was trying to say is that the error needs to be corrected at some point, but meanwhile, even as is, the counter provides useful information _for library authors_. I used it to determine interest in typeof, which was otherwise undetectable. I can also see some interest in RTL, and this also is pretty much the only indicator of this interest. Even if tomorrow the download counter for RTL drops, I can still monitor the reaction to any particular change, and this is quite useful, IMO. Regards, Arkadiy
Arkadiy Vertleyb wrote:
even as is, the counter provides useful information _for library authors_. I used it to determine interest in typeof, which was otherwise undetectable.
Ah, ok. Good point. But for everybody else, the numbers are pretty misleading. I could easily see somebody put off a library because of an uncommonly low download counter. "Well, it couldn't be that interesting or more people would have downloaded it." I'm not sure what we should do. Leave it alone until something better comes along, I suppose. -- Eric Niebler Boost Consulting www.boost-consulting.com
participants (4)
-
Arkadiy Vertleyb -
Cromwell Enage -
Eric Niebler -
Rene Rivera