PHP Wiki - gsoc:2009

api

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/07/31 10:10		current
Line 222:		Line 222:
	* Example usage of the dependency interface : [[http://www.xvpj.net/2009/06/26/how-to-use-php-extension-api-dependancy-interface/]]		* Example usage of the dependency interface : [[http://www.xvpj.net/2009/06/26/how-to-use-php-extension-api-dependancy-interface/]]
	* How dependency interface is implemented on mbstring / exif : [[http://www.xvpj.net/2009/07/29/eapi2/]]		* How dependency interface is implemented on mbstring / exif : [[http://www.xvpj.net/2009/07/29/eapi2/]]
		+
		+	== 16th August ==
		+	* Received some suggestions from the community (mailing list)
		+	* Fixed a problem with win32 build - included zend_eapi.c in config.w32
		+	* TSRMLS parameters are passed to callbacks to improve performance
		+	* Added support for extensions loaded through dl()
		+	* When a extension (say ext_dl) is loaded through dl() the callbacks of other extensions (already loaded) are called, if they require the ext_dl and the versions match
		+	* Callbacks of ext_dl are called if the required extensions are available
		+	* Did some testing with dl()

benchmarks

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/05/21 01:10		current
Line 14:		Line 14:
	Late may and early June: Research and start coding on the CLI-version of the benchmark suite. This involves porting necessarily benchmarks and place them in the benchmark suite.		Late may and early June: Research and start coding on the CLI-version of the benchmark suite. This involves porting necessarily benchmarks and place them in the benchmark suite.

-	Mid june - late june: The CLI version of the benchmark suite should have a clear shape.	+	Mid June: The CLI version of the benchmark suite should have a clear shape.

-	Early July (Mid term): The CLI-application should be totally complete and work should be focused on the web applications such as phpBB, worpress, joomla and/or SugarCRM.	+	Mid June - Early July: The CLI-application should be totally complete and work should be focused on the web applications such as phpBB, worpress, joomla and/or SugarCRM. Depending on the CLI-application, this date might be moved more towards June.

-	Early august: Applications should start to pile up. Hopefully there should be plenty of them here, but it will depend on the difficulty to modify them and the size of them.	+	Early July: Work on the web application should start.

-	August 10th - August 17th: Documentation and bug checking.	+	Early August: The first web application should be finished or almost done.
		+
		+	August 10th - August 17th: Buffert week for problems, documentation, bug checking etc.

bugtracker

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/06/01 16:02		current
Line 20:		Line 20:
	* May 20 : Decided to use pear/Bugtracker and phpweb/bugs as a base		* May 20 : Decided to use pear/Bugtracker and phpweb/bugs as a base
	* May 28 : Began coding part of GSoC. Starting with removing deprecated libraries from bugtracker, and merging in code from phpweb/bugs		* May 28 : Began coding part of GSoC. Starting with removing deprecated libraries from bugtracker, and merging in code from phpweb/bugs
-	* May 30 : Decided to replace DB, DB_Object and Tree with mysqli	+	* May 30 : Decided to replace DB with MDB2
		+	* Jun 26 : Finished migration from DB to MDB2, remove Savant and Damblan
		+	* Jul 1 : Decided to implement and SVN integration
		+	* Jul 15 : Implemented RSS 2.0
		+	* Jul 20 : Implemented SVN Client and we're discussing how to integrate with bugtracker

	===== Notes =====		===== Notes =====
	* Initial code is [[http://cvs.php.net/viewvc.cgi/pear/Bugtracker/\|pear/Bugtracker]] which is a fork of [[http://cvs.php.net/viewvc.cgi/pearweb/public_html/bugs/\|pearweb/bugs]] from a couple years ago with modifications made by Jani to unify and convert the current bugs database		* Initial code is [[http://cvs.php.net/viewvc.cgi/pear/Bugtracker/\|pear/Bugtracker]] which is a fork of [[http://cvs.php.net/viewvc.cgi/pearweb/public_html/bugs/\|pearweb/bugs]] from a couple years ago with modifications made by Jani to unify and convert the current bugs database

ideas

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 155:		Line 155:


-	===== New Mirror Management System =====
-	// Possible Mentor: [[danbrown@php.net\|Daniel P. Brown]] //
-
-	Our existing management system for the network of official mirrors worldwide has a few issues and areas for improvement. The present system is accessible via a browser-based web interface (using a php.net CVS account, and hosted on master.php.net), and provides the following services:
-
-	* Addition, deletion, and modification of DNS for official mirrors of the php.net site as a whole
-	* Automated checking of all mirrors, marking mirrors as "disabled" when issues are detected
-	* Listing of all mirrors presently configured with the system (active and otherwise)
-	* Manual disabling of mirrors
-	* Generic status display of the "health" of the mirror ("OK" or flagged)
-	* Ability to edit the mirror's display information within our list on php.net
-	* Automated mailing to the mirror's maintainer when an issue is detected
-	* Automated mailing of the status of all mirrors on a weekly basis
-
-	Over time, some of the php.net mirror admins have discussed the need and/or desire to add new - or improve existing - functionality in this system. This includes, but is not limited to:
-
-	* Improved mirror status checking
-	* The ability to keep logs of notes regarding the mirror over time, displaying the most recent on the summary page
-	* Simple graphing and statistics for uptime and PING response time
-	* A geo-IP lookup to ensure that the mirror IP address matches the physical region it serves
-	* An online "waiting list" application form (many potential donors currently contact the mailing list or Dan Brown directly)
-	* An online form to collect data from mirror maintainer applicants
-	* A form-to-mail interface to email individual maintainers, the mailing list, or all maintainers directly (for announcements)
-	* Number of interested donors on the "waiting list" under each country's heading
-	* Automated quarterly reminders to folks on the "waiting list" to update their status if they are no longer willing/able (?)
-	* System specifications on each individual mirror (?)
-	* A scoring system based on the system specs of the mirrors (?)
-	* Load-balancing based upon the score of the mirror when redirecting to a local mirror in the region (?)
-	* Automated daily reminder emails to mirror maintainer when mirror is out-of-sync > 24 hours (still auto-disabled) (?)
-	* .... etc.

	===== Close and evaluate PHP Bugs =====		===== Close and evaluate PHP Bugs =====

introduction

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/05/28 16:01		current
Line 12:		Line 12:
	===== Status Updates =====		===== Status Updates =====
	At a minimum status updates should be sent every 2 weeks, these should be sent to the appropriate mailing list and cc'd to [[gsoc@lists.php.net]], your mentor may ask for more regular updates.		At a minimum status updates should be sent every 2 weeks, these should be sent to the appropriate mailing list and cc'd to [[gsoc@lists.php.net]], your mentor may ask for more regular updates.
		+
		+
		+	You can find a template for your report [[gsoc/2009/report_template\|here]]

	===== Exams / Holidays =====		===== Exams / Holidays =====

phdoe

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2011/04/06 10:59		current
Line 9:		Line 9:
	* Mailing list: phpdoc@lists.php.net		* Mailing list: phpdoc@lists.php.net
	* Blog: [[http://mrkschan.blogspot.com/search/label/gsoc]]		* Blog: [[http://mrkschan.blogspot.com/search/label/gsoc]]
		+	* Live at: [[https://edit.php.net]]
	===== Abstract =====		===== Abstract =====
	Currently, the documentation work is synchronized by cvs. But still, there are potential conflicts due to redundant work. Besides, it's not that easy to share the works or even pipelining the works in a distributed environment. Therefore, a centralized environment is introduced.		Currently, the documentation work is synchronized by cvs. But still, there are potential conflicts due to redundant work. Besides, it's not that easy to share the works or even pipelining the works in a distributed environment. Therefore, a centralized environment is introduced.

phdplugins

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/05/30 18:38		current
Line 40:		Line 40:
	* Implement PI (Processing Instructions) support		* Implement PI (Processing Instructions) support
	* Write tests		* Write tests
		+
		+	(We decided not to render the books Docbook: The Definitive Guide and Producing Open Source Software to focus in port the old Themes to new Packages)

	Sprint 6 - (26 July to 08 August)		Sprint 6 - (26 July to 08 August)
-	* Implement the rendering of DocBook: The Definitive Guide	+	* Port the Pear Themes to Packages
-	* Implement a xhtml format	+
-	* Implement a bigxhtml format	+

	Sprint 7 - (09 August to 22 August)		Sprint 7 - (09 August to 22 August)
-	* Implement the rendering of Producing Open Source Software	+	* Port the PHP Themes to Packages
-	* Implement a xhtml format	+
-	* Implement a bigxhtml format	+

	Sprint 8 - (16 August to 24 August)		Sprint 8 - (16 August to 24 August)
	* Final Evaluations		* Final Evaluations

report_template

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2026/04/22 14:33	current
Line 1:	Line 1:
	+	====== Two Weekly report template ======

	+
	+	Subject: XXX's Report for the two weeks starting: 2009-MM-DD
	+
	+
	+	TIME SPENT: XX hours (approx)
	+
	+
	+	HIGHLIGHTS
	+	< things that you were really pleased with >
	+
	+	KEY CONCERNS
	+	< anything that is outside of your control and which
	+	concern you >
	+
	+	WAITING FOR...
	+	< if you are waiting for someone else in order to complete
	+	one or more tasks >
	+
	+	KEY TASKS THAT STALLED
	+	< if something stalled that is not outside your control
	+	in and by itself, even if it was outside factors that
	+	delayed it >
	+
	+	KEY ACCOMPLISHMENTS
	+	< list as many things as you wish, but prioritize
	+	by putting the most important items first >
	+
	+
	+	DETAILED ACTIVITIES
	+	< This section is optional -- list here all minor tasks that
	+	did not fit into any of the categories above. >
	+
	+	MY TODO
	+	< The major tasks you will be doing in the next couple
	+	of weeks >

runtests

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/04/28 17:05		current
Line 7:		Line 7:
	* Timezone: GMT +2 (Georg, Stefan), GMT +1 (Zoe)		* Timezone: GMT +2 (Georg, Stefan), GMT +1 (Zoe)
	* Mailing list: php-qa@lists.php.net – IRC: #php.pecl on EFnet		* Mailing list: php-qa@lists.php.net – IRC: #php.pecl on EFnet
		+	* Repository access : cvs -d :pserver:cvsread@cvs.php.net:/repository checkout phpruntests

xdebug

Anonymous (anonymous@undisclosed.example.com) — 2025-04-03T13:08:43+00:00

2009/07/05 20:49		current
Line 11:		Line 11:
	Extend the code coverage instrumentation in Xdebug from statement coverage to include decision and path coverage. Xdebug will be able to report for a given block of code the number of unique branches, how many branches were executed during execution of the block, how many linearly independent paths exist through the code block, and which of these code paths were executed. A data structure representing which paths and branches were taken will be available to code coverage tools .		Extend the code coverage instrumentation in Xdebug from statement coverage to include decision and path coverage. Xdebug will be able to report for a given block of code the number of unique branches, how many branches were executed during execution of the block, how many linearly independent paths exist through the code block, and which of these code paths were executed. A data structure representing which paths and branches were taken will be available to code coverage tools .

-	==== Initial Timeline ====	+	==== Timeline ====
	May 23rd - June 13th: Study closely PHP runtime, opcodes and extending PHP		May 23rd - June 13th: Study closely PHP runtime, opcodes and extending PHP

-	June 13th - June 27th: Implement branch coverage statistics (counting branches executed / total branches)	+	June 13th - July 12th: Implement branch coverage statistics (counting branches executed / total branches)

-	June 27th - July 18th: Implement path coverage statistics (counting paths executed / total paths)	+	June 13th - July 19th: Implement branch coverage data structure

-	July 18th - August 1st Implement branch coverage data structure	+	July 20th - August 8th Implement path coverage statistics (counting paths executed / total paths)

-	August 1st - 24th Implement path coverage data structure	+	August 9th - 24th Implement path coverage data structure

-	This will be refined as I go deeper into the project

	==== Resources ====		==== Resources ====