soledad penadés » Code

A hack to parse RSS feeds with php

sole — Sat, 21 Jan 2012 17:19:37 +0000

Just happened to assemble this ~~script~~ hack recently, out of the requirement for a quick’n'dirty feed parsing feature:

$feed_contents = file_get_contents($feed_url);

$xml = simplexml_load_string($feed_contents, LIBXML_NOCDATA); 

$feed_array = json_decode(json_encode($xml));

print_r($feed_array); // Surprise!!

Now this evidently is not SimplePie or Magpie RSS or whatever feed reader library tickles your fancy*, but assuming the feed will never be malformed, it can save you lots of time! Isn’t that what php was meant for? :-P

At first it surprised me that it would even work–but it seems that the JSON module interoperates very nicely with SimpleXML objects. At the end you get an associative array in $feed_array which is a nice representation of the RSS 2 feed. It’s important to highlight the LIBXML_NOCDATA parameter, as it makes sure the CDATA nodes are read as text. Otherwise you would just get empty feed items, etc.

Obviously for this to work you need both the JSON and SimpleXML modules installed and enabled in your server. Since that’s something that always worries me, I wrote another quick script to test whether the hack would work on the server:

$functions = array('simplexml_load_string', 'json_decode');

foreach($functions as $f) {

  echo $f . ' exists? ' . (function_exists($f) ? 'yes' : 'no') . '
';

}

It should output something like…

simplexml_load_string yes

json_decode yes

Happy hacking! :-P

Aduki shader

sole — Fri, 11 Nov 2011 00:29:21 +0000

Got this toying with Mr.doob’s GLSL Sandbox. See it live.

It’s my first shader ever!! :D

Here’s the code:

#ifdef GL_ES

precision highp float;

#endif



uniform float time;

uniform vec2 resolution;



void main( void ) {



        vec2 position = gl_FragCoord.xy / resolution.xy;



        float color = 0.0;

        float t = time / 8.0;

        

        float r = 0.7 + 0.35 * (sin(position.x + t) + sin(position.x + t * 5.0));

        float g = 1.0 + 0.5 * sin(t);

        float b = 0.7 + 0.35 * (sin(position.y + t * 1.7) + sin(position.y + t*0.5) );







        gl_FragColor = vec4( vec3( r, g, b ), 1.0 );



}

I actually wanted to replicate the crappy plasma effect I did for “Killotrona“, but the original code is an scary, terrible mess:

// [...]

this->colorList[x][y].x=0.7+0.5*(sin(vertexList[x][y].x+t + vertexList[x][y].z)+sin(vertexList[x][y].x+t*5 + vertexList[x][y].z));//+0.5*sin(vertexList[x][y].x+t);

this->colorList[x][y].y=2+sin(t);//1+0.5*(sin(vertexList[x][y].x+t*0.1 + vertexList[x][y].z)+sin(vertexList[x][y].y+t*2 + vertexList[x][y].z));

this->colorList[x][y].z=0.7+0.5*(sin(vertexList[x][y].y+t*1.7 + vertexList[x][y].z)+sin(vertexList[x][y].y+t*0.5 + vertexList[x][y].z)) +this->colorList[x][y].x;



this->colorList[x][y].x=fmod(this->colorList[x][y].x + this->colorList[x][y].y,1.1+cos(t));

this->colorList[x][y].z=fmod(this->colorList[x][y].z + this->colorList[x][y].y,1.1+sin(t));



aux=this->colorList[x][y].y;

this->colorList[x][y].y=this->colorList[x][y].x;

this->colorList[x][y].x=aux;



this->vertexList[x][y].z=10*(sin(t*0.1)+cos(t*0.5));

// [...]

Although it’s a bit hard to follow, that code updates a list of colours on each iteration, and these colours are then used for the next iteration. I have no idea how to do this with shaders… I have the notion that you need a texture of sorts to store that kind of values but I’m not sure.

Also, it’s not shown in the above fragment but the code also scales the entire output cyclically:

float sx=1.5+0.5*(sin(t_elapsed*0.1)+cos(t_elapsed*0.2));

float sy=1.5+0.5*cos(t_elapsed*0.1);

glScalef(sx,sy,1);

I guess this could be emulated by multiplying the values we send to the various sin() functions with the output of another sin which is function of time, so that the scaling is cyclical, but again, I’m quite unsure…

It’s nice to see how clean GLSL code is, though. I might even finally learn it after five years promising to do so! But I have an excuse: having to include glew and all that is just so cumbersome…!

HTML5′s custom attributes minigotcha

sole — Sun, 16 Oct 2011 19:29:27 +0000

I was trying to set a Javascript Object as the value for a custom attribute, but I was just getting “[Object object]” as the value when reading it back. This is actually the toString() version of my object, and was also my ‘fault’ for not reading the specs (or for daring to attempt something risky!), as the custom attributes can only contain strings:

element . dataset
Returns a DOMStringMap object for the element’s data-* attributes.

