Been repeatedly getting this error in the analytics script. The script is running PHP via the commandline and the error appears (in Windows XP) after the script has finished.
After much tweaking and searching the Internet, I’ve narrowed this down to an internal PHP error rather than anything code-related. I tried increasing the PHP memory limit as the script is quite hefty when running against a large log but this was to no avail.
Interestingly it fires after all the destructors have run and the script has finished. It appears to be some sort of garbage-collection related error. Understanding this, I tried unsetting all my objects and arrays in the destructors but this failed to fix the problem.
Research on the Internet suggests that it is related to doing a foreach on very large arrays. These loops run perfectly well and the script produces all the expected output but on closure you get an error. When I comment-out these foreach loops then no-error!
I had hoped an upgrade to PHP 5.3.6, might fix this but it still errors out at termination. I guessing that most people do not do the sort of large loops I’m running with these script so it isn’t a priority to fix. It’s the sort of error that would probably only happen from the commandline.
Anyway, if anyone else out there is getting these errors on their own code; I’ll save you the effort in trying to fix it:
- It’s a PHP internal error not you!
- It’s unfixable without getting rid of your large foreach loops.
- It fires after the destructors and closure of the script.
The Impact repository has reached it’s 300th commit.
The project is still moving-along nicely with major progress in some of the file/directory handling classes as well as the filtering/reporting classes.
Recent progress has been driven by my employers need for a new Web Analytics system. The flexibility of an analytics suit based upon Impact was too tempting to avoid. Eventually, this will probably form a sub-project but at the moment is being added to the main project.
Spent a lot of time today, updating code documentation and creating Unit Tests Stubs. It is my intention to get some tests written next week for the new classes. Testing has fallen behind and I’m now starting to regret this as classes have become too complicated.
Unit Tests do seem to force you down the route of simple code, rather than bloated and complicated. I’m looking forward to forcing the new classes back down this route.
The iCal parsing code hasn’t made much more progress recently as my social life has been extra busy and I’ve lacked the time outside of work.
It seems a mighty long time since I actually posted something to this development blog. It’s quite a shame, since the project has actually been moving-along nicely. We’re now up to revision 220 in subversion, which suggests a serious amount of coding has been done recently.
I will try to keep this updated in future with major changes when they happen.
The heads-up on where we now are is:
- Most of the CMS work is done and with a few extra tweaks and fixes its ready for live testing.
- No work has been done on the CRM side of things.
- The template module is now working, extremely well. Plugins are now also, working well and have completely replaced the early components concept.
- The Calendar module is almost complete but considerable work still needs do on recursion. RRULES in iCal are what is considering my attention at the moment. Major progress has been made in the last few days.
- There is still a lot of Unit Tests to add, however a significant portion of the project is now covered.
- Coding Standards are reasonably consistent but a little work is still needed.
- I’ve added an Analytics module, which is actually sub-projects. This is being developed during my normal day-job as it will replace one we been using internally for a number of years. When the internal Perl scrips needed replacing, something based on PHP and Impact seemed obvious. At some point this will be hived-off into it’s own sub-project to avoid conflicts of interest.