Yvan Rodrigues' problogue

(like a blog, but with less effort)

Disconnected ramblings about software development, iOS, FreeBSD, anti-social networking, kittens, drosophilidae, small business, Android, web services, finches, Windows, electrical engineering, XML, rental cars, rye, or ... FIVE dollars??!... something something beer.

Matter.js: A Physics Engine in Javascript

How to install PECL uploadprogress on FreeBSD

You need this PECL extension to be installed if you would like to see an upload progress indicator in Drupal. Installation is easy, but not obvious.

cd /tmp
# Substitute the latest version from http://pecl.php.net/package/uploadprogress
fetch http://pecl.php.net/get/uploadprogress-1.0.3.1.tgz
tar xf uploadprogress-1.0.3.1.tgz
cd uploadprogress-1.0.3.1
phpize
./configure
make build install
echo "extension=uploadprogress.so" >> /usr/local/etc/php/extensions.ini
cd /tmp
rm -R uploadprogress-1.0.3.1

Igor

This is my cat and best friend Igor who died of cancer.

5 Alternatives to Google Analytics

Tags: 

Float Labels with CSS

Click on the image to see an animated demonstration.

Read how at: http://css-tricks.com/float-labels-css/

Tags: 

iOS filenames cannot contain more than one period.

It took me a while to figure out why my app couldn't file the file day-icon.20.png. When it renamed it to day-icon.png it worked fine.

System.InvalidOperationException: The operation cannot be completed because a build is already in progress.

Building using Xamarin.iOS and Visual Studio 2012 stopped working for me when my debugging target is a physical device. Clicking Start resulted in the message:

System.InvalidOperationException: The operation cannot be completed because a build is already in progress.

It worked fine at invoking the simulator.

This appears to be a bug, but there is a workaround: Go to the solution's Configuration Manager and uncheck Deploy.

This issue and workaround are present in Xamarin.iOS 1.8.365.

iOS AutoLayout is broken for non-trivial layouts.

A custom control, like the calendar component shown here, requires many subviews. In fact, to generate this view requires about 700 subviews, unless manually user-drawn.

Apple's AutoLayout was introduced in iOS6 to provide a means to layout user interfaces independently of screen size, aspect-ration, and resolution. Unfortunately it is very ineffecient and appears to have an order of O(c^n) i.e. every subview added makes the layout take exponentially longer.

The control that is shown, designed to use AutoLayout, takes up to 10 seconds to render on an iPad. This essentially makes it unusable.

In examining the execution using Instruments I came to the realization that it was all Apple code that was swallowing all this time. Eventually I found two others who came to the same conclusion the hard way:

By turning off AutoLayout, the calendar renders (incorrectly of course) in a fraction of a second. I'll be spending this weekend writing my own MagicLayout code, which will be used by the cross-platform component library that is in development.

Pages

Simple Copyright Policy: If you want to reproduce anything on this site, get my permission first.