Summer of Code

Lukas Smith

20 years ago

Rasmus Lerdorf wrote:

> Google is doing their Summer of Code thing again this year.  You can
> read more about it here: http://code.google.com/summerofcode.html

A few days ago I started a wiki for PEAR to get organized for this. But
not much content has been generated so far. Only some ideas have been
kicked around (latest: adding an optional PHP4<->PHP5 E_STRICT converter
to the PEAR installer ;) ).

Anyways .. obviously we are missing a foundation, but maybe we can
squeeze in somehow. Should we coordinate this, or should each subproject
of php.net try to get in on its own?

regards,
Lukas

Steph

20 years ago

Is it a really stupid idea to suggest a script upgrading program a la
'autoupdate' (for 4/5 -> 6)?

It's something I hoped to tackle myself, but am unlikely to find the time
for.

- Steph

Lukas Smith

20 years ago

Steph Fox wrote:

> Is it a really stupid idea to suggest a script upgrading program a la
> 'autoupdate' (for 4/5 -> 6)?
>
> It's something I hoped to tackle myself, but am unlikely to find the
> time for.

Well if it works it could solve some issues. Like handling stupid BC
breaks (array_merge, class_exists), exploit new features (parsing phpdoc
to set PPP) and generally make the code a happy E_STRICT camper.

The potential for breakage is huge though (take the PPP example ..) and
also for code library it would mean that users will report all sorts of
suprising bugs (unless you test the code in all its variations).

So maybe as a one time migration tool it could make a nice addition to
PHP_Compat (implements new functions/constants etc in userland) and
PHP_CompatInfo (determines the minimal php version).

regards,
Lukas

Steph

20 years ago

I wasn't thinking of writing something in PHP... there'd be no way for
userland code to 'see' half the stuff that needed changing.

Anyway, just a thought.

Lukas Smith

20 years ago

Steph Fox wrote:

> I wasn't thinking of writing something in PHP... there'd be no way for
> userland code to 'see' half the stuff that needed changing.

I was not implying it would have to. But I also do not see why it should
not be possible to do it in PHP.

regards,
Lukas

Steph

20 years ago

> Steph Fox wrote:
>> I wasn't thinking of writing something in PHP... there'd be no way for
>> userland code to 'see' half the stuff that needed changing.
>
> I was not implying it would have to. But I also do not see why it should
> not be possible to do it in PHP.

If you wrote something like this in PHP you'd necessarily be searching for
patterns in the code. In C you'd be working with tokens directly - coding
style wouldn't be an issue.

- Steph

Lukas Smith

20 years ago

Steph Fox wrote:

>> Steph Fox wrote:
>>> I wasn't thinking of writing something in PHP... there'd be no way
>>> for userland code to 'see' half the stuff that needed changing.
>>
>> I was not implying it would have to. But I also do not see why it
>> should not be possible to do it in PHP.
>
> If you wrote something like this in PHP you'd necessarily be searching
> for patterns in the code. In C you'd be working with tokens directly -
> coding style wouldn't be an issue.

Isnt that what we have ext/tokenizer for?

regards,
Lukas

Steph

20 years ago

>> If you wrote something like this in PHP you'd necessarily be searching
>> for patterns in the code. In C you'd be working with tokens directly -
>> coding style wouldn't be an issue.
>
> Isnt that what we have ext/tokenizer for?
>

Wouldn't that be relatively slow?

Also there's the psychological difference between being presented with a
binary and being presented with a script (but then again I suppose you could
argue that there's nothing to prevent the embed SAPI coming into play)...

- Steph

Mark Evans

20 years ago

Something I always thought would be cool to do and havent seen anywhere (or
even know if its possible) is script or extension which can scan a php 4 app
and point out area's where the code isnt compatible with php 5.. similar to
the analyzer in zend studio I guess. This would help people audit existing
applications and encourage them to become compatible with php 5.

This is turn (I hope) would then encourage hosting companies to start
deploying php 5 and get out of the circle of them not updating to php 5 as
apps arent compatible.. and apps not becoming compatible with php 5 as the
hosting companies dont support it :-)

Is this a crazy idea? Or is it even possible? I guess its not possible to
garuantee 100% compatability but even 90 - 95% would be a start.

Regards

Mark

Rasmus Lerdorf

20 years ago

Lukas Smith wrote:

