Hi,
It seems to be the case but this is not documented anywhere on
php.net. Instead
http://php.net/manual/en/function.apache-request-headers.php say "You
can also get at the value of the common CGI variables by reading them
from the environment".
This comment http://www.php.net/manual/en/reserved
On 09/07/2011 04:57 PM, David Soria Parra wrote:
For everyone else, go read http:/progit.org, make yourself familar with Git.
- David
The Drupal community has collected various good resources on Git as well:
http://drupal.org/node/783086
(You can ignore the Drupal-specific ones, of course.
Yup, I know, actually I've just finished reading the RFC's implementation
part and saw github just mentioned here and there, but not being the point
of focus, which is the most correct attitude to have IMHO while choosing a
DVCS (that's the only way Mercurial can steal some of the DVCS thunder:
git
On 09/07/2011 11:15 PM, dukeofgaming wrote:
> Awesome news, this particular decision tends not to be an easy one in open
> source software communities (well, perhaps now it is easier with all the
> traction git & github have) so I think this is evidence of how good the RFC
> process is.
>
> Is the
Awesome news, this particular decision tends not to be an easy one in open
source software communities (well, perhaps now it is easier with all the
traction git & github have) so I think this is evidence of how good the RFC
process is.
Is there a github repository already?.
Best regards and congr
Am 08.09.2011 08:09, schrieb Flavius Aspra:
> As a former svn-only user, I can tell you how I've learned (and still
> learn) about git:
I found @chacon's talk (https://bit.ly/3treespreso) at FrOSCon very
useful.
--
Sebastian BergmannCo-Founder and Principal Consultant
http:
On 09/07/2011 11:57 PM, David Soria Parra wrote:
For everyone else, go read http:/progit.org, make yourself familar with Git.
As a former svn-only user, I can tell you how I've learned (and still
learn) about git:
1. http://git.or.cz/course/svn.html
2. progit
3. Git from the Bottom up:
h
On Wed, Sep 7, 2011 at 11:20 PM, Rasmus Lerdorf wrote:
> On 09/07/2011 02:12 PM, Stas Malyshev wrote:
>> But it doesn't send SIGPROF by itself. Looks like Darwin got screwed up
>> itimer implementation at least up to kernel 10.8.0, Mac OS X 10.6.8.
>> Didn't try it on Lion, maybe the have updated/
Hi Internals,
after 2 weeks of voting and discussion, I closed the votes today. The results
are fairly straightforward. Most of the users want to move to a decentralized
version
control system.
52 want to switch to git
15 want to switch to Mercurial
1 for bazaar
13 want to stay
On 09/07/2011 02:12 PM, Stas Malyshev wrote:
> But it doesn't send SIGPROF by itself. Looks like Darwin got screwed up
> itimer implementation at least up to kernel 10.8.0, Mac OS X 10.6.8.
> Didn't try it on Lion, maybe the have updated/fixed it.
Right, so we need to decide what to do about that.
Hi!
On 9/7/11 2:01 PM, Rasmus Lerdorf wrote:
I am curious, what do you see when you strace it?
On Linux you get:
Darwin has no strace. dtruss is not very helpful:
83310/0x43ee45: 32798 11 7 munmap(0x208B000, 0x11E)
= 0 0
83310/0x43ee45: 32805 9 6 close_n
On 09/07/2011 01:32 PM, Stas Malyshev wrote:
> Hi
>
> On 9/7/11 1:17 PM, Rasmus Lerdorf wrote:
>>
>> Interesting that this is different on Darwin. That doesn't seem like
>> something that should be OS-specific unless Darwin's itimer
>> implementation is messed up.
>
> Looks like it might be the c
Hi
On 9/7/11 1:17 PM, Rasmus Lerdorf wrote:
Interesting that this is different on Darwin. That doesn't seem like
something that should be OS-specific unless Darwin's itimer
implementation is messed up.
Looks like it might be the case:
http://openradar.appspot.com/9336975
REAL timer works, o
On 09/07/2011 01:04 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/7/11 12:43 PM, Rasmus Lerdorf wrote:
>> Actually, it seems to be more than that. That set_time_limit() just
>> speeds up the test. Since we have a default max_execution_time you
>> should still have hit that and the shutdown function shou
Hi!
On 9/7/11 12:43 PM, Rasmus Lerdorf wrote:
Actually, it seems to be more than that. That set_time_limit() just
speeds up the test. Since we have a default max_execution_time you
should still have hit that and the shutdown function should have been
called. But your other max_execution_time-rel
On 09/07/2011 12:28 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/7/11 12:24 PM, Rasmus Lerdorf wrote:
>>> tests/lang/045.phpt now works for me, but tests/func/005a.phpt still
>>> fails. It's on Darwin.
>>
>> That one doesn't fail for me. What's your diff?
>
> 002+
> 002- Shutdown
> 003+ ** ERROR: pro
On 09/07/2011 12:28 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/7/11 12:24 PM, Rasmus Lerdorf wrote:
>>> tests/lang/045.phpt now works for me, but tests/func/005a.phpt still
>>> fails. It's on Darwin.
>>
>> That one doesn't fail for me. What's your diff?
>
> 002+
> 002- Shutdown
> 003+ ** ERROR: pro
Hi!
On 9/7/11 12:24 PM, Rasmus Lerdorf wrote:
tests/lang/045.phpt now works for me, but tests/func/005a.phpt still
fails. It's on Darwin.
That one doesn't fail for me. What's your diff?
002+
002- Shutdown
003+ ** ERROR: process timed out **
It looks like set_time_limit(1) doesn't work.
--
On 09/07/2011 12:16 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/7/11 11:54 AM, Rasmus Lerdorf wrote:
>> Please help me figure out if this fix causes any weird side-effects
>> anywhere. Essentially the problem is that the new deferred signals
>> patch ignores signals when running signal handlers. But s
Hi!
On 9/7/11 11:54 AM, Rasmus Lerdorf wrote:
Please help me figure out if this fix causes any weird side-effects
anywhere. Essentially the problem is that the new deferred signals
patch ignores signals when running signal handlers. But since
register shutdown functions are called by the signal
Please help me figure out if this fix causes any weird side-effects
anywhere. Essentially the problem is that the new deferred signals
patch ignores signals when running signal handlers. But since
register shutdown functions are called by the signal handler they
won't time out anymore. By pretendin
hi,
the main problem is that the (stupid) windows filesystem APIs consider
" foo", "foo " as being the same than "foo". It has caused all kind of
bad effects and we added checks in some areas already in 5.3.
Now that 5.4 has a "p" parameter we can simply cleanup the given paths
before passing it
Em Wed, 07 Sep 2011 13:41:45 +0100, Hannes Magnusson
escreveu:
On Wed, Sep 7, 2011 at 14:33, Pierre Joye wrote:
pajoye Wed, 07 Sep 2011 12:33:22 +
Revision: http://svn.php.net/viewvc?view=revision&revision=316345
Log:
- reject paths with trainling spa
On Wed, Sep 7, 2011 at 14:33, Pierre Joye wrote:
> pajoye Wed, 07 Sep 2011 12:33:22 +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=316345
>
> Log:
> - reject paths with trainling spaces using the very good new zend arg
>
> Changed paths:
>
On Wed, Sep 7, 2011 at 03:53, Ferenc Kovacs wrote:
> On Wed, Sep 7, 2011 at 3:29 AM, Stas Malyshev wrote:
>> Hi!
>>
>> Since we started to pay real attention to our unit tests now, I wonder if we
>> could set up some kind of frequently-running CI system that could be used to
>> screen commits and
Hi:
sure , most of them is const <-> no-const, also some incompatible
pointer type.
I have submitted a patch for trunk, https://bugs.php.net/bug.php?id=55629
if there is no problem, I will make a patch for 5.4 branch too.
in further, and after I set up a VS environ, I will try to fix
26 matches
Mail list logo
