Hi Diogo,
Diogo Neves wrote:
> On Tue, Sep 2, 2008 at 11:30 PM, Arnaud Le Blanc <[EMAIL PROTECTED]>wrote:
>
>> Hi,
>>
>> On Tuesday 02 September 2008 12:15:02 Dmitry Stogov wrote:
>>> Jani Taskinen wrote:
>> Dmitry Stogov wrote:
>>> Hi,
>>>
>>> Attached is a proposed fix for http:
On Thu, Sep 4, 2008 at 8:36 AM, steve <[EMAIL PROTECTED]> wrote:
>> Try with IIS7 + FCGI, it is _fast_ :)
>
> It's a "same-across-platforms" thing. Mostly to do with the fact we
> use mod-rewrite. :(
I did not try it yet but IIS has a rewrite module. There is also a
commercial product being 100% c
hi,
On Thu, Sep 4, 2008 at 6:06 AM, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Btw, contrary to what many believe, 32bit PHP tends to perform better
> than 64bit PHP.
> So unless there's a really good reason why you want 64bit I wouldn't
> waste too much time on that.
And do not forget that the x6
On Thu Aug 28 01:47 PM, Christian Seiler wrote:
> Hi again,
>
>> A few weeks ago I wrote quite a long posting to internals@ that tried
>> to clarify the situation on the round() function in PHP. I was asked
>> to write it up as an RFC in the wiki, which I have done:
>>
>> http://wiki.php.net/rf
Услуги патентного поверенного:
товарные знаки, патенты, авторские права Бесплатные консультации.
Тел. (495) 629 9611
Тел. (499) 408 9683
On Wed, 2008-09-03 at 23:36 -0700, steve wrote:
> It is pretty much include() and its relatives. Autoloading with a lot
> of possible include paths. I'm sure if you had a Zend Framework App
> and put it on Windows, and took out all the require_onces with paths
> in them
Try 5.3 please, our impleme
Hello guys,
I just had to write you guys to give you some "real-life" examples.
We're working here at a PHP framework, named ALFA PHP Framework, that's
rather unique in the way that it enforces strong types in every method
(using classes for basic data types). We have our files organized th
Hello guys,
We have too clases:
- Abstract class OutputBuffering
- Class ErrorHandler extends OutputBuffering, implements obHandler
as a "protected" method. I can detect: set_error_handler errors, through a
specific error handler (and obError method - I can dete
Yes, excuse my English would be appropriate. I was in a hurry when writing
the email. Waiting for feedback from you guys ...
-Original Message-
From: Catalin Zamfir Alexandru | KIT Software CAZ
[mailto:[EMAIL PROTECTED]
Sent: Thursday, September 04, 2008 5:17 PM
To: 'PHP Internals List'
S
On Thu, Sep 4, 2008 at 3:21 PM, Catalin Zamfir Alexandru | KIT Software CAZ
<[EMAIL PROTECTED]> wrote:
> Yes, excuse my English would be appropriate. I was in a hurry when writing
> the email. Waiting for feedback from you guys ...
>
> -Original Message-
> From: Catalin Zamfir Alexandru |
Yes, that's the "so-called bug" I'm talking about. Having the obHandler
marked as "protected" makes "$this->getMe ()" kind of errors, from GLOBAL
context undetectable, while Parse/Notice/Warning errors are stil there, even
if the "$this->getMe ()" error is marked as "Fatal Error:". Here: Fatal
erro
This is my PHP:
PHP 5.2.6-pl6-gentoo (cli) (built: Aug 17 2008 01:02:28)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
-Original Message-
From: Catalin Zamfir Alexandru | KIT Software CAZ
[mailto:[EMAIL PROTECTED]
Sent: Thursday, Septe
On Thu, Sep 4, 2008 at 3:36 PM, Catalin Zamfir Alexandru | KIT Software CAZ
<[EMAIL PROTECTED]> wrote:
> This is my PHP:
> PHP 5.2.6-pl6-gentoo (cli) (built: Aug 17 2008 01:02:28)
> Copyright (c) 1997-2008 The PHP Group
> Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
>
> -Origi
Abstract class Output_Buffering {
Protected static function obStart () {
Ob_start ('ErrorH::obHandler');
Set_our_error_handler ('some_error_h_we_have');
}
}
Class ErrorH extends Output_Buffering {
Protected static obHandler {
On Thu, Sep 4, 2008 at 4:47 PM, Catalin Zamfir Alexandru | KIT Software CAZ
<[EMAIL PROTECTED]> wrote:
> Abstract class Output_Buffering {
>Protected static function obStart () {
>Ob_start ('ErrorH::obHandler');
>Set_our_error_handler ('some_error_h_we_have'
Actually it's not when you want to separate Output Buffering from
ErrorHandling. :) . and YES, you can access "obHandler" when it is
protected, because you extends the abstract base class, but it fails
miserably on the "$this->getMe ()" error type.
From: Diogo Neves [mailto:[EMAIL PROTECTED]
S
Hi,
now that we have a publicly available alpha on Windows we get the first
feedback from Windows users. Within quite short time we got two bug
reports (#45992 #45994) about a change in the ini-parsing:
With <=5.2 we allow
include_path = "c:\foo\bar\"
and treat the backslash as regular chara
hi,
On Thu, Sep 4, 2008 at 7:07 PM, Johannes Schlüter <[EMAIL PROTECTED]> wrote:
> Hi,
>
> now that we have a publicly available alpha on Windows we get the first
> feedback from Windows users. Within quite short time we got two bug
> reports (#45992 #45994) about a change in the ini-parsing:
>
>
On 04.09.2008 21:07, Johannes Schlüter wrote:
This was caused by the changes in the ini parser which are important,
but in my opinion this is a break where we should try to find a way to
keep the behavior, especially as it was in the "recommended" php.ini
file and other places before.
I have to
hi,
On Thu, Sep 4, 2008 at 7:27 PM, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> but now it's too late for such changes,
> we have to put the old behavior back.
Even if it may mean drop the new ini parser and features?
I'm waiting Jani's anwer on that.
Cheers,
--
Pierre
http://blog.thepimp.net
Hi!
Even if it may mean drop the new ini parser and features?
Which features require \ to be special character? Maybe we could change
them so they do not?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP I
Pierre Joye:
> hi,
>
> On Thu, Sep 4, 2008 at 7:27 PM, Antony Dovgal <[EMAIL PROTECTED]> wrote:
>
> > but now it's too late for such changes,
> > we have to put the old behavior back.
>
> Even if it may mean drop the new ini parser and features?
If you can allow both old and new behavior to co-
I have to agree, this kind of change would be very frustrating for Win32
users, even though the solution is that simple.
Nobody reads update guides or installation instructions, they're used to
write path like that and they'll continue to do it, so we'll have much
more bug reports after the re
Stan Vassilev | FM wrote:
I have to agree, this kind of change would be very frustrating for
Win32 users, even though the solution is that simple.
Nobody reads update guides or installation instructions, they're used
to write path like that and they'll continue to do it, so we'll have
much mo
2008/9/4 Catalin Zamfir Alexandru | KIT Software CAZ <[EMAIL PROTECTED]>:
> Actually it's not when you want to separate Output Buffering from
> ErrorHandling. :) . and YES, you can access "obHandler" when it is
> protected, because you extends the abstract base class, but it fails
> miserably on th
Hi,
> For the record, I was very excited to see your proposal and the work you've
> done.
Thanks! :)
> I'm not a PHP dev so I can't comment on the patch, maybe there might
> be a performance concern?
The new algorithm is slightly slower in most of the cases and quite a
bit slower if strings h
Stan Vassilev | FM kirjoitti:
I have to agree, this kind of change would be very frustrating for
Win32 users, even though the solution is that simple.
Nobody reads update guides or installation instructions, they're used
to write path like that and they'll continue to do it, so we'll have
muc
Pierre Joye kirjoitti:
hi,
On Thu, Sep 4, 2008 at 7:27 PM, Antony Dovgal <[EMAIL PROTECTED]> wrote:
but now it's too late for such changes,
we have to put the old behavior back.
Even if it may mean drop the new ini parser and features?
I'm waiting Jani's anwer on that.
"" allow using ini
Johannes Schlüter kirjoitti:
Hi,
now that we have a publicly available alpha on Windows we get the first
feedback from Windows users. Within quite short time we got two bug
reports (#45992 #45994) about a change in the ini-parsing:
With <=5.2 we allow
include_path = "c:\foo\bar\"
That SHOU
Hi!
I don't think something allowed and documented can be just remove
without considering the consequences. It worked and did what it was
intended to do, why we need to drop it?
If people actually have configs that would stop working in 5.3 and it
wouldn't be good for anybody. In windows, beca
hi,
On Thu, Sep 4, 2008 at 11:08 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I don't think something allowed and documented can be just remove without
> considering the consequences. It worked and did what it was intended to do,
> why we need to drop it?
> If people actually have c
Hi!
Or simply remove the double quotes.
include_path=C:\Users\pierre\Documents\Digsby Logs
works just fine.
I was under impression it doesn't always work, looking at the parser
space is not in VALUE_CHARS, also single quote and () (which can be used
by Windows in directory names) isn't. I'
I agree, users will notice quickly enough and the previous behaviour
doesn't match that of PHP.
If we provide an uprade information popup at the end of the Windows
installer it might help.
Scott
On 4 Sep 2008, at 22:24, "Pierre Joye" <[EMAIL PROTECTED]> wrote:
hi,
On Thu, Sep 4, 2008 at
33 matches
Mail list logo