> Rasmus Lerdorf wrote:
>> Google is doing their Summer of Code thing again this year.  You can
>> read more about it here: http://code.google.com/summerofcode.html
>
> A few days ago I started a wiki for PEAR to get organized for this. But
> not much content has been generated so far. Only some ideas have been
> kicked around (latest: adding an optional PHP4<->PHP5 E_STRICT converter
> to the PEAR installer ;) ).
>
> Anyways .. obviously we are missing a foundation, but maybe we can
> squeeze in somehow. Should we coordinate this, or should each subproject
> of php.net try to get in on its own?

I think we can lump them all together under PHP.  And while having
suggestions is definitely good, we also need to stay open to interesting
proposals.

-Rasmus

Lukas Smith

20 years ago

Rasmus Lerdorf wrote:

> I think we can lump them all together under PHP.  And while having
> suggestions is definitely good, we also need to stay open to interesting
> proposals.

Ok, how do we get on that list?
Do we have friends inside google?

I poked some more and the stuff I first found seemed to indicate a
foundation as a requirement:
http://code.google.com/summfaq.html#what_is_a_mentoring_organ

But poking some more I found this not to be the case:
http://code.google.com/soc/mentorfaq.html#5

I guess we need to cover the following steps:
http://code.google.com/soc/mentorfaq.html#3

Quoted here for lazy people:
3. How does the program work?

1. Organizations who would like to participate in Summer of Code
2006 should choose an organization administrator(s) to represent them
2. Organization administrators submit their organization's interest
by emailing soc2006support@google.com
3. Google notifies of acceptance and creates the organization's
account on the Summer of Code site
4. Organizations sign up mentors and publish their pool of project ideas
5. Students submit to Google proposals to work with particular
mentoring organizations; Google routes to the mentor organization, and
the proposals are ranked by mentors working with those organizations.
6. Accepted students start work based on their proposals; mentors
give guidance throughout the duration of the program
7. Mentors provide mid-term evaluations of student progress
8. Mentors provide a final review of student work, and each student
provides a single overall review of her/his mentor
9. Student uploads completed program to Google site

regards,
Lukas

Lukas Smith

20 years ago

Lukas Smith wrote:

> A few days ago I started a wiki for PEAR to get organized for this. But

BTW .. here is the URL
http://oss.backendmedia.com/PEARSummerCode/

The wiki can be used for other php.net projects of course as well.
Maybe just open a new page if needed.

regards,
Lukas

Kevin Waterson

20 years ago

This one time, at band camp, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> Google is doing their Summer of Code thing again this year.  You can
> read more about it here: http://code.google.com/summerofcode.html

ahh, just the spring board for the srm updates needed to give php
persistent objects

Kevin

--
"Democracy is two wolves and a lamb voting on what to have for lunch.
Liberty is a well-armed lamb contesting the vote."

Nuno Lopes

20 years ago

> Google is doing their Summer of Code thing again this year.  You can read
> more about it here: http://code.google.com/summerofcode.html
>
> It doesn't actually mention PHP there yet, but it will soon.  So if you
> are a student and have an interesting idea for a PHP-related project,
> start thinking about your proposal.
>
> For eligibility see:
>
>   http://code.google.com/summfaq.html#who_is_eligible
>
> and the rest of the FAQ as well I guess.
>
> -Rasmus

Ah great! :)

This year I might participate. I would like to do something in the core or
even in the zend engine. I'll think in something.. (I'm also open to
suggestions, of course).

I would also like to propose a project related with the documentation team,
which is very useful to us:
* working on livedocs (rewriting the indexer, improving docbook compat,
pear/gtk/smarty docs support, php 6 support, etc..)


Nuno

Gabor Hojtsy

20 years ago

Nuno Lopes wrote:

>> Google is doing their Summer of Code thing again this year.  You can
>> read more about it here: http://code.google.com/summerofcode.html
>
> This year I might participate. I would like to do something in the core
> or even in the zend engine. I'll think in something.. (I'm also open to
> suggestions, of course).
>
> I would also like to propose a project related with the documentation
> team, which is very useful to us:
> * working on livedocs (rewriting the indexer, improving docbook compat,
> pear/gtk/smarty docs support, php 6 support, etc..)

+1 for someone cleaning up livedocs to a ready-to-deploy state :)

Goba

Lukas Smith

20 years ago

Gabor Hojtsy wrote:

