Oh-kay, for people who aren’t reading the forums, the SVN trunk is now officially unstable.

Trunk is reachable using:

svn co http://flatpress.svn.sourceforge.net/flatpress/flatpress 

The fixes for stable are in a branch:

svn co http://flatpress.svn.sourceforge.net/flatpress/branches/0.804-vivace 

Being “unstable” means that if something is broken… ARGH a BUG HOW IN HELL AM I SUPPOSED TO GET A DEGREE BEFORE DECEMBER??????? ARRRRGH!!! erm, I mean, “…I’ll have to fix it”.

The first part it’s my usual reaction against bugs.

That one or “damn annoying n00b nobody ever complained about that one WTF do you want??”

Soooo, our new fancy indexing system will allow us to have a more reliable (?) storage, and have not to fear anymore PHP’s memory limits. Yes, that was my main concern, not “features”.

BTW, first the good news.

Image does not exist: images/indices-screenie.jpg

omg! OMG! OH-EM-GEE!!11! THAT IS TEH AWESOMEST!11! Post count near the categories!

Image does not exist: images/whosawesome.jpg

Default: disabled. The reason it’s I have to open and load every single index (there is one index for each of your categories), and that’s not cheap (= slow). BTW if you don’t care, open your plugin.categories.php (in SVN of course), set the corresponding option to true and enjoy your truly new awesomeness.

Yes, there is an index for each category.

If you think of the FP’s storage as a DB, then the old index was a subset of the “Posts” table (the files on your disk); this subset - of course - contained the categories as well.

When you asked the system for a search filtered by category, a sequential scan (sloooooowww) took place.

This won’t happen anymore, since each category has its own sub-index (conceptually in DB-speech there is a secondary index for the category attribute).

Now, the “bad news” part.

As I said the focus here was in reliability/performances in the long distance, which doesn’t mean exactly “faster”, but always “acceptably fast” when the number of posts increases… and not failing with a white page of death, because the memory limit exceeds; theoretically we won’t have fear memory limits anymore, since the index is never loaded completely to memory.

…and - I know you’re going to hate me - that’s why some minor features might not be there anymore.

the current winner is…:

Image does not exist: images/nextprev-screenie.jpg

next/prev link in permalinks. So you won’t have anymore the title of the next/prev entry (when in permalink mode: next/prev page should still be there).

The reason it’s I’ve tried to keep the structure of the bplustree as clean as possible (I won’t bother you more on this subject, but believe me :p).

This does not mean that those features will never be back; there is a hack for instance to take that next/prev thingie back (scan through the tree), but it would make then the index thing a little pointless :p

I have a few ideas in mind to take it back, however, maybe not for this upcoming release, that’s all ;)

There is another winner, the admin panel, where, in order to take more advantage of the indices, I’ve killed the author column, since there is no official support for multiuser, yet, anyway.

I hope you’ll anyway like the efforts.

Bye!

I’ve been working on this bplustree library for the whole last month; I have to confess I’ve got scared more than a few times, and I was going to fear I couldn’t make it to the end; finally, looks like it’s almost there. Now I only have a talk with my tutor to ask a few things.

Image does not exist: images/php-programming.jpg

Aside: despite all of my best intentions, although I’ve put all of my efforts to make it hopefully backward compatible, this library has been only tested under PHP5, and I can’t assure it will work with PHP4 as well (if at all).

By the way, let’s go straight to the subject of this post, which is meant as a little compendium about PHP performances and issues about arrays.

In PHP there’s no formal distinction between integer-indexed arrays and associative arrays, which are indexed using a string.

$arr = array();
$arr[0] = 42;

works as fine as

$arr = array();
$arr[’answer-to-life-universe-and-all’] = ’fourty-two’;

The bplustree library I’ve been working on is essentially a port of a python library (bplustree.py by Aaron Watters) I’ve read about on a paper about genome indexing in bio-informatics. As it sounded well tested enough I’ve finally decided to base on that my PHP class.

Python and PHP are of course two fairly different languages.

In PHP we have several functions and ways to deal with arrays; in this post I’ll list some and write a little summary about performance comparisons and “oddities” using what I’ve found on the net, and what I think I’ve found out myself.

Maybe nothing new, but useful as a remind for myself, and maybe for some of you :)

[Read more…]

Image does not exist: images/nowhere-strikes-back.jpg

I’m taking a rest for a while, I’ll be back in the end of August; meanwhile I’ll be working finally on the new indexing system which will hopefully make FP more reliable (and I hope even a little bit faster in the long run) :)

No multi-user for now: sorry guys, the indexing thingie should be very hard already, but don’t worry it is still planned.

So, I hope you’ll take a little rest too.

Oh, user approval in this period will be disabled on the forum, so new users will be able to register and beg^H^H^Hask for help right away.

This also means do not ever ever ever try and contact me by mail, by contact form, comments to this post or by phone (how did you…??) for help, support requests or selling me vacuums or otherwise die in a fire :D (pic related)

For all of this use the forums :p

See you soon.

Sorry guys if I won’t be as quick as usual to answer you on the forum; I’ve been problem with my Internet connection; hope they’ll be sorted out ASAP; don’t worry anyway: meanwhile I’m searching for papers about flat file indexing and such :)

Depending on how many of you are still needing PHP4, I will consider different solutions for the new features (mostly optimized indexing and such).

I’m developing under apache+PHP5 but I always care about being compatible with PHP4.

As you might know, however, support for PHP4 has been dropped in February; so how is the situation of your web hosts? Would you still use FP if I chose a PHP5-only feature for future development?

Let me know. You can discuss on the forum, too.

Bye