Karsten Dambekalns | 1 Apr 10:24 2009

Re: [PHP-DEV] GSoC - XDebug profiling web front-end

Hi.

On 31.03.2009 18:08 Uhr, David Coallier wrote:
> I'm sorry to tell you that but xdebug web profiling was a project for
> last year. Please read http://wiki.php.net/gsoc/2009 for this years
> GSoC ideas.

Well, was it done last year? If yes: great, where is it? If no: yeah, do 
it this year!

Regards,
Karsten

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Derick Rethans | 1 Apr 10:33 2009
Picon
Picon

Re: [PHP-DEV] GSoC - XDebug profiling web front-end

On Wed, 1 Apr 2009, Karsten Dambekalns wrote:

> On 31.03.2009 18:08 Uhr, David Coallier wrote:
> > I'm sorry to tell you that but xdebug web profiling was a project for
> > last year. Please read http://wiki.php.net/gsoc/2009 for this years
> > GSoC ideas.
> 
> Well, was it done last year? If yes: great, where is it? If no: yeah, 
> do it this year!

There was something, it's in my CVS 
(srmread:srmread <at> cvs.xdebug.org:/repository co xdebug-web) 
or http://cvs.xdebug.org/cgi-bin/viewvc.cgi/xdebug-web/ 

I don't know what the state is tbh, but there is now also "webgrind" at 
http://code.google.com/p/webgrind/

regards,
Derick

-- 
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
twitter: derickrethans

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Sebastian Bergmann | 1 Apr 10:46 2009
Picon

Re: [PHP-DEV] GSoC - XDebug profiling web front-end

Derick Rethans schrieb:
> I don't know what the state is tbh, but there is now also "webgrind" at 
> http://code.google.com/p/webgrind/

 There is also Carica Cachegrind (http://ccg.sourceforge.net/).

-- 
Sebastian Bergmann                    Co-Founder and Principal Consultant
http://sebastian-bergmann.de/                           http://thePHP.cc/

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Richard Quadling | 1 Apr 12:12 2009

Re: [PHP-DEV] PEAR support in 5.3

2009/3/31 Lukas Kahwe Smith <mls <at> pooteeweet.org>:
>
> On 28.03.2009, at 16:45, Ionut G. Stan wrote:
>
>> Hi,
>>
>> I'm playing with 5.3.0 RC1 and wanted to install PEAR. In the previous
>> versions (for Windows at least)
>> there was a go-pear executable which is missing now. So what are the plans
>> for supporting PEAR in
>> this new PHP version?
>
>
> Just FYI ... seems like Pierre fixed that one.
>
> regards,
> Lukas Kahwe Smith
> mls <at> pooteeweet.org
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

I've just downloaded all the win32 RC versions from
http://windows.php.net/qa/ (x86 and x64 versions).
(Continue reading)

Pierre Joye | 1 Apr 12:50 2009
Picon

Re: [PHP-DEV] PEAR support in 5.3

check the snapshot.

On Wed, Apr 1, 2009 at 12:12 PM, Richard Quadling
<rquadling <at> googlemail.com> wrote:
> 2009/3/31 Lukas Kahwe Smith <mls <at> pooteeweet.org>:
>>
>> On 28.03.2009, at 16:45, Ionut G. Stan wrote:
>>
>>> Hi,
>>>
>>> I'm playing with 5.3.0 RC1 and wanted to install PEAR. In the previous
>>> versions (for Windows at least)
>>> there was a go-pear executable which is missing now. So what are the plans
>>> for supporting PEAR in
>>> this new PHP version?
>>
>>
>> Just FYI ... seems like Pierre fixed that one.
>>
>> regards,
>> Lukas Kahwe Smith
>> mls <at> pooteeweet.org
>>
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
(Continue reading)

Stan Vassilev | FM | 1 Apr 13:04 2009

Re: [PHP-DEV] User namespaces and PHP classes


Hi,

There is a way to implement in some future release of PHP (without hurting 
performance), but it's not in the scope of 5.3.

Each namespace should have a meta file listing all symbols present in it. 
The parser loads that static file at parse time and resolves all naming at 
parse time, leaving autoload to figure out only where a symbol is, not 
whether it's present.

I've not noticed great interest in this approach last time I offered it.

Regards,
Stan Vassilev

> Hi,
>
> So definetly I need to prepend the \ or declare the "usage" of the
> class at the beginning in order to use classes declared in the global
> scope? This means SPL classes and 3rd-party classes.
>
> Is there a way to import all the SPL classes at once? ;) (use SPL\*,
> use PDO\*).. just wondering.
>
> Thanks
>
> On Tue, Mar 31, 2009 at 5:38 PM, Stan Vassilev | FM
> <sv_forums <at> fmethod.com> wrote:
>>
(Continue reading)