> Nuno Lopes wrote:
>>> Google is doing their Summer of Code thing again this year.  You can
>>> read more about it here: http://code.google.com/summerofcode.html
>> This year I might participate. I would like to do something in the core
>> or even in the zend engine. I'll think in something.. (I'm also open to
>> suggestions, of course).
>>
>> I would also like to propose a project related with the documentation
>> team, which is very useful to us:
>> * working on livedocs (rewriting the indexer, improving docbook compat,
>> pear/gtk/smarty docs support, php 6 support, etc..)
>
> +1 for someone cleaning up livedocs to a ready-to-deploy state :)

And maybe bring in lost children like peardoc back into things.

Somewhat related: I am not sure if we really have the OO documentation
solved optimally yet either.

regards,
Lukas

Jared Williams

20 years ago

> -----Original Message-----
> From: Gabor Hojtsy [mailto:gabor@hojtsy.hu]
> Sent: 15 April 2006 13:24
> To: Nuno Lopes
> Cc: Rasmus Lerdorf; internals; PHPdoc
> Subject: Re: [PHP-DOC] Re: [PHP-DEV] Summer of Code
>
> Nuno Lopes wrote:
> >> Google is doing their Summer of Code thing again this
> year.  You can
> >> read more about it here: http://code.google.com/summerofcode.html
> >
> > This year I might participate. I would like to do something in the
> > core or even in the zend engine. I'll think in something..
> (I'm also
> > open to suggestions, of course).
> >
> > I would also like to propose a project related with the
> documentation
> > team, which is very useful to us:
> > * working on livedocs (rewriting the indexer, improving docbook
> > compat, pear/gtk/smarty docs support, php 6 support, etc..)
>
> +1 for someone cleaning up livedocs to a ready-to-deploy state :)

How about moving away from using system entities to construct the manual and using Xinclude instead? (See the mysql ref manual
docbook sources) This would make the base pages independent from each other, and loadable into a DOMDocument, which could be
transformed with xslt.

Jared

Jochem Maas

20 years ago

Jared Williams wrote:

>
>
>
>>-----Original Message-----

...

>
> How about moving away from using system entities to construct the manual and using Xinclude instead? (See the mysql ref manual
> docbook sources) This would make the base pages independent from each other, and loadable into a DOMDocument, which could be
> transformed with xslt.

for what it's worth: my end-user experience of (and that of pretty much everyone in php-land I work with/ speak to)
is that the mysql docs are a dog to work with and the the php docs are in comparison a delight.

the interface/layout of the php docs are brilliant (regardless of whether things like OO related fucntionality
cannot be optimally tackled from a doc maintainers point of view.), a testament to the people who create and
maintain it... by all accounts phpers are better catered for than most other communities.

of course the content of the docs itself is, in general, imho, fantastic also. :-)

so don't go changing a winning formula, from the end user's point of view, lightly - what you have now
is a very big factor in the fact the php has grown so large. :-)

rgds,
Jochem.

Jared Williams

20 years ago

> > How about moving away from using system entities to construct the
> > manual and using Xinclude instead? (See the mysql ref
> manual docbook
> > sources) This would make the base pages independent from
> each other, and loadable into a DOMDocument, which could be
> transformed with xslt.
>
> for what it's worth: my end-user experience of (and that of
> pretty much everyone in php-land I work with/ speak to) is
> that the mysql docs are a dog to work with and the the php
> docs are in comparison a delight.

I'm not sure what you mean by end-user experience. Xinclude is just another mechanism for including a file in xml.

Livedocs currently has todo a fair bit of work dealing with entities. Making each of the .xml files standalone would simplify it a
lot.

I did attempt to write a custom user stream that injected entity definitions into an xml file, so you could load a raw page of the
manual directly into a DOMDocument and apply a xsl transform. Didn't have enough time/patience to get it working tho :)

Jared

André Luis Ferreira da Silva Bacci

20 years ago

Jared Williams escreveu:

>>>How about moving away from using system entities to construct the
>>>manual and using Xinclude instead? (See the mysql ref
>>manual docbook
>>>sources) This would make the base pages independent from
>>
>>each other, and loadable into a DOMDocument, which could be
>>transformed with xslt.
>>
>>for what it's worth: my end-user experience of (and that of
>>pretty much everyone in php-land I work with/ speak to) is
>>that the mysql docs are a dog to work with and the the php
>>docs are in comparison a delight.
>
> I'm not sure what you mean by end-user experience. Xinclude is just another mechanism for including a file in xml.
>
> Livedocs currently has todo a fair bit of work dealing with entities. Making each of the .xml files standalone would simplify it a
> lot.
>
> I did attempt to write a custom user stream that injected entity definitions into an xml file, so you could load a raw page of the
> manual directly into a DOMDocument and apply a xsl transform. Didn't have enough time/patience to get it working tho :)

