pychan general

pychan is a lightweight (~150 Python LOC and ~450 JavaScript LOC) Python imageboard that uses AJAX requests and JSON responses. Although it lacks some of the detailed features that 4chan has had worked in over the years, it has reached a state that it can run faster and more reliably than 4chan's imageboards.

Source: http://azabani.com/cgit.cgi/pychan
Instance: http://neckbeardchan.azabani.com/

ITT: /prog/'s suggestions, feature requests and such for pychan

It's much improved since the first time you posted it. Good job. I would like to see inline post image expansion.

>>2
That's certainly possible, and I'll get it done some time next week. It's not as easy as just expanding the image, as each 10-second polling cycle will rewrite the DOM tree and kill the expansion. What I'll need to do is expand the image but add the post ID to an array of expanded post IDs, so that when the next polling cycle comes in, I can keep track of which ones should stay expanded.

ONE WORD: THE FORCED INDENTATION OF CODE
THREAD OVER!

>>4
I used Python because it was easy. I don't think that FIOC is bad, though I am capable of writing good-looking code without it. I started it in C, then realised that the development times were ridiculous and I'd never get it done.

>>5
Fair enough.

>>3
Thanks! I'm looking forward to it.

The code looks pretty elegant, well done. One suggestion I have is to combine the JavaScript functions for thread listing and thread viewing -- they're quite similar. You'll cut down a fair bit of LOC.

I'm learning python at the moment, and a section by section tutorial for the code would be great to go along with it all.

>>9
So, you'd like an explanation of how the code works?

>>10
I don't know JS, but one for the python file would be awesome.

I can't believe you wrote the whole interface in pure JS. What browsers are you targeting?

>>12
Chrome and Firefox. Maybe Opera too. Safari and IE are unsupported, though they may work. Right now Opera doesn't work because I seem to have tripped on an Opera bug that causes it to malloc a gigabyte per second, all the way to its crashing death. Chrome and Firefox work great, though.

Traditional CGI is utter shit for scalability, and the process fork overheads will be a pain. Is there a chance that you could write a FastCGI version? Maybe even a hybrid that works on both FastCGI and traditional CGI? It'd eat far less CPU.

>>13
Sure. I haven't done anything with FastCGI before, but I'll give it a go.

I've reported a bug for Opera's weird behaviour:

Dear Opera User,

This is to acknowledge that we have received your bug report, with the ID: (redacted). You may wish to keep this ID for future reference.

All bug reports are read and handled by our staff. However, please note that you will not receive a personal reply to the bug report, unless we need more information to investigate the bug.

We are not able to respond to questions and queries through the bug tracking system. To get help with Opera, please visit http://www.opera.com/support/.

You can use this e-mail address (or reply to this e-mail) to update your report with more information, such as screenshots, crash logs, code examples, and so on:

(redacted)

This is the information you submitted to us:
Version: 11.50
Build: 1074
Operating system: Linux
Platform: PC

Summary: Opera allocates memory while visiting a pychan imageboard until crash

URL: http://neckbeardchan.azabani.com/

Steps to reproduce
===================
1. open a monitor to view the system memory usage
2. open Opera
3. visit the page http://neckbeardchan.azabani.com/

Expected result
===============
The page should load, showing thread posts.

Actual result
=============
The page stays blank with only the light blue background colour. Although the Opera interface is still responsive, the system memory monitor shows that memory usage is increasing very quickly (maybe at about 500MB per second). Opera continues to use more memory until it is eventually killed by the kernel due to allocating memory with none available.

HTTP_USER_AGENT: Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110713 Firefox/8.0a1
HTTP_ACCEPT_LANGUAGE: en


PLUGINS:
===========
Google Talk Plugin Video Accelerator (Google Talk Plugin Video Accelerator version:0.1.44.5) libnpgtpo3dautoplugin.so
Google Talk Plugin (Version: 2.1.7.0) libnpgoogletalk64.so
Shockwave Flash (Shockwave Flash 10.3 d162) libflashplayer.so

AJAX is bad because Javascript is bad because client-side web scripting is bad because HTML is a document format and should never have been interactive in any way. Also, applets are bad and HTML5 is the most horrific monstrosity I have ever set my eyes upon.

>>17
Deal with it, you luddite.

>>17
EVERYTHING SHUOLD BE FLASH

