I just read about buildbot [1] on the Mono mailinglist. Would this (or
a similar solution) not be helpfull?
--
[1] http://buildbot.sourceforge.net/
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-so
> > The next question that brings up then is in relation to bug#27798:
> >
> > I would think that get_object_vars() should expose private/protected
props
> > when called from within the class itself (as appropriate based on
> > inheretance of course). Is this assumption true?
>
> yeah, I think th
On Tue, 18 May 2004, Stanislav Malyshev wrote:
> Well, the big deal is that sometimes - probably, not this time, but
> sometimes - "small changes" break things that the author didn't even
> think about it in some entirely different place. And it's always
> unexpected and unforeseen. That's why ther
On Tue, 18 May 2004, Sara Golemon wrote:
> The next question that brings up then is in relation to bug#27798:
>
> I would think that get_object_vars() should expose private/protected props
> when called from within the class itself (as appropriate based on
> inheretance of course). Is this assum
> var_dump($someobject); shows only public properties (as I'd expect), but
> print_r($someobject) shows all properties (explicitly identifying
> protected/private props).
>
So, to sum up the responses to the above question:
1) It's okay for print_r/var_dump to expose public/protected members (thei
Hi,
what is the current status of php5isapi for iis6 under win2003 server?
i couldn't run it.
--
Best regards,
npguy npguy¤websurfer.com.np
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, 18 May 2004 13:55:18 +0100
"Wez Furlong" <[EMAIL PROTECTED]> wrote:
> Hey Antony,
>
> This is most likely due to some issues with serialize/unserialize and floating
> point numbers; we don't want the format to change with the locale, since it
> should be independent.
>
> Yes, it is a mes
On Tuesday 18 May 2004 15:00, Wez Furlong wrote:
> > Exactly. Case and point: loading of php extensions from
> > php.ini or via dl()
> > being broken at the moment due to one of those "small changes".
>
> It works fine under windows, so I'm assuming the problem is in non-zts
> builds only.
It does
> Exactly. Case and point: loading of php extensions from
> php.ini or via dl()
> being broken at the moment due to one of those "small changes".
It works fine under windows, so I'm assuming the problem is in non-zts builds
only.
If you load an extension from php.ini or manually using dl(), MIN
Hey Antony,
This is most likely due to some issues with serialize/unserialize and floating
point numbers; we don't want the format to change with the locale, since it
should be independent.
Yes, it is a mess :)
--Wez.
> -Original Message-
> From: Antony Dovgal [mailto:[EMAIL PROTECTED]
On Tuesday 18 May 2004 10:41, Stanislav Malyshev wrote:
> Well, the big deal is that sometimes - probably, not this time, but
> sometimes - "small changes" break things that the author didn't even
> think about it in some entirely different place.
Exactly. Case and point: loading of php extension
Hi all!
Could somebody explain me why we're setting only LC_CTYPE to it's current value in
main/main.c, line 1368 ?
What is the reason to make all users to call setlocale() explicitly to set LC_ALL ?
Of course, there can be some reasons I'm unaware of, but I'd like to propose following
tiny pat
Hi All,
When I compiled and ran the php with apache2.0.49 my extensions module
init routines are called twice and even simple script execution keep
happening for 30 seconds and I get Timeout after 30 seconds.
Later I took 5.0.0RC2 everything works fine.
Please do the needful.
With regards
Kamesh
Hallo Marcus,
then will you cut the protected/private functionality from print_r() (so the
engine). Probably not :) . IMO var_dump() has been always superior for usage to
print_r(). During his presentation at the last conference Derick had to change
print_r() in his example to var_dump() to show t
Derick Rethans wrote:
I don't want var_dump() to change.
Oops, sorry for being too brief, I meant I agree with you about print_r
being alright and like Andrey I think *if* something's changed it should
be var_dump ;-)
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
On Tue, 18 May 2004, Christian Schneider wrote:
> Sara Golemon wrote:
> > var_dump($someobject); shows only public properties (as I'd expect), but
> > print_r($someobject) shows all properties (explicitly identifying
> > protected/private props).
>
> I agree with Derick and Andrey in that if anyth
Sara Golemon wrote:
var_dump($someobject); shows only public properties (as I'd expect), but
print_r($someobject) shows all properties (explicitly identifying
protected/private props).
I agree with Derick and Andrey in that if anything should be changed it
is var_dump.
Reasoning: PPP is there to
AZ>>Let me add to this: isn't this what "open source" is about? The bug
AZ>>did not manifest itself on my system (FreeBSD). You pointed out the
AZ>>issue. I fixed it. Cooperation prevailed. What's the big deal?
Well, the big deal is that sometimes - probably, not this time, but
sometimes - "small
Hello Andrey,
if we change something then we prevent all those function from showing
private and protected values. The current situation is ok for me though.
marcus
Tuesday, May 18, 2004, 10:01:12 AM, you wrote:
> Sara Golemon wrote:
>> var_dump($someobject); shows only public properties (as I'
Sara Golemon wrote:
var_dump($someobject); shows only public properties (as I'd expect), but
print_r($someobject) shows all properties (explicitly identifying
protected/private props).
Am I wrong in thinking that's not right?
-Sara
print_r relies on a engine's routine while var_dump() does not. I h
On Mon, 17 May 2004, Sara Golemon wrote:
> var_dump($someobject); shows only public properties (as I'd expect), but
> print_r($someobject) shows all properties (explicitly identifying
> protected/private props).
>
> Am I wrong in thinking that's not right?
I think the current way is perfectly alr
21 matches
Mail list logo