I litle hack.

It removes comments in XML, but resolves all XML entities without
modifications to make all xml files "standalone"

andre@macrossv:~/projects/cvs.php.net/phpdoc/scripts$ time php5
prepare_livedocs.php
Chunk: dotnet.intro
Only a example file
real    0m46.695s
user    0m8.890s
sys     0m2.879s
andre@macrossv:~/projects/cvs.php.net/phpdoc/scripts$ ls ../livedocsxml/
dotnet.intro.xml
andre@macrossv:~/projects/cvs.php.net/phpdoc/scripts$

[]s

André AE

anatoly techtonik

20 years ago

||*()*|| Hi, Nuno.

>> Google is doing their Summer of Code thing again this year.  You can read
>> more about it here: http://code.google.com/summerofcode.html
>>
>> It doesn't actually mention PHP there yet, but it will soon.  So if you
>> are a student and have an interesting idea for a PHP-related project,
>> start thinking about your proposal.
>>
>> For eligibility see:
>>
>>   http://code.google.com/summfaq.html#who_is_eligible
>>
>> and the rest of the FAQ as well I guess.
>>
>> -Rasmus

NL> Ah great! :)

NL> This year I might participate. I would like to do something in the core or
NL> even in the zend engine. I'll think in something.. (I'm also open to
NL> suggestions, of course).

NL> I would also like to propose a project related with the documentation team,
NL> which is very useful to us:
NL>  * working on livedocs (rewriting the indexer, improving docbook compat,
NL> pear/gtk/smarty docs support, php 6 support, etc..)


Too bad your letter was lost in my usual phpdoc traffic. I wish we
could discuss this this a little bit earlier and review RFC/ with howto/
to analyse the progress so far and plan the future steps for PHPDOC.
This can help to guide sporadic PHPDOC tools development to make it more
popular and clear among those potential ones from millions of PHP addicts,
who is able and willing to help given that bottlenecks and stone blocks are
removed from the steep enough learning curve.


What I would like to see is:
1. Visibility of PHPDOC software architecture and process

I guess for phpdoc/ howto is a good draft, but lacks some
pictures.   There can be additional chapter about how the
docs are born and uploaded and who is involved in the
process. Clear entrypoint to PHPDOC tools world is also
must have, because amount of information can be frustating.

2. Issue tracker

PHP bugtracker is good, well-tested, but not suitable for
maintaining issues. Issue (in my vision) can not be "bogus".
Issue is a step in more general plan and it need to be
resolved for the plan to be succeeded. Plan is an idea.
Ideas can be possible or impossible. Possible ideas depend
on resources. Impossible ideas are just that - impossible,
but still contain explanation why (stoneblock, like on
graveyards). Possible ideas, which depend on external factors
can be frozen to wait for these factors (blockers) to resolve.
Ideas can be frozen also if resources are scarce or just
unavailable. To freeze an idea some current status must be
written. Usually this means that somebody else can pick up
the idea, resolve blocker issue and he will have every
available information to fix it. Ideas are not proposals
- idea is a more mild variant of requirement and issue within
idea is a detailed specification of what should be done for
this idea to be archieved. Idea status can be refactored -
you can always write a different status to outline steps
in development, keep duscussion focused. Discussions can be
filtered accordingly, but you can always dig down levels
to initial discussions. Input for "notes" or additions to
issues can be everything - from emails to SVN/CVS commits,
quotes and links, but with periodical link/consistency checks
and perhaps even local copies of necessary information (cache).
This can be used for gathering requirements and elaboration.
Everything can be RSS'ed.

2. CVS to SVN, SVN as a Livedocs backend

I can be a little bit misleaded, but it seems to me that
SVN can be accessed from web application and we can use
this ability. First idea is online patch generation, where
user can edit the page (like in wiki), but instead of
page text he is presented with XML source and preview
is basically the a patch, which is after automatically
assigned to an issue. Patch can be approved and directly
applied to SVN.

3. Livedocs AJAX