>>19
I heartily laughed.

>>17
So don't get on the internet then.

>>17
/prog/ is interactive. Being hypocritical, are we now?

>>21
Pretty much. I'm convinced that HTML5 was created for the sole purpose of pissing me off.

>>22
Not at all. Putting up with it doesn't mean I like it. I'd much rather have a separate protocol for bulletin boards and leave HTTP as a protocol for downloading only.

>>24
Not only have I made pychan so that it returns all requests as JSON, making it not bound to HTML, but rather, transformable into any output format you'd like, but it's easy for me to unbind it from CGI, making it non-HTTP-dependent. But people like using the web; it's accessible.

>>25
Oh, cool.

>>25
Goddamn I wish I understood what you said. ;_;

* So, where you trying to cut down on LOCs by removing blank lines? That's horrible.
* Why are you printing HTML inside a code file? That's horrible.
* Why open and close a database connection for each request? Granted, it'll work for CGI, but as Anonymous-san further up pointed out, you do not want to have a website based on CGI, ever.
* Why hardcode MySQL as backend, when you could as well use something like sqlalchemy for transparent DB access?
* Speaking of external dependencies, flup is the standard for FastCGI. Combine it with something like colubrid for an extremely simple WSGI path-mapped application.

>>28
So, where you trying to cut down on LOCs by removing blank lines? That's horrible.
Are you suggesting that I randomly put in blank lines for no reason?
Why are you printing HTML inside a code file? That's horrible.
Where else would I put it? Do you realise that there is only one instance of output HTML in the whole codebase, so it is most efficient to put it there?
Why open and close a database connection for each request? Granted, it'll work for CGI, but as Anonymous-san further up pointed out, you do not want to have a website based on CGI, ever.
I'll do that when I implement FastCGI.
Why hardcode MySQL as backend, when you could as well use something like sqlalchemy for transparent DB access?
Thanks, I'll take that into consideration. Then again, is the demand for other database backends really high?
Speaking of external dependencies, flup is the standard for FastCGI. Combine it with something like colubrid for an extremely simple WSGI path-mapped application.
I'll think about it, but it's unlikely that I'll decide to do this.

So, here's a question to the /prog/ gods: how can I modify index.py to have a hybrid FastCGI/CGI solution? I'd like to make it so that it can run in both environments, not just FastCGI only, or traditional CGI only. Currently it's traditional CGI only.

>>24
HTTP is for hypertext, so it's just fine for /prog/'s use case. AJAX is an abomination of a platform and we need a real network protocols to take care of dynamic web hackery.

>>31
While AJAX has its weaknesses, I think that pychan's use of AJAX is done fairly well and it was a good choice. Sending a whole HTML page for each request for a thread list or view, the way that 4chan et al. do it is stupid.

gonna steal your source and make a million dollars just like moot did to 2chan

>>33
You are free to do with it as you wish, within the terms of the GPL 3. It does not matter to the GPL (nor does it matter to me) if you 'steal' my source and profit.

>>34
I think I will do the same!

>>35
I am merely flattered that you think my code is good. Granted, it probably isn't, but hey.

moot is a faggot
I'd love to use neckbeardchan (is this your reference implementation or something) if it weren't so slow. Not slow as in runtime, but slow as in the fact that nobody uses it.

Get out pychan devs

>>34
Nope, the GPLv3 steals the third party developers' freedom.

>>39
he doesn't know anything about how the GPL works
he just parrots the FUD that BSD proponents spout

>>40
He defines freedom as, "do as you wish". The GPL exists to ensure USER freedom.

>>41
But, GPL is also "do as you wish", is it not?

I would like to interject for a moment. http://en.wikipedia.org/wiki/Clifford_Cocks

>>42
he doesn't know anything about how the GPL works
he just parrots the propaganda that GNU proponents spout

the amount of latent homosexuality in this thread is incredible

If it ain't Lisp, it's crap.

If it ain't Lisp, it's great.

>>42
Not really. Some people would like to share GPL software binaries and maintain proprietary control over the associated source code. The GPL states they are not permitted to do this and as a result, they'd forfeit their licence to share the GPL software.

http://www.gnu.org/philosophy/freedom-or-power.html

>>48
That's good.

Whoever posts next or is the last to post in this thread is a faggot.

Someone write one in UNIX standard tools

Faggots are no longer after me.