Hello everyone,
My name is William Candillon. I'm developing the phpAspect project
(http://phpaspect.org) for the Google Summer of Code 2006.
My mentor is Sebastian Bergmann.
Phpaspect is a PHP language extension which implements aspect-oriented
programming. The phpaspect compiler weaves aspects
Without looking to deeply into this reincarnation my guess would be
that for CLI, Zeev's approach makes good sense.
Andi
At 08:04 PM 5/27/2006, Steph Fox wrote:
Thanks Xuefer...
This bug's been extant for a long time, and I only found out why
when I spent two days/nights trying to track down
At 01:00 PM 5/30/2006, Pierre wrote:
On Wed, 31 May 2006 00:58:34 +0500
[EMAIL PROTECTED] ("Alexander Pak") wrote:
On 5/30/06, Alexander Pak <[EMAIL PROTECTED]> wrote:
> As for me I don't really like "array_has_more" name.. maybe array_end?
I find *end confusing as well. array_has_more is unamb
Zeev and I designed each() to deprecate key()/current()/etc. which
came from PHP/FI 2. Maybe not exactly what you're looking for but
just want to point out that there have always been some issues with
the latter functions.
If each() isn't suitable (and/or you want something quicker) than I'm
OK
I think E_STRICT the way it is, is good enough. We don't need to make
it even more confusing by having lots of additional error levels. We
do mention in some E_STRICT msgs that things are deprecated
"Deprecated: ...". Some things are just best practices... Let's not
over complicate this and hav
I'd back the majority over this. Changes from E_STRICT to fatal in minor
versions is out of the question; most people still use PHP 4.3.*, and
this is something you're failing to consider here.
So that'd be a major version bump for them. :)
If they'd had E_STRICT messages in 4.3.*, sure...
right now the fate of E_STRICT error messages is uncertain. A few
people think those should change to fatal after a reasonable amount of
time, is two years (e.g. 5.0.0) reasonable. A few even think a minor
version like 5.1 to 5.2 is enough but the majortiy (at least i guess
so) wants the change o
Now if we were _really_ sneaky, we'd make E_DEVEL visible in 'lint mode'
only...
At 03:02 PM 5/30/2006, Marcus Boerger wrote:
whatever the patch looks like, it is a change from 5.0.0's E_STRICT
to a E_COMPILE_ERROR and actually fixes another problem. This raises
an interesting question. How
At 03:02 PM 5/30/2006, Marcus Boerger wrote:
whatever the patch looks like, it is a change from 5.0.0's E_STRICT
to a E_COMPILE_ERROR and actually fixes another problem. This raises
an interesting question. How long must we wait until we can follow the
E_STRICT idea and change a specific E_STRI
Hi Marcus,
right now the fate of E_STRICT error messages is uncertain. A few
people think those should change to fatal after a reasonable amount of
time, is two years (e.g. 5.0.0) reasonable. A few even think a minor
version like 5.1 to 5.2 is enough but the majortiy (at least i guess
so) wants
At 03:02 PM 5/30/2006, Marcus Boerger wrote:
whatever the patch looks like, it is a change from 5.0.0's E_STRICT
to a E_COMPILE_ERROR and actually fixes another problem. This raises
an interesting question. How long must we wait until we can follow the
E_STRICT idea and change a specific E_STRI
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Read the docs again. They do not claim that. I quote:
"Note: If magic_quotes_gpc is enabled, first apply stripslashes() to
the data. Using this function on data which has already been escaped
will escape the data twice." -- http://php.net/mysql_
Here's a question. The docs for mysql_real_escape_string claim that it
checks the magic_quotes_gpc setting and will stripslashes()
automatically. However, I see nothing in the code that indicates this.
Is it a documentation error?
Chris
Christopher Kings-Lynne wrote:
As a follow up I've a
Marcus Boerger wrote:
> Hello internals,
>
> right now the fate of E_STRICT error messages is uncertain. A few
> people think those should change to fatal after a reasonable amount of
> time, is two years (e.g. 5.0.0) reasonable. A few even think a minor
> version like 5.1 to 5.2 is enough but t
Hello Sebastian,
ok, changed back to old severity (E_STRICT) and kept the fix.
best regards
marcus
Tuesday, May 30, 2006, 2:04:56 PM, you wrote:
> Marcus Boerger wrote:
>> helly Mon May 29 20:06:44 2006 UTC
>>
>> Added files: (Branch: PHP_5_2)
>> /ZendEngine2/te
Hello internals,
right now the fate of E_STRICT error messages is uncertain. A few
people think those should change to fatal after a reasonable amount of
time, is two years (e.g. 5.0.0) reasonable. A few even think a minor
version like 5.1 to 5.2 is enough but the majortiy (at least i guess
so)
Let me second that. This was a long weekend in the US and I am just
getting to my email now as well. Some of us, for our own sanity, do
occasionally tune out for a couple of days.
-Rasmus
Andi Gutmans wrote:
Marcus,
Saturday when you sent this was the weekend which lasted until this
morni
Marcus Boerger wrote:
whatever the patch looks like, it is a change from 5.0.0's E_STRICT
I was just noticing a probable bug in the patch and felt like reporting
it, that's all. I didn't want to start a discussion about migration
paths but since you asked for my opinion, here it is...
to
Hello Christian,
whatever the patch looks like, it is a change from 5.0.0's E_STRICT
to a E_COMPILE_ERROR and actually fixes another problem. This raises
an interesting question. How long must we wait until we can follow the
E_STRICT idea and change a specific E_STRICT into a fatal error. Must
i
Marcus Boerger wrote:
-/* $Id: zend_compile.c,v 1.647.2.27.2.5 2006/05/27 18:23:48 johannes Exp $ */
+/* $Id: zend_compile.c,v 1.647.2.27.2.6 2006/05/29 20:06:43 helly Exp $ */
#include
#include "zend.h"
@@ -2028,8 +2028,9 @@
if (parent_flags & ZEND_ACC_ABSTRACT) {
c
Marcus,
Saturday when you sent this was the weekend which lasted until this
morning here in the US (and I happened to be away for the weekend). I
am now busy catching up on all emails so by tomorrow I'll probably be
able to respond.
I suggest in future to give people adequate time to read emai
On Wed, 31 May 2006 00:58:34 +0500
[EMAIL PROTECTED] ("Alexander Pak") wrote:
On 5/30/06, Alexander Pak <[EMAIL PROTECTED]> wrote:
> As for me I don't really like "array_has_more" name.. maybe array_end?
I find *end confusing as well. array_has_more is unambiguous and
perfectly matches the functi
As for me I don't really like "array_has_more" name.. maybe array_end?
On 5/31/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello internals,
just as a reminder for those that insist on being heared - you have been
heared. Here is your second try. I am not going to wait till the dawn of
time
On Tue, 30 May 2006 12:20:20 -0700
[EMAIL PROTECTED] ("Benjamin Muskalla") wrote:
> Need CVS access to commit the the pear package XML_DB_eXist.
>
> see pear-dev mailing list, pear propsal
> (http://pear.php.net/pepr/pepr-proposal-show.php?id=303)
>
> CVS account request also wanted by Pierre
C
Hello Pierre,
Tuesday, May 30, 2006, 9:39:44 PM, you wrote:
> On 5/30/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
>> Hello internals,
>>
>> just as a reminder for those that insist on being heared - you have been
>> heared. Here is your second try. I am not going to wait till the dawn of
>> t
On 5/30/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello internals,
just as a reminder for those that insist on being heared - you have been
heared. Here is your second try. I am not going to wait till the dawn of
time.
It is a long process but we will get somewhere.
One or two work days
Hello Antony,
thanks for looking this up :-)
best regards
,arcus
Tuesday, May 30, 2006, 2:32:29 PM, you wrote:
> On 30.05.2006 16:04, Sebastian Bergmann wrote:
>> Marcus Boerger wrote:
>>> hellyMon May 29 20:06:44 2006 UTC
>>>
>>> Added files: (Branch: PHP_5
Hello,
i guess i don'T get an answer to this do i?
Saturday, May 27, 2006, 10:32:13 PM, you wrote:
> Hello Andi, Zeev, Ilia,
> the attached patch adds three new functions that make calling
> functions a lot easier - at least for me in SPL. And it also does
> a few things correct which are p
Need CVS access to commit the the pear package XML_DB_eXist.
see pear-dev mailing list, pear propsal
(http://pear.php.net/pepr/pepr-proposal-show.php?id=303)
CVS account request also wanted by Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
Hello internals,
just as a reminder for those that insist on being heared - you have been
heared. Here is your second try. I am not going to wait till the dawn of
time.
best regards
marcus
Saturday, May 27, 2006, 11:27:43 PM, you wrote:
> Hello internals,
> i'd like to add two array functi
Hello Sebastian,
this is again an oversight of inheritance rules
for holw fucking BC we might be able to break the rule at different places
but well just remove my fix, i am to bored of discussing this
ciao
marcus
Tuesday, May 30, 2006, 2:04:56 PM, you wrote:
> Marcus Boerger wrote:
Short version:
zend_config.w32.h
#define USE_ZEND_ALLOC 1
-#define HAVE_ALLOCA 1
-#define HAVE_LIMITS_H 1
+
+#include <../main/config.w32.h>
In theory that's OK because main/config.w32.h has '#define HAVE_ALLOCA 1'
halfway down it.
In practice, the order actually matters.
- Steph
- Ori
On 30.05.2006 16:04, Sebastian Bergmann wrote:
Marcus Boerger wrote:
helly Mon May 29 20:06:44 2006 UTC
Added files: (Branch: PHP_5_2)
/ZendEngine2/tests bug37632.phpt
Modified files:
/ZendEngine2 zend_compile.c zend_object_handlers.c
Log
Marcus Boerger wrote:
> helly Mon May 29 20:06:44 2006 UTC
>
> Added files: (Branch: PHP_5_2)
> /ZendEngine2/testsbug37632.phpt
>
> Modified files:
> /ZendEngine2 zend_compile.c zend_object_handlers.c
> Log:
> - MFH Bugfix #3763
34 matches
Mail list logo
