Michal Čihař - Archives

Contributing to phpMyAdmin and GSoC 2011

It looks like questions about contributing to phpMyAdmin are more and more frequent with upcoming GSoC. The fact that is still time for organizations to apply and it's not yet decided whether we will be accepted or not does not change anything.

But before asking, please try to look up existing resources. We have lot of information available on wiki, with entry point being contribution page on website. You should find there all basic information how project works.

Should you specifically ask for GSoC, we have an applicant guide, which tells you what to do if you want to apply. After last year experiences, we will be even stricter on previous contributions, because it turned out to be good filter for people who would have problems with contributing during GSoC as well.

In case you don't know where to start, there is list of junior jobs which should not be that complicated and then there is of course GSoC ideas list with things primarily targeted on GSoC.

phpMyAdmin translation status

Another week is over and it's time to spam^W look again at state of translations for phpMyAdmin 3.4. There are no changes to list of complete translations, so we still have 12 translations at 100%:

There are still lot of translations which would need some love:

And I'm really happy to see progress of some exotic languages (at least for me) such as Urdu.

You can help make translation to your language better! If your language is missing just let me know (either in comments or by email).

Fun with MinGW64 and ODBC

The test suite for recently added ODBC support in Gammu was consistently failing on Win64 platform (all others were just fine). It took me some time to figure out why. The reason is SQLLEN type, which is in some sort special, that generated code for it is broken.

All started with pretty much standard retrieving value from ODBC result:

SQLLEN size;
SQLRETURN ret;

/* Figure out string length */
ret = SQLGetData(res->odbc, 1, SQL_C_CHAR, NULL, 0, &size);
if (!SQL_SUCCEEDED(ret)) {
    return NULL;
}

/* Did not we get NULL? */
if (size == SQL_NULL_DATA) {
    return NULL;
}

/* Allocate buffer for string */
out = reallocate(out, size + 1);

The first problem was comparing of size against SQL_NULL_DATA. It simply always failed even if size did contain -1 (what is actually value of SQL_NULL_DATA). Yesterday, I've come out with typecasting magic that worked fine for this case.

However what I've missed is that even reallocate is failing with this parameter. No matter what the size would be, it would return NULL. Typecasting again did help here. Hey, should not be compiler clever enough to typecast this for me? It turns out that in case of MinGW64 it is not. Anybody has suggestion why?

At the end I ended up with pretty ugly duplicating of the variable just to avoid mixing it up in future changes (as would happen with typecasting everywhere).

I'd really like to know why my assumptions are wrong in this case.

Gammu has ODBC support

One of features for Gammu SMSD which was for quite a long time in my head was ODBC support. With unified SQL backend we have right now it should be pretty easy to add support for it so I gave it a try.

It really did not take to long and the ODBC driver is committed to git and will be part of next release. The great benefit of this is that we get native database support on Windows without need to linking against database libraries, which is always painful.

The ODBC driver behaves like any other SQL based driver for SMSD, so if you are familiar with it, the configuration won't surprise you:

[smsd]
service = sql
driver = odbc
host = dsn_of_your_database
user = username
password = password

All important information about the driver should be available in the manual.

Bloating dependencies

It looks like many peoples decided it is right time to bloat my system with stuff I don't use.

The first think I did not like when squeeze went out was libpcsclite1 pulling pcsd and hal into my system. This is being solved on two fronts - porting pcsd to udev (in #612971) and disabling libpcslite1 support in wpasupplicant. Both of them being good ideas.

What actually drove me to writing this post is today's update, where aptitude suddenly wanted to install whole latex and thus using about 760MiB of extra disk space. I know disk space is supposed to be cheap these days, but it's not that cheap with SSD in notebook. The culprit turned out to be doxygen, which up to now happily lived without single bit of latex, but now needs it (though temporarily according to changelog).

I know it is tempting to enable every possible feature in your package, but in same cases it is really not something what most of people would appreciate.

OpenID in phpMyAdmin

Well not really. The simple reason is that it does not make sense without further integration with other services.

However if you want to deploy such solution, you can now base on example script, I've just pushed to our git repository. It is definitely meant only as example, major reason being storing MySQL user names and passwords in clear text in the PHP script.

phpMyAdmin has new theme

Following results of theme survey, I've changed default theme of phpMyAdmin to pmahomme:

pmahomme theme

I'm sure this new attractive look will improve user experience of upcoming 3.4 release. You can expect beta release with new theme soon and then we will hopefully smoothly continue through one (or more) release candidates to final release.

While making this theme default one, we've also offered team membership to Mike Hommé and I'm quite confident this will be valuable addition to the team. Mike, welcome on board!

phpMyAdmin translation status

Another week is over and it's time to look again at state of translations for phpMyAdmin 3.4. Compared to last week, there one three translations at 100%, so we now have 12 translations at 100%:

But there are still lot of translations which would need some love:

You can help make translation to your language better!

phpMyAdmin theme survey results

The phpMyAdmin survey for new theme is over and it's time to publish results. Today I will show only basic summary, I will dig deeper into the data later.

The first question for default theme has quite clear winner:

Default theme results

As the results are quite persuating, this gives no space to discuss.

Next question was about inclusion of additional theme in standard download kit:

Number of themes results

While two themes still have big majority, people are not that convinced about it.

The last question of the survey was which theme should be included as additional in the download kit:

Second theme results

I think this is most interesting result - while in question about default theme Graphite theme was clearly the second one, in this question people have indicated that Original theme should stay in the download kit.

I would like to thank to all 228 people who have participated (the number is low because the survey required email confirmation, but I still think it is better way than thousands of votes which are easily scriptable).

PS: You can see complete results on the survey site.