We’ve just deployed a change that now caches all the sidebar elements both on the server and on the client. As a result its quite feasible that the top contributors may be a little out of sync with user profile page. Its cached for an hour so changes will only appear after an hour.
wmoore
- Mar 21, 2010, 2:57 AM; 0 points) 's comment on Spring 2010 Meta Thread by (
Darius recently updated the Hacking on Less Wrong wiki page to include instructions for getting up and running on Ubuntu 8.10. He’s just set up an install on 9.04 as well and has some notes on the experience. I’ll ask him to add them to the wiki page too.
I have added links to the mailing list in the README in the code (which GitHub shows) and also on the ‘Home’ wiki page.
Hmm interesting observation. Not sure why that’s happening. Raised an issue to investigate.
Yes it seems this is something that needs to be brought back, there is an issue for this that I raised a while back.
Fair comments. I’ve raised an issue to revisit its use and location.
This is pretty much right, it uses a big key value store. The issue with karma is that the Account record maintains the karma value but the vote is stored as a separate relationship between the Account and the Link (article). Generally is is not safe to update the database directly as it is necessary to keep the separate memcache coherent. Thus any changes must be done via Python code. Whilst such a change is possible and relatively straightforward I’m not sure its worth it. From what I’ve seen there are no truly obnoxious users on less wrong that need to be dealt with by such a change.
Yes that’s correct. So on default settings all content is still visible.
The changes Eliezer refers to have now been deployed.
The karma underflow bug should have been fixed now.
Raised issue #157 to track this.
We need to run a periodic process on the server to make rising work. I’ve raised an issue to address this.
We deployed a fix yesterday that addresses this problem. The bug was influenced by the caching that is employed, which is why it happens sometimes but not others.
Indentation implies preformatted text. The 1. should be at the start of the line.
This is a numbered list item. In the text box, it wasn’t 4 spaces, followed by “1.”, followed by the rest of the text. If this line is longer than your browser window is wide, it will wrap.
If you want to nest lists, then you need to indent the second list item.
First level
This is a numbered list item. In the text box, it was 3 spaces, followed by “1.”, followed by the rest of the text. If this line is longer than your browser window is wide, it will wrap.
Full Markdown documentation is available on Daring Fireball
I’ve applied a fix for this today. The links should now be valid.
There is no way to do this at the moment. I’ve raised a feature request for it. #123
This problem has been fixed and Issue #120 resolved.
There is an about link permanently in the top navigation bar now.
We filter user submitted HTML to remove potentially unsafe content. style attributes are one of the things that gets removed because in IE you can embed javascript in them. I thought that all of the markup the editor was generating was permitted but it looks like this one case where that’s not true. I’ve raised an issue to fix it. #122
We tested the change in Firefox for Linux (3 on Ubuntu 9.04). What version are you using? Do you have JavaScript turned off or anything like that?