I do not know the status of livedocs and the abilities
of this system to provide describe, validate and modify
docbook structure. But if this functionality is suitable, we
can try to move it into AJAX to provide some WYSIWYG features
keeping internal XML structure in 1:1 with presentation on a
visually edited web page.

4. PHP.NET API, Web-Services and visual tools

Just for the Summer of Code. It would be nice to see PHP core to
invent some advanced techniques (?PHP4EE) to let PHP technology
make the step from scripting to modeling applications, to use
abstraction as a survival instrument in complex projects. phpdoc/
is such complex project.


It is a lot of work and it is more research work than actual coding.

a. What would we like to achieve?
b. How this could be achieved?
c. What do we have?
d. What is the current status?


a. Convenient tools to communicate, edit PHPDOC documention,
build it and control the process. Easy for new developers.
b. Time, time and time (given you know what to do and how to)
detailed plan, clear idea, steps (milestones), user feedback,
requirements gathering, strong community support. Perhaps even
commercial development support.
c. Very busy and few tools developers, parts of tools code,
parts of phpdoc/ tools decription, high-volume mailing list, a
lot of sites.
d. As far as I know the only way to get the status of phpdoc/
tools is to monitor mailing list and ask questions. You can also
try to look for files on CVS and especially RFC/ folder, but
the latter seems to be greatly outdated. There is no priority/
entrypoint tasks, which will make it clear what should be done
in the first place, why it isn't done yet. There is no clear
visibility in phpdoc/ process, but almost total freedom to
hack. =)

t

--

Nuno Lopes

20 years ago

I've remembered of one more idea: gcov.php.net
That site has an enormous potential to help us building a bug-free PHP. But
this site needs some work on usability. It could for example e-mail the
developers list when there was a regression on a test or when it found a new
memory leak.
For example, today I noticed that PHP 5.1.3 was released with a pdo::mysql
test segfaulting. With a proper site, this wouldn't get forgot.
So, I think this site could use some help from a google SoC student.


Nuno

P.S.: I've already done some work, but currently I don't have time to finish
it:
http://mega.ist.utl.pt/~ncpl/phptest/
http://mega.ist.utl.pt/~ncpl/cvs/viewcvs.cgi/phpqa/

Rasmus Lerdorf

20 years ago

Nuno Lopes wrote:

> I've remembered of one more idea: gcov.php.net
> That site has an enormous potential to help us building a bug-free PHP.
> But this site needs some work on usability. It could for example e-mail
> the developers list when there was a regression on a test or when it
> found a new memory leak.
> For example, today I noticed that PHP 5.1.3 was released with a
> pdo::mysql test segfaulting. With a proper site, this wouldn't get forgot.
> So, I think this site could use some help from a google SoC student.
>
>
> Nuno
>
> P.S.: I've already done some work, but currently I don't have time to
> finish it:
> http://mega.ist.utl.pt/~ncpl/phptest/
> http://mega.ist.utl.pt/~ncpl/cvs/viewcvs.cgi/phpqa/

Add it to the ideas.php page in CVS please.

-Rasmus

Nuno Lopes

20 years ago

> Nuno Lopes wrote:
>> I've remembered of one more idea: gcov.php.net
>> That site has an enormous potential to help us building a bug-free PHP.
>> But this site needs some work on usability. It could for example e-mail
>> the developers list when there was a regression on a test or when it
>> found a new memory leak.
>> For example, today I noticed that PHP 5.1.3 was released with a
>> pdo::mysql test segfaulting. With a proper site, this wouldn't get
>> forgot.
>> So, I think this site could use some help from a google SoC student.
>>
>>
>> Nuno
>>
>> P.S.: I've already done some work, but currently I don't have time to
>> finish it:
>> http://mega.ist.utl.pt/~ncpl/phptest/
>> http://mega.ist.utl.pt/~ncpl/cvs/viewcvs.cgi/phpqa/
>
> Add it to the ideas.php page in CVS please.
>
> -Rasmus

done,
Nuno

Lukas Smith

20 years ago

Hi,

I would like to add two other project ideas:

1) Expand PEAR::MDB2_Schema to cover all aspects of schema evolution:
http://pooteeweet.org/files/phptek06/database_schema_deployment.pdf

2) Create a new set of classes to create/read/modify OpenDocument files

I would be interested in mentoring the first. I would rather not mentor
the second but I would if necessary.

regards,
Lukas