Richard Quadling | 1 Apr 14:34 2009

Re: [PHP-DEV] PEAR support in 5.3

2009/4/1 Pierre Joye <pierre.php <at> gmail.com>:
> check the snapshot.
>
> On Wed, Apr 1, 2009 at 12:12 PM, Richard Quadling
> <rquadling <at> googlemail.com> wrote:
>> 2009/3/31 Lukas Kahwe Smith <mls <at> pooteeweet.org>:
>>>
>>> On 28.03.2009, at 16:45, Ionut G. Stan wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm playing with 5.3.0 RC1 and wanted to install PEAR. In the previous
>>>> versions (for Windows at least)
>>>> there was a go-pear executable which is missing now. So what are the plans
>>>> for supporting PEAR in
>>>> this new PHP version?
>>>
>>>
>>> Just FYI ... seems like Pierre fixed that one.
>>>
>>> regards,
>>> Lukas Kahwe Smith
>>> mls <at> pooteeweet.org
>>>
>>>
>>>
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
(Continue reading)

Paul Biggar | 1 Apr 15:24 2009
Picon

Re: [PHP-DEV] RFC: Removing the Zend API

On Tue, Mar 31, 2009 at 9:23 PM, Nuno Lopes <nlopess <at> php.net> wrote:
> Hi Paul et all,
>
> I fully understand (and even share) your motivations and goals. However it
> seems to me that describing an extension in PHP will lead to loss of
> performance, as you cannot capture certain C features in PHP. For example,
> there are some internal functions that rely on pointer arithmetic to get
> decent performance.

This is not about capturing every C feature. Instead, it is about
strictly separating the C and PHP code. If someone wants to C pointer
arithmetic, it is simple to code it on the C side of the line. Its not
necessary to expose the exact C function from the library. Sometime,
you may wish to to have a C function wrapping it, to do some "dirty
tricks".

> Then you may extend to PHP to better capture these "dirty tricks", and then
> you'll end up with some DSL for building PHP extensions. It's not
> necessarily bad, it's just a lot of work.. :)

This - which I'll call the Pyrex model - is one way to go, but its not
my preference. While I think it beats the current model, I hope that
it won't be required with whatI propose in the RFC.

> Moreover, in your example in the wiki you don't include how you would do
> parameter parsing. Or do you rely on the code generator to look at the C
> functions signatures and figure out by itself what to do? (actually there is
> some ambiguity, AFAIR, and thus guessing cannot be done reliably)

That is exactly right. (I'll make this clearer in the RFC). I can't
(Continue reading)

Greg Beaver | 1 Apr 15:59 2009
Picon

Re: [PHP-DEV] User namespaces and PHP classes

Stan Vassilev | FM wrote:
> 
> Hi,
> 
> There is a way to implement in some future release of PHP (without
> hurting performance), but it's not in the scope of 5.3.
> 
> Each namespace should have a meta file listing all symbols present in
> it. The parser loads that static file at parse time and resolves all
> naming at parse time, leaving autoload to figure out only where a symbol
> is, not whether it's present.
> 
> I've not noticed great interest in this approach last time I offered it.

Hi Stan,

The reason there is little to no enthusiasm about this idea is that it
would make developing less robust while giving the illusion of ease.

let's say you have this line of code:

$a = new Blah();

Currently, the class name is deterministic.  It's either (1)
namespace\Blah() or (2) whatever we "use nsname\Blah"ed.

With your proposal, one would have to check every single one of the
meta-files for every class "use"d.  This would mean code review becomes
impossible.

(Continue reading)

Richard Quadling | 1 Apr 16:22 2009

Re: [PHP-DEV] PEAR support in 5.3

2009/4/1 Richard Quadling <rquadling <at> googlemail.com>:
> 2009/4/1 Pierre Joye <pierre.php <at> gmail.com>:
>> check the snapshot.
>>
>> On Wed, Apr 1, 2009 at 12:12 PM, Richard Quadling
>> <rquadling <at> googlemail.com> wrote:
>>> 2009/3/31 Lukas Kahwe Smith <mls <at> pooteeweet.org>:
>>>>
>>>> On 28.03.2009, at 16:45, Ionut G. Stan wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm playing with 5.3.0 RC1 and wanted to install PEAR. In the previous
>>>>> versions (for Windows at least)
>>>>> there was a go-pear executable which is missing now. So what are the plans
>>>>> for supporting PEAR in
>>>>> this new PHP version?
>>>>
>>>>
>>>> Just FYI ... seems like Pierre fixed that one.
>>>>
>>>> regards,
>>>> Lukas Kahwe Smith
>>>> mls <at> pooteeweet.org
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> PHP Internals - PHP Runtime Development Mailing List
(Continue reading)


Gmane