Pandora Apps, it's alive!


And the ages old issue that you end on an error page when going to http://apps.openpandora.org and directly click "New Uploads" still ain't fixed. A workaround is first clicking in the top left corner when going to apps.openpandora.org. Though this is really not nice, since a plain apache redirect on apps.openpandora.org itself (when going there) would solve this issue!


The page you end at is: http://apps.openpandora.org/latestapps.shtml


The correct page you *should* end at would be: http://apps.openpandora.org/apps/latestapps.shtml


BTW a comment regarding a 100% wrong entry: http://apps.open-pandora.org/cgi-bin/viewapp.pl?/Emulator/snes9x4d4p.inf


The license is NOT gplv2! It is a "as-is non-commercial" kind of license.


Plus it doesn't update properly. After I go to site I hit pandora logo and get different set in the new uploads list. Also, I then have to hit browsers refresh and get more to show up. Then click on new uploads tab and get the old list again and have to refresh with browser button.


The site needs alot more than just updates it needs fixing and features.


Edit to qualify my last post: Date should be released not when it was uploaded. Confusion occurs over if uploads are simply new to site rather than NEW UPDATES. More info to link link to website even its simply discussion thread where it was released with extra info.
 
Last edited by a moderator:
Appears on my Linux desktop in Firefox 3.6.15, and on my Pandora in Firefox, Chromium, and Midori, and even on my BeagleBoard.


It's a hex sequence 0x0AA0 (which is an invalid unicode encoding, hence the �) followed by 0x0A, which is just a line feed. That's the one in the very top left. It appears even before DOCTYPE element, so almost definitely a server problem I think.


The second one is basically the same. It's 3 line feeds (0x0A) followed by this invalid unicode encoding (0xAA0) and another line feed.


Check your source, delete all the blank lines that appear before "<div id="apptitle">" and see if that helps.

Hmm, but it only seems to appear on that appstore site, not on any other sites here on the server (and basically all our sites run here).


Weird... it must've happened after the upgrade to Debian 6.0, but I have no idea where that could come from.
 
Well, looked for it a bit... seems like viewapp.pl includes leftside.pl in a variable ($doc) and prints it.


That's where it happens... leftside.pl alone is fine, but before and after the inclusion of leftside.pl, it displays that weird character.


Weird. Seems to be related to perl... I wonder what they changed from Debian 5 to Debian 6 here?
 
Seems fixed.



Code:
wget -O /dev/stdout -q 'http://apps.open-pandora.org/' | perl -e 'while(<STDIN>) { print unpack("H*",$_) }'


now shows "200a3c21444f43...", aka "[space][lf]<!DOC..."


Still it's weird for a web page to start with two blanks, especially since IIRC some clients look for the <! on the exact first chars to guess the encoding.


Edit: still there after all, but only appears on the pages for applications, NOT on the main page and menus. May explain why some people see it and some don't.


For example, the same script used on /cgi-bin/viewapp.pl?/Emulator/Hatari131d.inf still gives "0aa00a3c21444f43".
 
Last edited by a moderator:
I think you should tell the person, who updates it, that he should include license information and sourcecodeurls, as in dl.openhandhelds.org before uploading the apps.


Edit: Where is the press, there are the lawyers...
 
Last edited by a moderator:
It's actually not as weird as it might look. Despite the a0 being among 0a's, they have no relation to each other :)


a0 is supposed to be the no-break space.


The problem is that the the header says that the encoding is utf-8 (content="text/html; charset=utf-8"), but "a0" is not a valid utf-8 sequence, since any character over 127 would represented by multiple bytes.


So the solution is to either change it to a 1-byte encoding (charset=iso-8859-1) - which would break any characters outside of latin-1, or coerce perl to output utf-8.
 
Last edited by a moderator:
It shouldn't be outputting 0xA0 as no break space. It should be outputting "&nbsp;" and letting the client handle it.
 
I've grabbed it in a script and cut it off. It's appearing at the start and end of text grabbed via the perl function 'get'.


If it ever fixes itself the site could end up slightly broken. We will have to keep an eye on it.
 
It's still there on the Account page.


A0.png



(Also, there's a lot of places where quotes are missing around attributes, on the other pages - for example <div class=cominputform> should be <div class="cominputform">)
 
Last edited by a moderator:
It's still there on the Account page.


A0.png



(Also, there's a lot of places where quotes are missing around attributes, on the other pages - for example <div class=cominputform> should be <div class="cominputform">)

I don't succumb to that stuff. It's meaningless. It makes absolutely no difference. Only pedants notice ;)
 
I don't succumb to that stuff. It's meaningless. It makes absolutely no difference. Only pedants notice ;)
So long as it doesn't contain any special characters, such as a forward slash, you are correct. The standard doesn't require there be quotes around everything, just some things with the potential for ambiguous parsing.


People blatantly ignoring the standard is why Microsoft had to write so many hacks into IE, which ultimately lead to so many very-wrong websites not working in browsers that tried to do things right.


Seriously, 3 errors away from being 100% compliant, and all 3 are the result of not wrapping a single anchor href in quotes. Two characters, that's all, is keeping your site from getting a 100% rating.
 
What's the sort order? It kinda looks like most recent first. If that's just an illusion, perhaps it should be an option.
 
What's the sort order? It kinda looks like most recent first. If that's just an illusion, perhaps it should be an option.

You can change it to whatever you like.

I don't succumb to that stuff. It's meaningless. It makes absolutely no difference. Only pedants notice ;)
So long as it doesn't contain any special characters, such as a forward slash, you are correct. The standard doesn't require there be quotes around everything, just some things with the potential for ambiguous parsing.


People blatantly ignoring the standard is why Microsoft had to write so many hacks into IE, which ultimately lead to so many very-wrong websites not working in browsers that tried to do things right.


Seriously, 3 errors away from being 100% compliant, and all 3 are the result of not wrapping a single anchor href in quotes. Two characters, that's all, is keeping your site from getting a 100% rating.

Hehehe.


"""""""""!
 
Back
Top