You are wrong because __autoload() *is* called and you can load the class
on the-fly. The only problem is if the class does not exist in your code
base, in which case, your application should blow up!
Andi
At 07:44 AM 8/9/2005 +0200, Pierre-Alain Joye wrote:
On Mon, 08 Aug 2005 14:43:25
Derick Rethans schrieb:
I prefer not to comment on that :)
I might have something to do with that, but I am not sure.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals - PHP
At 07:57 AM 8/9/2005 +0200, Sebastian Bergmann wrote:
Andi Gutmans schrieb:
I just branched off PHP 5.1 (PHP_5_1).
Does that mean that PHP_5_1 is in feature-freeze or are changes like
the one Derick proposed (making type hint violations throw an exception
instead of raising a fatal error)
Andi Gutmans schrieb:
Feature-freeze.
Okay.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Mon, 2005-08-08 at 23:08 -0700, Andi Gutmans wrote:
You are wrong because __autoload() *is* called and you can load the class
on the-fly. The only problem is if the class does not exist in your code
base, in which case, your application should blow up!
The basic point is that is_a()
Hi Andi Gutmans, you wrote:
You are wrong because __autoload() *is* called and you can load the
class on the-fly. The only problem is if the class does not exist in
your code base, in which case, your application should blow up!
No insult intended, but this is just stubborn. You want to hear a
Hello Jessie,
Tuesday, August 9, 2005, 4:36:41 AM, you wrote:
Classes that had uppercase letters were not being handled properly in
namespace imports. The attached patch has this fix (thanks Maxx!). Also,
the attached patch includes the default behavior of resolving
simple-imported class
On Mon, 8 Aug 2005, Andi Gutmans wrote:
You are wrong because __autoload() *is* called and you can load the class on
the-fly. The only problem is if the class does not exist in your code base, in
which case, your application should blow up!
Right, and there is no reason why it shouldn't blow
Hi Marcus Boerger, you wrote:
Hello Jessie,
Tuesday, August 9, 2005, 4:36:41 AM, you wrote:
1) I asked this before, but it wasn't answered: is there any reason why .php
is not a default extension for spl_autoload?
PEAR uses .inc.php and i as well as all i have spoken too like .inc better
On Tue, 9 Aug 2005, Sebastian Bergmann wrote:
Andi Gutmans schrieb:
I just branched off PHP 5.1 (PHP_5_1).
Does that mean that PHP_5_1 is in feature-freeze or are changes like
the one Derick proposed (making type hint violations throw an exception
instead of raising a fatal error)
On Mon, 8 Aug 2005, Andrei Zmievski wrote:
On Aug 4, 2005, at 12:09 AM, Derick Rethans wrote:
Then you don't do it - it's not a requirement... just an optional thing
(and ofcourse you can't do the __have_prop() thing then that you
suggested below.
Why not? _have_prop() should be able
On Mon, 8 Aug 2005, Justin Hannus wrote:
The way ActionScript 2.0 solves this is with set and get keywords on function
declarations. Any class can contain as many setter/getters as they need,.
Since we dont want to introduce any new keywords how about something similar
with __set and __get?
On Tue, 9 Aug 2005, Sebastian Bergmann wrote:
Derick Rethans schrieb:
I prefer not to comment on that :)
I might have something to do with that, but I am not sure.
You've nothing to do with that.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
On Tue, 09 Aug 2005 14:31:08 +0800
[EMAIL PROTECTED] (Alan Knowles) wrote:
On Mon, 2005-08-08 at 23:08 -0700, Andi Gutmans wrote:
You are wrong because __autoload() *is* called and you can load
the class on the-fly. The only problem is if the class does not
exist in your code base, in
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
This technique is already frequently used to cope with lazy
loaded code, which even with cached code compilers, is pretty
damn efficient in a scripted language (less IO operations, less
parsing, less memory...)
It is not about the fact we
Now that we branched it's time to rename HEAD to something else than 5.1
in order to have different version numbers. Although the name PHP 5.5
was mentioned before, I do think we should call it PHP 6.0. As the
Unicode support is quite a drastic change. Going with PHP 6.0 also
allows us to be a
Alan Knowles wrote:
On Mon, 2005-08-08 at 23:08 -0700, Andi Gutmans wrote:
You are wrong because __autoload() *is* called and you can load the class
on the-fly. The only problem is if the class does not exist in your code
base, in which case, your application should blow up!
The basic
On Tue, 9 Aug 2005, Derick Rethans wrote:
Now that we branched it's time to rename HEAD to something else than 5.1
in order to have different version numbers. Although the name PHP 5.5
was mentioned before, I do think we should call it PHP 6.0. As the
Unicode support is quite a drastic change.
Derick Rethans schrieb:
I do think we should call it PHP 6.0
+1
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
6.0 if the Namespaces patch makes it in, 5.5 with Unicode only? ;)
- David
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 09, 2005 10:41 AM
To: PHP Developers Mailing List
Subject: [PHP-DEV] PHP 5.5 or 6.0
Now that we branched it's time
Hi
6.0 if the Namespaces patch makes it in, 5.5 with Unicode only? ;)
Namespaces patch is a patch so it's fine for version 5.5, if you would
ask me.
I would see the unicode support as a bigger step forward.
--
Yours,
Weyert de Boer ([EMAIL PROTECTED])
innerfuse*
On Tue, 9 Aug 2005 10:15:15 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
This technique is already frequently used to cope with lazy
loaded code, which even with cached code compilers, is pretty
damn efficient in a scripted
On Tue, 9 Aug 2005, Weyert de Boer wrote:
6.0 if the Namespaces patch makes it in, 5.5 with Unicode only? ;)
Namespaces patch is a patch so it's fine for version 5.5, if you would
ask me. I would see the unicode support as a bigger step forward.
I'm not sure what you guys are discussing
On Tue, 9 Aug 2005 10:41:07 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
Now that we branched it's time to rename HEAD to something else
than 5.1 in order to have different version numbers. Although the
name PHP 5.5 was mentioned before, I do think we should call it
PHP 6.0. As the
MWto *load* a class for checking an object to be of a specific class
MW
MW- just because of the simple reason that the checked object can not
MW be of *that* class, because it doesn't exist.
I think, if we leave alone the implementation, there's nothing logically
wrong to return false if we ask
Hi
I'm not sure what you guys are discussing here, but it's definitely not
up to any non-contributor to decide which version number we pick. And
making it dependable on whether some patch goes in or not doesn't make
sense at all.
Such a kind way of response on your site, I won't even
Hi Stanislav Malyshev, you wrote:
Now the only problem I see here is if you
type Bar when you intended to type Baz - but I'm not sure this warrants
the fatal error.
Yes, unit tests could catch such issues.
MWThere could be a flag to let instanceof *not* die -
MWa little less generic but
Alan Knowles wrote:
The basic point is that is_a() provided negative testing of non-existant
classes
if (!is_a($obj, SomeRarelyUsedClass)) {
instance_of does not, and can not, at present.
You can use `if (!($obj instanceof SomeRarelyUsedClass))` ;)
Why statement `$obj instanceof
On Tue, 9 Aug 2005 12:03:28 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
On Tue, 9 Aug 2005, Weyert de Boer wrote:
6.0 if the Namespaces patch makes it in, 5.5 with Unicode
only? ;)
Namespaces patch is a patch so it's fine for version 5.5, if
you would ask me. I would see
A minimum of respect does not cost anything. The author of this
patch invest a lot of time in it.
Oh well, one of the reasons why the patch for the parser won't be
available, no faster parser for PHP. Neither the other stuff I was
working on, will just use for in my own compiles.
A
On Tue, 09 Aug 2005 13:24:56 +0300
[EMAIL PROTECTED] (Pasha Zubkov) wrote:
Alan Knowles wrote:
The basic point is that is_a() provided negative testing of
non-existant classes
if (!is_a($obj, SomeRarelyUsedClass)) {
instance_of does not, and can not, at present.
You can use
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
But I have some about what we will do in php 5.x (without unicode,
namespace), and 6.0.
I like to see once that we clearly and loudly define what we want
in or not. So I may waste less time than before.
I see it as:
4.4 - no new features, no new
On Tue, 9 Aug 2005 12:47:50 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
But I have some about what we will do in php 5.x (without
unicode, namespace), and 6.0.
I like to see once that we clearly and loudly define what we
want
6.0 - to define, for now we have two candidates,
unicode for sure, namespace to be discussed/approved/
whatever
How 'bout PIMP for 6.0, Pierre? *hint hint* ;)
- David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
On Tue, 9 Aug 2005 12:47:50 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
But I have some about what we will do in php 5.x (without
unicode, namespace), and 6.0.
I like to see
Sorry, I forgot to add subject line to the old mail.
On Mon, 08 Aug 2005 23:56:24 -0700, Rathna N [EMAIL PROTECTED]
said:
Hi All,
this is first my post to this list.
I'm interested to do QA related contributions to PHP.
Pls do find the test scripts for Calendar extension at below links,
On Tue, 9 Aug 2005, Rathna N wrote:
Sorry, I forgot to add subject line to the old mail.
the [EMAIL PROTECTED] list would be the best list for this subject.
As for the tests, it would be nice if you could provide a unified diff
against CVS's HEAD. That's much easier than have to download a
As already mentioned earlier, there does not seem to be
any extension or core code using static properties for
internal classes.
I'd like to request a change in their behaviour/implementation.
Currently static properties of internal classes are allocated
persitently which limits their usage and
Quoting Weyert de Boer [EMAIL PROTECTED]:
Hi
I'm not sure what you guys are discussing here, but it's definitely
not up to any non-contributor to decide which version number we
pick. And making it dependable on whether some patch goes in or not
doesn't make sense at all.
Such a kind way
I wrote:
Therefore I'd suggest changing that so that they'll be
initialized and destructed for each request, which means
that there will need to be some form of hooks, which
Let me change that part... :)
There's no need for any hooks as there's already
RINIT() and RSHUTDOWN(), so I guess all
Derick Rethans wrote:
I see it as:
4.4 - no new features, no new additions. Just bugfixes.
5.1 - no new major features, just smaller additions.
6.0 - brand new experimental stuff.
This breakdown looks good, although it'd be nice to quantify just what
kind of smaller additions are acceptable
I've noticed that in a script of mine, memory consumption can explode quite
drastically when Exceptions are thrown, opposed to very normal memory
consumption when exceptions are not thrown.
This is the idea:
?
class Obj
{
function process($i)
{
// do a lot of stuff, occupy a lot of
It is very likely that this has something to do with DOM. It's a huge piece
of code though, making it hard to test where the problem really lies.
Ron Korving [EMAIL PROTECTED] schreef in bericht
news:[EMAIL PROTECTED]
I've noticed that in a script of mine, memory consumption can explode
quite
On Tue, Aug 09, 2005 at 02:31:08PM +0800, Alan Knowles wrote:
It is not about the fact we 'can' load the class, but that we dont
'want' to load the class.. - it's a waste of resources, memory, cpu etc.
just for the sake of CS perfection..
Hear, hear!
--Dan
--
T H E A N A L Y S I S A
On Aug 9, 2005, at 12:18 AM, Derick Rethans wrote:
Ah,you meant that __have_prop() should always return the full array of
things that are supported. That is fine, as long as we can have this
generated from the abstract properties that people declared (so that
they can be documented properly
Andi et al,
I am hoping to finish rough draft of HTTP input decoding today. I'd
rather not merge in half-finished stuff. Besides that, do you think we
need a write up on what has been changed in the core, new APIs,
function upgrade guidelines, etc?
Ping me on IM if you can.
-Andrei
On Aug
Nonetheless, Rasmus, isn't it something to work on? Like Steve said, #1 and
#2 can be accomplished, and that would at least be a good start. You are
right about the libraries, but in time, even these may become thread safe
(of course, likely not by anyone from the PHP-community). Why is this
I am not familiar with PIMP, but I would not get it in 6.0 until we have
HOES (HTML Output Extension Server) complete. Then we can start on the
client(s) for 6.1 :-).
--
Jessie
David Zülke [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
6.0 - to define, for now we have two
If we find thread safety problems in PHP we will fix them, of course.
It's not like we ignore them. Same goes for extensions, except for
those which are specifically designed to access libraries that show no
signs of ever becoming thread safe.
At the same time, you need to recognize that
Hi Ron,
On Tuesday 09 August 2005 19:09, Ron Korving wrote:
Nonetheless, Rasmus, isn't it something to work on? Like Steve said, #1 and
#2 can be accomplished, and that would at least be a good start. You are
right about the libraries, but in time, even these may become thread safe
(of
Maybe a little late throwing my 2 cents in, but here they are anyway.
If you're writing an app that can optionally use a component that is
not present, there is nothing conceptually wrong with calling
instanceof to determine if that support is present; PHP should not
blow up. If the class is not
On Aug 9, 2005, at 5:56 AM, Pierre-Alain Joye wrote:
On Tue, 9 Aug 2005 10:15:15 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
This technique is already frequently used to cope with lazy
loaded code, which even with cached code
On 8/9/05, Pierre-Alain Joye [EMAIL PROTECTED] wrote:
5.x - small additions (in my case, gd updates and merge,
xmlwriter)
This is what PECL is for. We're trying to move stuff out of the core
so that these kinds of updates are easier for everyone to work on and
use.
--Wez.
--
PHP
Now that we branched it's time to rename HEAD to something else than 5.1
in order to have different version numbers. Although the name PHP 5.5
was mentioned before, I do think we should call it PHP 6.0. As the
Unicode support is quite a drastic change. Going with PHP 6.0 also
allows us to
Bitch, where are my page views?
-Andrei
On Aug 9, 2005, at 10:26 AM, Darrell Brogdon wrote:
I think by client(s) you mean JOHNS (Justified Output with Heuristic
Notifications Server).
On Aug 9, 2005, at 11:14 AM, Jessie Hernandez wrote:
I am not familiar with PIMP, but I would not get it
Hello Michael,
Tuesday, August 9, 2005, 2:19:25 PM, you wrote:
I wrote:
Therefore I'd suggest changing that so that they'll be
initialized and destructed for each request, which means
that there will need to be some form of hooks, which
Let me change that part... :)
There's no need for
On 8/8/05, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
3. Problems with thread-safety of modules
You missed the most serious one. Thread safety problems in random
libraries you link in and we have absolutely no control over those.
OK, I am confused. I always thought (an assumption with nothing
On Aug 9, 2005, at 3:12 PM, steve roussey wrote:
On 8/8/05, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
3. Problems with thread-safety of modules
You missed the most serious one. Thread safety problems in random
libraries you link in and we have absolutely no control over those.
OK, I am
Wez Furlong wrote:
On 8/9/05, Pierre-Alain Joye [EMAIL PROTECTED] wrote:
5.x - small additions (in my case, gd updates and merge,
xmlwriter)
This is what PECL is for. We're trying to move stuff out of the core
so that these kinds of updates are easier for everyone to work on and
I am not stubborn. I just think this has close to 0 use in real-life (or
you're doing some weird coding). In any case, for the one in a million
case, I think Reflection is good enough.
Andi
At 08:40 AM 8/9/2005 +0200, Michael Wallner wrote:
Hi Andi Gutmans, you wrote:
You are wrong because
I think Unicode warrants a major version. I'd go with PHP 6 and aim to
release it before Perl 6 :)
From judging by a Perl 6 talk we attended at OSCON, that might actually be
a realistic goal.
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On 8/9/05, steve roussey [EMAIL PROTECTED] wrote:
My stuff is far bigger and busier than yours
My spewing of stuff...
I often write things to make me feel better and delete them before
hitting send. Sort of stream of consciousness that I edit before
sending. IRasmus, apologize for being an
Andi Gutmans wrote:
I am not stubborn. I just think this has close to 0 use in real-life (or
you're doing some weird coding). In any case, for the one in a million
case, I think Reflection is good enough.
I worded my example a bit wrong. I dont like people loading PEAR.php on
demand. However
My the way, the performance argument wouldn't work because even if this
would be supported, we'd have to first try and load the class to make
sure we can actually check the instanceof, and only if the class doesn't
load then we would return false. So you won't save that step of trying to
load
Hi Michael,
I agree that this might be the right way to resolve the current issues. I
mentioned it to Marcus at OSCON.
Andi
At 02:19 PM 8/9/2005 +0200, Michael Wallner wrote:
I wrote:
Therefore I'd suggest changing that so that they'll be
initialized and destructed for each request,
On Tue, 09 Aug 2005 12:29:45 -0700
Andi Gutmans [EMAIL PROTECTED] wrote:
we'd have to first try and load the class to make
sure we can actually check the instanceof
Pardon me? :)
As I said in my 2nd post about this topic, the problem (and only
problem here) is that in the lexer, the right
Hi Ilia,
I think it's hard to define ahead of time, but usually I prefer allowing
non-BC breaking and non-infrastructure changes, for example, a new
function, a new optional parameter to a function, some minor functionality...
If it's a change in the infrastructure of PHP, then chances are
Can you send a complete script which also passes $data that reproduces the
problem? Thanks.
At 05:27 PM 8/9/2005 +0200, Ron Korving wrote:
The problem occurs in this particular situation:
public function process($data)
{
$largeResultSet = $this-xmlParser-parseString($data);
foreach
On Tue, 09 Aug 2005 12:25:27 -0700
[EMAIL PROTECTED] (Andi Gutmans) wrote:
I think Unicode warrants a major version. I'd go with PHP 6 and
aim to release it before Perl 6 :)
From judging by a Perl 6 talk we attended at OSCON, that might
actually be a realistic goal.
No rush please... Better
We've made a start a long time ago, and we do our best to keep all of PHP
thread-safe. On paper it is. When a bug appears we fix it. Is it a risk to
run it... I think it is but I have seen people running it successfully on
IIS for a long time. (I still think that's a bad idea though).
Andi
steve roussey wrote:
I know my name can be easily traced to a website I own that only gets
about 10M pv/day but I also work as a consultant for another that gets
an order of magnitude more. So perhaps you do get more then them and
get 1B pv/day and your dad can beat up my dad. Ug. Strike that.
steve roussey wrote:
The setup we are striving for is to keep connections open all the way
down the chain to the database. Ideally this would mean that we would
use Apache 2.2 with the event MPM to hold user connections. Then the
PHP threads would ideally hold persistent connections to the
At 02:07 PM 8/9/2005 -0400, George Schlossnagle wrote:
To duplicate the old semantic now you need to do:
if(class_exists('MyFoo') $obj instanceof MyFoo) { }
which is definitely uglier than
if(is_a($obj, 'MyFoo')) {}
George
But that's a good point. For the few frameworks that might require
Per my online conversation with Andi, I will be committing the gcov
stuff prior to the deep-freeze tomorrow morning -- expect a cvs commit
and a follow-up e-mail on usage early tomorrow morning.
John
On Mon, 2005-08-08 at 23:11 -0700, Andi Gutmans wrote:
At 07:57 AM 8/9/2005 +0200, Sebastian
At 09:41 PM 8/9/2005 +0200, Pierre-Alain Joye wrote:
On Tue, 09 Aug 2005 12:25:27 -0700
[EMAIL PROTECTED] (Andi Gutmans) wrote:
I think Unicode warrants a major version. I'd go with PHP 6 and
aim to release it before Perl 6 :)
From judging by a Perl 6 talk we attended at OSCON, that might
On Tue, 09 Aug 2005 12:44:59 -0700
Andi Gutmans [EMAIL PROTECTED] wrote:
But that's a good point. For the few frameworks that might
require such functionality they can use class_exists() or other
methods. That doesn't mean we should change instanceof for
mainstream usage which is 99.99%.
Hello George,
Tuesday, August 9, 2005, 9:48:22 PM, you wrote:
On Aug 9, 2005, at 3:25 PM, Andi Gutmans wrote:
I think Unicode warrants a major version. I'd go with PHP 6 and aim
to release it before Perl 6 :)
From judging by a Perl 6 talk we attended at OSCON, that might
actually be a
At 09:55 PM 8/9/2005 +0200, Pierre-Alain Joye wrote:
On Tue, 09 Aug 2005 12:44:59 -0700
Andi Gutmans [EMAIL PROTECTED] wrote:
But that's a good point. For the few frameworks that might
require such functionality they can use class_exists() or other
methods. That doesn't mean we should change
Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed.
The changes are relatively minor and I've already run it past Andi. I'm
trying to get around one last problem that maybe someone else can take
care of:
The basic issue is that our parsers have broken file/line preprocessor
IIRC, we have a script that does this already for our release
tarballs; should save some effort.
--Wez.
On 8/9/05, John Coggeshall [EMAIL PROTECTED] wrote:
Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed.
The changes are relatively minor and I've already run it past
I also wrote one, i don't care which we use... it's a 5 line shell
script :)
On Tue, 2005-08-09 at 16:40 -0400, Wez Furlong wrote:
IIRC, we have a script that does this already for our release
tarballs; should save some effort.
--Wez.
On 8/9/05, John Coggeshall [EMAIL PROTECTED] wrote:
Hi,
I've already had a change to test your patch (I've even have asked my
university for a server to put ithe reports on-line).
I've also came into this issue, which happens because re2c is called in the
wrong way (the output is printed to stdout, rather than directly to the
file). Those
Hello John,
for the .re ones i could simply release re2c 0.9.10 and you use the new
switch we especially made for that. If i knew we were going for 5.1 i had
probably done that at OSCON but i didn't see any action required until just
now.
best regards
marcus
Tuesday, August 9, 2005, 10:44:01
Andi Gutmans wrote:
My the way, the performance argument wouldn't work because even if this
would be supported, we'd have to first try and load the class to make
sure we can actually check the instanceof, and only if the class doesn't
load then we would return false. So you won't save that
Hello Nuno,
that's also absolutley correct for most .re'S.
Tuesday, August 9, 2005, 10:49:02 PM, you wrote:
Hi,
I've already had a change to test your patch (I've even have asked my
university for a server to put ithe reports on-line).
I've also came into this issue, which happens
JFYI: -o doesn't work on all versions of re2c
--Wez.
On 8/9/05, Nuno Lopes [EMAIL PROTECTED] wrote:
Hi,
I've already had a change to test your patch (I've even have asked my
university for a server to put ithe reports on-line).
I've also came into this issue, which happens because re2c is
Hello Wez,
just to remind you: you are the only one using an old unsupport version
that doesn't come with -o.
marcus
Tuesday, August 9, 2005, 10:55:43 PM, you wrote:
JFYI: -o doesn't work on all versions of re2c
--Wez.
On 8/9/05, Nuno Lopes [EMAIL PROTECTED] wrote:
Hi,
I've already
On Aug 9, 2005, at 4:55 PM, Wez Furlong wrote:
JFYI: -o doesn't work on all versions of re2c
Since when has PHP been concerned about not requiring the most-most
recent version of a library, let alone a development tool?
George still sore about having to upgrade libxml2 every couple weeks
No, I'm not (both not the only one using an older version, nor am I
necessarily using an older version).
Until someone points out a re2c bug that actually impacts PHP, I'm in
no rush to run around upgrading more than 20 machines.
--Wez.
On 8/9/05, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello
Hello Wez,
i fixed some bugs in re2c since -o was added. Some of those were serious
ones. Whether they affect pdo i cannot tell but for one issue i know that it
may affect ext/standard usage (depending on the compiler iirc). Maybe jani
can recall the reasons why and when we increased the re2c
Weiredly had the wrong adress in my contacts. So, here's what was
intended to get here...
Original Message
Hi all!
Sebastian has blogged [1] about FrOSCon, a pondon to FOSDEM in Germany,
St. Augustin. If there is interesst, I'd love to see a PHP/PECL/PEAR
room there.
On 8/9/05, Andreas Korthaus [EMAIL PROTECTED] wrote:
By using lighttpd with fastcgi we seperate the webserver process from
php processes (which could even work on other machines)...
Someone else emailed me about using FastCGI with Apache 2.1/event but
I just figured that there would be a
On Tue, 2005-08-09 at 21:49 +0100, Nuno Lopes wrote:
BTW, there was an error in your patch: it cleans the *.gcno files (which are
generated at compile time) in cov_gen_clean() before running lcov, thus
breaking the proccess.
Opps. I'll fix that when I commit. As soon as we get the parsers
steve roussey wrote:
On 8/9/05, Andreas Korthaus [EMAIL PROTECTED] wrote:
By using lighttpd with fastcgi we seperate the webserver process from
php processes (which could even work on other machines)...
Someone else emailed me about using FastCGI with Apache 2.1/event but
I just figured
Hi Steve,
From my experiences, FastCGI performance is comparable to mod_php.
Andi
At 02:24 PM 8/9/2005 -0700, steve roussey wrote:
On 8/9/05, Andreas Korthaus [EMAIL PROTECTED] wrote:
By using lighttpd with fastcgi we seperate the webserver process from
php processes (which could even work
That is great to know. In that case, I won't worry about threading
again. I'm assuming that the 4.3.0 Release Announcement that FastCGI
was removed is bogus or reversed.
Unfortunately my source for mysql connection pooling was never
upgraded to support 4.1's APIs. If anyone knows one, pass it by
Marcus Boerger schrieb:
regarding static props the solution is to define another hash table
in the class_entry that holdes the initial values for the static
variables. During minit these would be copied to the used hash table,
done. But even though the solution is pretty easy i do not know if
On Tue, Aug 09, 2005 at 02:07:27PM -0400, George Schlossnagle wrote:
if(class_exists('MyFoo') $obj instanceof MyFoo) { }
Unfortunately, class_exists() still calls __autoload(). Un-deprecating
is_a() seems to be an easy way to resolve this situation.
--Dan
--
T H E A N A L Y S I S A
Hello Daniel,
RTFM: try class_exists(..., false)
marcus
Wednesday, August 10, 2005, 12:38:49 AM, you wrote:
On Tue, Aug 09, 2005 at 02:07:27PM -0400, George Schlossnagle wrote:
if(class_exists('MyFoo') $obj instanceof MyFoo) { }
Unfortunately, class_exists() still calls __autoload().
On Wed, Aug 10, 2005 at 01:03:06AM +0200, Marcus Boerger wrote:
Wednesday, August 10, 2005, 12:38:49 AM, you wrote:
On Tue, Aug 09, 2005 at 02:07:27PM -0400, George Schlossnagle wrote:
if(class_exists('MyFoo') $obj instanceof MyFoo) { }
Unfortunately, class_exists() still calls
1 - 100 of 108 matches
Mail list logo
