Project Euler Forum

kotulek wrote:I'm happy to see that PE is back again. Thank you very much euler for you hard work

Seconded - and if you do get that donations link set up, I'd be more than happy to send in a few drinking vouchers, in gratitude for your work.

Kudos for getting the site back so soon!
I am extremely happy to see ProjectEuler back and working. However there is a small amount of disappointment that the forums have been disabled. The forums is one of the main beauties of projecteuler . I think this was essential to reduce the bandwidth consumption. However I would like to suggest that the forums should still be open for some selected problems(for instance the top 20 toughest problems). I think the forums that have a more number of solved users will consume huge amount of bandwidth(since more users will try to access the forums).

I agree with you entirely: the forums are indeed one of the jewels of Project Euler. However, I can assure you that disabling the forums is only a temporary measure. I am getting very close to a workable solution, but time is not on my side. I will have to work on it whenever I get a chance. But assuming my master plan is viable, I estimate that it will be up and running, in some form, by the end of this week.

The "solved by" column on the problems page isn't working, it says for example that p176 solved by 13 users, but there are 14 peoples who have solved all problems.

Yep, number fourteen was for test purposes. Confirms a gremlin.
At least the Top1000 page seems to be correctly updated, the problems and statistics page updating will be looked into.
And we hope to find a comprehensive solution soon.

I was the one that put that to a test. I was doubting the updating of various semi static files.
To be sure I entrered a few solutions, one as hk (disturbing the competition, I know, but for the sake of testing) and a few using some testaccount.
Problem is defined now. I hope Colin (Euler) has time and energy to look into it after his heroic effort to get PE online again.

BjornEdstrom wrote:For web apps, I'm a huge fan of the hybrid approach of using both static files and databases at the same time.

that won't work. you need to display the user status in the top right corner, for example.
any dynamic website like this won't work with the static file approach.

but why not cache data structures? it's a common practice, and the only thing it needs is
disk space or RAM, depending on how you cache. for example, there is memcache, quite popular,
really easy to use. i only know the perl API but i guess it's similar for php.
i wonder if you already do some caching like this or not. if not, i'm not surprised about the
problems, really.

things that can be cached very easily: the problems page. just cache the list of problems with
the number of people who solved this as a data structure. this caching even won't take much space.
for every logged-in user cache their stats that you would have to regenerate otherwise.
cache the country/language statistics page. easy. cache statistics for each country.
updating/expiring these caches is easy. as you said you have 2000 correct solutions every day
this would mean 1-2 cache expirations per minute. you expire the problems page, the logged-in
stats, the country/language statistics page and the statics page for the users country.
as soon as a user clicks on a page not cached it will be regenerated and cached. the
cache entry last recently used is thrown out of the cache if you reach your cache size limit.

if the website was written in perl i would certainly offer my help to implement this.
but as i said, it's easy, and the memcached server itself is easy to run.

thanks for putting the forum back so quickly colin!

If you combine the semi-static approach of the delivery of statistics with some little surrounding php, it would be possible to even highlight the current user rank and provide the other statistics pages (user solved tasks, national ranks). You could insert a little bit script into the pages to fill in the contents from a (statically annotated) script table while matching the logged on user against additionally notated user ids in that table.

Thus you keep website delivery a one-stage-process matter of the web browser, but the same time keep the "old good" service level. I would gladly help you with that.

perhaps the google bot is taking up a lot of bandwidth also?