(# source)

[...] The custom data attributes is transformed to a key for the DOMStringMap entry [...]

(# source)

Or more specifically, only ‘DOMStrings’ are allowed.

Line spacing inconsistencies when pasting to Firefox from gedit

sole — Fri, 19 Aug 2011 17:09:46 +0000

I was adding some productions to escena.org when I noticed something strange about the way the info section of the latest productions was looking. I was slightly distracted by the excitement of watching all those intros and demos that I hadn’t heard before about, so it took me a while to notice what it was exactly that “didn’t quite look right”. It was the spacing!

Or more exactly, the double spacing that I was seeing, instead of just a single line as in the original!

Initially willing (or expecting) to put the blame on me, I examined my back-end code first, but there is nothing dealing with double spacing or “Windows spacing” correction, such as automatically replacing \r\n with \n only.

I then remembered that when I developed this section a year ago I was using Chrome as my main browser, so I wondered if it was a Firefox-only error that had slipped thru back then. Therefore, I repeated my test with Chrome: opened a FILE_ID.DIZ with gedit, copied the text and pasted it to the corresponding textarea. Clicked on save… and the result came out OK! Simple single line-endings were received by PHP, as one would expect.

So it’s a Firefox thing then, I thought. Not so fast, it can still get more bizarre. But before I get to that, let me show you a little piece of test code I wrote to ensure nothing else was interfering in the process:

 



$txt = '';

$pasted_text = '';



if($_SERVER['REQUEST_METHOD'] == 'POST')

{

        $pasted_text = $_POST['text'];

        

        $text = str_replace("\n", '' . "\n", $pasted_text);

        $text = str_replace("\r", '' . "\r", $text);

        

        $txt = 'You pasted this:
' . $text . '

(end of your paste)';

}



?>



        

        

        

                 echo $txt; ?>

                

                <span style="color: #000000; font-weight: bold;"><?php</span> <span style="color: #b1b100;">echo</span> <span style="color: #000088;">$pasted_text</span><span style="color: #339933;">;</span> <span style="color: #000000; font-weight: bold;">?></span>

(you can download it from here, in case you want to test it too)

What the test code does is simply highlight ‘\n’ characters with red, and ‘\r’ characters with green, so I can visually see what has been added. It’s not exactly like a full-grown hex editor, but it’s more practical for testing in the browser.

Then, if I use the following test text (please ignore the fact that some characters are garbled because of the encoding–though if you don’t understand Spanish it should all look fine to you!):

Esta es una peque€a rutina realizada en Turbo Pascal 6.0.

Est  programada por motivo de una mini-competici¢n que hicimos en el area

SUR.DEMOS de SurNet.

Espero que os guste ;-)

When run with Firefox, I get this:

(notice the double spacing: there are double sequences of \n\rs)

And with Chrome it’s fine:

And here comes the fun: when I copy the text from Chrome and paste it in Firefox. What do you think will happen? Will it double the space when I press Submit?

No! This time it works properly! Crazy! Or what? Well, I have made more tests to try to pinpoint what’s happening.

Test one: copy from a txt file that I created on this computer (so it’s all Linux line endings), paste into Firefox: WORKS. Paste into Chrome: WORKS.

Some guy reported (for another product) that copying from Gnome terminal or gedit to Firefox got him strange results, so I tested the Gnome terminal bit too. Works on Firefox and Chrome: no extra line endings.

Test two: I converted the original text file from Code Page 437 (the old MSDOS encoding) to UTF-8, and opened it with gedit, and pasted it into Firefox: DOESN’T WORK! Double line spacing again! I guess a \r is a \r is a \r, no matter what the encoding! (fortunately).

Test three: Opened the file with GVim. Copied everything and pasted into Firefox: WORKS. Single line spacing as expected.

Conclusion?

Before drawing up a conclusion, I’ll summarise the facts:

In all the tests that “fail”, the copy-paste source is gedit, and the content is a file with MS-Dos line endings.
It only fails with Firefox

So this is what I think is happening: gedit is getting confused by the MS-Dos line endings, and “something is wrong” in the data it puts in the clipboard when I press CTRL+C. Then Firefox gets sort of crazy when it gets those “wrong” characters or whatever gedit is storing in the clipboard, and tries to correct it… but ends up adding double the required line spacing.

On the other hand, Chrome seems to be able to “recover” from possibly malformed data, and proceeds in the normal way we expect: not duplicating content.

However I’m not too sure about this theory. I’d like to see the raw clipboard contents (this time, with a proper hex editor), to find out what is in there, but I haven’t been able to find any program which does it. And I’m not sure I want to start digging X-Clipboard protocol RFC’s or whatever it is that they use for their specs in order to find out how to communicate with the daemon which is listening to CTRL+C/CTRL+V key presses.

Do any of you have any pointer? Any idea? (other than telling people to not to use gedit!). A server-side solution is not exactly the best idea, since although I can detect whether the user is using Firefox, I don’t have any way to detect if a text was pasted from gedit! And blindly replacing groups of \r\n\r\n with just \r\n won’t work either: what if the text file indeed contains two carriage returns?

Decisions, decisions!

Update: found a gedit bug which might be related to this issue!

“insufficient permissions for device”

sole — Mon, 18 Jul 2011 14:07:44 +0000

Yes, another of those note-to-self posts, since each time I try to connect a new device to the computer I’ve already forgotten how this is done :-)

Here are the official instructions, with a list of vendor IDs. If your vendor is not on this list, try to find out the vendor id by connecting the device with USB and running:

lsusb

For example, if we got this output:

Bus 001 Device 008: ID 0fce:615d Sony Ericsson Mobile Communications AB

the vendor ID is 0fce, i.e. the four numbers to the left of the semicolon on the left of the Vendor name (gee! this is overcomplicated!)

Then /etc/udev/rules.d/51-android.rules must be edited (by root) and the proper vendor must be added. For example:

SUBSYSTEM=="usb", ATTR{idVendor}=="0fce", MODE="0666", GROUP="plugdev"

Now I still haven’t exactly found which steps are really necessary and in which order, but seems that you might need to do some or all of the following actions so that the device is finally recognised:

unplug the phone, maybe disable and enable USB debugging in it
kill and restart the adb server:
adb kill-server; adb start-server
restart the udev service:
sudo restart udev