Hello Stanislav,
why then not have ini as follows:
allow_url_(fopen|include)_(local|user|remote)
That is 6 for the six cases - or is that too easy?
We could also have the _remote case be an alias to keep the old style
and have full consistency.
best regards
marcus
Wednesday, May 30, 2007, 2:16
Hello Rasmus,
I wouldn't expect much problems from converting to SVN. What we have to
analyse is how well it can handle all the directoy linking and stuff we
did to overcome the CVS disadvantages. I changed a few repositories my self
and never experienced any issues. Also we are friends with mos
Wez said. A few more columns in the bugs database would help a lot. And
last but not least bug numbers could contain something like P for PHP,
L for PECL and R for PEAR. That way it is clear where they came from.
Another way is to extend them with a first digit and then merge the
tables. It is imh
I already said that svn 1.5 looks interesting. And it will hopefully
finally be worth the effort to migrate. And I wasn't just guessing that
we would have trouble migrating the repository. I actually tried it,
and the history was completely hosed. It requires manual intervention
to clean up. O
why then not have ini as follows:
allow_url_(fopen|include)_(local|user|remote)
That is 6 for the six cases - or is that too easy?
Because there's no need for 6 settings. Also, what
allow_url_include_local is supposed to mean? Why would one prohibit
local file access and local includes?
Th
Rasmus, hi,
We've kinda moved away from the problem in hand. Moving the entire
repository over to svn doesn't make it any easier to know when someone
commits something that should be merged and doesn't merge it. It also
doesn't do anything to resolve the relationship between PHP branch release
On 30.05.2007 04:15, Richard Lynch wrote:
This code outputs "3" in native mode and "Fatal error: Unsupported
operand types" in Unicode mode.
I believe this is an inconsistency and it should be possible to use
Unicode strings there.
Given that there are probably a bazillion PHP scripts written b
Steph Fox wrote:
> Rasmus, hi,
>
> We've kinda moved away from the problem in hand. Moving the entire
> repository over to svn doesn't make it any easier to know when someone
> commits something that should be merged and doesn't merge it. It also
> doesn't do anything to resolve the relationship b
Rasmus,
We've kinda moved away from the problem in hand. Moving the entire
repository over to svn doesn't make it any easier to know when someone
commits something that should be merged and doesn't merge it. It also
doesn't do anything to resolve the relationship between PHP branch
releases and
On 5/30/07, Steph Fox <[EMAIL PROTECTED]> wrote:
Given that this entire thread came about because at least two of the core
team don't have time to deal with merging to HEAD, that doesn't seem very
likely. But you're right to put an end to quick-fix and possibly
cvs-specific solutions. Does svn ev
Wez Furlong wrote:
> As Rasmus said, it's a job for someone to sit down with a copy of the
> repository, cvs2svn, a lot of time, and a lot of patience, to make the
> migration work... but we're not stopping anyone from volunteering :)
I converted our company's CVS to SVN a while ago and might be w
Good luck forcing people developing PHP to do this or even agreeing
doing it. Laziness, do-what-I-need and chaos has been the driving force
of PHP development all the time. That works, why change it? ;)
But this is nice idea to add, having bug reports linked to cvs commits..
--Jani
On Tue, 2007
On Wed, 2007-05-30 at 01:29 -0700, Rasmus Lerdorf wrote:
> Well, the problem is that if the work involved to do this is in any way
> CVS-specific, it will be throw-away work once we move away from CVS,
> which is inevitable. What we don't know at this point is the lifespan
> of CVS. I'm unmotivat
Hi internals,
It seems that there is a bug in the way some callbacks are handled. For
instance:
array('B', 'parent::who');
Here, the classname 'B' will only be used for inheritance checks with
the current scope,
but the actual resolution will be made using the current scope, and
'parent::wh
Hi,
On 5/30/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
Hi Gal,
The guys from WSO2 are working on WS-* support for PHP. It's called
Axis2 (based on Apache Axis2/C) and you can find it at Pecl
http://pecl.php.net/package/axis2. I believe they are also trying to
make the API compatible with ext/s
Richard Lynch wrote:
> Maybe I'm just confused (well, I'm always confused...) but if a Class
> has multiple children, how the heck would PHP know which child:: to
> call?...
the use of the name 'child' is very confusing, I would prefer 'super' or
'static' ...
regardless the concept is actually qu
Jani Taskinen wrote:
> On Wed, 2007-05-30 at 01:29 -0700, Rasmus Lerdorf wrote:
>> Well, the problem is that if the work involved to do this is in any way
>> CVS-specific, it will be throw-away work once we move away from CVS,
>> which is inevitable. What we don't know at this point is the lifespa
Hi all,
I'm a bit concerned by the headlong rush to refactor phpbugsweb to
include PEAR and PECL bugs. The concept is fine by me, but starting
with phpbugsweb as the starting point is a big mistake if you plan to
include PEAR bugs. The PEAR bug tracker has several killer features
that you will h
> -Original Message-
> From: Antony Dovgal [mailto:[EMAIL PROTECTED]
> Sent: 30 May 2007 09:21
> To: [EMAIL PROTECTED]
> Cc: php-dev
> Subject: Re: [PHP-DEV] bitwise operations and Unicode strings
>
> On 30.05.2007 04:15, Richard Lynch wrote:
> >> This code outputs "3" in native mode a
Stanislav Malyshev wrote:
It seems that there is a bug in the way some callbacks are handled.
For instance:
array('B', 'parent::who');
I'm not sure such thing should be even supported. I.e. I'd expect it
to try and call method named 'parent::who' in class B, which would
fail since you can't
It seems that there is a bug in the way some callbacks are handled. For
instance:
array('B', 'parent::who');
I'm not sure such thing should be even supported. I.e. I'd expect it to
try and call method named 'parent::who' in class B, which would fail
since you can't define such method name. I
EG(scope) is used by zend_u_fetch_class to get the parent/current class,
I'm only altering it temporarily before zend_u_fetch_class and restore
it after that, no harm done.
I was speaking about 5.2 patch, didn't check the HEAD one.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]
Hey Greg,
I'm a bit concerned by the headlong rush to refactor phpbugsweb to
include PEAR and PECL bugs.
DON'T PANIC! There's not really a headlong rush to combine them all, it's
just Marcus brainstorming and me agreeing for the sake of the PECL devs
(especially but not only those with core
Steph Fox wrote:
> Hey Greg,
>
>> I'm a bit concerned by the headlong rush to refactor phpbugsweb to
>> include PEAR and PECL bugs.
>
> DON'T PANIC! There's not really a headlong rush to combine them all,
> it's just Marcus brainstorming and me agreeing for the sake of the
> PECL devs (especially
> From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
>
> According to the plan below, attached is the patch that
> restricts user
> streams from executing dangerous operations inside include context.
> Please comment.
I see that you added a boolean arg to stream_wrapper_register(). Why
could
I see that you added a boolean arg to stream_wrapper_register(). Why
couldn't it be an integer mask of OR-ed predefined constants, providing
some space for more stream options. A local stream would be created with :
stream_wrapper_register($protocol,$class,STREAM_IS_LOCAL);
Well, it could be
Hello Gwynne,
A suggestion: please add something about exceptions, creating and throwing
them, implementing try/catch blocks. I was looking for a way to catch
exceptions thrown by some userspace code, and I didn't find anything
except the PHP source.
Best regards
Francois
> -Original Mess
Stanislav Malyshev wrote:
EG(scope) is used by zend_u_fetch_class to get the parent/current
class, I'm only altering it temporarily before zend_u_fetch_class and
restore it after that, no harm done.
I was speaking about 5.2 patch, didn't check the HEAD one.
Oh, I see now what you mean. I porte
I read this email *AFTER* discussing with Gregory in IRC about current situation
of having 3 separate bug trackers in *.php.net. So now I'm hijacking this
coincidentally related thread for informing what happened during/after the
discussion. :D
Gregory Beaver kirjoitti:
I'm a bit concerned b
Hi,
I trying to find a reason why array functions are not allowed to be used as
normal arrays. To clarify, I'm allowed to write
$arr = array( "maria", "mario", "luigi", "luisa");
echo $arr[1];
but I'm not allowed to write
echo array( "maria", "mario", "luigi", "luisa")[1];
In PHP documentation
I notice that there are a number of places in HEAD where php 5 is still
mentioned - some build targets, file names, etc. Is there any reason for
it or it's just an omission and eventually only php 6 should be ever
mentioned in this branch?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PR
I trying to find a reason why array functions are not allowed to be
used as normal arrays. To clarify, I'm allowed to write
array(), despite its appearance, is not a function - it's an operator.
But it won't work with functions too.
Maybe is THIS the reason why it doesn't work in PHP? ;-)
The whole idea of having that number there is pretty stupid..why not just remove
them altogether..?
--Jani
Stanislav Malyshev kirjoitti:
I notice that there are a number of places in HEAD where php 5 is still
mentioned - some build targets, file names, etc. Is there any reason for
it or it's
The whole idea of having that number there is pretty stupid..why not
just remove them altogether..?
Could work too :)
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.
ATM I'm focusing only in getting all the projects (pear,php,pecl)
to use same codebase for their bugtrackers in this first phase.
Solving commit merge problems through adding some magic "link to bug"
thing in commits sounds so wrong to me..there's so much "fuzziness" involved.
This pear bugtrack
Hi Jani, sorry didn't realize this was a public exchange.
ATM I'm focusing only in getting all the projects (pear,php,pecl)
to use same codebase for their bugtrackers in this first phase.
At the risk of boring you, I'll repeat: 'Hmm I'm not familiar with PEAR
code base, but I can apprecia
On 5/30/07, Steph Fox <[EMAIL PROTECTED]> wrote:
Hi Jani, sorry didn't realize this was a public exchange.
> ATM I'm focusing only in getting all the projects (pear,php,pecl)
> to use same codebase for their bugtrackers in this first phase.
At the risk of boring you, I'll repeat: 'Hmm I'm n
Hi David,
Basically the PEAR codebase is an updated and upgrade version of the
PECL codebase, shouldn't be too complicated to do
Yes, but the problem is in relating either/both of them to the PHP
bugtracker codebase. Thankfully we have an expert in Jani who has
effectively told us to shut up
I also said inevitable :) For the reasons Rasmus mentions it makes very
much sense for us to move to SVN.
Over the years, as the PHP project has grown, we have increasingly felt
the shortcomings of CVS. In addition, there are likely to be additional
ways SVN can benefit our dev process.
At the end
Hi,
So I guess what we need is to figure out a bit what our current
development process is, what if it we actually want to keep and what we
are hoping to get in the future. Maybe we can brainstorm at php|vikinger
on this. One of the "processes" we have is that we have no formal
processes and
40 matches
Mail list logo
