programming Archives

Staying on top of bitmaps

While putting off working on my Perl Advent Calendar submission, I was instead active in resolving bugs in App::ShaderToy and adding some interesting features. The three major features I added this week are, in order of implementation, loading of bitmap images, hot reloading of code and the feature to make the window stay always on top.

It is incredible how much joy quicker iterations bring me while toying around with shaders, tweaking the parameters to see if I can find new visuals.

Shadertoy progress and the state of OpenGL in Perl

Ultra Liquid Bokeh Shadertoy The shader is a modification of a shader by Inigo Quilez, hacked up by Weyland.

After the initial rush of success, I spent this week working more on the UI side of the app, putting off adding support for geometry generation for later. Prima proves to be a solid UI toolkit and to me it feels closer to using Delphi or Visual Basic, API wise.

Modern OpenGL with Perl

For a long time, I've wanted to actually make use of the modern hardware I have at home. The graphics card is capable of OpenGL and OpenGL now has a fancy little language to actually bring images to life. For example [https://www.shadertoy.com] has great so-called "shaders" that show off what can be done with them.

Because I also want to toy around with programming some shaders, I want to get a live environment running. So during the weekend, I took the Glew library, wrote a small Perl script to convert the header files to XS, and then fought with OpenGL until I had a driver that could run shaders from Shadertoy.com:

shadertoy-01-seascape-still.png

Trying to hide from the Cloud

I'm trying to get Plync to work with my Nexus 7, mainly because I want non-Google calendar synchronization between my mobile, my desktop and this shiny toy. Authentication works, but the Nexus 7 does not want to list the available folders at all and does not attempt to synchronize the Calendar folder.

To further debug this, having a good+free (or at least, available) ActiveSync server that I could use to debug the network traffic against would be very convenient. $work does not use ActiveSync, so it won't be much use there...

How many faces do you count?

How many faces do you count in this image?

image-ccv-face-mass.png="text-align: center; displa…

Work progress on WWW::Mechanize::NodeJs

Lots of people use WWW::Mechanize::Firefox. This makes me happy.

Some of these people would like to do away with needing Firefox to be running on the machine doing the automation. To look in that direction, and to gain some familiarity with nodejs, I started porting the proxy object backend MozRepl::RemoteObject to nodejs. I've uploaded the work in progress to Github as NodeJs::RemoteObject. There is a lot of copied and pasted code between the two ::RemoteObject modules, and likely, this will beget a third, shared incarnation of (Javascript) proxy object implementations.

The main thing that's still needed is to actually write a web "browser" implementing just enough to run most web applications, for nodejs. I think there already is something called "jsdom", which claims to be just enough of a browser to make this work.

Discontinuing support for Firefox 3.0

A heads up and last call for people using WWW::Mechanize::Firefox with Firefox 3.0.

I plan on discontinuing support for Firefox 3.0 due to moving to the native JSON encoder that exists starting with Firefox 3.5.

If you are a Firefox 3.0 user (for compatibility testing?), and really, /really/ need the support, please talk to me so that we can work on a solution that keeps the code small and maintainable for me. If nobody speaks up, I'll interpret that as nobody using Firefox 3.0 anymore, which is fine by me as well.

In other news, I now got several "portable" Firefox instances installed and modified the test files to test against all installed instances. This now tests Firefox versions 3.5, 4.0, 5.0 and 6.0 Beta.

Display your data - Random::PoissonDisc

I read this nice article on map generation and naturally want to write something like it, but in Perl. For the first step, I want to distribute points nicely across the plane, by using the Poisson Disk Sampling method outlined in the article. Implementing the algorithm was straightforward, but how would I know that the output data was correct in the sense of reaching my goal of uniform but randomly distributed points across the plane?

The test program of Random::PoissonDisc conveniently outputs the generated points to STDOUT. For visually inspecting the data, I can then pipe it into App::ffeedflotr which displays a nice point cloud. The first output of Random::PoissonDisc looked like this:

perl -w bin/random-poissondisc.pl -r 10 | ffeedflotr.pl --type=scatter

Image of wrong distribution

Clearly, this picture shows that something was wrong with the first attempt of creating the random data. The grid is 20x20 units, and with a minimum distance of 10 between points, there should be at most 2 points per grid. My error was in the code for sample rejection. The code only checked the immediate cache, and not the neighbouring cache positions. After fixing that part of the code, I'm not certain whether the code is correct. But its output looks quite satisfying:

Better distribution

The module itself will soonish hit CPAN. I see a lot of improvement opportunities for the module. It could support incremental point generation. It could actually use a vector library like PDL instead of hand-rolling most of the vector manipulation code. It could use some tests beyond basic functionality tests.

But for the moment, I'm very happy with the fact that the code produces results I can use in creating random maps. And also I'm very happy with the fact that I have nice visualisation tools that enable me to visually verify the quality of datasets.

You can solve any problem by adding another layer of indirection

During the Easter weekend, I've started to write code supporting Firefox 4 in WWW::Mechanize::Firefox. So far, only some ugly parts of the restructuring of Firefox have broken WWW::Mechanize::Firefox. As my main application for it still runs Firefox 3.x, I have to support both versions, and especially not break any functionality for 3.x. So far, I could put most of the differences between Firefox 3.x and Firefox 4 into two submodules, WWW::Mechanize::Firefox::API35 respectively WWW::Mechanize::Firefox::API40. The constructor of WWW::Mechanize::Firefox does return either of these subclasses, depending on the version. This proves that you can't solve the problem of too many indirections by adding another layer.

As I have no real use case for Firefox 4 yet, I'm not sure whether there are more differences in when (and which) events fire during page load etc.. There is one nice glimmer of improvement for Firefox 4. I've found a Selenium test file that overrides many of the modal dialogs, so that I can now maybe implement ->proxy() for WWW::Mechanize::Firefox and suppress modal dialogs from blocking the whole application.

If you have Firefox 3.x and automate a critical application, don't blindly upgrade Firefox on your main machine. Firefox 4 and Firefox 3 will not peacefully coexist if you don't take preventive measures.

If you want to do a test drive of the upcoming version, take a look at the Firefox4 branch of the Github repository.

I love it when a plan comes together

Barbie blogged about the 11 million test reports mark, and gave a link to a dataset.

I had been sitting on my data "visualization" idea App::ffeedflotr for some time already, and had just started writing and publishing it on github. That dataset pushed me to write a short tutorial / showcase of the application.

The screenshots were produced by WWW::Mechanize::Firefox, the charts produced by the flot library, and the Javascript manipulation also came through MozRepl::RemoteObject. It's nice when your tools conspire to surprise you in a good way!

About Max Maischein

user-pic I'm the Treasurer for the Frankfurt Perlmongers e.V. . I have organized Perl events including 7 German Perl Workshops one YAPC::Europe.