Posted
over 2 years
ago
by
nos...@example.com (Greg Beaver)
Posted
over 2 years
ago
by
jeichorn
A common request for PEAR is too use SVN instead of CVS for source code management. As part of the PEAR2 project we are making that happen.
I’m happy to announce that we now have an SVN repo ready for testing. Web access at http://svn.pear.php.net with the SVN url being http://svn.pear.php.net/repo
Were still working [...]
Posted
over 2 years
ago
by
Greg
The PEAR Project has lost a member of its community. Bertrand Gugger (toggg) passed away in the night from June 16th to 17th after suffering a heart attack.
Bertrand was involved in the maintenance of several important PEAR packages, including the Validate package family.
He leaves behind a wife and four children, who have our [...]
Posted
over 2 years
ago
by
till
Posted
over 3 years
ago
by
Helgi Þormar Þorbjörnsson
One thing I've always missed in phpt is code coverage reports, not lcov since I'm talking about testing userland code, kinda like we have in PHPUnit so I decided to implement it in pear run-tests so that I could check out how much code I've made
... [More]
tests for in PEAR and other projects where I utilize the phpt format.
So the first thing I had to figure out was the RunTest code in PEAR, it's a old port of php run-tests and hadn't really been updated to any real extent, mostly just adding features here and there, so what I did was to split it up into multiple functions so that it would be easier to understand the beast, run() was 700+ lines IIRC and in this process I managed to find a good amount of redundant code that we could throw out, yay!
So the next step was to figure out how to make XDebug only provide coverage reports for only the tests and the code they run and not to include the RunTest code in the equation with out me having to filter it out, and then a very ugly solution dawned on me, I'd have to inject the XDebug start / stop / get coverage code into RunTest, OH MY GOD!
But for those that understand how we execute tests this will make a lot of sense, because each test gets it's own php process, we use proc_* for that, and why might one ask and the answer is simple, mainly to test PHP fatal errors and code that uses exit/die as well as being able to define our own ini options that the process will use (enable safe mode, disable magic quote and things like that) ... There might be some other reasons but these are the most important IMHO.
Tho the first two reasons caused me some headache, since of course fetching the coverage info and throwing it into a file won't work if a PHP Fatal error occurs or if a die/exit get processed in the test since it's done at the end of each test, so I had a little chat with Derick to see if we could find some proper solution for that challenge and he said he was going to look into it for XDebug 2.1, yay for Derick
So to sum up a little I take the FILE part, detect the first and inject the start / get coverage / stop XDebug code as well as var_export($xdebug, true); and write that to a file in the same dir as the test with the file ending .xdebug (name can change, just seemed the most straight forward at the time :P) and hurray we have a file that contains a valid PHP array with the coverage info! :D
This isn't a silver bullet, it needs some more work and a renderer package to make those pretty graphs and progress bars, like we have at gcov.php.net or similar but at least it's progressing into the right direction and I'm pretty happy if it becomes useful to only handful of people, if more use it then I'll be thrilled.
So anyone up to helping with the renderer package ? [Less]
Posted
over 3 years
ago
by
Greg
Today, the latest incarnation of the PEAR Installer, version 1.6.0, was released at pear.php.net (http://pear.php.net/PEAR to download, pear upgrade PEAR to upgrade).
This release fixes a number of major regressions introduced in PEAR 1.5.2 that
... [More]
were not fixed in PEAR 1.5.3 or PEAR 1.5.4, and is recommended for immediate upgrade.
New features are mostly minor and include:
minor [...] [Less]
Posted
over 3 years
ago
by
Greg
A few minutes ago, the PEAR Group finished its third meeting, which was the first attended by newly elected PEAR Group member Paul Jones (welcome Paul!). In addition to other things discussed, the one that really interests me, and I suspect all of you, is the future direction of the repository and the PEAR [...]
Posted
over 3 years
ago
by
nos...@example.com (Greg Beaver)
Posted
over 3 years
ago
by
nos...@example.com (Greg Beaver)
Posted
over 3 years
ago
by
david
Finally after having a tie in the initial PEAR Group Election, we have ran a runoff election between the two tied parties Justin Patrin and Paul M. Jones.
After the regular time for an election, the choice has been made by the community on the seventh member of the PEAR Group.
%
Name
#
52.27%
Paul M. [...]
