hi,
Did we not discuss this problem recently? If I'm not mistaken the
decision was to do not change the way constructors work in 5.x.
Cheers,
2010/6/28 Johannes Schlüter :
> Hi,
>
> On Sat, 2010-06-26 at 22:05 +, Felipe Pena wrote:
>> felipe Sat, 26 Jun 2010
Hi,
On Sat, 2010-06-26 at 22:05 +, Felipe Pena wrote:
> felipe Sat, 26 Jun 2010 22:05:13 +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=300770
>
> Log:
> - Fixed bug #51421 (Abstract __construct constructor argument list not
> enforced
I'll adjust the code to simply use in_txn flag for the moment to avoid the
structure change.
2010/6/14 Johannes Schlüter
> On Thu, 2010-06-10 at 12:11 +, Ilia Alshanetsky wrote:
> > Modified: php/php-src/branches/PHP_5_3/ext/pdo/php_pdo_driver.h
> > ==
> Here you are changing a structure which is allocated and initialized in
> a driver and then read from the PDO core. PDO core will therefore read
> invalid memory when a driver compiled against 5.3.2 is used in 5.3.3
> while we usually guarantee binary compatibility in bug fix releases.
>
> This f
On Thu, 2010-06-10 at 12:11 +, Ilia Alshanetsky wrote:
> Modified: php/php-src/branches/PHP_5_3/ext/pdo/php_pdo_driver.h
> ===
> ---
> php/php-src/branches/PHP_5_3/ext/pdo/php_pdo_driver.h 2010-06-10
> 11:45:51 UTC (rev 30035
could you discuss that on internals please?
On Sat, May 22, 2010 at 5:15 PM, Ilia Alshanetsky wrote:
> Felipe,
>
> The idea behind the more complex logic was to allow people to have
> Int/String/etc... class names, which if we make the types reserved keywords
> will no longer be possible and brea
On Tue, May 18, 2010 at 10:24, Michael Wallner wrote:
> On 05/18/2010 10:12 AM, Hannes Magnusson wrote:
>>
>> Where is that commit?
>> Most context options are quite well documented, so I'd appreciate more
>> info about this.
>
> http://news.php.net/php.doc.cvs/6187
>
Hah! Kudos.
-Hannes
--
PH
On 05/18/2010 10:12 AM, Hannes Magnusson wrote:
Where is that commit?
Most context options are quite well documented, so I'd appreciate more
info about this.
http://news.php.net/php.doc.cvs/6187
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
Hi,
On Sat, 2010-05-15 at 15:33 +0100, Jared Williams wrote:
> With using traits, don't have to provide an implementation
> of jsonSerialize() unless want to customise the behaviour,
> but the current implementation will require having to
> implement JSONSerializable.
No. The default behavior wil
> -Original Message-
> From: Hannes Magnusson [mailto:hannes.magnus...@gmail.com]
> Sent: 15 May 2010 13:25
> To: Jared Williams
> Cc: Johannes Schlüter; Pierre Joye; Stanislav Malyshev; Sara
> Golemon; PHP Internals
> Subject: Re: [PHP-DEV] Re: [PHP-CVS] sv
2010/5/14 Jared Williams :
> $a = new A();
> echo $a->toJSONString(), "\n";
> $b = new B();
> echo $b->toJSONString(), "\n";
>
$array = array(new A,new B,);
// Does not use your toJSONString method
echo json_encode($array);
-Hannes
--
PHP Internals - PHP Runtime Dev
hi,
On Fri, May 14, 2010 at 12:54 AM, Davey Shafik wrote:
> The point is that json_encode will automatically call and use the return of
> jsonSerialize()
> no matter WHERE you serialize the object.
RIght, however Json is also not about serialize (as in php's
serialize), the naming could create
wrote:
>
>
>> -Original Message-
>> From: Johannes Schlüter [mailto:johan...@schlueters.de]
>> Sent: 13 May 2010 20:47
>> To: Jared Williams
>> Cc: 'Pierre Joye'; 'Stanislav Malyshev'; 'Sara Golemon'; 'PHP
>> Internals'
>&g
> -Original Message-
> From: Johannes Schlüter [mailto:johan...@schlueters.de]
> Sent: 13 May 2010 20:47
> To: Jared Williams
> Cc: 'Pierre Joye'; 'Stanislav Malyshev'; 'Sara Golemon'; 'PHP
> Internals'
> Subject: RE: [PHP
On Thu, 2010-05-13 at 20:27 +0100, Jared Williams wrote:
> Hi,
> Keep thinking with what is in php.next that interfaces seem
> overkill?
>
> Doesn't
>
> trait JSON
> {
> function toJSONString()
> {
> return json_encode(get_object_vars($this));
> }
> }
> clas
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: 12 May 2010 11:33
> To: Stanislav Malyshev
> Cc: Sara Golemon; PHP Internals
> Subject: Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/trunk/
> NEWS ext/json/json.c ext/json/php_
hi!
On Wed, May 12, 2010 at 4:25 AM, Stanislav Malyshev wrote:
> Hi!
>
>> Add JSON_Serializable interface
>> Objects implementing JSON_Serializable will have
>> their ->jsonSerialize() method called
>>
>> Similar to serialize() and __sleep()
>
> Why should we have special mechanism for JSON? I.e.
Stanislav Malyshev wrote:
Add JSON_Serializable interface
Objects implementing JSON_Serializable will have
their ->jsonSerialize() method called
Similar to serialize() and __sleep()
Why should we have special mechanism for JSON? I.e., now we have one for
serialize(), separate one for json, th
Hi!
Add JSON_Serializable interface
Objects implementing JSON_Serializable will have
their ->jsonSerialize() method called
Similar to serialize() and __sleep()
Why should we have special mechanism for JSON? I.e., now we have one for
serialize(), separate one for json, then we'd have separate
On 12 May 2010 06:01, Sara Golemon wrote:
> On method naming, I was following the pattern of __*() for "always on" magic
> methods (__get(), __set(), etc...) versus interface-induced magic methods
> (offsetGet(), offsetSet(), etc...).
Agreed. I don't have any real preference on the interface name
However nobody ever posted anything on internals about it. The
differences between the implementation and the RFC as well as the
questions raised by this addition show that it would be better to
discuss prior to commit.
But as it is in trunk, that's less a problem, that's why trunk exists:
a deve
However nobody ever posted anything on internals about it. The
differences between the implementation and the RFC as well as the
questions raised by this addition show that it would be better to
discuss prior to commit.
But as it is in trunk, that's less a problem, that's why trunk exists:
a deve
2010/5/7 Felipe Pena
> 2010/5/6 Stefan Marr
>
>>
>
> Hi Felipe:
>>
>> Hope you don't mind that I post it on the list, think the discussion
>> should be properly archived.
>>
>>
> No problem..., open source, open discussion. :-)
>
>
>> On 06 May 2010, at 18:30, Felipe Pena wrote:
>>
>> > Hello,
2010/5/6 Stefan Marr
> Hi Felipe:
>
> Hope you don't mind that I post it on the list, think the discussion should
> be properly archived.
>
>
No problem..., open source, open discussion. :-)
> On 06 May 2010, at 18:30, Felipe Pena wrote:
>
> > Hello,
> >
> > 2010/5/6 Stefan Marr
> > Hi Felipe:
Hi Felipe:
Hope you don't mind that I post it on the list, think the discussion should be
properly archived.
On 06 May 2010, at 18:30, Felipe Pena wrote:
> Hello,
>
> 2010/5/6 Stefan Marr
> Hi Felipe:
>
> On 05 May 2010, at 22:00, Felipe Pena wrote:
> > One question... Looking at the gramm
hi,
I like the feature, it is a nice and useful one.
However nobody ever posted anything on internals about it. The
differences between the implementation and the RFC as well as the
questions raised by this addition show that it would be better to
discuss prior to commit.
But as it is in trunk,
PS: Argh, sorry... pressed the send button without finishing to write the email.
Consistency that matches with Serializable interface when dealing with
(un)serialize(). So if we have to vote, I'd go for Jsonable.
The method should be renamed to _toJSON (I can even accept __toJson
here), using the
Hi guys,
I'd like to thank you for this implementation.
@Pierre: There is a RFC I wrote: http://wiki.php.net/rfc/jsonable
I'd suggest to rather be JSONSerializable or be Jsonable.
JSON is an acronym, the same as PDO. We don't have interface for Pdo,
but for PDO.
So we should keep consistency.
On Thu, May 6, 2010 at 12:59 PM, Hannes Magnusson
wrote:
> On Thu, May 6, 2010 at 00:48, Sara Golemon wrote:
>> pollita Wed, 05 May 2010 22:48:14 +
>>
>> Revision: http://svn.php.net/viewvc?view=revision&revision=299037
>>
>> Log:
>> Add JSON_Serializable inte
On 29/04/2010 09:45, Hannes Magnusson wrote:
On Thu, Apr 29, 2010 at 10:13, Pierre Joye wrote:
pajoye Thu, 29 Apr 2010 08:13:15 +
Revision: http://svn.php.net/viewvc?view=revision&revision=298759
Log:
- Adieu VC6/7/8, merci pour les bons et loyaux service
On Thu, 29 Apr 2010, Rob Richards wrote:
> The discussion was a while ago (Steph was working on a way to autogenerate
> them at the time). Unfortunately it failed miserably (buildconf error'd out)
> when I tried to use it (tried it after the dsps had been removed). Until that
> is working (or some
Right. My point is only that we keep them around until we can get the
automatic generation squared away.
Rob
Dmitry Stogov wrote:
Hi Rob,
The problem is not to have them. The problem is to keep them in
consistency in case someone adds/removes a file. I like the idea of
automatic generation
On Thu, Apr 29, 2010 at 11:28 AM, Dmitry Stogov wrote:
> Hi Rob,
>
> The problem is not to have them. The problem is to keep them in consistency
> in case someone adds/removes a file. I like the idea of automatic generation
> much more.
That's what cmake aims to. But having JS code to generate th
Hi Rob,
The problem is not to have them. The problem is to keep them in
consistency in case someone adds/removes a file. I like the idea of
automatic generation much more.
Thanks. Dmitry.
Rob Richards wrote:
Hi Dmitry,
The discussion was a while ago (Steph was working on a way to
autogene
On Thu, Apr 29, 2010 at 10:45 AM, Hannes Magnusson
wrote:
> On Thu, Apr 29, 2010 at 10:13, Pierre Joye wrote:
>> pajoye Thu, 29 Apr 2010 08:13:15 +
>>
>> Revision: http://svn.php.net/viewvc?view=revision&revision=298759
>>
>> Log:
>> - Adieu VC6/7/8, merci po
On Thu, Apr 29, 2010 at 10:13, Pierre Joye wrote:
> pajoye Thu, 29 Apr 2010 08:13:15 +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=298759
>
> Log:
> - Adieu VC6/7/8, merci pour les bons et loyaux services
In the offchance that some people a
Hi Dmitry,
The discussion was a while ago (Steph was working on a way to
autogenerate them at the time). Unfortunately it failed miserably
(buildconf error'd out) when I tried to use it (tried it after the dsps
had been removed). Until that is working (or some other mechanism is in
place to g
On Thu, Apr 29, 2010 at 10:23 AM, Dmitry Stogov wrote:
> Hi Rob,
>
> May be I missed the discussion...
>
> I'm not sure if it's a good idea to have all this scarp in SVN.
> Personally, I won't support these DSP files just because I don't use Visual
> Studio 6.0 to build php. This method was deprec
Hi Rob,
May be I missed the discussion...
I'm not sure if it's a good idea to have all this scarp in SVN.
Personally, I won't support these DSP files just because I don't use
Visual Studio 6.0 to build php. This method was deprecated for ages. I'm
also not sure if next php version is going to
On Tue, Apr 27, 2010 at 01:53, Kalle Sommer Nielsen wrote:
> kalle Mon, 26 Apr 2010 23:53:30 +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=298625
>
> Log:
> Removed safe_mode
> * Removed ini options, safe_mode*
> * Removed --enable-safe-m
2010/4/12 Johannes Schlüter :
> Hi,
>
> On Mon, 2010-04-12 at 08:25 +, Pierre Joye wrote:
>> - switch (ZEND_NUM_ARGS()) {
>> - case 2:
>> - if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rl",
>> &arg1, &arg2) == FAILURE) {
>> - RETURN_FALSE;
>> -
hi,
On Mon, Apr 12, 2010 at 10:25 AM, Pierre Joye wrote:
> pajoye Mon, 12 Apr 2010 08:25:50 +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=297865
>
> Log:
> - [doc] add stream_set_read_buffer, equivalent of stream_set_write_buffer for
> rea
> -Original Message-
> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Sent: 03 April 2010 02:44
> To: Jared Williams
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/
> branches/PHP_5_2/NEWS
> branches/PHP_5_2/ext/
On 04/02/2010 06:25 PM, Jared Williams wrote:
>
>
>> -Original Message-
>> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
>> Sent: 03 April 2010 01:20
>> To: Jared Williams
>> Cc: internals@lists.php.net
>> Subject: Re: [PHP-DEV] Re: [PHP-CV
> -Original Message-
> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Sent: 03 April 2010 01:20
> To: Jared Williams
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/
> branches/PHP_5_2/NEWS
> branches/PHP_5_2/ext/
Rasmus Lerdorf:
> The ABNF for an HTML5 valid email field is:
>
> 1*( atext / "." ) "@" ldh-str 1*( "." ldh-str )
>
> which means there must be a . in the domain part, so HTML5 doesn't think
> a...@b is valid either. The left-hand side looks wrong though. It seems
> to me it should be:
>
>
On 04/02/2010 04:47 PM, Jared Williams wrote:
> Would make sense. Especially considering HTML5's current validation
> rules of emails is something different again.
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-
> the-type-attribute.html#e-mail-state
>
> Having a mismat
> -Original Message-
> From: Ferenc Kovacs [mailto:tyr...@gmail.com]
> Sent: 02 April 2010 23:09
> To: Rasmus Lerdorf
> Cc: Sean Coates; internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/
> branches/PHP_5_2/NEWS
> bra
Why not define multiple filters?
I did that solution with more than one framework.
There are cases when you need to validate the email of your remote users
(eg. you want to restrict j...@localhost), and there are some cases, when you
want to go all the way: validate the email by format, check the d
On 04/02/2010 02:37 PM, Sean Coates wrote:
>> If you look closely you will see that all 5 validators in the chart
>> reject single-word domains.
>
> Note that this regex also considers anyth...@localhost to be an invalid email
> address.
> I hear your point about the difference between a local ma
> If you look closely you will see that all 5 validators in the chart
> reject single-word domains.
Note that this regex also considers anyth...@localhost to be an invalid email
address.
I hear your point about the difference between a local machine named "va" and
the "va." TLD, but I doubt I'm
I should also mention that most of the popular validators I checked came
to the same conclusion. There is a chart here:
http://www.dominicsayers.com/isemail/results.php
If you look closely you will see that all 5 validators in the chart
reject single-word domains.
-Rasmus
--
PHP Internals - P
On 04/02/2010 01:22 PM, Martin Jansen wrote:
> On 02.04.10 19:56, Rasmus Lerdorf wrote:
>> rasmus Fri, 02 Apr 2010 17:56:37 +
>>
>> Revision: http://svn.php.net/viewvc?view=revision&revision=297350
>>
>> Log:
>> Update the FILTER_VALIDATE_EMAIL filter to fix bu
On Fri, Apr 2, 2010 at 10:22 PM, Martin Jansen wrote:
> On 02.04.10 19:56, Rasmus Lerdorf wrote:
>> rasmus Fri, 02 Apr 2010 17:56:37 +
>>
>> Revision: http://svn.php.net/viewvc?view=revision&revision=297350
>>
>> Log:
>> Update the FILTER_VALIDATE_EMAIL filter
On 02.04.10 19:56, Rasmus Lerdorf wrote:
> rasmus Fri, 02 Apr 2010 17:56:37 +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=297350
>
> Log:
> Update the FILTER_VALIDATE_EMAIL filter to fix bug #49576
I'm referring to the following comment:
2010/3/29 Jérôme Loyet :
> Le 29 mars 2010 13:11, Pierre Joye a écrit :
>> hi,
>>
>> I would suggest to call it fpm.configuration_path if it looks for the
>> file it self there, or fpm.configuration_dir if it looks in this path
>> for the conf file(s), that's actually explicit :)
>
> as discuss wi
Le 29 mars 2010 13:11, Pierre Joye a écrit :
> hi,
>
> I would suggest to call it fpm.configuration_path if it looks for the
> file it self there, or fpm.configuration_dir if it looks in this path
> for the conf file(s), that's actually explicit :)
as discuss with tony, I changed that to fpm.conf
hi,
I would suggest to call it fpm.configuration_path if it looks for the
file it self there, or fpm.configuration_dir if it looks in this path
for the conf file(s), that's actually explicit :)
Cheers,
2010/3/29 Jérôme Loyet :
> fat Mon, 29 Mar 2010 10:45:28
On Fri, 2010-03-26 at 11:03 -0700, Stanislav Malyshev wrote:
> Hi!
>
> >> Well, they don't necessarily have to fix their application. They can
> >> just put: default_charset=iso-8859-1 in their php.ini.
> >
> > If they have access to the file, which many users don't have. And I
>
> Can't they ju
Hi!
Well, they don't necessarily have to fix their application. They can
just put: default_charset=iso-8859-1 in their php.ini.
If they have access to the file, which many users don't have. And I
Can't they just do ini_set? It's INI_ALL.
--
Stanislav Malyshev, Zend Software Architect
s...@z
On Fri, 2010-03-26 at 08:04 -0700, Rasmus Lerdorf wrote:
> On 03/26/2010 05:39 AM, Johannes Schlüter wrote:
> > On Tue, 2010-03-23 at 18:08 +, Rasmus Lerdorf wrote:
> >> rasmus Tue, 23 Mar 2010 18:08:06 +
> >>
> >> Revision: http://svn.php.net/viewvc?view=r
2010/3/26 Johannes Schlüter :
> On Tue, 2010-03-23 at 18:08 +, Rasmus Lerdorf wrote:
> With the environments using more and more Utf-8 (operating system
> environments, editor defaults, ...) the change is good but it is no
> small thing but will cause "trouble" for many users having iso-8859-1
On Fri, Mar 19, 2010 at 8:54 PM, sean finney wrote:
> On Thu, Mar 18, 2010 at 11:37:09PM +0100, Pierre Joye wrote:
>> While wondering what was the reasoning behind this commit, I came to
>> the conclusion that we should not do such thing in stable branches and
>> we should respect something we dec
On Thu, Mar 18, 2010 at 11:37:09PM +0100, Pierre Joye wrote:
> While wondering what was the reasoning behind this commit, I came to
> the conclusion that we should not do such thing in stable branches and
> we should respect something we decided long time ago, to stop to add
> bad options which can
Issue solved, the patch has been reverted by Andrei, thanks.
However the question about the bad new configure option remains.
On Thu, Mar 18, 2010 at 11:37 PM, Pierre Joye wrote:
> hi,
>
> CCing Ilia and Johannes as Andrei "discussed with the RM offline", I
> suppose it is Ilia, but Johannes is
hi,
CCing Ilia and Johannes as Andrei "discussed with the RM offline", I
suppose it is Ilia, but Johannes is the 5.3 RM.
For the record, this fix is about using size_t in the SAPI to fix
issues with uploaded files > 2G.
While wondering what was the reasoning behind this commit, I came to
the con
On Tue, Mar 16, 2010 at 16:45, Derick Rethans wrote:
> derick Tue, 16 Mar 2010 15:45:24 +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=296284
>
> Log:
> - Moved the Unicode experiment from trunk to its own branch for reference.
>
> Changed pa
where did that mail come from?
imho it should have been addressed to the mailing list directly.
I agree that he was short-tempered, but I think that the progress worth it.
Tyrael
On Fri, Mar 12, 2010 at 3:43 PM, Pierre Joye wrote:
> On Fri, Mar 12, 2010 at 3:38 PM, Lukas Kahwe Smith
> wrote:
On Fri, Mar 12, 2010 at 3:38 PM, Lukas Kahwe Smith wrote:
> imho jani's commit access should be revoked until we have sorted out our
> release plan for the future, because he has shown that he has no patience to
> respect other people's opinions and so we can alleviate him of doing stupid
> th
2010/3/11 Jani Taskinen :
> Yadda yadda, it's a bug fix. Just call next one 5.4 like it should be.
Let me translate what both reply said: Please revert, thanks.
The key number is this branche name is 3 and it is a stable branch.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http:/
On 03/11/2010 12:50 PM, Johannes Schlüter wrote:
On Thu, 2010-03-11 at 10:24 +, Jani Taskinen wrote:
jani Thu, 11 Mar 2010 10:24:29
+
Revision: http://svn.php.net/viewvc?view=revision&revision=296062
Log:
MFH: Improved / fixed output buffering (Mich
On Thu, 2010-03-11 at 10:24 +, Jani Taskinen wrote:
>
> jani Thu, 11 Mar 2010 10:24:29
> +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=296062
>
> Log:
> MFH: Improved / fixed output buffering (Michael Wallner)
Yes the old code had
HI Jani,
I don't think it is a good think to merge this change at this stage in
5.3. 5.3 is now very stable and should have only bug fixes and minor
improvements. I would have like to have the new output API in 5.3, but
we failed to do it before 5.3.0 release began. But it is definitively
too late
Pierre Joye wrote:
On Fri, Jan 29, 2010 at 9:36 AM, Alexey Zakhlestin wrote:
As far as I remember, it was decided that C99 is ok for php6.
I can't remember any decision about C99.
Anyway, we probably need to compose some table on what compilers have limited
(and how limited) s
On 29.01.2010, at 13:32, Pierre Joye wrote:
> On Fri, Jan 29, 2010 at 9:36 AM, Alexey Zakhlestin wrote:
>> As far as I remember, it was decided that C99 is ok for php6.
>
> I can't remember any decision about C99.
I remember some talk with andrei on irc… I guess we never wrote that down
>
>>
On Fri, Jan 29, 2010 at 9:36 AM, Alexey Zakhlestin wrote:
> As far as I remember, it was decided that C99 is ok for php6.
I can't remember any decision about C99.
> Anyway, we probably need to compose some table on what compilers have limited
> (and how limited) support for c99.
> Then we can o
On 29.01.2010, at 1:39, David Soria Parra wrote:
> On 2010-01-22, Johannes Schlüter wrote:
>> Hi,
>>
>> On Thu, 2010-01-21 at 17:49 +, Ilia Alshanetsky wrote:
>>> iliaaThu, 21 Jan 2010 17:49:38 +
>>>
>>> Revision: http://svn.php.net/viewvc?view=revis
On 2010-01-22, Johannes Schl?ter wrote:
> Hi,
>
> On Thu, 2010-01-21 at 17:49 +, Ilia Alshanetsky wrote:
>> iliaaThu, 21 Jan 2010 17:49:38 +
>>
>> Revision: http://svn.php.net/viewvc?view=revision&revision=293812
>>
>> Log:
>> Upgraded bundled PCRE to
The change is specific to :: since that is used for classes and causes
confusion as people may think foo::bar will allow definition or
re-definition of a class constant which it does not.
On 09-12-30 2:42 PM, Johannes Schlüter wrote:
> Hi,
>
> On Wed, 2009-12-30 at 19:15 +, Ilia Alshanetsky w
Hi,
On Wed, 2009-12-30 at 19:15 +, Ilia Alshanetsky wrote:
> iliaaWed, 30 Dec 2009 19:15:11 +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=292823
>
> Log:
> Fixed bug #44827 (define() allows :: in constant names).
>
> Bug: http://bu
Jani Taskinen wrote:
> Rasmus Lerdorf wrote:
>> Jani Taskinen wrote:
>>> 1. Why are you constantly not merging stuff to HEAD?
>>> 2. Isn't this related to bug #50231 and why are you not using the proper
>>> commit message then? Hint: - Fixed bug..
>>>
>>> It's getting quite annoying that some peopl
Rasmus Lerdorf wrote:
Jani Taskinen wrote:
1. Why are you constantly not merging stuff to HEAD?
2. Isn't this related to bug #50231 and why are you not using the proper
commit message then? Hint: - Fixed bug..
It's getting quite annoying that some people (Rasmus included) tend to
ignore that we
Jani Taskinen wrote:
> 1. Why are you constantly not merging stuff to HEAD?
> 2. Isn't this related to bug #50231 and why are you not using the proper
> commit message then? Hint: - Fixed bug..
>
> It's getting quite annoying that some people (Rasmus included) tend to
> ignore that we have a devel
1. Why are you constantly not merging stuff to HEAD?
2. Isn't this related to bug #50231 and why are you not using the proper commit
message then? Hint: - Fixed bug..
It's getting quite annoying that some people (Rasmus included) tend to ignore
that we have a development branch (HEAD, trunk) a
>>> I'm wondered why the shebang line support was removed from scanner.
>>
>> Because it didn't make any sense for other SAPIs. You could ask Ilia more
>> about it:
>>
>> -
>> r273178 | iliaa | 2009-01-09 19:21:12 +0200 (Fri,
Jani Taskinen wrote:
On 09/07/2009 09:25 AM, Dmitry Stogov wrote:
Hi,
I'm wondered why the shebang line support was removed from scanner.
Because it didn't make any sense for other SAPIs. You could ask Ilia
more about it:
--
On 09/07/2009 09:25 AM, Dmitry Stogov wrote:
Hi,
I'm wondered why the shebang line support was removed from scanner.
Because it didn't make any sense for other SAPIs. You could ask Ilia
more about it:
-
r273178 | iliaa
-
> From: Garrett Serack [mailto:garre...@microsoft.com]
> Sent: Thursday, August 20, 2009 7:24 AM
> To: Stas Malyshev; Pierre
> Cc: 'PHP Internals'
> Subject: RE: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/
branches/PHP_5_3/NEWS
> branches/PHP_5_3/TSRM/tsrm_win32.c trunk/T
ert that patch, and I'll write a new separate routine
> that doesn't use cmd.exe as a gateway.
>
> My Apologies.
>
> G
>
> -Original Message-
> From: Stanislav Malyshev [mailto:s...@zend.com]
> Sent: Wednesday, August 19, 2009 2:40 PM
> To: Garrett Serack; P
G
-Original Message-
From: Stanislav Malyshev [mailto:s...@zend.com]
Sent: Wednesday, August 19, 2009 2:40 PM
To: Garrett Serack; Pierre
Cc: 'PHP Internals'
Subject: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS
branches/PHP_5_3/TSRM/tsrm_win32.c trunk/TSRM/t
2009/8/19 Stanislav Malyshev :
> Hi!
>
>> Initially, this prevents popen_ex from failing when the actual
>> executable doesn't exist, since "cmd.exe /c c:\foo\bar\xxx.exe" will
>> *always* successfully start a process. This can be seen in bug
>> #43327.
>>
>> Second, is that by having the intermedi
Hi!
Initially, this prevents popen_ex from failing when the actual
executable doesn't exist, since "cmd.exe /c c:\foo\bar\xxx.exe" will
*always* successfully start a process. This can be seen in bug
#43327.
Second, is that by having the intermediate process, I'm pretty sure
there's some extra-b
Uwe Schindler wrote:
> Thanks Jani,
>
> I thought it is still optional to do this.
>
> The question is, how to do that on Windows with TortoiseSVN using the GUI?
> We had a similar discussion on the Lucene-Java Mailinglist about updating
> the backwards-compatibility tests branch with one commit
On Jul 13, 2009, at 12:51 PM, Pierre Joye wrote:
pajoye Mon, 13 Jul 2009 16:11:45 +
ViewVC URL: http://svn.php.net/viewvc?view=revision&revision=284019
Changed paths:
A php/php-src/trunk/win32/build/svnclean.js
Log:
- rename to svn
Copied: php/php-src/trunk/win32/build/s
201 - 294 of 294 matches
Mail list logo
